Giới thiệu về Agile

Trong bài chia sẻ này, chúng tôi sẽ giải thích cho các bạn hiểu khái niệm về Agile, các ưu điểm mà phương thức này mang lại, các kiến thức liên quan và cách thực hiện mà chúng tôi đã áp dụng để quản lý việc phát triển của các dự án.

Agile là gì?

Là một phương thức quản lý dự án phát triển phần mềm linh hoạt giúp tăng tốc độ, sự hợp tác và khả năng đáp ứng với xu hướng thị trường. Phương thức này có cách tiếp cận lặp đi lặp lại trong việc quản lý nhằm tập trung vào khả năng phát hành liên tục và sự kết hợp với phản hồi của khách hàng trong từng sự lặp đi lặp lại này. 

Và Agile có những ưu điểm nào?

Chúng ta sẽ cùng nhau so sánh sự khác biệt giữa 2 phương thức quản lý phần mềm Waterfall và Agile để có thể lý giải một cách rõ ràng nhất về những ưu điểm và nhược điểm mà Agile mang lại.

• Xem trọng cá nhân và sự tương tác hơn việc tuân thủ áp dụng quy trình và công cụ
• Phần mềm hoạt động được ưu tiên hơn tài liệu 
• Đề cao sự hợp tác giữa khách hàng tạo ra nhiều giá trị hơn việc đàm phán thông qua hợp đồng
• Khả năng đáp ứng sự thay đổi tốt hơn việc bám sát theo kế hoạch

Một dự án được quản lý bằng phương thức Waterfall thường sẽ phải trả qua một khoảng thời gian khá là dài từ công đoạn tiếp nhận yêu cầu cho đến công đoạn bàn giao cho khách hàng, thời gian này thường kéo dài từ 6 tháng đến 1 năm. Vì thời gian phát triển khá là dài như vậy thì rất có thể sẽ gặp các rủi ro sau:

• Đến lúc bàn giao mới phát hiện ra những sai sót như: chức năng bị lỗi, hoạt động được nhưng không như mong muốn từ khách hàng… Và để chỉnh sửa thì sẽ rất mất nhiều chi phí vì phạm vi chỉnh sửa có thể rất lớn và quy trình chỉnh sửa khá nhiều khâu: cập nhật documents, test case, unit test… Agile có thời gian phát triển ngắn hơn rất nhiều, khoản từ 2 tuần nên khi xảy ra các sai lầm thì phạm vi chỉnh sửa sẽ nhỏ hơn rất nhiều

• Có thể mất đi một lượng khách hàng tiềm năng của sản phẩm vì đối thủ đã tung ra sản phẩm tương đương trong thời gian chúng ta mải lo phát triển sản phẩm, hoặc xu hướng của người dùng đã thay đổi sau một thời gian dài. Agile thì ngược lại, luôn đặt mục tiêu tiếp cận với người dùng sớm nhất có thể, khả năng đón nhận và giải quyết vấn đề từ người dùng là thước đo cho sự thành công của sản phẩm.

• Tình trạng nghẽn cổ chai về điều phối nhân sự trong một team Waterfall cũng là một vấn đề khá nan giải: có những giai đoạn bộ phận phân tích và thiết kế rất bận rộn và các bộ phận lập trình viên và quản lý chất lượng phải chờ đợi, có những giai đoạn bộ phận lập trình viên lại quá tải… Với Agile, việc tương tác liên tục giữa lập trình và kiểm tra với thời gian ngắn nhất có thể, không ưu tiên về tài liệu sẽ làm giảm tối đa tình trạng thắt cổ chai này.

Ngoài ra, với một quy trình nhiều công đoạn, dẫn đến phân chia nhiệm vụ tách bạch giữa các bộ phận khác nhau từ phương thức quản lý Waterfall, khi gặp sự cố thì tình trạng đùn đẩy công việc và trách nhiệm giữa các bộ phận thường xảy ra: do làm tài liệu sai, do lập trình kém nên lỗi nhiều, do kiểm thử không cẩn thận… Team Agile sẽ nhìn nhận sự việc như là một sai lầm gặp phải và sẽ học hỏi được gì từ sai lầm đó, xác định nguyên nhân, tìm giải pháp và toàn bộ team sẽ vượt qua sai lầm đó.

