Có nên bao gồm thời gian của người kiểm tra khi ước tính vé?


17

Khi tạo ước tính thời gian cho vé, thời gian dành cho người kiểm tra (QAs) có nên được đưa vào ước tính vé không? Trước đây chúng tôi luôn ước tính không có thời gian của người kiểm tra nhưng chúng tôi đang nói về việc luôn luôn bao gồm nó. Nó có ý nghĩa cho lần chạy nước rút hiện tại của chúng tôi, lần cuối cùng trước khi phát hành, vì chúng tôi cần biết tổng thời gian vé sẽ mất trong một tuần để đi.

Tôi luôn hiểu ước tính chỉ dành cho thời gian của nhà phát triển vì đó có xu hướng là nguồn lực hạn chế trong các nhóm. Một đồng nghiệp đang nói rằng bất cứ nơi nào họ đã làm việc trước thời gian thử nghiệm cũng đã được đưa vào.

Để rõ ràng, đây là một quá trình trong đó các nhà phát triển đang viết các bài kiểm tra đơn vị, tích hợp và giao diện người dùng với độ bao phủ tốt.


Điều gì về thời gian cho các lỗi sửa đổi lại từ các vấn đề mà người kiểm tra tìm thấy? Đó là một điều thực sự khó khăn để ước tính :).
Frank Puffer

3
Là kiểm tra một phần định nghĩa của bạn về thực hiện, hoặc chúng ta đang nói về một nhóm / bộ phận khác?
nvoigt

2
Hoàn toàn có thể cho nỗ lực của người thử nghiệm là phần lớn thời gian dành cho một "vé". Vì vậy, IMO; Đúng.
Grimm The Opiner

@nvoigt Kiểm tra là một phần định nghĩa của chúng tôi được thực hiện.
TTransmit

Câu trả lời:


33

Đề xuất của tôi: Bạn có thể bao gồm thời gian thử nghiệm trong vé hoặc thêm một vé để thể hiện nhiệm vụ thử nghiệm. Bất kỳ cách tiếp cận nào khác khiến bạn đánh giá thấp công việc thực sự cần thiết.

Mặc dù thời gian của nhà phát triển thường là một nút cổ chai, nhưng theo kinh nghiệm của tôi, có nhiều đội bị hạn chế trong thử nghiệm. Giả sử tài nguyên giới hạn là cái này hay cái kia mà không có bằng chứng, có thể cắn bạn.

Là đồng nghiệp của bạn, tôi chưa thấy một tổ chức thành công nào không tính đến thời gian thử nghiệm.

Phụ lục theo sự làm rõ của bạn: Ngay cả khi các nhà phát triển viết các bài kiểm tra tự động, đặc biệt là các bài kiểm tra đơn vị (kiểm tra tích hợp làm tốt hơn), chúng vẫn không đủ để kiểm tra đúng cách.

Nếu có người QA tham gia, thời gian của họ cần được ước tính, bằng cách này hay cách khác. Chỉ khi bạn quyết định loại bỏ người QA khỏi bảng lương, thì thời gian làm việc của họ đã biến mất một cách hiệu quả và bạn có thể xóa nó khỏi dự toán. Nhưng điều này sẽ có tác dụng phụ rất dễ bỏ qua. Và bạn vẫn có thể thiếu kiểm tra hiệu suất, căng thẳng, bảo mật và chấp nhận.


6
Vị trí nút cổ chai phụ thuộc vào công ty. Tại tôi, chúng tôi có 8 nhà phát triển cung cấp một tài nguyên QA. QA rõ ràng là nút cổ chai
Marshall Tigerus

2
Tôi đồng ý rằng thêm một vé để thử nghiệm là một lựa chọn tốt ở đây. Có vẻ như OP không kiểm soát QA và nó được thực hiện bởi một nhóm riêng biệt. Nếu họ tìm thấy một cái gì đó sai thì đây có thể được coi là một lỗi và một vé mới được tạo để sửa chữa / thay đổi.
Đầu tôi đau

@MarshallTigerus: Tôi nghĩ rằng nói chung, việc phối hợp những người cần thiết để cung cấp QA cho các nhà phát triển N dễ dàng hơn (số chính xác phụ thuộc vào sản phẩm), hơn là phối hợp với các nhà phát triển N. Vì vậy, theo một nghĩa nào đó, QA "không nên" là nút cổ chai, bạn "nên" thuê một QA khác (và sa thải một nhà phát triển để tạo ra tiền lương và không gian bàn làm việc, thậm chí, nhưng hãy hy vọng nó không xảy ra). Tất nhiên không phải mọi thứ luôn luôn như vậy.
Steve Jessop

1
+1 cho một vé khác, giúp dễ dàng hơn để biết mọi thứ bị kẹt ở đâu.
Matthieu M.

1
@SteveJessop Rất nhiều điều "nên" xảy ra :)
Marshall Tigerus

19

Nhấn mạnh,

Kiểm tra là một phần của quá trình phát triển. Nếu nhóm của bạn thực sự dành thời gian để kiểm tra phần mềm, thì thời gian thử nghiệm cần phải là một phần của ước tính.


