فصل ۳ — اصول اجایل
صفحهٔ PDF 71
«اگر از مردم میپرسیدم چه میخواهند، میگفتند اسبهای سریعتر.» — هنری فورد¹
هیچ دستورالعمل واحدی وجود ندارد که هر بار به نرمافزار کامل و بینقص منجر شود. تیمهای Agile این را میدانند. بهجای یک نسخهٔ جادویی، ایدهها و قواعد پایهای دارند که به آنها کمک میکند انتخابهای درست انجام دهند، از مشکلها دور بمانند یا وقتی مشکل ناگزیر رخ داد با آن برخورد کنند.
چهار ارزش Agile Manifesto را دیدهایم. در کنار آنها، ۱۲ اصل وجود دارد که هر فرد فعال در Agile هنگام کار در یک تیم پروژهٔ نرمافزاری باید به کار گیرد. زمانی که ۱۷ امضاکنندهٔ نخست Agile Manifesto در Snowbird ایالت Utah گرد هم آمدند، خیلی سریع بر چهار ارزش Manifesto توافق کردند، اما تدوین ۱۲ اصل همراه آن زمان بیشتری برد. Alistair Cockburn، یکی از امضاکنندگان، چنین به یاد میآورد:²
گروه ۱۷ نفره خیلی سریع دربارهٔ این انتخابهای ارزشی توافق کرد. تدوین سطح بعدی گزارهها بیش از چیزی بود که در زمان باقیماندهٔ جلسه بتوانیم نهایی کنیم. ارزشهای این بخش مجموعهٔ کاری فعلی ما را میسازند. این گزارهها باید با یادگیری ما از برداشت مردم از واژههایمان و با پیدا کردن واژههای دقیقتر تکامل پیدا کنند. تعجب میکنم اگر این نسخهٔ مشخص کمی بعد از انتشار کتاب قدیمی نشده باشد. برای تازهترین نسخه به Agile Alliance مراجعه کنید.
¹ دربارهٔ اینکه هنری فورد واقعاً این جمله را گفته باشد اختلاف نظر وجود دارد، اما تقریباً همه موافقاند که احتمالاً از آن خوشش میآمد.
² Alistair Cockburn, Agile Software Development: The Cooperative Game, 2nd Edition (Boston: Addison Wesley, 2006).
صفحهٔ PDF 72
آلیستر درست میگفت؛ زبان وبسایت اصول اکنون کمی با زبان کتاب او تفاوت دارد. عبارتها ممکن است همیشه در حال تکامل باشند، اما ایدهها و اصول ثابت ماندهاند.
در این فصل ۱۲ اصل نرمافزار Agile را یاد میگیرید: چه هستند، چرا به آنها نیاز دارید و چگونه بر پروژه اثر میگذارند. با دنبالکردن یک مثال عملی میبینید این اصول چگونه در پروژهای واقعی به کار میروند. برای آسانترشدن یادگیری، آنها را در چهار بخش گرد آوردهایم: تحویل (delivery)، ارتباط (communication)، اجرا (execution) و بهبود (improvement)؛ چون این موضوعها در سراسر اصول و Agile تکرار میشوند. بااینحال هر اصل مستقل از بقیه نیز معنا و جایگاه خودش را دارد.
۱۲ اصل نرمافزار Agile
- بالاترین اولویت ما رضایت مشتری از طریق تحویل زودهنگام و پیوستهٔ نرمافزار ارزشمند است.
- از تغییر نیازمندیها، حتی در اواخر توسعه، استقبال کنید. فرایندهای Agile از تغییر برای مزیت رقابتی مشتری بهره میگیرند.
- نرمافزار کارا را بهطور مکرر، از هر چند هفته تا هر چند ماه، و ترجیحاً در بازههای کوتاهتر تحویل دهید.
- کارآمدترین و مؤثرترین روش انتقال اطلاعات به تیم توسعه و درون آن، گفتوگوی رودررو است.
- افراد کسبوکار و توسعهدهندگان باید هر روز در سراسر پروژه با هم کار کنند.
- پروژهها را حول افراد باانگیزه بسازید؛ محیط و پشتیبانی لازم را فراهم کنید و به آنها اعتماد کنید که کار را انجام دهند.
- نرمافزار کارا معیار اصلی پیشرفت است.
- فرایندهای Agile توسعهٔ پایدار را ترویج میکنند. حامیان، توسعهدهندگان و کاربران باید بتوانند برای مدت نامحدود آهنگی ثابت را حفظ کنند.
- توجه پیوسته به برتری فنی و طراحی خوب، چابکی را افزایش میدهد.
- سادگی—هنر بیشینهکردن مقدار کاری که انجام نمیشود—ضروری است.
- بهترین معماریها، نیازمندیها و طراحیها از تیمهای خودسازمانده پدید میآیند.
- تیم در فواصل منظم دربارهٔ چگونگی مؤثرترشدن تأمل میکند و سپس رفتارش را متناسب با آن تنظیم و اصلاح میکند.³
³ منبع: agilemanifesto.org/principles.html، وضعیت ژوئن ۲۰۱۴.
مشتری همیشه حق دارد... واقعاً؟
به آغاز فصل برگردید و نقلقول را دوباره بخوانید. هنری فورد واقعاً چه میگوید؟ دربارهٔ دادن چیزی است که مردم واقعاً نیاز دارند، نه فقط چیزی که درخواست میکنند. مشتری نیازی دارد و اگر برای پاسخ به آن نرمافزار میسازید، باید آن نیاز را بفهمید، حتی اگر خود مشتری نتواند دقیق بیانش کند. چگونه با مشتریای کار میکنید که در شروع پروژه لزوماً نمیتواند بگوید به «خودرو» نیاز دارد نه فقط «اسب سریعتر»؟
انگیزهٔ ۱۲ اصل همین است: کمک به تیم برای ساخت نرمافزاری که کاربر واقعاً نیاز دارد. این اصول بر این ایده بنا شدهاند که پروژه را برای تحویل ارزش (value) میسازیم. اما «ارزش» واژهٔ سادهای نیست؛ افراد مختلف ارزش متفاوتی در نرمافزار میبینند و از آن چیزهای متفاوتی میخواهند.
ممکن است همین کتابی که در دست دارید مثال خوبی باشد. اگر آن را روی Ebook Reader دستی میخوانید، از نرمافزاری استفاده میکنید که برای نمایش کتاب الکترونیکی روی آن دستگاه نوشته شده است. ذینفعان (stakeholders)، یعنی افرادی که چیزی از پروژه میخواهند، متفاوتاند:
- بهعنوان خواننده میخواهید کتاب بهآسانی خوانده شود؛ ورقزدن جلو و عقب، Highlight، یادداشت، جستوجوی متن و نگهداشتن آخرین صفحهٔ خواندهشده برایتان مهم است.
- بهعنوان نویسنده برای ما مهم است کلمات درست نمایش داده شوند، Bulletها تورفتگی خوانا داشته باشند، جابهجایی میان متن و Footnote آسان باشد و تجربهٔ کلی خوبی داشته باشید تا از نوشته لذت ببرید و بیاموزید.
- ویرایشگر O’Reilly میخواهد توزیع کتاب برای شما آسان باشد و اگر آن را پسندیدید بتوانید آسان Review مثبت بدهید و کتابهای دیگری از O’Reilly بخرید.
- کتابفروش یا خردهفروش میخواهد Browse و خرید کتابهای دیگر و Download سریع آنها روی Reader بسیار آسان باشد.
میتوانید ذینفعان بیشتری و خواستههای بیشتری برای هرکدام تصور کنید. هر مورد نمایندهٔ ارزشی است که به یک Stakeholder تحویل داده میشود.
نخستین Ebook Readerهای بازار همهٔ این قابلیتها را نداشتند. زمان زیادی طول کشید تا نرمافزارشان به جایگاه امروز برسد و تقریباً قطعی است که با کشف راههای تازهٔ تحویل ارزش توسط تیمها، بهتر و بهتر خواهد شد.
صفحهٔ PDF 73
دیدن ارزشی که Ebook Reader امروز تحویل میدهد آسان است چون در نگاه به گذشته همهچیز روشنتر است؛ دیدن همان ارزش در آغاز پروژه بسیار سختتر است. یک آزمایش ذهنی انجام دهیم: اگر یک Reader فرضی با فرایند Waterfall توسعه داده میشد چه شکلی از آب درمیآمد؟
«همان کاری را بکن که میگویم، نه آنچه قبلاً گفتم»
فرض کنید عضو تیمی هستید که نخستین Ebook Reader دستی را میسازد. تیم Hardware نمونهٔ اولیهای با USB Port برای بارگذاری Ebook و صفحهکلید کوچکی برای تعامل تحویل داده است. وظیفهٔ تیم شما ساخت نرمافزاری است که Ebook را به کاربر نشان دهد.
متأسفانه شرکت شما سابقهٔ طولانی استفاده از فرایند Waterfall بسیار ناکارآمد «Big Requirements Up Front» دارد. پس نخستین کار Project Manager تشکیل جلسهای عظیم با هرکسی است که پیدا میکند. تیم هفتهها در اتاقی با مدیران ارشد شرکت، نمایندهٔ Publisherی که میخواهد Ebookهای قابل نمایش روی Reader منتشر کند، Salesperson ارشد یک Online Retailer که میخواهد آن کتابها را بفروشد و هر Stakeholder دیگری جلسه میگذارد.
پس از روزها جلسهٔ سنگین و بحث فشرده، Business Analystها Specification بزرگی از Requirements همهٔ Stakeholderها میسازند. کار زیادی بوده، اما حالا Specی دارید که همه عالی میدانند. قابلیتهای گستردهای برای User در نظر گرفته شده که آن را پیشرفتهترین نرمافزار Reader بازار میکند؛ قابلیت ثبت Marketing Statistics برای Publisherها، یک Internet Storefront کامل برای خرید آسان کتاب و حتی قابلیتی نوآورانه برای نویسندگان تا هنگام نوشتن، کتاب را Preview و Edit کنند و فرایند Publishing را سریعتر سازند. نرمافزاری واقعاً انقلابی خواهد بود. تیم Estimate میکند و Schedule پانزدهماهه به دست میآید. طولانی است، اما همه هیجانزدهاند و مطمئنید تحویل میدهید.
یک سال و نیم جلو برویم. تیم باورنکردنی کار کرده: شبهای دیرهنگام، آخرهفتهها و فشار روی زندگی خانوادگی. پروژه با تلاش عظیم تمام شده و تقریباً دقیقاً مطابق Plan، حتی تا روز تعیینشده، تحویل دادهاید. برای آزمایش ذهنی فرض میکنیم این اتفاق بسیار بعید واقعاً افتاده است. همهٔ Requirementهای Spec پیادهسازی، Test و کامل بودنشان Verify شدهاند. تیم افتخار میکند و همهٔ Stakeholderهایی که محصول را دیدهاند تأیید میکنند دقیقاً همان چیزی را گرفتهاند که خواسته بودند.
محصول وارد بازار میشود... و شکست میخورد. هیچکس Reader را نمیخرد و هیچ Stakeholderی خوشحال نیست. چه شد؟
صفحهٔ PDF 74
مشکل این است که نرمافزاری که یک سال و نیم پیش همه لازم داشتند همان نرمافزاری نیست که امروز نیاز دارند. در این فاصله صنعت روی Format استاندارد جدیدی برای Ebook توافق کرده و چون آن Format در Spec نبود محصول پشتیبانیاش نمیکند. Retailerهای اینترنتی حاضر نیستند Format غیراستاندارد Reader شما را منتشر کنند. Internet Storefront عالی شما هم دیگر در برابر Storefrontهای پیشرفتهتر امروزی Retailerها جذاب نیست. و Preview ویژهٔ نویسندهها بهاندازهٔ قابلیت رقیبی که اجازه میدهد نویسنده MS Word Document را مستقیم Email کند و روی Reader ببیند مفید نیست.
چه آشفتگیای! Specification اولیه برای مشتریان داخل و خارج شرکت ارزش زیادی داشت، اما نرمافزاری که یک سال و نیم قبل توافق کردید بسازید امروز ارزش بسیار کمتری دارد. بعضی تغییرها زود قابل کشف بودند، اما بسیاری در ابتدا روشن نمیشدند. تیم باید در نقاط زیادی از پروژه خیلی سریع مسیر را عوض میکرد. Waterfall با Big Requirements Up Front انعطاف زیادی برای واکنش به این تغییرها نمیدهد.
پس چگونه میتوانیم ذینفعان و مشتریان را بهتر راضی کنیم و همچنان پروژهای را اداره کنیم که نرمافزار کارا تحویل دهد؟
تحویل پروژه
تیمهای Agile میدانند مهمترین کارشان تحویل نرمافزار کارا به مشتری است. از فصل ۲ میدانید چگونه: کار تیمی، Collaboration با مشتری و Responding to Change. اما این در کار روزمره دقیقاً چه شکلی دارد؟
با اولویتدادن به تحویل مکرر ارزش، نگاهکردن به هر تغییر بهعنوان اتفاقی مفید برای پروژه و تحویل مکرر نرمافزار، تیم و مشتری میتوانند در طول راه با هم تنظیمات لازم را انجام دهند. نرمافزار نهایی شاید همان چیزی نباشد که در شروع قصد ساختنش را داشتند و این خوب است، چون چیزی ساخته میشود که مشتری بیش از همه نیاز دارد.
اصل ۱: بالاترین اولویت ما رضایت مشتری از طریق تحویل زودهنگام و پیوستهٔ نرمافزار ارزشمند است
این اصل سه ایدهٔ مستقل و مهم دارد: Release زودهنگام نرمافزار، تحویل پیوستهٔ ارزش و رضایت مشتری. برای فهم هستهٔ اصل باید دید این سه چگونه با هم کار میکنند.
تیم پروژه در جهان واقعی کار میکند و در جهان واقعی هیچچیز همیشه کامل پیش نمیرود. حتی تیمی که Requirements را عالی جمعآوری و مستند میکند چیزهایی را جا میاندازد، چون ثبت کامل و بینقص Requirements هر System غیرممکن است. این به معنی تلاشنکردن نیست؛ Methodologyهای Agile Practiceهای بسیار خوبی برای ارتباط و ثبت Requirements دارند. واقعیت این است که تا وقتی مشتری نرمافزار کارا را در دست نگیرد، تصور دقیق رفتار آن برایش دشوار است.
اگر مشتری فقط پس از دیدن Working Software میتواند Feedback واقعی و آگاهانه بدهد، بهترین راه گرفتن آن Feedback Early Delivery است: نخستین نسخهٔ کارا را هرچه زودتر تحویل دهید. حتی یک Feature کارا که مشتری بتواند استفاده کند یک برد است. تیم Feedback آگاهانه میگیرد و پروژه را در جهت درست میبرد؛ مشتری هم امروز کاری را انجام میدهد که دیروز نمیتوانست. چون نرمافزار کار میکند و مشتری برای نیاز واقعی از آن استفاده میکند، ارزش واقعی تحویل شده است. شاید ارزش کم باشد، اما بسیار بهتر از صفر است، مخصوصاً در مقایسه با Userی که هر روز ناامیدتر میشود و مدت طولانی برای دیدن محصول تیم انتظار میکشد.
عیب تحویل زودهنگام این است که نخستین نرمافزارِ رسیده به مشتری کامل نیست. بعضی Userها و Stakeholderها با این مشکل دارند. برخی به دیدن Software زودهنگام عادت دارند و برخی نه. خیلیها وقتی نرمافزار بینقص نیست سخت واکنش نشان میدهند. در بسیاری شرکتها، بهخصوص سازمانهای بزرگی که سالها با Software Team کار کردهاند، تیم حتی باید شرایطی را که تحت آن نسخهٔ ناقص را در اختیار Stakeholder میگذارد مذاکره کند. اگر Partnership خوبی وجود نداشته باشد، Stakeholder ممکن است نسخهٔ ناقص را شدیداً قضاوت کند یا با ندیدن Feature مورد انتظار وحشت کند.
ارزشهای هستهای Agile پاسخی دارند: Customer Collaboration over Contract Negotiation. تیمی که به Specification ثابت و موانع بوروکراتیک سخت برای Change بسته شده، نمیتواند اجازه دهد Software در طول زمان تکامل پیدا کند؛ برای هر تغییر باید Change Management Process و Contract Negotiation تازهای شروع کند. تیمی که واقعاً با Customer همکاری میکند میتواند تغییرهای لازم را در طول مسیر انجام دهد. این معنای Continuous Delivery است.
به همین دلیل Methodologyهای Agile معمولاً Iterative هستند. تیم برای هر Iteration، Featureها و Requirementهایی را انتخاب میکند که بیشترین Value را تحویل میدهند. راه فهمیدن ارزش هم Collaboration با Customer و واردکردن Feedback Iteration قبلی است. این کار در کوتاهمدت با نمایش زودهنگام Value و در بلندمدت با تحویل محصول نهاییای که بیشترین Value ممکن را دارد Customer را راضی میکند.
اصل ۲: از تغییر نیازمندیها، حتی در اواخر توسعه، استقبال کنید؛ فرایندهای Agile از تغییر برای مزیت رقابتی مشتری بهره میگیرند
بسیاری از افراد موفق Agile هنگام نخستین مواجهه با این اصل مشکل دارند. در حرفِ انتزاعی، «استقبال از تغییر» آسان است؛ اما در گرمای پروژه وقتی Change به کار زیادی نیاز دارد، احساسات وارد ماجرا میشوند—بهخصوص برای Developerی که میداند رئیسش او را همچنان به Deadline قبلی پاسخگو خواهد کرد. عبور از این وضعیت در فرهنگی که افراد بابت تأخیر سرزنش میشوند دشوار است، اما ارزشمند هم هست، چون استقبال از Changing Requirements یکی از قدرتمندترین ابزارهای Agile است.
چرا Change بار عاطفی دارد؟ آخرین باری را به یاد آورید که فهمیدید باید چیزی را که میسازید تغییر دهید. تا آن لحظه فکر میکردید پروژه خوب پیش میرود. تصمیمهای زیادی گرفتهاید: ساختار کار، چیزی که میسازید و چیزی که به Customer قول دادهاید. حالا کسی از بیرون پروژه میگوید بخشی از Planning و Work شما اشتباه بوده—یعنی شما اشتباه بودهاید.
پذیرفتن اینکه کسی بگوید اشتباه کردهاید سخت است، بهویژه وقتی برای همان فرد کار کردهاید. بسیاری از Software Engineerها با غرور نسبت به کیفیت کار انگیزه میگیرند؛ میخواهیم Productی تحویل دهیم که بتوانیم پشت آن بایستیم و نیاز User را برآورده کند. Change این احساس را تهدید میکند چون مسیر و Assumptionهای شما را زیر سؤال میبرد.
خیلی وقتها همان کسی که شما را در یک مسیر گذاشته، بعداً میگوید مسیر را عوض کنید. اگر گفت چیزی بسازید و شما نصفش را ساختید، شنیدن «حالا که فکر میکنم، میشود یک چیز کاملاً متفاوت بسازیم؟» بسیار آزاردهنده است؛ حس میشود تلاش شما نادیده گرفته شده. حالا باید چیزی را که تمامشده میدانستید دوباره تغییر دهید. دفاعیشدن طبیعی است، و بدتر وقتی شما را بابت نخواندن ذهن Customer و خرابشدن Deadline مقصر بدانند.
تقریباً هر Developer حرفهای دستکم یک بار چنین وضعی دیده است. پس چطور میتوان از Changing Requirements استقبال کرد؟ قدم اول این است که موضوع را از دید Customer ببینید. آیا او عمداً شما را در مسیر اشتباه فرستاد؟ وقتی فهمید ماهها قبل دستور اشتباه داده و حالا ماهها کار تلف شده چه احساسی داشته؟ آمدن نزد شما و درخواست Change برای او اعتراف به Mistakeی است که کار زیادی برای شما ایجاد میکند؛ آسان نیست. عجیب نیست مشتریها گاهی دیر Change را مطرح میکنند؛ خجالتآور است و میدانند خبر بد میآورند. Deadline شما میشکند، اما Deadline خود او هم همینطور. اگر شرکت برای پاسخ به نیاز او پول خرج میکند و آن نیاز برآورده نمیشود، پروژه Value تحویل نمیدهد.
صفحهٔ PDF 77
به بیان دیگر از دو نفر خواسته شده غیرممکن را انجام دهند: از شما خواستهاند ذهن Customer را بخوانید و از او خواستهاند آینده را پیشبینی کند. وقتی اینطور نگاه کنید استقبال از Change بسیار آسانتر میشود. اگر هم میخواهید در برابر تغییر سرسختانه مقاومت کنید و به Plan آغاز پروژه بچسبید، راهش ساده است: فقط اعضایی استخدام کنید که ذهنخوان و غیبگو باشند!
استقبال از تغییر یعنی:
- هنگام Change هیچکس «به دردسر» نمیافتد. ما و مدیرانمان میپذیریم انسان و خطاپذیریم و برای شرکت بهتر است اجازه دهد اشتباه کنیم و مرتب اصلاحشان کنیم، نه اینکه از ما انتظار داشته باشد بار اول همهچیز کامل باشد.
- همه در یک قایقیم. اعضای تیم و Customerهایی که با آنها Collaboration میکنید با هم مالک Requirements و تغییرهای آن هستند. اگر Requirement اشتباه است، سهم مسئولیت شما هم بهاندازهٔ Customer است و Blame فایدهای ندارد.
- Change را تا وقتی دیر شود نگه نمیداریم. بله، اعتراف به Mistake خجالتآور است، اما چون این را میپذیریم تلاش میکنیم هرچه زودتر اصلاح کنیم تا خسارت محدود بماند.
- Change را «اشتباه» نمیدانیم. با اطلاعات آن زمان بهترین تصمیم ممکن را گرفتیم و فقط تصمیمهای مسیر بود که دید لازم برای فهم تغییر امروز را ایجاد کرد.
- از Change یاد میگیریم. این مؤثرترین راه رشد تیم و بهترشدن در ساخت نرمافزار با هم است.
اصل ۳: نرمافزار کارا را مکرراً، از چند هفته تا چند ماه و ترجیحاً در بازهٔ کوتاهتر تحویل دهید
ممکن است استقبال از Changing Requirements جذاب و کمککننده به نظر برسد و همزمان ترسناک باشد. این واکنش رایج است. بسیاری از افراد Software Team، بهخصوص Project Managerهای سنتی، در اولین مواجهه با استقبال از Change راحت نیستند. آنها هر روز با Change سروکار دارند، اما نگرش Agile نسبت به Change با چیزی که عادت کردهاند فرق دارد. افراد Agile نگرش سنتی را Command-and-Control مینامند.
اصطلاح Command-and-Control از ارتش آمده است. در کتاب Beautiful Teams در سال ۲۰۱۰ با Neil Siegel، Chief Engineer شرکت Northrop Grumman، مصاحبه کردیم و او تعریف نظامی را توضیح داد:
Andrew: با سیستمهای نظامی آشنا نیستم؛ Command-and-Control System چیست؟
>
Neil: یک Information System برای فرماندهان نظامی است. اجازه میدهد با هم ارتباط داشته باشند و Situational Awareness را حفظ کنند: هرکس کجاست و وضعیتش چیست. فرمانده از این طریق میفهمد چه خبر است. زمانی میدان نبرد کوچک بود و فرمانده میتوانست مثل Napoleon روی تپه بایستد و با دوربین ببیند چه میگذرد. حدود سال ۱۹۰۰ میدانها آنقدر بزرگ شدند که دیگر ممکن نبود و لازم شد با Technology کل میدان را «دید». سیستمهایی که این کار را میکنند Command-and-Control Systems نام دارند.
مدیریت پروژهٔ Command-and-Control هم مشابه است:
- Command به نحوهٔ تخصیص کار توسط Project Manager اشاره دارد. شاید Team مستقیماً به او Report ندهد، اما Assignmentها تحت کنترل اوست؛ Work را خرد، Schedule را میسازد و Activityها را به Resourceها واگذار میکند.
- Control شیوهٔ مدیریت Change است. در هر پروژه تغییر رخ میدهد: Work طولانیتر میشود، افراد بیمار میشوند یا پروژه را ترک میکنند، Hardware در دسترس نیست یا خراب میشود و اتفاقهای پیشبینینشدهٔ دیگر رخ میدهد. Project Manager دائم Changeها را Monitor میکند و با ارزیابی هرکدام، Update Plan و Schedule و Documentation، دادن Assignmentهای تازه و مدیریت انتظار Stakeholderها تلاش میکند کسی غافلگیر نشود.
Project Manager سنتی از استقبال از Change ناراحت میشود چون میداند همین مشکلات در Agile هم رخ میدهند و Team باید پاسخ دهد. پذیرفتن و حتی استقبال از تغییر در نگاه اول نسخهای تضمینی برای Chaos به نظر میرسد. اگر Agile Team از Command-and-Control استفاده نکند، چگونه هم با همهٔ Changeها همراه میشود و هم مسائل روزمرهٔ معمول را مدیریت میکند؟
شکل ۳-۱. تیم با Iteration نرمافزار کارا را مرتب تحویل میدهد و در هر Release قابلیتهای تازه اضافه میکند.
صفحهٔ PDF 80
تصویر منبع - صفحهٔ PDF 80
کلید استقبال از Change بدون Chaos، تحویل مکرر نرمافزار کارا است. Team با Iteration پروژه را به Deadlineهای منظم تقسیم میکند و در هر Iteration Working Software تحویل میدهد. پایان هر Iteration یک Demo برای Customer و یک Retrospective برای مرور درسهاست؛ سپس Planning Session شروع میشود تا محتوای Iteration بعد مشخص شود. Schedule قابل پیشبینی و Checkpointهای ثابت، Change را زود آشکار میکنند و محیطی بدون Blame میسازند تا تیم دربارهٔ هر Change و راه واردکردن آن به پروژه گفتوگو کند.
اینجا Agile برای Project Manager سنتی جذاب میشود. مدیر Command-and-Control میخواهد Deadline را کنترل کند و Iterationهای Timeboxed این کنترل را میدهند. یکی از سختترین مشکلات مدیریت سنتی Changeهای بسیار دیرهنگام است. Reviewهای روزانه و Retrospectiveها کل Team را به چشم و گوش مدیر تبدیل میکنند تا Change زودتر دیده شود، پیش از آنکه مشکل جدی بسازد.
نقش Project Manager از Command-and-Control—دادن Battle Plan روزانه و تنظیم دائم افراد—به همکاری با Team تغییر میکند تا همه دائم Big Picture را ببینند و به هدف مشترک بروند. Iteration کوتاهی که Working Software تحویل میدهد به هر نفر Goal ملموس، دید بهتر از خروجی دیگران و حس مسئولیت نه فقط نسبت به چیزی که خودش میسازد، بلکه نسبت به خروجی کل Team در پایان Iteration میدهد.
تحویل بهتر پروژهٔ Ebook Reader
مشکلات مثال Reader را به یاد آورید: محصول شکست خورد چون Featureهای مهم رقبا را نداشت، از جمله پشتیبانی Format استاندارد صنعت و فرستادن Document به Device، و Featureهایی داشت که دیگر بازار نمیخواست، مثل Internet Storefront.
پروژه را دوباره اجرا کنیم، این بار با Sprintهای یکماهه که Project Manager همراه Stakeholder و Team تنظیم میکند:
- پس از Sprint سوم، Developer گزارش میکند استاندارد صنعت برای Format جدید Ebook تصویب شده است. Team تصمیم میگیرد Library پشتیبان آن را در Sprint چهارم و UI آن را در Iteration پنجم پیاده کند.
- پس از ۱۰ ماه Development، Build کارایی تولید میکنند که روی Prototype نصب میشود و به Early Beta User داده میشود. Project Manager از آنها میشنود که میخواهند MS Word Document و Newspaper Article را روی Reader ببرند. بخشی از Sprint بعد به Email Integration اختصاص مییابد تا User مقاله را برای Device خودش Mail کند.
- یک سال بعد Stakeholderها میگویند Internet Storefront دیگر لازم نیست، چون Retailerها همگی Format استاندارد Ebook را پذیرفتهاند. خوشبختانه این Feature همیشه اولویت پایین Backlog بوده و Sprintها صرف Featureهای مهمتر شدهاند، پس کار کمی روی آن هدر رفته است.
چون Team پس از هر Sprint Working Software تحویل داده، حذف Featureها از Backlog باعث شده بتوانند زودتر تحویل دهند. Publishing Partner نیز آماده است چون Senior Managerهایش نسخههای زودهنگام Software و Prototype Hardware را برای آزمایش گرفتهاند. همین درگیر نگهداشتن آنها انگیزه داد کتابها را بهمحض آمادهشدن نسخهٔ اول Product آماده کنند.
شکل ۳-۲. در آغاز هر Iteration، تیم Featureهایی از Backlog برای ساخت انتخاب میکند.
با Continuous Release، استقبال از Change و تحویل Working Software بعد از هر Iteration، پروژهٔ Ebook Reader توانست Product موفق را بسیار زودتر تحویل دهد. برخلاف Waterfall ناکارآمد که پس از تأیید Requirements تیم را از Customer جدا میکرد، Agile Team با Customer درگیر ماند و توانست به Change پاسخ دهد و Product بهتری بسازد.
اما همهچیز عالی نیست. Team Iteration دارد، ولی زیر بار Documentation دفن شده است. هر بار Change خوبی پیدا میکنند، نصف Team به Specification برمیگردد تا آن را Update کند و Planها هممسیر بمانند. تقریباً همانقدر که برای Code وقت میگذارند صرف بهروزرسانی Documentation میشود.
تیم دربارهٔ «سطح درست جزئیات» Documentation بحث کرده است. هر بار چیزی را حذف میکنند، کسی نکتهٔ معتبری میگوید: اگر Feature، Requirement، Design یا Test Case خاص نوشته نشود ممکن است سوءتفاهم شود و اگر اشتباه پیاده شود، تیم سرزنش میشود. پس انگار همهٔ Documentation لازم است. آیا راهی هست بار را کم کنند بیآنکه به Project آسیب بزنند؟ اصلاً چیزی به نام «سطح درست Documentation» وجود دارد؟
نکات کلیدی بخش تحویل
- ۱۲ اصل توسعهٔ Agile همراه Agile Manifesto به Practitionerها جهت و بینش برای Practiceها و Methodologyها میدهند.
- Agile Team با گرفتن Feedback زودهنگام و تحویل پیوسته Software، Feedback را تازه نگه میدارد و Customer را راضی میکند (اصل ۱).
- Agile Team Change را بهعنوان رخدادی مثبت و سالم برای Project میپذیرد (اصل ۲).
- با Iterationهای Timeboxed و تحویل مکرر Working Software، پروژه دائماً تنظیم میشود تا بیشترین Value را به Customer بدهد (اصل ۳).
ارتباط و کارکردن با یکدیگر
Software Teamها از آغاز صنعت با سؤال «چقدر Documentation؟» درگیر بودهاند. همانطور که سالها دنبال Silver Bullet Methodology برای حل مشکل Process، Programming و Delivery بودهاند، بهدنبال Silver Bullet Documentation System یا Template هم بودهاند که جادویی همهٔ اطلاعات لازم برای ساخت Software امروز و نگهداری فردا را ثبت کند.
تفکر سنتی چنین است: به Documentation Management System نیاز داریم تا همه اطلاعاتشان را وارد و به اطلاعات دیگران وصل کنند. اگر Traceability کامل داشته باشیم و همهٔ روابط بین اطلاعات را برقرار کنیم، تقریباً دید کاملی از چیزی که میسازیم، نحوهٔ Test، Deployment و Maintenance خواهیم داشت. Developer هر Design Element را به Requirement و Tester هر Test Case را به Design، Requirement و Scope ردیابی میکند. اگر بخشی از Design تغییر کند دقیقاً میبینیم چه Code، Requirement، Scope و Test Caseهایی تحتتأثیرند و Analysis وقتگیر کمتر میشود.
Software Engineerها این را Impact Analysis مینامند و گاهی Traceability Matrixهای گستردهای میسازند که تمام عناصر Scope، Requirements، Design و Tests را به هم نگاشت میکنند. Project Manager هم Code، Bug Report، Design Element و Requirement را به Source مربوط ردیابی میکند.
پس پاسخ Agile به «چقدر Documentation؟» این است: دقیقاً به اندازهای که برای ساخت Project لازم است. مقدار دقیق به Team، کیفیت Communication و Problem وابسته است. Meeting Noteهای بسیار مفصل، Cross-reference Document برای همهٔ Data Source/Storeها، Matrix پیچیدهٔ Role/Responsibility/Rule—برای همه میتوان توجیه ساخت. اما اگر واقعاً به Team در ساخت Software کمک نمیکند و دلیل دیگری مثل Regulator، Investor، Senior Manager یا Stakeholder ندارد، Agile Team آن را نمیسازد. اگر تیمی واقعاً با Functional Requirements Document بهتر کار میکند، میتواند آن را بسازد و همچنان Agile باشد. آنچه برای Team بهترین است تعیینکننده است؛ این یکی از آزادیهای Agile است.
Documentation اضافی، Traceability Matrix و Impact Analysis عمدتاً برای تحلیل کامل اثر Change ساخته میشوند. Agile رویکرد متفاوت و اغلب کارآمدتری برای مدیریت Change دارد، اما باید پذیرفت هدف روش سنتی نیز بهتر برخوردکردن با Change است.
طنز ماجرا این است که Comprehensive Documentation اغلب مانع مدیریت Change میشود. رؤیای Documentation و Traceability کامل این است که System بتواند اثر هر Change را خودکار تولید کند و دقیقاً نشان دهد چه چیزهایی باید اصلاح شوند. در واقعیت، بیشتر Teamها زمان عظیمی در آغاز Project برای پیشبینی آینده و نوشتن کامل آن صرف میکنند. در طول Project باید Documentها را نگهداری و Developmentهای تازه را ثبت کنند. وقتی فهم اولیهٔ Product تغییر کند باید همهٔ Documentهای مرتبط را هم تغییر دهند. نتیجه بهمرور تودهای از Documentهای قدیمی و تلاش زیاد برای ساخت و نگهداری آنهاست.
چون این Documentation بینقص نیست، خودش Change غیرضروری و Waste ایجاد میکند. هر Document از Perspective یک Role نوشته میشود: Business Analyst از یک دید Requirement مینویسد، Architect از دید دیگر Design میسازد و QA Engineer از دید سوم Test Plan مینویسد. وقتی همه را با Traceability Matrix به هم میبندند، همان Inconsistencyهایی آشکار میشود که از این Fractured Perspectiveها انتظار دارید. ساخت Documentation به هدفی مستقل تبدیل میشود و Up-front Effort افزایش مییابد. وقتی Change رخ میدهد، تمام تلاش برای آشتیدادن Perspectiveها در یک مجموعهٔ جامع باید دوباره انجام شود. Team بهجای Code، Test و Deploy Change، Documentation را بازنویسی، Matrix را بازسازی و Conflict حل میکند.
باید راه کارآمدتری برای ساخت Software وجود داشته باشد.
اصل ۴: کارآمدترین و مؤثرترین روش انتقال اطلاعات به تیم توسعه و درون آن، گفتوگوی رودررو است
Agile Practitioner میداند Documentation فقط یک شکل از Communication است.⁴ وقتی Documentی مینویسم و به شما میدهم، هدف «نوشتن Documentation» نیست؛ هدف این است که ایدههای ذهن من تا حد ممکن با ایدههای ذهن شما یکی شوند. Documentation در بسیاری موارد ابزار خوبی است، اما تنها ابزار Communication ما نیست.
⁴ برای انصاف کامل، Project Managerهای سنتی هم میدانند Documentation فقط یک شکل Communication است. آنها تفاوت Formal/Informal و Written/Verbal Communication و نشانههای Nonverbal را میآموزند و میدانند Face-to-face مؤثرترین روش انتقال ایده است؛ این موضوع حتی در آزمون PMP هم مطرح میشود.
شکل ۳-۳. وقتی اعضای تیم ارتباط ندارند ممکن است در کلیات همنظر باشند، اما در عمل به سمت هدفهای متفاوت بروند. Comprehensive Documentation با ایجاد زمینهٔ Ambiguity میتواند وضعیت را بدتر کند.
تقریباً همیشه گفتوگوی رودررو برای اشتراک ایده در Software Team از Documentation بهتر است. همه میدانیم صحبت مستقیم دربارهٔ Problem مؤثرترین راه فهم ایدهٔ تازه است. احتمال بهخاطر سپردن چیزی که در Conversation بیان شده بیش از متنی است که روی صفحه یا Microsoft Word Document خواندهایم. به همین دلیل Practiceهای Communication در Agile بر ارتباط انسانها با هم تمرکز دارند و Documentation را برای جاهایی نگه میدارند که اطلاعات پیچیده باید بعداً با جزئیات دقیق بازیابی شود.
خوشبختانه گذار از Comprehensive Documentation به Face-to-face Communication برای تیمها سخت نیست، چون بیشترشان عملاً هرگز به «ایدهآل» Documentation و Traceability کامل نمیرسند. Software Engineerها بسیار عملگرا هستند؛ وقتی حجم کار لازم برای آن Documentation را میبینند در نهایت همان گفتوگوهای رودررو را انجام میدهند، چون تنها راه مؤثر ساخت Software است. با پذیرش اینکه Comprehensive Documentation اغلب نامتناسب است، دیگر بابت نرسیدن به هدف ناممکن «Documentation کامل و بینقص» احساس گناه نمیکنند؛ چون حتی اگر میساختند، الزاماً برای Projectشان مفید نبود.
هدف مؤثر Communication این است که همه به شیوهای مشابه فکر کنند تا هر فرد هنگام رسیدن Decision بتواند درست واکنش نشان دهد. وقتی گروهی جهان را به شکل نزدیک به هم میبینند و دربارهٔ ایدههای مثبت و منفی صادقانه صحبت میکنند، Shared Perspective میسازند. آنگاه هنگام Change نیاز کمتری به توضیحهای طولانی دارند.
هدف نهایی Team Communication ساخت حس Community و مقدار زیادی دانش ضمنی (implicit knowledge) است؛ توضیح دوباره و دوبارهٔ یک چیز کارآمد نیست. بدون Community، Roleهای مختلف باید انرژی بیشتری برای هماهنگکردن Perspectiveها مصرف کنند. هرچه Shared Perspective قویتر شود، افراد مستقل هنگام مواجهه با یک سؤال بیشتر به جواب مشابه میرسند. این پایهٔ باثباتی برای Change میسازد؛ Conflict سریعتر کنار میرود، Team روی Code کار میکند و در مدیریت Documentation منحرف نمیشود.
اصل ۵: افراد کسبوکار و توسعهدهندگان باید هر روز در سراسر پروژه با هم کار کنند
Agile Team گاهی فراموش میکند Businesspeople شغل روزانهٔ دیگری هم دارند. این باعث شکاف طبیعی میان Software Team و افرادی میشود که نرمافزار برایشان ساخته میشود.
برای ساخت خوب Software، Team به Face-to-face Discussion زیاد با Businesspeople نیاز دارد تا دانش آنها دربارهٔ Problemهای شرکت را که قرار است با Software حل شوند دریافت کند. آنها این دانش را با حل همان Problemها بدون Software به دست آوردهاند. بنابراین Software Project برای بسیاری فقط بخش کوچکی از Job است. در دنیای ایدهآلشان، یک یا دو Meeting برگزار میکنند، میگویند Software چه باید بکند و کمی بعد نسخهٔ کامل و بینقص را میگیرند.
Team برعکس، بیشترین Contact ممکن را میخواهد. Programmer باید Business Problem را یاد بگیرد؛ با صحبتکردن، مشاهدهٔ کار و دیدن خروجی افراد کسبوکار. Programmer دوست دارد توجه تماموقت آنها را داشته باشد چون هر تأخیر در پاسخ سرعت Project را کم میکند، اما Businessperson نمیخواهد تمام روز با Software Team باشد. چه کسی برنده میشود؟
Agile راهی میدهد که هر دو برنده شوند. نقطهٔ شروع این است که Team نرمافزار ارزشمند به شرکت تحویل میدهد و Finished Software برای شرکت پول میارزد. اگر Value بیش از Cost ساخت باشد، سرمایهگذاری در Development توجیه دارد. Project خوب باید آنقدر ارزشمند باشد که Businesspeople ببینند مشارکت مداومشان در طول Project ارزش Effort را دارد.
شکل ۳-۴. برخی Featureهای Backlog برای شرکت ارزشمندتر از بقیهاند. Team هنگام انتخاب اقلام هر Iteration باید Value هر Feature را در برابر Cost ساختش متعادل کند.
در بلندمدت کار روزانهٔ Businesspeople و Developerها با هم کارآمدتر است؛ Alternative این است که Businesspeople تا اواخر Project صبر کنند، Work را ببینند و Feedback بدهند، زمانی که Change بسیار گرانتر است. کشف زودتر Change در مجموع وقت کمتری از همه میگیرد. Daily Collaboration عملاً در کل Project زمان کمتری از Businessperson مصرف میکند.
به همین دلیل Teamهایی که Working Software مکرر تحویل میدهند، باارزشترین Featureها را اول میسازند تا Business زودتر Value بگیرد. این بخشی از معامله است. همچنین Agile Team افراد Business را عضو برابر Team میبیند، نه Customerی که باید با او Contract Negotiation کرد. Agile با Customer—اغلب Product Owner—بهعنوان فردی با حق نظر برابر در نحوهٔ ادارهٔ Project همکاری میکند. این همان Customer Collaboration over Contract Negotiation است.
Product Owner خوب میتواند زمان Businesspeople را کم کند. هنوز Daily Contact لازم است، ولی Product Owner روی فهم Value Software و Business Problem تمرکز میکند و Face-to-face Time با Businesspeople بیشتر برای Validate کردن اطلاعاتی استفاده میشود که Team از Product Owner آموخته است.
اصل ۶: پروژهها را حول افراد باانگیزه بسازید؛ محیط و پشتیبانی لازم را بدهید و اعتماد کنید کار را انجام دهند
Project زمانی بهترین عملکرد را دارد که همه در Company بفهمند Team نرمافزار ارزشمند میسازد و همهٔ اعضا، از جمله Product Owner، بدانند چه چیزی آن Software را برای Company ارزشمند میکند.
برعکس، در محیطی که Value دیده نمیشود یا افراد برای ساخت خوب Software پاداش نمیگیرند Project میشکند. عجیب نیست که بعضی شرکتها Performance Review و Compensation Systemهایی دارند که عملاً افراد را از رفتار Agile بازمیدارند. نمونهٔ Incentiveهای ضد Agile:
- دادن Performance Review بد به Programmer چون Code Review مرتب Bug پیدا میکند و پاداشدادن به Reviewهای «تمیز». نتیجه این میشود که Programmerها Bug را در Review پیدا نمیکنند.
- پاداشدادن به Tester بر اساس تعداد Bug Report. این کار Nitpicking و Reporting ضعیف را تشویق و Partnership با Programmer را نابود میکند چون رابطه را خصمانه میکند.
- سنجیدن Business Analyst براساس حجم Documentation تولیدشده، نه میزان Knowledgeی که با Team به اشتراک گذاشته است.
در نهایت Performance هر فرد باید بر آنچه Team تحویل میدهد بنا شود، نه صرفاً Role خاص او. این به معنی نادیدهگرفتن Programmer ضعیف یا مخرب نیست؛ Review باید Contribution او به Goalهای کل Team را بسنجد. اما افراد نباید از نگاهکردن بیرون مرز خشک Role خود دلسرد شوند. Environment خوب Programmerی را تشویق میکند که بخشی از Business Problem حلنشده را میبیند و رفع میکند یا Testerی را که Problem در Code/Architecture تشخیص میدهد و با Team مطرح میکند. این Environment Support لازم را میدهد و Project را موفقتر میکند.
Comprehensive Documentation و Traceability Matrix میتوانند منبع پنهان مشکل در Environment باشند. بهجای Trust، نگرش CYA — Cover Your Ass میسازند و Team را به Contract Negotiation بهجای Customer Collaboration میکشانند.
Tester در فرهنگ CYA میکوشد برای هر Requirement حتماً Test داشته باشد، حتی اگر به Quality کمک نکند. Developer فقط Letter of Requirement را رعایت میکند و به Value واقعی User فکر نمیکند، چون اگر چیزی را که Customer واقعاً نیاز دارد بسازد ممکن است بابت انحراف از Spec تنبیه شود. Business Analyst و Product Owner هم Scope و Requirement را آنقدر به هم میدوزند که گاهی Requirement ارزشمندی را صرفاً چون با Documentation موجود جور نیست حذف میکنند.
Team بیش از همه در محیطی نیاز به CYA دارد که Change چیز بدی تلقی میشود. در Comprehensive Documentation، Change گران است: Scope باید بازبینی، Spec Update، Design عوض و Traceability Matrix تعمیر شود. Manager هم طبیعی است دنبال «مقصر» این Extra Work بگردد. افراد به Defensive Documentation روی میآورند تا هنگام Blame بتوانند نشان دهند دقیقاً از کدام بخش Documentation پیروی کردهاند و از Performance Review بد یا Punishment نجات پیدا کنند.
متضاد CYA Trust است. شرکتی که فقط Minimal Documentation لازم را تولید میکند، Environmentی دارد که Team برای انجام کار درست هنگام Change مورد اعتماد است. Agile Team با نگرش «همه با هم هستیم» که در Failure همه سهم مسئولیت دارند، لازم نیست CYA کند. Change آسانتر میشود چون Documentation غیرضروری نگهداری نمیشود؛ Problem واقعی با Face-to-face Communication حل و فقط آنچه لازم است نوشته میشود، با اطمینان از اینکه Company به تصمیم درست Team اعتماد دارد—even اگر Project کمی بیشتر طول بکشد.
ارتباط بهتر برای پروژهٔ Ebook Reader
پروژهٔ Reader قطعاً میتوانست از Communication بهتر سود ببرد. روزهای جلسهٔ سنگین و جمعکردن Requirements جامع را به یاد آورید. این Requirements از بدبینی یا CYA شروع نشد؛ همه واقعاً فکر میکردند با بحث دربارهٔ کوچکترین جنبهها همهچیز پوشش داده میشود و بهترین Product حاصل خواهد شد. چون اینهمه وقت در آغاز گذاشته بودند توانستند از Spec اولیه دفاع کنند حتی وقتی Product نهایی دیگر در Market قابلرقابت نبود. اگر میتوانستند دقیقاً نیاز بازار دو سال آینده را پیشبینی کنند عالی میشد! نشد، اما دستکم کسی Job را از دست نداد چون همه میتوانستند به Specی اشاره کنند که دقیقاً پیاده شده بود.
اگر از ابتدا Communication بهتر بود چه؟ اگر Team بهجای Comprehensive Requirements فقط Minimum Documentation لازم برای شروع را مینوشت چه تغییری رخ میداد؟
شکل ۳-۵. وقتی Team بیشتر به Face-to-face Communication تکیه میکند و فقط Minimum Documentation لازم را دارد، همگام ماندن اعضا آسانتر میشود.
در این حالت باید به هم اعتماد میکردند که در طول مسیر Decision درست بگیرند. هنگام انتخاب Ebook Format به Format قدیمی آغاز پروژه زنجیر نبودند و میتوانستند New Standard را بپذیرند. حتی بهتر، شاید وقتی نوبت Internet Storefront میرسید واضح میشد Idea خوبی نیست و آن را رها میکردند—چیزی که وقتی Team به Specification آن متعهد است دشوار است. Communication بهتر Project را بهروز نگه میداشت و Product ارزشمندتری تحویل میداد.
فرض کنیم همین رخ داده است. Team حالا از Documentation کمحجمتر خوشحال است و فکر میکرد زمان زیادی ذخیره میشود. اما اگر با وجود آن Project هنوز On Track نباشد چه؟
به شکل عجیبی Time Saving ظاهر نشده. Team بیش از همیشه شبها و آخرهفتهها کار میکند تا همهٔ Featureهایی را که Product Owner برای هر Timeboxed Iteration قول داده جا دهد. انگار هرچه Agileتر میشوند Work بیشتر و زمان دور از Family بیشتر میشود. این که Improvement نیست! قبل از Burnout چه میتوان کرد؟
نکات کلیدی بخش ارتباط
- Documentation بیش از حد جامع Risk ابهام، سوءتفاهم و Miscommunication را زیاد میکند.
- Agile Team با Face-to-face Conversation و Minimum Documentation لازم مؤثرتر ارتباط میگیرد (اصل ۴).
- Developer هر روز با Business User کار میکند تا بیشترین Value را تحویل دهد (اصل ۵).
- همهٔ اعضای Agile Team خود را مسئول Project و پاسخگوی Success آن میدانند (اصل ۶).
اجرای پروژه — حرکتدادن پروژه به جلو
Communication و Trust شروع خوبی است. وقتی همه میدانند جایگاهشان چیست، باید روی بزرگترین Problem تمرکز کنند: انجام واقعی Work هر روز. Agile Team چگونه Project را در حرکت نگه میدارد؟
اصل ۷: نرمافزار کارا معیار اصلی پیشرفت است
Team خوب مطمئن میشود همه—Team Member، Manager، Stakeholder و Customer—در هر لحظه واقعاً میدانند Project کجاست. اما Status پروژه چگونه Communicate میشود؟ سختتر از چیزی است که به نظر میآید.
Project Manager Command-and-Control معمولاً با Schedule و Status Report گسترده Project را روی Course نگه میدارد. اما «Essence» واقعی Project در Status Report خوب ثبت نمیشود. سه نفر میتوانند یک Report را بخوانند و سه برداشت متفاوت از وضعیت داشته باشند. Reporting همچنین سیاسی است: تقریباً هر Project Manager زمانی تحت فشار قرار میگیرد چیزی را که Manager یا Team Lead را بد نشان میدهد از Report حذف کند—و معمولاً همان Information برای Decision فرد دیگری حیاتی است.
پاسخ Working Software است. همان لحظه که Software را در حال کار میبینید «میفهمید». معلوم است چه میکند و چه نمیکند. اگر Manager چیزی قول داده باشد که وارد Software نشده، شاید خجالتآور باشد، اما پنهانکردنش ممکن نیست؛ Software خودش حرف میزند.
شکل ۳-۶. Working Software از Progress Report برای بهروزکردن همه دربارهٔ Status پروژه بهتر است، چون مؤثرترین راه نشاندادن چیزی است که Team واقعاً انجام داده است.
این یکی از دلایل Iterative Development است. Team با تحویل Working Software در پایان هر Iteration و Demo واقعی Product، Progress را طوری نشان میدهد که تقریباً امکان برداشت اشتباه ندارد.
اصل ۸: فرایندهای Agile توسعهٔ پایدار را ترویج میکنند؛ حامیان، توسعهدهندگان و کاربران باید بتوانند برای مدت نامحدود آهنگی ثابت را حفظ کنند
تیم Ebook Reader نخستین تیمی نیست که برای رسیدن به Deadline غیرواقعی ساعتهای دیوانهوار کار میکند. در واقع Deadline سخت و غیرقابلمذاکره ابزار اصلی جعبهابزار Project Manager Command-and-Control است. وقتی Deadline نزدیک میشود، شب و آخرهفته نخستین راهحل میشود. Deadline غیرواقعی میتواند حتی ابزاری زیرکانه برای گرفتن کار بیشتر از Team باشد، با فشردن ساعتهای اضافه در هر هفته.
اما در بلندمدت کار نمیکند. شناختهشده است که Team میتواند چند هفته Crunch کند و Work بیشتری انجام دهد، اما بعد Productivity معمولاً سقوط میکند. طبیعی است: آدمها خسته و بیانگیزه میشوند، Fatigue بالا میرود و کارهای زندگی که عقب انداختهاند دوباره برمیگردند. تیمی که مدت طولانی Overtime شدید دارد، در واقع کمتر از تیمی با ساعت کار عادی تحویل میدهد و Quality هم معمولاً پایینتر است.
به همین دلیل Agile Team به Sustainable Pace باور دارد. باید فقط کاری را Plan کند که واقعاً در زمان رزروشده قابل انجام است. Iterative Development این را واقعبینانهتر میکند، چون Estimate مقدار Software در دو، چهار یا شش هفتهٔ آینده بسیار آسانتر از یک سال و نیم آینده است. با Promise کردن فقط چیزی که واقعاً قابل ساخت است، شبها و آخرهفتهها به استثنا تبدیل میشوند.⁵
⁵ این نمونهای از Simplification فصل ۱ است. فعلاً Sustainable Pace را دادن زمان کافی برای ساخت Software با ساعتهای سالم و بدون کار مداوم شب و آخرهفته تعریف میکنیم؛ بعداً اثر دقیق آن بر Environment، Culture و Quality را بررسی خواهیم کرد.
اصل ۹: توجه پیوسته به برتری فنی و طراحی خوب، چابکی را افزایش میدهد
Estimate بد تنها دلیل کار شب و آخرهفته نیست. بیشتر Developerها آن احساس فرورفتن دل را میشناسند وقتی Coding ظاهراً ساده ناگهان به Nightmare طراحی تبدیل میشود—و سه آخرهفتهٔ بعد صرف Bug Tracking و Patch Code خواهد شد.
در بلندمدت جلوگیری از Bug امروز بسیار سریعتر از Fix کردن آن فرداست. Code خوشطراحی هم آسانتر Maintain میشود چون برای Extend شدن ساخته شده است.
دو دههٔ گذشته انقلاب مهمی در Software Design آوردهاند: Object-Oriented Design/Analysis، Design Pattern، Decoupled و Service-Oriented Architecture و Innovationهای دیگر Pattern و Toolهای زیادی برای Technical Excellence در اختیار Developer گذاشتهاند.
اما این به معنی صرف زمان زیاد Agile Team برای Large-scale Design در آغاز Project نیست. Agile Developer عادتهای Coding قوی میسازد که به Well-designed Code منجر میشوند، دائم دنبال Design/Code Problem است و همان موقع برای Fix آن وقت میگذارد. چند دقیقه یا ساعت بیشتر امروز برای Solid Code و رفع Problem، Codebaseی میسازد که فردا Maintain کردنش آسان است.
محیط کاری بهتر برای تیم Ebook Reader
Team و همسرانشان قطعاً از Sustainable Pace استقبال میکردند، اما خود Project هم بهتر میشد. از روز اول به شب و آخرهفته محکوم بودند چون Tool لازم برای Plan واقعبینانهای که یک سال و نیم بعد هم دقیق بماند نداشتند.
بدتر اینکه Design و Architecture را برای Specification بسیار جزئی آغاز پروژه ساختند و در نهایت Code بسیار Complex و سخت برای Extend داشتند. Changeهای کوچک به Patchهای بزرگ و Spaghetti Code در Codebase تبدیل شدند. با Iterative Approach و Working Software در طول مسیر، میتوانستند هر Iteration را طوری Plan کنند که Sustainable Pace حفظ شود. Architecture سادهتر و Just-in-time میتوانست Design منعطفتر و Extensibleتری بسازد. Practiceهای بهتر Design، Architecture و Coding به Codeی میانجامید که Maintain و Extend آن آسانتر بود.
فرض کنیم Team همهٔ این اصول را به کار گرفته و حالا ماشین روان تولید Software است: Iteration دارد، منظم Working Software تحویل میدهد، دائم Adjust میکند تا باارزشترین Software را بسازد، Communication خوب و Documentation فقط بهاندازهٔ نیاز دارد، Design Practiceهای خوب و Codebase قابلنگهداری میسازد و بدون Overtime انجامش میدهد. Team واقعاً Agile شده است.
اما ابرهای تیرهٔ پروژهٔ بعدی دیده میشوند. Project Manager جدید دعوت جلسهای عظیم برای هرکسی که میتواند پیدا کند میفرستد. دعوتها Accept میشوند، Room رزرو میشود و بحث دربارهٔ Requirementsی که باید Document شوند شروع میشود... و Team تازه Agileشده دوباره همان حس بد را در معده دارد.
میدانند چه میآید: اولین Specها، Planها و Gantt Chartها شروع به چرخش کردهاند. چگونه تضمین کنند Project بعدی دوباره در همان دامها نیفتد؟
نکات کلیدی بخش اجرا
- مؤثرترین روش Communicate کردن Progress، تحویل Working Software و قرار دادن آن در دست User است (اصل ۷).
- Team در Sustainable Pace و با پرهیز از Heroics، Shortcut و Overtime بیشترین Productivity را دارد (اصل ۸).
- Softwareی که خوب Design و Implement شده سریعتر تحویل میشود چون تغییرش آسانتر است (اصل ۹).
بهبود پیوستهٔ پروژه و تیم
یکی از بنیادیترین اصول Design در همهٔ Engineering اصل KISS — Keep It Simple, Stupid است. Agile Team در Planning، ساخت Software و ادارهٔ Team با همین اصل زندگی میکند.
اصل ۱۰: سادگی—هنر بیشینهکردن کاری که انجام نمیشود—ضروری است
افزودن Code به Project موجود معمولاً Complexity را زیاد میکند، مخصوصاً وقتی Code بیشتری به آن وابسته شود. Dependency بین System، Object، Service و غیره Code را Complex و Change را دشوار میکند؛ یک Change به بخش دوم و سپس سوم Cascade میکند و Domino Effect پیچیدگی میسازد. Iteration و Minimal Documentation در آغاز به Team کمک میکنند Software غیرضروری تحویل ندهد.
بااینحال خیلی از Developerها وقتی نخستین بار میشنوند «Iterative Development انجام بده» یا «Minimum Planning لازم برای شروع را انجام بده» ناراحت میشوند. احساس میکنند برای شروع Code زود است تا وقتی Decisionهای Design/Architecture زیاد گرفته و نوشته نشده باشند؛ وگرنه امروز Codeی مینویسند که فردا با Change Design باید حذف شود.
این واکنش قابل فهم است چون در بسیاری Projectهای خارج Software Development منطقی است. Programmer تازهوارد Agile ممکن است بگوید: «اگر Contractor خانهام را Renovate کند، اول Blueprint کامل میخواهم. نمیخواهم یک گفتوگوی کوتاه کند و بعد شروع به خرابکردن دیوارها کند.»
برای Renovation درست است. چون مخربترین کار با خانه برداشتن Sledgehammer و خرابکردن Wall است. اما Software با Object فیزیکی فرق دارد. Delete Code چندان مخرب نیست؛ معمولاً Version Control آن را برمیگرداند. مخربترین کار در Project ساخت Code جدید و سپس ساخت Code بیشتر وابسته به آن است، بعد Dependency بیشتر و Domino Effect Changeها تا Spaghetti Code غیرقابل نگهداری.
Maximize کردن Work Not Done یعنی اجتناب از همین Mess. بهترین راه ساخت System با Dependency و Code غیرضروری کم است. مؤثرترین روش هم همکاری با Customer/Stakeholder و ساخت فقط Useful و Valuable Software است. اگر Feature Value ندارد، در بلندمدت Build نکردنش ارزانتر است، چون Cost نگهداری Additional Code میتواند از Value آن بیشتر شود. هنگام Code، Design را با Unitهای کوچک و Self-contained مانند Class، Module و Service که فقط یک کار میکنند ساده نگه دارید؛ این Domino Effect را کاهش میدهد.⁶
⁶ این هم Simplification دیگری است. بعداً دقیقاً میبینیم Team چگونه بدون Big Design Up Front Code عالی میسازد و همچنان Change را میپذیرد.
اصل ۱۱: بهترین معماریها، نیازمندیها و طراحیها از تیمهای خودسازمانده پدید میآیند
Design بیش از حد Complex در Teamهایی که Up-front Planning زیاد میکنند رایج است. به Waterfall فصل ۲ نگاه کنید: Phase کامل برای Requirements و Phase دیگری برای Design/Architecture دارد. وقتی تمام Phase به Design اختصاص داده شده، «بهترین کار ممکن» طبیعی است که به Awesomeترین Architecture ممکن تعبیر شود. برای چنین Teamی Requirements کم و Simple Design انگار کمکاری است؛ پس عجیب نیست Document بزرگ و Design پیچیده تولید کند—Process دقیقاً همین را از آنها خواسته است.
Self-organizing Team برعکس، Phase مستقل Requirements یا Design ندارد. افراد با هم Project را Plan میکنند، نه با تکیه بر یک نفر «مالک Plan»، و مرتب بهعنوان Team Plan را Revision میکنند. Project را به User Story یا Chunkهای کوچک تقسیم میکنند و ابتدا سراغ مواردی میروند که بیشترین Value را به Company میدهند؛ بعد دربارهٔ Detailed Requirement، Design و Architecture فکر میکنند.
این کار Job معمار سنتی را دشوارتر و در عین حال رضایتبخشتر میکند. در تصویر سنتی Software Architect پشت در بسته و بهصورت انتزاعی به Problemها فکر میکند. همهٔ Architectها اینطور نیستند، اما فاصلهداشتن از Day-to-day Work غیرمعمول نیست.
در Agile Team همه مسئول Architecture هستند. Senior Architect/Designer هنوز Role مهم دارد، اما دیگر در Isolation کار نمیکند. وقتی Team Software را Piece-by-piece و از باارزشترین Chunk میسازد، کار Architect چالشبرانگیزتر و اغلب جالبتر است. بهجای Big Design آغاز Project برای همهٔ Requirementها، Incremental Design به کار میرود؛ Techniqueهایی که System را هم Complete و هم آسان برای Modify در برابر Change میسازند.
اصل ۱۲: تیم در فواصل منظم دربارهٔ مؤثرترشدن تأمل میکند و رفتار خود را متناسب با آن تنظیم میکند
Team تا وقتی دائماً روش ساخت Software را بهتر نکند Agile نیست. Agile Team پیوسته Inspect and Adapt میکند: میبیند Project چگونه پیش رفته و Knowledge آن را برای Improvement آینده استفاده میکند. این فقط End Project نیست؛ در Daily Meeting هم دنبال راه Change میگردد و اگر منطقی باشد Work فعلی را تغییر میدهد.⁷
باید بتوانید با خودتان و Team دربارهٔ آنچه کار میکند و نمیکند بیرحمانه صادق باشید، مخصوصاً در آغاز مسیر Agile. تنها راه افزایش Capability این است که دائم به گذشته نگاه کنید، کارکرد Team را Assess کنید و Plan بهترشدن بسازید.
تقریباً همه قبول دارند این کار خوب است، اما Retrospect از آن کارهایی است که خیلی Teamها قصدش را دارند و انجامش نمیدهند. دلیل اول ناراحتی اولیه است: باید Problem و Mistake مشخص را دید و کمتر کسی راحت است Mistake همکارش را علنی کند. با زمان Team راحتتر میشود و این گفتوگو بیشتر Constructive دیده میشود تا Critical.
دلیل دوم این است که Time رزرو نمیشود؛ یا حتی اگر شود، شروع زودتر Project بعدی مهمتر به نظر میرسد. Teamی که از ابتدا در پایان هر Iteration و End Project زمان Meeting، Review، Assessment و Improvement Plan رزرو کند احتمال بیشتری دارد واقعاً درسها را مرور کند و از Experience یاد بگیرد.
نکات کلیدی بخش بهبود
- Agile Team Solution را با نساختن Feature غیرضروری یا Software بیش از حد Complex تا حد ممکن ساده نگه میدارد (اصل ۱۰).
- Self-organizing Team مسئولیت همهٔ جنبههای Project، از تصور Product و Project Management تا Design و Implementation را شریک میشود (اصل ۱۱).
- با نگاه به عقب و گفتوگو دربارهٔ Lesson Learned پس از هر Iteration و End Project، Agile Team دائماً در ساخت Software بهتر میشود (اصل ۱۲).
پروژهٔ Agile: کنار هم آوردن همهٔ اصول
Agile در تاریخ Software Engineering خاص است. شبیه موجهای Silver Bullet Methodology نیست که وعده میدادند با ترکیبی از Practice جادویی، Tool درخشان و اغلب Invoice بزرگ Consulting همهٔ Problemهای Software را حل کنند.
یکی از تفاوتهای Teamی که فقط نتیجهٔ «بهتر از هیچکاری نکردن» میگیرد با Teamی که Benefit جدی از Agile میگیرد این است که دومی Practiceها را «Menu انتخابی» نمیبیند. کلید استفادهٔ مشترک از Practiceها Mindset تیم است و این Mindset از Agile Values و Principles میآید.
Agile متفاوت است چون با Value و Principle شروع میشود. Teamی که Agile میشود باید صادقانه نه فقط نحوهٔ ساخت Software، بلکه شیوهٔ Interaction با هم و با Company را بررسی کند. ابتدا Principles را بفهمد و بعد Methodology را اعمال کند، با آگاهی از اینکه Work، Assessment و Improvement زیادی در طول راه لازم است. این رویکرد مسیر واقعی برای افزایش Agility و ساخت و تحویل Software بهتر میدهد.
پرسشهای متداول
من یک Developer «Rock Star» هستم و فقط لازم است بقیه کنار بروند تا Software عالی بسازم! چرا باید به Task Board و Burndown Chart فکر کنم؟
هر Developer عالی تجربه کرده Code خوبی بسازد و بعد بهخاطر Change لحظهٔ آخر از فردی که چیزی از ساخت Code نمیداند مجبور شود آن را تکهتکه و Patch کند. برای کسی که Craft برنامهنویسی مهم است، Technical Compromise غیرضروری بهخاطر اینکه Non-developer تا میانهٔ Project به نیازش فکر نکرده بسیار آزاردهنده است.
همین یکی از علتهایی است که Developerهای خوب جذب Agile Team میشوند. بله، باید به Planning اهمیت بدهید و Toolهایی مثل Task Board و Burndown Chart را استفاده کنید. Agile Methodology چنین Practiceهایی دارد چون ساده و تا Minimum لازم برای Plan/Run Project لاغر شدهاند. سود بزرگ مشارکت در Planning این است که میتوانید با پرسیدن Tough Questionها هنوز در زمان Planning از Change آزاردهندهٔ آخر جلوگیری کنید. این فقط چون Agile Team از آغاز دائم با User ارتباط دارد کار میکند. خیلی Developerهای خوب همان بار اولی که سؤال دشواری از User میپرسند و متوجه Requirement مهمی میشوند، به ارزش Planning ایمان میآورند.
در بسیاری موارد همین سؤال دشوار Changeی را آشکار میکند که وگرنه در آخر Project ظاهر میشد. جلوگیری از همان Rip-and-patch Coding دقیقهٔ آخر، دلیل قانعکنندهای برای Adoption Agile است.
Agile Planning همچنین دربارهٔ Communication با Team است و میتواند Developer عالی را هم بهتر کند. «Rock Star»ها همیشه یاد میگیرند، اما در Command-and-Control Team از همکاران جدا هستند و بیشتر Learning باید Self-directed باشد. Self-organizing Team Communication زیادی دارد، ولی نه Status Meetingهای بیپایان و بیفایده؛ اعضا خودشان تصمیم میگیرند برای درست انجامشدن Project دربارهٔ چه چیزهایی حرف بزنند.
این هم Project را بهتر میکند و هم Knowledge Sharing را خودکار میسازد. اگر Developer کنار شما Design Pattern جدیدی را به شیوهای به کار ببرد که ندیدهاید، تا پایان Project خواهید فهمید Idea خوبی بوده یا نه و اگر خوب باشد وارد Toolbox شما میشود؛ Learning بدون Effort اضافه، صرفاً چون Team خوب Communicate میکند. به همین دلیل Developerهایی که Agile را میپذیرند اغلب از نظر فنی بهتر میشوند و حس میکنند Craft برنامهنویسیشان دائم رشد میکند.
من Project Manager هستم و هنوز نمیدانم در Agile Team کجا قرار میگیرم. Role من چیست؟
اگر Project Manager باشید احتمالاً یکی از سه Role سنتی زیر را دارید:
- Planner «درگیر جزئیات» که Estimate میگیرد، Project Schedule میسازد و Work روزانهٔ Team را هدایت میکند.
- Product Expert، احتمالاً در نقش Business Analyst، که Requirements را تعیین و به Team منتقل میکند و مطمئن میشود Software آنها را برآورده میکند.
- Supervisor که با Senior Manager و Executive کار میکند و آنها را از بازده Investment پروژه آگاه نگه میدارد.
در فصل ۴ با Scrum، رایجترین Agile Methodology، و Roleهای Scrum Team آشنا میشوید. اگر Managerی هستید که آستین بالا میزند و با Team وارد Detail میشود، Scrum Master احتمالاً مناسب است؛ کار او کمک به Planning و برداشتن Roadblockهاست تا Team Software تحویل دهد. اگر Job شما فهم نیاز Company و Communication آن به Team است، احتمالاً Product Owner میشوید: Backlog را مدیریت میکنید، Featureهای هر Iteration را تعیین میکنید و در طول Project به سؤالهای جزئی Team پاسخ میدهید تا Software درست بسازند.
اگر Project Manager شما Role نظارتی دارد، معمولاً داخل Agile Team نخواهید بود و این اشکالی ندارد. در عوض یکی از مهمترین Roleها را بهعنوان Agile Champion دارید: تشویق Team و Managerها به Practiceهای Agile و ترویج Values. Backlog تقسیمشده به Iteration بههمراه Detail Iteration فعلی همان سطح Detail مناسبی است که برای Communication با Executive و Senior Manager نیاز دارید. هرچه Project Team تصویر واقعیتری از Progress و Goalها داشته باشد، فهم واقعبینانهتری به شما میدهد. برای این کار باید Agile Team را خوب بشناسید تا زبان آنها را بفهمید و Informationشان را به فرم قابل فهم برای Executive تبدیل کنید.
اگر کل Team با هم Plan میکند یعنی هیچکس رئیس نیست؟ این عملی به نظر نمیرسد. Decisionها چگونه گرفته میشوند؟
بستگی دارد چه Decisionی. اگر دربارهٔ Resolve Conflict میپرسید، همان روشی که Team فعلی شما انجام میدهد ادامه دارد. در Team فعلی چه کسی Disputeهای حلنشده را حل میکند؟ چه کسی Performance را Review میکند؟ Company Hierarchy میتواند شکلهای بسیار متفاوتی داشته باشد و Agile Team باید در هرکدام کار کند. البته Agile Team معمولاً Conflict را بهتر خودش حل میکند چون Communication بیشتر و Alignment قویتری با Goalهای مشترک دارد.
اگر سؤال دربارهٔ این است که چه Featureهایی وارد Software شوند یا چگونه ساخته شوند، Roleهای مشخص جواب میدهند. در Scrum، Product Owner اختیار تصمیم دربارهٔ Feature را دارد؛ اما Team فقط Featureهایی را میپذیرد که براساس Information واقعی در Iteration جا شوند. Plan مالک کل Team است چون Self-organizing است.
مالکیت Team بر Plan به معنی نبودن Boss نیست. رئیس وجود دارد و اگر امروز Agile شوید احتمالاً یک سال بعد همان رئیس را دارید. تفاوت این است که او آنقدر به Agile باور دارد که به Team اختیار Project Decision میدهد و پشت آن Decisionها میایستد، بدون Micromanage یا Second-guess. در دنیای واقعی فقط در این صورت سیستم کار میکند.
کارهایی که امروز میتوانید انجام دهید
- اگر اکنون Project میسازید، پیش از شروع Code پانزده دقیقه با Team دربارهٔ Featureهایی که میسازید حرف بزنید. آیا دو نفر تصویر متفاوتی از چیزی دارند که قرار است ساخته شود؟
- فهرست Featureهای در حال کار را بنویسید و بر اساس Value و Difficulty مرتب کنید.
- چند دقیقه وقت بگذارید و همهٔ Documentationهایی را که Team تولید یا مصرف میکند فهرست کنید. آیا چیزی هست که واقعاً برای ساخت Code استفاده نمیشود؟
- دفعهٔ بعد که تا دیروقت کار میکنید ببینید علت چه بود. آیا Deadline بیش از حد Aggressive بود؟ Extra Work دقیقهٔ آخر اضافه شد؟ شناخت Problem و علت آن نخستین گام Fix است.
برای یادگیری بیشتر
- دربارهٔ Values و Principles Agile Manifesto و نحوهٔ ایجاد آن: Alistair Cockburn, Agile Software Development: The Cooperative Game, 2nd Edition (Addison-Wesley, 2006).
- دربارهٔ Value، Iteration و Agile Project Management: Jim Highsmith, Agile Project Management: Creating Innovative Products, 2nd Edition (Addison-Wesley, 2009).
- دربارهٔ چالشهای Going Agile و غلبه بر آنها: Mike Cohn, Succeeding with Agile (Addison-Wesley, 2009).
- دربارهٔ عبور از Mindset فرماندهیوکنترل: Lyssa Adkins, Coaching Agile Teams (Addison-Wesley, 2010).
نکتههای مربیگری
- به Team کمک کنید بفهمد ساعتهای کاری بسیار طولانی باعث میشود Code کمتر و با Quality پایینتر ساخته شود، نه بیشتر.
- با اعضا جداگانه دربارهٔ Jobشان صحبت کنید: چه چیزی Motivation میدهد؟ چه چیزی Frustrate میکند؟ چه چیزی Decisionهایشان را هدایت میکند؟
- از هر نفر بخواهید سه Agile Principle را که بیشترین اثر مثبت یا منفی روی او دارند انتخاب کند. افراد از تفاوت انتخابها تعجب میکنند و همین Common Ground تیم را آشکار میکند.
- Principles مشترک را نقطهٔ شروع برای یافتن Practiceهایی قرار دهید که با Mindset Team بهترین تطابق را دارند.
تصاویر زیر از صفحات مربوط به همین مقاله در PDF اصلی استخراج و بهصورت دادهٔ داخلی Base64 جاسازی شدهاند.
تصویر منبع - صفحهٔ PDF 83
تصویر منبع - صفحهٔ PDF 87
تصویر منبع - صفحهٔ PDF 89
تصویر منبع - صفحهٔ PDF 93
تصویر منبع - صفحهٔ PDF 95