فصل ۱: یادگیری اجایل
صفحهٔ PDF 21
«مهمترین نگرشی که میتوان شکل داد، میل به ادامهدادن یادگیری است.» — John Dewey، Experience and Education
زمان هیجانانگیزی برای اجایل بودن است! برای نخستین بار، صنعت ما راهی واقعی و پایدار برای حل مشکلاتی یافته است که نسلهای مختلف تیمهای توسعهٔ نرمافزار با آنها درگیر بودهاند. فقط چند نمونه از وعدههایی که اجایل میدهد اینها هستند:
- پروژههای اجایل بهموقع به پایان میرسند؛ خبری عالی برای تیمهایی که با تحویل بسیار دیرهنگام و بودجههای بهشدت فراتررفته دستوپنجه نرم کردهاند.
- پروژههای اجایل نرمافزار باکیفیت تحویل میدهند؛ تغییری بزرگ برای تیمهایی که درگیر نرمافزارهای پرخطا و ناکارآمد بودهاند.
- کدی که تیمهای اجایل میسازند خوب ساختاربندی شده و نگهداشتپذیری بالایی دارد؛ آسودگی بزرگی برای تیمهایی که به نگهداری کد اسپاگتی پیچیده و درهمتنیده عادت کردهاند.
- تیمهای اجایل کاربرانشان را خوشحال میکنند؛ تفاوتی عظیم با نرمافزاری که در رساندن ارزش به کاربران شکست میخورد.
- و بهتر از همه، توسعهدهندگان یک تیم اجایل مؤثر با ساعات کاری عادی کار میکنند و میتوانند شبها و آخر هفتهها را با دوستان و خانوادهشان بگذرانند؛ شاید برای نخستین بار در زندگی حرفهایشان.
اجایل محبوب است چون بسیاری از تیمهایی که «اجایل شدهاند» نتایج بسیار خوبی گزارش میکنند: نرمافزار بهتر میسازند، بهتر با هم کار میکنند، کاربران را راضیتر نگه میدارند و همهٔ این کارها را در محیط کاری بسیار آرامتر و لذتبخشتری انجام میدهند. بعضی تیمهای اجایل بالاخره در حل مشکلاتی که دههها تیمهای نرمافزاری را گرفتار کرده بود پیشرفت واقعی داشتهاند. اما تیمهای عالی دقیقاً چگونه از اجایل برای ساخت نرمافزار بهتر استفاده میکنند؟ و مشخصتر، شما چگونه میتوانید با اجایل به چنین نتایجی برسید؟
صفحهٔ PDF 22
در این کتاب با دو متدولوژی محبوب اجایل، Scrum و Extreme Programming یا XP آشنا میشوید. همچنین Lean و Kanban را یاد میگیرید و میبینید چگونه به شما کمک میکنند شیوهٔ ساخت نرمافزار امروزتان را بفهمید و فردا آن را به وضعیت بهتری تکامل دهید. هرچند این چهار مکتب فکری اجایل روی حوزههای متفاوت توسعهٔ نرمافزار تمرکز دارند، یک ویژگی مهم مشترک دارند: همه روی تغییر ذهنیت تیم تمرکز میکنند.
همین تغییر ذهنیت است که تیم را از افزودن سطحی چند practice نمادین اجایل، به تیمی میرساند که واقعاً نحوهٔ ساخت نرمافزارش را بهبود داده است. هدف این کتاب این است که هر دو روی سکهٔ اجایل را یاد بگیرید: practiceهایی که کار روزمره را میسازند، و ارزشها و اصولی که کمک میکنند شما و تیمتان طرز فکر بنیادی خود دربارهٔ ساخت نرمافزار را تغییر دهید.
اجایل چیست؟
اجایل مجموعهای از روشها و متدولوژیهاست که به تیم شما کمک میکند مؤثرتر فکر کند، کارآمدتر کار کند و تصمیمهای بهتری بگیرد.
این روشها و متدولوژیها تمام حوزههای مهندسی نرمافزار سنتی، از جمله مدیریت پروژه، طراحی و معماری نرمافزار و بهبود فرایند را در بر میگیرند. هر روش و متدولوژی از practiceهایی تشکیل شده که سادهسازی و بهینه شدهاند تا بهکارگیریشان تا حد ممکن آسان باشد.
اجایل همچنین یک ذهنیت است، زیرا ذهنیت درست میتواند تفاوت بزرگی در میزان اثربخشی استفادهٔ تیم از practiceها ایجاد کند. این ذهنیت به افراد تیم کمک میکند اطلاعات را با هم به اشتراک بگذارند تا تصمیمهای مهم پروژه را با هم بگیرند، نه اینکه مدیری همهٔ تصمیمها را بهتنهایی بگیرد. ذهنیت اجایل یعنی بازکردن برنامهریزی، طراحی و بهبود فرایند به روی کل تیم. تیم اجایل practiceها را طوری به کار میگیرد که همه اطلاعات یکسانی داشته باشند و هر عضو تیم دربارهٔ نحوهٔ اجرای practiceها حق اظهارنظر داشته باشد.
واقعیت اجایل برای بسیاری از تیمهایی که موفقیت زیادی به دست نیاوردهاند، با وعدهٔ آن تفاوت دارد و کلید این تفاوت اغلب همان ذهنیتی است که تیم به هر پروژه میآورد. بیشتر شرکتهایی که نرمافزار میسازند اجایل را آزمایش کردهاند. بسیاری موفق شدهاند، اما بعضی تیمها نتایجی کمتر از انتظار گرفتهاند. آنها در نحوهٔ اجرای پروژهها مقداری بهبود ایجاد کردهاند—آنقدر که تلاش برای پذیرش اجایل ارزش داشته باشد—اما تغییرات بنیادینی را که احساس میکردند اجایل وعده داده بود ندیدهاند. تمام بحث «تغییر ذهنیت» همین است؛ «اجایل شدن» یعنی کمک به تیم برای پیدا کردن یک ذهنیت مؤثر.
اما «تغییر ذهنیت» واقعاً یعنی چه؟ اگر عضو یک تیم نرمافزاری باشید، کار روزانهتان برنامهریزی، طراحی، ساخت و تحویل نرمافزار است. ذهنیت چه ربطی به اینها دارد؟ مشخص میشود practiceهایی که برای کار روزانه استفاده میکنید وابستگی زیادی به نگرشی دارد که شما و همتیمیهایتان نسبت به آن practiceها دارید.
صفحهٔ PDF 23
تصویر منبع - صفحهٔ PDF 23
مثالی بزنیم. یکی از رایجترین practiceهای اجایل که تیمها میپذیرند daily standup است؛ جلسهای که اعضای تیم در آن دربارهٔ کاری که انجام میدهند و چالشهایشان صحبت میکنند. برای کوتاهماندن جلسه، همه در طول آن ایستاده میمانند. تیمهای زیادی با افزودن daily standup به پروژههایشان موفقیت چشمگیری داشتهاند.
تصور کنید یک مدیر پروژه تازه دربارهٔ اجایل یاد گرفته و میخواهد daily standup را به پروژهاش اضافه کند. برخلاف انتظارش، همهٔ اعضای تیم به اندازهٔ او از این practice جدید هیجانزده نیستند. یکی از توسعهدهندگان حتی از پیشنهاد جلسهٔ تازه عصبانی است و ظاهراً از این ایده که هر روز در جلسهای حاضر شود و دربارهٔ جزئیات کار روزانهاش پرسشهای ریز و مداخلهگرانه بشنود احساس توهین میکند.
شکل 1-1 — مدیر پروژهای که میخواهد تیم برگزاری daily standup را آغاز کند، از اینکه همه بلافاصله با ایده همراه نیستند غافلگیر میشود.
اینجا چه اتفاقی افتاده است؟ آیا توسعهدهنده غیرمنطقی است؟ آیا مدیر پروژه بیش از حد مطالبهگر است؟ چرا چنین practice ساده و پذیرفتهشدهای باعث تعارض میشود؟ مدیر پروژه و توسعهدهنده هر دو دیدگاههایی متفاوت، اما معتبر، دارند. یکی از بزرگترین چالشهای مدیر پروژه این است که برای برنامهریزی پروژه تلاش زیادی میکند، اما وقتی تیم در ساخت نرمافزار با مشکل روبهرو میشود از برنامه منحرف میشود. او مجبور است سخت تلاش کند تا از وضعیت همهٔ افراد مطلع بماند، برنامه را تنظیم کند و به آنها در حل مشکلات کمک کند.
صفحهٔ PDF 24
تصویر منبع - صفحهٔ PDF 24
از سوی دیگر، توسعهدهنده احساس میکند روزی چند بار با جلسهها کارش قطع میشود و همین انجام کار واقعی را بسیار دشوار میکند. او از قبل میداند برای ساخت کد خودش چه باید بکند و به فرد دیگری نیاز ندارد که دائماً دربارهٔ برنامهها و تغییرات به او فشار بیاورد. فقط میخواهد تنها گذاشته شود تا کدنویسی کند؛ آخرین چیزی که میخواهد یک جلسهٔ دیگر است.
شکل 1-2 — هر دو نفر ظاهراً دلیل معتبری برای نگرش خود نسبت به جلسهٔ daily standup دارند. این وضعیت چه اثری بر پروژه خواهد گذاشت؟
حالا تصور کنید مدیر پروژه بتواند همه، حتی همین توسعهدهندهٔ بیمیل، را وادار کند در daily standup شرکت کنند. جلسه چه شکلی خواهد شد؟ مدیر پروژه عمدتاً به این فکر میکند که افراد چگونه از برنامهٔ او منحرف شدهاند، بنابراین تمرکزش بر گرفتن status از تکتک افراد خواهد بود. توسعهدهنده هم میخواهد جلسه هرچه سریعتر تمام شود؛ پس تا نوبتش برسد به حرف دیگران توجهی نمیکند، هنگام نوبت خودش کمترین مقدار ممکن را میگوید و امیدوار است کل ماجرا زود تمام شود.
روشن بگوییم: بسیاری از daily standupها دقیقاً همینگونه برگزار میشوند. این حالت بهینه نیست، اما چنین جلسهای باز هم نتیجه ایجاد میکند. مدیر پروژه از مشکلات برنامهاش مطلع میشود و توسعهدهنده در بلندمدت سود میبرد، زیرا مشکلاتی که بر او اثر میگذارند زودتر رسیدگی میشوند. در مجموع این practice معمولاً بیش از زمانی که میگیرد، در وقت و تلاش تیم صرفهجویی میکند؛ بنابراین ارزش انجامدادن دارد.
صفحهٔ PDF 25
اما اگر توسعهدهنده و مدیر پروژه ذهنیت متفاوتی داشتند چه میشد؟ اگر همهٔ افراد تیم با نگرشی کاملاً متفاوت وارد daily standup میشدند چه؟
مثلاً اگر مدیر پروژه احساس میکرد همهٔ اعضای تیم با هم پروژه را برنامهریزی کردهاند، واقعاً به هر عضو گوش میداد؛ نه فقط برای اینکه بفهمد از برنامهٔ خودش چقدر منحرف شدهاند، بلکه برای اینکه درک کند برنامهای که کل تیم با هم ساخته ممکن است چگونه نیاز به تغییر داشته باشد. بهجای دیکتهکردن برنامه، تحویل آن به تیم و اندازهگیری میزان تبعیت تیم، او اکنون همراه تیم بهترین شیوهٔ پیشبرد پروژه را پیدا میکند. در این حالت daily standup به ابزاری برای همکاری تبدیل میشود تا مطمئن شوند هرکس در هر لحظه مؤثرترین کار ممکن را انجام میدهد. با تغییر واقعیتهای پروژه در هر روز، تیم از جلسهٔ روزانه برای گرفتن مؤثرترین تصمیمهای ممکن به صورت جمعی استفاده میکند. و چون هر روز جلسه دارند، تغییراتی که کشف میکنند فوراً اجرا میشود و از تلفشدن زمان و انرژی در مسیر اشتباه جلوگیری میکند.
اگر توسعهدهنده هم احساس میکرد این جلسه فقط برای status دادن نیست، بلکه برای فهم وضعیت پروژه و گردهمآمدن روزانه بهمنظور پیدا کردن راههای بهتر کارکردن همه است، daily standup برای او مهم میشد. یک توسعهدهندهٔ خوب تقریباً همیشه نهفقط دربارهٔ کد خودش، بلکه دربارهٔ جهت کل پروژه نظر دارد. جلسهٔ روزانه راهی میشود تا مطمئن شود پروژه منطقی و کارآمد پیش میرود؛ او میداند در بلندمدت این وضعیت کار کدنویسی خودش را هم رضایتبخشتر میکند، چون بقیهٔ پروژه درست مدیریت میشود. همچنین میداند اگر در جلسه مشکلی در برنامه مطرح کند، همه گوش میدهند و پروژه به دلیل آن بهتر پیش خواهد رفت.
شکل 1-3 — وقتی هر فرد تیم احساس کند سهمی برابر در برنامهریزی و ادارهٔ پروژه دارد، daily standup ارزشمندتر و بسیار مؤثرتر میشود.
به بیان دیگر، اگر ذهنیت تیم این باشد که daily standup صرفاً جلسهٔ status است که باید تحمل شود، انجامش همچنان مفید است، اما فقط اندکی بهتر از جلسهٔ status سنتی خواهد بود. اما اگر همه باور داشته باشند این جلسه راهی است برای اطمینان از اینکه همه در مسیرند، به سمت هدفی مشترک کار میکنند و دربارهٔ نحوهٔ ادارهٔ پروژه حق اظهارنظر دارند، جلسه بسیار مؤثرتر و رضایتبخشتر میشود. توسعهدهنده میبیند این جلسه در بلندمدت به خودش و تیم کمک میکند. مدیر پروژه باور دارد مشارکت هر عضو در برنامه نتایج پروژه را بهتر میکند. وقتی این نگرشها مشترک شوند، daily standup به همه کمک میکند سریعتر کار کنند، مستقیمتر ارتباط بگیرند و کارها را آسانتر پیش ببرند.
این فقط یک مثال کوچک از اثری است که ذهنیت و نگرش تیم بر موفقیت پذیرش practiceهای اجایل میگذارد. یکی از اهداف مهم کتاب این است که کمک کند بفهمید ذهنیت تیم خودتان چگونه بر پروژهها و پذیرش اجایل اثر میگذارد. با بررسی Scrum، XP، Lean و Kanban هر دو سوی سکهٔ اجایل—اصول و practiceها—و نحوهٔ ترکیب آنها برای ساخت نرمافزار بهتر را یاد میگیرید.
صفحهٔ PDF 26
تصویر منبع - صفحهٔ PDF 26
چه کسانی باید این کتاب را بخوانند؟
آیا یکی از موقعیتهای زیر شما و تیمتان را توصیف میکند؟
یک practice اجایل را امتحان کردید اما واقعاً جواب نداد. شاید daily standup راه انداختید و حالا هر روز جلسه دارید، اما هنوز مشکلات غافلگیرتان میکند و deadlineها را از دست میدهید. یا user story مینویسید و با تیم و ذینفعان مرور میکنید، اما توسعهدهندگان همچنان درست مثل قبل با تغییرات دقیقهٔ آخری و درخواست قابلیتهای اضافی روبهرو میشوند. شاید هم کل تیم تلاش کرده با پذیرش متدولوژیای مثل Scrum یا XP اجایل شود، اما همهچیز somehow «توخالی» به نظر میرسد؛ انگار همه حرکات «الزامی» را انجام میدهند ولی پروژهها فقط اندکی بهتر شدهاند.
یا شاید هنوز اجایل را امتحان نکردهاید اما میبینید تیمتان با چالشهای جدی روبهروست و نمیدانید از کجا شروع کنید. امیدوارید اجایل با کاربران سختگیری که دائماً نظرشان را عوض میکنند کمک کند. هر تغییر کاربر، کار بیشتری برای تیم میسازد و به راهحلهای «چسب نواری و گیرهٔ کاغذ» و کد اسپاگتی منجر میشود که نرمافزار را شکنندهتر و نگهداشتناپذیرتر میکند. شاید پروژههایتان صرفاً آشوب کنترلشدهاند؛ نرمافزار عمدتاً با ساعتهای کاری طولانی و قهرمانبازی شخصی تحویل میشود و فکر میکنید اجایل راه خروجی برای تیم فراهم میکند.
اگر مدیر ارشدی باشید که نگران است تیمهای پروژههای مهم در تحویل شکست بخورند چه؟ شاید دربارهٔ اجایل شنیدهاید اما دقیقاً نمیدانید چیست. آیا کافی است به تیم دستور دهید اجایل را بپذیرد؟ یا خود شما هم باید همراه تیم ذهنیتتان را تغییر دهید؟
اگر هر یک از این موقعیتها برایتان آشناست و میخواهید نحوهٔ کار تیم را بهتر کنید، این کتاب کمک خواهد کرد.
ما متدولوژیهای اجایل را توضیح میدهیم: چرا به این شکل طراحی شدهاند، چه مشکلاتی را هدف میگیرند و چه ارزشها، اصول و ایدههایی را نمایندگی میکنند. با ارائهٔ «چرایی» در کنار «چگونگی»، کمک میکنیم اصولی را تشخیص دهید که به مشکلات توسعهٔ خاص تیم، شرکت و پروژههای شما مربوطاند. سپس نشان میدهیم چگونه از این اطلاعات برای انتخاب متدولوژیها و practiceها استفاده کنید.
گروه دیگری هم هست که این کتاب برای او نوشته شده: مربی اجایل (Agile Coach). تیمها و شرکتها بیش از پیش برای هدایت پذیرش متدولوژیها و practiceهای اجایل و قرار دادن هر عضو در ذهنیت درست، به مربیان اجایل تکیه میکنند. اگر مربی اجایل هستید، ابزارهایی دریافت میکنید تا این ایدهها را بهتر به تیم منتقل کنید و بر چالشهای روزمرهٔ کمک به اجایلترشدن تیم غلبه کنید.
صفحهٔ PDF 27
اهداف ما برای این کتاب
آنچه برای شما میخواهیم:
- میخواهیم ایدههایی را بفهمید که تیمهای اجایل مؤثر را به حرکت درمیآورند و ارزشها و اصولی را درک کنید که آنها را کنار هم نگه میدارند.
- میخواهیم محبوبترین مکاتب فکری اجایل—Scrum، XP، Lean و Kanban—را بشناسید و بفهمید چگونه با وجود تفاوت بسیار زیاد، همگی میتوانند اجایل باشند.
- میخواهیم practiceهای مشخص اجایل را یاد بگیرید که همین امروز روی پروژهها قابل اجرا هستند؛ اما در کنار آن چارچوب ارزشها و اصول لازم برای اجرای مؤثرشان را هم در اختیار داشته باشید.
- میخواهیم تیم و شرکت خودتان را بهتر بشناسید تا بتوانید رویکرد اجایلی انتخاب کنید که با ذهنیت موجودتان سازگار باشد یا تا حد ممکن به آن نزدیک شود؛ و همزمان به شما و تیم کمک کنیم شیوهٔ تازهای از فکرکردن را بیاموزید تا به تیم اجایل مؤثرتری تبدیل شوید.
چگونه تمام متدولوژیها و practiceهای مختلف اجایل نرمافزار بهتری به شما میدهند؟ چرا توانایی تیم برای مدیریت تغییر را افزایش میدهند؟ چرا این چیزها «اجایل» هستند؟ آیا واقعاً مهم است برای برنامهریزی از کارتهای index استفاده کنید یا در جلسه بایستید؟ این پرسشها برای کسانی که تازه مسیر چابکی را آغاز میکنند دشوار و گاه گیجکنندهاند. تا پایان کتاب میتوانید خودتان به آنها پاسخ دهید.
اگر وبلاگها و مقالههای فراوان دربارهٔ توسعهٔ نرمافزار اجایل را نگاه کنید، یکی از نخستین جملهها معمولاً این است: «Agile خوب است و waterfall بد است.» چرا اجایل «خوب» و waterfall «بد» است؟ چرا با هم تعارض دارند؟ آیا میشود در تیمی با فرایند waterfall کار کرد و همچنان اجایل بود؟ تا پایان کتاب پاسخ این پرسشها را هم خواهید داشت.
اجایل را به هر روش لازم وارد مغزتان کنید
نام کتاب Learning Agile است چون واقعاً میخواهیم اجایل را یاد بگیرید. بیش از بیست سال است هر روز با تیمهای واقعی کار کردهایم که برای کاربران واقعی نرمافزار واقعی میسازند. بیش از ده سال هم دربارهٔ ساخت نرمافزار کتاب نوشتهایم، از جمله دو کتاب موفق مجموعهٔ O’Reilly Head First دربارهٔ مدیریت پروژه و یادگیری برنامهنویسی. این تجربه کمک کرده راههای مختلفی پیدا کنیم تا ایدههای پیچیده و فنی را بدون اینکه از شدت کسالت از پا دربیایید وارد ذهنتان کنیم.
تمام تلاشمان را کردهایم این مطالب تا جای ممکن جالب و درگیرکننده باشند، اما به کمک شما هم نیاز داریم. ابزارها و تکنیکهای زیر در سراسر کتاب برای ماندگارشدن ایدهها در ذهن استفاده میشوند.
صفحهٔ PDF 28
روایتها (Narratives)
این بخشها با یک آیکون مخصوص مشخص میشوند. آخرین کتاب فنیای که خواندید به یاد بیاورید؛ آیا همهٔ موضوعات اصلی و ترتیبشان را به خاطر دارید؟ احتمالاً نه. حالا آخرین فیلمی را که دیدید تصور کنید؛ آیا نقاط اصلی داستان و ترتیب رخدادها را به یاد دارید؟ تقریباً حتماً. مغز ما چیزهایی را که واکنش احساسی ایجاد میکنند بهتر به خاطر میسپارد.
در این کتاب از این ویژگی استفاده میکنیم. با روایتهایی شامل آدمها، گفتوگو و تعارض نشان میدهیم مواجههٔ انسانهای واقعی با اجایل چه شکلی است. این آدمها با مشکل روبهرو خواهند شد.
آنچه از شما میخواهیم: سعی کنید خودتان را در موقعیت آنها تصور کنید. این کار پیوندی احساسی با ایدهها میسازد و یادآوری و درکشان را آسانتر میکند. ذهنی باز نسبت به این روایتها داشته باشید، بهخصوص اگر از آن دسته یادگیرندگانی هستید که داستان تخیلی دوست ندارند. در هر روایت یادگیری واقعی وجود دارد و روایتها بخشی از محتوای اصلی کتاباند.
تصویرها (Illustrations)
افراد مختلف به روشهای مختلف یاد میگیرند. بعضیها یادگیرندهٔ دیداری هستند و وقتی تصویر میبینند، ایده برایشان خیلی راحتتر «جا میافتد». میخواهیم تا حد ممکن ابزارهای یادگیری مختلف در اختیار شما بگذاریم، بنابراین تصویرهای زیادی در سراسر کتاب قرار دادهایم. گاهی به استعارهٔ بصری تکیهٔ زیادی میکنیم؛ مثلاً شکلهای هندسی را نمایندهٔ featureهای مختلف میگیریم یا چرخدندهها را برای نمایش نرمافزار پیچیده به کار میبریم.
آنچه از شما میخواهیم: اگر یادگیرندهٔ دیداری نیستید، ممکن است برخی تصویرها ابتدا اضافی به نظر برسند یا فکر کنید تصویر خاصی بیمعناست. این میتواند فرصت یادگیری خوبی باشد. کمی وقت بگذارید و سعی کنید بفهمید یک یادگیرندهٔ دیداری چه چیزی از آن تصویر میگیرد؛ این کار به درک عمیقتر مفهوم کمک میکند.
تکرار (Redundancy)
بیشتر کتابهای فنی یک ایده را معرفی میکنند، کامل توضیح میدهند و سراغ موضوع بعدی میروند. این روش برای جا دادن بیشترین اطلاعات در کتاب مؤثر است، اما مغز ما اینگونه کار نمیکند. گاهی لازم است مفهوم یکسان را بیش از یک بار ببینید تا لحظهٔ «آها!» رخ دهد. به همین دلیل بعضی مفهومها را چند بار در یک فصل یا فصلهای مختلف تکرار میکنیم. این تکرار عمدی است و برای رساندن شما به همان لحظهٔ «آها!» انجام میشود.
آنچه از شما میخواهیم: وقتی برای بار دوم یا سوم با مفهومی روبهرو شدید، ممکن است بگویید «این را قبلاً نگفتند؟» بله، گفتیم؛ و اینکه متوجه شدهاید خیلی خوب است. خوانندگان دیگری ممکن است متوجه تکرار نشوند، همانطور که خود شما هم هر بار متوجه آن نخواهید شد. همهٔ این کارها برای کمک به یادگیری است.
صفحهٔ PDF 29
سادهسازی — در ابتدا
گاهی فهم یک موضوع پیچیده آسانتر است اگر ابتدا فقط سطحش را لمس کنید و فرصت دهید در ذهن جا بیفتد. در این کتاب بارها همین کار را میکنیم: نسخهای سادهشده، اما همچنان از نظر فنی درست، از مفهوم را معرفی میکنیم و بعداً جزئیات را گسترش میدهیم.
این روش در دو سطح کار میکند. اگر ایده را از قبل عمیق میدانید، سادهسازی را تشخیص میدهید و واکنش احساسی نشان میدهید و همین شما را درگیر نگه میدارد. اگر مفهوم برایتان تازه باشد، مقدمهای ملایمتر میسازد تا برای توضیح عمیقتر بعدی آماده شوید.
آنچه از شما میخواهیم: اگر چیزی بیش از حد ساده به نظر رسید، آن را کنار نگذارید و قطعاً فرض نکنید ما یک ایدهٔ اساسی را ندیدهایم یا نکتهٔ مهمی را سطحی رد کرده یا فراموش کردهایم. به احتمال زیاد بعداً همان نکته را پیدا خواهید کرد. میتوانید مقدمهٔ سادهشدهٔ یک مفهوم دشوار را مثل برنامهٔ «Hello, World!» برای مغز تصور کنید: به خوانندهٔ ناآشنا حس پیشرفت میدهد و زمینهٔ درک عمیقتر بعدی را میسازد.
لحن محاورهای و خودمانی
در سراسر کتاب لحن نسبتاً خودمانی نگه داشته شده تا مطالب جذاب باقی بمانند. از شوخی و گاهی ارجاعهای فرهنگی استفاده میکنیم و بعضی وقتها مستقیم با شما حرف میزنیم یا با ضمیرهایی مثل «ما» و «شما» به خودمان و خواننده اشاره میکنیم. پشت این روش حتی پژوهش علمی وجود دارد: پژوهش شناختی نشان میدهد وقتی احساس میکنید در یک گفتوگو هستید، مغز بیشتر به خاطر میسپارد.
آنچه از شما میخواهیم: بیشتر افراد با لحن خودمانی مشکلی ندارند، اما بعضیها واقعاً آن را دوست ندارند. مثلاً برخی خوانندگان با دیدن contractionهای انگلیسی واکنش منفی دارند؛ برای بعضی دیگر لحن خودمانی باعث میشود کتاب به اندازهٔ کافی معتبر به نظر نرسد. این را درک میکنیم. باور کنید یا نه، احتمالاً سریعتر از آنچه فکر میکنید به این لحن عادت خواهید کرد.
نکات کلیدی (Key Points)
این بخش با آیکون مخصوص مشخص میشود. در طول هر فصل، نکات کلیدیای که اخیراً پوشش داده شدهاند خلاصه میشوند. این کمک میکند مطمئن شوید همهچیز را «گرفتهاید» و مفهوم مهمی از دست نرفته است؛ همچنین وقفهٔ کوتاهی برای مغز ایجاد میکند.
پاورقی 1 — اگر میخواهید دربارهٔ اثر لحن محاورهای بر یادگیری بیشتر بدانید، کتاب E-Learning and the Science of Instruction نوشتهٔ Ruth C. Clark و Richard E. Mayer، انتشارات Wiley، 2011 را ببینید.
صفحهٔ PDF 30
آنچه از شما میخواهیم: بخشهای Key Points را صرفاً رد نکنید. یک دقیقه وقت بگذارید و مرورشان کنید. آیا هر نکته را به خاطر دارید؟ اگر نه، از برگشتن چند صفحه و تازهکردن حافظه نترسید.
پرسشهای متداول (Frequently Asked Questions)
این بخش با آیکون مخصوص مشخص میشود. بیشتر وقتمان را واقعاً در تیمهای نرمافزاری و ساخت نرمافزار واقعی برای کاربران واقعی میگذرانیم، اما سالها هم دربارهٔ اجایل سخنرانی و ارائه داشتهایم و با افراد بسیار زیادی حرف زدهایم. در تمام این گفتوگوها، بعضی پرسشها بارها و بارها تکرار شدهاند.
آنچه از شما میخواهیم: FAQهای پایان هر فصل را بخوانید. آیا پرسش خودتان هم بوده؟ اگر بله، پاسخ را میپسندید؟ ممکن است همیشه پاسخ را دوست نداشته باشید، اما سعی کنید حقیقت نهفته در آن را پیدا کنید. اگر پرسش شما نبوده، بفهمید چرا ممکن است شخص دیگری آن را بپرسد؛ این کمک میکند مطالب را از دیدگاهی متفاوت ببینید و در فصل ۲ خواهید دید چرا این موضوع برای تیم مهم است.
کاری که همین امروز میتوانید انجام دهید
این بخش هم با آیکون مخصوص مشخص میشود. مؤثرترین راه یادگیری چیزی، انجامدادن آن است. در پایان هر فصل بخش کوتاهی داریم که چند کار قابل انجام همین امروز، همین حالا، بهتنهایی یا همراه تیم، پیشنهاد میکند.
آنچه از شما میخواهیم: روشن است که بهترین کار واقعاً امتحانکردن آن پیشنهادهاست. اما واقعیت این است که همهٔ تیمها یا شرکتها پذیرای چنین چیزهایی نیستند. یکی از مهمترین چیزهایی که در سراسر کتاب یاد میگیرید این است که تلاش برای اجرای practice در تیمی با ذهنیت ناسازگار میتواند پایان بدی داشته باشد. پس پیش از امتحانکردن، فکر کنید تیم شما چه واکنشی خواهد داشت. همین فکرکردن هم میتواند به اندازهٔ انجام واقعی، ابزار یادگیری مؤثری باشد.
کجا بیشتر یاد بگیریم؟
این بخش با آیکون مخصوص مشخص میشود. Isaac Newton گفته است: «اگر دورتر دیدهام، به این دلیل بوده که بر شانههای غولها ایستادهام.» خوششانسیم که در زمانی این کتاب را مینویسیم که کتابهای پیشگامانهٔ زیادی دربارهٔ توسعهٔ نرمافزار اجایل نوشته شدهاند. پس از هر فصل چند منبع برای یادگیری بیشتر معرفی میکنیم.
آنچه از شما میخواهیم: یادگیری را ادامه دهید. این کتاب مرور جامعی بر Scrum، XP، Lean و Kanban است، اما نمیتوانیم تکتک جزئیات این ایدهها را پوشش دهیم. بیشتر ایدههای این کتاب را ما اختراع نکردهایم؛ خوشبختانه میتوانید از کسانی یاد بگیرید که آنها را ساختهاند.
صفحهٔ PDF 31
نکتههای مربیگری (Coaching Tips)
این بخش با آیکون مخصوص مشخص میشود. مربی اجایل کسی است که به تیمها کمک میکند اجایل را یاد بگیرند. کتاب برای کسی نوشته شده که در حال یادگیری اجایل است، اما میتواند راهنمایی برای مربی باتجربه نیز باشد تا این ایدهها را به تیم معرفی کند. اگر مربی اجایل هستید، نکتههای مربیگری پایان هر فصل را دنبال کنید؛ آنها کمک میکنند ایدهها و رویکردهای کتاب را با تیم خودتان تطبیق دهید.
آنچه از شما میخواهیم: حتی اگر مربی نیستید، Coaching Tips را بخوانید. یکی از راههای مؤثر یادگیری این است که خودتان را جای کسی بگذارید که به دیگران آموزش میدهد. اگر این مفاهیم برایتان تازهاند، تصور کنید چگونه از این نکتهها برای کمک به یادگیری بیشتر تیم دربارهٔ اجایل استفاده خواهید کرد.
ساختار این کتاب
این کتاب طوری ساختاربندی شده که با آموزش ارزشها و اصول یک تیم نرمافزاری مؤثر، مکاتب فکریای که این ارزشها را مجسم میکنند و practiceهایی که آنها را میسازند، اجایل را بفهمید.
دو فصل بعد کمک میکنند ارزشها و اصول لازم برای پذیرش ذهنیت اجایل را درک کنید. ابزارهایی به شما میدهند تا بفهمید تیم و شرکت برای اجایل آمادهاند یا نه، کدام بخشهای اجایل با تیمتان همخوانی دارند و کدام بخشها اجرای دشوارتری خواهند داشت:
- فصل ۲، Understanding Agile Values، ارزشهای اصلی اجایل را شرح میدهد. نمونهٔ تیمی را میبینید که در یک پروژهٔ نرمافزاری تقلا میکند و یاد میگیرید یکی از منابع اصلی مشکل «دیدگاه تکهتکه» (fractured perspective) است. سپس ارزشهای اجایل توضیح داده میشوند و با یک استعاره میبینید چگونه این ارزشها دیدگاه تیم را به هم نزدیک میکنند.
- فصل ۳، The Agile Principles، اصولی را شرح میدهد که تیمهای اجایل برای تصمیمگیری دربارهٔ ادارهٔ پروژه به کار میبرند. هدف و ایدهٔ پشت هر اصل با نمونهٔ عملی از پروژهٔ نرمافزاری نشان داده میشود.
صفحهٔ PDF 32
شش فصل بعدی محبوبترین مکاتب فکری اجایل—Scrum، XP، Lean و Kanban—را آموزش میدهند و کاربرد پایهٔ آنها را طوری معرفی میکنند که بتوانید همین امروز در تیم به کار بگیرید:
- فصل ۴، Scrum and Self-Organizing Teams، از Scrum بهعنوان یک متدولوژی محبوب برای آموزش نحوهٔ کار تیمهای خودسازمانده استفاده میکند. برای پذیرش Scrum در پروژهها توصیه میدهد و ابزارهایی برای یادگیری خودسازماندهی تیم فراهم میکند.
- فصل ۵، Scrum Planning and Collective Commitment، practiceهای مشخص برنامهریزی در Scrum را نشان میدهد و توضیح میدهد چگونه تیم بهصورت جمعی متعهد به تحویل نرمافزار ارزشمند میشود. همچنین نشان میدهد پذیرش واقعی Scrum به میزان تطابق ارزشهای Scrum با فرهنگ تیم و شرکت بستگی دارد و اگر تطابق وجود نداشت چه باید کرد.
- فصل ۶، XP and Embracing Change، practiceهای اصلی Extreme Programming و ارزشها و اصول XP را آموزش میدهد. خواهید دید چگونه هر عضو تیم به ذهنیتی میرسد که کد بهتر میسازد: بهجای متنفرشدن از تغییر، تغییر را میپذیرد.
- فصل ۷، XP, Simplicity, and Incremental Design، سه practice اصلی پایانی XP و نقش آنها در جلوگیری از مشکلات جدی کد و طراحی را توضیح میدهد. خواهید دید همهٔ practiceهای XP چگونه یک اکوسیستم تشکیل میدهند که به کد بهتر، نگهداشتپذیرتر، منعطفتر و تغییرپذیرتر منجر میشود.
- فصل ۸، Lean, Eliminating Waste, and Seeing the Whole، Lean و ارزشهایی را معرفی میکند که ذهنیت lean thinking را شکل میدهند. همچنین نشان میدهد ابزارهای تفکر ناب چگونه به تیم برای شناسایی و حذف اتلاف و دیدن کل سیستم ساخت نرمافزار کمک میکنند.
- فصل ۹، Kanban, Flow, and Constantly Improving، Kanban، اصول آن، ارتباطش با Lean و practiceهای آن را آموزش میدهد. میآموزید تمرکز Kanban بر flow و queuing theory چگونه تفکر ناب را به عمل تبدیل میکند و چطور Kanban میتواند فرهنگ بهبود مستمر ایجاد کند.
صفحهٔ PDF 33
دنیای اجایل فقط شامل ذهنیتها، متدولوژیها و مکاتب فکری نیست. شرکتها بیش از پیش به مربیان اجایل برای کمک به پذیرش اجایل تکیه میکنند. به همین دلیل فصل پایانی کتاب را اضافه کردهایم:
- فصل ۱۰، The Agile Coach، دربارهٔ مربیگری اجایل است: تیمها چگونه یاد میگیرند، مربی چگونه به تغییر ذهنیت تیم کمک میکند تا متدولوژی اجایل را آسانتر بپذیرد و چگونه میتواند شما و تیمتان را اجایلتر کند.
صفحهٔ PDF 34
تصویر منبع - صفحهٔ PDF 34
شکل 1-4 — ثبت گرافیکی زنده از سخنرانی Andrew Stellman در کنفرانس STRETCH 2013 در Budapest, Hungary. این سخنرانی بر مبنای مطالب همین فصل بود. ثبت گرافیکی: Kata Máthé و Márti Frigyik؛ منبع نمایشی www.remarker.eu در متن اصلی آمده است و در خروجی HTML به لینک خارجی فعال تبدیل نمیشود.