Scrum có biến các nhà phát triển tích cực thành các nhà phát triển thụ động không?

Tôi là một nhà phát triển web làm việc trong một nhóm gồm ba nhà phát triển và một nhà thiết kế. Bây giờ là khoảng năm tháng chúng tôi đã thực hiện phương pháp phát triển phần mềm nhanh nhẹn. Nhưng tôi có một cảm giác kỳ lạ tôi chỉ muốn chia sẻ trong trang web này.

Một yếu tố quan trọng trong cuộc sống của con người là quá trình ra quyết định. Tuy nhiên, có một sự khác biệt lớn trong các quyết định bạn đưa ra. Một số quyết định chỉ là kết quả của một lực lượng bên trong hoặc bên ngoài, trong khi các quyết định khác hoàn toàn dựa trên ý chí tự do của bạn, và một số quyết định chỉ đơn giản là một cái gì đó ở giữa. Bạn càng có nhiều tự do trong việc đưa ra quyết định, công việc của bạn sẽ càng tự điều khiển. Đây dường như là một quy tắc. Bởi vì chúng ta có xu hướng định hình cuộc sống của chúng ta.

Có một sự khác biệt lớn giữa bạn quyết định phải làm gì , hoặc được cho biết phải làm gì .

Trước scrum, tôi cảm thấy muốn có nhiều tự do hơn trong việc đưa ra các quyết định liên quan đến phát triển, phân tích, ưu tiên thực hiện, v.v. Tôi có cảm giác như mình đang quyết định mình đang làm gì .

Tuy nhiên, do phương pháp scrum, bây giờ nhiều quyết định chỉ đơn giản đến từ chủ sở hữu sản phẩm. Anh ấy ưu tiên PBI , anh ấy phân tích cách phần mềm nên hoạt động, thậm chí đôi khi cách triển khai UI và chức năng. Tôi biết rằng đây là một phần của phương pháp scrum và tôi cũng biết rằng điều này có thể dẫn đến doanh số bán sản phẩm tốt hơn trong tương lai. Tuy nhiên, bây giờ tôi cảm thấy như mình luôn được yêu cầu làm điều gì đó, thay vì quyết định làm điều gì đó . Hội chứng này bây giờ đã khiến tôi trở nên thụ động hơn trong công việc.

1. Tôi có xu hướng tìm kiếm ít hơn để tìm một giải pháp, cách tiếp cận hoặc kỹ thuật tốt hơn
2. Tôi không thức dậy vào buổi sáng để mong có được một công việc thú vị. Thay vào đó, tôi cảm thấy như bị buộc phải làm việc để sống
3. Tôi có nhiều khao khát hơn để làm việc trên các dự án sở thích của riêng tôi sau khi làm việc
4. Tôi sẽ không thúc đẩy nhóm nữa để đạt đến trình độ công nghệ cao hơn
5. Bây giờ tôi dành nhiều thời gian hơn cho bữa tối, hoặc thời gian uống trà và ít nhiệt tình hơn để trở lại làm việc
6. Bây giờ tôi sẵn sàng nhiều hơn cho công việc để hoàn thành sớm hơn, để tôi có thể về nhà

Vấn đề lớn là, tôi cũng thấy và chẩn đoán hành vi này ở các đồng nghiệp của mình. Nó có phải là kết quả của scrum? Scrum có thực sự làm cho nhóm phát triển cảm thấy như họ không có phần nào trong việc hình thành phần mềm tổng thể, do đó làm cho thụ động cho dự án? Làm thế nào tôi có thể vượt qua cảm giác này?

Tuy nhiên, bây giờ tôi cảm thấy như mình luôn được yêu cầu làm điều gì đó, thay vì quyết định làm điều gì đó.

Đây là một chỉ báo nghiêm trọng rằng một cái gì đó đã đi ra khỏi đường ray. Một dự án nhanh không nên cảm thấy như thế này. Biện pháp tu từ "mọi người trong quá trình" nên bao gồm "chúng ta không ép buộc mọi người làm những việc tệ hại". Đây là một số ý tưởng:

Bạn đang làm "scrum but"? Đó là, một phần scrum, một số điều khác. (ví dụ: "Chúng tôi đang làm scrum, nhưng tất cả các câu chuyện của chúng tôi phải đến từ PMO của chúng tôi, không phải chủ sở hữu sản phẩm.") Rất nhiều chuyện tào lao điên rồ được gọi là Scrum ngày nay.

