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

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

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

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

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

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

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

گزیده:

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

بیل کازبی

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

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

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

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

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

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

گزیده:

ندارد

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

بخش بعدی

بخش قبلی

پیش‌گفتار

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

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

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

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

بگذریم!

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

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

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

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

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

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

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

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

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

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

گزیده:

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

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

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

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

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

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

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

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

مارکوس پرسید: «کار روی هر قلم را چه‌­طوری شروع می‌­کنید؟ اولین کاری که باید انجام بدید چیه؟» فرانک گفت: «معمولاً با یک جلسه طراحی شروع می‌­کنیم. که چه‌­طوری کار رو پیاده‌سازی کنیم؟ برای چه کاری می­‌تونیم از سکوی نرم‌­افزاری (Platform) موجود استفاده کنیم؟ آیا برای راهکار نرم‌­افزاری جدید باید از مؤلفه‌های پیاده‌سازی شده در سایر تیم‌ها استفاده کنیم؟ معمولاً این جور کارها رو انجام می‌دیم.»

بِث گفت: «البته مستنداتی هم برای پاسخ این پرسش‌ها تهیه می‌کنیم.»

یوآخیم پرسید: «شما به این کار چی می‌گید؟»

سزار گفت: «با کلمه‌ی «طراحی» موافقید؟»

فرانک گفت: « آها…، نه، درست نیست. در این مرحله باید کارهای زیادی انجام بشه. شاید «تحلیل» (Analyze) کلمه‌ی مناسب­تری باشه.» و از مارکوس پرسید: «نظر شما چیه؟»

مارکوس رو به روی گروه ایستاد و گفت: «من نظری ندارم. این گردش‌ِکار تیم شماست. به جای من، از تیم بپرسید. نظر شماها چیه؟»

دافنه گفت: «بله. تحلیل کلمه‌ی مناسب­تری‌ یه.» بقیه هم به­‌نشانه‌ی موافقت سر تکان دادند.

مارکوس پرسید: «کاری هست که الآن مشغول تحلیل اون باشید؟»

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

یوآخیم گفت: «گردش کار رو تا مرحله‌ی «عملیاتی شدن» ( In production) دنبال کنید.» یوآخیم با خودش فکر ‌کرد که بعضی اوقات یکسری واژه‌های ناب (Lean) پشت سر هم تبدیل به شعر می‌شوند. نگاه سریعی به اطراف انداخت و متوجه شد که بقیه هنوز منظورش را نفهمیده‌اند. سرفه‌ای کرد و گفت: «خب! بعد از تحلیل چی‌کار می‌­کنید؟»

در ادامه، اعضای تیم ستون­های توسعه (Development) و آزمون (Testing) را به تابلو اضافه کردند و برگه‌­های کارهاي موجود را روی این ستون‌­ها چسباندند. سپس خیلی کوتاه در مورد معنی کار «انجام ‌شده» (Done) با هم بحث کردند. آنها تصمیم گرفتند در گردش‌کار مرحله­‌ای برای پذیرش(Accept) اضافه کنند و نام «پذیرش» را روی ستون آن قرار دادند. وقتی این کار تمام شد، آدام متوجه شد که سه تا از برگه‌های ستون «آزمون» قبلاً آزمون شده‌اند و منتظر تأیید سزار هستند. بنابراین تصمیم گرفتند سه برگه را به ستون «پذیرش» در کنار برگه‌ی دیگری که در آن ستون قرار داشت منتقل کنند.

آدام پای تابلو رفت و برگه­‌ها را از ستون آزمون به ستون پذیرش منتقل کرد.

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

اریک گفت: «خوش‌تیپ! خب ما باید کارها را روی سرویس‌دهنده‌های عملیاتی تحویل بدیم.»

دافنه بی‌معطلی گفت: «و منظورت از «ما» چیه؟»

اریک با حسرت آهی کشید و گفت: «عملیات» (Ops)

مارکوس گفت: «اون دیگه چیه؟»

فرانک مؤدبانه توضیح داد: «خب منظورش بخش عملیاته.»

دافنه زیر لب گفت: «بخش عملیاتِ شرکت به شرکت دیگری برون­سپاری (Outsourcing) شده ­است. و این مسأله، زمان استقرار محصول نهایی رو افزایش می‌ده.»

«اولین کاری که اونها کردند این بود که دسترسی ما رو به سرورهای عملیاتی قطع کردند.»

یوآخیم پرسید: «فکر می‌کنم مجبورید منتظر بمونید تا نسخه به تیم عملیات تحویل بشه. بعدش چی؟»

اریک با ناامیدی گفت: «خب! اون­ها استقرار محصول رو شش بار در سال انجام میدن. و فعلاً هم تصمیم ندارن این رویه­ رو تغییر ِبدن.»

آدام گفت: «بنویسید «در انتظار عمليات» (Waiting for Ops) یا چیزی شبیه به این»

فرانک گفت: «آره، فعلاً همین کلمه خوبه. ادامه بدیم.»

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

مارکوس پرسید: «چرا؟»

دافنه گفت: «چون تنها کاری که باقی مونده، عملیاتی کردنه که دست ما نیست.»

فرانک ادامه داد: «آره، ما بعد از این مرحله، کار زیادی نداریم.»

