بایگانی

Posts Tagged ‘Project Management’

نجات پروژه شکست خورده توسط اسکرام

فوریه 23, 2011 2 دیدگاه

https://sirasad.files.wordpress.com/2011/02/cpr2-300x300.jpg?w=300شاید این حقیقت بسیار تلخی باشد که در عرصه صنعت توسعه نرم افزار تعداد زیادی از پروژه ها با شکست مواجه و در برزخ گرفتار می شوند. نجات دادن و یا بازگردانی این پروژه ها بر روی ریل معمولا کار سختی است زیرا زمانی متوجه می شوند  پروژه مرده است که دیگر امکان بازگردانی وجود ندارد یا حداقل خیلی سخت است.

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

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

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

شاید سوال پیش بیاید که چگونه باید شفاف سازی کرد؟

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

بک لاگ موارد ساخته نشده که دقیقا مانند بک لاگ محصول می باشد و بک لاگ موارد مشکل دار و تست نشده هم شامل آیتم هایی خواهد بود که یا تست نشده اند (تست پذیرش مشتری و تست یکپارچه سازی و … ) و یا مشکل دار هستند. گذشته از اینکه یک یا دو بک لاگ داشته باشید باید بک لاگ (ها) را برآورد نمایید که آن هم بر اساس Story Point  خواهد بود.

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

https://sirasad.files.wordpress.com/2011/02/wayne-rooney-007.jpg?w=460 فرض کنید یک پروژه با زمان 1 سال داشتیم و بعد از 9 ماه فهمیدیم که در حال کج روی هستیم و خواستیم شفاف سازی نماییم. بعد از شفاف سازی فهمیدیم 200 پوینت آیتم داریم و 3 ماه هم وقت. طول اسپرینت های ما هم 4 هفته بود و با اندازه گیری سرعت به این نتیجه رسیدیم که تیم قادر است در هر اسپرینت 10 پوینت انجام بدهد. حالا این 200 پوینت با این سرعت 10 پوینتی به چند ماه کار نیاز دارد؟

بعد از این , مشکل مدیریتی خواهد بود. مثلا مدیریت می تواند با افزایش تعداد نفرات و تیم ها سرعت و ظرفیت انجام کار را بالا ببرد و یا می تواند با رایزنی از دامنه پروژه بکاهد و یا امثالهم.

اما بهترین تصمیم و یا عملکرد مدیریتی در این شرایط می تواند رفع موانع و درگیری های موجود می باشد, موانعی مانند موارد زیر :

  • فشار بر روی تیم
  • تست ها و پروسه های غیر موثر (مانند قوانین کدنویسی شرکتی)
  • فقدان کار تیمی و انگیزه در نفرات
  • انتظارات غیر واقعی
  • عدم تمرکز شرکت بر روی پروژه
  • مدیریت دستور- و – کنترل به جای خود سازماندهی

هر یک از این موارد ذکر شده تاثیر به سزایی بر روی ظرفیت و سرعت تیم و دیگر المان های موفقیت پروژه خواهد داشت مثلا فشار بیش از حد روی تیم باعث از بین رفتن انگیزه در تیم می شود و این نیز باعث افت شدید سرعت خواهد شد و … .

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

یاشیاسیز

Advertisements

خروجی کارآ در Agile

دسامبر 13, 2010 8 دیدگاه

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

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

شکل های زیر جوابگوی این سوالات خواهند بود :

https://sirasad.files.wordpress.com/2010/12/dsc00003.jpg?w=592

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

شاید این ذهنیت به وجود بیاید که «باعث به وجود آمدن این خروجی ناکارآمد مشتری بوده است زیرا او در ابتدا نمی دانسته است چه می خواهد و این مشکل ربطی به تیم توسعه ندارد».  البته شاید در این مثال بدین گونه باشد ولی همیشه اینطور نیست و نخواهد بود. برای مثال شاید مشتری از اول B را در ذهن خود داشته ولی در ارتباطات و قرار داد بدلیل تعامل کم و کج فهمی تیم توسعه محصول ناکارآمد به وجود آمده است.خیلی دلایل می تواند باعث کج روی تیم بشود که این دلایل اصلا مهم نیستند و مهم این است که خروجی کارآ باشد.

