Scrum (mô hình phát triển phần mềm)

Nhóm Scrum

Nhóm Scrum bao gồm Product Owner (Chủ Sản phẩm), Nhóm phát triển (Development Team) và Scrum Master. Các Nhóm Scrum là các nhóm tự quản (self-organizing) và liên chức năng (cross-functional). Các nhóm tự quản tự mình chọn cách thức tốt nhất để hoàn thành công việc của họ, chứ không bị chỉ đạo bởi ai đó bên ngoài nhóm. Các nhóm liên chức năng có đủ kĩ năng cần thiết để hoàn thành công việc mà không phụ thuộc vào bất kì người ngoài nào khác. Mô hình nhóm trong Scrum được thiết kế để tối ưu hóa sự linh hoạt, sáng tạo và năng suất.
Các Nhóm Scrum chuyển giao sản phẩm theo phân đoạn lặp đi lặp lại và tăng dần, tối đa hóa cơ hội cho các phản hồi. Việc chuyển giao tăng dần (incremental) các gói sản phẩm đạt tiêu 2 Xem thêm “Định nghĩa Hoàn thành”, chuẩn “Hoàn chỉnh” đảm bảo một phiên bản có thể sử dụng được của sản phẩm luôn luôn sẵn sàng.

Các sự kiện Scrum

Các sự kiện trong Scrum tạo ra thói quen và để giảm thiểu những buổi họp hành vốn không được định nghĩa trong Scrum. Scrum dùng các sự kiện được đóng khung thời gian (time-boxed), nghĩa là mỗi sự kiện có giới hạn thời gian tối đa. Điều này đảm bảo thời lượng vừa đủ để tránh lãng phí thời gian không cần thiết cho sự kiện.
Bao gồm cả bản thân Sprint vốn chứa tất cả các sự kiện khác, mỗi sự kiện trong Scrum là một cơ hội chính thức để thực hiện cơ chế thanh tra và thích nghi. Các sự kiện này được thiết kế đặc biệt để đảm bảo sự minh bạch và thanh tra. Nếu không thực hiện được các điều này có thể dẫn đến giảm thiểu tính minh bạch và đánh mất cơ hội để thanh tra và thích nghi.

Tạo Tác Scrum

Các tạo tác Scrum (artifact) hiển thị các công việc hoặc các giá trị bằng nhiều cách hữu ích để cung cấp tính minh bạch cũng như các cơ hội cho việc thanh tra và thích nghi. Các tạo tác Scrum được thiết kế để tối đa hóa tính minh bạch và thông suốt của các thông tin chính yếu nhằm đảm bảo mọi người có cùng cách hiểu thống nhất.

Product Backlog

Product Backlog là một danh sách sắp thứ tự tất cả những gì cần thiết của sản phẩm. Nó là nguồn yêu cầu duy nhất thể hiện các thay đổi trong sản phẩm. Product Owner là người chịu trách nhiệm về Product Backlog, nội dung của nó, sự hiện diện và thứ tự các hạng mục trong đó.
Product Backlog có thể không bao giờ hoàn chỉnh. Phiên bản sớm nhất của Product Backlog chỉ cho thấy các yêu cầu được tìm hiểu rõ ràng từ lúc đầu tiên. Product Backlog sẽ tiến hóa cùng với sản phẩm và môi trường mà nó sẽ được sử dụng. Product Backlog là động, nó thay đổi thường xuyên để nhận biết những gì mà sản phẩm cần phải có để có tính cạnh tranh và hữu ích. Chừng nào sản phẩm còn đó, thì Product Backlog cũng hiện diện.
Product Backlog liệt kê tất cả các tính năng (feature), chức năng, yêu cầu, cải thiện, vá lỗi cần thiết để làm nên sản phẩm trong tương lai. Các hạng mục trong Product Backlog được mô tả với các thuộc tính như: mô tả, thứ tự, ước lượng và giá trị.
Khi sản phẩm được đưa vào sử dụng và bắt đầu mang lại giá trị, thị trường sẽ cung cấp các phản hồi, Product Backlog sẽ trở thành một danh sách lớn hơn và toàn diện hơn. Nhu cầu thì không ngừng thay đổi, vì thế một Product Backlog là một thực thể sống động. Sự thay đổi trong các yêu cầu nghiệp vụ, điều kiện thị trường, hay công nghệ có thể dẫn đến các thay đổi trong Product Backlog.
Trong trường hợp nhiều Nhóm Scrum làm việc với nhau trên cùng một sản phẩm, một Product Backlog chung được dùng để mô tả những công việc tới đây của Sản phẩm. Khi đó, các hạng mục có thể được nhóm lại theo một tính chất nào đó.
Việc làm mới Product Backlog là hoạt động thêm vào các chi tiết, ước lượng và trình tự của các hạng mục trong Product Backlog. Đây là quá trình liên tục, theo đó Product Owner và Nhóm Phát triển thảo luận về các chi tiết của từng hạng mục. Trong suốt quá trình làm mới này, các hạng mục liên tục được xem xét và rà soát cẩn thận. Nhóm Scrum quyết định cách thức và thời điểm để làm mới Product Backlog. Hoạt động này có thể chiếm nhiều hơn 10% thời gian của Nhóm Phát triển. Tuy thế, các hạng mục Product Backlog có thể được cập nhật tại bất kì thời điểm nào theo chủ quan của Product Owner.
Product Backlog thường được sắp xếp theo các giá trị, độ rủi ro, độ ưu tiên và sự cần thiết. Các hạng mục đứng đầu danh sách sẽ trực tiếp điều khiển các hoạt động phát triển. Càng ở thứ tự cao hơn, các hạng mục càng được quan tâm nhiều hơn và được tập trung nỗ lực nhiều hơn vì chính giá trị của chúng.
Các hạng mục có thứ tự cao hơn rõ ràng và chi tiết hơn những mục ở vị trí thấp hơn trong Product Backlog. Ước lượng sẽ chính xác hơn nếu như hạng mục rõ ràng và chi tiết hơn vị trí càng thấp, hạng mục càng ít chi tiết. Hạng mục Product Backlog sắp tham gia vào Sprint tới thuộc loại “mịn”, được phân tách sao cho các hạng mục đó có thể được hoàn thành trong khung thời gian của Sprint. Hạng mục Product Backlog có thể hoàn tất trong một Sprint được coi là “Sẵn sàng”, có thể được chọn ra trong buổi Họp Kế hoạch Sprint. Các hạng mục Product Backlog thường rõ ràng và minh bạch hơn sau khi được làm mới.
Nhóm Phát triển chịu trách nhiệm việc ước lượng các hạng mục Product Backlog. Product Owner có thể gây ảnh hưởng lên Nhóm bằng cách giúp họ hiểu và lựa chọn trong các tình huống khó, nhưng người trực tiếp làm việc sẽ đưa ra con số ước lượng cuối cùng.

