بایگانی

Posts Tagged ‘بیانیه چابک’

از اول تا آخر Agile

در این گیرودار که ما در مورد مباحث تخصصی Agile می نویسیم و کنفرانس بین المللی معرفی می کنیم و ده ها کار دیگر در این مابین (یهو) دوستی پیدا می شود و می پرسد (ببخشید : Agile چیه؟ یا من یه برنامه نویس تنهام چطور از Agile استفاده کنم و … ) و خلاصه کاسه و کوزه ما رو بهم میرزه. confused

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

# Agile چیست ؟

# Agile و مدیریت

# اسکرام چیست ؟

# اسکرام و Agile

حرکت به سوی Agile

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

یاشیاسیز

توسعه نرم افزار 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 به دلیل خود سازمانده بودن تیم ها شاهد نفرات و تیم های خوشحال و راضی خواهیم بود. و سازمان نیز بدلیل چابک بودن دارای سود بالایی خواهد بود.

یاشیاسیز

اسکرام فقط Scrum نیست

ژوئیه 4, 2010 3 دیدگاه

https://sirasad.files.wordpress.com/2010/07/head_scratching.jpg?w=422زمانیکه به اولین تجربه خودم در مورد اسکرام فکر می کنم ,  حسابی خنده ام می گیره . اسکرامی که من برای اولین بار یاد گرفتم و آن را درشرکت بر روی یک پروژه پیاده سازی کردم ,  اصلا اسکرام نبود . اسکرام ما کلا به یک Task Board من در آوردی ختم می شد . از جمله اشتباهاتی که در مورد اسکرام داشتم , می توانم به موراد زیر اشاره کنم :

  • Top-Down Management :  همانطور که می دانید یکی از اصول اصلی در Agile و اسکرام Self-Organize بودن نیروی کار(برنامه نویس) می باشد که ما به هیچ وجه چنین اجازه ای به نیروی کار نمی دادیم و شیوه Command-And-Control را با بدترین حالت ممکن به کار می بستیم .
  • طرح ریزی تیمی : به دلیل وجود مدیریت بالابه پایین ,  این مورد هم که امکان نداشت انجام شود . یعنی بنده همه چیز رو طرح ریزی می کردم و به تیم تزریق می کردم که در محیط های چابک بدینگونه عمل نمی شود .
  • تکرارهای کوتاه مدت : در اسکرام که حداکثر طول اسپرینت 4 هفته هست , ما اسپرینت 3 ماهه داشتیم .
  • بازبینی عملکرد : بازبینی عملکرد تیم پس از هر اسپرینت طی جلسه retrospective تقریبا امری است ضروری که ما ,  سال به سال چنین کاری رو انجام نمی دادیم .
  • همکاری با مشتری : همکاری ما خوب بود ولی مشکل ما  این بود : ما باید یک نفر را به عنوان Product Owner داشتیم در حالی که ما 400 نفر Product Owner داشتیم . خاله مدیر شرکت هم نظر می داد .
  • ارائه نرم افزار کارا : یکی از ارزش های اصلی Agile ارائه نرم افزار ارزشمند برای مشتری است به صورتی که نیازهای کسب و کار مشتری را برآورده کند ولی ما فقط در فکر سود و منفعت بیشتر برای شرکت بودیم و کاری نداشتیم که مشتری استفاده می کند یا نه .
  • با انگیزگی تیم : برای توسعه نرم افزار خوب در محیط Agile حتما نیاز به نیروی کار با انگیزه بود ولی در محیط ما چیزی که وجود نداشت انگیزه بود . اعتصاب های گوناگون ,  تاخیر در پرداخت حقوق , تورم ,  سهمیه شده بنزین و … از عوامل کاهنده انگیزه نیروی کار بود .
  • تست نرم افزار : یکی از کارهایی که هیچ وقت انجام نشد ,  نوشتن تست برای بخش های مختلف برنامه بود .
  • تولید کدهای خوب : بدلیل عدم وجود Automate Tests و تغییرات زیاد در طول پروسه توسعه نرم افزار ,  ما در نهایت دارای یک سری کد کثیف بودیم .
  • جوابگویی به تغییرات : یکی از مشکلات اساسی ما همین مورد بود . یا ما جواب نمی دادیم و اگر هم جواب می دادیم در دام Scope Creep می افتادیم . کدهای کثیف تولید می شد , برنامه قابلیت پشتیبانی را از دست می داد .
  • و …

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

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

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

یاشیاسیز

CSM در ایران برای اولین بار

ژوئن 12, 2010 25 دیدگاه

