موتور چابک : چگونه باید چابک شد؟

در اولین کنفرانس چابک ایران، Iran Agile 2014 افتخار این را داشتم که ارایه ای با عنوان “موتور چابک: چگونه باید چابک شد؟” را داشته باشم. برای دانلود فایل اسلایدهای پرزنتیشن می توانید به این لینک مراجعه نمایید و در ادامه، متن مقاله ارایه شده آمده است. برای دانلود مقاله بصورت PDF هم می توانید از این لینک استفاده نمایید.

از یک داستان باید شروع کرد

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

 Agile-Umbrella-300x238.png (300×238)

این بیانیه همانند یک چتر بود که پرکتیس هایی مانند اسکرام، کانبان، XP , کریستال و … را در بر می گرفت.

چه نیازی بود که ما چابک شویم؟ 

گزارش سال 2007 موسسه Standish Group نشان میداد که قبل از زمان چابک فقط 16% پروژه های نرم افزاری موفق بودند ولی بعد از زمان چابک شدن گزارش گارتنر نشان میداد که 77% پروژه ها موفق بودند. [1][2][3]

تحقیقات سال 2004 فارستر [4] نشان میداد که بعد از چابک شدن:

  • 93% افزایش بهره وری
  • 88% افزایش کیفیت
  • 83% افزایش رضایت ذی نفعان
  • 49% کاهش هزینه
  • 66% کاهش ریسک در برگشت سرمایه

و شاید دلیل اصلی که دنبال چابک شدن بودیم این بود که همه داشتند چابک می شدند و اگر ما نمی شدیم از غافله جا می ماندیم و تصمیم گرفتیم چابک شویم.

شروع بسیار خوبی داشتیم ولی بعد از مدتی:

  • متد مدیریتی فرمان- و – کنترل توسط اسکرام مستر اجرا می شد
  • جلسات روزانه سرپایی اسکرام حالت گزارشی داشت
  • فقط جلسه برگزار می کردیم
  • تعهد یا احترامی در کار نبود
  • نرم افزار کارکننده داشتیم ولی همراه باگ های متعدد
  • زمانی برای تست نداشتیم

کن شوئبر مبدع اسکرام در یکی از مصاحبه های خود گفته است[5] :

من تخمین می زنم 75% از سازمان هایی که از اسکرام استفاده می کنند، در دست یابی به منافعی که از استفاده از اسکرام دنبال آن بودند ناموفق خواهند بود.

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

اگر مقالاتی در مورد “موانع چابک سازی” خوانده باشید یا حتی خودتان تحقیقی روی آن داشته باشید، حتما با موارد زیادی مواجه شدید مانند “فرهنگ سازمان” “مهارت های فنی” و … . ولی در این مقاله سعی شده است از منظر جدیدی این مشکل بررسی شود.

تئوری پنجره شکسته و چابک شدن

فرض کنید روزی از محله خلوتی رد می شوید، در آنجا ساختمانی است که یکی از شیشه های آن شکسته است. روز دوم می بینید که علاوه بر اینکه شیشه شکسته تعویض نشده بلکه یکی دیگر از شیشه ها هم شکسته است. روز سوم می بینید شیشه های بیشتری شکسته است. روز چهارم در می یابید که این ساختمان به حال خود رها شده است و احتمالش زیاد است که شیشه بعدی را شما بشکنید. با اینکه شما انسان به شدت با شخصیتی بودید ولی درگیر یک عارضه اجتماعی شدید که با عنوان تئوری پنجره شکسته[6] شناخته می شود.

تئوری پنجره شکسته زمانی اتفاق می افتد که “خراب کاری” در سیستم (شهر، محصول، پروژه یا …) اتفاق می افتد و “کسی اهمیت نمی دهد” و آن تبدیل به یک رفتار اجتماعی می شود. فلیپ زیمباردو روانشاس استنفورد، در آزمایشی ماشین بدون پلاکی با کاپوت باز در جایی از شهر رها کرد . در طی چند روز کسی با ماشین کاری نداشت. بعد چند روز خود او با میله ای شیشه های ماشین را خرد کرد، کمتر از 24 ساعت مردان و زنان شیک پوشی که از آنجا رد می شدند ماشین را تخریب کردند.

