جنگولرن

جنگولرن

سری مهندسی نرم‌افزار: پست 9 از لینکدین Saeed Shahrivari Joghan اسکرام: قدیمی، سبک، پر حاشیه در پست‌های قبلی خدمتتون عرض کردم روش‌های چابک معمولاً با استفاده از فرآیند توسعه تکرارشونده و افزایشی با چاشنی فیدبک مستمر سعی در هضم تغییرات دارند و با استفاده از…

سری مهندسی نرم‌افزار: پست 10
از لینکدین Saeed Shahrivari Joghan
اسکرام چکش طلایی نیست!

در پست قبلی اجمالاً راجع به چارچوب بودن اسکرام صحبت کردم. مجدداً تاکید می‌کنم که من طرفدار اسکرام نیستم ولی شدیداً با روال توسعه بی‌برنامه و یلخی هم مشکل دارم. من اخیراً تیم‌های زیادی رو دیدم که با توسل به حربه «ما داریم کنبان کار می‌کنیم» بدون داشتن فرآیند تکرارشونده حرکت می‌کنند و متاسفانه حتی قوانین پایه کنبان مثل «تعیین WIP» رو هم اجرا نمی‌کنند و یا در برخی موارد من زیاد دیدم که مدیر تیم بدون برگزاری حتی یک جلسه گروهی در ماه صرفا به صورت هفته به هفته و با استفاده از یک دفترچه و جلسات یک به یک به اعضای تیم وظایف هفتگی می‌ده. اغلب مخالفین سرسخت اسکرامی که من تا به حال دیدم خودشون یکبار به صورت عمیق راجع بهش مطالعه نکردنند و یا در برخی موارد حوصله روال و قانون رو ندارند. بدیهیه که برای هر پروژه‌ای اسکرام و حتی اجایل ممکنه مناسب نباشه و خیلی جاها همون تکنیک «مدیر + دفترچه یادداشت + جلسات تک به تک» ممکنه کار کنه ولی من مطابق تجربه خودم در بازار طی سال‌های اخیر به این رسیدم که روش‌های چابک در خیلی از پروژه‌ها کار می‌کنند فقط باید از روش چابک مناسب، در جای مناسب، و با تیلورینگ/کاستومایزیشن مناسب استفاده کرد (بازم تاکید می‌کنم که تیلورینگ به معنی تغییرات اساسی در چارچوب نیست بلکه به معنی انطباق روش با شرایطه). معمولاً در سازمان‌های بالای ۱۰۰ نفر، استفاده از مشاوره و یا همکاری یک فرد مسلط و با تجربه در زمینه چابکی می‌تونه خیلی کمک‌کننده باشه.

واقعیت تلخ و شاید شیرین اینه که اسکرام برای هر پروژه‌ای مناسب نیست! اسکرام معمولاً برای پروژه‌های با پیچیدگی بیزینسی بالا که نیاز به انعطاف بالایی در اجرا دارند مناسبه. برای چند نمونه از جاهایی که استفاده از اسکرام فایده‌ی زیادی نداره میشه به این موارد اشاره کرد:
◀️ پروژه‌های کوتاه مثلاً در حد یکی دو ماه
◀️ پروژه‌های که تیم‌های خیلی بزرگ و پراکنده از نظر جغرافیایی دارند. در این موارد شاید استفاده از چارچوب‌های مثل SAFe بهتر باشه
◀️ تیم‌هایی که بیشتر درگیر نگهداشت محصول هستند و بیشتر تیکت حل می‌کنند مثلاً تیم‌های DevOps و SRE (البته نه همیشه)
◀️ تیم‌هایی که کراس-فانکشنال نیستند مثلاً یه تیم UX و یا DevOps مستقل (بازم نه همیشه)
◀️ پروژه‌هایی که کل مسیر و گانت از اول تا آخر واضح و مشخصه و تغییری هم توش نخواهد بود
◀️ پروژه‌های خیلی خیلی تکنیکال مثلاً طراحی و توسعه یه هسته جدید برای یک سیستم‌عامل نهفته
◀️ تیم‌هایی که اصلاً به اسکرام و حتی در مرتبه بالاتر به چابکی اعتقادی ندارند

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

