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

فهرست مطالب این نوشته پنهان کردن

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

مدیریت چابک چیست؟

مدیریت چابک

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

مدیریت آبشاری در مقابل مدیریت چابک

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

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

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

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

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

مدیریت آبشاری

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

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

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

مدیریت چابک و ساختار سیکلی آن می‌تواند چندین فرصت برای تیم به وجود آورد:

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

مدیریت چابک به تیم‌ها اجازه می‌دهد واکنشی ارتجاعی‌تر به تغییراتی داشته باشند که به شکلی اجتناب‌ناپذیر حین پیش بردن یک پروژه رخ می‌دهند.

مدیریت چابک

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

قواعد مدیریت چابک

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

فاکتورهایی که هنگام گذار به مدیریت چابک باید در نظر داشت

مدیریت چابک

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

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

بیایید به بررسی مکانیزم‌هایی بپردازیم که مدیریت چابک از آن‌ها برای نظم‌بخشی، اجرا و ساختاربخشی به کار بهره می‌گیرد.

نقشه‌های راه

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

الزامات

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

وظایف انباشت شده (Backlog)

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

معیارهای چابک

تیم‌های چابک تمام موفقیت خود را مدیون معیارها هستند. محدودیت‌های Work in Progress (یا به اختصار WIP) تیم و کسب‌وکار را بر رسیدگی بر کارهایی که از بیشترین اولویت برخوردار هستند متمرکز می‌کند. گراف‌هایی مانند چارت‌های Burndown و چارت‌های کنترل به تیم در پیش‌بینی ریتم کار و دیاگرام‌های جریان فزاینده به شناسایی گلوگاه‌ها کمک می‌کنند. این معیارها باعث می‌شوند تمام اعضای تیم روی اهداف بزرگ متمرکز باشند و نسبت به توانایی‌های خود در رسیدگی به کارهای آتی اعتماد به نفس داشته باشند.

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

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

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

مدیریت چابک

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

کار را ساده و همین حالا شروع کنید

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

کارهایی که باید انجام شوند: کارهایی که هنوز شروع نشده‌اند.

کارهای در جریان: کارهایی که به صورت فعالانه تحت نظر تیم هستند.

بازنگری کد: کاری که به اتمام رسیده و نیازمند بازنگری و تایید نهایی است.

کار تمام شده: کاری که کاملا به پایان رسیده و با انتظارات تیم سازگار است.

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

جریان کاری مدیریت چابک

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

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

بهینه‌سازی جریان کاری

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

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

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

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

چالش‌های مقیاس‌پذیری در جریان کاری

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

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

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

اپیک‌ها، داستان‌ها، تم‌ها و ابتکار

مدیریت چابک

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

با درک اینکه این متدهای مدیریت چابک و DevOps چطور کار می‌کنند قادر به نظم‌بخشی به کار خواهید بود و تیم توسعه هم به بالانسی بی‌نقص میان ساختار و انعطاف‌پذیری رسیده و موشک را با موفقیت به فضا ارسال می‌کند.

داستان‌ها، اپیک‌ها، ابتکار و تم‌ها چه هستند؟

  • داستان‌ها (Stories) که به آن «داستان‌های کاربر» هم گفته می‌شود الزامات و خواسته‌هایی کوتاه هستند که از نقطه نظر کاربر نهایی نوشته می‌شوند.
  • اپیک‌ها (یا حماسه‌ها) بدنه بزرگ‌تری از کار هستند که می‌توانند به وظایفی کوچک‌تر (یا همان داستان‌ها) تقسیم شوند.
  • ابتکار مجموعه‌ای از اپیک‌ها است که به سمت هدفی مشترک حرکت می‌کنند.
  • تم‌ها نقاط تمرکز بزرگی هستند که تمام سازمان‌ها به آن‌ها پایبندی دارد.

اپیک‌ها و تم‌ها و داستان‌ها در مدیریت چابک

داستان چابک در برابر اپیک چابک

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

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

