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

—-English version—-

answer

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

Answer:

I believe when you mention AUP, you mean “Agile Unified Process”. This is a model that try to “compensate” between a traditional framework for large project such as the Rational Unified Process (RUP) and an approach for small project such as “Agile”. Basically, the author Scott Amber believe that you can create something designed for large project, changes it so it can be used for something not too large. Then take something designed for small  project and changes it so it can be used for something not too small. By adding the best of both into something “in between” than you can come up with an approach for “Medium” project – not to large and not too small.

For large project using RUP, you must have clearly defined roles. Each role is associated with a set of skills, competencies and responsibilities. People do model will focus on modeling. People do code will focus on coding. For small project using Scrum (an Agile approach), you only have three roles: Scrum Master, Product Owner and the development team. Scrum Master is a leader who make sure that the team is following the process and removes any issues and obstacles that may prevent the team from doing their job. The Product Owner is a business leader who decides what will be built for each “Sprint” as well as the feature contents and the release date. The team is “self organized” as each member must do almost everything from requirements analysis, design, to code and test.

For large project using RUP, the team must create “Work products” represents something resulting from a task such as documents, models, design, code or test. Each role is assigned tasks that the person must do. Some people will do document, others do modeling, someone does design, other does code. In small project using Scrum, team members must do everything, from requirement, design to code and test.

Both approaches are following incremental built, that means they build and release software product according to a defined schedule. With RUP, you have several releasing phases (Each may last several months). With Scrum (Agile approach) you have a shorter “Sprint” (2 to 4 weeks).

Agile Unified Process (AUP) uses several techniques borrowing from Scrum (Agile approach) such as “Test Driven Development”,  “Change Management”  and “Refactoring” but keep some of the roles in Rational Unified Process (RUP) such as Quality Assurance, Configuration Management, Testing. AUP does not have Scrum Master or Product Owner roles as in Scrum but they have Project Manager and Architect (modeler) of RUP.

From my personal experience, RUP is a framework for software development that allows you to modify and adjust to fit different types of project (Business or engineering) as well as size of project (Large or medium) but RUP is too complex for small project (Less than 10 people) especially in web development. If I have a medium size project (15 to 50 people) I would modify RUP rather than try to create another approach.

I have managed several projects using RUP as well as Scrum so I feel comfortable to explain about them. I never use AUP so I do not know it well enough to have better explanation for you. You may check out the website about AUP from the author Scott Amber for better explanation:

http://www.ambysoft.com/unifiedprocess/agileUP.html