👍1

www.tgoop.com/djangolearn_ir/715

1.46K viewsApr 12, 2024 at 05:45

سری مهندسی نرم‌افزار: پست 10
از لینکدین Saeed Shahrivari Joghan
اسکرام چکش طلایی نیست!

در پست قبلی اجمالاً راجع به چارچوب بودن اسکرام صحبت کردم. مجدداً تاکید می‌کنم که من طرفدار اسکرام نیستم ولی شدیداً با روال توسعه بی‌برنامه و یلخی هم مشکل دارم. من اخیراً تیم‌های زیادی رو دیدم که با توسل به حربه «ما داریم کنبان کار می‌کنیم» بدون داشتن فرآیند تکرارشونده حرکت می‌کنند و متاسفانه حتی قوانین پایه کنبان مثل «تعیین WIP» رو هم اجرا نمی‌کنند و یا در برخی موارد من زیاد دیدم که مدیر تیم بدون برگزاری حتی یک جلسه گروهی در ماه صرفا به صورت هفته به هفته و با استفاده از یک دفترچه و جلسات یک به یک به اعضای تیم وظایف هفتگی می‌ده. اغلب مخالفین سرسخت اسکرامی که من تا به حال دیدم خودشون یکبار به صورت عمیق راجع بهش مطالعه نکردنند و یا در برخی موارد حوصله روال و قانون رو ندارند. بدیهیه که برای هر پروژه‌ای اسکرام و حتی اجایل ممکنه مناسب نباشه و خیلی جاها همون تکنیک «مدیر + دفترچه یادداشت + جلسات تک به تک» ممکنه کار کنه ولی من مطابق تجربه خودم در بازار طی سال‌های اخیر به این رسیدم که روش‌های چابک در خیلی از پروژه‌ها کار می‌کنند فقط باید از روش چابک مناسب، در جای مناسب، و با تیلورینگ/کاستومایزیشن مناسب استفاده کرد (بازم تاکید می‌کنم که تیلورینگ به معنی تغییرات اساسی در چارچوب نیست بلکه به معنی انطباق روش با شرایطه). معمولاً در سازمان‌های بالای ۱۰۰ نفر، استفاده از مشاوره و یا همکاری یک فرد مسلط و با تجربه در زمینه چابکی می‌تونه خیلی کمک‌کننده باشه.

واقعیت تلخ و شاید شیرین اینه که اسکرام برای هر پروژه‌ای مناسب نیست! اسکرام معمولاً برای پروژه‌های با پیچیدگی بیزینسی بالا که نیاز به انعطاف بالایی در اجرا دارند مناسبه. برای چند نمونه از جاهایی که استفاده از اسکرام فایده‌ی زیادی نداره میشه به این موارد اشاره کرد:
◀️ پروژه‌های کوتاه مثلاً در حد یکی دو ماه
◀️ پروژه‌های که تیم‌های خیلی بزرگ و پراکنده از نظر جغرافیایی دارند. در این موارد شاید استفاده از چارچوب‌های مثل SAFe بهتر باشه
◀️ تیم‌هایی که بیشتر درگیر نگهداشت محصول هستند و بیشتر تیکت حل می‌کنند مثلاً تیم‌های DevOps و SRE (البته نه همیشه)
◀️ تیم‌هایی که کراس-فانکشنال نیستند مثلاً یه تیم UX و یا DevOps مستقل (بازم نه همیشه)
◀️ پروژه‌هایی که کل مسیر و گانت از اول تا آخر واضح و مشخصه و تغییری هم توش نخواهد بود
◀️ پروژه‌های خیلی خیلی تکنیکال مثلاً طراحی و توسعه یه هسته جدید برای یک سیستم‌عامل نهفته
◀️ تیم‌هایی که اصلاً به اسکرام و حتی در مرتبه بالاتر به چابکی اعتقادی ندارند

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

BY جنگولرن