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

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

پاسخ:
در مورد اسپرینت، تعیین هدف الزامی است. اما ممکن است به صورت رسمی و فرمال وجود نداشته باشد مثلاً در پروژه‌ای که به تازگی شروع شده، اقلام اولویت‌دهی‌ شده‌ای وجود دارند که باید به ترتیب انجام شوند. اما در توسعه‌ی محصول به خصوص زمانی که به محصول نسخه یک نزدیک شده‌ایم یا بعد از انتشار(Release) نسخه یک محصول وجود هدف الزامی است.

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

۲-یکی از شاخص‌های ارزیابی مؤفقیت تیم در اسپرینت، میزان تحقق هدف آن است. به عبارت دیگر، بخشی از تعهد تیم، تحقق هدف اسپرینت است. در بازنگری اسپرینت (Sprint Review) یکی از ورودی‌های مهم، هدف اسپرینت است. در پایان ماه از خانواده خواهیم پرسید که خوب ما که این همه خرج کردیم و هدفمان برگزاری جشن تولد بود، آیا جشن تولد به خوبی برگزار شد؟ آیا همه شاد و خندان بودند و رفتند؟

۳- هدف اسپرینت تحت تأثیر مسیر محصول(product roadmap) است که برای خیلی از شرکتهای ایرانی، واژه‌ای غریب است. مالک محصول باید و باید مسیری برای محصول داشته باشد. در مثال جشن تولد، خانواده و به خصوص مادر خانواده باید بداند که در دی ماه دو تا جشن تولد دارد، در اسفندماه خرید شب عید دارد و در فروردین هم مسافرت دارد و همه اینها خرج دارد و حقوق همسر(ظرفیت تیم) هم محدود و مشخص است

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

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

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

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

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

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

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

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

بخش اول
بخش دوم
بخش سوم
بخش چهارم

۳-۱– بک‌‏لاگ محصول

با به‌‏کارگیری اسکرام، همیشه باارزش‏‏‌ترین کارها زودتر انجام می‌‏شوند. مالک محصول با اطلاعات دریافتی از تیم‏ توسعه و ذینفعان، مسئول نهایی تعیین و مدیریت توالی انجام کارهاست. کارها به شکل فهرستی دارای اولویت‏(یا ترتیب) به نام بک‌‏لاگ محصول (Product Backlog) ارائه می‌‏‏شوند

شکل: بک‌‏‏لاگ محصول، مرجع

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

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

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

در سال 2011 انتخاب واژه مناسب برای شیوه چینش اقلام بک‏‏‌لاگ، موضوع بحث و جدل شد. موضوع بحث این بود که کدام یک از دو واژه اولویت‌‏دهی‌ شده (نخستین واژه)(Prioritized) یا مرتب‌‏‌شده(Ordered) (استفاده شده در راهنمای اسکرام 2011)، واژه مناسب‏‌‏تری است. برخی مدعی بودند که اولویت‌دهی فقط نوع ساده‏‏ای از مرتب‏‌‌‏سازی است(و البته حتی مناسب‏‏‌ترین روش آن نیز نیست).

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

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

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

شکل: اندازه‏‌گیری نسبی؛ مرجع

به عبارت دیگر، فقط به نسبت اندازه‏ یک قلم به سایر قلمها توجه می‌‏‏کنند. به عنوان مثال فرض کنید اندازه ویژگی C برابر 2 و ویژگی E برابر 8 است. پس اندازه ویژگی E، 4 برابر ویژگی C است. در روش اندازه‏‌‏گیری نسبی، تنها چیزی که اهمیت دارد، 4 برابر بودن اندازه E نسبت به C است و نه اندازه دقیق E و C.

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

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

ضمن تشکر از دوست گرامی جناب آقای مهندس مهدی نگاهی، ترجمه مقاله “در آغوش گرفتن تغییرات با XP”
یا Embracing Change with Extreme Programming نوشته Kent Beck را می‌توانید از اینجا دریافت فرمایید.

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

برچسب‌ها: چابک Agile

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

مجموعه جدید مقاله‌ها، به حوزه نیازمندی‌ها در متدهای چابک اختصاص داده شده است. مرجع فعلی مطالب، کتاب Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise نوشته‌ی Dean Leffingwell است.

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

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

فصل ششم
1-مقدمه
1-1-مروری بر داستان کاربر
1-2-داستان کاربر به کاهش فاصله مشتری-توسعه‌دهنده کمک می‌کند
1-3-داستان کاربر نیازمندی نیست
2-شکل داستان کاربر
3-INVEST در داستان‌های کاربر خوب
4-تقسیم داستان‌های کاربر
5-اسپایک‌ها(Spike)
6-مدلسازی داستان با کارت‌های نمایه
7-خلاصه فصل

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

درمورد آن‏چه که برای کاربر ارزشمند است، داستانی تعریف کنید؛
آن را در یک تکرار کوتاه پیاده‏سازی و آزمایش کنید؛
سپس آن را به کاربر نمایش یا تحویل دهید؛
تا ابد این کار را تکرار کنید!

