Archive

Posts Tagged ‘Agile manifesto’

خروجی کارآ در Agile

دسامبر 13, 2010 8 دیدگاه

در پست قبلی در تعریف Agile Software Development بیان شد که خروجی اصلی Agile نرم افزار یا محصول کارآ می باشد و منظور از محصول کارآ نرم افزاری می باشد که بتواند نیازهای کسب و کار مشتری را به بهترین نحو پاسخ گو باشد.

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

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

https://sirasad.files.wordpress.com/2010/12/dsc00003.jpg?w=592

شکل بالا (به خاطر بی کیفیت بودن شکل عذر خواهی می کنم) نشانگر روند توسعه نرم افزار در متدهای قدیمی می باشد. همانطورکه قابل ملاحظه است مشتری در فاز ابتدایی پروژه اقدام به سفارش محصول A می کند و تیم توسعه بر حسب این سفارش اقدام به پیاده سازی بر اساس قرار داد مندرج می کند. بالاخره خروجی فاز توسعه بعد از مدت زمانی آماده و تحویل مشتری می شود. اما مشتری در هنگام استفاده از خروجی فاز توسعه متوجه می شود که «این آنی نیست که من می خواستم یا این آنی نیست که بتواند نیاز های من را رفع کند» . به طور خلاصه این محصول برای مشتری ناکارآمد می باشد.

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

اما در محیط Agile برای این که بتوانیم همان محصول را به گونه کارآ توسعه دهیم می توانیم به گونه زیر عمل نماییم:

https://sirasad.files.wordpress.com/2010/12/dsc00004.jpg?w=592

همانطور که کاملا واضح است پروژه با Vision محصول A شروع می شود ولی در انتها مشتری صاحب محصول B است زیرا تیم توسعه و مشتری طی تعاملات دائمی در طول Iteration ها دائما در حال یادگیری هستند (یادگیری اینکه Business Value در چه سمتی و با چه محصولی به حداکثر خود خواهد رسید؟). اگر در شکل دقت نمایید متوجه می شوید  طی Iteration  ها به جای اینکه به جلو برویم (به طرف A ) کم کم به طرف B متمایل می شویم (محصول کارآ) . حتی در Iteration های آخر شاهد یک ثبات حرکتی هستیم که فقط و بدون تغییر جهت به سمت هدف حرکت می کنیم(بالاترین حد یادگیری).

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

البته با مقایسه اشکال بالا به نکات موثرتری پی خواهید برد.

یاشیاسیز

توسعه نرم افزار Agile

دسامبر 8, 2010 7 دیدگاه

Agile Software Development یا توسعه نرم افزار چابک چیست؟

Agile مجموعه ای از ارزش ها و اصول جهت توسعه نرم افزار های کارا توسط تیم های خود سازمانده می باشد. ارزش ها و اصول Agile در سال 2001 توسط 17 نفر از اساتید معتبر جهانی صنعت توسعه نرم افزار طی یک بیانیه با عنوان بیانیه توسعه چابک تنظیم و ارائه گردید. اساس و هدف این اصول و ارزش ها ارائه نرم افزار کارا و یا محصول کارآ به مشتری می باشد.

اما چه نیازی به روش Agile بود؟! به عبارتی چه شد که این 17 نفر (بعلاوه چند ده نفر دیگر که به صورت غیر مستقیم در این بیانیه تاثیر داشتند) در سال 2001 اقدام به انتشار چنین روشی کردند!؟

جواب کاملا واضح است: ضعف های موجود در روش های سنتی باعث شد که این دوستان روش Agile را معرفی نمایند.

روش های سنتی و یا موجود چه مشکلاتی داشتند؟

