Archive

Archive for the ‘Kanban’ Category

اولویت بندی نیازمندی های مشتری

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

اما چرا اولویت بندی مهم است و چرا اساسا باید چنین کاری انجام داد؟

در پروژه ای که از روش کانبان بهره گرفته بودیم، لیستی از نیازمندی های محصول را در آورده بودیم ولی این لیست نیازمندی ها دو ایراد اساسی داشت : 1- اولویت بندی نشده بود 2- کاملا تشریح شده بود

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

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

تحقیقات جهانی Standish Group نشان داد که تنها و تنها 20% قابلیت های محصول ما توسط مشتری معمولا استفاده می شه و 64% اون هرگز یا بندرت استفاده می شود.

features.jpg (529×256)

این آمار برای آن پروژه ما زنگ خطری بود چرا که :

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

در بیانیه چابک اصلی داریم با عنوان سادگی که متن آن بدین گونه است :

سادگی — هنر به حداکثر رساندن مقدار کار انجام نشده — ضروری است

و مشتری ها معمولا دو خصیصه اساسی دارند، اولا همه چیز می خواهند ، ثانیا همه چیز برای آنها با اولویت می باشد.

اما ما به عنوان تیم چابک هم باید هنر مند باشیم تا بتوانیم اولا با اصل سادگی مقدار کاری که نباید انجام شود را به حداکثر برسانیم ، ثانیا بتوانیم اولویت بندی مناسبی بر اساس معیارهای کسب و کار داشته باشیم.

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

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

قلب اسکرام

طی این چند روزی که از ثبت نام دوره های اسکرام می گذرد ، ثبت نام کنندگان در کورس های مختلف را بررسی کردیم و متوجه شدیم کمترین ثبت نام در دوره PSPO یا Professional Scrum Product Owner انجام شده است ولی واقعا چرا؟ آیا اینقدر نقش یک مالک محصول در تیم های اسکرام کم رنگ است که کسی حاضر نمی شود برای یادگیری وظایف این نقش خرج کند؟

به نظر من مسئله اصلی درک نکردن وظایف و یا پی نبردن به اهمیت یک مالک محصول خوب در تیم های اسکرام یا چابک می باشد.

با یک مثال می توان این قضیه را شرح داد. فرض کنید من یک نفر به عنوان مدیر شرکت ، تازه با چابک/اسکرام آشنا شدم و با خواندن چند مقاله از این متد خوشم آمده و می خواهم با شرکت در کورس های اسکرام این متد را در شرکت نرم افزاری خود اجرایی کنم. 3 کورس اسکرام پیش روی من هست که باید  انتخاب کنم ، من با خواندن این پست پی بردم که تیم ها نقش اساسی در چابک سازی دارند بنابراین برنامه نویس ها و توسعه گران تکلیفشان مشخص هست و چند نفر از برنامه نویس های شرکت به کورس PSD یا Professional Scrum Developer اعزام می شوند.

من هم به عنوان مدیر شرکت چون می خواهم اسکرام را در شرکت راه بیندازم به همراه مدیر فنی در کورس PSM یا Professional Scrum Master شرکت می کنیم. خوب بسیار عالی ، اما این کورس PSPO یا Professional Scrum Product Owner برای چه کسی مناسب هست یا اصلا چه لزومی داشته این دوره طراحی شده است؟

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

product-owner-blog-post.jpg (960×580)

امروزه مدیریت چابک محصول نیازمند مهارت هایی فراتر از نوشتن داستان های کاربر(User Story) یا مدیریت Product Backlog می باشد.یک مالک محصول حرفه ای نیاز به درک عینی از همه مواردی که ارزش های ویژه ای را برای محصول به ارمغان می آورد ، دارد.مدیران محصول باید به تکنیک هایی جهت ایجاد ، اندازه گیری و پایداری ارزش ها در سطح محصول و سازمان مجهز شوند.کورس PSPO به شرکت کنندگان تمامی موارد مورد نیاز جهت رسیدن به این درک را فراهم می کند.مواردی از قبیل درک نیازمندی های ذینفعان تا برنامه ریزی Release ها و تحویل محصول.

بطور کلی شرکت کنندگان در این دوره آموزشی یاد خواهند گرفت که چگونه نقش یک مدیر چابک را در محیط متغیر امروزی بازی کنند.در دوره اسکرام مستر حرفه ای به وظایف کلی مالک محصول اشاره می شود و بسیاری از جنبه های مرتبط با مدیریت محصول در این دوره مطرح نمیشود.از اینرواین دوره بطور تخصصی بر روی این نقش ( منظور Product Owner ) و تمرکز بر ایجاد و نگهداری ارزش برای مشتری بنا نهاده شده است.

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

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

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

برای اطلاعات بیشتر می توانید به این لینک مراجعه بفرمائید.

