مقایسه فرآیند مدل Scrum با Kanban (بخش اول - تعریف Scrum)

با اطمینان میشه گفت امروزه درصد بالایی از پروژه‌های نرم‌افزاری موفق از متدولوژی‌های مدیریت و توسعه پروژه Agile (چابک) استفاده می‌کنن.
Framework (چارچوب) های مختلفی جهت این متدولوژی تعریف و توسعه پیدا کرده که از بین اونها میشه به Scrum و Xp اشاره کنیم که از مابقی framework ها محبوب‌تر هستن.

بیایم XP رو بذاریم کنار و تمرکزمون رو بذاریم روی محبوب‌ترین framework مدیریت پروژه یعنی Scrum، خب پس Kanban کجا رفت ؟! در اصل میشه گفت Kanban یک نسخه ویرایش شده از Scrum هستش.

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

توی Scrum در مورد کار حرف می‌زنیم اما در Kanban کار می‌کنیم.

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

فرض کنید پروژه‌ای داریم که قراره با چارچوب Scrum پیش ببریم و طبق تجربمون بهتره که هر Sprint رو طی دو هفته انجام بدیم.

نیازمندی‌های مشتری رو استخراج می‌کنیم، تبدیل می‌کنیم به Story card و توی Backlog قرار می‌دیم، حالا که کارت هامونو ساختیم و Backlog آماده شده، بریم که شروع کنیم پروژه رو پیش ببریم.

طبق روند اصولی چارچوب Scrum، کارت‌ها به ترتیب اهمیت و الویت وارد Board میشن و پس از اتمام برنامه‌نویسی و تست وارد ستون Release میشن تا به یک محصول قابل انتشار برسن (Shippable Product).

تیم برنامه‌نویسی و مدیریت پروژه هر روز صبح قبل از شروع کار یک جلسه ۱۵ دقیقه‌ای تشکیل می‌دن و در مورد روند پیشرفت پروژه، کارهایی که می‌خوان اون‌روز انجام بدن، کارهایی که روز قبل انجام دادن، مشکلاشون، چالش‌هاشون و این جور موارد با هم بصورت ایستاده حرف میزنن که به این جلسه اصطلاحا می‌گن Stand up meeting. خب حالا چرا ایستاده ؟ برای اینکه نباید این جلسه زیاد طول بکشه، یک جلسه مختصر و مفید.

پس از پایان هفته دوم ممکنه یک سری فرآیند مونده باشه که هنوز برنامه‌نویسی‌شون تمام نشده و توی ستون‌هایی غیر از ستون Release مونده باشن، این کارت‌ها می‌مونن برای Sprint بعدی.

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

تا به اینجا توی چارچوب Scrum به ترتیب روند عملکرد، قسمت‌های زیر رو داشتیم:

• Backlog
• Sprint Planning
• Sprint
• Scrum Meeting (Daily)
• Done Pile
• Package Release
• Retrospective (جلسه جهت اسپرینت‌های آینده)

توی این نوشته یک نگاه کلی به چارچوب مدیریت پروژه Scrum داشتیم ( به جزییات کاری نداریم چون خیلی جزییات Kanban مثل Scrum هست و فقط قسمت‌هایی رو مورد بررسی قرار می‌دیم که درون این دو چارچوب متفاوت هستن ).

توی نوشته بعدی میریم سراغ بررسی Kanban.

موفق و پیروز باشید :-)