اما در محیط Agile برای این که بتوانیم همان محصول را به گونه کارآ توسعه دهیم می توانیم به گونه زیر عمل نماییم:

https://sirasad.files.wordpress.com/2010/12/dsc00004.jpg?w=592

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

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

البته با مقایسه اشکال بالا به نکات موثرتری پی خواهید برد.

یاشیاسیز

برنامه نویسی که مدیر پروژه شد

ژوئیه 26, 2010 24 دیدگاه

https://sirasad.files.wordpress.com/2010/07/cartoon_planning.gif?w=300این جریان مدیر پروژه شدن برنامه نویس ها در ایران حکایتی بس طولانی دارد که در این پست قصد مختصر بررسی در این باب را دارم . قبل از شروع بحث موردنظر  لازم می بینم  نظر خودم را در مورد لزوم مدیر پروژه در پروژه های توسعه نرم افزار عرض کنم : به نظر بنده در 90% پروژه های توسعه نرم افزار در ایران نیازی به نقشی با نام مدیر پروژه نیست زیرا این پروژه  ها دارای خصوصیات یک پروژه واقعی نیستند که نیازی به مدیریت پروژه باشد : مثلا به مدیر پروژه بودجه اختصاص داده نمی شود که او بتواند Cost Management بکند یا بتواند نیروی کار مورد نیاز را استخدام بکند و یا … . به طوری کلی مدیر پروژه ای که در اینگونه پروژه ها فعالیت می کند دارای مجوز و اختیارات لازم نیست : یعنی عملا Iron Triangle پروژه در دستان او نیست . البته علاوه بر اینکه مالکان شرکت او را محدود کرده اند ,  او وظایف یک مدیر پروژه را نیز انجام نمی دهد . برای مثال یک شرکت آگهی زده است که :

به یک مدیر پروژه نرم افزاری  حاذق نیازمندیم با شرایط ذیل :

  • توانایی کامل طرح ریزی کامل پروژه
  • توانایی مدیریت
  • توانایی برنامه نویس با زبان #C

کاملا از شرایط درخواستی معلوم است کسی که قرار است این کارها را انجام بدهد اسمش مدیر پروژه نیست (البته با توجه به تعاریف انیستیتو PMI ) . در ایران انتظار میرود که مدیر پروژه کل پروژه را طرح ریزی و طراحی کند . یعنی او عملا کار تحلیل گر و طراح را انجام می دهد  . بلی بنده قبول دارم که مدیر پروژه باید توانایی طرح ریزی داشته باشد ولی نه تحلیل و طراحی محصول  در بعد فنی و تکنیکی مثلا استخراج Class Diagram ؟ ! بلکه او در سطح مدیریت  باید طرح ریزی نماید : Road Map پروژه را مشخص کند ,  ریسک های پروژه را معلوم بکند و … .

انتظار بعدی این است توانایی مدیریت داشته باشد : خوب خیلی خوب است ولی توانایی مدیریت یعنی اینکه تقسیم وظایف برعهده او خواهد بود . مدیریت منابع انسانی (HR) تقسیم وظایف نیست . (مثلا از او انتظار میرود که وظایف برنامه نویسان را در هر ساعت مشخص کند) .

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

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

حکایت اینکه برنامه نویس مدیر پروژه می شود دقیقا مانند حکایت دندانپزشک شدن سلمونی ها در قدیم بود :

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

به نقل از نادر خرمی راد

