Phương pháp nhanh là gì? [đóng cửa]

Có ai có thể giải thích về phương pháp nhanh trong các câu đơn giản không?

Agile là rất nhiều thứ và thực hành, nhưng tôi nghĩ cốt lõi của nó chỉ là sự phát triển lặp đi lặp lại.

Lặp đi lặp lại: Hãy nghĩ về một loạt các thác nước rất nhỏ. Đó là, phương pháp thác nước (yêu cầu-> spec-> mã-> kiểm tra), nhưng thay vì thực hiện trong suốt một năm hoặc lâu hơn, bạn thực hiện nó trong suốt một vài tuần để có thể quản lý toàn bộ tổng thể dự án. Khi kết thúc 'lặp lại / chạy nước rút / gia tăng', bạn có một bộ chức năng bổ sung nhỏ nhưng đầy đủ và đã được thử nghiệm.

Điều này cho phép bạn nhanh chóng thay đổi tiến trình của dự án nếu nó chỉ ra rằng những gì bạn đang làm không phải là những gì khách hàng muốn, hoặc doanh nghiệp cần thay đổi, hoặc bất cứ điều gì. Do đó thuật ngữ "nhanh nhẹn."

Tôi nghĩ không có gì đặt nó tốt hơn Bản 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 đó.
Thông qua công việc này, chúng tôi đã đạt được giá trị:

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 của khách hàng trong đàm phán hợp đồng
Đáp ứng thay đổi theo kế hoạch

Đó là, trong khi có giá trị trong các mục ở
bên phải, chúng tôi đánh giá các mục ở bên trái nhiều hơn.

từ http://agilemanifesto.org/

Đối với tôi ý tưởng quan trọng nhất là đây:

Những thay đổi về yêu cầu sẽ xảy ra bởi vì chúng tôi buộc phải thiết kế phần mềm theo kiến ​​thức về những gì cần thiết (bắt đầu dự án) và các yêu cầu sẽ chỉ trở nên rõ ràng hơn trong suốt quá trình của dự án.

Các cách tiếp cận truyền thống (Waterfall) cố gắng giảm thiểu sự thay đổi này bằng cách khóa tất cả mọi người vào một hợp đồng khi bắt đầu dự án bằng cách cho họ ký vào các thông số kỹ thuật toàn diện. Điều này có thể hoạt động như một CYA, nhưng nó không làm cho bất cứ ai hài lòng khi cung cấp thứ gì đó không đáp ứng nhu cầu của người dùng, đặc biệt nếu sự phản đối của họ được đáp ứng với "Vâng, bạn đã đăng xuất trên đó!"

Phương pháp Agile được thiết kế để nắm lấy những thay đổi không thể tránh khỏi thay vì che chắn cho nhóm phát triển khỏi chúng. Nó thực hiện điều này theo một số cách, chủ yếu trong số đó là sự phát triển lặp lại và sự tham gia liên tục của các bên liên quan trong quá trình này. Theo kinh nghiệm của tôi, cuối cùng mọi người đều vui vẻ hơn, mặc dù điều đó có thể gây khó chịu hơn cho một số loại quản lý là những người lập kế hoạch khó tính.

Trong một câu này trông như thế này:

Phát triển phần mềm Agile là một nhóm các phương pháp phát triển phần mềm dựa trên sự phát triển lặp lại và tăng dần , 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 .

Điều này đến từ định nghĩa wikipedia, và tôi rất thích nó. Tôi nhấn mạnh các nguyên tắc cốt lõi.

Tôi cũng muốn thêm vào những gì Agile KHÔNG. Có rất nhiều cửa hàng ngoài kia tự nhận là Agile nhưng theo cách đó chỉ có nghĩa là họ không quan tâm đến việc lập kế hoạch cho dự án của họ và mong đợi mọi thứ được thực hiện trong một khoảng thời gian ngắn vô lý.

