ضرورت استفاده از Best Practice های اجایل

ضرورت استفاده از Best Practice های اجایل

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

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

۱- Best Practice های مطرح شده در اجایل

بعضی از متدلوژی‌ها معمولاً مجموعه‌ای از best practiceها را در روند خود دارند و حتی به عنوان یک اصل اساسی یا یک مفهوم در آنها تعریف شده اند. برای مثال تهیه مستند DOD در اسکرام یا Pair Programing در XP نمونه‌ای از best practiceهایی هستند که استفاده از آنها صریحا در روند این متدها در نظر گرفته شده است. از آنجایی که متدلوژی‌های scrum و xp بیشتر از بقیه متدولوژی‌ها در سازمانها استفاده می‌شود، در ادامه به best practiceهای مطرح در آنها می‌پردازیم.

۱-۱ best practice های متدلوژی اسکرام

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

  • Iterative Development: توسعه پروژه بهتر است به صورت iterative پیش برود تا اشتباهات در روند پروژه سریع شناسایی شود و ریسک پذیرفته نشدن کارها به حداقل برسد. در این صورت می‌توانیم به طور دوره‌ای از مشتری فیدبک بگیریم. هزینه تغییرات در این شرایط کمتر است. اغلب پروژه‌های اجایل به صورت Iterative توسعه پیدا می‌کنند و در آخر هر Iterative سعی در ارائه یک Increment کاربردی جهت گرفتن فیدبک از مشتری دارند. فقط لازم است که مدت مناسب Iteration را بسته به پروژه مشخص کنیم. بعد از اینکه مدت مناسب برای طول یک اسپرینت را بدست آوردیم نباید آن را تغییر دهیم باید سعی کنیم اولویت‌ها را طوری در نظر بگیریم که در دوره مورد نظر به خروجی مطلوب برسیم یا scope ویژگی‌ها و کارها را هوشمندانه تعریف کنیم. در اکثر سازمانها به اشتباه طول دوره خود را با ویژگی‌هایی که تعریف می‌شود متغیر در نظر می‌گیرند که این روند پروژه را مختل خواهد کرد.
  • Time Box: محدود کردن زمان رویدادها یک روش مناسب برای متمرکز کردن روند و افراد بر روی هدف آن رویداد است. به این دلیل است که تمام جلسات اسکرام بسته به طول اسپرینت مدت زمان مشخصی دارد. اگر زمان جلسات از آن محدوده مشخص بیشتر طول بکشد باید بدانیم که حاشیه جلسه زیاد شده و جلسه خوب مدیریت نشده است و سعی کنیم در جلسات صحبت‌ها هدفمندتر و در راستای هدف تعیین شده باشد تا بهرو‌وری بالا رود. در سازمان معمولا اهمیتی به این زمان داده نمی‌شود و باعث می‌شود که در انتها جلسه به نتیجه مطلوبی نرسد در اینصورت فقط اتلاف زمان خواهیم داشت.
  • Burndown Chart: استفاده از نمودار Burndown Chart برای اسپرینت و پروژه بسیار مفید است. با استفاده از این نمودار، میزان پایداری سرعت روند پروژه در طول اسپرینت مشخص می‌شود. ظرفیت کاری تیم بدست می‌آید و در زمانهایی که سرعت انجام کارها از میزان انتظار مورد نظر پایین‌تر باشد بررسی می‌شود تا ضعف‌ها و ریسک‌های پروژه شناسایی شود. در حالیکه در اکثر سازمانها فقط به اتمام کارهای تعریف شده توجه می‌شود و سرعت روند پروژه در طول اسپرینت در نظر گرفته نمی‌شود در حالی که می‌توان یکسری مشکلات اساسی را با تحلیل این نمودار در روزهای یک اسپرینت شناسایی کرد.
  • Definition of Done: آماده کردن مستند DOD، که مجموعه ای از استانداردها و معیارهایی است که باید به آن پایبند باشیم، یکی دیگر از مواردی است که اکثر نادیده گرفته می‌شود. هر user story و task در صورتی تمام شده در نظر گرفته می‌شود که این معیارها را برآورده کند. استفاده از DOD باعث می‌شود که ریسک تست نشدن درست کارها و توجه نکردن به مسائل مهمی که در بعضی از مواقع فراموش می‌شود، کاهش یابد و تعداد کارهای برگشتی که مورد پذیرش قرار نمی‌گیرند کاهش یابد.
  • Definition of Ready: این مستند در راستای تعریف واضح نیازمندی‌ها و مشخص شدن تمام جزئیات آنها تهیه می‌شود. این مستند کمک می‌کند که زمان مذاکرات در جلسه کمتر شود و ابهامات توسعه دهندگان در مورد کار تعریف شده برطرف شود و تا حد ممکن کار به صورت درست پیش رود و به نوعی دوباره کاری‌ها را کاهش می‌دهد.
  • Estimation: استفاده از روشهای مناسب جهت تخمین کارها باعث می‌شود که ظرفیت کاری تیم مشخص شود از طرفی اگر تخمین داده شده اختلاف زیادی با زمان واقعی انجام کار داشته باشد بررسی می‌شود و مشکلات و نواقص تحلیل شناسایی می‌شود در اینصورت به مرور زمان افراد یاد می‌گیرند که قبل از انجام کار تحلیل درستی انجام دهند و تا حد ممکن کارها را بشکنند تا قابل تخمین باشد. از طرفی باعث می‌شود که بتوانیم یک برنامه ریزی release مناسب انجام دهیم. علاوه بر روش تخمین ساعتی، روشهای دیگری مانند Planning Poker، Relative Estimation، Point Estimation وجو دارد که بسته به سیاست‌های پروژه و روحیه افراد می‌توان از روش مناسب آن شرایط استفاده کرد. این مورد معمولا خیلی جدی گرفته نمی‌شود و از روی عادت و به علت اجبار چارچوب، بدون بحث و تحلیل یک زمان الکی به کارها داده می‌شود و حتی در انتها درصد ریسک تخمین اشتباه هم در نظر گرفته نمی‌شود.
  • Backlog: مفهوم بک لاگ یک مفهوم بسیار مناسب در جهت مدیریت نیازمندی‌ها می‌باشد. استفاده از بک لاگ باعث جلوگیری از فراموشی نیازمندی‌های آینده می‌شود. کارها در آن قابل مقایسه هستند و اولویت بندی کارها و تغییر چندباره آنها را راحت می‌کند. به روز نگه داشتن بک لاگ توسط مالک محصول انجام می‌شود و نباید در انجام آن کوتاهی کند. امروزه ابزارهای مختلفی برای تهیه و مدیریت بک لاگ وجود دارد که کارها را ساده تر کرده است.
  • Backlog Grooming: این جلسه یکی از جلساتی است که در اکثر سازمانها نادیده گرفته می‌شود. این جلسه باید در مواقع نیاز با حضور مالک محصول و توسعه دهندگان تشکیل شود. در این جلسه کارهای بالای بک لاگ امکان سنجی می‌شود، ابهامات کارها مشخص می‌شود و ممکن است بسته به نتیجه جلسه اولویت‌ها تغییر کند. این جلسه خیلی از ریسک‌های برنامه ریزی را کاهش می‌دهد و جلسه مهمی است. خروجی این جلسه به مالک محصول کمک می‌کند که تحلیل‌های درستی انجام دهد و اولویت بندی مناسبی را در نظر بگیرد و ریسک کارها را شناسایی کند.

