مقدمه ای بر مدیریت پروژه چابک

1. مقدمه ای بر چابک
1.1. تاریخچه مختصری از Agile
در این بخش تاریخچه Agile به طور مختصر معرفی می شود و شما با ارزش ها و اصول Agile آشنا می شوید و خواهید آموخت که Agile می تواند در بسیاری از صنایع مختلف مورد استفاده قرار گیرد.

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

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

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

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

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

اکنون کمی در مورد تاریخچه Agile، منشا مانیفست Agile و برخی از صنایعی که از Agile برای مدیریت پروژه استفاده می کنند، می دانید. در ادامه، تفاوت های بیشتری بین Waterfall و Agile را با هم مقایسه خواهیم کرد تا واقعاً با این سبک های مدیریت پروژه آشنا شوید.



2.1. تمایز چابک از آبشار
عناصر کلیدی Agile را که آن را از Waterfall متمایز می کند، به تصویر کشیده می شود. سپس وقتی بعداً وارد مانیفست شدید، می‌توانید این دانش را تقویت کنید.

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

چند تفاوت بیشتر بین Waterfall و Agile :

سه جنبه مهم پروژه عبارتند از: الزامات، مستندات و اقلام قابل تحویل.

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

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

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

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

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

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

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



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

مانیفست چابک در سال 2001 نوشته شد و خرد جمعی افرادی را گرد هم می آورد که آن را باتوجه به تجربه گسترده و رهبری فکری خود در صنعت فناوری توسعه دادند. اگر می‌خواهید مانیفست را پیدا کنید، کار آسانی است—فقط در مرورگر جستجوی خود agilemanifesto.org را تایپ کنید. Manifesto for Agile توسعه نرم‌افزار می‌گوید:

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

ترجیح نرم افزار کارامد به مستند سازی های گسترده

ترجیح همکاری با مشتری به مذاکره قرارداد

ترجیح پاسخ به تغییرات به پیروی از یک طرح ثابت

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

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

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

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

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

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

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



4.1. دوازده اصل مانیفست چابک
12 اصلAgile، مطابق مانیفست اجایل، به شرح زیر است:

ایجاد رضایت در مشتری از طریق تحویل زودهنگام و مستمر نرم افزارهای ارزشمند.

استقبال از تغییرات

تحویل مکرر نرم افزار کارامد

همکاری هر روزه در طول پروژه

ایجاد پروژه ها پیرامون افراد با انگیزه که برای انجام کار مورد اطمینان هستند

مکالمه حضوری هر زمان که ممکن است

نرم افزار کارامد شاخص اصلی پیشرفت است

حفظ سرعت ثابت

توجه مستمر به تعالی فنی و طراحی خوب

حفظ سادگی – هنر به حداکثر رساندن میزان کار انجام نشده – ضروری است

بهترین معماری ها، الزامات و طرح ها از تیم های دارای سازمان دهی درونی پدیدار می شوند

در مورد چگونگی مؤثرتر شدن تأمل کنید، سپس در فواصل منظم آن را محقق کنید



این اصول پیام چهار ارزش را تقویت می کنند و وضوح بیشتری را ارائه می دهند و با چهار ارزش متفاوت اند. چهار موضوع اصول چابک عبارتند از:

- تحویل ارزش، یا چگونه تیم های چابک محصولات بسیار با ارزش را به مشتریان خود ارائه می کنند؟

- همکاری تجاری، یا چگونه تیم های Agile با شرکای تجاری و سهامداران خود برای ایجاد ارزش تجاری برای سازمان و کاربرانشان همکاری می کنند؟

- فرهنگ تیمی، یا چگونه یک تیم پویایی مناسب بین فردی و تیمی را برای ارائه ارزش برای مشتریان و کسب و کار ایجاد و حفظ می کند؟

-گذشته نگر، یا چگونه پروژه یاد می گیرد که به طور مداوم عملکرد یک سازمان و کسب و کار را افزایش دهد؟



هر یک از 12 اصل در زیر این مضامین گروه بندی شده تا یادگیری و به خاطر سپردن آنها آسان تر باشد.



موضوع اول تحویل ارزش است و شامل پنج اصل است.

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