شکل ۶-۱ خلاصه‏ای از فرآورده‏های مرتبط با نیازمندی‏ها را نشان می‏دهد که برای تحقق این رویکرد لازمند.

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

۱-۱-بازنگری داستان کاربر
به بخشی از تأثیرات اسکرام در توسعه تجربه‏های سازمانی چابک در فصلهای گذشته اشاره شد. به عنوان نمونه می‏توان به نقش «مالک محصول» اشاره کرد که بخش‏ مهمی از تجربه‌های حوزه نیازمندی‏ است. اما ابداع داستان کاربر را به متد XP مدیونیم و این طرفداران XP بودند که آن را بسط و گسترش دادند. بک(Beck) و فاولر(Fowler) در [2005] می‏نویسند:
«داستان، واحد کارکرد پروژه‏‏های مبتنی بر XP است. پیشرفت پروژه با تحویل کد هر داستان که آزمایش‏ و یکپارچه شده‏، نشان داده می‏شود. داستان باید قابلِ فهم برای مشتریان و توسعه‏دهندگان؛ آزمون‏پذیر؛ ارزشمند برای مشتریان؛ و به اندازه‏ای کوچک باشد که برنامه‏نویس بتواند تعدادی از آنها را در هر تکرار انجام دهد.»

با این حال، هر چند سرآغاز داستان کاربر از XP است، اما از جمله موضوعاتی است که درباره‏ی آن در متدولوژی‏ها اتفاق‏نظر وجود دارد. به همین دلیل، هم‏اکنون داستان‏ کاربر بخشی از دوره‏های آموزشی اسکرام به عنوان ابزاری جاافتاده برای ایجاد بک‏لاگ محصول و تعریف اسپرینت است. بخش عمده‏ای از یکپارچه‏سازی داستان‏کاربر با اسکرام توسط مایک کوهن(Mike Cohn) انجام شده که از وی سپاسگزاریم. او یکی از فعالان انجمن‏های اسکرام و کسی است که مفهوم داستان کاربر را در کتابش [2004] بسط و گسترش داد.

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

اغلب داستان‏های کاربر در XP توسط مشتری نوشته می‏شود که باعث حضور مستقیم وی در فرایند توسعه می‏شود. در اسکرام نیز اغلب مالک محصول داستانهای کاربر را با دریافت اطلاعات از مشتریان، ذینفعان و تیم می‏نویسد. عملاً هر عضو تیم که درباره‏ی قلمروی مسأله دانش کافی داشته باشد، می‏تواند داستانهای کاربر را بنویسد، اما وظیفه‏‏ی پذیرش و اولو‏یت‏دهی آنها با مالک محصول است.

داستان کاربر ابزاری برای تعریف رفتار سیستم است به‏گونه‏ای که برای کاربر و توسعه‏دهنده قابل فهم باشد. با به‏کارگیری داستان کاربر، کارها براساس ارزش تعیین‏شده‏‏ی کاربر انجام می‌شوند و نه براساس روش رایجِ ساختار شکستِ کارکردی(functional breakdown structure) . از طرف دیگر داستان کاربر، رویکردی سبک و مؤثر برای مدیریت نیازمندی‏ها نیز فراهم می‏کند.

داستان کاربر شرح کوتاهی از کارکرد سیستم است که بر روی یک کارت نمایه (index card) یا احتمالاً در یک ابزار نوشته می‏شود. در ساده‏‏ترین شکلِ بک‏لاگ، داستان‏ها فقط فهرستی از کارهایی‌اند که سیستم باید برای کاربر انجام دهد. به عنوان مثال:
○ ورود به صفحه‏ی پرتال پایش انرژی
○ دیدن مصرف انرژی روزانه
○ کنترل نرخ هزینه‏ی فعلی برق

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

گزیده:
انسانها ابزارِ ابزارهای خود شده‌اند.
اچ دی تورو

برچسب‌ها: چابک Agile, نیازمندی‌ها Requirements

