Agile دارویی برای تمام امراض

دانشمندان آمریکائی در آخرین پژوهش های خود موفق به ساخت داروئی با نام Agile شدند که این دارو می تواند تمام پروژه های در حال شکست را نجات دهد. به گزارش خبرنگار ما از Agile Manifesto هر قرص Agile می تواند چندین پروژه در حال مرگ را نجات دهد و دستور العمل استفاده از این فناوری جدید بدین صورت است که اعضای تیم فقط با میل فرمودن این قرص ها یا تزریق کردن آمپول مورد نظر خواهند توانست مانند کنت بک برنامه نویسی کنند ,  مانند مارتین فولر رفاکتور نمایند ,  مانند استیو جابز مدیریت فرمایند و خلاصه شرکت ها تبدیل به مایکروسافت و گوگل خواهند شد و پروژه ها هم که کاملا موفق. به شنیده ما از منابع غیر موثق این دارو  برای پروژه های ایرانی هم همان تاثیر را دارا می باشد.

یکی از مشکلاتی که در جوامع تازه آشنا با Agile یا متعلقات گرامی مانند اسکرام می تواند اتفاق بیفتد جو زدگی می باشد. برای مثال مدیر شرکتی با خواندن یک مقاله یا کتاب در مورد Agile  به این فکر می افتد که :»این همونه – این خودشه – همینه یا …» و سریعا اقدام به چابک سازی شرکت با معلومات یک مقاله ای یا کتابی می کند.مشکل از آنجایی حادث می شود که در مقالات یا کتاب های Agile (مانند منابع بنده) , Agile به گونه ای تشریح می شود(یا شده است) که اصطلاحا آب از دهن خواننده سرازیر می کند یا به عبارت رسمی تر خواننده را به سمتی هدایت می کند تا سریعا چابک شود. من به اینگونه چابک سازی ها ,  چابک سازی بی فکر می گویم.

اما مشکل چابک سازی بی فکر چیست ؟

مشکل از جایی شروع می شود که مدیر و یا رهبر شرکت یا پروژه بدون در نظر گرفتن جوانب امر یا تهیه ملزمات و معمولا با دانش کم اقدام به چابک سازی می نماید که اکثرا نتیجه آن جالب نیست و یا فرقی بین حالت چابکی آنها با غیر چابکی نمی توان یافت («ما که نفهمیدیم الان که Agile ایم با گذشته چه فرقی داریم؟«) . گرفتن نتیجه خنثی و یا بد پس از چابک سازی موجب به وجود آمدن جو نامناسب علیه متد Agile می شود که مثلا «آقا ما استفاده کردیم به درد نخورد – اینا تو آمریکا کاربرد داره – این جنگولک بازی ها چیه؟ بشین کدت رو بنویس – این هم یه چیزی هست مثل بقیه ولش کن و … . بدلیل نوپا بودن گستردش بحث Agile در ایران دور از انتظار نیست که بعضی از شرکت ها با چنین نتایجی مواجه شوند و دوباره به متدهای قبلی سوئیچ نمایند که این اصلا برای گسترش و نهادینه شدن Agile در ایران خوب نیست.

