Trong công ty của tôi, một nhiệm vụ không bao giờ có thể được hoàn thành bởi một cá nhân. Sẽ có một người riêng biệt để QA và Code Xem lại từng nhiệm vụ. Điều này có nghĩa là mỗi cá nhân sẽ đưa ra ước tính của họ, cho mỗi nhiệm vụ, bao nhiêu thời gian để hoàn thành.

Vấn đề là, tôi nên tiếp cận như thế nào? Nếu tôi tổng hợp các giờ với nhau, giả sử ước tính sau:

10 giờ - Thời gian phát triển

4 giờ - QA

4 giờ - Xem lại mã.

Ước tính nhiệm vụ = 18 giờ

Vào cuối mỗi ngày, tôi yêu cầu nhiệm vụ được cập nhật với "thời gian còn lại cho đến khi hoàn thành". Tuy nhiên, mỗi người thường chỉ nghĩ về phần của họ. Họ có nên đánh dấu nỗ lực còn lại, và sau đó THÊM ước tính nỗ lực vào đó? Các bạn làm thế nào đây?

CẬP NHẬT

Để giúp làm rõ một vài điều, tại tổ chức của tôi, mỗi Nhiệm vụ trong một câu chuyện cần có 3 người.

1. Có người phát triển nhiệm vụ. (làm bài kiểm tra đơn vị, ect ...)
2. Một chuyên gia QA để xem xét nhiệm vụ (họ chủ yếu thực hiện các bài kiểm tra tích hợp và hồi quy)
3. Một công nghệ dẫn để làm mã xem xét.

Tôi không nghĩ có một cách sai hay một cách đúng, nhưng đây là cách của chúng tôi ... và điều đó sẽ không thay đổi. Chúng tôi làm việc như một đội để hoàn thành cấp độ nhỏ nhất của câu chuyện bất cứ khi nào có thể. Bạn thực sự không thể kiểm tra nếu một cái gì đó hoạt động cho đến khi nó hoàn thành và bạn cũng không thể xem lại chất lượng của mã ... vì vậy, cách tốt nhất bạn có thể làm là chia mọi thứ thành các lát logic nhỏ để có thể kiểm tra chức năng tối thiểu xem xét càng sớm vào quá trình càng tốt.

Câu hỏi của tôi cho những người làm việc theo cách này sẽ là làm thế nào để ghi lại một "nhiệm vụ" khi họ được thiết lập theo cách này. Trừ khi một Nhiệm vụ có các nhiệm vụ phụ riêng (mà JIRA không cho phép) ... Tôi không chắc chắn cách tốt nhất để thực hiện theo dõi "những gì còn lại" hàng ngày.

Đó là 3 nhiệm vụ, không phải một.

Nó có thể là một tính năng / câu chuyện, nhưng nó là ba nhiệm vụ. Một nhiệm vụ có thể được hoàn thành bởi một người trong thời gian hữu hạn.

TL; DR

Bạn đang sử dụng burn-down không chính xác theo nhiều cách. Nhiệm vụ và câu chuyện được thực hiện hoặc không được thực hiện; bằng cách cố gắng theo dõi độ lệch so với ước tính lập kế hoạch dựa trên thời gian trong phần chi tiết của bạn, bạn thực sự đang ước tính lại lịch trình của mình thay vì ước tính sản phẩm công việc còn lại.

Trong Scrum, bạn nên đo lường tiến trình hướng tới Mục tiêu Sprint thay vì đo hộp thời gian của Sprint. Điều này giữ sự tập trung vào năng lực nhóm và phân phối tính năng thay vì điều chỉnh lịch trình liên tục.

Nhiệm vụ so với Câu chuyện

Bạn đang xáo trộn nhiệm vụ và câu chuyện. Câu chuyện bao gồm tất cả các nhiệm vụ cần thiết để hoàn thành câu chuyện theo "định nghĩa hoàn thành" của nhóm của bạn. Câu chuyện được coi là không hoàn thành 100% trừ khi tất cả các nhiệm vụ của nó đã hoàn thành. Trong Scrum, những câu chuyện luôn được ước tính theo một cách nào đó; thường xuyên nhất, họ được ước tính trong các điểm câu chuyện.

Các nhiệm vụ là các bước hoặc các mốc cần thiết để hoàn thành câu chuyện. Mặc dù mỗi tác vụ có thể có các phụ thuộc và điều kiện tiên quyết, bạn chắc chắn có thể nói rằng việc xem xét mã đã hoàn thành hay chưa, độc lập với các tác vụ khác.

Đốt

Trong Scrum, biểu đồ ghi chú của bạn hiển thị số lượng công việc còn lại cho lần chạy nước rút hoặc dự án. Biểu đồ burn-down thực thường có cao nguyên; trong một số trường hợp, đồ thị thậm chí có thể tăng lên. Ví dụ: trong lần chạy nước rút một tuần với hai câu chuyện trị giá 3 và 5 điểm, các điểm dữ liệu của bạn có thể trông giống như thế này:

Mon | Tue | Wed | Thu | Fri
--- | --- | --- | --- | ---
 8  |  5  |  5  |  5  |  0

Trong kịch bản lý tưởng này, bạn bắt đầu với 8 điểm câu chuyện. Câu chuyện 3 điểm đã được hoàn thành vào chiều thứ ba, trong khi câu chuyện 5 điểm chưa hoàn thành cho đến thứ Sáu. Điểm câu chuyện không được khấu trừ từ sự đốt cháy cho đến khi câu chuyện đã đáp ứng định nghĩa hoàn thành. Nếu bạn đang sử dụng giờ lý tưởng thay vì điểm câu chuyện, điều duy nhất thay đổi là quy mô của bạn.

