بایگانی

بایگانی برای دسته ی ‘Agile’

قوانین طراحی ساده

همه ما از سادگی صحبت می‌کنیم و می‌گوییم عاشق سادگی هستیم. ولی شاید جمله «برای آن مسئله یک راه‌حلی پیدا کردم که عمراً کسی بتواند بفهمد چیکار کردم.» را بعضی وقت‌ها با افتخار بزبان می‌آوریم. پیدا کردن یک راه‌حل پیچیده برای یک مسئله که برای دیگران قابل درک نباشد یک حس نبوغ در ما القا می‌کند؛ اما اگر کسی بتواند برای همان مسئله راه حلی ارائه بدهد که به سادگی توسط همه قابل درک باشد، راه حل پیچیده من یک راه‌حل احمقانه و شاید من یک احمق نامیده شوم. پس قبل از اینکه هر لقبی بگیرید لطفاً این سؤال را از خودتان بپرسید «ساده‌ترین چیزی که ممکن است کار کند، چیست؟”.» این سوالی است که توسعه دهندگان چابک در هنگام نوشتن کد از خودشان می‌پرسند و بدین معناست که ساده‌ترین کاری را انجام دهید که شما را قادر می‌سازد تا در مسیر درست به پیش بروید.

 یک از ارزش‌های XP، سادگی و یکی از تکنیک‌های آن طراحی ساده (Simple Design) هست. Kent Beck مبدع XP برای داشتن یک طراحی ساده چهار قانون تعریف کردن که عبارت‌اند از:

  1. پاس شدن همه تست‌ها
  2. عدم وجود تکرار
  3. بیان مقصود برنامه نویس
  4. کاهش تعداد کلاس‌ها و متدها

پاس شدن همه تست‌ها

پیاده‌سازی تمام کلاس‌ها و متدهایی که بر عهده شما بود را تمام کردید، خوب آیا این به منزله پایان کار شما هست؟ چگونه تشخیص می‎‌دهید کدی که نوشتید واقعاً کار می‌کند؟ چگونه تشخیص می‌دهید زمانیکه قسمتی از نرم‌افزار را تغییر می‌دهید سایر اجزای نرم‌افزار هنوز به درستی رفتار می‌کنند؟

همه سوالهای بالا بر وجود تست در سیستم تاکید دارند. Unit Test ها کمک می‌کنند که شما بدانید چه زمانی وظیفه شما به پایان رسیده است – زمانیکه شما تمام تست‌های مرتبط با وظیفه‌ای که انجام می‌دهید را نوشته باشید و همه آن‌ها پاس شده باشند. اگر تست یا تست‌هایی پاس نشده باشد شما باید به فعالیت خودتان ادامه بدهید تا همه آن‌ها پاس بشود.

عدم وجود تکرار

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

این اصل اغلب بین توسعه دهنده‌های نرم‌افزار با نام DRY(Don’t Repeat Yourself.) یا Once And Only Once شناخته می‌شود. البته اصل DRY درباره تکرار کد نیست و درباره تکرار دانش هست، این اصل بیان می‌کند که  هر قسمت از دانش ما در سیستم باید جایگاه واحد، بدون ابهام و معتبری داشته باشد. (حسین بقایی عزیز چند ماه قبل لینک یک پست را در مورد DRY توئیت کرده بود که به صورت عالی این اصل را تشریح کرده بود خواندنش را از دست ندهید.)

بیان مقصود برنامه‌‌نویس

شاید این اصل یکی از اولین اصول و در ظاهر ساده‌ترین اصلی است که تعدادی زیادی از برنامه‌نویس‌ها سعی می‌کنند آنرا رعایت کنند. تاکید این اصل بر روی این هست که اسامی متغیرها، متدها، کلاس‌ها و … باید به هدف وجود آن‌ها اشاره کند.

کاهش تعداد کلاس‌ها و متدها

