Nhiều nhóm scrum chuyển sang tồn đọng đơn

Chúng tôi hiện có 5 nhóm scrum hoạt động tồn đọng sản phẩm của riêng họ trong năm qua. Mỗi nhóm làm việc trên hệ thống chuyên dụng của riêng họ nhưng công nghệ cơ bản là như nhau .Net.

Đã có rất nhiều cuộc thảo luận về việc chuyển sang các nhóm dựa trên tính năng làm việc tồn đọng một lần duy nhất. Lý do là một trong những hệ thống chính của chúng tôi có một lượng công việc đáng kể sắp tới và chúng không đủ năng lực để cung cấp tất cả các công việc trong năm. Một lý do khác mà tôi tin là lý do quan trọng là nó cho phép linh hoạt hơn để điều chỉnh các thay đổi trong danh mục đầu tư một cách nhanh chóng.

Một quyết định đã được đưa ra để thay đổi hai đội làm việc trên một hồ sơ tồn đọng duy nhất nhưng các nhà phát triển không có kinh nghiệm trên các hệ thống khác. Một điều chúng tôi đang làm là lướt qua bằng cách chuyển một nhà phát triển hệ thống kinh nghiệm sang nhóm.

Câu hỏi của tôi là, bạn đã có kinh nghiệm chuyển sang tồn đọng duy nhất cho hai hoặc nhiều hệ thống khác nhau. Những thách thức của bạn là gì? Bạn cần làm gì để nó hoạt động?

Chúng tôi quản lý khoảng một nửa tá dự án bằng cách sử dụng một hồ sơ tồn đọng. Tôi nói "về" bởi vì nó phụ thuộc vào cách bạn muốn phân biệt các dự án.

Một cách lỏng lẻo, chúng tôi có năm hoặc sáu chủ sở hữu sản phẩm, một số người sở hữu nhiều hơn một sản phẩm. Chúng tôi có một nhóm nhỏ hợp lý với bảy nhà phát triển và một nhóm trưởng cũng mã hóa khi anh ấy có thời gian. Và chúng tôi có một vài nhà truyền giáo làm việc với dân gian quá trình của chúng tôi để chuyển ý tưởng vào đường ống dẫn. Tất nhiên, một số người dân đội một vài chiếc mũ làm vấy bẩn mọi thứ nhưng tôi sẽ bỏ qua điều đó cho câu trả lời của tôi. Thật thú vị, chúng tôi không có một bậc thầy chính thức.

Chúng tôi đã không phải hợp nhất các hồ sơ tồn đọng lại với nhau, nhưng có vẻ như đó là một nhiệm vụ đơn giản về phía bạn.

Giữ mọi thứ ngăn nắp có thể là một nỗi đau thực sự, vì vậy đây là một số điểm bạn sẽ muốn xem xét.

• Quản trị là chìa khóa. Mọi người có ngón tay hành chính trong chiếc bánh phải giao tiếp với người khác trước khi thực hiện những thay đổi đáng kể. Và / hoặc những người thực hiện thay đổi phải thoải mái với thẩm quyền của họ để làm như vậy (và sẵn sàng nhận nhiệt cho một thay đổi xấu). Các nhà sản xuất thay đổi của chúng tôi có sự ủng hộ điều hành mạnh mẽ và các đường được vẽ khá rõ ràng xung quanh các khu vực. Nhưng khi có nghi ngờ, chúng tôi hỏi trước khi thay đổi.

• Có thể có nhiều chi phí liên quan hơn với việc chải chuốt tồn đọng, ưu tiên và khởi động. Ưu tiên như một nghi lễ chịu đựng nhiều nhất bởi vì thật khó để có được tất cả các chủ sở hữu cùng nhau một cách thường xuyên. Chúng tôi sử dụng một số người đi đường để thương lượng ưu tiên và / hoặc đưa ra những tin tức xấu về việc không cắt giảm ưu tiên.

• Rất nhiều công việc của chúng tôi được thúc đẩy bởi cam kết bên ngoài. Điều đó lấy đi một số quyền tự chủ trong các quyết định của chúng tôi, nhưng đó là thực tế của kinh doanh. Nhà phát triển của bạn cần phải nhận thức được sự thay đổi đó mặc dù. Lông vũ có thể bị xù lông nếu mất kiểm soát. Mặc dù vậy, chúng tôi cố gắng không cam kết quá mức và chúng tôi đã phải nói "không" với một số chủ sở hữu sản phẩm đang ngồi trên đỉnh của việc đưa nó vào giai đoạn nước rút.

