Business Rules & Use Story in Agile/Scrum

Overview/Giới thiệu

Blog này ghi lại một số nhận định và sự liên quan giữa business rule (BR) và user story (US) kèm theo một số ví dụ,

Example of Business Rule/Ví dụ về BR

BR123 Tenured professors may administer student grades.
Business rule này là một story / chức năng to

BR245 All master’s degree programs must include the development of a thesis.
Business rule này tương ứng với một Specification

FR1 It must be possible to specify the following details when creating a new user:
First name
Surname
Birth date
…
Business rule này tương ứng với một Specification

Việc đọc một <yêu cầu> và phân loại nó, là:
– user story
– business rule
– chức năng to
– hay tương ứng với một Specification
Đây không phải là việc khó làm.

Việc này rất có lợi khi thiết kế và phát triển.
Nếu người viết business rule và yêu cầu hiểu được ở mức độ lập trình thì sẽ rất thuận tiện cho developer.

Relation between Business Rule và User Story

Đây là quan hệ nhiều:nhiều (N:M)

Thường thì một business rule (tương đối lớn) tương ứng với nhiều user story.

Khi dự án chạy theo khung Scrum, với ràng buộc rằng mọi yêu cầu, bao gồm cả yêu cầu nghiệp vụ, đều phải viết bằng user story, thì chúng ta cần viết lại Business Rule theo định dạng đã được khuyến nghị của một user story.

Điểm khác biệt giữa business rule và user story là tư duy và cách nhìn yêu cầu. Một user story thường đơn giản dễ hiểu, hướng tới giá trị (value) của yêu cầu đó đem đến cho người dùng. Ngược lại, business rule tiếp cận theo cách truyền thống, hoành tráng (to hơn), hướng kỹ thuật nghiệp vụ và rất top-down theo một chiều, từ vai của người làm nghiệp vụ tới người thiết kế, người lập trình và người kiểm thử.

Với business rule, chúng ta nhìn thấy tổng thể trong bức tranh toàn cảnh. Với User story, chúng ta thấy một lát cắt chức năng.

Tích hợp những thành phần (chức năng) liên quan là điều mà ít Scrum team nhận thức được và làm đúng. Việc vẽ ra một bức trang tổng thể, như theo quan điểm của business rule, giúp Scrum team nhìn xa và rộng hơn.

When to user BR or US?

Câu trả lời là: Tùy.

Có lẽ BR thích hợp với việc định hướng cho một chức năng to, trải dài nhiều sprint.

Có thể nhóm những gì liên quan tới một business rule vào bộ yêu cầu theo một tiêu chí nào đó nếu BR quá to và không vừa vặn hoàn thành trong một sprint. Theme/Epic là một cách gọi và phân chia công việc ở mức độ cao được khuyến nghị trong Agile/Scrum.

Agile Business Analyst

Agile Business Analyst không phải chỉ là một buzzword chỉ những người làm BA theo mô hình. Nó là kỹ năng, mô hình bắt buộc kết hợp bởi hai yếu tố:

1. Nghiệp vụ BA
2. Tư duy Agile

Với những người làm BA trong dự án áp dụng nguyên lý Agile, hoặc cụ thể hơn, Scrum framework nhưng một khung làm việc (quy trình làm việc)

Conclusions/Kết luận

Việc chuyển đổi mô hình mô hình truyền thống sang Agile/Scrum đòi hỏi sự thay đổi tư duy của mọi thành viên nhóm dự án. Tên gọi của vị trí có thể thay đổi nhưng kỹ năng là không thay đổi. BA vẫn là BA nhưng tốt hơn nên có một vài kỹ năng khác cộng với sự thay đổi về tư duy quy trình. BR là một thuật ngữ và cách làm cần thay đổi để thích hợp hơn với mô hình Agile.

Tham khảo

http://agilemodeling.com/artifacts/businessRule.htm
http://www.allaboutrequirements.com/2011/09/use-case-specification-example.html