توجه:
این مقاله برای حوزه طراحی محصول نرم افزاری تهیه و تدوین شده است.
در این مقاله اصطلاحات برای درک بهتر، ساده سازی شده اند.
توسعه چابک نرم‌افزار یا توسعه نرم‌افزاری چابک گروهی از متدهای توسعهٔ نرم‌افزار مبتنی بر تکرار و به شکل تدریجی است که در آنها، راه‌حل‌ها از طریق خودسازمان‌دهی و همکاری بین تیم‌های مختلف کاری، انجام میشوند. این روش برنامه‌ریزی تطبیقی، توسعه و تحویل تکاملی و رویکرد زمان بسته‌بندیِ تکرارشونده را ارتقا می‌بخشد و پاسخ‌های سریع و انعطاف‌پذیر برای انجام تغییرات را تقویت میکند. در واقع چابک‌سازی یک چارچوب مفهومی است که پیش‌بینی تعاملات در سراسر چرخهٔ توسعه را بهبود می‌بخشد. بیانیهٔ چابک در سال ۲۰۰۱ این اصطلاح را معرفی کرد.
بیانیهٔ چابک به شرح زیر است:
ما با توسعه نرم‌افزار و کمک به دیگران در انجام آن، در حال کشف راه‌های بهتری برای توسعهٔ نرم‌افزار هستیم. از این کار به ارزش‌های زیر می‌رسیم:
۱- افراد و تعاملات بالاتر از فرایندها و ابزارها
۲- نرم‌افزار کارکننده بالاتر از مستندات جامع
۳- مشارکت مشتری بالاتر از قرارداد کاری
۴- پاسخگویی به تغییرات بالاتر از پیروی از یک برنامه
با آنکه موارد سمت چپ ارزشمند هستند ولی ما برای موارد سمت راست ارزش بیشتری قائل هستیم.(منبع ویکی پدیا)
متدولوژی چابک یا اجایل/Agile از نوع adaptive یا تطبیقی هست و برای پروژه های زیر پیشنهاد میشود:
چارچوب یا فریمورک های/ Framework مانند اسکرام/Scrum، لین/Lean، سیف/Safe، کانبان/Kanban برای این مدل متدولوژی چابک یا اجایل/Agile طراحی شده اند.
در این نوع متدولوژی همه چیز تخمینی هست و قطعیت در آن وجود ندارد.این خاصیت برای استارت آپ ها بسیار مفید است البته حتما مدیران مجموعه/تیم/سازمان باید مایندست اجایل یا طرز تفکر اجایل داشته باشند.این متدولوژی انعطاف پذیری بسیار زیادی دارد و تیم هم باید نسبت به تغییرات و مشکلات انعطاف پذیر باشند.همچنین این متدولوژی چرخه های کوتاه مدت برای تولید و تحویل محصول به مشتری دارد.
اولین قدم برای برنامه ریزی به روش چابک، آشنایی با واژگان مورد نیاز برای برنامه‌ریزی در متدولوژی چابک است. در مدیریت پروژه به صورت چابک، ما کارها را از بزرگ به کوچک تقسیم بندی میکنیم:
تم/Theme
بزرگترین دسته از نیازها یا کارها یا اهدافی است که ما در طوب یک پروژه میخواهیم به آن دستیابی پیدا کنیم. یک Theme حوزه وسیعی است که به تیم چابک کمک میکند تا اهداف سازمانی خود را پیگیری کند.معمولا اهداف تعیین شده در تم بلند مدت هستند.
مثال:
اپیک یا ابتکار / Epic or Initiative
اپیک ها راهی برای سازماندهی یوز استوری ها و اطمینان از اینکه آنها در جهت یک هدف مشترک کار می کنند هستند.اپیک های معمولا تجمیع شده از چندین داستان کاربر میباشد.مثال های زیر اپیک هایی هستند که از ادامه مثل های بالا میباشند و در تم های بالا قرار میگیرند.
مثال:
امکانات / Features
فیچر ها یا امکانات انتخاب ویژگی هایی است که برای یک اپیک یا برای ذینفعان/مدیران/مشتری مهم هستند.معمولا فیچر ها باید ارزش تجاری/عملکردی داشته باشند. مثال های زیر فیچر هایی هستند که از ادامه مثل های بالا میباشند و در اپیک های بالا قرار میگیرند.
مثال:
داستان کاربر / User Stories
داستان کاربر یا User Story یک درخواست به زبان ساده است که از سمت کاربر/مشتری نوشته میشود.حتی میتوان برای نشوتن این داستان خودتان را بجای مشتری یا کاربر بگذارید و شروع به داستان نویسی کنید.کاربر مورد نظر ممکن است ادمین سایت، پرسونای محصول، کاربر عادی و ... باشد.یک داستان کاربر ممکن است لازم باشد به چندین داستان کوچکتر یا Task تبدیل شود.داستان کاربر بر اساس یک فرمت استاندارد معمولا نوشته میشود.برخی از فرمت ها به این شکل هستند:
As a [persona], I want to [action], so that I can [benefit]
As a [ type of user] I want [ some goal] so that [some reason]
As a [ WHO], I want [ WHAT] so that [ WHY]
نقشه برداری داستان کاربر / User Story Mapping
در نقشه برداری داستان کاربر، تمامی نیاز ها و کارهایی که باید برای تولید محصول ایجاد شود بصورت داستان کاربری نوشته میشود و سپس بر اساس نیاز و اولویت های کسب و کار یا بر اساس نیاز و اولویت های مشتری یا بر اساس فرمول های رایج مانند MoSCoW تنظیم میشود.همچنین ممکن است لازم باشد بر اساس زمان و منابع این اولویت ها تنظیم شود.ممکن است تصمیم بگیرید یک سری از امکانات/یوزر استوری های کاربر را در نسخه اول محصول بصورت MVP ارائه دهید.
در اسکرام اولین موضوع ارزش ها/اصول/طرز فکر در آن است که همه تیم های اسکرام باید به آن پایبند باشند، که مهمترین آنها شامل:
روند ها/پروسه ها در اسکرام iterative یعنی تکرار شوند است. در اسکرام با تکنیک کوچک کردن قطعات بزرگ تر پروژه امکان مهک زدن/سنجیدن توانایی مجریان، زیرساخت ها و ذینفعان وجود خواهد داشت.خروجی کار ها در اسکرام بصورت افزایشی Incrementally انجام میشود و تحویل مشتری میشود.یعنی یک محصول بزرگ به قطعات کوچک تقسیم میشود و سپس قطعات کوچک (که قابل تحویل و قابل استفاده و با ارزش برای مشتری است) تحویل مشتری میشود.در این تکنیک امکان دریافت بازخورد از مشتری زودتر فراهم میشود و بنابراین زودتر میتوان جلوی اشتباهات بزرگ تر را گرفت و در منابع و زمان صرفه جویی داشت.برای اولویت دادن به امکانات محصول باید فقط اولویت های مشتری را در نظر گرفت.اگر محصولی بصورت MVP قرار است تحویل مشتری شود باید ساده اما قابلیت های با ارزشی داشته باشد.تعامل افراد تیم با یکدیگر جز پایه های اساسی در اسکرام میباشد.اسکرام فریمورک سبک وزن است و از نوع adaptive هست یعنی خودش را با تغییرات منطبق میکند.روش های قدیمی یا predictive برای پروژه/تیم های از نوع استارت آپ قابل استفاده نیست و ممکن است پروژه شکست بخورد.
خصوصیات اسکرام
معمولا تیم اسکرام از 4 تا 10 نفر هستند.صاحب محصول/Product Owner، اسکرام مستر/Scrum Master و تیم توسعه(تستر، طراحان، متخصصین دیتابیس و ...) جز تیم اسکرام میباشند.
در تیم اسکرام سلسله مراتب/چارت سازمانی وجود ندارد یعنی اسکرام مستر و صاحب محصول نباید تیم را مدیریت جبری کنند. همه در تیم پیشنهاد میدهند اما دخالت نمیکنند Micro Management نباید در اجایل و اسکرام باشد.تفیض کار به افراد بدون در نظر گرفتن رضایت افراد در اجایل ممنوع است.باید علاقه مندی آن شخص هم در نظر گرفت شود.روند کار نباید command and controlیا دستوری و کنترلگر باشد و تیم باید خودش بتواند خودش را مدیریت کند.تیم اسکرام Cross Functional است و همه اعضای تیم باید بتوانند(کم کم) همه کارها را انجام دهند.تیم توسعه به بیرون مجموعه وابستگی ندارد.تیم اگر مطلبی یا تخصصی ندارد باید زمانی اختصاصی دهد برای یادگیری آن و پس از یادگیری تسکها/کارهایی که بلد نبودند را انجام میدهند البته حتما فرهنگ آموزش باید در سازمان/مدیران باشد.
تایم زدن/تخصیص زمان برای تسک فقط برای مدیریت زمان و پروژه است و نه برای سنجش میزان تنبلی افراد.در اسکرام پروژه به قسمت های ریز تقسیم میشوند و سپس تیم به تحقیق، برنامه ریزی و اجرای قسمت های ریز اقدام میکنند.در متدولوژی سنتی یا مثلا WaterFall/ابشاری برای کل پروژه تحقیق،برنامه ریزی انجام میشد و سپس شروع به تولید کل پروژه میکردند، لطفا به تصویر زیر دقت کنید.
فرض کنید یک پروژه را به 10 بخش تقسیم میکنیم.
مثلا در روش ابشاری برای کل یک پروژه، پروسه ای که در تصویر فوق دیده میشود، انجام خواهد شد:
اگر در حین تحویل به مشتری، نیاز های مشتری دچار تغییراتی شده باشد، بر اساس نیاز واقعی مشتری نبوده باشد، تیم نیاز واقعی مشتری را به خوبی درک نکرده باشد و مشتری راضی نباشد، بنابراین تیم مجبور خواهد شد که کل این پروسه را از ابتدا مجدد طی کند و این روند همین طور ادامه دارد، همچنین از مرحله اول تا مرحله تحویل، مشتری باید صبر کند تا محصول کامل شود و سپس تحویل شود.
اما در روش اسکرام کل پروژه به بخش های کوچک و قابل استفاده تقسیم خواهد شد و برای هر 1 بخش از پروژه، پروسه ای که در بالا ذکر شد انجام میشود و در پایان عملیات، فقط یک بخش تحویل مشتری میشود و پروژه قدم به قدم بهبود بخشیده و تکمیل میشود اما زیر نظر مشتری و طبق نیاز مشتری.بنابراین اگر مشتری در هر بخش تصمیم به تغییر داشته باشد کل پروژه دچار مشکل نمیشود و فقط همان 1 بخش تغییرات در آن داده میشود.در تصویر زیر پروژه بصورت تیکه های کوچک اما قابل استفاده برای مشتری ساخته(برنامه ریزی،طراحی،کدنویسی،تست،تحویل) و تحویل داده میشود.
افراد یا نقش ها یا Roles در اسکرام
مالک محصول / صاحب محصول / Product Owner: وظیفه مذاکرات با مشتری و دریافت و درک نیاز های مشتری به عهده مالک محصول یا به اختصار PO است.نیازهای بازار/مشتری را بفهمد.بهبود فیچرها/ویژگی ها به عهده Po است با هماهنگی مشتری.هدف گذاری و چشم انداز به عهده po است بر اساس پروداکت بک لاگ.اولویت ها را تنظیم میکند.بک لاگ هارا در صورت نیاز خورد و سبک میکند.باید شفاف باشد.البته به دلیل پیچیدگی وظایف PO و زیاد بودن حجم کاری PO، برخی از وظایف خارج از سازمان/تیم در این جایگاه ممکن است به عهده شخصی دیگر بعنوان مدیر محصول/Product Manager باشد.معمولا وظایف داخل چارچوب اسکرام به عهده PO است و وظایف ارتباط با مشتری و تحلیل و تحقیق رقبا، قیمت گذاری،استراتژی محصول و... به عهده PM است.(برای اطلاع دقیق و جامع از وظایف PM، به مقاله مدیریت محصول مراجعه کنید)
اسکرام مستر/ Scrum Master: آموزش اسکرام به همه جز وظیفه اسکرام مستر یا SM است.نظارت بر روش ها و چارچوب اسکرام و نظارت بر اجرای صحیح Ceremonies/تشریفات اسکرام نیز به عهده SM میباشد.SM اجازه مدیریت به سبک دستوری را ندارد.تیم را هدایت میکند و نوعی خدمتگذار تیم میباشد.پیاده سازی اصول اجایل به عهده اسکرام مستر است.تمرکزش فقط روی متدولوژی اسکرام است.همه impediment/سختی ها را با کمک تیم حل میکند.نظارت بر عدم دخالت مدیران بر روند اسکرام و تیم به عهده SM میباشد.در اسکرام مدیریت مجموعه نباید با تیم بصورت مستقیم در تماس باشد یا در روند کار آنها دخالت کند.
تیم توسعه / Development Team: تمامی افرادی که در تحقیق، طراحی، تولید، تست، نصب، نگهداری یک پروژه نقش دارند جز تیم اسکرام هستند.
عناصر اسکرام / Scrum Artifacts
در چارچوب/فریمورک اسکرام، نیاز های مشتری و تیم توسعه را به بخش های مختلف تقسیم میکنند، یکی از آنها بخش یا لیست بک لاگ محصول/Product Backlog است: لاگ از نظر لغوی به الوار هایی(چوب) گفته میشود که آماده شکل گرفتن تراشیده شدن برای محصول مورد نظر است.در واقع برخی موارد Backlog نیاز های مشتری برای یک محصول/پروژه هستند که به آنها داستان کاربر یا User Story گفته میشود.مشتری میتواند یک بک لاگ یا یوزر استوری را حذف/تغییر اولویت/جابجا/اضافه کند و همیشه مشتری اختیار این تغییرات را دارد.اصطلاحا به موارد موجود در این لیست PBI یا Product Backlog Item گفته میشود.در این لیست اولویت بندی انجام میشود.این اولویت بندی فقط بر اساس نیاز و خواسته مشتری توسط PO تنظیم میشود. البته PBI های این لیست شامل باگ، آموزش به تیم، تست یک فیچر،بهینه سازی و ... هم میشود و امکان خورد کردن آنها به قطعات کوچکتر نیز وجود دارد.همانطور که گفته شد برخی از PBIها همان یوزر استوری های مشتری هستند که بر اساس اولویت مشتری با فرم دادن/ترجمه فنی کردن به پروداکت بک لاگ قرار داده میشود.وظیفه این کار به عهده PO است.
رویداد اسپرینت/Sprint: یک پروسه زماندار است که در طی آن زمان، توسعه دهندگان میتوانند یک محصول را طراحی و تولید کنند سپس در انتهای مدت زمان تعیین شده یا زودتر، محصول را تحویل مشتری دهند یا محصول را در این مدت زمان بهبود دهند(دیباگ کنند یا امکانات اضافه کنند). در واقع مدت زمان لازم برای توسعه یک محصول که ممکن است شامل یک یا چند تسک/بک لاگ باشد، اسپرینت میگویند.
مدت زمان یک اسپرنیت حداقل 1 هفته و حداکثر 4 هفته میباشد.(کمتر از یک ماه) اگر زمان مثلا 2 هفته برای اسپرینت در نظر گرفته شد باید همیشه در همه اسپرینت ها مدت زمان 2 هفته را انتخاب کنیم.هر اسپرینت پس از اتمام اسپرینت قبلی شروع میشود.در بین این اسپرینت ها فاصله ای وجود ندارد.برای تیم هایی که توانایی هایشان ناشناخته است یا تیم تازه شکل گرفته و هنوز ناهماهنگ هستند، بهتر است این زمان 1 هفته باشد.
یک لیست دیگر برای تفکیک دقیقتر کارها، لیست بک لاگ انتشار/ Release Backlog است: در این بخش مواردی اضافه میشود که قرار است مثلا هر 2 ماه یا هر 3 ماه یک نسخه/Release به مشتری تحویل داده شود.آیتم هایی/بک لاگ هایی که در این بخش قرار میگرند از بخش Product Backlog برداشته شده اند.در واقع مواردی که توسط تیم اسکرام قرار است روی آن کار کنند تا نسخه قابل تحویل ساخته شود، از PBI تامین میشود و سپس در لیستی بعنوان Release Backlog قرار داده میشود.اولویت آیتم های در این لیست باز هم توسط مشتری تعیین و توسط PO تنظیم و قرارداده میشود.هر ریلیز ممکن است به چندین اسپرینت یا یک اسپرینت نیاز داشته باشد تا به نسخه قابل ریلیز برسند. درواقع آیتم های بخش ریلیز در اسپرینت هایی تقسیم میشود. اگر مشتری نیاز به تغییر اولویت/حذف/اضافه یک آیتم داشت، باید در اسپرینت یا ریلیز بعدی اعمال میشود تا برنامه ریزی بهم نریزد.(در شرایط خیلی خاص و مهم امکان تغییر در این ریلیز وجود دارد)
و آخرین لیست اسپرینت بک لاگ/ Sprint Backlog است: متشکل از بک لاگ های خورد شده بخش Release Backlog است که باید برنامه نویس ها/طراحان/تستر ها و ... روی آن کار کنند.که قبل از شروع اسپرینت اسکرام مستر نسبت به توان و تجربه تیم توسعه، تعدادی بک لاگ از ریلیز بک لاگ برمیدارد و به اسپرینت اضافه میکند و بعد تیم توسعه کار خود را شروع میکنند.پس از پایان اسپرینت یک اینکریمنت/Increment ساخته میشود. در صورتی که ریلیز بک لاگ ایتم های انجام نشده داشته باشد، نسخه قابل تحویل به مشتری نیست و باید همه ریلیز بک لاگ ها انجام شود.
مثال:
ما 30 آیتم/تسک در پروداکت بک لاگ داریم و آنها را بر اساس درخواست مشتری اولویت بندی کردیم.
9 آیتم از آنها را جدا میکنیم و به یک لیستی بعنوان Release Backlog اضافه میکنیم.
فرضا برای هر اسپرینت 4 هفته در نظر گرفته ایم.
و به مشتری وعده داده ایم که طی 3 ماه آینده نسخه شماره یک محصول را تحویل میدهیم
و طبق برنامه ریزی و تصمیم اعضای تیم اسکرام و محاسبات اسکرام مستر نسبت به توانایی های تیم، در هر 1 اسپرینت 3 آیتم/PBI /تسک قابل انجام است. بنابراین باید 9 آیتم در ریلیز بک لاگ را طی 3 اسپرینت به پایان برسانیم و پس از پایان 3 اسپرینت باید محصولی با 9 فیچر/آیتم/امکانات تحویل مشتری دهیم.
توجه داشته باشید که شخص PO یا مالک محصول با توجه به نیاز های مشتری، ایتم های با اولویت بالا را از Product Backlog برمیدارد و در داخل ریلیز بک لاگ میگذارد.اگر بک لاگ های ریلیز انجام شد(در واقع همه اسپرینت های مربوط به آن ریلیز به پایان رسید) همه افزایشی ها/Increments جمع میشود(مثلا Merge کردن کد ها، کلاس ها، طر ح ها و ...) و یک نسخه تحویل مشتری میشود.(افزایشی ها یا Increments مواردی است که توسط تیم توسعه یا طراحی انجام شده است و تکمیل کننده کل محصول هستند.)حتی میتوان در هر اسپرینت یک ریلیز/نسخه ارائه داد و دیگر قسمت ریلیز بک لاگ نخواهید داشت.اما بهتر است داشته باشید چون مثلا یک اپلیکیشن که روی وب هست را نمیتوان هر ماه/پایان هر اسپرینت نسخه جدیدی داد به این دلیل که معمولا مشتری ها گیج/کلافه خواهند شد.
رویداد برنامه ریزی اسپرینت / Sprint Planning: در اولین روز اسپرینت این جلسه انجام میشود.برای برنامه ریزی انجام کارهای داخل اسپرینت و اینکه تیم توسعه قرار است چه کاری انجام دهد و چه محصولی در پایان این اسپرنیت تحویل مشتری دهد.همه باید در این جلسه/رویداد شرکت کنند.مدت زمان این جلسه بین 2 تا 8 ساعت میباشد.تصمیم گرفته میشود که این تسکها چطور و توسط چه کسانی انجام میشود.اسکرام مستر با توجه به توانایی تیم و تجربیات قبلی که تیم داشت، اینکه تیم توسعه در چه زمان چه تعداد بک لاگ/یوزر استوری را به اتمام رسانده اند و البته فرمول های تقریبی وجود دارد که نسبت به توانایی تیم و تعداد افراد تیم ممکن است این تخمین ها فرق کند.اسکرام مستر پس از محاسبه، یک عدد بعنوان Velocity /ظرفیت/شتاب انجام کار برای تیم در نظر میگیرد.مثلا میگوید تیم اسکرام میتواند 30 استوری پوینت کار انجام دهد یا به بیانی دیگر Velocity تیم اسکرام 30 واحد میباشد.
در این جلسه SM یا اسکرام مستر به همراه تیم توسعه به یوز استوری ها وزن/پوینت میدهند.این محاسبه نیز بر اساس فرمول میباشد و البته تقریبی است.درواقع استوری پوینت وزنی است که هر کدام از یورز استوری ها به خود میگیرند. ارزش دادن به استوری پوینت توسط تیم برنامه نویس و اسکرام مستر محاسبه تقریبی میشود. تیم توسعه هر PBI را یک تخمینی میزند و یک وزن به آن میدهد و باتوجه به تعداد و وزن یوزراستوری ها در طول استپرینت های قبل موفق به انجام آن شده، اسکرام مستر میفهمد که قابلیت تیم چقدر هست.
سپس بر اساس تعداد اعضای تیم برنامه نویس هایی که در این اسپرینت قصد فعالیت دارند و با توجه به عدد velocity در اسپرینت های قبلی به PO اعلام میکند که تیم در این اسپرینت مثلا 30 استوری پوینت را میتوانند انجام دهند.PO بر روی PBI ها بررسی میکند که بر اساس اولویت های اول و جمع زدن استوری پوینت هایی که اسکرام مستر اعلام کرده، یوزر استوری را انتخاب میکند. مثلا SM اعلام کرده است که در این اسپرینت 30 استوری پوینت میتواند انجام دهد.بنابراین PO باید جمع استوری پوینت هایی که میخواهد تحویل تیم توسعه دهد حداکثر 30 پوینت باشد.سپس تیم ایتم ها را بررسی میکنند و PO به انها توضیح میدهد که روی چه مواردی باید کار کنند و سپس PO هدف اسپرینت/ sprint goal را مشخصی میکند.تیم باید در طول اسپرینت در مسیر هدف کار کنند.پس از تنظیم اسپرینت بک لاگ، ایتم ها بین تیم تقسیم میشود.نکته مهم اینکه تخصیص PBI ها به افراد باید توسط اعضای تیم توسعه تقسیم شود آن هم نسبت به توانایی های خود و صلاح دید خود تیم.
نکته: محاسبه استوری پوینت/تخمین میزان سختی/برآورد وزن برای PBI ها توسط روش هایی مانند:روش بازی پوکر،روش سایز تیشرت،روش سایز حیوانات،سایز سیارات،سیستم باکت،رای گیری نقطه ای،اعداد فیبوناچی و .. انجام میشود.
جلسات ایستاده اسکرام / جلسات روزانه اسکرام / Daily Scrum: این جلسات در در طول اسپرینت است. هر روز تیم برنامه نویس جمع میشوند و درباره شرایط کنونی پروژه و موانع پروژه صحبت میکنند و سعی میکنند موانع را از بین ببرند.زمان این جلسه حداکثر 15 دقیقه است.بین اعضا تیم های فنی و اسکرام مستر انجام میشود.موضوعات در این جلسات شامل کارهای انجام شده، کارهایی که قرار است انجام شود و آیا مشکلاتی وجود دارد یا خیر؟ نکته مهم اینکه این یک جلسه حسابرسی و حسابکشی نیست و فقط در جریان قراردادن اعضای تیم و حل مشکلات است.
جلسات تنظیم بک لاگ / Backlog Refinement / Grooming: این جلسات در طول اسپرینت است. در این جلسه شروع به بررسی ایتم های بک لاگ و تخمین زدن عدد استوری پوینت آنها میباشد. زمان مورد نیاز برای این جلسه از 1 الی 2 ساعت میباشد.این تخمین توسط تیم توسعه تنظیم خواهد شد.توضیحات هر PBI توسط PO در جلسه مطرح میشود.زمان برگزاری این جلسه در اختیار SM و PO میباشد و به تعداد مورد نیاز است.تخصیص این استوری پوینت ها به PBI ها به این دلیل است که برای اسپرینت بعدی PBI ها اماده باشد و اعداد استوری پوینت آنها مشخص باشد.
جلسات بازبینی اسپرینت/ Sprint Review:در روز آخر اسپرینت این جلسه برگزار میشود. پس از جلسات برنامه ریزی اسپرینت /Sprint Planning و جلسات روزانه اسکرام /Daily Scrum و انجام شدن همه ایتم های اسپرینت، این جلسه برگزار میشود.
در این جلسه انکریمینت یا توسعه یا نسخه ای که از نرم افزار بوجود امده را برای مشتری و مدیران و یوزر ها بصورت دمو/ارئه میدهند. بررسی کارهای انجام شده در طول اسپرینت و چه چیزی تحویل مشتری میخوایم بدیم نیز دراین جلسه مشخص میشود. درنهایت از جلسه بابت محصول یا انکریمنت ساخته شده از مدیران و مشتری فیدبک میگیرند و تیم اسکرام این بازخورد ها را در اسپرینت های بعدی در نظر میگیرند.البته ممکن است در پایان اسپرینت ریلیز نداشته باشید و فقط انکریمنت باشد.
جلسات Retro/ جلسات گذشته نگری/ Sprint Retrospective: آخرین جلسه که ایرادات اسپرینت قبلی را رفع میکنند تا در اسپرینت بعدی این مشکلات نباشد. پس از جلسه اسپرینت Review است.فقط تیم اسکرام در آن حضور دارند.(اسکرام مستر، مدیر محصول تیم توسعه).جلسه بابت بررسی ایرادات و اتفاقای خوب از نظر فنی برای بهبود مشکلات است.برای مشکلات گذشته برنامه ریزی و اکشن تعیین میکنند تا مشکل رفع شود.یادتان باشد در اسکرام همیشه میشود انتقادات را اعلام کرد.اصول اجایل و اسکرام است.
معیار های پذیرش یا Acceptance Criteria:
Acceptance Criteria یا به اختصار AC یک چک لیست ساده و یک معیار پذیرش قوی برای ویژگی ها، عملکردها و استانداردهای عملکردی را که محصول تحویلی باید رعایت کند، مشخص می کند.AC ها برای داستان کاربر یا PBI ها نوشته میشوند. Acceptance Criteria مرتبط با یک User Story خاص است و معیارهایی هستند که توسط Product Owner (مالک محصول) تعریف میشود. این معیارها نشان‌دهندهٔ اهداف آن یوزر استوری هستند و مشخص میکنند که آن ویژگی یا یوزراستوری چگونه باید کار کند.در واقع به نیاز های مشتری توجه میکند و همانطور که گفته شد، شرایط دقیقی هستند که یک ویژگی باید آن ها را داشته باشد تا آن یوزر استوری کامل در نظر گرفته شود. آنها فنی تر هستند و چک لیستی ارائه می دهند که تضمین می کند ویژگی از دیدگاه کاربر نهایی همانطور که در نظر گرفته شده است رفتار می کند.
برای نوشتن AC ها یک فرمت محبوب وجود دارد که توسط دستورات Gherkin نوشته میشود که 5 مرحله دارد:
Scenario - the name for the behavior that will be described
Given - the beginning state of the scenario
When - specific action that the user makes
Then - the outcome of the action in “When”
And - used to continue any of three previous statements
مثال برای یک یوزر استوری:
و نوشتن AC از نوع سناریو محور برای این یوزر استوری:
Scenario: Forgot password
Given: The user navigates to the login page
When: The user selects <forgot password> option
And: Enters a valid email to receive a link for password recovery
Then: The system sends the link to the entered email
Given: The user receives the link via the email
When: The user navigates through the link received in the email
Then: The system enables the user to set a new password
به این ساختار به اختصار GWT یا Given/When/Then نیز میگویند.AC ممکن است توسط تیم توسعه، مالک محصول، تحلیلگر سیستم نوشته شود و تیم توسعه هم در انتخاب معیار ها و تنظیم آنها میتواند نقش داشته باشد.این زبان به دلیل سادگی برای ذینفعان و مشتری نیز قابل فهم است.این ساختار از نوع سناریو محور میباشد.
مدل دیگر برای نوشتن این AC استفاده از ساختار نقش محور یا Base Role میباشد که به زبان ساده تر نوشته میشود.
مثال برای یک یوزر استوری:
User story: As a traveler, I want to search by city, name, or street, so that I can have more matching hotel options.
و نوشتن AC از نوع نقش محور برای این یوزر استوری:
The search field is placed on the top bar
Search starts once the user clicks “Search”
The field contains a placeholder with a grey-colored text: “Where are you going?”
The placeholder disappears once the user starts typing
Search is performed if a user types in a city, hotel name, street, or all combined
Search is in English, French, German, and Ukrainian
The user can’t type more than 200 symbols
The search doesn’t support special symbols (characters). If the user has typed a special symbol, show the warning message: “Search input cannot contain special symbols.”
شاخص DoR یا Definition of Ready:
قبل از انتقال User Story ها به Product Backlog یک استانداردی وجود دارد که تعیین میکند یک یوزر استوری آماده انتقال به Product Backlog و اسپرینت است.دلیل اینکار این است که همه اعضای تیم تا جای ممکن از ماهیت این تسک مطلع باشند و نیازمندی های اولیه این تسک شفاف است. به عنوان مثال این استاندارد ها میتواند شامل موارد زیر باشد:
شاخص DoD یا Definition of Done:
در پایان هر اسپرینت یا در پایان هر ریلیز، محصول باید یک استاندارد کیفی و کمی داشته باشد قبل از اینکه تحویل مشتری شود.در واقع هر یوزر استوری که به اتمام میرسد باید این DoD را رعایت/Pass کند.این DoDروشی است که کیفیت را ارزیابی کنید.این DoD ها برای همه تیم های یک محصول مشترک است.تعیین این استاندارد به عهده شرکت یا تیم اسکرام است که با توجه به بیزینس یا طبق ویژگی های فنی محصول این استاندارد ها را تدوین میکنند. به عنوان مثال این استاندارد ها میتواند شامل موارد زیر باشد:
نکته مهم اینکه امکان تخصیص استاندارد DoD برای بخش User Story، Epic،PBI ، Sprint، Releaseو ... در اسکرام میسر میباشد.در بعضی از تیم ها یک استاندارد تاکیدی دوم نیز استفاده میکنند به نام Done-Done.این برای اطمینان بیشتر DoD محصول میباشد که نسبت به شرایط پروژه تدوین و تنظیم میشود.البته به نظر من اگر تیم نسبت به DoD تعهد کافی داشته باشد نیاز به Done-Done نیست.
نکات مهم پایانی:
اگر اسپرینت شروع شد افراد تیم و PBI ها تغییر نخواهند کرد.هر تغییر برای اسپرینت بعدی قابل انجام خواهد بود.
مالک محصول، اسکرام مستر، مدیر محصول هیچکدام اجازه دستور دادن یا جبر کردن ندارند و همه به پیشنهادات و نظرات احترام میگذارند.هر سه این اشخاص باید در طول اسپرینت در کنار تیم باشند.
تیم فنی میتواند برای بهینه سازی محصول یا حل مشکل فنی یک تکنیکال استوری به PB اضافه کند.البته باید به تایید PO برسد.برای جمع بندی Velocity باید همه پوینت های PBI محاسبه شود و Technical Story نیز شامل این محاسبه میشود.
یک شاخص ساده برای ایجاد یوزر استوری وجود دارد که به آن INVEST میگویند و یوزر استوری را بر اساس این شاخص ها تنظیم و بهینه میکنند.INVEST برگرفته از 6 کلمه است که به آن اشاره ای میکنیم:
· Independent (not dependent on other work deliverables).
· Negotiable (allows for best practices),
· valuable (provides working functionality).
· Estimable (allows clear work estimates).
· Small (sized for the team's sprint).
· Testable (can be measured to ensure it meets customer expectations).
معنی لغوی کلمات بدین صورت است: یعنی یک یوزر استوری باید مستقل، قابل مذاکره، ارزشمند، قابل تخمین، کوچک و قابل آزمایش باشد.
همچنین یک استاندارد برای تعریف PBI یا ترجمه فنی User Story ها به PBI قابل انجام، وجود دارد که به آن اصول DEEP میگویند.این 4 کلمه D,E,E,Pعبارت است از:
1. کلمه Detailed / جزییات: دارای جزئیات کافی به طوری که هر عضوی از تیم اسکرام بتواند به طور مستقل روی PBI ها کار کند.
2. کلمه Emergent / اضطراری: انعطاف پذیر است، PBI بر اساس نیازهای تیم، کسب و کار یا مشتری نوسان غیر قابل پیش بینی/اضطراری دارد.
3. کلمه Estimated / تخمین زده شده: اندازه و پیچیدگی PBI با استفاده از User Story تخمین زده می شود - اگر یک PBI با تخمین بالا همراه باشد، احتمالاً آنقدر بزرگ است که باید به PBI های کوچکتر تقسیم شود.
4. کلمه Prioritized / اولویت‌بندی شده: PBI ها در این لیست بر اساس اولویت محصول مرتب میشوند - اگر همه PBI های اسپرینت زودتر تکمیل شوند، تیم باید PBI های بعدی را در اسپرینت جدید شروع کند.
پایان
