بایگانی

بایگانیِ دستهٔ ‘Programming’

آیا Agile نیازی به Technical Excellence دارد؟

اوت 24, 2010 4 دیدگاه

Technical Excellence یکی از مبحث های Agile می باشد که یا مورد محبت زیاد و یا کم مهری بیش از اندازه  قرار می گیرد .  البته این مسئله صرفا برای ایران نیست و تیم های تازه کار Agile با این مشکل مواجه می شوند.  در آیه شماره 9 اصول توسعه چابک آمده است :

http://sirasad.files.wordpress.com/2010/08/images.jpg?w=145&h=145Continuous attention to technical excellence
and good design enhances agility

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

ولی طبق تجربه من عرض می کنم که این اصل را قبول ندارم و این را می توان بیان کنم که : » بدون Technical Excellence چابک بودن امکان پذیر نخواهد بود » . و دغدغه نوشتن پستی فقط و فقط بیان لزوم برتری فنی برای تیم های Agile می باشد .

قبل از بیان لزوم برتری فنی لازم است تعریفی از Technical Excellence داشته باشیم :

Technical Excellence یا همان برتری فنی به معنی استفاده از ابزارها ,  روش ها ,  تکنیک ها ,  متد ها و … برتر در پروسه طراحی ,  تست و کد نویسی می باشد . از جمله Technical Excellence ها مورد بحث و مهم در زمینه چابک Unit Testing , Refactor , Continues Integration  , Clear Code , Automated Tests , TDD , … .و البته که تمام موارد فنی جزو این برتری فنی حساب خواهند شد .

برای اثبات مطلب ارائه شده (بدون Technical Excellence چابک بودن امکان پذیر نخواهد بود) کافی است با هم یک مثال کوچک را بررسی نماییم : در ارزش 4 ام بیانیه توسعه چابک آمده است :

Responding to change over following a plan

بیان شده است که ما به عنوان یک تیم چابک باید بتوانیم پذیرای تغییرات باشیم .

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

فرض کنید ما یک تیم Agile هستیم که اعتقادی به Technical Excellence نداریم و این را هم می دانیم که برای پذیرایی از تغییرات باید کد های تمیزی داشته باشیم . برای داشتن کد تمیز باید کدها Refactor  شده باشند . برای رفاکتور شدن کد های نیاز به تست های اتوماتیک و کلا Unit Testing داریم . Unit Test ها باید برروی یک Continues Integration قرار بگیرند .

http://sirasad.files.wordpress.com/2010/08/b5391b73f65841c4a9c49d0e2c9aec2d1.jpg?w=133&h=180حالا ما به عنوان یک تیم Agile چگونه می خواهیم بدون Technical Excellence پذیرای تغییرات باشیم ؟ اگر نمی خواهیم پذیرای تغییرات باشیم ,  پس چگونه اسم خودمان را تیم Agile یا چابک نامیده ایم ؟

این فقط یک مثال کوچک از لزوم Technical Excellence بود که خواستم از این طریق عرض کنم : موارد و اصولی که در بیانیه توسعه چابک بیان شده است ,  همینطوری کشکی نیست و نمی شود گفت که این به درد ما نمی خورد بنداز دور . نوشتن چنین نوشته هایی از آنجایی برای من اهمیت پیدامی کند که می شنوم : » ما Agile کار می کنیم  ,  ولی Unit Test نداریم . «

البته این معضل فقط برای Agile نیست ,  بنده تیم هایی (گردن کلفت) را دیدم که ادعای کار با RUP را می کردند ولی در واقع همان سنت حسنه Waterfall را ادامه می دادند . پیشنهاد من این است که  Agile  کار نکنیم بلکه Agile باشیم که اینگونه همه چیز حل خواهد شد .

به امید تیم های Agile در سرتاسر جهان .

یاشیاسیز

مطالب مرتبط با این بحث :

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

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

http://sirasad.files.wordpress.com/2010/07/cartoon_planning.gif?w=240&h=208این جریان مدیر پروژه شدن برنامه نویس ها در ایران حکایتی بس طولانی دارد که در این پست قصد مختصر بررسی در این باب را دارم . قبل از شروع بحث موردنظر  لازم می بینم  نظر خودم را در مورد لزوم مدیر پروژه در پروژه های توسعه نرم افزار عرض کنم : به نظر بنده در 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 . یعنی طرف به عنوان برنامه نویس خیلی موفقه و به همین دلیل یک هاله نوری او را احاطه می کنه که می تواند به عنوان مدیر پروژه کار کند و بدین گونه می شود که برنامه نویس مدیر پروژه می شود .

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

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

یاشیاسیز

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

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

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

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

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

یاشیاسیز

دنبال‌کردن

هر نوشتهٔ تازه‌ای را در نامه‌دان خود دریافت نمایید.