این یکی از اصولی هست که شاید در نگاه اول با اصول بالا در تضاد باشد. وقتی برای نمونه شما برای حذف کدهای تکراری کدهای موجود را ریفکتور می‌کنید به احتمال زیاد تعداد کلاس‌ها و متدها شما افزایش می‌یابد. پس اصل چهارم به خودی‌خود نقض می‌شود؛ اما این اصل به تعداد کلاس‌ها اشاره نمی‌کند و در واقع اشاره آن به اصل YAGNI (You Aren’t gonna need it) می‌باشد.  اصل YAGNI بیان می‌کند که شما باید هر چیزی را وقتی پیاده سازی کنید که واقعاً به آن نیاز دارید و نه وقتی که می‌فهمید در آینده ممکن است به آن نیازمند شوید. این جمله یکی از جملاتی است که XP واقعاً روی آن تاکید دارد و اعلام می‌کند که شما حتی اگر اطمینان حاصل کنید که به این ویژگی در آینده نیاز خواهید داشت آنرا الان پیاده سازی نکنید. پس هدف اصل چهارم این است که نباید با پیاده‌سازی کلاس‌ها و متدهایی که احتمالاً در آینده فرضی به آن نیاز خواهیم داشت نعداد کلاس‌ها و متدها را افزایش بدهیم.

فریم ورک تعاملات – قسمت دوم

چرا DISC مهم هست؟

در سه بند زیر به این سوال جواب داده می‌شود، که این سه بند شامل درک و پذیرش د‌یگران، تعامل با افراد با زبان خودشان و زبان DISC است.

درک و پذ‌یرش د‌یگران

افرادیکه با مدل DISC آشنایی دارند، می توانند با درک و پذیرش رفتار دیگران به صورت موثرتری در تیم‌ها فعالیت کنند.

مثالی که در ادامه آورده می شود، یک نمونه واقعی هست که چندین سال قبل در یک سازمان مشاوره رخ داده است. سارا یک شخص با D بالا هست، و علی که یکی از مشاوران اصلی سازمان است، یک شخص با C بالا است. سارا در حالت ناامید‌ی می‌گوید که: “من فقط یک جواب خیلی ساده می خواهم، آیا فرد مورد نظر را برای سازمان استخدام کنیم یا نه؟” علی سریعاً حرف او را قطع می کند و می گوید: “من تمام شب را نیاز دارم تا روی این مسئله فکر و بررسی کنم، و فردا صبح جواب را به شما اعلام خواهم کرد”.  سارا دوباره می گوید: “من نمی توانم درک کنم که چرا نمی توانم یک پاسخ خیلی ساده را الان از شما بگیرم. استخدام سریع یک فرد در این پست برای سازمان ضروری است.” علی هم به اندازه سارا ناراحت بود که چرا سارا دنبال یک جواب خیلی سریع است.

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

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

تعامل با افراد با زبان خودشان

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

تصور کنید که شما قرار است به یکی از مدیران ارشد شرکت خود یک گزارش درباره هزینه های یک پروژه که قرار است انجام شود بدهید. اگر شما قرار باشد گزارش را به یک مدیر با D بالا ارائه کنید به چه صورت گزارش خود را تنظیم و ارائه خواهید کرد؟ در صورتیکه مدیر با  Cبالا باشد چگونه اینکار را انجام خواهید داد؟

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

اگر شما باید گزارش را به یک مدیر با C بالا ارائه بدهید، باید کاملاً به صورت برعکس عمل کنید. یعنی اول باید اطلاعات و جزئیات مربوط به هر هزینه را بیاورید و سپس مبلغ آن هزینه را.

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

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

زبان DISC

دلیل آخر برای اهیمت DISC این است که افراد می توانند از “زبان DISC” به عنوان یک اهرم استفاده کنند.

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

