چارچوب XP در مدیریت چابک

مقدمه

این متد در سال ۱۹۹9 توسط بک ابداع شد. گرچه منابع اولیه درباره این روش تقریباً از آغاز، در اینترنت وجود داشت، با این حال سه سال طول کشید تا کتاب آن به بازار عرضه شود و نسخه اصلاح شده آن در سال 2004 منتشر شد. با این که بیشتر متدهایی که امروزه لقب چابک گرفته‌اند قدیمی‌تر از XP هستند، اما ظهور متد XP جرقه حرکت چابک را زد.

قبل از ادامه ی این مقاله، مقاله ی “صفر تا صد بیانیه و اصول چابک” را حتما مطالعه کنید.

XP بیشتر به مثابه دیسیپلین مهندسی نرم‌افزار در نظر گرفته می‌شود تا یک متد، با این حال یک چرخه دارد، چرخه XP شامل شش مرحله است.

فعالیت‌هایی که در مراحل دوم و سوم و چهارم انجام می‌شوند، موتور توسعه متد XP را تشکیل می‌دهند؛ زیرا هر کدام از این مراحل به یک عرضه جدید منتهی می‌شود. بر طبق فرایند XP اولین عرضه سیستم مرحله تولید و توسعه مقدماتی است. سپس محصول اولیه در مرحله نگهداری از طریق تکرارهای بیشتر به صورت افزایشی بهبود می‌یابد.

فرآیندهای چرخه XP

بخش‌های زیر توصیف مختصر فعالیت‌هایی است که در هر مرحله چرخه XP صورت می‌گیرند:

• کاوش

فعالیت‌های اصلی که در این مرحله از فرایند XP انجام می‌شوند، به شرح زیر است:

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

• برنامه ریزی

فعالیت‌های اصلی در این مرحله نسبتاً کوتاه انجام می‌شود (معمولاً بیشتر از دو روز طول نمی‌کشد) و معمولاً برنامه‌ریزی عرضه نامیده می‌شود. این فعالیت‌ها عبارتند از:

1. برآورد زمان توسعه (ایجاد): توسعه‌دهندگان زمان مورد نیاز برای ایجاد هر گزارش کاربر را به محض مطابقت دادن آن با یک شبه سیستم برآورد میکنند و آن را روی گزارش کاربر یادداشت می‌کنند. گزارش کاربری که معمولاً بیش از سه هفته زمان نیاز دارد، به بخش‌های کوچکتری تقسیم می‌شود و گزارش‌های کاربری که کمتر از یک هفته زمان می‌برند، با هم ترکیب می‌شوند. در این شرایط که برآوردها به اندازه کافی قابل اطمینان نیستند، نمونه‌ها (اسپایک‌ها) ایجاد می‌شوند تا به توسعه دهندگان برای کاهش ریسک‌های زمانبندی و بهبود برآوردها کمک کنند.
2. اولویت‌بندی گزارش‌های کاربر: مشتری بر طبق ارزش‌های تجاری، این گزارش‌ها را اولویت‌بندی می‌کند.
3. برنامه ریزی اولین عرضه: تیم، مجموعه‌ای کوچک و دارای بیشترین ارزش از گزارش‌های کاربر را برای اولین عرضه انتخاب می‌کند و برای اولین زمان عرضه توافق می‌کند. به این ترتیب، تیم روی زمان تکرار (بین 1 تا 3 هفته) تصمیم می‌گیرد. هر کدام که تعیین شد برای همه تکرارها اِعمال خواهد شد. برنامه‌ی عرضه به دست آمده، چارچوبی خواهد بود که بر طبق آن تلاش‌های توسعه‌ای تکراری در مرحله‌ی بعدی پیش خواهد رفت.

• تکرارها برای اولین عرضه

این مرحله، هسته توسعه تکراری چرخه XP است و هدف نهایی آن تولید اولین عرضه سیستم اجرایی بر طبق برنامه عرضه است. در نتیجه فعالیت‌های توسعه‌ای ممکن است گزارش‌های جدیدی ارائه شوند و گزارش‌های موجود تغییرکنند. فعالیت‌های زیر در هر یک از تکرارها انجام می‌شوند:

1. برنامه ریزی تکرار: در آغاز هر تکرار، یک جلسه برنامه‌ریزی برگزار می‌شود که در حین آن تیم توسعه کارهای زیر را انجام می‌دهد:

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

1. توسعه (ایجاد): فعالیت توسعه در هر تکرار خود، یک فرآیند تکراری در چرخه روزانه است. فعالیت‌های اصلی که دراین مرحله انجام می‌شوند به شرح زیر هستند:

• برگزاری جلسات روزانه: یک جلسه آغاز به کار هر روز صبح به منظور اعلام مشکلات و راه حل‌ها برگزار می‌شود و به تیم کمک می‌کند تا در مسیر درست باقی بماند.
• تحلیل، طراحی، کدنویسی، آزمودن و یکپارچگی کدهای دارای مالکیت مشترک: به معنی آن است که کلیه کدهایی که نوشته شده‌اند در یک مکان مشترک قرار داده می‌شوند و هر توسعه‌دهنده می‌تواند کد نوشته شده توسط خود با دیگران را برای افزودن قابلیت رفع نواقص یا ساده کردن آن تغییر دهد. برای اینکه بتوان این کار را عملی کرد از توسعه آزمون-محور استفاده می‌شود. توسعه‌دهندگان باید هنگامی که کدی را ایجاد می‌کنند آزمون واحدی را برای کد خود بنویسند . همه‌ی کدهای درون این مخزن آزمون واحد دارند . این آزمون‌های واحد مجموعه‌ای از آزمون‌هایی است که هر زمان کدی نوشته یا اضافه می‌شود، به صورت خودکار توسط ابزارهای آزمون به کار می‌روند. کد نویسی‌ها مکرراً در XP انجام می‌شوند و به یکپارچگی پیوسته ترغیب می‌شوند. با این حال، برای اینکه بتوانند با باقی کدها یکپارچه شوند باید از تمامی مجموعه آزمون‌ها عبور کنند. بنابراین، این مجموعه آزمون‌ها مخزن را از تغییرات زیان‌آور حفظ می‌کنند.

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

• آماده سازی برای تولید

فعالیت‌های اصلی که در این مرحله صورت می‌گیرند عبارتند از:

1. تایید گستردگی سیستم: عرضه‌ها برای اطمینان از تایید کاربر و آماده بودن سیستم برای انتقال بررسی می‌شوند. آزمون‌های پذیرش که پیش تر حین مرحله تکرارهای اولین عرضه ایجاد شده‌اند در اینجا برای آزمون‌های بازگشتی استفاده می‌شوند و نواقص پیدا شده از طریق تکرارهای چرخه توسعه اصلی رفع می‌شوند.
2. انتقال به محیط محصول: عرضه به محیط کاربر عرضه می‌شود. این کار طبیعتاً شامل یکپارچگی تبدیل، تنظیم آموزش و مستند کردن فعالیت‌های عمومی کارهای انتقال است. هر اقدام برای تثبیت و تنظیم روی عرضه، خود فعالیت توسعه‌ای در نظر گرفته می‌شود. در مقایسه با توسعه گزارش مشتری و از طریق تکرارهای کوتاه (معمولاً هفتگی)، چرخه توسعه هدایت می‌شود.

• نگهداری

این مرحله شامل فعالیت‌هایی مشابه سه مرحله قبلی (موتور توسعه) است: برنامه‌ریزی، تکرارها برای اولین عرضه (اولین حذف می‌شود) و آماده‌سازی برای تولید. همچنین به مجموعه گزارش‌های کاربر و شبه سیستم و فعالیت‌های مراحل تشکیل‌دهنده مطابق ترتیبی که قبلا گفته شد، بستگی دارد. اختلاف مهم این است که عرضه‌های کوچکی که حین این فاز ایجاد می‌شوند با سیستم عملیاتی و در حال کار موجود یکپارچه می‌شوند. مرحله نگهداری زمانی است که گزارش‌های باقی مانده کاربر در سیستم اجرا می‌شود و سیستم به این ترتیب نگهداری می‌شود. طبق روال فرآیندهای تکراری-افزایشی، با خواسته‌هایی که در مرحله نگهداری بروز می‌کنند مانند خواسته‌های معمولی رفتار می‌شود و در طول همان فرایند توسعه تکراری اجرا می‌شود. به این ترتیب نگهداری فرایند یکدستی را برای انتقال و نگهداری سیستم، فراتر از عمر عملیاتی آن به کار می‌گیرد.

مرحله نگهداری تا زمانی ادامه می‌یابد که هم گزارش‌های دیگری از مشتری موجود نباشد و چیزی برای آینده پیش‌بینی نشود (پایان خوشایند اما غیر ممکن برای پروژه) و هم سیستم نیاز به تکامل ضروری دیگری نداشته باشد.

• مرگ

زمانی که تکامل تدریجی، هم غیر ضروری و هم غیر ممکن شود، پروژه مرده تلقی می‌شود. فعالیت‌های اصلی در این مرحله پایانی XP عبارتند از:

اعلام خاتمه پروژه: شامل خاتمه یافتن معمولی، منطقی و مالی موارد باقی مانده است.

بازنگری و ثبت پس از مرگ: این مرحله اساساً شامل 1-تهیه یک سند کوتاه حداکثر 10صفحه‌ای است که کلیت سیستم را معرفی می‌کند. 2-نوشتن گزارش و بازنگری 3-ثبت درس‌های آموخته‌شده از پروژه به اختصار.

