کیانوش آل‌شیخ

در روش Agile وقتی تیم توسعه محصول و یا پروژه از 10 نفر بیشتر میشود باید آن را به تیم های کوچکتر تقسیم کرد تا تعامل افراد با یکدیگر دچار مشکل نشود. ولی وقتی تعداد تیم ها بیشتر از سه یا چهار تیم شود و پیچیدگی تعامل آنها با یکدیگر بالاتر رود چه چاره ای وجود دارد؟ این مسئله در صورتی بغرنج تر میشود که هر یک از این تیمها به محصول و یا محصولات یکدیگر وابستگی داشته باشند .

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

سوالی که مطرح میشود اینست که آیا Agile با ایجاد فرآیند و قوانین مربوط به آن تقابل دارد؟

پاسخ اینست که خیر، Agile مخالف مهندسی نرم افزار، طراحی، مستند سازی و مدیریت فرآیند کاری نیست. بلکه بیشترین تاکید Agile به این نکته است که قوانین، روش ها و استانداردها و مستندات دست و پا گیر با زمان و هزینه بسیار زیادی ایجاد شود به طوری که قابل تغییر نباشد و موجب پایین آمدن یا از دست رفتن انعطاف پذیری شود.

خاطره ای از ارائه مشاوره برای یک شرکت

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

پیشنهاد من در ابتدا بررسی وظایف تیم ها، فرآیندهای کاری بین تیم ها و سپس مستندسازی آنها برای کشف نقاط بحران بود و در درجه دوم بهبود این فرایندها و تبدیل آن ها به فرایندهای کاری داخلی بود. با ارائه این پیشنهاد مدیر محصول شرکت به من متذکر شد که با انجام این کار چابکی آنها کاسته خواهد شد و این کار متناقض چابکی است!

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

در حالت کلی در هیچ جایی از بیانیه Agile و دیگر منابع و کتاب های این حوزه مستند سازی و یا ایجاد روش و دستورالعمل متناقض روش Agile ذکر نشده بلکه گاهی وقت ها مجبور هستید برای کسب دانش و یا تعامل با تیم و یا حتی ارائه یک دستاورد به ذینفعان کلیدی مستند سازی انجام دهید.

به مثالهایی از مستند سازی هایی که با روش Agile در تناقض نیستند توجه کنید.

• می خواهید یک مسئله پیچیده را از طریق ایجاد نمودار های UML توضیح دهید و تیم را در حل مسئله خود شریک کنید
• میخواهید Road Map محصول را طراحی کنید و یا تاریخچه محصول خود را به همراه بازخورد های مشتریان نگهداری کنید
• می خواهید یک Feature (احتمالا پیچیده) را به همراه جزئیات داخلش برای یک ذینفع کلیدی تشریح کرده و توضیح دهید
• به منظور افزایش دانش افراد تیم، میخواهید دانشی را که به دست آورده اید برای آنها نیز تشریح کنید.
• تجربه ای را که به دست آورده اید مستند کرده و به دیگر افراد تیم بدهید تا آنها در تکمیل این تجربه نقشی داشته باشند و آنرا تکمیل نمایند.
• طراحی معماری نرم افزار با UML

تمام این مثالها درباره مستنداتی هستند که روشی برای حل مسئله یا رسیدن به بخشی از دستاوردی که مورد نیاز ذینفعی میباشد مورد استفاده قرار میگیرد.

تنها مستنداتی که با Agile در تناقض میباشند آنهایی هستند که با صرف هزینه و زمان بسیار زیاد ایجاد شده اند و موجب پایین آمدن و یا از بین رفتن انعطاف پذیری در تیم میشوند (مثل مستندات جامع نیازمندیهایی که در ابتدای چرخه تولید ایجاد شده اند) و یا با اعمال قوانین دست و پا گیر قدرت ابتکار عمل را از آنها می گیرند.