http://images.travelpod.com/users/uncle_davros/the_world.1146204120.dhaka_-_019_street_dentist.jpgهم اکنون طبق گفته بالا ما مدیر پرژه نداریم بلکه سلمونی ها و یا برنامه نویس ها دارند اینکار رو برای ما انجام می دهند . منتهی تنها دلیلی که باعث می شود که یک برنامه نویس احساس مدیر پروژه بودن بکند چیزی نیست جز Halo Effect . یعنی طرف به عنوان برنامه نویس خیلی موفقه و به همین دلیل یک هاله نوری او را احاطه می کنه که می تواند به عنوان مدیر پروژه کار کند و بدین گونه می شود که برنامه نویس مدیر پروژه می شود .

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

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

یاشیاسیز

ایجاد تیم های قدرتمند

ژوئیه 7, 2010 3 دیدگاه

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

https://i1.wp.com/ecx.images-amazon.com/images/I/41HGXP1C5ZL._SL500_AA300_.jpg

https://i2.wp.com/ecx.images-amazon.com/images/I/51sjDWgJXFL._.jpg

https://i1.wp.com/ecx.images-amazon.com/images/I/412y5AfggSL.__.jpg

https://i0.wp.com/ecx.images-amazon.com/images/I/51oOQhKSm5L.__.jpghttps://i1.wp.com/ecx.images-amazon.com/images/I/51qutgV40nL.__.jpg

یاشیاسیز

چابک سازی سازمان و چرا ها

مه 18, 2010 5 دیدگاه

https://sirasad.files.wordpress.com/2010/05/agile.jpg?w=592طی درخواست یکی از مدیران شرکت توسعه نرم افزار پ .س (اسم نبردم شاید علاقمند نباشند) در مورد امکان مشاوره و مربی گری Agile بنده برای آن شرکت , 3 سوال اساسی توسط ایشان مطرح گردید که در این پست قصد طرح و جواب دادن این سوالات را دارم  . به این دلیل که شاید دیگر مدیران و یا اشخاص که علاقمند به دانستن و آشنایی با این مسئله باشند این جواب به صورت سرگشاده ارائه گردید .

سوالات مطرح شده به قرار زیر می باشد :

  • یک سازمان چه پیش فرض ها و نیازمندی هایی برای Agile شدن نیازدارد؟
  • برنامه من برای Agile کردن سازمان چیست ؟
  • عواید و منافع این کار برای سازمان چه چیز می باشد و چگونه می توان آن را اندازه گرفت؟

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

https://sirasad.files.wordpress.com/2010/05/a305-distributed-agile-development.jpg?w=280خوب بیان این مسئله و جواب سوال , » برای اینکه Agile بشویم چه چیز می خواهد»  در واقع بسیار سخت و مشکل می باشد بدلیل اینکه شرایط از هر تیم به تیم دیگر متفاوت خواهد بود و نمی توان یک نسخه واحد پیچید . ولی می توان گفت که Agile شدن برای تیم ها سختی و راحتی خواهد داشت . یعنی اینکه یک تیم با شرایط راحت تر و کم هزینه تر خواهد توانست Agile شود و یک تیم سخت و پر هزینه تر Agile خواهد شد . پس می توان گفت همه تیم ها و سازمان ها  شاید  توانایی Agile شدن را خواهند داشت ولی با درجه سختی متفاوت .

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

برای درک مسئله بهتر است یک مثال زده شود . فرض کنید بنده در تلویزیون مسابقه دو (دوندگی) را می بینم و مشاهده می کنم که به فرد برنده 400 میلیون دلار جایزه می دهند . با توجه به جایزه خوب وسوسه می شوم فردا در دوی مارتن شرکت کنم ولی بدون آمادگی و ارزیابی توانایی ها و ظرفیت های خودم . زمان مسابقه چند صد متر ندویده خسته می شوم و خواهم ماند . در این حالت دو حالت خواهم داشت :1- خواهم توانست تا به خانه برگردم و از دیدن مسابقه در تلویزیون لذت ببرم  2- ایست قلبی می کنم  و خداحافظ.