5

Nếu điều này là nhanh nhẹn, tôi sẽ bao gồm nỗ lực thử nghiệm như là một phần của tổng số điểm câu chuyện. Ví dụ: nỗ lực dev có thể 1 ngày và thử nghiệm 1 ngày để đó sẽ là câu chuyện 2 điểm.

Nó phụ thuộc vào định nghĩa thực hiện của bạn là gì, nhưng thường thì dev hoàn thành, chấp nhận kinh doanh và kiểm tra đăng xuất trong lần lặp. Nếu DoD chỉ là sự chấp nhận kinh doanh thì không cần phải nỗ lực kiểm tra trong các điểm câu chuyện, nhưng nó vẫn nên được theo dõi.


2

Dự toán sẽ chiếm tất cả các công việc cần thiết để hoàn thành vé. Nếu kiểm tra là một phần bắt buộc của vé, thì nó nên được bao gồm trong ước tính. Nếu thử nghiệm là một vé riêng biệt thì không nên.

Điều đó tất nhiên có thể trở nên mờ nhạt khi bạn bắt đầu sử dụng điểm câu chuyện, vì sự khác biệt giữa dev 5 chỉ và dev 8 chỉ sẽ tỷ lệ thuận với dev-và-QA 5 so với dev-và-QA 8.

Tôi đã thấy bao gồm cả thời gian thử nghiệm làm việc. Tôi đã thấy những câu chuyện riêng biệt hoạt động. Tôi đã thấy các nhiệm vụ riêng biệt, mỗi nhóm ước tính thực hiện chúng. Hãy làm những gì có ý nghĩa với bạn, sau tất cả quá trình là để phục vụ bạn chứ không phải ngược lại.


2

Thực tế là bạn không thể trả lời điều này một cách mạnh mẽ cho thấy bạn không biết tại sao bạn viết dự toán (hoặc ít nhất là bạn không đồng ý với đồng nghiệp tại sao bạn viết dự toán). Đây là một vấn đề lớn hơn so với việc ước tính nên hay không nên bao gồm thử nghiệm.

Tìm hiểu hoặc đạt được thỏa thuận, tại sao bạn viết dự toán. Nếu đó là để dự đoán những gì một nhóm cụ thể sẽ đạt được trong một thời gian cụ thể, thì câu trả lời chỉ đơn giản phụ thuộc vào việc nhóm đó, nhóm mà bạn ước tính, có kiểm tra hay không. Nếu nhóm QA của bạn riêng biệt và có lịch trình riêng thì họ có thể quan tâm để biết bạn (nhà phát triển) nghĩ cần bao nhiêu thời gian thử nghiệm từ họ trên một vé nhất định. Họ có thể bỏ qua số của bạn và đặt số của họ vào. Dù bằng cách nào họ cũng có thể theo dõi số đó một cách riêng biệt với ước tính thời gian của nhà phát triển.

Mặt khác, nếu một nhóm thực hiện tất cả các nhà phát triển, thử nghiệm và QA và mục đích của ước tính thời gian là dự đoán và lập kế hoạch cho nhóm đó đang làm gì trong một khung thời gian cụ thể, thì tất nhiên các ước tính thời gian phải bao gồm QA, cùng với bất kỳ nhiệm vụ nào khác mà nhóm đó cần phải thực hiện để đạt được mục tiêu đã nêu. Đối với vấn đề đó nếu bạn phải có một cuộc họp khởi động cho mỗi vé, hoặc điền vào một số giấy tờ khi hoàn thành, thì thời gian để quản trị viên cần phải ở đó ở đâu đó . Bạn không thể bỏ qua nó.

Nếu đó là tất cả một nhóm nhưng với vai trò là "nhà phát triển" và "người thử nghiệm" riêng biệt, thì điều đó có thể có nghĩa là bạn có rất nhiều vé mà chỉ một bên của sự phân chia có khả năng hoạt động và biểu đồ Gantt (có lẽ hoàn toàn giả định) của bạn chính xác như biểu đồ cho hai đội riêng biệt sẽ nhìn. Thực tế này sẽ làm đảo lộn một số phương pháp hơn các phương pháp khác và bạn có thể tốt hơn nên chia nhỏ kế hoạch vì điều đó, nhưng nếu bạn không chia nó thì bạn phải bán vé và ước tính mọi thứ mà nhóm cần làm hoặc dự đoán của bạn sẽ vô vọng .

Nếu mục đích của các ước tính là một cái gì đó ngoài dự đoán và lập kế hoạch, ví dụ "bởi vì chúng tôi vô thức tuân theo một nghi thức trống rỗng bao gồm chúng" hoặc "bởi vì ban quản lý sử dụng chúng như một cây gậy để đánh bại chúng tôi để vượt qua chúng tôi", hoặc "bởi vì chúng tôi phải thực hiện một giá thầu cố định và các con số đi vào một công thức to lớn" (cảm ơn John Wu), nên có thể khó hơn để tìm ra những gì họ nên bao gồm ;-)


1