بعضی از کارها که برای برگزاری نحوه جلسات اسکرام توصیه شده است هم به نوعی best practice هستند برای مثال time box بودن تمام جلسات یا ۳ سوال مخصوصی که در جلسات روزانه باید به آن پرداخته شود همه در راستای حفظ تمرکز بر روی موضوع جلسات و افزایش بهره‌وری جلسات می‌باشد. استفاده از بورد کانبان هم در جهت مدیریت کارها یک Best Practice است.

۱-۲ best practice های متدلوژی XP

متدلوژی xp هم همانند سایر متدهای اجایل Iterative است، این متدلوژی دارای ruleها و principleهای زیادی می‌باشد و بسته به اسکرام انعطاف پذیری کمتری دارد. در این متد به practiceهای زیادی به صورت واضح در متدلوژی پرداخته شده است. اما شرکت ها بسته به تصمیم خود و برداشت اشتباه بعضی از این  best practiceها را نادیده می‌گیرند که در زیر به آنها می‌پردازیم.

  • Sustainable Pace: این موضوع یکی از مواردی است که نادیده گرفته می‌شود. داشتن یک سرعت پایدار در روند توسعه پروژه مهم است، نباید این طور باشد که در بعضی از مواقع توسعه دهندگان تحت فشار باشند و در بعضی از مواقع بار کاری کمتری داشته باشند به مرور زمان این امر باعث پایین آوردن بهره‌وری و انگیزه کاری می‌شود. برای مثال باید مدیریت شود که در هفته ۴۰ ساعت کار انجام شود یا در روز ۸ ساعت کار انجام شود، ظرفیت انسان محدود است و کار بیش از آن ظرفیت در بعضی از شرایط باعث بالا بردن ریسک باگ‌ها در پروژه می‌شود که بعداً ممکن است با مشکلات زیادی مواجه شویم. تجربه هم ثابت کرده که کار تحت فشار واسترس و بدون برنامه نتیجه مطلوبی ندارد. اما شرکت‌ها فکر می‌کنند با کار زیاد بهره‌وری هم بالا می‌رود در حالیکه اینچنین نیست.
  • Pair Programming: در این روش دو نفر باهم بر روی یک بخش کار می‌کند، کسی که کیبورد را در دست دارد Driver و کسی که نظارت و هم فکری می‌کند navigator نامیده می‌شود البته توصیه می‌شود که چند وقت یکبار جای همدیگر را عوض کنند. اکثر شرکتها و مدیران مخالف این روش هستند و فکر می‌کنند اگر رو نفر به طور موازی روی بخش‌های مختلف کار کنند، بهره‌وری بالا می‌رود در حالیکه در شرایطی استفاده از این روش ضرورت دارد. همیشه دو فکر بهتر از یک فکر است و اشتباهات کد نویسی کاهش می‌یابد، روش مناسبی برای به اشتراک گذاری دانش است و باعث بهبود مهارت‌های ارتباطی و کار تیمی افراد می‌شود. نباید این تصور را داشته باشیم که وقتی ۲ نفر همزمان بر روی یک بخش کار می‌کنند بهره‌وری ۵۰ درصد کاهش می‌یابد اتفاقا در بسیاری از شرایط راه حل مشکلات سریع‌تر یافت می‌شود و نرخ اشتباهات کمتر می‌شود. ارزشی که در بعضی شرایط از استفاده این روش کسب می‌شود به زمان از دست رفته می‌ارزد. البته باید گفته شود که اجبار استفاده از این روش خوب نیست باید فرهنگ این ایجاد شود که توسعه دهندگان در موارد نیاز از این روش استقبال کنند.
  • Refactoring: هر تغییری در راستای بهبود ساختار داخلی کد با حفظ رفتار آن بخش، Refactor می‌باشد. انجام Refactor خوانایی کد را بالا می‌برد و پیچیدگی کد را کاهش می‌دهد که باعث می‌شود کد قابل نگهداری شود. باعث بهبود طراحی کد و استفاده درست از design patternهادر هر مرحله از توسعه می‌شود و سازگاری را افزایش می‌دهد.
  • TDD: روش و یک استایل مؤثر از برنامه نویسی است که در آن ابتدا تست به صورت unit test برای کار مورد نظر نوشته می‌شود و بعد کد نویسی در راستای pass کردن آن تست انجام می‌شود و در نهایت یک refactoring برای آن بخش داریم. اکثر شرکت‌ها با تصور اینکه این کار زمان توسعه را طولانی می‌کند از این روش صرف نظر می‌کنند در حالی که در طولانی مدت مدت زمان توسعه را کاهش می‌دهد چون کد توسعه یافته کیفیت بالایی دارد و باگ‌هایی کمتری دارد و قابل اتکا است و در آینده وقت کمتری صرف debug خواهد شد.
  • User Stories: نوشتن user story با فرمت استاندارد باعث می‌شود که نیازمندی و هدف از آن نیازمندی به طور واضح مشخص شود، از طرفی باعث کنترل تعاملات نیز می‌شود. اما اکثر افراد از نوشتن فراری‌اند و آن را باعث اتلاف زمان می‌دانند و بیشتر در حد تایتل نیازمندی را نوشته و بقیه موارد را شفاهی مطرح می‌کنند که این باعث فراموشی بعضی از موارد مهم می‌شود و بعدا رفت و برگشت کار و تعاملات، زمان زیادی خواهد گرفت. البته منظور این نیست که ارتباط شفاهی وجود نداشته باشد بلکه باید هر دو مورد در حد مناسبی وجود داشته باشد، باید به این نکته هم توجه داشته باشیم که نحوه نوشتن user story هم اهمیت ویژه‌ای دارد.
  • Continuous Integration: یکپارچه‌سازی مداوم  کارها و کدهای توسعه دهندگان، یکی از روشهایی است که ضرورت آن در سازمان‌ها حس می‌شود چون باعث حفظ انسجام کد می‌شود و از به هم ریختگی کد جلوگیری می‌کند. برای این کار باید بتوان از ابزارها و روالهای اتوماتیک استفاده کرد تا قادر باشیم در مواقع نیاز، سریع نسخه دهیم. هر زمان که یک تغییری توسط توسعه دهنده انجام می‌شود و کد commit می‌شود باید تستهای اتوماتیک اجرا شوند تا اطمینان حاصل شود که با کدهای قبلی سازگار است و درست کار می‌کند. در اکثر پروژه‌ها این مورد نادیده گرفته می‌شود و روال مشخصی برای آن وجود ندارد و باعث می‌شود که در موقع integration با مشکلات زیادی مواجه شوند که رفع این مشکلات زمان بر خواهد بود.
  • Frequent Release: یکی از کارهای مفیدی که در روند توسعه وجود دارد ارائه ریلیزهای مداوم در بازه‌های کوتاه زمانی است. باید سعی کنیم نیازمندی‌ها را طوری اولویت بندی کنیم و طوری بشکنیم که بتوانیم در بازه‌های کوتاه مدت ریلیز بدهیم. دادن ریلیز باعث می‌شود که هزینه ریسک‌ها و تغییرات کمتر شود. به این طریق می‌توان فیدبک‌های مناسب را در بازه‌های کوتاه از مشتری دریافت کرد و در صورت نیاز به تغییر بتوان با هزینه کمتر آن تغییرات را اعمال کرد. در اینصورت چون مشتری در روند پروژه درگیر است در انتهای پروژه رضایت کافی دارد.

