Visual Paradigm Desktop | 
Visual Paradigm Online
Phương pháp Agile hứa hẹn tính linh hoạt, khả năng phản hồi nhanh và cải tiến liên tục. Tuy nhiên, thực tế thường đi kèm với những trở ngại. Một đợt sprint thất bại không phải là điều bất thường; đó là một điểm dữ liệu. Việc hiểu cách một đội ngũ vượt qua thất bại sẽ quyết định thành công lâu dài nhiều hơn là việc ăn mừng những chu kỳ hoàn hảo.
Bài viết này xem xét một tình huống cụ thể khi một đội phát triển đã hoàn toàn bỏ lỡ mục tiêu sprint. Chúng ta sẽ khám phá các yếu tố kỹ thuật và con người liên quan, quy trình tổng kết để chẩn đoán vấn đề, cũng như các bước cụ thể đã được thực hiện nhằm khôi phục tốc độ và chất lượng.
Để hiểu được nguyên nhân thất bại, chúng ta cần hiểu trước tiên về cấu trúc. Tổ chức hoạt động theo mô hình đội ngũ đa chức năng. Nhóm bao gồm năm nhà phát triển, một người sở hữu sản phẩm và một kiểm thử viên chuyên trách. Công việc được tổ chức theo các chu kỳ hai tuần.
Đội ngũ sử dụng bảng theo dõi vật lý và kỹ thuật số để quản lý luồng công việc. Các câu chuyện được di chuyển từ Danh sách chờ đến Đang thực hiện và cuối cùng đến Hoàn thành. Mục tiêu là giao giá trị đều đặn mà không làm ảnh hưởng đến chất lượng mã nguồn.
Sprint 42 bắt đầu với tốc độ cao. Đội đã kéo 30 điểm câu chuyện từ danh sách chờ. Đến ngày thứ ba, tốc độ dường như ổn định. Đến ngày thứ năm, sự cản trở xuất hiện. Đến ngày thứ mười, đội nhận ra họ sẽ không hoàn thành công việc đã cam kết.
Sự thất bại không phải do một sự kiện thảm họa duy nhất. Đó là một chuỗi các vấn đề tích tụ dần làm suy giảm năng lực.
Các con số nói lên câu chuyện rõ ràng hơn cảm xúc. Bảng sau minh họa sự chênh lệch giữa nỗ lực đã lên kế hoạch và kết quả thực tế.
| Loại | Đã lên kế hoạch | Thực tế | Chênh lệch |
|---|---|---|---|
| Điểm truyện hoàn thành | 30 | 12 | -18 |
| Lỗi phát hiện (trong đợt phát triển) | 2 | 14 | +12 |
| Vé hỗ trợ xử lý | 0 | 3 | +3 |
| Sự thay đổi phụ thuộc bên ngoài | 0 | 1 | +1 |
Dữ liệu này tiết lộ sự phân bổ nguồn lực đáng kể. Những gì bắt đầu là công việc phát triển đã chuyển thành bảo trì và quản lý khủng hoảng.
Trách móc cá nhân không giải quyết được các vấn đề hệ thống. Đội đã thực hiện phân tích nguyên nhân gốc rễ không đổ lỗi để xác định các vấn đề cốt lõi.
Để đi sâu hơn, đội đã áp dụng kỹ thuật5 Vì saovào vấn đề chậm tiến độ.
Vấn đề cốt lõi không phải là độ chính xác trong lập kế hoạch; mà là các thực hành phát triển bền vững.
Tổng kết là động cơ thúc đẩy cải tiến linh hoạt. Tuy nhiên, một sprint thất bại đòi hỏi một loại tổng kết đặc biệt. Các định dạng chuẩn thường cảm giác như một bài kiểm tra có đánh dấu. Buổi họp này đòi hỏi sự an toàn tâm lý và sự tìm hiểu sâu sắc.
Trước buổi họp, người chủ sản phẩm đã thu thập dữ liệu. Đội được yêu cầu suy ngẫm cá nhân về điều gì đã diễn ra tốt và điều gì không. Điều này đảm bảo những thành viên lặng lẽ có thời gian suy nghĩ kỹ lưỡng.
Đội đã thảo luận về khái niệmlên kế hoạch năng lực. Họ nhận ra rằng họ đã cam kết 100% thời gian của mình cho các tính năng mới. Không còn khoảng trống nào cho những sự gián đoạn không thể tránh khỏi xảy ra trong môi trường hoạt động thực tế.
Họ cũng đã đề cập đếnĐịnh nghĩa về Hoàn thành. Hiện tại, ‘Hoàn thành’ có nghĩa là ‘Mã đã được viết’. Nó không bao gồm ‘Mã đã được kiểm tra’ hay ‘Bài kiểm thử đã được viết’. Sự khác biệt này đã gây ra điểm nghẽn vào cuối chu kỳ phát triển.
Biết được vấn đề chỉ là một nửa cuộc chiến. Kế hoạch phục hồi đòi hỏi phải thay đổi quy trình làm việc, kỳ vọng và tiêu chuẩn kỹ thuật.
Đội đã ngừng cam kết 100% số giờ sẵn có của họ. Họ đã áp dụng mộtchiến lược đệm.
Sự thay đổi này đã giảm áp lực phải đạt được các con số hoàn hảo và cho phép xử lý hợp lý các sự gián đoạn.
Đội đã cập nhậtbảng kiểm DoD. Một câu chuyện không thể di chuyển đến Hoàn thành mà không đáp ứng các tiêu chí này:
Điều này ngăn chặn nợ kỹ thuật tích tụ một cách im lặng. Nó đảm bảo rằng những gì được giao thực sự có thể sử dụng được.
Các kênh liên lạc với các nhà cung cấp bên ngoài đã được chính thức hóa. Đội ngũ hiện nay yêu cầu:
Đội ngũ đã đồng ý dành một đợt sprint mỗi quý để đặc biệt giảm nợ kỹ thuật. Điều này ngăn chặn hiệu ứng lãi kép của mã nguồn kém chất lượng. Nó gửi thông điệp đến các bên liên quan rằng sự ổn định là một tính năng, chứ không phải là sau khi hoàn thành.
Các thay đổi đã được triển khai ngay lập tức trong Sprint 43. Sự phục hồi không diễn ra tức thì, nhưng xu hướng đã thay đổi.
Đội ngũ không nhắm trở lại tốc độ cũ 30 điểm. Họ nhắm đến tính dự đoán được. Tốt hơn là cam kết ít hơn và giao hàng nhất quán hơn là cam kết quá nhiều rồi thất bại.
Để đảm bảo sự phục hồi được duy trì, đội đã theo dõi các chỉ số cụ thể trong ba tháng tiếp theo.
| Tuần | Mục tiêu Sprint đạt được | Số lượng lỗi | Tinh thần đội nhóm (1-5) |
|---|---|---|---|
| Tháng 1 | Có | 12 | 3 |
| Tháng 2 | Có | 8 | 4 |
| Tháng 3 | Có | 5 | 5 |
Dữ liệu cho thấy mối tương quan rõ rệt giữa những thay đổi quy trình và sức khỏe đội nhóm. Số lượng lỗi ít hơn dẫn đến căng thẳng giảm, từ đó cải thiện tinh thần làm việc.
Thất bại là người thầy. Dưới đây là những bài học rút ra từ nghiên cứu trường hợp này, áp dụng được cho mọi môi trường Agile.
Tốc độ mà không có sự ổn định là một ảo ảnh. Các đội nên ưu tiên giao hàng ổn định hơn là sản lượng thô. Các bên liên quan tin tưởng vào những đội có thể thực hiện đúng cam kết, ngay cả khi những cam kết đó nhỏ hơn.
Luôn lập kế hoạch cho những điều bất ngờ. Nếu bạn có 100 giờ khả dụng, hãy lập kế hoạch cho 70 giờ công việc. Thời gian còn lại sẽ hấp thụ những xung đột không thể tránh khỏi trong quá trình phát triển phần mềm.
DoD không phải là một gợi ý. Đó là một hợp đồng giữa đội và người sở hữu sản phẩm. Nếu một câu chuyện không đáp ứng DoD, thì nó không sẵn sàng để phát hành.
Khi chuyện đi sai, đội phải cảm thấy an toàn khi lên tiếng. Nếu các thành viên sợ bị trừng phạt, họ sẽ giấu vấn đề cho đến khi chúng trở thành khủng hoảng.
Phần mềm không tồn tại trong trạng thái trống rỗng. Các phụ thuộc vào dịch vụ bên thứ ba phải được quản lý với cùng mức độ nghiêm ngặt như mã nội bộ.
Nhiều đội cố gắng khắc phục thất bại bằng cách làm việc chăm chỉ hơn. Đây là một sai lầm phổ biến. Những hành động sau đây nên được tránh trong giai đoạn phục hồi.
Mục tiêu của Agile không chỉ là đưa mã ra sản phẩm, mà còn là xây dựng một hệ thống có thể đưa mã ra sản phẩm liên tục. Tốc độ bền vững là nền tảng của hệ thống này.
Sau khi phục hồi, đội đã thiết lập một nhịp độ cải tiến liên tục. Mỗi hai tuần, họ không chỉ đánh giá sprint, mà còn đánh giá tình trạng của quy trình làm việc. Họ đặt ra những câu hỏi như:
Việc giám sát liên tục này ngăn chặn những vấn đề nhỏ trở thành những thất bại lớn lần nữa.
Tính minh bạch với các bên liên quan là điều quan trọng. Khi một sprint thất bại, hãy thông báo sớm. Giải thích tác động, nguyên nhân và kế hoạch khắc phục. Điều này xây dựng niềm tin.
Các bên liên quan thường coi một sprint thất bại là dấu hiệu thiếu năng lực. Khi được giải thích như một điểm dữ liệu để cải tiến, nó trở thành minh chứng cho sự trưởng thành chuyên nghiệp. Họ ưu tiên một đội biết thừa nhận vấn đề và khắc phục nó hơn là một đội che giấu vấn đề.
Việc thất bại là điều bình thường. Tỷ lệ bỏ sót 10% thường được chấp nhận tùy theo lĩnh vực. Tỷ lệ bỏ sót cao liên tục cho thấy vấn đề lập kế hoạch hệ thống.
Thông thường là không. Dừng sprint sẽ lãng phí thời gian đã bỏ ra. Tốt hơn hết là hoàn thành những gì có thể và khởi động lại cho chu kỳ tiếp theo.
Có, nếu tốc độ của bạn bị thổi phồng một cách giả tạo do cam kết quá mức. Giảm tốc độ xuống mức thực tế sẽ cải thiện độ chính xác và tính dự đoán.
Các giải pháp tạm thời là khả thi, nhưng phục hồi dài hạn đòi hỏi thay đổi quy trình. Nếu không, thất bại sẽ lặp lại.
Agile là hành trình thích nghi. Một cuộc sprint thất bại không phải là điểm kết thúc; đó là một biển chỉ dẫn chỉ hướng đến các phương pháp tốt hơn. Bằng cách phân tích sâu sắc nguyên nhân thất bại và thực hiện những thay đổi cấu trúc, các đội có thể trở nên mạnh mẽ và kiên cường hơn.