ارتباط و تعامل بین افراد یکی از ارزشهای متدهای چابک است. بسیاری از اقدامات (Practice) این متدها نیز بر این اساس، پایه‌گذاری شده است.
ارتباط و تعامل یکی از مهم‌ترین چالشهایی است که در پذیرش و استقرار متدهای چابک در تیمها، با آن روبرو خواهید شد.

برنامه‌نویسی دونفر یا Pair Programming از جمله اقداماتی است که این چالش در آن پررنگ است. در این اقدام، یک نفر نقش راننده (driver) و نفر دوم، نقش هدایتگر(navigator) را بر عهده می‌گیرد. صفحه کلید در اختیار راننده است که کد را می‌نویسد و وظیفه نفر دوم بازنگری، پایش طراحی و پیدا کردن خطاها است.

بروکس در دهه 1950، کونستانتین در دهه 1990 و فارسر در OOPSLA سال 94 به آن اشاره کرده‌اند. اما شهرت آن به سال 1999 با کتاب XP Explained از کنت بک و سایرین برمی‌گردد.

نکته جالب توجه این است که این تکنیک می‌تواند در تیم‌های غیرچابک نیز اجرا گردد.

به تازگی مقاله‌ای در وال استریت جورنال چاپ شده است که به نکات جالبی از مؤفقیت، شکست و دردسرهای این تکنیک اشاره کرده است. همچنین خاطراتی از کنت بک و کانینگهام را در انجام برنامه‌نویسی دو نفره در خود دارد. این مقاله تأکیدی است بر این که در کنار کارایی فوق‌العاده این اقدام، به‌کارگیری آن ساده نخواهد بود، حتی در شرکتهای آمریکایی.

موقع خواندن مقاله وقتی به جمله زیر رسیدم، نتوانستم جلوی خنده‌ام را بگیرم:

“People who have been pairing a while, they’ll start acting like old married couples,” said Marc Phillips.

مقاله را می‌توانید اینجا مطالعه کنید.
گزیده:

“A good programmer is someone who looks both ways before crossing a one-way street. “
– Anonymous

تازه‌کار: سلام
چابک: سلام. چهره‌ات نشان از سردرگمی دارد. می‌توانم کمک کنم؟

تازه‌کار: حق با شماست. بعد از توضیحات شما در مورد چابکی، بیش از پیش دچار ابهام شده‌ام.
چابک: ابهام چیز ناخوشایندی نیست. کدام بخش برایت مبهم است؟

تازه‌کار: چرایی متدهای چابک. یعنی فلسفه به وجود آمدن متدهای چابک و ارتباط آن با ایجاد نرم‌افزار
چابک: اجازه بدهید ابتدا کمی تاریخ برایتان بگویم.
متدهای اسکرام و دی‌اس‌دی‌ام قبل از متد اکس‌پی ارائه شده بودند. اولی چارچوبی برای مدیریت پروژه و دومی، متدی برای ایجاد سیستمهای کسب‌وکاری(business). ارائه اکس‌پی توسط کنت بک و دوستانش، نقطه عطفی بود بر این گونه متدها. به دلایل متعدد از جمله ارائه‌دهندگان اکس‌پی و تولد آن از دنیای توسعه‌دهندگان و برنامه‌نویسان، این متد با اقبال بسیاری روبرو شد، موج و حرکت جدیدی را به وجود آورد که تا به امروز نیز ادامه دارد.

تازه‌کار: نام چابک از کجا آمد؟
چابک: پس از مدتی چند تن از پیشروان این پارادایم، به دعوت باب مارتین (رابرت سی مارتین معروف به عمو باب) در جایی جمع شدند. هدف اصلی گردهمایی این بود که بین متدهای سبک شامل Adaptive Software Development, XP, Scrum, Crystal, Feature-Driven Development, Dynamic System Development Method (DSDM), and “pragmatic programming.” مشابهتی وجود دارد یا خیر.

یکی از نتایج گردهمایی، نامگذاری این گونه از متدها بود. در آن گردهمایی مجموعه‌ای از اسامی پیشنهاد شد و پس از مراحلی، بین دو نام چابک (agile) و سازگار (adaptive) رای به چابک داده شد، هر چند عنوان دوم در بسیاری از مراجع و حتی توسط بسیاری از پیشروان این متدها هنوز به کار برده می‌شود.

تازه‌کار: آِیا گردهمایی فقط منجر به انتخاب عنوان متدها شد؟
البته که خیر.
شرکت‌کنندگان گردهمایی در مورد چند موضوع اتفاق نظر داشتند:
– در سطح اول، بر سر ضرورت پاسخ‌گویی مناسب به تغییرات
– در سطح دوم، بر سر چهار ارزش اصلی (Value)
– در سطح سوم ( و به دشواری) ، بر سر دوازده بند و اصل همخوان با ارزشهای چهارگانه(Principle)

سطوح دوم و سوم به صورت بیانیه‌ای (Agile Manifest) صادر و توسط این افزاد امضاء شد. این افراد پس از آن، Agile Alliance را نیز پایه‌گذاری کردند.

