https://images.viblo.asia/29b87667-33ee-4c28-9fa4-a4385757eb06.jpg

Vào tháng 5, tôi có tham dự hội nghị thử nghiệm phần mềm đầu tiên của tôi ở tại StarEast ở Orlando. Tôi đã trải qua hầu hết các buổi học, ghi chép - đó là lý do tại sao tôi cảm thấy giật mình khi diễn giả đầu tiên của ngày nói điều gì đó giống như đập vào tôi cái cách nghĩ sai lầm.

Diễn giả bắt đầu với một tổng quan ngắn gọn về công ty và sau đó đề cập đến quy trình Agile của công ty. Những gì tôi nghe được là: "Chúng tôi sử dụng Scrum. Và chúng tôi ghi lại quá trình của chúng tôi, và chúng tôi lặp lại nó."

Phản ứng đầu tiên của tôi là, "Tôi vừa nghe những gì vậy ?" Ergo, họ đang nói về "Agile "??? Hay có một điều gì đó trong câu nói ngụ ý đó đơn giản là nói không cần tính toán.

Việc phát triển thác nước đã diễn ra từ năm 1970. Quy trình thác nước tuân theo một quá trình gia tăng lặp lại. Mô hình này cũng được ghi nhận rất nhiều nhưng nó không phải là Agile. Nó không có khả năng thích ứng.

Rõ ràng là một số người vẫn không biết Agile là gì? "Agile" đã trở thành từ "A" khác (gợi ý: Automation). Mọi người nói về phát triển phần mềm Agile như là cách để chữa trị mọi thứ, mà không biết nó thực sự có ý nghĩa gì. Chúng ta đã đi lạc nguồn gốc của Tuyên ngôn Agile, và nhanh chóng biến thành một thứ được sử dụng và lạm dụng bởi các nhân viên bán hàng để bán như một sản phẩm, chứ không phải là một tư duy.

Mọi người rất tập trung vào việc trở thành Agile mà đã quên mục tiêu thực sự : cung cấp chất lượng cho khách hàng. Làm thế nào để giữ được mục tiêu này ???

Những kinh nghiệm Agile của tôi

Hiểu biết đầu tiên của tôi về Agile xuất hiện vào năm 2011. Nhóm của tôi đã theo dõi rất nhiều quy trình Agile tiêu chuẩn: chạy nước rút trong hai tuần, các cuộc họp standup hàng ngày,làm mượt backlog, retro và lập kế hoạch. Tôi sớm hiểu được rằng chúng tôi đã bỏ lỡ một nguyên lý chính: các nhóm tự tổ chức. Chúng tôi đã chuyển đến một tòa nhà hoàn toàn mới, nơi văn phòng có thể được thiết lập và trang trí theo mọi cách, nhưng quyết định đã được thực hiện để đi đến : một mô hình cube farm lập phương chuẩn.

Trong vòng một vài tháng, ban quản lý đã quyết định phá bỏ các cube farm lập phương hình khối ở hầu hết các khu vực, hạ các bức tường giữa các team và làm gián đoạn nghiêm trọng công việc phát triển - ủng hộ khái niệm văn phòng mở. Điều này đã xảy ra mà không cần tham khảo ý kiến bất cứ ai trong nhóm Scrum của chúng tôi.

Những gì chúng tôi nhận được là Agile-trong-một-hộp. Quản lý chỉ có một ý tưởng rằng Agile là gì và nó mang lại những coaches agiel đã bán công ty chính xác như những gì họ nghĩ rằng nó cần thiết.

Trong kinh nghiệm Agile tiếp theo của tôi, tôi đã làm việc trên một nhóm sản phẩm với nhiều nhóm Scrum làm việc trên các lĩnh vực khác nhau của cùng một sản phẩm. Chúng tôi đã phát hành hàng tuần, giữ cho mỗi đội Scrum trên cùng một lịch trình.

Mặc dù khả năng cho mỗi nhóm để cung cấp những thay đổi một cách độc lập, chúng tôi đã không được phép làm như vậy. Điều gì xảy ra tiếp theo là hoàn toàn có thể đoán trước được.

Vòng đời Release sẽ bắt đầu vào đầu mỗi tuần, với một chu kỳ kiểm tra hồi qui được lên kế hoạch bởi mỗi nhóm trước khi triển khai đến sản xuất. Một nhóm sẽ phát hiện ra một khiếm khuyết có thể ngăn chặn mọi nhóm khác có thể Release những thay đổi của họ. Điều này ngăn cản chúng tôi phát hành những thay đổi nhỏ thường xuyên hơn, và thay vào đó buộc chúng tôi phải phát hành phiên bản lớn hơn với nhiều rủi ro hơn, một trong những điều mà quy trình Agile được dự định tránh.