Kiểm soát tiến độ hướng đến mục tiêu

Tại bất kì thời điểm nào, tổng khối lượng công việc còn lại để đạt mục tiêu phải được nhóm tổng kết. Product Owner theo dõi lượng công việc còn lại ít nhất một lần trong buổi họp Sơ kết Sprint. Product Owner so sánh giá trị này với lượng thời gian còn lại tính từ các Sprint trước để đánh giá tiến độ hướng đến thời điểm dự tính hoàn thành mục tiêu của dự án. Thông tin này được minh bạch trước tất cả các bên hữu quan.
Rất nhiều phương pháp có thể được sử dụng để biểu thị tiến độ công việc, như các biểu đồ burndown, biểu đồ burnup hay các phương pháp dự báo khác. Các biện pháp này đã được chứng minh là rất hữu ích. Tuy nhiên, những thứ này không thay thế được tầm quan trọng của tính thực nghiệm trong quá trình phát triển. Trong các môi trường phức tạp, ta không thể biết được những điều sắp xảy ra. Chỉ có thể dựa trên những điều đã xảy ra để đưa ra các quyết định cho tương lai.

Sprint Backlog

Sprint Backlog là tập hợp các hạng mục Product Backlog được lựa chọn để phát triển trong Sprint, kèm theo một kế hoạch để chuyển giao phần tăng trưởng của sản phẩm và hiện thực hóa Mục tiêu Sprint. Sprint Backlog là một bản dự báo của Nhóm Phát triển về những chức năng sẽ có trong phần tăng trưởng tiếp theo và công việc cần làm để hoàn thành phần tăng trưởng đó.
Sprint Backlog cho thấy tất cả những việc Nhóm Phát triển cần phải làm để tiến tới Mục tiêu Sprint.
Sprint Backlog là một kế hoạch với chi tiết vừa đủ để những thay đổi về tiến độ công việc có thể nhìn thấy được trong các cuộc họp Scrum Hằng ngày. Nhóm Phát triển chỉnh sửa Sprint Backlog trong suốt Sprint và Sprint Backlog sẽ được cập nhật trong thời gian đó. Sự cập nhật này xảy ra khi Nhóm Phát triển làm việc theo kế hoạch của họ và hiểu rõ hơn về các công việc cần thiết để đạt Mục tiêu Sprint.
Mỗi khi có thêm việc mới, Nhóm Phát triển đưa vào Sprint Backlog. Khi công việc bắt đầu hay kết thúc, giá trị ước lượng về thời gian còn lại để hoàn tất công việc được cập nhật. Khi có phần nào đó của kế hoạch là không cần thiết, chúng sẽ bị bỏ đi. Chỉ có Nhóm Phát triển mới có thể thay đổi Sprint Backlog trong Sprint. Sprint Backlog là một bức tranh thời gian thực về công việc mà Nhóm Phát triển lên kế hoạch để hoàn thành trong Sprint và nó cơ bản thuộc về Nhóm Phát triển.

Kiểm soát tiến độ Sprint