Một vấn đề với Waterfall mà bạn sẽ gặp phải khi dự án rơi vào tình trạng khó khăn về deadline, chất lượng… là xem khách hàng như GIẶC NGOÀI, tìm cách đối phó với các yêu cầu của khách hàng bằng hợp đồng, bằng mail, bằng tài liệu… để từ chối hoặc giảm tính năng của phần mềm. Còn Agile thì sẽ luôn hướng tới sự hợp tác với khách hàng, đón nhận những yêu cầu thay đổi dù là muộn màng nhất, làm sao để phần mềm tạo ra giá trị tốt nhất có thể.

Tuy nhiên, Agile cũng sẽ có một số vấn đề cần đạt được để có thể vận hành tốt

• Sẽ tồn tại những cá nhân không muốn thay đổi mà chỉ mong muốn làm việc với những kỹ năng và kiến thức đã biết trước đó
• Công ty cần luôn hướng đến sự thay đổi để phát triển
• Có cách vận hành và quản lý tốt nhất để đáp ứng sự thay đổi liên tục này

Chúng tôi đã xây dựng một team Agile như thế nào?

Training cẩn thận từng thành viên trong công ty từ các kiến thức về khởi nghiệp, kỹ thuật đến kỹ năng mềm.

• LEAN Startup:
  https://www.marketenterprise.vn/blog/gioi-thieu-sach-the-lean-startup.html
• 7 thói quen hiệu quả:
  https://www.marketenterprise.vn/blog/gioi-thieu-sach-7-thoi-quen-hieu-qua.html
• Cách giao tiếp hiệu quả LOW CONTEXT & HIGH CONTEXT: https://www.marketenterprise.vn/blog/lam-the-nao-de-giao-tiep-hieu-qua.htm
  https://www.marketenterprise.vn/blog/lam-the-nao-de-giao-tiep-hieu-qua-ky-2.html

• Pair/Mob programming:
  https://www.marketenterprise.vn/blog/pair-programing-va-mob-programing.html
  https://www.marketenterprise.vn/blog/pair-programing-va-mob-programing-part-2.html

• Các kiến thức kỹ thuật: docker, php, golang, python, vuejs, reactjs, mysql, mongodb…
• Và không thể thiếu đó là các kiến thức về Agile

Chúng tôi đã vận hành Agile ra sao

Trước tiên, tôi sẽ giới thiệu qua một số khái niệm liên quan:

• ITERATOR là những lặp đi lặp lại để phát triển dự án, thời gian mỗi lặp đi lặp lại này là khoảng 2 tuần, có thể ít hơn hoặc nhiều hơn tuy sự thống nhất của team. Mỗi lặp đi lặp lại này sẽ bao gồm: nhận yêu cầu, thiết kế, phát triển, kiểm tra và phát hành…
• ISSUE là các vấn đề liên quan đến dự án được thu thập từ nhiều nguồn khác nhau: người dùng cuối, product owner, developer, tester hoặc pm… thông tin của ISSUE cần giữ nguyên trạng thái ban đầu, không chỉnh sửa, hạn chế sử dụng các từ chuyên môn. 

Ví dụ:

1/ Tôi thấy cái site này chạy chậm quá.
2/ Tôi là admin, tôi muốn chỉnh sửa quyền của các user khác nhưng mà không biết cách nào thực hiện.

• USER STORY là những kịch bản, tài liệu sơ giản mô tả mục tiêu giải quyết vấn đề người dùng, cần viết rõ ràng, không sử dụng từ ngữ mơ hồ, có thể sử dụng từ ngữ chuyên môn nhưng hãy hạn chế, đảm bảo nguyên tắc INVEST. Ví dụ: 1/ Kiểm tra xem site chạy có chậm hơn 3 giây không? Nếu chậm hơn hãy cải thiện nó. 2/ Hãy thêm chức năng mà Admin có thể chỉnh sửa quyền cho các user khác với điều kiện là user khác có quyền thấp hơn Admin. Tôi gợi ý rằng chúng ta có thể thêm một màn hình mới với URL là. /users/roles

• BACKLOG là danh sách các USER STORY mà team dự định thực hiện cho mỗi  ITERATOR

