Các nhà thiết kế UX làm việc trước một Sprint

Các nhà thiết kế UX của chúng tôi thường có một câu chuyện trong Sprint X mà các nhà phát triển sẽ triển khai trong Sprint X + 1 (Các nhà thiết kế UX và các nhà phát triển / người thử nghiệm nằm trong một nhóm). Tôi nghĩ điều này có ý nghĩa bởi vì nếu bạn không có mockup màn hình và thông số kỹ thuật rõ ràng, bạn không thể thực sự ước tính công việc trong Kế hoạch Sprint.

Tuy nhiên, trong Scrum, bạn chỉ có các câu chuyện người dùng cung cấp giá trị cho người dùng. Trong trường hợp của chúng tôi, các câu chuyện thiết kế UX không cung cấp giá trị như vậy (chúng giống như một hoạt động chải chuốt tồn đọng). Ngoài ra, thông thường các huấn luyện viên Scrum không khuyên bạn nên có thông số kỹ thuật đầy đủ trước khi bắt đầu Sprint, một khuyến nghị mà tôi cảm thấy khó hiểu.

Vì vậy, bạn có thấy bất kỳ bất lợi trong cách tiếp cận của chúng tôi? Nó dường như làm việc cho chúng tôi, nhưng nó đi ngược lại với các nguyên tắc Scrum.

Tuy nhiên, trong Scrum, bạn chỉ có các câu chuyện người dùng cung cấp giá trị cho người dùng.

Giá trị không được đo chỉ trong các dòng mã có thể chuyển đổi.

Bạn dường như ngụ ý rằng việc có một UI được thiết kế tốt sẽ không cung cấp bất kỳ giá trị nào. Tất nhiên là thế. Rõ ràng có giá trị cho người dùng cuối, nhưng cũng có giá trị cho nhóm phát triển của bạn, đây là một bên liên quan hoàn toàn hợp lệ. Nếu bạn không có công cụ và tài liệu để thực hiện công việc của mình, bạn không thể cung cấp giá trị cho người dùng cuối.

Đừng bị treo lên trên giáo điều scrum. Scrum là có để làm cho bạn hiệu quả hơn. Nếu thực hiện một câu chuyện UX một lần chạy nước rút trước khi bạn triển khai UI giúp bạn cung cấp phần mềm tốt hơn, hãy thực hiện nó.

Những nhược điểm chính là:

1. Bạn đang xếp hàng: nếu các nhà thiết kế của bạn đến trễ, các nhà phát triển của bạn sẽ không có việc làm; nếu nhà phát triển của bạn bị trễ, nhà thiết kế của bạn cuối cùng sẽ làm việc nhiều hơn một lần lặp trước. Đó không phải là một tình huống ổn định - nó không bền vững .

2. Các nhà thiết kế của bạn đang làm việc trước, bạn đang trả chi phí cho những câu chuyện có thể hoặc không thể được phát triển. Ngay cả khi điều đó hiếm khi xảy ra, bạn vẫn đang vứt tiền.

3. Các nhà thiết kế UX của bạn đang đưa ra quyết định trước mà không liên quan đến các nhà phát triển. Bạn đang thiếu những hiểu biết hữu ích và làm tăng nguy cơ rằng các thiết kế bị sai lệch hoặc không thực tế. Điều này khá phổ biến vì thiết kế UX không phải là một bài tập "trừu tượng" - nó phải được tạo ra từ các đặc điểm của ứng dụng (bao gồm cả những gì khả thi / nên làm hoặc không nên làm về mặt kỹ thuật)

4. Loại trừ hoặc không cho phép các nhà phát triển của bạn không phải là một cách bền vững để chạy một dự án.

5. Các nhà thiết kế không cung cấp giá trị: điều này có nghĩa là khó, nếu không nói là không thể ưu tiên công việc của họ một cách chính xác. Thông thường, công việc của nhà phát triển được ưu tiên sử dụng các mối quan tâm, giá trị, tính khả thi khác nhau trong lần chạy nước rút tiếp theo, số lượng nỗ lực. Rất nhiều câu chuyện thời gian được đàm phán và thay đổi để làm cho chúng "phù hợp" hoặc vì thảo luận hữu ích: nếu bất kỳ điều nào trong số này thay đổi UI (và bạn có thể cho rằng nó không phải là một chi tiết triển khai đơn thuần), bạn sẽ làm gì với câu chuyện? Bạn không thể chơi nó nữa.

6. Bạn đang giả định rằng một câu chuyện có thể phù hợp với một lần lặp cho các nhà thiết kế phù hợp với một lần lặp cho các nhà phát triển: làm thế nào bạn có thể phân chia các câu chuyện để giả định này là chính xác?

Tôi thích nó, vì hai lý do:

1. nó dường như làm việc cho bạn; thật khó để tranh luận với thành công!
2. nhóm UX lấy câu chuyện và bắt đầu cuộc trò chuyện sớm - và các cuộc hội thoại là loại điểm chính của câu chuyện

Một yêu cầu cơ bản của Scrum là nhóm scrum có tất cả các kỹ năng cần thiết để tạo ra một sản phẩm có khả năng đáng tin cậy. Trong tình huống bạn mô tả, điều này không xảy ra.

