Scrum: Có ổn không khi thiết kế / UX của câu chuyện người dùng xảy ra trong cùng giai đoạn nước rút khi thực hiện

Tôi hiện đang trong giai đoạn nước rút (hai tuần), nơi nhà thiết kế được giao nhiệm vụ xác định các yêu cầu và UX của một câu chuyện người dùng cụ thể.

Trong cùng một lần chạy nước rút, tôi đang thực hiện thiết kế này. Trong quá trình lập kế hoạch nước rút, tôi đã phải đoán một cách hoang dã về câu chuyện người dùng không xác định này sẽ kéo dài bao lâu.

Hôm nay tôi cuối cùng đã nhận được thiết kế. Thật không may, thiết kế không đầy đủ / mơ hồ và gần giống với yêu cầu của khách hàng hơn là thiết kế. Tuy nhiên, từ điều này, tôi vẫn có thể thấy rằng tôi gần như không ước tính đủ.

Để làm cho vấn đề tồi tệ hơn đây không phải là lần đầu tiên. Trong lần chạy nước rút cuối cùng, điều tương tự chính xác đã xảy ra. Tôi đã gắn cờ nó trong quá trình hồi cứu của chúng tôi và chủ scrum không có câu trả lời về cách giải quyết vấn đề này, thay vì nói "đó chỉ là sự phát triển cho bạn". Trớ trêu thay anh ta lại thấy khó chịu nếu việc đốt cháy không phải là mục tiêu ...

Bây giờ tôi sẽ phải yêu cầu / làm việc với nhà thiết kế để hoàn thành công việc của mình. Điều này sẽ giữ tôi lại vì tôi đã hoàn thành tất cả các nhiệm vụ khác của mình.

Vì vậy, câu hỏi của tôi là

Làm thế nào để bạn xử lý các phụ thuộc trong kế hoạch nước rút?

Lý tưởng nhất là các phụ thuộc không phát triển được xử lý trước khi lập kế hoạch chạy nước rút, để bạn có một định nghĩa tốt về mục tồn đọng để ước tính nỗ lực chống lại.

Nhưng, nếu đó là "chỉ phát triển cho bạn" lần chạy nước rút cuối cùng, thì đó có lẽ sẽ chỉ là phát triển cho lần chạy nước rút này, vì vậy bạn nên thực sự tăng ước tính của mình ở đó và sau đó vào các nhiệm vụ sắp tới ở trạng thái tương tự. Điều này không được minh oan, và sẽ là một sai lầm khi để nó đi qua như vậy.

Những gì nó làm là cho thấy sự không chắc chắn của ước tính mà không có một thiết kế tương đối vững chắc để ước tính. Có lẽ, điều này sẽ khuyến khích các nhà quản lý của bạn đảm bảo rằng một mặt hàng tồn đọng của sản phẩm được xác định đúng; nhưng tệ nhất nó sẽ che lưng bạn. Không ai phàn nàn khi một công việc đến dưới ngân sách.

Tuy nhiên, bạn đã không làm điều đó, và bây giờ câu hỏi của bạn là ...

Làm thế nào bây giờ tôi nên tiếp cận nước rút?

Toàn bộ mục đích của Scrum như một công cụ quản lý dự án là xác định sớm các vấn đề mà bạn đã thực hiện. Đánh dấu nó lên quản lý của bạn, để họ quyết định làm gì với nước rút. Nếu họ cố đổ lỗi cho bạn, hãy khiêm tốn và hỏi họ đề nghị bạn tiếp cận những tình huống tương tự như thế nào trong tương lai, để tránh vấn đề tương tự, ngay cả khi bạn không thực sự tin rằng điều đó là công bằng.

Vào cuối ngày, đây là những vấn đề quản lý dự án và nếu bạn cố gắng giải quyết chúng trong bong bóng của chính mình, bạn sẽ tự đặt ra thất bại. Và, khi bạn làm thế, bạn sẽ tức giận vì điều đó sẽ thuộc về bạn chứ không phải những người quản lý không giải quyết được vấn đề khi bạn gắn cờ với họ.

Trước hết, có một sự khác biệt lớn giữa sự phụ thuộc giữa câu chuyện / nhiệm vụ và sự không chắc chắn trong phạm vi / nỗ lực của một câu chuyện / nhiệm vụ.

Sự phụ thuộc được xử lý bằng cách ưu tiên nhiệm vụ / câu chuyện phụ thuộc thấp hơn nhiệm vụ / câu chuyện mà nó phụ thuộc và có thể là một chú thích mà nó không thể bắt đầu trước khi nhiệm vụ / câu chuyện khác được thực hiện.

Sự không chắc chắn nên được giải quyết trong cuộc họp lập kế hoạch bằng cách làm rõ các công việc cần phải được thực hiện trên câu chuyện. Nếu không thể loại bỏ đủ sự không chắc chắn, câu chuyện rất có thể không đáp ứng "Định nghĩa về sự sẵn sàng" của bạn và không nên được chấp nhận vào giai đoạn nước rút.
Nếu, vì một số lý do, câu chuyện thực sự cần đi vào giai đoạn nước rút, lựa chọn duy nhất còn lại của bạn là thêm một bộ đệm rủi ro vào dự toán.

Đối với lần chạy nước rút hiện tại, nếu bạn không thể thực hiện một câu chuyện, chỉ cần báo cáo rằng trong cuộc họp hàng ngày tiếp theo và thực hiện bất kỳ công việc nào có thể để đạt được mục tiêu chạy nước rút chung của nhóm. Bạn cũng có thể chú thích câu chuyện bị chặn và bởi những gì.
Sau khi chạy nước rút đã bắt đầu, về nguyên tắc không thể thêm các nhiệm vụ mới vào chạy nước rút.
Ngoài ra, nếu một nhiệm vụ hóa ra là nhiều công việc hơn ước tính, thì bạn không thay đổi ước tính, nhưng bạn báo cáo trung thực tiến trình và nỗ lực còn lại của nhiệm vụ là gì.

