Có phải những câu chuyện về người dùng kỹ thuật của người Viking được cho phép trong Scrum?

Là những câu chuyện người dùng kỹ thuật được phép trong Scrum? Nếu vậy, mẫu tiêu chuẩn để viết câu chuyện người dùng kỹ thuật trong Scrum là gì? Có giống nhau không As a <user> I want to do <task> so that I can <goal>??

Tôi đã đọc trong một số blog rằng một nhà phát triển không phải là người dùng , nhưng tôi cũng đã đọc rằng Scrum không bắt buộc những điều này. Có vài blog, nơi họ đã chia sẻ những câu chuyện người dùng với hệ thống như sử dụng , giống như nó as a <user who is not end user> i want to <system functionality> so that <some techinical thing>. Vậy cái nào là tiêu chuẩn?

Chẳng hạn, có những câu chuyện của người dùng như:

Là người đánh giá, tôi muốn tải lên hình ảnh của bất kỳ khách sạn / thực phẩm nào để người dùng khác có thể xem và thích chúng

Là người dùng, tôi muốn thêm nhận xét ảnh để tôi có thể giải thích quan điểm của mình tốt hơn

Bây giờ đối với cả hai câu chuyện người dùng này, có một mục kỹ thuật lớn - Lưu và truy xuất hình ảnh

Vì vậy, tôi có thể thêm một câu chuyện kỹ thuật có tiêu đề "Cơ chế lưu trữ và truy xuất hình ảnh", với mô tả sau đây không?

Là một nhà phát triển, tôi muốn phát triển một cơ chế lưu trữ và truy xuất hình ảnh để người dùng có thể thêm / xem hình ảnh bất cứ nơi nào cần thiết

Câu chuyện kỹ thuật được cho phép, nhưng tôi sẽ khuyên bạn cố gắng tránh chúng càng nhiều càng tốt.

Ví dụ: câu chuyện của bạn để lưu và truy xuất hình ảnh có thể dễ dàng được viết thành hai câu chuyện người dùng thông thường

