حرفهایی برای نگفتن

  • یوسف مهرداد بی‌بالان

مقدمه:

در دوره هایی که برگزار می کنم معمولا دانشجویان باید یک پروژه را انجام بدهند. میزان مشارکت دانشجویان در پروژه، شدت و ضعف دارد. اما در یکی از دوره ها، دانشجویان آن قدر خوب کار کردند که خیلی تحت تأثیر قرار گرفتند. این نوشته را برای آنها نوشتم.

نامه:

سلام، شب به خیر!
کارهای شما در پروژه‌ی دوره متدهای چابک، مرا بسیار تحت تاثیر قرار داد. این نوشته را در پی آن نوشتم.

«حرفهایی برای نگفتن»
ای کاش آن قدر سرمایه داشتم که می‌توانستم هزینه‌ی یک زندگی راحت را برایتان فراهم کنم و ازتان می‌خواستم که ایده‌ای را انتخاب کنید و آن را اجرا کنید. همان طور که به دنبال تاکسی‌یاب هستید. ایده‌ای که زندگی را برای مردم راحت‌تر کند و رفاه آنان را افزایش دهد.
ای کاش می‌توانستم فضایی برایتان فراهم کنم که همان قدر که در تاکسی‌یاب خوشحال هستید، در آنجا نیز کار کنید و خوشحال باشید.
نه به سیستم حضور و غیاب نیازی بود و نه به مدیری!
فقط هیجان بود، شادی بود و تلاش!
مسابقه‌ای که رقیب‌اش، فقط خودمان بودیم.
ای کاش می‌توانستیم با این عمر، با این نعمت خدادادی، کاری کنیم که بتوانیم با افتخار زیرش را امضاء کنیم.
به امید آینده
یوسف مهرداد
چهارم اسفند نود و چهار

برنامه‌ریزی چندسطحی در اسکرام – بخش سوم

  • یوسف مهرداد بی‌بالان

مترجم: یاسر کازرونی

برنامه‌ریزی انتشار

هدف از برنامه‌ریزی انتشار، ایجاد توازن[1] بین محدوده، تاریخ انتشار و بودجه در تحویل‌ تدریجی محصول است.

معمولاً در توسعه­ی محصول، منطقی و ضروری است که برنامه‌ریزی انتشار پس از ترسیم چشم‌انداز (برنامه‌ریزی محصول) و قبل از شروع اولین اسپرینتِ هر انتشار انجام شود. در این مقطع از کار می‌توانید برنامه‌ای برای انتشار تهیه کنید که بین میزان کاری که می­توانید انجام دهید و تاریخ انتشار، تعادل ایجاد ‌کند.

برای تعیین تعداد ویژگی‌هایی که می‌توانید در تاریخ معینی تحویل دهید (انتشار با تاریخ ثابت) یا تعیین تاریخ تحویل مجموعه‌ای از ویژگی­ها (انتشار با محدوده‌ی ثابت) باید تعداد قابل قبولی از اقلام بک‌لاگ محصول را ایجاد و برآورد کنید.

یک روش ساده برای تصویرسازی[2] یک انتشار، کشیدن خطی افقی بر روی بک‌لاگ محصول است (شکل 15-3). اقلام بالای این خط در این انتشار قرار دارند و اقلام زیر این خط در این انتشار قرار نمی‌گیرند. به مرور زمان که دید بهتری از محصول پیدا می‌کنید، ممکن است این خط به سمت بالا یا پایین جا‌به‌جا شود. در فصل 18 درباره­ی روش تعیین محل این خط توضیح خواهیم داد.

شکل 153: استفاده از خط انتشار در بک‌لاگ محصول

1-1

حالا به آسانی می‌توانید ارتباط بین نقشه‌ی راه محصول و بک‌لاگ محصول را برقرار کنید و به کمک آن جزییات بیش‌تری از محتوای چند انتشار آتی در نقشه‌ی راه محصول دست پیدا کنید (شکل 15-4). هر انتشار در نقشه‌ی راه محصول با مجموعه‌ای از ویژگی‌ها در بک‌لاگ محصول در ارتباط است.

شکل 154: نگاشت انتشارهای نقشه‌ی راه محصول به بک‌لاگ محصول

2-1

برنامه‌ی انتشار باید دارای بُعد زمان نیز باشد. بُعد زمان را می‌توان با اسپرینت‌هایی که برای تکمیل انتشار لازم است نشان داد. اغلب انتشارها از نظر حجم کار، بزرگ هستند و ویژگی‌های موجود در آنها را نمی­توان در یک اسپرینت انجام داد و تمام کرد (شکل 15-5).

شکل 155: هر انتشار می­تواند شامل یک یا چند اسپرینت باشد

3-1

ممکن است در برنامه‌ریزی انتشار بخواهید پا را فراتر بگذارید و ویژگی‌هایی را که در چند اسپرینت اول قابل تحویل‌اند تخمین بزنید. این کار می­تواند برای ایجاد هماهنگی بین چند تیم یا درخواست زودتر از موعد یک تیم برای سخت‌افزار، ابزار یا کمکِ دیگران، مفید باشد. اما تخمین بیش از چند اسپرینت معمولاً بی‌فایده است و اصلِ«به‌موقع»[3] و «به اندازه‌ی کافی»[4] بودن برنامه‌ریزی را نقض می‌کند.

برنامه‌ریزی اسپرینت

