Agile software development – lập trình linh hoạt
Posted by: nttuyen on: Tháng Tư 27, 2008
Khi làm S.E chắc không ai không biết waterfall. Có lẽ trong tương lai chắc không ai không biết đến Agile.
1. Mô hình thác nước (waterfall model)
Mô hình thác nước được áp dụng trong hầu hết các công ty phát triển phần mềm hiện nay. Nó ra đời từ sự kết hợp các chu trình sản xuất các sản phẩm từ nhiều ngành kỹ thuật khác nhau : mỗi sản phẩm được sản xuất đề trải qua các giai đoạn : xác định yêu cầu, phân tích, thiết kế, sản xuất, kiểm định và cuối cùng là bàn giao cho người dùng.
Tuy nhiên mô hình này có 2 vấn đề lớn là :
- Mô hình này phải với giả định rằng chúng ta luôn có thể làm được một hệ thống hoàn hảo ngay từ đầu.
- Phần mềm ngày càng khác so với các cơ cấu kỹ thuật cứng nhắc mà giống với các cơ thể sống – nó phải tiến hoá để thích hợp với môi trường.
2. Agile development method – phát triển linh hoạt – phần mềm tiến hoá.
Phương pháp Agile (phát triển phần mềm linh hoạt) bắt đầu ra đời vào giữ những năm 90 với mục tiêu là phần mềm có khả năng mở rộng hay tiến hoá theo thời gian mà không cần phải làm lại từ đầu. Phần mềm này tập trung vào : Tạo ra một phần mềm đơn giản có thể đáp ứng nhu cầu khách hàng hiện tại và có khả năng mở rộng, sẵn sàng thay đổi đáp ứng cho nhu cầu trong tương lai.
Phương pháp Agile cố gắng cực tiểu hoá rủi ro bằng cách phát triển phần mền trong những khung thời gian ngắn. Mỗi bước lặp giống như phát triển một phần mềm hoàn chỉnh cũng gồm có lấy yêu cầu, làm phân tích thiết kế, code, test, viết tài liệu. Tuy mỗi bước lặp có thể không bổ xung đủ chức năng để đảm bảo sự ra đời của sản phẩm cuối cùng, nhưng nó nhằm cho ra đời một sản phẩm phần mềm mới sau mỗi bước lặp kết thúc. Cuối mỗi bước lặp bất kể kết quả thế nào, nhóm phát triển cũng đánh giá lại các ưu tiên của dự án.
Phương pháp Agile nhấn mạnh tầm quan trọng của giao tiếp thời gian thực, giao tiếp mặt đối mặt được đánh giá cao hơn là các tài liệu viết. Hầu hết các đội phát triển theo kiểu Agile đều đượ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 phải bao gồm các lập trình viên và các khách hàng của họ.
3. Principle behind Agile method
- Yêu cầu của khách hàng được phát triển nhanh chóng, phần mềm sau đó được tiếp tục phát triển, mở rộng
- working software được phân phối một cách thường xuyên
- working software là nhân tố đánh giá chính trong quy trình
- Luôn sẵn sàng cho những thay đổi về yêu cầu
- Có sự hợp tác liên tục giữ những người tác vụ và người phát triển
- Mặt đối mặt là các thức trao đổi tốt nhất
- Dự án được xây dựng thông qua sự thúc đẩy của một cá nhân, người mà được tín nhiệm
- Liên tiếp chú ý tới các công nghệ nổi trội hay những bản thiết kế tốt
- Đơn giản
- Những nhóm tự tổ chức
- Thích ứng với thay đổi theo môi trường.
4. Tham khảo thêm
- Agile Software development – wikipedia
- Lập trình linh hoạt – wikipedia
- Principle behind the Agile manifesto
- Lập trình viên – Bạn sẽ bị đào thải vào ngày mai ? – web2vietnam.com
3 phản hồi tới "Agile software development – lập trình linh hoạt"
Phương thức phát triển này dựa trên hai kỹ thuật đáng lưu ý nhất:
1. Refactoring: Giống như vệc bạn trang trí lại căn nhà mà không cần phải cơi nới, xây thêm hay xây lại, “refactoring” (xin lỗi, tôi chưa tìm được từ tiếng Việt nào thích hợp để dịch) cho phép chúng ta chuyển đổi mã lệnh để làm cho ứng dụng tốt hơn, đẹp hơn mà không phá hỏng nó (các bạn có thể tìm hiểu thêm về kỹ thuật này trong cuốn Refactoring: Improving the Design of Existing Code).
2. Developer Testing: Phần mềm do chính các lập trình viên được kiểm định thay vì do các nhóm tester độc lập làm. Công cụ là “unit test”, cho phép từng phần nhỏ của phần mềm được kiểm định ngay trong quá trình phát triển trước khi lắp ghép vào ứng dụng. (xin xem thêm cuốn Test Driven Development: By Example)
Như vậy xu thế mới trong S.E hiện nay đó là chia công việc devel software ra thành nhiều module nhỏ độc lập nhau, sau đó tích hợp chúng lại tạo ra một hệ thống hoàn chỉnh linh hoạt.
Ví dụ bạn hãy tưởng tượng sẽ chế tạo một con Robot đồ chơi của trẻ em. Nếu bạn dùng một khối nhựa và đúc thành một hình robot hoàn chỉnh. Khi đó nếu con robot đó bị hỏng trong phần nào đó hay nhu cầu thay đổi, bạn sẽ phải làm lại từ đầu. Nhưng nếu bạn đúc thành từng bộ phận nhỏ như tay, chân, thân hình … rồi sau đó lắp ghép chúng lại với nhau. Khi đó con robot có bị hỏng phần nào thì bạn chỉ cần sửa phần đó rồi ráp chúng lại, làm như thế nhanh hơn. Hơn nữa nếu bạn muốn sản xuất một loại robot mới thì cũng có thể sử dụng lại một bộ phận đã sản xuất nào đó của con robot trước.
Khi được chia nhỏ ra, mỗi phần nhỏ đó được test cẩn thận bằng Unit test bởi chính các developer. Khi tích hợp chúng lại được integation test.
JUnit và Cactus.
1 | nttuyen
Tháng Tư 27, 2008 lúc 10:51 sáng
Nhận xét 1 :
Thực ra cái mô hình Waterfall bây giờ đã thể hiện nhược điểm cứng nhắc, không linh hoạt. Tuy nhiên nó vẫn là mô hình được ứng dụng nhiều, chỉ có điều đang thay đổi trở nên nhỏ hơn thôi.
Agile là mô hình linh hoạt, nhưng trong mỗi khung thời gian của nó vẫn dùng mô hình Waterfall đó, công thêm yêu cầu về khả năng mở rộng linh hoạt của hệ thống.