مدیریت اجایل از تئوری تا کاربرد

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

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

در حالی که بیشتر فعالیت های ما به صورت مشتری محور و نتیجه گرایانه انجام میشه، گاهی شرایط ایجاب می کنه که چارچوب های معنایی که این متد ها تعریف می کنن، به نفع ما تغییر داده بشن.


چارچوب Sprint:

اسپرینت ها محدوده زمانی مشخصی هستن که Feature ها در این مدت به وجود میان، تست و اصلاح شده و در نهایت آماده ارائه به مشتری میشن.

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

دقت داشته باشیم که در سیستم های نتیجه گرا، همیشه هدف پایانی که بهش میرسیم مهم هست و تمامی متد ها و شیوه های انجام کار برای رسیدن به این نتایج کاربرد پیدا می کنن.

راهکار: زمانی که تغییرات تا این حد سریع هستن که برنامه اولیه یک Sprint رو تا این حد دستخوش تغییر می کنن گاهی لازمه تا زمان Sprint ها به اندازه حداقل یعنی یک تا دو هفته کوتاه بشه. ضمن اینکه با بالا بودن میزان کار تیمی افراد و همینطور قابلیت های Context Switching افراد بتونن بدون اینکه از تغییرات سریع و درخواست های زیاد Business دچار ناراحتی یا مشکل بشن، به کارشون ادامه بدن.

این شرایط نیاز به Release Management خیلی خوب داره همینطور که تیم توسعه این امکان رو داشته باشن تا در زمانی که فرصت دوباره ایجاد شد، به سراغ کار نیمه رها شده رفته و با دقت Project Controller ها، کاری از قلم نیوفته و همواره در زمان بررسی کار های باقیمانده لیست کاملی از موارد در اختیار مدیران قرار داشته باشه.


مستند سازی Documentation:

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

بعنوان مثال ممکنه تیمی تصمیم بگیره که Documentation در حال حاضر معنای یک کار اضافی و اتلاف وقت و هزینه رو میده. در صورتی که در آموزش های پایه ای Agile به Documentation اشاره و تاکید شده.

راهکار: زمانی که تیم کاری ما تصمیم میگیره feature جدیدی رو ایجاد کنه و تحویل مشتری بده، هر یک از افراد در زمانی که به صورت حدودی برای انجام Task هایی که بهشون محول شده در نظر میگیرن، Documentation رو هم لحاظ کنن. اون هم تا حدی که به ادامه و تسریع روند کاری شون کمک کنه.

اگه کل تیم تصمیم به این کار بگیرن و Documentation رو جز جدانشدنی از کار روزانه خودشون قرار بدن، به مرور هر تیم و هر فرد، شیوه مناسب و میزان مناسب Documentation رو پیدا می کنه. هدف از انجام Task ها ایجاد Feature ها در سریع ترین زمان ممکن به مشتریان هست ما محصول ایجاد می کنیم و نه مستند محصول.


وجود Dedicated Team:

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

که اگر در شرایط شلوغ مانند این قرار گرفته باشید، ممکنه تموم نشدن کار ها و اضافه شدن هر روزه درخواست های Business شما رو در مقابل کوهی از کارهای انجام نشده و ناقص مونده قرار میده!

راهکار: همونطور که در بالا گفتم توانایی های Context Switching در هر یک از اعضای تیم به همراه Documentation میتونه برای هر یک از اعضای تیم سودمند باشه ضمن اینکه افراد به صورت روزانه مسئول انجام Task هایی که در بالاترین اولویت In Progress یا Select for Development قرار داره، هستن.

به این شکل که اگر تسک هایی که در Select for Development یا Backlog قرار دارن هزار تا باشن، باز افراد هر تیم در جدول کار های روزانه خودشون فقط به اولین Task ها و بهترین شیوه انجام شون فکر می کنن و رسیدگی به اولویت های هر Task موضوعی هست که Project Controller ها و Project Manager ها اون رو مدیریت و بررسی می کنند.


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

http://vrgl.ir/SKnG3

منتظر نظرات و تجربه های شما درباره استفاده از متد های Agile هستم.