برای سازمان ها و شرکت های توسعه نرم افزار هم بدینگونه است . نمی توان با عجله و بدون ارزیابی توانایی سازمان و افراد شروع به چابک شدن کرد . مثلا فردا روز آقای مدیر از راه  می رسد و همه کارکنان رو جمع می کند و بعد از نطق در مورد فواید Agile می فرماید : «دوستان امروز می خواهیم Agile بشویم و سعی کنید تا امروز عصر کار را تمام کنید  ,  اینم مقالات وبلاگ دنیای چابک ,  زود بخونید تا شروع کنیم . هی ممد تو اسکرام مستر , خانم منشی به اون کاظمی (مشتری) زنگ بزن بیاد که اون Product owner ماست , دوستان زود باشید که سود ها و پول های کلان منتظر ما هستند و دیر بجنبیم از کف رفتند » .  و اینگونه خواهد بود که شاید بر خواهیم گشت به متد قبلی و یا ایست قلبی .

در مورد مثال دونده یک راه سومی هم وجود دارد و آن هم این است که من به موقع و در زمان مناسب در مارتن شرکت کنم . خوب عرض شد زمان مناسب ؟ زمان مناسب در این مثال این است که بنده به پیش یک مربی  دومیدانی بروم و او بنده را عرض یابی نماید و با توجه به توانایی جسمانی و روحانی بنده  ,  بنده را مورد آموزش و تمرین قرار دهد . زمانی که به توانایی لازم رسیدم می توانم در مارتن شرکت کنم . پس منتظر زمان مناسب خواهم بود .https://sirasad.files.wordpress.com/2010/05/tired_runner-758783.jpg?w=200

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

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

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

Agile می تواند در محیط ها و شرایط  زیر راحت ترو بهتر اعمال شود (و Agile کلا مناسب حال شرایط زیر می باشد) :

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

برای موانع در مورد  اعمال Agile هم می توان به موارد زیر اشاره کرد :

  • کمبود دانش Agile
  • تیم های بسیار بزرگ
  • توسعه به صورت توزیعی و گسترده به صورت فرا محلی
  • قراردادهای بسته (از نظر قیمتی و دامنه پروژه)
  • نیروی کار نابلد و یا نیروی کار تازه وارد و تازه تیم شده
  • حرکت به صورت سریع

موارد بالا شاید فقط تعدادی از موانع پیش روی تیم های و سازمان ها Agile هستند و برای اطلاعات بیشتر باید سازمان مورد بررسی قرار بگیرد .

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

اما در مورد سوال دوم . سوال شده است که برنامه بنده برای انتقال سازمان ها به Agile چه می باشد؟

برنامه و طرح بنده برای ارائه و کمک به سازمان ها برای انتقال به Agile شامل موارد زیر می تواند باشد:

  • بررسی سازمان و تعیین وضعیت فعلی سازمان
  • آموزش و نهادینه سازی ارزش ها و اصول Agile
  • آموزش اسکرام
  • برگزاری کارگاههای آموزشی در مورد متد اسکرام و XP
  • برپایی و استارت Agile در سازمان
  • بررسی وضع و نظارت بر عملکرد
  • برگزاری جلسات بازبینی عملکرد و تعیین روش های بهبود وضعیت

در حالت کلی برنامه در 4 سطح قابل تعریف خواهد بود : 1- بررسی 2- آموزش 3- اجرا 4- بازبینی

اما این طرح به صورت 100% نیست زیرا تیم ها و شرایط فرق می کنند و باید موارد و طرح هایی بعد از انجام کاری هایی پیش بینی شوند . یعنی آموزش به صورت 100% نیست . شاید در هنگام اجرا نیاز به آموزش دوباره تیم باشد . شاید بعضی از اصول Agile را باید فراموش کرد و شاید … و اینها همه به شرایط سازمان و افراد بستگی دارند. بدلیل اینکه عکس العمل و رفتار افراد در مقابل تغییرات قابل پیش بینی نیست ,  باید برنامه هایی در مورد عکس العمل های نشان داده شده بعد از اجرای Agile  طرح ریزی کرد .