با هماهنگی انجام گرفته با اساتید گرامی و بین المللی Scrum و Agile  از کشور سوئد خواهان برگزاری یک دوره CSM یا Certificated Scrum Master برای اولین بار در ایران و کشور های همجوار هستم . این دوره شامل آموزش کامل متد اسکرام طی 2 روز و اعطای مدرک CSM خواهد بود . امید است که بتوانیم این دوره را به نحو احسنت در ایران برای بار اول برگزار کنیم .البته این دوره در شرایطی برگزار خواهد شد که تعداد شرکت کننده در این دوره به حد نصاب برسد .

CSMhttps://sirasad.files.wordpress.com/2010/06/logo-certified-scrum-master-seal.jpg?w=260 چیست ؟

CSM مخفف Certificated Scrum Master می باشد و به کسی اطلاق می شود که مدرک Scrum Master بودن را داشته باشد . Scrum Master شخص اول و در واقع  برپا کننده و گرداننده اسکرام در تیم های توسعه نرم افزا می باشد و کل اسکرام بر پایه این اسکرام مستر خواهد بود  . CSM یک مدرک بین المللی و معتبر برای کسانی خواهد بود که می خواهند به عنوان اسکرام مستر در تیم های توسعه نرم افزار فعالیت داشته باشند .

مدرک CSM از طرف تشکل معتبر Agile Alliance به اسکرام مستر های عزیز اعطا خواهد شد و بدلیل معتبر بودن این مدرک در تمام جهان ,  شما به راحتی خواهید توانست در این رشته شغلی در هر کجای این کره خاکی مشغول به کار شوید .

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

  • آموزش کامل متد اسکرام طی کلاس ها ,  سمینار ها و کارگاههای عملی
  • رفع اشکال در مورد Agile و اسکرام به همراه اساتید جهانی این حوزه
  • دریافت مدرک بین المللی Scrum Mater
  • امکان اشتغال زایی به عنوان Scrum Master در تیم های توسعه نرم افزار

CSM در کشورهای دیگر چگونه است ؟

این مدرک در اکثر کشورهای پیشرفته جهان توسط تشکل Agile Alliance ارائه می گردد ولی در منطقه کشور ما فقط در کشور ترکیه و کشور هند ارائه می شود . منتهی در هر دو کشور با هزینه گزافی روبرو خواهید شد . برای مثال فقط خود دوره CSM در کشور ترکیه معادل مبلغ 1500 دلار آمریکا هزینه در بر خواهد داشت . این مبلغ را باید بعلاوه هزینه سفر (رفت و برگشت به ترکیه) و بعلاوه هزینه اقامت به مدت چند  روز و بعلاوه هزینه های متفرقه که در چنین کشورهایی خرج می شود باید بکنید .

فرق این دوره با دوره های کشور های همجوار چه خواهد بود ؟

دو فرق اساسی این دوره با دوره های کشورهای خارجی خواهد داشت :

  1. هزینه پایین: به خواهش بنده حقیر و بدلیل اولین برگزاری این دوره در ایران و با مساعدت  Agile Alliance این دوره با هزینه بسیار کم و شاید یک دهم کشورهای دیگر برگزار خواهد شد و تمام در آمدهای حاصله , خرج سفر اساتید گرامی ,  هزینه اقامت آنها  ,  هزینه محل برگزاری دوره و هزینه های متفرقه خواهد شد و به صراحت عرض می کنم بدلیل علاقه بنده به Scrum و تمایل به نهادینه کردن آن در ایران , بنده قصد درآمدزایی از این دوره را ندارم و فقط قصدم برگزاری این دوره در ایران می باشد .
  2. مدرسین : به جرات می توانم عرض نمایم مدرسینی که به امید خدا در خدمت آنها در ایران خواهیم بود ,  جزو اساتید جهانی و معروف حوزه Agile و Scrum  می باشند . ولی در کشورهای همجوار این دوره توسط اساتید بومی آنجا و با سطح بسیار نازل برگزار می شود .

در مورد اساتید دوره :

به احتمال زیاد ما در ایران در این دوره در خدمت دو تن از اساتید سوئدی اسکرام خواهیم بود  که هر دوی آنها کاربلد و در این حوزه از چهره های سرشناس جهانی می باشند . یکی از این برادران دوست عزیز Henrik Kniberg می باشد . این برادر پیشینه عریض و طویلی در زمینه اسکرام و Agile دارد ,  کتاب Scrum and XP from the Trenches او به جرات می توان گفت بهترین و روانترین کتاب در زمینه اسکرام می باشد . برای اطلاعات بیشتر در زمینه وی می توانید به این لینک مراجعه کنید .

هزینه دوره :

همانطور که در بالا عرض شد این دوره به دلیل اولین بار بودن آن با هزینه بسیار کم برگزار خواهد شد (شاید در دفعات بعدی بدین گونه نباشد) . این دوره در کشورهای مختلف با هزینه های مختلفی برگزار می شود : برای مثال این دوره در کشور سوئد با مبلغ 1500 یور برای هر نفر و یا در کشور ترکیه با مبلغ 1500 دلار آمریکا برای هر نفر برگزار می شود : ولی این دوره با حسن نیت دوستان به مبلغ 600-750 دلار کاهش یافت که مبلغ نهایی مابین این رنج خواهد بود .