Luôn ước tính tất cả các công việc cần được thực hiện để làm cho câu chuyện người dùng / tính năng / vé thực sự được thực hiện. Chúng tôi gọi đây là DoneDone .

Chúng tôi đã hoàn thành khi chúng tôi sẵn sàng sản xuất .

Điều này bao gồm mọi thử nghiệm thủ công và thăm dò, nhưng ngay cả thử nghiệm chấp nhận của người dùng.

Một nhóm Agile sẽ có thể phát hành một phần mới của công việc đã hoàn thành bất cứ lúc nào. Như:

Phần mềm làm việc là thước đo chính của sự tiến bộ.

Làm thế nào để bạn biết nếu nó hoạt động, nếu bạn chưa thử nghiệm nó? Bây giờ bạn viết rằng thời gian phát triển là nút cổ chai của thời gian của bạn. Là một kỹ sư QA, tôi nghĩ rằng hầu hết các đội đều có nút thắt trong khả năng kiểm tra hoặc họ chỉ đang thực hiện các bước ngắn.

Để làm cho một câu chuyện dài ngắn, cũng ước tính nỗ lực thử nghiệm. Hãy nhớ rằng điều này có thể ảnh hưởng đến vận tốc của bạn . Nếu bạn đã thực hiện các ước tính tương đối trong các điểm câu chuyện, thử nghiệm có thể đã được tích hợp vào vận tốc trung bình của bạn.


1

Đây là một điều rất quan trọng: Tất cả các ước tính nên được kèm theo các giả định và loại trừ .

Điều này bao gồm chỉ định những gì được bao gồm: chỉ phát triển, thiết kế và phát triển, thử nghiệm dev và đơn vị, bảo hiểm cho thử nghiệm chấp nhận, xây dựng cơ sở hạ tầng, v.v.

Nếu bạn đang cung cấp một tài liệu ước tính cho người quản lý dự án, họ sẽ chuyển đổi tài liệu đó thành một trật tự công việc hoặc tuyên bố công việc cho khách hàng hoặc (nếu là một dự án nội bộ) cho PMO . Họ có thể đã thiết lập các công thức để thêm chi phí (ví dụ: một số dự án có thể thêm X% để chi trả cho QA, sau đó thêm Y% để chi trả cho quản trị và quản lý dự án) được đặt theo hợp đồng hoặc theo kinh nghiệm. Và bạn không muốn tăng gấp đôi. Mặt khác, họ có thể không thêm chúng tự động.

Thực tiễn khác nhau. Bất cứ ai đang sử dụng những con số này sẽ cần phải biết những con số đó có ý nghĩa gì, và bạn nên rõ ràng về việc bạn có bao gồm thời gian kiểm tra hay không.


1

Thời gian nên được bao gồm trong ước tính nhưng bạn không nên ước tính thời gian của người kiểm tra, thay vào đó người kiểm tra nên ước tính thời gian của họ .

Không bao gồm thời gian thử nghiệm là ước tính sai về tổng thời gian cần thiết, nhưng thời gian của nhà phát triển và thời gian thử nghiệm không thể thay thế cho nhau (nhất là vì bạn có thể làm việc song song, với người kiểm tra lặp lại phía sau) vì vậy bạn nên ước tính chúng một cách riêng biệt. Hơn nữa, bạn không ở vị trí để ước tính người kiểm tra thời gian sẽ cần kiểm tra bất kỳ thay đổi nào, chỉ có bản thân nhân viên kiểm tra mới nên làm điều đó.


1
Cho rằng đó là bạn điền vào vé, và bao gồm thời gian thử nghiệm, sau đó nhà phát triển nên bao gồm một 'khách mời' để thử nghiệm, để sàng lọc sau. Thật dễ dàng để tạo ra một lỗ đen ước tính bắt 22 với các quy tắc nhất định ... Những lỗ này xảy ra trong nhiều tác vụ điền vào biểu mẫu.
Philip Oakley

0

Đóng gói

Tôi sẽ tiếp cận điều này từ quan điểm và ngôn ngữ phát triển phần mềm.

  • Bạn là một cog nhỏ trong một máy lớn.
  • Từ bên ngoài nhóm của bạn, hệ thống bán vé của bạn hoạt động như một giao diện / API cho nhóm của bạn
  • Người dùng doanh nghiệp sử dụng hệ thống bán vé không phải là nhà phát triển

Từ thiết kế phần mềm tốt, bạn nên đơn giản hóa và gói gọn càng nhiều càng tốt.

Vì vậy, để xem xét quá trình từ quan điểm của Người dùng doanh nghiệp, họ thực sự chỉ quan tâm đến 2 điều.

  1. Nó có giá bao nhiêu?
  2. Chúng ta xong chưa?

Cho phép Người dùng Doanh nghiệp biết về quy trình nội bộ của nhóm bạn là quản lý kém; giống như cho phép publictruy cập vào trạng thái nội bộ.

Thất bại trong việc bảo vệ trạng thái nội bộ của nhóm bạn, đang mời các nhóm khác quản lý tài nguyên của bạn và gây rối với trạng thái nội bộ của bạn.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.