ولی در کل هدف ما ارائه و عمل به مفهوم زیر در هر سازمان Agile خواهد بود :

https://sirasad.files.wordpress.com/2010/05/agilegoal.jpg

از طریق انجام و عمل به مفاهیم و اصول اصلی Agile خواهیم توانست به استراتژی درون سازمانی برسیم . مثلا با عمل به اصل «قبول و پذیرایی از تغییرات » که یکی از اصول Agile می باشد و در برنامه ما هم خواهد بود خواهیم توانست به یکی از استراتژی های اصلی سازمان که «ابقاء مشتریان » می باشد دست بیابیم  , که تحقق هر استراتژی سازمان مصادف با نزدیکی به هدف سازمان می باشد ,  که هدف سازمان شامل سود و منافع بیشتر می باشد .

اما در مورد سوال سوم . پرسیده شده است : «عواید و منافع Agile شدن  برای سازمان چه چیز می باشد و چگونه می توان آن را اندازه گرفت؟»

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

https://sirasad.files.wordpress.com/2010/05/agilechart.jpg?w=592

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

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

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

اگر سازمان بتواند دوران بحران را به سلامت بگذراند خواهد توانست به منافع خوبی دست بیابد : اعم از رضایت مشتری ,  سود بیشتر و … . برای باور بهتر این قضیه بهتر است دست به دامن آمار و ارقام شویم و مشاهده کنیم که کشورهای موفق و پیشرفته جهان با Agile به چه دستاوردهایی دست یافتده اند .

شرکت  VersionOne در سال 2007 آمارگیری در زمینه Agile انجام داد . در این آمارگیری 1500 نفر از 71 کشور مختلف حضور داشته اند . در این آمارگیری VersionOne خواسته تا بداند این 1500 نفر در شرکت هایشان که با Agile کار می کنند تا چه حد موفق بوده اند و نتیجه آمارگیری به صورت زیربوده است : (شاید قابل باور نباشد)

https://sirasad.files.wordpress.com/2010/05/agilebenefit.jpg

هر یک از ستون ها یک شاخص بسیار مهم برای یک شرکت توسعه نرم افزار می باشد . مثلا شرکت ها اذعان داشته اند که بعد استفاده از Agile  توانسته اند 90%  به بهروری خود بیفزایند که بسیار گام خوبی می باشد یا 66% در هزینه ها کاهش داشته اند که بسیار عالی است . البته این اعداد در بهترین حالت ها و در کشورهای متمدن جهان با فرهنگی بالا در زمینه توسعه نرم افزار جمع آوری شده است و در ایران هم می توان به متوسط  این اعداد دست یافت (فردا روز یقه ما رو نگیرید که چرا ما به 90% بهروری بیشتر نرسیدیم ) .

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

البته برای هر یک از سوالات می توان چندین سمینار ارائه کرد و یا  کتاب نوشت ولی در این نوشتار امیدوارم توانسته باشم به سوالات مطرح شده  اندکی جواب بدهم .

یاشیاسیز

رهبری تیم و خصوصیات یک رهبر خوب

آوریل 15, 2010 7 دیدگاه

https://sirasad.files.wordpress.com/2010/04/dragon-boat-race.jpg?w=592در طی نوشته های قبلی در مود مدیریت پروژه به چندین وظیفه یک مدیر پروژه اشاره کردم که در این پست می خواهم در مورد خصوصیت رهبری یک مدیر پروژه صحبت نمایم . یک رهبر می تواند صرفا یک مدیر پروژه نباشد ولی هر مدیر پروژه باید رهبر هم باشد . این موضوع را از این حیث عرض کردم که  در بعضی از پروژه ها توسعه نرم افزار در ایران  شاهد این هستیم که نفری به عنوان یک مدیر پروژه وجود ندارد . در مواردی هم که وجود دارد , وی تنها کاری که انجام نمی دهد مدیریت پروژه است پس قابل ذکر است رهبر تیم یا Leader می تواند در تیم های توسعه نرم افزارخوب جواب بدهد و کافی باشد . این رهبر همانند سرمربی تیم های فوتبال عمل می کند و کار وی چینش بازیکنان و ارائه خط مشی بازی است.

