صفر تا صد بیانیه و اصول مدیریت چابک Agile

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

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

تعریف و تاریخچه

از اواخر دهه ۱۹۸۰ تا اواسط دهه ۱۹۹۰ در پی تحولات گسترده اقتصادی و سیاسی در سرتاسر جهان، تلاش‌ها و اقدامات زیادی برای شناخت ریشه‌ها و عوامل مؤثر بر نظام‌های جدید در کسب‌ و کار جهانی صورت گرفت. برای نخستین بار، وقتی ایالات ‌متحده امریکا با رکود چشمگیری در سهم کسب‌وکار جهانی به‌ ویژه در عرصه تولید(که با رقابت‌های جدیدی از سوی آسیا و اروپا روبه‌رو شده بود) مواجه شد، رهبری این نهضت را در دست گرفت.در سال ۱۹۹۱ گروهی از متخصصان صنعتی مشاهده کردند که نرخ افزایش تغییرات در محیط تجاری، از توانایی‌های سازمان‌های تولیدی سنتی در جهت تطبیق و سازگاری با تغییرات سریع‌تر است. این سازمان‌ها در استفاده از فرصت‌هایی که برای آن‌ها پیش می‌آمد، ناتوان بودند و این ناتوانی ممکن بود در بلندمدت باعث ورشکستگی و ناکامیشان شود.بنابراین برای نخستین بار، دیدگاه متخصصان صنعتی در گزارشی تحت عنوان “استراتژی بنگاه‌های تولیدی در قرن بیست و یکم” به‌ وسیله مؤسسه لاکوکا منتشر و به همگان معرفی شد و بلافاصله بعد از آن، عبارت تولید چابک به ‌طور مشترک با انتشار این گزارش مورد استفاده عموم قرار گرفت.

جان بیان اینکه، چابک مجموعه ای از ارزش ها و اصول جهت توسعه خروجی ها و نتایج کارا توسط تیم های خودمدیریتی می باشد.

بیانیه یا مانیفست مدیریت چابک

   در سال 2001 مارتین فاولر و جیم های اسمیت ، بیانیه یا مانیفست چابک را برای توسعه نرم‌افزار چابک یشنهاد دادند کردند و 17 نفر از اجیلیست های آن زمان نیز این بیانیه را امضاء کردند؛ اما باوجودیکه این بیانیه در ابتدا در حوزه نرم افزار مطرح شد، اما اکنون در همه حوزه های کسب و کار، مدیریت پروژه، تولید ، بازاریابی و مدیریت عملیات نیز صادق است. این بیانیه ۴ گانه عبارت است از:

• افراد و تعاملات بینشان، اولویت دارد بر مقابل فرایندها و ابزارها
• نرم‌افزار (هر نوع خروجی) کارا و قابل اجرا، اولویت دارد بر مستندات حجیم
• همکاری و تعامل با مشتری، اولویت دارد بر مذاکرات قرادادی
• پاسخ‌گویی به تغییرات ( حتی خیلی دیر)، اولویت دارد بر پیروی از برنامه (حتی از پیش تعریف شده)

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

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

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

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

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

جمله دوم بیانیه بیشتر به ساخت نرم‌افزار  یا هر نوع خروجی کارا و قابل اجرا توجه دارد تا مستندسازی. اگر از کاربری پرسیده شود که آیا ترجیح می‌دهد نرم افزار قابل اجرا و مناسب در اختیار داشته باشد یا یک سند ۱۰۰ صفحه‌ای، چه پاسخی خواهد داد؟ در 99 درصد موارد، پاسخ “نرم افزار مناسب یا خروجی کارا” خواهد بود. مستندات برای آموزش کاربران و تا حدودی برای نگهداری از سیستم مورد نیاز هستند؛ اما نباید فراموش کرد که هدف اصلی توسعه نرم افزار است، نه توسعه مستندات.

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

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

اصول مدیریت چابک

بیانیه چابک مجموعه‌ای از ۱۲ اصول مدیریت چابک را تعریف می‌کند که این اصول ویژگی‌های بیانیه و جزئیات فرایند چابک را تشریح می کنند:

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

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

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

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

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

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

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

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

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

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

اصل ۱۰: سادگی(هنر به حداکثر رساندن انجام ندادن کار های غیر لازم) ضروری است. مثلا نبود کد (یا برنامه) به معنی نبود مشکل است^.. هرچه بیشتر کد بنویسید، ممکن است کدهای شما خطاهای بیشتری داشته باشند. برخی توسعه‌دهندگان تلاش می‌کنند چارچوب‌ها و بنیان‌های زیربنایی جامعی در سیستم ایجاد کنند، با این فرض که آن اجزا ممکن است در آینده لازم شوند. اصل در سادگی است.

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

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

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

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

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