اگر تیم شما در پی ارسال موشک به فضا بود و می‌خواست سرویس استریم زنده پرتاب‌های موشک را بهبود ببخشد، استوری‌ها چنین شکل و شمایلی داشتند:

  • کاربران آیفون هنگام استفاده از یک اپلیکیشن موبایل برای تماشای استریم زنده پرتاب موشک نیازمند تماشای ویدیو به صورت افقی هستند
  • کاربران دسکتاپ نیاز به یک دکمه «فول‌اسکرین» در گوشه پایین سمت راست ویدیو پلیر خود دارند
  • کاربران اندرویدی باید به استور اپل متصل شوند

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

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

اپیک چابک در برابر ابتکار چابک

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

مثالی از اپیک درون ابتکار:

بیایید فرض کنیم که کمپانی موشک‌سازی شما می‌خواهد امسال هزینه پرتاب هر موشک را ۵ درصد کاهش دهد. این هدفی عالی برای یک ابتکار عمل است، زیرا هیچ اپیکی به تنهایی نمی‌تواند چنین هدفی را محقق کند. درون این ابتکار شاهد اپیک‌هایی نظیر «کاهش ۱ درصدی مصرف سوخت در فاز پرتاب»، «افزایش شمار پرتاب‌ها در یک سه‌ماهه از ۳ پرتاب به ۴ پرتاب» و «کاهش دمای تمام ترموستات‌ها از ۷۱ درجه به ۶۹ درجه» را شاهد خواهیم بود.

ابتکارها در برابر تم‌ها

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

  • ابتکارها مجموعه‌ای از اپیک‌ها هستند
  • تم‌ها لیبل‌هایی هستند که اهداف سطح بالا و سازمانی را پایش می‌کنند

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

اپیک‌های چابک: معنا، مثال‌ها و قالب‌ها

مدیریت چابک

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

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

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

مثالی از اپیک چابک

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

اپیک ما می‌تواند «پرتاب موشک توریستی به فضای در ماه مارس ۲۰۵۰» باشد و شامل داستان‌هایی برای کارهای روتین و همینطور داستان‌هایی برای بهبود ابعاد مختلف پرتاب موشک و شاتل می‌شود: از مشتریان که بلیت‌های سفر فضایی ما را می‌خرند تا پرتاب خود موشک. به این ترتیب، چندین تیم مشغول کار روی داستان‌های مختلف هستند و همگی به سمت تحقق یک اپیک واحد حرکت می‌کنند.

درک اپیک‌ها در یک برنامه چابک کامل

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

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

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

ساخت یک اپیک چابک

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

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

کالبدشکافی یک اپیک در مدیریت چابک

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

نقش کاربر یا پرسونا – یک داستان منحصر به فرد برای پرسونای هر کار خود بسازید – به عنوان مثال می‌توان به «لاگین سریع‌تر برای کاربران تازه‌وارد» یا «لاگین سریع‌تر برای مشتریان که بازگشته‌اند» اشاره کرد.

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

فرهنگ – اجازه دهید نرم‌های تیمی دیکته‌کننده این باشند که داستان باید سریعا انجام شود یا پروژه‌ای یک هفته‌ای باشد.

زمان – یک مانع روانی دیگر را نیز از پیش روی تیم برداشته و داستان‌هایی طراحی کنید که می‌توانند در بازه زمانی واقع‌گرایانه به پایان برسند.

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

داستان‌های کاربر: معنا، مثال‌ها و قالب‌ها

مدیریت چابک

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

ممکن است به داشتن این ذهنیت وسوسه شوید که داستان‌های کاربر در واقع پیش‌نیازهای سیستم نرم‌افزاری هستند، اما این‌طور نیست.

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

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

داستان‌های کاربر چه هستند؟

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

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

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

چرا باید به خلق داستان‌های کاربر پرداخت؟

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

داستان‌های کاربر چندین مزیت کلیدی به همراه می‌آورند:

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

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

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

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

کار کردن با داستان‌های کاربر

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

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

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

چطور داستان‌های کاربر را بنویسیم؟

هنگام نوشتن داستان‌های کاربر به نکات زیر توجه نشان دهید:

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

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

قالب و مثال‌های داستان کاربر

داستان‌های کاربر معمولا با جملات ساده نوشته شده و ساختاری مشابه آنچه در پایین آمده دارند:

«به عنوان یک [پرسونا]، من [می‌خواهم که…]، تا…»

بیایید این ساختار را کالبدشکافی کنیم:

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

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

