Các khái niệm kiến thức cơ bản của mô hình scrum

Nên áp dụng scrum với dự án nào?

Với những dự án đòi hỏi khả năng thay đổi, cập nhật, điều chỉnh thường xuyên, phát triển liên tục. Tiêu chí quan trọng nhất là: sao cho nhanh nhất có thể đưa ra được các tính năng đến người dùng. Những dự án mà không đòi hỏi mọi thứ về yêu cầu phải đầy đủ ngay từ đầu, làm theo từng bước phân tích -> thiết kế -> code -> test(Waterfall):

• Chú trọng vào con người và sự tương tác giữa các thành viên hơn quy trình và công cụ
• Chú trọng vào ứng dụng chạy tốt hơn là tài liệu đầy đủ (Spec)
• Chú trọng đáp ứng được thay đổi hơn là tuân theo kế hoạch.

Các khái niệm của scrum

1. Các role, vị trí trong mô hình scrum ( scrum roles )

• Product owner (PO): Là người phụ trách sản phẩm, có quyền hạn trong việc quyết định tính năng của sản phẩm, quyết định thứ tự ,độ ưu tiên trong quá trình phát triển dự án. Khi team gặp phải tranh cãi về yêu cầu dự án, kỹ thuật, luồng chương trình mà không thông nhất được thì PO sẽ là người ra quyết định cuối cùng. PO cũng là người trả lời các câu hỏi của team về sản phẩm. Thông thường vị trí này sẽ là khách hàng ( người thuê làm sản phẩm trong dự án outsourcing ) và khách hàng này phải hiểu quy trình, cách thức làm Scrum. Product owner cũng là 1 thành viên của team. Trong trường hợp khách hàng không thể tham gia như một PO thực sự thì vị trí thay thế có thể là project manager hoặc BrSE, BA: người đóng vai trò phụ trách liên lạc với khách hàng trực tiếp và thường xuyên. Một điều rất quan trọng khi áp dụng mô hình scrum là: khách hàng phải biết và chấp nhận áp dụng mô hình này. Với scrum team, thời gian ban đầu áp dụng thì tiến độ có thể chậm và cả team sẽ tiến bộ dần theo thời gian. Khách hàng phải hiểu và chấp nhận điều đó, tránh can thiệp quá sâu vào tiến độ và quy trình của scrum team.

• Scrum master: Là người hỗ trợ cho Product owner và team. Scrum master không quản lý team, mà giúp team giải quyết những vấn đề cản trở, quấy nhiễu cho việc đạt được mục tiêu của team. Đảm bảo các luật lệ quy tắc do team đưa ra phải được tuân theo. Ví dụ: khi 1 thành viên trong team bị gọi nhờ sang support dự án khác thì Scrum master sẽ đứng ra đề thương thuyết điều chỉnh và có thể là từ chối support nếu dự án của mình không cho phép. Hoặc đơn giản là pha trà buổi sáng cho anh em nếu trong team bảo uống trà buổi sáng sẽ làm việc hiệu quả hơn Mô hình chuẩn thì vị trí Scrum master có thể là bất kỳ ai trong team và có thể luân phiên thay nhau làm ( nếu muốn ). Ở VN vị trí scrum master thường là PM hoặc team lead. Nhưng có sai lầm rất hay gặp đó là: hoặc là khi daily meeting một mình ông scrum master nói hoặc là theo kiểu hỏi đáp ông scrum master hỏi member khác đáp --> Hãy để mọi người trong team tự nói và người nói đầu tiên thì là random bất cứ ai.

• Scrum team: là toàn bộ thành viên còn lại của dự án . Scrum team đòi hỏi khả năng tự tổ chức, tự quản lý công việc theo cam kết và trách nhiệm đã hoàn thành công việc. Thường bao gồm 7 người. Tối thiểu là 3 và tối đa là 9. Các thành viên trong team thường đủ các vị trí để tạo nên sản phẩm: BA, tester, programmer, desinger...

