Nhóm scrum của chúng tôi bao gồm các vai trò scrum thông thường. Chúng tôi không có nhà thiết kế UI / UX và nhà phát triển làm việc UI / UX với chủ sở hữu sản phẩm. Đây là một vấn đề. Mỗi khi chúng tôi chuẩn bị tạo hồ sơ tồn đọng và chúng tôi không xác định thiết kế UI / UX chính xác trước khi bắt đầu nước rút, cuối cùng chúng tôi dành quá nhiều thời gian trong quá trình chạy nước rút để hoàn thiện thiết kế UI / UX.

Điều này là chính xác cho việc phân tích và kiến ​​trúc của các tính năng. Bạn có nghĩ rằng mọi chi tiết có thể có về một tính năng nên được cung cấp cho các nhà phát triển trước khi bắt đầu chạy nước rút hay nó nên là một nhiệm vụ trong các tính năng? Chúng tôi đã có kinh nghiệm với điều này và nó dẫn đến một số tính năng không xác định không có bất kỳ tiêu chí nào.

Đầu tiên: hãy xem cuộc nói chuyện hay này , Florian Haas đã đưa ra tại FROSCON (GER). Đó là về sự bất khả thi thực tế của việc làm scrum ở tất cả.

Tin tốt : Vì scrum là không thể thực hiện, bạn có thể tự do làm bất cứ điều gì bạn muốn.

Tin xấu : Đừng gọi đó là scrum.

Điều đó giải phóng bạn khỏi câu hỏi: »Tôi đang làm scrum phải không?« (Trả lời: Không bạn không ) và bạn có thể tiếp tục với những câu hỏi thực tế của cuộc sống, vấn đề đó.

Chúng tôi không có nhà thiết kế UI / UX và nhà phát triển làm việc UI / UX với chủ sở hữu sản phẩm

Đây là một tình huống không phổ biến. Nhưng scrum AFAIR chống lại chuyên môn hóa: mọi người nên có cùng một kỹ năng và có thể làm việc thay thế cho nhau.

Mỗi khi chúng tôi chuẩn bị tạo hồ sơ tồn đọng và chúng tôi không xác định thiết kế UI / UX chính xác trước khi bắt đầu mùa xuân, chúng tôi sẽ dành quá nhiều thời gian trong giai đoạn nước rút cố gắng hoàn thiện thiết kế UI / UX.

Vâng, tôi bây giờ tình hình tất cả quá tốt. Tôi đã làm việc trong một nhóm, nơi chúng tôi phải đối phó với các hồ sơ tồn đọng rất rộng như »Là một người dùng, tôi muốn xem thông tin x « và đó là nó. Sau đó các mục hạ cánh trên bảng nước rút. Một nhà phát triển đã lấy nó. Giải quyết nó. Sau khi thực hiện nó, một đánh giá ngang hàng đầu tiên đã diễn ra, nơi thảo luận bắt đầu về giao diện người dùng sẽ như thế nào.

Sau đó, Giai đoạn QA đến và thảo luận lại bắt đầu.

Sau khi chạy nước rút, chúng tôi đã làm như scrum yêu cầu xem xét lại nơi thiết kế bị xé toạc bởi PO . Thật không may, khách hàng của chúng tôi đã không đưa ra đánh giá, vì vậy anh ta đã không thấy phần mềm tại thời điểm đó.

Nhưng sau đó, chu kỳ bắt đầu lại cho đến khi PO hài lòng.

Và sau đó đến khách hàng ...

Từ câu chuyện chiến tranh này, bạn thấy rằng quá trình này (loại đặc biệt) là không hiệu quả.

Những gì làm việc cho chúng tôi cuối cùng là ném scrum trên tàu.

Nhưng đó không phải là giải pháp cho câu hỏi của bạn;)

Bạn có nghĩ rằng mọi chi tiết có thể có về một tính năng nên được cung cấp cho các nhà phát triển trước khi bắt đầu chạy nước rút hay nó nên là một nhiệm vụ trong các tính năng?

Một giải pháp cho vấn đề nan giải này sẽ liên quan đến các phản hồi chặt chẽ giữa a) chính khách hàng và PO , do đó các tiêu chí được xây dựng tương đối chặt chẽ. b) Một phản hồi chặt chẽ giữa đội scrum và PO để giảm thiểu cơ hội lái xe trên đường.

Tôi sẽ phá vỡ một số (nhiều) quy tắc scrum để xác định một backlogitem: a »giả làm việc«. PO và khách hàng có thể nhanh chóng xem xét để giảm thiểu thời gian phát triển chi cho một mặt hàng đơn giản.

tl; dr

Điều gì nên là đầu vào của một nhóm scrum?