Nhóm UX không sản xuất sản phẩm có khả năng đáng tin cậy và nhóm scrum không có khả năng tạo ra các lát chức năng theo chiều dọc vì họ không có tất cả các kỹ năng cần thiết. Đây là những rối loạn chức năng.

Sklivvz đã viết một bài tuyệt vời về các vấn đề mà các rối loạn chức năng trên có thể dẫn đến. Tóm lại, tôi không nghĩ bạn đang luyện tập Scrum.

Nhưng điều đó hoàn toàn không có gì sai với điều đó. Nếu bạn đã phát hiện ra một cách làm việc mang lại giá trị cho tất cả bạn, và bạn đều hài lòng với nó, hãy tiếp tục thực hiện nó. Lời khuyên duy nhất của tôi là kiểm tra và thích nghi thường xuyên.

Tuy nhiên, lưu ý rằng nếu mục đích của bạn là phân phối phần mềm bằng Scrum, bạn sẽ cần giải quyết các rối loạn chức năng được xác định.

Có hai vấn đề ở đây, một về thiết kế lấy người dùng làm trung tâm và vấn đề khác là căn chỉnh nước rút.

Thứ nhất : Câu chuyện của người dùng nên được liên kết với nhu cầu của người dùng, không chỉ tồn đọng. Các câu chuyện UX cần phải có giá trị rõ ràng cho người dùng. Điều này không yêu cầu đặc điểm kỹ thuật đầy đủ và một tuyên bố ngắn như,

"Người dùng sẽ có quyền truy cập dễ dàng hơn vào hoạt động tài khoản trên một trang thay vì chia cho nhiều trang"

có thể điều chỉnh và thích ứng với các triển khai khác nhau và vẫn rõ ràng về giá trị cho người dùng (truy cập dễ dàng hơn vào hoạt động tài khoản).

Thứ hai : liên kết Sprint. UX thiết kế các tính năng trong chạy nước rút X mà các nhà phát triển triển khai vào mùa xuân X + 1. Trong thực tế, điều này xảy ra ở nhiều cửa hàng và đôi khi nó có thể giống như thực hiện trong chạy nước rút X + 2 hoặc X + 3. Với một đội ngũ chặt chẽ và có kinh nghiệm, thiết lập này có thể hoạt động. Sẽ trở nên khó khăn nếu bạn có một nhóm mới hoặc thành viên mới, những người không quen thuộc với bộ kỹ năng, sở thích, thói quen, phong cách làm việc và xu hướng của các thành viên khác trong nhóm. Nếu bạn đã làm việc với nhau dưới 6 tháng thì đây có thể là một vấn đề.

Lùi lại một bước, và đánh giá lại. Về mặt tích cực, bạn có các nhà thiết kế và phát triển UX làm việc cạnh nhau, đó là một lợi ích. Bắt đầu bằng cách đảm bảo rằng câu chuyện của bạn có giá trị rõ ràng cho người dùng.

Một trong những vấn đề có thể xảy ra mà tôi thấy là trong Scrum, phạm vi cho chạy nước rút N + 1 thường được xác định ngay trước khi bắt đầu. Vậy làm thế nào bạn có thể thực hiện UX để chạy nước rút N + 1 câu chuyện trong lần chạy nước rút N trước khi bạn biết câu chuyện nào sẽ nằm trong phạm vi. Nếu bạn quyết định sửa phạm vi cho chạy nước rút N + 1 khi bắt đầu chạy nước rút N, bạn sẽ mất một số tính linh hoạt.

Tuy nhiên, trong Scrum, bạn chỉ có các câu chuyện người dùng cung cấp giá trị cho người dùng. Trong trường hợp của chúng tôi, các câu chuyện thiết kế UX không cung cấp giá trị như vậy (chúng giống như một hoạt động chải chuốt tồn đọng).

Theo cách tôi thấy, họ đang cung cấp rất nhiều giá trị cho người dùng của họ. Vấn đề là: người dùng của họ không phải là người dùng cuối cùng của công ty, người dùng của họ là nhóm phát triển sẽ triển khai tính năng này ở giai đoạn nước rút X + 1.

Bạn đang bị mắc kẹt trong tôn giáo của quá trình và trên đường đi, tôi thấy scrum / agile bị sử dụng sai và người dùng bị gắn nhãn sai. Scrum không phải là một công cụ phổ quát, nó là một phương tiện để kết thúc.

Tôi nghĩ rằng nhóm của bạn đã đánh dấu sai người dùng của bạn là ai và đang lên kế hoạch cho đối tượng sai.

Nhóm UX đang sử dụng scrum theo cách cổ điển, giá trị người dùng và thích ứng nhanh với đầu vào từ một số người dùng cuối kỳ diệu. Họ là một trong những người dùng. Nhóm của bạn đang lạm dụng scrum vì bạn chỉ đang điền vào cơ học để thực hiện một công việc thiết kế hiện có, không có gì cần thiết nhanh chóng và scrum đang lấp đầy vai trò của theo dõi quản lý.

Đó là lý do tại sao điều này cảm thấy sai đối với bạn, bạn thực sự không cần hoặc hưởng lợi từ scrum dưới bất kỳ hình thức nào vì bạn thuộc nhóm dịch vụ và công việc của bạn chuyển từ những người UX đã thực hiện các phần nhanh nhẹn / scrum.

Không có gì thực sự tồi tệ ở đó, chỉ là một quá trình khác được thực hiện so với những gì bạn đã nói.