| تبليغات | X |
راه حل عملی و قاطع برای تخمین و برنامه پروژهای Agile است.
آدرس سایت ایترنتی موسسه مایک کوهن(Mountain Goat Software):
http://www.mountaingoatsoftware.com/
PO Box 165
Lafayette, Colorado 80026
Phone: 1-888-61-Agile (24453)
این نمودار روند کارهای باقی مانده را در sprint را نمایش می دهد. بعبارت دیگر این نمودار پیشرفت روزانه تیم را در خلال دوره sprint نشان می دهد. این نمودار هر روز توسط تیم و Scrum Master بروز می شود و در واقع شیوه ساده ای است برای نمایش پیشرفت کار و در عین حال می تواند مرجعی بصری سریعی برای درک وضعیت پروژه باشد.
البته انواع دیگری نیز از نمودار های Burn Down وجود دارد:
Release Burn down Chart
این نمودار حجم کار لازم برای رسیدن به هدف تیم یعنی commit کردن نسخه جدید سیستم را نمایش می دهد و معمولاْ چندین sprint را شامل می شود.
این نمودار یک ابزار تصویری برای پیگیری روند تکمیل ویژگی های مورد انتظار از سیستم در رسیدن به اهدافی نظیر بازگشت سرمایه (ROI) یا یک تاریخ مشخص شده است. باکمک این نمودار٬ Product Owner می تواند تعداد واحد های کاری باقی مانده برای انتشار نسخه جدید را sprint به sprint تخمین بزند. این نمودار در عین حال نقش برجسته ای برای آگاهی بخشی به مدیریت سطح بالای پروژه دارد.با یک تحلیل ساده از روند این نمودار می توان فهمید کهآیا کار خاصی برای رسید به اهداف کاری پروژه هست یا خیر.
اگر ویژگی جدید به سیستم اضافه شود یا ویژگی از سیستم تغییر داده شود یا حتی حذف شود برای اینکه انعکاس این تغییرات و مشخص شدن تخمین جدید زمان تکمیل سیستم٬ بایستی این نمودار دوباره بروز کرد.
استفاده از این نمودار برای تخمین زمان خاتمه پروژه
به نمودار Product Burn-down Chart زیر دقت کنید. اولین sprint با ۳۸۰ مورد در Product Backlog شروع می شود که در نوار آبی اول کاملاْ مشخص شده است. در انتهای این sprint تیم ۱۸۰ مورد آنرا انجام می دهد و همینطور که می بینید نوار آبی دوم ۱۸۰ واحد پایین تر از نوار آبی اول است . اما از آن طرف در طی sprint اول٬ بیست مورد جدید به Product Backlog اضافه شده است برای مشخص کردن این موضوع ملاحظه می شود که نوار دوم بجای شروع شدن از صفر از ۲۰- شروع شده است چون در واقع ما در sprint دوم ۲۲۰ مورد برای تکمیل کردن پروژه داریم نه ۲۰۰ مورد. در ادامه روند پروژه هم همانطور که دیده می شود مدام موارد جدید به پروژه زیاد می شود.
با داشتن این اطلاعات می توان خطوط روند موارد تکمیل شده و روند موارد اضافه شده را ترسیم کرد. در نمودار بالا خط قرمز مشخص کننده روند موارد تکمیل شده و خط آبی مشخص کنند روند موارد اضافه شده در Product Backlog است. جایی که این دو خط به هم می رسند در واقع زمان تخمینی ختم پروژه است. بعبارت دیگر این نمودار به ما می گوید که اگر مورد جدیدی به Product Backlog اضافه نشود در ۲۰۰۴/۶/۱۰ تکمیل می شود اما اگر موارد جدیدی با این روند اضافه شوند این پروژه در سه sprint بعد ختم خواهد شد
البته از دیدن این نمودار ها می توان درس های دیگری هم گرفت: اول اینکه اگر مدام موارد جدید در Product Backlog با سرعتی بیشتر از سرعت انجام موارد توسط تیم مطرح شود پروژه هیچگاه به پایان نمی رسد پ برعکس اگر سرعت تیم در انجام موارد مندرجه در Product Backlog بیشتر از سرعت اضافه شدن موارد جدید در Product Backlog باشد پروژه سریعتر از آنچه برآورد شده به پایان خواهد رسید. در واقع مقایسه سرعت با حجم کارهای جدید تصویر دقیقتری از پیشرفت پروژه به ما می دهد.
Alternative Release Burn down Chart
این نمودار٬ همان کار نمودار سابق الذکر را انجام می دهد ولی در عین حال به وضوح حوزه کار را هم نشان می دهد.
۱- در طی جلسه برنامه ریزی دوره جدید Sprint Planning Meeting = SPM
۲- قبل از برگزاری جلسه بازبینی دوره Sprint Review Meeting = SRM
در جلسه SPM ٬ تیم مجبور است حجم کارها را تخمین بزند چون باید بر اساس آن٬ مدت sprint و تعداد نفرات کار از Product Owner بگیرد و در واقع آنها Sprint Backlog را براساس حجم کار نیازمندی ها پر می کنند.
در جلسه SRMُ ٬ تیم با اصلاح تخمین هایش و اعلام آنها به Product Owner به وی کمک می کند تا وقت بیشتری در خلال sprint برای افزودن موارد یا تغییر آنها در Product Backlog داشته باشد.
واحد های اندازه گیری حجم کار (Units of Complexity)
برای اندازه گیری حجم کار در مدیریت پروژه ها معمولاْ سه واحد زیر را در نظر می گیرند:
- Size Category
- Story Points
- Work days
در ادامه در مورد هر کدام از این واحد ها صحبت می کنیم
۱- Size Category: ساده ترین روش برای برآورد حجم کار لازم برای افزودن یک ویژگی یا قابلیت به سیستم استفاده از کلماتی مانند: کوچک٬ متوسط٬ بزرگ و خیلی بزرگ برای توصیف حجم کار لازمه برای آنهاست. البته لازمه استفاده از این دسته بندی این است که همه افراد درگیر دید یکسانی راجع به اطلاق این کلمات برای توصیف حجم کار لازمه فعالیت ها داشته باشند در غیر اینصورت احتمالاْ یکی از آنها بعضی از پیچیدگی ها کار را بیشتر از بقیه دیده است.
۲- Story Points: در این روش به موارد مشخص شده در Product Backlog یک امتیاز (Point) نسبت داده می شود. که مشخص کنند سطح نسبی پیچیدگی آن است. اینجا هم باز باید دید یکسان بین افراد وجود داشته باشد. مثلاْ در این روش اگر ویژگی A دو امتیاز داشته باشد و ویژگی B چهار امتیاز در اینصورت ویژگی B دو برابر بیشتر از ویژگی A طول خواهد کشید.
خاصیت این روش این است که تخمین زمان انجام پروژه را راحت تر می کند. در اینجا تعداد کل امتیاز ویژگی هایی که طی یک sprint تکمیل می شوند سرعت تیم (Velocity of the team) را مشخص می کند. بدست آوردن سرعت تیم برای خود تیم هم مفید است چون اعضاء تیم می توانند بر اساس آن بفهمند که چه مقدار کار را برای sprint بعدی می توانند قبول کنند.
۳ - Work days: این روش از قبل هم مرسوم بوده و تحت عنوان نفر- ساعت مطرح می شده. در اینجا پذیرنده کار عنوان می کند که مثلاْ این کار ۳ نفر ساعت وقت می گیرد. البته این نوع ارزش گذاری بر روی حجم کار ها می تواند بشدت گمراه کنند باشد. چون اولاْ بر اساس قابلیت های اعضاء فعلی تیم مطرح می شود و ثانیاْ امکان دارد باعث شود که کارفرما فکر کند با افزودن نیروی کار جدید کار سریعتر انجام می شود. یعنی به عنوان مثال اگر کار ۳ نفر ساعت باشد و این کار توسط یک برنامه نویس در ۳ ساعت انجام شود دلیلی وجود ندارد که اگر ما تعداد برنامه نویس ها را ۳ نفر کنیم این کار در یک ساعت انجام شود. وقتی می گوییم این کار ۶ نفر ساعت وقت می گیرد و تیم مان هم دو نفر بیشتر نیست یعنی اینکه این دو نفر در سه ساعت این کار را انجام خواهد داد و این خیلی اشتباه است که فکر کنیم با افزودن برنامه نویس سوم اینکار در دو ساعت انجام خواهد شد! (ولو اینکه برنامه نویس اضافه شده در قد و قوارهٔ دو برنامه نویس قبلی باشد). در واقع تخمین بر اساس این واحد نیازمند درک خوبی از کار محوله و قابلیت های تیم است٬ بنابراین با دقت از آن استفاده کنید.
روش های تخمین حجم کار
ساده ترین روش٬ بررسی کارشناس (Expert Review) است. یک برنامه نویس با تجربه که حوزه کاری محصول٬ تکنولوژی بکار رفته و اعضاء تیم را بخوبی می شناسد با یک نگاه سریع به ویژگی ها سیستم مورد انتظار می تواند یک تخمین نسبتاْ خوبی راجع به پیچیدگی کار بزند. این روش البته بکرار استفاده می شود اما در کلی موفقیت آن بستگی به تجربه و مهارت شخص تخمین زننده و روش های ذهنی و ابتکاری شخصی وی دارد.
روش بعدی ایجاد Work Breakdown Structure (اختصاراْ WBS) است. در اینجا کارها را آنقدر می شکنیم تا بجایی برسیم که بتوانیم در مورد خورده کارها تخمین درستی بزنیم و بعد با جمع تخمین خورده کارها می توانیم تخمین نسبتاْ خوبی از حجم کار لازم برای افزودن ویژگی مورد انتظار به سیستم بدست آوریم. این روش درواقع یک روش درختی است و از گذشته در تخمین زمان فعالیت های مختلف پروژه ها استفاده می شده. فقط اینجا باید احتیاط کنیم که زیاد در شکستن کارها عمیق نشویم چون در متدولوژی Agile سعی بر سریع انجام شدن کارهاست.
اصلاح تخمین ها
بعضی اوقات بعلت هایی مثل تغییر اعضاء تیم٬ تغییر شرایط کارکردن آنها و نظایر آنها مجبور خواهیم شد که در برآورد حجم کارها باقی مانده تجدید نظر کنیم. بهتر است در مورد هر کدام از این عوامل یک Drag Factor داشته باشیم. Drag Factor یا هزینه اضافی معمولاْ به درصد بیان می شود بعنوان مثال می گوییم اگر یکی از اعضاء تیم بخواهد از خانه اش و از راه دور با تیم کار کند ۲۰ درصد هزینه کار افزایش می یابد و در واقع Drag Factor اینجا ۲۰ درصد است. تعین Drag Factor ها کاری ذهنی و ابتکاری است ولی مقدار آنها باید در مستندات اسکرام ذکر شود.
تعریف کن شوابر:
هر Sprint یک دوره از سی روز متوالی تقویمی است.
Each Sprint is an iteration of 30 consecutive calendar days.
توجه: در بعضی از منابع الزامی بر مساوی بودن زمان sprint ها مشخص نشده است ولی توصیه شده که طول آنها یکسان باشد چون دقیق تر می توان در مورد زمان اجرای پروژه برنامه ریزی کرد و مدیریت. پروژه ساده تر و منظم تر است. در هر حال اگر زمان sprint ها یکسان نباشد بایستی در خلال جلسه برنامه ریزی sprintهر حتماْ مشخص مدت زمان آن sprint مشخص گردد.
http://blog.brianhartsock.com/2009/05/19/scrum-tip-sprint-length-is-a-variable/
تعیین زمان sprint براساس ملاک های مختلف مانند درصد تغییر نیازمندی ها٬ تعداد اعضاء تیم و ... انجام می شود. شاید تعیین زمان های کوتاه تر برای sprint ها چیز خوبی باشد چون باعث می شود تعداد جلسات ما با طرفین ذینفع پروژه و نمایندگان ها بیشتر شود و آنها بیشتر پیشرفت ها و موانع تیم را حس کنند و در واقع خودش را در داخل تیم حس کنند و سریعتر جلوی کجروی های تیم را بگیرند اما اگر این افراد گرفتار چندین پروژه باشد جمع کردن آنها ساده نیست و اغلب بخاطر زمان بری جلسات از آن فرار خواهند کرد. از طرف دیگر باید اذعان کرد که کوتاه مدت بودن sprint ها با افزایش انگیزه و تمرکز بیشتر اعضاء تیم می شود. یک نکته مثبت دیگری که در sprint های کوتاه مدت هست آن است که امکان برآورد بهتری از میزان کاری برعهده گرفتنی به تیم می دهد یعنی تیم زودتر می تواند بفهمد که سرعت و توانش چقدر است و در sprint ها بعدی برآورد دقیقتری از توان خودش در انجام نیازمندی ها و ویژگی ها مورد درخواست Product Owner پیدا می کند و به اندازه توانش کار می گیرد. البته بعضی ها هم گفته اند که اعضاء تیم بیشتر sprint های طولانی مدت را ترجیح می دهند چون زمان کافی برای رفع و رجوع کارهایشان دارند.
بهرحال تیم های کوچکتر معمولاْ سعی می کنند دوره های sprint کوتاه (بین یک الی دو هفته) داشته باشند و عین در حالی است که تیم های بزرگ بیشتر ترجیح می دهند که دوره های sprint طولانی تری داشته باشند (بین سه تا چهار هفته). عاقلانه این است که همیشه دوره زمانی sprint ها را بین ۲ الی ۴ هفته در نظر بگیریم و البته بصورت رسمی معمولاْ دوره زمانی sprint ها را یک ماه درنظر می گیرند.
یک بهروش برای این مسئله
سعی شود در یک دو sprint اول یک دید کلی از زمان مطلوب بدست آید و زمان sprint های بعدی بر اساس تجارب بدست آمده در یک دو sprint اول تغییر کند.
در هر دو حالت یعنی چه مدت sprint ها یکسان باشد و چه در هر جلسه برنامه ریزی sprint تعیین شود این زمان قطعی است (time boxed) یعنی حتماْ sprint باید در آن مدت خاتمه بیابد ولو اینکه به هداف خودش نائل نشده باشد.
شاید خیلی از ما از این تاکید زیادی که در اسکرام و سایر متدولوژی های Agile بر قطعی بودن زمان و به اصطلاح time boxed بودن آن هست قدری تعجب کنیم اما واقعیت این است که این طریقه برخورد در واقعی واکنشی بوده برای اجتناب از افتادن در ورطه تحلیل ها و تخمین های پیچیده و بسیار دور نگر. همه ما بیشتر این تمایل داریم که برای همه چیز پروژه از همان اول تحلیل کنیم و تخمین بزنیم در حالیکه این رویه با روح متدولوژی های Agile در تضاد کامل است و باعث پرت کاری زیاد و اتلاف وقت برای چیزهای بیخود در پروژه می رسد. تجربه نشان داده که قسمت قابل ملاحظه ای از آنچه که ما اکنون در سیستم وجودش را لازم می دانیم در خلال پروژه یا محو می شود یا کاملاْ تغییر شکل می یابد پس جرا باید وقتمان را برای تجسم و تحلیل چیزهای بسیار دور صرف کنیم. مقید کردن زمان جلسات و زمان sprint ها به ما این هشدار را میدهد که فقط در مورد مشکلات و مسائل جاریه فکر کنیم و کار کنیم.
برای اطلاعات بیشتر در مورد زمان بندی sprint ها به این منبع مراجع کنید:
Sprint Backlog
لیست کارهایی که طی یک Sprint انجام شود را اصطلاحاْ Sprint Backlog می نامیم.
Sprint Backlog در واقع ماحصل جلسه برنامه ریزی Sprint است که ابتدای هر sprint تشکیل می شود.
در این لیست نیازمندی ها و ویژگی ها را به وظیفه ها یا کارها (Tasks) شکسته می شود که معمولاْ هرکدام بین ۱۴ الی ۱۶ ساعت زمان می برند. با این سطح از جزئیات تمام اعضاء تیم می فهمند که دقیقاْ چه کاری را باید انجام دهند.
نکته مهم اینجاست که در اسکرام کار به کسی محول نمی شود بلکه این خود اعضاء تیم هستند که کارهایشان را از لیست گارهای sprint جاری برمی دارند و انجام می دهند. در واقع سطح جزئیات کار بحدی در Sprint Backlog مشخص شده که هر عضوی از تیم بصورت بالقوه می تواند یکی از کارهای باقی مانده در لیست را انتخاب کند و انجام دهد. انتخاب کارها بر عهده خود اعضاء تیم است و وی آنها را معمولاْ بر اساس اولویتشان و همینطور سطح مهارت های خودش انتخاب می کند. با این مکانیسم خصلت خود سازماندهی تیم ارتقاء می یابد.
Sprint Backlog از دارایی های تیم به شمار می آید. تمام تخمین هایی که بوسیله اعضاء تیم تهیه شده در آن لحاظ می شود. معمولاْ بهمراه این Backlog ٬ یک Task Board هم برای مشاهده و تغییر وضعیت کارهای sprint جاری استفاده می شود.
وضعیت یک کار (Task) می تواند یکی از سه حالت زیر باشد:
- بایستی انجام شود (TO DO)
- در حال پیشرفت (IN PROGRESS)
- انجام شده (DONE)
Product Backlog
معمولاْ نیازمندی های سطح بالای سیستمی که قرار است در جریان پروژه اسکرام تولید شود٬ در Product Backlog لیست می شود.
البته همیشه هم نیازمندی های سطح بالا مثل User Story ها و امثالهم نیست که در این مستند آورد می شوند. امکان دارد نیازمندی های تغییر یا refactoring در کد های برنامه ها در Product Backlog بیاید یا حتی ویژگی ها کوچکی که در برنامه باید لحاظ شوند بعنوان مثال :
Refactor the Login class to throw an exception
Allow undo on the setup screen
نیازمندی ها در این لیست دسته بندی شدند یعنی نیازمندی های با ارزش بالاتر در ابتدای لیست هستند و نیازمندی ها با ارزش پایین تر در انتهای لیست. بایستی در نظر داشت که وقتی صحبت از نیازمندی های میشود منظور هر دو نوع نیازمندی های عملیاتی و غیر عملیاتی است بعبارت دیگر هر ویژگی (Feature) و هر قالبیتی (functionality) که از سیستم تولیدی مورد انتظار است بایستی با احتساب اولویت در Product Backlog بیاید.
این لیست باز است و می تواند توسط هرکسی ویرایش شود اما در هر حال مسئول اصلی ایجاد و نگهداری این لیست شخص Product Owner است.
Product Owner مسئول محتوی Product Backlog ٬ اولویت بندی آن و دردسترس بودن آن است.
کی Product Backlog برای اولین بار درست میشود؟
قبل از این که پروژه شروع شود٬ در طی جلسه ای بنام Pre-project /Kickoff Meeting ٬ نسخه اولیه Product Backlog ایجاد می شود٬ موارد مشخص شده در آن اولیت بندی می شوند و زمان انجام آنها نیز تخمین زده می شود.
Product Backlog هیچ وقت کامل نمی شود. تا زمانی که پروژه وجود دارد Product Backlog آن پابرجاست و آن Product Backlog ی که برای استخراج برنامه پروژه (Project Plan) استفاده می شود٬ تنها تخمین اولیه ای از نیازمندی های سیستم ست.این لیست می تواند تخمینی نه چندان دقیق از ارزش کاری ویژگی های سیستم و وقت و هزینه ای که باید صرف تحقق و پیاده سازی آنها شود به افراد درگیر در پروژه ارائه کند و این تخمین ها به Product Owner کمک می کند که time line های لازمه را اندازه گیری نماید.
در Product Backlog نیازمندی ها بر اساس sprint ها و release ها گروه بندی می شوند. امکان دارد یک نیازمندی در دو یا چند Sprint مختلف تکرار شود.
نحوه اولویت بندی در Product Backlog
اولویت بندی اقلام مشخص شده در Backlog براساس توافقی که Product Owner با طرفین ذینفع در پروژه انجام می دهد مشخص می شود و امکان دارد که بر اساس بروز نیاز های کاری جدید لیست نیازمندی های Backlog مجدداْ اولویت بندی بشود. در اولویت بندی ویژگی ها هر دو عامل ارزش کاری business value و میزان تلاش و کاری که برای پیاده سازی آن باید صرف شود (Development Effort) لحاظ می شود.
یعنی اگر ویژگی A و ویژگی B هر دو از لحاظ ارزش کاری در یک سطح باشند٬ ویژگی که بار پیاده سازی کمتری دارد دارای اولویت بالاتری خواهد بود چرا که بازگشت سرمایه (ROI) آن بیشتر است.
ولویت یک نیازمندی بر اساس میزان ریسک٬در پیاده سازی آن٬ ارزش و اهمیت آن و درجه نیاز به آن استخراج می شود. تکنیک های زیادی برای ارزیابی این ویژگی ها وجود دارد.
نیازمندی ها با اولیت بالاتر شفاف تر و واضح تر هستند و نسبت به نیازمندی های با اولویت پایین تر دارای جزئیات بیشتری در Product Backlog هستند
Product Backlog شامل چه اطلاعاتی است؟
همانطور که اشاره شد این Backlog شامل لیست مرتب شده برای نیازمندی های مختلف سیستم مورد انتظار است. انیکه چه چیزهایی برای هر کدام از این نیازمندی ها ذکر می شود البته بستگی به سلیقهُ نظر و نیازمندی های افراد درگیر در پروژه دارد. در اینجا یک سری از اطلاعاتی که امکان دارد برای نیازمندی ها ذکر شود شرح داده می شود
- شناسه(ID): معمولاْ به هر نیازمندی که در اکثر موارد User Story ها هستند یک عدد بعنوان شناسه منحصر بفرد داده می شود
- نام یا عنوان: یک عنوان که بطور خلاصه ماهیت نیازمندی کارفرما را مشخص می کند. بایستی در عین کوتاه بودن و موجر بودن٬ مفهوم و رسا باشد.
- دسته (Category) یا اجزاء (Component) یا حوزه عملیاتی (Functional Area): (اختیاری) مشخص می کند که این نیازمندی تحت چه دسته ای از دید کاربر نیازمندی ها قرار می گیرد. مثلاْ برای مدیریت کاربران است٬ برای جستجو است و .... یک معیار دیگر برای دسته بندی نیازمندی آن است که در مورد چه جزء یا عنصری از سیستم است (Component) مثلاْ در مورد مدیریت سبد خرید کالاست (در سیستم ها خرید الکترونیکی)
- نوع (Type): (اختیاری) مشخص می کند که این سطر یا این قلم از Backlog چه جور چیزی است: ویژگی است٬ User Story است٬ بهینه سازی است یا ....
- شرح (Description or Summary): توضیح مختصری در مورد نیازمندی. در مورد نیازمندهای عملیاتی شرح داستان کاربر (User Story) است. در مورد User Story احتمالاْ در فرصت مناسب دیگری به تفصیل صحبت خواهیم کرد فقط باید این الگو را در مورد User Story ها در ذهن داشته باشید: به عنوان XXX من می خواهم YYY را به انجام دهم بگونه ای که ZZZ .(در راهکار Test Driven Development این فیلد زیر مورد استفاده قرار می گیرد)
As a [User Role], I want [goal/desire] so that [benefit]
As a customer representative,
I want to search for my customers by their first and last name.
همچنان که در بالا اشاره شد فقط User Story ها نیستند که در product backlog می آیند. امکان نیازمندی های غیر عملیاتی٬ ویژگی ها فنی و ... هم در این لیست لحاظ شوند.جهت توضیحات بیشتر می توانید به منابع زیر مراجعه کنید:
http://www.agilemodeling.com/artifacts/userStory.htm
http://www.userstories.com
- نظرات و نکات (Comments): در این فیلد توضیحات اضافه ای در مورد نحوه پیاده سازی این نیازمندی ذکر می شود.
- اهمیت(Rank): در بعضی از منابع از این فیلد در Backlog ها استفاده شده. به هر حال این فیلد بصورت ضمنی در دل هر Product Backlog ی هست و در واقع نیازمندی ها بر اساس این فیلد است که مرتب می شوند. آوردن آن در پیاده سازی Product Backlog ها ضروری است و همینطور تغییر آن اما این که نمایش داده شود کلاْ تاثیر چندانی ندارد چون بهرحال نیازمندی ها بر اساس آن در Product Backlog مرتب می شوند. البته امکان دارد که اولویت تحقق یک نیازمندی الزاماْ منطبق بر اهمیت آن نباشد و شاید در این حالت نشان دادن آن به استفاده کننده مفید باشد. دو روش برای مشخص کردن اهمیت مسائل وجود دارد استفاده از عدد و رقم یا استفاده از اصطلاحات فازی نظیر با اهمیت٬ کم اهمیت٬ با اهمیت متوسط و نظایر آنها.
سایر اصطلاحات مشابه برای این فیلد: Defect Type و Severity
فیلد هایی که در زیر اشاره می شوند فیلد های هستند که منحصراْ در مدیریت پروژه اهمیت دارند.
- تخمین یا برآورد اولیه (Initial Estimate or Original Estimate):
برای هر نیازمندی ما نیاز داریم که زمان و منبع انسانی که صرف آن می شود را به شکل تخمینی مشخص کنیم مثلاْ بگوییم دو نفر ساعت. (MAN-DAY UNIT OR STORY-POINT UNIT)
بعنوان مثال اعضاء تیم می گویند برای انجام این داستان از نیازمندی سیستم ما سه نفر در بهترین حالت ۴ ساعت باید وقت صرف کنیم با توجه به گفته اینها شما بعنوان Product Owner تخمین اولیه این نیازمندی را ۱۲ نفر ساعت وارد می کنید.
توجه: تخمین ها بر اساس نظرات تیم محاسبه می شوند.
فیلد هایی که در ادامه می آیند کاملاْ اختیاری هستند.
- ضریب پیچیدگی (Complexity Factor):
این ضریب٬ تخمین را بر اساس خصوصیات پروژه که بهره وری تیم را پایین می آورد افزایش می یابد. یعنی هر چه مسئله ای مشکل باشد باعث می شود که زمان تخمین زده شده برای آن افزایش یابد و بعبارت دیگر باعث کم شدن میزان بهره وری تیم (بر اساس معیار زمان مصرف شده برای حل مسئله) می شود.
در بعضی از منابع به این فیلد بعنوان اندازه یا حجم مسئله (size) هم در Product Backlog مشخص شده است.
- تخمین تطبیق داده شده (Adjusted Estimate):
بعد از تحقق یک نیازمندی توسط تیم٬ نفر- ساعت صرف شده برای آن در این فیلد وارد می شود.
- تخمین نفر- ساعت برای تحقق نیازمندی در sprint های مختلف:
به ازای هر sprint یک فیلد نفر ساعت برای نیازمندی در نظر گرفته می شود که مشخص می کند در آن sprint چند نفر ساعت بایستی صرف تحقق آن نیازمندی شود. بدیهی است که اگر یک نیازمندی در یک sprint محقق شود فقط یکی از این نفر ساعت غیر صفر خواهند بود و مابقی صفر. اما در حالتی که یک نیازمندی در یک sprint محقق نشود و تحقق آن در sprint های بعدی هم ادامه داشته باشد در آن صورت چند تا از این نفر- ساعت ها غیر صفر خواهند بود.
- وضعیت (Status)
وضعیت انجام تحقق میازمندی. در ساده ترین حالت: آیا نیازمندی انجام شده یا خیر(Accomplished?) اسم فیلد خود گویا ماهیت و کارکرد آن است. در موارد محیط های تولید نرم افزار توسعه یافته تر که مثلاْ از Jira یا امثالهم استفاده می کنند. فیلد وضعیت مقادیری زیر را دارد: شروع نشده (Not Started)٬در حال انجام (Started)٬ خاتمه یافته (Completed)٬ در حال استفرار (Deploy) و ...
در بعضی از ارگانها در کنار این فیلد٬ درصد انجام کار را هم مشخص می کنند.
- تیم انجام دهنده(Assignee Team): اگر چند تیم درگیر در پروژه باشند اسم تیم که تحقق نیازمندی به آن محول شده بعنوان یک فیلد مستقل ذکر می شود.
- تاریخ و زمان تکمیل یا انجام نیازمندی (Done): در چه تاریخ و زمانی این نیازمندی بر اساس معیار ها مشخص شده انجام شده است. ( در مورد معیار های انجام شدن یا تکمیل شدن نیازمندی ها بعد اْ مفصلاْ صحبت خواهیم کرد)
- دوره (Sprint): مشخص می کند که در چه sprint یا sprint هایی روی این نیازمندی کار شده است. همانطور که اشاره شد از این فیلد برای دسته بندی نیازمندی ها در Product Backlog استفاده می شود.
- نسخه انتشار (Release or Version): مشخص می کند که در release ی از برنامه این نیازمندی محقق شده است. بازهم همانطور که اشاره شده از این فیلد برای دسته بندی نیازمندی ها در Product Backlog استفاده می شود.
- منشاء (Source) یا درخواست کننده: مشخص می کند چه کسی یا کسانی خواهان این نیازمندی شود. این بخصوص زمانی مفید است که Product Owner یا یکی اعضاء تیم خواهان دریافت جزئیات بیشتر در مورد آن نیازمندی و نظرات آنها هستند.
l
نیازمندی های Product Backlog از کجا استخراج می شوند
مواردی که در Product Backlog می آیند بیشتر از حوزه کسب و کار استخراج می شوند(Business Driven) تا از حوزه فن آوری (Technology). معمولاْ این منابع برای استخراج نیازمندی ها٬ ویژگی ها و ... که در Product Backlog لیست می شوند مورد استفاده قرار می گیرند
۱- برنامه کسب و کار Business Plan
۲- اعلامیه یا صورتجلسه چشم انداز سیستم Vision Statement
۳ - بازخورد مشتری از سیستم Customer Feedback
۴ - بازخورد های داخلی از سرویس مشتریان (Client services)٬ واحد فروش یا واحد پشتیبانی مشتریان
۵ - تحلیل بازار
۶ - پیشنهاد هایی که در جهت بهبود فرآیند مطرح شده است.
بطور کلی هر چیزی در کسب و کار که از منابع تیم مصرف خواهد کرد بایستی در Product Backlog ذکر شود
البته غیر از اینها معمولاْ مواردی هم هست که از طرف تیم تولید و توسعه نرم افزار مطرح می شود یا حتی Product Owner با توجه به شناختی که از مسائل فنی دارد موارد فنی را در Product Backlog مطرح می کند ولی باید همیشه بخاطر داشت که این پیشنهادات و موارد بایستی با زبان کسب و کار در Product Backlog منعکس شود تا ارزش خود را روشن کند. بعنوان مثال اگر اعضاء تیم یا Product Owner خواهان گنجاندن موردی مانند استفاده از بانک اطلاعاتی X بجای Y برای نگهداری اطلاعات مشتریان بودند. بایستی نیازمندی آنها را به این شکل در Product Owner برگرداند. برای کاربر سیستم مهم است که اطلاعات مشتری سریعاْ قابل جستجو و بازیابی باشند.
بعنوان مثال نمونه دیگر نیازمندی که از طرف تیم ابراز شده است:
Re-factor the code to eliminate duplicate code and increase maintainability
این نیازمندی از طرف تیم توسط Product Owner به این صورت در Product Backlog ثبت می شود و اولویت دهی می شود:
Eliminate Refresh Inconsistencies By Using the Same Code Base.
از چه ابزار هایی برای نگهداری Product Backlog استفاده می شود
معمولاْ از Spreed sheet ها برای نگهداری اطلاعات Product Backlog استفاده می شود. ولی می توان White-board ٬ کاغذ های Post-it و لیست های کاغذی هم برای پیگیری Product Backlog استفاده کرد.
ابزارهای تخصصی نیز برای این نگهداری Product Backlog وجود دارد:
ابزاری که برای نگهداری Product Backlog استفاده می شود بایستی توسط Scrum Master و Product Onwer و با مشورت از اعضاء تیم انتخاب شود.
چه زمانی مندرجات Product Backlog تغییر می کند و دوباره اولیت بندی می شود؟
معمولاْ در جلسات برنامه ریزی دوره ای مندرجات Backlog بر اساس نیازمندی های جدید مجدداْ اولویت بندی می شود و چه بسا که اولویت بسیاری از نیازمندی ها تغییر کند. اما از یک طرف مواردی که در Product Backlog مورد انتخاب تیم قرار می گیرند و در Sprint Backlog تیم ثبت می شود تا پایان دوره sprint در Product Backlog قابل تغییر نیستند.
اما چرا این تغییرات در Product Backlog صورت می گیرد شاید یکی از دلایل آن این باشد که Product Owner می خواهد آنچه که در Product Backlog آمد با آنچه که تیم در واقع پیاده سازی کرده نزدیک شود. توصیف اولیه نیازمندی ها در Backlog اغلب گنگ و مبهم و فاقد جزئیات است و تخمین هایش چندان دقیق نیست اما هرچه که به پیش می رویم لازم است که نیازمندی ها نادقیق اشاره شده در Product Backlog با یک یا چند نیازمندی دقیق جایگزین شود و تخمین زمانی بر اساس نیازمندی ها جدید صورت بگیرد
بعد از ختم یک sprint هم تغییراتی در Product Backlog بوجود می آید. امکان دارد بعضی از نیازمندی های برعهده تیم در طول sprint تحقق نیابد و در این حالت ها٬ این نیازمندی ها مجدداٌ به Product Backlog بر می گردند و فعال می شوند.
نکته مهم این است که درک کنیم آنچه که در Product Backlog لیست می شود. وظیفه یا Task نیست.برای توضیحات بیشتر به منابع زیر مراجعه کنید:
همانطور که قبلاْ هم اشاره شد اسکرام تمام بهروش هایی (Best Practices) هایی که در اسمل فرآیند های افزایشی Incremental و تکراری iterative هست را در خود جمع کرده است.شکل زیر اسکلت فرآیند اسکرام را نمایش می دهد.
اسکرام برای اینکه بتواند متدولوژی کاملی باشد از هر دو بهروش استفاده کرده است . Sprint های یک پروژه همان Iteration های ما می باشند و انجام دادن قابلیت های مورد اشاره در نیازمندی های هر دوره بصورت Incremental خواهند بود . به عبارت سادتر در داخل یک Iteration که همان Sprint است ما شاهد فرآیندی Incremental خواهیم بود.
جلسه شروع پروژه Pre-project/Kickoff Meeting
هر پروژه اسکرام با بوجود آوردن یک دید یا چشم انداز (Vision) از سیستم که بایستی تولید شود شروع می شود. این Vision در ابتدا امکان دارد کمی ابهام داشته باشد٬ شاید بخاطر اینکه مستندات آن بر اساس عبارات و اصطلاحات بازار تنظیم می شود و نه براساس عبارات و اصطلاحات سیستم اما به مرور که پروژه جلو می رود این Vision هم شفافتر می شود.
در اسکرام مسئولیت تولید این Vision بر عهده شخص Product Owner است و او باید مستندات Vision را به گونه ای تهیه کند که حداکثر بازگشت سرمایه ROI را نصیب سرمایه گزاران در پروژه شود. طرحی که وی برای انجام چنین ماموریتی فراهم می کند در واقع دربردارنده Product Backlog است.
جلسه برنامه ریزی نسخه جدید Release Planning Meeting
منظور از این جلسه ایجاد برنامه و مشخص نمون اهداف پروژه است. اهدافی که اعضاء تیم و سایر طرفین درگیر باید آنها را درک کنند و برپایه آنها با هم ارتباط برقرار کنند.
برنامه ریزی نسخه جدید باید به این سئوالات جواب دهد:
چگونه می توان Vision را به یک محصول موفق در بهترین روش برگرداند؟
چگونه می تواند رضایت مشتری مورد نظر و بازگشت سرمایه را برآورده کرد؟
برنامه انتشار نسخه جدید(Release Plan) باید:
۱- اهداف نسخه جدید را مشخص کند
۲ - موارد پر اولویت Product Backlog را معین کند٬ بگونه ای که خطرات عمده و جمیع ویژگی ها و قابلیت ها در آن لحاظ شده باشد.
۳ - تاریخ احتمالی تحمیل و هزینه احتمالی را مشخص کند.
بعد از استخراج این سند٬ سازمان مربوطه می تواند بطور مستمر بازرسی و وارسی کند و Sprint به Sprint تغییراتی را در این برنامه ایجاد کند.
بهرحال کل این جلسه و فرآیند اختیاری است و می توان از آن صرفنظر کرد و کارهای مربوط به آن را کم کم در خلال جلسات برنامه ریزی دوره Sprint Planning Meeting انجام داد.
همانطور که قبلاْ هم گفته شد Product Backlog لیستی از نیازمندی های عملیاتی function requirements و غیر عملیاتی Non functional requirement است و اگر این نیازمندی ها در اجرای پروژه به عنوان قابلیت سیستم محقق شوند٬ آنچه را که در Vision گفته شده٬ تحویل داده می شود. آنچه که در Product Backlog می آید به گونه اولیت بندی و مرتب می شوند که نیازمندی های واجد ارزش بالاتر در بالاترین اولویت باشند. این نیازمندی ها در Product Backlog بین نسخه های پیشنهادی مختلف تقسیم می شوند. محتویات Product Backlog و اولویت بندی آنها وحی منزل نیستند و می توانند در خلال پروژه تغییر کنند و تغییر آنها منعکس کننده تغییر در نیازمندی های کاری Business Requirements پروژه است و در عین حال مشخص می کند که اعضاء تیم چگونه و با چه سرعتی مندرجات Product Backlog را به قابلیت های سیستمی تبدیل کردند.
تمام کارها در sprint ها انجام می شود
اجرای پروژه به دوره های زمانی مشخص و مساوی بنام sprint تقسیم می شوند که بعبارت دیگر همان iteration ها هستند.
در طی هر sprint یک یا چند قابلیت جدید که در Product Backlog آمده به سیستم در حال تولید اضافه می شوند. خروجی هر sprint اصطلاحاْ یک incremental of Product نامیده می شود.. ملاک پیاده سازی این نیازمندی ها و قابلیت ها٬ اولویت آنها در Product Backlog است که توسط Product Owner و با مشاوره با ذینفعان تعیین می شود. حلقه بزرگ پایینی شکل بالا هم یکی از این sprint ها را نمایش می دهد و این این حلقه بارها و بارها تکرار می شود تا پروژه به ثمر برسد.
اما در طی همین ۳۰ روز دوره یک sprint ما حلقه های دوره های کوچکتری داریم(حلقه کوچک بالایی نمایانگر این دوره هاست) که بیانگر Daily Inspection نامیده می شوند. این یعنی که در طی یک sprint ما هر روز یک جلسه داخلی درون تیم پیاده سازی داریم که در آن اعضاء تیم هم فعالیت های همدیگر را مورد ارزیابی قرار می دهندو با هم هماهنگ می شوند و هم اینکه مشکلاتشان را با Scrum Master مطرح می کنند و Scrum Master مشکلات آنها را رفع می کند. در این جلسه البته Product Owner یا حضور ندارد یا نمی تواند دخالتی در روند جلسه داشته باشد. به این جلسات داخلی اصطلاحاْ Daily Stand Up می گوییم.
این دوره های یک روزه در واقع فرصت خوبی برای خود ارزیابی کردن اعضاء تیم است٬ اینکه در چه چالش هایی درگیر هستند و چه پیچیدگی ها و سختی و موارد غیر منتظره ای برخورد کرده اند همه و همه به کل اعضاء تیم کمک می کند که راهش را تصحیح کنند و بهترین راه ها را برگزینند. این فرآیند سازنده قلب بازدهی اسکرام است.
توجه: در خلال sprint هیچکس حق ندارد نیازمندی جدیدی به تیم ابلاغ کند و در واقع آنچه که به تیم ابلاغ شده تا پایان دوره sprint غیر قابل تغییر است.
جلسه برنامه ریزی دوره Sprint Planning Meeting
در ابتدای هر دوره٬ اعضاء تیم آنچه را که باید در این دوره sprint انجام دهند را مرور می کنند. سپس آنچه را که فکر می کنند می توانند در آخر دوره بعنوان یک محصول باقوه قابل ارائه تحویل دهند را انتخاب می کنند و به Product Owner اعلام می کنند. این در واقع همان چیزی است که تحت عنوان Sprint Backlog شناخته می شود.به جلسه ای که در خلال آن این تصمیم گیری ها انجام می شود جلسه برنامه ریزی دوره یا Sprint planning Meeting گفته می شود و در واقعی جایی است که Product Owner و اعضاء تیم با هم بر انچه که باید در طی sprint انجام شود توافق می کنند.Product Owner نیازمندی های پر اولویت باقی مانده در Product Backlog را انتخاب می کند و به تیم اعلام می کند که انتظاراتی در مورد آنها دارد و تیم هم به وی اعلام می کند که چه مقدار از انتظارات وی را در طی این sprint می توانند برآورده کنند.
این جلسه نمی تواند بیش از هشت ساعت طول بکشد.
هدف از محدود کردن زمان این جلسه جلوگیری از بوجود آمدن دست نوشته هایی است که امکان دارد توسط حضار در جلسه بوجود بیایند. هدف در اینجا گرفتن کار است نه اندیشیدن در مورد کار.
این جلسه شامل دو بخش است:
چهار ساعت اول: Team + Product Owner : دیالوگ برای اولویت بندی Product Backlog
در چهار ساعت اول٬ Product Owner با اولویت ترین نیازمندی های مد نظر وی در Product Backlog را به تیم ارائه می کند. و اعضاء تیم از وی در مورد محتوا٬ هدف٬ معنی و مقصود نیازمندی های Product Backlog سئوالاتی را می پرسند.
چهار ساعت دوم: فقط اعضاء تیم: استخراج برنامه انجام نیازمندی ها و گذاشتن آن در Sprint Backlog
در چهار ساعت دوم و بعد از اینکه اعضاء تیم به حد کافی از آنچه باید انجام بدهند آگاه شدند٬ Product Owner آنها را به حال خود می گذارد تا خودشان بهترین کاری را که می توانند در بقیه دوره زمانی sprint انجام دهند را تصمیم گیری نماید. اینجاست که اعضاء تیم خودشان مسئول مدیریت کارهای خودشان می شوند و احتیاج پیدا می کنند که برنامه ای برای شروع انجام کارها در Sprint تهیه کنند و وظایف خودشان را در آن مشخص کنند. وظایف Tasks هایی که در این برنامه مشخص می شوند در Sprint Backlog گذاشته می شوند. در واقع ماحصل بخش دوم جلسه برنامه ریزی دوره Sprint Backlog است.
در پایان این جلسه تیم به Product Owner متعهد می شود که هرآنچه که می تواند به بهتر روش انجام دهد. اما از آغاز چهار ساعت دوم جلسه برنامه ریزی دوره٬ در واقع sprint شروع شده است.
خط مشی های کلی این جلسه:
۱- انتخاب اینکه چکاری باید در این دوره انجام شود.
۲ - آماده کردن Sprint Backlog بگونه ای که جزپیات زمانی که بایستی صرف کارها و وظایف تیم شود باکمک اعضاء تیم درآورده شده باشد.
۳- شناسایی و اعلام حجم کاری که احتمالاْ در این Sprint انجام می شود به Product Owner.
۴- حداکثر هشت ساعت باید وقت بگیرد.
۵- حضور Product Owner در چهار ساعت اول جلسه الزامی است.( اگر وی به هر علتی نتواند در جلسه حضور بیابد این وظیفه اعضاء تیم است که خودشان یکنفر از خودشان را انتخاب کنند و بعنوان نماینده Product Owner جانشین وی نمایند و البته این انتخاب را باید به اطلاع و تایید Product Owner هم برسانند و شخص انتخاب . همچنین می توان از مدیریت پروژه درخواست نمود تا شخص دیگری را جانشین دائم یا موقت Product Owner فعلی نمایند.)
خروجی این جلسه:
۱- مشخصات کلی محصول نهایی که در این sprint تولید خواهد شد.( در واقع هدف sprint که مشخصاْ از طرف Product Owner بیان می شود.)
۲- فهرست افراد تیم و سطح مشارکت و مسئولیت آنها
۳ - فرآورده Sprint Backlog که در مطالب بعدی توضیح داده می شود.
۴ - تعیین تاریخ ارائه محصول نهایی این دوره به Product Owner و طرفهای ذینفع در پروژه. ( برآورد زمانی برای ارائه محصول و حجم کاری که انجام می شود از وظایف اعضاء تیم است.)
۵- زمان و محل برگزاری جلسات روزانه Daily Stand up که در ادامه توضیح داده خواهد شد.
نکات دیگر:
- طبیعی است که هر چه اعضاء تیم زیاد تر باشند برنامه ریزی sprint سخت تر می شود.
جلسات روزانه اسکرام Scrum Daiiy meetings
به این جلسه٬ جلسه وضعیت پروژه یا Project Status Meeting و Daily Stand-up هم گفته می شود.
هر روز اعضاء تیم با هم جلسه ای پانزده دقیقه ای را تشکیل می دهند که اصطلاحاْ Daily Scrum meeting نامیده می شوند. در این جلسه هر کدام از اعضاء تیم به سه سئوال زیر جواب می دهد:
۱ - از آخرین جلسه روزانه اسکرام تا الان چه کاری بر روی پروژه انجام داده است؟
۲ - قصد دارد بین این جلسه و جلسه روزانه بعدی چه کاری روی پروژه انجام دهد؟
۳ - چه موانع و مشکلاتی در مورد نایل شدن به تعهدات وی در این sprint و این پروژه وجود دارد؟ وظیفه Scrum Master حل این مشکلات است.
هدف از تشکیل این جلسه هماهنگ نمودن کار همه اعضاء تیم بصورت روزانه است و همینطور زمانبندی برای هر جلسه دیگری که تیم برای پیشبرد کارش نیاز دارد.
خط مشی های این جلسه عبارتند از:
۱- جلسه دقیقاْ سر وقت باید شروع شود
۲- از حضور همه افراد در جلسه استقبال می شود ولی فقط افرادی که عضو گروه خوک ها Pigs هستند حق صحبت دارند
۳- جلسه بیشتر از پانزده دقیقه نباید طول بکشد.
۴ - جلسه باید همیشه در یک مکان و یک زمان تشکیل شود.
جلسه بازبینی دوره Sprint review meeting
در انتهای دوره٬ تیم یک نسخه جدید از سیستم را تحویل به گونه ای تحویل می دهد که ذینفعان پروژه بتوانند هم قابلیت ها اضاقه شده جدید را بررسی کنند و همین اینکه باتوجه به کارهای انجام شده و زمان صرف شده برای آنهاُ بتوانند تاریخ و زمان جدیدتری برای انجام کل پروژه تخمین بزنند. بخاطر همین موضوع جلسه بازبینی دوره در انتهای دوره تشکیل می شود.
این جلسه بایستی در چهار ساعت به اتمام برسد و در آن اعضاء تیم آنچه را که در خلال sprint تولید کرده اند و توسعه دادند را به Product Owner و هر کدام از ذینفعان (Stakeholders) پروژه که در جلسه حضور داشته باشند ارائه می کنند.
هدف از تشکیل این نشست غیر رسمی که در آن قابلیت های جدیداْ افزوده شده به سیستم ارائه می شود٬ گرد هم آوردن افراد و کمک به آنها برای مشارکت در شناسایی آن چیزی است که بعداْ اعضاء تیم بایستی انجام دهند.
خط مشی های کلی این جلسه:
۱ - بازبینی و بررسی کارهایی که در خلال این sprint تکمیل شده اند و آنهایی که تکمیل نشده اند.
۲ - فقط کارهای تکمیل شده به ذینفعان پروژه ارائه باید شوند ( به عبارت دیگر برگزاری Demo نسخه تکمیل شده سیستم)
۳ - کارهای تکمیل نشده نبایستی نمایش داده شوند
۴- حداکثر بایستی چهار ساعت طول بکشد.
Sprint Retrospective Meeting
بعد از جلسه بازبینی دوره و قبل از جلسه برنامه ریزی دوره بعد٬ Scrum Master جلسه ای با اعضاء تیم تشکیل می دهد که Sprint Retrospective Meeting نامیده می شود.
این جلسه بایستی در سه ساعت به پایان برسد و هدف آن تشویق اعضاء تیم به تجدید نظر در کارهایشان در چارچوب فرآیند اسکرام و روشهایش استُ بطوریکه در sprint بعدی فرآیند تولید و توسعه موثر تر و بانشاط تر شود.
خطی مشی های کلی این جلسه عبارتند از:
۱ - همه اعضاء تیم نظرشان را در مورد آنچه که در sprint قبلی اتفاق افتاده بیان می کنند.
۲ - نظرات و طرح ها مطرح شده در جلسه بایستی در جهت بهبود پیوسته فرآیند تولید نرم افزار باشد.
۳ - دو سه زیر از طرف Scrum Master از تیم پرسیده می شود: چه چیز هایی در طول sprint بخوبی گذشت؟ چه چیز هایی می تواند در sprint بعدی بهتر شود؟
۴ - حداکثر مدت این جلسه باید سه ساعت باشد.
در مجموع جلساتی که داریم یعنی Sprint Planning Meeting ٬ Daily Scrum Meeting ٬ Sprint Review Meeting و Sprint Retrospective Meeting روش های تطبیق و بررسی تجربی هستند که اسکرام را تشکیل می دهند
اینکه چطور این اسامی برای گروه بندی نقش ها درست شده به یک داستان قدیمی بچگانه برمی گردد. اما در واقع خوک ها (Pigs) متعهد به ساختن منظم و متناوب نرم افزار هستند و هر کسی بغیر از آنها جوجه (Chicken) است٬ یعنی افرادی که علاقمند به پروژه هستند ولی در عمل بیتفاوت هستند چرا اگر پروژه با شکت مواجه شوپد آنها مسئولیتی و تعهدی ندارند.
این دسته بندی در اسکرام مهم است و در واقع به تاکید اسکرام در مورد
شفافیت کل فرآیند پروژه بر می گردد. در اسکرام مهم است که چه کسی مسئول بازگشت سرمایه ROI = Return of Investment است و چه کسی در ROI سهم دارد ولی در کار بحساب نمی آید.
در واقع این نیازها٬ تمایلات٬ ایده ها و ایده های جوجه هاست که در پروژه بحساب می آید اما به هر حال به آنها حق دخالت متقیم در پروژه داده نمی شود.
اما فارغ از این دسته بندی سطح بالایی که اشاره شد یک سری دسته بندی ها سطح پایین تر از نقش افراد در پروژه نیز وجود دارد که در اینجا توضیح داده می شود.
اول - Scrum Master یا استاد اسکرام
وظیفه اصلی وی رفع مشکلات تیم است. مشکلاتی که مانع از بروز قابلیت های تیم در جهت تحویل محصول نهایی sprint می شوند. اما بیاد داشته باشیم که scrum master رهبر تیم نیست چرا که در قاموس متدولوژی اسکرام خود تیم ماهیت خود سازماندهی دارد و در واقع این شخص نقش میانجی را برای این منظور بازی می کند. نقش عمده وی در این زمینه اطمینان حاصل کردن از اجرای درست فرآیند اسکرام و محافظت از تیم است.
The Scrum Master is the "pig" of the Scrum Process.
از دید کن شوابر این شخص دارای مسئولیت های زیر می باشد:
۱- راهبری خود فرآیند اسکرام در تیم
۲- آموزش اسکرام به هرکسی که درگیر پروژه است
۳- محقق ساختن فرآیند اسکرام بر اساس شرایط و فرهنگ سازمان مجری پروژه
۴- ارائه منافع حاصله از بکار بردن اسکرام
۵- اطمینان از اینکه هر کسی قوانین و روش های اسکرام را بدرستی دنبال می کند
یکی از نکات مهمی که دراسکرام بر روی آن تاکید می شود تقویت روحیه همکاری یا بعبارت دیگر cross-functional است. در جلسات روزانه تیم که در خلال یک sprint برگزار می شود این وظیفه Scrum Master است که مشکل تک تک اعضاء تیم را تشخیص بدهد و از سایر اعضاء تیم برای حل مشکلات و کندی ها اعضاء مشکل دار کمک بگیرد. مثلاْ اگر در طی جلسه روزانه یکی از اعضاء تیم عنوان کرد که نمی تواند کاری را که بر عهده گرفته است در موعد مقرر (یعنی انتهای sprint) به انجام برساند این وظیفه Scrum Master است که از سایر اعضاء تیم که وقت آزاد بیشتری دارند یا سرعت کارشان بیشتر است دعوت کند که به این فرد کمک کنند.
توجه: Scrum Master می تواند یکی از اعضاء تیم باشد هر چند که داشتن این نقش مضاعف امکان دارد باعث شود که وی در ایفای یکی از وظایف خود یعنی رفع موانع بقیه اعضاء تیم بعنوان Scrum Master دچار مشکل شود اما بهرحال هیچ وقت نمی تواند Product Owner باشد.
دوم - Product Owner یا صاحب محصول
این شخص در واقع نماینده مشتری است . همیشه باید مطمئن شود که تیم دید درستی از منظر کاری(Business Par) پروژه کار می کند و در مسیر درستی پیش می رود
The Product Owner is the "pig" of Product Backlog.
تعریف کن شوابر:این شخص مسئول ارائه علائق و تمایلات هر کسی است که در پروژه و سیستم منتج از آن نفعی دارد.
در واقع این شخص است که نیازمندی های مورد دغدغه مشتری Customer Critic را جمع آوری می کند ( توعاْ بصورت User Story ها)٬ آنها را اولویت بندی می کند و نهایتاْ در Product Backlog می گذارد. Product Backlog همانطور که قبلاْ هم اشاره شده چیزی جز لیست نیازمندی نیست.
تعریف کن شوابر:این شخص مسئول استفاده از Product Backlog است تا مطمئن شود که با ارزش ترین قابلیت ها در اولین فرصت تولید می شوند و این مقصود با اولیت بندی پی درپی موارد مشخص شده در Product Backlog در هر sprint محقق می شود.
برای هر Product Backlog باید یک Product Owner وجود داشته باشد بعبارت دیگر به ازای هر محصول باید ما یک Product Owner داشته باشیم.
Product Owner می تواند عضوی از تیم باشد ولی نمی تواند Scrum Master تیم هم باشد. البته این نقش یک (در صورتی که تواماْ عضوی از تیم پروژه نباشد) ماهیت دوگانه هم دارد چرا که در طول جلسات روزانه تیم که اصطلاحاْ Stand Up Session نامیده می شود کلاْ نقش جوجه را بازی می کند و عملاْ هیچ نقشی در پیاده سازی وظایف اشاره شده در Sprint ها ندارد.
در محیط های تولید تجاری این شخص می تواند Product Manager باشد ولی در محیط های که محصول استفاده داخلی برای سازمان یا شرکتی دارد Product Owner می تواند مدیر Business Function ی باشد که قرار است اتوماتیزه شود.
Product Owner یک شخص است نه کمیته ای متشکل از اشخاص البته ممکن است کمیته هایی برای دادن مشورت به این شخص یا تحت تاثیر قرار دادن وی وجود داشته باشند ولی خودشان نمی توانند راساْ در تغییر Product Backlog نقشی داشته باشند و برای این منظور باید Product Owner را متقاعد نمایند. برای موفق بودن این شخص در کارش باید تمام اعضاء سازمان به تصمیم گیری های وی احترام بگذارند. هیچ کس بغیر از وی حق ندارد اولویت های کاری تیم را تغییر دهد.
سوم - Team
و نهایتاْ خود تیم که محصول تحویل محصول است و معمولاْ از ۹ الی ۱۵ نفر تشکیل می شود(تعداد نفرات بهینه برای تیم ۷ نفر است نهایت دو نفر این طرفتر یا آن طرفتر).
اگر تعداد اعضاء تیم از ۵ نفر کمتر باشد تعامل افراد باهم کمتر می شود و در نتیجه بهره وری کاهش می یابد. علاوه بر اینها امکان دارد که در خلال کار تیم نیاز به تخصصی داشته باشد و قادر به تحویل بخشی از کار نشود.
اگر تعداد نفرات از نه نفر بیشتر شود هماهنگ کردن و مدیریت افراد سخت می شود.
البته اینها وحی منزل نیستند و تیم هایی بودند که با تعداد نفرات کمتر از پنج نفر یا بیشتر از نه نفر بخوبی نتیجه داده اند.
باید در نظر داشت که Product Owner و Scrum Master در این تعداد نمی گنجند و اعداد داشته در مورد اعضاء تیم بغیر از این دو نفر است.
عمده وظایف این گروه از افراد عبارت است از:
- طراحی سیستم
- تولید و توسعه سیستم
- تست سیستم
- ارتباط فنی با دنیای خارج
The team is the "pig" of the Sprint work.
تعریف کن شوابر: تیم مسئول تولید و توسعه قابلیت هاست.
ویژگی های تیم اسکرام عبارتند از:
۱- خود مدیریتی (Self-Managing)
۲- خود سازماندهی (Self-Organizing)
۳- هر کاری رابرای هم انجام دادن (Cross-functional)
آنها مسئول هستند طوری برنامه ريزی کنند که بتوانند تا انتهای دوره sprint ٬ موارد انتخاب شده از Product Backlog را بهر شکلی کی می توانند محقق کنند.
اعضاء تیم کلاْ در موفقیت یک دوره و کل پروژه مسئول هستند.
اعضاء تیم می توانند تخصص های مختلفی داشتند و در هنگام نیاز بهم کمک کنند (در واقع مفهوم Cross-functional بودن همین است) مثلاْ می توانند برنامه نویس٬ مسئول کنترل کیفیت٬ تحلیگر کار و کسب٬ معمار٬ طراح واسط کاربری یا طراح پایگاه داده ها باشند یعنی هر تخصصی که برای پیاده سازی نیازمندی ها وجود در بین آنها موجود باشد و همه از تخصص های همدیگر استفاده کنند.
اعضاء تیم فاقد عنوان هستند و هیچ استثنائی در مورد این قانون وجود ندارد. ما در اینجا Sub-Team برای حوزه های خاص نظیر تست یا تحلیل کسب و کار و امثالهم نداریم.
هیچکس حتی Scrum Master به تیم نمی گوید چه کند یا چه نکند. تیم خودش مسئول کار خودش است.
اول - Stakeholders یا ذینفعان پروژه
اینها افرادی هستند که فقط در طول sprint review ها مستقیماْ درگیر می شوند اما در واقع اینها هستند که پروژه ها را راه اندازی می کنند و البته پروژه ها هم برای آنها به میزان توافق شده ای سود ایجاد می کنند.
دوم - Managers یا مدیران
مسئول برپا کردن محیط کاری برای سازمانها و شرکت های تولید محصول هستند.
فرق بین Iterative بودن یک فرآیند و Incremental بودن یک فرآیند در این سایت بخوبی مشخص شده است.
ویژگی های اسکرام
اسکرام دربردارنده مجموعه ای از روش (Practice) ها و نقش های از قبل تعریف شده است اما سه ویژگی است که پایه های وجودی اسکرام هستند:
۱- شفافیت Transparency: یعنی اینکه باید تمام جنبه های مختلف فرآیند که بر خروجی آن اثر می گذارد بایستی برای آنهایی که فرآیند را کنترل می کنند مشهود و قابل دید باشد. نه فقط این جنبه ها باید شفاف باشد بلکه بایستی مشخص و معلوم هم باشند یعنی اگر کسی که فرآیند را ممیزی می کند تشخیص داده که چیزی انجام شده این باید مطابق با تعریف انجام شده Done از دید تمام افراد درگیر در پروژه باشد. اگر توافقی بین همه طرف های درگیر در پروژه بر سر معانی و مفاهیم نباشد٬ مشهود بودن اینکه یک قابلیت یا ویژگی انجام شده یا خیر٬ دیگر محلی از اعراب ندارند.
۲- ممیزی و وارسی Inspection: جنبه های مختلف فرآیند تولید نرم افزار بایستی مدام به اندازه ای در حال وارسی و چک باشند که انحرافات فرآیند قابل تشخیص باشد.
۳- تطابق پذیری Adaption: اگر بازرس و ممیز فرآیند پس از بازرسی فرآیند٬ تشخیص داد که یک یا چند جنبه از فرآیند خارج از حدود قابل قبول است و باعث غیر قابل پذیرش شدن محصول تولیدی می شود٬ آن شخص باید فرآیند یا آنچه که فرآیند بر روی آن انجام می شود را تنظیم و تعدیل کند. این کار باید در سریعترین زمان ممکنه انجام شود تا از انحرافات بیشتر جلوگیری شود.
نقش های عمده در اسکرام عبارتند از:
Scrum Master که وظیفه نگهداریُ و حفظ فرآیند را برعهده دارد
Product Owner که نماینده ذینفعان (Stakeholders) های پروژه و business است.
Team یک گروه cross-function متشکل از حداکثر ۷ نفر برنامه نویس است که عملیات تحلیل٫ طراحی٫ پیاده سازی و ... را انجام می دهند.
مثل تمام متدولوژی های Incremental و Iterative اینجا هم ما دوره های زمانی یا iteration داریم که در طی آنها محصول نهایی پروژه بتدریج تکمیل می شود. این دوره های زمانی را در اسکرام اصطلاحاْ sprint نامیده می شوند.
در طی یک اسکرام که معمولاْ یک دوره دو تا چهار هفته است(طول دوره را تیم مشخص می کند) اعضاء تیم یک محصول بالقوه قابل ارائه و قابل استفاده را تدریجاْ تولید می کنند. بطور رسمی دوره هر sprint یک ماه یا سی روز در نظر می گیرند.
مجموعه ویژگی هایی از محصول نهایی پروژه که در یک sprint محقق می شود از یک Requirements Repository بنام Backlog استخراج می شود.
اصطلاح Product Backlog نامی است که به بانک اطلاعاتی نیازمندهای عملیاتی و غیر عملیاتی یک پروژه اطلاق می شود و در حقیقت مجموعه ای اولویت بندی شده از نیازمندی های سطح بالای سیستمی است که بایستی تحویل داده شود.
Sprint Planning Meeting
مواردی از Product Backlog که در طی یک sprint باییستی انجام شود در طول جلسه برنامه ریزی sprint مشخص می شود. اصطلاحاْ این جلسه را Sprint Planning Meeting می نامند.
در طول این جلسه٫ Product Owner اعضاء تیم را درباره مواردی از Product Backlog محصولی که می خواهند تکمیل شود٬ آگاه می کند. سپس اعضاء تیم مشخص می کنند که چه مقدار از موارد مشخص شده توسط Product Owner را می توانند در این sprint انجام دهند و چه میزان از آنرا در sprint های بعدی.
مواردی از Product Backlog که قرار است در یک Sprint انجام شود را اصطلاجاْ Sprint Backlog می نامند. مفاد Sprint Backlog در واقع توافقی است بین اعضاء تیم و Product Owner برای انجام بخشی از نیازمندی های پروژه در طول sprint جاری و بهرحال طبیعی است که بعد از تصویب شدن مفاد یک sprint ٬ هیچکس نمی تواند آنرا در طول sprint تغییر دهد. در طول دوره٬ نیازمندی های لحاظ شده در Sprint Backlog از Product Backlog بر داشته می شوند . اما امکان دارد به دلایلی که در ادامه می آید این نیازمندی های دوباره به Product Backlog برگردد.
مانند تمام متدولوژی های iterative توسعه نرم افزار در اسکرام نیز Time Boxed است٬ به این معنی که sprint بایستی دقیقاْ سروقت تمام شود و اگر نیازمندی های اشاره شده در Spring Backlog به هر علتی تکمیل نشده باشند آنها را کنار گذاشته و دوباره وارد Product Backlog می کنند.
بعد از خاتمه یک sprint ٬ اعضاء تیم طی جلسه ای به Product Owner و سایر ذینفعان پروژه نشان می دهند که چکار کرده اند و چطور از نسخه جاری نرم افزار می شود استفاده کرد.
در ساده ترین روش معمولاْ از Mircosoft Excel برای ساختن و نگهداری Product Backlog و Sprint Backlog استفاده می شود اما شرکت Atlassian امکاناتی در این زمینه در محصول JIRA خود گنجانده است که از جمله اینها می تواند به ابزار GreenHopper اشاره کرد.
برای این منظور ما مستلزم داشتن ابزار هایی نظیر Source Controler ها (که به آنها Source Repositoy هم گفته می شود)، ابزار های Build خودکار و ... می باشیم. مجموعه این ابزار ها معمولاً بر روی یک سرویس دهنده مرکزی که اصطلاحاً CI Server نامیده می شود نصب می گردد.
سیستم های Source Code Control سیستم هایی هستند که کل سورس کد های برنامه را در یک repositoy نگهداری و محافظت می کنند. البته این سیستم ها را به اسامی دیگری هم می شناسند، از جمله می تواند به این اصطلاحات اشاره کرد:
Source Code Management Tool
Configuration Management
Version Control System
Repository
در حال حاضر ابزار Subversion(SVN) محبوب ترین ابزار Source Control در بین برنامه نویسان Open Source است ولی بغیر از این ابزار، ابزار های دیگری نظیر CVS، Cleare Case و غیر ه هم هست. در دنیای این ابزار ها اصطلاحات خاصی است که لازم است برنامه نویس از معنی و مفهوم آنها اطلاع داشته باشند. بعنوان مثال حالت فعلی سورس کد های یک پروژه نرم افزاری که در این سیستم ها نگهداری می شود اصطلاحاً mainline خوانده می شود. برنامه نویس ها معمولاً در آغاز کارشان یک کپی از سورس کد هایی که می خواهند تغییر دهند از Repository می گیرند به این عمل گرفتن اصطلاحاً Check out گفته می شود. در واقع با اینکار، یک عضو تیم تولید نرم افزار از تغییراتی که توسط سایر اعضا صورت گرفته آکاهی می یابد و سعی می کند تغییرات خودش را بر اساس آخرین نسخه کد های سورس برنامه انجام دهد.نسخه کپی کد ها که توسط برنامه نویس دریافت شده و بر روی دستگاه وی قرار دارد اصطلاحاً Working Copy گفته می شود.
پس از انجام تغییرات و اضافه کردن کد های جدید روی Working Copy، برنامه نویس سیستم را اجرا و تست می کند و بعد از اینکه از درستی تغییرات خودش مطمئن شد، کد های تغییر کرده در Repository ثبت می کند که به اینکار اصطلاحاً commit کردن گفته می شود.البته بهتر است که از قبل از commit کردن کد ها یکبار دیگر آخرین تغییرات نسخه جاری Repository را بگیرد. (یعنی یکبار دیگر check out کند) و بعد دوباره با همه سورس کدها کامپایل کند و تست هایش را انجام دهد تا مطمئن شود که در صورت commit کردن کد هایش، تناقضی در کد ها بوجود نمی آید و سورس کد ها او در کنار سورس کد های بقیه همکارانش قابل کامپایل شدن و اجرا هستند.
همیشه بیاد داشته باشید که Repository شما باید شامل همه چیز باشد نه فقط سورس کد ها بلکه هرچیزی که برای کامپایل، اجرا و تست برنامه مورد نیاز است بایستی در Repository باشد. البته به این معنی نیست که مثلاً ابزار کامپایل، سیستم عامل یا محیط اجرا را هم باید روی Repository گذاشتند و البته نبایستی برنامه کامپایل شده و نسخه اجرا شدنی برنامه را در Repository گذاشت.
مسئله دیگری که در این راهکار مد نظر قرار می گیرد ، کامپایل کردن و ایجاد نسخه قابل اجرای برنامه بصورت خودکار است. برای این منظور ابزار هایی مانند ANT و MAVEN وجود دارد و البته همه اینها بر اساس یک فایل پیکربندی کامپایل و ساخت نرم افزار مه اصطلاحا Build File نامیده می شوند کار می کنند. شما بعنوان برنامه نویس وظیفه دارید این فایل یا فایلها را بر اساس ساختار و ماهیت برنامه و چیزهایی که برای کامپایل کردن و نصب کردن آن لازم است ایجاد یا تغییر دهید و البته خود همین فایل یا فایل ها هم باید در Repositoy ثبت شوند. اکثر برنامه نویس ها از IDE ها برای توسعه تولید، اجرا و تست پروژه های نرم افزاری استفاده می کنند بودن ابزارها در این روش چیز بدی نیست ولی نباید به سیستم Build این ابزارهای IDE وابسته بود و باید همیشه ابزارهایی مانند Maven یا Ant را در دستگاه برنامه نویس نصب کرد و او را وادرا کرد که با این ابزار های عملیات کامپایل و استقرار را انجام دهند.
علاوه بر اینها برای مدیریت خودکار سرور بایتسی یک نرم افزار سیستمی خاص این کار نصب شود.بهترین نرم افزاری که برای مدیریت کارهای یک CI Server می شود پیدا کرد، برنامه Cruise Control است که یک برنامه Open Source روی سایت sourceforge است. توصیه جدی: برای به حداقل رساندن زمان کامپایل، استفرار و ارسال فیدبک اقدامات پیشین به اعضاء تیم بهتر است، دستگاهی انتخاب شود که دارای سرعت و حافظه بالایی باشد.
علاوه براینها می توان بایستی مکانیسم های مناسب برای اطلاع رسانی به اعضاء تیم نیز موجود باشد. بعنوان مثال اگر درجریان کامپایل کردن یا نصب برنامه بصورت خودکار، مشکلی پی بیاید بایستی پیغام های هشدار دهنده مناسب به اعضاء تیم فرستاده شود. البته حجم این پیغام ها نباید به اندازه ای باشد که اعضاء تیم را به ستوه آورد وباعث شود که آنها تصمیم بگیرند که نسبت پیام های ارسال شده را بعنوان هرزنامه بی توجه شوند.
توضیحات مفصل در مورد روش در لینک های زیر موجود است:
Automation for the people: Continuous Integration anti-patterns