توزيع Agile در سازمان

ما می خواهیم به سمت Agile حرکت کنیم، XP، Scrum، Lean، FDD، AUP و شاید دهها اسم دیگر در این دسته از متدلوژیها وجو دارد که من نمی دانم و نشیدنم. ما باید از بین این اسامی کدام را انتخاب کنیم، چگونه انتخاب کنیم و چگونه به سمت آن حرکت کنیم؟ تفاوت اینها نسبت به هم چیست؟ نقاط قوت و ضعف آنها نسبت به هم چیست؟

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

یک انتقاد

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

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

راه حل : تفکر سیستمی

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

سطوح سازمان

در کتابهای مدیریت، سازمان را از لحاظ سطوح مدیریت به سه سطح مختلف تقسیم می کنند :

1-       سطح عالی (استراتژیک – راهبردی) : در این سطح مدیران وظیفه دارند اهداف بلند مدت، آزمانها و استراتژیهای سازمان را تعیین کنند.

2-       سطح میانی : این سطح وظیفه دریافت دستورات و برنامه ها را از سطح عالی سازمان و تبدیل آن به برنامه میان مدت، برنامه هایی اجرایی و زمانبندی شده و ابلاغ آن به سطوح پایین تر را بهعده دارد.

3-       سطح عملیاتی : این سطح مدیریت را سطح درگیر در فعالیت های اجرایی گویند. به عبارت دیگر وظیفه به اجرا گذاردن تصمیمات و دستورات مدیریت عالی و میانی را بعهده دارد.

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

توزیع Agile در سازمان

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

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

نظر شما درباره این راه حل و پاسخ چیست؟

نحوه توزیع Agile در سازمان

5 comments on “توزيع Agile در سازمان

  1. Asad Safari on

    فکر نکنم که هیچکدام از متدهای Agile با همدیگر در تعارض باشند . به نظر من XP باید و حتما باید زیر مجموعه اسکرام قرار بگیرد زیرا که توصیه Technical Excellence در Agile Manifesto از این طریق قابل حصول خواهد بود . ولی در مورد Lean که نیازی نیست زیرا Agile خود برای مبنای Lean است و در اسکرام ما Lean را در نظر می گیریم .

    پس به نظر من اسکرام راهی است برای موفقیت سازمان ها . (با اسکرام رستگار شوید )

    مطلب خوبی بود . ممنون بهروز خان .

    با تشکر

    • بهروز بختیاری on

      در کل متن صحبتی از تعارض بین متدها به میان نیامده است بحث بر سر استفاده از هر متد در مکان و سطح مناسب خود است.
      به نظر من XP نباید زیرمجموعه Scurm باشد و البته نیست. بلکه XP باید در ترکیب با Scrum استفاده شود و البته Scrum هم در ترکیب با XP. جمله زیر صددرصد برایتان آشنا است و فکر کنم حتما قبول می کنید:
      “Scrum focuses on management and organization practices while XP focuses mostly on actual programming practices. That’s why they work well together – they address different
      areas and complement each other.”
      در بالاترین سطح مدیریت هم نه XP و نه Scrum چیز خاصی برای ارائه ندارند و فکر کنم Lean با توجه به منشا و خاستکاه خود می تواند این سطح را تا حد قابل قبولی پوشش دهد و همانطور که خودتان هم اشاره کردید، ارزشها و اصول Lean در سایر سطوح هم استفاده می شود.

  2. Asad Safari on

    آره قبول دارم . اما به نظر من این ها همه باید Native (بومی برای سازمان) بشوند و از ادا کردن مرز XP , اسکرام یا Lean باید پرهیز بشود زیرا همه زیر یک سقف هستند و هدف جز Agile نیست . البته اشتباه نشود که Agile هدف والای یک سازمان نیست بلکه در Transition هدف سازمان دسترسی به اهداف والای سازمانی توسط Agile می باشد .

    به نظر من مشکل در این مورد به این خاطر حادث می شود که سمت حرکتی سازمان درست نیست . یعنی ما با متد می خاییم به Agile برسیم در حالی که متد مهم نیست بلکه ارزش های Agile مهم هستند . همه متدها جز یک پک آماده نیستند . حتی Ken Schewber میگه که حتما برای خودتون اسکرام داشته باشید و نه اسکرام من رو .

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

    موفق باشید

  3. بهروز بختیاری on

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

Comments are closed.