• Chúng tôi thường sử dụng hai phương pháp để gắn thẻ sản phẩm tồn đọng của sản phẩm. Chúng tôi sử dụng cả hai đơn giản vì nó làm cho việc chải chuốt và các nhiệm vụ khác dễ dàng hơn.

  1. Chúng tôi sẽ mở đầu tiêu đề PBI bằng tên sản phẩm hoặc phiên bản tốc ký.
  2. Chúng tôi có một lĩnh vực riêng chỉ ra sản phẩm tổng thể, và điều đó cũng phải được điền vào.

• Chúng tôi phải nỗ lực có ý thức vào đào tạo chéo và đảm bảo rằng tất cả mọi người đều có được trong các lĩnh vực khác nhau. Chúng tôi có một cơ sở mã rất lớn đối với nhóm phát triển của chúng tôi. Một số mã chúng tôi làm là rất chuyên ngành là tốt. Trưởng nhóm của chúng tôi là tuyệt vời trong vấn đề đó và anh ấy sẽ đẩy mức độ cam kết của chúng tôi xuống một mức để chúng tôi có thể đủ khả năng thiếu hiệu quả đến từ đào tạo chéo. Có một đội ngũ mạnh mẽ là rất quan trọng trong vấn đề này.

• Chúng tôi làm hết sức mình để duy trì khung thời gian nước rút của chúng tôi. Các dự án phức tạp với các thành viên nhóm mới hơn chuyển thành không phổ biến với các cam kết. Quá trình xung quanh chi nhánh của bạn sẽ thực sự giúp đỡ ở đây. Tất cả các công việc của chúng tôi được thực hiện đối với một chi nhánh sau đó được hợp nhất trở lại để phát hành thân cây. Chúng tôi cũng có một máy chủ xây dựng chạy hàng đêm ngoài các kích hoạt đặc biệt. Các nhà phát triển phá vỡ bản dựng biết và giải quyết vấn đề trong vòng 24 giờ. Giai đoạn = Stage. Không giải quyết trong vòng 24 giờ có nghĩa là cam kết của bạn bị đẩy lùi và các nhà phát triển cấp cao cho họ đau buồn. Và các nhà phát triển cấp cao là những người khó khăn nhất khi nói đến việc duy trì việc xây dựng.

• Mã đi bộ và đánh giá trở nên quan trọng hơn. Nó giúp mọi người luôn cập nhật về những gì thay đổi trong các lĩnh vực khác nhau.

• Tương tự như vậy, standup hàng ngày liên quan đến tất cả các nhà phát triển cộng với người dùng UI của chúng tôi. Chúng ta đang ở ngay rìa của giao tiếp hợp tác có lợi và không hiệu quả từ quá nhiều người. Nhưng chúng tôi giữ trạng thái chờ đến dưới 15 phút và sẽ nhanh chóng chuyển từ các cuộc thảo luận bên lề. Thông thường chúng tôi hoàn thành trong 5 đến 10 phút.

• Tôi không thể nói về các tác động đối với các số liệu như vận tốc hoặc cam kết chung và tỷ lệ phát sinh. Những khía cạnh đó không đủ quan trọng để chúng ta theo dõi chặt chẽ. YMMV, vì vậy hãy xem xét điều đó. Điều này cũng cho rằng mỗi đội có một định nghĩa tương đối hợp lý về điểm câu chuyện. Nếu không, điều đó sẽ làm xáo trộn các ước tính ban đầu sau khi hợp nhất. Nó cũng sẽ tạo ra một số vấn đề cho các so sánh lịch sử vì bạn không sử dụng cùng một đơn vị đo lường như trước đây. Cách dễ dàng là chỉ cần khai báo nó là "nhóm mới" cho các số liệu và chỉ bắt đầu thu thập dữ liệu sau khi hợp nhất.

