it-swarm-vi.com

Agile có phải là quản lý vi mô mới không?

Câu hỏi này đã được nấu trong đầu tôi một thời gian vì vậy tôi muốn hỏi những người đang theo dõi các thực hành nhanh nhẹn/scrum trong môi trường phát triển của họ.

Công ty của tôi cuối cùng đã mạo hiểm kết hợp các thực hành nhanh và đã bắt đầu với một nhóm gồm 4 nhà phát triển trong một nhóm nhanh nhẹn trên cơ sở thử nghiệm. Đã 4 tháng với 3 lần lặp lại và họ tiếp tục làm điều đó mà không hoàn toàn nhanh nhẹn cho phần còn lại của chúng tôi. Điều này là do thực tế là sự tin tưởng của ban quản lý để đáp ứng các yêu cầu kinh doanh với khá nhiều yêu cầu loại ad hoc từ trên cao.

Gần đây, tôi đã nói chuyện với các nhà phát triển là một phần của sáng kiến ​​này; họ nói với tôi rằng nó không vui Họ không được phép nói chuyện với các nhà phát triển khác bởi chủ Scrum của họ và không được phép thực hiện bất kỳ cuộc gọi điện thoại nào trong khu vực làm việc (có thể tốt ở một mức độ nào đó). Ví dụ, nếu tôi muốn nói chuyện với bạn của tôi về những cú đá trong đội nhanh nhẹn, tôi không được phép nếu không có sự chấp thuận của chủ Scrum; người đang ngồi ngay bên cạnh đội ngũ nhanh nhẹn.

Ý tưởng của tất cả những điều này hoặc nhanh nhẹn là cung cấp một khoảng trống hoàn toàn cho các nhà phát triển nhanh nhẹn khỏi mọi gián đoạn và để họ đưa vào hơn 6 giờ làm việc hiệu quả. Chà, các bạn, tôi không phải là một bậc thầy nhanh nhẹn nhưng những gì tôi đã đọc tài liệu giới thiệu nhanh nhẹn của Yahoo và tương tự cho các tổ chức khác, nó mang lại cho tôi cảm giác rằng nhanh nhẹn không hề rẻ. Nó đòi hỏi các nguồn lực và ngân sách để thấm nhuần vào các đội và khắc phục vấn đề khi họ đến để đưa họ trở lại đúng hướng.

Đối với người mới bắt đầu, nó yêu cầu đào tạo cho các nhà phát triển và huấn luyện cho các nhà quản lý, v.v. ... Chủ nhân Scrum hiện tại là một người quản lý đã mất vài ngày lớp đào tạo nhanh nhẹn do ban quản lý trả tiền hiện đang dẫn dắt nhóm nhanh nhẹn này. Tôi cũng đã nghe trong cuộc họp rằng bản tuyên ngôn nhanh nhẹn không cho rằng agile không được đặt trong đá và được tùy chỉnh khác nhau cho mỗi công ty. Vâng, tất cả nghe có vẻ tốt và lý do.

Để kết luận, tôi luôn nghĩ rằng nhanh nhẹn được cho là mang lại sự hài hòa trong các nhóm phát triển dẫn đến kết quả là các nhà phát triển hạnh phúc. Tuy nhiên, tôi đang có một cảm giác rất trái ngược khi nói chuyện với các nhà phát triển trong nhóm nhanh nhẹn. Họ không vui khi họ không thể nói bất cứ điều gì ngoài công việc, ngồi im lặng cả ngày chỉ làm việc và họ cảm thấy đó chỉ là một cách khác để quản lý làm cho họ làm việc nhiều hơn.

Xin vui lòng cho tôi biết, nếu đây là một trong những ví dụ về các thực hành tốt được sử dụng cho mục đích lợi ích ích kỷ để có thêm đô la? Hoặc có thể, chỉ có chúng tôi là những nhà phát triển như tôi và nhóm nhanh nhẹn này cảm thấy rằng họ không thích làm việc trong môi trường mà họ chỉ thở khi làm việc vì họ đang làm việc.


Đó là một công ty trong lĩnh vực chăm sóc sức khỏe có văn phòng trên khắp Hoa Kỳ. Nó chắc chắn cảm thấy như một cao bồi nhanh nhẹn khiến tôi thực sự không muốn đi nhanh nhẹn, đặc biệt là tại công ty hiện tại của tôi.

