Làm thế nào để xử lý các phụ thuộc 'bên ngoài' trong scrum?

Nếu bạn đã lên kế hoạch một số câu chuyện của người dùng cho một lần chạy nước rút và một câu chuyện ứng cử viên phụ thuộc vào một số nhà cung cấp bên ngoài cung cấp một cái gì đó cho nhóm của bạn. Ví dụ: nhà cung cấp dịch vụ trực tuyến thêm lệnh gọi API mới vào hệ thống của họ hoặc cho phép tài khoản thử nghiệm của bạn trên hệ thống của họ hoặc tương tự.

Bạn biết rằng nó sẽ đến 'sớm thôi'.

Bạn có tiếp tục và thêm câu chuyện vào giai đoạn nước rút với hy vọng họ sẽ cung cấp những gì cần thiết để bạn hoàn thành câu chuyện của mình hay bạn đợi đến lần chạy nước rút tiếp theo, khi bạn biết nó sẽ sẵn sàng và bạn có thể bắt đầu ngay lập tức ngay cả khi nó có nghĩa là không bắt đầu câu chuyện sớm nhất có thể.

Nếu trước đây làm thế nào để bạn xử lý các điểm câu chuyện 'không học được' bị mất vì sự phụ thuộc? tín dụng một phần (eek!) hoặc lấy nó ở cằm.

Cuối cùng, điều đó phụ thuộc vào việc bạn có tự tin 100% rằng nhà cung cấp bên ngoài sẽ cung cấp thứ gì đó bạn có thể sử dụng vào thời gian bạn cần sử dụng hay không.

Nếu bạn không thể chắc chắn rằng họ sẽ giao hàng kịp thời thì đừng thêm câu chuyện vào giai đoạn nước rút. Tuy nhiên, chỉ vì họ đã luôn giao hàng trong quá khứ nên không có gì đảm bảo họ sẽ giao hàng lần này.

Bạn nên cho khách hàng biết rằng sự phụ thuộc này tồn tại và bạn sẽ phải chờ API (hoặc bất cứ thứ gì) có sẵn trước khi bạn có thể lên lịch làm việc.

Về mặt tích cực, có thể có những khía cạnh của câu chuyện bạn có thể phân phối - tức là chia nhỏ nó ra cho đến khi bạn tách biệt các phụ thuộc càng nhiều càng tốt. Điều này có thể cho phép bạn thực hiện một số câu chuyện trước khi nhà cung cấp giao công việc của họ.

Một điều bạn có thể làm là tạo giao diện giữa mã của bạn và API của bên thứ ba. Bạn mã hóa giao diện của mình để phần còn lại của dự án có thể tiến hành và cho đến khi bạn có API thực sự, hãy sử dụng giả để trả về dữ liệu mẫu. Sau đó, khi API thực sự xuất hiện, bạn chỉ cần thay đổi mã phía sau giao diện sẽ không ảnh hưởng đến phần còn lại của ứng dụng. Chỉ làm điều này nếu bạn có thể đồng ý với nhà cung cấp API rằng giao diện của họ sẽ không thay đổi (ít nhất là không quyết liệt).

Nhóm là người thực hiện cam kết. Trong nhóm của chúng tôi, nếu chúng tôi cảm thấy chúng tôi đang chờ đợi (ví dụ) một nhà phát triển bên ngoài, chúng tôi đã học được cách nói rằng chúng tôi không sẵn sàng tiếp thu câu chuyện. Câu chuyện không ở trong một trạng thái phù hợp để chọn.

Có một cơ hội rất tốt rằng việc phân phối trễ, bất ngờ hoặc khác nhau từ tài nguyên bên ngoài sẽ có nghĩa là ước tính và ưu tiên của bạn có thể thay đổi.

Cho đến khi bạn có tất cả thông tin, nhóm không nên ngây thơ đến mức nghĩ rằng họ có thể hoàn thành câu chuyện. Nếu họ nói họ có thể, thì nó sẽ đến muộn, trong một định dạng dự kiến ​​hoặc hoàn toàn không, họ đã làm mọi người thất vọng.