تا: تمایلات آنی ‌آن‌ها برای انجام یک کار چطور با تصویر کلی پروژه سازگاری می‌یابد؟ آنچه آن‌ها به دنبالش هستند چه مزایایی به همراه می‌آورد؟ مشکل بزرگی که باید برطرف شود چیست؟

برای مثال داستان‌های کاربر می‌توانند چنین شکل و شمایلی داشته باشند:

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

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

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

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

آغاز به کار با داستان‌های کاربر

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

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

امتیازهای داستانی و تخمین‌ها

مدیریت چابک

 

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

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

همکاری با صاحب محصول

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

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

تخمین چابک ورزشی تیمی است

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

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

امتیازهای داستانی در برابر ساعات

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

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

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

هوشمندانه تخمین بزنید، نه سخت

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

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

از تخمین‌های قبلی بیاموزید

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

مثل هر کار دیگری در مدیریت چابک و مدرن، تخمین‌ها هم تمرینی دائمی می‌طلبند و هرچه زمان بگذرد، مهارت بیشتری در ارائه آن‌ها به دست خواهید آورد.

۵ معیار مدیریت چابک که عاشق آن‌ها می‌شوید

مدیریت چابک

 

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

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

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

کسب‌وکار خود را بشناسید

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

معیارهای کسب‌وکار باید ریشه در نقشه راه شرکت یا سازمان دوانده باشند.

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

حالا چطور از معیارهای چابک برای افزایش بهینگی استفاده کنیم؟

چارت Burndown برای بازه‌های «تاخت»

چارت برن‌داون در مدیریت چابک

تیم‌های چابک، کار توسعه را در بازه‌های زمانی مشخصی پیش می‌برند که تحت عنوان «تاخت» (یا Sprint) شناخته می‌شوند. همینطور که دورنمای بازه تاخت تنظیم می‌شود، تیم به پیش‌بینی این می‌پردازد که در بازه مورد اشاره به چه میزان زمان نیاز دارد. سپس یک گزارش Burndown تولید می‌شود که میزان کارهای انجام شده در بازه تاخت را پایش می‌کنند. محور X نشان‌دهنده زمان و محور Y نشان‌دهنده میزان کاری است که باقی مانده و هردو یا براساس امتیازهای داستانی و یا ساعات کاری سنجیده می‌شوند. هدف غایی این است که تمام کارهای پیش‌بینی شده تا پیش از پایان بازه تاخت به اتمام برسند.

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

ضد الگوهایی که باید به آن‌ها دقت کنید:

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

چارت‌های Release Burndown و Epic Burndown

اپیک برن‌داون در مدیریت چابک

چارت‌های Epic Burndown و Release Burndown به پایش پیشرفت رویه توسعه براساس بدنه‌ای بزرگ‌تر از Sprint Burndown می‌پردازند و توسعه را در تیم‌های متکی بر اسکرام و کانبان پیش می‌برند. از جایی که یک برهه تاخت (برای تیم‌های اسکرام) ممکن است حاوی کار روی چندین اپیک و ورژن مختلف باشد، لازم است که مقدار پیشرفت هر بازه تاخت و همینطور هر اپیک و هر ورژن پایش شود.

در این بین با پدیده‌ای به نام «Scope Creep»‌ هم روبه‌رو هستیم، یعنی تزریق پیش‌نیازهای بیشتر به پروژه‌ای که پیشتر تمام ابعاد آن تعیین شده است. برای مثال اگر یک تیم مشغول توسعه وب‌سایتی تازه برای شرکت باشد، شخصی که Scope Creep نام دارد بعد از تعیین تمام پیش‌نیازها و الزامات، به ناگاه خواستار قابلیت‌های جدید می‌شود. اگرچه تحمل کردن Scope Screep در برهه تاخت رویکردی اشتباه است، اما تغییر ابعاد اپیک‌ها و ورژن‌ها، پیامدی طبیعی در مدیریت چابک به حساب می‌آید. همینطور که تیم پروژه را بیشتر پیش می‌برد، صاحب محصول ممکن است بسته به آنچه آموخته شده، وظایف جدید اضافه کرده یا از شمار آن‌ها بکاهد. چارت‌های Release Burndown و Epic Burndown باعث می‌شوند همه از بالا و پایین‌های کار باخبر باشند.

چارت شتاب