-اینها ممکن است بسیار نرم‌افزار محور به نظر برسند، اما اگر کلمه «نرم‌افزار» را با «موارد قابل تحویل» یا «راه‌حل» جایگزین کنید، این موارد می‌توانند تقریباً برای هر پروژه‌ای اعمال شوند. به عنوان مثال: راه حل های کاری را به طور مکرر ارائه دهید.

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

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

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

موضوع دوم همکاری تجاری است و شامل دو اصل دیگر است.

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

-مثال دیگر ممکن است نحوه مدیریت بازخورد و تغییرات در اولویت ها باشد. به جای تلاش برای دور نگه داشتن مشتری از توسعه دهندگان به دلیل نگرانی در مورد خزش دامنه، یک huddle هفتگی ایجاد کنید که در آن مشتریان و کسب و کارمردم می توانند بازخورد و ایده های جدید را با تیم بررسی کنند. این می تواند راهی عالی برای کشف این موضوع باشد که ساختن یک ویژگی واقعاً ارزشمند بسیار آسان است، در حالی که ویژگی دیگری که کاربران فکر می کردند آسان است در واقع واقعاً سخت است.

موضوع سوم پویایی و فرهنگ تیم است و شامل چهار اصل دیگر است.

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

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

- نمونه ای از تاکید بر فرهنگ تیمی موثر این است که از تیم بپرسید که به چه نوع تجهیزاتی برای انجام کار خود نیاز دارند و سپس آن ابزارها را در اختیار آنها قرار دهید.

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

آخرین اصل در موضوع گذشته نگر و یادگیری مستمر به تنهایی وجود دارد.

- در فواصل زمانی منظم، تیم در مورد چگونگی موثرتر شدن فکر می کند، سپس رفتار خود را بر اساس آن تنظیم می کند. این یکی به تنهایی آورده شده، زیرا می‌خواهم توجه را جلب کنم که چقدر برای تیم‌های Agile مهم است که به طور مداوم یاد بگیرند و با آنچه که برای آنها کار می‌کند و چه چیزی برای آنها کار نمی‌کند سازگار شوند. تیم‌ها همیشه باید راه‌های بهتری برای کار بیابند و این واقعاً ارزشمند است که بعد از هر بار تکرار، این زمان را کنار بگذاریم و کاملاً روی چگونگی بهبود تمرکز کنیم. در این جلسات، تیم می‌تواند عقب‌نشینی کند و سؤالاتی مانند: وضعیت تیم چگونه است؟ آیا مشتریان راضی هستند؟ آیا فرآیندهایی وجود دارد که بتوانیم آنها را بهینه کنیم؟ آیا ابزارهای ما برای ما کار می کنند؟ آیا ما از ارزش ها پیروی می کنیم؟ آیا بدهی انباشته می کنیم؟ و منظور از "بدهی" فرآیندها یا فناوری هایی است که سرعت ما را کند می کند.

رسما بحث درباره مانیفست چابک به پایان رسید. این چهار ارزش و 12 اصل، پایه پیشرفت های بسیاری در مدیریت پروژه هستند. در ادامه نشان می دهیم چگونه اینها به فعالیت های روزمره یک پروژه چابک مرتبط می شوند و چه نوع صنایعی از رویکرد چابک بیشترین سود را می برند.



