فصل ۲ — Agile Manifesto، فیل Agile و انتخاب Methodology | Learning Agile

عنوان اصلی اثر

Learning Agile: Understanding Scrum, XP, Lean, and Kanban

عنوان این مقاله

فصل ۲ — Agile Manifesto، فیل Agile و انتخاب Methodology

عنوان بخش منبع

Chapter 2: Agile Manifesto and methodology selection

نویسندگان

Andrew Stellman و Jennifer Greene

زبان اصلی

English

صفحات منبع

53 تا 70 از PDF

حق‌نشر منبع

Copyright © 2015 O’Reilly Media, Inc. — All rights reserved.

تاریخ ترجمه

1405/05/20 / 2026-08-11

اعتبار ترجمه

ترجمه با کمک هوش مصنوعی

فروش یا انتشار این ترجمه منوط به داشتن مجوز لازم از صاحب حقوق اثر است.

فصل ۲: درک ارزش‌های اجایل — Agile Manifesto، استعارهٔ فیل و انتخاب متدولوژی

ادامهٔ نکات کلیدی بخش قبل

• پروژه‌های نرم‌افزاری از دههٔ ۱۹۶۰ غیرقابل‌پیش‌بینی بوده‌اند و نتایج ضعیفی داشته‌اند؛ در آن دوره برای این وضعیت نام «software crisis» به کار رفت.
• بسیاری از تیم‌ها تلاش می‌کنند با پذیرش practiceهای عالی اجایل که همان کارهای فعلی‌شان را بهتر می‌کند، «اجایل شوند».
• پذیرش practiceهای بهتر به نتایج «بهتر از انجام‌ندادن» می‌رسد، چون تیم شیوهٔ بنیادی ارتباط و کار خود را تغییر نداده است.
• user story یک practice اجایل است که در آن یک عضو تیم—اغلب product owner—در یک یا چند جمله و با زبانی قابل‌فهم برای کاربران، یک شیوهٔ مشخص تعامل کاربر با سیستم را شرح می‌دهد.
• پذیرش practiceها یکی‌یکی رایج‌ترین روش پذیرش اجایل امروز است، اما مؤثرترین مسیر برای اجایل‌شدن نیست.

Agile Manifesto کمک می‌کند هدف پشت هر practice دیده شود

Manifesto for Agile Software Development که بیشتر با نام Agile Manifesto شناخته می‌شود، در سال ۲۰۰۱ به‌دست گروهی از ۱۷ نفر هم‌فکر ساخته شد. آن‌ها در Snowbird Retreat، در کوه‌های اطراف Salt Lake City در Utah، گرد هم آمدند تا برای مشکلات توسعهٔ نرم‌افزاری که در طول حرفه‌شان دیده بودند راه‌حلی پیدا کنند. پس از چند روز بحث، روی مجموعه‌ای اصلی از ایده‌ها و اصول—و همچنین نام «agile»—توافق کردند و همه را در یک سند واحد گرد آوردند. همین سند آغازگر تغییر نگرشی در دنیای توسعهٔ نرم‌افزار شد.

Agile Manifesto چهار ارزش ساده دارد. متن کامل آن چنین است:

«ما با انجام توسعهٔ نرم‌افزار و کمک به دیگران برای انجام آن، در حال کشف راه‌های بهتری برای توسعهٔ نرم‌افزار هستیم. از این کار به این ارزش‌ها رسیده‌ایم:

• افراد و تعاملات، مهم‌تر از فرایندها و ابزارها؛
• نرم‌افزار کارا، مهم‌تر از مستندات جامع؛
• همکاری با مشتری، مهم‌تر از مذاکرهٔ قراردادی؛
• پاسخ‌گویی به تغییر، مهم‌تر از پیروی از برنامه.

یعنی با اینکه موارد سمت راست ارزشمندند، موارد سمت چپ را بیشتر ارزش می‌نهیم.»

فهم اجایل و کار مؤثر با آن از فهم همین ارزش‌ها آغاز می‌شود.

افراد و تعاملات، مهم‌تر از فرایندها و ابزارها

افراد وقتی کورکورانه از یک process پیروی می‌کنند ممکن است اشتباه کنند. یک ابزار عالی گاهی فقط کمک می‌کند کار اشتباه را سریع‌تر انجام دهید. دنیای نرم‌افزار پر از practiceهای عالی است، اما همهٔ آن‌ها برای هر پروژه و هر موقعیت مناسب نیستند. آنچه در همهٔ موقعیت‌ها اهمیت دارد، شناخت افراد تیم، نحوهٔ همکاری آن‌ها و اثری است که کار هر فرد بر دیگران می‌گذارد.

این ایده به‌ویژه برای کسی مفید است که می‌خواهد نحوهٔ کار تیمش را بهتر کند. به همین دلیل تیم‌های اجایل افراد و تعاملات را بالاتر از processها و ابزارها قرار می‌دهند: داشتن «process درست» یا «بهترین practice» کافی نیست. اگر افرادی که باید از process یا ابزار استفاده کنند آن را نپذیرند، کنار گذاشته می‌شود؛ یا بدتر، افراد فقط متن process را مو به مو اجرا می‌کنند حتی اگر به نتیجه‌ای بی‌معنا منجر شود. پیش از پیاده‌سازی یک process—حتی اگر از نظر منطقی بسیار معقول و rationally کار درست باشد—باید آن را برای افرادی که با شما کار می‌کنند قابل‌قبول کنید. اگر مردم نفهمند چرا این کار را می‌کنید، تنها چیزی که می‌بینند یک تغییر دل‌بخواهی است که به آن‌ها تحمیل می‌شود.