ظرفیت دوره :

به دلیل اینکه دوره شامل کارگاههای آموزشی هم خواهد بود پس امکان حضور تعداد زیادی از دوستان نخواهد بود . حداکثر 20- 30 نفر قابل پذیرش خواهیم بود . اما اگر تعداد ثبت نام کننده بیش از این تعداد شد و به حد نصاب دو گروه برسد ,  این دوره در دو گروه مجزا برای رفاه حال دوستان برگزار خواهد شد .

محل برگزاری دوره :

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

زمان برگزاری :

زمان برگزاری دوره در اوایل دی یا اوایل بهمن خواهد بود و مدت دوره 2 روز می باشد .

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

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

  • مدیران شرکت های توسعه نرم افزار
  • متخصصان توسعه نرم افزار(برنامه نویس ,  تحلیل گر , آزمایشگر و… )
  • مدیران پروژه

نحوه شرکت در این دوره :

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

پ . ن : از یکی از دوستان عزیز ساکن در تهران که توانایی رزرو مکان برگزاری این دوره را در یکی از هتل های خوب تهران با امکانات لازم برای این دوره را دارا می باشد وتمایل همکاری دارند لطفا با بنده با ایمیل safari_asad[at]yahoo[dot]com مکاتبه نمایند ,  بدیهی می باشد که در هزینه دوره این عزیز تخفیف ویژه ای در نظر خواهیم گرفت .

یاشیاسیز

چابک سازی سازمان و چرا ها

مه 18, 2010 5 دیدگاه

https://sirasad.files.wordpress.com/2010/05/agile.jpg?w=592طی درخواست یکی از مدیران شرکت توسعه نرم افزار پ .س (اسم نبردم شاید علاقمند نباشند) در مورد امکان مشاوره و مربی گری Agile بنده برای آن شرکت , 3 سوال اساسی توسط ایشان مطرح گردید که در این پست قصد طرح و جواب دادن این سوالات را دارم  . به این دلیل که شاید دیگر مدیران و یا اشخاص که علاقمند به دانستن و آشنایی با این مسئله باشند این جواب به صورت سرگشاده ارائه گردید .

سوالات مطرح شده به قرار زیر می باشد :

  • یک سازمان چه پیش فرض ها و نیازمندی هایی برای Agile شدن نیازدارد؟
  • برنامه من برای Agile کردن سازمان چیست ؟
  • عواید و منافع این کار برای سازمان چه چیز می باشد و چگونه می توان آن را اندازه گرفت؟

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

https://sirasad.files.wordpress.com/2010/05/a305-distributed-agile-development.jpg?w=280خوب بیان این مسئله و جواب سوال , » برای اینکه Agile بشویم چه چیز می خواهد»  در واقع بسیار سخت و مشکل می باشد بدلیل اینکه شرایط از هر تیم به تیم دیگر متفاوت خواهد بود و نمی توان یک نسخه واحد پیچید . ولی می توان گفت که Agile شدن برای تیم ها سختی و راحتی خواهد داشت . یعنی اینکه یک تیم با شرایط راحت تر و کم هزینه تر خواهد توانست Agile شود و یک تیم سخت و پر هزینه تر Agile خواهد شد . پس می توان گفت همه تیم ها و سازمان ها  شاید  توانایی Agile شدن را خواهند داشت ولی با درجه سختی متفاوت .

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

برای درک مسئله بهتر است یک مثال زده شود . فرض کنید بنده در تلویزیون مسابقه دو (دوندگی) را می بینم و مشاهده می کنم که به فرد برنده 400 میلیون دلار جایزه می دهند . با توجه به جایزه خوب وسوسه می شوم فردا در دوی مارتن شرکت کنم ولی بدون آمادگی و ارزیابی توانایی ها و ظرفیت های خودم . زمان مسابقه چند صد متر ندویده خسته می شوم و خواهم ماند . در این حالت دو حالت خواهم داشت :1- خواهم توانست تا به خانه برگردم و از دیدن مسابقه در تلویزیون لذت ببرم  2- ایست قلبی می کنم  و خداحافظ.

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

در مورد مثال دونده یک راه سومی هم وجود دارد و آن هم این است که من به موقع و در زمان مناسب در مارتن شرکت کنم . خوب عرض شد زمان مناسب ؟ زمان مناسب در این مثال این است که بنده به پیش یک مربی  دومیدانی بروم و او بنده را عرض یابی نماید و با توجه به توانایی جسمانی و روحانی بنده  ,  بنده را مورد آموزش و تمرین قرار دهد . زمانی که به توانایی لازم رسیدم می توانم در مارتن شرکت کنم . پس منتظر زمان مناسب خواهم بود .https://sirasad.files.wordpress.com/2010/05/tired_runner-758783.jpg?w=200

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

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

