Một số tình huống mà Agile không phù hợp là gì?

Question

Tôi đã nghe và đọc về Agile trong nhiều năm. Tôi sở hữu một hoặc hai cuốn sách trên đó và tôi thích ý tưởng đó.

Tôi cuối cùng ở một vị trí mà tôi có thể cuộn một cái gì đó như thế này ra nơi tôi làm việc, nhưng tôi có mối quan tâm nghiêm túc về việc cho dù đó là con đường để đi cho chúng ta:

• Không phải là có một kích thước tối thiểu cho điều này? Thiết kế lớn lên phía trước phải sẽ hiệu quả hơn cho dự án ba hoặc bốn tuần ... Phải không?
• Khách hàng của chúng tôi thường yêu cầu giá cố định. Họ cần phải biết họ đang xử lý những gì, ngoại trừ trong những trường hợp đặc biệt mà chúng tôi đang chống lại một lỗ đen rõ ràng và thậm chí sau đó mọi người cảm thấy thoải mái hơn với một chiếc mũ. Vì vậy, làm thế nào bạn có thể cung cấp một báo giá nếu bạn đang đi với một quá trình đó là khoan dung của những thay đổi yêu cầu đang diễn ra?
• Tôi hiểu rằng Agile có thể cung cấp tỷ lệ thành công tốt hơn trong các dự án phức tạp hơn, nhưng sẽ không làm tăng chi phí cho khách hàng? Và tất nhiên có chi phí thất bại để xem xét - có lẽ chúng tôi đang trở lại với câu hỏi kích thước tối thiểu ở đây.
• Làm cách nào để bạn giải thích cách tiếp cận phản trực giác này với khách hàng? Các bên liên quan không kỹ thuật có thể không có kinh nghiệm để quấn đầu của họ xung quanh bất cứ thứ gì ngoài thác nước.
• Ngay cả đối với các dự án nội bộ, có ngân sách. Tôi đang thiếu gì?
• Dường như có một số phản ứng dữ dội chống lại Agile gần đây. Có cái gì khác sẽ bắt đầu đạt được lực kéo sớm không?

Lưu ý: Chúng tôi là một cửa hàng 5 dev với các dự án khác nhau, từ một hoặc hai ngày cho đến vài tháng. Tôi không tin rằng có một phương pháp để thống trị tất cả, nhưng sẽ thật tuyệt vời khi tìm được thứ gì đó đủ linh hoạt để chúng ta có thể điều chỉnh nó cho tất cả các dự án của chúng ta.

Cảm ơn rất nhiều!

Brian MacKay

Answer 1

Tôi không nghĩ một phương pháp nào có thể loại trừ tất cả. Tôi xin lỗi. Tôi là một người tin tưởng vững chắc trong việc tìm ra mô hình phù hợp cho dự án đúng. Ví dụ như làm thế nào bạn sẽ cảm thấy nếu bạn đã được vào phẫu thuật và bạn biết máy mà đã giữ cho bạn sống được phát triển trong một chu kỳ lặp đi lặp lại nhanh chóng với thiết kế nhỏ trả trước.

Nhưng dù sao, về câu hỏi của bạn.Tôi là một người tin tưởng vào các cách tiếp cận nhanh nhẹn, giữ cho các lần lặp lại của bạn ngắn, tập trung vào những gì người dùng muốn và không xây dựng thiết giáp hạm mà chỉ xây dựng chính xác những gì bạn cần. Tôi có thể nói 95% của tất cả các dự án có thể sử dụng các phương pháp nhanh nhẹn, và nếu chúng không thể là vấn đề văn hóa, không phải là vấn đề dự án.

Bây giờ theo BDUF (Thiết kế lớn lên phía trước), chúng tôi đã thành công rực rỡ với nhóm 20 người trong dự án 4 tháng, chúng tôi đã thực hiện dự án chia nhỏ thành 3 chu kỳ 4 tuần, vào đầu mỗi chu kỳ tất cả chúng ta gặp nhau trong một căn phòng, và nói ok đây là những gì chúng ta cần xây dựng, đây là cách chúng ta sẽ xây dựng nó, và chúng ta đã đâm vào giao diện của chúng ta, dữ liệu nào chúng ta cần ... Nhưng nó chỉ là đâm, sau đó chúng tôi quay trở lại bàn làm việc của chúng tôi, và bất cứ ai sở hữu các phần khác nhau đã xóa sạch các chi tiết.