Tất cả phải làm với việc quản lý là hoàn toàn rẻ. Cắt giảm cà phê đắt tiền cho phiên bản rẻ hơn, nhấn mạnh vào tiết kiệm và có năng suất trong khi vẫn gọn gàng nhất có thể.

Cảm giác của tôi là ai đó trong ban quản lý đã đưa ra ý tưởng này, sự nhanh nhẹn đó khiến bạn sản xuất nhiều hơn để chúng tôi có thể cho thấy các ông chủ của chúng tôi đang sản xuất nhiều hơn với cùng số lượng nhân viên. Hoặc, có thể, nó sẽ cho phép chúng tôi giảm số lượng nhân viên nếu đó là trường hợp.

Họ đang có cuộc họp hàng ngày 5 phút. Nhưng không được phép trò chuyện hoặc nói chuyện với ai đó bên ngoài nhóm của họ. Tất cả tập trung vào công việc.

81
Smith James

Bạn đang mô tả chế độ độc tài quản lý, không nhanh nhẹn. Agile là về sự phát triển gia tăng trong một lĩnh vực thay đổi các yêu cầu, không phải là chỉ đạo mọi người về cách họ thực hiện công việc của mình.

89
Sami Lehtinen

Họ không được phép nói chuyện với các nhà phát triển khác bởi chủ Scrum của họ và không được phép thực hiện bất kỳ cuộc gọi điện thoại nào trong khu vực làm việc

Đây thực sự không phải là một phần của các thực hành Agile - và một vấn đề riêng biệt.

Một động lực lớn của các phương pháp Agile là tăng giao tiếp giữa các nhà phát triển. Hạn chế nhà phát triển <-> giao tiếp với nhà phát triển là một vấn đề riêng biệt với các thực tiễn Agile. Tôi không nói điều này không xảy ra - rõ ràng là như vậy và nó được coi là một phần của buổi giới thiệu "nhanh nhẹn" trong tổ chức của bạn, nhưng đây thực sự là một vấn đề riêng biệt với sự nhanh nhẹn (và hơi chống lại tinh thần phát triển nhanh nhẹn, IMO).

46
Reed Copsey

Nghe có vẻ như một triển khai khá nhanh nhẹn. Agile, nếu có bất cứ điều gì, nên giảm quản lý vi mô, không tăng nó. Nhóm thực hiện một cam kết và một phần của quy trình là quản lý tin tưởng rằng nhóm sẽ hoàn thành nó. Scrum hàng ngày là cách để các nhà phát triển giao tiếp với nhau và là cách để thông báo những gì họ đã làm, chứ không phải họ đã dành thời gian như thế nào (đó là một lỗi tôi đã thấy ở một vài nơi). Ngay cả quá trình ước tính cũng nên loại bỏ thời gian rõ ràng khỏi các ước tính, vì bạn nên ước tính độ phức tạp tương đối, chứ không phải là một câu chuyện sẽ kéo dài bao lâu (một lỗi phổ biến khác). Kiểm soát thời gian của các nhà phát triển là đặc trưng của quản lý vi mô và loại bỏ thời gian khỏi quy trình là một trong những nguyên lý cốt lõi của sự nhanh nhẹn.

31
jjb

Môi trường bạn mô tả âm thanh giống như khu vườn giả nhảm Agile .

Tôi đã tham gia với Agile trước khi nó là Agile. Circa 2000 Tôi đã say mê viết mã, nghe về Lập trình cực đoan, đã thử nó và thích nó. Nó mang lại cho tôi như một nhà phát triển bối cảnh trong đó việc sản xuất phần mềm vững chắc là điều quan trọng nhất và nó đã cho tôi các công cụ để giảm thiểu rất nhiều điều nhảm nhí khiến tôi phát điên. Tôi yêu nó.

Vấn đề ngày nay, mà tôi giải thích chi tiết ở nơi khác , là hầu hết mọi người "chấp nhận Agile" ngày nay không quan tâm đến việc cải thiện bất cứ điều gì nếu điều đó làm họ khó chịu. Vì vậy, đối với họ, "Agile" chỉ là một cây gậy mới để đánh bại các nhà phát triển theo cách cũ. Trái ngược với, một cách để tăng triệt để năng suất trong khi loại bỏ tất cả những điều nhảm nhí đang làm chậm sự phát triển.

Ngay bây giờ. Tôi đang thành lập một công ty và tôi sẽ sử dụng rất nhiều XP, cộng với một loạt các mánh khóe khác mà tôi đã học được trong thế giới Agile. Nhưng chính xác là vì những câu chuyện như của bạn, tôi nao núng bất cứ khi nào tôi nghe về việc nhận con nuôi Agile những ngày này.