تازه‌کار: خوب، پس هدف اصلی متدهای چابک، پذیرش تغییرات و اعمال مناسب آنهاست.
چابک: البته. اما این موضوع، همه فلسفه چابک را در بر نمی‌گیرد.
در دهه گذشته، حرکت به سوی متدهای چابک سرعت روزافزونی به خود گرفته است. در این سالها، واضعان این متدها با تفکرات متفاوت اما همگرا و با تکیه بر تجربه­های مؤفق نشان دادند که اجرای این متدها تأثیر به­سزایی در بهبود چهار پارامتر بزرگ و مهم دارند: کارایی، کیفیت، روحیه افراد و زمان ورود به بازار.

هدف اصلی متدهای چابک تحویل سریع­تر نرم­افزار و کسب اطمینان از پوشش نیازهای در حال تغییر مشتری است. بطور کلی این متدها بر چهار موضوع انسانها و تعاملات بین آنها، پذیرش تغییرات نیازمندی­ها، تحویل زود به زود نرم­افزار قابل استفاده و همکاری نزدیک مشتری و توسعه­دهندگان تأکید دارند.

تازه‌کار: خوب، پس از فردا شروع می‌کنم به چابک‌کار شدن و مدیرانم را نیز تشویق می‌کنم به چابک‌کاری.
چابک: صبر کن. به کجا چنین شتابان. چقدر زود احساساتی شدی. به قول دوستان «چرا جوگیر شدی؟».

تازه‌کار: مگر شما نگفتید که چابک خیلی خوب است.
چابک: چرا!
تازه‌کار: خوب. پس باید شروع کنیم.
چابک: حتماً ابتدا شروع می‌کنی یک بک‌لاگ محصول می‌نویسی،..، بعد هم تکرارهای ماهانه (اسپرینت) خواهی داشت، جلسات ایستاده روزانه برگزار می‌کنی؟

تازه‌کار: شما از کجا فهمیدید؟
چابک: چون ساده‌ترین بخش کار، همین مواردی است که شما می‌خواهید انجام دهید. خیلی از کسانی که می‌شناسم به همین گونه شروع کرده‌اند و بعد «عشق آسان نمود اول، ولی افتاد مشکل‌ها»

بگذارید آماری را خدمت شما ارائه دهم. مؤسسه Standish Group در گزارش سال 2011 خود، اعلام کرده است که:
9 درصد پروژه‌های چابک شکست خورده‌اند.
49 درصد …. دچار چالش بوده‌اند.
42 درصد …. با مؤفقیت پایان یافته‌اند.

این آمار به این معنی است که با وجود مؤفقیت متدهای چابک، 58 درصد پروژه‌ها دچار مشکل هستند. به عبارت ساده‌تر اجرای متدهای چابک حتی به بهترین شیوه آن، به معنی واکسینه شدن در مقابل خطرات و ریسکهای پروژه‌ها نیست.

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

تازه‌کار: بسیار خوب.
چابک: بقیه‌اش باشد برای بعد. تعطیلات خوش بگذرد.
تازه‌کار: به شما هم همینطور.

مراجع:
سیلابس دوره متدهای چابک (Agile Methods)
Agile Software Development: The Cooperative Game, 2^nd, Alistair Cockburn
Standish Group, CHAOS Report, 2011

گزیده:

Agile methods derive much of their agility by relying on the tacit knowledge embodied in the team, rather than writing the knowleadge down in plans.
Barry Boehm

Code is often refactored to simplify it and make it easier to maintain. A similar activity can be taken to clean up the requirements. Like code refactoring, refactoring requirements does not increase the number of features or fix bugs. The intent is to reduce complexity and ambiguity in the requirements so they are easier to manage and to improve the ability of the team to support and maintain the system.

When refactoring requirements look for duplicate requirements, ambiguous requirements, requirements that are difficult to test, and requirements that appear to contradict other requirements. This is also a good time to re-examine the Requirements Management Plan to see what should be added or removed. There may be attributes that track information the team doesn’t use, or traces between requirements that are never examined. Each item in a Requirements Management Plan requires overhead to maintain, so if it’s no longer needed it should be removed. Conversely, there may be some difficulties the team has had in managing requirements. This is a good time to add appropriate attributes, traces, or activities that will better support the environment.
Reference: IBM Rational Unified Process

Quote:
When you feel the need to write a comment, first try to refactor the code so that any comment becomes superflouus.
Martin Fowler

Software engineering is gravely hampered by immature practices. Specific problems include: The prevalence of fads more typical of the fashion industry than an engineering discipline; a huge number of methods and method variants, with differences little understood and artificially magnified; the lack of credible experimental evaluation and validation; and the split between industry practice and academic research.

At the root of the problems we lack a sound, widely accepted theoretical basis. A prime example of such a basis is Maxwell’s equations in electrical engineering. It is difficult to fathom what electrical engineering would be today without those four concise equations. They are a great example to the statement “There is nothing so practical as a good theory”. In software engineering we have nothing similar, and there is widespread doubt whether it is needed. This talk will argue for the need of a basic theory in software engineering, a theory identifying its pure essence, its common ground or its kernel.