در یکی از جلسات طوفان مغزی که به‌صورت دوره‌ای در این شرکت برگزار می شود. مدیرعامل به صورت پیوسته در حال سخنرانی است و فرصت صحبت را به فرد دیگری نمی‌دهد. مدیرعامل فرد بسیاری باهوشی است و ائده‌های خوب زیادی برای ارائه کردن دارد. اما هیچ کدام از اعضاء فرصت صحبت پیدا نمی کنند. اگر شما در آن جلسه بودید چگونه فرصت صحبت را برای خودتان یا دیگران مهیاء می کردید؟ در آن جلسه یکی از حاضران در فرصت مناسب فقط این جمله را بیان می کنه: “آقای مدیرعامل، مثل اینکه D شما امروز در سطح خیلی بالای هست.” با شنیدن این جمله مدیرعامل شروع به خندیدن می کند و فرصت صحبت را به دیگران نیز می‌دهد. بدون “زبان DISC”  به‌آسانی ممکن نبودکه از مدیرعامل خواست که سخنان خود را قطع کند (خفه شود) تا دیگران نیز به اظهار عقیده بپردازند. زمانیکه از “زبان DISC ” استفاده می‌کنید، مردم اغلب لبخند می‌زنند و نکته جمله را می‌گیرند.

استراتژهای برای تعامل

جدول زیر به طور خلاصه استراتژیهای را برای تعامل افراد با دیگران با توجه به مدل رفتاری آنها ارائه می‌دهد.

رفتار

استراتژیهای برای تعامل

D

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

I

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

S

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

C

با آنها جدی باشید، اطلاعات را با جزئیات به آنها ارائه دهید، اجازه دهید سوالات‌شان را بپرسند، از آنها سوال بپرسید، منظم باشید، مدارک و شواهد ملموس به آنها ارائه بدهید، نظرات و عقاید خود چه موافق و چه مخالف را با آنها در میان بگذارید.

 پایان

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

فریم ورک تعاملات – قسمت اول

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

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

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

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

پس سریعا تصمیم گرفتم که کارائی تیم را افزایش دهم. برای این منظور در اولین مرحله باید اعضای تیم سبک رفتاری همدیگر را درک می‌کردند و با استفاده از آن سبک تعاملات خود را به گونه ای تغییر می‌دادند که به عنوان یک تیم به شکل موثرتری کار کنند.

فریم ورک تعاملات

اگر شما از افرادی بخواهید تعریفی از اجایل برای شما ارائه بدهند، احتمالاً شما به تعداد نفراتی که این سوال را از آنها پرسیده اید، پاسخ دریافت خواهید کرد. مجدداً از این افراد بخواهید یک تعریف خیلی انتزاعی از اجایل را اینبار در سه عبارت یک و یا دو کلمه‌ای ارائه بدهند. نتیجه را بررسی کنید به احتمال زیاد در جواب اکثر افراد با عبارات “کارتیمی”  و‌ یا “تعاملات” روبرو خواهید شد.

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

تاریخچه DISC

فریم ورکی که من اکثر موارد برای تیم های مختلف توصیه می کنم  DISC نام دارد. احتمال دارد شما نیز با DISC  آشنایی داشته باشید. اما DISC  بسیار قدیمی تر از متدهای چابک و تفکر ناب هست و ریشه های آن به ۴۰۰ سال قبل از میلاد مسیح برمی گردد، زمانیکه بقراط رفتارهای انسان را مورد بررسی قرار داد و آنها را به چهار گروه تقسیم کرد.

در ۱۹۲۸ ویلیام مولتون مارستن کتابی با عنوان “The Emotions of Normal People” منتشر کرد، که در آن تئوری DISC را تشریح کرد. در طول این سالها، شرکتهای متعددی تاییدیه های آماری و بهبود مستمر را بر روی DISC ارائه کرده‌اند.

تعریف DISC

شما می توانید DISC را به عنوان اثر انگشت رفتاری هر فرد در نظر بگیرید. رفتار هر فرد ترکیبی از چهار عنصر است، اما ترکیب این چهار عنصر در هیچ دو فردی دقیقا مشابه یکدیگر نیست. ترکیب این چهار عنصر است که مشخص می کند هر فرد چگونه رفتار می کند. درک DISC بسیار ساده است، اگر یک فرد بخواهد که بر همه افراد و محیط خود تسلط داشته باشد، این فرد یک D است. هر یک از حروف در عنوان DISC  بیانگر یکی از این چهار عنصر است. هر کدام از این حروف به چه معنای هستند؟

