Ai chịu trách nhiệm triển khai?

Question

Tôi làm việc như một nhà phát triển nội bộ cho một công ty sản xuất. Chúng tôi làm cho phần mềm cho quá trình sản xuất, không thực sự kiểm soát phần mềm, giống như quy trình xử lý.

Chúng tôi đang sử dụng quy trình Scrum để phát triển phần mềm, mặc dù được điều chỉnh để phù hợp với nhóm và môi trường của chúng tôi và điều này đang hoạt động khá tốt. Chúng ta sắp kết thúc chạy nước rút và phần mềm đang ở giai đoạn mà chủ sở hữu sản phẩm muốn triển khai nó.

Trước đây, tức là trước Scrum, chúng tôi đã triển khai phần mềm. Bây giờ tôi cảm thấy như chúng tôi đã phát triển phần mềm, chúng tôi đã vượt qua tất cả các bài kiểm tra phát hành do người dùng xác định/đồng ý và trình bày phần mềm cho PO bằng trình mô phỏng, chúng tôi đã đạt được mục tiêu. Chúng tôi sẵn sàng cung cấp hỗ trợ triển khai nhưng tôi không nghĩ rằng đó là trách nhiệm của chúng tôi để triển khai.

Trải nghiệm của người khác là gì? Nếu nhóm dev thực hiện triển khai hay chúng ta nên bàn giao phần mềm đã hoàn thành cho PO và cung cấp hỗ trợ?

Tổng hợp

Rất nhiều phản ứng tuyệt vời, cảm ơn. Câu hỏi có vẻ như tôi đang cố gắng vất vả ra khỏi công việc hoặc trách nhiệm, có lẽ tôi là một chút; o) Điều tôi quan tâm nhiều hơn là các quá trình của người khác. Vấn đề chúng ta phải đối mặt ở đây là nếu nhóm dev triển khai phần mềm thì chúng tôi sẽ cung cấp hỗ trợ 24/7 cho sản xuất cho phần mềm. Không có prob, ngoại trừ chỉ có hai chúng tôi. Vì vậy, để cho phép chúng tôi quay lại phát triển phần mềm thay vì cung cấp hỗ trợ mọi lúc, tôi nghĩ có thể hữu ích khi nhóm "CNTT" tham gia vào quá trình phát triển. Hy vọng rằng điều này sẽ nhận được 'mua vào' và sau đó cho phép họ triển khai và cung cấp hỗ trợ mức đầu tiên. Chúng tôi cũng có một nhà máy ở Mexico và khó khăn cho nhóm dev để đi và triển khai ở đó, nó có ý nghĩa hơn cho sự hỗ trợ của địa phương để làm điều đó, với sự hướng dẫn/lời khuyên từ các nhà phát triển.

Để cho bạn biết, các kỹ sư CNTT đã triển khai phần mềm, với hướng dẫn/lời khuyên từ dev. Nó biến mất khá tốt, khách hàng rất hạnh phúc - anh ta đã tăng giá trị cho phần mềm của mình, và đó không phải là tất cả những gì về nó?

Answer 1

Tôi nghĩ là nhà phát triển "nội bộ" sẽ là trách nhiệm của bạn (trừ khi có nhóm triển khai chuyên biệt) triển khai phần mềm mới trong khi nếu bạn đến từ một công ty bên ngoài thì nó sẽ giúp họ triển khai bản thân nó, trừ khi được quy định trong hợp đồng.

Answer 2

Tôi không nghĩ Scrum là phương pháp luận giải quyết trách nhiệm triển khai. Tôi đã làm việc cho các tổ chức lớn với một nhóm triển khai hoàn toàn độc lập với nhóm phát triển. Tôi cũng đã làm việc tại các tổ chức nhỏ, nơi nhóm phát triển xử lý triển khai. Lý tưởng nhất, nhóm triển khai tách biệt với sự phát triển, nhưng nó hầu như không bao giờ là PO (mà tôi cho là chủ sở hữu sản phẩm). PO thường tắt, nhưng thường không phải là lựa chọn tốt nhất để xử lý việc triển khai.

Answer 3

Phụ thuộc vào dự án và "triển khai" có ý nghĩa gì đối với bạn. Vì tôi là một nhà phát triển web, triển khai hầu hết các ứng dụng .NET với cơ sở dữ liệu Sql Server, tôi luôn thích việc triển khai được thực hiện bởi người quản lý phát hành hoặc trình quản lý triển khai. Tại sao? Vì việc tách các công việc đảm bảo rằng các vấn đề sẽ bị bắt khi họ cần.

Công việc của nhà phát triển cần cung cấp các đối tượng hoặc hướng dẫn bắt buộc về cách triển khai, sau đó người khác triển khai môi trường dàn dựng. Nếu xảy ra sự cố trong quá trình triển khai dàn dựng, hướng dẫn triển khai sẽ được sửa chữa cho đến khi triển khai dàn dựng hoạt động hoàn hảo. Bằng cách đó, hy vọng sẽ không có sai sót khi cùng một kịch bản triển khai được sử dụng để chuyển mã sang sản xuất.Nói cách khác, không chỉ bạn phải kiểm tra mã của bạn mà còn là kịch bản triển khai.

tất nhiên, trong thế giới thực, điều này không phải lúc nào cũng xảy ra do vấn đề nhân sự, nhưng đây sẽ là lý tưởng của tôi.

Answer 4

Dường như khá đơn giản đối với tôi- nếu không phải bạn, thì ai? Liệu trách nhiệm triển khai thực sự đã giảm xuống một số nhóm khác trước khi bạn bắt đầu sử dụng Scrum? Nếu không, thì tôi không hiểu tại sao Scrum lại thay đổi điều đó.

Answer 5

Nếu nhóm phát triển đã cung cấp triển khai trước scrum, họ nên tiếp tục làm như vậy, trừ khi Ban quản lý nói cụ thể là ai đó nên làm điều đó. Nếu quản lý đã không nói, sau đó họ đã không thực sự nghĩ về nó, và chỉ hy vọng rằng nó sẽ xảy ra kỳ diệu, như nó luôn luôn có.

Nếu bạn không thích điều đó, hãy mang nó lên với ban quản lý, nhưng thực hiện công việc cho đến khi được nói khác đi.

Answer 6

1. quá trình phần mềm chưa hoàn thiện cho đến khi phần mềm hoạt động nằm trong tay của người sử dụng mà cần nó - nếu không nó chỉ là "shelfware"

2. nếu không có ai chịu trách nhiệm cho việc triển khai và quản lý cấu hình, sau đó là bạn ;-)

Answer 7

Tôi là một người có trách nhiệm với nhiều sản phẩm. Tôi có các nhóm dev của tôi sản xuất các bản dựng của các tạo phẩm triển khai, chẳng hạn như các tệp .war, có thể được triển khai đơn giản tới máy chủ web Tomcat bằng cách sử dụng giao diện quản lý hoặc API dịch vụ web. Cấu hình cho ứng dụng được đặt và tự chứa trong tệp .war. Do đó nó là đơn giản cho người thực hiện triển khai để chỉ mất nó và "thả nó vào", do đó, để nói chuyện.

Nếu chúng tôi không đạt được mức độ triển khai dễ dàng đến nơi triển khai có thể được tách hoàn toàn khỏi nhóm phát triển, thì tôi coi đó là thất bại trong phần của nhóm dev để thực hiện công việc của họ.

Người triển khai tiến hành phát hành một sản phẩm nhất định cho nhiều trang web khách hàng - đó không phải là hoạt động hữu ích để tôi cho phép nhà phát triển làm - họ có các sản phẩm để thiết kế và tạo ra như chuyên môn chuyên môn của họ.

Trong tổ chức của chúng tôi trách nhiệm triển khai cũng trùng lặp với trách nhiệm hỗ trợ sản xuất cấp đầu tiên.

Chúng tôi thực hành một số phương pháp scrum nhưng tôi chưa bao giờ xem vấn đề này là gắn với phương pháp xử lý phần mềm phát triển, mỗi se.

Answer 8

Tôi nghĩ bạn phải xây dựng và triển khai phần mềm. trừ khi bạn đang làm việc trong một tổ chức có một số loại vấn đề bảo mật dữ liệu nghiêm trọng và các vấn đề SOX với việc cho phép ô uế xử lý kết thúc sản xuất của mọi thứ.

Tôi đồng ý với nhận xét đầu tiên - SCRUM không liên quan gì đến nó. Trong thực tế, tôi sẽ nghĩ rằng nó là tốt hơn cho bạn để được triển khai như bạn sẽ biết tay đầu tiên như thế nào những điều đang làm việc và được quyền có để có được thông tin phản hồi từ những người dùng.

Answer 9

Ai nhận cuộc gọi lúc 3 giờ sáng khi phần mềm không hoạt động hoặc hệ thống bị chết? Nếu đó là đội ngũ dev thì tất cả các phương tiện đều mong muốn sở hữu triển khai (kể từ khi bạn sở hữu sản xuất).

Thực tiễn tốt nhất cho các tổ chức có thể hỗ trợ là cung cấp nhóm hoạt động với hướng dẫn triển khai và mong muốn tốt. Chai scotch giúp quá.

Nếu kiểm soát sản xuất của bạn là lỏng lẻo, hơn thắt chặt chúng. Một cuốn sách như "Opible Visible" là một hướng dẫn tuyệt vời để có được những thứ dưới mức kiểm soát thích hợp trong tay thích hợp.