برنامه‌ریزی اسپرینت در ابتدای هر اسپرینت انجام می‌شود و طی آن در مورد اقلامی از بک‌لاگ محصول که در اسپرینت جاری انجام خواهند شد، توافق می‌شود. تیم در این فعالیت، بک‌لاگ اسپرینت را تهیه می‌کند که شامل کارهایی است که در سطح وظیفه­اند[5] و انجام آنها برای تکمیل اقلام بک‌لاگ محصول ضروری است (شکل 15-6).

تیم در برنامه‌ریزی اسپرینت، سطح بعدی از رویکرد برنامه‌ریزی تفصیلی[6] و به‌موقع را انجام می­دهد[7]. جزییات برنامه‌ریزی اسپرینت را در فصل 19 بررسی خواهیم کرد.

برنامه‌ریزی روزانه

جزیی‌ترین سطح برنامه‌ریزی تیم در جلسات روزانه‌ی اسکرام اتفاق می‌افتد. همان‌طور که قبلاً گفته شد برنامه‌ریزی روزانه فعالیتی است که در آن، اعضای تیم دور هم جمع می‌شوند و هر کس به­نوبت توضیح می‌دهد که:

  • از اسکرام روزانه‌ی قبلی تا حالا چه کارهایی انجام داده است
  • چه کارهایی را برای امروز برنامه‌ریزی کرده است
  • با چه مشکلات و موانعی روبه­روست

شکل 156: هر اسپرینت دارای یک بک‌لاگ اسپرینت است

4-1

در اسکرام روزانه، اعضای تیم به صورت دسته­جمعی و به شیوه‌ای بسیار شفاف، تصویر کلانی از برنامه‌ی روزانه‌ی­ تیم را ارائه می‌دهند. چنین کاری به تیم کمک می‌کند تا از هشدار و آماده­باش­ اعضایش استفاده کند. مثلاً ممکن است یکی از اعضا بگوید: «امروز می‌خواهم روی رویه‌ی ذخیره­شده‌ی‌[8] پایگاه داده کار کنم و باید آن را تا ظهر تمام کنم. کسی که می‌خواهد روی منطق کسب‌وکار[9] کار کند باید آماده باشد تا بلافاصله بعد از ناهار کارش را شروع کند و حواسش باشد که پیاده‌سازی منطق کسب‌وکار برای تکمیل کارِ ما در این اسپرینت روی مسیر بحرانی[10] قرار دارد». چنین گفتگوهایی باعث می‌شود تا موانع احتمالی در اولین فرصت شناسایی شوند و رفع آنها منجر به بهبود اجرای اسپرینت گردند.

سخن پایانی

در این فصل نشان داده شد که برنامه‌ریزی در توسعه به روش اسکرام، چگونه در چندین سطح و هر یک با جزییات متفاوت انجام می‌شود. در شکل 15-7 فراورده‌های هر یک از این سطوح (به جز برنامه‌ریزی سبد محصول و برنامه‌ریزی روزانه) و نحوه‌ی ارتباط آنها با یکدیگر به تصویر کشیده شده است.

در فصل‌های بعد به طور عمیق‌تری به برنامه‌ریزی سبد محصول، برنامه‌ریزی محصول، برنامه‌ریزی انتشار و برنامه‌ریزی اسپرینت خواهیم پرداخت.

شکل 157: برنامه‌ریزی سلسلهمراتبی[11] در اسکرام

5-1

[1] Trade-off

[2] Visualize

[3] Just in time

[4] Just enough

[5] Task-level

[6] Detailed planning

[7] همان‌طور که گفته شد، برنامه‌ریزی در اسکرام در سطوح مختلفی از جزییات مانند استراتژی، سبد محصول، محصول، انتشار، اسپرینت و روزانه انجام می‌شود. هر سطح، جزییات موارد تعیین‌شده‌ در سطح قبلی را برنامه‌ریزی می‌کند. برنامه‌ریزی اسپرینت پس از برنامه‌ریزی انتشار انجام می‌شود که در آن جزییات روش انجام اقلام بک‌لاگ در یک اسپرینت را برنامه‌ریزی می‌شود. [مترجم]

[8] Stored procedure

[9] Business logic

[10] Critical path

مسیر بحرانی، مجموعه‌ای از فعالیت‌ها هستند که بلندترین مسیر در طول پروژه را تشکیل می‌دهند. جمع زمان فعالیت‌های موجود در مسیر بحرانی نشان‌گر حداقل مدت ممکن برای انجام پروژه است و هرگونه تغییری در آنها باعث افزایش مدت پروژه خواهد شد. [مترجم]

[11] Hierarchical

The Illusive Definition of Agile

  • یوسف مهرداد بی‌بالان

What is Agile? Is it a set of practices, a set of values, or a set of mind—or some combination of the three? Is it “Doing Agile” or “Being Agile?”

Is agile defined by a checklist of offered practices—the Nokia test for Scrum, or checking 9 of 12 practice boxes for XP?

Is agile a mindset, an amalgamation of adaptation, embracing change, transparency, collaboration, complex systems theory, or courage?

Is agile the frequent delivery of high quality customer value while effectively adapting to change, regardless of specific practices? (Ken Collier)

The right-brained and the left-brained are alive and well in this debate. Daniel Pink (A Whole New Mind) refers to this as L-directed thinking, “sequential, literal, functional, textual, and analytic,” versus R-directed thinking, “simultaneous, metaphorical, aesthetic, contextual, and synthetic.” This agile definition debate is a classic one that pits these two halves of ourselves against each other.

Is agile a management style, one that encourages self-organization, servant leadership, controlled chaos, or light-touch management?

Is agile a set of technical practices—iterative development, refactoring, coding standards, pair programming, or test-driven development?