1. Là người đánh giá, tôi muốn các bức ảnh đã tải lên của tôi được lưu trữ liên tục để người dùng khác có thể xem chúng bất cứ lúc nào.
   (Lưu ý rằng điều này giả định rằng trong câu chuyện tải lên ban đầu của bạn, hình ảnh sẽ không được lưu trữ liên tục sau khi tải lên. Mặc dù điều này có vẻ lạ, nhưng đó là một cách hợp lệ để tách các câu chuyện để có thể quản lý chúng.
2. Là người dùng, tôi muốn xem hình ảnh được tải lên tại một thời điểm thuận tiện cho tôi.
   (Điều này ngụ ý rằng hình ảnh được lưu trữ có thể được lấy sau này.)

Câu chuyện kỹ thuật nên được dành riêng cho công việc quan trọng đối với tổ chức, nhưng không được hiển thị trực tiếp dưới dạng tính năng / chức năng cho người dùng. Ví dụ: thêm cân bằng tải để xử lý số lượng lớn hơn hoặc yêu cầu.

Câu hỏi, cho ví dụ cụ thể của bạn, sẽ là tại sao nhà phát triển muốn phát triển cơ chế lưu trữ và truy xuất hình ảnh để người dùng có thể thêm / xem hình ảnh bất cứ nơi nào cần, trừ khi người dùng muốn thêm hoặc xem hình ảnh?

Đó là, trong khi câu hỏi của bạn là một câu hỏi hay, ví dụ không. Đây là một tính năng người dùng và nên có một câu chuyện người dùng. Và nếu người dùng không thực sự cần chức năng đó thì nhà phát triển không nên làm điều đó.

Một câu chuyện kỹ thuật có nhiều hơn "Là một nhà phát triển, tôi muốn giảm sự trùng lặp trong các mô-đun lưu trữ dữ liệu, để tôi không phải thực hiện mọi thay đổi ở 6 vị trí."

Câu hỏi liệu những thứ này có nên được đưa vào nước rút hay không là một câu hỏi khó, và nó phụ thuộc phần nào vào việc bạn coi là khách hàng của mình. Đó có phải là người dùng cuối, hoặc doanh nghiệp sử dụng bạn, hoặc doanh nghiệp sử dụng doanh nghiệp sử dụng bạn?

Rất nhiều hướng dẫn quan điểm trong ngành được thực hiện bởi những người làm việc cho các công ty tư vấn. Từ quan điểm đó, tôi có thể thấy lập luận rằng các câu chuyện của nhà phát triển là xấu. Họ chỉ nên là một phần của những gì bạn làm, hàng ngày, vô hình với công ty đang trả tiền cho nó. Các công ty đó theo bản năng biết rằng việc tăng hóa đơn quá cao đảm bảo rằng công việc của bạn cạn kiệt, vì vậy mọi nhà phát triển làm việc theo nguyên tắc chỉ phát triển kỹ thuật để cải thiện thời gian phát triển của bạn hoặc cải thiện khả năng phát hành phần mềm không có lỗi.

Kinh nghiệm của tôi là nhiều hơn khi làm việc trong các nhóm nội bộ, cung cấp phần mềm trực tiếp cho công ty trả lương cho tôi. Trong nhiều công ty đó, có một rào cản niềm tin giữa doanh nghiệp và cánh kỹ thuật của doanh nghiệp. Trong tất cả chúng, có một tâm lý khác nhau, trong đó giảm chi phí là mỗi bit khi tăng thu nhập.

Trong các môi trường đó, có thể tốt để xác định các câu chuyện nhà phát triển quan trọng. Nó làm tăng khả năng hiển thị, thu hút sự tin tưởng và khuyến khích các nhà phát triển cũng như quản lý suy nghĩ về giá trị của các nhiệm vụ đó đối với doanh nghiệp và ưu tiên phù hợp.

Cuối cùng, tôi khuyên bạn nên thử nó. Và, nếu nó không mang lại giá trị, hãy ngừng làm điều đó.

Nhưng bản năng của tôi nói rằng nếu bạn đang xem xét giá trị của sự phát triển này đối với doanh nghiệp, bạn thậm chí sẽ không cố gắng biến nó thành một câu chuyện của nhà phát triển. Nó tốt cho người dùng cuối hoặc không. Nếu không thì sẽ không có giá trị cho doanh nghiệp.

Đây là một câu hỏi hay. Tôi không có câu trả lời chính thức nhưng nơi tôi làm việc, chúng tôi thêm câu chuyện của người dùng kỹ thuật và gọi họ là nợ kỹ thuật. Nếu họ không được phép, tôi sẽ tìm một số cách khác để bổ sung họ cho mục đích đơn thuần là để công việc của tôi được ghi lại và truyền đạt cho doanh nghiệp. Tương tự như vậy, có tài liệu này nhắc nhở chúng ta về những gì cần thiết cho các dự án trong tương lai.

Ví dụ, việc ngắt kết nối trong một ứng dụng mới, nếu chúng tôi không được phép thêm các câu chuyện kỹ thuật, là tôi sẽ ồn ào trong một tuần sau khi bắt đầu chạy nước rút tạo mô hình cơ sở dữ liệu và chờ nhà mô hình dữ liệu của tôi phê duyệt chúng, lặp đi lặp lại với trình tạo mô hình và khi hoàn thành, gửi các tập lệnh đến dba và đợi chúng tạo các đối tượng db. Trong thời gian này, tôi sẽ tạo một dự án mã mới, một số chức năng ORM cơ bản và bố cục kiểm soát nguồn của tôi và khi tất cả được nói và thực hiện, tôi sẽ có thời gian để tạo một trang đích trống và triển khai.

Ngày qua ngày trong khi điều này đang diễn ra, nếu tôi không ghi lại thông tin, doanh nghiệp sẽ lúng túng rằng nhóm của chúng tôi không làm việc trong dự án khi thực tế chúng tôi đang làm. Có những mục này trong các câu chuyện có nghĩa là chúng ta có thể kiểm tra công việc của mình, ghi chép lại công việc và liên lạc với doanh nghiệp mà chúng ta đang tiến bộ.

Nếu có một cách thực hành tốt nhất để làm điều này thì tôi đều nghe thấy.

Cảm nhận cá nhân của tôi là các đội không nên quá nôn nao về những gì scrum cho phép và lo lắng hơn về những gì làm việc cho nhóm. Một phần lý do khiến scrum nhận được một chút tiếng xấu là các học viên có thể trở thành quá trình tập trung , điều này trái với các ý tưởng đằng sau việc quản lý dự án nhanh.

Bây giờ tôi sẽ rời khỏi hộp xà phòng của mình nhưng nếu bạn thắc mắc liệu bên dưới có thực sự là 'scrum' hay không, xin vui lòng (đọc lại) ở trên.

Điều quan trọng là phải phân tách 'các tính năng' mà các câu chuyện của người dùng xác định và 'các sản phẩm' mà nhóm kỹ thuật cần cung cấp để hỗ trợ các tính năng đó. Trong trường hợp này, cần lưu và truy xuất hình ảnh là một kỹ thuật có thể phân phối mà bạn (với tư cách là nhóm kỹ thuật) cần thực hiện. Khá nhiều câu chuyện sẽ cần một số sản phẩm kỹ thuật.

Lý do điều này rất quan trọng là một kỹ thuật có thể phân phối (tự nó) không phải là thứ tạo ra giá trị từ góc độ người dùng. Nếu bạn bắt đầu theo dõi các sản phẩm kỹ thuật dưới dạng câu chuyện của người dùng, bạn có thể dễ dàng rơi vào cái bẫy coi đầu ra kỹ thuật là sản xuất giá trị doanh nghiệp. Làm vấy bẩn vùng biển theo cách này sẽ gây nhầm lẫn công việc hỗ trợ các mục tiêu kinh doanh (tức là những thứ tốn tiền) với các mục tiêu kinh doanh thực tế (tức là những thứ tạo ra tiền.)

Tất cả các câu trả lời trên không thể tham chiếu tài liệu nguồn có thẩm quyền cho khung Scrum: Hướng dẫn Scrum .

Product Backlog liệt kê tất cả các tính năng, chức năng, yêu cầu, cải tiến và sửa lỗi tạo thành các thay đổi được thực hiện cho sản phẩm trong các bản phát hành trong tương lai.

Nên tập trung vào giá trị sản xuất. Đôi khi giá trị đó đến từ công việc kỹ thuật, chẳng hạn như nâng cấp cơ sở hạ tầng. Đừng loại trừ những mục đó!

Thuật ngữ người dùng không bao giờ xuất hiện trong Hướng dẫn Scrum vì

đó là một khung trong đó bạn có thể sử dụng các quy trình và kỹ thuật khác nhau.

Sử dụng câu chuyện người dùng chỉ là một kỹ thuật có thể để ghi lại PBIs. Mặc dù người ta thường thấy định dạng "Như một, tôi muốn, Vì vậy,", nó có thể phản tác dụng với mục đích ban đầu của nó . Định dạng rắc rối này cũng đã được giải quyết tại Agile 2017 .

Hiểu và sử dụng cắt dọc sẽ hữu ích cho việc giảm kích thước của các mục tồn đọng Sản phẩm (PBIs). Xem xét việc cắt một lần lưu và Lấy mục đó thành lưu và truy xuất mục s .