پیاده سازی SCRUM - قسمت اول

[Asad.Safari]

با سلام

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


من SCRUM رو انتخاب کردم بدلایل زیاد , اگر نمی دونید اسکرام چیه روی این (http://sir.blogsky.com/1388/06/30/post-153/) کلیک کنید.


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


شروع قسمت اول :


تجهیزات خود را آماده کنید


در گام اول ما نیاز داریم که یک گروه اسکرام تشکیل دهیم . این گروه برای مدیریت تولید محصول و تحت دستور SCRUM Master فعالیت خواهند کرد . حداقل افراد مورد نیاز بعد از مدیریت یک نفر می باشد . یک نفری که باید به صورت اختصاصی با این محصول باشد .


گفتم محصول نه پروژه !

اسکرام محصول محور است نه پروژه محور و تمام تلاشش برای تکمیل یک محصول است ولی ممکن است در یک پروژه چندین محصول باشد.


قدمی بعدی پیدا کردن مالک محصول است

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


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

همانند یک Scrum master عمل کنید

اکنون شما محصول را سروسامان داده اید . تیم اسکرام خود را جمع کرده اید . یک نفر دارید که به صورت اختصاصی در خدمت محصول است . یک نفر دارید که وی مالک و صاحب محصول می باشد . احتمالا شما الان یک SCRUM Master می باشید .


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

ساخت Backlog محصول

شما در این مرحله باید Backlog محصول را درست نمایید و یا اینکه تسهیلاتی ایجاد نمایید که تیم اسکرام این کار انجام دهند . تاکید می شود که این کار حتما و حتما باید با حضور مالک محصول و یا افراد ذینفع محصول انجام گیرد .


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


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


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


Backlog محصول می تواند شامل همه چیز باشد . هرچیزی که در رابطه با محصول باشد . آیتم های موجود در Backlog باید به صورت واضح باشد و تا حد امکان از اصلاحات تجاری به جای اصلاحات تکنیکی استفاده کنید (مشتری شما تاجر است نه برنامه نویس مایکروسافت) .


نیاز های Functional (عملیاتی) باید به صورت یک ویژگی (Feature) در Backlog محصول ثبت شود . نیازهای Non-functional (غیر عملیاتی) را نیز می توان در Backlog قرار داد , برای مثال "محصول نیاز دارد که سریعتر کار کند" یا "ما باید مطمئن شویم که محصول کاملا امن است" و... . این موارد همه ویژگی محصول نیستند ولی می توان به عنوان یک آیتم توجیه پذیر در Backlog ثبت کرد.



اولویت بندی Backlog


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


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


اگر به نظر شما آیتمی در Backlog می باشد که واقعا وقت تلف کردن است , با رعایت صبر و آرامش به صورت کامل به مالک محصول توضیح دهید که این آیتم باید از لیست حذف شود و یا باید اولویت آن را کم در نظر گرفته شود و در ته صف قرار گیرد.


موارد پایین نیز بسیار موثر می باشند:


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


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


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


اما این کار مارا در طراحی لاگ های Backlog مشکل می کند , بدلیل اینکه باید دقت نماییم از هم پیوستگی اجزای متفاوت تا جایی که ممکن است بپرهیزیم در غیر اینصورت کل اسکرام و مدیریت ما زیر سوال میرود.


تبریگ میگم ... شما اولین گام اسکرام را با موفقیت برداشتید ... البته اگر گام ها را به صورت قدم به قدم برداشته باشید .


قسمت دوم در حال تحریر می باشد.


یاشیاسیز

[Asad.Safari]

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

موفق باشید

[Saeed_m_Farid]

بدلیل کم لطفی دوستان و با نظر به اینکه این مطلب فعلا در اینجا خریداری نداره , قسمت دومی که در حال تحریر بود فعلا تعلیق شد و حالا حالا منتظر قسمت دوم نباشید مگر اینکه بدون واقعا مطالبم واقعا به درد کسی میخوره.
جناب SIR_asad:
با سلام و تشکر از شروع به مبحث مفید و جدید؛ علیرغم مطالعه وبلاگ مفید و پست قسمت اول این تاپیک، با دیدن این پست (احتراماً) لازم دونستم چند تا یادآوری خدمتتون عرض کنم :


"نمي فهمم . خيلي گيج كننده است !": احتمالاً این جمله بتونه چیزی رو برای شما تداعی کنه، جمله ای که آلیس در سرزمین عجایب گفت و براش دنیایی بود که "بغايت از جهان واقعي متفاوت بود". این داستان كلاسيك كارول ، استعاره اي است مناسب برای درک تفاوت های فراوان دنیای مدیریت و دنیای برنامه نویسی، محیط کاملاً قابل پیش بینی 2X2 تا حتماً 4تا، فرضيه هاي مستدل و نتایج دقيق و بطورخلاصه دنیای افرادی که از بي نظمي، عدم قطعيت و آشفتگي بیزارند! به همين دليل ، دنياي مديريت مي تونه برای متخصصین برنامه نویس و توسعه دهندگان سیستم دنيايي شگفت، گيج كننده و بسيار پر هياهو باشه. انتظاری که شما از طیف وسیعی (نه همه) از این جامعه دارید (چیزی که ملاک "کم لطفی دوستان" و "خریدار داشتن مطلب" درنظر دارید)، از این دید کاملاً توجیه شده است و شکایت در این زمینه بی منطق.



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

http://www.osec.doc.gov/bmi/Budget/05APPR/images/PyramidChart_color.jpg


"علل گرايش مديران پروژه به مسائل علمي": انعطاف ناپذيری، وفاداری به نظام ارزشی مرتبط با علم، جهت گيری سياه و سفيد در مقابل جهت گيری خاكستری، هراس از نادان جلوه كردن، تمايل به دخالت، نياز به تحسين و احترام و ... : اینها قسمتی از دلایلی هستند که "جيمز اي . تينگستاد" در کتاب "مديريت بر هوشهاي پرورش يافته" آورده که در همین جا هم صادقه؛ بگذاريد مسأله رو دقيق تر بررسي كنيم. هر پژوهشگر بطور متوسط چهار تا ده سال از عمرش را براي مجرب شدن در حرفه اش تو دانشگاه سپري مي كنه و بعد اونهم سالهاي زيادي را در يك سازمان تحقيق و توسعه به پژوهش مي گذرونه و وقتي مهارت و تخصص علمي و فني پيدا كرد، [معمولاً] بدون آنكه پيرامون مهارتهاي مديريتي و يا روابط انساني آموزشي ديده باشه، ارتقاي مقام يافته و به مديريت پروژه مي رسه. حالا بگذریم از کم تجربه ترها، معمولاً این طیف مدیرها (که خود من شدیداً باهاشون درگیرم)، بین اینکه تخصص فني شان را حفظ كنند یا تو مهارتهای مدیریتی شون تسلط پیدا کنند، تو دوراهی گیر می کنند و مشکلات عدیده ای برای (قشر پایین تر) توسعه دهندگان سیستم ها درست می کنن مثل : رقابت با كاركنان، تصميم گيري انحصاری، افت سطح علمی (مشكل استخدام افراد با كفايت - خلاصه اش حسودی!)، شيوع احساس زائد بودن، خود را استادی بی همتا دانستن، فشار غير منطقی و هزار تا بلای دیگه : و تمام اینها جای اینکه اين كه توجه خود رو به حرفه مديريتی جديدشان معطوف كرده و به اون تسلط پیدا کنند رو می گیره و نتیجه اش این میشه که: من نوعی (توسعه گر سیستم) باید بیام اینجا نظر بدم! یا یک دانشجوی مهندسی نرم افزار یا مهندس جوهرخشک نشده لیسانس تاپیک نظری ارائه کنه...




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

======================================

و اما در مورد اسکرام :


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

از طرف دیگه اصلاً این Backlog چیه؟ معماری و تکنولوژی که میتونه اسکرام رو نمونه سازیش کنه چی هستند (مثلاً ما میگیم برای معماری سرویس گرا با این و آن متدولوژی میشه از تکنولوژی وب سرویس و مثلاً برای مراحل تحلیل سیستم از ™BizTalk استفاده می کنیم و ...)، این Backlog مثلاً یه داکیومنت Word هست؟ یا یه برنامه که به همه حق دسترسی لاگ میده و خودمون باید بنویسیم و یا ...
اگه عرایض بنده رو بی احترامی فرض نکنید، حداقل یکی دو تا لینک از سیستم های مشابه یا توضیحاتی عملی (نه صرفاً با دید مدیریتی) لطف می کردید بد نبود و می تونست دیدگاه خوبی برای ما ایحاد کنه، والا این که بگیم "برو تو گوگل SCRUM رو بگرد" که فکر نمی کنم تجربه های شما رو به ما انتقال بده ...

با تشکر.

[Asad.Safari]

Woow خیلی مطلب بود ...

در قسمت اول تون صحبت هاتون نبست به بنده لطف داشتید که بسیار ممنونم ... البته در یه مورد همه بنده رو بی منطق قلم داد کردید که موردی نداره ...

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

در مورد قسمت دوم :



جسارتاً چی رو تبریک میگید؟
با تشکر.

تسلیت عرض می کنم .



شما خودتون بعنوان یه مدیر باسابقه، به من نوعی بعنوان یه توسعه گر سیستم یا حتی (مثلاً) تحلیل گر موفق (با درنظر گرفتن پروژه های موفق متعدّد)، چقدر می تونین اعتماد کنید که منابع دپارتمان رو برای پیشبرد پروژه ای که تعیین مالک اون در مرحله دوم اولویت هست، قرار بدین؟ البته نه در شرایط ایده آل بحث های فرومی و علمی! .

ما هم در محیط فرومی و علمی بحث می کنیم .



حالا اومدیم رو پروژه سرمایه گذاری (زمانی و نیروی انسانی) کردیم و مالک تزریق کننده پولِ باحوصلهِ فهمیدهِ در روندِ کار قرار گیرنده، پیدا نشد:اشتباه: به احتمال 110 درصد، چوبش رو بنده ارائه دهنده ایده، خواهم خورد.


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



اگه عرایض بنده رو بی احترامی فرض نکنید، حداقل یکی دو تا لینک از سیستم های مشابه یا توضیحاتی عملی (نه صرفاً با دید مدیریتی) لطف می کردید بد نبود و می تونست دیدگاه خوبی برای ما ایحاد کنه، والا این که بگیم "برو تو گوگل SCRUM رو بگرد" که فکر نمی کنم تجربه های شما رو به ما انتقال بده ...
با تشکر.

برادر من , آیا من در جایی قید کرده ام که میخام تجربه ام در زمینه مدیریت را انتقال بدم ؟ فکر نکنم من در این تاپیک خواسته باشم تجربه انتقال بدم .

هدف من از تحریر این مطلب : بدلیل این که در ایران , عزیزان ما 20 سال بعد می فهمن که این خارجی ای ها داشتن ار چی استفاده می کردند , بدلیل جدید بودن اسکرام در عرصه تولید نرمافزار و بدلیل پیاده سازی این روش در 2 تا پروژه توسط این جانب خواستم این مطلب رو انتقال بدم .

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

ببینید اگر این تاپیک هم ادامه داشته باشه فقط در مورد اسکرام خواهد بود و بس .

حالا شما مشخص کن که میخای تاپیک ادامه پیدا کنه یا نه .

موفق باشید

[_jmimi]

سلام
شما موضوع بسیار جذابی رو شروع کردید. و به نظر من حتماً ادامه بدید.
چون که Agile , SCRUM خیلی جدید هستند و به درد کسانی که به صورت FreeLance کار می کنند ، خوب می خوره.
این متدولوژی خوبیه که حتماً باید یاد بگیریم.
مرسی از شروع این تاپیک

[_jmimi]

حالا نه این که جدید بودن یه روش، معیار خوب بودن یا مناسب بودنش باشه، ولی اسکرام اونقدرها هم که در بالا گفته شده جدید نیست (http://en.wikipedia.org/wiki/Scrum_%28development%29#History) (حداقل از نظر خود روش، استفاده‌ش رو نمی‌دونم که آیا اخیراً در حال رایج شدن هست یا نه).

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

[_jmimi]

سلام
منم با پاک کردن اضافات توسط مدیر موافقم.
در ضمن SCRUM از RUP جدیدتره.

[Asad.Safari]

من فکر نکنم شما قبلا تو یه جایی شنیده باشید که فلان شرکت از اسکرام استفاده کرد و فلان محصول رو تولید کرد , پس واسه ما خیلی تازه است .

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

در ضمن این موضوع به احتمال زیاد در اینجا ادامه پیدا نکنه .

پیاده سازی SCRUM - قسمت دوم (http://sir.blogsky.com/1388/07/13/post-160/)

موفق باشید