پس همیشه و در هر شرایطی به یاد داشته باشید با گروهی از انسان‌ها کار می‌کنید. هرکدام انگیزه‌ها، ایده‌ها و ترجیح‌های خودش را دارد.

practiceهای اجایل زیادی از این اصل پشتیبانی می‌کنند. به همین دلیل در سراسر کتاب با practiceهایی مانند daily standup و retrospective روبه‌رو می‌شوید که افراد را به تعامل و گفت‌وگو دربارهٔ نحوهٔ پیشرفت پروژه یا iteration و درس‌های آموخته‌شده تشویق می‌کنند. user story هم همین‌طور است: خودِ متن story از این واقعیت کم‌اهمیت‌تر است که باعث می‌شود تیم دربارهٔ معنای آن گفت‌وگو کند.

نرم‌افزار کارا، مهم‌تر از مستندات جامع

در سراسر دنیا کلاسورهای پر از documentation کامل نرم‌افزار روی قفسه‌ها نشسته‌اند و باز نشده‌اند. چیزهای بسیار زیادی را می‌توان در پروژهٔ نرم‌افزاری document کرد و وسط فشار پروژه اغلب سخت است پیش‌بینی کنیم کدام سند در آینده مفید می‌شود و کدام خاک خواهد خورد. به همین دلیل بسیاری از تیم‌ها—و به‌خصوص مدیرانشان—رویکردی جامع انتخاب می‌کنند که در آن هر جزئیات کوچکی باید document شود، چه خواننده‌ای برای آن وجود داشته باشد چه نه.

تیم‌های اجایل working software را مهم‌تر از comprehensive documentation می‌دانند. اما عبارت «working software» ممکن است مبهم به نظر برسد؛ «working» دقیقاً یعنی چه؟ برای یک practitioner اجایل، working software نرم‌افزاری است که برای سازمان value ایجاد کند. ممکن است محصولی باشد که شرکت می‌فروشد و درآمد می‌سازد، یا نرم‌افزاری داخلی که کارکنان با آن کارشان را کارآمدتر انجام می‌دهند. برای ایجاد value، پروژه باید بیش از هزینهٔ ساختش پول تحویل دهد یا صرفه‌جویی کند. در بسیاری از مواقع ارزش در نهایت به پول برمی‌گردد، حتی اگر تیم مستقیم درباره‌اش حرف نزند. پس تیم باید ساخت و تحویل working softwareای را در مرکز قرار دهد که value می‌آورد. documentation صرفاً وسیله‌ای برای رسیدن به این هدف است.

این ارزش به این معنا نیست که نباید documentation بنویسید. انواع زیادی از سند برای تیم بسیار مفید است. فقط باید به یاد داشت کسانی که documentation می‌نویسند اغلب همان کسانی هستند که software را می‌سازند. سندی که به آن‌ها در فهم problem، ارتباط با users و اصلاح مشکلات پیش از ورود به software کمک کند، زمان و تلاش بیشتری از هزینهٔ خودش ذخیره می‌کند. اتفاقاً چنین اسنادی—مانند wireframe یا sequence diagram—اغلب از همان انواعی هستند که programmerها از نوشتنشان بدشان نمی‌آید.

از سوی دیگر تمرکز بر working software راه خوبی است برای مطمئن‌شدن از اینکه تیم در مسیر می‌ماند. هر وقت documentation به‌وضوح به سمت working software حرکت می‌کند، مشارکت مثبتی در پروژه دارد. گاهی تیم می‌تواند documentation را به‌شکلی نوآورانه داخل خود software قرار دهد. مثلاً در test-driven development، programmerها automated unit test را پیش از code اصلی می‌سازند. این testها code هستند و کنار بقیهٔ code ذخیره می‌شوند، اما هم‌زمان documentation هم محسوب می‌شوند، چون recordای از رفتار مورد انتظار code و اجزای software در اختیار توسعه‌دهنده می‌گذارند.

همکاری با مشتری، مهم‌تر از مذاکرهٔ قراردادی

بعضی‌ها با دیدن «contract negotiation» تصور می‌کنند این ارزش فقط برای consultantها و contractorهایی است که با قرارداد رسمی کار می‌کنند، اما برای بسیاری از تیم‌های داخل یک شرکت هم صدق می‌کند. وقتی programmerها، testerها، business ownerها و project managerها در تیم‌های جدا هستند و واقعاً برای goal مشترک تحویل working software همکاری نمی‌کنند، با هم طوری رفتار می‌کنند که انگار طرف‌های قراردادند. در بسیاری از شرکت‌ها حتی SLA یا service-level agreement میان programming teamها، testerها و developerها، و میان team و user تعریف می‌شود.

این کار شاید risk دردسر با boss را کم کند، چون مقصرکردن تیم دیگر را آسان می‌کند؛ اما اگر goal رساندن working software به دست user باشد، شدیداً counterproductive است. developerای که دائماً در حال محافظت از خودش است کمتر می‌تواند راه‌های تازهٔ collaboration و innovation با کسانی که قرار است software را استفاده کنند امتحان کند.