2 . Các đối tượng, phương tiện của scrum ( Artifacts)

• Product backlog: toàn bộ danh sách các yêu cầu, tính năng của sản phẩm. Danh sách này sẽ được cập nhật thường xuyên bởi PO và bất kỳ ai trong team Độ ưu tiên thứ tự của các tính năng sẽ được PO quyết định.
• Sprint: 1 giai đoạn của dự án với thời gian cố định. Độ dài của 1 sprint sẽ được team và PO quyết định. Thông thường là từ 1 - 4 tuần.
• Sprint backlog: các tính năng của sản phẩm sẽ được làm trong 1 sprint. Việc chọn các tính năng nào nên làm và thứ tự ưu tiên sẽ do PO lựa chọn, team cùng thảo luận ở buổi sprint planing. Team có quyền bỏ bớt hoặc đưa thêm tính năng vào trong sprint dựa trên thứ tự mà PO đưa ra dựa trên đánh giá thời gian. Lưu ý là scope - phạm vi của sprint không được thay đổi.
• Planing poker: quân bài ghi các con số để cho điểm đánh giá các tính năng trong 1 sprint
• Velocity ( Burn down chart ): biểu đồ thể hiện kết quả mà team đã làm được trong 1 sprint.

3 . Các nghi thức trong scrum ( Ceremonies )

• Sprint planing meeting: Làm khi bắt đầu 1 sprint, PO thường sẽ mô tả và đưa ra thứ tự của các item trong Product backlog. Scrum team có thể đặt câu hỏi cho PO để hiểu hơn về sản phẩm. Sau đó team sẽ thảo luận và lựa chọn các item sẽ làm được trong sprint này.
• Daily meeting: thực hiện hàng ngày và từng thành viên trong team nếu các vấn đề để trả lời cho 3 câu hỏi
  • Hôm qua làm gì?
  • Hôm nay sẽ làm gì?
  • Có gặp vấn đề gì không?

Lưu ý ở đây là chỉ nên nói theo kiểu mô tả ngắn, nêu vấn đề chứ không nên đi sâu vào mô tả chi tiết, rồi trình bày giải pháp bla bla.. Các vấn đề gặp phải hay thảo luận sẽ được làm sau buổi daily meeting này với những người liên quan. Để tránh mất nhiều thời gian của cả đội.

• Sprint review/Demo meeting: Được thực hiện khi gần kết thúc 1 sprint: trong buổi này team sẽ show( demo) các tính năng đã làm được trong sprint. Team và PO sẽ review và quyết định những task nào được coi là xong ( done). Với những feature chưa done sẽ được đẩy trở lại product backlog và xếp lại thứ tự
• Sprint retrospection meeting: thực hiện gần khi kết thúc 1 sprint sau buổi sprint review: Cả team sẽ nhìn lại công việc trong sprint này để cải thiện và đạt hiệu quả hơn trong sprint tiếp theo. Có thể sử dụng các tool để thu thập các con số thông kê về số point( điểm estimate cho các feature ) thực hiện được, số bugs phát sinh. Team cùng thảo luận về tech, về quy trình, cách thức làm việc trao đổi, best practice để có thể làm tốt hơn.

4 . Các rule cần định nghĩa trong scrum

• Enough to start: không chú trọng vào quy trình tài liệu, làm thế nào để có thể đưa ra được sản phẩm sớm nhất.
• Definition of done: Đưa ra định nghĩa của team 1 task, 1 tính năng như thế nào được coi là hoàn thành.
• Time box: giới hạn thời gian của sprint , của các buổi meeting phải tuân thủ đúng như thời gian đưa ra. Để đảm bảo scrum team hoạt động ổn định.

5 . References

http://scrummethodology.com/ ( rất hay và dễ hiểu, có animated motion minh họa )

https://gurtejpsingh.wordpress.com/2013/07/04/scrum-ceremonies-and-artifacts/