I. Phát triền phần mềm truyền thống
a. Nhắc lại về phát triển truyền thống
Phát triển phần mềm như chúng ta đã biết thường trải qua các giai đoạn Requirement – Design – Code – Test – UAT – Release. Ở mỗi giai đoạn sẽ tập trung vào những công việc khác nhau và cố gắng để hoàn tất trước khi bước đến gia đoạn tiếp theo.
- Requirement : giai đoạn thu thập yêu cầu người dùng. Sau khi hợp đồng ký kết, sẽ tiến hành thu thập yêu cầu và phân tích yêu cầu. Giai đoạn này, nhà phân tích (BA- Business Analysis) sẽ hoạt động và để chốt yêu cầu với khách hàng. Kết thúc giai đoạn là sự phê chuẩn của khách hàng.
- Design : giai đoạn thiết kế, từ khởi nguồn là yêu cầu người dùng, sẽ đưa ra những bản thiết kế về giao diện (UI- User Interface ) và Architecture Design. Cuối giai đoạn này cũng là bước phê duyệt của khách hàng.
- Coding : giai đoạn thực thi, giai đoạn này đòi hỏi tất cả nguồn lực cùng làm việc ( BA, SA – Solution Architect, Desginer, Developer, Tester) đê tạo ra sản phẩm phần mềm theo ý khách hàng, cuối giai đoạn này sẽ là một gói phần mềm đưa lên môi trường test.
- Test : giai đoạn này thường đi chung với giai đoạn code ở những dự án sau này. Xong chức năng nào sẽ test chức năng ấy, cuối cùng là test lại toàn bộ. cuối giai đoạn này sẽ là test report để chứng minh rằng sản phẩm chạy tốt như yêu cầu.
- UAT (User Acceptance Test) : là bước để khách hàng vào dùng thử sản phầm. nếu mọi thứ trơn tru thì sẽ kết thúc bằng văn bản nghiệp thu sản phẩm. cuối cùng là chuyển sang bước cuối là release và nếu hợp đồng có đề cập thì sẽ qua giai đoạn bảo trì (phần Maintenance).
b. Một ví dụ về mô hình phát triền
Waterfall và các bước phát triển phần mềm.
Một mô hình khác khá thông dụng là V-Model , ở mỗi bước sẽ đi cùng với validation và verification. Để mọi step được test và kiểm tra càng sớm càng tốt.
c. Các vấn đề của mô hình truyền thống
Điểm mạnh
- Mỗi giai đoạn sẽ tập trung vào một công việc cụ thể
- Kế hoạch được lên một cách chi tiết cho từng giai đoạn
- Phạm vi công việc rõ ràng, khách hàng kiểm soát được ngân sách
Điểm hạn chế
- Khi qua một giai đoạn mới, những thay đổi sẽ ảnh hưởng đến các giai đoạn trước đó.
- Kế hoạch cho một thời gian phát triển dài sẽ nhiều nguy cơ tiềm tàng
- Khách hàng thiếu cơ hội tiếp cận sản phẩm ở những giai đoạn sớm. Tranh cãi về những phản hồi và thay đổi từ khách hàng.
- Khó thay đổi, vì sẽ cần sửa lại toàn bộ quá trình
II. Phát triển Agile
a. Hướng tiếp cận
Theo Agile , việc phát triển phần mềm sẽ theo hướng tăng trưởng. Những chức năng nhỏ được phát triển trong khoảng thời gian ngắn. Sau đó, được đưa ra thị trường để người dùng tiếp cận và phản hồi ngay. Chờ đợi một sản phẩm hoàn chỉnh sẽ là không cần thiết.
Những chức năng nhỏ ( gói tăng trưởng ) sẽ đảm bảo các tiêu chí sau :
- Đáp ứng tiêu chí người dùng – xài được
- Đáp ứng tiêu chí chất lượng mà đội ngũ đề ra
- Có thể đưa ra thị trường bất cứ lúc nào
Hình ảnh minh họa
b. Những khung làm việc phổ biến
Phổ biến nhất là mô hình Scrum với các vòng lặp gọi là Sprint. Cuối mỗi sprint sẽ cho ra một gói tăng trưởng (increment) để thảo luận cùng người dùng và lấy ý kiến .
Ngoài ra còn có mô hình Kanban hoặc Scrumban, với việc quản lý công việc theo từng trạng thái (Todo, Inprogress, Done) để làm cách nào tối ưu hóa quy trình làm việc để từ Todo sang Done được rút ngắn.
c. những ưu điểm và nhược điểm
Ưu Điểm
- Khách hàng được thấy sản phẩm ở từng phần được hình thành
- Các thay đổi có thể được thêm vào ở chu kỳ tiếp theo.
- Thời gian phát triển chia nhỏ thành nhiều vòng lặp và khách hàng có thể thấy được kết quả ở giai đoạn sớm
Nhược Điểm
- Phần tài liệu (document) được đơn giản hóa. nên đôi khi không có tài liệu về yêu cầu để tham khảo sau này.
- Quy trình kiểm tra hồi quy càng lớn về sau khi khối lượng tăng trưởng gia tăng. đòi hỏi Automation Test và DevOps hỗ trợ.
- Cần sự hỗ trợ từ phía khách hàng và ý kiến từ họ. ít nhất là có sự góp mặt ở cuối mỗi vòng lặp.