Is agile a methodology or a set of core values and guiding principles?

There are many people and organizations who want a prescriptive, non-ambiguous definition of agile (or Scrum or XP or …). They are the L-directed thinkers, the ones who still want predictable plans and measures for the un-measurable. Conversely, there are those who insist that agile is a state of mind, a style of management, a wisp of content and a whisper of context.

And, there are those who are comfortable in-between—realizing that while at one level agile might be evaluated by a core set of practices, the essence of agile involves more philosophy than tutorial.

Is agile a set of rules established by some prescient guru, or an adaptive learning process that uses rules merely as a starting point?

Is agile a transcendent concept for bringing purpose, meaning, satisfaction, and fun to work?

The motto of the Scrum Alliance, “Transforming the World of Work,” speaks to agile’s wider purpose and meaning. In the final chapter of Adaptive Software Development I make two statements about work:

“People want to succeed; given the right environment, people motivate themselves to heroic achievements.

The right environment is one of adaptation through self-organization.”

In its search for purpose and meaning the core of agile has a secular spirituality feel to it. This core is why thousands upon thousands of individuals have signed the Agile Manifesto. It’s why hundreds of thousands around the world have embraced agile—even though they can’t quite define it.

Agile is one of those illusive things that the harder you try to grasp it, the more it slips through your fingers.

For me, the day we explicitly define agile, is the day it becomes sterile and lifeless.

For me, the day agile becomes whatever someone wants it to be, is the day it becomes useless.

For me, agile is a whole-minded philosophy, one that combines the left-brained and the right-brained—balancing on the precarious edge between the literal and the metaphysical, between performance and meaning. We need to revel in that balance and ambiguity, not try to define away its awe, grandeur, and paradox.

Jim Highsmith

برنامه‌ریزی چندسطحی در اسکرام – بخش دوم

  • یوسف مهرداد بی‌بالان

مترجم: یاسر کازرونی

بک‌لاگ کلان محصول

پس از تدوین چشم‌انداز محصول، نوبت به ایجاد نسخه‌ی اولیه‌ای از بک‌لاگ کلان محصول می‌رسد. در نمونه­ی قبلی یعنی طراحی مجدد وب‌سایت اتحادیه‌ی اسکرام، در پایان سال 2006 بک‌لاگی از محصول داشتیم که اقلام آن در حال افزایش بود؛ این اقلام شامل ویژگی‌های درخواستی ذینفعان و کاربران از نسخه‌ی جدید و بهبودیافته‌ی وب‌سایت می‌شد.

بک‌لاگ محصول شامل اپیک­‌های (داستان بلند) زیر بود:

  • به عنوان مربی رسمی اسکرام[1]، می‌خواهم برگزاری دوره‌های عمومی‌ام را در وب‌سایت اتحادیه‌ی اسکرام اعلام کنم تا اعضای اتحادیه از زمان و مکان برگزاری آن‌ها باخبر شوند.
  • به عنوان یک دانشجو می‌خواهم اطلاعات همه‌ی دوره‌های عمومی اسکرام را ببینم تا کلاسی را پیدا کنم که با شرایطم مطابقت داشته باشد.

اگر قرار بود محصول کاملاً جدیدی تولید کنیم، حداقل باید بخش کمینه­ای از نیازمندی­ها را در ابتدا شناسایی می­کردیم و در بک‌لاگ محصول قرار می‌دادیم و سپس بااولویت­ترین اقلام را برآورد می‌کردیم. اما در اینجا بخشی از اقلام بک‌لاگ محصول قبلاً وجود داشت که از آن به عنوان نقطه شروعی برای تدوین ایده‌های موجود در چشم‌انداز وب‌سایت جدید استفاده کردیم.

 

نقشه‌ی راه محصول

پس از تهیه­‌ی چشم‌انداز و بک‌لاگ کلان محصول، تهیه‌ی نقشه‌ی راه محصول که به آن نقشه‌ی راه انتشار[2] هم گفته می­‌شود می‌تواند مفید باشد. نقشه‌ی راه محصول بیان­گر ماهیتِ تدریجی ساخت و تحویل یک محصول در طی زمان و عوامل مهم و تأثیرگذار در هر یک از انتشارهای آن است.

امروزه بسیاری از سازمان‌ها تلاش می‌کنند تا به روش استقرار پیوسته[3] کار کنند؛ یعنی به‌محض آماده شدن ویژگی‌ها، آنها را در محیط عملیاتی مستقر می­کنند[4]. اگر سازمان شما نیز به همین روش کار می­کند، نیازی به تهیه‌ی نقشه‌ی راه محصول نیست. اما با وجود استفاده از «استقرار پیوسته»، نقشه­ی راه محصول می‌­تواند ابزار مناسبی برای کمک به سازمان در موارد زیر باشد:

  • بررسی و انتخاب مجموعه­‌ی بزرگ­تری از ویژگی­‌ها
  • شناسایی قیدها و محدودیت­‌هایی که منجر به توسعه­‌ی هم‌زمان برخی از ویژگی­‌ها می­‌شوند
  • تعیین زمان مناسب برای انتشار ویژگی­ها

شکل 15-2 نمونه‌­ای از نقشه‌ی راه محصول را در قالبی که لوک هومن[5] پیشنهاد کرده است نمایش می‌دهد [22].

