Có một sự thay thế khả thi cho phương pháp phát triển nhanh không?

Hai phương pháp phát triển phần mềm chiếm ưu thế là thác nước và nhanh nhẹn. Khi thảo luận về hai điều này, thường tập trung nhiều vào các thực tiễn cụ thể để phân biệt chúng (lập trình cặp, TDD, v.v. so với thông số chức năng, thiết kế phía trước lớn, v.v.)

Nhưng sự khác biệt thực sự sâu sắc hơn nhiều, trong đó những thực tiễn này đến từ một triết lý.

Waterfall nói: Thay đổi là tốn kém, vì vậy nó cần được giảm thiểu.
Agile nói: Thay đổi là không thể tránh khỏi, vì vậy hãy thay đổi giá rẻ.

Câu hỏi của tôi là, bất kể bạn nghĩ gì về TDD hoặc thông số chức năng, liệu phương pháp phát triển thác nước có thực sự khả thi?

Có ai thực sự nghĩ rằng giảm thiểu thay đổi trong phần mềm là một lựa chọn khả thi cho những người mong muốn cung cấp phần mềm có giá trị? Hay là câu hỏi thực sự về loại thực hành nào hoạt động tốt nhất trong các tình huống của chúng ta để quản lý sự thay đổi không thể tránh khỏi?

Tất nhiên thác nước là khả thi. Nó đưa chúng ta đến mặt trăng!

Và đó là một huấn luyện viên nhanh nhẹn nói chuyện ở đây!

Trừ khi bạn có thể xác định rõ các vấn đề liên quan đến cách bạn quản lý dự án của mình, không có lý do hợp lệ để thay đổi.

Thay thế cho phương pháp Agile và Waterfall , tôi sẽ đề xuất phương pháp của BẠN . Thích nghi với doanh nghiệp cụ thể của bạn, nhóm cụ thể của bạn, sản phẩm của bạn, cách làm việc, văn hóa công ty của bạn ... Đó là lý do Scrum được gọi là một khung đơn giản thay vì phương pháp luận.

Muốn thực hiện một phương pháp bởi vì ai đó trên blog mà bạn thích đã nói về nó cũng ngu ngốc như để cho các vấn đề xảy ra mà không làm gì cả.

Đầu tiên, tôi sẽ không đồng ý với tuyên bố của bạn:

Waterfall nói: Thay đổi là tốn kém, vì vậy nó cần được giảm thiểu.
Agile nói: Thay đổi là không thể tránh khỏi, vì vậy hãy thay đổi giá rẻ.

Giải thích của tôi là:

Waterfall nói: Khách hàng biết họ muốn gì.
Agile nói: Khách hàng không biết họ muốn gì nên chúng tôi sẽ phải tạo một vài phiên bản khác nhau.

Việc thực hiện tốt nhất "thác nước" mà tôi từng thấy là một dự án tích hợp lớn với một khách hàng tài chính rất lớn và có khoảng hơn 40 dự án phụ tham gia. Gói máy tính để bàn và trang web chúng tôi cung cấp chỉ là 1 trong số hơn 40 dự án con. Trong khi tôi nghĩ rằng họ đã thổi qua tiền của người khác khá nhiều, họ đã có những thứ của họ với nhau và giữ hơn 40 tàu khác nhau di chuyển cùng nhau trong đội hình. Dự án đã đi vào ngày đích (mục tiêu đã được di chuyển một lần trong suốt dự án) và trong khi tôi nghĩ rằng họ có thể thực hiện nó một cách tiết kiệm và nhanh nhẹn hơn, nó đã được thực hiện đúng thời gian và theo thông số kỹ thuật. Lịch trình của đêm diễn trực tiếp dài khoảng 100 trang và khoảng 40 trong số đó là chi tiết liên lạc hoảng loạn khẩn cấp của tất cả các loại người liên quan. Tôi đã rất ấn tượng bởi khách hàng này.

Hoặc, bạn có thể làm những gì chúng tôi làm, chạy xung quanh và làm những gì báo cáo khiếu nại / lỗi gần đây nhất và gọi đó là nhanh nhẹn.

Bạn bắt đầu bằng cách nói:

Hai triết lý phát triển phần mềm chiếm ưu thế là thác nước và nhanh nhẹn.

Điều này là sai. Sự phân đôi này đã được xây dựng bởi cộng đồng nhanh nhẹn để tạo ra một đối thủ để chống lại chính họ. Trước khi nhanh nhẹn thịnh hành, mọi người thường nói về vô số cách tiếp cận khác nhau để xây dựng phần mềm. Chúng vẫn tồn tại cho đến ngày nay, nhưng bằng cách nào đó, chúng thường bị gộp lại thành một mớ hỗn độn lớn gọi là "thác nước" bởi những người đề xướng nhanh nhẹn.