Nghe có vẻ khắc nghiệt nhưng tôi muốn có được quan điểm của mình.

Trong Scrum có một định nghĩa được thực hiện và có một định nghĩa về sự sẵn sàng cho các câu chuyện của người dùng. Trong một tình huống như của bạn, điều quan trọng là phải có định nghĩa về sự sẵn sàng mà tất cả các bên liên quan đều hiểu và đồng ý. Ví dụ có vẻ rất hợp lý để có một dòng trong định nghĩa của bạn về sự sẵn sàng như:

• Tất cả các API bên ngoài cần thiết cho câu chuyện phải được phân phối và thử nghiệm.

Nếu bạn cần API này để thêm giá trị cho sản phẩm của mình, điều hợp lý là phải chờ cho đến khi chúng tôi thực sự có API này để bắt đầu công việc. Trong khi đó, chúng ta có thể làm một nước Mỹ khác làm tăng giá trị cho sản phẩm, tôi thực sự không thích nước Mỹ này với các triển khai giả và tương tự, nếu không có giá trị thực sự cho chi phí thì không có Mỹ, lãng phí thời gian và tài nguyên của nó .

Nếu bạn đang chờ đợi điều gì đó mà bạn chưa biết thì bạn không thể lập kế hoạch ngay cả khi bạn chắc chắn 100% rằng nó sẽ được giao vào ngày mai. Tại sao? Bởi vì nếu bạn không biết điều đó, bạn thậm chí không thể ước tính độ phức tạp của nó và nếu bạn không thể ước tính được thì bạn không thể lập kế hoạch cho nó.

Nếu bạn đã xác định một số giao diện "giao diện" / "hợp đồng" phải được theo sau bởi công ty bên ngoài, bạn có thể lập kế hoạch và tạo ra dịch vụ giả về phía bạn. Sự phát triển của bạn sẽ sử dụng dịch vụ giả định để chúng không bị phụ thuộc vào việc giao hàng bên ngoài. Việc phát triển vẫn với mock nên được lên kế hoạch cho chạy nước rút trong đó dịch vụ thực sẽ được cung cấp vì tính năng được phát triển và thử nghiệm chống lại giả không hoàn thành - nó phải được thử nghiệm với dịch vụ thực sự để được coi là hoàn thành vào cuối giai đoạn nước rút.

Truyền thông và thỏa thuận

Hai hệ thống được tích hợp bởi các lập trình viên, không phải bởi chính phương pháp. Nếu một công ty đã quyết định tích hợp một hệ thống bên ngoài, sẽ có một hợp đồng giữa (tối thiểu) 2 thực thể. Hợp đồng phải đảm bảo rằng hội nhập diễn ra . Do đó, nếu thỏa thuận giữa các công ty, không yêu cầu sự hợp tác kỹ thuật giữa cả hai bộ phận, vấn đề không phải là phương pháp phát triển. Vấn đề là phương pháp kinh doanh (về cơ bản là hợp đồng) .

Đã nói rằng, nó phải được coi là rủi ro trong quá trình lập kế hoạch cho những trường hợp đó và xem xét rằng bạn không biết tốc độ của đội, bạn sẽ cần phải hào phóng với những lợi nhuận đó.

Làm thế nào một người quản lý dự án có thể quản lý một sự phụ thuộc vào một nhóm bên ngoài?

/pm/1400/how-can-a-project-manager-manage-a-dependency-on-an-external-team

Nếu nó không phụ thuộc vào nhóm của bạn và bạn có thể thực hiện các nhiệm vụ khác, tôi khuyên bạn chỉ nên thực hiện khi nó sẵn sàng. Ngay cả khi bạn có một dịch vụ web, lược đồ, giao diện và / hoặc hợp đồng mockup, nó vẫn có thể bị hỏng (hãy nhớ Luật Murphy?).