یکی از راه‌هایی که تیم‌های اجایل این ارزش را اجرا می‌کنند داشتن product owner به‌عنوان عضو واقعی و درجه‌یک تیم است. ممکن است خودش code ننویسد، اما در meetingها حاضر می‌شود، idea می‌دهد و مهم‌تر از همه نسبت به محصول نهایی حس ownership دارد. product owner اغلب از user story برای collaboration با بقیهٔ team استفاده می‌کند.

پاسخ‌گویی به تغییر، مهم‌تر از پیروی از برنامه

یک جملهٔ قدیمی مدیریت پروژه می‌گوید: «کار را برنامه‌ریزی کن و برنامه را اجرا کن.» مشکل اینجاست که اگر plan اشتباه را اجرا کنید، محصول اشتباه می‌سازید. تیم‌ها باید دائماً دنبال change بگردند و وقتی نیاز user یا شیوهٔ ساخت software تغییر کرد، به‌درستی پاسخ دهند. اگر شرایط تغییر کند، پروژه به plan جدید نیاز دارد.

مقاومت کسی که plan را ساخته در برابر change غیرعادی نیست، چون تغییر plan کار می‌برد. ممکن است effort زیادی برای شکستن work به packageها و estimate هر کدام صرف شده باشد. یک change ممکن است project manager را مجبور کند همهٔ این کارها را دوباره انجام دهد. اگر او پیروی از plan را بالاتر از پاسخ به change بگذارد، ممکن است سرسختانه مقاومت کند. این مقاومت شاید ظاهر پروژه را smooth نگه دارد، اما اگر change واقعاً لازم باشد، اجرای آن در آینده و پس از کامل‌ترشدن code بسیار سخت‌تر خواهد شد.

شکل 2-3 — تیم‌های اجایل اغلب از task board برای نمایش taskها و دنبال‌کردن progress استفاده می‌کنند. task یا user story روی index card نوشته می‌شود و با پیشرفت کار روی board جابه‌جا می‌شود. بسیاری از تیم‌ها chartهایی نیز روی board می‌کشند تا progress را دنبال کنند.

task board مثال خوبی از practiceای است که کمک می‌کند تیم دربارهٔ پاسخ به change تصمیم درست بگیرد. هر واحد work—معمولاً user story—روی index card نوشته و به board وصل می‌شود، مثل boardی که Joanna در پروژهٔ jukebox استفاده کرد؛ معمولاً columnها status هر کار را نشان می‌دهند. task board را می‌توان با software هم مدیریت کرد، اما بسیاری از تیم‌ها نصب فیزیکی روی دیوار را مؤثرتر می‌دانند، چون ایستادن جلوی board، حرف‌زدن، اشاره‌کردن و جابه‌جاکردن storyها شکل غنی‌تری از communication نسبت به صرف گفت‌وگوست.

board طوری است که هرکس بتواند order taskها را جابه‌جا کند و حتی تشویق می‌شود این کار را انجام دهد. وقتی change رخ می‌دهد، افراد می‌توانند index card جدید اضافه کنند و مجبور نیستند همهٔ changeها از یک hub مرکزی project manager عبور کند. این روش همه را در جریان change نگه می‌دارد و مانع کهنه‌شدن plan می‌شود.

اصول مهم‌تر از practiceها

تیم jukebox با نتیجهٔ «بهتر از انجام‌ندادن» به نتایج خوبی رسید چون practiceهای عالی گرفت و پروژه بهتر شد. اما fractured perspective مانع شد benefit کاملِ همکاری جمعی برای ساخت نرم‌افزار بهتر را بگیرند. اجایل ذهنیتی دارد که فراتر از practiceهاست و تیمی که راهش را به ایده‌های پشت اجایل پیدا کند، شکل‌های بهتری از collaboration و interaction پیدا می‌کند.

یعنی تیمی که practiceهای اجایل را برای goal ساخت working software ارزشمند برای customer، از راه interaction، collaboration و responding to change استفاده می‌کند، از پروژه بیشتر بهره می‌برد تا تیمی که فقط planning، programming و documentation بهتری پذیرفته است.

Jim Highsmith این ایده را در Agile Project Management: Creating Innovative Products خوب خلاصه می‌کند: «بدون practiceهای concrete، اصول عقیم‌اند؛ اما بدون اصول، practiceها جان، شخصیت و قلب ندارند. محصول عالی از تیم عالی می‌آید؛ تیم‌هایی اصول‌مند، با شخصیت، با قلب، با persistence و courage.»

پس تیم چگونه از صرف پذیرش practiceها فراتر می‌رود و «principled» می‌شود تا محصول عالی بسازد؟

نکات کلیدی

