Có ổn không khi có những người có nhiều vai trò trong một nhóm Scrum?


9

Tôi đang đánh giá một số phương pháp theo kiểu Agile để có thể giới thiệu về nhóm của mình. Với Scrum, có được phép cùng một người thực hiện nhiều vai trò không? Chúng tôi có một nhóm nhỏ gồm bốn nhà phát triển và một nhà thiết kế web; chúng tôi thực sự không có vai trò lãnh đạo (tôi hoàn thành vai trò này), người kiểm tra QA hoặc nhà phân tích kinh doanh và tất cả các nhiệm vụ phát triển của chúng tôi đều đến từ CIO. Kiểm tra tự động được coi là một sự lãng phí toàn bộ thời gian và mọi thứ tập trung vào tốc độ và không chất lượng.

Điều gì sẽ xảy ra là CIO sẽ đưa ra một nhiệm vụ phát triển (cho dù là một tính năng hay một lỗi) và đưa nó cho một nhà phát triển (không phải cho cả nhóm, cho một cá nhân, thường ở chế độ riêng tư hoặc ngoài màu xanh), người sau đó dự kiến ​​sẽ hoàn thành nó CIO không thu thập các yêu cầu ngoài ý tưởng ban đầu (và điều này đã cắn chúng tôi trước đây vì chúng tôi sẽ triển khai một cái gì đó chỉ để biết rằng không ai trong số những người dùng cuối có thể sử dụng tính năng này, vì họ đã không hỏi ý kiến ​​hoặc thậm chí không được thông báo về nó trước khi chúng tôi phát triển nó và trong hoảng loạn, chúng tôi sẽ được yêu cầu hoàn nguyên thay đổi) nhưng yêu cầu phải nói / chấp thuận mọi thứ chúng tôi làm.

Điều đầu tiên trước tiên, là một phong cách Scrum một cái gì đó để xem xét để giới thiệu một số tiêu chuẩn và thực hành? Từ việc đọc, Scrum dường như dựa vào một chút tin tưởng và giao tiếp và tập trung nhiều hơn vào quản lý dự án hơn là phát triển, đó là điều chúng tôi hoàn toàn không có vì hiện tại chúng tôi không có bất kỳ sự hiểu biết nào về quản lý dự án.

Thứ hai, nếu nó có thể hoạt động thì có hợp lý với ai đó không, hãy nói bản thân tôi, đóng vai trò là cả ScrumMaster và nhà phát triển? Hoặc cho một nhà phát triển cũng là Chủ sở hữu sản phẩm (mặc dù rất có thể đây sẽ là CIO, người không phải là nhà phát triển)? Tôi nhận ra Scrum Master và Chủ sở hữu sản phẩm nên là những người khác nhau nhưng đồng thời tôi không nghĩ chúng ta có bất kỳ ai có phẩm chất của Chủ sở hữu sản phẩm (rất có thể nó sẽ biến thành "Tôi cần tất cả những câu chuyện này, tôi không quan tâm làm thế nào nhưng hoàn thành nó "loại thỏa thuận và / hoặc bất kỳ sự đóng băng nào sẽ bị đóng băng trong một ý thích bất chợt).

Dường như với tôi rằng tôi có thể cần phải chọn và chọn các phần của Scrum / XP / Lean để bù đắp cho cách mọi thứ được thực hiện hiện tại, vì rất khó có thể thay đổi tâm lý; ví dụ Lập trình cặp sẽ không bao giờ bay (được coi là lãng phí, bạn sẽ hoàn thành một nửa nhiệm vụ nếu bạn cần hai người cho mọi thứ), TDD sẽ là một việc khó bán, nhưng chu kỳ ngắn sẽ được hoan nghênh.


2
Bắt đầu với nhóm của bạn có một cuộc họp độc lập để thảo luận về tất cả các phiên riêng tư với CIO để ở cùng một trang. Chúc may mắn với việc giữ cho nước rút của bạn khỏi bị gián đoạn.
JeffO

Câu trả lời:


13