Bạn, cá nhân, không tham gia vào quá trình mà bạn nên ở đâu? Tôi đã biết một số người buồn bã về nội dung câu chuyện, và hóa ra họ chỉ tham gia khi câu chuyện đang trong giai đoạn tồn đọng nước rút. Nói chuyện với chủ sở hữu sản phẩm sớm trong quá trình phát triển câu chuyện và nhận phản hồi của bạn. (Là PO, họ có tiếng nói cuối cùng, nhưng điều đó không có nghĩa là họ phải làm điều đó một mình.)

Trong Scrum, nhóm được cho là sở hữu quy trình và dự kiến ​​quy trình sẽ thay đổi theo thời gian để phù hợp với nhu cầu của nhóm. Đưa ra mối quan tâm của bạn ở hồi cứu. Nếu bạn có thể đưa ra một tinh chỉnh quy trình để đề xuất, điều đó có xu hướng giúp bán dễ dàng hơn cho một số đội.

Vấn đề của bạn không phải là Scrum (và như Jarrod Roberson đã đề cập trong các bình luận, đó không phải là Scrum những gì bạn đang mô tả) - đó là quản lý vi mô của Chủ sở hữu sản phẩm và sự thiếu quyết đoán của bạn (và của Nhóm) .

"Tuy nhiên, do phương pháp scrum, giờ đây nhiều quyết định chỉ xuất phát từ chủ sở hữu sản phẩm. Ông ưu tiên PBIs, ông phân tích cách phần mềm nên hoạt động, thậm chí đôi khi nên triển khai UI và chức năng. Tôi biết rằng đây là một phần của phương pháp scrum."

Bạn đang nhầm. Chỉ từ một cái nhìn ngắn gọn trên trang wikipedia cho Scrum, người ta có thể thấy rằng: "Nhóm, một nhóm chức năng chéo thực hiện phân tích thực tế, thiết kế, thực hiện, thử nghiệm, v.v." Xem? Chủ sở hữu sản phẩm cho bạn biết phải làm gì, nhưng tùy thuộc vào Nhóm quyết định cách thực hiện.

Bạn là người chịu trách nhiệm thực hiện, vì vậy bạn nên quyết định cách ứng dụng sẽ được thực hiện. Lắng nghe ý kiến ​​của Chủ sở hữu sản phẩm, nhưng quyết định cuối cùng là tùy thuộc vào bạn (hoặc Nhóm).

Quản lý vi mô BTW không biến các nhà phát triển tích cực thành các nhà phát triển thụ động.

Những gì bạn đang mô tả là KHÔNG PHÙ

Chủ sở hữu sản phẩm của bạn đang vượt quá giới hạn của mình nếu anh ấy nói cho bạn biết cách thực hiện công việc của bạn về mặt kỹ thuật, đó không phải là điều mà SCRUM hướng tới.

SCRUM là về việc giải phóng các nhà phát triển để tập trung vào các vấn đề phát triển và trao quyền cho họ chịu trách nhiệm xác định thời gian thực hiện và cách thực hiện chúng.

SCRUM là về sự hợp tác, đó là những gì các cuộc họp lập kế hoạch của Sprint dành cho, để thúc đẩy sự hợp tác giữa tất cả các bên liên quan; chủ sở hữu sản phẩm, nhà phát triển và thử nghiệm.

Có, chủ sở hữu sản phẩm nên ưu tiên các tính năng, những gì cần được phân phối trước theo nhu cầu của khách hàng, nhưng các nhà phát triển nên thực hiện kỹ thuật và thiết kế, chứ không phải chủ sở hữu sản phẩm.

Tôi không đồng ý rằng các nhà phát triển nên thiết kế GUI và quy trình công việc trừ khi họ được giao nhiệm vụ và đào tạo cụ thể để làm việc với khách hàng và băm trực tiếp chức năng với khách hàng. Lập trình viên xây dựng GUI được thực hiện trong chân không hiếm khi đáp ứng nhu cầu của khách hàng.

SCRUM là về việc đặt một quy trình trọng lượng nhẹ có thể dự đoán và lặp lại được trong bản tuyên ngôn nhanh nhẹn.

Tôi cảm thấy buồn khi nghe những câu chuyện rằng những điều rất tốt đang bị biến thái như thế này.