• KANBAN là một bảng gồm các nhãn để theo dõi USER STORY đã được làm tới bước nào, các nhãn này tuỳ dự án mà team thống nhất. Ví dụ: New, Doing, Review, Done, Release…

• Development Team là những người tham gia vào các công đoạn phát triển sản phẩm gồm pm, designer, developer, tester, comtor…

• Owner Team: là những bộ phận hỗ trợ sự phát triển sản phẩm: CEO, CTO, marketing, operator, Investor, client…

• Trade off sliders là một công cụ sử dụng thanh trượt để mô tả trực quan những vấn đề cần ưu tiên trong mỗi ITERATOR. Ví dụ: cần ưu tiên chất lượng (chất lượng là khái niệm khá rộng nên hẹn các bạn dịp khác để thảo luận về nó) USER STORY, cần ưu tiên số lượng USER STORY xử lý trong ITERATOR này…

• Planning Poker: là những lá bài với các điểm số để đánh giá độ phức tạp của USER STORY

• DASHBOARD: là sử dụng các số liệu liên quan đến hoạt động của dự án để report đến tất cả những người liên quan trong dự án: số lượng USER STORY đã giải quyết, số lượng ISSUE đã thu thập, số lượt người truy cập, số lượt người mua hàng…

Chúng tôi bắt đầu một ITERATOR với một buổi meeting, trong buổi meeting này chúng tôi sẽ có 3 việc chính nhất:

1/ Đánh độ ưu tiên để thống nhất tầm nhìn của tất cả thành viên trong team: nên ưu tiên vấn đề gì: thời gian, chất lượng, số lượng, chi phí… bằng công cụ Trade off sliders

2/ Lựa chọn những USER STORY sẽ thực hiện trong ITERATOR

3/ Đánh giá độ phức tạp của từng USER STORY bằng Planning Poker, các thành viên cùng cho điểm số, nếu có sự khác nhau thì mỗi thành viên sẽ giải thích, PM dự vào các thông tin nhận được sẽ quyết định cuối cùng

Trong quá trình phát triển của mỗi ITERATOR, chúng tôi tiếp tục thu thập ISSUE, tiếp tục mở ra các cuộc meeting khi gặp vấn đề khó khăn. Sau khi thu thập ISSUE, vai trò của pm là phải xác định được ISSUE đó cần thiết để xử lý hay không, nếu cần xử lý thì sẽ viết USER STORY cho ISSUE đó. Mỗi thành viên sẽ luôn chủ động tìm kiếm giải pháp để thực hiện USER STORY mà mình đảm nhận, nếu cần lời khuyên, mọi người trong team sẽ giúp đỡ, nếu vượt quá năng lực của team thì sẽ nhờ OWNER hỗ trợ. Các USER STORY có độ phức tạp cao hoặc cần tiếp cận công nghệ mới, chúng tôi thường sử dụng hình thức Pair/Mob programming để xử lý và qua đó cũng nâng cao skill cho các thành viên trong team lên mức ngang bằng nhau.

Đến cuối mỗi ITERATOR, chúng tôi sẽ tổ chức một cuộc họp để nhìn nhận lại kết quả của ITERATOR đó, số lượng USER STORY đã được xử lý, số lượng truy cập từ người dùng (sử dụng DASHBOARD), các thành tích đáng khen và đặc biệt là những những vấn đề khó khăn cũng như sai lầm mà team đã gặp phải, đưa ra giải pháp để giải quyết, tránh tình trạng lặp lại ở các ITERATOR sau cũng như ở các dự án khác. Trong buổi meeting này, chúng tôi tuyệt đối tuân thủ sử dụng LOW CONTEXT để thảo luận với nhau.

Kết quả mà chúng tôi đạt được?

• Các thành viên chủ động hơn, phát triển nhanh hơn khi tự mình tìm kiếm giải pháp để giải quyết vấn đề: các thành viên đều có thể làm fullstack sau khoảng 3 tháng tham gia dự án
• Các vấn đề liên quan đến nhóm cũng như dự án đã được phát hiện và xử lý sớm nhất có thể: giao tiếp trong team, giao tiếp với owner, dự án làm một số chức năng không cần thiết, …
• Dự án release liên tục, nhận phản hồi sớm từ owner, sau đó là khách hàng.