شاید شما هم مثل من فکر می‌کنید، به اندازه‌ای که درحرفه یا زندگی شخصی خود زحمت می‌کشید، نتیجه نمی‌گیرید! چندی پیش کتابی خواندم از آقای J.D Meier  (مهندس نرم افزار و مدیر پروژه در شرکت مایکروسافت) که نحوه‌ی برنامه ریزی و زمان بندی من در کار و زندگی ام را به طور شگفت آوری متحول کرد. به همین دلیل به این فکر افتادم که در قالب چند مقاله به معرفی روش ایشان که یک روش بسیار آسان برای گرفتن نتایج بهتر و سریع‌تر در کار و زندگی است، بپردازم. امیدوارم همانطور که من این روش را مفید و کاربردی یافتم، برای خوانندگان این مقاله هم تأثیرگزار باشد.

این مدل که روش چابک ( Agile way ) نام دارد برپایه چهار اصل اساسی  به نام‌های قانون سه تایی، دیدگاه شنبه، خروجی روزانه و بازخورد پنجشنبه شکل گرفته است که درادامه به توضیح هریک از این اصول پرداخته شده است.

1)  قانون سه تایی:

این قانون یک قانون ساده است و به شما کمک میکند تا در زمانی که خیلی پرمشغله هستید، با یک روش ساده بتوانید به کارهای خود سروسامان دهید و در زمان کوتاه به بهترین نتایج دلخواه‌تان دست یابید.

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

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

2) دیدگاه شنبه

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

3) خروجی روزانه

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

4) بازتاب پنجشنبه

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

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

نقاط جوش

در جدول برنامه ریزی مدل چابک ستونی به نام نقاط جوش ( hot spots ) گنجانده شده است. اگر مسایل مهم زندگی خود را در نظر بگیرید، احتمالاً آنها جزء یکی از مسایل مربوط به تفکرات و یا جسم شما، مسایل احساسی ویا مالی، معاشرت با دیگران و تفریحات خواهند بود. نقاط جوش زندگی در حقیقت بخش هایی از زندگی شما هستند که شما بر روی آنها تمرکز بیشتری دارید و به طور ساده آنها می‌توانند بیانگر درد و رنج فراوان، یا موفقیت‌ها و موقعیت‌های فراوان برای شما باشند. نکته‌ی مهم این است که این نقاط جوش هرچه باشند، بخش‌های مهمی در زندگی شما، از نظر شما هستند.

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

خلاصه‌ی مطلب

1) قانون سه تایی به عنوان یک روش ساده برای جلوگیری از بی نظمی و هرج ومرج و به سرانجام رساندن کارهای موردنظر با کیفیت بالا در مدت زمان مناسب به کار می‌رود.

2) ابتدا سه نقطه‌ی جوش را در زندگی خود انتخاب کنید. سه نتیجه‌ی کلی و نهایی را برای هریک، براساس اولویت‌ها و اهمیت آنها مشخص کنید. به طور مثال این سوال را از خود بپرسید که دوست دارید در سال آینده در هر یک از این بخشهای زندگی خود، چه دستاوردی را داشته باشید.

3) انتخاب سه دستاورد دلخواه را به صورت ماهیانه، هفتگی و روزانه تکرار کنید. توجه کنید که خروجی هر روز باید در راستای خروجی هفته و خروجی هر هفته در راستای خروجی هر ماه، باشد.

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

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

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

رمز موفقیت در روش برنامه ریزی چابک، اولویت بندی مؤثر کارها و خواسته‌هاست. زمانیکه شما احساس کنید دارید بر روی کار و هدفی درست، در زمانی مناسب کار می‌کنید تمرکز بیشتری برروی کارتان خواهید داشت و بنابراین نتایج بهتری از انجام آن کار خواهید گرفت.