Tôi đoán trước Scrum, mọi người chỉ làm những gì họ muốn: yippee ki-yay mf'er . Người dùng của bạn là ân nhân của bạn và họ lái câu chuyện và trả các hóa đơn. Chủ sở hữu sản phẩm đảm bảo câu chuyện được thực hiện. Một số cách, nhóm của bạn đã đi đến kết luận rằng Chủ sở hữu sản phẩm sẽ cho bạn biết cách lập trình.

Bạn muốn viết mã hoặc làm cho các ứng dụng nhỏ gọn mà bạn nghĩ là mát mẻ? "Tôi muốn làm tính năng A trước chứ không phải B, vì vậy tôi có thể duy trì quyền tự do lựa chọn của mình." Tìm một ân nhân khác nhau và không phải là một phương pháp phát triển mới.

Bạn bị cuốn vào tiêu đề Chủ dự án hoặc một cái gì đó. Nếu bạn có một lý do hợp lệ để không đồng ý với câu chuyện, hãy nói điều gì đó, đưa ra lập luận của bạn. Bạn có thể không luôn luôn chiến thắng. Công việc của họ là trả lại cho người dùng và cho họ biết có vấn đề hợp lệ với yêu cầu của họ. Hãy đối mặt với nó, nếu câu chuyện yêu cầu bạn bỏ cơ sở dữ liệu ngẫu nhiên trong suốt cả ngày, không có bản sao lưu, không mất dữ liệu hoặc thời gian ngừng hoạt động, bạn có một vấn đề và nhiệm vụ phải đặt câu chuyện thẳng.

Có vẻ như cuộc phiêu lưu của bạn vào Agile đã bị Scrum làm hỏng. Tôi thấy rằng, trong tất cả các phương pháp nhanh, Scrum là nhanh nhất. Nó giống như thác nước thu nhỏ và quản lý dự án bổ sung. Điều này, tất nhiên, làm cho nó được quản lý thích nhất, những người cảm thấy họ đang kiểm soát lại từ những nhà phát triển phiền phức đó, nhưng tất nhiên bạn thấy thực tế của tình huống.

Agile không phải là đi theo một con đường quy định, nó được thiết kế để làm cho bạn năng suất và động lực hơn. Mọi người không nói các tuyên ngôn (diễn giải) và bị mất trong hệ thống bạn đang sử dụng.

Vì vậy, thay đổi nó. Đưa lên với quản lý và nói rằng đó là một bước thụt lùi, rằng năng suất của bạn thấp hơn trước đây và tất cả bạn đều không hài lòng với cách làm việc của nó. Hiển thị Tuyên ngôn Agile (và song sinh độc ác của nó ) và chứng minh rằng bạn không chỉ học được bài học từ thí nghiệm này mà còn muốn phát triển các bit tốt từ nó thành một hệ thống tốt hơn (một thứ giống như bạn từng có, dường như hoạt động tốt cho bạn).

Tôi nghĩ rằng, đơn giản là các bạn đã quen với việc có nhiều quyền sở hữu hơn - và tất cả mọi người tôi nghĩ thích điều đó, bản chất con người của nó.

Thật không may, tôi nghĩ rằng rất nhiều phần mềm ít hơn nó có thể, bởi vì các phần thường được viết cho nhà phát triển chứ không phải máy khách. Cách tiếp cận mới của bạn sẽ làm giảm điều đó, nhưng phải trả giá bằng cảm giác sở hữu của bạn.

Tôi không biết làm thế nào để đề nghị bạn làm cho mọi thứ tốt hơn hoặc vui hơn nhưng đó là một câu hỏi hay và một cái nhìn sâu sắc rất tốt.

Bạn có nhận được các câu chuyện của người dùng ở dạng "Như một --role--, tôi muốn --goal / mong muốn-- vì vậy --benefit--"? Có vẻ như Chủ sở hữu sản phẩm của bạn muốn thực hiện công việc thiết kế và anh ấy / cô ấy có thể không phải là người tốt nhất để làm điều đó. Sử dụng mẫu câu chuyện người dùng có thể giúp đảm bảo rằng Chủ sở hữu sản phẩm bám sát lợi ích kinh doanh và việc phát triển phần mềm đang được thực hiện bởi các nhà phát triển phần mềm.