یوآخیم و مارکوس نگاهی به هم کردند و بدون گفتن کلامی این سوال را بین خودشان رد و بدل کردند که «نوبت کیه؟ من یا تو؟». ظاهراً نوبت یوآخیم بود.

یوآخیم پرسید: «مشتری شما کیه؟»

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

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

فرانک هم توضیح داد: «خب، ذی­نفعانی (Stakeholders) که نیازمندی­های سیستم رو نوشتند.»

یوآخیم موذیانه گفت: «واقعاً؟»

بِث متفکرانه گفت: «آها…، لطفاً دوباره «مشتری» رو برای من تعریف کنید.»

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

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

یوآخیم با پرسش خود، آنها را تحت فشار قرار داد: «پس ستون «در انتظار عمليات» چی؟ آیا این کار (در انتظار عملیات)، کاربر نهایی شما رو خوشحال‌تر می‌­کنه؟»

بِث گفت: «البته که نه. اما فرایند ما این شکلیه. چه کاری از دست ما برمی‌آد؟»

یوآخیم رو به گروه کرد و پرسید: «اگر از شما بخواهیم که همه‌ی برگه‌های «در انتظار عمليات» رو روی تابلو بچسبونید، چند تا برگه می‌شه؟»

قبل از اینکه کسی فرصت صحبت کردن پیدا کند، اریک جواب داد: «یک کامیون!»

فرانک گفت: «خب. تعداد اون­ها خیلی زیاده. آخرین انتشار…..» سکوت کرد وبعد از کمی فکر کردن گفت: «فکر می‌کنم چهارشنبه‌ی این هفته یک نسخه بالا می‌آد. حدس می­‌زنم حدود 25 تا 40 تا قلم توش باشه.»

مارکوس رو به سزار کرد و پرسید: «پروژه‌هایی که «در انتظار عمليات» هستند چه فایده‌ای برای مشتریان شما دارند؟» و به ستون آن اشاره کرد.

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

یوآخیم پرسید: «می­‌تونید اون رو تغییر بدید؟»

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

بخش بعدی
بخش قبلی

پیش‌گفتار:

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

از ایشان سپاسگزارم که زحمت کشیدند و گزارشی در این زمینه نوشتند تا بتوانم آن را در اینجا منتشر نمایم. برای ایشان بهترین‌ها را آرزومندم.

گزارش یک Meetup:

اگر نخوام زیاد کشش بدم و از خلقت آدم و حوا شروع کنم! باید بگم که با استفاده از نرم افزار Meetup برای شرکت در نشست Software Craftsmanship (مهارت در نرم افزار) که توسط آقای Mark Seemann در شرکت NNIT برگزار میشد، اعلام آمادگی کردم و روز Meetup اونجا حاضر شدم.

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

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

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

فقط این رو ذکر کنم که این نکات رو قبل از عید در ایران، استاد عزیز، جناب آقای مهندس مهرداد، به زبان فارسی سلیس و خیلی روان و قابل فهم برای من گفته بودن! انگار نه تنها زبان برنامه‌نویسی در تمام دنیا یکسان هست که رفتار برنامه‌نویسان هم در تمام دنیا شبیه هم هست!! یعنی هر جایی که در کلاس و تو ایران به یاد خاطرات مون و کارهای کرده و نکرده می‌خندیدیم! اینجا هم دقیقا به همون نکات می‌خندیدن! هر جا که استاد مهرداد در ایران خواهش می‌کرد که این کار رو انجام بدید یا انجام ندید!! آقای مارک سیمن هم ملتمسانه ازمون میخواست که چه چیزهایی رو رعایت کنیم!

بگذریم. برسیم به اهم سخنان مارک سیمن متخصص معماری نرم افزار و برنامه نویس.
1- نقل قولی از آقای مارتین فاولر به این مضمون:
Any fool can write code that a computer can understand. Good programmers write code that humans can understand.
2- فرضیه خوانایی کد رو مطرح شد. ” Code is read much more than written ” پس یه جوری بنویسید که راحت قابل خوانده شدن باشه. توصیه اکید بر کامنت گذاشتن در کدها داشتن!
3- از نوشتن کدهای طولانی خودداری کنید. کدهای شما تا حد ممکن باید کوتاه باشند. برنامه‌های بلند را به کلاس ها، متدها و کدهای دیگر بگنجانید!
4- از بازی تنیس بخاطر خاصیت رفت و برگشتی سریع به عتوان مدلی مناسب برای برنامه‌نویسی نام برد
5- کدهایی بنویسید که مهربان و زیبا باشند!!
6- از کدهای بد یا کثیف دوری کنید.
7- عدم استفاده بیش از حد از حلقه‌ها و دستورات کنترلی و …
8- لزوم رعایت اصول شی‌گرایی در برنامه‌نویسی مثل: تجرید، چسبندگی، وارونگی وابستگی، وارونگی کنترل، خودت را تکرار نکن و ….
9- لزوم Refactoring و اصلاح مجدد کدها
10- حتما برای کدهای خود تست بنویسید! (خنده ی حضار!!)
11- لزوم استفاده از Source Code Control System
12- حتما به زبان مورد علاقه خودتون برنامه نویسی کنید، با این حال از یادگرفتن زبان های دیگر غافل نشوید!

گزیده:
ندارد.