همه‌ی ما با اولویت بندی آشنا هستیم و معمولا با اختصاص دادن شماره به هر مورد، آن مورد را اولویت بندی می‌کنیم. به طور مثال، «نوشتن مقاله برنامه ریزی به روش چابک» اولویت 2، «شبیه سازی الگوریتم همزمان سازی» اولویت 1 و «دویدن به مدت 30 دقیقه» اولویت 3، مثال‌هایی از اولویت بندی به روش سنتی است. اما آقای  Meier .J.D  در کتاب خودش روش مؤثرتری را که بر اساس بایدها و نبایدها بنا شده است، پیشنهاد می‌کند که در ادامه به آن اشاره می‌کنیم.

اولویت‌ها در مدل چابک 

در این روش سه درجه از اولویت وجود دارند. درجه‌ی اول، کارهایی هستند که حتما باید انجام بگیرند. درجه دوم، کارهایی هستند که بهتراست (بایستی) انجام شوند و درجه سوم، کارهایی هستند که می‌شود انجام شوند و یا نشوند. آقای Meier این سه درجه را به ترتیب با سه واژه " Must "، " Should " و " Could " مشخص کرده است.

روش اولویت بندی در مدل چابک

برای تهیه سه دیدگاه هفته و خروجی روزانه، ابتدا لیستی از اهداف و کارهای مورد نظر خود را تهیه کنید. سپس از خود بپرسید: (1) کدامیک از اقلام این لیست را باید انجام دهید؟ (2) کدامیک را بهتر است که انجام دهید؟ (3) کدامیک را می‌توانید انجام دهید؟ پس از مشخص کردن اولویت‌ها، سه خروجی روزانه و یا سه دیدگاه هفتگی خود را از میان اقلامی که در دسته اول، یعنی بایدها قرار می‌گیرند، انتخاب کنید.

مزایای اولویت بندی

1- نتیجه‌ای که از اولویت بندی کارها نصیبتان می‌شود ارزش این را دارد که روی فرآیند اولویت بندی، مدت زمانی را صرف کنید. بدون اولویت بندی شما نگران یک لیست طولانی از کارهای خود هستید؛ در حالیکه  فکر می‌کنید مشغول انجام یک کار مهم هستید. در آخر روز متوجه می‌شوید که کاری که باید انجام می‌گرفته است، انجام نشده است.

2-  با تعیین اولویت‌ها برای هفته و هر روز خود، شما حداقل کارهایی را که باید برای هفته یا هر روز خود انجام دهید، مشخص کرده‌اید. زمانیکه این بایدها را انجام دهید، بقیه هفته و یا روز برای شما خواهد بود و می‌توانید از آن لذت ببرید!

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

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

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

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

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

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

اتحاد چابک

در وضعیتی که تیم­های نرم افزاری در بسیاری از شرکت­ها خود را در مردابی از فرآیندهای زیاد شونده می­دیدند، تعدادی از خبره‌­های این صنعت که خود را اتحاد چابک[۲] نامیدند در اویل سال ۲۰۰۱ یکدیگر را ملاقات کرده و ارزش هایی را معرفی کردند تا تیم­های نرم افزاری سریعتر نرم افزار را توسعه داده و زودتر به تغییرات پاسخ دهند. چند ماه بعد، این گروه ارزش­هایی تعریف شده را تحت مانیفست اتحاد چابک در سایت http://agilemanifesto.org منتشر کردند.

مانیفست اتحاد چابک

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

۱- افراد و تعاملات بالاتر از فرآیندها و ابزارها

۲- نرم افزار کار کننده بالاتر از  مستندات جامع

۳- مشارکت مشتری بالاتر از قرارداد کاری

۴- پاسخگویی به تغییرات بالاتر از پیروی از یک برنامه

با آنکه موارد سمت چپ ارزشمند هستند ولی ما برای موارد سمت راست ارزش بیشتری قائل هستیم.

افراد و تعاملات بالاتر از فرآیندها و ابزارها

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

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

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

نرم افزار کار کننده بالاتر از  مستندات جامع

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