The D—Dominator

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

Dهای مشهور: جورج بوش، مارگارت تاچر، پوتین، مایکل جردن و رابرت دنیرو.

The I—Influencer

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

Iهای مشهور: بیل کلینتون، آندره آغاسی، استیو مارتین

The S—Supporter

Sها سنگ صبور تیم‌ها هستند. آنها از دسته افرادی هستند که آهسته و پیوسته حرکت می کنند تا به مقصد برسند، شما می توانید مطمئن باشید که آنها حتما تا آخر با شما خواهند بود. آنها صبور، متفکر، آرام، دلسوز، حامی و مهم تر از همه یک گوش شنوا و هم تیمی قابل اتکاء برای همکاران و دوستانشان هستند. با توجه به ذات پایدار آنها، آنها از تغییرات آنی و تناقصی گریزان هستند و دوست دارند که در محیط های پایداری که با ریتم ثابتی حرکت می کنند فعالیت کنند. آنها نمی خواهند زمانیکه برای در کنار خانواده بودن را در نظر گرفته اند به هیچ قیمتی از دست بدهند. در یک کلام آنها عاشق کار در تیم های کوچک و کمک به دیگران هستند.

Sهای مشهور: مادر تزار، مارتین لوتر کینگ، جان اف کندی

The C—Critical Thinker

Cها عاشقان استانداردها و جزئیات. آنها به درستی و کیفیت اهمیت زیادی می دهند، و به همین دلیل قبل از تصمیم گیری و انجام کارها تحقیق کافی می کنند، و برای اینکار پیش نیازهای این کار یعنی، دسترسی به اطلاعات کامل، زمان کافی برای بررسی تمام جزئیات را نیز طلب می کنند. آنها به صورت سیستمی فکر می کنند و مسائل را به درک خوبی می‌کنند. آنها معمولا استانداردهای بالای را برای خود در نظر می گیرند که اغلب بالاتر از سطح نرمال هستند. آنها اگر به استانداردهای مورد نظر خود دست نیابند ممکن است برای دیگران مشکل ایجاد کنند.Cها معمولا نیمه خالی لیوان را می بینند زیرا آنها می خواهند همه چیز کامل باشد. آنها اغلب در دسته درونگراها قرار می‌گیرند و تمایل دارند در پروژه‌های انفرادی فعالیت کنند. صنعت ما نیازی به افرادی با سی بالا دارد، کدنویسی، طراحی، تست، جمع آوری نیازها و … همه به مهارت های تحلیلی و توجه بالا به جزئیات دارد.

Cهای مشهور: بیل گیتس، آلبرت انشتین، آلن گرین اسپن

پیشگیری از شکست در یک هفته

۲۲ اردیبهشت ۱۳۹۱ بدون دیدگاه

یک سوال هست که دائم توی ذهنم دارد تکرار می شود، در مورد یک اتفاق. آن اتفاق رخ می دهد یا نه؟ به نظر من که به احتمال زیاد رخ می دهد. حتما می پرسید کدام اتفاق؟ شکست توسعه یک محصول. شکست توسعه یک محصول گاه یک واقعیت خیلی ملموس است، ملموس تر از چیزی که تصورش را دارید.

