در اینجا یک راه بهتر از چرخه های استرس زا برای تحویل محصول را به شما معرفی می کنیم که شما را در مسیر چابکی حفظ کند.

تکرار ابهامات باعث ایجاد بدهی فنی بیشتر و کاهش کیفیت محصول می شود. به عبارت دیگر نتیجه زمان گذاشتن روی تکرار ابهامات باعث افزایش دوباره کاری و بدهی فنی می شود. اگر از یک روند تکرار شونده 4 ساله به یک روند 4 ماهه بروید تغییر در ارزش ایجاد شده آن را مشاهده خواهید کرد، ولی فرآیند شما مبهم و توانائی فقط تحویل محصول کارا (ability to deliver working software) کاهش می یابد.

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

یک قانون کلی:

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

به عنوان مثال: به این معنا که اگر شما در حال تست یک دستگاه ضربان سنج باشید خب ۶ هفته برای آزمایش بر روی حیوان زمان می برد و ۶ هفته هم آزمایشات بر روی انسان. شما نمی توانید این کارها را در Sprint دو هفته ای انجام دهید. در عوض شما می توانید بر روی چیزهایی که موجب انجام موفق این تست ها شود تمرکز کنید. در صورت عدم موفقیت مسیر و عوامل را به صورت کامل بررسی کنید و اطلاعات بدست آمده را در جلسه Sprint Retrospective وارد کنید و اطمینان حاصل کنید که شما معیارهای اندازه گیری را در محل خود قرار داده اید و مطمئن شوید که دیگر اتفاق رخ نخواهد داد.

چارچوبهای غیر واقعی

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

درباره این متد نامهای زیادی گفته می شود مانند: Water-Scrum-fall یا شاید Scrummerfall اما هرقدر که آن را واقعی بنامیم ولی در واقع چیزی جز همان مدل آبشاری در ابعاد کوچکتر نیست که البته در مدل بالا واقعا کوچک نیست. این است که اغلب زمانیکه در سازمان گفته می شود که چابک عمل می کنید پاسخ میدهند بله ولی در عمل تغییر نکرده اند و به دنبال آن هستند که همان کاری را انجام دهند که در گذشته انجام می گرفته است.

مشکل چرخه های استرس زا برای تحویل محصول چیست؟

در دیاگرام بالا ما از بررسی تا تحویل یک چرخه ۱۸ هفته ای داریم که بیش از ۴ ماه بین ایده پردازی و تحویل با یک تاخیر ۲ ماهه برای دریافت feedback و یک تاخیر ۲ ماهه برای همه feedback های بعدی داریم. که بدترین و هزینه بر ترین نوع دریافت feedback است که تیم های توسعه و تست چیزی را تحویل داده اند که قبلا از آن feedback گرفته اند و نتیجه پیاده سازی این feedback ها بسیار هزینه بر خواهد بود. از ان بدتر اینکه اگر واحد QA موردی پیدا کند که نیاز به اصلاح داشته باشد ما نه تنها هزینه اصلاحات را افزایش داده ایم بلکه زمان رفع باگ را نیز در توسعه این موارد استفاده کرده ایم. پس، حالا با feedback ها چه کنیم؟ آیا اولویت دارند؟ آنها را رها کنیم و کار های قبلی که عمدتا انجام میدادیم را ادامه دهیم یا کارهای قبلی را متوقف کنیم تا feedback ها را تحویل دهیم؟ اگر QA جلوی اینها را بگیرد چه می شود؟ آیا QA بنشیند تا پایان هر چرخه یکی از آنها گزارشی از مشکلات محصول ارائه دهد؟

راهکارهای رفع مشکل چرخه های استرس زا برای تحویل محصول

ما نیاز داریم که تیمها را به جای افراد پرورش دهیم و تیمها را مسئول تحویل محصول کارا کنیم. برای این کار ما نیاز به تیمهای cross-functional  داریم که می توانند ایده ها را به محصول کارا تبدیل کنند و باید اغلب این کار را انجام دهیم.

• Cross-functional teams

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

• Asynchronous development

  در حالت ایده آل شما می توانید برای رسیدن به محصول کارا از همه رشته های مورد نیاز برای تکمیل هر Backlog item در کنار هم داشته باشید. این چیزی بیش از سپردن بخشی از کار بین هر رشته است، ارسال کار به سمت افراد به صورت مداوم و در هر زمان است. رسیدن به این مورد کار سختی است اما این وظیفه تیم است تا بفهمد که چطور: برای دستیابی به توسعه غیر همزمان به یک سیستم source control مدرن نیاز دارید.

• Test first

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

• Working software each iteration

  اگر شما در پایان هر دوره یک نرم افزار کارا ایجاد نمی کنید شما هیچ راهی ندارید که بفهمید برای ایجاد یک increment کارا چه چیزی واقعا نیاز دارید که done کنید. اگر قبل از فکر کردن درباره ایجاد یک increment کارا شما چهار دوره دو هفته ای را گذراندید چه مقدار کار (کار تکراری) باقی مانده است که باید واقعا برای تکمیل و رسیدن به مفهوم done انجام دهید؟ همچنین آیا واقعا کیفیت قابل حمل را داریم؟ اگر شما در پایان هر چرخه نرم افزار کارا ندارید مطمئن باشید که تجارت شما نمی تواند اوج بگیرد. مهم نیست که چه مقدار بخواهد; تیمهای scrum حرفه ای نرم افزارهای کارا تولید می کنند.

• Quality Assurance requires no testing

  اگر در نظر بگیرید که تمام آزمایشات به عنوان بخشی از Sprint انجام (done) می شود، بعد فقط تنها چیزی که نیاز است توسط درگاه QA انجام شود بازبینی نتایج تست و پوشش و تعیین کفایت نتایج است. اگر شما برای یک دوره دو هفته ای بیش از ۴ ساعت برای QA صرف می کنید من فکر می کنم که تیمهای توسعه شما به اندازه کافی کار نمی کنند.

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

لینک مقاله اصلی:

https://www.scrum.org/resources/blog/better-way-staggered-iterations-delivery

مدرسه اسکرام ، مرجع حرفه ای آموزش اسکرام