Phát triển phần mềm linh hoạt

Các phương pháp phát triển phần mềm khác nhau gia tăng từ năm 1957.^[1] Phương pháp Phát triển phần mềm linh hoạt được nhiều người chấp nhận, nó có một số nội dung sau:

Bản tuyên ngôn của Phát triển phần mềm linh hoạt

Trong tháng 2 năm 2001, 17 nhà phát triển phần mềm đã gặp nhau ở một khu nghỉ mát tại bang Utah để thảo luận phương pháp phát triển phần mềm. Họ đưa ra Bản tuyên ngôn sau cho Phát triển phần mềm linh hoạt:^[2]

• Cá nhân và sự tương tác hơn là quy trình và các công cụ
• Phần mềm chạy được hơn là tài liệu đầy đủ
• Hợp tác với khách hàng hơn là đàm phán dựa theo hợp đồng
• Đáp ứng với các thay đổi hơn là làm theo kế hoạch đã định

Mặc dù vế thứ hai có vai trò quan trọng, người ta đánh giá vế thứ nhất cao hơn để thành công.

Cá nhân và sự tương tác

Tự tổ chức và động lực rất quan trọng, cũng như sự tương tác để làm việc cùng vị trí và theo cặp lập trình.

Phần mềm có thể chạy được

Phần mềm chạy được sẽ hữu ích hơn hơn là chỉ trình bày tài liệu cho khách hàng xem ở cuộc họp.

Khách hàng hợp tác

Không thể thu thập tất cả yêu cầu của khách hàng vào giai đoạn đầu của chu kỳ phát triển phần mềm, do đó liên tục cộng tác để lấy thông tin từ khách hàng hoặc các bên tham gia là rất quan trọng.

Đáp ứng thay đổi

Phương pháp Linh hoạt tập trung vào việc phản ứng nhanh chóng với sự thay đổi và không ngừng phát triển.

Các nguyên tắc của Phát triển phần mềm linh hoạt

Phát triển phần mềm linh hoạt dựa trên mười hai nguyên tắc:^[3]

1. Sự hài lòng của khách hàng được đặt lên hàng đầu và liên tục chuyển giao phần mềm có giá trị cho họ
2. Chào mừng các yêu cầu thay đổi, ngay cả trong giai đoạn muộn của dự án
3. Phần mềm chạy được, được giao thường xuyên (hàng tuần chứ không nên là hàng tháng)
4. Người làm bên mảng kinh doanh và người phát triển phần mềm nên gần gũi, hợp tác hàng ngày
5. Dự án phần mềm được xây dựng bởi các cá nhân có động lực, những người đáng tin cậy
6. Mặt đối mặt khi nói chuyện là cách tốt nhất để liên lạc (làm việc cùng nơi)
7. Phần mềm chạy được là thước đo của tiến độ
8. Phát triển bền vững, có thể duy trì một tốc độ không đổi
9. Liên tục chú ý đến các kỹ thuật mới và thiết kế tốt
10. Đơn giản hóa - nghệ thuật của việc tối đa hóa số việc không cần phải làm - là điều cần thiết
11. Kiến trúc, yêu cầu và thiết kế tốt tạo nên nhóm tự tổ chức tốt
12. Thường xuyên phản ánh việc làm thế nào để nhóm làm việc hiệu quả hơn và điều chỉnh cho phù hợp

Có rất nhiều cụ thể phát triển nhanh phương pháp. Nhất đẩy mạnh tinh thần đồng đội, cộng tác, và khả năng thích ứng quá trình trong suốt các sản phẩm phát triển sự sống, chu kỳ.Có nhiều phương pháp phát triển phần mềm linh hoạt. Đa số các phương pháp này cố gắng cực tiểu hóa rủi ro bằng cách phát triển phần mềm trong các khung thời gian ngắn, gọi là các bước lặp, mỗi bước lặp thường trong khoảng từ 1 đến 4 tuần. Mỗi bước lặp tự nó giống như một dự án phần mềm thu nhỏ, bao gồm tất cả các tác vụ cần thiết để cho ra nâng cấp mi-ni của chức năng mới: lập kế hoạch, phân tích yêu cầu, thiết kế, viết mã, kiểm thử, và viết tài liệu. Tuy một bước lặp có thể không bổ sung đủ chức năng để đảm bảo sự ra đời của sản phẩm cuối cùng, nhưng một dự án phần mềm linh hoạt nhằm đến việc cho ra phần mềm mới khi kết thúc mỗi bước lặp. Trong nhiều trường hợp, người ta đạt được mục tiêu này. Điều này đặc biệt đúng đối với phần mềm ứng dụng web. Cuối mỗi bước lặp, bất kể kết quả như thế nào, nhóm phát triển phần mềm cũng đánh giá lại các ưu tiên của dự án.