با این حال، مستندات زیاد از مستندات کم بدتر است. ساخت مستندات زیاد نیاز به وقت زیادی دارد و وقت بیشتری را می‌گیرد تا آن را با کد برنامه به روز نمایید. اگر آنها با یکدیگر به روز نباشند باعث درک اشتباه از سیستم می‌شوند.

بهتر است که همیشه مستندات کم حجمی از منطق و ساختار برنامه داشته باشید و آن را به روز نماید. البته آنها باید کوتاه و برجسته باشند. کوتاه به این معنی که ۱۰ تا ۲۰ صفحه بیشتر نباشد و برجسته به این معنی که طراحی کلی و ساختار سطح بالای سیستم را بیان نماید.

اگر فقط مستندات کوتاه از ساختار و منطق سیستم داشته باشیم چگونه می‌توانیم اعضای جدید تیم را آموزش دهیم؟ پاسخ کار نزدیک شدن به آنها است. ما دانش خود را با نشستن در کنار آنها و کمک کردن به آنها انتقال می­دهیم. ما آنها را بخشی از تیم می­کنیم و با تعامل نزدیک و رو در رو به آنها آموزش می­دهیم.

مشارکت مشتری بالاتر از قرارداد کاری

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

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

قراردادی که مشخص کننده نیازمندیها، زمانبندی و قیمت پروژه است، اساسا نقص دارد. بهترین قرارداد این است که تیم توسعه و مشتری با یکدیگر کار کنند.

پاسخگویی به تغییرات بالاتر از پیروی از یک برنامه

توانایی پاسخ به تغییرات اغلب تعیین کننده موفقیت یا شکست یک پروژه نرم افزاری است. وقتی که طرحی را می­ریزیم باید مطمئن شویم که به اندازه کافی انعطاف پذیر است و آمادگی پذیرش تغییرات در سطح بیزنس و تکنولوژی را دارد.

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

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

اصول چابک

۱- بالاترین اولویت ما عبارت است از راضی کردن مشتری با تحویل سریع و مداوم نرم افزار با ارزش. تحویل نرم افزار با کارکردهای کم در زود هنگام بسیار مهم است چون هم مشتری چشم اندازی از محصول نهایی خواهد داشت و هم مسیر کمتر به بیراهه می‌رود.

۲- خوش آمدگویی به تغییرات حتی در انتهای توسعه. اعضای تیم چابک، تغییرات را چیز خوبی می‌بینند زیرا تغییرات به این معنی است که تیم بیشتر یاد گرفته است که چه چیزی مشتری را راضی می‌کند.

۳- تحویل نرم افزار قابل استفاده از چند هفته تا چند ماه با تقدم بر تحویل در دوره زمانی کوتاهتر. ما مجموعه از مستندات و طرحها را به مشتری نمی‌دهیم.

۴- افراد مسلط به بیزنس و توسعه دهندگان باید روزانه با یکدیگر روی پروژه کار کنند. یک پروژه نرم افزاری نیاز به هدایت مداوم دارد.

۵- ساخت پروژه را بر توان افراد با انگیزه بگذارید و به آنها محیط و ابزار را داده و اعتماد کنید.  مهمترین فاکتور موفقیت افراد هستند، هر چیز دیگر مانند فرآیند، محیط و مدیریت  فاکتورهای بعدی محسوب می­شوند که اگر تاثیر بدی روی افراد می­گذارند، باید تغییر کنند.

۶- بهترین و موثر‌ترین روش کسب اطلاعات در تیم توسعه، ارتباط چهره به چهره است. در تیم چابک افراد با یکدیگر صحبت می‌کنند. نامه نگاری و مستند سازی فقط زمانی که نیاز است باید صورت گیرد.

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

۸- فرآیندهای چابک توسعه با آهنگ ثابت را ترویج می‌دهد. حامیان، توسعه دهندگان و کاربران باید یک آهنگ توسعه ثابت را حفظ کنند که بیشتر شبیه به دو  ماراتون است یا دوی ۱۰۰ متر. آنها با سرعتی کار می‌کنند که بالاترین کیفیت را ارائه دهند.

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

