Phương thức phát triển phần mềm linh hoạt (Agile Software Development) – sau đây được gọi vắn tắt là “Agile” – đã trở nên phổ biến trong ngành phát triển phần mềm. Với những phương phức tổ chức và triển khai mới lạ, năng động và linh hoạt, Agile đã thu hút sự quan tâm lớn của cộng đồng làm phần mềm và dĩ nhiên là một kỹ sư kiểm thử mình không thể nào thờ ơ với Agile được. Trước hết mình xin nói ngay rằng mình không phải là một chuyên gia về Agile cũng không phải là kỹ sư kiểm thử nhiều năm chinh chiến với Agile. Mình chỉ là một kỹ sư kiểm thử với chút kinh nghiệm dự án thực tế và ít kiến thức lụm lặt được về Agile. Tuy nhiên mình vẫn mong muốn được chia sẻ những hiểu biết suy nghĩ của mình và hy vọng nhận được sự chia sẻ từ các anh chị em trong ngành về Agile.
Bài viết “Tổng quan về Agile” sau đây là một phần trong một loạt bài giới thiệu về Agile theo cách nhìn của mình, nội dung được tinh giản nhưng hy vọng vẫn giữ được nguyên giá trị của Agile và…chúng ta bắt đầu thôi.
Phương thức phát triển phần mềm Agile là gì?
Wiki định nghĩa như sau: “Phương thức phát triển phần mềm Agile là một tập hợp các phương thức phát triển lặp và tăng dần trong đó các yêu cầu và giải pháp được phát triển thông qua sự liên kết cộng tác giữa các nhóm tự quản và liên chức năng v.v và v.v”. OK. Bỏ qua phần định nghĩa nhé vì mình thấy không giúp ích gì nhiều. Đại ý là Agile là cách thức làm phần mềm linh hoạt để làm sao đưa sản phẩm đến tay người dùng càng nhanh càng tốt càng sớm càng tốt và được xem như là sự cải tiến (ở một khía cạnh nào đó) khi đặt cạnh những mô hình cũ như Mô hình “Thác nước (waterfall)” hay “CMMI”.
Định nghĩa Agile có thể trừu tượng và bạn có thể không nhớ nhưng bạn không thể không nhớ “Tuyên ngôn của Agile” (Agile manifesto). “Tuyên ngôn của Agile” được xem là cốt lõi là ngôi sao dẫn đường trong Agile. Theo tuyên ngôn, Agile hoạt động dựa trên những tôn chỉ sau:
Tuyên ngôn của Agile
- “Cá nhân và sự tương hỗ quan trọng hơn quy trình và công cụ”
- “Sản phẩm xài được quan trọng hơn tài liệu về sản phẩm”
- “Cộng tác với khách hàng quan trọng hơn đàm phán hợp đồng”
- “Phản hồi với sự thay đổi quan trọng hơn bám theo kế hoạch”
Tuyên ngôn cũng nói rằng mặc dù những mục bên phải vẫn có giá trị nhưng Agile đánh giá cao các mục bên trái hơn (phần in đậm)
4 tôn chỉ trên được dựa trên 12 nguyên tắc sau:
- Thỏa mãn yêu cầu của khách hàng thông qua việc giao hàng sớm và liên tục
- Chào đón việc thay đổi yêu cầu, thậm chí là những thay đổi yêu cầu muộn
- Giao phần mềm chạy được cho khách hàng một cách thường xuyên (giao hàng tuần hơn là hàng tháng)
- Nhà kinh doanh và kỹ sư lập trình phải làm việc cùng nhau hàng ngày trong suốt dự án
- Các dự án được xây dựng xung quanh những cá nhân có động lực. Cung cấp cho họ môi trường và sự hỗ trợ cần thiết, và tin tưởng họ để hoàn thành công việc
- Trao đổi trực tiếp mặt đối mặt là phương pháp hiệu quả nhất để truyền đạt thông tin
- Phần mềm chạy được là thước đo chính của tiến độ
- Phát triển bền vững và duy trì được nhịp độ phát triển liên tục
- Liên tục quan tâm đến kĩ thuật và thiết kế để cải tiến sự linh hoạt
- Sự đơn giản là cần thiết – nghệ thuật tối đa hóa lượng công việc chưa hoàn thành
- Nhóm tự tổ chức
- Thích ứng thường xuyên với sự thay đổi
Mình vừa giới thiệu các bạn tổng quan về Agile. Cũng không đến nỗi khó hiểu lắm phải không các bạn. Trong phần kế tiếp mình sẽ giới thiệu rõ hơn về “Tuyên ngôn của Agile”.
Rất vui nếu nhận ý kiến đóng góp, phê bình, chia sẻ từ các bạn.
(?) Bạn có biết cách phát âm “Agile”. Agile có phiên âm quốc tế là /ˈædʒaɪl/, /ˈædʒəl/. Nghe phát âm tại đây. Mình phát âm là “Á-chai-ồ” :-s (coi như các bạn chưa nghe thấy gì đi)
Bài viết có tham khảo và lược dịch từ Wiki và Agilemanifesto.org