Làm thế nào để một nhóm Scrum tài khoản cho các nhiệm vụ cơ sở hạ tầng trong cuộc họp lập kế hoạch?

Làm thế nào để một nhóm Scrum tài khoản cho các nhiệm vụ dev / cơ sở hạ tầng trong cuộc họp lập kế hoạch?

Thoạt nhìn, chúng không giống như những câu chuyện của người dùng vì chúng không mang lại giá trị cho người dùng cuối.

Tuy nhiên, việc gắn chúng dưới dạng các tác vụ vào một câu chuyện người dùng cụ thể đôi khi cũng không có ý nghĩa gì. Ví dụ: giả sử tác vụ là: "Cài đặt tre." Nhiệm vụ đó không bắt buộc để hoàn thành bất kỳ câu chuyện người dùng nào vì nhóm có thể tự xây dựng và triển khai. Vì vậy, việc gắn nó vào câu chuyện của người dùng sẽ không có ý nghĩa vì nhiệm vụ này không bắt buộc phải hoàn thành câu chuyện của người dùng.

Vì vậy, sau đó, điều này cho thấy rằng các tác vụ này trở thành câu chuyện của người dùng. Nhưng sau đó, nếu câu chuyện nhóm chỉ cho họ, thì điều này sẽ thay đổi vận tốc kỳ lạ vì Chủ sở hữu sản phẩm muốn biết vận tốc chống lại hồ sơ tồn đọng của anh ta, chứ không phải chống lại hồ sơ tồn đọng của anh ta với một loạt các câu chuyện người dùng kỹ thuật kèm theo.

Họ không thực sự là những câu chuyện của người dùng. Họ là những câu chuyện của các bên liên quan. Trừ khi phần mềm thực sự được trả tiền cho người dùng trực tiếp, thật hiếm khi một câu chuyện được tạo ra hoàn toàn vì lợi ích của họ.

Tôi cho bạn một vài ví dụ:

• bài viết được từ khóa, cho phép nhà quảng cáo có quảng cáo hiệu quả hơn
• CAPTCHA, có sẵn để ngăn người kiểm duyệt phải xử lý thư rác theo cách thủ công.

Hầu hết các câu chuyện kỹ thuật thực sự mang lại lợi ích kinh doanh, nhưng nó hiếm khi cho người dùng. Phrasing chúng theo một cách khác nhau có thể giúp đỡ. Tôi thường sử dụng mẫu Tính năng tiêm của Chris Matts:

In order to <achieve my goal>
As <the stakeholder who wants the goal>
I want (<some users to do>) <some stuff>.

Điều này công nhận rõ ràng tất cả các loại bên liên quan, bao gồm cả nhóm phát triển. Bây giờ bạn cũng có thể diễn đạt các câu chuyện kỹ thuật của mình, gọi ra lợi ích kinh doanh:

In order to minimize the risk of deploying something broken
As the team deploying the code
We want to spend a few days on an automated deployment system.

Tôi đã viết một vài bài đăng trên blog về điều này: Chúng không phải là Câu chuyện của người dùng , và Tính năng tiêm và xử lý các câu chuyện kỹ thuật . Mong họ giúp đỡ.

Vận tốc là thước đo năng lực của nhóm để thực hiện công việc hữu ích (trái ngược với Kéo). Nhiệm vụ cơ sở hạ tầng vẫn cung cấp giá trị người dùng cuối, mặc dù gián tiếp, bằng cách làm cho nhóm hiệu quả hơn trong thời gian dài. Tôi không gặp vấn đề gì khi theo dõi những điều này dưới dạng câu chuyện của người dùng (người dùng là nhóm nhà phát triển trong trường hợp này) và ưu tiên chúng một cách thích hợp. Chủ sở hữu sản phẩm trong giao tiếp tốt với (các) khách hàng sẽ có thể tìm ra nơi các nhiệm vụ đó có thể phù hợp mà không làm gián đoạn việc giao hàng.

Làm chúng dần dần.