Đủ thông tin để đáp ứng các thông số kỹ thuật trong thời gian ít nhất có thể.

Đề ra:

Chúng tôi không làm scrum nữa. Chúng tôi không làm dự toán. Chúng tôi giữ bảng chạy nước rút. Chúng tôi không chạy nước rút. Chúng tôi phát triển các tính năng / sửa lỗi và phát hành ASAP. Khi các tính năng mới được triển khai, chúng sẽ ASAP đến một máy chủ công cộng nơi chúng tôi có thể thảo luận về thiết kế tiếp theo với khách hàng càng chặt chẽ càng tốt.

Câu trả lời kinh điển là "làm những gì phù hợp với bạn."

Scrum là một trong những phương pháp nhanh. Nó được thiết kế rõ ràng để thay đổi và thích nghi với nhóm của bạn và dự án của bạn. Bạn nên tập trung vào:

Các cá nhân và tương tác qua các quy trình và công cụ
Phần mềm làm việc trên tài liệu toàn diện Sự
hợp tác của khách hàng trong đàm phán hợp đồng
Đáp ứng thay đổi theo kế hoạch ( Bản tuyên ngôn Agile )

Đây không phải là câu hỏi về nhóm của bạn nên bắt đầu câu chuyện gì, Đó là câu hỏi về đầu vào nào cho phép nhóm cụ thể của bạn giải quyết nhu cầu kinh doanh cụ thể.

Theo kinh nghiệm cá nhân của tôi, nó phụ thuộc vào mục tiêu kinh doanh. Một số câu chuyện đã đi kèm với nghiên cứu UI / UX và thiết kế đầy đủ, và điều đó ổn. Một số câu chuyện đi kèm với yêu cầu mơ hồ, bởi vì doanh nghiệp chỉ cần một vấn đề được giải quyết. Điều đó cũng ổn.

Có những yếu tố khác nữa, tất nhiên. Giống như liệu các nhà thiết kế của bạn là một phần của nhóm phát triển, hoặc tiếp thị, hoặc phát triển sản phẩm, v.v ... Rất nhiều yếu tố. Chỉ cần làm những gì cần thiết để đáp ứng doanh nghiệp, linh hoạt và đảm bảo bạn thảo luận về những điều này trong quá trình hồi tưởng, điều chỉnh quy trình khi cần thiết.

Tôi đã có sự đẩy lùi tương tự từ các nhà phát triển. Vấn đề từ quan điểm của họ là họ cảnh giác về việc phần UX có thể mất bao lâu để thực hiện. Nếu họ đồng ý thử và cung cấp N câu chuyện trong một lần chạy nước rút nhưng một số câu chuyện mất nhiều thời gian hơn dự kiến ​​do quay trở lại trên UX thì họ cảm thấy nó phản ánh không tốt về họ.

Những gì đã làm việc cho chúng tôi là:

1. Ai đó làm việc với chủ sở hữu sản phẩm để tạo ra các mô hình màn hình được phát triển. Chúng được xem xét trong quá trình sàng lọc câu chuyện thông thường trước khi câu chuyện được đưa vào giai đoạn nước rút, cho phép mọi người có cơ hội thảo luận trung thực.
2. Đừng thử và hoàn thiện thiết kế trước khi mã hóa, chỉ cần lấy nó ra và sau đó nói chuyện về những gì cần thay đổi. Các chi phí thực hiện thay đổi sau đó rõ ràng hơn giúp chủ sở hữu sản phẩm / khách hàng quyết định xem nó có đáng hay không.
3. Sự tin tưởng giữa chủ sở hữu sản phẩm / khách hàng và nhà phát triển. Cuối cùng tất cả mọi người đang cố gắng để cung cấp công cụ cho khách hàng. PO không được phép than vãn về việc nhóm không phân phối mọi thứ từ nước rút. Các nhà phát triển không thể cố tình cản trở vì họ lo lắng về việc không cung cấp.
4. Thực hành. Chúng tôi đã có được một kích thước câu chuyện ước tính tốt hơn và có thể phát hiện ra các vấn đề có thể xảy ra.

Tl; DR: Không xác định đầy đủ UX trước khi mã hóa. Đợi cho đến khi người dùng nhìn thấy nó và chơi với nó.

Bạn có nghĩ rằng mọi chi tiết có thể có về một tính năng nên được cung cấp cho các nhà phát triển trước khi bắt đầu chạy nước rút hay nó nên là một nhiệm vụ trong các tính năng?

Nói một cách đơn giản, nếu chủ sở hữu sản phẩm không thể cung cấp thiết kế ui / ux trước khi chạy nước rút, việc phát triển ui / ux nên là một câu chuyện , không phải là một nhiệm vụ.

