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 sự cố 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 được 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à một người nào đó 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.

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, chứ 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.

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).

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 dành cho các nhà phát triển là đặc điểm nổi bật 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.

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

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 thủ thuật 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 câu hỏi của bạn trực tiếp: 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.

Đâ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ả điều đó; bất kỳ phương pháp nào khác muốn tự gọi mình 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, mà là một trình bao bọc cho một quy trình. Một người đàn ông khôn ngoan đã từng chỉ ra rằng một cái 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à nó 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ó.

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ả.

Các ví dụ tốt nhất của việc này được đưa ra bởi Alistair Cockburn (một trong những người đưa ra 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 ứng 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ó.

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 nên đến từ các nhà phát triển. Hoặc ít nhất được xem xét và phê duyệt bởi họ 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ó, đừng thực hiện nó ! Hoặc nó sẽ là thảm họa mà bạn mô tả.

"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.

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

Trước tiên, hãy đọc phần này (bản 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.

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 một câu chuyện người dùng có phạm vi hợp lý được thêm vào hồ sơ tồn đọng khi các 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à chủ scrum. 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 cảm thấy như công việc hàng ngày được quản lý theo cấp bậc. Nếu các quyết định được đưa ra từ xa bởi một người đứng đầu một tổ chức phân cấp, thì đã đến lú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 điều sau đây không đúng với tổ chức của bạn:

Sống theo Tuyên ngôn Agile

"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 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ể tham gia 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.

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 .

Để 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 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 dev 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 của họ về cách công việc đó sẽ phù hợp với nước rút 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 cho lần 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ự dịch là "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.

Tác giả gốc Smith Janes có thể đã có kinh nghiệm. Nhưng đây là những vấn đề điển hình tôi tìm thấy trong dự án Agile.

1. Hầu hết các tổ chức, nhà phát triển được cho là làm việc trong nhiều dự án, trong Agile / scrum .. Sprints không bao giờ được coi là thực tế này. Scrum Master của bạn cho rằng bạn nên hoàn thành các câu chuyện của mình vào cuối giai đoạn nước rút .. Chủ Scrum của bạn có thể chỉ dành riêng cho một dự án, nhưng không phải là nhà phát triển .. ĐÂY LÀ PHÂN PHỐI-- không cần chỉ gọi điện thoại hoặc cho phép một cuộc gọi điện thoại.
2. Tôi đã thấy các dự án Agile nơi Sprint được lên kế hoạch, Các câu chuyện được đưa vào Sprint, mà không bị lộn xộn..trong nửa chặng đường hoặc giữa các lần chạy nước rút .. các nhà phát triển tìm thấy sự phụ thuộc không được giải quyết, các yêu cầu hoặc câu chuyện chưa được kể lại ..... Điều này là một trong những Lạm dụng trong hầu hết các dự án nhanh nhẹn.
3. Kiểm tra: TTD .. vâng, nó rất tốt .. nhưng tôi đã thấy hầu hết các dự án Agile hoàn toàn dựa vào TTD ... không có phạm vi hoặc thời gian nào cho phép thử nghiệm theo chức năng hoặc con người .. Một lạm dụng khác ... Rất nhiều Scrum Master cũng không biết hoặc hiểu tầm quan trọng của kiểm tra chức năng. Đoạn mã của bạn có thể hoạt động hoàn hảo, nếu không phục vụ nhu cầu kinh doanh .. nó không có tác dụng .. Điều này xảy ra khi doanh nghiệp không tham gia tốt trước .. hoặc tham gia ở đó ... nhưng không phản ánh việc ra quyết định kinh doanh Cuối cùng, các nhà phát triển bị đổ lỗi, bạn đã không cung cấp chức năng..hoặc nó sẽ kết thúc với thay đổi vào phút cuối ... thêm một giờ nữa vì chủ Scrum của bạn không muốn đổ lỗi cho câu chuyện chưa hoàn thành.

Lạm dụng ở đây ... hoặc sự tham gia thấp của doanh nghiệp hoặc người tham gia không hiểu biết đầy đủ hoặc người kinh doanh bỏ học giữa chừng nước rút.

1. Không phải tất cả các dự án đều phù hợp với Agile ... Hầu hết các nhà quản lý hoặc thạc sĩ scrum đều không biết điều này .. Các dự án bảo trì .. Một lỗi có thể được giả định ban đầu có thể được thực hiện trong 8 giờ, được chấp nhận trong giai đoạn nước rút. Sau khi dành 4 giờ, nhận thấy đây là Java / một sản phẩm khác ... (Gần đây tôi đã gặp phải lỗi xử lý liên quan đến Quartz Lập lịch .. bên trong dự án của chúng tôi) và lỗi này có thể dẫn đến việc nâng cấp sản phẩm / gói..theo sự quan tâm, phê duyệt, tài trợ, phiên bản mới hoặc nâng cấp phải được phê duyệt bởi Kỹ thuật nội bộ, v.v., 5.Retrospection: chỉ một số ít các dự án Agile thực hiện bước này .. Nếu hoàn thành tất cả..Quản lý, Scrum Master không bao giờ chịu trách nhiệm về những câu chuyện thất bại ..
2. Ghép nối .. Rất nhiều nhà phát triển coi việc ghép đôi là địa điểm để lạm dụng đồng nghiệp .. chỉ trích thiết kế khác, thực hành mã hóa .. người coi là làm việc theo nhóm., Học hỏi lẫn nhau ... Một cách khác để lạm dụng Agile / Scrum.

Agile chắc chắn là phương pháp tốt .. Trừ khi tổ chức của bạn không tuân thủ hoàn toàn hoặc không được đào tạo .... Nó bị lạm dụng .... tác dụng phụ 60+ giờ làm việc / tuần, trò chơi đổ lỗi, đạo đức thấp.

Agile là quản lý vi mô trong ngụy trang. Không có chỗ cho sự chủ động hay sáng tạo trong Agile, nó đã loại bỏ niềm vui khỏi lập trình để cho phép các nhà quản lý không đủ năng lực kiểm soát ngay cả khi không có manh mối từ quan điểm kỹ thuật.