Về cơ bản, chúng tôi đã làm đủ BDUF trả trước để khởi động nhóm (Và đảm bảo chúng tôi đã đáp ứng tất cả các yêu cầu kinh doanh). Chúng tôi đã từng gọi những phiên này là Ngày nhà phát triển và đó là một cách hay để bắt đầu nhóm. Nếu bạn có tiền mặt đưa nhóm ra khỏi trang web, bạn có thể nhồi nhét chúng trong một phòng hội nghị tại một khách sạn cho chúng ăn nhiều rác và xem dòng nước chảy.

Answer 2

Nó phụ thuộc vào người bạn hỏi và liệu họ có tin vào nhanh nhẹn hay không ...

Đối với điều này:

Tôi muốn tìm một phương pháp để cai trị khu mua sắm.

http://www.opaquelucidity.com/facepalm.jpg

Có phải tất cả khách hàng của bạn giống nhau không? Bạn đã nói rằng thời lượng thay đổi rất nhiều ... Tại sao bạn cho rằng tất cả các cách thức của các dự án khác nhau sẽ phù hợp với một phương pháp duy nhất?

Answer 3

Tìm kiếm những gì làm cho thực hành Agile thất bại ... Nếu bạn có 1-2 trẻ vị thành niên điểm cho nó, bạn sẽ tìm cách để đi qua chúng. Khác, bạn đang tìm kiếm một thất bại. Và một khi bạn thất bại, bạn sẽ không có cơ hội khác để thử nó. Ngay cả khi đó không phải là thực hành Agile thất bại ...

Answer 4

Bắt đầu với các dự án nội bộ để có được một số kinh nghiệm về cách thức hoạt động của quy trình nhanh và cách bạn có thể ước tính tốt nhất thời gian cần thực hiện. Khi bạn cảm thấy rằng bạn đã sẵn sàng để tiếp nhận một khách hàng thực sự, hãy chọn một khách hàng mà bạn có nhiều niềm tin và chọn một dự án nhỏ hợp lý để bắt đầu. Chìa khóa ở đây là bạn muốn xây dựng sự tự tin. Giải thích những gì bạn đang làm và tại sao - bạn muốn cung cấp phần mềm tốt hơn cho họ phản ánh tốt hơn các ưu tiên của họ sớm hơn - và chỉ cho họ cách bạn đã thành công trên các dự án nội bộ của bạn. Cung cấp lời hứa của bạn - vì tôi tin vào các phương pháp nhanh nhẹn, tôi không nghĩ điều này sẽ quá khó để làm.

Sau khi bạn đã thành công (và làm cho khách hàng thất vọng), họ sẽ yêu cầu bạn sử dụng phương pháp trên các dự án khác của họ. Khi bạn có một khách hàng hài lòng, bạn có thể bắt đầu mở rộng cho người khác, sử dụng khách hàng đầu tiên của bạn làm tài liệu tham khảo. Khá sớm, bạn sẽ thấy rằng các thực hành bạn đang sử dụng hoạt động tốt đến mức chúng cũng leo vào các quá trình "thác nước" của bạn. Cuối cùng, bạn sẽ uống đủ lượng kool-aid để giống như những người còn lại trong chúng ta. :-)

Ồ. Và có, có những dự án không đặc biệt phù hợp với các phương thức nhanh nhẹn. Những thứ như các hệ thống quan trọng trong cuộc sống, kiểm soát nhà máy điện hạt nhân, các ngành công nghiệp được quản lý cao có thể đòi hỏi nhiều thiết kế và quy trình phía trước nhanh hơn cho phép. Hầu hết chúng ta không bao giờ làm việc trên các dự án này.

Answer 5

Nếu bạn không thể mua được từ các bên liên quan; nếu tổ chức của bạn yêu cầu một số phương pháp và nhà phát triển khác được đánh giá bằng kỹ thuật chứ không phải là thành công; nếu không có đủ thời gian hoặc tiền bạc; thì không thích hợp.

Câu hỏi đặt ra là, phương pháp nào khác sẽ làm tốt hơn trong những trường hợp đó.

Answer 6

các giải pháp đơn giản có 2 bước sau:

1. không ước tính chi phí và lịch trình cho các dự án, chi phí ước tính và lịch trình cho tính năng
2. đo lường và ghi đầy đủ thông tin để tính toán vận tốc và ước tính của bạn lỗi