Các sản phẩm chạy nước rút của bạn không phải luôn luôn là mã làm việc và chính nhóm có thể là "ai" trong câu chuyện. Bạn có thể có một câu chuyện như "Là thành viên của nhóm phát triển, chúng tôi cần các mockup UI để có thể triển khai UI". Sau đó, bạn ước tính sẽ mất bao lâu để nhóm của bạn cung cấp các mockup, và đó trở thành một trong những câu chuyện đầu tiên bạn làm việc.

Bạn không cần phải đánh vần UI, chỉ cần chấp nhận yêu cầu chức năng (câu chuyện) và ghi điểm khi biết bạn phải suy nghĩ về UI. Có khách hàng chỉ định UI đang yêu cầu sự cố.

Bây giờ bạn đã biết UI sẽ khiến bạn mất một thời gian để bạn có thể lập kế hoạch tốt hơn, Lần tới khi bạn nhận một nhiệm vụ bao gồm công việc UI, bạn sẽ chỉ định một số điểm câu chuyện bổ sung cho nó.

Nếu bạn không phải ai cũng có thể là nhà thiết kế UI / UX.

UI / UX không nên là một suy nghĩ sau. Nó sẽ là một giao hàng. Nó phải được sự chấp thuận của chủ sở hữu sản phẩm của bạn. Nó sẽ hiển thị, ngay cả khi chỉ là một gif, khi giao hàng.

Điều đó không có nghĩa là nó không thể thay đổi. Đó là thứ sẽ thay đổi thường xuyên. Đó cũng là điều bạn muốn phản hồi sớm. Đừng để mã điều khiển thiết kế UI. Hãy để khách hàng lái nó. Đẩy lùi chỉ khi khách hàng yêu cầu phép thuật. Mặt khác, chỉ cần làm cho họ biết về số lượng công việc họ đang yêu cầu và chi phí của nó là bao nhiêu.

UI / UX hoàn thiện duy nhất là trên phần mềm đã chết.

Từ bình luận của bạn:

"Nó phải được sự chấp thuận của chủ sở hữu sản phẩm của bạn." Đây chính xác là nơi phát sinh vấn đề. Có một lượng lớn thời gian dành cho quá trình phê duyệt này và chúng tôi kết thúc việc dành nhiều ngày thay vì vài giờ như ước tính ban đầu. - Rashid

Loại bỏ mọi thứ không cần thiết làm bạn chậm lại.

Bạn có một ý tưởng. Nói với chủ sở hữu sản phẩm. Họ nên ngồi cạnh bạn.

Họ ghét nó? Tiến lên. Yêu nó? Làm đi. Không hiểu nó à? Cho họ thấy đi.

Các cuộc họp ngắn thường xuyên đột xuất. Nói chuyện. Doodle trên bảng trắng hoặc giấy. Giả lập trong một chương trình sơn bằng cách sử dụng ảnh chụp màn hình. Truyền đạt, phê duyệt, thực hiện và xem xét ý tưởng một cách nhanh chóng.

Nếu chủ sở hữu sản phẩm không ở xung quanh lấy một người thuận tiện và hỏi họ. Bất cứ điều gì cần để bắt đầu lặp đi lặp lại. Lặp lại chủ sở hữu sản phẩm trở lại ngay khi bạn có thể.

Đừng dành một giây để làm cho nó đẹp. Chỉ cần đến điểm. Giữ ý tưởng của bạn nhỏ và tăng dần và bạn có thể được thực hiện trước khi bất cứ ai thậm chí yêu cầu ước tính.

Theo kinh nghiệm của tôi:

• Phân tích quá ít gây ra sự phát triển không hiệu quả, dừng lại bắt đầu
• Quá nhiều phân tích trực tiếp gây ra tê liệt phân tích (Sprint không bao giờ được bắt đầu)

Chúng ta làm gì:

• Xác định một số tiêu chí " Sẵn sàng để phát triển "
• Đối với các câu chuyện về UX, đây có thể là "chúng tôi có một khung dây được nhóm hiểu rõ"

Trong kế hoạch Sprint:

• Bất kỳ Câu chuyện nào chưa sẵn sàng để phát triển đều bị loại bỏ (chúng sẽ quá gây rối cho nhóm và quay lại để phân tích thêm)
• Bất kỳ Câu chuyện về đường biên giới nào cũng được tuyên bố là "Nguy cơ cao" và được thực hiện ngay khi bắt đầu Sprint
• Câu chuyện được hiểu rõ được ước tính và cho phép vào Sprint