Các phương pháp phát triển phần mềm linh hoạt nhấn mạnh tầm quan trọng của giao tiếp thời gian thực, giao tiếp trực tiếp mặt-đối-mặt được đánh giá cao hơn giao tiếp qua các tài liệu viết. Hầu hết các đội phát triển linh hoạt được tập trung trong một môi trường có điều kiện thuận lợi cho việc giao tiếp, và các đội này bao gồm cả các lập trình viên và các "khách hàng" của họ (khách hàng là người định nghĩa sản phẩm; họ có thể là các quản lý sản phẩm, các nhà phân tích doanh nghiệp (business analyst), hoặc các khách hàng thực sự). Đội còn có thể bao gồm cả các chuyên gia test, thiết kế tương tác, những người viết tài liệu kỹ thuật, và các quản lý.

Các phương pháp phát triển phần mềm linh hoạt còn nhấn mạnh khả năng hoạt động của phần mềm như là phương thức chính yếu để đánh giá tiến độ. Cùng với việc đánh giá cao giao tiếp trực tiếp, các phương pháp tạo ra rất ít tài liệu khi so sánh với các phương pháp khác. Điều này dẫn đến phê phán rằng các phương pháp phát triển linh hoạt không có tính kỷ luật.

Lặp đi lặp lại, gia tăng và tiến hóa (Iterative, incremental và evolutionary)

Dự án thường sẽ chia thành các giai đoạn nhỏ (timebox), có đầy đủ các bước làm việc (ra kế hoạch, phân tích, thiết kế, lập trình, kiểm thử). Chúng được lặp đi lặp lại trong suốt dự án (chu kỳ từ 2-4 tuần).

Phần mềm chạy được là thước đo của tiến độ làm việc.

Hiệu quả và đối thoại mặt-đối-mặt

Người ta khuyến khích sự giao tiếp trực tiếp giữa các bên liên quan trong phương pháp Phát triển phần mềm linh hoạt.

Rất ngắn vòng lặp phản hồi và chu kỳ thích ứng

Một đặc điểm nổi bật của Phát triển phần mềm linh hoạt là các buổi "trao đổi hằng ngày" (daily stand-up). Trong khoảng thời gian ngắn (chẳng hạn 15 phút), các thành viên của nhóm sẽ cho biết mình đã làm được gì và sẽ làm gì hôm nay. Khó khăn cũng được nêu ra nếu có.

Tập trung vào chất lượng

Các công cụ như Tích hợp liên tục, kiểm thử tự động,... được áp dụng để tăng chất lượng của dự án.

Thích nghi so với tiên đoán

Lặp đi lặp lại so với phương pháp Thác nước

Mã nguồn so với tài Liệu

Một số phương pháp phổ biến:

• Adaptive software development (ASD)
• Agile modeling
• Agile Unified Process (AUP)
• Crystal Clear methods
• Disciplined agile delivery
• Dynamic systems development method (DSDM)
• Extreme programming (XP)
• Feature-driven development (FDD)
• Lean software development
• Kanban
• Scrum
• Scrumban
• RAD(Rapid Application Development)

^ theo Edmonds.

Tiếng Anh:

• Manifesto for Agile Software Development Lưu trữ 2021-03-27 tại Wayback Machine
• The Agile Alliance
• Post-Agilism: Process Skepticism by Jonathan Kohl (This is where the term "post-Agilism" first appeared in the blogosphere.)

• Why Agile Software Development Techniques Work: Improved Feedback
• Risk based selection for agile iterative lifecycle methods
• "The Demise of the Waterfall Model Is Imminent" and Other Urban Myths
• Agile, Multidisciplinary Teamwork by Gautam Gosh
• Agile Requirements by Rachel Davies
• Two Ways to Build a Pyramid by John Mayo-Smith
• Levent Gurses (ngày 1 tháng 11 năm 2006). “10 Mistakes in Transitioning to Agile: Slow down the transition in order to go fast”. Dr. Dobb's Journal. Kiểm tra giá trị ngày tháng trong: |date= (trợ giúp)
• Breaking the Major Release Habit Lưu trữ 2007-09-27 tại Wayback Machine - Why are long iterations a hard habit to break?

• Agile Toolkit Podcast - Conversations and Interviews related to Agile Software Development

• Video - Why does Agile Software Development pay? - by OutSystems
• Agile Modeling: Effective Practices for XP and RUP Lưu trữ 2019-08-08 tại Wayback Machine by S.W. Ambler.
• TechBookReport An archive of book reviews devoted to a range of software methodologies, particularly Agile (including Scrum, XP and other agile processes.

• Agile trên DMOZ
• Agile Methodology Overview Lưu trữ 2007-06-23 tại Wayback Machine - OutSystems Agile Methodology Overview