My Authors
Read all threads
چرا #اسکرام اولین قدم اشتباه در مسیری درست است؟
#رشتو در حسن و قبح اسکرام
بعد از یه تبادلات توییتی تصمیم گرفتم تجربیات و مشاهدات از پیاده‌سازی اسکرام توی شرکتهایی که بودم بگم و در نهایت مدل پیشنهادی خودم رو توضیح بدم.
من تو سه شرکت تا الان کار کردم. پیچک، اسنپ و الان آروان/
پیچک وقتی من رفتم یه استارتاپ کوچیک در حال رشد بود و دغدغه مدیران، مدیریت رشد و بهینه شدن کار نیروها. به طبعش با جستجوهای فراوان به اسکرام رسیدن! اسکرام توی پیچک تقریبا ۳ بار پیاده شده و هر سه بار شکست خورد به این دلایل:
۱- بجز برای تیمهای دولوپمنت برای سایرین (از ops تا بقیه)/
قابل استفاده نبود.
۲- حتی در تیمهای دولوپمنت امکان پایبندی به تسکهایی که در شروع اسپرینت برنامه‌ریزی شده بود وجود نداشت چون اولویتها ممکن بود در حین اسپرینت تغییر کنه و عملا اسپرینت (طبق قوانین اسکرام) باید میشکست.
هر بار که این پیاده‌سازی شکست میخورد ما فرض میکردیم که ما داریم/
اشتباه میکنیم، ولی در نهایت پذیرفتیم که مشکل از ما نیست و خود اسکرام متد خوبی برای تولید نرم‌افزار نیست، و یه سری از روشهای پایه رو ازش برداشتیم و قوانین مدیریت تسکها رو بر اساس کانبان چیدیم و از اون به بعد دیگه تغییر عمده‌ای نداشتیم. /
اسنپ با اینکه هم از لحاظ مالی و هم نیروی انسانی رشد کرده بود ولی از لحاظ مدریتی ضعیف بود. در اونجا هم به دلیل دغدغه معمول رفتن یه نفر از یه شرکت گنده دیگه آوردن که بشه اسکرام مستر بخش فنی. مهمترین چیزی که ذهنم رو همون اول مشغول کرد اینه که اون شرکتی که این شخص ازش اومده بود اصلا/
کارنامه خوبی در توسعه سرویس پایه خودشون نداشتن حالا اینجا میخواد چیکار کنه ...
کلاسهای بسیار گذاشته شد در مورد اصول پایه اسکرام، همه‌ی تیمها موظف شدن که در مورد دیلی و اسپرینت و بقیه چیزها گزارش بدن. البته همین که از کل کلاسهای طرف فقط دو اسلاید در مورد رلیز و صفر اسلاید در/
مورد maintenace داشت میشد نتیجه رو حدس زد. و از هفته دوم یا سوم طبق معمول تنها چیزی که از این مسائل باقی موند یه دیلی بود که بچه‌ها دور هم خوش بودن.
اسکرام مشخصا برای تیمهای ops کاربردی نبود ولی من چون توی بقیه‌ی تیمها نبودم تخمین خوبی از عملکرد بقیه ندارم. در مجموع
برای اسنپ بد نبود، چون از بی‌برنامه‌گی محض یکم اومد بیرون.

در آروان هم مثل شرکتهای دیگه یه تصور کتاب مقدسی به اسم اسکرام درش وجود داشت، و سیر تغییر تحول تقریبا شبیه دو شرکت قبل بود. اول خیلی تاکید بر اجرا مو به مو اسکرام، تاکید (برای من بسیار آزار دهنده) بر اجرای دیلی سر ساعت/
مشخص در صبح، و تاکید بر اجرای اسپرینت پلنینگ دقیق برای به نتیجه رسوندن حداکثر چیزهایی که براش برنامه‌ریزی شده. و اینجا هم طبق انتظار، اکثر پروسه شکست خورد و در نهایت اکثر تیمها به مدل ترکیبی کانبان-اسکرام بر اساس نیازهای خودشون رسیدن.