این نقشه دو انتشار را نشان می‌­دهد؛ یکی در سه‌ماهه‌ی اول و دیگری در سه‌ماهه‌ی دوم سال 2007. انتشار «0.5» که در سه‌ماهه‌ی اول سال 2007 منتشر شد اولین انتشار از وب‌سایت جدید بود. دلیل انتخاب عدد 0.5 این بود که هرچند وب‌سایت جدید نسبت به وب‌سایت قدیمی امکانات بهتری داشت، ولی فقط نیمی از ویژگی­های[6] وب‌سایت قدیمی در برنامه‌ریزی این انتشار گنجانده شده بود. در مجموع ویژگی‌های مطلوب این انتشار مربوط به مشاهده‌ی دوره‌های عمومی اسکرام در دنیا و حداقلِ پشتیبانی از مربیان رسمی اسکرام یا CSTها بود. انتشار شماره‌ی 0.5، «انتشاری با محدوده‌ی ثابت»[7] بود زیرا می‌دانستیم وب­سایت جدید باید چه ویژگی‌هایی داشته باشد تا بتواند جایگزین وب‌سایت قدیمی شود و انتشار سایت بدون این مجموعه از ویژگی­ها امکان‌­پذیر نبود. آنچه نمی‌دانستیم این بود که پیاده‌­سازی این ویژگی‌ها چقدر طول می‌کشد. در فصل 18 به بررسی این موضوع خواهیم پرداخت که چگونه می‌توان تاریخ عرضه‌ی «انتشاری با محدوده‌ی ثابت» را تعیین کرد.

 

شکل 152: نقشهی راه وبسایت اتحادیه‌ی اسکرام

