Dự án agile
Thay đổi yêu cầu là một trong những vấn đề chính trong hầu hết các dự án phần mềm. Để giảm thiểu vấn đề này, tổ phát triển phần mềm phải hội tụ vào làm việc với người dùng để phát triển yêu cầu rõ ràng và chính xác. Tuy nhiên, khi người dùng không biết họ muốn gì, hay thường đổi ý thì tổ phát triển có thể chấp thuận cách tiếp cận gia tăng bằng việc xác định điều người dùng có thể giải thích được vào lúc đó rồi ưu tiên hoá chúng thành nhiều bản đưa ra với bản họ đã biết được thực hiện trước nhất.
Cách tiếp cận này được gọi là “Cách tiếp cận Agile” bao gồm nhiều cách phát triển phần mềm. Một trong những cách phổ biến nhất là “Scrum”, chia hoạt động phát triển thành nhiều nỗ lực nhỏ, từng nỗ lực kéo dài từ 2 tới 4 tuần có tên là “Sprint- Nước rút”. Với từng nước rút, nhu cầu của người dùng được ưu tiên hoá thành “Tồn đọng nước rút- Sprint backlog” (Yêu cầu đối với một nước rút đặc biệt) nơi tổ có thể tập trung vào làm việc về nhu cầu của người dùng mà không phải lo lắng về các yêu cầu khác. Bằng việc xây dựng tăng dần phần mềm tương ứng theo ưu tiên của người dùng, tổ tiếp tục chuyển giao phần mềm làm việc thoả mãn cho người dùng thay vì chuyển giao mọi thứ một lần như với vòng đời thác đổ. Bằng việc đưa ra một mảnh phần mềm mỗi lúc, người dùng không phải chờ đợi lâu mà có thể dùng vài tính năng mỗi vài tuần và có thể đo được tiến bộ của tổ tương ứng. Với từng việc đưa ra, tổ cũng suy nghĩ về điều gì có tác dụng và điều gì không và tiếp tục cải tiến cách họ làm việc cùng nhau.
Trước khi dự án mau lẹ bắt đầu, cả tổ phát triển và người dùng phải đồng ý về cách qui trình này sẽ được thực hiện. Vai trò, trách nhiệm và đảm nhiệm phải được xác định và phân công để đảm bảo rằng người quản lí, người dùng và tổ dự án hiểu họ được giả định làm gì. Theo cách tiếp cận mau lẹ, trao đổi là yếu tố quan trọng nhất cho nên người dùng phải phân công ai đó làm việc cùng tổ dự án để phối hợp các yêu cầu và ưu tiên trên cơ sở hàng ngày. Đại diện này làm việc cùng “Thầy Scrum” của tổ dự án để xácđịnh “tồn đọng” cho từng nước rút Sprint. Đại diện của người dùng cũng phải có khả năng trả lời nhanh chóng mọi câu hỏi đặt ra cho tổ và lập ưu tiên mới, nếu cần. Nếu với bất kì lí do nào, người dùng bận rộn và không thể tham gia được vào giao tiếp hàng ngày với tổ, tính mau lẹ sẽ KHÔNG có tác dụng.
Thầy Scrum chịu trách nhiệm cho mọi dự án trong việc phối hợp các hoạt động với người dùng, đảm bảo rằng mọi người đều tuân theo qui trình agile tương ứng với vai trò, trách nhiệm của họ và thúc đẩy công việc tổ trong các thành viên tổ. Như đã đăng trước đây trong blog của tôi, cách tiếp cận Agile có tác dụng tốt cho các dự án nhỏ (4 tới 10 người) và mọi người trong tổ đều phải nhận được việc đào tạo agile để cho họ có thể làm việc tương ứng. Tuy nhiên, xung đột giữa mọi người trong tổ có xảy ra. Chính công việc của Thầy Scrum là giải quyết những vấn đề này nhanh chóng và hiệu quả. Thầy Scrum phải có kĩ năng giải quyết xung đột tổ bởi vì với cách làm mau lẹ, thời gian là cốt yếu (2 tới 4 tuần cho từng nước rút), cho dù với một người “khó làm việc”, toàn tổ cũng có thể bị tác động. Thầy Scrum cũng làm việc để loại bỏ bất kì chướng ngại nào được báo cáo trong cuộc họp hàng ngày và bảo vệ tổ khỏi bất kì việc ngắt quãng nào từ bên ngoài bởi vì công việc mau lẹ là rất dồn dập.
Có vài công cụ thương mại sẵn có trên thị trường cho dự án mau lẹ nhưng có những phương án như phần mềm nguồn mở nữa. Tôi thích dùng ba công cụ “tự do” này:
Wiki: Công cụ này có thể được cả người dùng và tổ dự án dùng để trao đổi và cộng tác trên mọi vấn đề có liên quan tới dự án.
Geeklog: Dùng công cụ này các thành viên dự án có thể thảo luận vấn đề lẫn với nhau. Công cụ này sẽ có giá trị cho các thành viên dự án để thảo luận về các vấn đề có liên quan tới các dự án khác nhau.
CVS: Nó là công cụ cấu hình nguồn mở để kiểm soát phiên bản đưa ra.
Bugzilla: Project team can use this tool to track defects and take various reports on defects.
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