Vấn đề với cách tiếp cận Agile
Một người phát triển phần mềm hỏi tôi: “Người quản lí của tôi nói rằng hoạt động chính của Agile chỉ là viết mã và kiểm thử. Bạn không cần tài liệu cho nên chúng tôi có thể hoàn thanh nhanh và đó là lí do tại sao cái tên “Agile - mau lẹ” tới. Điều đó có đúng không?”
Đáp: Nếu người quản lí của bạn coi “Agile” CHỈ là viết mã, kiểm thử và không có tài liệu thì tôi sẽ gọi nó là: “Agile muốn vậy”, “Agile giả” KHÔNG phải “Agile thực”. Mặc dầu mục đích chính của Agile là nhanh và linh hoạt nhưng nó cũng bao gồm các nguyên tắc kĩ nghệ phần mềm để đảm bảo sản phẩm đạt tới chất lượng. Chẳng hạn, kiểm điểm tình trạng dự án bằng họp hàng ngày; giảm rủi ro bằng dựng tăng dần; xác định yêu cầu bằng “câu chuyện của người dùng”. Mô tả này về yêu cầu được kể từ quan điểm của người dùng cũng là tài liệu. Bỏ những nguyên lí này sẽ tạo ra rủi ro về chi phí cao, và chuyển giao chậm.
Có nhiều hiểu lầm về cách tiếp cận Agile và “không tài liệu” là một cách hiểu sai. Nhiều người dùng cái tên “Agile” để bảo vệ cho việc “thiếu kỉ luật” của họ và “thiếu tri thức” trong điều họ làm. Nếu họ bỏ qua thiết kế và nhày vào viết mã, họ nói họ đang dùng Agile. Khi họ không có đủ thời gian, họ bỏ qua việc kiểm thử và nói vì họ dùng Agile. Có chuyện ngụ ngôn cổ về gà và cáo thảo luận về cơ hội mở tiệm ăn. Cáo gợi ý cho gà: Tớ sẽ là người nấu, vì cậu đã cam kết cho thành công của tiệm ăn, tớ đề nghị chúng ta có mục menu kiểu như “Gà rán” “Súp gà”, “Gà ca ri” v.v.”. Câu chuyện này được ngụ ý chỉ ra sự khác biệt giữa những người nói và những người cam kết làm công việc.
Ý định của Agile là xây dựng cấu phần sản phẩm theo những việc lặp nhỏ. Trong phương pháp Scrum, từng lần lặp được gọi là “Sprint” (chặng nước rút) vào quãng hai tới bốn tuần. Một dự án điển hình có thể bắt đầu với tài liệu của người chủ sản phẩm về yêu cầu dự án trong tồn dư sản phẩm Product Backlog (Scrum có yêu cầu tài liệu ở đây). Người quản lí dự án hay thầy Scrum sẽ lập kế hoạch đưa ra sản phẩm bằng việc xác định cần bao nhiêu “Sprints” để hoàn thành dự án và thời hạn cho từng Sprint (2 hay 4 tuần). Với từng Sprint, tổ sẽ làm việc với người chủ sản phẩm, thầy Scrum để xác định những thứ họ phải làm và làm tài liệu chúng trong tồn dư của Sprint (nhiều tài liệu hơn). Tổ sẽ phân tích tồn dư này, bắt đầu thiết kế, viết mã, kiểm thử và thảo luận về tiến độ, vấn đề, rào chắn, và phân bổ công việc trong cuộc họp hàng ngày của họ. Tại cuối từng Sprint, tổ đưa ra sản phẩm và tiến hành nội quan suy ngẫm về Sprint để xác định cái gì có tác dụng và không có tác dụng rồi tái tổ chức lại công việc của họ để cho họ có thể làm nó tốt hơn trong Sprint tiếp. Thầy Scrum làm tài liệu điều tổ đã học được ttrong một tài liệu để được kiểm điểm vào chặng nước rút tiếp. Về căn bản, với Agile bạn cũng làm một số tài liệu.
Agile KHÔNG ngụ ý bỏ qua cái gì mà chỉ làm mọi sự theo từng mảnh nhỏ vào từng lúc. Nó chủ trương đưa ra tăng dần sản phẩm phần mềm với từng việc đưa ra chứa vài chức năng vào mỗi lúc. Điều này là tốt hơn cách tiếp cận khác bởi vì với từng việc đưa ra, tổ sẽ lấy phản hồi từ người dùng ngay lập tức. Điều quan trọng là giải thích cách tiếp cận tăng dần trước khi dự án bắt đầu để cho người dùng biết rằng họ sẽ có thêm chức năng với từng lần đưa ra. Người dùng có thể nói cho tổ liệu chức năng đưa ra là đúng hay không, đôi khi nếu đó không phải là điều họ có trong tâm trí, họ có thể yêu cầu thay đổi. Khi tổ tiếp tục nhận được phản hồi từ người dùng, họ có thể tiếp tục xây dựng phần mềm với mọi chức năng mà người dùng cần. Đây là khác biệt với cách tiếp cận thác đổ nơi tổ chỉ đưa ra cho người dùng khi họ kết thúc đầy đủ toàn bộ phần mềm.
Một số người KHÔNG thích họp hàng ngày của Agile vì họ nghĩ họp là phí thời gian. Theo kinh nghiệm của tôi, tôi bao giờ cũng yêu cầu thành viên tổ tuân theo qui trình này bằng việc nói cho tổ: Tôi đã làm cái gì (Kiểm điểm công việc ngày hôm trước với tổ); Tôi làm nó thế nào (Kiểm về phản hồi chất lượng); Tôi sẽ làm gì (Hỏi về phân công hôm nay), Tôi cần gì (Kiểm về bất kì thông tin thêm nào). Điều này có thể xảy ra trong cuộc họp ngắn, thường không quá nửa giờ cho nên tổ có thể tiếp tục với công việc của họ. Vì tổ Agile là “tự tổ chức”, người có kĩ năng là nhân tố quan trọng nhất cho thành công của dự án. Điều quan trọng là lựa người đúng và đào tạo họ theo cách tiếp cận này bởi vì không có người lãnh đạo tổ toàn diện, người quyết định người nào sẽ làm nhiệm vụ nào hay vấn đề sẽ được giải quyết thế nào. Đấy là những vấn đề được quyết định bởi tổ như một toàn thể. Trong kiểu tổ này, từng người làm bất kì cái gì được cần tới để hoàn thành công việc. Điều đó cũng có nghĩa là mọi người phải có mọi kĩ năng được cần trong phát triển phần mềm vì có thể không có người kiểm thử hay người lập trình hay người thiết kế nhưng các thành viên tổ có thể phải làm cả ba việc đó.
Agile là cách tiếp cận phát triển phần mềm tốt cho dự án nhỏ và dự án có yêu cầu không được xác định rõ mà phải được hoàn thành nhanh. Giống như mọi cách phát triển, các thành viên tổ phải được đào tạo đúng và hiểu cả nguyên lí cũng như phương pháp. Agile KHÔNG phải là giải pháp cho mọi thứ, bạn phải biết giới hạn của nó và cẩn thận tránh một số hiểu lầm và dùng lầm.
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
