Cách tiếp cận Agile
Nhiều người phát triển phần mềm nói rằng họ dùng cách tiếp cận Agile, nhưng thực tế họ chỉ dùng nó như cơ hội để nhảy qua qui trình phát triển và làm tài liệu để cho họ có thể nhảy vào viết mã. Những “người phát triển vô kỉ luật” này biết rằng quản lí cấp trung và người chủ công ti không có ý tưởng về Agile thực sự là gì. Đó là lí do tại sao nhiều người quản lí bảo với tôi rằng Agile không có tác dụng trong công ti của họ. Trong khảo cứu của tôi về 250 dự án phần mềm trong ba năm qua, tôi thấy rằng Agile là tuyệt hảo cho các dự án phần mềm nhỏ (ít hơn 10 người), nó có thể giúp cải tiến chất lượng và sự thoả mãn của khách hàng đáng kể.
Điều thành công then chốt trong Agile là có tổ dự án có kinh nghiệm và có kĩ năng. Dự án Agile đòi hỏi mọi thành viên tổ đóng nhiều vai trò khi được cần, từ kiến trúc, thiết kế tới phát triển và kiểm thử. Người lập trình chỉ viết mã sẽ không có khả năng dùng Agile một cách thành công. Bên cạnh những người phát triển có kĩ năng, dự án cần người đảm bảo chất lượng (QA) tốt, người có thể xây dựng và thực hiện các kiểm thử, và người quản lí cấu hình (CM) người có thể giúp kiểm soát các thay đổi và dựng sản phẩm phần mềm. Một vai trò quan trọng trong Agile là người chủ sản phẩm (PO). Vai trò này yêu cầu người có kinh nghiệm cao để làm việc với khách hàng và đảm bảo mọi người trong tổ hiểu nhu cầu khách hàng. (Vai trò này cũng được gọi là người phân tích nghiệp vụ hay kĩ sư yêu cầu trong cách tiếp cận khác.) PO phải nhận diện khách hàng đúng để đảm bảo yêu cầu là chính xác và cung cấp giá trị cho công ty. Đôi khi đại diện khách hàng sẽ được phân công cho dự án để hành động như PO. Việc chính của PO là kiểm nghiệm điều tổ đang dựng là cái gì đó mà khách hàng thực sự muốn.
Vai trò then chốt khác trong Agile (phương pháp Scrum) là Thầy Scrum. Thầy Scrum xác định các qui trình và thực hành cho dự án và đảm bảo tổ tuân theo chúng. Nhiệm vụ then chốt khác của Thầy Scrum là loại bỏ bất kì chướng ngại hay khối chắn nào cho dự án. Thầy Scrum cũng tạo điều kiện cho phiên lập kế hoạch nước rút Sprint, theo dõi hàng ngày, suy ngẫm, và phiên lập kế hoạch đưa ra. Nếu tổ chức của bạn là mới với Agile, điều quan trọng là đưa vào một huấn luyện viên Agile, người đã kinh nghiệm sâu sắc trong cách tiếp cận Agile để đảm bảo cho tổ đang thực hiện Agile một cách hiệu quả. Huấn luyện viên cũng cung cấp đào tạo cho tổ và phải chắc rằng họ sẽ không làm “lối tắt” hay “thủ đoạn” nào để nhảy lùi lại thói quen cũ như “mã trước, thiết kế sau.”
Để chắc chắn rằng công ti dùng Agile đúng, điều quan trọng là đào tạo cả người quản lí cấp trung và người chủ nữa. Họ phải hiểu qui trình Agile, vai trò và trách nhiệm của thành viên tổ và tin cậy vào tổ của họ làm công việc. Họ nên tham gia và kiểm điểm Sprint (phương pháp Scrum) để thu được cảm giác tiến bộ thay vì chỉ đọc báo cáo trạng thái. Họ phải hiểu rằng ý định chính của nó là xây dựng giá trị khách hàng điều chung cuộc có thể có nghĩa là nhiều thu nhập hơn cho công ty. Tất nhiên, họ KHÔNG cần là chuyên gia nhưng tối thiểu họ phải hiểu khái niệm về tổ tự tổ chức, cộng tác. Họ cần giúp đỡ PO bằng các yêu cầu và làm sáng tỏ để đảm bảo rằng tổ xây dựng cái gì đó mà khách hàng cần. Họ cần hiểu rằng tồn lưu sản phẩm và mục đích đưa ra được PO sở hữu và tránh đưa ra hứa hẹn cho khách hàng mà không có PO trong thoả thuận. Về căn bản, cách tiếp cận Agile KHÔNG chỉ dành cho tổ phát triển mà mọi người bên trong công ti phải hiểu qui trình và ích lợi của nó. Nó đưa tổ tới thành công và với Agile, tổ là toàn bộ công ty.
Ngược với khái niệm sai về Agile rằng nó chỉ yêu cầu “kĩ năng viết mã để làm điều đó cho nhanh”, có nhiều thực hành Agile nghiêm ngặt. Đó là lí do tại sao điều quan trọng là có đào tạo Agile tốt trước khi thích nghi nó cho công ty. Có kỉ luật tốt giúp cho năng suất và chất lượng vì kỉ luật đảm bảo rằng mọi người được hội tụ vào công việc. Nếu bạn nghe ai đó nói rằng Agile là về “viết mã nhanh hơn và chóng hơn”, điều rõ ràng là họ chắc chắn chưa bao giờ thực tế làm Agile mà chỉ giả vờ biết cái gì đó về nó.
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