Cuối cùng, trong Scrum, nhóm hứa hẹn sẽ cung cấp một cái gì đó. Nếu lời hứa đó không thể được thực hiện, thì đó là thất bại của toàn đội, không bao giờ là của một cá nhân trong đội.

Trong quá trình lập kế hoạch chạy nước rút, tôi đã phải đoán xem câu chuyện người dùng không xác định này sẽ kéo dài bao lâu.

Đó là sai lầm bạn đã làm. Không ai có thể buộc nhóm chấp nhận một nhiệm vụ trong lần chạy nước rút và công việc của bạn là tuyên bố rằng nhiệm vụ đó không thể được ước tính và chấp nhận trong lần chạy nước rút trừ khi có ít nhất khung dây (ví dụ). Có vẻ như chủ scrum của bạn thực sự là một người quản lý dự án, điều này chỉ làm cho mọi thứ tồi tệ hơn.

Làm thế nào để tiếp cận nhiệm vụ đó nếu cần hoàn thành nó trong giai đoạn nước rút (vì lý do kinh doanh hợp lệ)? Chà, trước tiên bạn phải đặt thời hạn cho thiết kế, sau đó bạn sẽ không thể thực hiện nó. Ví dụ: câu chuyện được chấp nhận, nhưng thiết kế nên được gửi trong tuần đầu tiên và được thực hiện trong vòng thứ hai. Tiếp theo, bạn phải làm việc rất chặt chẽ với nhà thiết kế để đảm bảo nó sẽ có thể được thực hiện trong giai đoạn nước rút. Scrum giả định nhóm chức năng chéo và tùy thuộc vào bạn để tổ chức công việc của bạn với nhà thiết kế. Phải nói rằng, nếu bạn chấp nhận nhiệm vụ trong giai đoạn nước rút - tùy thuộc vào nhóm quyết định - thì nhóm phải quản lý công việc theo cách hoàn thành trong giai đoạn nước rút và quản lý các rủi ro liên quan. Bạn không nên đợi người khác hoàn thành công việc của mình để hoàn thành công việc. Có thể là bạn sắp tiết lộ một rối loạn chức năng lớn hơn trong tổ chức của bạn.

Các nhiệm vụ về thiết kế được thể hiện dưới dạng câu chuyện và định nghĩa của nhóm bạn là gì

• một câu chuyện đã sẵn sàng
• một câu chuyện đã xong

Mỗi câu chuyện nên có những yêu cầu và điều kiện chấp nhận riêng, nhưng tôi nghĩ rằng đó là một cách thực hành tốt để có một bộ quy tắc áp dụng cho tất cả các câu chuyện. Chẳng hạn, một câu chuyện đã sẵn sàng nếu (và chỉ khi!): Kết thúc nghiên cứu kiến ​​trúc kết thúc, thiết kế có sẵn, câu chuyện đã được nhóm ước tính. Các điều kiện chấp nhận tối thiểu có thể là: thử nghiệm tự động được thực hiện, OK và đã được tích hợp vào thử nghiệm phù hợp, đánh giá mã được thực hiện.

Nếu một câu chuyện chưa sẵn sàng, đừng nhúng nó vào nước rút của bạn. Nếu điều kiện chấp nhận không được đáp ứng, thì nó không kết thúc.

Trong trường hợp của bạn, nhóm có thể quyết định rằng để sẵn sàng, một câu chuyện phát triển cần phải có một thiết kế hoàn chỉnh (ít nhất là một khung dây, điều chỉnh điều này với thực tế của bạn). Nếu vậy, bạn không thể xử lý thiết kế và dev trong cùng một lần chạy nước rút. Nhóm nghiên cứu cũng có thể quyết định rằng một câu chuyện UX / thiết kế ít nhất nên tạo ra một thiết kế khung dây. Nếu không phải như vậy, thì câu chuyện không được chấp nhận và do đó, những câu chuyện tùy thuộc vào nó không thể được bắt đầu.

Bạn nên dễ dàng thuyết phục các nhà quản lý của mình rằng có các quy tắc mạnh mẽ để sẵn sàng là một điều tốt: đánh giá lại sự phức tạp trong quá trình chạy nước rút là một thực tiễn tồi. Điều đó có nghĩa là vận tốc của đội là không chắc chắn và sau đó họ, với tư cách là người quản lý, có tầm nhìn xấu về công việc của đội và về tương lai.

Một Sprint thường bắt đầu khi câu chuyện rõ ràng - ở giai đoạn này, Product Backlog được thiết lập và ưu tiên. Nếu bạn bắt đầu mà không có thiết kế hơn thì rõ ràng những gì có thể được thực hiện mà không có thiết kế và những gì không ...

Nếu bạn phải ứng biến trong khi thiết kế 'va chạm' giữa máy khách và PO thì PO của bạn phải thông báo cho nhóm về bất kỳ tính năng mới nào ngay khi chúng xuất hiện: đây là ý nghĩa của 'tính linh hoạt' trong Scrum - thích ứng với sự tiếp diễn tình hình. Nhóm phát triển, Scrum Master và Chủ sở hữu sản phẩm cần liên lạc vĩnh viễn, nếu không sẽ không có phản ứng thời gian thực để thay đổi.

Một số khóa đào tạo khác không thể gây hại ... Có lẽ làm việc với nhà thiết kế sẽ là cơ hội để bạn có được một số kỹ năng UX mới? ... đó là quan sát kính đầy một nửa thay vì nửa trống :))