به احترام هدف، گلدرات و نقشینه (بخش اول)

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

بخش اول: حامد، گلدرات و نقشینه

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

یکی از آموخته‌های بسیار مهم‌ام در زمینه‌ی «لذت توسعه‌ی نرم‌افزار» از روزی شروع شد که با حامد در مورد موضوعی صحبت می‌کردیم و او به ناگاه گفت «با تئوری محدودیت‌ها آشنا هستی؟» و من پاسخ دادم «خیر». گفت کتابی دارم که برایت می‌آورم تا بخوانی.

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

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

بیراه نگفته‌ام اگر ادعا کنم که یکی از کتاب‌هایی که تفکرم را نسبت به نرم‌افزار تغییر داد و مسیر زندگی و کاری‌ام را بازطراحی کرد، کتاب «گلدرات» بود.

از آن کتاب نکات زیادی یاد گرفتم «درایور زندگی و کسب‌وکار چیست؟»، «گلوگاه چیست و به چه کار می‌آید؟»، ….

ELI_GOLDRATT

بخش دوم: دکتر حاجعلی، صنعت خودرو، گلدرات و تئوری محدودیت‌ها

ماجرا به همین جا ختم نشد.

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

در دوره‌هایی که برای شرکت‌ها برگزار می‌کنم، معمولاً پروژه‌ای از شرکت انتخاب می‌شود و در طول دوره انجام می‌شود. پروژه‌ی پیشنهادی چه بود؟ بله! پروژه‌ای مرتبط با کتاب «هدف» و «تئوری محدودیت‌ها».

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

گزیده:

مشکلات شما از آنجا ناشی می‌شود که شما نمی‌دانید هدفتان چیست. گلدرات

لذت نوشتن (بخش سوم)

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

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

مقدمه‌ی مترجم (3)

افرادی که تجربه‌ی استفاده از اسکرام دارند می‌دانند که وقتی وارد اسپرینت می‌شویم، پرسش‌های متعددی مطرح می‌شود:

-چگونه اقلام را به وظیفه‌ها بشکنیم؟،

-کارها چگونه به افراد محول شود که حداکثر کارایی را داشته باشد؟،

-جلسه‌ی بازنگری را چگونه و با حضور چه کسانی برگزار کنیم؟،

-چگونه مالک محصول، تکمیل شدن اقلام را تأیید کند؟.

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

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

نبود تمرکز در تیم‌ها و ایجاد اختلال در کار آنها به دلیل مدیریت نشدن ورودی‌ها و به‌ویژه ورود کارهای موردی و لحظه‌ای، مشکل بعدی تیم‌هاست. جمله‌ای که بارها در این تیم‌ها شنیده‌ام این است که: «هر روز اولویت‌ها جابه‌جا می‌شوند؛ هنوز یک کار تمام نشده، باید آن را نیمه‌کاره رها کنیم و کار بعدی را شروع کنیم؛ ما کاملاً خسته و بی‌انگیزه شده‌ایم».

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

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

گزیده:

هنر یک رهبر، توانایی «نه گفتن» است و نه «بله گفتن». زیرا «بله گفتن» کار آسانی است. تونی بلر

لذت نوشتن (بخش دوم)

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

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

مقدمه‌ی مترجم (2)

تجربه­ نشان می­دهد که استفاده از فناوری و دانش­ نوین اگر با آموزش و استفاده از مراجع معتبر همراه نباشد، به بیراهه خواهد رفت. تجربه­هایی چون شیءگرایی، UML و RUP در گذشته و متدهای Agile در چند سال اخیر، گواه این مطلب است و متأسفانه نمونه­های زیادی از این موارد وجود دارد. مدیرعامل یکی از شرکت­های بزرگ نرم­افزاری می‌گفت: «از تیمی خواستم تا برای پروژه­اش برنامه­ی بلندمدت­تری ارائه کند، مدیر تیم گفت: چون متدولوژی ما اسکرام است برنامه­ریزی بلندمدت نداریم! فقط کارهای یک ماه آینده [اسپرینت جاری] را برنامه­ریزی می­کنیم!». با چهره­ای متعجب از من پرسید: «آیا متدهای چابک واقعاً این گونه­اند؟!». پاسخ واضح است: خیر!

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

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