Vì vậy, để trả lời trực tiếp câu hỏi của bạn: Agile không nên là quản lý vi mô mới. Nó nên là về việc trao quyền cho những người làm công việc thực tế để hoàn thành công việc. Nhưng trong trường hợp của bạn, Agile nghe giống như lời nói dối mới nhất mà họ đang nói với bạn trong khi họ nuông chiều bản năng xấu của chính mình. Mà tôi thực sự xin lỗi.

24
William Pietri

Đây không phải là nhanh nhẹn.

Thứ nhất, Scrum không nhanh nhẹn. Scrum, thẳng thắn, là nhảm nhí. Tôi lớn lên trong một ngôi nhà lập trình cực đoan (theo nghĩa đen - tôi đã có Kent Beck ngồi trên ghế sofa của cha tôi và nói chuyện với tôi về việc thử nghiệm), và tôi có thể nói thẳng với bạn rằng Scrum không phải vậy. Scrum là một công cụ quản lý dự án - một nhịp điệu xác định cho một dự án phát triển. Nhưng nó không có gì để nói về sự phát triển, và rất ít để nói về các yêu cầu, kế hoạch và mối quan hệ với khách hàng. XP có rất nhiều điều để nói về tất cả những điều đó; bất kỳ phương pháp nào khác muốn tự gọi là nhanh nhẹn phải có một cái gì đó để thêm vào cuộc trò chuyện. Những người đề xuất Scrum đã mô tả nó không phải là một quá trình, nhưng như Một người bao bọc cho một quá trình. Một người khôn ngoan đã từng chỉ ra rằng một trình bao bọc là thứ bạn loại bỏ và loại bỏ để có được những thứ tốt.

Được rồi, scrum rant hơn!

Thứ hai, một nguyên tắc sáng lập của XP, mà tôi tin là cơ bản cho bất kỳ quy trình nhanh nào, đó là tập trung vào nhà phát triển. Đó là một cách mang lại cho các nhà phát triển sức mạnh để thực hiện công việc mà họ biết họ cần phải làm và thường xuyên bị ngừng thực hiện. Một nhóm nhanh nhẹn có thể được cấu trúc như một nền dân chủ hoặc chuyên chế, nhưng các nhà lãnh đạo là các nhà phát triển. Có những vai trò cho người quản lý dự án, v.v. - vai trò quan trọng - nhưng đó không phải là một trong những người lãnh đạo nhóm. Có một người quản lý - xin lỗi, 'bậc thầy scrum' - ngồi đó làm chủ mọi người xung quanh là một dấu hiệu chắc chắn rằng nhóm không làm việc nhanh nhẹn.

Tôi cảm thấy như nên có một phần ba. Không có.

23
Tom Anderson

Scrum là đứa con hoang của Agile. Đây là kiểu thác nước nhất trong tất cả các phương pháp nhanh, và đó là lý do tại sao nó phổ biến nhất trong số các nhà quản lý.

Tất cả các phương thức nhanh là về việc tạo mã làm việc mà không làm phiền. Đọc lại lần nữa Và một lần nữa.

Bất cứ điều gì cản trở mục tiêu đó, bất kể "quy tắc nhanh" là xấu. Nếu quy tắc cản trở, hãy thay đổi quy tắc f * * ! Đó là cách nhanh nhẹn, đó là những gì làm cho nó có liên quan và hiệu quả.

ví dụ tốt nhất trong số này được đưa ra bởi Alistair Cockburn (một trong những người khởi tạo bản tuyên ngôn nhanh nhẹn):

Tiết kiệm Đặt 4 - 6 người trong một phòng với máy trạm và bảng trắng và quyền truy cập cho người dùng. Yêu cầu họ cung cấp phần mềm đang chạy, đã được kiểm tra cho người dùng cứ sau một hoặc hai tháng, và nếu không thì hãy để họ một mình.

Nếu điều đó làm việc cho chất lượng của những người bạn có, thì đó là tất cả những gì bạn cần. Bạn không cần một bậc thầy scrum hoặc bất kỳ phương pháp "nhanh nhẹn" nào. Nếu ngồi xuống trong một scrum hàng ngày làm việc cho bạn, thì f * * * làm điều đó. Làm cho bạn đứng lên chỉ là sự ghê tởm thảm hại về khả năng suy nghĩ của bạn.

