Tôi nghĩ nó đúng, trong một số môi trường, Agile được sử dụng như một cái cớ để không có kỷ luật. Vấn đề thực sự là chúng ta đã đánh mất lý do tại sao chúng ta có bất kỳ phương pháp nào. Cá nhân, tôi cảm thấy phương pháp luận là một vấn đề kiến trúc theo nghĩa là kiến trúc của hệ thống phải giải quyết các thuộc tính chất lượng, không chức năng, phương pháp nên giải quyết một số thuộc tính tương tự (khả năng duy trì, năng suất phát triển, chuyển giao kiến thức, et al.)
Xem phương pháp luận như một điều khiển cho các thuộc tính quy trình ngụ ý một số điều: 1) không có số liệu, chúng ta không thể so sánh hiệu quả của phương pháp này với phương pháp khác, 2) cần đưa ra quyết định chủ động về những thuộc tính nào quan trọng (thời gian giao hàng so với mã chất lượng so với chuyển giao kiến thức).
Không có cả số liệu và mục tiêu hữu hình, chúng tôi chỉ cần chọn một phương pháp là "chiếc lông ma thuật" mà nếu chúng tôi giữ chặt, chúng tôi sẽ có thể cung cấp phần mềm.
Bây giờ những người nói về Agile, XP, Scrum, v.v. nói về sự mong manh của thể loại phương pháp cụ thể đó. Đối số là: tại sao sử dụng một phương pháp có thể bị phá hoại bởi một cá nhân thiếu kỷ luật để tuân theo tất cả các quy tắc? Câu hỏi là một câu hỏi hợp lệ; tuy nhiên, đó là triệu chứng, không phải nguyên nhân. Nếu một bộ số liệu chính xác và có ý nghĩa (đó là phần cứng) được xác định, kiểm tra và phản hồi kịp thời được đưa ra, tôi nghĩ chúng ta sẽ khám phá ra phương pháp cụ thể ít liên quan đến thành công. (Nói một cách ngẫu nhiên tôi đã thấy các dự án thành công khi sử dụng vô số phương pháp và gấp đôi số lần thất bại khi sử dụng cùng một phương pháp)
Vậy các số liệu là gì? Họ thay đổi từ dự án để dự án, nhóm này sang nhóm khác, và theo thời gian. Hữu ích khi lịch trình giao hàng là quan trọng, một điều mà cá nhân tôi đã sử dụng là kỹ năng và chất lượng ước tính. Hầu hết các nhà phát triển có thể ước tính chính xác các nhiệm vụ kéo dài một tuần hoặc ít hơn. Vì vậy, một cách tiếp cận là chia dự án thành các nhiệm vụ kéo dài một tuần của nhà phát triển và theo dõi ai đã thực hiện ước tính. Khi dự án đi cùng, họ có thể thay đổi ước tính của họ. Sau khi một nhiệm vụ hoàn thành, nếu nó giảm hơn 10% (1/2 mỗi ngày), chúng tôi coi đây là lỗi - chúng tôi xác định lý do tại sao ước tính bị tắt (nghĩa là bảng cơ sở dữ liệu không được xem xét), xác định hành động khắc phục (nghĩa là liên quan đến DBA trong dự toán), và sau đó tiếp tục. Sử dụng thông tin này, chúng tôi có thể tạo các số liệu như # lỗi ước tính mỗi tuần, # lỗi cho mỗi nhà phát triển,
Vậy thì sao? Đó là khi các phương pháp ra đời - nếu bạn có một mô hình dự đoán không đáp ứng được các phẩm chất của quy trình, bạn có thể chọn thêm hoặc xóa một số khía cạnh của phương pháp và xem nó ảnh hưởng đến mô hình của bạn như thế nào. Cấp, không ai muốn chơi với một quá trình phát triển vì sợ thất bại, nhưng chúng ta đã thất bại ở một tỷ lệ cao và có thể dự đoán được. Bằng cách thực hiện các thay đổi riêng lẻ và đo lường kết quả, bạn có thể thấy rằng Agile là phương pháp hoàn hảo cho nhóm của bạn, nhưng bạn có thể dễ dàng tìm thấy RUP, thác nước, hoặc chỉ là nơi trú ẩn của các thực tiễn tốt nhất là lý tưởng.
Vì vậy, đề xuất của tôi là hãy ngừng lo lắng về những gì chúng ta gọi là quy trình, đặt các kiểm tra phù hợp với mục tiêu của quy trình phát triển của chúng tôi và thử nghiệm các kỹ thuật khác nhau để cải thiện quy trình đó.
