دسته: Agile

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

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

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

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

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

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

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

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

هزینه یک محصول معیوب، هر چه در خط تولید به جلو می رود، به نحوی چشمگیری افزایش می یابد. این جمله متن همان قانونی است که به آن اشاره کردیم. تصویر زیر که بر اساس نتایج بررسی های انجام شده برای اندازه گیری هزینه خطاهای فازهای مختلف پروژه های نرم افزاری در شرکت 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

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

Sprint Review Meeting

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

Sprint Retrospective
Meeting

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

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

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

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

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

3.       منطبق سازی (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 و برای دریافت اطلاعات مفید درباره این دوره به پست آقای خرمی راد مراجعه کنید.

Not list

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

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

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

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

1.       اضافه کردن مشخصات مشتریان

2.       اصلاح مشخصات مشتریان

3.     

1.       سیستم گزارشگیری دینامیک

2.       ویژگی آنلاین بودن سیستم

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

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

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

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

اولین دوره 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 هفته در نظر گرفته شده است.

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.

مراحل رشد یک تیم

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

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

یک انتقاد

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

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

مدل تاکمن

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

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

  • جر و بحث و اختلاف نظر بین اعضای تیم وجود دارد. حتی در مواردیکه افراد قبلا روی آن موضوع توافق کرده اند.
  • حسادت اعضاء نسبت به یکدیگر افزایش می یابد.
  • اعضاء با آرمانها و اهداف تیم و مجموعه مخالفت می کنند، و حتی اعلام می کنند که آنها اشتباه است.
  • اهداف غیر واقعی (جدا از هدفی که تیم برای آن ایجاد شده است) توسط افراد مطرح می شود و حتی در جهت آن اهداف نیز حرکت می شود.
  • روابط بین اعضای تیم کاهش می یابد، شاید بتوان گفت تیم به صورت انزوا حرکت می کند.

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

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

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

Performing :این مرحله، مرحله ای است که تیم به بالاترین میزان کارائی و بازدهی خود می رسد.و تیم برای حرکت خود به سمت هدف دارای استراتژی مشخص شده است. افراد دارای مسئولیت پذیری بالای هستند و برای انجام کارها نیازی به مداخله  مستقیم مدیریت ندارند. تصمیم ها به صورت جمعی و در یک محیط کاملاً دوستانه و اکنده از احترام گرفته می شود. می توان خصوصیات مثبت دیگری را برای این مرحله شمرد. ولی متاسفانه تیم های زیادی به این مرحله صعود نمی کنند و اغلب در مراحل قبلی در جا می زنند.

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

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

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

توزيع Agile در سازمان

ما می خواهیم به سمت Agile حرکت کنیم، XP، Scrum، Lean، FDD، AUP و شاید دهها اسم دیگر در این دسته از متدلوژیها وجو دارد که من نمی دانم و نشیدنم. ما باید از بین این اسامی کدام را انتخاب کنیم، چگونه انتخاب کنیم و چگونه به سمت آن حرکت کنیم؟ تفاوت اینها نسبت به هم چیست؟ نقاط قوت و ضعف آنها نسبت به هم چیست؟

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

یک انتقاد

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

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

راه حل : تفکر سیستمی

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

سطوح سازمان

در کتابهای مدیریت، سازمان را از لحاظ سطوح مدیریت به سه سطح مختلف تقسیم می کنند :

1-       سطح عالی (استراتژیک – راهبردی) : در این سطح مدیران وظیفه دارند اهداف بلند مدت، آزمانها و استراتژیهای سازمان را تعیین کنند.

2-       سطح میانی : این سطح وظیفه دریافت دستورات و برنامه ها را از سطح عالی سازمان و تبدیل آن به برنامه میان مدت، برنامه هایی اجرایی و زمانبندی شده و ابلاغ آن به سطوح پایین تر را بهعده دارد.

3-       سطح عملیاتی : این سطح مدیریت را سطح درگیر در فعالیت های اجرایی گویند. به عبارت دیگر وظیفه به اجرا گذاردن تصمیمات و دستورات مدیریت عالی و میانی را بعهده دارد.

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

توزیع Agile در سازمان

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

برای پوشش هر سه سطح سازمان، سه گزینه XP،  Scrum و Lean را انتخاب می کنیم و هر کدام از آنها را به یک سطح سازمان نگاشت می دهیم. Lean را به بالاترین سطح سازمان نسبت می دهیم یعنی زمانیکه بازگشت سرمایه و اهداف بلندمدت و استراتژی نمود پیدا می کند (به پست 14 اصل راه تویوتا مراجعه کنید). برای سطح میانی، Scrum را به کار می بریم یعنی سطحی که باید به سازماندهی تیمی، مدیریت زمان و تحویل پروژه تمرکز کرد. سطح آخر یا عملیاتی، جائیکه واقعا XP با آن تکنیک ها و اصول زیبای خود می تواند به تمام نیازهای عملیاتی توسعه نرم افزار جواب دهد.

نظر شما درباره این راه حل و پاسخ چیست؟

نحوه توزیع Agile در سازمان