Tôi không có bất kỳ tài liệu nghiên cứu hoặc số liệu thống kê nào để cung cấp cho bạn, nhưng tôi sẽ liên quan đến kinh nghiệm của mình khi làm việc trong một nhóm / tổ chức có lịch sử kiểm tra đơn vị từ thấp đến trung bình và không có kiểm tra từ đầu đến cuối, và dần dần di chuyển quán bar đến nơi chúng ta đang ở hiện tại, với nhiều ATDD hơn (nhưng, trớ trêu thay, không phải cách tiếp cận TDD truyền thống).
Cụ thể, đây là cách các mốc thời gian dự án được sử dụng để chơi (và vẫn diễn ra trên các đội / sản phẩm khác trong cùng một tổ chức):
- Lên đến 4 tuần phân tích và thực hiện
- 2 tuần thử nghiệm hồi quy, sửa lỗi, ổn định và chuẩn bị phát hành
- 1-2 tuần sửa chữa các khuyết tật đã biết
- 2-3 tuần dọn dẹp mã và các vấn đề / hỗ trợ sau sản xuất (lỗi không xác định / mất điện ngoài dự kiến)
Điều này có vẻ như vô lý trên đầu nhưng nó thực sự rất phổ biến, nó chỉ thường bị che dấu trong nhiều tổ chức do thiếu QA hoặc không hiệu quả. Chúng tôi có những người kiểm tra tốt và có văn hóa kiểm tra chuyên sâu, vì vậy những vấn đề này được phát hiện sớm và được khắc phục trước (hầu hết thời gian), thay vì được phép diễn ra từ từ trong suốt nhiều tháng / năm. Chi phí bảo trì 55-65% thấp hơn hơn định mức được chấp nhận phổ biến là 80% thời gian dành cho gỡ lỗi - điều này có vẻ hợp lý, bởi vì chúng tôi đã có một số thử nghiệm đơn vị và các nhóm chức năng chéo (bao gồm cả QA).
Trong lần phát hành sản phẩm mới nhất của nhóm chúng tôi, chúng tôi đã bắt đầu trang bị thêm các bài kiểm tra chấp nhận nhưng họ không hoàn toàn ngớ ngẩn và chúng tôi vẫn phải dựa vào rất nhiều thử nghiệm thủ công. Việc phát hành có phần ít đau đớn hơn những người khác, IMO một phần vì các thử nghiệm chấp nhận khó hiểu của chúng tôi và một phần vì độ bao phủ thử nghiệm đơn vị rất cao của chúng tôi so với các dự án khác. Tuy nhiên, chúng tôi vẫn dành gần 2 tuần cho hồi quy / ổn định và 2 tuần cho các vấn đề hậu kỳ.
Ngược lại, mọi bản phát hành kể từ lần phát hành đầu tiên đó đều có các tiêu chí chấp nhận và kiểm tra chấp nhận sớm, và các lần lặp hiện tại của chúng tôi trông như thế này:
- 8 ngày phân tích và thực hiện
- 2 ngày ổn định
- 0-2 ngày kết hợp hỗ trợ sau sản xuất và dọn dẹp
Nói cách khác, chúng tôi đã tăng từ 55-65% chi phí bảo trì lên 20-30% chi phí bảo trì. Cùng một đội, cùng một sản phẩm, sự khác biệt chính là sự cải tiến tiến bộ và hợp lý hóa các bài kiểm tra chấp nhận của chúng tôi.
Chi phí duy trì chúng là, mỗi lần chạy nước rút, 3-5 ngày cho nhà phân tích QA và 1-2 ngày cho nhà phát triển. Nhóm của chúng tôi có 4 nhà phát triển và 2 nhà phân tích QA, vì vậy (không tính UX, quản lý dự án, v.v.) đó là tối đa 7 ngày làm việc trong số 60, mà tôi sẽ làm tròn 15% chi phí triển khai chỉ để thực hiện mặt an toàn.
Chúng tôi dành 15% cho mỗi giai đoạn phát hành để phát triển các thử nghiệm chấp nhận tự động và trong quá trình này có thể cắt giảm 70% mỗi lần phát hành để thực hiện kiểm tra hồi quy và sửa các lỗi tiền sản xuất và hậu sản xuất.
Bạn có thể nhận thấy rằng dòng thời gian thứ hai chính xác hơn và cũng ngắn hơn nhiều so với dòng đầu tiên. Đó là điều có thể thực hiện được nhờ các tiêu chí chấp nhận và kiểm tra chấp nhận trước mắt, bởi vì nó đơn giản hóa rất nhiều "định nghĩa hoàn thành" và cho phép chúng tôi tự tin hơn nhiều về tính ổn định của bản phát hành. Không có đội nào khác (cho đến nay) đã thành công với lịch phát hành hai tuần một lần, ngoại trừ có lẽ khi thực hiện các bản phát hành bảo trì khá tầm thường (chỉ có lỗi, v.v.).
Một tác dụng phụ thú vị khác là chúng tôi đã có thể điều chỉnh lịch phát hành của mình theo nhu cầu kinh doanh. Một lần, chúng tôi phải kéo dài khoảng 3 tuần để trùng với bản phát hành khác và có thể làm như vậy trong khi cung cấp nhiều chức năng hơn nhưng không mất thêm thời gian để thử nghiệm hoặc ổn định. Một lần khác, chúng tôi phải rút ngắn nó xuống còn khoảng 1 tuần, do ngày nghỉ và xung đột tài nguyên; chúng tôi đã phải đảm nhận công việc phát triển ít hơn, nhưng, như mong đợi, có thể dành ít thời gian tương ứng để thử nghiệm và ổn định mà không đưa ra bất kỳ khiếm khuyết mới nào.
Vì vậy, theo kinh nghiệm của tôi, các thử nghiệm chấp nhận, đặc biệt là khi được thực hiện rất sớm trong một dự án hoặc chạy nước rút và khi được duy trì tốt với các tiêu chí chấp nhận được viết bởi Chủ sở hữu sản phẩm, là một trong những khoản đầu tư tốt nhất bạn có thể thực hiện. Không giống như TDD truyền thống, điều mà những người khác chỉ ra một cách chính xác được tập trung nhiều hơn vào việc tạo mã có thể kiểm tra hơn là mã không có lỗi - ATDD thực sự giúp bắt lỗi nhanh hơn rất nhiều ; đó là tổ chức tương đương với việc có một đội quân thử nghiệm thực hiện kiểm tra hồi quy hoàn chỉnh mỗi ngày, nhưng rẻ hơn.
ATDD sẽ giúp bạn trong các dự án dài hạn được thực hiện theo kiểu RUP hoặc (ugh) Waterfall, các dự án kéo dài 3 tháng trở lên? Tôi nghĩ rằng bồi thẩm đoàn vẫn ra về điều đó. Theo kinh nghiệm của tôi, rủi ro lớn nhất và xấu nhất trong các dự án dài hạn là thời hạn không thực tế và yêu cầu thay đổi. Thời hạn không thực tế sẽ khiến mọi người thực hiện các phím tắt, bao gồm các phím tắt thử nghiệm và những thay đổi đáng kể đối với các yêu cầu có thể sẽ làm mất hiệu lực một số lượng lớn các thử nghiệm, yêu cầu chúng phải được viết lại và có khả năng làm tăng chi phí thực hiện.
Tôi khá chắc chắn rằng ATDD có một khoản tiền tuyệt vời cho các mô hình Agile hoặc cho các nhóm không chính thức Agile nhưng có lịch phát hành rất thường xuyên. Tôi chưa bao giờ thử nó trong một dự án dài hạn, chủ yếu là vì tôi chưa bao giờ tham gia hoặc thậm chí nghe nói về một tổ chức sẵn sàng thử nó trong loại dự án đó, vì vậy hãy từ chối trách nhiệm tiêu chuẩn ở đây. YMMV và tất cả những thứ đó.
PS Trong trường hợp của chúng tôi, không có thêm nỗ lực nào từ "khách hàng", nhưng chúng tôi có Chủ sở hữu sản phẩm toàn thời gian, tận tâm, người thực sự viết các tiêu chí chấp nhận. Nếu bạn đang kinh doanh trong lĩnh vực "tư vấn", tôi nghi ngờ việc người dùng cuối viết các tiêu chí chấp nhận hữu ích sẽ khó khăn hơn rất nhiều . Chủ sở hữu sản phẩm / Giám đốc sản phẩm có vẻ như là một yếu tố khá cần thiết để thực hiện ATDD và mặc dù tôi có thể một lần nữa chỉ nói từ kinh nghiệm của chính mình, tôi chưa bao giờ nghe nói về ATDD được thực hành thành công mà không có ai thực hiện vai trò đó.
