فصل ۴ — اسکرام و تیمهای خودسازمانده
صفحهٔ PDF 107
«اصول بزرگ اگر به عمل منجر نشوند، چیزی جز بخار نیستند. برعکس، رویههای مشخص در غیاب اصول راهنما اغلب بهشکل نامناسب به کار گرفته میشوند.» — جیم هایاسمیت¹
بازی رومیزی Othello شعاری دارد: «یک دقیقه برای یادگیری، یک عمر برای استادشدن.» این توصیف برای تیمی که در حال یادگیری Scrum است بسیار مناسب است. رویهها و سازوکارهای پایهٔ Scrum سرراستاند و پذیرششان دشوار نیست؛ اما فهم اینکه ارزشهای Scrum چگونه باعث میشوند همین رویهها و سازوکارها به نرمافزار بهتری منجر شوند، چالشبرانگیزتر است.
قواعد Scrum ساده و قابل انتقالاند و همین موضوع آن را به نقطهٔ شروع خوبی برای بسیاری از تیمهایی تبدیل میکند که Agile را میپذیرند. الگوی پایهٔ یک پروژهٔ Scrum چنین است:
- در پروژهٔ Scrum سه نقش اصلی وجود دارد: Product Owner، Scrum Master و عضو تیم. (وقتی دربارهٔ نقشهای Scrum صحبت میکنیم، عبارتهای Product Owner و Scrum Master را با حروف بزرگ آغاز میکنیم.)
- Product Owner همراه با سایر اعضای تیم، Product Backlog شامل قابلیتها و نیازمندیهایی را که باید ساخته شوند نگهداری و اولویتبندی میکند.
- نرمافزار با تکرارهای زمانبندیشدهای به نام Sprint ساخته میشود. در آغاز هر Sprint، تیم Sprint Planning انجام میدهد تا مشخص کند کدام قابلیتهای Backlog را خواهد ساخت. این مجموعه Sprint Backlog نام دارد و تیم در طول Sprint تلاش میکند همهٔ قابلیتهای آن را بسازد.
- هر روز تیم جلسهٔ کوتاه رودررویی به نام Daily Scrum برگزار میکند تا اعضا یکدیگر را از پیشرفت خود آگاه کنند و موانع پیش رو را بررسی کنند. هر فرد به سه پرسش پاسخ میدهد: از Daily Scrum قبلی چه کردهام؟ تا Daily Scrum بعدی چه خواهم کرد؟ چه مانعهایی سر راه من هستند؟
- یک نفر، یعنی Scrum Master، با کمککردن به تیم برای عبور از موانعی که شناسایی کرده و برایشان کمک خواسته است، حرکت پروژه را حفظ میکند. در پایان Sprint، نرمافزار کارا در Sprint Review به Product Owner و ذینفعان نمایش داده میشود و تیم Retrospective برگزار میکند تا درسهای آموختهشده را پیدا کند و شیوهٔ اجرای Sprintها و ساخت نرمافزار را در آینده بهبود دهد.
¹ Jim Highsmith, Agile Project Management: Creating Innovative Products, 2nd Edition (Upper Saddle River, NJ: Pearson Education, 2009).
شکل ۴-۱. الگوی پایهٔ Scrum.
صفحهٔ PDF 108
تصویر منبع - صفحهٔ PDF 108
اما برای اینکه یک تیم Scrum مؤثر شود، باید کاری بیش از پیروی از الگوی پایهٔ Scrum انجام دهد. تیمهای مؤثر Scrum خودسازمانده هستند؛ همانطور که Ken Schwaber در Agile Project Management with Scrum توضیح میدهد (واژههایی که در اصل با ایتالیک تأکید شدهاند):
برای اینکه Scrum کار کند، تیم باید تعهد جمعی و خودسازماندهی را عمیق و از صمیم وجود درک کند. نظریه، رویهها و قواعد Scrum از نظر ذهنی بهسادگی قابل فهماند. اما تا زمانی که گروهی از افراد بهصورت جمعی متعهد نشدهاند چیزی ملموس را در زمانی ثابت تحویل دهند، احتمالاً Scrum را واقعاً «نگرفتهاند». هنگامی که اعضای تیم دست از رفتارکردن بهصورت چند فرد جدا میکشند و یک هدف مشترک را میپذیرند و به آن متعهد میشوند، تیم توان خودسازماندهی پیدا میکند و میتواند بهسرعت از پیچیدگی عبور کرده و برنامههای قابل اقدام تولید کند.
هدف این فصل آن است که با تکیه بر ایدههای فصلهای ۲ و ۳، رویهها و الگوهای Scrum را آموزش دهد تا شما واقعاً «Scrum را بفهمید». از این رویهها برای نشاندادن ایدههای پشت اصول تعهد جمعی (collective commitment) و خودسازماندهی (self-organization) استفاده خواهیم کرد.
قواعد Scrum
در Agile Project Management with Scrum، کن شوابر قواعد Scrum را که الگوی پایهٔ یک پروژهٔ Scrum را توصیف میکنند بیان میکند. در واقع میتوانید قواعد مرجع Scrum را از www.scrum.org بهصورت یک PDF رایگان دریافت کنید؛ کتاب الکترونیکی The Scrum Guide نوشتهٔ Ken Schwaber و Jeff Sutherland، افرادی که Scrum را ایجاد کردند و به گسترش آن در صنعت کمک کردند. این قواعد باید تا اینجا برایتان آشنا باشند، چون بسیاری از آنها در فصلهای ۲ و ۳ توضیح داده شدهاند. یک پروژهٔ معمول Scrum از قواعد زیر پیروی میکند:
- هر Sprint با Sprint Planning آغاز میشود که Scrum Master، Product Owner و بقیهٔ تیم انجام میدهند. این جلسه به دو بخش تقسیم میشود و هر بخش Timebox چهار ساعته دارد. تکلیف Product Owner پیش از Sprint Planning این است که Product Backlog اولویتبندیشدهای شامل مجموعهای از اقلامی آماده کند که کاربران و ذینفعان با آنها موافقاند. در بخش اول جلسه، Product Owner با تیم کار میکند تا براساس ارزش اقلام و برآورد تیم از میزان کار آنها، مواردی را انتخاب کنند که در پایان Sprint تحویل خواهند شد. تیم توافق میکند در پایان Sprint نمایشی از نرمافزار کارا شامل این اقلام ارائه کند. این بخش اول Timebox دارد (برای Sprint سیروزه چهار ساعت و برای Sprintهای کوتاهتر به همان نسبت کمتر)؛ بنابراین با پایان زمان، تیم هر آنچه تا آن لحظه انتخاب کرده است بهعنوان Sprint Backlog در نظر میگیرد. در بخش دوم جلسه، اعضای تیم با کمک Product Owner وظایف منفردی را مشخص میکنند که برای پیادهسازی واقعی آن اقلام انجام خواهند داد. این بخش نیز بر اساس طول Sprint زمانبندی میشود، هرچند اغلب زمان کمتری میگیرد. در پایان Sprint Planning، اقلام انتخابشده Sprint Backlog را تشکیل میدهند.
صفحهٔ PDF 109
- تیم هر روز جلسهٔ Daily Scrum برگزار میکند. همهٔ اعضای تیم، از جمله Scrum Master و Product Owner، باید حاضر باشند² و ذینفعان علاقهمند نیز میتوانند شرکت کنند، اما باید صرفاً ناظر خاموش باشند. جلسه ۱۵ دقیقه Timebox دارد، پس همه باید سر وقت حاضر شوند. هر عضو تیم به سه پرسش پاسخ میدهد: از Daily Scrum قبلی چه کردهام؟ از حالا تا Daily Scrum بعدی چه خواهم کرد؟ چه موانع و سدهایی سر راه من هستند؟ پاسخ هر نفر باید کوتاه باشد؛ اگر پاسخی به بحث نیاز دارد، اعضای مرتبط بلافاصله پس از جلسه گفتوگوی پیگیری تعیین میکنند.
- هر Sprint طول مشخص و Timeboxشدهای دارد که هنگام Sprint Planning تعیین میشود. بسیاری از تیمها ۳۰ روز تقویمی را به کار میبرند، اما این طول میتواند متفاوت باشد؛ برخی Sprintهای دو هفتهای و برخی یک ماهه را انتخاب میکنند و Timebox برنامهریزی هم باید متناسب با آن تغییر کند. طی Sprint، تیم اقلام Sprint Backlog را به نرمافزار کارا تبدیل میکند. میتوانند از افراد خارج تیم کمک بگیرند، اما افراد بیرون تیم نمیتوانند به تیم بگویند چگونه کارش را انجام دهد و باید به تیم اعتماد کنند که تحویل خواهد داد. اگر در میانهٔ Sprint کسی متوجه شود تیم بیش از ظرفیت متعهد شده یا میتواند اقلام بیشتری اضافه کند، باید بهمحض تشخیص خطر Product Owner را در جریان بگذارد. Product Owner عضوی است که میتواند با کاربران و ذینفعان کار کند، انتظارهایشان را بازتنظیم کند و با استفاده از این اطلاعات Sprint Backlog را با ظرفیت واقعی تیم هماهنگ سازد. اگر تیم ببیند پیش از پایان Sprint کارش تمام میشود، میتواند اقلام بیشتری به Sprint Backlog بیفزاید. Sprint Backlog باید بهروز و برای همه قابل مشاهده بماند. در موارد بسیار غیرعادی و شرایط حاد، اگر تیم کشف کند نمیتواند نرمافزار کارا تحویل دهد (برای مثال مشکل جدی فناوری، سازمانی یا نیروی انسانی رخ دهد)، Product Owner میتواند Sprint را زودتر خاتمه دهد و Sprint Planning جدیدی آغاز کند. اما همه باید بدانند خاتمهٔ Sprint اتفاقی نادر است و هزینهای بسیار منفی برای توان تولید و تحویل نرمافزار دارد و به اعتمادی که نزد کاربران و ذینفعان ساختهاند آسیب جدی میزند.
- در پایان Sprint، تیم Sprint Review برگزار میکند و نرمافزار کارا را به کاربران و ذینفعان نشان میدهد. در Demo فقط اقلامی مجازند که واقعاً «done done»³ باشند؛ یعنی همهٔ کارشان تمام و آزموده شده باشد و Product Owner آنها را کامل پذیرفته باشد. تیم فقط نرمافزار عملیاتی و کارا نشان میدهد، نه اقلام میانی مانند نمودار معماری، طرحوارهٔ پایگاه داده، مشخصات عملکردی و مانند آن. ذینفعان میتوانند سؤال بپرسند و تیم پاسخ دهد. در پایان Demo از ذینفعان نظر و بازخورد خواسته میشود و فرصت دارند افکار، احساسات، ایدهها و دیدگاههایشان را مطرح کنند. اگر تغییری لازم باشد هنگام برنامهریزی Sprint بعدی لحاظ میشود. Product Owner میتواند تغییرها را به Product Backlog اضافه کند و اگر فوری باشند، در Sprint Backlog بعدی قرار میگیرند.
- پس از Sprint، تیم جلسهٔ Sprint Retrospective برگزار میکند تا راههای مشخصی برای بهبود نحوهٔ کار پیدا کند. تیم و Scrum Master و در صورت تمایل Product Owner شرکت میکنند. هر فرد به دو پرسش پاسخ میدهد: در Sprint چه چیزهایی خوب پیش رفت؟ در آینده چه چیزهایی میتواند بهتر شود؟ Scrum Master بهبودها را ثبت میکند و موارد مشخصی مانند راهاندازی Build Server جدید، پذیرش یک رویهٔ برنامهنویسی تازه یا تغییر چیدمان دفتر بهعنوان اقلام غیرعملکردی به Product Backlog افزوده میشوند.
و همین! ساده است!
البته شاید نه. اگر اینقدر ساده است چرا همه Scrum انجام نمیدهیم؟ و برای کسانی از ما که Scrum اجرا میکنیم و همهٔ قواعد را دنبال میکنیم، چرا بسیاری از اعضای تیم احساس میکنند نتیجه فقط «بهتر از هیچکاری نکردن» است؟ چه چیزی کم است؟
روایت: تیمی که در یک شرکت کوچک روی اپلیکیشن تلفن همراه کار میکند
- Roger — سرپرست تیم که میکوشد Agile شود
- Avi — Product Owner
- Eric — Scrum Master در یک تیم دیگر
² آیا جلسهٔ روزانه برای تیم شما غیرواقعی به نظر میرسد، مثلاً چون افراد میان چند تیم تقسیم شدهاند یا تعهدهای دیگری دارند؟ آیا از همین حالا دنبال جایگزینی برای Daily Scrum مثل Hangout آنلاین یا صفحهٔ Wiki هستید؟ این میتواند نشانهای باشد که برای گرفتن بهترین نتیجه از Scrum، Mindset شما باید تغییر کند.
³ ایدهٔ «done done»—کاری که واقعاً و حقیقتاً تمام شده و هیچ چیز دیگری برای انجامدادن روی آن باقی نمانده—در نگاه اول بدیهی است، اما ظرافتهای زیادی دارد. این نمونهٔ دیگری از سادهسازی است و در طول کتاب چند بار دیگر به آن بازمیگردیم. حواستان به آن باشد! حالا که چند نمونه از این سادهسازیها را دیدهاید، دیگر هر بار با پاورقی به آنها اشاره نمیکنیم، اما همچنان در سراسر کتاب از آنها استفاده خواهیم کرد.
صفحهٔ PDF 111
پردهٔ اول: I Can Haz Scrum؟
Hover Puppy Software شرکت کوچکی است که وبسایت و اپلیکیشن تلفن همراه میسازد و چند سال بسیار خوب داشته است. شش ماه پیش، جدیدترین اپلیکیشن موبایلش فروش فوقالعادهای داشت و مدیرعامل تصمیم گرفت درآمد آن را دوباره در شرکت سرمایهگذاری کند و پروژهای جدید، وبسایتی به نام Lolleaderz.com، راه بیندازد که به کاربران اجازه میدهد برای ویدئوهای حیوانات خانگی Leaderboard و Achievement بسازند.
وقتی پروژه شروع شد، سرپرست تیم، Roger، میخواست Agile شود. او خوشحال شد که تیمش نیز به همان اندازه از این چشمانداز هیجانزده است. تیم دیگری در همان شرکت، تیم موبایل، برای توسعهٔ اپلیکیشن بسیار موفقش از Scrum استفاده کرده بود و این ایده در شرکت پخش شده بود. یکی از اعضا شروع کرد Roger را Scrum Master صدا بزند و این نقش روی او ماند.
اولین کار Roger پیدا کردن Product Owner بود، اما فوراً روشن نبود چه کسی باید باشد. خوشبختانه Hover Puppy از آن شرکتهای کوچکی است که همه مدیرعامل را با نام کوچک صدا میزنند. Roger نزد او رفت و وضعیت را توضیح داد و Product Owner را «پادشاه ذینفعان» پروژه توصیف کرد. اتفاقاً یکی از Account Managerها به نام Avi بهتازگی پروژهای را تمام کرده بود. مدیرعامل او را به Roger معرفی کرد، گفت کاملاً از Scrum پشتیبانی میکند و ادامه را به خودشان واگذاشت تا ببینند چگونه باید آن را عملی کنند.
در ابتدا پروژه خوب به نظر میرسید. Roger Sprintهای یکماهه تنظیم کرد و در آغاز هر Sprint، Avi Backlog قابلیتهایی را که باید ساخته شوند آماده میکرد. Roger جلسهٔ Daily Scrum را برقرار کرد و Avi آن را در تقویمش مسدود کرد تا هر روز حاضر شود. Sprint اول عالی بود؛ همه با هم کنار میآمدند و تیم پیشرفت میکرد. در پایان همان Sprint، تیم نسخهای ساده از وبسایت را با چند قابلیتی که همگی برنامهریزی کرده بودند به Avi نشان داد. به نظر میرسید آزمایش Scrum جواب میدهد.
طی چند هفتهٔ بعد ترکهایی در پروژه ظاهر شد، اما هنوز تقریباً در مسیر بود. یکی از Account Managerها با یکی از مشتریانش، یک شرکت تولید فیلم، کار میکرد تا تبلیغ فیلم پرفروش تابستانی آیندهشان را در همهٔ سایتهای Hover Puppy قرار دهد. تیم به Avi قول داده بود این قابلیت را در پایان Sprint نمایش دهد. اما از همان ابتدا به مشکلات فنی خوردند و در نهایت کار به Sprint بعدی منتقل شد. Roger توضیح داد تیمهای Scrum همیشه نرمافزار کارا تحویل میدهند، پس اگر قابلیتی تا پایان Sprint تمام نشود، فقط به Sprint بعدی هل داده میشود. بااینحال خودشان هم مطمئن نبودند Scrum واقعاً باید همینطور کار کند.
هر Sprint ظاهراً کندتر از قبلی میشد. تا پایان Sprint سوم، Avi احساس میکرد وقت بیشتری را با تیم میگذراند و هر روز زمان کمتری برای کار واقعیاش با مشتریان دارد. در آغاز پروژه فکر میکرد کنترل آنچه تیم انجام میدهد دست اوست. حالا کمکم احساس میکرد وقتی Product Owner پروژهٔ Lolleaderz.com شد قرعهٔ بد به نامش افتاده است. Roger وقتی شنید Avi نزد Account Managerهای دیگر از دشواربودن همکاری با تیم گلایه کرده، ناراحت شد.
بدتر از آن، تیم از تمام این ماجرای Scrum به ستوه آمده بود. پیش از اینکه Roger و Avi حتی فرصت حل آن مشکل را پیدا کنند، بحران کوچکی رخ داد: سه توسعهدهنده Roger را کنار کشیدند و از Daily Scrum جدید شکایت کردند. یکی گفت: «همین حالا هم کلی کار دارم که این را تحویل بدهم و این جلسهها فقط وقت ما را تلف میکنند. چرا باید در Status Update روزانهٔ تو بنشینم و منتظر بمانم به هر کس وظایف روز بعدش را بدهی؟ نمیتوانی فقط برایمان ایمیل کنی؟» Roger پاسخ خوبی نداشت. گفت اینها قواعد Scrum است و همین کافی بود که توسعهدهندگان همچنان در جلسهها شرکت کنند، اما هیچکس واقعاً از این جواب راضی نبود و Roger کمکم فکر میکرد شاید آنها حق دارند.
یک درگیری بزرگ هنگام برنامهریزی Sprint چهارم رخ داد. Avi اصرار داشت قابلیت امتیازدادن «paws up» به ویدئوها حتماً وارد شود، وگرنه تبلیغدهندگان را از دست میدهند. اما کار پایگاه دادهٔ آن قابلیت سنگین بود و به DBA ستارهٔ تیم نیاز داشت تا تغییرات اساسی در Data Model بدهد، یعنی دیگر وقتی برای نوشتن Stored Procedureها نمیماند. به نظر میرسید قابلیت یک هفته دیر میشود، اما انتقال آن به Sprint بعدی هم امکانپذیر نبود.
اکنون شش ماه و پنج Sprint از پروژه گذشته بود. Roger احساس میکرد Avi تقاضاهای بزرگتری از تیم دارد. Avi از اینکه پروژه وبسایتی تحویل نمیداد که بتواند به مشتریان بفروشد کلافه بود. قرار بود تیم صفحهٔ Video Tagging و Social Media Feed را دو Sprint پیش تمام کرده باشد، اما هنوز تحویل نشده بود. در آخرین جلسهٔ Account Managerها، Avi تیم را مقصر تأخیر دانست. Roger میدانست پروژه در خطر لغو است.
Roger دیگر طاقت نداشت. پروژهای که خیلی خوب شروع شده بود به هیولا تبدیل شده بود. احساس میکرد از توانش خارج است، اما نمیدانست چطور درستش کند. به کتابها و سایتهایی برگشت که Scrum را از آنها آموخته بود و از هرچه میخواند به نظر میرسید—حداقل روی کاغذ—همهچیز را درست انجام میدهد: Sprint داشت، Daily Scrum و Retrospective داشت، با Product Owner برای اولویتبندی Backlog کار میکرد، ارزشمندترین قابلیتها را برای هر Sprint بیرون میکشید، با تیم برآورد میکرد تا در Sprint جا شوند و آنها را به توسعهدهندگان واگذار میکرد.
Roger تازه بهترین سخنرانی انگیزشیای را که میتوانست برای تیم انجام داده بود: «همین الان من را به دفتر CEO کشیدند. خوشحال نیست که عقب افتادهایم و Avi هم خوشحال نیست. ببینید، من از شما محافظت میکنم و فشار مشکلات را خودم میگیرم. اما باید روی برآوردها کار کنیم، چون خیلی اشتباه بودند—و واقعاً لازم است آخر هفته کار کنید تا جبرانش کنیم.»
این سومین بار طی دو ماه بود که از آنها میخواست شبها و آخرهفتهها کار کنند. پروژه درست مثل پروژههای قبلیای شده بود که از ریل خارج شده بودند.
پس چه چیزی اشتباه شد؟ میتوانید مشکل را پیدا کنید؟ اگر از شما میخواستند Scrum Master این پروژه شوید چه میکردید؟ به ارزشها و اصول Agile فکر کنید. آیا راهی برای بهکارگیری آنها وجود دارد که پروژه بهتر پیش برود؟
همهٔ اعضای یک تیم Scrum مالک پروژهاند
هر پروژهٔ Scrum یک Product Owner، یک Scrum Master و یک تیم دارد. اما هر پروژهای که این نقشها را به افراد نسبت داده باشد، الزاماً پروژهٔ مؤثر Scrum نیست. Product Owner در Scrum متفاوت از Product Owner یک پروژهٔ Waterfall معمول با «نیازمندیهای بزرگ در ابتدا» عمل میکند. Scrum Master همان کارهای Project Manager فرماندهیوکنترل یا Technical Team Lead را انجام نمیدهد. وقتی Scrum Master، Product Owner و تیم بهجای جدا از هم با یکدیگر کار میکنند، پروژه کمکم واقعاً شبیه Scrum میشود.
Scrum Master تصمیمهای تیم را هدایت میکند
نحوهٔ انجام کار Scrum Master بزرگترین تفاوت میان مدیریت پروژهٔ سنتی Command-and-Control و یک تیم Agile Scrum را ایجاد میکند.
در پروژهٔ Command-and-Control، Project Manager مالک و نگهدارندهٔ Schedule و Plan است. او با ذینفعان صحبت میکند، Requirements را میگیرد، کار را خرد میکند، از تیم Estimate میگیرد، Taskها را تخصیص میدهد و Schedule میسازد. Roger در پروژهٔ Lolleaderz.com همین رویکرد را گرفت: Requirements را از Avi گرفت، Estimate را از تیم گرفت و Task هر فرد را واگذار کرد.
اعضای تیم در پروژهٔ Command-and-Control بهطور طبیعی میل CYA (محافظت از خود) دارند و وقتی مشکل پروژه ناشی از برنامهٔ شخص دیگری است دستشان را از آن میشویند. وقتی یک نفر مالک انحصاری Schedule و Plan باشد، بقیهٔ تیم و Product Owner با خوشحالی اجازه میدهند همان فرد تصمیمها را بگیرد.
صفحهٔ PDF 113
این یکی از دلایلی است که Scrum نقش جداگانهای برای «مالک برنامه» ندارد. اگر در تیم یک نقش مالک برنامه باشد و نقشهای دیگر صرفاً از آن پیروی کنند، هنگام مشکل خیلی آسان است که افراد بگویند: «این مشکل آن آدم است.» تقریباً هر پروژهای در مقطعی به مشکل میخورد، زیرا تقریباً همهٔ مشکلات پروژه یا باعث مشکل برنامهریزی میشوند یا از آن ناشی میشوند. بنابراین Scrum Master مالک برنامه نیست. ممکن است به تیم برای ساخت برنامه کمک کند، اما مهمتر از آن، استفادهٔ تیم از Scrum و رویههایش را هدایت میکند و کمک میکند همه احساس کنند برنامه را با هم مالکاند. رویهها و ارزشهای Scrum این حس مالکیت مشترک را ایجاد میکنند.
Product Owner به تیم کمک میکند ارزش نرمافزار را بفهمد
گفتوگویی میان مدیرعامل و Scrum Master را تصور کنید. مدیرعامل میپرسد با سرمایهگذاری دو میلیون دلاری روی نرمافزار در سال آینده دقیقاً چه چیزی دریافت خواهد کرد. Scrum Master میگوید هنوز مطمئن نیست؛ هر ماه بهروزرسانی خواهند داشت و در پایان پروژه دستکم دو میلیون دلار نرمافزار خواهند داشت. هیچ مدیرعامل عاقلی چنین پروژهای را تصویب نمیکند. چرا؟
چون این پروژه بر یک تعهد واقعی بنا نشده است. تعهدها وعدههایی هستند که آدمها میدهند تا کارهای مشخصی را، معمولاً تا زمانی مشخص، انجام دهند. تعهد واقعی یک مسئولیت اضافه هم دارد: وقتی شرایط طوری تغییر میکند که ممکن است وعده عملی نشود، باید همه را خبردار کرد و برای آن راهحل پیدا کرد.
بیشتر ما در جلسهای بودهایم که یکی از اعضای تیم میگوید Deadlineهایی را که به آن متعهد شده امضا یا تأیید نکرده است، پس پیامد نرسیدن به Deadline تقصیر او نیست. این زمانی رخ میدهد که Project Managerهای کمتجربه اشتباه میکنند و فکر میکنند بهمحض اینکه Taskی در Plan نوشته شد، تیم خودکار به آن متعهد میشود.
Planها ما را متعهد نمیکنند؛ تعهدهای ما هستند که ما را متعهد میکنند. Plan فقط جای مناسبی برای نوشتن آن تعهدهاست. تعهد را انسانها میسازند و در Plan پروژه ثبت میکنند. وقتی کسی به Project Plan اشاره میکند تا ثابت کند تعهدی وجود داشته، واقعاً کاغذ موضوع نیست؛ همه به وعدهای فکر میکنند که روی آن نوشته شده است.
در تیم Scrum، Product Owner کسی است که تعهد را به شرکت داده است. او باید بایستد و قول دهد در پایان پروژه چیز مشخصی تحویل خواهد شد. Product Owner مستقیماً با هدفهای واقعی کسبوکاری پروژه در ارتباط است. هرچه بهتر بتواند تیم را وادارد آن اهداف را بفهمد و نسبت به تحققشان متعهد شود، پروژه بهتر پیش میرود. وقتی پروژه ناگزیر با مشکلی مثل مسئلهٔ فنی، تغییر در کسبوکار یا خروج افراد از تیم روبهرو شود، Product Owner باید راهی پیدا کند که درک تیم از اهداف بهروز بماند و حس تعهدشان حفظ شود. او بر اساس تغییرات کسبوکار تصمیمهای روزمره میگیرد و هر روز با تیم دیدار میکند تا مطمئن شود اعضا میفهمند Backlog و اهداف پروژه چگونه در حال تغییرند.
Product Owner فقط نمینشیند منتظر پایان Sprint بماند. کار او مالکیت و اولویتبندی Backlog، رساندن صدای کسبوکار به تیم، کمک به تیم برای فهم اینکه کدام Storyها و Backlog Itemها مهمتر و ارزشمندترند، و اطمینان از این است که همه میدانند «done done» شدن یک Backlog Item دقیقاً یعنی چه. در Sprint Planning، تیم براساس ارزش و میزان کار موردنیاز بهصورت جمعی اقلام را از Product Backlog به Sprint Backlog منتقل میکند، اما Product Owner آنها را در این مسیر هدایت میکند. و کار او همانجا تمام نمیشود.
صفحهٔ PDF 115
Product Owner در کار روزمرهٔ پروژه نقشی بسیار فعال دارد. مانند همهٔ تیمهای Agile خوب، تیمهای Scrum برای فهم دقیق آنچه میسازند شدیداً به ارتباط رودررو متکیاند. Sprint Planning آغاز Sprint اطلاعات کافی برای شروع کار میدهد، اما بههیچوجه زمان کافی نیست تا Product Owner همهٔ جزئیات چیزی را که قرار است ساخته شود به کل تیم منتقل کند. پس Product Owner در طول Sprint هر روز با اعضای تیم کار میکند، به سؤالهای جزئی فراوان پاسخ میدهد، پاسخهای مشخص دربارهٔ آنچه میسازند و نحوهٔ استفادهٔ کاربران از قابلیتها ارائه میکند و تصمیمهای کوچک زیادی دربارهٔ نحوهٔ کار محصول میگیرد.
Product Owner اختیار این تصمیمها را دارد. اگر ندارد، فرد مناسبی برای این نقش نیست؛ Scrum به توان Product Owner برای تصمیمگیری از طرف کسبوکار، از جمله پذیرش کار تکمیلشده، وابسته است. اما همهٔ اطلاعات را در اختیار ندارد. معمولاً کاربران و ذینفعان زیادی وجود دارند که اطلاعات و دیدگاه ارزشمندی دارند؛ بنابراین Product Owner زمان زیادی را صرف گفتوگو با آنها میکند تا پاسخهایی را که توسعهدهندگان لازم دارند به دست آورد. او از این ارتباط برای باخبرماندن از تغییرها نیز استفاده میکند و Product Backlog را بهروز نگه میدارد تا تازهترین نیازهای شرکت را منعکس کند. اگر ارزش نسبی Backlog Itemها تغییر کند، اولویتبندی را اصلاح میکند تا تیم برای Sprint Planning بعدی آماده باشد.
همه مالک پروژهاند
تیمهای Scrum برای توضیح نحوهٔ کار تعهدها دوست دارند از حکایت خوک و مرغ استفاده کنند:
خوک و مرغ در جاده راه میروند. مرغ میگوید: «هی خوک، فکر میکردم یک رستوران باز کنیم!» خوک میگوید: «هوم، شاید؛ اسمش را چه بگذاریم؟» مرغ پاسخ میدهد: «Ham-n-Eggs چطور؟» خوک کمی فکر میکند و میگوید: «نه ممنون. من متعهد میشوم، ولی تو فقط درگیر میشوی!»⁴
⁴ برگرفته از صفحهٔ Wikipedia با عنوان “The Chicken and the Pig” (دسترسی در 26 ژوئیهٔ 2014).
پس در پروژهٔ Scrum چه کسی مرغِ صرفاً درگیر است و چه کسی خوکِ متعهد؟ این با پروژهٔ Waterfall ناکارآمد چه تفاوتی دارد؟ همهچیز به نحوهٔ رفتار اعضای تیم، Project Manager و Product Owner برمیگردد.⁵
تیمهای Scrum اغلب نقشها را با استعارهٔ خوک و مرغ توضیح میدهند. این میانبری برای مشخصکردن آن است که شخصِ حاضر در یک نقش فقط به پروژه تخصیص داده شده (مرغ) یا واقعاً به موفقیت آن متعهد است (خوک). به پروژههای خودتان فکر کنید: آیا همیشه واقعاً موفقیت یا شکست خودتان را وابسته به موفقیت همان پروژه میدانستید؟
شکل ۴-۲. در داستان خوک و مرغ، خوک نسبت به صبحانه متعهد است؛ مرغ فقط درگیر آن است.
⁵ صحبت از خوک و مرغ ممکن است کمی خندهدار به نظر برسد، اما تیمهای Scrum واقعاً این کار را میکنند. حتی بعضی نسخههای قدیمی Scrum Guide بخشی دربارهٔ خوکها و مرغها داشتند.
صفحهٔ PDF 117
تصویر منبع - صفحهٔ PDF 117
واقعیت این است که بیشتر افراد در مسیر شغلی خودشان را «مرغ» میبینند. میخواهند به پروژه کمک کنند، اما اینکه موفقیت واقعیشان در محل کار—ارزیابی، افزایش حقوق، هدفهای شغلی آینده و ادامهٔ استخدام—به یک پروژه وابسته باشد خطرناک است. همچنین آسان است فراموش کنیم مردم برای پول کار میکنند. چرا افراد شغلشان را انجام میدهند؟ واقعاً چه چیزی به آنها انگیزه میدهد؟ لزوماً موفقیت پروژهٔ فعلی نیست.
افراد یک تیم Agile مؤثر—همهٔ خوکها—واقعاً احساس میکنند برای موفقشدن خودشان، پروژه باید موفق شود. بااینحال حتی یک تیم Scrum باتجربه هم بهراحتی ممکن است به ذهنیت مرغی بازگردد.
چند بار پیش آمده توسعهدهندهای فناوریای را فقط به این دلیل انتخاب کند که میخواهد آن را یاد بگیرد؟ بهعنوان Project Manager، آیا پروژههای Agile را انتخاب کردهاید چون شما را در بازار کار جذابتر میکنند؟ احتمالاً. همهٔ ما تا حدی چنین کردهایم. همه انگیزههای شخصی دارند و شناخت آن مهم است. اما Scrum از شما یک چیز میخواهد: وقتی روی Sprint کار میکنید، موفقیت پروژه باید از هر هدف حرفهای دیگری⁶ مهمتر باشد. به بیان دیگر، وقتی عضو Scrum Team هستید خوک بمانید.
وقتی همهٔ اعضای تیم خوکاند، یعنی همه متعهدند. همچنین یعنی هرکس هر کاری را که پروژه نیاز داشته باشد انجام میدهد.
مثالی برای فهم تعهد: فرض کنید CEO یک شرکت هستید، اما واقعاً به پروژه متعهدید. تیم کمی خسته شده و واضح است به قهوه نیاز دارد. اگر همهٔ دیگران مشغول کاری باشند که همین حالا نمیتواند متوقف شود، شما قهوه میگیرید—و چون واقعاً متعهدید، حتی بهعنوان CEO احساس میکنید این بهترین استفاده از وقت شماست، چون همین چیزی است که تیم الآن نیاز دارد.
از طرف دیگر، هر پروژهٔ نرمافزاری به مرغ هم نیاز دارد. برای مثال هر کاربر یک مرغ بالقوه است. چند بار از قابلیتی در Browser، Word Processor یا Email Client ناراحت شدهاید؟ آیا بازخوردتان را در سایت نوشته یا برای Support ایمیل کردهاید؟ این یکی از راههای مرغشدن است. اگر تیم به شما گوش دهد و مشکل را رفع کند، به افزودن ارزش به محصول کمک کردهاید. هرچه یک مرغ بیشتر درگیر شود، بالقوه ارزش بیشتری میتواند اضافه کند.
وقتی در پروژهٔ Scrum مرغ هستید، نظر شما مهم است. به نتیجه اهمیت میدهید و تیم میخواهد حرفتان را بشنود؛ اما شغلتان به پروژه گره نخورده است. هدفهای دیگری دارید، مثلاً فروش محصول، پشتیبانی از آن یا ادارهٔ شرکت. این هدفها مهماند، اما همان چیزهای مشخصی نیستند که پروژه باید تولید کند.
⁶ برای روشنبودن: «خوک» متعهد موفقیت پروژه را از هر چیز دیگری در زندگی حرفهایاش مهمتر میداند. در زندگی شخصی چیزهای دیگری—مثلاً خانواده—معمولاً مهمترند. اگر چنین نباشد، خود این موضوع مشکل Mindset تیم است و با Sustainable Pace تداخل خواهد داشت.
صفحهٔ PDF 118
به همین دلیل تیمهای Scrum، و بهویژه Product Ownerهایشان، رابطه با مرغها را پرورش میدهند. یکی از مؤثرترین راهها، انتشار نرمافزار کارا با برنامهای منظم و قابل پیشبینی برای کاربران است. این کار مرغها را درگیر نگه میدارد و کمک میکند اثر خودشان بر پروژه را ببینند.
Product Owner، Scrum Master و اعضای تیم چگونه «خوک»های بهتری باشند
وقتی عضو تیم فقط Taskهایی را که Project Manager به او داده انجام میدهد و وقتی Plan به مشکل میخورد احساس نمیکند واقعاً مشکل خودش است، مانند مرغ رفتار میکند. تعهد واقعی نسبت به پروژه ندارد و مهمتر اینکه نسبت به دیگر افراد تیم هم تعهد ندارد. برعکس، وقتی همان عضو تیم واقعاً احساس مسئولیت میکند که Plan درست باشد و ارزشمندترین نرمافزار ممکن برای شرکت و تیم ساخته شود، مانند خوک رفتار میکند.
حقیقت ناراحتکننده این است که بسیاری از شرکتها از اعضای تیم انتظار دارند مرغ باشند، نه خوک. حتی برنامهنویسها اغلب میبینند وقتی میخواهند در برنامهریزی پروژه مشارکت کنند از فرایند کنار زده میشوند، چون Planning و Decision Making امتیاز مدیران تلقی میشود نه برنامهنویسان عادی. («فکر کردی کی هستی، مدیر؟ برگرد به مزرعهٔ Cubicleها، برنامهنویس دونپایه!») وقتی این ارزش در فرهنگ شرکت جا افتاده باشد، پذیرش مؤثر Scrum بسیار دشوار میشود.
Scrum Master هم میتواند ناخواسته با تبدیلشدن به مالک یا «نگهبان» Plan، تیم را به مرغبودن تشویق کند. ترک این عادت برای Project Manager فرماندهیوکنترلی که در حال یادگیری Scrum Master شدن است بسیار دشوار است. ضمن اینکه خیلی از Project Managerها با همین «نگهبان برنامه» بودن در حرفهٔ خود موفق شدهاند. برای مدیریت ارشد راحت است فقط یک فرد پاسخگو داشته باشد؛ گاهی به آن فرد «یک گردن قابل پیچاندن» میگویند. بودن در آن جایگاه احساس خوبی میدهد، چون حس میکنید مفید و مهم هستید و به آشفتگی نظم دادهاید.
Planning ضروری است؛ بیرونکشیدن Planning از دست تیم ضروری نیست. وقتی Scrum Master بهتنهایی کار Sprint را خرد میکند، از تیم Estimate میگیرد، کار را تخصیص میدهد و وضعیتشان را کنترل میکند، دارد نقش «نگهبان Plan» را بازی میکند و همزمان آنها را به مرغبودن، نه خوکبودن، تشویق میکند.
شکل ۴-۳. وقتی Project Manager فرماندهیوکنترل نقش «نگهبان برنامه» را بازی میکند، تیم را به مرغبودن تشویق میکند.
اصلاح نگرش مرغی در تیم یکی از دشوارترین موانع پذیرش Scrum برای Scrum Masterهاست. تیمها اغلب نقش Project Manager فرماندهیوکنترل را میپذیرند، چون بار فکرکردن به کل پروژه را از دوششان برمیدارد. اما این موضوع برای انجام سریع و خوب پروژه مرکزی است، زیرا تیمهای توسعهای که با نگاه کوتاهمدت سراغ کد میروند سیستمهای شکننده و بدطراحی میسازند. وقتی تیم میانبُر میزند، ممکن است چیزی را که امروز ظاهراً کار میکند بیرون بدهد، اما در ادامه به سیستمی شکننده و کابوسوار برای نگهداری میرسد.
Scrum Master میتواند با برخورد با Estimateها بهعنوان «واقعیتهایی که هنوز کشف نشدهاند»، نه تعهدهایی که باید از تیم بیرون کشیده شوند، اعضا را به خوکبودن تشویق کند. Estimate یک Task واقعیت است چون تیم در نهایت مدت معینی را واقعاً برای آن کار صرف خواهد کرد. بهترین Estimateها تلاشهای واقعی برای گفتن حقیقت دربارهٔ آن چیزی هستند که رخ خواهد داد، نه حدسهای خوشبینانهٔ خیالی برای راضیکردن مدیر یا زودتر بیرونآمدن از جلسهٔ Planning.
یک Plan خوب شبیه تاریخی است که هنوز نوشته نشده. در پایان Sprint، تیم میتواند با اطمینان کامل به عقب نگاه کند و بگوید دقیقاً روی چه چیزهایی کار کرده و برای هر Task چقدر زمان صرف کرده است. Sprint گذشته و هرچه در آن رخ داده به اطلاعات تثبیتشده—Facts on the record—تبدیل شده است. اگر تیم کار خوبی کرده باشد، Plan آغاز Sprint بسیار شبیه واقعیت پایان آن خواهد بود. هرچه Plan بیشتر شبیه چیزی باشد که در نهایت رخ میدهد، دقیقتر بوده است.
این برای بسیاری از تیمها تغییر Mindset واقعی است. افراد تیمی که عادت دارد Plan را مجموعهای از هدفهای خوشبینانه بداند، اغلب در رسیدن به آن هدفها تقلا میکنند و شکست میخورند. کافی است یک عضو یا مدیر بیش از حد خوشبین باشد تا Plan همه—و چهار آخرهفتهٔ بعد—خراب شود، حتی اگر همان لحظه فکر کند دارد کمک میکند. اما اگر تیم Plan را واقعبینانهترین تلاش برای نوشتن چیزی بداند که فکر میکند طی ۳۰ روز آینده واقعاً اتفاق میافتد، احتمال اینکه بیش از ظرفیت تعهد کند بسیار کمتر میشود و احتمال رسیدن به زمانبندی بدون بریدن گوشهها، میانبُرزدن و ساختن کد شکننده بیشتر میشود.
برای بسیاری از Project Managerها این شیوهٔ تازهای برای نگاهکردن به Planning است. مدیران سنتی اغلب Plan را ابزاری برای انگیزهدادن به تیم و متعهدکردن آن به Deadline میبینند؛ گویی اگر Plan نباشد تیم مینشیند و هیچ کاری نمیکند. Project Managerی که Estimateهای تهاجمی را از تیم بیرون میکشد و در آغاز Sprint آنها را «تصویب» میکند، ممکن است بعداً با خیال راحت از همان Plan برای زورگویی به تیم استفاده کند. به همین دلیل نگرش «کار را برنامهریزی کن، برنامه را کار کن» میتواند شکافی میان Project Manager و تیم بسازد.
در تیم Scrum مؤثر، Scrum Master بهجای مطالبهٔ Estimate و سپس پاسخگوکردن فردی هرکس نسبت به آن، با کل تیم برای کشف هر Estimate کار میکند، نه فقط با فردی که Task به او رسیده است. Scrum Master و تیمی که با هم بهترین پیشبینی ممکن از آینده را میسازند و در طول پروژه هم این تصویر را تا حد ممکن دقیق نگه میدارند، به خودشان فرصت انجام بهترین کار را میدهند و در نتیجه نرمافزار ارزشمندتری تحویل خواهند داد.
شکل ۴-۴. تیمهای خودسازمانده با Estimate و Plan مانند واقعیتهایی برخورد میکنند که باید کشف شوند، نه تعهدهایی که لازم است از تیم بیرون کشیده شوند.
صفحهٔ PDF 122
تصویر منبع - صفحهٔ PDF 122
اعضای تیم همچنین وقتی در Sprint Planning در تخصیص کار مشارکت میکنند، بهجای اینکه کار به آنها تحمیل شود، تعهد بیشتری احساس میکنند. اگر واقعاً حس تعهد وجود داشته باشد، حتی لازم نیست Assignmentها در آغاز Sprint انجام شوند. تیمهای مؤثر Scrum میتوانند در طول Sprint تصمیم بگیرند چه کسی کدام Task را انجام دهد، بر اساس اینکه چه کسانی در دسترساند و چه مهارتهایی برای آن کار دارند. این یکی از کلیدهای فهم تیمهای خودسازمانده است.
در نتیجه، در تیم Scrum مؤثر اعضا فقط به Taskهای شخصی خود متعهد نیستند. هر نفر واقعاً به تحویل ارزشمندترین نرمافزار ممکن برای کاربران و ذینفعان متعهد است. وقتی همه این احساس را به اشتراک میگذارند و توافق میکنند در پایان هر Sprint نرمافزار کارا تحویل دهند، میگوییم تیم یک تعهد جمعی (collective commitment) ساخته است. بهجای تعهد به Taskهای خرد در Plan، تیم به تحویل اقلام ارزشمند Backlog متعهد است. این آزادی میدهد که با کشف واقعیتهای جدید پروژه، روش انجام کار را تنظیم کنند. مثلاً اگر Roger و توسعهدهندگان در میانهٔ پروژه بفهمند باید شیوهٔ ساخت چیزی را تغییر دهند، Avi تا وقتی همهٔ اقلام Sprint Backlog تحویل شوند به آنها اعتماد میکند. و اگر مشخص شود اشتباه کردهاند—که پیش میآید—و همهٔ Sprint Backlog تمام نمیشود، میتوانند دربارهٔ چیزهایی که Avi واقعاً به آنها اهمیت میدهد، یعنی Backlog Itemها، صحبت کنند، بدون اینکه مجبور باشند هر جزئیات کوچک را توجیه کنند.
این یکی از دلایل بنیادینی است که Scrum اینقدر خوب کار میکند و تفاوت میان تیم بسیار پربازدهٔ Scrum و تیمی را که فقط نتیجهای «بهتر از هیچکاری نکردن» گرفته است رقم میزند.
جایی برای مرغها در تیم نیست
در خود Scrum Team جایی برای مرغ وجود ندارد. Product Owner هم بخشی از تیم است، پس او هم باید خوک باشد. این برای Product Ownerها همیشه آسان نیست، بهخصوص اگر احساس کنند با «قرعهٔ بد» به Scrum Team تخصیص یافتهاند. بیشتر ذینفعان بهطور طبیعی ترجیح میدهند مرغ باشند، چون فاصلهداشتن راحتتر است. (گاهی هم میخواهند خوک باشند، حتی وقتی نباید.)
صفحهٔ PDF 123
گاهی ذینفعان حتی وقتی مناسب نیست میخواهند «خوک» باشند، چون این وضعیت اختیار بیشتری برای اثرگذاشتن بر تیم به آنها میدهد؛ این مسئلهای است که Product Owner باید حل کند.
Scrum Master و تیم میتوانند حس تعهد واقعی را در Product Owner تقویت کنند. مهمترین راه این است که واقعاً به نظرها و ایدههای او گوش دهند و بپذیرند که تخصص واقعی و موردنیازی را وارد پروژه میکند.
بسیاری از برنامهنویسان فکر میکنند Programming تنها بخش مهم پروژه است و همهٔ جنبههای دیگر باید پشت جزئیات فنی قرار بگیرند. بدتر اینکه بسیاری از شرکتها با سازماندهی تیمها حول یک هستهٔ فنی این طرز فکر را تقویت میکنند. جداکردن Project Managerها و Product Ownerها از تیم فنی در سلسلهمراتب شرکت باعث میشود توسعهدهندگان دیگران را «خارجی» ببینند و برای نظرشان ارزش کمتری قائل شوند.
Product Owner لزوماً جزئیات فنی را نمیداند و اشکالی هم ندارد. در Scrum Team هرکس مهارت و دانش خاص خودش را میآورد و Taskهایی را انجام میدهد که برای او مناسبتر است. Product Owner درک واقعی و عمیقی از هدفهای پروژه به میز میآورد. هرچه Scrum Master و تیم بیشتر Product Owner را درگیر کنند، دربارهٔ اهداف سؤال کنند و بکوشند آنها را از دید او بفهمند، Product Owner نیز تعهد بیشتری به پروژه و تیم خواهد داشت.
Scrum مجموعهٔ ارزشهای خودش را دارد
هر شرکت فرهنگ خودش را دارد که شامل ارزشهای مشخصی است. برای مثال بعضی شرکتها «تفکیک وظایف» را ارزش میدانند؛ هرکس نقش مشخصی دارد و از پاسخگویی نسبت به چیزهایی که کنترل یا اثرگذاری آسانی بر آنها ندارد محافظت میشود. شرکتهای دیگر Transparency را ارزش میدانند؛ اطلاعات آزادانه به اشتراک گذاشته میشود و حتی کارکنان سطوح پایین میتوانند بر تصمیمهای مدیریت اثر بگذارند. هیچیک بهخودیخود «روش درست» ادارهٔ شرکت نیست. فرهنگ هر شرکت طی زمان و بر اساس شیوهٔ مدیریت و تصمیمهایی که گرفته میشود تکامل مییابد.
هر Methodology ارزشهایی درون خود دارد. در فصل ۳ دیدیم که اصول Agile مشخص اغلب به Practiceهای منفرد پیوند دارند یا توسط آنها پیاده میشوند و همین Practiceها راه مؤثری برای آوردن هر اصل به پروژهاند. قبلاً دیدیم که افراد تیم در شرکتی که Decision Making را منحصراً برای مدیران نگه میدارد، بهسختی تعهد واقعی احساس میکنند. همین دربارهٔ هر Value یا Principle دیگری صدق میکند: اگر با ارزشهای شرکت برخورد داشته باشد، مانع Adoption ایجاد میکند.
اما در شرکتی که فرهنگ با ارزشها و اصول Agile هماهنگ است، تیم Agile بسیار موفقتر از تیم Command-and-Control خواهد بود. این یکی از سرچشمههای «نتایج شگفتانگیزی» است که بعضی تیمهای Agile گزارش میکنند.
ممکن است تعجب کنید که ارزشها و اصول Agile تا چه اندازه با فرهنگ شرکت شما همراستا هستند. قدم اول خوب برای معرفی Agile این است که دربارهٔ ارزشها و اثر احتمالی آنها بر فرهنگ شرکت گفتوگو کنید. اگر Adoption شما به مشکل بخورد، پیدا کردن ناهماهنگی بین ارزشهای Agile و فرهنگ شرکت میتواند انتقال را روانتر کند یا دستکم با فهم علت شکست، وضعیت را روشنتر سازد.
تیمهای خودسازمانده متفاوت از تیمهای Command-and-Control کار میکنند چون ارزشهای متفاوتی دارند. Ken Schwaber در Agile Project Management with Scrum پنج ارزش Scrum را مطرح میکند: شجاعت (courage)، تعهد (commitment)، احترام (respect)، تمرکز (focus) و گشودگی (openness). فهم Self-Organization با دیدن این نکته آغاز میشود که این ارزشها امور عملیاند که میتوان در پروژه گنجاند.
هر فرد به اهداف پروژه متعهد است
این سطح از تعهد زمانی ممکن است که تیم اختیار تصمیمگیری برای رسیدن به اهداف را داشته باشد و همه در چگونگی Planning و Execution پروژه حق اظهارنظر داشته باشند. تیم Ebook Reader در فصل ۳ ابتدا Requirement ساخت Internet Storefront را داشت. برای موفقیت محصول لازم شد آن Requirement را کنار بگذارند و پروژهای بسیار ارزشمندتر تحویل دهند. این فقط به این دلیل ممکن شد که Team، Scrum Master و Product Owner اجازه داشتند خودشان تصمیم بگیرند و مجبور نبودند از بوروکراسی عبور کنند.
اعضای تیم به یکدیگر احترام میگذارند
وقتی اعضا احترام متقابل دارند، میتوانند به هم اعتماد کنند که کار پذیرفتهشده را خوب انجام دهند. اما این احترام برای برنامهنویسان و افراد فنی همیشه آسان نیست. بسیاری از برنامهنویسان، بهخصوص افراد بسیار ماهر، احترام خود را صرفاً بر توانایی فنی بنا میکنند و این میتواند مانع Adoption مؤثر Scrum شود. اگر برنامهنویس به Product Owner احترام نگذارد، وقتی او دربارهٔ اهداف پروژه صحبت میکند گوش نخواهد داد.
Scrum Master خوب راههایی برای افزایش احترام متقابل پیدا میکند. مثلاً به برنامهنویسان نشان میدهد Product Owner درک عمیقی از نحوهٔ فکرکردن کاربران و نیازهای شرکت دارد. وقتی برنامهنویسان میبینند این دانش برای موفقیت پروژه چقدر مفید است، برای نظر Product Owner ارزش و احترام بیشتری قائل میشوند.
همه روی کار تمرکز دارند
وقتی عضو Scrum Team روی Sprint کار میکند، در مدت Sprint همان تنها کار اوست. آزاد است هر کاری را که برای کاملکردن Sprint Backlog لازم است انجام دهد و تغییرهای Backlog را در طول Sprint مدیریت کند. وقتی همه روی اهداف Sprint متمرکزند و آزادی انجام هر کار لازم را دارند، کل تیم میتواند خودش را سازمان دهد و هر زمان لازم شد بهراحتی جهت را تغییر دهد.
تیم حواسپرت، تیم کماثرتر است. در محیط کار مدرن افسانهای وجود دارد که افراد—بهخصوص برنامهنویسان—با Multitasking بهتر کار میکنند، چون اگر در پروژهٔ اول Block شوند میتوانند به Task پروژهٔ دوم بروند. انسان در دنیای واقعی اینگونه کار نمیکند. جابهجایی بین پروژهها یا حتی Taskهای نامرتبط یک پروژه، تأخیر و تلاش پیشبینینشده میافزاید، چون Context Switching سربار شناختی زیادی دارد. کنارگذاشتن کار فعلی و ادامهدادن پروژهای دیگر از همان نقطهٔ قبلی انرژی ذهنی قابلتوجهی میخواهد؛ معمولاً مجبورید کار قبلی را دوباره مرور کنید تا یادتان بیاید چه مسئلهای را حل میکردید. دستور به عضو تیم برای رفتن به Task پروژهای دیگر فقط زمان خود Task را مصرف نمیکند؛ زمان رفت و برگشت ذهنی هم اضافه میشود که گاهی تقریباً به اندازهٔ خود کار است.
صفحهٔ PDF 125
باور ندارید؟ این آزمایش ذهنی را انجام دهید. دو Task یکهفتهای دارید و فرض کنید با شکستن معجزهآسای قوانین فیزیک، Multitasking هیچ سرباری ندارد؛ میتوانید بیوقفه بین دو Task جابهجا شوید و در مجموع دقیقاً دو هفته طول میکشند. حتی در این شرایط کامل و ناممکن هم Multitasking منطقی نیست. اگر Multitask نکنید، Task اول در پایان هفتهٔ اول و Task دوم در پایان هفتهٔ دوم تمام میشود. اگر Multitask کنید، ناچار بخشی از هفتهٔ اول را روی Task دوم گذاشتهاید، پس Task اول تا هفتهٔ دوم تمام نمیشود. این یکی از دلایلی است که حتی اگر انسان در Multitasking خوب بود—که نیست—باز هم انجامش منطقی نبود.
Multitasking تنها حواسپرتی نیست. اعضا ممکن است مجبور شوند در جلسههای بیفایده و کمیتههای اضافی شرکت کنند، فعالیتهای نامرتبط با پروژه انجام دهند یا برای پروژههای دیگر Support بدهند. Scrum Team خوب اجازه دارد این حواسپرتیها را بدون خطر برای شغل یا Promotion خود نادیده بگیرد.⁷ کار پشتیبانی فوری مربوط به همین پروژه میتواند به Sprint Backlog افزوده شود، اما فقط اگر چیز دیگری برای جا شدن در Timebox بیرون بیاید.
تیم برای گشودگی (Openness) ارزش قائل است
وقتی در Scrum Team کار میکنید، بقیهٔ اعضا باید همیشه بدانند روی چه چیزی کار میکنید و چگونه پروژه را به سمت اهداف فعلی میبرید. به همین دلیل Practiceهای الگوی پایهٔ Scrum برای تشویق Openness طراحی شدهاند. Task Board اجازه میدهد همهٔ کار هر عضو و مقدار کار باقیمانده دیده شود. Burndown Chart به هر نفر اجازه میدهد خودش سرعت نزدیکشدن Sprint به اهدافش را بسنجد. Daily Scrum اگر مؤثر اجرا شود تقریباً تمرین خالص Openness است، چون هرکس Taskها، چالشها و پیشرفت را پیش روی کل تیم مطرح میکند. همهٔ اینها به ساخت فضای حمایت و تشویق متقابل کمک میکنند.
⁷ آیا این توصیه غیرواقعی به نظر میرسد؟ اگر تیم اجازه ندارد چیزی را که «حواسپرتی» مینامد نادیده بگیرد، شاید اصلاً حواسپرتی نیست. حواسپرتیای که نمیتوان نادیده گرفت یک Requirement است. اگر در تیم شما نادیدهگرفتن یک «حواسپرتی» مشکل جدی پروژه ایجاد میکند، Mindset تیم ممکن است مانع پذیرش Scrum باشد؛ این موضوعی است که میتوانید روی آن کار کنید.
ساخت فرهنگ Openness برای Scrum Team مثبت و عالی به نظر میرسد و همینطور هم هست؛ اما اغلب یکی از سختترین کارهاست، چون از رایجترین نقاط برخورد ارزشهای Scrum با فرهنگ قبلی شرکت است.
بسیاری از شرکتها فرهنگی دارند که Transparency را دلسرد و با سلسلهمراتب سختی متکی بر Opaqueness جایگزین میکند. مدیرانی که چنین فرهنگی میسازند چند جور سود میبرند: در سازمان غیرشفاف خیلی آسانتر است به تیم هدف غیرواقعی بدهند («مهم نیست چطور، فقط انجامش بده!») و آنها را مجبور به اضافهکاری کنند؛ و وقتی تیم ناگزیر شکست خورد، مدیر امکان CYA و انکارپذیری دارد («تقصیر من نبود، خودشان خراب کردند!»).
به همین دلیل Openness و Self-Organization گاهی «ریل سوم» دستنزدنی Adoption Scrum میشوند. برای درست انجامشدن Scrum مفاهیمی مرکزیاند، اما از شرکت میخواهند تیم را متفاوت از گذشته مدیریت کند. دیدهشدن جزئیات توسعه، پوشش CYA را از مدیر غیرشفاف میگیرد. بسیاری از Scrum Teamهای تازهکار دیدهاند وقتی مدیران غیرشفاف فهمیدند کار واقعاً چگونه ساخته میشود، Adoption از بالا تضعیف شد.
Openness برای یک مدیر کارتونیِ کلهتیز و غیرشفاف تهدیدکننده است؛ ولی در عمل حتی برای تیم خوب هم دشوار است. از دید توسعهدهندهای نگاه کنید که Expert بخشی از Code شناخته میشود، Project Managerی که «نگهبان Plan» است، یا Product Ownerی که تنها نقطهٔ تماس بسیاری از کاربران و تصمیمگیر اصلی دربارهٔ محتوای نرمافزار است. هرکدام حق دارند این چیزها را سهم خودشان در پروژه ببینند. بازکردن آنها برای تیم و تشویق دیگران به مالکیت و تغییر بدون گرفتن اجازه میتواند بسیار دشوار باشد. این مقاومت فردی در برابر Openness طبیعی است. اما وقتی از آن عبور کنند و مالکیت—از جمله Accountability هنگام خطا—را با کل تیم شریک شوند، همه سود میبرند، چون تنها در این صورت میتوانند به هم اعتماد کنند و نرمافزار ارزشمندتر را سریع تحویل دهند.
اعضای تیم شجاعت دفاع از پروژه را دارند
وقتی Openness را به Opaqueness ترجیح میدهید، تیم را قویتر میکنید، نه خودتان را به هزینهٔ تیم. این کار شجاعت میخواهد، اما نتیجه محصول و محیط کار بهتر است.
Scrum Team شجاعت زندگیکردن بر اساس ارزشها و اصولی را دارد که به پروژه سود میرسانند. مقاومت مداوم شرکتی که ارزشهایش با Scrum و Agile برخورد دارد، شجاعت میخواهد. همهٔ اعضا، بهخصوص Scrum Master، باید هوشیار باشند. همچنین هرکس باید حاضر باشد اعتماد کند که تحویل نرمافزار ارزشمند به او کمک میکند بر مقاومت نسبت به این ارزشها غلبه کند. این هم شجاعت میخواهد، بهخصوص وقتی زمان Review با رئیس میرسد. لازم است بتوانید به خودتان بگویید: «کمک به این تیم برای تولید نرمافزار ارزشمند برای من مهمتر از حقِ فخرفروشی دربارهٔ سهم شخصی خودم است.»
پس چگونه در تیم شجاعت میسازید؟ چگونه کاری میکنید تیم به خودش باور داشته باشد و باور کند Scrum نهفقط نرمافزار ارزشمندتری میسازد، بلکه شرکت هم ارزش Methodology جدید را خواهد دید؟
نکات کلیدی
- الگوی پایهٔ Scrum نقشها و Practiceهای Scrum را پوشش میدهد: Scrum Master، Product Owner، Team، Sprintها، Product/Sprint Backlog، Daily Scrum، Review و Retrospective.
- برای اینکه تیم واقعاً Scrum را «بگیرد»، اعضا باید از صرف اجرای Practiceها فراتر بروند و Self-Organization و Collective Commitment را بفهمند.
- تیمها از استعارهٔ خوک و مرغ استفاده میکنند تا معنای واقعی تعهد به تحویل نرمافزار ارزشمند و مالکیت واقعی همهٔ خروجیهای تیم را بفهمند.
- برای تبدیلشدن به Scrum Team مؤثر، تیم باید ارزشهای تعهد، احترام، تمرکز، گشودگی و شجاعت را واقعاً بفهمد و درونی کند.
تصاویر زیر از صفحات مربوط به همین مقاله در PDF اصلی استخراج و بهصورت دادهٔ داخلی Base64 جاسازی شدهاند.
تصویر منبع - صفحهٔ PDF 120