Scrum, Kanban hoặc bất kỳ phương pháp Agile nào khác chủ yếu là một phương pháp tập trung vào các dự án phát triển phần mềm . Nói cách khác, nó là một thực hành quản lý dự án bởi bản chất của nó.

Nhiều như bạn rất muốn bạn và nhóm của bạn thực hiện công việc dự án, bạn sẽ thấy rằng Agile sẽ chỉ đơn giản là không làm việc trong tổ chức của bạn vì thực tế là bạn thực sự không làm việc "dự án" hoặc cống hiến hết mình cho một nhóm một "cam kết dự án".

Bạn có thể tổ chức một dự án nhỏ xung quanh một tính năng phức tạp, nhưng thực tế bạn không có kết nối với các nhà phân tích kinh doanh hoặc người dùng cuối, vậy làm thế nào bạn có thể xác minh rằng bạn đang phân phối trên Câu chuyện người dùng khi bạn không có cách nào thực sự biết đó là người dùng nào muốn gì

Các bên liên quan duy nhất của bạn là ông chủ của bạn và về cơ bản anh ta đảm bảo rằng nhóm của bạn không tồn tại để phục vụ các bên liên quan khác của dự án, bạn tồn tại như một nhóm để phục vụ anh ta và nhu cầu của anh ta bất kể điều này ảnh hưởng đến các bên liên quan khác như thế nào.

Trên hết, anh ấy đang giao nhiệm vụ cá nhân cho các cá nhân và có thể sắp xếp lại mọi thứ ngay lập tức khi anh ấy quyết định rằng họ nên đi. Bạn không thể hoạt động trong phương pháp dự án Agile nếu tài nguyên dự án riêng lẻ sẽ được sắp xếp lại trong một thông báo khoảnh khắc hoặc nếu chạy nước rút sẽ bị giữ lại.

Nó không phải là để làm việc như vậy

Chạy nước rút là một cam kết của toàn bộ nhóm để cung cấp một tập hợp các câu chuyện của người dùng trước một ngày cụ thể. Sau khi bắt đầu, một lần chạy nước rút phải được hoàn thành trước khi bất kỳ sự thay đổi hoặc thay đổi nào xảy ra. Làm thế nào là một dự án được quản lý khi chạy trong một môi trường ad-hoc hỗn loạn như vậy?

Bạn không làm việc trong một môi trường thuận lợi cho các phương pháp quản lý dự án Agile. Bạn thậm chí không làm việc trong một môi trường thuận lợi cho các phương pháp Thác nước. Bạn làm việc trong một chế độ quân chủ và bạn chỉ đơn thuần là những vị vua cầm đồ khi đấu thầu và dập lửa.

Đây không phải là thành viên của một nhóm dự án phát triển phần mềm.

Vì vậy, theo một cách rất mơ hồ, tôi đang trả lời câu hỏi của bạn khi nói rằng trong tình huống của bạn, điều đó thực sự không quan trọng nếu các cá nhân đang đóng nhiều vai trò. Bạn có vấn đề lớn hơn nhiều trên tay của bạn. Bạn đang hỏi làm thế nào để có được vết nước từ thảm trên một ngôi nhà không có mái nhà.


Đáng buồn là tôi sợ phản hồi của bạn là chính xác .. về cơ bản chúng tôi cần trì hoãn bất cứ điều gì với CIO của chúng tôi, ngay cả những điều không liên quan đến anh ấy như thế nào và khi nào chúng tôi nên phân nhánh SVN của chúng tôi (chúng tôi vừa mới quay lại, lần thứ ba một hàng và CIO của chúng tôi đang đưa ra quyết định cho chúng tôi biết chúng tôi nên phân nhánh như thế nào, khi anh ấy không phải là nhà phát triển).
Wayne Molina

1
@WayneM Có thể tất cả các vị vua và tất cả những người đàn ông của các vị vua lại đặt đống bừa bãi lại với nhau khi nhà vua là một kẻ ngốc quản lý vi mô? Kinh nghiệm chung của tôi nói với tôi không. Môi trường này không có lợi cho việc viết phần mềm trong một dự án. Nếu bạn thực sự muốn có kinh nghiệm tốt khi làm việc cho một nhóm dự án thì hãy bắt đầu tìm kiếm xung quanh vì bạn sẽ không tìm thấy nó ở đó.
maple_shaft