best practiceها را بسته به کاربردی که دارند می‌توان دسته بندی کرد، برای مثال best practiceهای حوزه تست، حوزه مدیریت پروژه، حوزه طراحی و مواردی از این قبیل. از آنجایی که تست پروژه از اهمیت زیادی برخورداری است در ادامه به Best practiceهای مطرح در این حوزه می‌پردازیم.

۱-۳ Best Practice های حوزه تست

در شرایطی که پروژه بزرگ می‌شود ضرورت استفاده از تست بیشتر محسوس می‌شود. ضعف تست در نرم‌افزار باعث می‌شود که پشتیبانی و نگهداری پروژه با مشکل مواجه شود و رفع خطاها هم سخت باشد. بنابراین بهتر است از همان ابتدای شروع پروژه به تست تمرکز ویژه‌ای داشته باشیم و زمان و هزینه آن را در  پروژه در نظر بگیریم. انواع مختلفی تست وجود دارد که بسته به ماهیت و بزرگی پروژه مشخص می‌شود که کدام تست‌ها باید پیاده سازی شوند. برای مثال تست functional، تست nonfunctional و تست maintenance سه دسته بندی از تست است که هر کدام روشهای مختلفی از تست را در بر می‌گیرد. بعضی از best practiceهای اجایل در حوزه تست در زیر لیست شده است.

  • Role-Feature-Reason
  • Given-When-Then
  • Test-Driven-Development
  • Behavior-Driven-Development
  • Acceptance-Test-Driven-Development
  • Usability Testing
  • Exploratory Testing
  • Acceptance Tests
  • Unit Tests

