Scrum có thể sử dụng thông số kỹ thuật trong Product Backlog thay vì câu chuyện của người dùng không?

Tại công ty tôi hiện đang làm việc cho chúng tôi bắt đầu thực hiện các dự án Scrum. Không quá khó để thuyết phục các nhà quản lý chuyển từ thác nước sang Scrum. Chúng tôi đang thực hiện một dự án nơi chúng tôi xây dựng lại nền tảng của mình từ đầu. Vì vậy, hầu hết các chức năng được biết đến và hầu hết các cải tiến là khá kỹ thuật.

Trong trường hợp này, có thể có lý do để có các nhiệm vụ kỹ thuật hơn là các câu chuyện của người dùng. Backlog của chúng tôi đã có tất cả các loại nhiệm vụ kỹ thuật như:

• Viết lại lớp DB từ MySQL sang PostgreSQL.
• Thực hiện đăng nhập hệ thống.
• Viết lại bộ đệm đối tượng.

Những điều xuất hiện trong quá trình đứng lên bao gồm những "nhiệm vụ nghiên cứu" dài được mong muốn, nhưng chúng không bao giờ được thực hiện. Ngoài ra, các thành viên trong nhóm tuyên bố ở giữa nước rút rằng các nhiệm vụ ngoài kế hoạch cần phải được thêm vào.

Scrum Master nên giải quyết vấn đề này như thế nào? Có thể là đối với loại dự án này, Scrum KHÔNG phải là con đường để đi?

TL; DR

Scrum không bắt buộc sử dụng các câu chuyện của người dùng; chúng chỉ đơn giản là một thực hành nhanh nhẹn hữu ích. Mặc dù Chủ sở hữu sản phẩm chắc chắn có thể sử dụng các thông số kỹ thuật thay vì câu chuyện của người dùng để xây dựng Product Backlog, hầu hết các vấn đề về quy trình khác của bạn xuất phát từ việc không tuân thủ các thực hành Scrum và nhanh nhẹn hiệu quả.

Nhiều vấn đề với quy trình của bạn

Scrum của bạn dường như bị phá vỡ theo nhiều cách khác nhau, bao gồm:

1. Thông số kỹ thuật của bạn thiếu một quan điểm rõ ràng hoặc đề xuất giá trị.
2. Các mục tồn đọng của bạn không bị ràng buộc với các Mục tiêu Sprint.
3. Quá trình chải chuốt Backlog của bạn bị thiếu hoàn toàn hoặc không tạo được các xung đột câu chuyện cho Product Backlog.
4. Quy trình Lập kế hoạch Sprint của bạn không phân tách đầy đủ các mục Product Backlog thành các mục Sprint Backlog.
5. Nhóm của bạn không chính xác bao gồm sự không chắc chắn về các mục tồn đọng trong các ước tính Lập kế hoạch Sprint.
6. Nhóm của bạn không tôn trọng các nguyên tắc cơ bản của quyền anh thời gian hoặc tính toàn vẹn của Sprint.

Mặc dù Scrum không phải lúc nào cũng phù hợp cho mọi dự án, nhưng trong trường hợp này, sẽ chính xác hơn khi nói rằng Scrum không hoạt động vì nhóm không thực sự làm Scrum. Câu hỏi của bạn về câu chuyện của người dùng chỉ là một phần nhỏ trong các vấn đề quy trình lớn hơn mà nhóm của bạn phải đối mặt.

Tại sao lập trình viên Agile ôm lấy câu chuyện của người dùng

Thông số kỹ thuật là một cách cơ bản để phá vỡ các yêu cầu. Các yêu cầu không được cung cấp theo quan điểm không cung cấp bất kỳ hướng dẫn hữu ích nào cho các nhà phát triển. Sử dụng các ví dụ được đăng của bạn:

• Viết lại bộ đệm đối tượng. Tại sao? Mục tiêu là gì? Ai nhận được lợi ích? Ai có thể cung cấp làm rõ về nhiệm vụ? Nếu điều này được gắn với một yêu cầu phi chức năng, mục tiêu của dự án này là gì?
• Thực hiện đăng nhập hệ thống. Tại sao? Ai sẽ đọc nhật ký? Nhật ký cần chứa thông tin gì? Làm thế nào bạn sẽ biết nếu định dạng nhật ký hoặc dữ liệu nhật ký là hữu ích?

Từ quan điểm của một nhà phát triển, việc không thể trả lời các loại câu hỏi này dẫn đến chính xác các loại vấn đề mà bạn mô tả. Đó là những gì câu chuyện của người dùng làm: họ cung cấp bối cảnh rất cần thiết và đóng vai trò giữ chỗ cho các cuộc hội thoại bổ sung với các bên liên quan hoặc người dùng cuối về các tính năng cụ thể.

Bạn không nên sử dụng các câu chuyện của người dùng vì bạn nghĩ rằng đó là một yêu cầu khung hoặc bởi vì đó là một thực hành nhanh nhẹn được chấp nhận rộng rãi. Thay vào đó, bạn nên làm việc để tạo và sử dụng chúng một cách hiệu quả vì nó làm cho các tác vụ lập trình dễ dàng hơn và nghề lập trình trở nên thú vị hơn. Mileage của bạn có thể thay đổi, tất nhiên.

Tôi không nghĩ vấn đề ở đây là Scrum như vậy, tôi nghĩ vấn đề là không có dự án nào được xác định rõ ràng có thể giao được và (tôi đã trải nghiệm điều này nhiều lần) không có hướng rõ ràng.

Tôi nghĩ rằng các nhiệm vụ kỹ thuật của bạn là tốt, có thể ở khía cạnh lớn nhưng có thể đo lường được và có thể xác định được nên hoàn toàn tốt cho một câu chuyện.

Nhiệm vụ nghiên cứu là một lá cờ đỏ khổng lồ đối với tôi trong Scrum vì chúng cung cấp rất ít lợi ích có thể nhìn thấy và có thể tạo ra phạm vi khổng lồ. Tôi ủng hộ việc giới hạn các trả trước này trong một lần chạy nước rút, chúng không nên được thêm vào và chúng chắc chắn không nên được thêm vào với chi phí cho các mục tiêu đã cam kết. Nếu họ cần hoàn thành một nhiệm vụ chạy nước rút đã thỏa thuận thì sự phụ thuộc đó đã rõ ràng trong việc lập kế hoạch (nếu không, họ đã ước tính điều gì?).

Theo kinh nghiệm của tôi, các dự án có nhiều "đột biến điều tra" là vỏ bọc cho các nhà phát triển không thực sự làm được gì nhiều và muốn dành thời gian tìm hiểu về điều tuyệt vời mới sáng bóng hơn là tạo ra giá trị kinh doanh. Tôi không đề xuất nhóm của bạn đang làm điều này, nhưng một dự án cần có mục tiêu rõ ràng và nếu các nhà phát triển được tự do "nghiên cứu" thì họ sẽ làm điều đó và tiếp tục thực hiện, miễn là bạn cho phép.

Scrum nói rằng bạn tốt hơn nên có một sản phẩm có thể giao cho khách hàng của bạn. Tuy nhiên, vấn đề ở đây là, nó không chỉ định sản phẩm có thể giao được và khách hàng .

Nói cách khác, trong trường hợp cụ thể của bạn, bạn có thể xác định sản phẩm có thể phân phối của mình là cải tiến mã, thay đổi nền tảng, viết lại và thiết kế lại, v.v. và coi người quản lý kỹ thuật của bạn là khách hàng của bạn.

Điều đó có ý nghĩa 100% với tôi. Bạn tạo một hồ sơ tồn đọng kể những câu chuyện của người dùng sản phẩm của bạn và ai là người dùng? Quản lý kỹ thuật. Do đó, các mục như:

1. Là người quản lý kỹ thuật, tôi muốn cơ sở dữ liệu của mình thay đổi từ MySQL sang X, để tôi có thể tăng khả năng mở rộng
2. Là nhà phát triển, tôi muốn có một hệ thống ghi nhật ký toàn diện, để tôi có thể chẩn đoán hiệu quả hơn

Và những gì bạn cung cấp cho khách hàng của bạn (người quản lý kỹ thuật) là một hệ thống đăng nhập.

Tuy nhiên, liên quan đến các nhiệm vụ R & D mà bạn đã nói, tôi khuyên bạn nên đọc về các đột biến trong Scrum. Về cơ bản, chúng là các tác vụ nhỏ được đóng hộp theo thời gian giúp bạn xác định thời gian cần thiết để thực hiện các tác vụ lạ lớn hơn.

Là Scrum Master, bạn có thể muốn xem xét các lần chạy nước rút dài hơn vì tính chất của công việc. Điều này sẽ cung cấp cho bạn thêm một chút bộ đệm cho các nhiệm vụ "nghiên cứu". Tuy nhiên, tôi nghĩ rằng bạn cần đảm bảo rằng các tác vụ tạo ra một số loại sản phẩm công việc / bằng chứng về khái niệm trong mã. Bạn mong đợi một lập trình viên sẽ làm gì? Yêu cầu họ lấy thứ gì đó để làm việc và sử dụng thông tin này để xác định xem A: nó có làm những gì chúng ta muốn B: nó hoạt động tốt hơn C: Sẽ mất bao lâu để tăng tốc độ và bắt đầu nhận được bất kỳ ý tưởng nào trong bao lâu lấy để làm một cái gì đó

Nếu bạn phát hiện ra bạn không biết nhiều như bạn nghĩ về việc viết lại hiện tại, bạn có thể đi đến các chu kỳ nước rút ngắn hơn. Đừng ngại điều chỉnh chúng khi bạn đi cùng; đây là những gì có nghĩa là nhanh nhẹn. Sau khi nghiên cứu, bạn cũng có thể quyết định đi với công nghệ mới. Đây có thể là một lý do khác để rút ngắn nước rút trước khi vượt quá tầm kiểm soát. Bạn có thể phát hiện ra giữa cuộc đua nước rút, những thứ mới sẽ không hoạt động. Dừng chạy nước rút và điều chỉnh nó với công nghệ cũ. Sau tất cả, các nhà phát triển của bạn đã có thể so sánh và đối chiếu các phương thức cũ và mới.

Bạn đang giải quyết nhu cầu của các nhà phát triển của mình và trong trường hợp này, ứng dụng sẽ được viết lại. Tôi đoán có những Chủ sở hữu sản phẩm muốn dự án này hoàn thành sớm hơn là muộn hơn và sẽ không chấp nhận nhu cầu "nghiên cứu" như một lý do dài hạn.

Một số chiến lược dưới đây có thể giúp ích,

1. Có, bạn có thể tồn đọng với các câu chuyện kỹ thuật .

   Giống như một câu chuyện người dùng, đây cũng phải là Câu chuyện kỹ thuật, tập trung vào những lợi ích mà nó sẽ mang lại cho người dùng cuối. Đây là một số lời khuyên viết nó. Đây là những câu chuyện sẽ mang lại giá trị nội tại cho sản phẩm như bạn muốn chuyển đến một back-end tốt hơn, v.v.

2. Đối với nhiệm vụ điều tra (nghiên cứu) sử dụng Spike

   Spike là một thử nghiệm cho phép các nhà phát triển tìm hiểu vừa đủ về một điều chưa biết trong câu chuyện của người dùng, ví dụ như một công nghệ mới, để có thể ước tính câu chuyện của người dùng đó. Một cành phải được đóng hộp thời gian. Điều này xác định thời gian tối đa sẽ được dành cho việc học và sửa lỗi ước tính cho mức tăng đột biến.