به جرأت می‌توان گفت شرکت‌هایی که برنامه‌ریزی را جدی می‌گیرند و دانش و مهارت انجام آن را دارند، انگشت‌شمارند. در حالی که در متدهای چابک نمی‌توان از برنامه‌ریزی به سادگی گذشت. همان‌طور که در جلد اول نیز گفته شد متدهای چابک بر دو نکته‌ی کلیدی تأکید می‌کنند: پیش‌بینی در ابتدای کار (Up-front Anticipation) و تطبیق به‌موقع (Just in time Adaptation) در میانه‌ی راه. اما اکثر شرکت‌ها و تیم‌های ما فقط «تطبیق» را انجام می‌دهند و آن هم نه تطبیق به‌موقع بلکه تطبیق موردی (Ad-hoc). در نتیجه فرهنگ مدیریتی کوتاه‌مدت و حتی مدیریت لحظه‌ای (موردی) و نداشتن برنامه‌ی میان‌مدت و بلندمدت، چالشی بسیار بزرگ و سدی محکم برای استفاده‌ی درست از متدهای چابک در کشورمان است. این کتاب، مرجع بسیار مفیدی برای برنامه‌ریزی میان‌مدت و بلندمدت در شرکت‌های نرم‌افزاری است.

تیم‌های توسعه‌ی نرم‌افزار معمولاً به نداشتن برنامه مشهورند! حکایت روابط نامناسب واحدهای PMO با تیم‌های توسعه، مثنوی هفتاد من است. واحدهای PMO با حمایت مدیران ارشد، تیم‌های توسعه را وادار می‌کنند تا برنامه‌های خود را در قالب‌های مرسوم مانند نمودار گانت‌ تهیه کنند و میزان پیشرفت کار را بر اساس آن گزارش کنند. مشاجرات، اتهام‌زنی و فرافکنی‌ها بخش ناخوشایندی از این مثنوی است. در یکی از شرکت‌ها، مدیرعامل از مدیرانش خواسته بود تا برنامه‌های خود را به واحد برنامه‌ریزی ارائه دهند. طبیعی بود که واحد توسعه‌ی محصول از همه‌ی واحدها عقب‌تر باشد! برای جبران این عقب‌ماندگی، ابتدا آموزش‌هایی بر اساس این کتاب به اعضای تیم داده شد و از آنها خواسته شد بر اساس رویکردهای برنامه‌ریزی انتشار (تاریخ‌ثابت و محدوده‌ثابت)، کارها را برنامه‌ریزی کنند و به واحد برنامه‌ریزی ارائه نمایند. بعد از مدتی که از اجرای برنامه‌ریزی انتشار گذشت، واحد توسعه‌ی محصول، بانظم‌ترین و دقیق‌ترین واحد در همکاری با واحد برنامه‌ریزی شد.

گزیده:

برای موفق شدن،
اشتیاق به پیروزی باید بیشتر از ترس از شکست باشد.

بیل کازبی

لذت نوشتن (بخش اول)

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

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

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

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

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

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

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

گزیده:

ندارد

یادگیری کانبان (8)

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

مترجمها: یاسر کازرونی، مریم معصومی‌راد

دافنه به سمت تابلو رفت و گفت: «ولی ما ستونی به نام «در انتظار عمليات» با تعدادی برگه داریم و تنها مانع انجام اون‌ها هم بچه‌های عملیات هستن. فکر نمی‌­کنید حداقل می­تونیم با اون‌ها در این رابطه مذاکره کنیم؟»

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

1003

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

سزار هم تأیید کرد: «آره، حداقل ارزش یک بار امتحان کردن رو داره.»

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

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

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

سزار با این­که از پیشرفتی که تا حالا داشتند خیلی خوشحال بود، اما زیر لب گفت: «مطمئنم که می‌­دونند. خب، بعد از اون چه اتفاقی می‌­افته؟ منظورم بعد از مرحله‌ی «در انتظار عملیاته»»

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

یوآخیم پرسید: «اگر این‌طوریه که شما می‌گید باشه، یعنی این که فرایند شما اینجا تموم می‌شه. پس آخرین ستون را هم اضافه می‌کنیم و اسم ستون رو هم «انجام شده» (Done) می‌ذاریم. پیشنهاد دیگه‌ای دارید؟»