bắt đầu nhỏ và trong nhà nếu có thể để nhận một số số cơ sở. Nếu bạn vẫn muốn làm 'lớn lên phía trước thiết kế', làm điều đó cho các tính năng cá nhân. Điều này sẽ giúp các ước tính ban đầu của bạn chính xác hơn và cũng có mức độ chi tiết của 'tính năng' mà bạn cảm thấy thoải mái.

Lưu ý: này sẽ chỉ làm việc nếu khách hàng cam kết làm một phần của họ, cụ thể là, để được đánh giá cao dành cho các nhà phát triển (để trả lời câu hỏi, viết truyện và giới thiệu thử nghiệm, et al), và để không thay đổi ý định của họ trong khi lặp lại

chúc bạn may mắn với quá trình chuyển đổi của mình và cho chúng tôi biết cách thực hiện!

Answer 7

Cho đến nay, chống chỉ định lớn nhất mà tôi đã thấy là một giá trị không phù hợp. Lập trình cực đoan dựa trên sự tôn trọng, giao tiếp, phản hồi, can đảm và đơn giản. Trong một tổ chức hoạt động dựa trên các giá trị không tương thích, việc áp dụng XP sẽ gây ra ma sát và sẽ không dẫn đến thay đổi lâu dài (IME).

Answer 8

Scott Ambler là một cơ quan tốt cho an answer về điều này. Bài viết của anh ấy làm tốt công việc nêu bật một số cạm bẫy của giá cố định, nhưng nó chắc chắn có thể. Alistair Cockburn agrees cũng có thể, nhưng chỉ ra rằng một số lợi ích bạn nhận được từ nhanh nhẹn bị mất trong các hợp đồng giá cố định.

Một vấn đề cơ bản với "thiết kế lớn lên phía trước" (BDUF) là thời gian dành cho việc thiết kế chức năng hiếm khi được sử dụng. Nếu bạn cần phải có một sản phẩm hoàn thành trong một tháng hoặc ít hơn, vấn đề phải được thực sự xác định trước.

Đối với chi phí thất bại, đó là một mối quan tâm rất hợp pháp. Một lợi ích của Agile là bất kỳ thất bại nào xảy ra sớm hơn và với chi phí thấp hơn nhiều so với chúng trong một dự án theo phương pháp thác nước. Có thể học hỏi từ những thất bại đó và có được một sản phẩm tốt ở cuối không phải là một kết quả mà phương pháp thác nước có thể mang lại. Chính phủ liên bang có một số lượng lớn các thất bại cao trong các dự án phần mềm theo phương pháp thác nước và BDUF. Tôi đã blogged về lỗi dự án Tệp trường hợp ảo của FBI.

Phương pháp nào bạn sử dụng sẽ được xác định là phù hợp với nhóm của bạn như loại phần mềm bạn đang xây dựng và khách hàng của bạn. tvanfosson hoàn toàn đúng về các dự án không phù hợp với các phương thức nhanh. Tôi đồng ý với Kent Beck về các giá trị không phù hợp với ý tưởng. Một số tổ chức chưa sẵn sàng cho Agile từ góc độ văn hóa, bất kể thành tích và thành công của nó ở đâu khác.

Answer 9

Hãy để tôi giải đáp mối quan tâm của bạn point-by-điểm:

Không phải là có một kích thước tối thiểu cho việc này? Thiết kế lớn lên phía trước phải hơn hiệu quả cho dự án ba hoặc bốn tuần ... Phải không?

Tôi không chắc chắn điều gì khiến bạn nghĩ rằng vẽ hình chữ nhật trên giấy phải nhanh hơn mã refactoring.

Dù sao đi chăng nữa, câu hỏi liệu BDUF trả tiền có còn là chức năng của việc bạn học được bao nhiêu trong dự án hơn là kích thước dự án hay không. Bạn càng có thể mong đợi để tìm hiểu một cái gì đó về thiết kế, các yêu cầu, vv trong khi thực hiện hệ thống, thiết kế phía trước của bạn càng trở nên lãng phí.

Tôi chưa gặp phải một dự án mà tôi không học được những điều quan trọng trong khi triển khai hệ thống.

Khách hàng của chúng tôi thường yêu cầu giá cố định .Họ cần biết họ đang xử lý những gì , ngoại trừ trong trường hợp đặc biệt nơi chúng tôi chống lại một lỗ đen rõ ràng và thậm chí sau đó mọi người là thoải mái hơn với nắp. Vì vậy, làm thế nào bạn có thể cung cấp một báo giá nếu bạn đang đi với một quá trình là khoan dung của những thay đổi yêu cầu đang diễn ra?