۱۰-  سادگی هنر بیشینه کردن مقدار کاری که لازم نیست انجام شود، است. تیم چابک همیشه ساده‌ترین مسیر که با هدف آنها سازگار است را در پیش می­گیرند. آنها وقت زیادی روی مشکلاتی که ممکن است فردا رخ دهد، نمی­گذارند.  آنها کار امروز را با کیفیت انجام داده و مطمئن می­شوند که تغییر آن در صورت بروز مشکلات در فردا، آسان خواهد بود.

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

۱۲-  در بازهای زمانی مناسب تیم در می­یابد که چگونه می­تواند کاراتر باشد و رفتار خود را متناسب با آن تغییر دهد. تیم می­داند که محیط دائما در حال تغییر است، بنابراین خود را با محیط تغییر می­دهد تا چابک بماند.

ضرورت توسعه چابک

امروزه صنعت نرم افزار دارای سابقه بدی در تحویل به موقع و با کیفیت نرم افزار است. گزارشات بسیاری تایید می­کنند که بیش از ۸۰ درصد از پروژه‌های نرم افزاری با شکست مواجه می­شوند؛ در سال ۲۰۰۵ موسسه IEEE  برآورد زده است که بیش از ۶۰ بیلیون دلار صرف پروژه‌های نرم افزاری شکست خورده شده است. عجب فاجعه­ای؟

شش دلیل اصلی شکست پروژه‌های نرم افزاری

وقتی که از مدیران و کارکنان سوال می­شود که چرا پروژه‌های نرم افزاری با شکست مواجه می­شوند، آنها به موضوعات گسترده ای اشاره می­کنند. اما شش دلیل زیر بارها و بارها تکرار شده است که به عنوان دلایل اصلی شکست نرم افزار معرفی می­شوند:

۱- درگیر نشدن  مشتری

۲- عدم درک درست نیازمندها

۳- زمان بندی غیر واقعی

۴- عدم پذیریش و مدیریت تغییرات

۵- کمبود تست نرم افزار

۶- فرآیندهای غیر منعطف و باد دار

چگونه چابکی این مشکلات را رفع می­کند؟

با آنکه Agile برای هر مشکلی راه حل ندارد ولی برای مسائل فوق بدین صورت کمک می­کند:

مشتری پادشاه است!

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

نیازمندی‌ها به صورت تست­های پذیرش[۳] نوشته می­شوند

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

زمانبندی با مذاکره بین تیم توسعه و سفارش دهنده تنظیم می­شود

برای حل مشکل زمان بندی غیر واقعی، Agile زمان بندی را به صورت یک فرآیند مشترک بین تیم توسعه و سفارش دهنده تعریف می­کند. در شروع هر نسخه از  نرم افزار، سفارش دهنده ویژگی‌های مورد انتظار را به تیم توسعه می­گوید. تیم توسعه تاریخ تحویل را بر اساس ویژگی­ها برآورد می­زد و در اختیار سفارش دهنده قرار می­دهد. این تعامل تا رسیدن به یک دیدگاه مشترک ادامه می­یابد.

هیچ چیزی روی سنگ حک نشده است، مگر تاریخ تحویل

برای رفع مشکل ضعف در مدیریت تغییرات، Agile اصرار دارد که هر کسی باید تغییرات را بپذیرد و نسبت به آنها واقع بین باشد. یک اصل مهم Agile  می­گوید که هر چیزی می­تواند تغییر کند مگر تاریخ تحویل! به عبارت دیگر همین که محصول به سمت تولید شدن حرکت می­کند، مشتری (در تیم محصول) می­تواند بر اساس اولویت­ها و ارزش­های خود ویژگی­های محصول را کم یا زیاد کرده و یا تغییر دهد. به هر حال او باید واقع بین باشد. اگر او یک ویژگی جدید اضافه کنید، باید تاریخ تحویل را تغییر دهد. به این ترتیب همیشه تاریخ تحویل رعایت می­گردد.

