Làm cách nào để quản lý thông số kỹ thuật trong Scrum?

Question

Đề cập đến this buddy question, tôi muốn biết cách người ta có thể quản lý thông số kỹ thuật trong quy trình Scrum? Tôi đang đối mặt với vấn đề này trong khi giao nhiệm vụ cho nhóm của tôi để chạy nước rút. Không cần phải nói - Tôi mới sử dụng Agile/Scrum.

Hiện tại, chúng tôi đang sử dụng trang thông số kỹ thuật của riêng mình để ánh xạ StoryId tới SpecId và ngược lại. Tôi nhận được sự chặt chẽ mà Scrum hiểu rõ hơn về quản lý dự án [hoàn thành công việc đúng lúc] và bạn cần một quy trình riêng biệt để quản lý thông số và yêu cầu.

Làm cách nào để quản lý thông số kỹ thuật trong quy trình Scrum?

Answer 1

Câu trả lời ngắn gọn là, bạn không.

Câu hỏi quan trọng để tự hỏi mình khi viết các thông số kỹ thuật này, đó là lý do chúng tôi thực hiện chúng? Giá trị trong spec là gì?

Giá trị trong thông số kỹ thuật thường đi kèm trong việc truyền đạt ý tưởng của doanh nghiệp với nhóm phát triển. Scrum được thiết kế để mang lại cho doanh nghiệp (dưới hình thức Chủ sở hữu sản phẩm) cho nhóm phát triển. Bằng cách tương tác với nhóm thường xuyên (nhớ, cá nhân và tương tác qua các quy trình và công cụ), và bằng cách xem phần mềm làm việc thường xuyên, doanh nghiệp có thể phối hợp với các nhà phát triển để sản xuất phần mềm giải quyết các vấn đề kinh doanh tốt hơn bằng cách cố gắng tìm hiểu toàn bộ trước khi bạn thử.

Đây là cách các dự án Agile thực hiện tốt hơn việc phân phối sản phẩm mà doanh nghiệp muốn thay vì sản phẩm mà họ yêu cầu.

Điều đó nói rằng, có một số tiêu chí cơ bản nhất định cần được đáp ứng. Chúng tôi có thể kiểm tra cho điều này, và như với bất kỳ thử nghiệm tốt, chúng tôi có thể tự động hóa nó.

Hãy xem BDD và Cucumber. Ngoài Câu chuyện của người dùng, bạn nên có một bộ điều kiện cơ bản về sự hài lòng, tốt nhất là ở định dạng "Cho/Khi/Sau đó". Các điều kiện này là tối thiểu bộ tiêu chí cho câu chuyện được chấp nhận là hoàn chỉnh.

Ví dụ: "Với tôi đã đăng nhập, khi tôi đăng xuất, sau đó tôi được đưa trở lại trang chủ".

Nếu bạn sẽ có tiêu chí chấp nhận, bạn sẽ muốn tự động hóa nó. Phần tồi tệ nhất của hầu hết các thông số kỹ thuật là chúng thường kết thúc và thu thập bụi khi dự án hoàn thành.

Ngoài ra, bạn không nên chỉ định nhiệm vụ cho nhóm. Các nhóm Scrum tự tổ chức và bất kỳ ai cũng có thể lấy bất kỳ nhiệm vụ nào mà họ cảm thấy họ có thể làm việc trong khi tôn trọng quyền ưu tiên của các câu chuyện. Swarming là một phần quan trọng trong những lợi ích của Scrum.

Bạn có thể cân nhắc việc mang theo một huấn luyện viên bên ngoài để hỗ trợ quá trình chuyển đổi của mình.

Answer 2

Khi tôi hiểu SCRUM, nó không quan tâm đến việc quản lý thông số kỹ thuật. Bạn phải phá vỡ/ánh xạ thông số kỹ thuật hoặc thông số kỹ thuật của bạn để thay đổi các câu chuyện và nhiệm vụ một cách riêng biệt. Nhưng bạn có thể có một nhiệm vụ cho việc này :).

Answer 3

Tôi nghĩ rằng cách dễ nhất là làm cho thông số kỹ thuật trở thành một phần của câu chuyện của người dùng trong các tác vụ. Liệt kê rõ ràng các tiêu chí chấp nhận trong mỗi một (hoặc nếu phần mềm theo dõi vấn đề của bạn cho phép bạn, hãy tạo chúng làm loại hạng mục công việc hạng nhất). Hãy để vấn đề trong bất cứ điều gì bạn sử dụng để theo dõi mục công việc trở thành tài liệu sống.