روش های موجود آن زمان (و فعلی این زمان ایران) که بیشتر به صورتی فاز به فاز عملیات اجرا می شد و نتیجه کار از قبل به صورت یک طراحی اولیه دقیق (Up-front Design) پیش بینی می شد یک سری ایراد اساسی و کلی داشت :

  • صرف زمان زیاد و در واقع اتلاف زمان برای طراحی Up-front در فاز اولیه پروژه
  • مشخص نبودن و واضح نبودن نیازمندی ها بدلیل ارتباطات کاغذی به جای ارتباطات چهره به چهره و کج روی های متعاقب
  • بالا بودن هزینه تغییرات
  • به طول انجامیدن پروژه و گذر از زمان تعیین شده در حد بسیار زیاد در بسیاری از پروژه ها
  • عدم وجود زمان برای آزمایش محصول و متعاقبا محصولات پر از باگ و بدون کیفیت
  • عدم شفافیت در پروسه توسعه و تولید : هیچ کس حتی مدیر پروژه نمی دانست که چقدر از محصول مورد نظر تکمیل شده است؟ چه اهدافی باقی مانده است؟ و … .

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

به این دلیل که عملکرد این پروسه ها بر اصل Anticipation یا پیش بینی استوار بود. در Anticipation یک سری موارد بر روی کاغذ و به عنوان قرار داد بسته جهت پیاده سازی تحویل تیم توسعه داده می شد و تیم توسعه موظف می شد در یک زمان مقرر و با یک منابع مشخص و ثابت این وظایف را پیاده سازی نماید. این اصل  همراه خود در بردارنده طراحی دقیق اولیه یا Big Design Up-Front بود (همان صحبت معروفی که شاید شنیده باشید :»ما اگر 1 سال وقت داشته باشیم 10 ماه آن را برای تحلیل و طراحی و  2 ماه آن را برای پیاده سازی صرف می کنیم).

Big Design Up-Front خوب است ولی در جایی که همه چیز ثابت باشد و نیازی به تغییر نداشته باشیم ولی آیا به راستی در جهان واقع و در اکثر پروژه هامان نیاز به تغییر نداریم؟!

زمانیکه در پروژه ای Up-Front Design می شود مسلما فاز تست آخرین فازی خواهد شد که بر روی محصول انجام می شود. ولی آیا این فاز تاثیر گذار می تواند باشد؟ محصولی که کامل ساخته شده است تزریق کیفیت به آن ساده نیست و در بعضی از موارد غیر ممکن خواهد بود. بهتر است به جای این , محصول با کیفیت ساخته شود و نه کیفیت به آن در آخر پروژه تزریق شود.

درکل اصل Anticipation که متد های آن زمان , بر آن استوار بودند رابطه ی خوبی با تغییر نداشتند زیرا آن ها عادت داشتند همه چیز را از قبل پیش بینی کنند و تغییر برای آنها بسیار هزینه بر بود. اما چرا تغییر برای آن پر هزینه بود؟ زیرا آنها تغییرات و کج روی های خود را خیلی دیر متوجه می شدند (اکثرا در آخر پروژه) و در محور زمان هر چقدر تغییر و یا مشکل دیر کشف شود رفع و یا ایجاد آن مشکل تر – پیچیده تر و پرهزینه تر خواهد بود. به همین دلیل آنها تغییر را رد می کردند.

رد کردن تغییر به منزله ناکارآمد کردن محصول و خروجی پروژه می باشد. هر تغییر و یا اصلاحی که در محصول نیاز می شود برای تکمیل و کارآمدتر کردن آن می باشد : به این دلیل که مشتری نیازمند تغییر است (زیرا تجارت او در حال تغییر است و یا اصلا او در شناخت نیازها اشتباه کرده است و یا هر چیز دیگری)  و اگر تغییر انجام نشود محصول به درد تجارت و کسب وکار مشتری نخواهد خورد و اگر تغییر نیز انجام شود هزینه آن بالا خواهد بود , که در این صورت هم پروژه به صرف نخواهد بود.

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

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

نقطه عکس حالت Anticipation حالت Adaptation می باشد که Agile بر آن استوار می باشد.

در Adaptation به جای یک طراحی دقیق و برای سازگاری بیشتر محصول با نیاز های واقعی مشتری از Real-Time Planning و Emergent Design استفاده می شود. یعنی به حد کافی در زمان های مناسب نیازمندی هایی از طریق ارتباط چهره به چهره دائم و فیدبک مشتری دریافت می شود که فقط آنها بر اساس عکس بزرگ محصول برنامه ریزی و طراحی می شوند و نه بیشتر.