5.1. اتخاذ یک طرز فکر چابک
هر پروژه در سازمان ها و محیط هایی با فرهنگ ها، اهداف تجاری و پویایی های صنعتی متفاوت وجود دارد. سناریوهای مختلفی را مورد بحث قرار می‌دهیم که در آن‌ها می‌خواهید ذهنیت چابکی را اتخاذ کنید. همچنین مفهومی به نام VUCA معرفی می شود که می تواند به شما کمک کند تصمیم بگیرید کدام رویکرد مدیریتی برای پروژه شما بهترین است. به یاد داشته باشید، Agile در مورد ارائه ارزش در جهانی با درجه بالایی از عدم اطمینان، ریسک و رقابت است. تیمی را تشکیل می دهد تا در سریع ترین زمان ممکن به اطلاعات جدید، فرصت های جدید بازار و حتی فناوری های جدید واکنش نشان دهند. Agile در صنایع یا پروژه هایی که مستعد تغییر و عدم اطمینان هستند یا مشوق تغییر و عدم اطمینان هستند، بهترین کار را انجام می دهد. چه نوع مشاغل یا صنایعی به جز نرم افزار به ذهن می رسد که با تغییرات زیادی سروکار دارد؟ چند موردی که می توان اشاره کرد: بیوتکنولوژی با واکسن‌ها، درمان‌ها و فناوری‌های نوظهور، رسانه‌هایی با روش‌های جدید بی‌پایان برای اشتراک‌گذاری محتوا هستند. صنعت غذا با سرآشپزهای مشهور و جدیدترین علاقه غذایی و مد، صنعتی که بر اساس همگامی با روندهای در حال تغییر ساخته شده است. آیا هیچ کدام از اینها شما را شگفت زده کرد؟ از طرف دیگر، در اینجا برخی از صنایع وجود دارد که ممکن است به عنوان صنایع نسبتاً پایدار درنظر گرفته شوند، کشاورزی، هوافضا، تولید و معدن. اما حتی این صنایع با زنجیره تامین و کدهای دقیق، به دلیل قوانین و مقررات جدید، بلایای طبیعی و سایر مسائل پیش‌بینی نشده، باید با تغییرات سازگار شوند. چیزی که سال 2020 به همه ما آموخت این است که هیچ صنعتی واقعاً از تغییر و عدم اطمینان مصون نیست. ما قصد داریم مفهومی را برای طبقه بندی و تفکر در مورد این نیروهایی که دنیای ما را شکل می دهند، بدون توجه به اینکه در چه صنعتی هستیم، بررسی کنیم. این مفهوم VUCA نام دارد و می تواند به شما کمک کند تصمیم بگیرید کدام رویکرد مدیریت پروژه برای شما بهترین است.

کالج جنگ نظامی ایالات متحده مفهومی به نام VUCA با املای V-U-C-A ایجاد کرد. VUCA نام اختصاری است که شرایطی را که بر سازمان ها در دنیایی در حال تغییر و پیچیده تأثیر می گذارد، تعریف می کند. طراحی شده است تا به ما کمک کند تا نیروهای تغییر و عدم اطمینان را در پروژه‌ها و کسب‌وکارهایمان فاکتور کنیم. VUCA مخفف نوسانات، عدم قطعیت، پیچیدگی و ابهام (volatility, uncertainty, complexity, and ambiguity ) است.



VUCA در پروژه ها و تنظیمات تجاری

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

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

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

-بالاخره ابهام داریم. ابهام به احتمال سوء تفاهم از شرایط و علل ریشه ای رویدادها یا شرایط اشاره دارد. پروژه‌ای که از ابهام رنج می‌برد، در شناسایی دلایل تاخیر پروژه مشکل خواهد داشت و طراحی برنامه‌های کاهش خطرات را دشوار می‌کند.

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







چگونه می‌توان این مفاهیم جدید از Agile و VUCA را در یک پروژه جدید اعمال کرد.

6.1. به کارگیری Agile در محیط VUCA
سناریوی پروژه با پارامترهای VUCA بالا و نحوه اعمال رویکرد Agile توسط تیم Office Green را بررسی خواهیم کرد. چرا درک VUCA در ارتباط با مدیریت پروژه مهم است؟ هنگامی که پروژه جدیدی را شروع می کنیم، قبل از اینکه بهترین رویکرد برای استفاده را انتخاب کنیم، بررسی محیط و شرایطی که پروژه در آن وجود دارد، مفید است. اگر محیط پروژه شما دارای سطوح بالایی از نوسانات، عدم قطعیت، پیچیدگی و ابهام است، نشانه خوبی است که باید یک رویکرد چابک را در نظر بگیرید. در حالی که رویکرد چابک راه حل کاملی برای خلاص شدن از شر VUCA نیست، با در اختیار گذاشتن ابزارها و سیستم‌های شما و تیمتان برای کاهش خطراتی که VUCA ارائه می‌کند، به نتایج بهتری منجر می‌شود. هنگامی که ارزش ها و اصول Agile را در نظر می گیرید، واضح است که Agile یک راه حل اثبات شده و مستند برای چالش هایی است که VUCA برای پروژه شما ارائه می دهد.

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

