مقایسه Kanban و Scrum

اگر می‌خواهید نکات مهم و اساسی Scrum و Kanban را بیاموزید، این مقاله به شما کمک می‌کند.

همه چیز درباره Agile

مهم نیست که در مقایسه Kanban و Scrum کدام برنده هستند یا برای توسعه محصول دیجیتال خود کدام فریم‌ورک Agile را انتخاب می‌کنید، شایان ذکر است که همه آن‌ها یک پیشینه مشترک دارند. Manifesto که در سال 2001 منتشر شد، و هنوز اکثر شرکت‌های توسعه نرم‌افزار را در سراسر جهان هدایت می‌کند. هر رویکرد فقط یک پیاده‌سازی متفاوت از همان مجموعه با 4 مقدار و 12 اصل است.

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

بیایید دومین مورد را در مقایسه Kanban و Scrum بررسی کنیم. روش Kanban برای توسعه نرم‌افزار در سال 2007 معرفی شده است. این روشی برای تعریف، مدیریت و بهبود خدماتی است که ارائه‌دهنده دانش است، مثل خدمات حرفه‌ای، تلاش‌های خلاقانه، و طراحی محصولات فیزیکی و نرم‌افزاری.

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

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

تغییر و تحول

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

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

نتیجه این نبرد در جنگ Kanban و Scrum چیست؟ اگر ما قاضی باشیم، یک امتیاز به Kanban می‌دهیم. یکی از روندهای مدیریت پروژه IT می‌گوید که شما باید روش‌ها را ترکیب کنید تا بهترین نتیجه را دریافت کنید. اگر شما در Agile تجربه داشته باشید و از تجربیات برای اعتبارسنجی فرضیه‌های خود استفاده می‌کنید، شما می‌توانید رویکرد تغییر مداوم را به کار گرفته و به عنوان یک تیم و سازمان عالی رشد کنید.

نقش‌ها و مسئولیت‌ها

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

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

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

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

هماهنگی و رویدادها

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

هدف sprint ارائه محصول بالقوه قابل حمل است. علاوه بر این، تیم برنامه‌ریزی‌های sprint، اسکرام‌های روزانه، بازبینی‌های sprint و sprintهای سابق را مدیریت می‌کند. این موارد نیز زمان محدود دارند اما می‌توانند زودتر تمام شوند، تا زمانی که به اهداف‌شان برسند.

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

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

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

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

برنده Kanban در مقایسه با Scrum

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

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

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

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