دافنه پرسید: «چرا باید یک ستون به نام «انجام شده» داشته باشیم؟»

اریک گفت: «چرا نداشته باشیم؟ ما می‌خوایم نشون بدیم که خیلی باحالیم، درسته؟»

مارکوس با اریک موافق بود: «آره، حتماً». کمی مکث کرد و گفت: «این کار، روش خوبیه برای این‌که کارهای تموم شده رو روی تابلو جمع کنیم.»

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

بقیه‌ی اعضای تیم هم با ایده‌ی آدام موافقت کردند ولی در آن لحظه، هیچ برگه‌ای برای قرار گرفتن در آن وجود نداشت.

1004

یوآخیم رو به فلیپ­چارت و فهرست چالش­‌ها کرد و پرسید: «به تابلو نگاه کنید، آیا این ستون‌ها تقریباً همان گردش کاریه که کارهاتون رو مرحله به مرحله بر اساس اون انجام می‌دید؟ الآن می‌تونید وضعیت کارها رو دقیق‌تر ببینید یا زمانی‌که در سیستم الکترونیکی حبس شده بود؟»

یوآخیم به برگه‌ای روی فلیپ‌چارت اشاره کرد و گفت: «اولویت­‌بندی چه­‌طور؟ اون هم یکی از چالش­‌های شما بود. الان که کارها به ترتیب اولویت در هر ستون مرتب شده­، دیدن اولویت­‌ها برای شما راحت‌تر نیست؟»

 

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

اعضای تیم برای چند لحظه به تابلو نگاه کردند. فرانک گفت که به نظرش ساده­‌تر شده است ولی تا زمانی­‌که در عمل از آن استفاده نکنند، نمی‌­توانند در موردش مطمئن شوند.

مارکوس گفت: «تا همین­‌جا کافیه. فقط دو نکته: اول اینکه این، پایان کار نیست. این بهترین چیزیه که تا الان بهش رسیدیم. این تابلو و چیزهایی که درباره‌‌شون بحث کردیم، احتمالاً بعداً تغییر می‌کنند. همین­طور که پیش می‌­ریم، باید اون‌ها رو بهبود بدیم.» برای چند ثانیه ساکت شد و سعی کرد جلوی خودش را بگیرد تا درباره‌ی مزایای بازرسی (Inspect)، تطبیق (Adapt) و بهبود مستمر با حرارت صحبت نکند.

«بیایید دوباره در مورد انواع کارهایی که شما به آنها اشاره کردید صحبت کنیم. اجازه بدید ساده‌تر بگویم: چه چیزی روی تابلو و بین ستون‌ها حرکت می‌کنه؟»

 

گردش کار را روی تابلو نگاشت کنید

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

بخش بعدی

بخش قبلی

آیا تیم شما باید هر روز اسکرام روزانه داشته باشد؟

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

پیش‌گفتار

متن زیر ترجمه‌ای است از یکی از نوشته‌های آقای مایک کوهن درباره‌ی اسکرام روزانه. امیدوارم برای شما خوانندگان گرامی مفید باشد.

آیا تیم شما باید هر روز اسکرام روزانه داشته باشد؟

در سال 1975، فرد بروکس (Fred Brooks) مدیر پروژه‌ی IBM OS/360 بود. این پروژه جزء اولین پروژه‌های نرم‌افزاری بود که تأخیرش شهره‌ی خاص و عام شد. در واقع، پروژه یک سال تأخیر داشت. … از بروکس پرسیده بودند که «چه طور یک پروژه می‌تواند یک سال تأخیر داشته باشد؟». بروکس در پاسخ، جمله‌ی بسیار معروف خود را گفت: «یک روز، یک روز» (one day at a time یا هر بار، یک روز).

اعتقاد دارم که اسکرام روزانه به ما کمک می‌کند تا پروژه‌های ما دچار چنین سرنوشتی نشوند. با برگزاری جلسه‌ی روزانه، مشکلات زودتر از هر روش شناخته‌شده‌ی دیگری مطرح می‌شوند. این کار باعث می‌شود که اشتباه «هر بار، یک روز تأخیر» را مرتکب نشویم که باعث شد پروژه‌ی بروکس یک سال تأخیر داشته باشد.

