Gobiz có áp dụng tư duy Agile trong quy trình làm việc hay không?

Ở Việt Nam, loại mô hình phát triển phần mềm được rất nhiều các doanh nghiệp hoạt động trong lĩnh vực sản xuất phần mềm, gia công phần mềm (software outsourcing), các startup về công nghệ, các ngân hàng và công ty bảo hiểm áp dụng, đó là AGILE.

Có thể hiểu một cách đơn giản Agile là mô hình phát triển linh hoạt, dựa trên phương thức lặp (iterative) và tăng trưởng (incremental). Trong đó khuyến khích việc lập kế hoạch thích ứng, phát triển tăng dần, chuyển giao sớm và cải tiến liên tục. Agile được mô tả bằng 4 giá trị và 12 nguyên lý cốt lõi trong Tuyên ngôn phát triển phần mềm linh hoạt (Tuyên ngôn Agile).

## Vậy tại Gobiz, có đang áp dụng tư duy Agile trong quy trình làm việc hay không?

Nhiều người đặt câu hỏi như thế này, vì thấy chúng tôi có dùng SCRUM – hoặc có thể là SCRUMBut hay là một biến thể nào đó của SCRUM. Và Gobiz có đội ngũ “được gọi là SM” triển khai các quy trình Agile.

Thế nhưng, chỗ này chỗ kia người ta cảm thấy rằng không đúng. Rằng như thế không phải là Agile, như thế là sai rồi. Cũng không đúng là SCRUM luôn. SCRUM Master cũng chả phải SCRUM Master. Burndown chart thì không có, SCRUM cái nỗi gì chứ?

Hây. Chúng tôi – hoặc ít nhất là tôi, người phụ trách và chịu trách nhiệm cho toàn bộ những thứ ở trên, không quan tâm đến điều đó đâu. Nếu ai đó cho rằng chúng tôi Agile, thì chúng tôi là Agile. Nếu ai đó cho rằng chúng tôi không hề Agile, thậm chí phản Agile, thì chúng tôi là phản Agile. Với chúng tôi điều đó không quan trọng.

Và thực ra, nói chúng tôi có Agile, cũng đúng, vì nếu chiếu theo 4 cái gạch đầu dòng được gọi là tuyên ngôn Agile, thì chúng tôi đang hướng đến đúng như vậy. Nói chúng tôi không phải Agile vì vi phạm điều A khoản B gì đó của bộ luật Agile, cũng đúng luôn, chẳng sai gì cả và chúng tôi không phủ nhận những điều mà chúng tôi “phạm luật”.

Nhưng nếu như có điều gì mà cá nhân tôi thích nhất ở cái được gọi là tư duy Agile, đó là: Quan trọng là kết quả, chứ không phải nguyên tắc hay quy trình.

Và chúng tôi cũng chỉ quan tâm tới kết quả. Cái gì đem lại hiệu quả thì chúng tôi làm. Agile thì Agile. Waterfall thì waterfall. Chữ V thì chữ v. Miễn sao nó phù hợp là được. Cũng xin đừng “gán nhãn” cho chúng tôi làm gì. Vì tất cả mọi quy tắc làm việc, hay quy trình, hay bất kỳ thứ gì đi chăng nữa, chẳng phải đều hướng đến một mục đích cuối cùng là kết quả hay sao?

> Cái chúng tôi quan tâm là kết quả. Việc tranh luận gọi tên nó là Agile hay không Agile không đem lại giá trị gì cả nếu như không đem đến được hiệu quả tốt hơn.

## Agile đối với cá nhân tôi là gì?

Agile đối với bản thân tôi nó có nghĩa là “linh hoạt”, mà linh hoạt thì có nghĩa là có thể làm bất kỳ điều gì để đạt được kết quả. Do đó tự bản thân tôi thì thấy chúng tôi đã và đang thực hành Agile.

Và một thực tế là cũng chẳng có một cái gì gọi là bộ luật Agile cả. Các bạn có thể đi tìm kiếm khắp nơi, nhưng trong những tài liệu chính thống nhất bao giờ cũng chỉ dùng đến khái niệm tư duy Agile, hoặc cùng lắm là phương pháp Agile; và sau đó là những Best practices khi thực hành Agile.