تئوری پنجره شکسته را می توان در جاهای مختلف و در سیستم ها مختلف مشاهده کرد ولی به طور تخصصی می خواهیم در پیاده سازی چابک بررسی کنیم.

کیفیتی که می شکند

شاید اگر درگیر پروژه های نرم افزاری شوید، می بینید که در ابتدای پروژه کیفیت محصول تولیدی بشدت بالا است ولی در گذر زمان این کیفیت بشدت پایین می آید. بعد از مدتی میتوان به وضوح تئوری پنجره شکسته را در آن جا دید.

در خیلی از پروژه ها “سرعت” یا “فشار” بهانه برنامه نویسان برای تولید محصول بی کیفیت می باشد، “این گناه من نبود، مدیر فشار می آورد که باید سریع این قابلیت را ارایه کنید”. بعد از مدتی که کدها به اصلاح “اسپاگتی” شد، یا کدها “بو” دادند. برنامه نویس های حتی خوب هم شروع خواهند کرد به “اسپاگتی” نوشتن. و اینجا هست که رژه مرگ شروع می شود.

وقتی برنامه نویس خوب که تا دیروز سعی می کرد “بهترین کدهای خود را بنویسد، همیشه ریفاکتور کند و …” با دیدن پنجره های شکسته (کدهای کثیف) به عارضه پنجره شکسته دچار خواهد شد.

در اینجا شاهد چنین دیالوگ هایی خواهیم بود “حالا اینهم اینطوری بزن بره بعدا درستش میکنم” یا “حالا کی می فهمه” یا “فعلا وقت نداریم برای رفاکتور” و ….

چابک سازی که می شکند

در آغاز فرآیند چابک شدن همه فکر میکنند که از روز اول باید همه چیز بهترین باشد و زمانی که پنجره های شکسته را می بینند (کد کثیف، نتیجه بد در یک اسپرینت، مشکل در ارتباطات تیمی و … ) به جای تعمیر آنها، شروع می کنند به شکستن پنجره های بیشتر.

اگر ما در اسپرینت های نخستین تست نمی کنیم، دیگر تست نخواهیم کرد و شاید در پروژه بعدی.

اگر کد کثیف می نویسیم، کد تمیز را در پروژه بعدی خواهیم نوشت.

و فرمول”… را در  پروژه بعدی انجام خواهیم داد” و پروژه ای که هیچ وقت از راه فرا نخواهد رسید، مثل همان شنبه ای که می خواهیم تغییر کنیم و هیچ وقت نمی آید.

چابک و دنیای پیوسته ها می باشد

ما در فرآیند چابک چندین پیوسته یا Continuous داریم:

  • Continuous Integration
  • Continuous Deployment
  • Continuous Delivery
  • Continuous Improvement

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

باید این تفکر به وجود بیاید که دفعه بعدی یا فردایی در کار نیست و امروز و همین الان باید (کمی) بهتر شد.

اما بهبود مداوم امروزه در تیم های چابک چگونه انجام می شود؟ شاید در جلسات بازنگری(Retrospective)؟

جلسات بازنگری می تواند تبدیل شود به جایی برای :

  • پیدا کردن پنجره های شکسته
  • سرزنش کردن همدیگر
  • نشان دادن اینکه چابک به درد ما نمی خورد
  • ما تیم یا سازمان بدی هستیم

و تصمیم بگیریم تا پنجره های بیشتری بشکنیم.

به جای تمرکز بر روی کاستی ها و پیدا کردن پنجره های شکسته ابتدا باید بر روی نقاط مثبت یا نقاط قوت تمرکز کنیم. (چه کاری را خوب انجام دادیم؟ چه چیزهایی کار کرد؟)

کشف قدردانی یا Appreciative Inquiry

AI  یک متد با رویکردی تازه برای بهبود سیستم ها و کاتالیز کردن تغییرات می باشد که در سال 1980 توسط دیوید کوپرایدر و همکارانش توسعه داده شده است. این متد با یک سری سوال و مصاحبه شروع می شود که فرآیند کشف می گویند. [7]

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

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

مقایسه رویکرد AI  با رویکرد مشکل محور:

Problem Solving

