پیچک وقتی من رفتم یه استارتاپ کوچیک در حال رشد بود و دغدغه مدیران، مدیریت رشد و بهینه شدن کار نیروها. به طبعش با جستجوهای فراوان به اسکرام رسیدن! اسکرام توی پیچک تقریبا ۳ بار پیاده شده و هر سه بار شکست خورد به این دلایل:
۱- بجز برای تیمهای دولوپمنت برای سایرین (از ops تا بقیه)/
۱- بجز برای تیمهای دولوپمنت برای سایرین (از ops تا بقیه)/
قابل استفاده نبود.
۲- حتی در تیمهای دولوپمنت امکان پایبندی به تسکهایی که در شروع اسپرینت برنامه‌ریزی شده بود وجود نداشت چون اولویتها ممکن بود در حین اسپرینت تغییر کنه و عملا اسپرینت (طبق قوانین اسکرام) باید میشکست.
هر بار که این پیاده‌سازی شکست میخورد ما فرض میکردیم که ما داریم/
۲- حتی در تیمهای دولوپمنت امکان پایبندی به تسکهایی که در شروع اسپرینت برنامه‌ریزی شده بود وجود نداشت چون اولویتها ممکن بود در حین اسپرینت تغییر کنه و عملا اسپرینت (طبق قوانین اسکرام) باید میشکست.
هر بار که این پیاده‌سازی شکست میخورد ما فرض میکردیم که ما داریم/
اشتباه میکنیم، ولی در نهایت پذیرفتیم که مشکل از ما نیست و خود اسکرام متد خوبی برای تولید نرم‌افزار نیست، و یه سری از روشهای پایه رو ازش برداشتیم و قوانین مدیریت تسکها رو بر اساس کانبان چیدیم و از اون به بعد دیگه تغییر عمده‌ای نداشتیم. /
اسنپ با اینکه هم از لحاظ مالی و هم نیروی انسانی رشد کرده بود ولی از لحاظ مدریتی ضعیف بود. در اونجا هم به دلیل دغدغه معمول رفتن یه نفر از یه شرکت گنده دیگه آوردن که بشه اسکرام مستر بخش فنی. مهمترین چیزی که ذهنم رو همون اول مشغول کرد اینه که اون شرکتی که این شخص ازش اومده بود اصلا/
کارنامه خوبی در توسعه سرویس پایه خودشون نداشتن حالا اینجا میخواد چیکار کنه ...
کلاسهای بسیار گذاشته شد در مورد اصول پایه اسکرام، همه‌ی تیمها موظف شدن که در مورد دیلی و اسپرینت و بقیه چیزها گزارش بدن. البته همین که از کل کلاسهای طرف فقط دو اسلاید در مورد رلیز و صفر اسلاید در/
کلاسهای بسیار گذاشته شد در مورد اصول پایه اسکرام، همه‌ی تیمها موظف شدن که در مورد دیلی و اسپرینت و بقیه چیزها گزارش بدن. البته همین که از کل کلاسهای طرف فقط دو اسلاید در مورد رلیز و صفر اسلاید در/
مورد maintenace داشت میشد نتیجه رو حدس زد. و از هفته دوم یا سوم طبق معمول تنها چیزی که از این مسائل باقی موند یه دیلی بود که بچه‌ها دور هم خوش بودن.
اسکرام مشخصا برای تیمهای ops کاربردی نبود ولی من چون توی بقیه‌ی تیمها نبودم تخمین خوبی از عملکرد بقیه ندارم. در مجموع
اسکرام مشخصا برای تیمهای ops کاربردی نبود ولی من چون توی بقیه‌ی تیمها نبودم تخمین خوبی از عملکرد بقیه ندارم. در مجموع
برای اسنپ بد نبود، چون از بی‌برنامه‌گی محض یکم اومد بیرون.
در آروان هم مثل شرکتهای دیگه یه تصور کتاب مقدسی به اسم اسکرام درش وجود داشت، و سیر تغییر تحول تقریبا شبیه دو شرکت قبل بود. اول خیلی تاکید بر اجرا مو به مو اسکرام، تاکید (برای من بسیار آزار دهنده) بر اجرای دیلی سر ساعت/
در آروان هم مثل شرکتهای دیگه یه تصور کتاب مقدسی به اسم اسکرام درش وجود داشت، و سیر تغییر تحول تقریبا شبیه دو شرکت قبل بود. اول خیلی تاکید بر اجرا مو به مو اسکرام، تاکید (برای من بسیار آزار دهنده) بر اجرای دیلی سر ساعت/
مشخص در صبح، و تاکید بر اجرای اسپرینت پلنینگ دقیق برای به نتیجه رسوندن حداکثر چیزهایی که براش برنامه‌ریزی شده. و اینجا هم طبق انتظار، اکثر پروسه شکست خورد و در نهایت اکثر تیمها به مدل ترکیبی کانبان-اسکرام بر اساس نیازهای خودشون رسیدن.
در نهایت نظر خودم در مورد task management:
/
در نهایت نظر خودم در مورد task management:
/
اسکرام از دید من یک متدلوژی با practiceهای خوبی و قوانین بد هست.
مهمترین قضیه که اسکرام در نظر نگرفته اینه که release و maintenace جزئی از چرخه توسعه نرم‌افزار هستن.
بر همین اساس، هر متدلوژی که این بخش رو در نظر نگیره توی روال کاری مشکل ایجاد میکنه.
مهمترین قضیه که اسکرام در نظر نگرفته اینه که release و maintenace جزئی از چرخه توسعه نرم‌افزار هستن.
بر همین اساس، هر متدلوژی که این بخش رو در نظر نگیره توی روال کاری مشکل ایجاد میکنه.
در مورد اسکرام پیشنهاد میکنم متانسب با شرایط شرکتتون هر کدوم از بخشهایی که میتونه مفید باشه رو پیاده کنید.
پیشنهاد من در مورد خوبها و بدهای اسکرام:
خوبها:
دیلی استنداپ: خوبه که تیم هر روز با هم سینک بشن که چه کارهای انجام دادن و چه کارهایی انجام ندادن و جلسات هم کوتاه باشه،/
پیشنهاد من در مورد خوبها و بدهای اسکرام:
خوبها:
دیلی استنداپ: خوبه که تیم هر روز با هم سینک بشن که چه کارهای انجام دادن و چه کارهایی انجام ندادن و جلسات هم کوتاه باشه،/
بین ۵ تا ۱۰ دقیقه. ولی هدف رو گم نکنید. هدف تبادل اطلاعات بین "همه" اعضای تیمه، نه حضور غیاب. در زمان انجامش منظم ولی منعطف باشید (تیم ما معمولا ساعت یک برگزار میکنه)
اسپرینت ریویو: نه به معنی اجرای اسپرینت، بلکه به معنی این که جلساتی بصورت منظم (مثلا دو هفته‌ای) وجود داشته باشه/
اسپرینت ریویو: نه به معنی اجرای اسپرینت، بلکه به معنی این که جلساتی بصورت منظم (مثلا دو هفته‌ای) وجود داشته باشه/
که طرفهای مختلف دخیل در محصول درش حضور داشته باشن تا جوانب فنی و بیزینسی سنجیده بشه. این جلسه میتونه با تعیین اولویت‌بندی‌ها یا نیازسنجی اونها همزمان باشه.
بدها:
اسپرینت بسته: در اکثر موارد مخصوصا وقتی که دارید روی سیستم پروداکش دولوپ میکنید، فقط یک درصدی از اولویتها از سمت /
بدها:
اسپرینت بسته: در اکثر موارد مخصوصا وقتی که دارید روی سیستم پروداکش دولوپ میکنید، فقط یک درصدی از اولویتها از سمت /
بیزینس بصورت برنامه‌ریزی شده وارد میشن، اونها رو به خوبی مدریت کنید، ولی باید بدونید که محصول پروداکشن به خودی خود رو دولوپمنت شما فیدبک داره و خیلی سریع میتونه اولویت رو جابجا کنه و معمولا نمیشه کل تسکها رو دوهفته‌ای بست و اولویتهای وارد شده از پروداکشن مثل باگ سیستم یا مشکلی/
اساسی UX که باعث شلوغ شدن پشتیبانی میشه بی‌توجهی کرد. در اولویت‌بندی منعطف باشید و در صورت نیاز عوضش کنید.
خیلی وقتهای ممکنه از اون طرف بوم بیوفتید و کل کارهای شما بشه اصطلاحا firefighting. سعی کنید زمان رو تقسیم کنید و درصدی از کارها رو از روی برنامه‌ریزی قبلی همیشه جلو ببرید./
خیلی وقتهای ممکنه از اون طرف بوم بیوفتید و کل کارهای شما بشه اصطلاحا firefighting. سعی کنید زمان رو تقسیم کنید و درصدی از کارها رو از روی برنامه‌ریزی قبلی همیشه جلو ببرید./
اگر اینم ممکن نیست، افرادی که کار firefighting رو انجام میدن مشخصا جدا کنید و بصورت دوره‌ای عوض کنید.
کتاب مقدس اسکرام: این توصیه من به مدیران هست: اسکرام و قوانینش ضعفهای عمده‌ای دارن، اگر میخواید اسکرام رو هم پیاده کنید، در نظر بگیرید که این ضعفها رو باید درستش کنید. بنظر من/
کتاب مقدس اسکرام: این توصیه من به مدیران هست: اسکرام و قوانینش ضعفهای عمده‌ای دارن، اگر میخواید اسکرام رو هم پیاده کنید، در نظر بگیرید که این ضعفها رو باید درستش کنید. بنظر من/
بجای تاکید بر قوانین، نظم ورود خروج یا نظم جلسات، تاکیدتون بر visualization کارهای انجام شده، کوتاه کردن زمان Value Chain و کیفیت دلیوری، همراه رفع بدهی‌های فنی باشه. البته اینا هم نیاز مداخله بصورت مربی ممکنه داشته باشه، ولی اگر خودتون تجربه و دانشش رو ندارید خواهشن مربی نشید!/
بقیه بخشهای اسکرام رو متناسب با نیاز شرکت به سیستم اضافه کنید. کلا خوبه که در موردش مطالعه داشته باشید تا ازش ایده بگیرید.
در مورد قوانین برای محدود کردن پروسه task management پیشنهاد من قوانین کانبان هست که هم منعطفن و هم تقریبا همه جا کاربردی./
در مورد قوانین برای محدود کردن پروسه task management پیشنهاد من قوانین کانبان هست که هم منعطفن و هم تقریبا همه جا کاربردی./
قوانینی مثل تاکید بر اتمام تسک بجای شروع تسک جدید (stop starting, start finishing)، تاکید بر محدود کردن تعداد تسکهای جاری، اولویت بندی مداوم backlog، و visualization وضعیت تیم از لحاظ پیشرفت در تسکها.
چون رشته توییت طولانی هست از threadreader بخونید:
