Agile như một phương pháp tiếp cận kinh doanh

Agile là phương pháp quản lý công việc còn nhiều bất định thông qua các chu kỳ học hỏi ngắn, hợp tác chặt chẽ và thường xuyên bàn giao giá trị. Phương pháp này ra đời như một lựa chọn thay thế cho các mô hình dự án cố gắng xác định toàn bộ giải pháp ngay từ đầu và xem những thay đổi về sau là thất bại. Agile không có nghĩa là làm việc mà không có kế hoạch. Điều đó có nghĩa là lập kế hoạch ở nhiều cấp độ, sớm kiểm chứng các giả định và điều chỉnh quyết định khi bằng chứng thay đổi.

Agile Manifesto nêu rõ bốn ưu tiên về giá trị: cá nhân và sự tương tác hơn là quy trình và công cụ; giải pháp hoạt động được hơn là tài liệu đầy đủ; hợp tác với khách hàng hơn là đàm phán hợp đồng; và phản hồi trước thay đổi hơn là bám theo kế hoạch. Những yếu tố ở vế sau vẫn quan trọng, nhưng chúng nên hỗ trợ việc đạt được kết quả thay vì trở thành mục tiêu tự thân. Ví dụ, kế hoạch dự án hữu ích khi giúp các bên liên quan phối hợp. Kế hoạch sẽ trở nên có hại khi nhóm tiếp tục bàn giao phạm vi ít giá trị chỉ vì phạm vi đó có trong kế hoạch ban đầu.

Mười hai nguyên tắc Agile chuyển hóa các giá trị này thành hướng dẫn vận hành. Những chủ đề quan trọng gồm bàn giao giá trị sớm và liên tục, chào đón các yêu cầu thay đổi, bàn giao thường xuyên, hợp tác hằng ngày giữa bộ phận kinh doanh và kỹ thuật, duy trì nhịp độ bền vững, đảm bảo sự xuất sắc về kỹ thuật, đề cao tính đơn giản, xây dựng các nhóm tự tổ chức và thường xuyên nhìn lại. Xét trên phương diện kinh doanh, các nguyên tắc này rút ngắn khoảng thời gian từ quyết định đầu tư đến khi có bằng chứng đáng tin cậy về việc quyết định đó có tạo ra giá trị hay không.

Framework Scrum và tính thực nghiệm

Scrum là một framework tinh gọn để áp dụng các ý tưởng Agile vào việc phát triển sản phẩm phức tạp. Scrum dựa trên tính thực nghiệm, nghĩa là các quyết định được đưa ra dựa trên quan sát và kinh nghiệm thay vì những dự đoán thiếu căn cứ. Ba trụ cột của Scrum là minh bạch, kiểm tra và thích nghi. Công việc, mục tiêu, kỳ vọng về chất lượng và vấn đề phải đủ rõ ràng để có thể kiểm tra. Sau đó, việc kiểm tra cần dẫn đến những điều chỉnh kịp thời khi kết quả khác với kỳ vọng.

Scrum tổ chức công việc thành các Sprint, là những khoảng thời gian cố định kéo dài không quá một tháng. Mỗi Sprint là một chu kỳ học hỏi hoàn chỉnh, trong đó Scrum Team theo đuổi Sprint Goal và tạo ra ít nhất một Increment có thể sử dụng. Chu kỳ ngắn hơn giúp hạn chế rủi ro vì các bên liên quan không phải chờ vài tháng mới phát hiện tính năng đang giải quyết sai vấn đề. Chẳng hạn, một Sprint hai tuần có thể kiểm chứng liệu quy trình onboarding khách hàng được đơn giản hóa có giúp giảm tỷ lệ bỏ ngang hay không trước khi công ty đầu tư thêm vào các tính năng tự động hóa nâng cao.

Scrum được thiết kế có chủ đích để không quy định mọi chi tiết. Framework này xác định các trách nhiệm, sự kiện và tạo tác tối thiểu, nhưng không đưa ra quy trình dự án chi tiết, chức danh công việc hay cấu hình Jira cụ thể. Tổ chức có thể áp dụng hoạt động dự báo, nghiên cứu, chỉ số cấp dịch vụ và cơ chế quản trị cùng với Scrum, miễn là các hoạt động đó không làm suy yếu tính minh bạch, quyền làm chủ của nhóm hoặc khả năng thích nghi.

Trách nhiệm trong Scrum Team

Scrum Team gồm một Product Owner, một Scrum Master và các Developers. Nhóm có năng lực đa chức năng, nghĩa là tập thể nhóm sở hữu những kỹ năng cần thiết để tạo ra giá trị; đồng thời tự quản, nghĩa là các thành viên tự quyết định ai làm việc gì, khi nào và bằng cách nào. Các bên liên quan có thể xác định những ràng buộc và kết quả mong đợi, nhưng không nên phân công công việc hằng ngày cho từng thành viên trong nhóm.

Product Owner chịu trách nhiệm tối đa hóa giá trị sản phẩm và quản lý Product Backlog hiệu quả. Công việc này bao gồm truyền đạt Product Goal, tạo hoặc làm rõ các mục trong Product Backlog, sắp xếp thứ tự ưu tiên và bảo đảm backlog minh bạch. Product Owner có thể ủy quyền các hoạt động nhưng vẫn giữ trách nhiệm giải trình. Trong một dự án cổng thông tin khách hàng, người này có thể ưu tiên khôi phục mật khẩu trước tùy chỉnh hồ sơ, vì dữ liệu hỗ trợ cho thấy các sự cố không thể truy cập gây tốn kém hơn và khiến khách hàng bức xúc hơn.

Developers chịu trách nhiệm tạo ra một Increment có thể sử dụng được trong mỗi Sprint, lập kế hoạch công việc của Sprint, duy trì chất lượng theo Definition of Done và điều chỉnh kế hoạch hằng ngày. Scrum Master chịu trách nhiệm thiết lập Scrum theo đúng định nghĩa và nâng cao hiệu quả của Scrum Team. Scrum Master hướng dẫn, điều phối khi cần thiết và hỗ trợ loại bỏ các trở ngại mang tính hệ thống. Đây không phải là vai trò quản lý dự án theo kiểu chỉ huy và kiểm soát; Scrum Master không giao nhiệm vụ hay phê duyệt công việc đã hoàn thành.

Các sự kiện Scrum và quyết định của chúng

Sprint Planning khởi động Sprint bằng cách làm rõ vì sao Sprint có giá trị, có thể hoàn thành những gì và sẽ hoàn thành công việc đã chọn như thế nào. Sprint Goal được xác lập sau buổi lập kế hoạch tạo cho nhóm một mục tiêu nhất quán, thay vì một danh sách ticket rời rạc. Developers dự báo khối lượng công việc có thể hoàn thành dựa trên năng lực sẵn có, hiệu suất trước đây, các yếu tố phụ thuộc và Definition of Done. Product Owner cung cấp bối cảnh về giá trị và mức độ ưu tiên, nhưng không áp đặt cam kết về phạm vi.

Daily Scrum là sự kiện kéo dài mười lăm phút để Developers đánh giá tiến độ hướng tới Sprint Goal và điều chỉnh kế hoạch. Đây không phải là buổi báo cáo tình hình cho Scrum Master, cũng không phải vòng lần lượt trả lời ba câu hỏi soạn sẵn bắt buộc. Một Daily Scrum hữu ích giúp xác định liệu công việc hiện tại có còn hỗ trợ mục tiêu hay không, làm rõ nhu cầu phối hợp và khởi động các cuộc trao đổi tiếp theo mà không biến sự kiện này thành một buổi họp giải quyết vấn đề kéo dài.

Sprint Review đánh giá kết quả của Sprint cùng với các bên liên quan và xác định những điều chỉnh tiếp theo. Đây nên là một buổi làm việc tập trung vào bằng chứng, thay đổi của thị trường và các ưu tiên tiếp theo, chứ không chỉ là buổi trình diễn hay một vòng phê duyệt. Sprint Retrospective tập trung vào hiệu quả của nhóm, bao gồm tương tác, quy trình, công cụ và chất lượng. Nhóm lựa chọn những cải tiến thiết thực cho Sprint tiếp theo. Bản thân Sprint bao gồm tất cả các sự kiện còn lại và tạo ra nhịp độ đều đặn, giúp việc đánh giá trở nên có thể dự đoán.