• Chúng tôi đã thấy lợi ích đáng kể từ phương pháp này. Chúng tôi đã có một số lần chạy nước rút trong đó tất cả các tay tập trung vào một khu vực và chúng tôi có thể loại bỏ rất nhiều thay đổi trong một khoảng thời gian ngắn. Bạn không nên đánh giá thấp giá trị xuất phát từ việc có thể nhanh chóng áp dụng gấp đôi số lượng nhà phát triển bình thường cho một dự án cụ thể. Nhưng bạn phải đưa vào đào tạo chéo trước thời hạn. Điều đó cũng có nghĩa là chúng tôi không bao giờ có nhà phát triển với "không có gì để làm" vì chu kỳ kiểm tra hoặc chải chuốt hoặc bất cứ điều gì. Chúng tôi luôn luôn tồn đọng để giải quyết.

• Dành thời gian cho các dự án R & D. Nếu không, quá dễ để họ trượt qua vết nứt và bạn mất cơ hội đầu tư vào những khu vực đó.

• Thực sự hoạt động trên mã hóa ít bản ngã và trong khi bạn có thể có các chuyên gia trong một khu vực, bạn không có chủ sở hữu của một khu vực mã. Ngăn chặn cơ hội cho bản ngã bị bầm tím rất quan trọng khi các phong cách khác nhau được đưa vào một khu vực. Miễn là mã mới đáp ứng các tiêu chuẩn của nhóm và có chức năng, nó sẽ tốt. Chỉ vì đó không phải là cách chuyên gia sẽ làm nó không thành vấn đề.

• Hãy chắc chắn rằng các đội tham gia đang sử dụng các quy ước và phong cách mã hóa giống nhau. Không có gì giống như sự không nhất quán ở đây để tàn phá những nỗ lực của bạn khi tích hợp.

• Tiếp tục giữ lại quá khứ của bạn, và giữ chúng như một nhóm. Điều quan trọng là có được phản hồi của mọi người về những gì đang hoạt động, những gì không hoạt động và những gì cần phải được thử khác nhau. Điều này giúp thúc đẩy cảm giác tình bạn trong nhóm và mang lại cảm giác sở hữu xung quanh quá trình phát triển.

Câu trả lời đúng của Scrum là "Hỏi nhóm (s)". Đây là nguyên tắc tự tổ chức, nơi họ sẽ có thể tự cơ cấu lại để hoàn thành công việc một cách nhanh chóng. Bạn thấy nhiều người trong các đội có kiến ​​thức bối cảnh hơn người ngoài cuộc và họ biết điều gì là tốt nhất. Điều này cũng bao gồm Chủ sản phẩm.

Tôi hiểu rằng bạn đã đến đây và đặt câu hỏi vì có điều gì đó không đúng và bạn có những mối quan tâm ẩn giấu. Vì vậy, tôi sẽ cung cấp cho bạn một vài gợi ý để thảo luận với nhóm để đưa ra quyết định đúng đắn.

Chủ sản phẩm

Chỉ có một chủ sở hữu sản phẩm cho một hồ sơ tồn đọng và đây phải là một người kinh doanh hoặc người đại diện cho doanh nghiệp. Nó không nên là quản lý CNTT. Một hồ sơ tồn đọng lớn có nhiều mặt hàng và với nhiều đội, nó có thể là quá nhiều cho một PO để giải quyết. Bạn có thể muốn giữ tồn đọng riêng biệt vì lý do này.

Nếu có nhiều PO, thì bạn chắc chắn cần nhiều backlog vì các đội nên được dành riêng trong một lần chạy nước rút cho một PO và tồn đọng. Lý do là một nhóm không cần quản lý xung đột giữa các ưu tiên của chủ sở hữu sản phẩm.

Phát triển sản phẩm so với bảo trì

Các nhóm bảo trì làm việc trên nhiều cải tiến nhỏ, lỗi trên một số sản phẩm khác nhau và có thể với một số chủ sở hữu sản phẩm. Các nhóm BAU này cần sự hỗ trợ của quản lý CNTT để giúp lên lịch và quản lý xung đột giữa nhiều chủ sở hữu sản phẩm.

Các nhóm dự án nên tập trung vào một sản phẩm tại một thời điểm để giảm thiểu chuyển đổi ngữ cảnh và cung cấp một sản phẩm tuyệt vời tại một thời điểm. Chuyển đổi bối cảnh có thể dẫn đến việc cung cấp nhiều sản phẩm tầm thường với một số mức độ nợ kỹ thuật.

Chuyển đổi bối cảnh

Làm việc trên nhiều sản phẩm hoặc các tính năng khác nhau gây ra chuyển đổi ngữ cảnh làm chậm năng suất của các nhóm. PO nên tính đến yếu tố này khi tìm ra cái gì tiếp theo và nhóm nào nên làm việc với phần nào của công việc. Lượng chuyển đổi không đáng kể và không chỉ là vấn đề lý thuyết, nó là có thật và tôi đã chứng kiến ​​đội ngũ giảm tới 80% năng suất do điều này.

Một PO tốt sẽ thử các tính năng nhóm và loại công việc để giúp các nhóm thực hiện chuyển đổi ngữ cảnh ít hơn, do đó cải thiện hiệu suất của họ.

Rủi ro

Đáng buồn thay, quản lý cố gắng đặt rủi ro về thời gian, tiền bạc, ngân sách và áp lực kinh doanh lên đội ngũ; và các đội chấp nhận điều này bằng cách đồng ý với điều này. Là một chuyên gia phát triển, bạn chỉ cần nêu ra sự thật và tác động của các quyết định và khiến doanh nghiệp tự chịu rủi ro.

Ví dụ

• Đồng ý đến một thời gian vô lý. Thay vì nói những nỗ lực sẽ làm để thực hiện công việc đúng cách và làm cho doanh nghiệp quản lý vấn đề thời gian

• Dự toán. Doanh nghiệp mong muốn các đội ước tính chính xác trong một thế giới phức tạp và không chắc chắn. Các đội nên hỏi doanh nghiệp những gì họ đang làm để giảm thiểu nếu ước tính bị vượt quá do những thách thức không lường trước, rất có khả năng. Các đội không nên yếu tố béo, mà thay vào đó nên kinh doanh.

• Nợ kỹ thuật. Các nhóm nên ước tính về việc thực hiện mã chất lượng cao đã được kiểm tra đầy đủ và ước tính về điều đó, tức là Dừng viết lỗi do áp lực. Nếu doanh nghiệp muốn chất lượng thấp hơn, thì đó là rủi ro của họ và khi mọi thứ đi sai thì đó là vấn đề của họ.

Chuyên nghiệp

Hãy là một chuyên gia bằng cách nói rằng xây dựng những điều đúng với chất lượng đã thỏa thuận. Ước tính khả năng tốt nhất của bạn dựa trên sự thật trong tầm tay. Khi những sự thật này thay đổi, truyền đạt nó và điều chỉnh ước tính. Là một nhóm phát triển, xây dựng các sản phẩm tuyệt vời và không chấp nhận rủi ro kinh doanh. Giao tiếp và quản lý kỳ vọng.

Kiểm tra và thích ứng

Các đội nên luôn tìm cách cải thiện và nếu họ cảm thấy điều đó sẽ làm mọi thứ tốt hơn, họ nên thử nó. Sau đó kiểm tra xem có cải tiến không. Cuối cùng, họ nên thích nghi và cải thiện phương pháp mới hoặc loại bỏ nó nếu không hoạt động. Ý định đằng sau tìm cách cải thiện nên luôn luôn có.

Dòng dưới cùng

Cuối cùng, việc quản lý tồn đọng là sự lựa chọn của PO. Làm thế nào anh ấy / cô ấy muốn quản lý hàng đợi công việc là tùy thuộc vào họ. Suy nghĩ duy nhất là họ PHẢI giữ cho hệ thống công việc cho TẤT CẢ các đội khỏe mạnh và ở trạng thái tốt. Do đó, tùy thuộc vào PO để quyết định.

Hợp đồng

Trong các phiên lập kế hoạch nước rút, nhóm nên mong đợi một danh sách các mặt hàng tồn đọng của sản phẩm được chải chuốt rõ ràng, không mơ hồ và được đặt hàng. Với một cuộc thảo luận ngắn với PO, nhóm nên biết chính xác PO muốn gì; các GÌ . Sau đó, nhóm tập trung vào cách họ sẽ xây dựng.

Nếu PO đến cuộc họp lập kế hoạch được chuẩn bị tốt, ai sẽ quan tâm cách quản lý tồn đọng. Nếu PO không được chuẩn bị cho cuộc họp lập kế hoạch nước rút, điều này cần được SM giải quyết và thể hiện rất rõ vì điều này hoàn toàn không thể chấp nhận được và không phải là vấn đề của nhóm.