• Agile Manifesto ارزش‌ها و ایده‌های مشترکی دارد که به تیم مؤثر منجر می‌شود.
• «افراد و تعاملات مهم‌تر از فرایندها و ابزارها» یعنی ابتدا روی انسان‌ها و communication تمرکز کنید و بعد روی tool و practice.
• «working software مهم‌تر از comprehensive documentation» یعنی تحویل softwareای که نیاز user را انجام می‌دهد مهم‌تر از specificationای است که آن را توصیف می‌کند.
• working software یعنی softwareای که value برای company ایجاد می‌کند.
• «customer collaboration مهم‌تر از contract negotiation» یعنی همه را عضو یک team ببینید.
• بسیاری از تیم‌های مؤثر اجایل product owner را عضو project team برای collaboration می‌دانند، نه client یا customer برای negotiation.
• «responding to change مهم‌تر از following a plan» یعنی planها inaccurate می‌شوند و تحویل software مهم‌تر از اجرای کور plan است.
• task board ابزار planning اجایل است که user storyها را روی board و در columnهای متناسب با status پروژه یا iteration دسته‌بندی می‌کند.

پاورقی 6 — Jim Highsmith، Agile Project Management: Creating Innovative Products، ویرایش دوم، Pearson Education، 2009.

درک فیل

Lyssa Adkins در کتاب Coaching Agile Teams توضیح می‌دهد metaphor چگونه ابزار قدرتمندی برای فهم concept است. مربیان حرفه‌ای مدت‌هاست این را می‌دانند؛ metaphor حتی مهارتی اصلی در دوره‌های professional coaching است. coach با پرسش‌ها به client کمک می‌کند metaphor خودش را بسازد؛ استعاره‌ای ملموس و resonant که بعداً برای جهت‌یابی در رخدادهای زندگی از آن استفاده کند.

استعاره‌ای مفید برای فهم بهتر fractured perspective و اینکه چرا تیم را به مسیر کم‌اثر می‌برد، داستان «مردان نابینا و فیل» است:

شش مرد نابینا خواستند بفهمند فیل چه شکلی است و هر کدام بخش متفاوتی از بدن فیل را لمس کردند. کسی که پا را لمس کرد گفت فیل مثل ستون است؛ کسی که دم را لمس کرد گفت مثل طناب؛ کسی که خرطوم را لمس کرد گفت مثل شاخهٔ درخت؛ کسی که گوش را لمس کرد گفت مثل بادبزن دستی؛ کسی که شکم را لمس کرد گفت مثل دیوار و کسی که عاج را لمس کرد گفت مثل لوله‌ای سخت است.

پادشاه به آن‌ها توضیح داد: «همهٔ شما درست می‌گویید. دلیل اینکه هرکدام چیز متفاوتی می‌گویید این است که بخش متفاوتی از فیل را لمس کرده‌اید. در واقع فیل همهٔ ویژگی‌هایی را که گفتید دارد.»

پاورقی 7 — Lyssa Adkins، Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition، Addison-Wesley، 2010.

پاورقی 8 — برگرفته از صفحهٔ Wikipedia داستان Blind Men and the Elephant، بازیابی‌شده در 25 June 2014.

تیم‌هایی که از اجایل نتایج better-than-not-doing-it می‌گیرند اغلب قبل از اجایل هم می‌توانستند نرم‌افزار را نسبتاً خوب تحویل دهند و امیدوار بودند اجایل پروژهٔ خوب را بهتر کند. مشکل این است که پیش از پذیرش اجایل هم مشکلاتی داشتند؛ نه مشکلات شدید software crisis که پروژه را کامل نابود می‌کرد، بلکه friction و discomfort در تیم.

fractured perspective واقعاً یعنی همین: developer دربارهٔ موضوعات developer فکر می‌کند، project manager دربارهٔ موضوعات project manager و code از «روی دیوار» برای business user پرتاب می‌شود که او هم دربارهٔ business فکر می‌کند. هرکس آن‌قدر درگیر کار خودش است که حتی اصطلاح «throw it over the wall» را به کار می‌برد؛ اصطلاحی که team را صریحاً تقسیم می‌کند و collaboration را می‌کشد. وقتی هرکس فقط practiceهای خودش را می‌بیند communication کم می‌شود و افراد به‌جای team، اشخاصی جدا هستند که فقط به goalهای سازگار حرکت می‌کنند.

اینجاست که داستان مردان نابینا و فیل وارد می‌شود. در پذیرش fractured agile، هر شخص فقط practiceهایی را به کار می‌گیرد که بر کار خودش اثر دارد، همان‌طور که هر مرد نابینا فقط یک بخش فیل را لمس کرد. developerها روی test-driven development، refactoring و automated build تمرکز می‌کنند. project managerها task board، project velocity و burndown chart را دوست دارند. business userها از release planning و user story برای فهم کار تیم استفاده می‌کنند. team leadها daily standup و retrospective را برای مدیریت و بهبود team به کار می‌برند. هرکس چیز متفاوتی از project می‌خواهد و چند practice می‌بیند که مشخصاً به خودش کمک می‌کند.

پذیرش هر یک از این practiceها به‌تنهایی واقعاً شرایط را بهتر می‌کند، چون practiceهای اجایل خوب‌اند. مشکل این است که developer، project manager، business user و team lead هرکدام project را از perspective متفاوتی می‌بینند و فقط practiceهایی را انتخاب می‌کنند که فوراً برایشان جذاب است. اثر paradoxical رخ می‌دهد: «دیدی! از اول حق با من بود.» هر شخص فقط همان بخشی از اجایل را می‌بیند که به کار خودش مربوط است و نتیجه می‌گیرد اجایل یعنی همهٔ افراد دیگر بالاخره باید viewpoint او را بپذیرند.

پس با اینکه «فیل» اجایل از practiceهای بسیار عالی ساخته شده، کل آن از مجموع اجزا بزرگ‌تر است. اگر فقط practiceهای منفرد را ببینید—به‌خصوص practiceهایی که مستقیماً روی کار خودتان اثر دارند—فقط بخش کوچکی از اجایل را دیده‌اید. فیل اجایل از practiceهای روزمره ساخته شده، اما بسیار بزرگ‌تر از آن‌هاست.

شکل 2-4 — «فیل» اجایل بزرگ‌تر از مجموع practiceهایش است.

تیمی که اعضایش فقط practice را می‌بینند و به principles فکر نمی‌کنند، interactionهای مهم میان انسان‌ها را از دست می‌دهد. perspective تکه‌تکه باقی می‌ماند؛ اعضا جدا می‌مانند و واقعاً به‌عنوان واحدی مؤثر عمل نمی‌کنند. کار انجام می‌شود، اما interaction و collaboration فوق‌العاده‌ای که اجایل را قدرتمند می‌کند از دست می‌رود.

این موضوع از همان ابتدا در خود اجایل تعبیه شده است. نخستین value Agile Manifesto را دوباره ببینید: «افراد و تعاملات، مهم‌تر از فرایندها و ابزارها.» process، methodology و tool همچنان مهم‌اند—به همین دلیل Manifesto می‌گوید موارد سمت راست value دارند—اما individuals و interactions مهم‌ترند. همین valueها همراه ۱۲ principle فصل ۳ نشان می‌دهند practiceها چگونه با هم کار می‌کنند و راهنمای team در پذیرش آن‌ها هستند.

متدولوژی‌ها کمک می‌کنند همه‌چیز را یک‌جا مستقر کنید

میان فهم valueهای Agile Manifesto و principles پشت آن، با تغییر واقعی نحوهٔ ساخت software فاصلهٔ بزرگی وجود دارد. خوشبختانه جنبهٔ مهم دیگری از agile development دقیقاً برای همین فاصله وجود دارد: agile methodologyهایی که با هدف کمک به team برای پذیرش اجایل و بهبود project ساخته شده‌اند.

agile methodology ارزش دارد چون practiceها را در context نشان می‌دهد، به‌ویژه برای teamهایی که همهٔ practiceها را نمی‌شناسند. هر methodology طی سال‌ها توسط expertهایی توسعه و اصلاح شده که به تمام بخش‌های «فیل» توجه کرده‌اند. پذیرش کامل یک methodology یعنی دنبال‌کردن مسیر آزموده‌شده‌ای از آغاز تا پایان project، بدون trial and errorی که می‌تواند fractured perspective ایجاد کند.

agile methodology مجموعه‌ای از practiceهاست که با idea، advice و اغلب body of knowledge و تجربهٔ جمعی practitionerها ترکیب می‌شود. methodology نقش‌ها و responsibilityهای مختلف افراد را مشخص می‌کند و practiceهای مناسب هر نقش در مرحله‌های مختلف پروژه را پیشنهاد می‌دهد.

در نتایج State of Agile Development 2013، Scrum محبوب‌ترین methodology است و hybrid Scrum+XP بعد از آن قرار دارد. پاسخ‌دهندگان Lean و Kanban را هم گزارش کرده‌اند؛ این دو methodology اجایل نیستند، اما همان‌طور که در فصل‌های ۸ و ۹ خواهید دید بخش مهمی از جهان اجایل هستند.

Alistair Cockburn در Agile Software Development: The Cooperative Game، ویرایش دوم، Scrum را چنین خلاصه می‌کند—هرچند برای اجرای واقعی این خلاصه کافی نیست:

• team و project sponsorها فهرستی priorityبندی‌شده از همهٔ کارهای لازم می‌سازند؛ task یا feature. این فهرست product backlog نام دارد.
• هر ماه team بخش بالایی list را که تقریباً یک ماه work برآورد می‌شود برمی‌دارد و آن را به task list جزئی‌تر یعنی sprint backlog تبدیل می‌کند. team قول می‌دهد پایان ماه result را demo یا deliver کند.
• هر روز team پنج تا ده دقیقه face-to-face meeting دارد تا status و roadblockها را با هم به‌روز کند؛ daily standup.
• یک نفر Scrum Master می‌شود و مسئولیت دارد roadblockهایی را که در standup مطرح شده حذف کند یا حذفشان را پیگیری کند.

پاورقی 9 — Alistair Cockburn، Agile Software Development: The Cooperative Game، ویرایش دوم، Addison Wesley، 2006.

برای بسیاری از تیم‌هایی که مهاجرت به اجایل را آغاز می‌کنند، Scrum به practiceهای مشخص زیر ترجمه می‌شود:

• product owner، product backlog یعنی list requirements را ایجاد و نگهداری می‌کند.
• team sprintهای timeboxed یک‌ماهه اجرا می‌کند و work یک ماه را از product backlog برای build، test و demo می‌کشد. requirementهای sprint جاری sprint backlog نام دارند. بعضی teamها sprint دو یا چهار هفته‌ای دارند.
• team daily standup برگزار می‌کند و هرکس دربارهٔ کار دیروز، plan امروز و obstacleهای سر راه صحبت می‌کند.
• Scrum Master به‌عنوان leader، coach و shepherd تیم را در project هدایت می‌کند.

اما پذیرش Scrum بیش از پذیرش همین practiceهای خوب است. تک‌تک آن‌ها می‌توانند به شکلی استفاده شوند که value و principleهای اجایل را منعکس نکند. daily standup وقتی team از آن برای collaboration و حرکت project استفاده کند بسیار خوب است، اما می‌تواند به جلسه‌ای هم تبدیل شود که project manager assignment هر شخص را اعلام کند و status را تک‌تک بگیرد. developer هم فقط بگوید: «این obstacleها جلوی من‌اند؛ تو برو حلشان کن.» اگر هرکس به role خود بچسبد—«این مسئولیت توست، نه من»—هر obstacle به problem فرد دیگری تبدیل می‌شود. meeting به contract-like negotiation بدل می‌شود، نه opportunity برای collaboration. چنین تیمی شاید practiceهای شبیه Scrum گرفته باشد، اما Scrum را اجرا نمی‌کند.

methodology دوم eXtreme Programming یا XP است. James Shore و Shane Warden در The Art of Agile Development آن را چنین خلاصه می‌کنند: «با phaseهای هم‌زمان، تیم XP هر هفته software قابل‌deploy تولید می‌کند. در هر iteration، team subsetای از featureها را analyze، design، code، test و deploy می‌کند.» بسیاری از تیم‌های XP iteration یک‌هفته‌ای دارند و بعضی دو هفته یا یک ماه. Scrum هم قابل تطبیق با طول iterationهای دیگر است.

XP practiceهای مشخص development برای بهبود collaboration با user، planning، development و testing تجویز می‌کند. اما از این هم فراتر می‌رود و با همین practiceها به team کمک می‌کند designهای ساده و flexible بسازد که نگهداری و گسترششان آسان است.

Scrum و XP اشتراک‌های زیادی دارند، از جمله iterative بودن. project به iterationهایی تقسیم می‌شود که team در هر کدام تمام activityهای یک پروژهٔ کامل را انجام می‌دهد تا پایان iteration working و deployable software داشته باشد. بسیاری از تیم‌های XP iteration یک‌هفته‌ای و بسیاری از تیم‌های Scrum iteration یک‌ماهه دارند. محدودکردن مدت iteration timeboxing نام دارد و کمک می‌کند user بداند feature جدید چه زمانی تحویل می‌شود.

بسیاری از تیم‌ها پذیرش methodology کامل—به‌خصوص Scrum یا XP—را مؤثرتر از پذیرش practiceهای منفرد می‌دانند. پذیرش منفرد به هر عضو اجازه می‌دهد practiceهای نزدیک به job خودش را بردارد، اما methodology کامل team را مجبور می‌کند با هم بنشینند و تصمیم بگیرند چگونه همهٔ practiceها را به‌عنوان یک team بپذیرند. برای این کار باید شیوهٔ فکرکردن دربارهٔ job تغییر کند. methodologyها حول value و principleهای اجایل ساخته شده‌اند، پس این تغییر attitude معمولاً به سمت collaboration و interaction، working software و responding to change است.

این transition با کتاب‌ها و knowledge جمع‌آوری‌شده توسط practitionerهای دیگر و communityهای شکل‌گرفته حول methodology آسان‌تر می‌شود.

Lean یک methodology نیست، بلکه نام یک mindset است؛ valueها و thinking toolهای خودش را دارد. Lean در دنیای اجایل به اندازهٔ XP و Scrum مهم است و با فهم مشترکات این سه می‌توان معنی اجایل را بهتر فهمید. Kanban یک agile method برای بهبود نحوهٔ ساخت software است که بر valueهای Lean ساخته شده و practiceهای خودش را برای improvement و evolution دارد.

practice و focus XP با Scrum متفاوت است و Lean و Kanban رویکرد سومی دارند. چگونه ممکن است focus و practiceهایشان متفاوت باشد اما همه اجایل باشند؟ چون همه بر همان principleهای بنیادی تکیه دارند و از همهٔ اعضای team می‌خواهند با هم کار کنند و نسبت به تمام جنبه‌های project ownership جمعی داشته باشند. valueها و principleهای Agile Manifesto چیزی است که methodologyها و methodهای مختلف را به هم پیوند می‌دهد.

شکل 2-5 — Scrum، XP و Lean همگی valueهای اجایل را در هسته دارند و بخشی از valueها، ideaها و practiceها را با یکدیگر به اشتراک می‌گذارند.

برای یک متدولوژی جدید از کجا شروع کنیم؟

وقتی همه برای goal واحد پذیرش methodology گرد هم می‌آیند، افراد شروع می‌کنند دربارهٔ practice، idea و perspectiveهای همدیگر حرف بزنند. این نقطهٔ مقابل fractured perspective است. با نگاه به methodology به‌عنوان یک whole، team کم‌کم interaction میان practiceهای مختلف را می‌فهمد. Bruce، Dan، Joanna و Tom می‌خواهند به همین نقطه برسند اما دقیقاً نمی‌دانند چگونه.