بگذریم!

آیا اسکرام روزانه باید هر روز برگزار شود؟

بله! اکثر تیم‌ها باید هر روز این جلسه را برگزار کنند.

در کل اعتقاد دارم که اسکرام روزانه باید دو هدف را دنبال کند.

مسلماً این که «اعضای تیم در هر صورت زیاد با هم صحبت می‌کنند»، هیچ یک از این اهداف را محقق نمی‌کند. این استدلال را بارها شنیده‌ام. این که اعضای تیم کل روز را کنار هم می‌نشینند و زیاد با هم صحبت می‌کنند، دلیل قانع‌کننده‌ای برای برگزار نشدن اسکرام روزانه نیست.

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

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

اما چه زمانی برگزاری اسکرام روزانه در یک تیم ضرورت ندارد؟

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

ب) روزهایی که برنامه‌ریزی اسپرینت برگزار می‌شود، بسیاری از تیم‌ها برگزاری اسکرام روزانه را بی‌فایده می‌دانند. معمولاً برنامه‌ریزی اسپرینت با بحث‌هایی تمام می‌شود که همان بحث‌های اسکرام روزانه است….

اسکرام روزانه بسیار مهم است و هنگامی که به خوبی برگزار شود می‌تواند بی‌نهایت به تیم کمک کند. اما شرایطی وجود دارد که برگزار نشدن اسکرام روزانه می‌تواند به تیم شما در کسب موفقیت با چابکی کمک کند.

گزیده:

daily scrum

تابلوی کانبان و واکنش مدیران

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

به نقل از مایک بوروس:

اگر تابلوی کانبان نشان ‌دهد که شرایط مطابق انتظار شما نیست، چه واکنشی نسبت به آن خواهید داشت؟ برخی از واکنش‌های متداول مدیران یا مربیان به شرح زیر است:

  1. اهمیت ندهید، مثل همیشه خودش درست می‌شود.
  2. تا زمانی که این شرایط تغییر نکند باید دخالت کنم و کارها را دقیق‌تر مدیریت کنم.
  3. باید دخالت کنم و سیستم را تغییر بدهم .
  4. آیا آنها می‌دانند که چه‌طور کار به اینجا رسیده؟ آیا می‌خواهند تغییراتی در سیستم ایجاد کنند؟ چگونه می‌توانم به آنها کمک کنم؟
  5. به توانمندی آنها برای ایجاد تغییرات مناسب برای چنین شرایطی باور دارم.

 

همه‌ی این واکنش‌ها درست است اما به نظر می‌رسد برخی از آنها پخته‌تر از بقیه هستند. کانبان با تشویق به اقدام و پشتیبانی از تصمیم‌گیری درست، افراد را به سمت واکنش‌های پخته‌تر مانند 4 و 5 هدایت می‌کند. سازمان‌هایی که آگاهانه از این‌گونه موضوعات و شیوه‌هایی از رهبری که مشوق این‌گونه موضوعات‌اند استقبال می‌کنند، در مسیر بلوغ پیش می‌روند.

واکنش‌ 5 (و کمی کم‌تر، واکنش 4) شامل عنصر جذاب دیگری به نام خودسازماندهی است. خودسازماندهی پدیده‌ی زیبایی است و فقط به این معنا نیست که افراد برای کارهای خود دارای استقلال هستند، هرچند این امر برای موفقیت آنها ضروری است. معنای دیگر خودسازماندهی این است که سیستم برای روبه‌رو شدن اثربخش‌تر با چالش‌های خود می‌تواند خود را بازپیکربندی کند. خودسازماندهی با این تعریف درست و کامل خود، موجب تطبیق‌پذیری و انعطاف‌پذیری می‌شود و چون بدون مداخله‌ی بیرونی رخ می‌دهد، به‌خوبی مقیاس‌پذیر است. خودسازماندهی هم برای عملیات سیستم و هم برای تغییر سیستم، موضوعی اثربخش و انسانی است.

گزیده:
شما چه واکنشی به تابلوی کانبان خواهید داشت؟

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