Trong Scrum có rất nhiều không gian để các nhà phát triển đóng góp và đưa ra lời khuyên cho họ về các tính năng mới, giao diện người dùng, khả năng sử dụng ... Cần có sự hợp tác và trò chuyện giữa người kinh doanh và nhà phát triển trong Scrum và điều đó cho phép điều đó. Tuy nhiên , cuối cùng, chủ sở hữu sản phẩm sẽ luôn có tiếng nói cuối cùng bởi vì anh ta là người chịu trách nhiệm tối đa hóa giá trị kinh doanh của các phần mềm gia tăng được tạo ra sau khi chạy nước rút (nói cách khác là ROI).

Từ Tuyên ngôn Agile:

Ưu tiên cao nhất của chúng tôi là làm hài lòng khách hàng thông qua việc cung cấp phần mềm có giá trị sớm và liên tục.

Chủ sở hữu sản phẩm cho bạn biết cách triển khai UI và chức năng không được chấp nhận. Trong trường hợp đó, bạn nên có tiếng nói cuối cùng vì bạn chịu trách nhiệm về chất lượng bên trong của phần mềm bạn sản xuất.

Có thể bạn làm việc trong một công ty được tạo bởi các nhà phát triển nơi các lập trình viên có quyền tự do thực hiện bất kỳ tính năng nào họ muốn. Tuy nhiên, hầu hết các phương pháp Agile tạo ra sự tách biệt rõ ràng giữa những người trong lĩnh vực kinh doanh và nhóm chịu trách nhiệm sản xuất phần mềm (nhà phát triển, người thử nghiệm ...) là bộ phận công việc phổ biến nhất ở hầu hết các nơi. Nếu giả định của tôi là đúng, tôi có thể hiểu cảm giác của bạn rằng bạn không thể "có ảnh hưởng đến bức tranh lớn" nữa nhưng với công ty đang phát triển tôi đoán dù sao thì đó cũng là trường hợp, Scrum hay không.

Về phân tích, thiết kế và các hoạt động phát triển meta khác mà bạn đề cập (một lần nữa không được Chủ sở hữu sản phẩm thực hiện), các nhóm Agile được cho là có chức năng chéo và không có silo. Không ai có nghĩa vụ phải sở hữu tất cả kiến ​​thức xung quanh một hoạt động phát triển cụ thể, vì vậy có thể có cơ hội để bạn đa dạng hóa ở đó so với chỉ "đánh lừa mã".

Ngược lại, tôi thấy rằng việc chủ sở hữu sản phẩm đưa ra quyết định về chức năng cho phép tôi dành nhiều thời gian hơn để sản xuất mã chất lượng. Ngoài ra, nếu có những lo ngại hợp lệ, tôi luôn có thể đặt câu hỏi cho các quyết định của chủ sở hữu sản phẩm và điều đó thường dẫn đến các cuộc thảo luận hiệu quả.

Chúng tôi thực hành Scrum ở đây. Chúng tôi có một cuộc họp lập kế hoạch hai tuần một lần, nơi chúng tôi nuôi dưỡng các ưu tiên kinh doanh hiện tại, những thành công và thất bại từ lần chạy nước rút trước đó và chúng tôi quyết định, với tư cách là một đội , chúng tôi muốn giải quyết gì cho lần chạy nước rút tiếp theo.

Một trong những cách chúng tôi làm là sắp xếp các hồ sơ tồn đọng trên một bảng theo độ phức tạp theo chiều dọc và ưu tiên kinh doanh theo chiều ngang. Sau đó, Chủ sở hữu sản phẩm đã có đầu vào của mình, do đó, tùy thuộc vào nhóm để chọn ra những gì chúng tôi muốn làm. Rõ ràng, chọn ra một nhiệm vụ ưu tiên thấp có độ phức tạp cao được tán thành, nhưng chúng tôi quyết định đây là một nhóm. Nó làm cho các phiên lập kế hoạch dài hơn, nhưng nó đáng giá và là một phần cốt lõi của quy trình Agile.

Và đôi khi chúng ta có quản lý vi mô, nhưng đó là một vấn đề khác.

Vấn đề thực sự mà bạn mô tả là một bệnh lý phổ biến khi các nhóm áp dụng Phương pháp luận: họ tắt não. Điều này đúng với hệ thống nhanh nhẹn của trường học mới như với hệ thống hạng nặng trường cũ.

Q: Phương pháp quy định x, nhưng x không hoạt động tốt. Chúng ta nên làm gì?