به دنبال تحول در فرآیند توسعه محصول جدیدمان بودیم. یکی از بچه ها گفت: اسکرام! اسکرام یک گزینه عالی است. من هم مطالعه زیادی روی اسکرام دارم، می توانم مسئول اجرای صحیح اسکرام توی تیم بشوم. توی اسکرام شخصی که این وظیفه را بعهده داره اسکرام مستر نامیده می شود. ما بزودی خیلی چیزها در مورد اسکرام یاد گرفتیم، جلسات مختلف برنامه ریزی، بازبینی، نحوه و تکنیکهای تخمین کارها، اسپرینت های با زمان مشخص و هدف مشخص و خیلی چیزهای دیگر. ولی اتفاق درست اینجا می تواند شروع به رخ دادن بکند و همه این آموخته ها می تواند پاشنه آشیل یک تیم جدید که شروع به اجرای اسکرام کرده بشود. اری! هیچ کدام از اینها نمی تواند باعث موفقیت توسعه یک محصول بشود. چون اسکرام ۳ نقش دارد نه یک نقش. مالک محصول یا Product Owner، یکی از این سه نقش است. اگر قرار باشد مشتری نهایی خود را با دادن چیزی که واقعا آنرا می خواهد شاد کنیم، اصلی ترین و اولین گام ها را باید مالک محصول بردارد. مطمئن باشید بدون یک مالک محصول خوب، اولین و اصلی ترین گام را به سوی شکست برمی دارید. شاید اشکال از شما نباشد، چون اکثر کتابهای را که در مورد اسکرام تالیف شده باشید را مطالعه کنید، حداکثر سهم مالک محصول یک فصل از آن کتاب خواهد بود. پس گاهی کتابها هم یاری رسان ما جهت حرکت به سمت شکست خواهند بود. ولی اگر دوست دارید مسیر خود را به سمت موفقیت تغییر دهید، یک مالک محصول خوب و آموزش دیده برای تیم خود در نظر بگیرید. فرصت داشتن یک مالک محصول خوب را دوستان ما برای شما آماده کردند. پس اولین گام برای دور شدن از شکست را از دست ندهید.

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

توصیه من برای همه کسانی که می خواهند اسکرام را در تیم خودشان اجراء کنند، حضور در هر سه دوره اسکرام خواهد بود. و اگر تمایلی به اجرای اسکرام در تیم خود ندارید، حتما دوره های PSD را از دست ندهید. به طور خلاصه فقط می توانم بگویم پیشگیری از شکست در یک هفته را با حضور در این سه دوره تجربه کنید.

Categories: Agile Tags:

جیدوکا در فرآیند توسعه نرم افزار

۱۸ فروردین ۱۳۹۱ بدون دیدگاه

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

کیفیت، هزینه کم! این یک پارادوکس است. نه این یک پارادوکس نیست، بلکه این بسیاری از باورهای دورنی ما است که با واقعیت های عینی دنیا ما در تضاد است. امروز می‌خواهیم با استفاده از یک قانون و یک تکنیک این پارادوکس را در وجود خود از بین ببریم.

هزینه یک محصول معیوب، هر چه در خط تولید به جلو می رود، به نحوی چشمگیری افزایش می یابد. این جمله متن همان قانونی است که به آن اشاره کردیم. تصویر زیر که بر اساس نتایج بررسی های انجام شده برای اندازه گیری هزینه خطاهای فازهای مختلف پروژه های نرم افزاری در شرکت IBM، TRW، GTE و HP تهیه شده است، به روشنی بیانگر نتیجه حاصل از این قانون است. ‌برای اینکه به یک محصول معیوب اجازه ندهیم در خط تولید رو به جلو حرکت کند، چگونه باید عمل کنیم؟

نسبت هزینه رفع خطا و نواقص در هر مرحله

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

چگونه می توان جیدوکا را در دنیای توسعه نرم افزار بکار برد؟ اگر شما از توسعه تست گرا (TDD) یا تست واحد (Unit Test) در فرآیند توسعه خود استفاده می کنید، جیدوکا را به کار می‌برید. شما تست های مورد نظرتان را می نویسید، اگر آنها شکسته شدند، شما کد خود را اصلاح می کنید تا بتوانید تست‌ها را با موفقیت تمام پاس کنید. اگر شما به آزمونهای خودتان وفادار باشید تا حد امکان اجازه نخواهید داد که خطاها در فازهای  بعدی کشف شوند و هزینه اصلاح آنها به شدت افزایش یابد. اگر شما در فرآیند توسعه خود از یکپارچه سازی پیوسته (Continuous Integration) استفاده می کنید و به همراه آن از مفهوم فیدبک پیوسته (Continuous Feedback) استفاده می کنید از جیدوکا استفاده می کنید. هر زمانیکه عمل Build در سرور CI شما با شکست روبرو شد. سرور CI با مکانسیمی که شما برای فیدبک پیوسته در نظر گرفتید، نتیجه را به اطلاع اعضای تیم خواهد رساند و اعضای تیم شروع به رفع مشکل خواهند کرد. دو مورد اشاره شده، بیشتر

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