یاشیاسیز

دسته‌ها:Agile, Kanban, Scrum برچسب‌ها: , ,

پوستر کتاب کانبان و اسکرام

دسته‌ها:Agile, Kanban

کانبان ساده شده

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

کانبان همانند اسکرام یکی از متدهای توسعه چابک می باشد که در این متد توجه بیشتر بر روی ارائه های درجا (just-in-time) و بصری سازی فرآیند توسعه می باشد. کانبان ذاتا از متد تفکری Lean گرفته شده است و بیشتر صنعت گران (بدلیل آشنایی مانند تولید ناب و تویوتا وی) با کانبان آشنا هستند.

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

کانبان در اختصار

کانبان فقط شامل یک تابلو (Board) می باشد که کارهای در جریان روی آن تابلو قرار می گیرد. این تابلو توسط ستون هایی که هر ستون نشان دهنده وضعیت کاری (مثلا در حال توسعه یا در حال تست و یا …) به چندین قسمت تقسیم شده است. کارهای موجود در ستون های مختلف این تابلو سیر می نمایند تا به آخرین ستون برسند .

1.jpg (407×203)نکاتی در رابطه با کانبان

  • برای هر ستون محدودیتی در نظر گرفته می شود که فقط این تعداد کار در هر زمان می تواند در داخل این ستون قرار داشته باشد.  این محدودیت را اصلاحا محدودیت WIP یا Work-in-progress بیان می شود.
  • کانبان یک سیستم کششی می باشد . یعنی اگر تیم تست کاری برای انجام دادن در ستون خود نداشت ، مقدار کاری را (نسبت به محدودیت) از ستون قبلی خود به ستون خود می کشد (پس تیم توسعه حق ندارد کار انجامم شده خود را به ستون تیم توسعه هل بدهد ، برای اینکه آیتم های تکمیل شده هم در این ستون تجمیع نشود از ستون هایی با عنوان صف یا بافر استفاده می شود)
  • تابلوهای مختلفی می توان برای کانبان ایجاد کرد که بهترین تابلو فقط از طریق تجربه به دست خواهد آمد.
  • در کانبان کارها به صورت اسپرینتی نیست که آخر هر اسپرینت ارائه ای انجام شود ، در کانبان هر وقت که لازم شد و یا طبق برنامه ریزی خاصی می توان ارائه داشت و جلساتی مانند بازبینی و بازنگری را انجام داد.
  • نقش ها در کانبان تجویز شده نیستند ولی می توان از نقش های اسکرام (مالک محصول / اسکرام مستر / تیم ) استفاده کرد.
  • کانبان در فاز نگه داری سیستم بسیار خوب عمل می کند.
  • یک تابلوی کانبان بین همه تیم ها و اشخاص مشترک می باشد و نیازی به تابلوهای جداگانه نیست.

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

یاشیاسیز

دسته‌ها:Agile, Kanban, Lean برچسب‌ها: , , ,

دنیای چابک در یک فایل Pdf

ژوئیه 2, 2010 2 دیدگاه

https://sirasad.files.wordpress.com/2010/07/pdf.jpg?w=400یکی از دوستان به نام سعید اسفندی لطف کردند و برای راحتی دوستان دیگر , کل مطالب وبلاگ را (تا به این تاریخ) به صورت فایل PDF در آوردند . در صورت علاقه و تمایل  می توانید از این فایل به طریق لینک زیر استفاده فرمائید.

دانلود فایل Pdf دنیای چابک

از دوست گرامی که زحمت کشیده اند و این فایل را آماده نمودند نهایت تشکر را دارم .

یاشیاسیز

آیا Agile در پروژه های بزرگ جواب خواهد داد ؟

فوریه 12, 2010 بیان دیدگاه

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

https://i0.wp.com/2.bp.blogspot.com/_H0iqHTCqRyo/Rj-ZoyAZv_I/AAAAAAAAAEc/X6q_8mIhqlc/s400/agile+development+-+surprise.jpgبعضی ها می گویند نه و اعتقاد دارند که که Agile فقط یک راه حل کوچک و فنی می باشد . عدم وجود برنامه ریزی از قبل تعیین شده باعث به وجود آمدن موانع در راه پروژه می شود .
و بعضی دیگر می گویند بلی و اذعان دارند که فرآیند قابل گسترش می باشد اما این عمل طول می کشد. و اشتباه از کسانی است که نمی توانند این عمل را درست انجام دهند و ایرادی بر Agile  وارد نمی باشد.

Michael Mah  شما را در این موضوع با ویدئوی خود راهنمایی خواهد کرد.
مشاهده ویدئو

یاشیاسیز

دسته‌ها:Agile, Kanban, Project Management, Scrum برچسب‌ها: ,