A: Tinh chỉnh việc thực hiện x của bạn. Có lẽ ngừng làm việc đó hoàn toàn. Phương pháp không phải là ông chủ của bạn!

Trong trường hợp cụ thể này, có vẻ như chủ sở hữu sản phẩm có thể đang làm quá nhiều. Bạn có thoải mái khi nói chuyện với anh ấy về điều đó? Bạn có cảm thấy thoải mái khi có cuộc trò chuyện đó nếu bạn không "làm scrum?" Nếu chủ sở hữu sản phẩm không nhạy cảm với phản hồi mang tính xây dựng, thì đó không phải là vấn đề về phương pháp, đó là vấn đề với chủ sở hữu sản phẩm.

Tôi không thực sự đồng điệu với toàn bộ điều scrum vì đã có nhiều thác nước trong một thời gian.

Nhưng thành thật mà nói, điều này nghe giống như một vấn đề nhân sự quản lý hơn là một vấn đề kỹ thuật quản lý dự án. Như trong đó nhiều người dựa trên kỹ thuật hơn.

Vai trò của các nhà lãnh đạo đối với một nhóm tự tổ chức sẽ là một bài đăng trên blog về một cái gì đó dường như bị thiếu trong bài viết của bạn. Đội quyết định công việc nào được thực hiện trong giai đoạn nước rút? Đội ngũ có quyền sở hữu trong quá trình và công việc ở đâu? Bạn có ai đó biết Scrum đủ rằng bạn đang làm Scrum và không phải là phiên bản biến thái của nó không?

Tôi đã có cùng trải nghiệm với Scrum và muốn gọi nó là "sự chuyên chế của câu chuyện".

Từ kinh nghiệm của tôi, các nhà phát triển nhiều hơn về phía sáng tạo / thiết kế / frontend dường như phải chịu đựng nhiều hơn từ nó so với những người tham gia vào công việc phụ trợ.

Cách duy nhất tôi tìm thấy cho đến nay là bỏ qua Scrum - thường là không thể và / hoặc phù hợp bởi vì sau tất cả, nó có lợi thế - hoặc giới thiệu thứ gì đó như 20% thời gian của Google để cung cấp cho các nhà phát triển một lối thoát sáng tạo ngoài "bạn" Bạn có thể tự do lựa chọn cách triển khai Trang đăng nhập ", vì thực tế bạn không phải vì việc triển khai của bạn bị ràng buộc bởi mã và kiến ​​trúc hệ thống hiện có - đó là trừ khi người ta xem xét quyền tự do lựa chọn giữa 'vòng lặp for và vòng lặp' sự tự do.

Có một sự khác biệt lớn giữa bạn quyết định phải làm gì , hoặc được cho biết phải làm gì .

Theo kinh nghiệm của tôi, chỉ còn một chặng đường khá dài từ việc được nói phải làm gì để quyết định phải làm gì.

Vào cuối của cách này, nó thường chỉ ra rằng chúng tôi đã được hướng dẫn không phải vì họ thích sức mạnh và không phải vì họ không có gì tốt hơn để làm. Hoàn toàn ngược lại, ở cuối con đường này - khi họ có đủ niềm tin vào đội ngũ của chúng tôi - họ dường như cảm thấy nhẹ nhõm và vui vẻ vượt qua chúng tôi nhiều quyền kiểm soát nhất (và nếu niềm tin của họ thực sự vững chắc, họ thậm chí còn cố gắng vượt qua nhiều hơn thế)

Ồ và theo kinh nghiệm của tôi thì điều này về cơ bản không liên quan gì đến Scrum / agile. Đã xảy ra với scrum, lặp đi lặp lại, thác nước, bất cứ điều gì. Có vẻ như vấn đề của niềm tin là quá trình bất khả tri

Trong nhóm của chúng tôi, chủ sở hữu sản phẩm cho chúng tôi biết phải làm gì và chúng tôi quyết định cách chúng tôi làm điều đó. Điều thực sự quan trọng là có sự tách biệt này hoặc bạn sẽ kết thúc trong tình huống bạn đã mô tả.

Theo kinh nghiệm của tôi, Scrum là để theo dõi sâu sắc những gì bạn làm. Nó chỉ ngồi trên vai bạn và xem những gì bạn làm. Mặc dù nó có lợi thế riêng của nó, tôi ghét phương pháp scrum. Nó mong đợi số lượng, không phải chất lượng. Chất lượng đang bị tổn hại với phương pháp scrum.