مکانسیم فیدبک پیوسته (Continuous feedback mechanism)

خطاهای مرحله کد نویسی را پوشش می دهند. برای  جلوگیری از نواقص و یا برداشت‌های مختلف از نیازمندیها توسط تیم توسعه و مشتری که باعث ارائه محصول معیوب خواهد شد چگونه عمل کنیم؟ اگر فرآیند توسعه شما بر اساس مفاهیم Incremental و Iterative بنا نهاده شده است و مشتری و یا نماینده آن را در طول هر تکرار و افزایش شرکت می دهید، شما می توانید بر این مشکل نیز غلبه کنید و اجازه ندهید یک محصول معیوب تا آخرین مرحله توسعه به جلو حرکت کنید.

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

پا‌نوشت: تصویر اول از کتاب روش کاربردی تحلیل نیازمندی های نرم افزار نوشته دوستان عزیز یوسف مهرداد، پویا شهبازیان و مظفر ایراف برداشت شده است. تصویر دوم هم از کتاب Continuous Integration برداشت شده است.


من پشت سرم را نگاه می کنم، شما چطور؟

جدول زیر را در نظر بگیرید:

Daily Scrum Meeting

بدون در نظر گرفتن تعداد نفرات تیم یک جلسه زمان بسته (time-boxed) 15 دقیقه ای می باشد.

Sprint Planning Meeting

زمان این جلسه برای یک اسپرینت یک ماهه ۸ ساعت می باشد. برای اسپرینتهای کوتاهتر زمان کمتری در نظر گرفته می شود.

Sprint Review Meeting

یک جلسه زمان بسته ۴ ساعته برای یک اسپرینت یک ماهه می باشد. برای اسپرینتهای کوتاهتر زمان کمتری در نظر گرفته می شود.

Sprint Retrospective
Meeting

یک جلسه زمان بسته ۳ ساعته برای یک اسپرینت یک ماهه می باشد. برای اسپرینتهای کوتاهتر زمان کمتری در نظر گرفته می شود.

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

به مثالهای بالا اشاره کردم تا به جمله ای برسم که واقعا با آن مشکل دارم. یعنی این جمله : ” ﻧﻘﺶ ﻫﺎ ، ﻣﺼﻨﻮﻋﺎت ، روﯾﺪادﻫﺎ و ﻗﻮاﻧﯿﻦ اﺳﮑﺮام ﺗﻐﯿﯿﺮ ﻧﺎﭘﺬﯾﺮ ﻣﯽ ﺑﺎﺷﻨﺪ و ﻫﻤﭽﻨﯿﻦ ﭘﯿﺎده ﺳﺎزی ﺑﺨﺸﯽ از اﺳﮑﺮام ﻣﻤﮑﻦ ﻣﯽ ﺑﺎﺷﺪ و اﻟﺒﺘﻪ ﻧﺘﯿﺠﻪ ﺣﺎﺻﻠﻪ از اﯾﻦ ﻧﻮع ﭘﯿﺎده ﺳﺎزی اﺳﮑﺮام ﻧﺨﻮاﻫﺪ ﺑﻮد.”.
به نظر من وقتی در اسکرام از تغییر ناپذیری صحبت می شود ما در واقع با ذات و ماهیتی که اسکرام بر روی آن بنا شده است مخالفت می کنیم. پایه ها و زیر بنای اسکرام بروی تجربه گرایی بنا شده است، تجربه گرایی اعتقاد دارد که دانش از تجربه حاصل می شود. اجازه بدهید بر خلاف راهنمای اسکرام  تنها به همین چند کلمه اکتفا نکنیم و چند کلمه ای بیشتر درباره آن بدانیم. فرانسیس بیکن
 یکی از بنیانگذاران فلسفه تجربه گرایی است، او معتقد بود که علم زمانی به دست می آید که فرد محسوسات و جزئیات را به مشاهده و تجربه در آورد و برای