نقش‌ها و مسئولیت‌ها

نقش‌هایی که توسط بک برای متد XP معرفی شده‌اند عبارتند از:

برنامه‌نویس، مشتری، آزمایش‌کننده، پیگیری‌کننده (کسی که وضعیت پروژه را بررسی کرده و بازخورد می‌دهد)، رهبر عملیات(هماهنگ‌کننده)، مشاور و مدیر(رئیس بزرگ-تصمیم‌‌گیرنده).

همچنین بخوانید: چارچوب ASD در مدیریت چابک

دوازده روش کار XP

برای به کارگیری این متد سازمان‌ها باید بتوانند این دوازده روش کار را در سازمان خود پیاده کنند.

1. بازی برنامه‌ریزی

همان برنامه‌ریزی است که به عنوان بازی برنامه‌ریزی شناخته می‌شود. این برنامه‌ریزی هم تکراری است و هم مشارکتی. تکراری است چون در آغاز هر توسعه افزایشی می‌شود. مشارکتی است چون توسط اعضای تیم مشتری و مدیریت انجام می‌شود.

2. عرضه‌های کوچک

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

3. تصور

تصور پروژه، ایده اصلی سیستمی است که تیم آن را می‌سازد. این تصور از تشبیه‌ها برای توصیف نتیجه سیستم استفاده می‌کند به شکلی که هم برای تیم توسعه و هم برای مشتری به راحتی قابل درک باشد. این تصور دیدی بسیار کلی از خواسته‌های کلی پروژه XP است و این انتظار وجود دارد که این تصور در سرتاسر پروژه نسبتاً ثابت باقی بماند.

توصیف‌های واقعی ویژگی‌های سیستم به صورت مجزا در گزارش‌ها ثبت می‌شوند.

4. طراحی ساده

این روش کار اساس ارزش سادگی در XP است. این روش کار توصیه می‌کند که برنامه‌نویسان از طراحی ویژگی‌های اضافی که در آینده ممکن است خواسته شوند، اجتناب کنند.XP بر این باور شکل گرفته که روش کار طراحی ساده، در مقایسه با طراحی برای آینده، منجر به دوباره‌کاری کمتر می‌شود.

5. اول آزمون

یکی از فلسفه‌های شکل‌گیری XP، روش کار آن است. این فلسفه بیان می‌کند که قبل از اینکه دو برنامه‌نویس یک خط برنامه بنویسند حتماً باید آزمون‌های خودکاری را تهیه کنند که این کار برای تایید گزارش کاربردی که قصد ایجاد آن را دارند ضرورت دارد.

6. دوباره سازی

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

7. برنامه‌نویسی دو نفره

ملموس‌ترین روش کار XP برنامه‌نویسی دو نفره است. این روش کار لازمه تمام کارهای فنی است (از طراحی گرفته تا برنامه نویسی تا آزمون) که باید توسط یک جفت برنامه نویس و باهم صورت گیرد. این جفت در سرتاسر پروژه بر مبنای نیازهای گزارش‌ها تغییر می‌کند.

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

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

8. مالکیت مشترک

متد XP نقشی را برای مالکیت کدهایی که نوشته می‌شود در نظر می‌گیرد که با استاندارد مسئولیت واگذاری کدها به هر فرد نسبتاً متفاوت است. XP در سمت دیگر طیف قرار دارد: یعنی کدهای نوشته شده نباید در مالکیت فرد خاصی باشند و همه باید بتوانند به آنها دسترسی داشته باشند. زمانی که فردی لازم ببیند کدی تغییر کند، مسئولیت جفت اوست تا آن تغییر را اعمال کند. هر یک از اعضای تیم مالکیت همه کدهای گردآوری شده را دارند.

9. یکپارچگی مستمر

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

10. چهل ساعت کار در هفته

XP به ندرت به دنبال اضافه‌کاری است. در این متد به صراحت فرض می‌شود که اضافه‌کاری نباید بیش از دو هفته پشت سر هم باشد. هدف از این روش کار این است که افراد سر حال باشند تا بتوانند با آهنگی مستمر اما ملموس به کار خود ادامه دهند.

11. مشتری (کارفرما) در محل

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

12. استانداردهای کدنویسی

روش‌های کار متعدد XP (به خصوص برنامه‌نویسی دونفره و مالکیت مشترک)، اهمیت استانداردی را برای کدنویسی نشان می‌دهد. در تیمی که همکاری نزدیکی با سایرین دارد، استانداردهای مناسب تنها راه برای حفظ نظم و یکپارچگی است.

جمع بندی

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

حتما نظرتون رو برامون بنویسید