چارت شتاب در مدیریت چابک

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

بیایید فرض کنیم صاحب محصول می‌خواهد ۵۰۰ امتیاز داستانی انباشت شده را به پایان برساند. می‌دانیم که تیم توسعه معمولا در هر سیکل ۵۰ امتیاز داستانی را به پایان می‌رساند. صاحب محصول می‌تواند به شکلی منطقی فرض کند که تیم حدودا نیازمند ۱۰ سیکل است تا به تمام وظایف رسیدگی کند.

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

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

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

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

چارت کنترل

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

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

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

دیاگرام جریان فزاینده

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

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

معیارهایی حتی بیشتر

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

  • چند عیب در کار یافتیم؟
    حین توسعه…
    بعد از عرضه و رساندن محصول به دست مشتریان…
    توسط اعضای بیرون از تیم توسعه…
  • برطرف‌سازی چند عیب قرار است تا عرضه‌های بعدی به تعویق بیفتد؟
  • چه میزان درخواست پشتیبانی مشتری دریافت می‌کنیم؟
  • درصد پوشش تست‌های اتوماتیک چقدر است؟

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

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

چارت گانت چیست؟

Gantt chart

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

تاریخچه کوتاه چارت گانت

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

از چارت گانت برای چه کاری استفاده می‌شود؟

مدیران پروژه به سه دلیل اصلی از چارت‌های گانت استفاده می‌کنند:

ساخت و مدیریت یک پروژه فراگیر

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

تعیین لجستیک‌ها و وابستگی‌های میان وظایف

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

پایش پیشرفت پروژه

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

مزایای استفاده از چارت گانت

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

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

چارت‌های گانت می‌توانند ابزاری قدرتمند هم برای متدولوژی آبشاری و هم مدیریت چابک باشند.

مدیریت آبشاری

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

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

مدیریت چابک

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

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

استفاده از چارت‌های گانت

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

مدیریت برنامه در مقابل مدیریت پروژه

مدیریت چابک

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

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

معرفی فیلم‌های آموزش مبانی توسعه نرم‌افزاری Agile (چابک)

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

این مجموعه آموزشی در ۱۰ درس ارائه می‌شود. در درس اول تا سوم با مفاهیم کلی مدیریت چابک، تاریخچه پیدایش Agile و ارزش‌ها و اصول بنیادین آن آشنا خواهید شد. درس چهارم و پنجم بر توصیف مزایای اجایل و رویکرد اسکرام اختصاص می‌یابند. درس پنجم شما را به شکلی بنیادین با مفهوم Extreme Programming آشنا می‌کند. درس هفتم به صورت جامع مفاهیم کانبان، اسکرام بان، اسکرام و XP را در بر می‌گیرد و در درس هشتم نیز با داستان‌های کاربر و روش‌های استفاده از آن‌ها آشنا می‌شود. درس نهم با تمرکز بر تخمین در رویکرد Agile پیش می‌رود و در درس دهم هم تمرین‌هایی عملی دریافت خواهید کرد تا دانشی که در حوزه مدیریت چابک به دست آورده‌اید مورد آزمایش قرار بگیرد.

  • برای دیدن فیلم‌‌‌های آموزش مبانی توسعه نرم‌افزاری Agile (چابک) + اینجا کلیک کنید.

مدیریت برنامه چیست؟

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

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

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

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

پروژه‌ها چنین ویژگی‌هایی دارند:

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

برنامه‌ها چنین ویژگی‌هایی دارند:

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

مدیر برنامه چه می‌کند؟

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

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

ارزیابی وضعیت سبد محصولات

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

مدیریت ریسک‌ها

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

به اجرا در آوردن برنامه

مدیران برنامه وظیفه دارند یک برنامه را به اجرا در آورند که خود شامل این موارد است:

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

تعامل با سهام‌داران

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

پالایش مدل عملیاتی

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

مدیر پروژه چه می‌کند؟

یک روز کاری عادی برای مدیر محصول شامل چنین کارهایی می‌شود:

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

اگر این مطلب برای شما مفید بوده است، آموزش‌ها و مطالب زیر نیز به شما پیشنهاد می‌شوند:

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

بر اساس رای 2 نفر

آیا این مطلب برای شما مفید بود؟

نظر شما چیست؟

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