استخراج قواعد به کلیات جمع آوری مواد روی آورد. اما این جمع آوری مواد، مشاهده و تجربه را سرسری نباید گرفت، و با نهایت دقت و تامل باید به کار برد. وی در شناخت واقعیت ها بر محسوسات و تجربه اهمیت زیادی قائل بود و تاکید داشت که جهت شناخت معارف و کسب علم باید از تاکید بیجا و افراط بر گفته ها و نوشته های دیگر علما پرهیز نمود  و با تکیه بر دیدگاه و جهان بینی خود در راه تاسیس علم و معرفت قدم برداشت
 .پس بر اساس اصول پایه اسکرام یاد بگیریم که تنها به نوشته های روی کاغذ و قوانین مبدعان پایبندی بی اساس نداشته باشیم و اجازه بدهیم که این قوانین، رویدادها و نقش ها را با شرایط و فرهنگ خود تجربه کنیم و بر اساس تجربیات خود آنها را تغییر دهیم و برای تیم خود بهینه سازی کنیم.

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

۲٫       بازرسی (Inspection) : یک فرآیند کنترلی داشته باشید که بررسی کند که آیا رویدادها، قوانین و مصنوعات موجود در اسکرام به دلایل انتخابی شما پاسخگو است یا نه؟

۳٫       منطبق سازی (Adaptation) : اکر در حین بررسی متوجه شدید که یک رویداد ارزش خاصی برای تیم ایجاد نمی کند، آن رویداد را تغییر دهید و حتی حذف کنید. اگر با نقش های که در تیم اسکرام هست نمی توانید تمام مسائل خود را پوشش بدهید نقش های جدید برای حل مسئله خود به آن اضافه کنید.

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

گزیده:

The important thing is not your process.

The important thing is your process for improving your process.

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

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

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

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

Categories: Agile Tags: , ,

Not list

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

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

چه چیزهای را می خواهیم انجام بدهیم

چه چیزهای را نمی خواهیم انجام بدهیم

۱٫       اضافه کردن مشخصات مشتریان

۲٫       اصلاح مشخصات مشتریان

۳٫     

۱٫       سیستم گزارشگیری دینامیک

۲٫       ویژگی آنلاین بودن سیستم

ویژگیهای که هنوز در مورد آن تصمیم گیری نشده است

۱٫       ارسال صورتحساب از طریق رسانه های مختلف

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

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

اولین دوره 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، ۶ هفته در نظر گرفته اند. اما در نسخه های که فقط متد اسکرام را در نظر داشتند همان ۴ هفته در نظر گرفته شده است.

Three Simple Truths

The following are three simple project truths that, once accepted, get rid of much of the drama and dysfunction we regularly see on software projects.

It is impossible to gather all the requirements at the beginning of a project.

Whatever requirements you do gather are guaranteed to change.

There will always be more to do than time and money will allow.

Accepting the first truth means you are not afraid to begin your journey without knowing everything up front. You understand that requirements are meant to be discovered and that not proceeding until all are gathered would mean never starting.

Accepting the second means you no longer fear or avoid change. You know it is coming. You accept it for what it is. You adapt your plan when necessary and move on.

And by accepting the third, you no longer get stressed when your todo list exceeds your time and resources to deliver. This is the normal state for any interesting project. You do the only thing you can—you set some priorities, get the most important stuff done first, and save

the least important for last.

Once you accept these three simple project truths, much of the stress and anxiety traditionally associated with software delivery disappears. You are then able to think and innovate with a level of focus and clarity that escapes most in our industry.