Agile! = Không có kế hoạch dự án. Thật khó để xử lý những người mặc nhiên nghĩ rằng tuyên bố đó là sai bởi vì họ có xu hướng là loại quản lý và không phải lúc nào cũng dễ mâu thuẫn.

Andy đã liên kết với Tuyên ngôn Agile, mà tôi nghĩ chỉ là về nó.

Tôi nghĩ thật hữu ích khi nhìn vào Bản tuyên ngôn Agile đến từ đâu. Có một số phương pháp luận có một số yếu tố phổ biến và nhiều động lực tương tự: Lập trình cực đoan (XP), Scrum, DSDM, Phát triển phần mềm thích ứng, Pha lê, Phát triển dựa trên tính năng, Lập trình thực dụng (danh sách từ Alistair Cockburn ). Những người đề xuất các phương pháp đó đã quyết định đưa ra một thuật ngữ tiếp thị để đề cập đến những điều họ có chung để lực lượng của những gì họ nói sẽ được tăng cường.

Thật thú vị (theo những gì ai đó nói với tôi) có một số tên trong danh sách rút gọn có thể được chọn thay vì "Agile" - một trong số đó là "Thích nghi". Cá nhân tôi nghĩ rằng như một từ duy nhất tổng hợp tốt hơn những gì nhanh nhẹn thực sự là tốt hơn "nhanh nhẹn"!

Sử dụng một phương pháp nhanh nhẹn để nhấn mạnh việc cung cấp các sản phẩm chất lượng hơn các khía cạnh khác của phát triển sản phẩm và nhận ra rằng phản hồi từ cộng đồng người dùng là một phần quan trọng trong việc tạo ra các sản phẩm chất lượng.

Ngược lại với cách tiếp cận phát triển truyền thống / thác nước nhấn mạnh vào thiết kế, tài liệu và định nghĩa giao diện phía trước trong khi nhấn mạnh việc thực hiện và chuyển sản phẩm từ phát triển sang phát hành.

Theo ý kiến ​​của tôi, có một chất lượng nội tại mà một nhóm có thể xây dựng thành một sản phẩm, tôi thấy điều này có hình thức xác minh rằng một sản phẩm hoạt động như nhóm phát triển dự định và có thể đáp ứng một cách hợp lý các cải tiến có thể thấy trước. Ngoài ra còn có các yếu tố chất lượng hoàn toàn dựa trên nhận thức đo lường mức độ sản phẩm đáp ứng nhu cầu của người dùng.

Các cách tiếp cận Agile có xu hướng phân phối các sản phẩm lặp đi lặp lại , kết hợp phản hồi của người dùng và phản hồi của nhà phát triển vào mỗi lần lặp và thúc đẩy việc cung cấp từng mức tăng chức năng khi nó đạt được khả năng tồn tại tối thiểu như là một chức năng buộc phải khơi gợi phản hồi của người dùng thường xuyên và chống lại xu hướng của các hoạt động phát triển. kéo dài thời gian mà không có phản hồi từ người dùng của nó. Theo tôi, các khía cạnh khác của cách tiếp cận nhanh có xu hướng hỗ trợ các nguyên lý chính này.

• Nhấn mạnh sự hợp tác của khách hàng thường xuyên tạo ra phản hồi của người dùng trong khi vẫn linh hoạt với các thay đổi trong yêu cầu cho phép phát triển sản phẩm thường xuyên tích hợp phản hồi đó
• Việc tích hợp thường xuyên vào các cấu hình và môi trường triển khai có liên quan đi đôi với việc xác định liên tục cấu hình và môi trường nào vẫn phù hợp để đảm bảo rằng sản phẩm vẫn có giá trị và phù hợp với người dùng cung cấp phản hồi
• Các nhóm tự tổ chức và thúc đẩy các nhóm chức năng chéo nói lên việc tạo ra trách nhiệm cá nhân trong nhóm và trao quyền cho nhóm để xác định cách tốt nhất để loại bỏ các rào cản một cách hiệu quả mà không bị giữ lại bởi các vai trò được phân bổ và phân cấp quản lý trong nhóm