در نهایت نظر خودم در مورد task management:
/
اسکرام از دید من یک متدلوژی با practiceهای خوبی و قوانین بد هست.
مهمترین قضیه که اسکرام در نظر نگرفته اینه که release و maintenace جزئی از چرخه توسعه نرم‌افزار هستن.
بر همین اساس، هر متدلوژی که این بخش رو در نظر نگیره توی روال کاری مشکل ایجاد میکنه.
در مورد اسکرام پیشنهاد میکنم متانسب با شرایط شرکتتون هر کدوم از بخشهایی که میتونه مفید باشه رو پیاده کنید.
پیشنهاد من در مورد خوبها و بدهای اسکرام:
خوبها:
دیلی استنداپ: خوبه که تیم هر روز با هم سینک بشن که چه کارهای انجام دادن و چه کارهایی انجام ندادن و جلسات هم کوتاه باشه،/
بین ۵ تا ۱۰ دقیقه. ولی هدف رو گم نکنید. هدف تبادل اطلاعات بین "همه" اعضای تیمه، نه حضور غیاب. در زمان انجامش منظم ولی منعطف باشید (تیم ما معمولا ساعت یک برگزار میکنه)
اسپرینت ریویو: نه به معنی اجرای اسپرینت، بلکه به معنی این که جلساتی بصورت منظم (مثلا دو هفته‌ای) وجود داشته باشه/
که طرفهای مختلف دخیل در محصول درش حضور داشته باشن تا جوانب فنی و بیزینسی سنجیده بشه. این جلسه میتونه با تعیین اولویت‌بندی‌ها یا نیازسنجی اونها همزمان باشه.

بدها:
اسپرینت بسته: در اکثر موارد مخصوصا وقتی که دارید روی سیستم پروداکش دولوپ میکنید، فقط یک درصدی از اولویتها از سمت /
بیزینس بصورت برنامه‌ریزی شده وارد میشن، اونها رو به خوبی مدریت کنید، ولی باید بدونید که محصول پروداکشن به خودی خود رو دولوپمنت شما فیدبک داره و خیلی سریع میتونه اولویت رو جابجا کنه و معمولا نمیشه کل تسکها رو دوهفته‌ای بست و اولویتهای وارد شده از پروداکشن مثل باگ سیستم یا مشکلی/
اساسی UX که باعث شلوغ شدن پشتیبانی میشه بی‌توجهی کرد. در اولویت‌بندی منعطف باشید و در صورت نیاز عوضش کنید.
خیلی وقتهای ممکنه از اون طرف بوم بیوفتید و کل کارهای شما بشه اصطلاحا firefighting. سعی کنید زمان رو تقسیم کنید و درصدی از کارها رو از روی برنامه‌ریزی قبلی همیشه جلو ببرید./
اگر اینم ممکن نیست، افرادی که کار firefighting رو انجام میدن مشخصا جدا کنید و بصورت دوره‌ای عوض کنید.
کتاب مقدس اسکرام: این توصیه من به مدیران هست: اسکرام و قوانینش ضعفهای عمده‌ای دارن، اگر میخواید اسکرام رو هم پیاده کنید، در نظر بگیرید که این ضعفها رو باید درستش کنید. بنظر من/
بجای تاکید بر قوانین، نظم ورود خروج یا نظم جلسات، تاکیدتون بر visualization کارهای انجام شده، کوتاه کردن زمان Value Chain و کیفیت دلیوری، همراه رفع بدهی‌های فنی باشه. البته اینا هم نیاز مداخله بصورت مربی ممکنه داشته باشه، ولی اگر خودتون تجربه و دانشش رو ندارید خواهشن مربی نشید!/
بقیه بخشهای اسکرام رو متناسب با نیاز شرکت به سیستم اضافه کنید. کلا خوبه که در موردش مطالعه داشته باشید تا ازش ایده بگیرید.
در مورد قوانین برای محدود کردن پروسه task management پیشنهاد من قوانین کانبان هست که هم منعطفن و هم تقریبا همه جا کاربردی./
قوانینی مثل تاکید بر اتمام تسک بجای شروع تسک جدید (stop starting, start finishing)، تاکید بر محدود کردن تعداد تسکهای جاری، اولویت بندی مداوم backlog، و visualization وضعیت تیم از لحاظ پیشرفت در تسکها.
چون رشته توییت طولانی هست از threadreader بخونید:
Missing some Tweet in this thread? You can try to force a refresh.

Enjoying this thread?

Keep Current with Vahid Ashrafian

Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

Twitter may remove this content at anytime, convert it as a PDF, save and print for later use!

Try unrolling a thread yourself!

how to unroll video

1) Follow Thread Reader App on Twitter so you can easily mention us!

2) Go to a Twitter thread (series of Tweets by the same owner) and mention us with a keyword "unroll" @threadreaderapp unroll

You can practice here first or read more on our help page!

Follow Us on Twitter!

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just three indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3.00/month or $30.00/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!