Nhanh nhẹn không có nghĩa là không biết mình đang đi đâu, mà là linh hoạt trên con đường bạn đi.
Ý tưởng rằng quy trình phát triển phần mềm nhanh nhẹn (Agile) loại bỏ kế hoạch dài hạn có thể là một trong những lầm tưởng lớn nhất của mọi người về Agile. Lộ trình sản phẩm cũng quan trọng đối với một nhóm Agile như đối với nhóm Waterfall, vì nó cung cấp bối cảnh xung quanh công việc hằng ngày của nhóm và đáp ứng những thay đổi trong bối cảnh cạnh tranh. Một lộ trình aigle được thực hiện đúng rất dễ tìm và dễ hiểu.
Lộ trình sản phẩm Agile là gì?
Lộ trình sản phẩm (roadmap) là một kế hoạch hành động về cách một sản phẩm hoặc giải pháp sẽ phát triển theo thời gian. Chủ sở hữu sản phẩm sử dụng lộ trình sản phẩm để phác thảo chức năng sản phẩm trong tương lai và thời điểm các tính năng mới sẽ được phát hành. Khi được sử dụng trong quy trình phát triển phần mềm linh hoạt Agile, một lộ trình cung cấp bối cảnh quan trọng cho công việc hằng ngày của nhóm và linh hoạt để đáp ứng những thay đổi trong bối cảnh cạnh tranh. Nhiều nhóm Agile có thể chia sẻ cùng một lộ trình sẩn phẩm duy nhất.
Tìm hiểu thêm về Tầm quan trọng của lộ trình sản phẩm trong quy trình Agile.
Xây dựng lộ trình
Để xây dựng lộ trình, chủ sở hữu sản phẩm cần cân nhắc đến quỹ đạo thị trường, đề xuất giá trị và các hạn chế về kỹ thuật. Một khi các yếu tố này được cân nhắc hợp lý và được hiểu một cách rõ ràng, chúng sẽ được thể hiện trong lộ trình dưới dạng các sáng kiến và mốc thời gian. Dưới đây là ví dụ về một lộ trình rất đơn giản cho một nhóm sản phẩm. Các sáng kiến có màu xanh lam và các mốc thời gian được biểu thị bằng các cột mốc màu đỏ.
Chia sẻ lộ trình
Một khi lộ trình được xây dựng, nó cần được chia sẻ với toàn bộ nhóm sản phẩm để mọi người đều hiểu được tầm nhìn và hướng đi của quá trình phát triển sản phẩm. Trong nhiều tổ chức, chủ sở hữu sản phẩm tạo lộ trình của họ trong PowerPoint và bảng tính, sau đó gửi các trang trình bày và bảng tính qua email cho nhóm. Mặc dù có mục đích tốt, nhưng chiến lược này đã có những điểm thiếu sót ngay từ đầu. Mỗi thành viên trong nhóm đều có bản sao lộ trình của riêng họ và việc giúp mọi người luôn cập nhật kịp thời khi có sự thay đổi là một thách thức phức tạp.
Vậy làm cách nào để chủ sở hữu sản phẩm có thể giữ cho nhóm luôn được cập nhật một cách tốt hơn? Việc này không hề khó.
Hầu hết các công cụ cộng tác được xây dựng cho loại công việc này sẽ tự động thông báo cho tất cả những người tham gia dự án để họ biết rằng lộ trình đã thay đổi.
Khi thêm một sáng kiến vào lộ trình, bạn hãy xem xét các câu hỏi sau:
- Các ưu tiên tương đối của mỗi sáng kiến là gì?
- Khi nào chúng ta dự định thực hiện mỗi sáng kiến?
- Có những ngày nào cụ thể mà nhóm cần đạt được hay không?
- Chương trình có những phụ thuộc nào (nội bộ hoặc trong các nhóm khác)?
- Những nhóm nào đang làm việc với mỗi sáng kiến?
- Các nhóm hiện tại có sẵn sàng trong lịch trình của họ và đủ năng lực không?
- Chúng ta có thể giữ cho các nhóm agile hiện tại ổn định không? Nếu không thì các nhóm sẽ được tổ chức lại như thế nào?
- Chúng ta có tính đến các nhóm mới thành lập đang phát triển trong tiến trình của dự án không?
Sử dụng lộ trình
Việc liên kết công việc của nhóm bạn với lộ trình để bạn có được toàn bộ “bối cảnh” như trên là một điều rất quan trọng. Một phương pháp đã được thử và đúng để thực hiện điều này là chia nhỏ các sáng kiến thành các epic trong backlog của sản phẩm, sau đó phân tích chúng thành các yêu cầu và user story. Việc liên kết tất cả lại với nhau như vậy giúp chủ sở hữu sản phẩm và nhóm phát triển dễ dàng đưa ra các quyết định ngắn hạn mà không làm ảnh hưởng đến công việc trong tương lai. Hãy cùng xem một ví dụ để hiểu rõ hơn về việc này.
Giả sử chúng ta cần triển khai tính năng hồ sơ người dùng mở rộng trên trang web. Nếu chúng ta nhận thấy rằng khách hàng không tương tác với tính năng nay, liệu ta có nên tiếp tục đầu tư vào nó hay không? Có lẽ là không. Chúng ta cần hiểu tại sao mức độ tương tác lại thấp trước khi đưa ra quyết định này. Vì vậy, thay vì đẩy mạnh về phía trước, chúng ta có thể lựa chọn triển khai một số thử nghiệm A/B với hy vọng thu được một số thông tin chi tiết về tỷ lệ tương tác thấp.
Khả năng lùi lại một bước và nghiên cứu trước khi đưa ra quyết định là bản chất của một lộ trình Agile. Nó cung cấp cho nhóm khả năng phát triển các tính năng khi họ tìm hiểu thêm về sản phẩm và thị trường.
Phát triển lộ trình
Các dự án Waterfall đòi hỏi một khoản đầu tư trả trước rất lớn. Kết quả là, các thành viên trong nhóm trở nên gắn bó về mặt cảm xúc với lộ trình và hy sinh việc đưa ra quyết định đúng đắn vì họ sẽ cảm thấy buồn khi công việc đã hoàn thành – một lỗi lầm rất “nhân văn”.
Còn quy trình Agile thì gặp phải ba rủi ro khác nhau:
- Nhóm có thể mất niềm tin vào khả năng đưa ra quyết định chiến lược của ban lãnh đạo nếu lộ trình được cập nhật quá thường xuyên.
- Sản phẩm có thể được phát hành quá muộn trên thị trường và bỏ lỡ nhu cầu tồn đọng nếu lộ trình không được cập nhật đủ thường xuyên.
- Những nỗ lực dài hạn có vẻ “quá lớn và quá khó” đối với những lần lặp lại ngắn hơn. Nhóm có thể đã chia công việc thành những phần quá nhỏ và cuối cùng lại tập trung quá nhiều vào kết quả ngắn hạn.
Một cách để phòng tránh những rủi ro này là xem xét và đánh giá lại lộ trình hàng quý, điều chỉnh khi cần thiết và chia sẻ với nhau. Phương pháp này hoạt động tốt trong các tổ chức với bất cứ quy mô nào, nhưng bạn cần lưu ý: một lộ trình duy nhất có thể bao gồm nhiều nhóm Agile, vì vậy hãy kiểm tra, điều chỉnh và giao tiếp với mọi người một cách phù hợp.
Đề xuất đọc thêm: Tầm quan trọng của lộ trình sản phẩm trong Agile
Theo Atlassian