Tôi đã sử dụng OPEN / Metis và các biến thể của nó trong hơn 10 năm với thành công lớn. Nó chắc chắn không nhanh nhẹn, và chắc chắn không phải thác nước. Hàng ngàn nhà phát triển tạo ra phần mềm cực kỳ phức tạp cho máy bay, hệ thống quan trọng trong cuộc sống, ngân hàng, v.v ... bằng cách sử dụng các phương pháp không nhanh nhẹn mỗi ngày.

Vì vậy, có, tất nhiên có một sự thay thế khả thi cho nhanh nhẹn.

Có, các kỹ thuật phát triển phần mềm khác nhau đều khả thi tùy thuộc vào miền vấn đề của bạn. Đó là "Ngựa cho các khóa học".

Ví dụ: bạn đang viết phần mềm để điều khiển nhà máy điện hạt nhân hoặc lái tàu con thoi của NASA. Loại miền vấn đề này có lẽ phù hợp hơn với cách tiếp cận thác nước (hoặc thậm chí chặt chẽ hơn), bạn muốn sắp xếp tất cả các vấn đề lên phía trước nếu có thể (hoặc BÙM!).

Xây dựng giao diện người dùng tiếp thị web 2.0 / 3.0 / buzzy mới nhất? Agile là một cách tốt hơn để đi (yo cần phản hồi nhanh chóng và thay đổi).

Có những gì tôi sẽ gọi là các nguyên tắc thủ công phần mềm vẫn có thể được áp dụng cho dù phương pháp là gì:

• Kiểm soát nguồn
• xây dựng và CI
• lập trình cặp
• TDD
• Tôi cho ^% $$ &

và nhiều hơn nữa.

Dù bạn làm gì, đừng lắng nghe những người quá khích ở hai bên của phương trình, hãy làm những gì phù hợp với bạn, nhóm của bạn và miền vấn đề của bạn.

Vấn đề bắt nguồn từ sự phức tạp của phần mềm. Thác nước hoạt động tuyệt vời cho những thứ như xây dựng cầu và lát đường vì vật lý không bao giờ thay đổi. Chắc chắn, đến một lúc nào đó chúng ta sẽ phát triển một loại nhựa đường mới nhưng nó sẽ không cách mạng hóa cách xây dựng đường. Thép trong hệ thống treo của cây cầu có kích thước phù hợp hoặc không. Bạn không thể loại bỏ hoặc sơ khai một dự án xây dựng thực sự như bạn có thể với phần mềm.

Phần mềm thay đổi. Phần mềm thay đổi nhanh chóng. Định luật Moore cho biết số lượng bóng bán dẫn trên chip tăng gấp đôi cứ sau 18-24 tháng. Trong hệ quả, số lượng dòng mã trong một chương trình cũng tăng gấp đôi. Do đó, độ phức tạp ở giữa các dòng mã đó tăng lên với một lượng lớn thứ gì đó như 2 ^ (2t).

Phần mềm thay đổi nhanh chóng và độ phức tạp tăng theo cấp số nhân với nó.

Khi kiểm soát chi phí của phần mềm, bạn muốn kiểm soát các yếu tố theo cấp số nhân, không chỉ là nhân hoặc cộng. Thay đổi mã làm tăng độ phức tạp (và trở nên phức tạp hơn theo cấp số nhân khi dự án tiếp tục) theo cách theo cấp số nhân.

Thay đổi là không thể tránh khỏi. Bản chất của lập trình mở rộng ngôn ngữ với các lớp và phương thức tùy chỉnh, do đó thay đổi chính ngôn ngữ. Bạn không thể làm điều đó trong bất kỳ loại kỷ luật kỹ thuật nào khác (như xây dựng đường. Bạn không phát minh ra mặt đường mới chỉ để mở đường ở k Kansas trên california).

Phương thức nhanh cũng cung cấp cho bạn một nền tảng để xử lý các bản phát hành và sửa lỗi trong tương lai. Bạn luôn có các công cụ quản lý, quy trình, nhân viên được đào tạo để phát triển phần mềm phiên bản. Với phương pháp thác nước, bạn sẽ cần phải đào tạo lại nhóm của mình để xử lý ngay cả các sửa lỗi nhỏ.

Dù sao, 2 xu của tôi.

Để trả lời câu hỏi, có một sự thay thế khả thi, cho phần mềm có lẽ không - hoặc chưa, ít nhất là trong trường hợp chung. Tôi nghĩ rằng nó thuộc về bản chất của phần mềm. Phần mềm, là thông tin, có thể được nhân đôi miễn phí. Không giống như một cây cầu hoặc một ngôi nhà. Điều này có nghĩa, với thực tế, tôi có thể giỏi trong việc xây dựng một ngôi nhà và hoạt động trong một lĩnh vực tương đối đơn giản. Tại điểm nào tại sao không sử dụng phương pháp một lần bắn?

