برچسب: Scrum

آیا زمان یاد گرفتن فرا نرسیده است؟

ارسال شده در تاریخ نوامبر 2, 2011 Agile

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

بحث من در این پست بیشتر بر روی متدهای چابک است و بحث خود را با مثالی که مهندس مهرداد در یکی از پست های قبلی حود به آن اشاره کرده بود ادامه می دهم. در این مثال به فردی اشاره شده است که ادعا می کند که در سازمان آنها از متد XP استفاده می شود. و وقتی از او سوال می شود که از تکنیکهای XP  مانند Pair programming،Refactoring ، TDD و یاPlanning game  در سازمان آنها استفاده می شود یا نه؟ جواب این شخص نه است و اشاره می کند که آنها فقط هیچ چیزی را مستند نمی کنند. این دقیقا شبیه طرز تفکری است که در جامعه ما نسبت به متدهای چابک وجود دارد و من یک دلیل خوب برای وجود این طرز تفکر در این جامعه دارم. چون مستند نکردن هیچ چیز، تنها چیزی است که از این متدها می توان استنباط کرد که نیاز به هیچ آموزش و مطالعه ای ندارد و با یک تفسیر نادرست از بیانیه Agile می توان از این بیانیه استنباط کرد. آیا واقعا در متدهای چابک هیچ چیزی مستند نمی شود؟. “تو شروع  به کد نویسی کن، من میرم ببینم مشتری چه می خواهد!” این نقل واقعا به چه میزان با ذات متدهای چابک سازگاری دارد؟ آیا واقعا متدهای چابک فقط برای تیم های کوچک مفید هستند؟ بهتر است به سوالاتی که درباره Agile Planning مطرح می شود نپردازم.

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

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

ارسال شده در تاریخ می 26, 2011 Agile, مهندسی نرم افزار

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

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

First, are you doing Iterative Development?
  • Iterations must be time-boxed to less than 4  weeks
  • Is the software completely tested and working at the end of an iteration
  • Can the iteration start before specification is complete

The next part of the test checks whether you are doing Scrum (in Nokia’s opinion):
  • Does the team know who the product owner is
  • Is there a product backlog prioritized by business value
  • Does the product backlog have estimates created by the team
  • Does the team generate its burndown charts and knows its velocity
  • Does the team have outside people disrupting the work of the team during the sprint

البته توجه شود که در بعضی از نسخه های این آزمون time-box را برای یک Iteration، 6 هفته در نظر گرفته اند. اما در نسخه های که فقط متد اسکرام را در نظر داشتند همان 4 هفته در نظر گرفته شده است.

آیا اسامی متدلوژی ها میزان موفقیت ما را مشخص می کنند؟

ارسال شده در تاریخ اکتبر 9, 2010 Agile

مکتب ها، مذاهب، متدولوژیها و … اهداف و عصاره مطالب خود را به شکل ها و اسامی مختلف بیان می کنند در صورتیکه اکثر آنها دارای منظور و مقصود یکسان و مشترکی می باشند. شاید این اهداف مشترک که در قالب جملات و اسامی مختلف بیان می شود بیانگر اهمیت آن هدف باشد.

ما در پست ضایعات نرم افزاری، به بررسی مفهومی به نام ضایعات نرم افزاری پرداختیم و آن را از دیدگاه Lean مورد بررسی قرار دادیم. در این پست به بررسی همین موضوع از دید متدلوژیهای دیگر خواهیم پرداخت.

XP و YAGNI

در XP اصلی با عنوان YAGNI که سرنامی برای عبارت “You ain’t gonna need it” می باشد و به معنی “شما به آن نیاز نخواهید داشت” می باشد وجود دارد. که این اصل بیان می کند که شما باید هر چیزی را وقتی پیاده سازی کنید که واقعا به آن نیاز دارید، و نه وقتی که می فهمید در آینده ممکن است به آن نیازمند شوید. این جمله یکی از جملاتی است که XP واقعا روی آن تاکید دارد و اعلام می کند که شما حتی اگر اطمینان حاصل کنید که به این ویژگی در آینده نیاز خواهد داشت آنرا الان پیاده سازی نکنید.

Scrum و قلب آن (Product backlog)

Product backlog را قلب Scrum می نامند. لیستی از ویژگیها و نیازمندیهای نرم افزار که بر حسب اولویت مرتب شده است و بر حسب همان ترتیب در عمل پیاده سازی خواهد شد. اما این اولویت توسط چه کسی یا کسانی و با چه منطقی انجام می شود؟ وظیقه اصلی اولویت دهی را Scrum بر عهده Product owner قرار می دهد و او بر حسب ارزشی که هر ویژگی برای مشتری ایجاد می کند آنها را مرتب سازی می کند. ویژکیهای با ارزش افزوده بالا در ابتدای لیست قرار می گیرند و به به ترتیب که در لیست پایان می رویم از ارزش افزوده هر ویژگی کاسته می شود و همچنین از اولویت پیاده سازی آن.

Lean و حذف ضایعات در هر نقطه و هر زمانی

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

خلاصه و هدف هر سه دیدگاه بالا اولویت بندی نیازمندیها و ویژگیهای برنامه بر اساس ارزشی است که برای مشتری تولید می کنند، انجام هر کار در زمان مناسب با توجه به درخواستهای مشتری و بازگشت سرمایه. ولی هر کدام آن را با شیوه و ابزارهای خود بیان می کنند. شاید بتوان گفت ما باید بیشتر از آنکه درگیر اسامی باشیم باید به فکر ابزارها و شیوه های باشیم که به تیم و فرآیند ما در موفقیت کمک می کند (پست RUP بهتر است یا Agile؟ از استاد مهرداد یا پست آقای شهبازیان در مورد الگوهای فکری می تواند جالب توجه باشد). شاید منظور و هدف من به روشنی از متن پایین قابل استنباط باشد.

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