The Semat (Software Engineering Methods and Theory) community addresses this huge challenge. It supports a process to refound software engineering based on a kernel of widely-agreed elements, extensible for specific uses, addressing both technology and people issues. This kernel represents the essence of software engineering.
Reference: ASE 2012 Keynote, by Ivar Jacobson

Quote:
“I find that I am most happy and healthy when I am living in alignment with my goals, dreams, and principles.”
Steve Maraboli

نمی‌دانم چرا گاهی نوشتن تا این اندازه دشوار می‌شود.

گزیده:
بسياري از ما در تلاش براي زندگي بهتر، زندگي را از ياد مي‌بريم. مارگارت فولر
مرجع: اس. جی.

یادآوری: حادثه‌دیدگان زلزله اخیر را از یاد نبریم.

تازه‌کار: سلام
چابک: سلام، خیلی وقت است که منتظر شما و پرسشهایتان بودم.
تازه‌کار: بله. خودم هم مشتاق یادگیری بودم. فرصت نکردم.
چابک: بسیار خوب

تازه‌کار: شما را که می‌بینم یاد یوزپلنگ و ببر می‌افتم.
چابک: یعنی قیافه من شبیه یوزپلنگ است
تازه‌کار: نه! نه! آخر همه جا چابکی را با تصویر ببر یا یوزپلنگ نمایش می­دهند.
چابک: خوب! متوجه شدم. نه این تصور درست نیست.
تازه‌کار: یعنی شما یوزپلنگ نیستید؟
چابک: ها ها. التبه که نه. من چابک هستم، انسانی مثل خود شما. اجازه دهید برای رفع سوءتفاهم ابتدا تعریفی از چابکی ارائه دهم.
تعریف چابکی سازمانی یا چالاکی را می­توانید در اینجا ببینید.

چابکی «توانایی واکنش(پاسخ) سریع به تغییرات و ریسکها است»
حال که شما از یوزپلنگ صحبت کردید، اجازه دهید از دنیای حیوانات مثالی بیاورم. با تعریف گفته شده، فیل، خرگوش، زرافه و حتی یوزپلنگ، همگی چابک هستند. چرا که در طول تاریخ، با پذیرش تغییرات و تطابق­پذیری با محیط به حیات خود ادامه داده­اند، در حالی که دایناسورها نتوانسته­اند به حیاتشان ادامه دهند. جایی خوانده­ام که ظاهر زرافه کاملاً با شرایط آب و هوایی محل سکونتش تطابق دارد. اگر دقت کرده باشید (همان طور که در تعریف مشخص است)، سرعت، ویژگی چابکی نیست، بلکه سرعتِ تطببق­پذیری با تغییرات محیط و ریسکهایش، ویژگی بارز چابکی است.
تازه‌کار: متوجه شدم. چه جالب.

چابک: فیلها که نماد کندی هستند، در طول تاریخ، زنده مانده­اند و چه بسیار جانوران تند و تیزی که امروز اثری ازآنها باقی نیست. پس سرعت، ویژگی بقا نیست. سرعت پذیرش تغییرات محیطی، راز بقاست.
تازه‌کار: با شما مؤافق نیستم. نماد کندی، فیلها نیستند.
چابک: پس چیست؟
تازه‌کار: رحیم، برادرم!
چابک: بله!
تازه‌کار: آخر وقتی که می‌خواهیم از خانه بیرون برویم، دردسر داریم. عروس خانم در روز عروسی زودتر آماده می‌شود تا این آقا رحیم ما! همه خانواده نگران روز دامادی‌اش هستند، می‌خواهند سه روز زودتر از روز عروسی، او را بفرستند تا آماده مراسم شود!

چابک: ها ها ها. خوب باشه، قبول. یادم خواهد ماند که از این پس، آقا رحیمِ شما را نماد کندی در عالم هستی اعلام کنم.
تازه‌کار: دست شما درد نکند.
چرا شما مدام از بقا و حیات صحبت می­کنید؟

چابک: به نکته جالبی توجه کردید. همه تلاش ما این است که سازمان یا بنگاه به عنوان یک موجود جاندار، زنده بماند، رشد کند و تکامل یابد. اگر شرکت یا تیمی نتواند خودش را با محیط تطبیق دهد، محکوم به نابودی است.
تازه‌کار: نکاتی که اشاره کردید، خیلی برایم جالب بود. باعث شد از دیدگاهی دیگر به موضوع نگاه کنم. اما یک مشکل عمده دارم: گفته‌های شما چه ارتباطی با ایجاد و نگهداری نرم‌افزار دارد.

چابک: کمی خسته شده‌ام، اجازه می‌دهید این بحث را در دیدار بعدی ادامه دهیم.
تازه‌کار: حتماً. به امید دیدار
چابک: تا فرصت درودی دیگر، بدرود.

گزیده:
«موفقیت یک آموزگار کشنده ‌است، افراد باهوش را از راه به‌در می‌کند و آن‌ها فکر می‌کنند که دیگر هرگز نمی‌بازند.» بیل گیتس