Có sự thay thế chính nào cho Thác nước và Agile không? [đóng cửa]


35

Tôi tò mò liệu có ai biết bất kỳ phương pháp nào khác biệt đáng kể (không phải là tái hợp) và tôi đặc biệt đánh giá cao bất kỳ ai đưa ra bất kỳ kinh nghiệm nào với các lựa chọn thay thế.

Câu trả lời:


47

Wikipedia liệt kê những điều này như các phương pháp / quy trình phát triển :

  • Agile - dựa trên sự phát triển lặp lại và gia tăng, trong đó các yêu cầu và giải pháp phát triển thông qua sự hợp tác giữa các nhóm tự tổ chức, đa chức năng.

  • Phòng sạch - trọng tâm của quy trình Phòng sạch là phòng ngừa khuyết tật, thay vì loại bỏ khuyết tật.

  • Lặp đi lặp lại - một quy trình phát triển phần mềm theo chu kỳ được phát triển để đáp ứng với những điểm yếu của mô hình thác nước. Nó bắt đầu với một kế hoạch ban đầu và kết thúc bằng việc triển khai với các tương tác tuần hoàn ở giữa.
    sơ đồ lặp

  • RAD - sử dụng kế hoạch tối thiểu có lợi cho việc tạo mẫu nhanh. Việc "lập kế hoạch" cho phần mềm được phát triển bằng RAD được xen kẽ với việc tự viết phần mềm.

  • RUP - Quy trình hợp nhất Rational (RUP) là một khung quy trình phát triển phần mềm lặp có thể thích ứng, dự định được điều chỉnh bằng cách chọn các yếu tố của quy trình phù hợp.

  • Xoắn ốc - kết hợp các yếu tố của cả thiết kế và tạo mẫu trong các giai đoạn, trong nỗ lực kết hợp các lợi thế của các khái niệm từ trên xuống và từ dưới lên. Mô hình phát triển này kết hợp các tính năng của mô hình tạo mẫu và mô hình thác nước.
    sơ đồ mô hình xoắn ốc

  • Thác nước - tuần tự qua các giai đoạn của khái niệm, khởi tạo, phân tích, thiết kế, xây dựng, thử nghiệm và bảo trì.
    sơ đồ thác nước

  • Lean - bản dịch của Lean sản xuất và các nguyên tắc và thực hành Lean IT cho lĩnh vực phát triển phần mềm; tất cả mọi thứ không thêm giá trị cho khách hàng được coi là lãng phí.

  • Mô hình V - Thay vì di chuyển xuống theo cách tuyến tính, các bước của quy trình được uốn cong lên sau giai đoạn mã hóa, để tạo thành hình chữ V điển hình. Mô hình V thể hiện mối quan hệ giữa từng giai đoạn của vòng đời phát triển và giai đoạn thử nghiệm liên quan của nó.
    sơ đồ mô hình v

  • TDD - dựa vào sự lặp lại của một chu kỳ phát triển rất ngắn: đầu tiên nhà phát triển viết một trường hợp thử nghiệm tự động không xác định một cải tiến mong muốn hoặc chức năng mới, sau đó tạo mã để vượt qua thử nghiệm đó và cuối cùng tái cấu trúc mã mới theo các tiêu chuẩn chấp nhận được.


Cảm ơn bạn cho một câu trả lời rõ ràng, súc tích. Tôi rất già đi học, tôi chưa bao giờ nghe nhiều điều khoản được ném xung quanh trên P.SE.
Michael Riley - AKA Gunny

7
Danh sách tuyệt vời, ngoại trừ TDD. Đó không phải là một vòng đời mà là một thực tiễn phát triển.
Michael

18

Mã hóa cao bồi

Tinh khiết không cấu trúc, không được quản lý, phát triển tự do. Nó có thể hữu ích cho các dự án sở thích nhỏ không có thời hạn hoặc thậm chí là mục tiêu rõ ràng, nhưng có khả năng sẽ không hoạt động trong môi trường công ty.


2
vâng bang Bang!
mlvljr

3
"có khả năng sẽ không làm việc trong môi trường công ty". Nói bạn ;)
Bobby Bảng

+1 Aaa, tuyệt! Đôi khi tôi làm điều đó, nhưng tôi không biết cách đặt tên cho "quy trình" này :)
Zzz