سه ماهه‌ی اول 2007 سه ماهه‌ی دوم 2007 سه ماهه‌ی سوم 2007
نقشه‌ی بازار[8] راه‌اندازی وب‌سایت جدید وکنار گذاشتن وب‌سایت قدیمی
نقشه‌ی ویژگی/مزیت[9] فهرست دوره‌هاپشتیبانی از مربیان رسمی اسکرام عضویتورود دسته‌ای داده­‌ها[10] جستجوپالایش (فیلتر)
نقشه‌ی معماری[11] [Ruby on Rails [12 یکپارچه‌سازی با سیستم ثبت نام آنلاین
رویدادهای بازار[13] گرد­همایی اسکرام کنفرانس چابک 2007
زمان‌بندی انتشار[14] 0.5 1.0

 

انتشار 1.0 از نوع «انتشار در تاریخ ثابت»[15] بود. زیرا می‌خواستیم تاریخ انتشار وب­سایت با تاریخ کنفرانس اتحادیه‌ی اسکرام در پورتلند اورگان[16] آمریکا که در تاریخ 7 می 2007 شروع می‌­شد همزمان شود. هدف ما این بود که در اولین روز کنفرانس، مجموعه‌ی جذابی از امکانات آماده باشد. اما نمی‌دانستیم که چه تعداد از ویژگی‌ها را می­‌توانیم برای این انتشار آماده کنیم. در فصل 18 روش تصمیم­‌گیری در مورد محتوای یک «انتشار در تاریخ ثابت» را بررسی می­کنیم.

خلاصه این­که در نقشه‌ی راه اولیه‌ی محصول، هم انتشاری با محدوده‌ی ثابت (0.5) و هم انتشاری در تاریخ ثابت (1.0) وجود داشت.

صرف نظر از این‌که چه محصولی می­‌خواهید تولید کنید، در پایان برنامه‌ریزی محصول باید فراورده‌های زیر وجود داشته باشد:

  • چشم‌انداز محصول
  • بک‌لاگ کلان محصول به‌همراه داستان‌های کاربر برآورده­‌شده
  • نقشه‌ی راه محصول (اختیاری)

البته ممکن است برای افزایش اطمینان خاطر تصمیم‌گیرندگان برای تأیید توسعه‌‌ی محصول، فراورده‌های دیگری نیز تهیه کنید.

خروجی‌­های برنامه‌ریزی محصول به عنوان ورودی‌ به برنامه‌ریزی سبد محصول برگشت داده شد تا انتشار نسخه‌ی 0.5 از وب‌سایت جدید مورد تأیید هیأت مدیره قرار گیرد.

[1] (Certified Scrum Trainer (CST

[2] Release roadmap

[3] Continuous deployment

[4] Deploy

[5] Luke Hohmann

[6] Feature

[7] Fixed-scope release

[8] Market map

[9] Feature/benefirt map

[10] Bulk loading

[11] Architecture map

[12] Ruby on Rails

روبی یک زبان برنامه‌نویسی انعطاف‌پذیر، پویا و شی‌گرا است. روبی ویژگی‌های نگارشی Perl و شی‌گرایی SmallTalk را در خود دارد. زبان روبی در سال‌های میانی دهه ۱۹۹۰ توسط یوکی هیرو ماتسوموتو در ژاپن اختراع شد. ویژگی‌های گوناگون زبان‌های Perl، Lisp، SmallTalk و Eiffel الهام‌بخش ماتسوموتو در ساخت روبی بودند. رِیلز چارچوبی کدباز و مبتنی بر وب است که به زبان روبی نوشته شده است. طراحی این چارچوب با هدف ساده‌سازی برنامه‌نویسی تحت وب انجام شده است با این فرض که هر برنامه‌نویسی بتواند به آسانی از آن استفاده کند. حجم کد مورد نیاز برای ایجاد یک ویژگیِ تحت وب در رِیلز نسبت به بسیاری از زبان‌ها و چارچوب‌های موجود کم‌تر است. [ویکی­پدیا] [مترجم]

[13] Market events

[14] Release schedule

[15] Fixed-date release

[16] Portland, Oregon

Does a Team Need to Finish Everything Every Sprint?

  • یوسف مهرداد بی‌بالان

When a team selects a set of product backlog items to work on in a sprint, the ScrumMaster and product owner should expect that the team will finish those items. Not always, but most of the time.

I coach teams that during sprint planning they are to commit to a set of product backlog items that they will deliver.

(Yes, I know the word commit has gone out of favor in the Scrum world over the past few years. But I think that’s a mistake and a misunderstanding of the word.)

When a team commits to a set of product backlog items, they are saying they will do their best to deliver those items within the sprint.

The team is not making a guarantee. They are committing to do their best to deliver what they said they would. That’s all.

I tell teams I’d like to see them fulfill that commitment about 80 to 90% of the time. That is, I want them to make it most of the time.

I never actually measure how often they deliver everything. I never track anything like number of product backlog items delivered divided by number of product backlog items committed to.

I really don’t want to know it that precisely. Tracking it at that level would introduce too much dysfunctionality into the team’s behavior.

If a team is told they must deliver everything every time, the team may respond by under committing during sprint planning. I would rather have a team that feels safe sometimes grabbing a little more than they may finish, knowing there are no repercussions if they don’t finish.

So, I want the team to finish all they say they will in most but not in all sprints. If a team finishes everything most of the time, the organization will have a great deal of predictability.

And that will help our organizations succeed with agile,

Mike Cohn

عقوبت مداخله

  • یوسف مهرداد بی‌بالان

پیش‌گفتار:

مقاله «عقوبت مداخله» به قلم استاد بزرگوار آقای دکتر «مرتضی ایمانی‌ راد» که در ادامه آورده شده است در هفته‌نامه‌ی «تجارت فردا» چاپ شده است. دکتر ایمانی راد در این مقاله نظام اقتصادی کشور و نقش دولت در آن را بررسی می‌کند.

به ظاهر مقاله‌ی ایشان هیچ ارتباطی با توسعه‌ی نرم‌افزار ندارد. اما پر از نکاتی است که ما بی‌کم و کاست در توسعه‌ی نرم‌افزار داریم. دوست داشتم درباره‌ی وجوه مشترک این مقاله با توسعه‌ی نرم‌افزار صحبت کنم ولی بهتر دیدم که ابتدا نظر خوانندگان را بشنویم و سپس در این باره چند خطی بنویسم.

منتظر دریافت نظرات شما خوانندگان گرامی هستم.

گفتار:

نظام اقتصادی یک کشور نه همانند، بلکه خود یک سیستم سازگار و پیچیده است که ویژگی‌های منحصربه‌فردی دارد. این سیستم زنده است و چون زنده است پویاست. جنس پویایی این سیستم‌ها، به دلیل زنده‌ بودن‌شان غیرخطی است و لذا مسیر حرکت‌شان با خط قابل تصویر و تبیین نیست و لذا هرگونه الگوی خطی برای تصویر این سیستم‌ها نتیجه‌اش ساده‌ کردن این سیستم‌ها و عدم توانایی در تبیین حرکت‌شان است. این سیستم‌ها یک ویژگی فوق‌العاده‌ دارند. این ویژگی به حرکت غیرخطی بودن آنها ارتباط دارد. وقتی یک سیستم حرکتش خطی است، به راحتی می‌توان ادامه حرکت آن را نقاشی کرد و بر همین اساس می‌توان آینده آن را پیش‌بینی و بنابراین آن را کنترل کرد.
این سیستم‌ها، که سیستم اقتصادی کشور هم این‌گونه است، پویایی‌شان در آزادی‌شان است و هرگونه کنترلی این سیستم‌ها را تخریب می‌کند. بنابراین جنس توسعه این سیستم‌ها خودجوشی و «پدیدارشدنی» است تا «طراحی کردنی» و بنابراین این سیستم‌ها به سختی برنامه‌پذیرند. بر همین اساس است که این سیستم‌ها را برای اینکه توسعه دهند، به جای برنامه از سیاست استفاده می‌کنند که هم عنصر اراده انسانی را به سیستم وارد کنند و هم مانع پویایی آنها شوند.
گذشته از این ویژگی، سیستم‌های پیچیده به دلیل پیش‌بینی‌ناپذیری‌شان نمی‌توانند «سیاست‌باران» شوند و همزمانی سیاست‌ها باید جای خود را به توالی سیاست‌ها بدهد. به این تعبیر که وقتی نتایج خوب یا بد، مورد انتظار یا غیرقابل‌انتظار یک سیاست مشخص شد یا به عبارتی ظاهر شد، اطلاعات کافی برای تدوین و اجرای سیاست بعدی فراهم می‌شود و به همین ترتیب اعمال سیاست‌ها ادامه خواهد داشت. بنابراین پیاده‌سازی مجموعه‌ای از سیاست‌ها (که معمولاً در قالب برنامه‌های توسعه اجرا می‌شود) منجر به بهبود بهینگی این سیستم‌ها نمی‌شود زیرا از قابلیت پدیدارشدگی آنها بهره کافی گرفته نمی‌شود. یعنی ابتدا باید سیاست به کار گرفته شود و از اطلاعات پدیدار شده استفاده شود و سیاست و سیاست‌های دیگر اعمال و اجرا شود. به همین ترتیب همانند چرخ‌دنده، اقتصاد، سیاست می‌گیرد و سپس تغییر می‌کند. این تغییر و شیوه این تغییر با توجه به ویژگی سیستم‌های پیچیده بهترین حالت برای این سیستم‌هاست. سیاستگذاران برای حرکت سریع‌تر رو به جلو این سیستم‌ها دست به دخالت می‌زنند و همین دخالت، بهینگی حرکت آنها را خراب می‌کند یا حرکت آنها را مانع می‌شود. این سیستم‌ها یکسری عوامل تغییر دارند و یک زمینه، که معمولاً این زمینه غیراقتصادی است، چون زمینه‌های اقتصادی درون سیاست‌هاست. موفقیت حرکت و پویایی این سیستم‌ها هم وابسته به عوامل است و هم زمینه‌ها.
گاهی عوامل فعال هستند و زمینه‌ها غایب و در نتیجه حرکت پویای سیستم عقیم می‌ماند. حرکت‌های کشورهای مختلف در بعد از جنگ دوم جهانی اساساً منسوب به زمینه‌های مهیای آن زمان است (از جمله تحولات بی‌نظیر ایران در دهه 40 شمسی) ولی متاسفانه این حرکت قدرتمند بعضی از کشورها به برنامه‌های توسعه آن منسوب می‌شود که در واقع اشتباه دیدن «همزمانی» به جای «علیت» است. این مساله موجب می‌شود سیاستمداران بعدی از برنامه‌های توسعه (که دو مساله مهم سیستم‌های اقتصادی را نادیده می‌گیرد) برای سرعت توسعه استفاده ‌کنند و چون سرعت را برعکس نیت‌شان کند می‌کنند، فکر می‌کنند علت را باید در مکانیسم برنامه ببینند تا خود برنامه.
نکته مهم‌تر اینکه در این سیستم‌ها قانون علیت به روشنی کار نمی‌کند. می‌توان از منبع تغییرات صحبت کرد، ولی گفت‌وگو درباره علت تغییرات چالش‌برانگیز است. وقتی علیت به روشنی مشخص باشد استراتژی‌های تهاجمی به کار گرفته می‌شود، چون علت و مسیر مشخص است و لذا اراده سیاستگذار عامل اساسی تغییر می‌شود که این سیستم‌ها بیشتر از اینکه بر اساس قواعد پویایی‌شناسی حرکت کنند و همراه با خود آزادی و دموکراسی را توسعه دهند، بیشتر منجر به اقتدار و دیکتاتوری و سیاستگذاری آمرانه می‌شوند. فقط لازم است سیاست در بیان تلطیف شود، وگرنه در محتوایش «آمرانه» است.
همه سیستم‌های زنده در این مقوله جای می‌گیرند. ولی سیستم‌های حیوانی به دلیل تکمیل‌شدگی مغز حیوانات مسیر مشخصی دارند و به دلیل عدم توسعه‌یافتگی مغزشان نه قدرت سازندگی جدید دارند و نه قدرت تخریب. به همین دلیل الگوی تحول هم ساده و هم تکرارشدنی است و لذا «پدیدارشدگی» در آنها محدود است. ولی در سیستم‌های انسانی هم به خاطر ناکامل بودن مغز انسان (چون در جریان بزرگ شدن کامل می‌شود) و هم به خاطر انعطاف‌پذیری بالای مغز انسان و شکل‌گیری نیاز به بقا، این پدیدارشدنی به شدت غنی و در عین حال غیرقابل پیش‌بینی است. مهم‌تر اینکه عوامل منحصربه‌فرد انسانی در این میان وارد می‌شوند و سیستم پویا را تخریب می‌کنند. در این میان شناسایی رمز و راز سیستم‌های سازگار و پیچیده بسیار مهم می‌شود. برای این رمزگشایی نیاز به باز بودن ذهن دارد و وقتی ذهن باز نباشد قدرت فهم پدیدارشدگی سیستم‌های پیچیده امکان‌ناپذیر می‌شود و لذا انسان به جای فهم سیستم، اراده خودش را می‌گذارد و دخالت جای خود را به واگذاری می‌دهد. حال هر چه ذهن بسته‌تر باشد تحکم بیشتر می‌شود و عدم فهم قابلیت‌های سیستم‌های سازگار و پیچیده بیشتر می‌شود.
چون ذهن محدود، ذهن قضاوت‌کننده است و این ذهن به جای دیدن واقعیت همیشه می‌خواهد واقعیت را در چارچوب ذهن خودش بگذارد و این اصل در ادبیات اقتصادی حاصلش دخالت است. بنابراین دخالت، که به عنوان سیاستی موقت ضرورت دارد، به یک استراتژی و پارادایم تبدیل می‌شود و حاصل آن سیاست‌های عقیم، برنامه‌های بی‌نتیجه و سازمان‌های مداخله‌گر است. جالب این است که به دلیل دخالت در یک پدیده پویا و آزاد انعطاف‌ناپذیری‌های ساختاری شکل می‌گیرد که این خود به عنوان مانع برای رشد سیستم عمل می‌کند و چون پارادایم دخالت حضور مستمر دارد، دست به ایجاد یک سازمان جدید برای رفع این انعطاف‌ناپذیری‌ها می‌زند که این خود مانع جدیدی می‌شود. نهایت همه این روندها مداخله مستمر و تخریب پویایی‌های سیستم زنده است که در مجموع باعث پایین آمدن شدید کارایی در سیستم می‌شود.
نتیجه بحث‌های بالا این است که همیشه یک نظام اقتصادی برآیند پویایی‌های درون خود به اضافه ملحقات ناشی از مداخلات اراده‌گرایانه است. محور این پویایی‌ها بدون تردید بخش خصوصی است که موتور محرکه بسیار قدرتمندی برای حرکت رو به جلو اقتصاد است و از طرف دیگر قدرت‌گیری ستاد این بخش است که همان اتاق‌های بازرگانی و صنعت و معدن است. بدون رسمیت این بخش و ستادش، حل رشد اقتصادی توام با تردیدهای جدی است. از طرف دیگر ملحقات این سیستم‌ها تلاش دولت‌ها برای رشد اقتصادی است که عمدتاً به یک مانع جدی تبدیل شده است و هر دولتی همّ خود را بر رفع این موانع می‌گذارد، ولی متاسفانه سیاست‌های پیشنهادی، چون ماهیت سیستم را نمی‌فهمد خودش به یک مانع جدید تبدیل می‌شود. متاسفانه وقتی این موانع نهادینه می‌شود، در رفتار بازیگران اقتصادی قالب‌گیری می‌شود و رفع آن را در آینده با مشکل مواجه می‌کند.
بنابراین برای توسعه ما یک موتور نیاز داریم (بخش خصوصی و ستادهای مرتبط با بخش خصوصی) که همان مدیران بخش خصوصی‌اند (یا بنگاه‌های دولتی که تماماً با مکانیسم بازار آزاد اداره می‌شوند و از رانت هم محرومند) و یک تسهیل‌گر که حکومت و به طور مشخص دولت است که وظیفه اصلی‌اش در یک کلام بهبود فضای کسب و کار و در قلب آن شفافیت اطلاعاتی در کشور است. ولی وقتی اراده دولت در توسعه و پیشرفت اقتصادی جای موتور محرکه توسعه را می‌گیرد، سیستم قفل می‌کند. باز کردن قفل این سیستم به طور جدی در دوره‌های بعد با محدودیت مواجه است. اگر اندکی به گیرهای موجود در اقتصاد نگاه کنیم، اثر اراده‌گرایی دولت برای ساماندهی و رشد اقتصادی را به صورت موانع رشد می‌بینیم و به این ترتیب گشایشی در اقتصاد پدید نمی‌آید.
گزیده:
ندارد.

برنامه‌ریزی چندسطحی در اسکرام

  • یوسف مهرداد بی‌بالان

مترجم: یاسر کازرونی

برنامه‌ریزی چندسطحی در اسکرام

برنامه‌ریزی در توسعه‌ی محصول با اسکرام در چندین سطح انجام می‌شود.

بالاترین سطح آن، برنامه‌ریزی استراتژیک است. با اینکه برنامه‌ریزی استراتژیک برای موفقیت سازمان امری حیاتی است، اما بررسی آن خارج از موضوع ما است. اسکرام به طور رسمی فقط دارای برنامه‌ریزی اسپرینت و برنامه‌ریزی روزانه (به کمک اسکرام روزانه) است. اما برنامه‌ریزی سبد محصول، برنامه‌ریزی محصول و برنامه‌ریزی انتشار برای اکثر سازمان­ها سودمند است.

 

برنامه ریزی چند سطحی

جدول 1 پنج نوع مختلف برنامه‌ریزی را نشان می‌دهد. این جدول، افق برنامه‌ریزی[1]، افراد شرکت‌کننده، نقطه­ی تمرکز[2] و تحویل­‌دادنی‌­های (اقلام قابل تحویل)[3] هر سطح را نمایش می‌دهد.

برای تشریح روش برنامه‌ریزی در هر یک از این سطوح، از مثال طراحی مجدد وب‌سایت اتحادیه‌ی اسکرام[4] استفاده می‌کنم. سابقه‌ی این محصول به سال 2006 برمی‌گردد؛ در آن سال، اتحادیه‌ی اسکرام به عنوان سازمانی غیرانتفاعی فعالیت­هایش را روی ترویج اسکرام در کل دنیا متمرکز کرده بود و این در حالی بود که وب‌سایت مناسبی نداشت. وب‌سایت اتحادیه زیبا نبود، پیمایش[5] آن دشوار و محتوای[6] آن نیز بسیار ضعیف بود. در پایان سال 2006 وقتی که مدیرعامل اتحادیه‌ی اسکرام شدم، یکی از اولین خواسته‌های هیأت مدیره، راه‌اندازی وب‌سایتی جدید و به‌­مراتب بهتر از وب‌سایت موجود بود. من در این کار، نقش مالک محصول را داشتم و در ادامه توضیح خواهم داد که چه سطوحی از برنامه‌ریزی را برای دست‌یابی به این هدف به کار گرفتیم.

جدول 1: جزییات سطوح برنامه‌ریزی

سطح برنامه

افق برنامه‌ریزی شرکتکنندگان نقطه­‌ی تمرکز تحویل‌­دادنی‌ها
برنامه‌ریزی سبد محصول یک سال یا بیش‌تر ذینفعان، مالکان محصول مدیریت سبد محصول بک‌لاگ سبد محصول و محصولات جاری[7]
برنامه‌ریزی محصول(ترسیم چشم‌انداز) چندین ماه مالک محصول، ذینفعان چشم‌انداز و مسیر تکامل محصول چشم‌انداز محصول، نقشهی راه و ویژگی‌های کلان محصول
برنامه‌ریزی انتشار بین سه ماه (یا کم‌تر) تا نه ماه همهی اعضای تیم اسکرام، ذینفعان حفظ توازن بین ارزشهای قابل ارائه به مشتری[8] و کیفیت از يک طرف و قیدهای محدوده، زمان و بودجه از طرف دیگر طرح انتشار
برنامه‌ریزی اسپرینت در هر تکرار (بین یک هفته تا یک ماه تقویمی) همهی اعضای تیم اسکرام ویژگی‌هایی که باید در اسپرینت جاری تحویل داده شوند هدف اسپرینت و بک‌لاگ اسپرینت
برنامه‌ریزی روزانه هر روز استاد اسکرام و تیم توسعه روش تکمیل ویژگیهای تعهدشده بررسی پیشرفت کار و تطبیق با بهترین شیوه­ی سازماندهیِ کارهای روزانه

برنامه‌ریزی سبد محصول

برنامه‌ریزی سبد محصول یا مدیریت سبد محصول، فعالیتی است که طی آن تعیین می‌کنیم روی چه محصولاتی، با چه ترتیبی و چه مدت باید کار کنیم. با اینکه برنامه‌ریزی سبد محصول از نظر مفهومی، کلان‌تر از برنامه‌ریزی محصول است (زیرا برخلاف برنامه‌ریزی محصول که فقط مربوط به یک محصول است، با مجموعه‌ای از محصولات سروکار دارد)، اما یکی از ورودی‌های اصلی آن، ایده­ی محصولی است که چشم­انداز آن به‌تازگی در برنامه‌ریزی محصول تدوین شده است.

در سال 2006 اتحادیه‌ی اسکرام سازمان نسبتاً نوپایی بود و سبد محصولاتش فقط مرتبط با توسعه‌ی مداوم وب‌سایت موجود بود. پس از اینکه چشم‌انداز اولیه‌ی وب‌سایت جدید آماده شد، هیأت مدیره (ذینفعان بک‌لاگِ سبد محصول در اتحادیه‌ی اسکرام) توسعه‌ی اولین انتشار آن را تأیید کرد.

برنامه‌ریزی محصول (ترسیم چشم‌انداز)

هدف از برنامه‌ریزی در سطح محصول که «ترسیم چشمانداز» نیز نامیده می‌شود، فهمیدن ماهیت و جوهره­ی[9] محصولِ بالقوه‌ و تهیه‌­ی برنامه‌ای کلی برای ساخت آن است. این کار با تدوین چشم‌انداز آغاز می‌شود و با تهیه‌ی بک‌لاگ کلانی از محصول[10] و در اغلب موارد، نقشه‌ی راه محصول[11] ادامه پیدا می‌کند.

چشم‌انداز[12]

چشم‌انداز محصول، توصیف شفافی از حوزه‌هایی است که برای ذینفعان مانند مشتریان و کاربران باارزش است. در مثال ما کاربران وب‌سایت، اعضای اتحادیه‌ی اسکرام در سراسر جهان بودند که تعداد آن‌ها در آن زمان به 10،000 نفر می‌رسید (در پایان سال 2011 این تعداد به 150،000 نفر رسید). مشتری وب‌سایت، هیأت مدیره‌ی اتحادیه‌ی اسکرام بود که به نمایندگی از طرف اعضا، هزینه‌‌ی محصول جدید را پرداخت می‌کرد.

این وب‌سایت باید به منبع قابل اعتمادی درباره­‌ی اسکرام برای علاقه‌مندان در سراسر دنیا تبدیل می‌­شد. همچنین باید محتوایی غنی و امکاناتی ارزشمند می­‌داشت و نخستین مرجع در اینترنت برای یادگیری اسکرام یا مشارکت در موضوعات مرتبط با آن می‌­شد.

چشم‌انداز ما برای وب‌سایت جدید اتحادیه‌ی اسکرام به شرح زیر بود:

«این وب‌سایت باید به منبع قابل اعتمادی درباره­‌ی اسکرام برای علاقه‌مندان در سراسر دنیا تبدیل شود. همچنین باید محتوایی غنی و امکاناتی ارزشمند داشته باشد و نخستین مرجع در اینترنت برای یادگیری اسکرام یا مشارکت در موضوعات مرتبط با آن باشد.»

——————————————————————————————————————

[1] Time horizon

به‌ندرت پیش می‌آید که بخواهیم یا حتی بتوانیم پروژه‌ای را در ابتدا به‌طور کامل برنامه‌ریزی کنیم. در یک پروژه، هر بازه‌ی زمانی‌ که بتوان آن را به‌دقت برنامه‌ریزی کرد، افق برنامه‌ریزی یا افق زمانی می‌گویند. [مترجم]

[2] Focus

[3] Deliverable

«قلم قابل تحويل» هر گونه خروجي يا نتيجه‌ی قابل مميزي، ملموس و قابل سنجش است كه توليد آن براي تكميل يك پروژه يا بخشي از آن ضروری است. معمولاً اين اصطلاح در مفهومی خاص‌تر براي اشاره به اقلام قابل تحويل خارجي به کار می‌رود؛ قلم قابل تحويل خارجي، قلمي است كه نيازمند تأیید حامي پروژه يا مشتري است. [راهنمای PMBOK 2000] [مترجم]

[4] Scrum Alliance (www.scrumalliance.org)

[5] Navigate

[6] Content

[7] In-process Products

محصولات جاری، محصولاتی هستند که در حال حاضر، سازمان در حال توسعه یا فروش آنها است. [مترجم]

[8] Customer value

ارزش مشتری یا ارزش قابل ارائه به مشتری عبارت است از تفاوت بین آنچه مشتری از محصول به‌دست می‌آورد و آنچه باید در ازای دریافت محصول بپردازد. [مترجم]

[9] Essence

[10] High-level product backlog

[11] Product roadmap

[12] Vision

برای خروج از جستجو کلید ESC را بفشارید