تست­ها قبل از کد نوشته می­شوند و کاملا خودکار هستند

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

مدیریت پروژه یک فعالیت جداگانه نیست

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

به کار گیری توسعه چابک

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

برای این یک توسعه دهنده چابک شوید، باید به مهارت­های فردی و تیمی چابک برسید. در ادامه این مهارت­ها معرفی می­شوند.

مهارت­های فردی

قبل از هر چیز شما باید یک برنامه نویس باشید و مقدمات برنامه نویسی مانند الگوریتم و فلوچارت، دستورات برنامه نویسی، کار با متغیرها، توابع و آرایه­‌ها را بلد باشید. پس از تسلط به مقدمات برنامه نویسی می­توانید مهارت­های برنامه نویسی چابک را فرا بگیرید که عبارتند از:

- برنامه نویسی شیءگرا

- توسعه تست محور

- الگوهای طراحی

در ادامه نحوه کسب این مهارت­ها بیان می­شوند.

برنامه نویسی شیءگرا

اساس طراحی چابک بر تفکر شیءگرا استوار است. بنابراین تسلط به مفاهیم و طراحی شیءگرا ضروری است. 

توسعه تست محور

مهمترین و انقلابی‌ترین سبک برنامه نویسی از دهه گذشته تا به امروز، توسعه یا برنامه نویسی تست محور است. این سبک بسیاری از ارزش‌های توسعه چابک را فراهم می­کند و یادگیری آن برای هر توسعه دهنده چابک ضروری است.

الگوهای طراحی

الگوهای طراحی راه حل­های انتزاعی سطح بالا هستند. این الگوها بهترین تکنیک­های[۴] طراحی نرم افزار هستند و بسیاری از مشکلاتی که در طراحی نرم افزار رخ می­دهند با استفاده از این الگوها قابل حل هستند.

مهارت­های تیمی

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

اسکرام

تمامی مهارت­های تیمی توسعه چابک توسط اسکرام آموزش داده می­شوند. اسکرام فریم ورکی برای توسعه چابک است که با تعریف فرآیندها، نقش­ها و آرتیفکت­های مشخص به تیم­های نرم افزاری کمک می­کند تا چابک شوند.

---

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

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

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

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

ج) اگر پروژه شما یک کتابخانه است، نوع زبان و Runtimeهای پشتیبانی شده را مشخص کنید
برای مثال اگر یک کتابخانه دات نتی را ارائه می‌دهید، مشخص کنید که از کدام نگارش دات نت به بعد را پشتیبانی می‌کنید.

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

- یک پروژه نیاز به مستندات دارد
مستند سازی کار، سخت و زمانبر است؛ اما بهترین لطفی است که می‌توانید به کاربران خود نمائید. مستندات نه تنها زمان جستجوی بسیاری را صرفه جویی خواهند کرد، همچنین حس اطمینان خاطر را به کاربر القاء می‌کنند. از این جهت که احساس می‌کنند شما برای کارتان ارزش قائل بوده‌اید و احتمال اینکه این برنامه در آینده نزدیک به یک abandonware تبدیل شود، کم است (منظور یک برنامه فراموش شده و خاتمه یافته).