وقتی ابتدا practiceها و ideaهای تازه را امتحان کردند هنوز نمی‌فهمیدند رابطهٔ آن‌ها با practiceهای آشنای قبلی چیست. این understanding با experience بیشتر در methodology به دست می‌آید. دلیلش این است که agile methodology یک system کامل از practiceهایی است که می‌دانیم خوب با هم interaction دارند و teamهای واقعی برای productiveترشدن از آن‌ها استفاده کرده‌اند. پذیرش مجموعهٔ کامل practiceها foundation لازم برای یادگیری همین interactionها را می‌دهد.

بااین‌حال پذیرش methodology کامل سخت‌تر از cherry-pick کردن practiceهایی است که با روش فعلی کار سازگارند. اگر team بتواند methodology را یکجا بپذیرد شانس بسیار بیشتری دارد حداکثر benefit را بگیرد، چون علاوه بر practiceهای آشنا، practiceها و ideaهایی را هم می‌پذیرد که شاید اول فکر نکند نیازشان دارد.

تیم jukebox مشکل پیدا کرد چون Bruce، Dan، Joanna و Tom مستقل از هم به practiceها نزدیک شدند. برای گرفتن بیشترین benefit در آینده، پیش از شیرجه‌زدن داخل practiceها باید کنار هم بنشینند و دربارهٔ اینکه هر practice برای team و project چه می‌کند گفت‌وگوی واقعی داشته باشند. اما مشکل این است که نمی‌دانند گفت‌وگو را از کجا شروع کنند. مثل بسیاری از تیم‌ها در dilemma قرار دارند: اگر از قبل می‌دانستند practiceهای اجایل چه می‌کنند و چگونه باید با هم اجرا شوند، اصلاً به این گفت‌وگو نیاز نداشتند؛ ولی چون نمی‌دانند، خود گفت‌وگو سخت می‌شود.

راه‌حل وجود دارد: ۱۲ principle که کنار valueهای Agile Manifesto قرار دارند. فصل ۳ دربارهٔ آن‌هاست.

نکات کلیدی

• تیمی که فقط practiceهای منفرد را می‌بیند ممکن است goal بزرگ‌تر یعنی communication بهتر و responding to change را فراموش کند.
• agile methodology مجموعه‌ای از practiceها همراه با idea، advice و community practitionerهاست.
• methodologyهایی مثل Scrum و XP و رویکردی مثل Lean practiceهای عالی دارند، اما هم‌زمان بر ideaهایی تأکید می‌کنند که team را روی goalهای اصلی متمرکز نگه می‌دارند.
• agile coachها اغلب از metaphor به‌عنوان ابزار یادگیری team استفاده می‌کنند.

پرسش‌های متداول

وقتی Agile Manifesto می‌گوید comprehensive documentation در اولویت نیست، یعنی لازم نیست چیزی بنویسیم؟

این پرسش بسیار رایج است. متن Manifesto می‌گوید «working software را بیش از comprehensive documentation ارزش می‌نهیم.» این به این معنا نیست که practitioner اجایل documentation جامع را بی‌ارزش می‌داند و قطعاً به این معنا نیست که هیچ documentationای نباید نوشته شود. documentation مفید فراوانی وجود دارد که لازم نیست «comprehensive» باشد.

معنا این است که گذاشتن working software در دست user بهترین راه برای نشان‌دادن progress team است. در عین حال جا برای نوشتن هم وجود دارد. code با comment document می‌شود، مثلاً برای توضیح اینکه چرا تصمیمی گرفته شده یا چرا algorithm دیگری استفاده نشده است. بعداً user story را به‌عنوان نوع خاصی از documentation می‌بینید که معمولاً روی index card نوشته می‌شود و به team، user و stakeholder کمک می‌کند دقیقاً بفهمند چه چیزی قرار است ساخته شود. انواع دیگری هم وجود دارند؛ بعضی جامع‌تر از بقیه.

مطمئنید؟ من شنیده‌ام اجایل یعنی هیچ‌چیز ننویسیم و planning نکنیم و مستقیم programming را شروع کنیم. این کار efficientتر نیست؟

یکی از رایج‌ترین mythهای agile software development این است که تیم‌های اجایل plan ندارند. در واقع بسیاری از آن‌ها planning بسیار کامل‌تری از تیم‌های سنتی انجام می‌دهند. اما از بیرون شاید planning کم به نظر برسد، چون کل team درگیر است و کسی از دعوت به planning meeting ناله نمی‌کند.

مثلاً team Scrum معمولاً یک روز کامل هشت‌ساعته برای planning یک iteration سی‌روزه صرف می‌کند. بعد meeting روزانه—اغلب timebox پانزده دقیقه—دارد که plan را با هم review می‌کنند. برای تیم پنج‌نفره، این یعنی ۴۰ person-hour planning در ابتدا و حدود ۴۰ person-hour دیگر در سی روز آینده؛ بسیار بیشتر از planning بسیاری از تیم‌های سنتی برای سی روز development. عجیب نیست Scrum teamها deadline را خوب رعایت می‌کنند. بااین‌حال برای اعضا حس «planning خسته‌کننده» ندارد چون در process درگیرند، outcome برایشان مهم است و می‌دانند planning باعث بهترشدن iteration خواهد شد.

برای developerای که از بیرون نگاه می‌کند، این ممکن است شبیه پرش مستقیم به project باشد. وقتی team فقط روز اول iteration سی‌روزه را صرف planning می‌کند، روز دوم می‌تواند programming را شروع کند. از بیرون planning بسیار کم به نظر می‌رسد، هرچند مجموع effort-hour نشان می‌دهد مقدار زیادی planning انجام شده است.

