دوستان گرامی عضو انجمن چابک ایران به سرپرستی جناب آقای مهندس صفری کار بزرگی انجام داده و کتاب «اسکرام و کانبان در کنار هم» (Kanban and Scrum – making the most of both) را به فارسی برگردانده‌اند.

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

– جناب آقای اسد صفری
– جناب آقای آرش میلانی
– جناب آقای رضا فرشی
– جناب آقای سهیل صمدزاده
– جناب آقای سینا استاد‌هاشم
– جناب آقای صادق ترکمن
– جناب آقای علی مقدم
– سرکار خانم فاطمه کروبی
– جناب آقای هادی نیکوئی
– جناب آقای محمود متین‏فر

کتاب را می‌توانید از اینجا دانلود فرمایید و درباره‌اش در اینجا بیشتر بدانید.

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

مترجم: مهندس شهاب‌الدین فرحبخش
بخش اول

۱-۲-مالک محصول(Product Owner)
مالک محصول، نفر اصلی و صاحب صلاحیت در رهبری محصول است. وی تنها مرجع تصمیم-گیری برای انتخاب ویژگی‏های محصول و ترتیب ساخت آنها است. مالک محصول، چشم‏انداز روشنی از کار تیم اسکرام را با همکاری ذینفعان تهیه و همواره به‏روز نگه‏ می‏دارد. به همین دلیل، وی مسئول موفقیت کلی راهکار است که می‏تواند توسعه سیستمی جدید یا نگهداری سیستم موجود باشد.

مهم‏نیست که هدف، تولید محصولی برای مشتریان خارجی است یا برنامه‏ای برای داخل سازمان. در هر صورت وظیفه مالک محصول، اطمینان از انجام باارزش‏ترین کار ممکن -شامل کارهای فنی- است. مالک محصول برای کسب اطمینان از برآورده شدن سریع خواسته‏هایش توسط تیم، فعالانه با راهبر اسکرام و تیم توسعه همکاری می‏کند و باید برای پاسخگویی به پرسش‏های آنان در زودترین زمان ممکن در دسترس باشد.

۲-۲-راهبر اسکرام( SCRUM Master)
راهبر اسکرام به کسانی که در حال یادگیری و پذیرش ارزشها، اصول و تجربه‏های اسکرام هستند، کمک می‏کند. وی مانند یک مربی، رهبری فرآیند را بر عهده دارد و به تیم اسکرام و سازمان کمک می‏کند که روشی مبتنی بر اسکرام با کارایی بالا و خاص سازمان ایجاد کنند. همزمان با این کار، راهبر اسکرام به سازمان در رفع چالش‏های ناشی از پذیرش و بکارگيری اسکرام نیز کمک می‏کند.

وی در نقش تسهیل‏کننده(Facilitator)، به تیم در رفع مشکلات ناشی از اجرای اسکرام و ایجاد بهبود در آن کمک می‏کند. وظیفه حفاظت از تیم در برابر عوامل مزاحم بیرونی بر دوش راهبر اسکرام است. وی با برداشتن موانعی که بهره‏وری تیم را کاهش می‏دهد، نقش رهبری‏اش را ایفا می‏کند(در صورتی که افراد تیم قادر به رفع آنها نباشند).

راهبر اسکرام مجاز به اعمال کنترل بر تیم نیست، از این رو، این نقش به نقش‏های سنتی مدیر پروژه یا مدیر توسعه شباهتی ندارد. وی مانند یک رهبر عمل می‏کند، نه یک مدیر.

گزیده:
پاداش‌هايي كه در زندگي مي‌گيريد بستگي به اين دارد كه چه كاري مي‌كنيد، چقدر خوب آن را انجام مي‌دهيد و چقدر مشكل است كه بتوان كسي را جايگزين شما كرد. برايان تريسي
مرجع: اس.جی.

برچسب‌ها: Scrum اسکرام, Agile چابک

پیش گفتار

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

مقدمه:
یکی از عباراتی که خیلی وقت‌ها می‌شنویم این است که: اینتراپت نده! (وقفه یا interrupt)
در فرهنگ لغت دهخدا، در شرح «وقفه» آمده است:
1ـ توقف، ایست، مکث، درنگ 2ـ توقف در حرفی از کلمه 3ـ فراغت، فرصت

interrupt در اینجا بدین شکل تعریف شده است:

1. To break the continuity or uniformity of: Rain interrupted our baseball game.
2. To hinder or stop the action or discourse of (someone) by breaking in on: The baby interrupted me while I was on the phone.

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

تجربه نشان داده است که هر چند نمی‌توان تعداد وقفه‌ها در کار را به صفر رساند، اما مدیریت و کنترل آنها به شکل معناداری در افزایش کارایی و رضایت اعضای تیم مؤثر واقع می‌شود.

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

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

گزیده:

“Don’t interrupt me while I’m interrupting.”
Winston Churchill

مترجم: آقای مهندس مهدی نگاهی

تغییر نیازمندها
غول [بزرگ‌ترین و ترسناک‌ترین] مشکلات بسیاری از روشهای توسعه نرم‌افزار، فقط در حد یک مشکل ساده در XP است. با به کارگیری دستورالعمل «انجام طراحی فقط برای مسأله‌های امروز»، سیستمی که بر اساس XP در حال ساخت است، روز بعد برای پیمودن هر مسیری آمادگی دارد. انجام کارهای مشابه با کارهای قبلی، به دلیل ماهیت تکنیک بازسازی( Refactoring) در برآورده کردن اصل «یک بار و فقط یک بار»، ساده تر خواهد بود. لازم به یادآوری است که کارهای مشابه در یک پروژه زیاد است. با این حال، با اعلام یک نیازمندی اساسی و متفاوت-نامشابه-، برای انجام آن مجبور نیستید پای‌بند بسیاری از مکانیزمهای قبلی باشید.
در ابتدا درکی از میزان توانایی XP برای مواجهه با تغییر نیازمندی‌ها نداشتم. در اولین نسخه XP، تعیین این که هر داستان در کدام تکرار انجام شود، بخشی از برنامه‌ریزی انتشار(Release Planning) بود. تیم به مرور به این نتیجه رسید که می‌توان با کاهش زمان برنامه‌ریزی به نتایج بهتری دست یافت؛ کافی است از مشتری بخواهید فقط داستانهای تکرار جاری را انتخاب کند. در این روش، با شناسایی هر داستان جدید، نیازی نیست ترتیب داستانهای موجود در تکرارهای باقی‌مانده را بهم ریخته و دوباره مرتب کنید تا تکرار انجام داستان جدید مشخص شود. تنها کاری که باید انجام دهید، قراردادن داستان جدید در بین داستانهای انجام‌نشده است. یک یا دو هفته بعد، اگر داستان جدید هنوز هم برای مشتری اهمیت داشته باشد، وی آن را برای انجام در تکرار پیش‌رو انتخاب خواهد کرد.
(مترجم:
فرض کنید که در سه تکرار پیش رو، قرار است داستانهای زیر انجام شود(اندازه هر داستان جلوی آن مشخص شده است). سرعت تیم برای هر تکرار را 7 فرض کنید.
تکرار 1:
داستان A‏ = 3 داستان B‏ = 4
تکرار 2:
داستان C‏ = 5 داستان D‏ = 2
تکرار 3:
داستان E‏ = 2 داستان F‏ = 3 داستان G‏ = 2

حال اگر داستان Z با اندازه 2 به تازگی شناسایی شود و مشخص گردد باید که بعد از داستان A انجام شود، ترتیب انجام داستان‌ها و تکرارهای متناظر آنها دچار تغییر می‌شود که در زیر نمایش داده شده است. این تغییر فقط یک جابه‌جایی ساده نیست، بلکه واقعاً به‌هم ریختن داستان‌ها و مرتب‌سازی دوباره است(به ترتیب حروف الفبای انگلیسی در بالا و پایین دقت کنید).
تکرار 1:
داستان A‏ = 3 داستان Z‏ = 2 داستان D‏ = 2
تکرار 2:
داستان B‏ = 4 داستان F‏ = 3
تکرار 3:
داستان C‏ = 5 داستان E‏ = 2
تکرار 4:
داستان G‏ = 2
)

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

Ron Jeffries

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

گزیده:
روياهاي كوچك نداشته باشيد، چون آن‌ها قدرت حركت دادن قلب انسان را ندارند.
يوهان ولفگانگ فان گوته

تصویر زیر برگرفته از سایت اتحادیه چابک(agile alliance) است. در این تصویر، تجربه‌های(practices) متدهای چابک در قالب دسته‌هایی به نمایش گذاشته شده است.
هر بار که به این تصویر نگاه می‌کنم، زیبایی و سادگی‌اش تحسین مرا برمی‌انگیزد. شاید این احساس ناشی از شباهت این تصویر با نقشه متروی تهران باشد!

برای مشاهده تصویر بزرگتر روی آن کلیک کنید.

گزیده:
مرد خردمند هنر پیشه را
عمر دو بایست در این روزگار
تا به یکی تجربه آموختن
با دگری تجربه بردن به کار.
سعدی

ضمن سپاس از آقای مجید آواژ، نوشته زیر به نقل از ایشان در روزنوشت‌های بهساد آورده شده است.
“