Trả lời mô hình AUP
Em chào thầy
Hiện nay em đang tìm hiểu về mô hình AUP. Nhưng em vẫn chưa được hiểu kĩ về những roles trong mô hình AUP, quy trình thực hiện của AUP như thế nào và ưu nhược điểm của nó ra sao? Thầy có thể giải thích giúp em được không ạ.
NoName
Trả lời:
Tôi tin khi bạn nhắc tới AUP, bạn ngụ ý “Agile Unified Process”. Đây là mô hình cố “bù lại” giữa khuôn khổ truyền thống cho các dự án lớn như Rational Unified Process (RUP) và cách tiếp cận cho các dự án nhỏ như “Agile”. Về căn bản, tác giả Scott Amber tin rằng bạn có thể tạo ra cái gì đó được thiết kế cho dự án lớn, thay đổi nó để cho nó có thể được dùng cho cái gì đó không quá lớn. Rồi lấy cái gì đó được thiết kế cho dự án nhỏ và thay đổi nó để cho nó có thể được dùng cho cái gì đó không quá nhỏ. Bằng việc bổ sung cái tốt nhất của cả hai cách tiếp cận vào cái gì đó “ở giữa” bạn đi tới với cách tiếp cận cho dự án “vừa” – không quá lớn và không quá nhỏ.
Với dự án lớn dùng RUP, bạn phải xác định rõ các vai trò. Từng vai trò được kết hợp với tập các kĩ năng, năng lực và trách nhiệm. Những người làm mô hình sẽ hội tụ và việc làm mô hình. Những người viết mã sẽ hội tụ vào viết mã. Với dự án nhỏ dùng Scrum (cách tiếp cận Agile), bạn chỉ có ba vai trò: Thầy Scrum, Người chủ Sản phẩm và tổ phát triển. Thầy Scrum là người lãnh đạo, người chắc chắn rằng tổ đang tuân theo qui trình và loại bỏ mọi vấn đề và chướng ngại mà có thể ngăn cản tổ làm việc của họ. Người chủ Sản phẩm là người lãnh đạo doanh nghiệp người quyết định cái gì sẽ được xây dựng cho từng “Sprint” cũng như nội dung tính năng và ngày đưa ra. Tổ là “tự tổ chức” vì từng thành viên phải làm hầu hết mọi thứ từ phân tích yêu cầu, thiết kế, tới viết mã và kiểm thử.
Với dự án lớn dùng RUP, tổ phải tạo ra “Sản phẩm công việc” đại diện cho cái gì đó nảy sinh từ nhiệm vụ như tài liệu, mô hình, thiết kế, mã hay kiểm thử. Từng vai trò được gán cho các nhiệm vụ mà người đó phải làm. Một số người sẽ làm tài liệu, số khác làm mô hình, ai đó thiết kế, người khác viết mã. Trong dự án nhỏ dùng Scrum, thành viên tổ phải làm mọi thứ, từ yêu cầu, thiết kế cho tới viết mã và kiểm thử.
Cả hai cách tiếp cận đều tuân theo dựng tăng dần, có nghĩa là họ dựng và đưa ra sản phẩm phần mềm theo lịch biểu được xác định. Với RUP, bạn có vài pha đưa ra (từng pha có thể kéo dài vài tháng). Với Scrum (cách tiếp cận Agile) bạn có “Sprint” ngắn hơn (2 tới 4 tuần).
Agile Unified Process (AUP) dùng vài kĩ thuật vay mượng từ Scrum (cách tiếp cận Agile) như “Phát triển được dẫn lái theo kiểm thử”, “Quản lí thay đổi” và “Refactoring-rút ra điểm chung” nhưng giữ một số vai trò trong Rational Unified Process (RUP) như đảm bảo chất lượng, quản lí cấu hình, kiểm thử. AUP không có vai trò Thầy Scrum hay Người chủ Sản phẩm như trong Scrum nhưng họ có người quản lí dự án và kiến trúc sư (người làm mô hình) của RUP.
Theo kinh nghiệm của tôi, RUP là khuôn khổ cho phát triển phần mềm mà cho phép bạn thay đổi và điều chỉnh cho khớp với các kiểu dự án khác nhau (doanh nghiệp hay kĩ nghệ) cũng như kích cỡ dự án (lớn hay vừa) nhưng RUP là quá phức tạp cho dự án nhỏ (ít hơn 10 người) đặc biệt trong phát triển web. Nếu tôi có dự án cỡ trung bình (15 tới 50 người) tôi sẽ sửa đổi RUP thay vì cố tạo ra cách tiếp cận khác.
Tôi đã quản lí vài dự án dùng RUP cũng như Scrum cho nên tôi cải thấy thoải mái để giải thích về chúng. Tôi chưa bao giờ dùng AUP cho nên tôi không biết nó đủ tốt để có giải thích tốt hơn cho bạn. Bạn có thể kiểm website về AUP từ tác giả Scott Amber để xem giải thích tốt hơn:
http://www.ambysoft.com/unifiedprocess/agileUP.html
Tác phẩm, tác giả, nguồn
- Tác phẩm: Quản lý dự án
- Nguồn: Blog của giáo sư John Vu, Carnegie Mellon University.
- Wiki hóa: https://kipkis.com