yeeee-haw padnah!
ybakos

Trong thiết lập chính thức của công ty trưởng thành đúng. Tuy nhiên, trong doanh nghiệp nhỏ có thể có khá nhiều tâm lý "Chỉ cần thực hiện".
JB King

4

Mô hình xoắn ốc

Mô hình xoắn ốc là một quá trình phát triển phần mềm kết hợp các yếu tố của cả giai đoạn thiết kế và tạo mẫu, trong nỗ lực kết hợp các lợi thế của các khái niệm từ trên xuống và từ dưới lên. Còn được gọi là mô hình vòng đời xoắn ốc (hay phát triển xoắn ốc), nó là một phương pháp phát triển hệ thống (SDM) được sử dụng trong công nghệ thông tin (CNTT). Mô hình phát triển này kết hợp các tính năng của mô hình tạo mẫu và mô hình thác nước. Mô hình xoắn ốc dành cho các dự án lớn, đắt tiền và phức tạp.

- Wikipedia văn bản thay thế


1

Kế hoạch

Ngồi xuống với khách hàng (hoặc người dùng cuối) và thiết kế một loạt các trường hợp sử dụng.

Thiết kế

Bố trí hệ thống trên giấy / bảng trắng trên một vài loại bia và pizza. Cười thầm khi một cái gì đó trông phallic.

Xác nhận

Xác nhận thiết kế với khách hàng (hoặc người dùng cuối) và yêu cầu đóng băng.

Tự giải thích.


"Yêu cầu đóng băng" là cách nói dễ nói lớn nhất từ ​​trước đến nay.
Justin Schier

1

Cuộc tranh luận về Thác nước này đã xuất hiện được một lúc và được các nhà lãnh đạo tư tưởng nhanh nhẹn sử dụng từ rất sớm. Họ cũng gặp phải "thực tế" của thác nước như một "báo động đỏ".

Khi bạn bắt đầu làm việc với một dự án phát triển phần mềm, bạn sẽ nhanh chóng phát hiện ra rằng phương pháp phát triển được sử dụng sẽ đóng vai trò chính trong tốc độ và chất lượng của mã được phát triển. Phương pháp Agile được sử dụng rộng rãi, điều quan trọng là bạn hiểu được những lợi thế và nhược điểm của nhanh nhẹn để bạn có thể xác định liệu nó có phù hợp nhất cho các sản phẩm dự án của bạn hay không.

Phát triển phần mềm Agile là một khung khái niệm để thực hiện các dự án kỹ thuật phần mềm. Các phương pháp nhanh nhất cố gắng giảm thiểu rủi ro bằng cách phát triển phần mềm trong các bảng thời gian ngắn, được gọi là lặp, thường kéo dài từ một đến bốn tuần. Mỗi lần lặp giống như một dự án phần mềm thu nhỏ của riêng nó, và bao gồm tất cả các nhiệm vụ cần thiết để giải phóng sự gia tăng nhỏ của chức năng mới: lập kế hoạch, phân tích yêu cầu, thiết kế, mã hóa, kiểm tra và tài liệu.

Đó là một quy trình tốt cho công ty vì nó bao gồm khách hàng trong quá trình phát triển và khiến công ty chịu trách nhiệm phân phối sản phẩm. Ở phía bên kia, khách hàng rất vui vì họ thấy họ tự tham gia vào việc phát triển sản phẩm.

Yêu cầu đối với Agile:

  • Agile quá tập trung vào lập trình viên, không rõ làm thế nào để cân bằng công việc giữa một tổ chức.
  • Nếu bạn không biết bạn đang đi đâu, Agile sẽ không đưa bạn đến đó!
  • Tạo khung mà không có nhu cầu rõ ràng.
  • Sử dụng quá mức các tính năng ngôn ngữ (không phù hợp).
  • Không có tâm lý thử nghiệm đầu tiên.

Vâng, đối với một phương pháp thú vị có thể hoạt động thay thế cho AGILE có thể được xem tốt nhất theo 3 liên kết sau:

Kanban là triển khai Agile thay thế

Phát triển phần mềm Kanban

Phát triển phần mềm tinh gọn trên đám mây


3
Nếu bạn không biết bạn đang đi đâu, thác nước sẽ không đưa bạn đến đó!
Eric Wilson
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.