برای انجام این کار، Office Green شما را به عنوان مدیر پروژه یک تیم جدید Agile منصوب کرد. هدف شما ارائه سرویس جدید آنها به نام Virtual Verde (دماغه سبز مجازی) است. آفیس گرین با چه محیطی روبرو شد؟ نوسان، عدم قطعیت، پیچیدگی و ابهام. آنها نوسانات را در قالب یک تغییر مخرب عمده در برنامه های تجاری خود تجربه کردند. عدم اطمینان از طریق فقدان قابلیت پیش بینی، که ایجاد برنامه های مشخص برای آینده را دشوار می کرد. سطح بالایی از پیچیدگی، به دلیل عوامل مرتبط با یکدیگر مانند تامین کنندگان و اقتصاد؛ و آنها با عدم توانایی در تعیین یا کنترل آنچه ممکن است باعث تغییرات آتی شود، دچار ابهام شدند. با استفاده از رویکرد چابک برای پروژه خود، Office Green توانست فاکتورهای VUCA بالا را که بر کسب و کارشان تأثیر می‌گذارد، رسیدگی کند. به جای اینکه تجارت به آرامی یا به سرعت به دلیل نیروهای بازار فرسوده شود، آفیس گرین، بازار در حال تغییر را پذیرفت و در نحوه نزدیک شدن به پروژه بعدی خود انعطاف پذیر بود.





2. فریم ورک متداول چابک
1.2. مقدمه ای بر اسکرام
تا کنون کمی از تاریخچه چابک، مانیفست چابک و برخی از انواع آن و پروژه هایی که از رویکرد چابک بهره می برند را بررسی کرده ایم. در ادامه، چند روش خاص به شما معرفی خواهد شد. زیر چتر چابک، متداول ترین آنها تا کنون اسکرام است.

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

مبتکران روش اسکرام، تیم خود را به عنوان یک گروه سر به زیر می دیدند کار کردن بسیار نزدیک با هم تا آن توپ را به زمین بیاورند، درست مانند یک اسکرام در یک مسابقه راگبی. پس چگونه می شود روش اسکرام به عنوان یک روش مدیریت پروژه کار می کند؟ اگر در مدیریت پروژه Agile کار می کنید، احتمال آن بسیار زیاد است که از اسکرام یا رویکردی مبتنی بر اسکرام استفاده خواهید کرد. در گزارش وضعیت چابک 2019، 72 درصد تیم ها با استفاده از روش های چابک از اسکرام یا ترکیبی استفاده می شد. وقتی از اسکرام برای مدیریت پروژه استفاده می کنید، تیمی که برای توسعه و آزمایش سریع یک محصول تحویلی با یکدیگر همکاری خواهند کرد فرم می گیرد. کار به طور خلاصه تمام شد چرخه ها، و تیم هر روز برای بحث در مورد وظایف فعلی و پاکسازی هر چیزی که مانع پیشرفت آنها می شود، ملاقات می کند.



برخی از اصطلاحات و مفاهیم خاص اسکرام

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

- Sprint نام دوره زمانی در Scrum که در آن کار انجام می شود. اسپرینت می تواند بین یک تا چهار هفته طول بکشد .اما اکثر اسپرینت ها حدود دو هفته هستند. اغلب "تکرار" نامیده می شود.

- تمرینی به نام Daily Scrum وجود دارد که Stand-up نیز نامیده می شود. این جایی است که تیم هر روز به مدت 15 دقیقه اسپرینت یا کمتر برای بررسی پیشرفت آنها به سمت هدفشان ملاقات می کنند.

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



اسکرام به دلایل زیادی محبوب است.

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

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

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

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

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

اکنون برخی از ویژگی های کلیدی اسکرام و انواع پروژه ها را می دانید که واقعاً می توانند از آن بهره مند شوند. این یک روش هیجان‌انگیز است و در حالی که پیش از پیاده‌سازی کامل Scrum چیزهای بیشتری برای بحث داریم، ابتدا چند متدولوژی رایج Agile را مورد بحث قرار می‌دهیم. یادگیری در مورد این رویکردها به شما کمک می کند تا به یک عضو جامع و همه کاره در هر تیم پروژه تبدیل شوید.





2.2. معرفی مجدد Kanban، XP و Lean
روش‌های چابک پرطرفدار زیادی وجود دارند که هنوز از دهه 90، زمانی که Agile اختراع شد، وجود دارند. این روش‌ها، ارزش‌ها و اصول چابک را به اشتراک می‌گذارند، اما شیوه‌ها و کاربردهای بسیار خاصی دارند. علاوه بر اسکرام، به چند مورد از محبوب ترین آنها می پردازیم:

- اولین آنها Kanban است. این یک متدولوژی است که می تواند به روشی بسیار ساده اعمال شود، یا می توان از آن برای هدایت کل پروژه استفاده کرد. نام کانبان از دو کلمه ژاپنی گرفته شده است. «کان» به معنای «نشانه» و «بان» به معنای «تخته». ممکن است قبلاً از یک برد Kanban استفاده کرده باشید زیرا این معروف ترین ویژگی است که توسط اکثر علاقه مندان به Agile پذیرفته شده است. دلیل محبوبیت Kanban این است که بازخورد بصری شفافی را برای همه کسانی که ممکن است در مورد وضعیت کار در حال انجام علاقه مند باشند ارائه می دهد. تابلوها یا نمودارهای کانبان پیشرفت یک پروژه را به صورت در حال انجام و انجام شده نمایش می دهند. همچنین، به همین دلیل، ابزارهای نرم افزاری وجود دارند که تابلوهای دیجیتال کانبان را برای شما ایجاد می کنند. روش کانبان تضمین می کند که تیم پروژه فقط مقدار پایداری از کار در حال پیشرفت را می پذیرد. این به این معنی است که مقدار وظایف در پیشرفت به آنچه که تیم واقعاً می تواند در مدت زمان معینی انجام دهد محدود می شود. این محدودیت کار در حال پیشرفت یا محدودیت WIP نامیده می شود. محدودیت WIP توسط تیم تعیین می شود. این بازتابی از چابکی است که تیم‌ها هم خود سازماندهی می‌کنند و هم توانمند هستند و با سرعتی پایدار کار می‌کنند. اعضای تیم کارهای جدیدی را اضافه می کنند که تنها پس از اتمام کار قبلی خود و زیر حد WIP انجام می شوند. این رویکرد به این معنی است که هنگامی که کار روی یک کار شروع می شود، انجام آن برای کل تیم در اولویت قرار می گیرد. با تمرکز بر روی کار کمتر، کار سریعتر انجام می شود. این هدف از تلاش برای به حداکثر رساندن کارایی جریان نامیده می شود و یک اصل اصلی کانبان است.

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

چهار فعالیت اساسی وجود دارد که در طول فرآیند توسعه محصول انجام می شود که روش XP سعی در بهبود آنها دارد:

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

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

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

- گوش دادن به مشتری و اطمینان از ادغام الزامات در محصول: این امر به چابکی مربوط می شود به گونه ای که برای همکاری مشتری، ارتباطات مکرر و بازخورد منظم ارزش قائل است. نیازهای در حال تغییر کاربر باید شنیده شوند و در سیستم موجود ادغام شوند.

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

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

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

- Lean روش شناسی ناب شامل پنج اصل است که به عنوان دستورالعملی برای بهبود نتایج پروژه عمل می کند. آنها عبارتند از: تعریف ارزش، نقشه جریان ارزش، ایجاد جریان، ایجاد کشش و دنبال کردن کمال.

- تعریف ارزش به معنای شناسایی و تمرکز بر آنچه مشتری می خواهد و شامل کردن مشتری در فرآیند است. ارزش یک محصول مجموع تمام چیزهایی است که مشتری می خواهد.

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

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

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

-در نهایت، کمال را دنبال کنید. این به معنای تحت فشار قرار دادن تیم خود برای بهبود مستمر چهار مرحله اول فرآیند است.

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

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