بایگانی

Posts Tagged ‘متدلوژی’

کارگاه آموزشی اسکرام

ژوئیه 27, 2012 بیان دیدگاه

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

عنوان کارگاه : کارگاه دو روزه اسکرام

مخاطبین : همه (همه که گفته می شود یعنی همه حتی کسانی که در دپارتمان توسعه نرم افزاری هم نیستند)

مدت : 2 روز هر روز 9 ساعت

مکان : در سایت سازمان یا شرکت درخواست کننده

scrumworkshop.jpg (803×525)

مطالب ارئه شده در این کارگاه به صورت خلاصه بدین صورت می باشد :

روز اول

  • مقدمات
  • مقدمه ای از Agile  و Scrum
  • اسپرینت 1
  • چارچوب اسکرام : 1
  • نقش ها و مسئولیت ها
  • مصنوعات اسکرام
  • رویدادها و Time Boxes
  • اسپرینت 2
  • چارچوب اسکرام : 2
  • مترهای اسکرام
  • بیشتر در مورد نقش ها ، مصنوعات و رویدادها
  • خود سازماندهی (Self-Organization)

روز دوم

  • اسپرینت 3
  • برنامه ریزی و طرح ریزی در اسکرام
  • Planning Levels
  • Estimating Software Development
  • Owning a Product Backlog
  • Defining Done
  • اسپرینت 4
  • شروع اسکرام (بحث هایی در مورد نحوه شروع اسکرام و ملزمات)
  • Getting Started
  • Starting
  • سلامت نگه داری اسکرام
  • What Scrum Is and Is Not
  • Monitoring Your Health
  • Patterns of Healthy Scrum Teams
  • ScrumBut

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

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

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

شرکت های یا سازمان ها یا آموزشگاها در سراسر کشور که خواهان استفاده از این کارگاه آموزشی می باشند می توانند از طریق آدرس ایمیل asad.safari در Gmail.com  یا با شماره تلفن 0914-912-0914 تماس حاصل نمیاند.

چابک و موفق باشید

Advertisements

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

مه 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 با آن سنجید و درصد پیشرفت را مشخص کرد .

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

یاشیاسیز

Scrum Game Pack

مه 12, 2010 3 دیدگاه

در راستای گسترش تفکر چابک و اشاعه فرهنگ Agile و آموزش Scrum تصمیم به تولید بسته آموزشی با نام Scrum Game Pack کردیم . این بسته آموزشی شامل یک بازی اسکرام می باشد که برای تیم های اسکرام و یا Agile بسیار سودمند و یاد دهنده است .

آیا می خواهید در مورد موارد زیر یاد بگیرید (البته هم تیم و هم خودتان) ؟

  • بازی Planning (همان Sprint Planning در اسکرام)
  • سرعت سنجی تیم (Velocity)
  • برآورد User Story ها (story estimation)
  • تکرار های کوتاه مدت (short releases)
  • و نحوه معرفی موارد بالا در کمپانی و سازمان ها

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

Scrum Game یک پک بازی است  که به تیم توسعه کمک می کند مشکل ترین اصول اسکرام را اعم از Sprint Planning ,  Velocity , Story estimation ,… را طی بازی و سرگرمی آشنا بشوند. این بازی توسط اکثر Agile Coach ها معروف جهان در کارگاههای آموزشی اسکرام وAgile  انجام می شود . و در واقع جزو بهترین راه ها برای آشنایی دادن اعضای تیم با اصول اصلی و بنیادین اسکرام می باشد.

در این بازی اعضای تیم  به صورت مجازی Planning می کنند . بعد Sprint Backlog می سازند . بعد پیاده سازی می کنند و بعد بازبینی می کنند . این بازی شامل 3 Iteration می باشد که در حدود 3,2 ساعت به طول می انجامد که بدلیل مفرح بودن اعضای تیم احساس خستگی نمی کنند .

این بسته برای چه تیم هایی مناسب است ؟

  • تیم هایی که می خواهند به تازگی وارد متد Scrum بشوند .
  • تیم هایی که وارد متد Scrum شده اند ولی در مفاهیم مشکل دارند .
  • تیم هایی که می خواهند Scrum را اصولی انجام بدهند .

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

  • بسته Scrum Game
  • تیم توسعه
  • دو عدد میز + تعدادی صندلی (به تعداد اعضای تیم)

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

  • راهنمای کامل انجام بازی به زبان فارسی
  • وسائل و تجهیزات مورد نیاز انجام بازی