Chỉ chấp nhận thay đổi yêu cầu không thay đổi toàn bộ nỗ lực. Đó là, khi yêu cầu mới đến, hãy thả những thứ ít quan trọng hơn. Hãy để khách hàng quyết định để anh ấy có thể nhận được nhiều lợi nhuận nhất.

Bạn sẽ không nhận được tất cả các lợi ích của Agile theo cách này, nhưng nó tốt như giá cố định có thể nhận được, theo như tôi có thể nói.

Tôi hiểu rằng Agile có thể cung cấp tỷ lệ thành công tốt hơn trong các dự án phức tạp hơn, nhưng sẽ không làm tăng chi phí cho khách hàng?

Bạn có gợi ý rằng các dự án chạy theo cách Agile tốn kém hơn các dự án truyền thống không? Có những công ty thực sự ở đó có kinh nghiệm ngược lại, giảm đến 50% chi phí.

Và tất nhiên có chi phí không xem xét - có lẽ chúng tôi quay lại câu hỏi kích thước tối thiểu tại đây.

Chi phí thất bại giảm xuống với dự án Agile, do phản hồi sớm. Bạn có thể nhận thấy sự thất bại - và do đó quyết định hủy dự án - sớm hơn nhiều.

Bạn sẽ giải thích cách tiếp cận phản trực giác này với khách hàng như thế nào? Các bên liên quan không kỹ thuật có thể không có kinh nghiệm để quấn đầu của họ xung quanh bất cứ điều gì ngoài thác nước.

Why does Agile Software Development pay?

Ngay cả đối với các dự án nội bộ, có ngân sách. Tôi đang thiếu gì?

Tôi không biết. Agile hoạt động tốt với ngân sách - triển khai các tính năng ưu tiên cao nhất cho đến khi ngân sách được sử dụng hết. Bạn có hệ thống có giá trị nhất có thể đã được triển khai cho số tiền đó.

Dường như có một số phản ứng dữ dội chống lại Agile gần đây. Có cái gì khác sẽ bắt đầu đạt được lực kéo sớm không?

Đã có phản ứng ngược với nó ngay từ đầu. Và khi nó trở nên phổ biến hơn (và nó là!), Nó chỉ là tự nhiên mà bạn cũng thấy phản ứng dữ dội hơn.

Phát triển phần mềm Lean đang thu hút rất nhiều lực kéo. Nó không phải là cạnh tranh để phát triển Agile, nhưng thay vì bổ sung, mặc dù. Các cộng đồng thực sự khá trùng lặp.

Về "một phương pháp để thống trị tất cả" - hãy xem gia đình "Tinh thể" của Agist của Alistair Cockburn trong quy trình Agile. Ông lập luận (khá thành thạo) rằng mọi dự án đều cần quy trình riêng của nó, và rằng ngay cả một quá trình của dự án cũng cần phải thay đổi trong quá trình của dự án.Và anh ấy cung cấp một khung làm việc nhẹ để phát triển quy trình của bạn.

Cũng như Scrum, như tôi nghĩ về nó. Scrum thực sự không nói cho bạn biết nhiều về cách chạy dự án của bạn, nhưng còn nhiều hơn nữa về cách tìm hiểu những gì đang hoạt động và cách cho phép nhóm thích ứng với những phát hiện đó.

Answer 10

Tôi khuyên bạn nên chống lại Agile khi phát triển hệ thống kiểm soát không lưu mới.

Answer 11

Tôi sẽ không nhất thiết sử dụng nhanh nhẹn cho dự án mà tất cả đều được biết trước. Agile hoạt động tốt khi thay đổi có khả năng cao. Trong trường hợp thay đổi không phải là likley, người ta có thể sử dụng quá trình tiên đoán hoặc thác nước để quản lý một dự án như vậy.

Trả lời các câu hỏi cụ thể của bạn theo: Không có kích thước tối thiểu cho điều này? Từ góc nhìn thực tế, Agile có kích thước độc lập. Có nói rằng, dự án càng lớn thì càng có nhiều khả năng xảy ra thay đổi. Nếu một dự án là nhỏ thì tất cả đều có thể biết được và thay đổi là không thể.

