Chi phí trì hoãn lâu hơn giữa phát triển và QA

Ở vị trí hiện tại của tôi, QA đã trở thành nút cổ chai. Chúng tôi đã có sự xuất hiện đáng tiếc của các tính năng được đưa ra khỏi bản dựng hiện tại để QA có thể hoàn thành thử nghiệm. Điều này có nghĩa là các tính năng được thực hiện đang được phát triển có thể không được kiểm tra trong 2-3 tuần sau khi nhà phát triển đã chuyển sang. Với dev di chuyển nhanh hơn QA, khoảng cách thời gian này sẽ chỉ lớn hơn.

Tôi tiếp tục lướt qua bản sao Code Complete của mình, tìm kiếm một đoạn "Dữ liệu cứng" cho thấy chi phí sửa lỗi tăng theo cấp số nhân khi nó tồn tại lâu hơn. Ai đó có thể chỉ cho tôi một số nghiên cứu sao lưu khái niệm này? Tôi đang cố gắng thuyết phục các thế lực rằng nút cổ chai QA tốn kém hơn nhiều so với họ nghĩ.

Bạn không cần bất kỳ tài liệu tham khảo, IMHO. Đây là những gì bạn có thể ( nên làm):

Định lượng chi phí của sự chậm trễ! Giả sử rằng phải mất 1 tuần để kiểm tra (các) tính năng. Trì hoãn 2-3 tuần ngụ ý rằng tính năng này sẽ không khả dụng cho đến ít nhất là tuần thứ 4. Và điều đó cũng giả sử thành công 100%. Thêm thời gian sửa chữa của một tuần khác để chậm khoảng 5 tuần.

Bây giờ, nếu có thể hãy truy cập vào thời hạn dự kiến ​​của dự án / tính năng. Bởi khi nào khách hàng mong đợi nó? Nó sẽ trượt? Nếu không, những người khác sẽ trượt như một hệ quả? Vì vậy, kết quả của việc "phát hành" sẽ bị trì hoãn bao nhiêu?

'Chi phí cho công ty' cho bản phát hành đó là bao nhiêu, khách hàng mong đợi lợi nhuận bao nhiêu từ bản phát hành đó? Nếu họ mong đợi $ 5200 / năm lợi nhuận từ bản phát hành đó thì mỗi tuần trượt sẽ khiến họ mất 100 đô la doanh thu. Đó là quan điểm của khách hàng. Bạn có thể có hoặc không có quyền truy cập vào dữ liệu này nhưng đáng để xem xét và nêu rõ sự chậm trễ có thể ảnh hưởng đến mối quan hệ như thế nào.

Bây giờ, những gì mất mát cho các nhà phát triển? Khi nhà phát triển chuyển sang các tính năng khác, bạn yêu cầu anh ấy / cô ấy phá vỡ chu kỳ của họ và 'sửa chữa' tính năng trước đó. Mất thời gian / công sức là gì? Chuyển đổi nó thành chi phí cho công ty bằng cách sử dụng tiền lương làm bội số cho mỗi giờ lãng phí. Bạn có thể sử dụng số đó để nói số tiền "lợi nhuận / doanh thu" mà chất thải đang "ăn vào".

Những gì bạn đã vấp ngã có thể được định lượng một cách thuận tiện bằng cách sử dụng "Chi phí trì hoãn" - được Don Reinerstein ủng hộ trong Nguyên tắc phát triển sản phẩm và cũng bởi Dean Leffingwell trong Yêu cầu phần mềm Agile. Bạn có thể ủng hộ mọi yêu sách như vậy bởi các yếu tố kinh tế để thuyết phục 'quyền lực cao hơn' có ngôn ngữ chính là $$ - bạn phải nói ngôn ngữ của họ để thuyết phục họ :)

Con thú may mắn! (ý định chơi chữ :)

Tôi thực sự không nghĩ rằng Code Complete là tài nguyên phù hợp với bạn ở đây. Đây không phải là vấn đề về mã, nó là vấn đề về quy trình và có thể là vấn đề quản lý.

Nếu một phần trong quy trình của bạn đặc biệt yếu, thì đã đến lúc bạn cần phải vượt qua Lý thuyết về các ràng buộc :