ولی شاید توضیحات بالا تعدادی از مدیران را قانع نکند و آنها به دنبال فهمیدن و نام بردن چند عامل به صورت موردی می باشند .  خوب من می توانم چند مورد عمومی زیر را نام ببرم :

Agile می تواند در محیط ها و شرایط  زیر راحت ترو بهتر اعمال شود (و Agile کلا مناسب حال شرایط زیر می باشد) :

  • ارائه های اورژانسی : در بعضی از موارد هنگام توسعه نرم افزار باید نرم افزار به صورت زود به زود به مشتری ارائه شود در غیر اینصورت مشتری لنگ خواهد ماند . یعنی هم نرم افزار توسعه یافته می شود و هم توسط مشتری استفاده می شود .
  • کمبود اطلاعات و نیازمندی های پروژه یا محصول  در هنگام شروع پروژه و در فاز برپایی یا Initiate پروژه
  • در دسترس بودن همیشگی مشتری
  • نیروی انسانی سازگار
  • نیروی های انسانی در یک جا مستقر باشند
  • تیمی که واقعا تیم باشد

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

  • کمبود دانش Agile
  • تیم های بسیار بزرگ
  • توسعه به صورت توزیعی و گسترده به صورت فرا محلی
  • قراردادهای بسته (از نظر قیمتی و دامنه پروژه)
  • نیروی کار نابلد و یا نیروی کار تازه وارد و تازه تیم شده
  • حرکت به صورت سریع

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

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

اما در مورد سوال دوم . سوال شده است که برنامه بنده برای انتقال سازمان ها به Agile چه می باشد؟

برنامه و طرح بنده برای ارائه و کمک به سازمان ها برای انتقال به Agile شامل موارد زیر می تواند باشد:

  • بررسی سازمان و تعیین وضعیت فعلی سازمان
  • آموزش و نهادینه سازی ارزش ها و اصول Agile
  • آموزش اسکرام
  • برگزاری کارگاههای آموزشی در مورد متد اسکرام و XP
  • برپایی و استارت Agile در سازمان
  • بررسی وضع و نظارت بر عملکرد
  • برگزاری جلسات بازبینی عملکرد و تعیین روش های بهبود وضعیت

در حالت کلی برنامه در 4 سطح قابل تعریف خواهد بود : 1- بررسی 2- آموزش 3- اجرا 4- بازبینی

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

ولی در کل هدف ما ارائه و عمل به مفهوم زیر در هر سازمان Agile خواهد بود :

https://sirasad.files.wordpress.com/2010/05/agilegoal.jpg

از طریق انجام و عمل به مفاهیم و اصول اصلی Agile خواهیم توانست به استراتژی درون سازمانی برسیم . مثلا با عمل به اصل «قبول و پذیرایی از تغییرات » که یکی از اصول Agile می باشد و در برنامه ما هم خواهد بود خواهیم توانست به یکی از استراتژی های اصلی سازمان که «ابقاء مشتریان » می باشد دست بیابیم  , که تحقق هر استراتژی سازمان مصادف با نزدیکی به هدف سازمان می باشد ,  که هدف سازمان شامل سود و منافع بیشتر می باشد .

اما در مورد سوال سوم . پرسیده شده است : «عواید و منافع Agile شدن  برای سازمان چه چیز می باشد و چگونه می توان آن را اندازه گرفت؟»

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

https://sirasad.files.wordpress.com/2010/05/agilechart.jpg?w=592

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

دانشی که از نمودارهای بالا حاصل شد گواه این قضیه خواهد بود که نباید انتظار داشته باشیم در چند روز به بهره وری مناسب  و بالا برسیم  . حتی باید منتظر پایین آمدن بهره وری هم باشیم . در همین باب در کتاب پنج دشمن کار تیمی می خوانیم :» برای جوش خوردن درست استخوان شکسته یک انسان ,  شاید لازم باشد دوباره آن راشکست و دوباره به هم متصل کرد و این درد آور خواهد بود ولی لازم است » .

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

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

شرکت  VersionOne در سال 2007 آمارگیری در زمینه Agile انجام داد . در این آمارگیری 1500 نفر از 71 کشور مختلف حضور داشته اند . در این آمارگیری VersionOne خواسته تا بداند این 1500 نفر در شرکت هایشان که با Agile کار می کنند تا چه حد موفق بوده اند و نتیجه آمارگیری به صورت زیربوده است : (شاید قابل باور نباشد)

https://sirasad.files.wordpress.com/2010/05/agilebenefit.jpg

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

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

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

یاشیاسیز

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

آوریل 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 های خوبی داشته باشیم .

یاشیاسیز