Dự án đóng cửa trong Scrum

Trong một môi trường phát triển phần mềm điển hình, việc đóng cửa dự án đánh dấu sự kết thúc của một dự án.

1. Hồ sơ dự án được hoàn thành và lưu trữ,
2. tài nguyên được phát hành,
3. các vấn đề và bài học được ghi lại, và
4. một bữa tối / bữa tiệc trang trọng được tổ chức cho lễ kỷ niệm.

Bước cuối cùng là tùy chọn, mặc dù rất có động lực cho người tham gia. :-)

Tương phản điều này với Scrum. Tôi biết rằng scrum chạy trên những câu chuyện từ các hồ sơ tồn đọng . Vì vậy, về mặt kỹ thuật, mỗi lần lặp lại đều đóng những câu chuyện nhất định. Vì vậy, có hai câu hỏi ở đây.

1. Đối với một nhóm hoạt động trên nhiều dự án đồng thời , làm thế nào để đóng cửa dự án phù hợp?
2. Đối với một dự án liên quan đến nhiều nhóm , khái niệm này được áp dụng như thế nào?

Hoặc, có phải thời hạn đóng cửa dự án không áp dụng cho các dự án T & M không?

Đối với một nhóm hoạt động trên nhiều dự án đồng thời, làm thế nào để đóng cửa dự án phù hợp?

Đầu tiên, "nhiều dự án đồng thời" được coi là một ý tưởng thực sự tồi tệ. Điểm của scrum là chạy nước rút và được thực hiện. Chuyển đổi dự án để bắt đầu một cuộc chạy nước rút khác là đột phá. Làm hai dự án cùng một lúc không phải là một cuộc chạy nước rút. Đó là một mớ hỗn độn.

Tuy nhiên, Scrum không khác với phương pháp không nhanh nhẹn (thác nước). Khi tồn đọng giảm xuống gần bằng 0, bạn vẫn hoàn thành. Cũng giống như bạn đã có một cách tiếp cận thác nước thay vì một cách tiếp cận nhanh nhẹn.

Đôi khi tồn đọng là khác không, nhưng khách hàng rất vui mừng và không muốn thêm nữa. Vậy là bạn đã hoàn thành. Thường được thực hiện sớm hơn và rẻ hơn một thác nước (phải xây dựng mọi thứ, ngay cả những ý tưởng hóa ra là vô dụng.)

Đối với một dự án liên quan đến nhiều nhóm, khái niệm này được áp dụng như thế nào?

Tương tự như một dự án không scrum với nhiều nhóm. Không có gì thay đổi về con người. Họ vẫn thích một bữa tiệc tốt.

Hoặc, có phải thời hạn đóng cửa dự án không áp dụng cho các dự án T & M không?

Tại sao hóa đơn sẽ thay đổi bất cứ điều gì về bản chất của công việc hoặc buổi lễ vào cuối?

Tôi thường thấy các phương thức nhanh như thực hành scrum trong khung quản lý dự án có cấu trúc chặt chẽ hơn. Đây không phải là một mâu thuẫn ở tất cả. Agile hoạt động để giao hàng, mục tiêu của nó là cung cấp phần mềm phù hợp nhanh hơn. Nó giúp với các tương tác giữa các nhà phát triển và các bên liên quan. Nó có thể được sử dụng như một phần của chương trình thời gian cố định hoặc cho các cải tiến kết thúc mở.

Vì vậy, với suy nghĩ đó, không có lý do gì mà phần còn lại của quản lý dự án không thể được quản lý theo cách truyền thống, với một PM quản lý dòng thời gian, chi phí và các phụ thuộc khác. Khi hoàn thành, bạn có các sự kiện đóng cửa như bình thường.

Tôi làm việc trong lĩnh vực tài chính, đôi khi các quy định mới xảy ra hoặc một cuộc trao đổi mới xuất hiện và chúng tôi có một ngày trực tiếp cho những gì được đặt trong đá. Chúng tôi vẫn sử dụng phương thức Agile để phân phối nhưng trong khuôn khổ quản lý dự án truyền thống hơn để chúng tôi nhận được giao hàng đúng hạn.

Việc ước tính các đơn vị công việc và chọn một giải pháp có thể đạt được trong khung thời gian có sẵn là điều khiến chúng tôi trở thành nhà phát triển giỏi (Một trong những điều tôi nên nói).

Trong Scrum, như trong tất cả các kỹ thuật Agile, các dự án là những thứ nhỏ đến và đi, trong khi nhóm ở lại với nhau. Vì vậy, không có nghi thức "dự án-clojure" như vậy. Thay vào đó là các dự án trong khi các loại sáp khác. Dòng chảy của các mặt hàng tồn đọng dần dần chuyển từ cái này sang cái khác. Nhóm nghiên cứu hầu như không biết sự khác biệt.

Thật vậy, nhóm có thể đang làm việc trên hai hoặc ba dự án khác nhau cùng một lúc. Một lần nữa, họ hầu như không biết sự khác biệt. Các mục tồn đọng đi vào đội khi bắt đầu mỗi lần chạy nước rút và nhóm thực hiện chúng. Tất cả chúng có thể thuộc về một dự án, hoặc chúng có thể được chia đều giữa nhiều dự án. Nhóm không quan tâm. Nhóm chỉ thực hiện các mục tồn đọng mà họ được đưa ra.

Nếu doanh nghiệp cần thay đổi mức độ ưu tiên của các dự án, họ chỉ cần thay đổi luồng các mặt hàng tồn đọng vào các nhóm.

Một số điều bạn đang thảo luận ở đây sẽ bị thay thế bởi hầu hết các quy trình nhanh nhẹn, với những thứ như tài liệu và bản phát hành thường xuyên xảy ra như một vấn đề, thay vì chờ đợi một số kích hoạt bên ngoài. Tất nhiên, điều đó không phải luôn luôn như vậy, tùy thuộc vào loại khách hàng bạn có và loại hình kinh doanh của bạn. Ví dụ: nếu bạn đang tạo một phần của hệ thống lớn hơn do một thực thể bên ngoài sở hữu, thường có một số ngày thúc đẩy quá trình, và ngày đó sẽ là thời điểm thích hợp để thực hiện thêm việc dọn phòng và tất nhiên là tiệc tùng. Những lần khác, ngay cả khi khách hàng là nội bộ, doanh nghiệp vẫn có thể nhận ra việc hoàn thành một cột mốc kinh doanh / giao hàng chính / khác mà một lần nữa kêu gọi bạn kết thúc kế toán / tiệc tùng dự án. Nếu công ty của bạn tham gia vào kế hoạch phát hành, điều đó sẽ mang lại cho bạn những điểm dừng tự nhiên, nhưng ngay cả khi bạn không, việc hoàn thành các biện pháp thành công theo hướng kinh doanh là hoàn toàn phù hợp. Đó là, các dự án có thể không còn là một đặc điểm của quy trình kỹ thuật của bạn, nhưng chúng chắc chắn có thể là một phần của doanh nghiệp của bạn và kỷ niệm / giao dịch với chúng có thể và vẫn nên là một phần trong văn hóa của công ty bạn.