Asad.Safari
جمعه 15 اردیبهشت 1391, 19:33 عصر
شاید برنامه نویسان یا به عبارتی توسعه گران در تیم های نرم افزاری مانع جدی در روند چابک سازی و یا استفاده از متد اسکرام باشند. ولی چگونه و چرا؟
در این سال ها که بسیاری بر روی چابک سازی و لزوم حرکت سازمان ها به سمت چابک شدن صحبت کرده اند ، کتاب نوشته اند و … به نظر میرسد که خوب عمل شده است ، و خیلی ها حتی از جمله شرکت هایی در ایران به این سمت حرکت کرده اند. در این مابین که موسساتی مانند PMI هم که از لزوم چابک شدن صحبت می کنند ، بر اهمیت قضیه می افزایند و شرکت ها و نفرات غیر نرم افزاری را هم به این دنیا علاقمند می سازند.
آماری در سال 2008 توسط موسسه فاستر نشان داد که اسکرام پر طرفدارترین متد از متدهای چابک می باشد و شرکت ها هم بیشتر به سمت استفاده ازاین متد برای چابک شدن حرکت کرده اند.
اما شرکت ها چگونه می توانند از اسکرام استفاده نمایند ؟
در کورس های اسکرام ایران ، با بعضی از مدیران شرکت های نرم افزاری صحبت می کردم ، هدفشان از شرکت در کورس ها را جویا می شدم ؟ و جواب استارت اسکرام در شرکتشان بود. اما واقعا با شرکت در یک دوره اسکرام می توان اسکرام راه انداخت؟
مسلما که خواهد شد ، کسانی که در دوره های اسکرام بودند عنوان اسکرام مستر را یدک می کشیدند. وظیفه یک اسکرام مستر راه اندازی فرآیند اسکرام و مراقبت از این روند می باشد. اما این اسکرام آیا همان اسکرام ایده آل خواهد بود؟ همان اسکرامی که در کتاب ها می نویسند؟ همان اسکرامی که دنیای چابک گفته بود شکست نخواهید خورد ؟ شاید نه …
به مفهموم دیگر ، اسکرام یک فرآیند مدیریت پروژه می باشد و برای همین مدیران شرکت ها و تیم ها به یادگیری آن علاقه نشان می دهند. ولی آیا برنامه نویس مگر قرار نیست در این فرآیند کار کند؟ خوب شاید بگوییم فرآیند تغییر پیدا می کند ولی برنامه نویس لازم نیست تکنیک یا روش جدیدی یاد بگیرد و همین که با مفاهیمی مثل جلسات روزانه سرپایی اسکرام و … آشنا شد کافی هست آن را هم که اسکرام مستر در چند ساعت به بقیه یاد می دهد. شرکت های نرم افزاری ما (البته نه فقط ایران) معمولا دارای برنامه نویسان خوبی است ، ولی از تکنیک ها و روش های سنتی و بزن درویی در فرآیند توسعه استفاده می کنند. معمولا کد تمیز ، نوشتن تست قبل از کد نویسی ، اتوماتیک سازی چرخه ساخت و اینگونه مفاهیم در حد تئوری در تیم های ما جا دارند و نه در عمل.
بدون تعارف ، تنها با تغییر اسمی فرآیند ، ما به بهشت برین دست نخواهیم یافت. ما نیازمند این هستیم که برنامه نویس ها و تمامی توسعه گران به تکنیک ها و روش های جدیدی مجهز شوند. یک جمله در بیانیه چابک “قبول تغییرات در هر لحظه” کسانی که دستی برآتش دارند می دانند که یعنی چه و چه هزینه ای می تواند داشته باشد و شاید اگر دارای چارچوب خوبی نباشیم اصلا امکان پذیر نباشد.
این نگرانی فقط برای تیم های ایرانی نیست ، یعنی در تمام دنیا تیم هایی که می خواستند به سمت اسکرام بروند با این مشکل مواجه شده اند :
“Agile is an excellent approach is you have a small team of highly skilled developers managing themselves in a co-located workplace with great engineering tools and practices.
2002 , in response to the Agile Manifesto, Barry Boehm-
یا
“There’s a mess I’ve heard about with quite a few projects recently. It works out like this
• They want to use an agile process, and pick Scrum
• They adopt the Scrum practices, and maybe even the principles
• After a while progress is slow because the code base is a mess
What’s happened is (people using Scrum) haven’t paid enough attention to the internal quality of their software (…) I’ve mentioned Scrum because when we see this problem, Scrum seems to be particularly common as the nominative process the team is following (…) because Scrum is process that’s centered on project management techniques and deliberately omits any technical practices.
I’m sure that the many Flaccid Scrum projects being run will harm Scrum’s reputation, and probably the broader agile reputation as well.”
– Martin Fowler, January 2009
یا
“By early 2009, (…) more organizations were using Agile processes than waterfall processes (…) However, less than 50% of those using Scrum were developing in incremental iterations, which are the heartbeat of Scrum. (…) One of the biggest challenges of using Scrum has always been the steep learning curve for the developers on the Scrum team.”
– Jeff Sutherland and Ken Schwaber, March 2010
با توجه به این صحبت ها ، ما به تیم هایی نیاز داریم که از نظر فنی و تکنیکی جوابگوی فرآیند اسکرام و اجایل باشند. در همین مورد موسسه ای همچون Scrum.org برای پشتیبانی از اسکرام اقدام به طراحی دوره آموزشی به نام PSD یا Professional Scrum Developer کرده است که در این دوره اقدام به تربیت توسعه گران و برنامه نویسان مناسب با حال و احوال محیط های چابک می کنند. این دوره که یک دوره کاملا عملی است ، یک محیط اسکرام و اجایل برای شرکت کنندگان ایجاد می کنند، تا آنها با کارهایی که یک تیم اجایل در طول پروژه انجام می دهد آشنا شوند و روش ها و تکنیک های آنها را فرا بگیرند.
اما همین دوره در ایران نیز تیرماه برگزار خواهد شد که فرصت مغتنمی برای تیم های نرم افزاری می باشد که از آن استفاده نمایند و گامی برای چابک شدن بردارند.
http://irscrum.com
موفق باشید
در این سال ها که بسیاری بر روی چابک سازی و لزوم حرکت سازمان ها به سمت چابک شدن صحبت کرده اند ، کتاب نوشته اند و … به نظر میرسد که خوب عمل شده است ، و خیلی ها حتی از جمله شرکت هایی در ایران به این سمت حرکت کرده اند. در این مابین که موسساتی مانند PMI هم که از لزوم چابک شدن صحبت می کنند ، بر اهمیت قضیه می افزایند و شرکت ها و نفرات غیر نرم افزاری را هم به این دنیا علاقمند می سازند.
آماری در سال 2008 توسط موسسه فاستر نشان داد که اسکرام پر طرفدارترین متد از متدهای چابک می باشد و شرکت ها هم بیشتر به سمت استفاده ازاین متد برای چابک شدن حرکت کرده اند.
اما شرکت ها چگونه می توانند از اسکرام استفاده نمایند ؟
در کورس های اسکرام ایران ، با بعضی از مدیران شرکت های نرم افزاری صحبت می کردم ، هدفشان از شرکت در کورس ها را جویا می شدم ؟ و جواب استارت اسکرام در شرکتشان بود. اما واقعا با شرکت در یک دوره اسکرام می توان اسکرام راه انداخت؟
مسلما که خواهد شد ، کسانی که در دوره های اسکرام بودند عنوان اسکرام مستر را یدک می کشیدند. وظیفه یک اسکرام مستر راه اندازی فرآیند اسکرام و مراقبت از این روند می باشد. اما این اسکرام آیا همان اسکرام ایده آل خواهد بود؟ همان اسکرامی که در کتاب ها می نویسند؟ همان اسکرامی که دنیای چابک گفته بود شکست نخواهید خورد ؟ شاید نه …
به مفهموم دیگر ، اسکرام یک فرآیند مدیریت پروژه می باشد و برای همین مدیران شرکت ها و تیم ها به یادگیری آن علاقه نشان می دهند. ولی آیا برنامه نویس مگر قرار نیست در این فرآیند کار کند؟ خوب شاید بگوییم فرآیند تغییر پیدا می کند ولی برنامه نویس لازم نیست تکنیک یا روش جدیدی یاد بگیرد و همین که با مفاهیمی مثل جلسات روزانه سرپایی اسکرام و … آشنا شد کافی هست آن را هم که اسکرام مستر در چند ساعت به بقیه یاد می دهد. شرکت های نرم افزاری ما (البته نه فقط ایران) معمولا دارای برنامه نویسان خوبی است ، ولی از تکنیک ها و روش های سنتی و بزن درویی در فرآیند توسعه استفاده می کنند. معمولا کد تمیز ، نوشتن تست قبل از کد نویسی ، اتوماتیک سازی چرخه ساخت و اینگونه مفاهیم در حد تئوری در تیم های ما جا دارند و نه در عمل.
بدون تعارف ، تنها با تغییر اسمی فرآیند ، ما به بهشت برین دست نخواهیم یافت. ما نیازمند این هستیم که برنامه نویس ها و تمامی توسعه گران به تکنیک ها و روش های جدیدی مجهز شوند. یک جمله در بیانیه چابک “قبول تغییرات در هر لحظه” کسانی که دستی برآتش دارند می دانند که یعنی چه و چه هزینه ای می تواند داشته باشد و شاید اگر دارای چارچوب خوبی نباشیم اصلا امکان پذیر نباشد.
این نگرانی فقط برای تیم های ایرانی نیست ، یعنی در تمام دنیا تیم هایی که می خواستند به سمت اسکرام بروند با این مشکل مواجه شده اند :
“Agile is an excellent approach is you have a small team of highly skilled developers managing themselves in a co-located workplace with great engineering tools and practices.
2002 , in response to the Agile Manifesto, Barry Boehm-
یا
“There’s a mess I’ve heard about with quite a few projects recently. It works out like this
• They want to use an agile process, and pick Scrum
• They adopt the Scrum practices, and maybe even the principles
• After a while progress is slow because the code base is a mess
What’s happened is (people using Scrum) haven’t paid enough attention to the internal quality of their software (…) I’ve mentioned Scrum because when we see this problem, Scrum seems to be particularly common as the nominative process the team is following (…) because Scrum is process that’s centered on project management techniques and deliberately omits any technical practices.
I’m sure that the many Flaccid Scrum projects being run will harm Scrum’s reputation, and probably the broader agile reputation as well.”
– Martin Fowler, January 2009
یا
“By early 2009, (…) more organizations were using Agile processes than waterfall processes (…) However, less than 50% of those using Scrum were developing in incremental iterations, which are the heartbeat of Scrum. (…) One of the biggest challenges of using Scrum has always been the steep learning curve for the developers on the Scrum team.”
– Jeff Sutherland and Ken Schwaber, March 2010
با توجه به این صحبت ها ، ما به تیم هایی نیاز داریم که از نظر فنی و تکنیکی جوابگوی فرآیند اسکرام و اجایل باشند. در همین مورد موسسه ای همچون Scrum.org برای پشتیبانی از اسکرام اقدام به طراحی دوره آموزشی به نام PSD یا Professional Scrum Developer کرده است که در این دوره اقدام به تربیت توسعه گران و برنامه نویسان مناسب با حال و احوال محیط های چابک می کنند. این دوره که یک دوره کاملا عملی است ، یک محیط اسکرام و اجایل برای شرکت کنندگان ایجاد می کنند، تا آنها با کارهایی که یک تیم اجایل در طول پروژه انجام می دهد آشنا شوند و روش ها و تکنیک های آنها را فرا بگیرند.
اما همین دوره در ایران نیز تیرماه برگزار خواهد شد که فرصت مغتنمی برای تیم های نرم افزاری می باشد که از آن استفاده نمایند و گامی برای چابک شدن بردارند.
http://irscrum.com
موفق باشید