اغلب ما در تیم های اسکرام سخت کار می کنیم، اما نه لزوما هوشمندانه تر. بنابراین نحوه کار ما باید تغییر کند. پنج نکته برای کار چابک موثرتر.

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

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

آیا می دانید چه چیزی در چابک بودن موثر است؟

چیزی که من اغلب می توانم مشاهده کنم این است که تیم ها در حالت آبشار کوچک (mini-waterfall) کار می کنند.
یعنی در اسپرینت اسکرام آنها در چهار یا پنج مرحله کار می کنند.

این چیزی شبیه به چنین طرحی است:

مشکلی که در این مورد وجود دارد این است که فقط باعث می شود بیشتر کار کنیم، نه هوشمندتر.

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

بیایید روی “تست کردن” تمرکز کنیم. این بدان معنی است که تیم ها در مورد “تست کردن” (نقش تست کننده) و “تست کردن” به عنوان مرحله ای از توسعه نرم افزار یا مأموریت و تسک صحبت می کنند.
این رویکرد شبیه این طرح است:

آیا شباهت با رویکرد آبشاری را می بینید؟
و آیا مشکلی که معمولاً بعد از آن بروز می کند را متوجه می شوید؟

طبق تجربه من ، این همان چیزی است که معمولاً اتفاق می افتد:

“آه … ما هنوز کار توسعه رو کامل نکردیم.”
“می تونید تست رو متوقف کنید؟”
“نمیشه اسپرینت بعدی بطور کامل فقط تست رو انجام بدین؟ ما هنوز مشغول کاریم!”

این باید زنگ خطر باشد.

این معمولاً همان چیزی است که مجسم می شود:

این بدین معنی است که زمان تست بسیار کوتاه خواهد بود. به ندرت، بعداً انجام می شود یا در دسته های بزرگ تست می شود (خیلی زیاد به یک باره و دسته جمعی)، و این منجر به سرزنش، شب های طولانی تست، ادغام دیرهنگام، استقرارهای یک ماه در میان و ناامیدی عمومی می شود.

بنابراین چگونه می توانیم آن را برطرف کنیم؟

نحوه رسیدن از رویکرد آبشاری به اسپرینت های 1 هفته ای

آنچه تجربه من در موردش خوب کار می کند، موارد زیر است (شاید بتوان گفت پیشرفت در تیم):

1. ما بر روی جریان تک قطعه ای تمرکز می کنیم
این یک تفکر از فلسفه Lean است، جایی که ما یک کار کوچک را به پایان می رسانیم و فقط پس از آن کار بعدی را می گیریم.

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

3. ما تست های زیادی را خودکار انجام می دهیم
… و این می تواند ما را به عنوان انسان در تست های اکتشافی دستی (manual exploratory tests) که جذاب هم هستند متمرکز کند. انسان ها ماشین های خودکار بدی هستند. نرم افزارها و ماشین ها در بررسی موارد خودکار خسته کننده بسیار بهتر عمل می کنند.

4. ما تست محور کار می کنیم
یک تست قرمز این دید را به ما می دهد که باید یک فیچر را اضافه کنیم یا دوباره بسازیم. ما از تست ها به عنوان شاخص استفاده می کنیم: تست ها نشان می دهند که کارهایی برای تکمیل و Done شدن وجود دارد.

5. ما به ساخت بهترین سیستم کمک می کنیم
… از طریق ارتباط اولیه با سوالات و تمرکز بر کیفیت. اکنون تیم وقت بیشتری برای برقراری ارتباط با دنیای خارج و به چالش کشیدن، مدل سازی و اعتبار سنجی ایده ها، فرضیه ها و الزامات دارد. دنیای خارج از “ذینفعان” (stakeholders) تشکیل شده است: کاربران، مدیران و سایر طرف های درگیر.

اگر مطابق آنچه در موارد 1 تا 5 گفته شده است کار می کنید، روند شما معمولاً به این شکل است:

چگونه می توان در مورد آن تجدید نظر کرد:
• تست یک فعالیت است. (نه یک فاز جداگانه در انتهای کار)
• تست کردن در تمام طول فرآیند توسعه و مکرراً انجام می شود.

کاری که باید متفاوت انجام دهید:
• تست های خودکار ما چیزی است که فرآیند توسعه را پیش می برد.
• تست های خودکار ما معماری را پیش می برد.
• تمام تست های سبز به معنای آن است که “کار ما تمام شده (Done)” .

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

https://www.scrum.org/resources/blog/5-practices-help-agile-software-development

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