Hệ thống này cho phép chúng tôi dành hầu hết mọi Sprint để thực hiện, tức là chúng tôi làm việc hiệu quả hơn nhiều.

Bất kỳ nhiệm vụ nào trong scrum của bạn phải có ước tính cho toàn bộ công việc liên quan và kết quả có thể kiểm chứng được.

Nếu tôi đặt một nhiệm vụ vào scrum của bạn "triển khai tính năng X với giao diện người dùng mà người quản lý sản phẩm hài lòng", điều đó có kết quả có thể kiểm chứng được, nhưng rõ ràng không thể ước tính số lượng công việc liên quan. Vì vậy, nhiệm vụ này không thể được đưa vào một cách hợp lý.

Bây giờ tôi đặt một nhiệm vụ vào scrum của bạn "thiết kế giao diện người dùng cho tính năng X". Điều đó có thể được ước tính, và kết quả có thể kiểm chứng được. Đó là một nhiệm vụ Ok trong một scrum. Khi nhiệm vụ hoàn thành, bạn đã hoàn thành nó.

Bây giờ khi nhiệm vụ hoàn thành, người quản lý sản phẩm của bạn có thể nói rằng anh ta không thích kết quả đó. Vậy là được rồi. Có một nhiệm vụ trong scrum, bạn đã hoàn thành nó và đó là công việc của bạn đã hoàn thành. Anh ta có thể đặt một nhiệm vụ khác vào scrum tiếp theo. Có lẽ với một chút định hướng về loại giao diện người dùng anh ta thực sự sẽ thích. Đó là công việc của anh ấy. Đặt các nhiệm vụ cho kết quả hữu ích . Đôi khi thật khó, và công việc được thực hiện hóa ra là vô ích. Đó là lý do tại sao họ gọi nó là "nhanh nhẹn"; nhiệm vụ được thực hiện mà hóa ra là vô dụng, và sau đó bạn thay đổi sang một hướng tốt hơn.

Ngoài ra, thiết kế UX, đặc biệt là thiết kế UX tốt, là một công việc toàn thời gian cho một người đã thực hành thiết kế UX. Nhiều nhà phát triển phần mềm giỏi có thể thực hiện một công việc dễ dàng tạo ra UX, nhưng họ sẽ không làm điều đó tốt và hiệu quả về chi phí như một nhà thiết kế UX giỏi (nếu có thể, thì họ sẽ tạo ra các thiết kế UX và không phát triển phần mềm). Vì vậy, việc không có một nhà thiết kế UX là không hiệu quả - lại là một vấn đề đối với chủ sở hữu sản phẩm.

Tôi không chắc chắn bạn đang tuân theo các nguyên tắc nhanh nhẹn, nhưng đây là cách xử lý vấn đề này.

chúng tôi không xác định thiết kế UI / UX chính xác trước khi bắt đầu chạy nước rút

Mục tiêu không phải là hoàn hảo vào thời điểm này. Nhận càng nhiều đầu vào cho các yêu cầu để các nhà phát triển có thể xây dựng một cái gì đó phù hợp với những gì đã được yêu cầu càng gần càng tốt. Đừng tạo ra một loạt các điều chỉnh hoặc cố gắng thiết kế những thứ chưa được yêu cầu. Bạn sẽ lãng phí thời gian của bạn.

chúng tôi cuối cùng đã dành quá nhiều thời gian trong giai đoạn nước rút cố gắng hoàn thiện thiết kế UI / UX.

Làm việc trên một cách để xác định khi nào mọi thứ được thực hiện. Tôi có cảm giác, ai đó đang tiếp tục thực hiện nhiều đánh giá qua lại về UI / UX. Quá nhiều người có ý kiến ​​về UX / UI mà không có gì từ khách hàng để hỗ trợ các giả định của họ.

Manager: "I think this should be bold."
Programmer: "The client didn't ask for this"
Manager: "But I think they'll like it."

Loại điều này có thể đi mãi mãi. Đó không phải là một lỗ hổng Scrum. Ai đó đang can thiệp với các yêu cầu trong khi chạy nước rút. Quay trở lại để quyết định những gì khách hàng muốn, xác định sẽ mất bao lâu và làm việc với họ để ưu tiên. Nếu họ nghĩ rằng nó sẽ mất quá nhiều thời gian, hãy hỏi họ những gì để thoát khỏi.

Có một công ty thiết kế logo cho một khoản phí cố định. Họ giới hạn số lượng yêu cầu thay đổi bởi vì họ biết một số khách hàng sẽ giết họ bằng cái chết từ hàng ngàn vết cắt với tất cả các thay đổi của họ. Đặt một điểm dừng cho nó hoặc tính phí nhiều hơn. Nó được gọi là kinh doanh.