Nếu không có bên liên quan nào muốn nó, đừng biến nó thành một câu chuyện. Chỉ cần chăm sóc nó, một chút tại một thời điểm. Ví dụ, lần đầu tiên bạn triển khai thủ công. Lần thứ hai, bạn tự động hóa một chút về nó. Lần thứ ba, bạn tự động hóa thêm một chút. Cuối cùng, bản dựng của bạn không phải là vấn đề lớn nhất, vì vậy bạn tập trung vào thứ khác.

Bạn sẽ có nhiều hơn các nhiệm vụ tập trung vào nhà phát triển này ngay từ đầu, và điều đó tốt; vận tốc của bạn (được đo bằng những câu chuyện) sẽ chỉ thấp hơn. Đó là một đại diện chính xác của tình huống. Nhưng bạn sẽ luôn có một số, vì vậy điều quan trọng đối với nhóm là tập thói quen làm những gì cần thiết để cải thiện quy trình.

IMHO phương pháp lý tưởng là đặt nỗ lực cơ sở hạ tầng như các nhiệm vụ theo câu chuyện của người dùng nơi nó lần đầu tiên giữ giá trị; như bạn đã đề cập.

Lấy ví dụ của bạn; xây dựng và triển khai thủ công ngụ ý nó là một nỗ lực liên tục và không có hình thức hoàn thành. Nó tồn tại vô thời hạn.

Điều tương tự cũng có thể xảy ra đối với mã tự động hóa bất kỳ phần nỗ lực nào trong một ứng dụng thông thường được thực hiện thủ công trước đó. Xác định nỗ lực này như một nhiệm vụ trong câu chuyện người dùng xác định hoàn thành; mà bản chất của nó có giá trị cho người dùng cuối.

Bạn chắc chắn có thể xây dựng và triển khai ứng dụng mỗi lần chạy nước rút nhưng sau đó trở thành một phần của các nhiệm vụ hàng ngày không được theo dõi chính thức thông qua hồ sơ tồn đọng và sau đó tất cả sẽ trở thành tranh luận.

Câu chuyện của người dùng xác định giá trị doanh nghiệp từ góc độ người dùng. Do đó, các nhiệm vụ cơ sở hạ tầng thường được coi là "lãng phí". Điều đó không có nghĩa là họ không cần. Nó có nghĩa là thực hiện nhiều nhiệm vụ cơ sở hạ tầng sẽ mang lại giá trị kinh doanh ít hơn. Do đó, các tác vụ cơ sở hạ tầng không nên được coi là kho lưu trữ của người dùng và không nên gắn liền với bất kỳ câu chuyện người dùng nào.

Trong một cuộc họp lập kế hoạch phải xem xét những nhiệm vụ cơ sở hạ tầng nào sẽ thực sự cần thiết trong lần chạy nước rút tiếp theo. Các cam kết sẽ được thực hiện với các nhiệm vụ cơ sở hạ tầng trong tâm trí. Nó sẽ ảnh hưởng đến vận tốc của nhóm, đó là kết quả chính xác bởi vì vận tốc đo lường giá trị kinh doanh mà nhóm có thể mang lại.

Tôi không bao giờ đánh đồng các câu chuyện của người dùng là phải cung cấp giá trị người dùng cuối. Nó có thể là phổ biến, nhưng nó không phải là cách chúng tôi xử lý các câu chuyện của người dùng. Đôi khi, các loại tác vụ này được coi là tăng đột biến, nhưng chúng tôi cũng có các câu chuyện người dùng thường xuyên, điểm được ước tính như bất kỳ câu chuyện người dùng nào khác.

Từ những gì tôi đã thấy phần lớn cơ sở hạ tầng được coi là nhất định. Điều này bao gồm những thứ như:

• Hệ thống kiểm soát sửa đổi;
• Hệ thống xây dựng tự động;
• IDE và các công cụ phát triển khác;
• Phát triển máy chủ;
• Quy trình triển khai; và
• Quy trình và tiêu chuẩn dự án.