2
@WayneM Hơn nữa, CIO của bạn cần có được các ưu tiên của anh ấy. Nếu anh ấy thực sự cố gắng tập trung vào việc chỉ đạo các dòng sản phẩm của bạn để đáp ứng nhu cầu của khách hàng và người dùng thay vì lãng phí thời gian quý báu của anh ấy cho bạn biết cách làm của bạn thì có lẽ công ty sẽ làm tốt hơn rất nhiều. Thật là một sự chấm dứt của rối loạn chức năng hoàn toàn.
maple_shaft

Điều tồi tệ nhất là họ thành công vừa phải do may mắn ngu ngốc, vì vậy họ thậm chí không nhìn thấy vấn đề.
Wayne Molina

1
@WayneM Dumb may mắn hoặc kết nối chính trị trong một thị trường thích hợp? Nó có lẽ là cái sau. Các doanh nghiệp không kiên trì với sự may mắn ngu ngốc trong thời gian dài. Điều duy nhất có khả năng giữ cho các đối thủ cạnh tranh hiệu quả hơn rời khỏi công ty của bạn phía sau là những rào cản như vậy để gia nhập.
maple_shaft

6

Như tôi đã lưu ý ở đây , nếu Scrum Master hoặc Chủ sở hữu sản phẩm có các nhiệm vụ có thể thực hiện được thì họ cũng là thành viên của Nhóm.

Điều đó nói rằng, bạn sẽ gặp vấn đề nghiêm trọng khi Agile trừ khi bạn mua thực sự từ cả CIO và khách hàng của bạn. CIO của bạn có sẵn sàng tuân theo thực tế là anh ấy không thể thêm một mục công việc giữa nước rút, nhưng sẽ phải đợi đến lần tiếp theo? Anh ấy có sẵn sàng ưu tiên các hạng mục sẽ được phát triển không? Từ những gì bạn đã viết, có vẻ như anh ấy sở hữu những gì bạn làm và do đó, nên là Chủ sở hữu sản phẩm. Nếu anh ấy không sẵn lòng, bạn sẽ không thành công hơn bạn hiện tại.


3
ĐIỀU NÀY. Chủ sở hữu sản phẩm phải cam kết và hiểu tầm quan trọng của nhóm luôn hướng tới một mục tiêu chung. Anh chàng này không nói về điều đó và thẳng thắn nghe như một công cụ khổng lồ đang cố gắng chơi một trò chơi trưởng thành trong một thế giới mà anh ta không hiểu. Hãy nhớ rằng tôi cũng đang đánh giá anh ấy bằng một số câu hỏi trong quá khứ của OP.
maple_shaft

1

Scrum có thể là một giải pháp tốt cho vấn đề của bạn về việc phân công CIO cho một nhà phát triển ad hoc, nhưng chỉ khi CIO sẽ mua vào quy trình. Tôi nghi ngờ rằng CIO của bạn sẽ không thích bị chuyển nhượng trực tiếp. Nhưng nếu bạn có thể khiến CIO mua ý tưởng về việc anh ấy viết truyện cho người dùng và sau đó ưu tiên chúng, anh ấy có thể thấy đó là một cách rất hiệu quả để quản lý. Nhưng nó sẽ bắt đầu với việc bạn thuyết phục CIO của bạn tuân thủ quy trình.


1

Scrum là một cái gì đó để xem xét, chắc chắn. Tuy nhiên, có một điều cần nói khi đưa tất cả những người tham gia vào cùng một trang và chấp nhận một vài thay đổi về cấu trúc cùng với việc có ít nhất một vài lần chạy nước rút để giải quyết các vấn đề ban đầu khác nhau khi sử dụng phương pháp này.

Chủ sở hữu sản phẩm nên ở bên ngoài nhóm phát triển vì nếu không sẽ có xung đột lợi ích xấu được trình bày ở đây. Scrum Master có thể là một nhà phát triển mặc dù không có gì xấu khi xảy ra xung đột trong trường hợp này.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.