Note nhanh khi đọc quyển Scrum Primer, bản tiếng Việt của Học viện Agile.
Khung phát triển Scrum gồm các nhóm liên chức năng phát triển các sản phẩm hoặc dự án theo hình thức lặp, phản hồi, tăng trưởng.
Các thành phần của Scrum
- Sprint là các chu trình kéo dài từ 2 đến 4 tuần và diễn ra liên tiếp nhau mà không bị gián đoạn. Sprint sẽ kết thúc vào một ngày nhất định cho dù công việc đã được hoàn thành hết hay chưa và không được phép kéo dài thêm.
- Nhóm phát triển sản phẩm (Development Team - liên chức năng bao gồm Developers, UI/UX Designers, Marketers, Growth Hackers… ) khoảng 7 người (dao động +2, -2).
- Đầu Sprint nhóm phát triển sản phẩm sẽ họp và pick các hạng mục cần làm trong sprint từ danh sách ưu tiên (Product Backlog). Nhóm phát triển sản phẩm thống nhất một mục tiêu chung mà họ tin rằng có thể hoàn thành và chuyển giao được vào cuối Sprint. Sau khi đã thống nhất thì không có hạng mục mới nào được phép chen vào giữa Sprint mà phải để dành cho những Sprint tới.
- Đầu mỗi ngày đều có Standup Meeting.
- Cuối Sprint Họp để rà soát Sprint, trình bày phần mình đã xây dựng được trong Sprint và nhận phản hồi từ cả nhóm phát triển sản phẩm.
Các vai trò trong Scrum
- Product Owner - người chịu trách nhiệm chính về sản phẩm)
- Đội phát triển - những người trực tiếp tham gia phát triển sản phẩm)
- Scrum Master - người nắm vững các nguyên lý của Scrum, hỗ trợ và giúp đỡ nhóm phát triển sản phẩm áp dụng Scrum. Scrum Master không được là cùng một người với Product Owner.
Product Backlog
- Các hạng mục được đưa vào Product Backlog là các tính năng hướng khách hàng (Customer-centric), các mục tiêu cải tiến, các công việc nghiên cứu, các lỗi đã phát hiện… Dù là gì đi nữa thì phần lớn các hạng mục phải tập trung vào chuyển giao giá trị cho khách hàng.
- Là một danh sách có độ ưu tiên.
- Tồn tại và tiến hóa trong suốt vòng đời của sản phẩm và là lộ trình của sản phẩm.
- Góc nhìn duy nhất và mang tính quyết định của “tất cả mọi thứ có thể được nhóm Phát triển hoàn thành theo thứ tự ưu tiên”.
- Một Product Backlog tốt cần đạt được tiêu chí DEEP
- Detailed Appropriately (Chi tiết hợp lý): Các hạng mục có độ ưu tiên cao cần được làm mịn và chi tiết hơn so với hạng mục có ưu tiên thấp hơn vì chúng sẽ được lựa chọn để thực hiện trước.
- Estimated (được ước lượng) - Mỗi hạng mục cần có khối lượng công việc ước tính cùng một số thông số khác.
- Emergent (Tiến hóa) - Trong mỗi Sprint, các hạng mục có thể được thêm vào, xóa đi, hoặc thay đổi, chia nhỏ và thay đổi độ ưu tiên. Product Backlog luôn được cập nhật bởi Product Owner để thể hiện các thay đổi trong nhu cầu của khách hàng, các ý tưởng hoặc hiểu biết mới, động thái của các đối thủ cạnh tranh, các rào cản kỹ thuật vừa xuất hiện v.v…
- Prioritized (Sắp xếp theo độ ưu tiên), các hạng mục có độ ưu tiên cao hơn nằm ở phía trên của Product Backlog. Tiêu chí sắp xếp độ ưu tiên dựa trên Lợi ích tương xứng với đồng tiền bạn bỏ ra, nhiều lợi ích với ít tiền nhất. Một lý do khác có thể dẫn đến tăng độ ưu tiên của một hạng mục là nhằm giải quyết sớm các rủi ro lớn trước khi chúng tấn công bạn.
- Để ước tính khối lượng công việc (Estimated), một kỹ thuật phổ biến đó là ước tính theo kích thước tương đối (hệ số nỗ lực, độ phức tạp và tính bất định) gọi là “story point” trong sự thống nhất, tương quan và mặt bằng chung của cả nhóm.
- Một lợi thế của Scrum là nhờ vào việc ước tính khối lượng công việc tốt, Product Owner có thể theo dõi lượng công việc hoàn thành trong mỗi Sprint: Ví dụ, trung bình Team hoàn thành 26 point cho một Sprint. Với thông tin này, nếu giá trị trung bình được giữ nguyên và không có gì khác thay đổi, người ta có thể trù liệu được ngày phát hành (đợt Release) mà tất cả các tính năng (dự kiến sẽ ra mắt) đều được hoàn thành.
- Các hạng mục lớn trong Product Backlog cần được làm mịn + chia nhỏ hơn trong buổi họp Sprint Planning. Và các hạng mục nhỏ có thể được hợp nhất lại với nhau.
- Phần lớn thời gian của nhóm Phát triển là dành cho các mục tiêu của Product Owner chứ không phải là các công việc kỹ thuật nội bộ mặc dù nhóm Phát triển có quyền độc lập trong việc quyết định số lượng hạng mục được đưa vào trong một Sprint.
- Không nên mô tả tất cả mọi chi tiết có thể có của một hạng mục mà chỉ nên làm rõ những gì cần thiết đủ để hiểu tốt hạng mục đó.
Định nghĩa hoàn thành
- Kết quả của mỗi Sprint được gọi là Potentially Shippable Product Increment - Phần tăng trưởng sản phẩm có thể chuyển giao được.
- Trước khi bắt đầu Sprint, Product Owner, Team và Scrum Master ngồi lại với nhau và rà soát lại những thứ cần làm để biến một hạng mục Product Backlog được đưa vào Sprint này trở thành có thể chuyển giao được. Không may là không phải lúc nào Team cũng có thể chuyển giao được tất cả mục tiêu một cách đúng hạn do nhiều khó khăn không lường trước hết được hay do bị nghẽn ở một khâu nào đó trong một nhóm liên chức năng (khi người này phải chờ người kia hoàn thành công việc mới thực hiện tiếp được).
- Trước Sprint đầu tiên, Product Owner và Nhóm phát triển cần thống nhất một Định nghĩa hoàn thành (Definition of Done), nó là một tập con của các hoạt động cần thiết để tạo ra một Potentially Shippable Product Increment. Team sẽ lập kế hoạch công việc của Sprint dựa theo Định Nghĩa Hoàn Thành này.
- Một Product Owner tốt sẽ luôn cố gắng để Định Nghĩa Hoàn Thành này bám sát hết mức có thể với Khả năng chuyển giao được vì nó sẽ giúp tăng tính minh bạch và giảm thiểu rủi ro chậm trễ.
- Một nhóm Scrum cần phải liên tục cải tiến, điều này được phản ánh vào trong việc mở rộng Định Nghĩa Hoàn Thành.
Tạm kết phần đầu tiên của Scrum Primer (Sách vỡ lòng về Scrum - Học viện Agile Việt Nam). Tản mạn một chút về lý do đến tận bây giờ mới đọc và tìm hiểu về Scrum (rồi Agile), mình làm trong một startup với một team rất trẻ và non kinh nghiệm nhưng lại phải vừa học vừa ứng dụng Scrum vào việc điều hành và phát triển sản phẩm. Vì vậy, khó tránh khỏi thất bại khi apply scrum vào dự án. Trước giờ thì Team đã khoán hết cho Product Owner việc tìm hiểu và áp dụng Scrum nhưng hiện tại qua việc đọc phần mở đầu của quyển Scrum Primer này, mình đã ngộ ra rằng các Principle này toàn bộ Team đều nên nắm và cần thiết phải có một người grow lên thành Scrum Master để “phò tá” Product Owner và giúp đỡ Team học hỏi và phát triển. Với mục tiêu nghề nghiệp ban đầu mà mình định hướng, mình muốn trở thành Senior Developer rồi Technical Lead nhưng những chức danh này hầu như chỉ còn trên danh nghĩa và chỉ mang tính chất hỗ trợ trong phương phát phát triển phần mềm linh hoạt như Agile, Vì vậy, Scrum Master và sau đó là Product Owner có thể là sự lựa chọn đáng cân nhắc.