مدیریت به روش اجایل (Agile) یک رویکرد در مدیریت پروژه است که از پاسخگویی دائم به تغییرات به جای پیروی از یک برنامه ریزی دقیق و از پیش تعیین شده حمایت می کند. مدیریت چابک (اجایل) یک روش شناسی نیست. بلکه مجموعه ای از اصول است (که به اسم بیانیه مدیریت چابک شناخته می-شود) و حاکی از آن است که ما باید با چه رویکردی به مدیریت پروژه بپردازیم.
اساسا دو روش کلی برای مدیریت پروژه های توسعه نرم افزار وجود دارد:
- آبشاری (waterfall): در این روش همه چیز از پیش برنامه ریزی شده است و تولید و ساخت در طی یک سال آینده طبق این برنامه ریزی از پیش تعیین شده انجام می گیرد.
- چابک(agile): در این روش شما چیزی را برنامه ریزی می کنید که طی چند هفته آینده قصد تولید یا ساخت آن را دارید و بعد از این چند هفته راجع به چگونگی ادامه روند کار تصمیم می گیرید.
اما چگونه متوجه شویم که ما واقعا از رویکرد اجایل در مدیریت پروژه های خود استفاده می کنیم؟ صرف اینکه شما از تخته های کنبن یا بوردهای اسکرام استفاده می کنید به خودی خود به معنای داشتن یک رویکرد چابک در مدیریت پروژه های شما نیست. برای اینکه به طور واقعی چابک باشید، باید به ارزش های رویکرد چابک که در بیانیه مدیریت چابک بیان شده است پایبند باشید و آنها را به کار ببندید.
بیانیه مدیریت اجایل (Agile)
در سال ۲۰۰۱، ۱۷ توسعه دهنده نرم افزار در ایالت یوتا گردهم آمدند تا در مورد روند و رویه های کاری خود که با مدیریت پروژه به شیوه ی آبشاری متفاوت بود بحث و گفت وگو کنند. آنها با همدیگر مفهوم توسعه چابک نرم افزار را در بیانیه مدیریت چابک تعریف کردند. امروزه وقتی می گوییم یک روش شناسی خاص اجایل به حساب می آید، به این معناست که از اصول و ارزش های بیاینه چابک پیروی می کند.
مهمترین بخش بیانیه مدیریت اجایل ۴ ارزش آن است. این ۴ ارزش به مانند قلب چیزی است که مدیریت چابک نامیده می شود.
ارزش های مدیریت چابک به شما کمک می کند روی چیزی که مهم است تمرکز کنید. برای مثال، یکی از ارزش ها ” نرم افزار در حال کار به جای مستندسازی جامع” است. اما این به این معنا نیست که مستندسازی فعالیت ها کار بدی است، بلکه به این معناست که اگر شما بین صرف کردن زمانتان برای نوشتن جزئیات یک مسئله و اشکال یا رفع آن اشکال نرم افزار باید یکی را انتخاب کنید، انتخاب شما باید رفع اشکال باشد.
افراد و تعاملات آنها به جای ابزار و فرآیندها
کارمندانی که با اطلاعات و دانش زیادی سر و کار دارند ترجیح می-دهند که در کار خود اختیار و آزادی عمل داشته باشند. بنابراین در توسعه نرم افزار بسیار اهمیت دارد که به جای مجبور کردن افراد تیم به پیروی از یک رویه خاص برای به جا آوردن یک سری خط و مشی های کهنه، به آنها اجازه دهیم تا مشکلات به وجود آمده را با همکاری و تعامل با یکدیگر حل کنند.
هر شرکتی نیازمند یک سری رویه و فرآیند خاص است (به ویژه بعد از این که تا اندازه معینی رشد می کنند). اما شما باید بدانید که چه زمانی یک قاعده خاص در جای خود به خوبی عمل می کند و چه زمانی باید آن را حذف کرد. برای مثال اگر جلسات ایستاده روزانه دیگر مفید نیستند فقط به این دلیل که بعضی روش های مدیریت چابک می گویند که باید این جلسات را داشته باشید اعضای تیم را مجبور به برگزاری آن نکنید
زمانی که افراد دیگر نوانند از طریق یک روند خاص به طور کارآمد با هم همکاری داشته باشند شما باید بدانید که آن روند دیگر مفید نیست و کار نمی کند. افراد تیم، موتور محرکه ی هر پروژه ای هستند. اگر آنها به دلیل وجود یک پروتکل پیچیده یا سلسله مراتب زیاد قادر به تعامل با یکدیگر نباشند ، مجبورند تا زمان بیشتری صرف مدیریت ابزار و فرآیندها بکنند تا انجام دادن کارشان.
پی نوشت: فرآیندهای کاری خوب در خدمت شما هستند و در نتیجه شما هم به مشتریان خدمات ارائه می دهید. اما اگر مراقب نباشید خود این فرآیندها تبدیل به مسئله می شوند برای شما. دراین وضعیت، رویه های کاری جای نتیجه و خروجی ها مد نظر شما را می گیرند و شما به جای اینکه به دنبال خروجی ها و نتایج مورد انتظارتان باشید، دائما در حال کسب اطمینان از این موضوع هستید که آیا رویه های کاری به درستی انجام می شوند یا خیر. بسیار شنیده شده است که رهبران تازه کار تیم ها برای توجیه نتیجه بد کسب شده تیمشان گفته اند که ” ما دقیقا از روند کاری تعیین شده پیروی کردیم.”. یک رهبر با تجربه تر از فرصت مناسب برای بررسی و بهبود رویه های کاری استفاده می کند. رویه های کاری اصل مطلب نیستند. همیشه این سوال را در ذهن خود داشته باشید که آیا رویه های کاری در خدمت ما هستند یا ما در خدمت رویه ها کاری؟” جف بزوس“. اگر انجام موفقیت آمیز یک پروژه در نظر شما به معنی به انجام رساندن تک تک وظایف در نظر گرفته شده برای یک شخص در آن پروژه باشد و شکست یک پروژه به معنای این باشد که پروژه اهداف مد نظر تجارت را بدون انجام همه ی رویه ها به دست آورده تعریفتان از مفهوم “پروژه کامل شده ” کاملا اشتباه است. (منبع: the phoenix project: a novel about IT, DevOps, and helping your buissiness win)
نرم افزار در حال کار به جای مستندات جامع
در مدیریت پروژه سنتی، مراحل پروژه به ترتیب اتفاق می افتد و اگر در مرحله اول عملکرد خوبی نداشته باشید (جمع آوری نیازمندی ها و مستندسازی) تک تک مراحل دیگر پروژه دچار مشکل می شوند. به همین دلیل است که مدیریت پروژه به سبک آبشاری نیازمند مستندسازی جامع است. اما در مدیریت پروژه اجایل ما انتظار وقوع تغییر در مسائل پیش رو را داریم.
آیا واقعا می خواهید که کل زمان خود را صرف به روزرسانی مستندات پروژه بکنید؟ چیزی که بیشترین اهمیت را دارد این است که یک محصول در حال کارداشته باشیم که کاربران واقعی بتوانند آن را آزمایش کنند. اگر شما مجبور به انتخاب بین نوشتن گزارش از اشکال موجود و درست کردن آن اشکال در محصول خود هستید درست کردن آن اشکال بهترین حالت استفاده از زمانتان است.
این به آن معنا نیست که شما باید مستندسازی را رهاکنید. این دامی است که توسعه دهندگان در آن می افتند و معمولا یک شرح مختصر و و کوتاه از فعالیت خود به صورت آنلاین می نویسند که این کار برای تضمین کیفیت و نگهدارندگان مشکل ایجاد می کند. چرا که آنها نم یتوانند متوجه شوند معیار پذیرش مناسب برای کاربر چیست. یک مستندسازی ایده آل فقط باید به اندازه کافی باشد. اگر بیش از حد باشد اتلاف زمان و منابع است و قابل اعتماد نیست چرا که با کدها هم خوانی ندارد. اگر خیلی کم باشد حفظ و نگهداری آن سخت بوده و نمیتوان اعضای جدید تیم را هماهنگ کرد.
هنگام نوشتن مستندات بایداز خودتان بپرسید که اگر شما فردا به این تیم بپیوندید میخواهید چه چیزی از وضعیت کارها و روند تیم بدانید.
همکاری با مشتری به جای مذاکرات حین قرارداد
قراردادها بستری را به وجود می آورند که تغییر در آنها به عنوان یک گزینه در نظر گرفته نمی شود. در مقابل آن مدیریت چابک بستری را فراهم می کند که تغییر در آن محتمل و قابل انتظار است. اما چگونه تغییرات را مدیریت می کنید؟ به وسیله همکاری و ارتباط با مشتری.
پیش فرض مدیریت اجایل (Agile) بر این است که شما محدودیتی برای دسترسی به مشتریان خود ندارید و همیشه میتوانید جلسه ای برای صحبت راجع به روند کار با آنها داشته باشید. توسعه دهندگان یک حلال مشکل ذاتی هستند اما نیاز دارند به مشتریان خود دسترسی داشته باشند تا بهتر متوجه بشوند که مشکل واقعی کجای کار است.
قراردادها سودمند هستند اما یک عارضه جانبی بد دارند: افراد معمولا تمایل دارند بیشتر به تحویل پروژه در زمان و بودجه مشخص اهمیت بدهند تا تحقق اهداف واقعی پروژه. علاوه بر این، وقتی تیم تحت تاثیر یک برنامه ریزی مشخص قرار می گیرد، افراد تیم معمولا کارها را طوری انجام می دهند که منجر به ناامیدی، هراس و کیفیت پایین می شود.
همچنین وقتی شما قراردادی را امضا می کنید، در مرحله اولیه شما در حال تخمین زدن هستید که بیشتر این حدس و تخمین ها اشتباه است. اما شما همچنان در حال تلاش برای رسیدن به یک مایلستون خاص هستید حتی اگر این مایلستون ها ربطی به نیازهای واقعی شما نداشته باشند.
این همان دلیلی است که مدیریت چابک از همکاری با مشتری و تحویل کار در مقیاس های کوچک و به شکل فزاینده و تدریجی حمایت می کند. این کار باعث می شود که شما اطلاعات بیشتری در حوزه کاری خود جمع آوری کنید و چیزهایی که نمی دانید را کشف کنید.
پاسخ به تغییر به جای پیروی از یک برنامه مشخص
هرچه زمان بیشتری صرف برنامه ریزی کنید مقاومت شما در برابر تغییرات به وجود آمده در برنامه بیشتر خواهد بود چرا که این تغییرات را عامل به هدر رفتن تلاش های خود می بینید. اما باید در نظر داشت هدف ما تحویل پروژه براساس برنامه زمان بندی شده و هزینه از پیش تعیین شده نیست. هدف واقعی دستیابی به بعضی از اهداف کسب و کار ماست و اگر این دستیابی مستلزم تغییر برنامه به طور کلی است باید این تغییر را انجام داد.
این بسیار مهم است که چیزی که واقعا به آن نیاز دارید را بسازید تا به طور کورکورانه از یک برنامه مشخص پیروی کنید. توسعه دهندگان ممکن است از این که کد آنها بی اعتبار می شود متنفر باشند اما اگر مشتریان محصولی که به آن احتیاج دارند را دریافت نکنند نارضایتی آنها خیلی بیشتر از این تنفر است.
به همین دلیل است که مدیریت چابک از بازه های زمانی کوچک حمایت میکند و تیم ها را تشویق می کند تا کارها را به بخش های قابل تحویل کوچک تبدیل کنند تا مجبور به انجام دوباره حجم زیادی از کارها نباشند. این به این معنی است که جمع-آوری نیازمندی ها و مرحله طراحی هیچ وقت تمام نمی شود و شما به طور مداوم طی چرخه های مختلف آنها رو مورد بازبینی قرار می دهید.
عناصر مدیریت پروژه چابک (اجایل)
فرهنگی که تغییر در آن انتظار میرود
مدیریت چابک به معنای استفاده از تخته کنبن، داشتن جلسات ایستاده روزانه یا چیزهای از این دست نیست (اینها عناصر یک روش خاص از مدیریت چابک است). مدیریت اجایل در هسته ی خود یک ذهنیت است که همه ی افراد از کارکنان گرفته تا مشتریان انتظار تغییر را دارند. شما نمیتوانید در ابتدا به مشتریان خود قول۱۰۰% همه چیز و یک تاریخ سررسید مشخص بدهید چرا که هر دوی شما می دانید که غیرواقعی است. اما می توانید به به آنها قول بدهید که در نهایت محصولی را خواهند داشت استفاده می کنند.
توسعه فزاینده
هر چرخه تکرار بر مبنای کارهای از قبل انجام شده شکل گرفته و به طور تدریجی محصول را بهبود می بخشد. همچنین شما منتظر انجام حجم انبوهی از کارها و انتشار آنها به یکباره نمی مانید. به محض اینکه بخشی از کار تمام می شود شما آن را منتشر می کنید. یک چرخه تکرار ممکن است امکانات و ویژگی های لازم برای تضمین یک کمپین تبلیغاتی را به محصول اضافه نکند اما این امر اهمیتی ندارد چرا که هدف نهایی ما تحویل ارزش به مشتری است.
انتشارهای مکرر
چون نرم افزار به تدریج و به طور فزاینده توسعه پیدا می کند شما می توانید چرخه های کوتاه تری داشته و در انتهای هرچرخه ویژگی یا آپدیت های جدیدی را منتشر کنید. با این روش مشتریان هر چه سریعتر به ارزش محصول دست پیدا می کنند و می توانند آن را تایید کنند.
حلقه های بازخورد کوتاه
چون انتشار به دفعات مکرر اتفاق می افتد شما سریعتر میتوانید به بازخورد دست پیدا کنید. و چون شما سریعتر به بازخورد دست پیدا میکنید با سرعت بیشتری میتوانید تغییرات لازم را رو محصول اعمال کرده و به ارزش دست یابید.
میزان درگیری و تعامل زیاد با مشتری
برا اینکه بیشترین بهره را از حلقه های بازخوزد کوتاه و انتشارات مکرر ببریم، شما نیازمند میزان درگیری و تعامل زیاد با مشتری خود هستید. نیاز دارید تا با مشتریان خود بعد از هر چرخه صحبت کنید و ببینید چگونه از نرمافزار استفاده کرده و آیا ارزشی از این نرم افزار کسب می کنند.
گاهی مشتری برای ارائه بازخورد به شما در دسترس نیست. بعضی از روش های مدیریت اجایل (Agile) مانند اسکرام این مشکل را با در نظر گرفتن یک نقش در تیم به نام مالک محصول حل کرده است. این شخص به مانند نماینده مشتری عمل می کند و به نیابت از او رفتار میکند. اگر تیم توسعه دهنده سوالی داشته باشد از او می پرسد. مالک محصول پیشرفت تیم را بررسی کرده و در انتهای چرخه های تکرار الویت های مشتری را دوباره ارزیابی می کند.