نحوه تهیه ؟

برای تهیه Scrum Game Pack  و یا اطلاعات بیشتر می توانید با آدرس ایمیل زیر مکاتبه فرمایید:

Safari_asad[at]yahoo[dot]com

در موضوع یا Subject ایمیل قید شود : Scrum Game Pack

یاشیاسیز

اسکرام راهی به سوی مشکلات

مارس 26, 2010 5 دیدگاه

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

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

https://sirasad.files.wordpress.com/2010/03/sprint_guy_f_thumb.jpg?w=300

شما IDE ها را در نظر بگیرید ,  وقتی کلمه ای مانند sting را به جای string می زنیم خود IDE قبل از اینکه حتی ما کامپایل نماییم زیر کلمه sting نشان قرمز می زند . و ما با چند عدد Back Space  آن را اصلاح می نماییم ,  این خاصیت بسیار عالی می باشد ,  فرض کنید همه اینها جمع می شد و ما در زمان کامپایل می فهمیدیم ,  درست است حل می شد ولی کمی خسته کننده و زمان بر می شد .   همین قابلیت را اسکرام برای پروژه ما به ارمغان میآورد .

همیشه در همه مقالاتی که در مورد اسکرام نوشته ام تاکید کرده ام که در Sprint Planning باید همه اعضای تیم اسکرام حضور داشته باشند ,  در این جلسات چه اتفاقی می افتد ؟ به نظر من بزرگترین ارمغان این جلسات Big Picture می باشد . Big Picture تصویر ذهنی از کل سیستم می باشد که در ذهن اعضای تیم به وجود می آید . فرض کنید یکی از اعضای تیم در یک جایی از Big Picture اشتباه دارد یعنی اشتباه فهمیده است و در ذهنیت خود چیز دیگری را جز درخواست مشتری ساخته است (البته در ذهن خود ساخته است و نه در عمل) . پس این عضو از تیم در صورتی که بخواهد این قسمت را پیاده سازی نماید چیزی را پیاده سازی خواهد کرد که مطلوب مشتری نمی باشد . اینجا است که اسکرام ظهور می کند و مشکل را نمایان می کند و بر روی پیشانی آن عضو از تیم خط قرمز می کشد . شاید بپرسید چگونه ؟

اسکرام در دو مرحله می تواند این مشکل را شناسایی و اعلام نماید ,  اگر در محله اول کشف نشد حتما در مرحله دوم کشف می شود و اعلام می شود( رد خور ندارد) :

1- جلسات روزانه :  در این جلسه وقتی که این عضو تیم می فرماید ,  1- دیروز چه کار انجام داده ام ؟ 2- امروز چه کاری می خواهم انجام بدهم ؟ تیم باید متوجه این مشکل شود که این برادر اشتباه فهمیده است و باید اصلاح نماید ,  در غیر اینصورت کل تیم اشتباه فهمیده اند و یا اینکه اصلا مشتری اشتباه گفته است . اگر مشکل در این مرحله کشف شود هزینه چندانی نخواهد داشت بدلیل اینکه در عرض یک روز کشف شده است و نهایتا یک روز دوباره کاری می شود.

2- هنگام تحویل Demo  به مشتری :  همانطور که مستحضر می باشید بعد از اتمام هر اسپرینت ,  برآیند و نتیجه اسپرینت در قالب یک محصول Demo تحویل مشتری داده می شود که مشتری با استفاده از محصول پی خواهد برد که فلان جا آن برادر اشتباه فهمیده و یا اشتباه گفته شده است و باید اصلاح شود و طی یک فید بک این قضیه سریعا  به اطلاع تیم توسعه رسانده می شود.  اگر مشکل در این مرحله کشف شود باز بهتر از این است مشکل بعد از 6 ماه یا بیشتر کشف شود بدلیل اینکه ما نهایتا زمان اسپرینت ها را سه هفته تا یک ماه در نظر می گیریم . (سه هفته بهتر و کم هزینه تر از 6 ماه خواهد بود)

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

یاشیاسیز