Có những hạn chế, chẳng hạn như tìm các vấn đề liên quan khi thông số thay đổi theo thời gian, nhưng điều này thường có thể được quản lý trong công cụ theo dõi mục công việc, giả sử bạn có thể liên quan đến vấn đề với nhau.

Cách chúng tôi làm là chúng tôi (thực sự là BA, không phải nhà phát triển) tạo ra một bảng đăng xuất để chủ sở hữu sản phẩm xem xét và chúng tôi cùng nhau tạo ra các nhiệm vụ. Nếu chúng tôi không thể tạo công việc hoặc có câu hỏi mở, chúng tôi sẽ quay lại chủ sở hữu sản phẩm với các câu hỏi và cập nhật bộ bài. Tất cả các bộ bài của chúng tôi được tổ chức (trong SharePoint) để chúng tôi có thể dễ dàng tìm thấy chúng trong tương lai.

Answer 4

Có một sự căng thẳng thực sự giữa Scrum và các phương pháp dev nhanh khác và viết đặc tả. Tôi nghĩ có hai điểm lớn của sự căng thẳng:

1. Bởi vì nhanh nhẹn nói tất cả mọi thứ nên được trên một thẻ chỉ mục, có nghĩa là bạn phải có công cụ lên kế hoạch ra đủ để phù hợp trên một thẻ chỉ mục. (Ví dụ: bạn có biết làm thế nào đó là tất cả đi làm.)

2. Một số điều không có ý nghĩa trong cách ly (việc sử dụng một trang tập tin tải lên mà không có một quản lý trang file tải lên là những gì, cho ví dụ.)

Bạn không phải thiết kế toàn bộ ứng dụng cùng một lúc, nhưng bạn phải có tầm nhìn toàn bộ ứng dụng. Sau đó, đặc biệt là nếu bạn có một nhà thiết kế và lập trình viên tách biệt, bạn sẽ thiết kế chức năng cho một đoạn có kích thước chạy nước rút tại một thời điểm. Những thiết kế này sau đó phải được chia nhỏ thành các khối có kích thước câu chuyện.

Đây là rất nhiều thiết kế chức năng phía trước, và tôi nghĩ rằng đó là bỏ qua trong rất nhiều nói về phương pháp nhanh nhẹn. Có lẽ một số cửa hàng có các nhà phát triển làm nhiều hơn về thiết kế. Ngoài ra, tôi nghĩ sẽ dễ dàng hơn khi sử dụng scrum/agile để thực hiện thay đổi/sửa lỗi cho các ứng dụng hiện có thay vì tạo các ứng dụng mới.

Điều tôi thấy hữu ích nhất là chống lại kích thước câu chuyện. Rất nhiều tổ chức đã phát điên, câu chuyện chỉ cần vài giờ.Cuốn sách scrum ban đầu nói 16 giờ, tôi nghĩ, thường đủ lớn để phù hợp với toàn bộ màn hình của một ứng dụng web. Vì vậy, "triển khai quản lý tài khoản của tôi" có thể là một câu chuyện (trái ngược với cách tiếp cận hàng trăm câu chuyện nhỏ "thực hiện tên người dùng", "triển khai mật khẩu", v.v.) Tham khảo tài liệu thiết kế của bạn cho "Quản lý tài khoản của tôi" chắc chắn có ảnh chụp màn hình hoàn hảo/nguyên mẫu/mockup để dev có thể xem chúng và sao chép/dán văn bản trực tiếp vào mã mà chúng đang viết và họ biết chắc chắn trường nào cần phải có (hoặc liên kết nào hoặc hình ảnh, hoặc bất cứ điều gì).

Answer 5

Đối với tôi, thông số kỹ thuật nằm trong các câu chuyện của người dùng. Chúng tôi xác định thông số kỹ thuật và các nhiệm vụ thực hiện cuộc họp scrum ban đầu cùng với chủ sở hữu sản phẩm. Các thông số kỹ thuật và nhiệm vụ chỉ dành cho thời gian sống của vòng lặp scrum vì mọi thứ có thể thay đổi trong lần lặp tiếp theo (trong trường hợp xấu nhất nhưng chắc chắn sẽ có những thay đổi).

Chúng tôi thường theo dõi các đặc điểm và nhiệm vụ trên bảng tính để mọi người biết họ đang làm gì. Tôi cũng đã thử một vài phần mềm để làm điều này và một trong những phần mềm thú vị nhất mà tôi gặp phải là từ [VersionOne] [1] và cũng từ [Rally] [2].

Nhưng tôi vẫn thấy rằng việc sử dụng bảng tính đơn giản là giải pháp nhanh nhất và đơn giản nhất.