Hotline

0963 801 047
APEX Global Education
ACADEMY FOR PROFESSIONAL EXCELLENCE

Giá trị của sự chào đón thay đổi yêu cầu trong dự án Agile

2018-07-17  (1563)

Một trong 12 nguyên lý của Agile đưa ra nhấn mạnh đến “chào đón sự thay đổi yêu cầu”. Nhưng chào đón như thế nào là phù hợp và giá trị là gì? Đâu đó là câu hỏi các nhà quản lý đã và đang đặt ra.

Có một sự thật người làm dự án CNTT thấy có các điểm cần vượt qua rằng:

  • Khách hàng thật sự hiểu yêu cầu của mình khi nhìn thấy bóng dáng của sản phẩm.
  • Đội dự án chỉ thật sự hiểu yêu cầu của khách hàng một cách đầy đủ cho đến khi chia sẻ cái bóng dáng sản phẩm mà bạn chuyển giao.
  • Khách hàng nhận thấy rằng nếu thay đổi một ít về yêu cầu thì sản phẩm sẽ chất lượng hơn và mang lại nhiều giá trị hơn.
  • Lỗi là một thứ gì đó chúng ta cố gắng hạn chế nhưng không thể triệt tiêu hoàn toàn

Tất cả các điểm trên tạo ra sự thay đổi trong yêu cầu. Với phương pháp quản lý dự án truyền thống thì việc thay đổi yêu cầu dẫn đến kế hoạch được lên trước đó thay đổi và phạm vi (Scope) thay đổi và hàng loạt vấn đề khác thay đổi theo.

(Hình ảnh khóa đào tạo Agile Project Management cho VP Bank Hà Nội)

Phương pháp quản lý dự án Agile thì luôn chào đón sự thay đổi yêu cầu. Cụ thể hơn khi triển khai theo Scrum Framework thì những yêu cầu thay đổi cứ đẩy vào Product Backlog nhưng không được đẩy vào Sprint (hoặc nếu có đẩy vào thì cần có sự đồng thuận). Ở vai trò là khách hàng (hoặc đại diện cho khách hàng) dưới vai trò Product Owner. Bạn không thể yêu cầu đội dự án đưa ra lời cam kết hoàn thành trên 1 cơ sở yêu cầu ở thời điểm lên kế hoạch cho Sprint (Sprint Planning) rồi thay đổi yêu cầu xành xạch trong quá trình thực hiện công việc trong Sprint. Nếu bạn đặt mình vào vai trò của Development team thì bạn có dám cam kết không? Phần lớn câu trả lời là “Không”.

Việc chào đón sự thay đổi với quy tắc “không được thay đổi yêu cầu được cam kết thực hiện trong Sprint” thúc đẩy Product Owner tạo ra giá trị:

  • Đội dự án có cơ hội từ chối cam kết triển khai các yêu cầu kém chất lượng.
  • Hạn chế đội dự án đoán yêu cầu.
  • Chất lượng yêu cầu chất lượng hơn.
  • Chất lượng của sản phẩm sẽ tốt hơn.

Ở góc nhìn một nhà quản lý CNTT, tôi tin rằng bạn muốn đạt được thứ giá trị trên. Nhưng để đạt được thì đòi hỏi bạn đầu tư vào đào tạo, huấn luyện triển khai, tạo điều kiện môi trường tốt để loại bỏ các rào cản và triển khai một cách đầy đủ.

Đây là series “Câu chuyện đưa Agile vào doanh nghiệp” tôi chia sẻ cho cộng đồng Agile Việt Nam.

Phần 1: Giá trị mà phương pháp Agile có thể mang lại

Phần 2: Giới hạn của phương pháp quản lý dự án truyền thống – và hướng đi mới.

Phần 3: Thay đổi nhận thức là khởi đầu đưa Agile vào doanh nghiệp.

Phần 4: Thành công của phương pháp Agile đến từ sức mạnh của Teamwork.

Phần 5: Động lực triển khai phương pháp Agile là gì?

Phần 6: Triển khai Agile có thành công hay không ở công ty Software Outsourcing?

Phần 7: Giá trị của sự tương tác giữa Business User với đội dự án

***

Sẽ cập nhật tiếp… trong series “Câu chuyện đưa Agile vào doanh nghiệp”.

By Cao Trần