نتایج یک مطالعه نشان داده است مهندسان و طراحان نرم افزار بخش زیادی از وقت خود را صرف فعالیت‌های حاشیه‌ای نرم افزار نویسی می‌کنند و فعالیت‌های اصلی این حرفه وقت کمتری از آن‌ها می‌گیرد.
به گزارش وب سایت infoworld، مطالعه یک شرکت عرضه کننده خدمات توسعه نرم افزاری به نام الکتریک کلود نشان می‌دهد مهندسان نرم افزار بخش زیادی از وقت شغلی خود را صرف فعالیت‌هایی به غیر از طراحی نرم افزار و برنامه نویسی می‌کنند. در این مطالعه که نظر ۴۴۳ مهندس نرم افزار را در ماه مارس جویا شده بود، مشخص شد که فعالیت‌های اصلی برنامه نویسی و طراحی نرم افزار به طور متوسط هفته‌ای ۱. ۱۹ساعت زمان می‌برد، اما دیگر فعالیت‌های مرتبط با این رشته شغلی در مجموع به زمان بسیار بیشتری نیاز دارد.
بر اساس این گزارش، هم اندیشی بین مهندسان نرم افزار یا به اصطلاح «طوفان مغزی» هفته‌ای ۷. ۶ ساعت وقت از آن‌ها می‌گیرد. فعالیت‌های اجرایی مثل بررسی ایمیل‌ها و یا شرکت در جلسات رسمی نیز هفته‌ای ۸. ۵ ساعت زمان لازم دارد. همچنین مشخص شد مهندسان نرم افزار هفته‌ای ۷. ۳ ساعت از وقت کاری خود را منتظر می‌مانند تا نرم افزار طراحی شده آزمایش شود و ۵. ۳ ساعت در هفته را نیز منتظر تکمیل نرم افزار طراحی شده می‌مانند. مدیریت محیط شغلی نیز هفته‌ای ۷. ۲ ساعت زمان می‌برد و ۹. ۹ ساعت نیز صرف امور خانه‌داری می‌شود.
این آمار و ارقام نشان می‌دهد مهندسان نرم افزار در مجموع ۴. ۲۲ ساعت از ۵. ۴۱ ساعت وقت کاری خود در هفته را به فعالیت‌هایی غیر از برنامه نویسی و طراحی نرم افزار اختصاص می‌دهند.
منبع: همکاران سیستم

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

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

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

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

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

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

گزیده:
درس سوم: قراردادهای کاری را طوری انتخاب کنید که انگار دارید دنبال همسر می‌گردید

برچسب‌ها: کتاب

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

بخش اول
بخش دوم
بخش سوم

ادامه …
واژه مناسب برای توصیف نتیجه‌ی برنامه‌ریزی اسکرام چیست: پیش‌بینی یا تعهد؟

استدلال طرفداران واژه پیش‌بینی این است که هر چند تیم توسعه بهترین برآورد را در زمان برنامه‌ریزی ارائه می‌نماید، ولی در طول اسپرینت با دریافت اطلاعات جدید، احتمال تغییر برآوردها وجود دارد. برخی دیگر از طرفداران نیز بر این باورند که تعهد گرفتن از تیم می‌تواند باعث شود که آنها برای پای‌بندی به تعهد خود یا کیفیت را فدا کنند یا تعداد اقلام را کاهش دهند.
برخی نیز با این نظر موافقند که بهتر است تیمهای توسعه آنچه را که می‌توانند در هر اسپرينت تحويل ‏دهند، پیش‏بینی(برآورد) کنند و نه تعهد.
با این حال بسیاری از تیم‏های توسعه می‌توانند از پیش‏بینی برای تعهدسپاری نیز استفاده کنند. تعهدات، اعتماد بین مالک محصول و تیم توسعه و همچنین بین اعضای تیم را افزایش می‏‌‏دهد. از طرف دیگر، تعهدات موجب تقویت برنامه‌ریزی و تصمیم‏‌گیری‌‏های کوتاه‏مدتِ قابل قبول در سازمان می‏گردد. اگر محصولی همزمان توسط چندین تیم در حال توسعه باشد، تعهدات باعث ایجاد هماهنگی در برنامه‌‏ریزی تیم‏ها می‌شود –یک تیم می‌تواند بر اساس تعهد سایر تیمها، برنامه‌ریزی کند.

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

اجرای اسپرینت گام بعدی است که تیم، کارها و وظایف لازم را برای تحقق ویژگی‌ها انجام می‏‌دهد. در هر روز از اسپرینت، اعضای تیم فعالیتی از نوع هماهنگی، بازرسی(inspection) و انطباق‌پذیری(adaptation) به نام اسکرام روزانه(daily scrum) را برای کمک به مدیریت کارها انجام می‌دهند. تیم در پایان اسپرینت، بخش قابل عرضه‌ای از محصول را تولید می‌کند که قسمتی از چشم‌انداز مورد نظر مالک محصول است.

عکس برگرفته از اینجا

تیم اسکرام، اسپرینت را با انجام دو فعالیت از نوع بازرسی و انطباق‌پذیری به پایان می‌رساند. در فعالیت اول که بازنگری اسپرینت (sprint review) نامیده می‌‏شود، ذینفعان و تیم اسکرام محصول ساخته شده را بررسی می‌کنند که ممکن است منجر به درخواست تغییراتی گردد که در بک‌لاگ محصول ثبت می‌شود. در فعالیت دوم که بازاندیشی اسپرینت (sprint retrospective) نامیده می‌شود، تیم اسکرام فرایند ساخت محصول را بررسی می‌کند که ممکن است منجر به تغییراتی در فرایند توسعه شود.

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

در ادامه موضوعات زیر شرح داده خواهد شد:
– بک‌لاگ محصول
– اسپرینت
– برنامه‌ریزی اسپرینت
– اجرای اسپرینت
– اسکرام روزانه
– واژه «کامل شد»
– بازنگری اسپرینت
– بازاندیشی اسپرینت

گزیده:

Unless commitment is made, there are only promises and hopes… but no plans.
Peter Drucker

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