کانبان چیست؟
اگرچه کانبان امروزه در میان تیمهای نرمافزار و DevOps طرفداران زیادی دارد، اما روش کار آن به بیش از 50 سال قبل بازمیگردد. در اواخر دهه 1940 تویوتا شروع به بهینه سازی فرآیندهای مهندسی خود بر اساس همان مدلی کرد که فروشگاه ها برای انبار قفسههای خود استفاده می کردند. فروشگاه ها برای پاسخگویی به تقاضای مصرف کننده، محصول را در انبار نگهداری میکنند، این کار که جریان بین فروشنده و مصرف کننده را بهینه میکند. از آنجا که میزان موجودی با الگوهای مصرف مطابقت دارد، فروشنده میتواند موجودی را طوری مدیریت کند که همواره در انبار موجود باشد. به این ترتیب در عین این که موجودی اضافه از محصول نگهداری نمیشود، تقاضای خریدار هم هیچ وقت بی پاسخ نمی ماند.
زمانی که تویوتا از همین سیستم در کارخانه خود استفاده کرد، هدف این بود که سطح موجودی خود را با مصرف مواد اولیه هماهنگ کند. برای برقراری ارتباط بین موجودی، تقاضا و تولید، کارگران یک کارت یا کانبان را بین تیم ها به اشتراک میگذاشتند. هنگامی که یک سطل از مواد مورد استفاده در خط تولید خالی می شد، یک کانبان به انبار ارسال میشد که در آن مواد مورد نیاز، مقدار دقیق این مواد و غیره شرح داده شده بود. انبار کانبان را برای تامین کننده ارسال می کرد. تامین کننده هم یک سطل از مواد اولیه موردنیاز خط تولید را در صف انتظار نگه می داشت تا به انبار ارسال کند.
تکامل فرایند کانبان از دهه ۱۹۴۰ آغاز شده بود، اما در آغاز قرن بیست و یکم، شرکتهای فعال در صنعت نرم افزار دریافتند که کانبان چگونه میتواند شیوه ارائه محصولات و خدمات را در جهت مثبت تغییر دهد. کانبان با تمرکز بیشتر بر کارایی و با بهرهگیری از پیشرفتها در فناوری محاسبات، قلمرو صنعت خودرو را ترک کرد و جایگاه خود را در سایر بخشهای تجاری مانند فناوری اطلاعات، توسعه نرمافزار، تحقیق و توسعه و غیره پیدا کرد.
آنچه ما اکنون به عنوان روش کانبان می شناسیم، در ابتدای سال ۲۰۰۷ پدیدار شد. این روش نتیجه سال ها آزمایش، تجربه و تلاش مشترک چهرههای برجسته جامعه چابک مانند دیوید اندرسون، دن وکانتی، دارن دیویس، کوری لاداس، دومینیکا دیگراندیس، ریک گاربر و دیگران بود.
طبق تعریف کانبان بلاگ، کانبان یک تکنیک برای مدیریت یک پروسه توسعه نرم افزاری با استفاده از روشی با اثربخشی بالاست. زیربنای روش کانبان، سیستم تولید همزمان (just-in-time) کمپانی تویوتا است. هرچند که توسعه نرم افزار یک فعالیت خلاقانه و مبتکرانه اسست و با تولید انبوه اتومبیل تفاوتهای بنیادی دارد، اما با این حال مکانیزم پایه برای مدیریت خط تولید، میتواند بر روی آن پیاده سازی شود. اما روش کانبان چگونه کار میکند؟ با ما همراه باشید.
اصطلاحات کانبان که باید بدانید
به نظر می رسد کانبان راه ساده ای برای بهبود فرآیندهای کاری شما باشد، اما این روش در واقع چیزی بیش از تجسم کار شما است. اگر می خواهید از این روش بیشترین بهره را ببرید، باید به جزئیات توجه کنید و با اصطلاحات و مفاهیم پایه کانبان آشنا شوید. در ادامه لیستی از اصطلاحات تخصصی کانبان را ذکر میکنیم که برای شروع کار به شما کمک میکند.
تابلوی کانبان یا Kanban Board
تابلوی کانبان یکی از اجزای کلیدی این روش و جایی است که شما تمام کارها را به تصویر میکشید. برد کانبان باید به حداقل ۳ ستون (یا بیشتر) تقسیم شود. هر ستون نماینده مرحله ای که است کار در آن قرار دارد. تابلوی کانبان میتواند فیزیکی باشد و یا به صورت دیجیتالی در نرم افزارهای مخصوص این کار ایجاد شده باشد.
کارت کانبان یا Kanban Cards
کارتهای کانبان نشان دهنده کارها و وظایف مختلف است که به مرور زمان در تابلوی کانبان حرکت میکنند و به ستون بعدی منتقل میشوند. کارت ها حاوی جزئیات مهمی مانند شرح، مهلت، اندازه، مسئول و غیره هستند. کارت کانبان هم مانند برد، ممکن است فیزیکی یا دیجیتالی باشد.
ستونهای کانبان یا Kanban Boards
برد کانبان را به صورت عمودی تقسیم میکنند و هر یک از آنها مرحله متفاوتی از گردش کار را نشان میدهد. هر برد کانبان دارای ۳ ستون پیش فرض است: کارهایی که باید انجام شوند، کارهای در حال انجام و کارهای انجام شده که نشان دهنده مراحل مختلف فرآیند است. ممکن است ستون چهارمی با نام بازبینی که به تابلوی کانبان اضافه شود.
خطوط جداکننده یا Swimlanes
خطوط افقی تابلوی کانبان را به نوارهای افقی تقسیم میکند. افراد درگیر در یک پروژه کانبان، از خطوط جداکننده برای جداسازی بصری انواع مختلف کار روی یک تخته و سازماندهی وظایف همگن با هم استفاده میکنند.
زمان چرخه یا Cycle Time
زمان چرخه زمانی شروع میشود که یک کار جدید وارد مرحله در حال انجام گردش کار میشود و یک فرد یا تیم، کار کردن بر روی آن کار را شروع میکند.
زمان سررسید یاLead Time
زمان سررسید از لحظه ای که یک کار جدید در ستون اول برد کانبان قرار میگیرد، شروع میشود و با وارد شدن کار به ستون آخر و خروج آن از سیستم، به پایان می رسد.
توان عملیاتی یا Throughput
توان عملیاتی با تعداد موارد کاری که در یک دوره معین از یک سیستم یا فرآیند عبور میکنند، سنجیده میشود. توان عملیاتی یک شاخص کلیدی است که نشان میدهد تیم شما در طول زمان چقدر کارآمد است.
کارهای در حال انجام یا Work in Progress (WIP)
این شاخص نشان دهنده مقدار کاری است که در حال حاضر روی آن کار میکنید و هنوز تمام نشده است.
محدودیت کردن کارهای در حال انجام یا WIP limits
محدود کردن کار در حال انجام به معنای محدود کردن تعداد وظایفی است که تیم شما میتواند به طور همزمان روی آنها کار کند تا از بارگذاری بیش از حد یا تاخیر در تحویل پروژه جلوگیری شود.
روش کانبان چطور کار میکند؟
روش کار کانبان را با یک مثال واقعی بررسی میکنیم: فرض کنید یک پروژه به شما واگذار شده است. صرف نظر از ماهیت، حجم و زمان در اختیار، اولین گام برای انجام پروژه این است که کارهایی را که باید انجام شوند، تعیین کنید و هر یک از این کارها را به یک فرد یا تیم واگذار کنید. در روش کانبان برای هر پروژه یک برد با چهار ستون در نظر گرفته میشود: کارهایی که باید انجام شوند، کارهایی که در حال انجام شدن هستند، کارهایی که در حال بازبینی هستند و کارهایی که انجام شدهاند.
در ابتدا تمام کارهایی که باید انجام شوند، بر روی کاغذهای یادداشت نوشته میشوند و در ستون اول قرار میگیرند. اگر حین اجرای روش کانبان متوچجه شدید که یکی از کارها از قلم افتاده، میتوانید آن راغ به لیست اضافه کنید؛ این کار خللی به اجرای کانبان وارد نمیکند. در مرحله بعد، هر کار به یک فرد یا تیم واگذار میشود .و به ستون کارهای در حال انجام منتقل میشود. برای جلوگیری از بی نظمی، میتوانید برای هر فرد یا تیم، از یک رنگ استفاده کنید. هر فرد یا تیم پس از به پایان رساندن یک کار، کارت مربوط به آن را به ستون بازبینی منتقل میکند.
فردی که برای نظارت بر پروژه انتخاب شده، پس از تایید کیفیت کار، کارت آن را به ستون انجام شده منتقل میکند. انتقال کارت از ستون بازبینی به ستون انجام شده، نشان میدهد که کار موردنظر انجام شده و کیفیت آن هم مورد تایید ناظر پروژه قرار گرفته است. در پروژههای ساده تر ممکن است مرحله بازبینی حذف شود. استفاده از برد برای روش کانبان، به مدیر پروژه امکان میدهد که در هر لحظه از اجرای پروژه، بتواند با نگاه کردن به برد، روند پیشرفت پروژه را ارزیابی کند و در صورت نیاز، با افزایش زمان یا نیروی کار، اطمینان حاصل کند که پروژه در زمان مقرر به پایان می رسد.
اسکرام یا کانبان؟ مسئله این است!
وقتی روش کانبان را در مقابل مدیریت پروژه چابک قرار دهیم، یادآوری این نکته مهم است که روش کانبان تنها یکی از انواع مدیریت چابک است. این روش یکی از چهارچوبهای چابک است که برای پیاده سازی توسعه نرم افزار چابک به کار میرود.
مهمترین تفاوت بین کانبان و اسکرام این است که اولی یک روش است، در حالی که دومی یک چارچوب است. کانبان یک مدل تحویل مستمر ایجاد میکند، در حالی که اسکرام کار را در اسپرینتها سازماندهی میکند. این که کدام روش را اجرا میکنید، به ماهیت فرآیند شما بستگی دارد؛ اما به طور کلی میتوان گفت که کانبان یک رویکرد مناسب ارائه میدهد، در حالی که اسکرام بر قوانین از پیش تعیین شده متکی است. یکی دیگر از مشخصههای اصلی تمایز بین این دو، طرز فکر و سیستمهای اعتقادی بنیانگذار اسکرام و کانبان است.
کانبان و اسکرام از لحاظ ساختار تیم اجرایی هم با هم تفاوت بنیادی دارند. در متدولوژی اسکرام، سه نقش اصلی وجود دارد که حتما باید در ساختار تیم تعریف شده باشند: مالک محصول، مدیر اسکرام و تیم توسعه. در مقابل، کانبان در قبال ساختار تیم بسیار انعطاف پذیر است. دو نقش اصلی مدیر درخواست خدمات و مدیر تحویل خدمات در روش کانبان قابل تعریف هستند، اما با این حال تعریف این دو نقش هم به هیچ وجه ضروری نیست و میتوان کانبان را در هر ساختاری اجرا کرد.
موضوع دیگر در تفاوت کانبان و اسکرام، اصول برنامه ریزی است. در اسکرام بازههای زمانی مشخصی در نظر گرفته می شود و کارهایی که در این بازه باید انجام شوند، از قبل تعریف می شوند. اما در کانبان برای هر کار، زمان آغاز و پایان تعریف می شود و به محض این که عضو تیم، کار موردنظر را به ستون انجام شده منتقل کند، میتوان از این ظرفیت آزاد برای شروع کار دیگری استفاده کرد.
سیستم کانبان چیزی بیش از چسباندن چند یادداشت روی تابلو است. ساده ترین راه برای درک کانبان این است که فلسفه آن را بپذیرید و آن را در امور روزانه خود به کار ببرید. عمل کردن به اصول کانبان از جمله تجسم گردش کار، تعیین محدودیتهای WIP، مدیریت جریان، اطمینان از سیاستهای صریح و بهبود مستمر، باعث می شود روند کار فراتر از تصورات شما بهبود یابد. به یاد داشته باشید که حلقههای بازخورد منظم را سازماندهی کنید، و همه این قطعات در کنار هم قدرت واقعی کانبان را آشکار خواهند کرد.
اسپرینتها یکی از کلیدیترین اجزای روش اسکرام هستند. همانطور که در مقاله همه چیز در مورد روش اسکرام گفتیم، اسپرینت یک دوره زمانی از پیش تعریف شده است که در آن تیمهای چابک برای رسیدن به یک هدف مورد توافق، با یکدیگر همکاری میکنند. در طول یک اسپرینت، پنج نوع جلسه برگزار میشود که برای اطمینان از موفقیت فرآیند چابک، حیاتی هستند. جلسات چابک با هدف ایجاد و تقویت هماهنگی بین اعضای تیم، رهبران و ذینفعان برگزار میشوند. پس ماحصل این جلسات، نقش حیاتی در موفقیت فرایند پروژه دارد.
در ادامه مقاله دیگر آوات در مورد مدیریت موثر جلسات مجازی در دورکاری، این مقاله را به انواع جلسات چابک اختصاص دادهایم. در یک نگاه کلی این جلسات، برنامهریزی برای اسپرینت (Sprint Planning)، جلسههای روزانه (Daily Standups)، مرور اسپرینت گذشته (Sprint Review) و جلسات گذشته نگر (Sprint Retrospectives) را شامل میشوند. در ادامه در مورد نوع دیگری از جلسه به نام شفافسازی اقلام بک لاگ (backlog refinement) نیز توضیحاتی ارائه خواهیم داد.
جلسات چابک در مقابل جلسات اسکرام
اسکرام یکی از روشهای مدیریت پروژه چابک است که بیشتر در پروژههای تولید یا توسعه نرمافزار استفاده میشود. جلسات اسکرام از نظر فنی، نوعی از جلسات چابک هستند؛ اما دارای پارامترهای خاصتری هستند که متناسب با چارچوب اسکرام طراحی شدهاند. این فرآیند حول محور یک اسپرینت ۲ تا ۴ هفتهای می چرخد که صاحب محصول، مدیر اسکرام و اعضای تیم اسکرام در آن حضور دارند.
به زبان ساده میتوان گفت اسکرام نسبت به اجایل، چارچوبهای جدیتر و پیچیدهتری دارد. فرآیند چابک و اسکرام تقریباً یکسان هستند؛ با این تفاوت که در اسکرام، انعطافپذیری بیشتری برای تنظیم چارچوب زمانی اسپرینت و تطبیق فرآیند اسکرام وجود دارد. روش اسکرام از اصول چابک پیروی می کند، اما شامل تعاریف و مشخصات بیشتری است، خصوصا در مورد برخی از روش های توسعه نرم افزار. در ادامه جلسههای اسکرام و اجایل را به تفصیل شرح میدهیم.
معرفی انواع جلسات چابک
در روش اجایل پنج نوع جلسه وجود دارد: برنامهریزی اسپرینت، جلسه روزانه یا دیلی، بررسی اسپرینت و جلسات گذشتهنگر. هر اسپرینت با یک جلسه برنامهریزی یا پلنینگ شروع میشود. به علاوه در هر روز کاری، یک جلسه روزانه هم برگزار میشود. در نهایت در پایان هر اسپرینت، جلسهای برای بررسی و مرور آن برگزار میشود و مشکلات اسپرینت قبلی، در یک جلسه گذشته نگر شناسایی میشود. این فرآیند بارها تکرار میشود تا پروژه به پایان برسد یا محصول به بازار یا مشتری ارائه شود.
جلسه برنامه ریزی اسپرینت
جلسه برنامهریزی یا پلنینگ قبل از شروع هر اسپرینت برگزار میشود و همه اعضای تیم را درگیر میکند. در برنامهریزی اسپرینت، کل تیم گرد هم میآیند تا در مورد این که کدام وظایف کاری باید تا پایان اسپرینت جاری تکمیل شوند، بحث و تبادل نظر کنند. در طول جلسه، اهداف اسپرینت تعیین میشوند و اعضای تیم بر اساس انتظارات مدیر محصول، با هم هماهنگ میشوند. اشتباهاتی که ممکن است در جلسه برنامه ریزی اسپرینت رخ بدهند، به شرح زیر است:
جلسه روزانه
جلسه روزانه یا دیلی در همه روزهای کاری اسپرینت برگزار میشود. این جلسه تضمین میکنند که اعضای تیم در مسیر درست گام برمیدارند و به آنها کمک میکند تا هر گونه تنگنای احتمالی را برطرف کنند. در فرآیند اسکرام، این جلسه ممکن است جلسه اسکرام روزانه نیز نامیده شود. این جلسات فرصتی برای اعضای تیم هستند تا درباره کارهایی که روز قبل تکمیل شده و کارهایی که قرار است در ۲۴ ساعت آینده انجام شوند، صحبت کنند. هدف این جلسه پاسخ به سه سوال مهم است:
در این جلسه ها مشخص میشود که چرا برنامهریزی روز قبل تکمیل نشده و چه عاملی باعث بروز تاخیر شده است. همچنین مشخص میشود که اعضای تیم چگونه میتواند برای حل مشکلاتی که مانع از پیشبرد کار میشود، با هم همکاری کنند.
جلسه دیلی کوتاه و دقیق است و قرار نیست وقت زیادی از اعضای تیم بگیرد، آنقدر کوتاه که اغلب توصیه میشود شرکت کنندگان در طول جلسه بایستند! به همین دلیل در زبان انگلیسی به جلسات روزانه، standup هم گفته میشود. معمولا در مورد زمان برگزاری جلسه از قبل تصمیم گیری میشود تا همه اعضا بتوانند برای شرکت در آن برنامهریزی کنند. اشتباهات جلسه روزانه که باید از آنها اجتناب کنید عبارتند از:
جلسه بررسی اسپرینت
یکی دیگر از جلسات چابک جلسه بررسی اسپرینت یا ریویو است. این جلسه فرصتی برای تیم است تا کارهای انجام شده در طول اسپرینت را برای ذینفعان به نمایش بگذارد و از آنها بازخورد انتقادی دریافت کند. این جلسه ممکن است یک ارائه داخلی و غیررسمی بین اعضای تیم اجرایی باشد یا یک ارائه رسمیتر با حضور مشتری؛ تصمیمگیری در مورد حاضران در جلسه، به نیازهای پروژه بستگی دارد. اشتباهاتی که ممکن است در جلسه بررسی اسپرینت رخ دهند، در ادامه شرح می دهیم:
جلسه گذشته نگر اسپرینت
جلسه گذشته نگر یا رترو بخش مهمی از فرآیند چابک است. این جلسه در پایان هر اسپرینت برگزار میشود و کل تیم را گرد هم میآورد تا فرآیندهای اسپرینت قبلی را ارزیابی کنند و در مورد چگونگی بهبود فرایندها در اسپرینتهای بعدی بحث کنند. به اعضای تیم اجازه میدهد تا در مورد اینکه چه مواردی نیاز به اصلاح یا تغییر مسیر دارند، بحث کنند. جلسه گذشته نگر به اعضای تیم اجازه میدهد تا در مورد اینکه چه مواردی نیاز به اصلاح یا تغییر مسیر دارند، بحث کنند.
در جلسات گذشته نگر به این سوالات پاسخ داده میشود: کدام جنبههای اسپرینت پیشرفت خوبی داشته و چه چیزی میتوانید از این موفقیت بیاموزید؟ چه مواردی نیاز به بهبود داشته و تیم به چه مشکلاتی برخورد کرده است؟ در اسپرینتهای بعدی چه کارهایی را میتوان بهتر انجام داد؟ از آنجایی که مدیریت پروژه چابک حول محور یادگیری و تکرار می چرخد، پس از هر اسپرینت باید درسهایی از جنبههای مثبت و منفی آن آموخت. اشتباهاتی که ممکن است در جلسات گذشته نگر مرتکب شوید، عبارتند از:
جلسه شفاف سازی اقلام بک لاگ
جلسه شفاف سازی یا ریفاین، با تعیین مواردی که بیشترین تأثیر را در اسپرینت بعدی دارند، بک لاگ را برای برنامهریزی اسپرینت آماده میکند. در طول شفاف سازی بک لاگ، صاحب محصول اطمینان میدهد که اقلام بکلاگ محصول، حاوی اطلاعات کافی، جزئیات و اولویتبندی هستند تا تیم با یک تصمیمگیری هوشمندانه بتواند با آنها مقابله کند. خطاهای جلسه بک لاگ ریفاینمنت به شرح زیر است:
کلام آخر
بر اساس نتایج پژوهشهای انجام شده، پروژههایی که از روشهای چابک استفاده میکنند، ۲۸ درصد موفقتر هستند و تقریباً ۷۱ درصد از سازمانها، از اجایل با فرکانسهای متفاوت استفاده میکنند. اما چه چیزی اجایل را تا این حد موفق میکند و چرا مدیران پروژه از آن در ترکیب با سایر چارچوبها استفاده میکنند؟ تنها به یک دلیل ساده: اجایل کار مدیران را آسان میکند و به آنها اجازه میدهد تا کنترل بیشتری بر پروژههای خود داشته باشند.
آنچه مدیریت روش اجایل را منحصربهفرد میکند، این است که بر دو عامل کلیدی تمرکز دارد و هیچکدام را فدای دیگری نمیکند؛ ارائه پروژه با کیفیت بالا، و تکمیل پروژه در چارچوب محدودیتهای زمانی و مالی. در مقاله دیگری در مورد مزایای مدیریت پروژه به روش اجایل نوشتهایم که شاید خواندن آن برای شما مفید باشد. کتاب اسکرام و اکس پی ساده شده هم گزینه خوبی برای آشنایی بیشتر با روش اسکرام است.
منبع: EASY AGILE
اگر در کسب و کار خود از روش اجایل استفاده میکنید، ممکن است در مورد این که اسپرینت پیش رو باید شامل کدام یوزر استوری ها باشد، دچار تردید شده باشید. اهمیت این انتخاب به این دلیل است که خطا در انتخاب یوزر استوری ها، میتواند دستاوردهای یک اسپرینت را تا حد زیادی کاهش دهد. به همین دلیل آشنایی با تکنیکهای اولویت بندی بک لاگ محصول، در روش اجایل اهمیت زیادی دارد.
تکنیکهای مختلفی برای اولویت بندی بک لاگ محصول وجود دارد. ما در این مقاله روش اولویت بندی مسکو را شرح میدهیم. در مقالههای دیگر آوات در مورد روش اجایل و اسکرام نوشته ایم. برای مطالعه بیشتر در این زمینه مقالههای دیگر آوات با عنوان متدولوژی اسکرام و مزایای آن و ۸ مزیت استفاده از اجایل را مطالعه کنید.
روش اولویت بندی مسکو دقیقاً چیست؟
روش اولویت بندی مسکو یکی از تکنیک هایی است که به منظور اولویت بندی بک لاگهای محصول از آن استفاده میشود. مسکو در واقع شامل حروف اول نام چهار دسته از نیازمندی ها یا اولویتهای ما است: Must have، Should have،Could have و Won’t have. عدهای هم حرف W را به کلمه Wish به معنای آرزو ربط میدهند. جزئیات این روش را میتوانید در کتابچه راهنمای روش توسعه سیستم پویا (DSDM) ببینید. برای مشاهده کتابچه به سایتAgile Business مراجعه کنید.
این روش توسط یک متخصص نرم افزار به نام Dai Clegg ایجاد شد. او چارچوبی را طراحی کرد که به افراد تیمش در اولویت بندی وظایف، حین کار بر روی پروژههای توسعه محصول کمک می کرد. اما در حال حاضر روش مسکو توسعه یافته و از آن برای طیف وسیعی از پروژه ها استفاده میشود.
روش اولویت بندی مسکو چگونه کار میکند؟
قبل از اجرای روش MoSCoW لازم است چند اقدام زیرساختی انجام دهید. در گام اول باید تیم توسعه محصول و ذینفعان کلیدی، بر روی اهداف و عوامل اولویت بندی به توافق برسند. سپس باید در مورد این که کدام موارد در اولویت قرار دارند، مذاکره کنند و به نتیجه برسند. در این مرحله تیم اجایل باید در مورد چگونگی حل و فصل هر گونه اختلاف نظر در اولویت بندی هم صحبت کند. لازم است نحوه حل و فصل اختلافات را قبل از بروز آنها مشخص کنید. در نهایت، شما باید در مورد اینکه چه درصدی از منابع را میخواهید به هر دسته اختصاص دهید، به اجماع برسید.
دسته بندی اولویتهای روش مسکو
همانطور که گفتیم، مسکو در واقع شامل حروف اول نام چهار دسته از نیازمندی ها یا اولویتهای ما است : Must have، Should have، Could have و Won’t have. در ادامه هر کدام از این دستهبندیها را شرح میدهیم.
اولویتهای Must have
همانطور که از نام آن پیداست، این دسته شامل ابتکاراتی است که برای تیم شما ضروری هستند. اولویت هایی که در این دسته قرار میگیرند، شامل نیازهای غیر قابل مذاکره پروژه یا محصول شما هستند. اولویتهای ضروری، تیم را ملزم به انجام یک کار اجباری میکند. اگر مطمئن نیستید که چیزی به این دسته تعلق دارد یا نه، موارد زیر را از خود بپرسید که محصول بدون آن کار میکند یا نه. اگر پاسخ شما به این سوال منفی است، با یک اولویت Must have طرف هستید.
اولویتهای Should have
اولویتهای این دسته یک گام پایین تر از اولویتهای ضروری قرار میگیرند؛ یعنی اگرچه برای محصول یا پروژه ضرورت هستند، اما حیاتی نیستند. این موارد حتی اگر کنار گذاشته شوند، محصول یا پروژه همچنان کار میکند. هرچند وجود آنها معمولاً برای پروژه ارزش افزوده به همراه دارد.
اولویتهای Could have
یکی از راههای شناسایی اولویتهای این دسته در روش مسکو، این است که داشتن این اولویت ها خوب است، اما داشتن آنها برای محصول نهایی ضروری نیست. در عین حال اگر کنار گذاشته شوند، تاثیر آنها بر محصول نهایی کمتر از اولویت Sholud have است. بنابراین اگر مواردی که در دسته Must و Should قرار میگیرند بیشتر از حد انتظار باشند، اولین چیزی که کنار گذاشته میشود، مواردی هستند که در دسته Could have قرار میگیرند.
اولویتهای Won’t have
یکی از مزایای روش مسکو این است که مشخص میکند شما چه چیزی را در محصول نهایی پیاده سازی نخواهید کرد. مزیت این اولویت این است که مشخص میکند شما (در حال حاضر) چه انتظاراتی از محصول نهایی نباید داشته باشید، اگرچه ممکن است این اولویت ها در طول زمان از دسته Won’t have خارج شوند و در دستههای دیگر قرار بگیرند. برخی از مواردی که در این اولویت قرار میگیرند، در آینده اولویت بندی خواهند شد؛ در حالی که برخی دیگر اصلا پیاده سازی نمیشوند. میتوانید یک گروه بندی دیگر هم در نظر بگیرید و این دو نوع اولویت را از یکدیگر متمایز کنید.
روش اولویت بندی مسکو یک روش رایج و محبوب در میان مدیران محصول تیمهای اجایل است. با این حال گزینههای دیگری هم برای این منظور وجود دارد. انتظار میرود که به عنوان مدیر محصول به همه این روش ها تسلط داشته باشید و بسته به موقعیتی که تیم شما در آن قرار دارد، از روش مناسب برای اولویت بندی یوزر استوریهای بک لاگ محصول استفاده کنید. برای مطالعه مزایا و معایب استفاده از روش اولویتبندی مسکو به وبلاگ راهکار ابری آوات مراجعه کنید.
منبع: productplan
به دنبال شیوع کووید و تاثیرات آن بر تجارت جهانی، سازمانها در حال بازنگری اساسی در سبد محصولات و خدمات خود هستند، زنجیرههای تامین خود را از نو ایجاد میکنند و بازسازی سازمانی در مقیاس بزرگ و تحول دیجیتالی را با سرعت بیشتری دنبال میکنند. دنیای تجارت در دو سال گذشته تغییرات جدی را تجربه کرده که در شرایط عادی به چند سال زمان نیاز دارد؛ و از آنجا که دنیا منتظر ما نمیماند، لازم است همگام با این تحولات، به فکر تغییر باشیم. انچه در این فرایند اهمیت مییابد، مدیریت تغییر است.
اما مدیریت تغییر سنتی که اغلب با فرآیندهای پیچیده همراه است و به زمان زیادی نیاز دارد، چیزی نیست که ما به آن نیاز داریم. برای همراه شدن با این تغییرات باید هوشمندانه و چابک عمل کنیم و مسیر تغییر را در زمان کوتاهتری طی کنیم. در این مقاله با استفاده از اصول و فرآیندهای توسعه نرمافزار اجایل یا چابک، دستورالعمل مدیریت تغییر را بازآفرینی میکنیم تا با تسریع و سادهسازی این فرایند، از این بحران به سلامت عبور کنید. با آوات همراه باشید.
چشم انداز تغییر خود را اعلام کنید
اولین قدم در مدلهای رایج مدیریت تغییر، ایجاد احساس فوریت است، اتفاقی که در سال 2020 به دنبال شیوع کووید رخ داد. بسته به میزان تغییری که در نظر دارید، میتوانید چشم اندازی را که ترسیمکننده وضعیت مطلوب شما است، تبیین کنید. این چشم انداز شامل اصول و ارزشهایی است که موضع شما در قبال تغییر را مشخص میکنند. در ترسیم این چشم انداز، به جزئیات توجه کنید؛ اما در عین حال در نظر داشته باشید که باید بتوانید به تعهداتی که در چشمانداز تغییر خود اعلام کردهاید، عمل کنید.
حرکت سریع به این معنی است که همه کارکنان نمیتوانند با شما همراه شوند و چشم انداز تغییر شما هم ایراداتی خواهد داشت. اما این چشم انداز با وجود همه ایراداتی که دارد، مشخص میکند که کجا ایستادهاید، به حدسها و گمانها پایان میدهد و برای توسعه برنامههایتان، برای شما زمان میخرد. ترسیم این چشم انداز به شما کمک میکند تا زمان و انرژی لازم برای مدیریت تغییر را در مسیر درست هدایت کنید.
از رسانههای اجتماعی برای افزایش مشارکت کارکنان استفاده کنید
برای سازمانهایی که به صورت مجازی فعالیت میکنند، رسانههای اجتماعی داخلی و پلتفرمهای همکاری، سریعترین و مؤثرترین راه درک تلاشهای شما برای مدیریت تغییر و به کارگیری افرادی هستند که از این تحول حمایت میکنند. اگر مدیرعامل یا سایر مدیران شما در این پلتفرمها فعال نیستند، به آنها کمک کنید تا تغییر رویه بدهند.
کانالهای اجتماعی غیررسمی برای شما و سازمانتان اعتبار ایجاد میکنند و امکان گفتگوی دوطرفه را هم فراهم میکنند. با همکاری کارمندهای تاثیرگذار (اینفلوئنسر) مکالمه آنلاین پیرامون مدیریت تغییر را آغاز کنید و با همراه کردن سایر کارکنان، یک جامعه مجازی برای هدایت افکار و اندیشهها ایجاد کنید.
رویکرد آزمون و یادگیری را بپذیرید
رویدادهای اخیر بر حقیقتی که بسیاری از مدیران از قبل میدانستند، صحه گذاشته است: اگرچه تبیین چشمانداز تغییر برای ایجاد مشارکت بین افراد بسیار مهم است، اما این چشم انداز از شروع یک پروژه تغییر تا پایان آن، به ندرت ثابت میماند. حتی در پروژههای کوتاهمدت هم باید به صورت مستمر نوسانات داخل و خارج از سازمان را مدنظر قرار داد. با توجه به این حقیقت، مدیران تغییر باید اقداماتی را انجام دهند که در ادامه شرح میدهیم:
اگر کسی که به شما بگوید یک راه میانبر برای دستیابی به اهداف مدیریت تغییر در یک شب پیدا کرده است، بدون شک دروغ می گوید! اما با این حال راههایی برای تسریع تغییر در دنیای سریع و نامطمئن امروز وجود دارد؛ راههایی که شرکتهای معتبر و موفق بینالمللی آن را کشف کردهاند. این شرکتها تغییر را پیشبینی میکنند، در جستجوی فرصتها هستند، خلاءهای توانایی افراد را به سرعت پر کنند و به سرعت تیمهایی را برای حل چالش موجود مستقر کنند.
پذیرش رسمی اجایل ممکن است برای سازمان شما مناسب باشد، شاید هم نباشد؛ اما اکنون زمان آن رسیده است که دریابید چگونه میتوانید مدیریت تغییر را سریعتر و قدرتمندتر انجام دهید. در حال حاضر تنها از یک موضوع میتوانیم اطمینان داشته باشیم و آن این است که تغییرات بیشتری در راه است! متن کامل مقاله را در وبلاگ آوات مطالعه کنید.
منبع: harward business review
متدولوژی اسکرام یکی از روشهای مدیریت پروژه چابک است که در توسعه نرمافزار بر اساس فرآیندهای تکراری و افزایشی کاربرد دارد. اسکرام یک چارچوب چابک سازگار، سریع، انعطافپذیر و موثر است که به منظور ارائه ارزش به مشتری در طول توسعه پروژه طراحی شده است. هدف اولیه اسکرام، پاسخگویی به نیازهای مشتری در محیطی شفاف، تقسیم کار صحیح و پیشرفت مستمر است. توسعه، از یک ایده کلی در مورد آنچه باید ساخته شود، شروع میشود و با فهرستی از ویژگیهای مرتب شده بر اساس اولویت که صاحب محصول میخواهد به دست بیاورد، ادامه مییابد. این رویکرد بر اهمیت توانمندسازی تیمهای خودسازمانده تاکید میکند.
تاریخچه اسکرام
روش اسکرام در سال 1986 توسط دو استاد ژاپنی به نام هیروتاکا تاکوچی و ایکوجیرو نانوکا پایهگذاری شد. در سال 1993، جف ساترلند و تیمش در شرکت Easel با ترکیب مفاهیم مقاله تاکوچی و نانوکا با مفاهیم توسعه شیءگرا، کنترل فرآیند تجربی، توسعه تکراری و افزایشی و فرآیندهای نرمافزاری، فرآیند اسکرام را برای استفاده در توسعه نرمافزار ایجاد کردند. هدف از توسعه این روش، بهبود بهرهوری و همچنین توسعه سیستمهای پیچیده و پویا بود. اکنون شرکتهایی مانند هوندا، کانن، و فوجی زیراکس با استفاده از رویکرد مقیاسپذیر و مبتنی بر تیم برای توسعه محصول، محصولات جدید را برای ارائه در سراسر جهان تولید میکنند.
روش و فرآیند اسکرام
اسکرام دقیقاً تکامل یافته مدیریت چابک است. متدولوژی اسکرام بر مبنای مجموعهای از اقدامات و نقشها تعریف شده که در طول فرآیند توسعه نرمافزار رخ میدهند. اسکرام در بلوکهای موقت کوتاه و دورهای تحت عنوان Sprintاجرا میشود که معمولاً بین 2 تا 4 هفته در نظر گرفته میشوند. هر اسپرینت به خودی خود یک موجودیت است، یعنی یک نتیجه کامل را ارائه میکند؛ نسخهای از محصول نهایی که با کمترین تلاش ممکن به مشتری تحویل داده میشود.
فرآیند اسکرام در نقطه شروع، فهرستی از اهداف و نیازهای مشتری است که طرح پروژه را تشکیل میدهند. این مشتری پروژه است که این اهداف را با در نظر گرفتن ارزش و هزینه آن اولویتبندی میکند. دورههای تکرار و تحویل محصول هم بر اساس همین اولویتها تعیین میشوند.
بازار، خواستار کیفیت بالا و تحویل سریع با کمترین هزینه است. برای تامین این خواسته، شرکت تولیدکننده باید در توسعه محصولات بسیار چابک و انعطافپذیر عمل کند تا بتواند به چرخههای توسعه کوتاهی دست پیدا کند و تقاضای مشتریان را بدون افت کیفیت برآورده کند. اسکرام یک روش بسیار کاربردی است که خواستههای بازار، مشتری و تولیدکننده محصول را برآورده میکند.
روش اسکرام عمدتاً برای توسعه نرمافزار استفاده میشود، اما سایر بخشها نیز با پیادهسازی این متدولوژی در مدلهای سازمانی مانند تیمهای فروش، بازاریابی و منابع انسانی و غیره، از مزایای آن بهره میبرند.
مزایای روش اسکرام
اسکرام مزایای زیادی نسبت به سایر روشهای توسعه چابک دارد و پرکاربردترین و قابل اعتمادترین چارچوب مرجع در صنعت نرمافزار است. در زیر برخی از مزایای شناخته شده اسکرام آورده شده است:
مقیاسپذیری
فرآیندهای اسکرام تکراری هستند و در دورههای کاری خاص انجام میشوند. این فرایند، تمرکز تیم را بر روی عملکردهای مشخص برای هر دوره آسانتر میکند. این امر نهتنها دستیابی به نتایج بهتر مطابق با نیازهای کاربر را ممکن میکند، بلکه به تیمها این توانایی را میدهد که ماژولها را از نظر عملکرد، طراحی، وسعت و ویژگیها به صورت منظم، شفاف و ساده مقیاسبندی کنند.
انطباق انتظارات
مشتری انتظارات خود را مشخص میکند و ارزش نیازهای خود را برآورد میکند؛ مالک محصول با اطلاعاتی که مشتری به او میدهد، اولویتهای خود را تعیین میکند؛ و تیم اجرایی آنها را برآورد میکند. به طور منظم، در دموهای اسپرینت، مالک محصول تأیید میکند که الزامات برآورده شده است و بازخورد را به تیم ارسال میکند.
انعطافپذیری در برابر تغییرات
یکی از مزیتهای دیگر روش اسکرام، امکان واکنش سریع به تغییرات نیازهای مشتری یا تحولات بازار است. این روش بهترین ابزار برای انطباق با الزامات متغیری است که در پروژههای بزرگ و پیچیده رخ میدهند.
کیفیت بالای محصول
روش کار اسکرام و نیاز به دریافت نسخه کاربردی پس از هر اسپرینت، باعث میشود ایرادات محصول به تدریج خود را نشان بدهند و محصول نهایی با کمترین ایراد به مشتری ارائه شود. به علاوه محصول در زمان کوتاهتری به مشتری یا بازار هدف ارائه میشود.
پیشبینی به موقع
با استفاده از روش اسکرام، میانگین سرعت تیم با بررسی سرعت پیشرفت اسپرینتها برآورد میشود. در نتیجه، میتوان تخمین زد که چه زمانی یک عملکرد خاص که هنوز در بکلاگ قرار دارد، در دسترس مشتری قرار خواهد گرفت.
کاهش ریسک
در هر پروژه ریسکهایی از قبیل هزینه، زمان و عملکرد، کیفیت محصول را تهدید میکنند. در روش اسکرام، باارزشترین عملکردها تعیین میشوند و سرعت پیشرفت پروژه نیز به خوبی قابل پیشبینی است. این عوامل در کنار هم، از بروز ریسکهای احتمالی جلوگیری خواهند کرد.
برای اطلاع از نقشهای افراد در روش اسکرام و همچنین انواع رویدادی های این روش، متن کامل مقاله روش اسکرام در مدیریت پروژه چابک را در وبلاگ آوات بخوانید.
کتاب اسکرام و اکس پی ساده شده با عنوان فرعی چگونه اسکرام را انجام دهیم، اثری است که به قلم نوشته هنریک کنیبرگ نوشته شده و تاکنون دو ویرایش از آن منتشر شده است. این کتاب یکی از محبوبترین و پرطرفدارترین کتابهای اسکرام و مدیریت پروژه چابک (اجایل) است و به نوعی کتاب مرجع در این حوزه به شمار میرود. علت محبوبیت و استقبال فوقالعاده از این کتاب، واقعگرایانه بودن آن است. نگارنده این کتاب را با ذکر مثالهای واقعی از محیط کار و شرکتهای توسعه نرمافزار به رشته تحریر درآورده است. کتاب اسکرام و اکس پی ساده شده، حاصل تجریه چندین سال نویسنده هنریک کنیبرگ است، او تجربیات موفق خود را در زمینه اسکرام و اکس پی و مدیریت پروژه با خواننده به اشتراک گذاشته است.
حوزههایی که این کتاب پوشش میدهد، در مورد آشنایی و پیادهسازی کامل اسکرام است و علاوه بر آن معرفی و ترکیب روش XP با اسکرام را نیز به طور مفصل شرح داده است. کتاب اسکرام و اکس پی ساده شده، در ایران به همت اسد صفری به فارسی ترجمه شده و نشر سلوی آن را منتشر کرده است. متن فارسی این کتاب، کاملاً واضح و گویا است و خواننده کتاب با کمترین اطلاعات در مورد اسکرام، میتواند این روش را به طور کامل فرا بگیرد و در سازمان و شرکت خود به کار ببندد. بسیاری از دورههای رسمی اسکرام که در ایران برگزار میشوند، با استناد به متن همین کتاب طراحی شدهاند.
در این کتاب نحوه مدیریت نوین با استفاده از اسکرام، به صورت کامل شرح داده شده و نویسنده در نگارش آن، توجه ویژه به مدیریت نیروی انسانی و مشتریان داشته است .به قول نویسنده، کتاب اسکرام و اکس پی ساده شده، داستان جنگ است و نشان میدهد که چگونه مشکلات توسعه نرمافزار را میتوان با اسکرام رفع و رجوع کرد .اساتید برجسته حوزه اجایل و اسکرام از جمله مایک کان و جف سادرلند، به دلیل نوع نوشتار و متفاوت بودن قالب و محتوای کتاب با دیگر کتابهای موجود، آن را منبع موثقی در این زمینه دانستهاند. فایل کتاب را از وبلاگ آوات دانلود کنید.
مدیریت پروژه چابک یا اجایل (Agile) به دلیل انعطافپذیری و ماهیت تکاملی خود، به عنوان یکی از محبوبترین رویکردها در مدیریت پروژه شناخته میشود. این رویکرد در ابتدا برای توسعه نرمافزار طراحی شد و در سال ۲۰۰۱ با صدور بیانیه توسعه نرمافزار چابک، رسمیت یافت. با گذشت زمان، مدیریت پروژه چابک تکامل یافت و به یک انتخاب محبوب برای بسیاری از مدیران پروژه (صرفنظر از صنعت) تبدیل شد. اجایل به طور خلاصه، یک رویکرد تکراری و افزایشی برای مدیریت پروژه است که به تیمها کمک میکند تا با خواستههای کارفرما یا مشتری مطابقت داشته باشند. رویکرد مدیریت چابک از متدولوژیهای مختلفی تشکیل شده است و همه آنها مبتنی بر مفاهیم انعطافپذیری، شفافیت، کیفیت و بهبود مستمر هستند.
بر اساس پژوهشهایی که در سال ۲۰۱۸ انجام شده، پروژههایی که از روشهای چابک استفاده میکنند، ۲۸ درصد موفقتر هستند و تقریباً ۷۱ درصد از سازمانها، از اجایل با فرکانسهای متفاوت استفاده میکنند. اما چه چیزی اجایل را تا این حد موفق میکند و چرا مدیران پروژه از آن در ترکیب با سایر چارچوبها استفاده میکنند؟ تنها به یک دلیل ساده: اجایل کار مدیران را آسان میکند و به آنها اجازه میدهد تا کنترل بیشتری بر پروژههای خود داشته باشند. آنچه مدیریت روش اجایل را منحصربهفرد میکند، این که بر دو عامل کلیدی تمرکز دارد و هیچکدام را فدای دیگری نمیکند؛ ارائه پروژه با کیفیت بالا، و تکمیل پروژه در چارچوب محدودیتهای زمانی و مالی.
در ادامه برخی از مهمترین مزایای استفاده از مدیریت پروژه چابک و چرایی استفاده از آن توسط شرکتهای خلاق برای مدیریت پروژه را شرح میدهیم. متن کامل مقاله را در آوات بخوانید.
- کیفیت محصول
- رضایت مشتری
- کنترل بهتر
- قابلیت پیشبینی
- افزایش انعطافپذیری
- بهبود مستمر
- بهبود روحیه تیم
مدیریت چابک یا اجایل، ابزار قدرتمندی است که به مدیران، اعضای تیم و مشتریان کمک میکند تا بهتر و کارآمدتر عمل کنند. از بهبود کیفیت محصول گرفته تا کمک به پیشرفت حرفهای اعضای تیم، همه از مزایای استفاده از این روش در مدیریت پروژه هستند.