1. Xác định các ràng buộc.

   Điều này có nghĩa là tìm ra phần chậm nhất hoặc kém hiệu quả nhất của quá trình tổng thể. Trong trường hợp của bạn, nó đang thử nghiệm. Nhưng phần nào của bài kiểm tra? Là nó:

   • Chuẩn bị môi trường thử nghiệm?
   • Xác định những gì để kiểm tra?
   • Chức năng (chấp nhận) xét nghiệm?
   • Kiểm tra hồi quy?
   • Thử nghiệm thăm dò?
   • Báo cáo lỗi / lỗi từ các bài kiểm tra?
   • Xác định các bước để tái tạo một lỗi?
   • Làm rõ từ các nhà phát triển hoặc quản lý dự án?
   • Khắc phục các sự cố được tìm thấy trong giai đoạn QA?

   Đây là tất cả các vấn đề rất khác nhau và kêu gọi các giải pháp khác nhau. Bạn cần phải quyết định cái nào là tốn kém / quan trọng nhất. Việc chứng minh điều đó cho quản lý không nên khó, vì tất cả các hoạt động trên đều tốn thời gian (tiền AKA) và chỉ một vài trong số đó là thời gian giá trị gia tăng.

2. Khai thác các ràng buộc.

   Nói cách khác, tối ưu hóa xung quanh quá trình ràng buộc. Đừng bao giờ để người kiểm tra nhàn rỗi. Điều này về cơ bản là:

   • Đưa người kiểm tra vào các nhóm phát triển, nếu họ chưa có, do đó, có một vòng phản hồi liên tục với các nhà phát triển.
   • Có triển khai thử nghiệm thường xuyên, vì vậy luôn có một cái gì đó mới / cố định để thử nghiệm.
   • Làm cho giao tiếp nhanh hơn và thường xuyên hơn. Ví dụ, ủng hộ nhắn tin tức thì qua các chủ đề email.
   • Đảm bảo rằng người kiểm tra có sẵn các công cụ tốt nhất (máy nhanh, nhiều màn hình, theo dõi lỗi được sắp xếp hợp lý, v.v.)

   Giai đoạn này không phải là tối ưu hóa quá trình thử nghiệm (chưa), mà là về việc giảm chi phí. Đừng lãng phí thời gian của người kiểm tra. Loại bỏ thời gian thực sự lãng phí cũng nên dễ dàng bán cho ban quản lý.

3. Cấp dưới các hoạt động khác để hạn chế.

   Tại thời điểm này, những người thử nghiệm có năng suất cao nhất có thể một mình, vì vậy chúng tôi cần bắt đầu vay năng suất từ ​​các lĩnh vực khác:

   • Hướng dẫn các nhà phát triển và nhân viên vận hành ưu tiên cho người thử nghiệm, bất kể họ đang làm gì.
   • Nếu bạn không có các nhóm chức năng chéo, hãy đặt phòng họp mỗi ngày vào thời gian định sẵn để người kiểm tra không bao giờ phải lãng phí thời gian để cố gắng đặt phòng.
   • Chuyển một số phần trăm lớn hơn của nhà phát triển (và có thể hoạt động) ra khỏi công việc tính năng; ví dụ: tập trung vào sửa lỗi, nợ / tái cấu trúc công nghệ, xem xét mã và kiểm tra đơn vị.
   • Kiểm tra liên tục và tăng dần - không phát triển trong 3 tuần và sau đó chuyển nó cho người kiểm tra. Yêu cầu các nhà phát triển làm việc để làm cho mã của họ có thể kiểm tra ngay lập tức, ví dụ như với các giàn giáo hoặc UI nguyên mẫu.