Iterative و Incremental بودن روش Agile فرصت مغتنمی برای ایجاد یک بستر Adaptation به وجود آورده است. بدین صورت که محصول به صورت Incremental ساخته می شود و در Iterative های معلوم و کوتاه در اختیار مشتری قرار داده می شود  در هر تکرار و یا چرخش فیدبک های مشتری به عنوان نیازمندی های جدید وارد پروسه توسعه می شوند که بدلیل فیدبک های دائم و زود هزینه تغییرات بسیار پایین خواهد آمد.

علاوه بر این در Agile بدلیل Incremental بودن , پروسه آزمایش  و یا Test به صورت یکپارچه با توسعه بخش ها انجام می شود که این نوید دهنده یک محصول با کیفیت در هر Release خواهد بود. به عبارت ساده تر به جای تزریق کیفیت ,  بخش ها را با کیفیت می سازیم که این هم هزینه نگه داری هر بخش را کاهش می دهد و هم محصول نهایی با کیفیت می شود و هم تغییرات قابل اجرا خواهند بود. در حالی که در روش Anticipation پروسه Test در فاز آخر انجام می شد.

به طور کلی برای ویژگی یک متد بر پایه Adaptation می توان موارد زیر را بر شمرد :

  • Real-Time Planning
  • Emergent Design
  • Integrated Testing
  • Collaborative Discussions
  • Just-in-Time & Just-Enough Requirements

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

ارزش های توسعه نرم افزار چابک

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

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

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

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

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

در کنار ارزش های سازمان چابک 12 اصل چابک نیز وجود دارد که سازمان های چابک برای دست یابی به ارزش های چابک می توانند پیرو آن اصول باشند:

اصول بیانیه چابک
ما از این اصول پیروی می کنیم :

بالاترین اولویت ما رضایت مشتری از طریق
تحویل به موقع و مداوم نرم افزار ارزشمند می باشد

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

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

ذینفعان تجاری و توسعه دهندگان باید هر روزه در
طول پروژه با هم کار کنند

پروژه ها را بر روی افراد با انگیزه بنا کنید. محیط لازم را
به آنها بدهید و از نیازهای آن ها پشتیبانی نمایید وبه
آنها اعتماد نمایید تا کارها را انجام بدهند

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

نرم افزار کارکننده اصلی ترین معیار پیشرفت می باشد

فرآیند های چابک توسعه پایدار را ترویج می دهند.
حامیان مالی , توسعه دهندگان و کاربران باید قادر به
حفظ سرعت پیشرفت ثابتی براى يک مدت نامحدود باشند

توجه مداوم به برتری فنی و طراحی خوب باعث
افزایش چابکی می شود

اصل سادگی ضروری می باشد

بهترین معماری ها , نیاز مندی ها و طراحی ها از تیم های
خود سازمانده پدید آور می شود

در فواصل منظم , تیم برچگونگی موثرتر شدن تامل وتفکر می نماید
و سپس تیم رفتار خود را بر اساس بازتاب این تفکر تنظیم و هم سو می نماید

جمع این ارزش ها و اصول در یک سازمان باعث چابک شدن آن سازمان می شود. البته به این نکته توجه نمایید که سازمان چابک کار نمی کند بلکه چابک می شود.

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

برای چابک شدن باید در پروسه توسعه و یا حتی سطوح کلان سازمان مانند مدیریت منابع انسانی پروژه و یا هر سطحی ارزش های و اصول چابک رعایت شوند و در نظر گرفته شوند. به عبارتی باید همه سازمان چابک شود و نه فقط بخش یا واحد توسعه نرم افزار. به همین دلیل حرکت سازمان به سمت Agile را تغییر یا Change گفته نمی شود و از اصطلاح Transformation یا تحول استفاده می شود. یعنی باید سازمان در راه چابک شدن متحول شود.

برای اینکه بتوان به سطحی از چابکی دست یافت می توان از Practice های Agile مانند Scrum , XP , Crystal و یا … بهره جست . در همین رابطه پیشنهاد می کنم این مطلب را مطالعه کنید: ربط اسکرام با Agile.

نتیجه گیری

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

یاشیاسیز

Succeeding with Agile

ژوئن 28, 2010 ۱ دیدگاه

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