Hầu hết các phương pháp tôi đã làm việc với không chú ý nhiều đến chúng. Những hình thức này mà tôi gọi là Bản phát hành 0. Những điều này nên được đặt ra trước khi bạn bắt đầu phát triển. Khi bạn bắt đầu thực hiện các câu chuyện, mọi thay đổi trong những điều này có thể được theo dõi dưới dạng cải tiến quy trình.

Mặc dù nhóm phát triển có thể có đầu vào, nhưng hầu hết các mục này nên được xử lý bởi nhóm hỗ trợ dự án. Tiêu chuẩn hóa các mục này trên nhiều dự án sẽ có một khoản hoàn vốn đáng kể cho tổ chức.

Hãy xem xét những điều sau đây:

• Nhóm Scrum thêm các tính năng chính cho bộ sản phẩm hiện có.

• Cần phải nâng cấp công nghệ / công cụ / tiện ích phát triển để luôn cập nhật dựa trên các thực tiễn tốt nhất về kỹ thuật.

• Thật ý nghĩa khi tải trước một bản phát hành với công việc này để qua quá trình phát hành Các vấn đề của Sprint có thể được giải quyết.

• Vì doanh nghiệp có được giá trị gián tiếp từ các mục này, tôi đề nghị rằng vì lợi ích của tính minh bạch, đây là các Mục tồn đọng sản phẩm (PBIs).

• Nhóm kích thước các mặt hàng này và xử lý chúng như bất kỳ PBI nào.

Vấn đề này đối với tôi làm nổi bật thực tế là tôi không muốn lãng phí thời gian để cố gắng tìm ra cách che giấu công việc này như các nhiệm vụ bên dưới các PBI tập trung vào kinh doanh khác.

Tôi không muốn kích thước PBI bị lệch bởi loại công việc cơ sở hạ tầng này. Tôi muốn xem những gì đang được thực hiện và hiểu những gì tôi đang trả tiền.

Tôi cũng nghĩ rằng có giá trị trong việc nhóm có được sự cam kết mà doanh nghiệp đang thực hiện bằng cách đầu tư vào cơ sở hạ tầng cần thiết để cung cấp các giải pháp chất lượng.

XP khuyên bạn nên có "số không lặp" trong đó tất cả các công cụ và cơ sở hạ tầng được thiết lập. Viết truyện cho những điều này là tùy chọn, nhưng có lẽ là một ý tưởng tốt. Có thể kiểm tra cơ sở hạ tầng của bạn (xây dựng gia tăng, kiểm tra và triển khai tự động, thông báo, v.v.) là có lợi

Trong nhóm của chúng tôi, chúng tôi làm như sau:

1. Giả sử một yếu tố tập trung thấp hơn .
2. Cố gắng đưa các tác vụ đó vào các câu chuyện của người dùng thực sự cần thực hiện chúng.
3. Nếu một số nhiệm vụ là hoàn toàn cần thiết, nhưng không cung cấp giá trị kinh doanh trực tiếp (chẳng hạn như di chuyển thử nghiệm đơn vị từ khung này sang khung khác), khi bắt đầu chạy nước rút, chúng tôi tạo ra một danh sách "các nhiệm vụ liên tục" . Đây là những nhiệm vụ liên quan đến phát triển không phải là câu chuyện, nhưng nhóm phát triển muốn chúng được thực hiện. Chúng tôi liệt kê các nhiệm vụ này trên bảng đen của chúng tôi, vẫn giữ nó tách biệt với các câu chuyện. Trong giai đoạn nước rút, tại mỗi cuộc họp hàng ngày, chúng tôi sẽ xem xét những gì đã được thực hiện để hoàn thành chúng.

Bước 2 là quan trọng nhất. Như trong một thực hành nhanh, trong Scrum, bạn cố gắng làm càng ít càng tốt để hoàn thành nhiệm vụ của mình. Hãy coi đó là một cách để không lãng phí cuộc sống của bạn khi làm những công việc không cần thiết: kinh nghiệm của tôi cho thấy rằng có đến 50% những thứ "tuyệt vời" cuối cùng bị bỏ rơi và không được biết đến trong thời gian dài.