4. Nâng cao các ràng buộc.

   Nếu những người thử nghiệm đang làm việc hết công suất - cả về năng suất và chi phí tối thiểu - và vẫn chưa đủ nhanh, thì bạn cần bắt đầu đầu tư nhiều hơn vào thử nghiệm.

   • Nếu bạn dựa vào việc triển khai thử nghiệm thủ công, hãy tự động hóa nó thông qua việc sử dụng các tập lệnh quản lý cấu hình và tích hợp liên tục.
   • Nếu các kế hoạch kiểm tra mất nhiều thời gian để tạo, hãy làm việc để có được các tiêu chí chấp nhận tốt hơn (tức là ĐẦU TƯ ). Hầu hết các tổ chức ban đầu rất xấu về điều này.
   • Nếu các bài kiểm tra chấp nhận mất quá nhiều thời gian, hãy bắt đầu tự động hóa chúng. Sử dụng một công cụ như Cucumber hoặc FitNesse hoặc viết các bài kiểm tra loại xUnit nếu bạn phải. Ngoài ra còn có Selenium, Watij và các công cụ tự động hóa trình duyệt khác nếu quá trình kiểm tra giao diện người dùng mất nhiều thời gian.
   • Nếu kiểm tra hồi quy mất quá nhiều thời gian, hãy tự động hóa quá. Nếu không thể tự động hóa, hãy tập trung vào việc cải thiện chất lượng ngoài cổng, tức là chú trọng hơn nữa vào việc xem xét mã, kiểm tra đơn vị, công cụ phân tích tĩnh, v.v. Các nhà phát triển nên khá tự tin rằng có rất ít lỗi thực tế trước khi vượt qua đến QA (lỗi sản phẩm là một câu chuyện khác).
   • Nếu thử nghiệm thăm dò là nút cổ chai, bạn có khả năng trì hoãn một số trong số đó cho đến sau khi phát hành hoặc ký hợp đồng với một công ty thử nghiệm để thực hiện những việc song song cao như thử nghiệm cùng một quy trình trong nhiều trình duyệt.
   • Nếu người kiểm tra không thể sửa chữa nhiều lỗi, hãy xem xét xây dựng môi trường kiểm tra năng lực để có thể bắt đầu tái tạo các lỗi không liên tục. Hoặc, hãy thử chạy các bài kiểm tra chấp nhận tự động của bạn song song và liên tục, cả ngày, giữ nhật ký chi tiết.
   • Nếu mất quá nhiều thời gian để sửa lỗi, thì hãy bắt đầu phân vùng các dự án của bạn và / hoặc nghiêm túc xem xét việc nghiên cứu lại các giải pháp của bạn. Hoặc, thay thế, không sửa một số trong số họ; không phải mọi lỗi đều nghiêm trọng, bạn sẽ có thể ưu tiên chúng cùng với công việc tính năng.
   • Nếu vẫn thất bại, thuê thêm người thử nghiệm.

5. Quay trở lại Bước 1.

Tôi muốn nói rằng đây là tất cả lẽ thường, nhưng tiếc là nó không, ít nhất là không phải trong hầu hết các tổ chức. Nếu bạn đang nhận được nhiều sự phản kháng từ ban quản lý, một kỹ thuật vô giá là Ánh xạ dòng giá trị (một kỹ thuật từ sản xuất tinh gọn), bạn có thể sử dụng để hiển thị bao nhiêu thời gian và do đó tiền thực sự bị lãng phí mỗi ngày bởi một ứng cử viên phát hành không thể để chuyển sang giai đoạn tiếp theo. Chi phí cơ hội là khó hiểu nhưng đây là một trong những cách tốt nhất tôi đã tìm thấy để hình dung và chứng minh nó.

Và nếu không có cái nào hoạt động ... thì có lẽ bạn đang ở trong một công ty không hoạt động, hãy ra ngoài trước khi quá muộn!

Nhưng bạn sẽ không giải quyết vấn đề này đơn giản bằng cách bỏ một vài tờ giấy trên bàn của người quản lý và yêu cầu họ ném tiền vào vấn đề, bởi vì họ sẽ cho rằng (chính xác) rằng ném tiền vào nó có thể không thực sự giải quyết được, và thậm chí có thể làm nó tệ hơn Bạn cần cung cấp giải pháp , và đó là những gì câu trả lời này là về. Nếu bạn giới thiệu vấn đề là "đây là danh sách các cách chúng ta có thể bắt đầu giải quyết vấn đề này, theo thứ tự giảm dần chi phí / lợi ích" thay vì "chúng tôi cần nhiều người thử nghiệm hơn", thì bạn sẽ có nhiều thành công hơn.

Trang 29 và 30 có thể có dữ liệu bạn đang tìm kiếm, mặc dù có thể cần phải theo dõi.

Tôi sẽ xem xét nghiên cứu được đề cập trong câu này trên trang 30:

Hàng chục công ty đã phát hiện ra rằng chỉ cần tập trung vào việc sửa chữa các khiếm khuyết sớm hơn là sau này trong một dự án có thể cắt giảm chi phí và lịch trình phát triển theo các yếu tố từ hai trở lên (McConnell 2004).

BTW, chính câu hỏi của bạn đã khiến tôi chọn cuốn sách một lần nữa để làm mới nó :-)

Những gì bạn đang mô tả là một nút cổ chai trong một quy trình. Lý thuyết tinh gọn nói rằng sẽ luôn có một nút cổ chai trong một quy trình, nhưng mức độ nghiêm trọng của nó có thể rất khác nhau. Nếu QA thuê thêm, thì sự phát triển có thể trở thành nút cổ chai.

Để hiểu chi phí, hãy tưởng tượng tình huống sau đây. Bạn đã chọn một trong những nhà phát triển. Công việc của anh ta sẽ không bao giờ được Đảm bảo Chất lượng, nhưng luôn bị xếp hàng vô thời hạn. Hãy tưởng tượng rằng, điều này có nghĩa là QA có thể đảm bảo chất lượng cho công việc của các nhà phát triển còn lại một cách kịp thời và sẽ không có chi phí trì hoãn.