مایک حدودا 15 سال در زمینه Agile طی کار در ایالات آمریکا و اروپا تجربه اندوخته است . او نتیجه 15 سال کار در زمینه Agile را کتابی کرده است که نام آن Succeeding with Agile می باشد . نگارش این کتاب برای مایک 4 سال به طول انجامیده است که واقعا جای بسی تشکر دارد .

https://sirasad.files.wordpress.com/2010/06/rotator.jpg

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

همانطور که  مایک در مقدمه کتاب می نویسد : این کتاب برای کسانی که می خواهند با اسکرام و یا Agile آشنا بشوند مناسب نیست , در این کتاب نحوه رسم Burdown Chart آموزش داده نمی شود و یا شما تعریفی برای Product Backlog پیدا نخواهید کرد . این کتاب برای کسانی مناسب می باشد که آشنایی خوبی با Agile و Scrum دارند و در اینجا صحبت های تکمیلی انجام خواهد شد .

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

و در آخر , امضای جناب Mike Cohn بر روی این کتاب برای بنده

https://sirasad.files.wordpress.com/2010/06/dsc000331.jpg?w=592

یاشیاسیز

بیانیه توسعه چابک این بار به فارسی

آوریل 29, 2010 7 دیدگاه

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

https://sirasad.files.wordpress.com/2010/04/build-fast.jpg?w=550

شاید بعضی از دوستان  اصلا ندانند که Agile Manifesto چیست ؟!

Agile manifesto بیانیه توسعه نرم افزار چابک می باشد . این بیانیه مشخص کننده اصول و قواعد و مرامنامه Agile به شمار میرود . این بیانیه توسط بزرگترین و کاربلدترین افراد دنیا در زمینه توسعه نرم افزار تهیه و تنظیم و تصویب و در اختیار ملت قرار گرفته است . تمام متد های Agile (اسکرام , XP ,  کریستال و…) به این بیانیه وفادار می باشند و در واقع همه آنها بر اساس این بیانیه و سند بنا نهاده شده اند .

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

https://sirasad.files.wordpress.com/2010/04/agilealliance_logo.jpg?w=200چندی پیش Agile Alliance بنابه اهمیت این بیانیه تصمیم گرفته اند در یک اقدام بزرگ و جهانی ,  این بیانه را به تمام زبان های جهان ترجمه و در اختیار تمام ملت ها با هر زبانی قرار دهند . بنده نیز با توجه به تجربه اندکی که در زمینه Agile داشتم و با توجه به نیاز کشور به چنین چیزی و از همه مهمتر عقب نماندن از صف کشورهای مدعی در زمینه Agile تصمیم به همکاری با Agile Alliance جهت ترجمه و ارائه بیانیه توسعه چابک به زبان فارسی برای تمام ایرانیان کردم .

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

مشاهده متن اصلی این بیانیه

مشاهده متن بیانیه به زبان فارسی مشاهده دوازده اصل چابک به زبان فارسی

مشاهده پروسه زبان های در حال ترجمه

یاشیاسیز

دسته‌ها:Agile برچسب‌ها: ,

بازنگری در اسکرام

آوریل 23, 2010 5 دیدگاه

واژه «بازنگری» را با کمک یک دوست عزیز توانستم معادل واژه گرانبهای Retrospective پیدا نمایم .{ بدلیل اینکه معادل فارسی مناسب و معنی رسان نیست از خود کلمه Retrospective استفاده خواهد شد} .

Retrospective یکی از مهم ترین و مقدسترین واژه ها در فرهنگ Agile می باشد به صورتی که در آیه دوازدهم بیانیه چابک به صورت واضح به اهمیت این مسئله اشاره شده است . در این آیه چنین می خوانیم :

At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly

بیانیه چابک – Agile Manifesto – اصل دوازدهم

در این پست قصد دارم این اصل راتفسیر و تشریح نمایم .  اگر پست اسکرام ساده شده را کامل خوانده باشید خواهید دانست که در این پست تا آنجا رسیدیم که Sprint planning را انجام دادیم و شروع به کار کردیم . حالا زمانی که Sprint تمام شد و دمو به مشتری ارائه شد باید کار مهمی به نام Retrospective انجام شود . https://sirasad.files.wordpress.com/2010/04/retro.jpg?w=475