Các tạo tác Scrum và cam kết

Product Backlog là danh sách được sắp xếp thứ tự và liên tục phát triển, ghi lại những gì cần thiết để cải thiện sản phẩm. Cam kết gắn với nó là Product Goal, một mục tiêu dài hạn hơn định hướng các quyết định về backlog. Những mục sắp được triển khai thường có nhiều chi tiết hơn các khả năng còn ở xa. Backlog refinement là hoạt động liên tục nhằm chia nhỏ và làm rõ các mục, nhưng đây không phải là một sự kiện Scrum chính thức hay lời hứa rằng mọi điều chưa chắc chắn sẽ biến mất.

Sprint Backlog gồm Sprint Goal, các mục Product Backlog được chọn cho Sprint và kế hoạch triển khai có thể hành động của Developers. Cam kết của Sprint Backlog là Sprint Goal. Developers cập nhật Sprint Backlog khi có thêm thông tin, và phạm vi có thể được thương lượng lại với Product Owner mà không làm ảnh hưởng đến mục tiêu. Tính linh hoạt này phân biệt dự báo với hợp đồng cố định. Chỉ Product Owner mới có thể hủy Sprint, thường là khi Sprint Goal không còn phù hợp.

Increment là kết quả tích hợp, có thể sử dụng được của công việc đã hoàn thành. Cam kết gắn với Increment là Definition of Done, mô tả chung về các tiêu chí chất lượng cần đáp ứng để công việc được xem là hoàn tất. Công việc không đáp ứng Definition of Done không thể được trình bày như một phần của Increment hoặc được xem là đã hoàn thành. Có thể tạo ra hoặc phát hành nhiều Increment trong một Sprint; thời điểm phát hành là quyết định kinh doanh và không nhất thiết phải chờ đến Sprint Review.

Vận dụng các nguyên lý nền tảng với Jira

Jira có thể giúp hiển thị tiến độ Scrum, nhưng cấu hình công cụ không thể tạo ra sự linh hoạt. Một thiết lập thực tế sẽ liên kết các mục trong Product Backlog với kết quả kinh doanh, dùng bảng để thể hiện quy trình làm việc hiện tại và cung cấp cho cả nhóm một góc nhìn chung về tiến độ Sprint. Sprint Goal cần luôn hiển thị bên cạnh các issue đã chọn để các bên liên quan không nhầm việc hoàn thành ticket với mục đích của Sprint. Các trạng thái quy trình nên thể hiện những giai đoạn có ý nghĩa, thay vì mọi lần bàn giao nhỏ.

Hãy xem xét một nhóm dịch vụ tài chính đang tìm cách giảm số hồ sơ mở tài khoản chưa hoàn chỉnh. Product Owner sắp xếp thứ tự backlog dựa trên bằng chứng từ khách hàng và tác động dự kiến. Trong Sprint Planning, nhóm chọn những công việc hỗ trợ một mục tiêu như giảm tình trạng khách hàng bỏ dở bước xác minh danh tính. Jira ghi lại các mục đã chọn và quy trình làm việc, trong khi Daily Scrum sử dụng thông tin đó để xác định những công việc bị cản trở. Tại Sprint Review, nhóm đánh giá Increment có thể sử dụng được và dữ liệu ban đầu về mức độ hoàn thành. Tại Retrospective, nhóm có thể quyết định mời các chuyên gia tuân thủ tham gia sớm hơn sau khi phát hiện tình trạng chậm phê duyệt lặp đi lặp lại.

Không nên chỉ đánh giá thành công qua velocity, story point, mức độ sử dụng nguồn lực hay số issue đã đóng. Những chỉ số đó có thể hỗ trợ dự báo, nhưng không chứng minh được giá trị. Các nhóm nên kết hợp chỉ số phân phối như thời gian chu kỳ và mức độ dự đoán được với các thước đo chất lượng, hành vi khách hàng và kết quả kinh doanh. Tiêu chí cốt lõi để ra quyết định là mỗi Sprint có tạo ra kết quả có thể sử dụng, giúp cải thiện hiểu biết và cung cấp thông tin cho quyết định đầu tư tiếp theo hay không.