Ngay trong chính cái gọi là tuyên ngôn Agile cũng chỉ có 4 cái gạch đầu dòng, cùng với 1 đoạn giải thích rằng chúng tôi đánh giá cao vế bên trái nhưng không có nghĩa là bỏ qua vế bên phải. Mà như thế, có nghĩa là cần phải linh hoạt theo từng trường hợp, chứ không thể áp dụng 1 cách duy nhất cho tất cả mọi trường hợp được.

Cũng giống như mỗi cá nhân là một sự khác biệt, mỗi tập thể cũng là một sự khác biệt, không thể giống nhau hoàn toàn được. Vậy thì cũng không có một quy trình “Agile” nào gọi là thống nhất cho tất cả các cá nhân, tập thể để thực hành theo được. Bản thân SCRUM cũng chỉ là 1 framework chứ không phải là 1 sản phẩm cuối cùng. Tất nhiên, nếu bạn nói chúng tôi không Agile, tôi sẽ không phản bác gì, nhưng các bạn cũng đừng bắt buộc chúng tôi phải thế này hay thế kia.

Những thứ đó, có thể phù hợp với bạn, và có thể phù hợp với 99% đi chăng nữa, thì vẫn có thể chúng tôi nằm ở 1% còn lại.

> Đối với tôi, Gobiz có thực hành Agile, theo cái nghĩa “linh hoạt” chứ không phải theo một bộ luật Agile nào cả.

## Làm thế nào để linh hoạt?

Linh hoạt, không có nghĩa là không có nguyên tắc.

Ngay cả bản thân đội ngũ của chúng tôi, cũng có người bảo tư duy là “sai thì sửa” cơ mà, vậy thì cứ sai đi. Điều đó là hoàn toàn không phù hợp.

Tôi không biết là nó đúng hay không đúng với bộ luật Agile. Nhưng theo tôi thì tư duy cần có là sẵn sàng thử sai để có được phản hồi từ phía khách hàng, chứ không phải dù biết là nó sai nhưng vẫn làm vì “sai thì sửa”. Biết sai mà vẫn làm không gọi là linh hoạt, mà có một khái niệm khác dành cho nó, là “ngu”.

Cũng không phải cứ viện cớ “linh hoạt”, mà làm việc không theo bất kỳ một nguyên tắc nào. Thực ra, để “linh hoạt” được thì có nghĩa là phải cực kỳ tuân thủ nguyên tắc. Chỉ có điều những nguyên tắc đó được đưa về dạng nguyên lý cơ bản nhất, để có thể có nhiều cách thực hiện khác nhau mà không vi phạm nguyên tắc đặt ra ban đầu. Dù sao, ít nhất nguyên tắc cơ bản đầu tiên của mọi phương pháp, mọi quy trình, đó đều là “ra kết quả”.

So sánh, thực ra nó cũng giống như một khái niệm thường được sử dụng ở các team có áp dụng Agile là Acceptance Criteria. Chỉ cần thỏa mãn AC, thì cách làm như thế nào không cần phải bám quá sát. Như vậy chính là nguyên tắc, nhưng cũng chính là linh hoạt.

Như vậy, theo tôi, để có thể linh hoạt được, thì chúng ta cần phải thực sự biết cách tuân thủ nguyên tắc. Nếu không thì sẽ không còn là linh hoạt nữa, mà là vô tổ chức, và một khi đã vô tổ chức, thì kết quả cuối cùng sẽ không thể nào nắm bắt được.

> Linh hoạt có nghĩa là có thể sử dụng nhiều biện pháp, nhưng vẫn tuân thủ theo những nguyên tắc cơ bản. Chính nguyên tắc sẽ đem lại sự linh hoạt.

P/S: Nếu như các bạn chưa có bất kỳ nguyên tắc nào cảm thấy có thể dùng làm nguyên tắc cơ bản, không sao cả, chính bản thân tuyên ngôn Agile cũng là 1 nguyên tắc cơ bản có thể bám vào.

Nguyễn Xuân Kiên – CEO @Gobiz

———–
✅ Gobiz – Phần mềm Quản lý nhập hàng đa quốc gia
📞 Hotline: 0388.432.436
🔎 Fanpage: Gobiz.vn
🔎 Youtube: Gobiz vn
🔎 Zalo OA: Gobiz
🔎 Linkedin: Gobiz Việt Nam