Agile leader - anh là ai?

Agile leader - là một cụm từ tôi nghĩ ra trong những ngày gần đây. Tạm diễn đạt theo nghĩa tiếng Việt: người lãnh đạo theo trường phái Agile (chữ agile không muốn dịch - vì dịch ra có thể không hay).

Agile là một trường phái phát triển phần mềm được khởi xướng từ bản tuyên ngôn Agile do 17 bậc lão làng trong ngành phần mềm: Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland và Dave Thomas.

Bản tuyên ngôn này được phác thảo từ 11-13/02/2001 tại Snowbird/Uhtar.

Agile được hiện thực bởi nhiều phương pháp luận (Extreme Programming, Scrum, Crystal, Feature driven,...). Tuy nhiên bài viết này không đi vào một phương pháp luận cụ thể nào. Bạn có thể đọc về chúng trong rất nhiều sách và tài liệu trên Internet.

Tôi không thích sách vở suông. Sách vở chỉ là tờ giấy vứt đi nếu nó không được áp dụng vào thực tiễn và mang lại hiệu quả. Ở đây tôi viết về những practices để trở thành Agile leader dựa trên 2 phát biểu đầu tiên của tuyên ngôn Agile. Tôi không viết các practices cho 2 phát biểu kế tiếp vì một số lý do nhạy cảm. Tất nhiên, các practices này chỉ là do tôi đúc kết từ những kinh nghiệm chủ quan trong những dự án tôi tham gia.

Phát biểu 1: Individuals and interactions over processes and tools
(Cá nhân và giao tiếp được đánh giá cao hơn quy trình và công cụ)

- Tôi coi trọng việc giao tiếp với những thành viên trong nhóm đặc biệt qua hình thức nói chuyện mặt đối mặt. Tôi muốn nhìn thấy cảm xúc/ nghe giọng nói/ đọc những dòng code bạn tôi viết/ cảm nhận được khó khăn mà bạn tôi vấp phải. Thông qua cách này giúp tôi hiểu và chia sẻ được với đồng sự của tôi nhiều hơn việc sử dụng những công cụ vô cảm như email/skype/phone.
- Tôi không viết ra những tài liệu nếu nó không phục vụ cho mục đích giao tiếp/ truyền đạt. Nếu phải viết ra một thuật toán/ xử lý phức tạp, tôi sẽ trao đổi trực tiếp và nếu cần thiết sẽ cùng đồng sự của tôi code ra nó trên bàn của anh ta/ hoặc của tôi.
- Tôi không đưa cho ai bất kì một tài liệu mà không có giải thích trực tiếp để đảm bảo họ hiểu nhanh những gì tôi đã viết.
- Tôi sẵn sàng di chuyển để được ngồi và làm việc bên cạnh những đồng sự của tôi trong cùng một dự án.
- Nếu bạn tôi gặp khó khăn, tôi sẽ ngồi bên anh ta để cùng làm và giải quyết vấn đề.
- Tôi luôn muốn tạo điều kiện và phấn đấu để giúp cho đồng sự của tôi/ và cả tôi phát triển vì tôi tin rằng: chỉ có những con người giỏi mới tạo ra được phần mềm tốt. Không có công cụ/ quy trình nào có thể giúp sản xuất ra những phần mềm hoàn hảo với những con người yếu kém.

Phát biểu 2: Working software over comprehensive documentation
(Phần mềm chạy được được đánh giá cao hơn việc viết ra tài liệu dễ hiểu).
- Tôi đặt mong đợi ở chất lượng code và thiết kế hơn những xấp tài liệu system architecture dày cộm. Thiết kế hệ thống sẽ thay đổi theo thời gian. Vì vậy nếu cần bản thiết kế hoàn chỉnh, tôi sẽ viết ở những giai đoạn cuối dự án khi thiết kế đã hoàn chỉnh.
- Tôi chứng minh cho khách hàng nhìn thấy phần mềm chúng tôi viết chạy được bằng cách cho họ nhìn thấy càng sớm càng tốt và liên tục những gì chúng tôi đã làm được để có những phản hồi sớm nhất.
- Để có một phần mềm chạy được, tôi cập nhật/đánh giá/giải quyết những rủi ro kĩ thuật sớm nhất trong từng vòng lặp phát triển.