در زیر لیستی از خصوصیات یک رهبر واقعی و خوب آمده است :

  • چشم ها را به سوی Big Picture می دوزد : زمانی که تیم با یک مسئله دشوار روبرو می شود ,  معمولا اعضای تیم ناخواسته از مسیر اصلی پروژه خارج می شوند بدلیل اینکه تمام حواس ویا بااصطلاح فوکوس تیم بر روی مسئله و یا مشکل جاری میرود. به عبارت دیگر مشکلی که وجود دارد این است که مشکل در حیطه خود مشکل حل می شود و نه نسبت به اهداف  کلی پروژه که مشتری انتظار دارد  . در این جا است که رهبر باید تیم را طوری هدایت نماید که تیم دوباره مشکل را بر اساس Big Picture و در راستای اهداف پروژه حل نماید . پس یکی از وظایف رهبر تیم ,  هدایت تیم زیر سایه Big Picture است.
  • نگه داری همبستگی تیمی : زمانی که پروژه با مشکل حادی مواجه می شود , مثلا در عرضه محصول تاخیر چند ماهه به وجود می آید و بدلیل فشار از طرف مشتری و مدیران شرکت ,  این فشار باعث می شود که همبستگی تیمی که در شروع پروژه به وجود آمده بود کم کم از بین برود . اعضای تیم به یکدیگر بد بین خواهند شد . همه دنبال تقصیر کار خواهند بود  و اگر اجازه بدهیم همدیگر را ترور خواهند کرد .  در ترکی یک مثل داریم که می گوید : «یر برک اولاندا ,  اوکوز اوکوز دن اینجییر »   معنی لفظی این مثل این می شود که شما فرض کنید دو تا گاو که در حال شخم زدن یک زمین زراعی می باشند اگر زمین مزرعه سخت و سفت باشد این گاوها از همدیگر ناراحت خواهند شد و هر یک دیگری را مقصر خواهند دانست . در اینجا است که رهبر تیم باید بتواند چنین شرایطی را کنترل و مدیریت نماید و سعی نماید که همبستگی تیمی خدشه دار نشود .
  • اولین فدایی هستند : اگر در پروژه لازم باشد که تیم سختی بکشد باید رهبر تیم اولین کسی باشد که این سختی را تحمل می نماید . اگر لازم باشد اضافه کاری بشود باید رهبر تیم بهترین کار خود را در این اضافه کاری انجام دهد . اگر لازم باشد در روز تعطیل مثلا جمعه ها ملت به سرکار بیایند باید رهبر تیم از همه زودتر بیاید  و از همه دیرتر برود .
  • توانایی آرامش : یک رهبر باید بتواند به مشکلات در آرامش و بدون هیچ وحشتی فکر نماید تا بتواند بهترین تصمیمات را بگیرد . اگر رهبر تیم وحشت زده شود صدرصد این وحشت را به اعضای تیم انتقال خواهد داد و پروژه به ناکجاآباد خواهد کشید . این مسئله عین این است که تیم فوتبال ما 2 گل خورده است و دقیقه 60 بازی است و مدیر باشگاه می گوید اگر بازی را ببازید همه شما را اخراج خواهم کرد  . مربی اگر بتواند آرامش خود را حفظ نماید پس خواهد توانست تصمیمات عاقلانه ای را بگیرد در غیر اینصورت کل تیم را مضطرب خواهد کرد و تیم 5 تا گل دیگر خواهد خورد.
  • انگیزه بخشی : یکی دیگر از وظایف رهبر تیم توانایی انگیزه بخشی به اعضای تیم می باشد که در این مورد در پست قبلی به صورت مفصل صحبت کردیم .
  • خلق پیروزی های کوچک : در پروژه های توسعه نرم افزار خروجی همانند فتح قله اورست می باشد . زمانیکه پروژه Deploy شد و مشکلی خاصی در عرضه محصول به مشتری نبود همه اعضای تیم در حال پرواز می باشند و انگار در جنگ جهانی پیروز شده اند و در حال برگشت به خانه هستند . در متدولوژی هایی مانند RUP یا Waterfall این خروجی بعد چندین ماه و یا سال به وجود می آید که باعث دلمردگی و فرسودگی افراد و اعضای تیم می شود ولی اگر تیم به سبک Agile کار نماید ,  بدلیل اینکه خروجی مثلا هر 3 هفته یک بار به وجود می آید پس هر 3 هفته شاهد یک پیروزی خواهیم بود . معمولا به یمن و شادباش این پیروزی بعد از هر Sprint به همه اعضای تیم 2 , 3 روزی مرخصی داده می شود تا بتوانند طمع خوش پیروزی را بچشند .

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