Trong kịch bản đó, chi phí của sự chậm trễ là chi phí tiền lương của nhà phát triển, bởi vì công việc của anh ta sẽ bị lãng phí.

Lý do tại sao tôi tranh luận về chi phí chứ không phải giá trị do quá trình tạo ra, đơn giản là vì khó ghi lại giá trị của một quy trình, mặc dù nó tốt hơn nhiều.

Tôi tiếp tục lướt qua bản sao Code Complete của mình, tìm kiếm một đoạn "Dữ liệu cứng" cho thấy chi phí sửa lỗi tăng theo cấp số nhân khi nó tồn tại lâu hơn. Ai đó có thể chỉ cho tôi một số nghiên cứu sao lưu khái niệm này?

Chi phí theo cấp số nhân của việc tìm kiếm một lỗi dường như được dựa trên một nghiên cứu của NIST . Nghiên cứu là một cuộc khảo sát giả định các giai đoạn thác nước khác nhau:

Software Development Stage         | Cost
-----------------------------------+------
Requirements and Design            | 1X
Code and Unit Testing              | 5X
Integration and System Testing     | 10X
Beta Testing                       | 15X
Post Release                       | 30X

( bảng ở đây từ đây )

Một trong những mục tiêu của các phương pháp phát triển phần mềm Agile là loại bỏ các giai đoạn riêng biệt này và giảm các chi phí này. Các số liệu không áp dụng khi sử dụng các phương pháp khác để thác nước.

Thực tế của bạn không phải là với QA, trên thực tế, nếu QA của bạn đang thực hiện Kiểm tra, sự chậm trễ là điều ít lo lắng nhất của bạn. Xin vui lòng cho tôi expalin (một lần nữa, vì đó là quan niệm sai lầm phổ biến trong ngành Lập trình) ... QA Đảm bảo chất lượng sản phẩm bằng cách giám sát toàn bộ SDLC, từ Yêu cầu (có thể trước đó), thông qua phát triển, xác minh, phát hành và hỗ trợ. Kiểm tra đảm bảo rằng không có lỗi rõ ràng tồn tại trong mã. Có một sự khác biệt rất lớn và quan trọng. Nếu bạn có QA thực sự, họ sẽ ở khắp bộ phận Test / V & V hỏi tại sao họ lại tốn thời gian kinh doanh (và do đó tiền), hoặc tất cả các công việc quản lý dự án đều cho rằng họ đang quản lý lập kế hoạch dự án đúng cách hoặc quản lý dự án đúng cách chắc chắn đã có đủ người kiểm tra mã được sản xuất, v.v ...

Vì vậy, giả sử bởi QA bạn thực sự có nghĩa là Kiểm tra, trở lại câu hỏi ban đầu. Code Complete đã làm đúng - chi phí của lỗi là thời gian từ khi chèn đến sửa. Phát hiện sớm chỉ hữu ích nếu bạn cũng sửa nó sớm, nhưng hầu hết mọi người giải thích đều sai.

(Lưu ý: Tôi đang chơi Quỷ ủng hộ ở đây, đừng hiểu điều này theo nghĩa đen vì tôi không biết gì về tình huống của bạn) Nguyên nhân trì hoãn của bộ phận Kiểm tra của bạn là một chi phí, tuy nhiên, tôi phải hỏi, nếu bạn là chờ đợi họ tìm ra khuyết điểm của bạn, bạn đang làm gì - bạn có nên tìm ra khuyết điểm của mình không? Có lẽ nếu họ có ít công việc hơn (thông qua đầu vào chất lượng cao hơn với ít lỗi hơn từ bạn), thì độ trễ sẽ không đáng kể và chi phí thấp hơn - như một người quản lý tôi sẽ hỏi bạn cách bạn dự định giảm các khiếm khuyết trong mã bạn cung cấp kiểm tra, vì (dựa trên lập luận của bạn) những khiếm khuyết đó có giá cao hơn nếu được tìm thấy bằng thử nghiệm sau đó chính bạn.

Ngoài ra, với tư cách là người quản lý của bạn, tôi có thể nói rằng công việc Kiểm tra không tìm thấy khuyết điểm của bạn, công việc của họ là tìm thấy không có khuyết điểm - nếu bạn đang mong đợi họ tìm ra khuyết điểm, có thể bạn chưa hoàn thành tốt công việc của mình.

Hãy cẩn thận cách bạn tiếp cận điều này. Nếu bạn không có giải pháp cho vấn đề này, bạn có khả năng trở thành người giỏi thứ hai.