- به روز رسانی را ساده کنید
بالاخره زمانی نیاز خواهد بود تا نگارش جدیدی از کار خود را ارائه دهید. در این حالت نیاز است یک سری از شرایط را مدنظر داشته باشید:
الف) سازگاری قبلی را مدنظر داشته باشید
یکی از بدترین حالات به روز رسانی یک کتابخانه زمانی است که کاربر آن با ده‌ها خطای کامپایل حاصل از به روز رسانی مواجه شود. اگر نیاز است قسمتی از کد خود را حذف کنید یا تغییر دهید، استفاده از ویژگی Obsolete را فراموش نکنید و اینکار باید مرحله به مرحله انجام شود. در یک نگارش، ویژگی Obsolete را معرفی کنید. در دو نگارش بعد، API را تغییر دهید.
ب) حتما یک Change log را تکمیل کنید
پس از ارائه یک نگارش جدید، حداقل در چند سطر مشخص کنید که چه مواردی تغییر کرده‌اند، چه مواردی اضافه شده‌اند و چه مواردی را حذف کرده‌اید.
همچنین اگر مواردی تغییر کرده‌اند، نحوه ارتقاء کدهای قدیمی را به نگارش جدید، شرح دهید. اگر مورد جدیدی اضافه شده‌است، لینکی را به مثالی درباره‌ی آن ارائه دهید.

- نگارش‌های جدید را اعلام کنید
برای مثال در طی ارائه یک مطلب جدید در وبلاگ خود، ارائه نگارش جدیدی از کتابخانه یا برنامه خود را به عموم اعلام کنید. در این حالت، حتما لینکی را به change log، ارائه داده و مشخص کنید که وضعیت سازگاری آن با قبل چگونه است.

- محلی را برای دریافت بازخوردهای پروژه خود مشخص کنید
نیاز است بتوانید پروژه خود را پشتیبانی کنید یا به سؤالات مربوطه پاسخ دهید. اگر سورس کنترل یا برنامه مدیریت پروژه شما، امکان پرسش و پاسخ را دارد، که بسیار خوب. اگر خیر، می‌توانید مثلا یک گروه گوگل جدید و امثال آن‌را برای دریافت بازخوردهای پروژه ایجاد کنید.
همچنین نیاز است لینک به این محل را در فایل ReadME پروژه به صراحت مشخص کنید.

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

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

در این روش چهار دسته وجود دارد که هر فعالیت می‌تواند در آن دسته قرار بگیرد: (1) انجام شود، (2) موکول شود، (3) زمانبندی شود، (4) واگذار شود.

1) دسته اول کارهایی هستند که هم اکنون زمان انجام آنها فرا رسیده است. به این معنی که یا اکنون بهترین زمان انجام آنهاست، یا اگر آنها را به آینده موکول کنید مجبور خواهید بود انرژی و وقت بیشتری را صرف انجام آنها کنید.

2) دسته دوم کارهایی هستند که می‌بایستی انجام شوند اما اکنون زمان مناسبی برای انجام آنها نیست. بنابراین شما می‌توانید آنها را در صف انتظار قرار دهید و در آینده تصمیم بگیرید که با آنها چه کنید.

3) دسته سوم کارهایی هستند که برای شما اهمیت بالایی دارند، اما اکنون زمان مناسبی برای انجام آنها نیست. آنها را زمانبندی کنید. به این معنی که در تقویم خود برای انجام آنها یک زمان مشخص درنظر بگیرید تا در آن زمان انجام شوند.

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

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

سؤالات زیر را در نظر بگیرید:

1- چه دستاوردی را می‌خواهید داشته باشید؟

2- آیا واقعا مهم است؟

3- چقدر مهم است؟

4- به انجام رساندن این کار چه تاثیر یا نتایجی خواهد داشت؟

5- بهترین کاری که می‌توانید الان انجام دهید چیست؟

6- آیا حتما باید توسط من انجام گیرد؟

7- و...

این‌ها نمونه سؤالاتی هستند که می‌توانید در زمان دسته بندی کردن کارها از خود بپرسید. سؤالاتی از این قبیل شما را راهنمایی می‌کنند تا دسته بندی کارها را با مهارت بیشتر و بهتری انجام دهید.

بعد از دسته بندی کارها، حالا لیستی از کارهایی را دارید که هم اکنون زمان انجام آنها فرا رسیده است. آنها را توسط سیستم اولویت بندی چابک، اولویت بندی نمایید و 3 تا از بایدهای لیست را به عنوان دیدگاه هفتگی و یا خروجی روزانه انتخاب کنید.