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

۳-۲-تیم توسعه

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

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

۳-فعاليتها و فرآورد‌ه‌های اسکرام

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

اسپرینت با برنامه‌ریزی شروع می‌شود، با انجام کارهای توسعه در طول اسپرینت که اجرای اسپرینت نامیده می‌شود، ادامه می‌یابد و با بازنگری (Sprint Review) و بازاندیشی(Sprint Retrospective) اسپرینت به پایان می‌رسد.

تعداد اقلام بک‌لاگ محصول(Product Backlog Item) بیشتر از چیزی است که تیم توسعه قادر به انجام آنها در یک اسپرینت باشد. به همین دلیل در ابتدای هر اسپرینت، تیم توسعه تعیین می‌نماید که کدام یک از اقلام بک‌لاگ محصول را می‌تواند تا پایان اسپرینت انجام دهد. این فعالیت برنامه‌ریزی اسپرینت(Sprint Planning) نامیده می‌شود.

تغییرات سال 2011 «راهنمای اسکرام»(شوئبر و سادرلند 2011) منجر به بروز این بحث گردید که واژه مناسب برای توصیف نتیجه‌ی برنامه‌ریزی اسکرام چیست: پیش‌بینی یا تعهد؟

گزیده:
پسرخاله: یه روز رفتم نونوایی، نونوا گفت هر کسی اومد بگو پشت سرت وا نسه، نون نمی‌رسه؛
منم هر کی اومد گفتم بیا جلوی من واسا؛ پشت سرم نون نمی‌رسه….
کلاه قرمزی

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

جناب آقای مهندس نوذری عزیز سایت جدیدی –پارس آنالیست– را راه‌اندازی کرده‌اند (ایشان نویسنده وبلاگ اندیشه هستند). ضمن عرض شادباش خدمت ایشان، برایشان آرزوی مؤفقیت دارم.
دو خبر بسیار مهم را به نقل از سایت ایشان در اینجا آورده‌ام.

۱) کنفرانس مجازی IIBA
شرکت اینتل با همکاری شعبه IIBA در انگلستان یک کنفرانس علمی آموزشی را به صورت مجازی با عنوان Intel BA Web 2013 در روز چهارشنبه ۱۶ اسفندماه از ساعت شش و نیم تا ده و نیم بعدازظهر به وقت ایران برگزار می نماید. این سمینار و سخنرانی های آن پیرامون مباحث تحلیل کسب و کار و موضوعات مرتبط با آن خواهد بود.
در این همایش ۵ سخنران با موضوعات زیر سخنرانی خواهند داشت. که جهت کسب اطلاعات بیشتر و ثبت نام در سمینار می توانید به این لینک مراجعه نمایید. ضمنا شرکت در همایش رایگان بوده و نیاز به عضویت در IIBA هم ندارد.

۲) دوره IIBA مجازی
دانشگاه کالیفرنیا در مرکز آموزش های مجازی خود بخشی با نام Fundamentals of Business Analysis دایر نموده است که تمام محتوای استاندارد BABOK 2.0 را پوشش داده و قابلیت های تعامل با کاربر را نیز دارد. محتوای فراهم شده قوی و جالب هستند. بخصوص اینکه لینک های خارجی، ارزیابی و مواردی شبیه به این نیز فراهم شده است. این بخش در سایت دانشگاه کالیفرنیا قابل دسترسی می باشد.

گزیده:
تنها براي دست يافتن به امور محال است كه بشر مي‌تواند به بالاترين حد امور ممكن دست يابد. سنت بور
مرجع: اس.جی.

دوستان گرامی عضو انجمن چابک ایران به سرپرستی جناب آقای مهندس صفری کار بزرگی انجام داده و کتاب «اسکرام و کانبان در کنار هم» (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 برای تیم خود را مدیریت کنید و در کنار تغییر فرایند، تحویل محصول نیز دچار مشکل بیشتری نشود.

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