Thời gian-Boxing

Thực tiễn thường được chấp nhận là để đảm bảo rằng các nhiệm vụ của bạn được phân tách thành các khối có kích thước cắn trong khoảng từ 1/2 ngày đến 2 ngày. Phương sai của hơn một ngày nên được hiển thị rõ ràng từ các bản dựng hàng ngày hoặc Sprint Backlog; không cần phải thực hiện kéo trạng thái chính thức.

Bạn cũng có thể thực hiện phân tích thống kê trên biểu đồ ghi chú để xác định xem chạy nước rút của bạn có đúng xu hướng hay không. Những sai lệch nhỏ hoặc cao nguyên là bình thường, nhưng nếu không ai nâng bất kỳ trình chặn nào trong trạng thái đứng hàng ngày nhưng sự cố của bạn dường như bị kẹt, đó thường là dấu hiệu cho thấy Sprint Backlog bị đánh giá sai hoặc có "công việc vô hình" cần phải được làm rõ ràng trong quá trình của bạn.

Bạn có thể định nghĩa nhiệm vụ dev là "hoàn thành" trước khi QA thực hiện phần của họ không? Bạn có thể định nghĩa đánh giá mã là "xong" trước khi dev được thực hiện không? QA có thể được "thực hiện" nếu đánh giá dev và code không?

Tôi muốn nói rằng bạn nên tổng hợp ba mục thành một nhiệm vụ duy nhất và ba người nên cùng nhau thực hiện nó.

Scrum KHÔNG nói rằng bất kỳ mục nào là trách nhiệm của bất kỳ thành viên nào trong nhóm. Ngược lại - các mục nhật ký chạy nước rút là trách nhiệm của TEAM. Nếu phải mất ba người để thực hiện một nhiệm vụ, thì đó là những gì nó cần.

Nó không thành vấn đề. Miễn là nó tương đối nhất quán trong các câu chuyện, biểu đồ phát sinh của bạn vẫn sẽ hoạt động theo cách nào đó. Sử dụng bất cứ cách nào là tự nhiên nhất để nhóm của bạn báo cáo.

Nhóm của tôi thực sự làm một loại lai, mặc dù không phải theo thỏa thuận chính thức. Chúng tôi đặt 16 giờ nếu chúng tôi nghĩ rằng một nhiệm vụ sẽ mất một người hai ngày, nhưng nếu hai người kết thúc công việc đó, chúng tôi sẽ không thay đổi nó.

Sau khi ước tính ban đầu, nó không chính thức trở thành phần trăm hoàn thành cho nhóm của chúng tôi hơn là một giờ còn lại. Nếu ban đầu chúng tôi nghĩ rằng sẽ mất hai ngày, nhưng sau một ngày, chúng tôi nghĩ rằng nó chỉ hoàn thành 25%, chúng tôi sẽ nghỉ 4 trong số 16 giờ ban đầu. Mất 12 giờ trong khi về mặt kỹ thuật, chúng tôi ước tính 24 giờ, vì có thể chúng tôi sẽ khấu trừ 4 giờ trong 3 ngày còn lại.

Điều đó làm tôi khó chịu khi là một bậc thầy scrum lúc đầu, nhưng có vẻ lạ, dường như đó là một cách rất tự nhiên để đưa ra ước tính, bởi vì các nhà phát triển thực sự ghét phải thêm hàng giờ vào ước tính. Tất cả chỉ tính trung bình để làm cho sự phát triển vẫn còn hữu ích, và đó là điều quan trọng.

Thời gian còn lại của nhiệm vụ không quan trọng lắm: không có gì có thể được giao cho đến khi toàn bộ câu chuyện được thực hiện.

Nếu bạn muốn theo dõi thời gian còn lại trên một câu chuyện (tổng thể) bằng cách mọi người điền vào thời gian còn lại cho các nhiệm vụ, sau đó phân chia nhiệm vụ cho mỗi người.

Mà nói:

• Nhiệm vụ lớn có thể là một dấu hiệu cho thấy câu chuyện của bạn quá lớn. Trong trường hợp này, giải pháp tốt nhất là giảm phạm vi và kích thước của câu chuyện và nếu bạn giảm đủ thời gian theo dõi còn lại cho các nhiệm vụ thì không còn vấn đề gì nữa (chúng có được thực hiện hay không - tổng ước tính cho các nhiệm vụ không hoàn thành là đủ hạt).
• SCRUM khuyến khích tất cả mọi người chọn những gì cần làm. Nếu bạn đang phân công nhiệm vụ cho mọi người (trái ngược với vai trò), thì bạn có khả năng ngăn mình phát một câu chuyện, ngay cả khi nhà phát triển không làm gì - vì QA bị tắc nghẽn.

Chia nhiệm vụ thành nhiều nhiệm vụ và nhập chúng dưới dạng các nhiệm vụ trong đó mỗi nhiệm vụ được xử lý bởi một người khác nhau.

Nhiệm vụ gốc: Sửa một cái gì đó

Nhiệm vụ mới: (con của cha mẹ của nhiệm vụ ban đầu)

• Dev A - Khắc phục sự cố
• Dev B - Giúp Dev A khắc phục sự cố (tức là lập trình cặp, xem lại mã)
• Dev A - dev kiểm tra bản sửa lỗi bằng Dataset X
• Dev B - dev kiểm tra bản sửa lỗi bằng Dataset Y