Nhưng vì phần mềm có chi phí nhân đôi bằng 0, tại sao bạn lại làm điều tương tự hai lần? Phần mềm có xu hướng tránh xa sản xuất. Vì vậy, nếu tất cả các phần mềm là tạo ra sản phẩm mới thì chúng ta luôn hoạt động trong một miền phức tạp, ở một chừng mực nào đó, chúng ta không biết mình đang làm gì. Hoặc tốn kém để biết trước và rẻ hơn để tìm hiểu bằng cách làm. Trong một miền phức tạp, đầy rủi ro, tôi muốn thử các thử nghiệm và tăng dần và lặp lại.

Các nhà máy điện hạt nhân và hệ thống dây bay thường được đưa ra làm ví dụ về phần mềm bạn muốn làm thác nước. Nhưng không phải hệ thống điện tử con thoi phát triển lặp đi lặp lại? Như hệ thống kiểm soát không lưu của Canada và Hoa Kỳ?

Và nếu OPEN / Metis lặp đi lặp lại và tăng dần thì đối với tôi, có vẻ như nó có triết lý nhanh nhẹn ngay cả khi nó không liên kết với các thực hành nhanh nhẹn thông thường khác.

Phương pháp Waterfall chắc chắn là khả thi và có vẻ triết lý như bất kỳ phương pháp nào khác. Hãy nhớ rằng Waterfall đã tồn tại lâu hơn Agile rất nhiều, nhưng lưu ý rằng đây không phải là một đối số để nói rõ liệu một phương pháp này có tốt hơn phương pháp khác hay không.

Bạn sử dụng phương pháp Waterfall khi hiểu rất rõ về toàn bộ miền vấn đề và những gì khách hàng muốn đạt được trong gói phần mềm. Bạn có thể đã trích dẫn một mức giá cố định khi thực hiện hợp đồng và khách hàng của bạn hiểu rằng họ không thể đi chệch khỏi bất kỳ yêu cầu đã thỏa thuận nào. Quá trình của bạn hoàn toàn là một quy trình chuyển qua một loạt các lần đăng nhập giữa các giai đoạn phát triển khác nhau và thường là mỗi giai đoạn được hoàn thành bởi một nhóm khác nhau - đôi khi thậm chí là một công ty khác nhau - mỗi công ty có thể không nhất thiết phải ở liên lạc với những người khác. Bạn thường thấy Thác nước được áp dụng để có hiệu quả tốt trong các dự án quân sự và chính phủ khi chúng được đấu thầu cho các nhà thầu bên ngoài. Trường hợp Waterfall và các phương pháp tương tự khác bị mang tiếng xấu là khi các nhà phát triển gặp vấn đề, chẳng hạn như ước tính kém, lịch trình được lên kế hoạch mà không có thời gian dự phòng hoặc hiểu biết kém hoặc không đầy đủ về miền vấn đề. Vấn đề không bao giờ thực sự là một lỗi của phương pháp, nhưng trong việc áp dụng nó.

Sự so sánh giữa Agile và bất kỳ phương pháp nào là sai. Agile không phải là một phương pháp, đó là một triết lý, hoặc có lẽ sẽ tốt hơn khi nói rằng đó là một thuật ngữ ô đại diện cho một cách khác để xem xét cách bạn phát triển phần mềm. Một phương pháp chỉ đơn thuần là một công cụ và như vậy giá trị của nó sẽ luôn nhỏ hơn các cá nhân và tương tác là trung tâm của ý nghĩa của Agile .

Có ai thực sự nghĩ rằng giảm thiểu thay đổi trong phần mềm là một lựa chọn khả thi cho những người mong muốn cung cấp phần mềm có giá trị?

Mọi cơ hội để giảm thiểu thay đổi đều có giá trị cho cả nhà phát triển và khách hàng. Các thay đổi có thể khiến lịch biểu bị trượt hoặc các tính năng bị bỏ qua để đáp ứng lịch biểu. Đó là cách bạn quản lý các tác động của thay đổi ảnh hưởng đến giá trị của các dự án của bạn.

Hay là câu hỏi thực sự về loại thực hành nào hoạt động tốt nhất trong các tình huống của chúng ta để quản lý sự thay đổi không thể tránh khỏi?

Thực tiễn của bạn có thể hỗ trợ trong việc quản lý thay đổi hoặc họ có thể bỏ qua thay đổi hoàn toàn. Vấn đề là sự kết hợp giữa thực tiễn phát triển của bạn và quản lý mối quan hệ của bạn với khách hàng và liệu những điều này có phối hợp hiệu quả với tất cả các bên liên quan hay không.

