Iterative incremental  چیست و چرا باید به این شیوه کار کرد؟

روشIterative incremental در  تولید نرم افزار از ملزومات همگرایی یک تیم برای تولید یک سیستم کارا و صحیح در قالب یک پروژه موفق است.

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

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

در شیوه­ ای که مشتری یا نماینده ویو در برخی شرکتها مدیریت آن شرکت می­تواند هر آن و بدون تهدیدی حیاتی کار را متوقف کند  و مسیر را تغییر دهد، اصلی ترین تهدید ها عبارتند از:

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

از منظر دیگر، چنانچه  تیم توسعه، ارائه بازخورد و بازنگری را برای خود و مشتری تا اتمام اولین کار مهم پیش رو به تعویق بیاندازد، چالشهایی را متوجه موفقیت پروژه خواهد کرد که مهم ترین آنها عبارتند از:

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

ممکن است یک تیم نرم­ افزاری به صورت Iterative کار کند اما خصوصیت Incremental را در انجام کارهایش رعایت نکند، یعنی بعد از هر Iteration فهمش از مساله افزایش پیدا  نکرده باشد و خروجی ملموسی برای مشتریان نیز ایجاد نشده باشد، در مقابل ممکن است که تیمی نیز به صورت Incremental کار کند اما خصوصیت Iterative بودن را در کار خود نداشته باشد، بدین شکل که کارهای یک سیستم بزرگ به مجموعه ای از کارها شکسته شود و انجام سلسله وار آنها شروع شود بدون آنکه در یک ریتم منظم تمام مناسک تولید نرم­ افزار و بويژه تولید بازخورد انجام شود. هیچ یک از این دو خصوصیت به تنهایی نمی­توانند منجر به بهبود روند تولید و کیفیت خروجی و نیز مدیریت ریسک شوند. لذا نیاز است برای نیل به هدف این دو را در کنار هم داشت تا در دنیایی از عدم قطعیت، بتوان پیش ­بینی ای از وضعیت موجود و گامهای باقی مانده تا حصول به نتیجه داشت. بدیهی است که نمی­توان انتظار داشت در فضای تولید نرم­ افزار عدم قطعیت را کاملا مهار کرد، از این رو به تکنیک و ابزارهایی نیاز داریم که ما را در کنترل این عدم قطعیت و تخفیف اثرات آن یاری دهد. شیوه Iterative Incremental ابزارهایی را در اختیار می­گذارد تا به شکل موثری به این هدف نایل شویم.

می­توان مزایایی که این شیوه از تولید نرم­ افزار در بر دارد را ینگونه برشمرد:

  1. سوء برداشتها و کج فهمی ها در حوزه مساله زود تر آَشکار می­شوند و زمان بیشتری برای واکنش نشان دادن به آنها وجود دارد.
  2. مشتری و کاربران را مشتاق به ارائه بازخورد زود هنگام خواهد کرد تا نیازمندی­های واقعی زودتر کشف شوند.
  3. تیم تولید را بر مهمترین موارد مرتبط با پروژه متمرکز می­کند تا ریسکها­ را مدیریت کنند و از تمرکز بر روی المانهایی که ریسک واقعی نیستند دوری کنند.
  4. روند منظم «تولید، تست، تحویل»، قابلیت اندازه گیری المانهای مختلف، برای سنجش وضعیت پروژه را فراهم می­کند.
  5. ناهمگونی بین نیاز، طراحی و پیاده سازی، زود و بر اساس روندی منظم کشف می­شوند.
  6. حجم کاری تیم در حد متعادلی باقی می­ماند.
  7. با استفاده از بازخوردهای منظم درونی، تیم می­تواند شیوه­ عملکرد خود را تصحیح کند.
  8. می­توان اطلاعات ملموسی بر اساس واقعیت پروژه برای ذینفعان در همه حوزه ها، مدیریت سازمان، واحد های نظارت مالی، واحد های نظارت کیفی و کنترلی فراهم کرد.

چالشهای معمول در پیاده سازی روش Iterative incremental    در سازمانها چیست؟

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

ادعا: می توان به راحتی روند  Iterative Incremental  را در سازمان پیاده سازی کرد.

واقعیت: چنین ادعایی چالش برانگیز است، زیرا بی­ شک در هر سازمانی در برابر تغییرات مقاومت وجود خواهد داشت. برخی از دلایل این مقاومتها عبارتند از:

  • ترس افراد از از دست دادن قدرت و نفوذشان: اگرچه ممکن است چنین تغییری برای سازمان مایه خیر و برکت باشد اما هستند افرادی که گمان می­کنند چنین روند و شفافیتی برایشان آزاردهنده خواهد بود. تغییر برای آن افراد یعنی باخت، باختی که آنها را دچار ترس و اضطراب می­کند. این مورد یکی از مهمترین عوامل مقاومت در برابر تغییراتی اینچنینی است.
  • افراد از وضعیت موجود راضی هستند: اعضای تیم دلبسته­ ی موفقیتهای پیشین خود هستند بدون آنکه بدانند راهی برای انجام بهتر کار هم هست. این خصوصیت اغلب با چنین جملاتی همراه هستند که« ما که تا به حال هم بد عمل نکرده ایم! پس چه نیازی به تغییر است؟»
  • سفسطه در باب استثناءها: فارغ از آنکه یک «به روش[1]» تا چه حد جا افتاده و موفق بوده است و از آزمون­های مختلف سربلند بیرون آمده است، افراد، محیط خود را مستثنی می­دانند و اداعا می­کنند که این الگو در اینجا (محیط شان) جواب نمی دهد، در واقع این افراد فارغ از شواهدی که عکس نظرات آنان را نشان می­دهند خود و محیطشان را مستثنی می­دانند.
  • عواقب ناخواسته و ناشناخته: شنیدن چنین جملاتی که« نمی دانیم اگر این تغییر را اعمال کنیم چه عواقبی را در پی دارد؟» در زمان تغییر در سازمان عجیب نیست.

باید پذیرفت که هر گونه تغییری در سازمان، از جمله حرکت به سمت تغییر شیوه تولید نرم افزار به شیوه Iterative Incremental مقاومت­هایی را در پی خواهد داشت. این شیوه از تولید، نه تنها تیم تولید را تحت تاثیر قرار می­دهد، بلکه مشتریان را نیز به واسطه تغییر در شیوه­ های برنامه­ ریزی و تولید، تحت تاثیر قرار می­دهد. از این رو برای به کارگیری این روش باید مخاطرات و مقاومت­های پیش رویتان را بشناسید و تمام قد از این تغییر حمایت کنید.

ادعا:تغییر به شیوه Iterative Incremental معجزه خواهد کرد و تمام مشکلاتمان را رفع می کند.

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

ادعا:همه چیز خوب است، چه نیازی به تغییراتی کلی و سراسری در این سطح داریم؟

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

عزم و اراده مدیران ارشد، برای ایجاد شفافیت و همسو سازی سازمان، در ایجاد تغییرات کلان که منجر به تمایز استراتژیک شود، مهم ترین عامل در رفع مشکلات پیش رو برای اعمال تغییرات است.

مراجع:

http://www.methodsandtools.com/archive/archive.php?id=14

http://www.ibm.com/developerworks/rational/library/4243.html

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.685.6705&rep=rep1&type=pdf

http://www.ibm.com/developerworks/rational/library/content/RationalEdge/oct04/nelson/

[1] Best Practice