Thiết kế lớn lên phía trước phải hiệu quả hơn cho dự án ba hoặc bốn tuần ... Phải không? Thiết kế đơn giản và tiến hóa được điều khiển bởi TDD luôn hiệu quả hơn. Bạn chỉ nên có đủ kiến ​​trúc được dựng lên phía trước để biết mảnh chính rơi vào đâu. Không sử dụng kiến ​​trúc để đoán những gì bạn định làm, chỉ nắm bắt những gì có thể biết được. Hãy để thiết kế đơn giản và tiến hóa cho phép bạn phát triển thiết kế chi tiết của bạn khi bạn xây dựng ứng dụng.

Khách hàng của chúng tôi thường yêu cầu giá cố định. Họ cần phải biết họ đang xử lý những gì, ngoại trừ trong những trường hợp đặc biệt mà chúng tôi đang chống lại một lỗ đen rõ ràng và thậm chí sau đó mọi người cảm thấy thoải mái hơn với một chiếc mũ. Vì vậy, làm thế nào bạn có thể cung cấp một báo giá nếu bạn đang đi với một quá trình đó là khoan dung của những thay đổi yêu cầu đang diễn ra? Một số yêu cầu giáo dục ban đầu. Bạn sẽ thiết lập một sản phẩm tồn đọng, yêu cầu chủ sở hữu sản phẩm ưu tiên nó và sau đó thực hiện ước tính ban đầu của công việc. Điều này yêu cầu chủ sở hữu sản phẩm thiết lập một đường cắt trên backlog cho giá thầu cố định. Sau đó, bạn quy mô nhóm và thời gian để đáp ứng ước tính. Hợp đồng sau đó cho biết bạn sẽ sử dụng khả năng cố định của nhóm cho hộp thời gian được thiết lập. Điều này sẽ giữ cho chủ sở hữu sản phẩm tập trung vào timebox và ngân sách khi thực hiện các cuộc gọi ưu tiên trên backlog.

Tôi hiểu rằng Agile có thể cung cấp tỷ lệ thành công tốt hơn trong các dự án phức tạp hơn, nhưng sẽ không làm tăng chi phí cho khách hàng? Một dự án thành công luôn rẻ hơn một dự án không thành công.

Bạn sẽ giải thích cách tiếp cận phản trực giác này với khách hàng như thế nào? Các bên liên quan không kỹ thuật có thể không có kinh nghiệm để quấn đầu của họ xung quanh bất cứ điều gì ngoài thác nước. Giáo dục (ví dụ: trại khởi động nhanh) và truy cập các nhóm nhanh nhẹn thành công sẽ giúp ích rất nhiều. Sau đó, có được nhóm đi. Công việc sẽ khiến họ bận rộn và kết quả sẽ bán chúng.

Ngay cả đối với các dự án nội bộ, còn có ngân sách. Tôi đang thiếu gì? Dường như có một số phản ứng dữ dội chống lại Agile gần đây. Có cái gì khác sẽ bắt đầu đạt được lực kéo sớm không? Phản ứng dữ dội duy nhất mà tôi biết là các dự án nhanh nhẹn không sử dụng thực tiễn kỹ thuật hiệu quả (tức là, chỉ SCRUM). Một nhóm sử dụng SCRUM và XP effectivley sẽ làm rất tốt ở tốc độ giao hàng và bền vững.

Answer 12

Imho:

Nhanh nhẹn hay không, bạn nên thiết kế những gì được biết trước khi triển khai - trước khi "thử công cụ". Đệ quy phá vỡ mọi thứ thành các nhiệm vụ có thể quản lý, sau đó thiết kế những gì được biết, có thể là các chi tiết cực kỳ gớm ghiếc hay chỉ là các khái niệm rộng. Những thứ như giao diện người dùng và các yêu cầu kinh doanh hàng ngày hầu như không bao giờ được đặt trong đá trước khi phát triển, trong khi các tính năng mô phỏng máy bay có thể là.

Một cách để cố gắng "bán" nhanh nhẹn cho khách hàng là cấp cho họ hai tùy chọn: 1. Thác, nơi không có hủy miễn là chúng tôi (nhà phát triển) đáp ứng kết thúc thỏa thuận của chúng tôi. 2. Nhanh nhẹn, nơi bạn nhận được cập nhật hàng tuần về trạng thái, bản trình diễn thực hành khi chúng khả dụng và quyền ngừng dịch vụ 2 tuần một lần (trong trường hợp bạn không thích công việc của chúng tôi).