Appreciative inquiry

Felt need, identification of problem(s)

Appreciating, valuing the Best of What Is

Analysis of Causes

Envisioning what might be

Analysis of possible solutions

Engaging in dialogue about what should be

Action Planning (treatment)

Innovating, what will be

فرآیند Appreciative Inquiry:

این فرآینده شامل 4D معروف می باشد :

  • Discover یا کشف: کشف بهترین ها و چه چیزهایی امروز کار می کند.
  • Dream یا رویا: ترسیم و دیدن آینده ای که می تواند اتفاق بیفتد.
  • Design یا طراحی: برنامه ریزی اینکه آینده چگونه باید باشد.
  • Delivery یا استقرار: پیاده سازی آنچه باید می شد.

بازنگری قدردانی یا Appreciative Retrospective

یکی از بهترین کارها برای بهبود عارضه پنجره شکسته برگزاری جلسات بازنگری به روش Appreciative Inquiry می باشد. [8]

1- هدف گزاری

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

برای مثال: “در طول این جلسه بازنگری، ما راه هایی برای تقویت نقاط قوتمان در کارتیمی پیدا خواهیم کرد”

2- جمع آوری داده

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

برای مثال ” چه کار ما بعنوان یک تیم در اسپرینت گذشته برای تو با ارزش بود؟”

3- ایجاد نگرش

داده های جمع آوری شده، با سوالی برای ایجاد چشم اندازی برای آینده ادامه دهید.

“فرض کنید ما سوار ماشین زمان شده ایم و یک سال به جلو رفته ایم، الان به عنوان بهترین تیم دنیا از ما یاد می کنند. الان در این شرایط چگونه هستم؟ چه شکلی عمل می کنیم و …”

4- تصمیم بگیرید چه کاری می خواهید انجام دهید

در این مرحله چشم انداز ترسیم شده را به مراحل قابل پیاده سازی می شکنید. و تصمیم می گیرید که کدامیک از آنها را چه زمانی پیاده سازی کنید.

 خلاصه

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

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

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

منابع :

1 Standish Group Report: There’s Less Development Chaos Today, by David Rubinstein SD Times March 1, 2007,
2 “Agile Has Crossed the Chasm,” Dr. Dobb’s Journal, July 2, 2007. 3QSMA and Cutter Consortium ROI case study on BMC Software, 2008. 4 Gartner, Inc. 2005
3 Why agile – Rally software development corp
4 “Agile Methodologies: Survey Results,” by Shine Technologies, 2003; 2 Forrester Research, 2004;
5 http://www.agilecollab.com/interview-with-ken-schwaber
6 en.wikipedia.org/wiki/Broken_windows_theory
7 http://en.wikipedia.org/wiki/Appreciative_inquiry
8 Diana Larsen, FutureWorks Consulting – An Appreciative Retrospective

 

درباره اسد صفری

اسد صفری – مربی تحول چابک سازمان و تیم های نرم افزاری. مدارک حرفه ای: CSP - CSM - PSM - PSPO - CDA - Management 3.0 برخی تجربیات: رئیس دفتر تحول چابک شرکت داده ورزی سداد(بیشتر از ده تیم نرم افزاری) - مربی چابک شرکت رامند (تیم های موبایل و گیم سازی) - مدیر تولید نرم افزار SimplyDesk برای شرکت فرانسوی PCI - مربی مشاور شرکت های:خدمات انفورماتیک، ارکید فارمد، فراداده، الفبا برخی از سوابق مشاوره کوتاه مدت و تدریس : علی بابا، فناپ، تجارت الکترونیک پارسیان، بیمه سامان، مهندسین مشاور تجارت (بانک تجارت)، بیمه ایران، پارس آنلاین، شرکت رهنما، ورانگر، انتشارات پزشکی کوثر، فولا آلیاژی یزد، پارک علم فناوری کردستان و ... . عضو انجمن های بین المللی Agile Alliance - Scrum Alliance

1 دیدگاه در “موتور چابک : چگونه باید چابک شد؟

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

این سایت از اکیسمت برای کاهش هرزنامه استفاده می کند. بیاموزید که چگونه اطلاعات دیدگاه های شما پردازش می‌شوند.