Chúng tôi vừa mới tiếp thu tồn đọng của một nhóm khác. Nhóm tôi chỉ có một thành viên (tôi không biết nhiều về một đội), nhưng có công việc thực tế trên hồ sơ tồn đọng của họ. Chúng tôi không quen thuộc lắm với công việc của họ và họ không quen thuộc lắm với chúng tôi.

Mặc dù các hồ sơ tồn đọng của bạn được hợp nhất, điều đó không có nghĩa là mọi người phải làm việc trên mọi thứ ngay lập tức. Thật không hợp lý khi mong đợi điều đó, vì vậy đừng quá lo lắng về việc mọi người có thể làm mọi thứ trong cả hai hồ sơ tồn đọng ngay lập tức.

Thay vào đó, hãy bắt đầu để cả hai đội làm việc với chính xác những gì họ đang làm việc trước đó; sự khác biệt duy nhất là mọi thứ đều nằm trong cùng một hồ sơ tồn đọng.

Sau đó, mỗi lần lặp / chạy nước rút có một số thành viên từ mỗi nhóm làm việc trên các câu chuyện từ các hồ sơ tồn đọng khác. Bằng cách không có tất cả mọi người làm việc trên các mặt hàng lạ cùng một lúc, bạn phân bổ chi phí cho việc học các hệ thống của nhau . Theo thời gian, nhóm của bạn sẽ dần dần tiếp thu kiến ​​thức của nhau.

Nếu bạn làm tất cả các bài học trước, sẽ có hình phạt hiệu suất đáng kể. Ai đó trong ban quản lý cấp cao chắc chắn sẽ chú ý, và bạn sẽ buộc phải tiếp thu hồ sơ tồn đọng của một nhóm khác với hy vọng rằng đội mới có thể bù đắp cho hiệu suất kém ... :) Tuy nhiên, đây sẽ là đề xuất của tôi.

Tôi giả sử rằng lý do bạn (hoặc quản lý) muốn tạo một hồ sơ tồn đọng hợp nhất cho hai nhóm là bạn muốn chỉ có thể chọn các mục tồn đọng cho một trong các hệ thống và có cả hai nhóm làm việc trên chúng.

Khi đây là trường hợp, mong đợi rất nhiều ma sát từ nhóm buộc phải làm việc trên hệ thống mà họ không quen thuộc. Hy vọng rằng nhóm sẽ lấy mọi ống hút (tức là vật phẩm tồn đọng nhỏ liên quan đến hệ thống "nhà" của họ) để tiếp tục làm việc trên hệ thống mà họ đang làm việc trước đó. Ai là người đổ lỗi cho họ? Không có gì thú vị khi làm việc trên một cái gì đó mà bạn không giỏi. Và thực tế là nhóm khác tốt vì điều gì đó bạn không giỏi làm cho nó tồi tệ hơn - bởi vì nó khiến bạn trông thậm chí còn ngớ ngẩn hơn.

Vì vậy, cách duy nhất để làm nên thành công này là chia hai đội và chia thành hai đội. Chỉ sau đó, có khả năng bạn sẽ giúp tất cả các nhà phát triển tăng tốc nhanh chóng trên hệ thống "quan trọng" hiện tại.

Điều đó không tốt lắm để làm theo cách đó. Công ty trước đây của tôi, đã chuyển sang chế độ một nhóm sản phẩm duy nhất bởi vì trong công ty lớn, chúng tôi có những người khác nhau làm việc trên các công cụ khác nhau.

Chuyển đổi giữa các dự án cũng tốn chi phí nỗ lực và nếu có người mới bắt đầu phát triển chi phí thực sự lớn. Người ta phải có quyền truy cập vào hệ thống phát triển, kho lưu trữ khác nhau, v.v.

Tôi thích chuyên môn hóa, mọi người biết họ đang làm gì, có tất cả thông tin cần thiết, biết những cạm bẫy của dự án và mọi người không có cảm giác rằng bạn phải bỏ chúng từ dự án này sang dự án để khiến họ làm việc, để hút từng đồng xu ra họ

Ngay cả khi họ đang rảnh rỗi trong dự án của họ, họ sẽ làm việc hiệu quả hơn nhiều so với những gì họ quen thuộc, hơn là nhảy từ dự án này sang dự án khác.