فصل ۲: درک ارزشهای اجایل — از بحران Waterfall تا دیدگاه تکهتکه
صفحهٔ PDF 35
«ما به این دلیل درست عمل نمیکنیم که فضیلت یا برتری داریم؛ بلکه چون درست عمل کردهایم صاحب آنها میشویم. ما همان چیزی هستیم که بارها انجام میدهیم. پس برتری یک عمل نیست، بلکه یک عادت است.» — Aristotle، Nicomachean Ethics
اجایل بهعنوان یک جنبش با هر رویکردی که پیش از آن در توسعهٔ نرمافزار وجود داشت تفاوت دارد، زیرا از مجموعهای از ایدهها، ارزشها و اصول آغاز شد که یک ذهنیت را مجسم میکنند. از دریچهٔ همین ایدههاست که میتوانید بهعنوان یک متخصص اجایلتر و بهعنوان عضو تیم پروژه ارزشمندتر شوید.
جنبش اجایل دنیای توسعهٔ نرمافزار را متحول میکند. تیمهایی که اجایل را پذیرفتهاند بهطور مداوم از بهبود—و گاهی جهشهای عظیم—در توانایی ساخت نرمافزار عالی گزارش دادهاند. تیمهایی که پذیرش اجایل را با موفقیت انجام میدهند محصولات نرمافزاری بهتر و باکیفیتتری میسازند و این کار را سریعتر از گذشته انجام میدهند.
صنعت ما با اجایل در نقطهٔ عطف قرار دارد. اجایل از یک جریان حاشیهای به یک نهاد تثبیتشده تبدیل شده است. در سالهای نخست، کسانی که اجایل را میپذیرفتند باید شرکت و همتیمیهایشان را قانع میکردند که این رویکرد کار میکند و ارزش انجامدادن دارد. اکنون کمتر کسی تردید دارد که توسعهٔ اجایل روشی بسیار مؤثر برای ساخت نرمافزار است. یک پیمایش مهم در سال ۲۰۰۸ نشان داد بیش از نیمی از تیمهای نرمافزاری بررسیشده از متدولوژیها، practiceها یا اصول اجایل استفاده میکردند و از آن زمان اجایل فقط رشد کرده است. تیمهای اجایل نیز کمکم از مسئلهٔ «خودمان چگونه اجایل شویم؟» فراتر رفتهاند و در حال پیدا کردن راهی برای گسترش توسعهٔ اجایل در سراسر شرکت هستند.
اما همیشه چنین نبود. شرکتها بهطور سنتی در پروژههای نرمافزاری از فرایند waterfall استفاده میکردند: تیم ابتدا requirements را تعریف میکرد، کل پروژه را برنامهریزی میکرد، نرمافزار را طراحی میکرد و بعد کد را میساخت و محصول را آزمایش میکرد. طی سالها نرمافزارهای زیادی—هم عالی و هم بسیار بد—با این روش ساخته شدند. اما با گذشت دههها، تیمهای مختلف در شرکتهای مختلف بارها با همان مشکلات روبهرو شدند و بعضی افراد شروع کردند به این احتمال فکر کنند که شاید خود فرایند waterfall یکی از منابع اصلی شکست پروژه باشد.
پاورقی 1 — The Forrester 2008 Global Agile Company Online Survey.
صفحهٔ PDF 36
داستان اجایل زمانی شروع شد که گروه کوچکی از افراد نوآور گرد هم آمدند تا راه متفاوتی برای فکرکردن به این مشکلات پیدا کنند. نخستین کار آنها تعریف چهار ارزش اصلی مشترک میان تیمها و پروژههای موفق بود که آن را Manifesto for Agile Software Development نامیدند:
- افراد و تعاملات، مهمتر از فرایندها و ابزارها.
- نرمافزارِ کارا، مهمتر از مستندات جامع.
- همکاری با مشتری، مهمتر از مذاکرهٔ قراردادی.
- پاسخگویی به تغییر، مهمتر از پیروی از برنامه.
در این فصل میآموزید این ارزشها از کجا آمدهاند، چه معنایی دارند و چگونه به پروژهٔ شما مربوط میشوند. همچنین تیمی خسته از waterfall را در نخستین تلاشش برای اجرای اجایل دنبال میکنید؛ پیش از آنکه اعضای تیم واقعاً بفهمند این ارزشها چگونه در مورد آنها صدق میکند. هنگام خواندن داستان ببینید آیا میتوانید تشخیص دهید فهم بهتر این ارزشها چگونه میتوانست مانع مشکلاتشان شود.
روایت: تیمی روی پروژهٔ jukebox پخش صوتی کار میکند.
- Dan: توسعهدهندهٔ ارشد و معمار.
- Bruce: رهبر تیم.
- Joanna: مدیر پروژهٔ تازهاستخدامشده.
- Tom: مالک محصول.
یک رهبر تیم، یک معمار و یک مدیر پروژه وارد یک بار میشوند...
Dan توسعهدهندهٔ ارشد و معماری در شرکتی است که بازیهای سکهای و kiosk تولید میکند. او از ماشینهای pinball آرکید تا دستگاههای ATM روی پروژههای مختلف کار کرده است. چند سال اخیر با رهبر تیمی به نام Bruce کار کرده و آن دو هنگام انتشار بزرگترین محصول شرکت، دستگاه slot لاسوگاسی «Slot-o-matic Weekend Warrior»، به هم نزدیک شدهاند.
Joanna چند ماه قبل بهعنوان مدیر پروژه استخدام شده تا پروژهٔ نرمافزار نسل جدید jukeboxهای streaming audio را هدایت کند؛ محصولی که شرکت میخواهد به barها و restaurantها بفروشد. استخدام او موفقیت بزرگی بود؛ او را از رقیبی جذب کرده بودند که jukebox موفقی در بازار داشت. Joanna با Dan و Bruce رابطهٔ خوبی پیدا کرده و از شروع پروژهٔ تازه با آنها هیجانزده است.
اما Dan و Bruce خیلی کمتر از Joanna هیجان دارند. یک روز بعد از کار برای نوشیدنی بیرون میروند و آن دو توضیح میدهند چرا تیم برای پروژهٔ slot machine نام دیگری ساخته بود: «Slog-o-matic Weekend Killer»؛ یعنی پروژهای که آخر هفتهها را میکشد.
Joanna خوشحال نشد وقتی فهمید در این شرکت پروژهٔ ناموفق استثنا نیست، بلکه قاعده است. سه پروژهٔ قبلی از سوی مدیران شرکت «موفق» اعلام شده بودند، اما فقط به این دلیل به خط پایان رسیدند که Dan و Bruce ساعتهای غیرقابلباوری کار کرده بودند. بدتر اینکه مجبور شدند چشمشان را ببندند و در کد میانبرهایی بزنند که امروز کابوس پشتیبانی ایجاد کرده است؛ مثلاً نمونهٔ اولیهٔ یک feature را با عجله patch کردند و وارد production کردند، اما بعد معلوم شد مشکلات شدید performance دارد چون بخشهایی از آن هیچوقت برای scale شدن ساخته نشده بود.
صفحهٔ PDF 37
در ادامهٔ گفتوگو Joanna الگو را تشخیص داد و فهمید چه چیزی مشکل ایجاد میکند: شرکت یک فرایند waterfall بهخصوص ناکارآمد دارد. تیمی که waterfall را دنبال میکند تلاش میکند هرچه زودتر شرح کاملی از نرمافزاری که قرار است ساخته شود بنویسد. وقتی کاربران، مدیران و مدیران ارشد دقیقاً روی کارهایی که نرمافزار باید انجام دهد—requirements—توافق کردند، سندی شامل requirements—specification—به تیم توسعه تحویل میدهند و تیم میرود دقیقاً همان چیزی را که نوشته شده میسازد. بعد از آن تیم testing وارد میشود و تأیید میکند نرمافزار با سند تطابق دارد. بسیاری از افراد اجایل به این رویکرد «big requirements up front» یا BRUF میگویند.
Joanna از تجربهٔ پروژههای خودش میدانست که theory با practice تفاوت دارد. هرچند برخی تیمها waterfall بسیار مؤثری دارند، بسیاری با آن مشکل دارند. کمکم به این نتیجه رسید که تیم جدیدش احتمالاً از همان گروه مشکلدار است.
شکل 2-1 — مدل waterfall.
در گفتوگو، Bruce و Dan چند نکته گفتند که نظر Joanna را تقویت کرد. همانطور که حدس میزد، specificationهای زیادی در کلاسورهای بزرگ در سراسر شرکت خاک میخوردند. somehow همه انتظار داشتند گروهی از کاربران، مدیران و مدیران ارشد یک specification کامل و بینقص بسازند. در واقعیت، specification عادت بدی داشت که تغییر کند؛ تا زمانی که به دست تیم برسد دیگر دقیق نبود و تا وقتی ساخت نرمافزار تمام شود میتوانست بهشدت غلط باشد. Bruce، Dan و بسیاری از افراد شرکت میدانستند انتظار spec بینقص غیرمنطقی است، اما همچنان پروژهها را طوری اداره میکردند که انگار چنین چیزی ممکن است.
با ادامهٔ شب، Bruce راحتتر و البته مستتر شد و مشکل دیگری را مطرح کرد: بسیاری از تیمهای شرکت در خودِ ساخت نرمافزار هم مشکل داشتند. حتی اگر کاربران requirements را درست تعریف میکردند—که بهندرت اتفاق میافتاد—و حتی اگر تیم پس از خواندن متن requirements آنها را بینقص میفهمید—که هنوز یک بار هم رخ نداده بود—باز هم اغلب از ابزارهای ضعیف استفاده میکردند و با software design و architecture مشکل داشتند. نتیجه این بود که تیمهای Bruce بارها نرمافزاری پر از bug و غالباً نگهداشتناپذیر میساختند.
صفحهٔ PDF 38
تصویر منبع - صفحهٔ PDF 38
هر دو مشکل به شکستهای زیاد منجر شده بود؛ بهخصوص چون از دید آنها پروژهای که برایش هفتههای ۹۰ ساعته کار کنند و در پایان کد bugدار تحویل دهند، شکستخورده است. Joanna توضیح داد بزرگترین علت شکستها ناتوانی فرایند waterfall شرکت در مدیریت تغییر است. در دنیای کامل، waterfall بهخوبی کار میکند، چون ابتدای پروژه همه دقیقاً میدانند در پایان به چه نیاز دارند؛ همهچیز را در یک spec مرتب مینویسند و برای ساخت به تیم میدهند. اما پروژههای واقعی تقریباً هیچوقت اینگونه پیش نمیروند.
Dan و Bruce حالا رسماً مست شده بودند و جلسهٔ گلایه با Joanna به یک ماراتن تبدیل شده بود. Dan گفت تقریباً در تمام پروژهها مشتری وسط کار تصمیم گرفته تیم باید چیزی متفاوت از برنامهٔ اولیه بسازد. طبق waterfall سختگیرانه، باید همه به ابتدای آبشار برمیگشتند: specification کاملاً جدید مینوشتند، design متفاوتی میساختند و plan تازهای تهیه میکردند. اما در عمل تقریباً هیچوقت چنین زمانی وجود نداشت و بهندرت میتوانستند همهٔ کدی را که تا آن لحظه نوشته شده دور بریزند. معمولاً مجبور بودند از کد موجود راهحلی hackشده بسازند. این rework باعث bug میشد، چون نرمافزاری که برای یک هدف طراحی شده وقتی زیر فشار و با عجله برای هدف دیگری تغییر کند به کدی شلوغ و درهم تبدیل میشود. تطبیق درست آن زمان گرانبهای پروژه را مصرف میکرد، پس تیم در نهایت workaroundهای ضعیف و کد شکننده تحویل میداد.
تا آخر شب، Dan، Bruce و Joanna فهمیده بودند مشکلات پروژه از مستندات بیش از حد سختگیرانه، ارتباط ضعیف و bugها میآید و نتیجه پروژههایی است که نمیتوانند با تغییرهای طبیعی پروژه همگام شوند.
پایان شب bartender برای هر سه taxi گرفت. درست پیش از رفتن، Dan گفت خوشحال است بالاخره این همه حرف را از سینه بیرون ریخته است. Joanna هم خوشحال بود تصویر بهتری از پروژهٔ جدید دارد، اما بسیار کمتر خوشبین بود. با خودش فکر میکرد آیا راهی پیدا خواهد کرد که این مشکلات را حل کند؟
گلولهٔ نقرهای وجود ندارد
امروز میدانیم هیچ «بهترین» روش واحدی برای ساخت نرمافزار وجود ندارد. اکنون این جمله جنجالی نیست، اما در بخش بزرگی از قرن گذشته بسیاری از افراد صنعت با صدای بلند مخالفت میکردند. حس عمومی این بود که میتوان یک متد بسیار دستوری و «گلولهٔ نقرهای» پیدا کرد که مشکلات پروژه را برای همه، همهجا حل کند. بسیاری فکر میکردند توسعهدهنده میتواند نرمافزار را صرفاً با دنبالکردن دستورالعملها بسازد؛ مثل دنبالکردن recipe یا مونتاژ محصول روی خط تولید.
طنز ماجرا این است که یکی از پراستنادترین مقالههای مهندسی نرمافزار، مقالهٔ ۱۹۸۶ Fred Brooks با عنوان “No Silver Bullet” است که بهطور قاطع نشان میدهد چنین هدفی ناممکن است؛ بااینحال هنوز افراد را از تلاش برای پیداکردن یکی بازنداشته است.
صفحهٔ PDF 39
راهحلهای پیشنهادی «گلولهٔ نقرهای» زیاد بودند و معمولاً یکی از دو شکل را داشتند: متدولوژیای که ادعا میکرد راهی بیخطا برای ساخت نرمافزار میدهد، یا فناوریای که برنامهنویس با آن میتوانست bugها را پیشگیری یا حذف کند. ایده این بود که اگر شرکت یک متدولوژی و یک فناوری انتخاب کند، کافی است تیم آیین رسمی شرکت را دنبال کند تا نرمافزار عالی شروع به بیرونآمدن کند.
Dan و Bruce از نزدیک میدانند این کار جواب نمیدهد؛ سالها شاهد بودهاند مدیران شرکت متدولوژیها و فناوریهای مختلف را روی پروژهها میریزند، بدون اینکه بهبود واقعی و پایدار رخ دهد. تلاش شرکت برای پیدا کردن silver bullet فرایندی تقریباً همیشه برای همه ناامیدکننده بوده، بهویژه برای Dan و Bruce که باید زنجیرهای همیشهدرحالتغییر از فرایندهایی را دنبال میکردند که خودشان نخواسته بودند.
Joanna هم در شغل قبلی با این وضعیت غریبه نبود. مرتب مجموعهای سخت و ثابت از requirements به او میدادند و دستور میدادند plan ساخت نرمافزار را تهیه کند. بعد plan او به تیم داده میشد و از تیم میخواستند کلمهبهکلمه اجرا کند. تیمهایی که «کار را برنامهریزی میکردند و برنامه را اجرا میکردند» محکوم بودند نرمافزاری بسازند که اغلب حتی روز deployment هم قدیمی و برای کاربر کمفایده بود.
اما نکتهای Joanna را به فکر فرو میبرد: بعضی تیمهایی که در آنها کار کرده بود واقعاً با فرایند waterfall یا waterfall-like سنگین از نظر مستندات اولیه، نرمافزار عالی تحویل داده بودند. برخی از بهترین پروژههای او در شرکتی بود که نرمافزار تجهیزات پزشکی را با practiceهای waterfall میساخت. Waterfall واقعاً میتواند جواب بدهد. اگر از ابتدا واقعاً بدانید چه نیاز دارید، نوشتنش پیش از شروع روشی کارآمد است. پروژههای تجهیزات پزشکی Joanna نمونههای نادری بودند که requirements واقعاً از ابتدا درست بود و در طول پروژه فقط تغییرهای بسیار کمی لازم داشت.
اما requirements پایدار بهتنهایی برای موفقیت waterfall کافی نیست. تیمهایی که با waterfall نرمافزار عالی میسازند معمولاً چند ویژگی مشترک دارند:
- ارتباط خوب: تیمهای موفق در شرکتهای waterfallمحور در سراسر پروژه بهطور پیوسته با کاربران، مدیران و مدیران ارشد صحبت میکنند.
- practiceهای خوب: بهویژه code review و automated testing که هدفشان یافتن bug هرچه زودتر در فرایند است. این رویکرد اغلب «defect prevention» نامیده میشود و تیم را وادار میکند فعالانه فکر کند bug اساساً چگونه وارد کد شده است.
- کشوهای پر از مستنداتی که بهندرت باز میشوند؛ چون اعضای تیم میفهمند خودِ عمل نوشتن plan و پرسشهایی که در برنامهریزی مطرح میشود مهمتر از چسبیدن کورکورانه به سند در ادامه است.
صفحهٔ PDF 40
قطعهٔ دیگری از پازل هم وجود دارد. Dan پس از انقلاب ابزارها و فناوریهای توسعهٔ دههٔ ۱۹۹۰ وارد حرفه شد؛ بنابراین همیشه در تیمهایی کار کرده که برای طراحی بهتر از object-oriented development استفاده میکردند. version control، automated testing، IDEهای بهتر با قابلیتهایی برای خودکارسازی practiceهایی مثل refactoring و class design و ابزارهای انقلابی دیگر به Dan کمک کردهاند کنترل کد را حفظ کند. Bruce سابقهٔ بیشتری دارد و طی سالها دیده توسعهدهندگان تیمهایش بیشتر و بیشتر ابزارهای نرمافزاری برای خودکارسازی کارهای تکراری میپذیرند.
Dan و Bruce از تجربهٔ خود میدانند موفقترین پروژهها از همین practiceها، ابزارها و ایدهها مؤثر استفاده کردهاند. در نتیجه زمان بیشتری برای گفتوگو با کاربران و همتیمیها و فکرکردن به مسئلههای واقعی باقی میماند، بهجای جنگیدن با کد.
و مشخص میشود وقتی پروژههای waterfall مؤثر اداره میشوند، علتش این است که تیمها بسیاری از همان ارزشها، اصول و practiceهایی را جدی میگیرند که پروژههای اجایل دنبال میکنند. پروژههایی که برخی تکنیکها و practiceهای اجایل را اجرا میکنند اما واقعاً از ارزشها و اصول اجایل پیروی نمیکنند، اغلب به همان مشکلاتی دچار میشوند که پروژههای waterfall را آزار میدهد.
متأسفانه Bruce، Dan و Joanna قرار است این را به روش سخت یاد بگیرند.
نکات کلیدی
- فرایند waterfall از تیم میخواهد ابتدای پروژه شرح کاملی از نرمافزار بنویسد و بعد دقیقاً همان را بسازد.
- تمرکز waterfall بر مستندات بهجای collaboration، پاسخ به تغییر را دشوار میکند.
- هیچ فرایند یا practice «گلولهٔ نقرهای» وجود ندارد که پروژهها را بینقص اجرا کند.
- تیمهایی که waterfall را موفق میکنند، در واقع practiceها و اصول مؤثر نرمافزاری، بهویژه موارد بهبوددهندهٔ ارتباط، را میپذیرند.
اجایل به نجات میآید! درست است؟
احتمالاً حتی اگر واژهٔ waterfall را تازه یاد گرفته باشید، حس چنین فرایندی را میشناسید. Joanna، Bruce و Dan هم میشناسند. پیش از ورود به برنامهریزی پروژهٔ jukebox دربارهٔ مشکلاتی که waterfall در گذشته برایشان ساخته بود حرف زدند.
صفحهٔ PDF 41
در پروژهٔ قبلی، Bruce و Dan با Tom، مدیر حساب مشتری شرکت، کار میکردند. Tom زمان زیادی را در سفر میگذراند و به مشتریان در arcadeها، casinoها، barها و restaurantها برای نصب و استفاده از محصولات کمک میکرد. سه نفر نخستین چند هفتهٔ پروژه را صرف ساخت specification دستگاه slot جدید کردند. Tom فقط نیمی از زمان در دفتر بود و این به Bruce و Dan فرصت داد طراحی نرمافزار و معماری را شروع کنند. وقتی هر سه روی requirements توافق کردند، جلسهٔ بزرگی با CEO و مدیران ارشد گذاشتند تا requirements را مرور کنند، تغییرهای لازم را بدهند و مجوز شروع ساخت را بگیرند.
بعد Tom دوباره به سفر رفت و کار را به Bruce و Dan سپرد. آنها پروژه را به taskها شکستند، میان تیم تقسیم کردند و همه شروع به ساخت کردند. وقتی کار تقریباً تمام شد، Tom گروهی از کاربران business، project managerها و executiveها را در اتاق کنفرانس جمع کرد تا نسخهٔ تقریباً کامل Slot-o-matic Weekend Warrior را demo کنند.
همهچیز خیلی بدتر از انتظار پیش رفت.
CEO در demo گفت: «نرمافزار عالی به نظر میرسد، اما قرار نبود حالت video poker هم داشته باشد؟» کشف ناخوشایندی بود. apparently CEO تصور میکرد نرمافزاری ساخته میشود که بتوان آن را هم روی سختافزار slot machine و هم روی سختافزار video poker deploy کرد. دربارهٔ این موضوع میان مدیران ارشد، board و صاحبان دو مشتری بزرگ شرکت بحث زیادی شده بود. حیف که هیچکس زحمت نداده بود تیم را خبر کند.
بدترین قسمت این بود که اگر Dan اوایل پروژه میدانست، تغییر جهت سخت نبود. اما حالا مجبور شدند بخش عظیمی از کد نوشتهشده را بیرون بکشند و با کدی retrofitشده از پروژهٔ video poker جایگزین کنند. هفتهها صرف troubleshooting bugهای عجیب ناشی از integration شد. Dan شبهای زیادی به Bruce شکایت میکرد که این مشکل صددرصد قابلپیشبینی بوده و تقریباً همیشه وقتی کدی که برای یک کار ساخته شده با عجله برای کار دیگری استفاده میشود همین اتفاق میافتد. حالا یک تودهٔ spaghetti code درهم نصیبش شده بود که نگهداریاش سخت بود و تیم را عصبانی میکرد، چون واضح بود لازم نبود چنین شود.
پاورقی 2 — اگر مدیر پروژهای هستید که برای آزمون PMP آماده شدهاید، احتمالاً waterfall را بهخوبی خواندهاید. انصافاً PMP متدولوژیهای صنایع مختلف را پوشش میدهد، نه فقط software. وقتی skyscraper یا bridge میسازید داشتن blueprint کامل در ابتدا معمولاً ایدهٔ خوبی است، هرچند در مسیر ممکن است تغییر کند.
صفحهٔ PDF 42
مشکل فقط برای Dan و Bruce نبود. مدیر پروژهٔ آن پروژه آنقدر ناراضی شد که شرکت را ترک کرد. او به estimateها و status تیم اعتماد کرده بود و تغییر video poker همهٔ آنها را نابود کرد. تیم نمیتوانست تغییر سختافزاری پیشبینینشده را بداند، اما این موضوع زندگی مدیر پروژه را آسانتر نمیکرد. با اینکه واقعیتهای پروژه تغییر کرده بود، deadline در سنگ حک شده بود. پایان پروژه plan کاملاً قدیمی و عملاً بیفایده شده بود، اما همچنان مدیر پروژه را بابت همان plan پاسخگو میدانستند. مدیران ارشد او را بهشدت سرزنش کردند و تنها دفاعش این بود که تیم از ابتدا اعداد خوبی نداده بود. مدت کوتاهی بعد شغل دیگری پیدا کرد و Joanna کمی بعد استخدام شد.
Tom شاید ناامیدترین فرد بود، چون وقتی مشتری مشکل پیدا میکرد او باید پاسخگو میبود. بزرگترین مشتری محصول، casinoای در Las Vegas به نام Little Rock بود که میخواست دستگاههای slot خود را با themeهای شهرهای Arkansas شخصیسازی کند. مشتری feature جدید را خواسته بود تا بین shiftها بازیها را عوض کند بدون اینکه kioskها جابهجا شوند. مهندسانشان مرتب با bugهای باقیمانده در نرمافزار تیم Bruce روبهرو میشدند و Tom و Dan هفتهها تلفنی patch و workaround میساختند. Little Rock قرارداد فعلی را لغو نکرد، اما سفارش بزرگ بعدی را به رقیب داد و پنهان نبود که CEO و مدیران، پروژهٔ Slot-o-matic Weekend Warrior را مسئول از دست رفتن کسبوکار میدانستند.
در پایان همه میدانستند پروژه خراب شده است. هرکس هم ایدهٔ خوبی داشت که چرا تقصیر شخص دیگری بوده است. اما ظاهراً هیچکس نمیدانست چگونه این نوع مشکلات تکرارشونده را اصلاح کند. نرمافزار تحویلدادهشده هم همچنان یک بههمریختگی بزرگ بود.
افزودن اجایل تفاوت ایجاد میکند
دفعهٔ بعد که Tom در شهر بود، Bruce، Dan و Joanna او را به ناهار بردند. بعد از مدتی همدردی دربارهٔ مشکلات پروژههای گذشته، Joanna پیشنهاد کرد وقتش رسیده اجایل شوند.
مثل بسیاری از تیمها در آغاز مهاجرت به اجایل، بحث را با این سؤال شروع کردند که واژهٔ «agile» برای هرکدام چه معنایی دارد. برای Bruce، اجایل به دنیای توسعهٔ اجایل اشاره میکرد: کتابها، practiceها، دورههای آموزشی، blogها و افرادی که اجایل را اجرا میکنند. برای Joanna، اجایل مشخصاً «توانایی پروژه برای مدیریت تغییر» بود و عمدتاً مجموعهای از practiceها با همین هدف. Dan فکر میکرد اجایل یعنی هیچ documentationای ننویسیم و مستقیم سراغ code برویم. Tom اصلاً نمیدانست دربارهٔ چه حرف میزنند، اما از اینکه صحبت از demoهای زیاد در طول مسیر بود خوشحال بود، چون نمیخواست اتفاق دفعهٔ قبل تکرار شود.
صفحهٔ PDF 43
اعضای تیمی که شروع به «اجایل شدن» میکند معمولاً دربارهٔ تکنیکها، practiceها و ایدههای اجایل آموزش میبینند و این تیم هم استثنا نبود. Dan به Agile Alliance پیوست و با سایر practitioners ارتباط گرفت. Bruce و Joanna blogها و کتابهای توسعه و مدیریت پروژهٔ اجایل را خواندند. هر دو ایدههای خوبی دیدند و شخصاً شروع به استفاده از آموختهها برای پیشبینی و حل مشکلات پروژه کردند. هرکس چیز متفاوتی کشف کرد و سریع وارد کار کرد.
Dan در پروژههای قبلی automated unit test نوشته بود، اما بسیاری از توسعهدهندگان پروژهٔ jukebox هرگز این کار را نکرده بودند. او با آنها روی unit testing و test-driven development کار کرد. automated build script ساخت و build serverای راه انداخت که هر ساعت code را checkout میکرد، نرمافزار را build میکرد و testها را اجرا میکرد. و جواب داد. بلافاصله بهبود کد دیده شد. هر روز توسعهدهندهای bugای پیدا میکرد که بدون automated test هیچوقت کشف نمیشد. روشن بود تیم از هفتهها debugging و پیدا کردن مشکلات سخت در میدان جلوگیری میکند. نهتنها bug کمتر میشد، بلکه احساس میکردند کد ساختهشده راحتتر تغییر میکند.
اگر اکنون همهٔ این practiceها—مثل test-driven development—را نمیشناسید اشکالی ندارد. در سراسر کتاب دربارهشان یاد خواهید گرفت و practiceهای تازه در متن اصلی بهصورت برجسته مشخص شدهاند.
Joanna در دورهٔ Scrum شرکت کرد و حالا تیم او را Scrum Master صدا میزند؛ هرچند در دوره فهمیده تفاوت بزرگی میان Scrum Master و project manager وجود دارد و صددرصد مطمئن نیست نقشی که در پروژه دارد واقعاً شایستهٔ عنوان Scrum Master باشد. او به تیم کمک میکند پروژه را به iterationها تقسیم کند، پیشرفت را روی task board دنبال کند و با project velocity و burndown chart—نمودارهای خطی که مقدار کار باقیمانده را روزانه دنبال میکنند و وقتی کار تمام شد به صفر «میسوزند»—همه را در جریان نگه دارد. برای نخستین بار تیم واقعاً به کار مدیر پروژه علاقه نشان میدهد و این موضوع پیشرفت کار را بهتر میکند.
Tom هم میخواست سهمی در بهبود اجایل داشته باشد. Dan، Bruce و Joanna او را product owner نامیدند و Tom شروع کرد برای تیم user story بنویسد تا تصویر بهتری از کاری که نرمافزار باید انجام دهد داشته باشند. با تیم release plan را بر اساس storyها ساخت و حالا احساس میکرد کنترل مستقیمتری بر آنچه تیم میسازد دارد.
صفحهٔ PDF 44
بهتر از همه اینکه Bruce daily standupهایی با Joanna، Dan و تمام programmerها راه انداخت و Tom هم شروع به حضور کرد. ابتدا کمی awkward بود، اما وقتی پروژه راه افتاد همه در دادن feedback واقعی و assessment صادقانه از وضعیت پروژه راحت شدند. Bruce تیم را قانع کرد پایان هر iteration با هم retrospective برگزار کنند و از اینکه تیم واقعاً تلاش میکرد بهبودهایی را که در retrospective مطرح میشود اجرا کند خوشحال بود.
نتایج «بهتر از انجامندادن»
همهچیز جواب داد. تیم بهتر شد و پروژه بهتر پیش رفت... تا حدی.
با «اجایل شدن» هر عضو تیم در کار خودش بهتر شد. Dan و توسعهدهندگان عادتهای بهتر ساختند و کد بهتری نوشتند. Joanna هر لحظه تصویر دقیقتری از وضعیت پروژه داشت. Tom بسیار بیشتر با تیم ارتباط گرفت و این کنترل او بر نرمافزار ساختهشده را بهتر کرد؛ در نتیجه بهتر میتوانست نیاز کاربران را تحویل دهد. Bruce میتوانست روی رشد مهارتها و ارتباطات تیم تمرکز کند.
اما آیا آنها واقعاً یک تیم اجایل شدهاند؟
practiceهای عالی زیادی پذیرفتند. بسیاری نسخههای بهتر همان کارهایی بودند که قبلاً میکردند و همه باعث شدند هر شخص در شغل خودش productiveتر شود. این قطعاً بهبود بود.
اما با اینکه تیم خوشحالتر بود و پروژهٔ jukebox واقعاً بهتر از پروژههای قبلی پیش میرفت، دربارهٔ دنیای تازه و اجایلترشان تردیدهایی هم داشتند. Dan فکر میکرد کد تیم قطعاً بهتر شده، اما برای رسیدن به schedule گاهی مجبور به technical sacrifice میشود.
Joanna از اینکه روی شیوهٔ ادارهٔ پروژه کنترل بیشتری دارد خوشحال است، اما شکستن پروژه به iterationهای کوتاه کمی احساس نابینایی به او میدهد. بهجای schedule بزرگ top-down که نقشهٔ راه باشد، اکنون بیشتر به تیم وابسته است تا در daily standup بگویند چه میگذرد. این جلسهها مفیدند اما عمدتاً هر عضو status خودش را میخواند؛ Joanna هم با دقت مینویسد و به stakeholderها منتقل میکند. کمکم حس میکند بیشتر coordinator یا organizer است تا project manager کنترلکنندهٔ پروژه. تمرکزش فقط روی status قرار گرفته و همین تشخیص obstacle و حذف آنها برای تیم را دشوار میکند. تیم در واکنش به change بهتر شده، اما Joanna در وضعیت ناراحتکنندهای قرار دارد که تمام تمرکزش «واکنش» است نه planning.
صفحهٔ PDF 45
Tom از اینکه بهعنوان product owner توان بیشتری برای تعریف آنچه تیم میسازد پیدا کرده هیجانزده است، اما دو دل هم هست، چون احساس میکند انتظار دارند تماموقت برای تیم کار کند. باید در جلسههای روزانه حاضر شود و دائماً به email و پرسشهای توسعهدهندگان دربارهٔ جزئیات نرمافزار پاسخ دهد. بعضی پرسشها را جوابش را نمیداند و گاهی آرزو میکند خودشان جواب بدهند. او از قبل یک شغل دارد و احساس میکند دیگران در نیمهٔ راه به او نمیرسند؛ انگار تمام مسئولیت ساخت محصول عالی را به دوش او برمیگردانند، در حالی که همهٔ جوابها را ندارد. بالاخره شغل «واقعی» او account manager است و jukeboxها خودشان فروخته نمیشوند. اگر تمام وقتش را صرف پاسخ به programmerها کند، چطور حسابهای مشتری و نیازهای کاربران را بهروز نگه دارد؟
Bruce از تحویلهای مکرر تیم راضی است، اما وقتی عقب میایستد و دقیق نگاه میکند چیزی ناراضیکننده و ناقص به نظر میرسد و دلیلش را نمیداند. نسبت به پروژههای قبلی که همیشه تا مرز شکست میرفتند این وضعیت واضحاً بهتر است. پذیرش اجایل کارها را بهتر کرده، قهرمانبازی فردی را کاهش داده و تعداد شبها و آخرهفتههای کاری را کم کرده است، اما Bruce احساس میکند اجایلشدن مجموعهٔ تازهای از مشکلات هم آورده است.
برای اعضای تیم، بهویژه team leadها، غیرعادی نیست که بعد از نخستین تلاش برای پذیرش اجایل کمی ناامید شوند. blogها، کتابها و trainingها از «نتایج شگفتانگیز» و «تیمهای hyper-productive» گفته بودند. این تیم پروژهٔ jukebox را بهتر از قبل میبیند اما قطعاً احساس hyper-productive ندارد و کسی از نتایج شگفتزده نشده است.
حس عمومی این است که پروژه از dysfunctional به functional تبدیل شده و این بسیار خوب است. آنها چیزی به دست آوردهاند که ما «نتایج بهتر از انجامندادن» مینامیم. اما آیا اجایل واقعاً فقط همین است؟
دیدگاه تکهتکه (Fractured Perspective)
تیمها از همان زمانی که نرمافزار ساختهاند با مشکل روبهرو بودهاند. در دههٔ ۱۹۶۰ حتی آشکارا دربارهٔ این ایده حرف زده میشد که توسعهٔ نرمافزار اساساً خراب است. اصطلاح software crisis در همان NATO Software Engineering Conference سال ۱۹۶۸ شکل گرفت که اصطلاح software engineering نیز مطرح شد. «بحران نرمافزار» وضعیت رایج توسعهٔ نرمافزار در شرکتهای دهههای ۱۹۷۰ و ۱۹۸۰ را توصیف میکرد؛ مشکلات جدی و اکنون آشنایی بسیار رایج بود و پروژهها را به شکست میکشاند.
پاورقی 3 — Peter Naur و Brian Randell (ویراستاران)، Software Engineering: Report on a Conference Sponsored by the NATO Science Committee، Garmisch, Germany، 7–11 October 1968، Brussels: Scientific Affairs Division, NATO، 1969، صفحه 231.
صفحهٔ PDF 46
با گذشت زمان صنعت ما یکی از منابع اصلی بحران نرمافزار را بهتر فهمید. نقطهٔ عطف مهمی زمانی بود که Winston Royce، مهندس Lockheed، در سال ۱۹۷۰ مقالهای منتشر کرد و مدلی بسیار محبوب اما بسیار ناکارآمد از توسعهٔ نرمافزار را توصیف کرد. تا اوایل دههٔ ۱۹۸۰ این روش بهطور گسترده waterfall نامیده میشد و ده تا بیست سال دیگر طول کشید تا بسیاری از تیمها از پذیرش کورکورانهٔ آن واقعاً عبور کنند. مثل Bruce، Dan و Joanna، تیمهای زیادی فهمیدند practiceهای اجایل میتواند به مشکلات waterfall کمک کند، اما بسیاری هم دیدند ماجرا به آن سادگی که انتظار داشتند نیست.
توسعهدهندگان هر روز برای ساخت کد از ابزارهای نرمافزاری استفاده میکنند و توسعهدهندهای که ابزارهای بیشتری را خوب بلد باشد در بازار کار جذابتر است. بنابراین وقتی بسیاری از توسعهدهندگان نخستین بار با اجایل روبهرو میشوند، فوراً آن را مجموعهای از ابزار، تکنیک و practice میبینند. تقریباً هر توسعهدهندهای که چند ماه با اجایل کار کرده باشد résumé خودش را با practiceهای جدید بهروز میکند. این برداشت اولیه خوب است چون practiceهای اجایل را برای کسانی که شاید در غیر این صورت علاقه نداشتند جذاب میکند.
اما دیدن فقط ابزارها، تکنیکها و practiceها نخستین قدم در اجایلشدن است و اثر جانبی مسئلهسازی دارد. از دید Dan نگاه کنید. او بهعنوان developer و architect عمدتاً روی چیزهایی تمرکز میکند که مستقیم بر development اثر دارند: تکنیکهای حذف یا پیشگیری bug، ابزارهای سریعتر و آسانتر برای build، و practiceهایی که design، review و ساخت code را بهتر میکنند. Joanna بهعنوان project manager عمیقاً به حجم effort لازم برای ساخت و کیفیت نتیجه اهمیت میدهد، پس روی ابزارهای schedule، estimate و effort تمرکز میکند. Tom بهعنوان business user بیشتر به value نرمافزار برای کسبوکار علاقه دارد و هر practiceای که به فهم دقیق نیاز کاربر کمک کند برایش جذاب است. Bruce بهعنوان team lead میخواهد مطمئن شود همه در یک جهت حرکت میکنند، خوب ارتباط میگیرند و از تجربهها یاد میگیرند؛ پس ابزارهای مرتبط با همین مسائل را میجوید.
practice نوشتن user story را در نظر بگیرید. user story راهی است برای بیان یک نیاز بسیار مشخص کاربر. معمولاً چند جمله است، اغلب روی index card، گاهی با ساختار سخت و گاهی انعطافپذیر. یکی از storyهای پروژهٔ jukebox چنین بود: «بهعنوان مشتری bar میخواهم بتوانم جدیدترین hit موسیقی را که همین امروز منتشر شده پخش کنم.»
صفحهٔ PDF 47
هر عضو تیم user story را کمی متفاوت میبیند:
- Joanna، مدیر پروژهای که میخواهد Scrum Master شود، user story را «کاری برای انجامدادن» میبیند؛ بستهای مرتب و آمادهٔ ساخت. او storyها را روی index card نوشته و به whiteboard چسبانده تا همه در مسیر بمانند.
- Dan، توسعهدهندهٔ ارشد و معمار، story را بخش کوچکی از functionality میبیند که ساده و قابلفهم نوشته شده است. آن را به taskها میشکند، برای هر task کارت میسازد، وقتی شروع کرد اسمش را روی کارت مینویسد و پس از اتمام به بخش «کاملشده» منتقل میکند.
- Tom، product owner، story را ارزشی میبیند که به شرکت تحویل میشود، چون پیوند روشنی میان چیزی که تیم میسازد و کاری که کاربر با آن انجام خواهد داد ایجاد میکند. storyها به او کمک میکنند با مشتریان حسابهای تحت مدیریت دربارهٔ نیازشان به jukebox صحبت کند و مطمئن شود هر story نمایندهٔ نیاز واقعی کاربر است.
- Bruce، team lead، story را هدف مشخصی میبیند که تیم میتواند حول آن سازماندهی شود. کمک میکند تصمیم بگیرند کدام story بعدی است و از پیشرفت برای حفظ انگیزه استفاده میکند.
افزودن user story به چنین تیمی میتواند نحوهٔ ساخت نرمافزار را بهتر کند، چون هر یک از این چهار نقش راهی میبیند که story شخصاً به خودش کمک میکند.
اما همین موضوع میتواند علیه تیم هم کار کند. در پروژههای گذشته Dan specification بسیار جزئی داشت و آزادی کمی برای تصمیمهای broad باقی میماند. حالا آزادی بیشتری داشت و این در اصل خوب بود، اما در پروژه مشکل ساخت. وقتی code مربوط به story «newest hit» را نوشت، تصور کرد یعنی featureای بسازد که مشتری bar بتواند هر hit را بلافاصله پس از upload به server پخش کند. اما هنگام demo به Tom در پایان iteration، بحث بزرگی شکل گرفت. Tom توضیح داد پخش آهنگهای جدیدتر باعث royalty fee بالاتر برای صاحب bar میشود. او با مشتریان جزئیاتی تنظیم کرده بود تا مشتریان بتوانند hitهای تازه را آنقدر بشنوند که راضی باشند، اما نه آنقدر زیاد که هزینهٔ سنگین ایجاد شود. Dan ناراحت شد چون باید بخش بزرگی از feature را کامل بازنویسی میکرد و Tom هم عصبانی بود چون release اول دیگر آن feature را نداشت.
اگر Dan میفهمید ارزش user story برای Tom در validate کردن نیاز کاربران است، شاید پیش از coding با Tom دربارهٔ رفتار دقیق نرمافزار صحبت میکرد. از طرف دیگر اگر Tom کمی بیشتر میفهمید Dan با اطلاعات محدود story چگونه میخواهد software را بسازد، شاید مطمئن میشد آن گفتوگو ابتدای iteration انجام شود. اما گفتوگو انجام نشد و پروژه به همان مشکلات پروژههای waterfall قبلی رسید: developerها assumption نادرست کردند، مستقیم وارد programming شدند و بعد مجبور شدند تغییرهای قابلاجتنابی بدهند که code را شکنندهتر میکرد.
صفحهٔ PDF 48
وقتی هر فرد فقط به نقش خودش و همان یک روش کمککردن user story به خودش فکر کند و از آن فراتر نرود تا ببیند کل تیم چگونه از story—یا هر ابزار، تکنیک و practice دیگر اجایل—استفاده میکند، دقیقاً مشکلی مثل Dan و Tom رخ میدهد. ما این را fractured perspective مینامیم، چون هرکس دید متفاوتی از practice اجایل دارد.
فعلاً تیم jukebox را با پروژهاش تنها میگذاریم؛ دیگر در این کتاب آنها را نمیبینیم. آیا بر مشکلات غلبه میکنند و نرمافزار را تحویل میدهند؟ هنگام خواندن ادامهٔ فصل ببینید آیا ایدههایی پیدا میکنید که بتواند به آنها کمک کند.
دیدگاه تکهتکه چگونه مشکل پروژه ایجاد میکند؟
وقتی هر فرد یک practice را فقط از دید خودش ببیند، همان مشکلات قدیمی برمیگردند. در سالهای software crisis، توسعهدهندگان بدون صرف زمان برای فهم نیاز کاربر مستقیماً وارد software میشدند. تقریباً همیشه وسط پروژه requirement جدیدی کشف میشد و مجبور بودند حجم زیادی code را بیرون بریزند و جایگزین کنند. بسیاری از practiceهای اجایل برای این طراحی شدهاند که از ابتدای پروژه فهم بهتری از نیاز customer بدهند و جلوی بخش زیادی از این ناکارآمدی را بگیرند. اما وقتی افراد ارتباط ندارند—مثلاً developer code را میسازد و بدون گفتوگوی واقعی دربارهٔ نیاز کاربر «از روی دیوار» برای product owner پرت میکند—مشکلهایی ایجاد میشود که باید اصلاح شوند و گاهی چند بار.
product ownerها در همین زمان خوشحالاند که اجایل راهی برای هدایت پروژه به سمت چیزهایی که کاربران نیاز دارند میدهد. برای product ownerی که پیشتر کنترل کمی داشت و با درماندگی میدید programming team نرمافزار سال گذشته را میسازد، چون آخرین گفتوگو با users همان موقع بوده، این یک آسودگی بزرگ است. بااینحال اگر story بنویسد و بعد ببیند تیم دقیقاً چیزی را که در ذهنش بوده نساخته، باز ناامید میشود. از دید تیم، product owner انتظار mind reading دارد؛ از دید product owner، تیم میخواهد او تماموقت حاضر باشد تا دائماً به هر پرسشی جواب دهد.
صفحهٔ PDF 49
همان fracture در نقشهای دیگر هم رخ میدهد. project manager و team lead خوشحالاند که developerها خودشان structure و goalهای concrete اضافه کردهاند. incremental improvement را میبینند اما تغییر بنیادین در شیوهٔ کار نه، چون وقتی اعضای تیم علیه هم کار کنند تغییر واقعی خنثی میشود. project managerی که user storyهای چسبیده به whiteboard را صرفاً جایگزین مستقیم Gantt chart در Microsoft Project میبیند و نگرش command-and-control خود را تغییر نداده، معمولاً در واکنش به change از تیم overtime میخواهد تا plan اولیه حفظ شود. team lead دفاعی میشود و برای محافظت از تیم در برابر کار اضافه، deadline راحتتر یا کاهش scope میخواهد. هر دو ممکن است نکتهٔ درستی داشته باشند، اما اگر از ابتدا دیدگاه همدیگر را میدیدند شاید بدون conflict به نتیجهٔ خوب میرسیدند.
یعنی وقتی تیم communication ندارد، افراد میتوانند ابزار تازهای مثل user story بپذیرند اما همان attitudeهای قدیمی را نگه دارند که friction و مشکلات تیم را ساخته بود. ابزار جدید بهتر است، پس پروژه روانتر میشود، اما برای افراد حس تغییر واقعی ایجاد نمیکند چون بسیاری از conflictهای قدیمی همچنان ظاهر میشوند. همینجا شروع میکنند به پرسیدن اینکه آیا اجایل تماماً همین است؟
شواهدی وجود دارد که تیمهای زیادی همین مشکل را تجربه کردهاند؛ پذیرش practiceهای منفرد به نتایج better-than-not-doing-it منجر شده است. VersionOne شرکتی است که ابزار نرمافزاری اجایل میسازد و به شکلهای مختلف به جامعهٔ اجایل کمک میکند. یکی از مهمترین کارهایش پیمایش سالانهٔ State of Agile Development است. نتایج ۲۰۱۳ نشان میداد تیمهای زیادی با پذیرش اجایل بهبود داشتهاند:
- 88٪ پاسخدهندگان گفتند سازمانشان توسعهٔ اجایل را اجرا میکند.
- 92٪ پاسخدهندگان نسبت به سال قبل در تمام حوزههای اندازهگیریشده بهبود گزارش کردند. مهمترین موارد: توانایی مدیریت اولویتهای درحالتغییر 92٪، افزایش productivity برابر 87٪، بهبود visibility پروژه 86٪، بهبود morale تیم 86٪ و افزایش quality نرمافزار 82٪.
اما در عین سریعترشدن پروژهها و بهترشدن واکنش به change، شکست پروژهٔ اجایل اغلب از تفاوتهای فرهنگی و فلسفی میان waterfall و agile میآید. پاسخدهندگان «کمبود تجربه در استفاده از روشهای اجایل»، «فلسفهٔ شرکت در تضاد با ارزشهای اجایل» و «فشار خارجی برای دنبالکردن practiceهای waterfall» را سه منبع بزرگ شکست اعلام کردند.
پاورقی 4 — متن اصلی برای آخرین گزارش VersionOne به stateofagile.versionone.com اشاره میکند؛ در خروجی نهایی این نشانی بهصورت متن غیرقابلکلیک نگهداری میشود.
صفحهٔ PDF 50
وقتی تیمهای تازهوارد به اجایل مشکل پیدا میکنند، اغلب دلیلش این است که واقعاً از روشهای قدیمی و waterfall-like جدا نشدهاند. همانطور که در تیم jukebox دیدیم، فقط افزودن practice کافی نیست تا تیم از مشکلاتی که conflict و change قابلاجتناب میسازند خارج شود. همهٔ اعضای jukebox ممکن است خودشان را «اجایلشده» بدانند، اما واقعیت این است که از بسیاری جهات هنوز یک تیم waterfall هستند که چند practice عالی اجایل گرفتهاند. Dave West از Forrester Research اصطلاحی برای این وضعیت ساخته است: Water-Scrum-Fall. به بیان دیگر، آنها فقط به کارآمدترین تیم waterfall ممکن تبدیل شدهاند.
پاورقی 5 — Dave West، “Water-Scrum-Fall Is the Reality of Agile for Most Organizations Today”، Forrester، 26 July 2011؛ پیوند منبع در نسخهٔ اصلی آمده است.
چرا دیدگاه تکهتکه فقط به نتیجهٔ «بهتر از انجامندادن» میرسد؟
آنچه افراد تحویل میدهند اغلب بر اساس چیزی که روی آن تمرکز کردهاند متفاوت خواهد بود. هرچه افراد بیشتر روی goalهای شخصی خود و کمتر روی goalهای تیم تمرکز کنند، احتمال اینکه خروجیشان واقعاً برای شرکت ارزش ایجاد کند کمتر میشود.
این یک paradox برای تیمی است که میخواهد اجایل شود. تیمهایی که فقط روی practiceهای منفرد تمرکز میکنند واقعاً بهبود میبینند، اما عمدتاً در حوزههایی که از قبل در آن خوب بودهاند. دلیلش این است که هر عضو فقط روی چیزی تمرکز میکند که از قبل میشناسد؛ برای گسترش به حوزهای که هنوز نمیشناسد باید اول درک خوبی از چیزی داشته باشد که نمیداند. درخواست از تیم برای بهبود چیزی که نمیشناسد توقع بزرگی است.
صفحهٔ PDF 51
شکل 2-2 — اعضای منفرد تیم معمولاً practiceهای اجایل را در حوزههایی اضافه میکنند که از قبل در آن قویاند. بنابراین تیم فقط در همان حوزهها بهتر میشود و به همین دلیل fractured perspective به نتایج «بهتر از انجامندادن» منجر میشود.
به همین دلیل تیمی که practiceهای اجایل را یکییکی میپذیرد اغلب فقط نتایج better-than-not-doing-it میگیرد. practiceهای بهتر را روی کارهایی گذاشتهاند که از قبل انجام میدادند، پس همان کارها را بهتر انجام میدهند. اما بخشهایی از پروژه که قبلاً به آنها توجه نمیکردند دستنخورده میماند، چون practiceهای مرتبط با آن حوزه برای هیچکس در پروژه جذاب نیست. بنابراین مشکلات آن بخشها بهتر نمیشود؛ و شاید دقیقاً همان بخشها باشند که مانع hyper-productive شدن تیم و رسیدن به نتایج شگفتانگیز میشوند.
یک تیم چگونه از این مشکل عبور میکند؟
نکات کلیدی
- ارتباط بهتر به تیم کمک میکند تغییر را بهتر مدیریت کند.
- برنامهریزی بهعنوان یک تیم مهمتر از مستندسازی افراطی plan و پیروی کورکورانه از آن است.
صفحهٔ PDF 52
تصویر منبع - صفحهٔ PDF 52
این صفحه پایان بخش «Fractured Perspective» را تثبیت میکند و ورودی بخش بعدی فصل را آماده میسازد؛ ادامهٔ فصل با توضیح اینکه Agile Manifesto چگونه به تیم کمک میکند هدف پشت هر practice را ببیند، در مقالهٔ بعدی میآید.