Role-Feature-Reason و Given-When-Then چارچوب‌هایی هستند که برای نحوه نوشتن user story و acceptance criteria استفاده می‌شوند تا بتوان به طور مناسب از آنها در راستای توسعه و نوشتن تست نیازمندی‌ها استفاده کرد. BDD ،TDD و ATDD روشهای مختلف توسعه پروژه هستند که به عنوان best practice در حوزه تست متدهای اجایل در نظر گرفته شده است. Acceptance tests, Exploratory testing, Usability testing و Unit test هم بعضی از best practiceهایی هستند که در حوزه نوشتن انواع تست در روند توسعه پروژه‌ها مناسب می‌باشد.

۲- جمع بندی

درنهایت باید گفته شود که استفاده درست و مناسب از best practiceها بسته به شرایط و موقعیت پروژه کاملا مفید است و نباید در مقابل استفاده از آنها مقاومت کرد. تغییر همیشه سخت و کند است اما در نهایت باعث می‌شود که محصول تولیدی در روند درستی حرکت کند و درصد موفقیت پروژه را افزایش می‌دهند. همانطور که قبلا هم گفتم هرکاری که باعث بهبود روند انجام کار شود و ریسک اشتباهات را کاهش داده و درصد موفقیت پروژه را افزایش دهد می‌توان به عنوان best practice در نظر گرفته شود. برای مثال ایجاد یک محیط کاری مبتنی بر ارتباط و تعامل، استفاده از استانداردهای کد نویسی و مسایلی از این قبیل هم best practice هستند. در حالت کلی استفاده از best practiceها مزیت‌های زیر را در پی دارد:

  • هزینه را کاهش می‌دهد و کارایی را بالا می‌برد.
  • اتلاف زمان را کاهش داده و کیفیت را بالا می‌برد.
  • اعتماد به نرم‌افزار را افزایش می‌دهد.
  • ریسک شکست پروژه را کاهش ‌می‌دهد.
  • روند توسعه را بهبود می‌بخشد.
  • درصد موفقیت پروژه را افزایش می‌دهد.
  • درصد رخداد خطاها را کاهش می‌دهد.
  • در طولانی مدت سرعت توسعه پروژه را افزایش می‌دهد.

باید به این نکته هم توجه داشته باشیم که استفاده نادرست و نابجا از best practiceها مشکل ساز خواهد شد، نباید بدون شناخت و درک شرایط استفاده از best practiceها به هر قیمتی از آنها استفاده شود.

[سمیرا نقی‌لو]

پاسخ دهید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *