Các nhà quản lý dự án có hữu ích trong Scrum không?

Có ba vai trò được xác định trong Scrum: Nhóm, Chủ sở hữu sản phẩm và Scrum Master. Không có người quản lý dự án, thay vào đó công việc quản lý dự án được trải đều qua ba vai trò .

Ví dụ:

• Scrum Master: Chịu trách nhiệm về quy trình. Loại bỏ các trở ngại.
• Chủ sở hữu sản phẩm: Quản lý và ưu tiên danh sách công việc cần thực hiện để tối đa hóa ROI. Đại diện cho tất cả các bên quan tâm (khách hàng, các bên liên quan).
• Nhóm: Tự quản lý công việc của mình bằng cách ước tính và phân phối nó cho nhau. Chịu trách nhiệm đáp ứng các cam kết của chính họ.

Vì vậy, trong Scrum, không còn một người nào chịu trách nhiệm cho thành công của dự án. Không có cấu trúc chỉ huy và kiểm soát tại chỗ. Điều đó dường như gây trở ngại cho rất nhiều người, đặc biệt là những người không quen với các phương pháp nhanh, và tất nhiên, PM.

Tôi thực sự quan tâm đến điều này và những trải nghiệm của bạn là gì, vì tôi nghĩ đây là một trong những điều có thể tạo ra hoặc phá vỡ việc triển khai Scrum.

Bạn có đồng ý với Scrum rằng không cần người quản lý dự án không? Bạn có nghĩ rằng một vai trò như vậy vẫn còn cần thiết? Tại sao?

Có lẽ bạn nên trình bày những thứ như thế này:

Người quản lý dự án đã không biến mất trong Scrum . Anh ấy vẫn ở đó. Bây giờ có ba người trong số họ!

• Scrum Master : anh ta quản lý quá trình và giải quyết các trở ngại. Đó là trách nhiệm của người quản lý dự án trước đây.

• Chủ sản phẩm : ông quản lý tồn đọng. Đó là trách nhiệm của người quản lý dự án trước đây khi anh dự đoán mọi thứ trong Microsoft Project.

• Nhóm : tự quản lý sản xuất của mình. Ai và làm thế nào một câu chuyện người dùng nhất định được chuyển đổi thành gia tăng sản phẩm có thể tin cậy được. Đó là trách nhiệm của người quản lý dự án khi anh ta giao nhiệm vụ.

Đối với tôi điều này xuất phát từ sự thiếu hiểu biết về những gì Người quản lý dự án làm và bản chất khá chung chung của chức danh PM. Tôi không phải là chuyên gia về SCRUM nhưng tôi luôn thấy SCRUM Master thay thế người quản lý phát triển / trưởng nhóm thay vì Giám đốc dự án.

Người quản lý dự án (như được định nghĩa bởi các phương pháp như PRINCE2 - tương thích khá nhiều với phương pháp Agile) thực sự không liên quan gì đến quá trình phát triển, họ đang chăm sóc dự án từ góc độ phân phối rộng hơn không chỉ là CNTT xây dựng. Có rất nhiều điều nằm trong vai trò của Trình quản lý dự án không được đề cập ở nơi khác trong Scrum (quản lý và giám sát trường hợp kinh doanh, quản lý các bên liên quan kinh doanh, các yếu tố của dự án bên ngoài bản dựng CNTT như làm lại quy trình kinh doanh, hỗ trợ, đào tạo và như vậy).

Nếu PM của bạn là người chăm sóc các nhà phát triển và không làm gì nhiều hơn thế (ví dụ, đối với các dự án chủ yếu là CNTT chỉ có phạm vi được xác định rõ) thì có lẽ anh ta sẽ không cần thiết trên một dự án SCRUM.

Nhưng trước khi ai đó nói rằng bạn không cần PM cho SCRUM, tôi muốn có một lời giải thích khá rõ ràng về cách các yếu tố phi CNTT của dự án được bảo hiểm và đặc biệt là ai đang quản lý trường hợp kinh doanh (vì người dùng muốn nó và nó là một cái gì đó nên được thực hiện là những thứ khác nhau).

Có thể là Thủ tướng cuối cùng ngồi nhiều hơn vào khía cạnh kinh doanh của dự án - Chủ sở hữu sản phẩm có thể đảm nhận vai trò của Thủ tướng nhiều hơn so với Scrum Master nhưng tôi nghĩ không chắc rằng mình sẽ biến mất hoàn toàn.

Có một vài điều mà Người quản lý dự án có thể làm mà Scrum Master hoặc Chủ sở hữu sản phẩm có thể không thực hiện được.

• Người quản lý dự án thường có nhiều kinh nghiệm trong việc điều hành các dự án (bất ngờ!).
• Họ nhận thức được những cạm bẫy phổ biến, và có thể phát hiện ra chúng và giúp giải quyết chúng trước khi chúng xảy ra.
• Họ thường là những nhà đàm phán có kinh nghiệm và có thể hỗ trợ các thành viên khác trong các cuộc thảo luận về thời hạn, phạm vi và các yêu cầu mâu thuẫn (rất quan trọng nếu PO khá mới trong vai trò này).
• Họ có thể quản lý tiền. Họ có quyền thuê và sa thải, và có thể giúp đỡ nếu ai đó trong nhóm không có khả năng thực hiện vai trò của họ (thông qua việc sắp xếp đào tạo, tư vấn, v.v.).
• Họ có thể giúp đảm bảo rằng dự án phù hợp hiệu quả với một chương trình làm việc lớn hơn.
• Họ có thể lấy đồ ra khỏi đội.
• Họ có thể giúp hướng dẫn các chính sách của công ty có hiệu quả cùng với Scrum (ví dụ: nếu người kiểm tra vẫn đang được đo lường bằng số lượng lỗi được tìm thấy).
• Họ có thể quản lý quản trị.
• Họ có thể di chuyển đồ đạc.
• Vốn từ vựng của họ là của doanh nghiệp lớn hơn và họ có thể thảo luận về dự án - và phương pháp Scrum - về rủi ro, tác động, ROI, các tùy chọn và sự khác biệt.
• Họ có thể giải thích với hội đồng quản trị tại sao sự minh bạch đột ngột và tin tức không thường xuyên về sự thất bại, thông qua một biển báo cáo xanh, là điều tốt và hữu ích để biết.
• Một PM tốt có thể giúp bạn cảm thấy an toàn, âm thanh tuyệt vời và trông tuyệt vời.

Scrum không bắt buộc phải có PM. Nhưng dù sao bạn cũng muốn có một cái.

Trong một trong những dự án tôi đã làm, khi nó biến thành Scrum, người quản lý dự án trước đó của chúng tôi thay thế giữ vai trò Chủ sở hữu sản phẩm và Scrum Master. Nó đã làm việc trong 6 tháng tôi dành cho đội đó, mặc dù nó không lý tưởng (đối với tôi). Anh ta là kiểu người muốn kiểm soát mọi thứ trong tầm kiểm soát chặt chẽ, nhưng đã làm điều đó khá tốt (tức là để nhóm thực hiện công việc của mình và đưa ra quyết định khi thích hợp).

Bối cảnh của việc này là công ty đang ở trong tình trạng tài chính khủng khiếp, mặc dù chúng tôi (nhóm) chỉ biết về nó một thời gian sau đó. Vì vậy, có một lý do để giữ mọi thứ trong tầm kiểm soát chặt chẽ, để đảm bảo rằng chỉ có những thứ hoàn toàn cần thiết được chế tạo và phiên bản đầu tiên của sản phẩm được giao đúng hạn.

Tôi sẽ công bằng và nói rằng theo quan điểm của tôi, điều làm việc cho tôi là bậc thầy Scrum đóng vai trò là người quản lý dự án. Trở thành một bậc thầy Scrum không phải là một công việc toàn thời gian - một khi nhóm trưởng thành, chủ scrum thậm chí không cần phải tham dự các cuộc họp hàng ngày.
Ngày càng có nhiều vị trí tuyển dụng mà tôi thấy cho Trình quản lý dự án / Scrum Master nơi các công ty không muốn phân biệt các vai trò này - thay vào đó có cùng một người đảm nhiệm cả hai vai trò - tức là: người quản lý dự án Agile.

Quản lý dự án: một vai trò trong một tổ chức hoặc doanh nghiệp truyền thống.

Scrum master: một vai trò trong nhóm phát triển phần mềm sử dụng phương pháp Scrum.

Nói về quản lý dự án so với scrum master thực sự là nói về táo và cam vì các vai trò có bối cảnh khác nhau. Tôi chưa bao giờ nghe nói về một tổ chức có "Scrum master" là một danh hiệu chính thức hoặc mức lương. Và các nhà quản lý dự án trên bất kỳ dự án nào, Scrum hay nói cách khác, thường bị loại bỏ phần nào khỏi các hoạt động phát triển phần mềm hàng ngày.

Chính xác những gì người quản lý dự án làm và vai trò của anh ta / cô ta bao nhiêu với vai trò của chủ Scrum hoặc chủ dự án phụ thuộc rất nhiều vào quy mô và tính chất của dự án, nhưng chắc chắn có những nhiệm vụ thường được quy cho người quản lý dự án không cụ thể một phần của vai trò chủ Scrum hoặc chủ dự án. Trong một dự án nhỏ, có thể mở rộng các nhiệm vụ của vai trò chủ Scrum hoặc chủ sở hữu dự án để bao gồm các nhiệm vụ đó (tuyển dụng, sa thải, mua, quản lý hợp đồng, giao tiếp với các giám đốc điều hành cấp cao hơn, v.v.). Trong một dự án lớn hơn, phát triển phần mềm chỉ là một phần của quản lý dự án và nhiệm vụ của người quản lý dự án và những người quản lý Scrum không có khả năng chồng chéo nhiều.

Người quản lý dự án phải là giao diện của Scrum master cho tổ chức. Scrum master nên là giao diện của người quản lý dự án cho nhóm.

Vì vậy, các nhà quản lý dự án có hữu ích trong Scrum không? Không, người quản lý dự án rất hữu ích ngoài Scrum. Chúng không phải là một phần của phương pháp phát triển phần mềm Scrum, nhưng chúng cung cấp các tài nguyên cho phép Scrum hoạt động.

Câu hỏi này có mùi của Scrumbut .

Scrum là tập hợp con của những gì có trong phương thức quản lý dự án (Prince2 / PMP, v.v.). Trên thực tế, nếu bạn nhìn vào Prince2 process MP (quản lý phân phối sản phẩm), tất cả các yếu tố của Scrum có thể được chứa ở đó.

Scrum Master không muốn bị sa lầy trong các cuộc họp với các nhà cung cấp, nhân sự, pháp lý, tài chính, nhà cung cấp, giám đốc điều hành hoặc hoạt động BAU . Họ cần tập trung vào việc loại bỏ các trở ngại từ nhóm trong giai đoạn nước rút hiện tại, không đàm phán bao nhiêu cơ quan việc làm có thể giảm giá thầu trong năm 2011 hoặc xác nhận thỏa thuận ký quỹ với nhà cung cấp x.

Nếu Scrum Master của bạn đang làm như trên, bạn không chạy Scrum, bạn đang chạy Scrumbut.

Từ kinh nghiệm, sự kết hợp tốt nhất là có Scrum Master cho mỗi nhóm trưởng và người quản lý dự án để điều phối các bậc thầy scrum theo kiểu Scrum of Scrums. Có một người quản lý dự án trong vai trò này hiệu quả hơn do những lý do nêu trên và kinh nghiệm sâu sắc của họ. Đổi lại, các nhà quản lý dự án này báo cáo thành Danh mục đầu tư / Trình quản lý chương trình, v.v. và tất cả trong chuỗi lệnh đều được chứng nhận ít nhất là Scrum Masters.

Hãy nhớ rằng Scrum là một công cụ để quản lý phân phối sản phẩm, ở một lớp trừu tượng, nó có thể được sử dụng để chạy các dự án, nhưng đã có các quy trình tốt hơn nhiều cho việc đó.

Một trong những vấn đề chính với vai trò quản lý dự án truyền thống là nó tách quyền hạn khỏi trách nhiệm. Thủ tướng có toàn quyền đối với tổ chức dự án - ông quyết định những nhiệm vụ nào cần phải thực hiện, bởi ai, theo thứ tự nào, v.v. Nhưng ông không chịu trách nhiệm về việc hoàn thành các nhiệm vụ này hoặc chất lượng phần mềm được sản xuất. Các thành viên trong nhóm là những người duy nhất chịu trách nhiệm. Điều này tạo ra một chi phí truyền thông khổng lồ, để đặt lại thẩm quyền và quyết định đồng bộ với công việc vận hành, các thành viên trong nhóm liên tục phải báo cáo mọi việc được thực hiện với Thủ tướng cùng với các thành viên còn lại trong nhóm. Nó cũng tạo ra một cảm giác thất vọng, bất lực và mất mục đích với các thành viên trong nhóm, đó là một nguồn lớn của sự thất vọng và chán nản.

Agile bằng cách nào đó đặt các khái niệm này lại với nhau - toàn quyền tổ chức công việc được tổ chức bởi toàn bộ nhóm (thông qua phát hành, lặp lại và các cuộc họp hàng ngày) để mọi người cảm thấy như họ có thể nói lên vấn đề, đổi lại các thành viên trong nhóm phải chịu trách nhiệm sản xuất phần mềm chất lượng hoạt động và cam kết mạnh mẽ với mục tiêu đó. Do đó về mặt lý thuyết bạn có thể thoát khỏi người quản lý dự án.

Khi bạn đã nói như vậy, vẫn có những nhiệm vụ được giao cho Thủ tướng mà vẫn cần phải quan tâm - lunivore đã mô tả chúng khá chính xác.

Như bài viết này cho thấy, trong các nhóm thực sự đa kỹ năng, một điều bạn có thể làm là loại bỏ vai trò quản lý dự án, phân phối lại nhiệm vụ của mình giữa các thành viên trong nhóm và để các cựu Thủ tướng trở thành thành viên nhóm thường xuyên.

Các vai trò Scrum được xác định khá rõ (nếu chúng có vẻ mơ hồ bởi vì chúng có nghĩa là được áp dụng trong các loại tổ chức khác nhau) và vì các nhóm Scrum luôn (có, thường) có cùng kích thước - tức là không lớn lắm - tương đối dễ dàng để đồng ý về những gì họ bao gồm, ngay cả khi điều đó thay đổi tùy thuộc vào tổ chức cơ bản.

Đọc câu hỏi, câu trả lời và nhận xét ở trên, có vẻ như rõ ràng rằng định nghĩa về vai trò của người quản lý dự án khó khăn hơn nhiều để hiểu rõ hơn. Tôi chắc chắn rằng bạn có thể tìm thấy một định nghĩa chung hay và bổ ích về vai trò của một Thủ tướng, nhưng điều đó thực sự có ý nghĩa gì trong cuộc sống thực là một câu chuyện hoàn toàn khác.

Dù sao, vì nó làm việc trong công việc của tôi, các nhà quản lý dự án rất ít khi tham gia vào "Scrumming" thực tế. Họ không được phép làm chủ Scrum (một quy tắc lợi ích xung đột cục bộ mà tất cả chúng ta đều rất hài lòng) và họ chỉ là chủ sở hữu sản phẩm trong các trường hợp đặc biệt.

Vì vậy, nơi tôi làm việc, những người quản lý dự án vẫn ở đó, làm khá nhiều việc họ luôn làm. Có nghĩa là họ giữ dự án đi đúng hướng, hoạt động như một bộ lọc chống lại quá nhiều hoang tưởng và xu hướng quản lý vi mô từ "bên trên", giải quyết các vấn đề cần nhiều đầu mối hơn chúng ta có thể giải quyết, v.v.

Tôi chắc chắn rằng điều này khá khác biệt ở những nơi khác, nhưng đối với chúng tôi nó hoạt động rất tốt.

Chỉnh sửa : Có lẽ tôi nên làm rõ rằng đối với chúng tôi, nhóm Scrum không thay thế nhóm dự án. Một hoặc nhiều nhóm Scrum được bắt đầu để thực hiện công việc phát triển thực tế cho (và thường là trong) một dự án. Nhóm Scrum có thể (và có thể luôn luôn làm) bao gồm các thành viên nhóm cũ, ngoại trừ người lãnh đạo dự án :-)