بنابر وظیفه تاریخی خودم (من از 200 سال بعد اومدم لازم دانستم در این پست اشاره ای بر بعضی از مسائل شاید نهان استفاده و یا عدم استفاده از متد ملت پسند Agile نمایم.

آیا Agile در هر سازمانی و یا در هر پروژه ای جوابگو می باشد؟

مسلما نه !

در چه نوع  Agile ایزه شدن احتمالا با مشکل مواجه خواهیم شد؟

• چابک سازی های بدون فکر.
• سطح فنی نفرات پیاده (نیروی کار) پایین باشد.

همان بحث معروف Technical  Excellence که در پست هایی به صورت مفصل شرح داده شده است.

• پروژه های با قراردادهای بسته.

قرارداد بسته از نظر قیود هزینه و زمان .

• عدم چابک سازی جامع و سازمانی.

برای مثال در بعضی از سازمان ها تیم توسعه چابک شده است ولی تیم رهبری و یا رده های بالا میلی به چابک شدن یا به قولی جنگولک بازی ها ندارند. چنین چابک سازی های غیر جامعی پایدار نخواهند بود.

• دانش ناکافی نسبت به متد Agile و یا به اصطلاحی دانش تک مقاله ای یا تک کتابی.

• چابک سازی صرفا جهت تفریح و یا ایجاد اوقات فراغت.
• عدم وجود روحیه چابک شونده.

و چندین مورد دیگر که می تواند مانع چابک سازی کامل و درست سازمان باشد. مهمترین مورد در این جا این است که چابک سازی باید اولا بر اساس دانش و آگاهی باشد دوما چابک سازی نباید یکباره و یکدفعه ای باشد و بالعکس باید به صورت inspect and adapt اجرا شود.

من به عنوان یک مربی Agile زمانی که درخواستی از سازمانی در باب چابک سازی سازمان دریافت می کنم ,  نخستین کار ارزیابی سازمان می باشد به طوری که با بررسی وضع سازمان و یا پرسش و پاسخ می خواهم به سوال «چرا باید این سازمان چابک شود؟ » جواب دهم یا به عبارت ساده تر مشکل این سازمان چیست که می خواهد  چابک شود؟ (اگر همه چیز در جای خود باشد و کامل و درست ,  چه نیازی است که سازمان چابک شود؟) . پس در اولین کار بدنبال کاستی ها می گردیم :

1- سرعت توسعه محصول کند است

2- محصول نهایی پر از باگ است

3- بهره وری نیروی انسانی پایین است

4- مشتری ناراضی است

و …

پس از اینکه ملاحظه کردیم که بلی سازمان دچار کاستی هایی می باشد و یا اصلا دچار کاستی نیست بلکه نیازمند بهبود بخشی هایی (مانند تسریع پروسه ارائه محصول) می باشد شروع به امکان سنجی Agile می کنیم که آیا شلوار Agile در قواره این سازمان با این وضع و با این درخواست ها می باشد؟ این سنجش را هم مانند قسمت اول که بیان شد انجام می دهیم : مثلا آیا برنامه نویس ها توانایی بحث Technical Excellence  را دارا می باشند؟ یا آیا مدیریت مایل به تغییر روند مدیریت به بحث خود سازماندهی می باشد و یا … .

نهایتا با توجه به کمبود ها و نیازهای سازمان جهت دست یابی به قله های رفیع موفقیت برنامه ریزی با عنوان برنامه چابک سازی انجام می دهیم که این برنامه با توجه به روند inspect and adapt بودنش متغییر می باشد. معمولا در این برنامه شاهد وجود برنامه های آموزشی – نظارتی – مشاوره ای و … خواهیم بود.

در آخر قابل ذکر است که Agile روشی است که در صورت به جا و درست به کار برده شدن می تواند ابزار موفقیت سازمان باشد وگرنه روشی است مانند روش های دیگر.

یاشیاسیز

مدیریت نسل سوم

برادر گرامی Jurgen Appelo به تازگی اقدام به نگارش و انتشار کتاب خوبی در زمینه مدیریت چابک با نام Management 3.0 کرده اند. این کتاب که به تازگی و از اوایل سال میلادی جدید در دسترس همگان قرار گرفته است که با استقبال خوبی از طرف مدیران و علاقمندان به مبحث Agile مواجه شده است.

در این کتاب بحث شیرین مدیریت به 3 نسل اولیه و اولیه تکمیل شده و مدیریت قرن 21 یا همان 3.0 تقسیم شده است که همان مدیریت Agile گذری از مراحل 1 و 2 به دوران مدیریت جدید می باشد.

همانطور که ذکر شد ورود به دنیای مدیریت Agile نیازمند گذر از دو مرحله پیشین مدیریت می باشد که در این کتاب به  خوبی این مهم شرح داده شده است. علاوه بر این به خوبی نیازهای یک سازمان به مدیریت چابک و نحوه تحول سازمان به این نوع مدیریت نوین نیز کاملا با بیانی کمی تا حدودی سخت شرح داده شده است.

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

ولی باز با این حال کتاب ,  کتاب بسیار خوب و عالی و کم نظیری می باشد که برای مدیران چابک و یا کسانی که می خواهند از تحول سازمانی چابک بهره مند شوند بسیار توصیه می شود.

این کتاب موضوعات زیر را شامل می شود :

• Getting beyond “Management 1.0” control and “Management 2.0” fads
• Understanding how complexity affects your organization
• Keeping your people active, creative, innovative, and motivated
• Giving teams the care and authority they need to grow on their own
• Defining boundaries so teams can succeed in alignment with business goals
• Sowing the seeds for a culture of software craftsmanship
• Crafting an organizational network that promotes success
• Implementing continuous improvement that actually works

یاشیاسیز

آیا شلوار Agile هنوز برای سازمان های ایرانی گشاد است؟

همانطور که در پست های متعدد مانند پست خروجی کارآ در Agile اشاره شد نرم افزار کارآ یا Working Software یکی از ارزش های چهارگانه توسعه نرم افزار چابک می باشد ولی سوالی که قابل طرح است این است که آیا سازمان ها یا شرکت های توسعه نرم افزار ایرانی آمادگی دست یابی به این ارزش را دارا می باشند؟

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

بزرگترین مانع در دست یابی به یک محصول کارآ به نظر من قراردهای بسته می باشد. قراردادهایی وابسته به یک نیاز سنجی اولیه و تخمین زمانی اغلب نادرست. مثلا Aو B را باید در 1 ماه انجام بدهید. انجام A و B در یک ماه حالا با یک تلرانس 1 هفته ای طی یک پروژه , عرضه کننده محصول کارآ نخواهد بود زیرا ما مکلف به تکمیل درخواست ها هستیم و نه ارائه محصول کارآ.  همین دید باعث می شود اگر زمانی نیاز باشد B به C تبدیل شود شاهد اختلافات بزرگی باشیم.

در قراردادهای بسته معمولا عامل های دامنه , هزینه و زمان پروژه بسته تعریف می شوند و این خود آغازی بر پایان خروجی کارآ خواهد بود. یعنی من مکلفم این موارد را در این زمان با این هزینه تکمیل نمایم و موارد بعدی ربطی به من ندارد.

در بحث خروجی کارآ همانطور که اشاره شد ما باید رفته رفته و طی Iterative ها یاد بگیریم که خروجی کارآی این پروژه چیست و مسیر خود را به سمت خروجی کارآ تغییر دهیم. اما در یک قراداد بسته بدلیل بسته بودن عامل های دامنه , هزینه و زمان پروژه امکان انجام چنین چیزی وجود نخواهد داشت.

اما بحث قرارداد بیشتر یک بحث فرهنگی می باشد تا یک بحث فنی. همیشه در قرارداد باید حداقل دو طرف وجود داشته باشند : 1- مشتری 2-مجری قرارداد. هر دو طرف این قرارداد باید به یک سطح فرهنگی و شعوری برسند که من مشتری برای رسیدن به خروجی کارآ باید هزینه کنم و من مجری باید خروجی کارآ ارائه نمایم و اسم این سطح شعوری را می توان چابکی نامید.مشتری چابک و مجری چابک خواهند توانست آغاز گر یک پروژه با خروجی کارآ باشند.

اما این فقط آغاز یک پروژه خوب خواهد بود و علاوه بر این در طی این پروژه مشتری و مجری باید دائما به صورت چهره به چهره ارتباط داشته باشند. باید اینها با هم یاد بگیرند ,  نوع آوری کنند, نیازهای جدید را استخراج نمایند و کلا خروجی کارآ را کشف نمایند و اینگونه خواهد شد که گوشی مانند iPhone پدید خواهد آمد.

اما هنوز هم برای خلق یک محصول کارآ آماده نیستیم زیرا هنوز تیم های ما از Technical Excellence برخودار نیستند. برای دست یابی به خروجی کارآ سطح فنی تیم های ما باید بالا باشد و به عبارتی در سطح فنی عالی باید باشند.

به نظر من یک تیم خود سازمانده با سطح فنی خوب در یک پروژه چابک خواهد توانست خروجی کارآ عرضه نماید و این است ارزش اصلی چابک شدن و بودن.

اینها یک سری مواردی بودند که برای به وجود آوردن و خلق محصول کارآ حیاتی می باشند و نتیجه گیری اینکه سازمان های ما می توانند خروجی کارآ ارائه نمایند بر عهده خود شما می باشد.

چابک شوید و چابک بمانید.

یاشیاسیز