Retrospective چیست ؟

به عبارت ساده یعنی نگاه به عملکرد تیم در sprint قبلی و بررسی عملکرد ها و نتیجه گیری برای بهبود بخشی به عملکردها و تغییر رفتار نسبت به نتیجه گیری انجام شده در Sprint های بعدی .

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

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

اصل مورد نظر از 3 بخش تشکیل شده است : بخش اول : At regular intervals یعنی در فواصل معین . همانطور که گفته شد فاصله ما بعد از ارائه دمو به مشتری و آخر هر اسپرینت می باشد. پس ما در اسکرام خودمان برای انجام Retrospective  یک فاصله معین داریم .

بخش دوم : the team reflects on how to become more effective به این معنی که تیم می فهمد که چگونه می تواند عملکرد خود را بهبود ببخشد همان بخش کلاه و جوراب و قاضی ما می شود .

بخش سوم : then tunes and adjusts its  behavior accordingly به این معنی که رفتار خود را در اسپرینت های بعدی نسبت به تصمیماتی که گرفته شد همسو و همساز می سازیم.

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

Retrospective چگونه انجام می شود ؟

Retrospective همانند همه جلسات دیگر اسکرام انجام خواهد شد به صورتی که تمام اعضای تیم توسعه و Product Owner و شخص Scrum Master هم باید حضور داشته باشد . شروع جلسه با اسکرام مستر خواهد بود .او خلاصه ای از اسپرینت انجام شده و تصمیمات مهمی که طی این اسپرینت گرفته شد بیان خواهد کرد .  اساس کار برروی Sprint Backlog خواهد بود . هر یک از اعضای تیم فرصت این را خواهند داشت که در مورد Story ها صحبت کنند .  برای بحث بهتر ما یک وایت برد را تبدیل به یک Retrospective Board می کنیم : (مانند عکس زیر)

https://sirasad.files.wordpress.com/2010/04/retroboard.jpg?w=592

همانطور که گفته شد اساس برپایه Sprint Backlog خواهد بود . یک  Story از Sprint Backlog برداشته خواهد شد و بر اساس نظرات تیم در یکی از ستون های Retrospective Board قرار خواهد گرفت  و همین طور تا آخر. ستون اول آنهایی هستند که مشکل خاصی نداشتند و همه راضی هستند . ستون سوم آنهایی هستند  که مشکل دار می باشند و باید حتما مشکل آنها مورد آنالیز قرار گرفته شود و نتیجه گیری انجام شود(مثلا مواردی که پیاده سازی آنها بیش از برآورد انجام گرفته طول کشیده است) . مواردی که نه در ستون اول و نه در ستون سوم قرار ندادید را به ستون دوم انتقال بدهید .ستون دوم بعد از اینکه پر شد باید دوباره خالی شود بدین صورت که  با یک نظرخواهی از گروه موارد ستون دوم را به ستون اول و یا ستون سوم منتقل کنید .

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

یک مسئله اساسی که شما هم به آن اشاره نمی کنید این است که اگر ما مسائل فنی تیم خودمان را در Retrospective بازبینی و اصلاح می کنیم چرا باید Product Owner حضور داشته باشد ؟ زیرا امکان دارد و بسیار هم امکان دارد ما از دل جلسات Retrospective به ایده های جدید و اصلا به نیازهای جدید دست پیدا کنیم . یعنی در آنالیز ما می فهمیم که باید فلان نیازمندی هم باشد که به اطلاع Product Owner رسانده می شود و او با بررسی نیازمندی  می تواند به نیازمندی مربوطه با توجه به نیازهای قبلی که در Product Backlog لیست شده اند , اولویت بدهد. علاوه بر این  تیم برروی این نیازمندی برآوردی انجام می دهد و  پس از برآورد و اولویت بندی , نیازمندی مربوطه به درون Product Backlog انتقال داده می شود تا در یکی از Sprint ها پیاده سازی شود .

امیدوارم بتوانید و بتوانیم Retrospective های خوبی داشته باشیم .

یاشیاسیز