Những người trong chúng ta, những người vì tất cả ý định và mục đích Agile hiểu rằng bạn chọn một phương pháp phù hợp với mình. Nếu bạn thích cách tiếp cận cụ thể, hãy làm theo nó. Nếu nó không phù hợp với nhu cầu của bạn, hãy thay đổi nó. Cách bạn tạo ra phần mềm chế tạo thực sự bắt nguồn từ việc cố gắng tận dụng tốt nhất các tài nguyên bạn có trong tay và giảm thiểu những thực tiễn có thể dẫn dự án của bạn đến thất bại, và bạn thường thấy rằng bạn cần thay đổi phương pháp của mình cho phù hợp với dự án cụ thể trong tầm tay.

Đó thực sự là một điều để nói "Ok, vậy bây giờ chúng ta là Agile", và hoàn toàn khác để thực sự sống và làm việc theo triết lý mà Agile đang có. Cho dù bạn sử dụng Waterfall, Tăng dần, Xoắn ốc, SCRUM, XP, FDD hoặc bất kỳ phương pháp nào khác, về cơ bản bạn đều Agile nơi bạn coi trọng:

• Các cá nhân và tương tác qua các quy trình và công cụ
• Phần mềm làm việc trên tài liệu toàn diện
• Hợp tác khách hàng qua đàm phán hợp đồng
• Đáp ứng để thay đổi theo kế hoạch

và nơi bạn mang các công cụ, phương pháp và kinh nghiệm của bạn cùng nhau để áp dụng các giá trị này thành công.

Đúng, Waterfall, xoắn ốc, lặp đi lặp lại và các mô hình quá trình lai khác đều khả thi, nhưng thay đổi là không thể tránh khỏi. Quá trình không chỉ là về cách xử lý sự thay đổi và (tôi khẳng định rằng) yếu tố quyết định lớn nhất là bạn hiểu / hiểu vấn đề như thế nào và bạn có thể lập kế hoạch và dự đoán chính xác như thế nào.

Nói rằng "hai phương pháp phát triển phần mềm chiếm ưu thế là thác nước và nhanh nhẹn" là không phù hợp, vì có một loạt các quy trình phát triển phần mềm và nhiều công ty tổng hợp phiên bản mô hình quy trình của riêng họ, thường thay đổi cho một dự án nhất định. Có nhiều hơn hai cách tiếp cận khả thi để phát triển phần mềm. Mặc dù Waterfall và Agile có xu hướng rơi vào hai đầu đối diện của phổ "thay đổi", nhưng thật hợp lý khi đánh dấu các phương pháp cạnh tranh này như,

Waterfall nói: Thay đổi là tốn kém, vì vậy nó cần được giảm thiểu.

Agile nói: Thay đổi là không thể tránh khỏi, vì vậy hãy thay đổi giá rẻ.

Nhưng đó không phải là toàn bộ câu chuyện. Doanh nghiệp cần có khả năng lập kế hoạch và dự đoán, nhưng phần mềm là một quá trình sáng tạo và ước tính thường sai. Ghi nhớ tam giác tốt - nhanh - rẻ? Thêm một chiều thứ tư, quy trình và bạn thấy rằng việc giảm nỗ lực quá trình cũng có thể nén lịch biểu, khi các ước tính hóa ra là sai và một dự án có nguy cơ bị trì hoãn. Phần mềm là một quá trình có thể thay đổi (có thể thay đổi) và Agile, Lặp lại, Xoắn ốc đều cung cấp khả năng cung cấp chức năng gia tăng trong các khoảng thời gian ngắn hơn.

Thác nước và các mô hình quy trình theo yêu cầu khác có các điều khiển để xử lý thay đổi, do đó không chính xác khi nói Thác giảm thiểu thay đổi, chính xác hơn là nói Thác nhận ra và quản lý thay đổi và truyền đạt tác động của thay đổi đó (vì thay đổi gây ra tác động theo lịch trình khi bạn có yêu cầu và thiết kế lên phía trước). Khi bạn đang xây dựng một sản phẩm, hoặc có nhu cầu xác định đầy đủ các yêu cầu (chức năng), bạn được hướng đến một trong các mô hình lai.

Và khi ước tính sai, thường xử lý (chân thứ tư của tam giác sắt) được hy sinh để đáp ứng lịch trình.

Nhanh nhẹn trưởng thành và cách tiếp cận thác nước không thể phân biệt với nhau. Giả định của bạn về mục tiêu của phương pháp thác nước là không chính xác. Cả hai đều có mục tiêu sản xuất phần mềm chất lượng. Khi bạn không có một phương pháp phát triển vững chắc cho toàn bộ công ty , bạn cần xem xét cách tiếp cận nào sẽ cung cấp ít ma sát nhất cho việc áp dụng. Trong các chu kỳ phát triển ngắn, một nhóm QA vững chắc và một doanh nghiệp thúc đẩy sự phát triển là điều quan trọng nhất để sản xuất phần mềm đỉnh cao.