یاشیاسیز

مدیر پروژه و تغییر دامنه

مارس 6, 2010 10 دیدگاه
هر پروژه ای که کار می شود باید در زمان خاص و با هزینه خاص تمام شود . که در این زمان و با این هزینه نیازمندی هایی که تعریف شده اند پیاده سازی می شود . این همان مثلث آهنین مدیریت پروژه می باشد : هزینه ,  زمان و دامنه .

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

https://i0.wp.com/www.targotennisberg.com/tarkvara/wp-content/uploads/2008/06/scope_creep.jpg

اصطلاح Scope creep چیست ؟ Scope creep یعنی تحدی از حدود و این زمانی اتفاق می افتد که شما خط دامنه را تغییر دهید.

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

بر طبق PMBOK تعریف دقیق Scope creep عبارتست از : اضافه کردن ویژگی و قابلیت جدید به دامنه بدون در نظر گرفتن تاثیر آن برروی هزینه و زمان پروژه (مثلث آهنین) .

بزرگ شدن دامنه پروژه یعنی هزینه اضافی و زمان بیشتر و دست آخر یعنی Fail پروژه . علت شکست تعداد زیادی از پروژه های نرم افزاری به همین دلیل بوده است .

تغییر دامنه می تواند از موارد زیر سرچشمه گرفته باشد :

  • کنترل تغییر ضعیف (Change control)
  • عدم جمع آوری لیست نیازمندی ها قبل از شروع پروژه به صورت کامل
  • عدم تاثیر دادن و تاثیر گرفتن از Product Owner

تغییر دامنه در دو سطح می تواند اتفاق بیفتد :

  1. تغییر دامنه فنی و تکنیکی (Technical Scope Creep)
  2. تغییر دامنه کسب و کار (Business Scope Creep)

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

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

بهترین راه برای مقابله با Scope Creep پرهیز از مواجه با آن می باشد . در زیر روش هایی برای مقابله یا پرهیز از Scope Creep بر شمرده شده است :

  • اولین راه همان Agile است ( به راه راست رستگار شوید)
  • حتما در اول شروع پروژه Product Owner را به جمع خود اضافه نمایید.
  • جمع آوری نیازمندی ها به صورت کامل در هنگام شروع پروژه .
  • CBB خود را بسازید – CBB مخفف Change Control Board می باشد که شامل یک کمیته از اعضای تیم توسعه می باشد معمولا اعضای کنه کار گروه و البته حرفه ای  . ریسک پیاده سازی مواردی که باید تغییر پیدا کنند  توسط این کمیته بررسی می شود .
  • پروژه را متوقف نمایید . تغییرات را دامنه بندی نمایید و بر طبق دامنه جدید عمل نمایید البته اگر ریسکش را به جان می خرید .

یاشیاسیز