Có một phản hồi đối với loại nhanh nhẹn bạn đang làm. Đây là nó. In nó ra và ghim nó lên một nơi nào đó khi không có ai xung quanh và để họ tự khám phá nó.

16
gbjbaanb

Bậc thầy Scrum hiện tại là một người quản lý, người đã mất vài ngày lớp đào tạo nhanh nhẹn do ban quản lý trả tiền, hiện đang lãnh đạo nhóm nhanh nhẹn này.

Đó là vấn đề của bạn. Các nhà quản lý muốn một số Agile, họ không thực sự biết nó là gì và họ áp đặt nó cho các đội. Đó là khá nhiều việc phải làm khi bạn muốn giảm đáng kể năng suất của các nhà phát triển của bạn;)

Đề xuất quy trình mới phải đến từ các nhà phát triển. Hoặc ít nhất là được họ xem xét & phê duyệt nếu đó là ý tưởng của ban quản lý.

Trong mọi trường hợp, nếu các nhà phát triển từ chối nó, không thực hiện nó! Hoặc nó sẽ là thảm họa mà bạn mô tả.

11
user2567

"Agile" và mọi "phương pháp quản lý" khác thường bị lạm dụng để ép buộc quản lý vi mô đối với con người. OTOH đôi khi cũng bị lạm dụng để bảo vệ tay nghề kém.

"Chúng tôi nhanh nhẹn" là lý do thường xuyên nhất tôi nghe thấy vì thiếu kế hoạch, thiếu suy nghĩ về thiết kế, tính năng, chất lượng, chu kỳ phát hành. Điều này thường từ các nhà phát triển và quản lý thấp hơn. Thật điên rồ cũng là cái cớ được sử dụng thường xuyên nhất mà tôi nghe được từ các nhà quản lý cấp trung, kiến ​​trúc sư, nhân viên bán hàng, v.v. .

Cả hai tất nhiên thường mâu thuẫn trực tiếp, và có thể xảy ra trong cùng một dự án.

9
jwenting

Để trả lời câu hỏi ban đầu của bạn, Agile là quản lý vi mô mới, tôi sẽ nói không.

Đầu tiên, hãy đọc this (tuyên ngôn Agile) và bạn sẽ nhận thấy rằng việc không nói chuyện với các nhà đồng phát triển của bạn không được liệt kê.

Trên thực tế "Cá nhân và tương tác" hoàn toàn ngược lại với việc không nói chuyện với các nhà đồng phát triển của bạn.

7
Ian

Agile nên là người tự quản lý mới. Nếu nhanh nhẹn được thực hành chính xác, nhiều quyết định được đưa ra bởi một khách hàng và nhà phát triển làm việc trong câu chuyện người dùng có phạm vi hợp lý được thêm vào backlog khi nhiệm vụ được xác định.

Scrum hàng ngày là về giao tiếp, không phải quản lý. Sẽ có một số cuộc thảo luận về ưu tiên và cân bằng tải, nhưng người được quản lý tại scrum hy vọng là scrum bậc thầy. NHƯ một nhà phát triển, tôi tham dự, nói những gì tôi đã làm, những gì tôi sẽ làm và những gì tôi cần giúp đỡ. Sau đó, chủ scrum sẽ chuyển sang hành động bù trừ hành động cho tiến trình của tôi.

Các nhóm nhanh nhẹn không cảm thấy công việc hàng ngày được quản lý theo cấp bậc. Nếu quyết định được đưa ra từ xa bởi một người nào đó ở đầu tổ chức phân cấp, thì đó là thời gian cho việc phân cấp ra quyết định! Đối với một số người và một số tổ chức, đây có thể là một cây cầu quá xa. Nếu những điều sau đây không đúng với tổ chức của bạn:

Sống theo Tuyên ngôn nhanh nhẹn

"Chúng tôi đang khám phá những cách tốt hơn để phát triển phần mềm bằng cách làm điều đó và giúp người khác làm điều đó."

Tránh "Gặp sếp mới, giống như sếp cũ." Tạo nguồn gốc từ Agile từ trong nhóm càng nhiều càng tốt. Đôi khi điều này xảy ra bằng cách chọn một liên minh sẵn sàng tham gia vào một dự án thử nghiệm sử dụng Agile. Nếu bạn có thể thành lập nhóm Agile của mình từ các tình nguyện viên hoặc các thành viên được mời có hồ sơ theo dõi để làm việc nhóm tốt, họ có thể giải quyết nó. Sử dụng một nhóm nhỏ trong một dự án ngắn, có thể cho một khách hàng nội bộ hoặc rất dễ tiếp cận.

