SCRUM khác với Waterful cũ như thế nào? Waterful: Plan → build → test → review → sản phẩm → cho khách hàng xem.
- Nếu mà build mà có lỗi thì quay lại sửa plan (tương tự với các cái sau)
- Mất khoảng 6 tháng khách mới được xem mặt mũi của cái sản phẩm như nào.
- Nhưng yêu cầu về tính năng của khách có thể liên tục thay đổi.
- IDEA: Như vậy mình rút ngắn thời gian, cho ra nhiều release của sản phẩm, trước hết cứ làm những cái chức năng core trước, những tính năng khác thì thêm vào sau. Scrum:
- Chia nhiều Sprint, mỗi sprint chỉ tầm 2 tuần → trong 2 tuần này chỉ làm ra một bản release nhỏ (đương nhiên quy trình thì vẫn có lên kế hoạch, build, test,... nhưng vì sp rất nhỏ nên nó không cần nhiều tgian như waterful gốc)
- Trước hết cần có một ông là Product Owner đi thu thập các cái order của khách hàng và tạo thành cái Product Backlog (nó chứa các feature chẳng hạn).
- Phần mềm máy tính bỏ túi có chức năng tính toán dựa vào gtri nhập vào, chuyển đổi tiền tệ,...
- Từ đó cần chuyển đổi nó thành những user stories (As a... i need ... to do...): Với vai trò là người dùng, tôi muốn thấy một trang caculator để tính toán cộng trừ nhân chia.
- Từ user story đó thì sẽ sinh ra các micro task: tạo giao diện người dùng (UI), tạo chức năng front-end và back-end.
- Mỗi người chỉ nên nhận làm 85-115% lượng micro task mà mình ước lượng là mình có thể làm được trong tgian đó thôi
- Một sprint sẽ có nhiều micro task của nhiều cái user story khác nhau và mỗi task tính là 1 point, thì sẽ sinh ra cái burndown chart: mỗi ngày trong 2 tuần của 1 sprint thì sẽ xem cái micro task của sprint đó còn lại bao nhiêu, xem có kịp tiến độ nổi không. (ideal nhất, lý tưởng nhất là cái chart này đi xuống, nghĩa là task được hoàn thành dần chứ không bị chững ngang)
- Mỗi ngày thì đứng họp 15' (daily stand-up) để xem hoàn thành đến đâu, định làm gì tiếp và blocking.
- cuối cùng thì có cái sprint review để ông product owner xem là sprint này như nào, đúng tiến độ chưa, hiệu suất như nào,... Cases:
Yêu cầu khách hàng thường xuyên thay đổi.
Cần sản phẩm nhanh, không cần quá hoàn chỉnh, chỉ cần core.
Các dự án cần thay đổi thường xuyên, nhận diện thất bại sớm để thay đổi hướng đi.
user stories: mô tả các tính năng đó dựa trên vai trò (As a user, as a admin,...) → ra được micro task (ticket)
Sprint backlog: Chứa các micro task của nhiều user stories khác nhau.
Ultilized in life
Pin
Phương pháp này lẫn Kanban thì đều hoạt động tốt nhất khi áp dụng vào việc làm dự án, cần thấy sản phẩm để biết được tiến trình công việc nhằm review ngay. Dự án quá nhỏ hoặc cá nhân thì sẽ không thấy có sự khác biệt nhiều.