آیا این یعنی اجایل فقط برای developerهای بسیار باتجربه و خوب در planning است؟

نه. اجایل برای افراد همهٔ skill levelهاست. planning یک skill است و تنها راه بهترشدن تمرین است. حتی developerهای باتجربه هم estimate را گاهی—و در واقع اغلب—اشتباه می‌کنند. نمونه‌های واقعی بسیاری از teamهای junior دیده شده که به‌خوبی اجایل شده‌اند و softwareای بسیار فراتر از انتظار company تحویل داده‌اند. فقط یک caveat وجود دارد: junior developer در team اجایل مؤثر معمولاً مدت زیادی junior نمی‌ماند؛ شاید همین باعث شده بعضی‌ها فکر کنند اجایل فقط برای experiencedهاست.

آیا می‌توانم فقط developerها را اجایل کنم و بقیهٔ تیم—tester، business analyst، UX designer، project manager و...—را دست‌نخورده بگذارم؟

بله، می‌توانید؛ اما احتمالاً خیلی مؤثر نیست. وقتی گفته می‌شود «فقط developerها اجایل شوند»، معمولاً یعنی آن‌ها چند practice از یک methodology را می‌پذیرند. productivity خودشان بهتر می‌شود و همین ارزش انجام‌دادن دارد، یعنی همان better-than-not-doing-it. اما چون team شیوهٔ فکرکردن دربارهٔ project را تغییر نداده، positive impact تفکر اجایل به‌شدت محدود می‌شود و team ممکن است وارد سناریوی Water-Scrum-Fall شود که پذیرش اجایل را خالی یا ناقص حس می‌کند.

اگر Scrum، XP، Lean یا Kanban استفاده نکنم یعنی team من اجایل نیست؟

قطعاً نه. agile methodologyهای زیادی وجود دارد. این کتاب روی چند مورد تمرکز کرده چون آن‌ها را برای آموزش ideaهای پشت اجایل به کار می‌گیرد. مهم‌تر اینکه goal کتاب این است که کمک کند خودتان جواب دهید «agile واقعاً یعنی چه؟» با مطالعهٔ value و practiceهای methodology و methodهای مختلف خواهید فهمید چرا رویکردهای بسیار متفاوت می‌توانند همگی اجایل باشند، حتی اگر ظاهرشان شبیه هم نباشد.

کارهایی که همین امروز می‌توانید انجام دهید

• فهرستی از همهٔ practiceهایی بنویسید که شما و team هنگام ساخت software استفاده می‌کنید؛ مثل نوشتن specification، check-in code در version control، استفاده از Gantt chart برای plan یا daily standup.
• از فرد دیگری در team بخواهید فهرست خودش را بنویسد. دو list را مقایسه کنید. چه practiceهایی فقط در یکی هستند؟ دربارهٔ آن practice گفت‌وگو کنید و ببینید آیا تفاوت perspective میان شما وجود دارد.

کجا بیشتر یاد بگیریم؟

• دربارهٔ valueها و principleهای اجایل: Agile Software Development: The Cooperative Game، ویرایش دوم، Alistair Cockburn، Addison-Wesley، 2006.
• دربارهٔ رابطهٔ principles و practices: Agile Project Management: Creating Innovative Projects، Jim Highsmith، Addison-Wesley، 2009.
• دربارهٔ agile coaching: Coaching Agile Teams، Lyssa Adkins، Addison-Wesley، 2010.

نکته‌های مربیگری

برای agile coachهایی که به team کمک می‌کنند ایده‌های فصل را اجرا کند:

• هنگام coaching team جدید، جداگانه با افراد صحبت کنید و تلاش کنید تفاوت perspective میان roleهای مختلف را بفهمید.
• مشخصاً دربارهٔ valueهای Agile Manifesto از افراد بپرسید: چه نظری دارند، کدام را مهم می‌دانند، و آیا فکر می‌کنند اصلاً این valueها به خودشان مربوط است؟
• teamها اغلب حس می‌کنند فقط better-than-not-doing-it گرفته‌اند اما نمی‌توانند این حس را خوب بیان کنند. concept را مستقیم مطرح کنید و از افراد مثال‌هایی از practiceهای «خالی» یا پرزحمت و کم‌بازده بخواهید.
• دربارهٔ یک value یا principle مشخص گفت‌وگو را شروع کنید. مثلاً اگر team دربارهٔ «contract» با user حرف می‌زند، از آن برای بحث contract negotiation در برابر customer collaboration استفاده کنید و کمک کنید نقاطی را ببینند که واقعاً در حال انتخاب‌کردن هستند.

این صفحه ادامهٔ بخش پایانی فصل و انتقال به فصل بعد را تشکیل می‌دهد؛ متن اصلی از منابع و coaching tipهای بالا فراتر از موارد ترجمه‌شده، محتوای آموزشی مستقل جدیدی ندارد.

صفحهٔ پایانی فصل ۲ و فضای انتقال به فصل ۳؛ محتوای آموزشی مستقل تازه‌ای در استخراج متن دیده نمی‌شود.

صفحهٔ قبل از آغاز فصل ۳؛ ادامهٔ فصل بعد در مقالهٔ بعدی ارائه می‌شود.