Nắm bắt sự thay đổi. Có lẽ bạn có thể thực hiện một số khóa đào tạo, nhưng có thể ngân sách của bạn eo hẹp và tiền không có ở đó. Các cơ hội khác cũng có thể cung cấp sự cải thiện. Đọc một số bài, để các thành viên trong nhóm tìm hiểu những gì họ có thể về Agile và dạy cho nhau. Bạn có thể tìm thấy nhân viên mới hoặc hiện có đủ điều kiện để làm mẫu và lãnh đạo trong việc áp dụng Agile.

2
DeveloperDon

Các đội Agile giống như các đội bóng đá làm việc hướng tới một mục tiêu thường được hiểu. Tôi đã là một phần của các nhóm nhanh nhẹn trong một số năm và chìa khóa là giao tiếp hiệu quả và hiệu quả trên tất cả các bên liên quan. Người quản lý/chủ Scrum chỉ là người hỗ trợ nhóm và quản lý truyền thống/quản lý vi mô sẽ giết chết tinh thần của đội.

Trong các đội tôi đã làm việc, chúng tôi được khuyến khích chơi các trò chơi tập thể sau giờ làm việc để cải thiện tình bạn trong các thành viên. Tôi đã thu thập những suy nghĩ đó ở đây .

1
Vinod R

Để trả lời câu hỏi của bạn: Không. Agile không phải là một hình thức quản lý vi mô. Nhưng giống như bất kỳ công cụ nào, mọi người có thể sử dụng nó không chính xác. Agile là tuyệt vời khi được thực hiện đúng cách và khi mọi người phù hợp với nó.

Suy nghĩ của tôi về chủ đề "Devs không nói chuyện với ai ngoài chủ nhân scrum":

Tôi đã từng làm việc ở một nơi mà đó là một quy tắc trước đây. TUY NHIÊN, quy tắc liên quan nhiều hơn đến việc yêu cầu mọi người hoàn thành nhiệm vụ. Ví dụ: tôi không thể ngẫu nhiên đến gặp một người thử nghiệm và yêu cầu họ thực hiện một số thử nghiệm cho tôi trong vài giờ tới. Tôi cần nói chuyện với chủ scrum để họ có thể thảo luận với thành viên trong nhóm về việc công việc đó sẽ phù hợp với nước rút như thế nào nếu đó là trường hợp khẩn cấp (hoặc nếu nó cần được đẩy vào tồn đọng để chạy nước rút trong tương lai).

Trong trường hợp đó, tôi hiểu khái niệm "các nhà phát triển không nói chuyện với nhau" bởi vì nó thực sự được dịch sang các nhiệm vụ kênh thông qua một điểm kiểm tra để một nhà phát triển cụ thể không làm việc quá sức hoặc quá bận rộn để thực hiện các nhiệm vụ khẩn cấp mà họ không thể lên kế hoạch công việc đã hoàn thành.

Nếu không, các nhà phát triển NÊN nói chuyện với nhau. Luôn luôn. Nó giúp bạn giải quyết các vấn đề nhanh hơn, trở nên gần gũi hơn với tư cách là một nhóm và cung cấp nhanh hơn.

Chỉ để đưa ra một viễn cảnh khác: Tôi cũng đã từng ở trong một môi trường mà mọi người nghĩ rằng các nhà phát triển "nói quá nhiều". Sau khi ngồi xuống, chúng tôi phát hiện ra rằng thực sự được dịch thành "các nhà phát triển không đủ độc lập để hoàn thành công việc của họ. Bởi vì mọi thứ rất rời rạc, các nhà phát triển phải đến ba người khác để hoàn thành nhiệm vụ nhỏ."

Vì vậy, khi các nhà quản lý quyết định chuyển sang nhanh nhẹn, họ hy vọng rằng sẽ giúp đưa thông tin đến đúng nơi và ngăn chặn rất nhiều sự phân mảnh trong tổ chức. Một số người thất vọng vì sau khi Agile được triển khai, các nhà phát triển vẫn chạy qua lại với nhau. Nhưng, điều họ không nhận ra là điều đó đã xảy ra ngày càng ít đi. Nó đã mất thời gian mặc dù. Vì vậy, có lẽ nếu đó là những gì đang diễn ra trong tổ chức của bạn, có thể mọi người mong đợi nhanh nhẹn để sửa chữa mọi thứ qua đêm. Đó không phải là cách nó hoạt động.

0
JustBlossom