Mục đích của Agile

Vì vậy, mục đích của sự nhanh nhẹn là gì? Agile không có nghĩa là không có tài liệu, hoặc không có kế hoạch. Agile không phải là về lặp lại. Iteration là một phương pháp, không phải là một mục tiêu. Chúng ta lặp lại để thích nghi.

Agile là về việc có thể thích nghi với nhu cầu thay đổi của khách hàng một cách nhanh chóng. Đó là về việc nhận phản hồi nhanh từ khách hàng - người coi trọng nhất về chất lượng. Chất lượng có nghĩa là những thứ khác nhau cho những người khác nhau, nhưng trong bối cảnh này tôi thích định nghĩa từ Alan Page và Brent Jensen trên podcast Thử nghiệm AB: Chất lượng là một vấn đề được giải quyết cho khách hàng.

Đối với những người tham gia phát triển phần mềm: Bạn không phải là khách hàng. Điều quan trọng là phải tìm hiểu về khách hàng, để hiểu khách hàng, nhưng bạn sẽ không bao giờ là khách hàng. Đây là lý do tại sao việc cung cấp thay đổi thường xuyên cho khách hàng là rất quan trọng, để nhận phản hồi nhanh và biết rằng bạn đã xây dựng đúng thứ, không chỉ đơn thuần là xây dựng thứ gì đó hoạt động.

Có một câu chuyện mà nhóm của tôi đã làm việc trong lần tiếp cận đầu tiên của tôi về Agile đã không đi đúng. Chúng tôi đã thảo luận câu chuyện trong cuộc họp làm sạch backlog của chúng tôi, nhà phát triển đã viết code để phù hợp với yêu cầu và tôi đã xác minh rằng code đã hoạt động mà không có lỗi. Chúng tôi demo story cho Product owner- đã ngay lập tức nói với chúng tôi rằng chúng tôi đã xây dựng một điều sai lầm.

Chúng tôi đã làm đúng mọi thứ - chúng tôi đã xác minh tính chính xác của code — nhưng chúng tôi đã không xây dựng mọi thứ đúng . Chúng tôi đã không cung cấp giải pháp chính xác cho khách hàng. May mắn thay, đó chỉ là một story duy nhất trong vòng hai tuần chạy nước rút của chúng tôi, và chúng tôi có thể nhanh chóng thích ứng và thực hiện thay đổi cần thiết.

Việc đuổi theo chất lượng

Tôi đã xem một phiên tuyệt vời gần đây từ hội nghị StarWest 2011, được trình bày bởi Tiến sĩ James Whittaker và có tiêu đề "Tất cả những thử nghiệm đó đang bắt đầu theo cách chất lượng". Anh ấy đã nói rất nhiều về thử nghiệm, nhưng bài học lớn hơn của anh ấy là: "Đừng lãng phí thời gian của bạn để làm những thứ không quan trọng."

Khách hàng không quan tâm:

• Process bạn apply
• Bạn ngồi ở đâu
• Team làm việc tập trung hay một số người remote làm việc
• Bạn stand up bao nhiêu lần
• Bạn có bao nhiêu team
• Code của bạn và cách bạn viết nó
• Kế hoạch kiểm thử hoặc trường hợp kiểm thử của bạn
• Báo cáo lỗi của bạn

Khách hàng chỉ quan tâm đến phần mềm thực sự được deliever . Nếu nó không được deliever , nó không có giá trị đối với khách hàng.

StarEast là một lời nhắc nhở rằng buzzwords quan trọng hơn những gì các nhóm phát triển đang cố gắng hoàn thành: tìm cách để giải quyết các vấn đề của khách hàng và cung cấp các giải pháp nhanh hơn. Quên về việc bạn đang theo Agile,lean , XP, DevOps, BDD / TDD hay sự kết hợp của những thứ đó.

Thay vào đó, lấy lời khuyên này từ George S. Patton:

"Nếu bạn nói với mọi người đi đâu, nhưng không phải cách đến đó, bạn sẽ ngạc nhiên trước kết quả."

Kết quả tốt nhất cho khách hàng là một vấn đề được giải quyết. Đó là chất lượng thực sự có ý nghĩa. Hãy tập trung vào đó

https://techbeacon.com/forget-about-agile-keep-focus-quality