وقتی از متد های اجایل صحبت میکنیم اکثر بحث ها به اسکرام ختم میشه. اسکرام یک سری پند و اندرز داره برامون که میگه اگر به اینها عمل کنین، رستگار میشین. داستانش از اونجایی شروع میشه که...
روزی روزگاری یه شرکت بزرگ بود که با مشکل ناهماهنگی کارکنان، نرسیدن به ددلاین های پروژه، نامنظمی کارمنداش دستو پنجه نرم میکرد، یه شب مدیر تیم اپلیکیشن با ناراحتی به خونه میرسه، وسایلشو میذاره روی زمین و خوابش میبره... چشماشو باز میکنه، ولی تار میبینه اطراف رو،یه برگه کهنه که جلوش افتاده نظرشو جلب میکنه، روی برگه نوشته شده "SCRUM" ... بازش میکنه که یه دفعه نوری از درون برگه میزنه بیرون و همه جا رو روشن میکنه به قدری که محیط اطراف همه سفید میشه و بعد مدیر تیم خودشو توی محیطی میبینه که همه خوشحالن، همه دارن کار میکنن، همه پروژه ها منظمه، همه ددلاین ها ساکسز شدن... نور محو میشه و ۵ جمله روی اون برگه میبیینه و بالای برگه نوشته، "برای آنان که فکر میکنن"...
این ها کلیات هستند ولی در عمل چه اتفاقی میوفته؟ تجربه واقعی میگه که همه در تیم مشارکت نمیکنند. همه تلاش واحد و یکسانی ندارند. ایجاد اشتیاق برای کسی که داره زیاد تلاش میکنه با کسی که معمولی قدم بر میداره سخته و حفظ تعادل پیچیده میشه.
اگر بخوایم قدم قدم بریم اینجوری اسکرام رو پیاده سازی میکنیم. ما اینجوری اسکرام رو پیاده سازی کردیم
اول ما به یه تیم نیاز داریم، دو نفر یا بیشتر نیرو...
مرحله دوم انتخاب Product-Owner هستش.
ما یک نفر به نام Product-Owner داریم. این نقش(در تیم) وظیفه ارتباط با بیرون، تهیه نیازمندی های تیم برای انجام یک تسک و تحویل گرفتن اون تسک بعد از تموم شدن رو داره. ولی مهمترین وظیفه اینه که تیم برای تصمیم هایی که نمیتونه بگیره یا راهی که نمیدونه الان باید دقیقا کدوم رو انتخاب کنه به یک تصمیم نهایی داره. کسی که حرف نهایی رو روی تسک هایی که ابهام دارن بزنه. این وظیفه مدیر محصول هستش.
کارها توسط مدیر محصول مشخص میشن و اولویت ها بررسی میشند. توی اسکرام ما اسپرینت داریم، یعنی برای مثال روز اول هفته میشینیم و کارهای دو هفته اینده رو در میاریم و شروع به انجامشون میکنیم. مدت زمان اسپرینت ها معمولا با توجه به ماهیت پروژه تعیین میشن. در نتیجه میتونن هفتگی، دو هفته یا ماهانه باشند ولی معمولا کمتر از یک هفته نمیتونن باشن. پس اسپرینت چیه؟ یه بازه زمانی مثل یک هفته یا چند هفته، که از قبل کارهایی که باید تو این مدت انجام بشه رو در میاریم و میگیم اخر اسپرینت باید این کارها تموم شده باشند. یکی از دلایل جذاب برای اینکه اسپرینت داشته باشیم اینه که ما یه کار بزرگ (ساختن یه پروژه) رو به کارهای کوچیک تقسیم میکنیم، اسپرینت علاوه بر این، اولویت ها رو هم برامون در میاره یعنی شما توی هر اسپرینت میدونین چه چیزی از همه مهمتره و باید اول انجام بشه، شما کلی تسک دارین که مشت مشت (اسپرینت اسپرینت) برشون میدارین، دسته بندی میکنین و انجامشون میدین.
پس مرحله سوم میتونه این باشه که پروژه رو بشناسیم و تعیین کنیم که هر اسپرینت ما چند هفته باشه. ما دو هفته ای اسپرینت ها رو میبندیم.
بعد از این باید بیایم سراغ کارهایی که باید انجام شه. کارها واحد هایی از پروژه هستند که باید انجام شن. ساخت لاگین، ساخت صفحه پروفایل و ... ما یه سبد داریم که تسک ها رو میریزم توش، مثل یه فایل در نظر بگیرین که همینجوری تسک هارو بش اضافه میکنیم. یه گونی، سبد یا هر چیزی و به اون بکلاگ Backlog میگیم. بکلاگ شامل همه کارهاییه که باید انجام بشه. روز اول ما همه کارهارو نمیدونیم. هرچی میدونیم رو به بک لاگ اضافه میکنیم و هرچی که در اینده به ذهنمون رسید، مشتری خواست یا باگی ایرادی چیزی دیدیم به بک لاگ اضافه میکنیم. همه تیم میتونن به این بکلاگ کار اضافه کنند. پس قدم چهارم میتونه این باشه که یه لیست از کارهایی که باید انجام بشه در بیاریم مهم نیست که همه کارها رو بدونیم یا همه رو از اول به بکلاگ اضافه کنیم. هرچی که میدونیم رو اضافه میکنیم و در اینده هرچی نیاز بود بازم میریزیم تو سبد بکلاگمون.
قدم پنجم اینجاست که Product-Owner باید بیاد و بررسی کنه. بکلاگ رو چک میکنه، با مشتری یا هرکسی دیگه ای که باید، چک میکنه و در نهایت تسک ها رو اولویت بندی میکنه یعنی اونایی که باید سریعتر انجام بشن میان بالای لیست، اینکار به صورت مداوم انجام میشه و هروقت فرصت میکنه اینکارو باید انجام بده، لیست رو اپدیت میکنه.
خب شما کارهایی که باید انجام بدین رو دارین (بکلاگ) اولویتشون هم که مشخص شده، اینجا تیم باید برای اسپرینتشون برنامه ریزی کنه. چه کارهایی رو باید توی این اسپرینت انجام بده. تیم دور هم جمع میشه و جلسه اسپرینت میذاره، کارهایی که باید انجام بده رو مشخص میکنه.
پس قدم بعدی (۶) برگذاری جلسه اسپرینت هستش. کسایی که باید توی این جلسه باشن تیم و پروداکت اونر حتما باید باشن. ما اینجا بر اساس تعداد اعضای تیم کارها رو بر میداریم و توی اسپرینتمون میذاریم. مثلا میگیم این ۱۰ تا کارو باید توی این دو هفته (مدت اسپرینت) انجام بدیم. از کجا میدونیم که ۱۰ تا کار رو میتونیم انجام بدیم توی دو هفته؟ راستش... اول کار نمیدونیم. ولی کم کم متوجه میشیم که تیم توی هر اسپرینت چندتا کار میتونه انجام بده. ولی کارها همه از یک جنس نیستن یعنی همه یه سایز ندارن. مثلا ساخت صفحه لاگین و کار تغییر متن ؛سلام؛ به سلام بر شما... هر دو یه مقدار زمان نیاز ندارند پس اینکه چنتا کار توی یه اسپرینت میشه انجام داد به دو عامل بستگی داره :
پس ما باید یه راهی پیدا کنیم که ببینم توی این اسپرینت چنتا کار میتونیم انجام بدیم. اینجا مفهومی به نام استوری پوینت Story Point داریم. این یه مقیاس از سایز کاری (از نظر زمانی) که باید انجام بشه و پیچیدگی اون کار هستش. یعنی مثلا فرض کنین ما ساخت صفحه لاگین رو داریم. باید ببینیم چقدر کار داره ولی خب ما عدد دقیقی نمیدونیم. میایم بش Story Point میدیم. چطور؟
اینجا با یه مفهوم دیگه به نام پوکر پلنینگ Poker Planning اشنا میشیم.
گفتیم توی جلسه اسپرینت، تیم هستند. تسک رو بر میداریم و از تیم میخوایم استوری پوینت بدن. یعنی هرکدوم از اعضای تیم بگن که اینکار چقدر پیچیده هستش. اینکار مثل پوکر انجام میشه. یک دو سه، همه اعضای تیم با هم استوری پوینتی که به این کار دادن رو نمایش میدن مثلا ۱،۲،۳...۱۰۰. معمولا به صورت استاندارد ۱۰۰ بالاترین استوری پوینت هستش و هرچی عدد بزرگتر بشه، از نظر تیم این کار پیچیده تر و زمان برتر است. کارو میزنیم به تخته و استوری پوینت رو روش مینویسیم. با اینکار متوجه میشیم که این کار چقدر پیچیده هستش . کار بعدی رو از بالای بکلاگ بر میداریم و بازم امتیاز گیری میکنیم. راستش اسپرینت های اول نمیدونیم که تیم چند استوری پوینت توی یه اسپرینت میتونن انجام بدن. در نتیجه بر اساس حدسی که میزنیم چنتا کارو برای انجام توی اون اسپرینت بر میداریم. وقتی استوری پوینت ها رو دادیم حالا از تیم میخوایم که بگن به نظرشون اینکار چقدر زمان میبره. دقیقا به ساعت یا روز بگن که حدس میزنن هرکدوم از این کارها چقدر زمان میبره این زمان دادن رو هم به صورت پوکر انجام میدیم. چرا باید همه تیم با هم و همزمان عددهایی که توی ذهنشون دارن رو بگن؟ برای اینکه رای یه نفر روی بقیه تاثیر نذاره. مثلا یکی که فک میکرده کار اسونی ولی یه نفر میگه خیلی سخته و در نهایت نفر اولم میگه شاید من اشتباه میکنم. کلا استوری پوینت دادن و تخمین زمانی از اسمشونو پیداست. عدد دقیقی نیستند و فقط و فقط برای تخمین زدن هستن.
تیم بعد از گذشت چند اسپرینت متوجه میشه که هر کار تقریبا چقدر زمان میخواد و استوری پوینت و زمانی که به یه تخمین مناسب از استوری پوینت و زمان رسیدیم میتونیم جلسه اسپرینت رو سریعتر پیش ببریم و دیگه فقط استوری پوینت بدیم و زمان رو براساس اون تخمینی که بدست اوردیم حساب کنیم. مثلا بعد از ۵ اسپرینت متوجه میشییم که هر ۱۳ استوری پوینت حدود ۱ روز کار میبره یعنی ۸ ساعت در نتیجه هر استوری پوینت ما حدود ۴۵ دقیقه هستش. اینجوری ما یه ویو کلی از تیممون و تواناییشون پیدا میکنیم. اینجوری میتونیم یه تخمین صحیح داشته باشیم و روش برنامه ریزی کنیم. بعد از اینکه کارهایی که باید انجام بشن مشخص شد، Product-Owner میاد و همون تسکهای مربوط به اون اسپرینت رو هم اولویت بندی میکنه یعنی اونایی که اولویت بالاتری دارند، سریعتر باید انجام بشن
پس هدف بعدی مون اسپرینت و پیدا کردن کارهایی شد که باید توی اون اسپرینت انجام بدن.
این جلسات برگزار میشه و کم کم، مشت مشت تسک از توی بکلاگ بالا میاد و انجام میشه تا پروژه تمام و تمام بکلاگ خالی میشه. وقتی کارهای دو هفته مشخص شد، تیم دیگه میتونه کار خودش رو شروع کنه، بدون اینکه به کسی نیاز داشته باشه. تسک ها رو توی جیرا یا هر نرم افزاری که برای مدیریت پروژه داریم میزنیم.
خب اگر تیم بزرگی داریم مثلا ۳ یا بیشتر، جلسه صبحگاهی روزانه رو فراموش نکنیم. هروز صبح سر یه ساعتی که همه میدوونن مثلا ۱۰، پاشیم و درباره کارهایی که امروز میخوایم بکنیم و فردا کمی حرف بزنیم. این خیلی کاربردی و خوبه چون اول اینکه تیم متوجه میشه چه کاری داره انجام میده و دوم اینکه تک تک افراد در جریان کارهای همه تیم هستند و حتی شاید بتونن کمک کنند. این ویژگی از تداخل ها یا اشتباهات کوچیک یا بززرگ تا حد زیادی جلوگیری میکنه. جلسات صبحگاهی رو سرپا برگذار کنیم. چرا؟ وقتی سر پا باشیم، خسته میشیم و این خسته شدن کمک میکنه تا سریعتر جلسه رو تموم کنیم. یعنی از اتلاف وقت و گفتگو درباره چیز های بی مورد جلوگیری میکنه ولی همیشه برگزارش کنین. این جلسه اصلا برای اینکه هرکسی رو زیر نظر داشته باشیم نیست و بیشتر برای اینه که تیم از حال هم با خبر بشه.
اخر هر اسپرینت دوباره جلسه میزاریم و تسک های اون هفته رو تحویل Product-Owner میدیم. ولی بهتره هر تسکی که تموم شد تحویل داده بشه تا اگر ایرادی داره همون موقع گفته بشه و اخر هفته تسک های دان شده کامل رو تحویل میدیم . بعدش درباره این اسپرینت صحبت میکنیم و سعی میکنیم بدی و خوبیاش رو بگیم. چه چیزی باعث شد سریعتر پیش بریم؟ چه چیزی ما رو کند کرد؟ اگر چه اتفاقی میوفتاد بهتر بود و اگر چه اتفاقی نمیوفتاد. یه گفتگو دوستانه برای اینکه بتونیم اسپرینت بعدی بهتر باشیم.
یه نقشی هم داریم به نام اسکرام مستر Scrum Master، این نقش توی تیم وظیفه یاد دادن اسکرام و جا انداختنشو داره. این نقش از دور به اسکرام نگاه میکنه و اگر نیاز بود نزدیک میشه و تیم رو راهنمایی میکنه برای اینکه بهتر اسکرام رو پیاده سازی بکنن. ایده و همه ارزوی اسکرام مستر، اینه که تیم رو سلف اورگنایز کنه Self-Organize کنه. اسکرام مستر حرفها رو میشنوه، اگر نیاز باشه به تیم کمک میکنه، سعی میکنه تک تک اعضای تیم رو SelfOrganize کنه. Self-Organize یعنی چی؟ هرفرد در تیم نیاز داره خودش رو مدیریت کنه، اصطلاحا تیم ها در اسکرام فلت هستند و نقشهایی که بودن مثلا Team Leader و ... کم رنگ یا حذف شدند. هر عضو از تیم باید بتونه خودش و بقیه رو مدریت کنه، هر نفر بدونه چیکار میخواد بکنه، چیکار باید بکنه و مسولیت کارهاشو برعهده بگیره، توی تصمیم گیری ها شرکت کنه و خودش رو به اندازه همه اعضای تیم مسول و تاثیر گذار بدونه. اسکرام مستر یکی یکی از اعضا رو تلاش میکنه Self Organize کنه و وقتی تیم به این ویژگی رسید، دیگه نیاز به ناظر نداره، خودش تسک هاش رو بر میداره، خودش جلسات رو برگزار میکنه، خودش برای پیشبرد پروژه تلاش میکنه. رسیدن به این ويژگی کار پیچیده ای هستش و سخت است چون افراد و اعضای تیم همگی در یک حد نیستند و در نتیجه سخته همه رو به سرعت Self Organize کرد. مطالبی که بالا گفته شد الان درحال انجام هستش روی تیم ما. اگر بخوام بگم اسکرام چه کمکی به ما کرده میتونم به این اشاره کنم که ما هرکدوم میدونیم که باید چه کاری بکنیم و کارها چطور تقسیم شدن. ما همه میدونیم که توی هر اسپرینت باید به کجا برسیم. میتونیم وقت هامونو رو تنظیم کنیم و همچنین ببینیم که اگر وقت خالی داریم اونو مدیریت کنیم با کارهای جانبی.
نقش های مخفی در اسکرام
ایا همه تیم شما از یک دانش و سطح توانایی برخوردارند؟ معمولا اینجور نیست. ما همیشه نمیتونیم ۱۰ سنیور دولوپر در کنار هم داشته باشیم چون هزینه تیم خیلی بالا میرود در نتیجه ترکیبی از سنیور ها و جونیور ها داریم. در اسکرام به فلت بودن تاکید میکنیم ولی در واقعیت نمیشه اینجور جلو رفت. من به شخصه اعتقاد دارم حتی اگر این اسم ها حذف شدند، ولی وجود این نقش ها در تیم کلیدی هستش. معمولا باید افرادی باشن که کد ها رو ریویو کنند، به تیم کمک کنند، از نظر دانشی سوالات رو پاسخ بدن و راهنمایی کنند. وقتی یکی اشتباه میکنه ما تیم رو تنبیه میکنیم ولی ایا بقیه تیم به همون اندازه که اون فرد اشتباه کننده، ناراحت شده، تحت تاثیر قرار میگیره؟ وقتی من مسئول کدهای خودم هستم آیا به اندازه کسی که اشتباه کرده خودمو سرزنش میکنم؟ آیا وقتی تیم فلت هستش کسی از دیگری سوالی میپرسه؟ اگر یکی از اعضا براش اهمیت نداشت و یکی براش اهمیت داشت چه اتفاقی میوفته؟ اگر یه عده کارنکنن و یکی از ترس اینکه کارها بمونه، کارهای بقیه رو انجام بده چی میشه؟ اعضای تیم ها همگی باید یک دست باشند در غیر اینصورت همیشه یه ناظر نیازمند هستش. Team Leader یکی از نقش هایی هستش که در اسکرام حذف شده، team leader ها وظیفه راهنمایی تیم برای بالابردن کیفیت محصول ارایه شده از نظر فنی رو دارند. تیم رو به مسیر درست هدایت میکنند. انتخاب صحیح تکنولوژي، انجام بعضی Code-Reviewها، پاسخ به سوالات تیم، انجام و پیاده سازی صحیح تکنیک ها، این افراد تیم رو بهتر میکنند. وقتی یه عنوان یه مرجع شناخته بشن و تایتلش رو حمل کنند، تیم همیشه میتونه سوالاتشو رو بپرسه ولی اینکه ما بگیم فلت در نتیجه هرکسی برای خودش تصمیم میگیره و پیاده سازی میکنه و نهایتا یه نظر میخواد ولی کار اصلی رو خودش میکنه، این خوبه ولی نمیتونیم تضمین کنیم که بهترین راه رو داره میره.
من خودم صرفا با فلت بودن مخالفم و به نظرم این نمیتونه به تیم کمک کنه که محصول با کیفیت تری بده، میتونه کمک کنه تیم مسولیت پذیر تر شه، ولی نمیتونه کمک کنه کیفیت بالاتر بره. چون برای انجام یه کار، راه های متفاوتی وجود داره ولی هرکسی به اندازه دانش علمیش، اون راه ها رو بلده و نمیشه تضمین کرد که همه بهترین کارو میکنن. فلت بودن تنها زمانی امکان داره که هم از نظر دانش فنی در یک سطح یا نزدیک به هم باشن.
شاید اسم این رولی که من بش اشاره میکنم Team Leader نباشه ولی دقیقا دارم به تعریف صریحش توی ویکی پدیا اشاره میکنم
A team leader is someone who provides guidance, instruction, direction and leadership to a group of individuals (the team) for the purpose of achieving a key result or group of aligned results. The team leader monitors the quantitative and qualitative achievements of the team and reports results to a manager (a manager may oversee multiple teams). The leader often works within the team, as a member, carrying out the same roles but with the additional 'leader' responsibilities
من دارم به کسی اشاره میکنم که تیم برای پرسش های علمی، راهنمایی برای استفاده از یک تکنولوژي، به عنوان یک مرجع برای حل یک مشکل بش اشاره کنه. همیشه در کنار تیم هستش و درکنار تیم هستش و درکنارشون کد میزنه. وقتش کامل در اختیار تیم هستش، در جلسات خارج از تیم شرکت نمیکنه. این فرد میتونه به تیم کمک کنه که پیشرفت کنه.
چرا نیاز است؟ فرهنگ سازی برای ما سخته، قبول اینکه یه نفر از ما بهتر هستش سخته. کم پیش میاد سوالی پرسیده بشه، مخصوصا توی تیم های برنامه نویسی که همه اطلاعاتشون رو سریعا توی stackOverflow جستجو میکنن و فکر میکنن مشکل رو حل کردن در صورتیکه الزاما اون نتیجه بهترین گزینه نیست. راه حل ها زیاده ولی همیشه همه بهترین نیستند. من هدفم اینه که کدهایی که زده میشه بالاترین کیفیت رو داشته باشند. محصولی که ارایه میشه در سطح مناسبی باشه و نگهداری از اون راحت باشه. چند نفر از ما با پروژه های ضعیف و کثیف مواجه شدیم؟ چند نفر از ما با اعتماد به نیروها جلو رفتیم و در نهایت پروژه ای با کیفیت بسیار کم داشتیم؟ چند تا تسک کد ریویو داشتیم و انجام نشده؟ کد ریویو وقتی که ۲۰۰ خط کد زده شد چه فایده ای داره؟ ایا شما به یکی میگی همه رو از اول بزن وقتی ۱ هفته روش کار کرده؟ اگر همون اول سوال پرسیده میشد و درست جلو میرفت هزینه کمتری داشت یا بعد از اینکه ۱ هفته گذشته و شما تازه کد ها رو میبینین؟
انسان ها به عنوان احترام زیادی میذارن. اگر رولی به نام Product Owner نبود، آیا شما به کسی مراجعه میکردین برای سوالاتون یا نهایتا با بغل دستی مشورت میکردیم و تمام؟ اگر رولی به نام مدیر نبود آیا از هم سطح خودتون کمک میخواستین یا فکر میکردین که این کار ضعف من رو میرسونه؟ اگر یکی باشه که همه ازش سوال کنند آیا سوال کردن از اون شخص ضعف شما رو میرسونه؟ از تیم های ورزشی، مفهومی بالاتر از تیم هم داریم؟ ۱۱ نفر با هم همکاری میکنن و مفهوم کامل تیم هستند، هر تیم یه کاپیتان داره که پا به پاشون تلاش میکنه، مدیر همش توی جلسه هستش، نمیتونه به عنوان یک مرجع در دسترس باشه، چقدر مدیریتون در روز کنارتون هستش؟ چقدر درجریان نحوه کد زدن ها و پیاده سازیشون هستش؟ هر اسمی روش بذاریم، به نظر من یه نفر در هر تیم باید مرجع باشه پا به پای بقیه بدوه و بقیه بتونن بدون ترس از اینکه نکنه ضعیف باشیم، بش رجوع کنند.
