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

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

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

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

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

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

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

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

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

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

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

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

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

انتشار 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

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

پیش‌گفتار:

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

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

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

گفتار:

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

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

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

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

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

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

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

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

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

در سال 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

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

خاطره:
پایان سال بود و قرار بود در مورد ادامه‌ی همکاری با شرکت گفتگو کنیم. مدیرم، خانم مهندس جوانی بود. مذاکرات را باید با قائم‌مقام شرکت انجام می‌دادیم.
یکی دو جلسه‌ای به همراه خانم مدیر در دفتر قائم‌مقام حاضر شدیم. بعد که نتیجه‌ی مذاکرات را خانم مدیر جویا شدم گفتند باشد بعد از عید صحبت خواهیم کرد.
طبق معمول، همگی به تعطیلات رفتیم و برگشتیم.
یکی دو روز که از شروع کار گذشت، یک روز خانم مدیر مرا صدا کرد و گفت:
متاسفانه نتوانستم با قائم‌مقام شرکت در مورد مبلغ حقوق پرداختی به شما و در نتیجه، ادامه همکاری به توافق برسم. شرکت قوانین و محدودیتهای خاص خودش دارد و مبلغ پرداختی به شما برای مدیران ارشد که تخصص آنها نرم‌افزار نیست، توجیه‌پذیر نیست.
طبق روال شرکت من باید پایان سال گذشته این موضوع را به شما اطلاع می‌دادم، اما به دلیل در پیش بودن سال نو نخواستم گفتن این موضوع، شیرینی و شادی تعطیلات سال نو را از شما و خانواده‌تان بگیرد.
در نتیجه با قائم‌مقام شرکت توافق کردم که بعد از تعطیلات، این موضوع را به شما اطلاع بدهم. شما تا زمانی که کار جدیدی پیدا نکرده‌اید می‌توانید در شرکت حضور داشته باشید.

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

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

آخرین سخن:
برای این خانم مدیر بزرگ‌وار و بزرگ‌منش، آرزوی تندرستی و بهروزی دارم.

پیش‌گفتار:

متن زیر بخشهایی از گفتگوی اعضای گروه تلگرامی «متدهای چابک» (Agile Methods) است.

گفتگو:

دو سوال کلیدی وجود دارد که هریک از ما به عنوان مدیر یا سرپرست یک تیم با آن مواجه هستیم.
آیا می توان معیارهای “شخصیت” و “استعداد” را به عنوان دو معیار اصلی برای حضور یک فرد در یک تیم دانست؟
افرادی که از “بعد شخصیتی” مردود شوند، آیا باید برای آنها شانسی در نظر گرفت؟ حتی اگر درون تیم استعدادشان را نشان دهند؟
————–

نفر اول:
دیروز خبری در رسانه های ورزشی منتشر شده بود که با پرسش شما مرتبط بود. بد نیست آن را بخوانید.
درخشش مهدی رحمتی در دیدارهای اخیر استقلال باعث شده تا رسانه ها و هواداران استقلال خواهان حضور شماره یک این تیم در تیم ملی شوند.
کارلوس کی روش، سرمربی تیم ملی درباره شانس مجدد رحمتی برای حضور در جمع شاگردانش گفت: معیار انتخابهای من همیشه بنا بر دو مطلب اصلی بوده است:
1- شخصیت
2- استعداد

افرادی که از بعد شخصیتی مردود شوند هیچ شانسی با من ندارند، حتی اگر درون زمین استعدادشان را نشان دهند.
—————

نفر دوم:

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

—————

نفر سوم:

مسئله مهم این است که آیا این مسئله در تیم ها، سازمان ها، ادارات و در مقیاس بزرگتر در کشور پذیرفته می شود؟
آیا عدم همکاری با افرادی که با استعدادند ولی شخصیت لازم جهت پیشبرد اهداف تیم ها(در هر سطح) را ندارند در فرهنگ ما پذیرفته است (در طول یک پروژه)؟

—————-

نفر چهارم:

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

ما توی شرکتمون معیارهای نسبتاً سختگیرانه‌ای برای جذب افراد داریم که حول این موارد تعریف میشن: استعداد، انجام‌دهنده‌ی کار (چون ممکنه فردی بااستعداد در اجرای کارها تنبل یا وسواسی باشه)، روحیه کار تیمی، مسئولیت‌پذیری، اخلاق، و دانش
(در صورت برآورده‌سازی معیارهای دیگه، ‘دانش’ رو میشه در حین کار هم به دست آورد و در نتیجه وزن کمتری داره. اما انتظار میره فرد از حداقل‌هایی از دانش برخوردار باشه.)

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

گزیده:

ندارد.

What is waste?
Waste is, in fact, the opposite of value (a capability delivered to the customer through which the customer attains a tangible or intangible benefit).
So whatever feature or functionality or process step that neither adds value nor is used will be considered waste and should be eliminated from the system/product/process.

The seven wastes listed below were identified in manufacturing in the Toyota Production System (TPS) by Shigeo Shingo:
1) Inventory: Unfinished goods (also called as “work in progress,” or WIP)
2) Overproduction: Producing more than the demand requires
3) Extra processing: Additional steps in the process that aren’t really needed
4) Transportation: Shipping the goods from one place to the other
5) Waiting: Lag between process steps
6) Motion: Moving around within the process
7) Defects: Flaws in the deliverables that impact their features/functionality

Reference: scrumalliance.org

گزیده:
ندارد