Tại bất kì thời điểm nào trong Sprint, tổng lượng thời gian còn lại để hoàn thành công việc có thể tính toán được. Nhóm Phát triển sẽ theo dõi con số này thường xuyên, ít nhất là vào các cuộc họp Scrum Hằng ngày. Dựa vào việc theo dõi này, họ có thể dự báo về các tiến độ đạt đến Mục tiêu Sprint. Theo đó, họ sẽ quản lý được tiến độ công việc.

Gói tăng trưởng

Gói tăng trưởng (Increment) là tập hợp tất cả các hạng mục Product Backlog đã được hoàn thành trong suốt Sprint hiện tại và những Sprint trước đó. Cuối Sprint, gói tăng trưởng mới phải thỏa mãn điều kiện “Hoàn thành”, có nghĩa là nó phải ở trạng thái sử dụng được và thỏa mãn định nghĩa của Nhóm Scrum về “Hoàn thành”. Gói tăng trưởng phải ở trạng thái dùng được để Product Owner có thể quyết định phát hành (release) nó.

Minh bạch hóa các tạo tác

Scrum vận hành dựa trên sự minh bạch. Các quyết định để tối ưu hóa giá trị và kiểm soát rủi ro dựa nhiều vào việc quan sát trạng thái của các đồ tạo tác Scrum (artifact). Nếu sự minh bạch là đầy đủ, các quyết định sẽ trở nên dễ dàng. Nếu các tạo tác không minh bạch, các quyết định có thể thiếu sót hoặc tiềm ẩn rủi ro.
Scrum Master phải làm việc với Product Owner, Nhóm Phát triển và các đối tượng khác để hiểu rõ tại sao các tạo tác này không hoàn toàn minh bạch. Có nhiều cách để xử lý việc này Scrum Master phải giúp đỡ mọi người áp dụng cách thức phù hợp trong tình thuống thiếu vắng sự minh bạch đầy đủ. Scrum Master có thể phát hiện sự minh bạch không đầy đủ bằng việc thanh tra các tạo tác, các mẫu thăm dò, lắng nghe những gì được nói và phát hiện những sự khác biệt giữa những gì dự kiến và kết quả thực tế.
Nhiệm vụ của Scrum Master là làm việc với Nhóm Scrum và tổ chức để gia tăng tính minh bạch cho các tạo tác này. Công việc này đòi hỏi sự học hỏi, thuyết phục và thay đổi. Minh bạch không phải là việc ngày một ngày hai, mà là cả một quá trình.

Định nghĩa "hoàn thành"

Khi một hạng mục Product Backlog hoặc một Gói tăng trưởng được cho là “Hoàn thành”, mọi người phải hiểu rõ “Hoàn thành” như thế nghĩa là thế nào. Mặc dù việc xác định rõ định nghĩa này hoàn toàn phụ thuộc vào từng Nhóm Scrum, nhưng mọi thành viên phải chia sẻ chung một cách hiểu về việc hoàn thành một công việc, để đảm bảo tính minh bạch và thông suốt. Đây chính là “Định nghĩa Hoàn thành” (Definition of Done) cho Nhóm Scrum nó được dùng để đánh giá khi nào công việc thực sự hoàn thành trên mỗi gói tăng trưởng của sản phẩm.
Định nghĩa thống nhất sẽ chỉ dẫn cho Nhóm Phát triển nắm được số lượng hạng mục Product Backlog có thể được lựa chọn cho một Sprint. Mục đích của mỗi Sprint là để chuyển giao Gói tăng trưởng của các chức năng có tiềm năng chuyển giao được tuân thủ “Định nghĩa Hoàn thành” của Nhóm Scrum.
Mỗi Sprint, Nhóm Phát triển chuyển giao một Gói tăng trưởng. Phần tăng trưởng này phải là khả dụng, để Product Owner có thể lựa chọn và phát hành ngay lập tức. Nếu định nghĩa về “Hoàn thành” là một của quy ước, tiêu chuẩn hoặc hướng dẫn của tổ chức, tất cả các Nhóm Scrum đều phải tuân thủ. Nếu tổ chức chưa có một quy ước như vậy thì Nhóm Phát triển của mỗi Nhóm Scrum phải định nghĩa “Hoàn thành” cho từng sản phẩm. Nếu nhiều Nhóm Scrum cùng làm việc trên một sản phẩm, thì họ phải cùng nhau định nghĩa một cách hiểu chung về “Hoàn thành’.
Mỗi gói tăng trưởng được cộng dồn vào các gói tăng trưởng trước đó và được kiểm thử toàn bộ để đảm bảo chúng làm việc tốt với nhau. Khi Nhóm Scrum ngày càng trưởng thành thì “Định nghĩa Hoàn thành” càng được mở rộng với các chỉ tiêu khắt khe hơn để đạt chất lượng cao hơn. Bất kì một sản phẩm hay hệ thống nào đều nên có một định nghĩa “Hoàn thành” như là tiêu chuẩn cho công việc.