Những khái niệm và giá trị cốt lõi của Agile – Scrum

278

Tăng năng suất lao động toàn FPT IS lên 20% là một trong những OKR trong năm 2019 của FPT IS. Để thực hiện mục tiêu này, đòi hòi Ban lãnh đạo và toàn thể cán bộ nhân viên phải liên tục cải tiến, rút ngắn quy trình, giảm thời gian thực hiện nhưng vẫn cần đảm bảo hiệu quả công việc.

Đa số các dự án đã và đang triển khai tại FPT IS thường phải đối mặt với các vấn đề “tính đúng hạn”, “sự thay đổi”. Tìm hiểu về các nguyên lý triển khai dự án trên thế giới, Ban quản lí sản xuất đã có những nguyên cứu về Agile – Scrum và thử nghiệm áp dụng trong 1 số dự án tại FPT IS với kỳ vọng chúng sẽ là một trong số giải pháp giúp FPT IS giải quyết bài toán trên.

Để có cái nhìn khái quát về Agile, phương pháp Scrum và cách ứng dụng, dưới đây là một số thông tin cơ bản nhất về Agile – Scrum.

1. Agile là gì?

Agile là khả năng đáp ứng cho việc phát sinh và phản hồi các thay đổi. Nó là một cách đối ứng và hướng tới mục tiêu cuối cùng là thành công trong bối cảnh tràn đầy sự không chắc chắnhỗn loạn.

Các tác giả của “Tuyên ngôn Agile” đã chọn “Agile” là tên cho ý tưởng này nhằm nhấn mạnh về vai trò của sự thích ứng và phản ứng đối với sự thay đổi trong phương pháp phát triển phần mềm mà họ áp dụng.

“Nó” thực sự thấu hiểu những gì bạn đang phải trải qua trong môi trường phát triển phần mềm ngày nay, giúp xác định những “thứ không chắc chắn” mà bạn có thể gặp phải, từ đó tìm ra cách để thích nghi với những điều đó trong quá trình “nó” đồng hành cùng bạn.

Phát triển phần mềm Agile không chỉ là những framework như Scrum, XP,… hay chỉ đơn giản là các phương pháp thực nghiệm như Pair-programming, TDD, stand-ups meeting, sprint,…

Phát triển phần mềm Agile là một thuật ngữ chung, bao quát chung (hình tượng chiếc ô) gồm các framework và các thói quen, tập tục xây dựng dựa trên các giá trị và nguyên tắc được trình bày trong “Tuyên ngôn Agile” và “12 nguyên tắc” đi kèm với nó. “Nó” không phải là một công thức hay một quy trình cố định, khi bạn tiếp cận với “nó” cần căn cứ thêm tình hình và bối cảnh thực tế bạn đang có, thích nghi là một từ khóa quan trọng mà bạn cần lưu ý.

Nguồn: https://www.agilealliance.org

2. Scrum là gì?

Scrum là một tập hợp gồm giá trị, nguyên tắc và các phương pháp thực nghiệm; nhẹ nhưng vô cùng mạnh mẽ.

Scrum dựa vào nhóm “liên chức năng” để cung cấp sản phẩm, dịch vụ trong các chu kỳ ngắn và cho phép:

  • Phản hồi nhanh;
  • Cải tiến liên tục;
  • Thích ứng nhanh với sự thay đổi;
  • Giao hàng nhanh.

Về cơ bản, Scrum hoạt động bằng cách chia sản phẩm và dịch vụ lớn thành các phần nhỏ, có thể hoàn thành (và có khả năng phát hành) bởi một nhóm “liên chức năng” trong một “khung thời gian” ngắn.

Các nhóm Scrum kiểm tra từng “lô” sản phẩm khi nó được hoàn thành, và sau đó điều chỉnh kế hoạch tiếp theo dựa trên qua trình học tập, phản hồi giúp giảm thiểu rủi ro và lãng phí. Chu kỳ này lặp đi lặp lại cho đến khi toàn bộ sản phẩm được cung cấp với đúng thứ mà khách hàng muốn vì doanh nghiệp có cơ hội điều chỉnh độ phù hợp của sản phẩm ở cuối mỗi “khung thời gian”.

Nguồn: https://www.scrumalliance.org – Tổ chức cung cấp chứng chỉ về Scrum hàng đầu thế giới.

Scrum đã được thử nghiệm ở trời Tây từ thập niên 90 của thế kỷ 20. Về cơ bản, Scrum đã và đang được sử dụng ở khá nhiều ông lớn mà chúng ta ít nhất đã từng nghe tên 1 vài lần như: Yahoo, Nokia, Microsoft, Google, Philips, BBC, Siemens, Intuit,… Tại Việt Nam, hầu hết các công ty/start-up công nghệ đều đã áp dụng Agile, trong đó FPT Software, Vietel, VinID là 3 doanh nghiệp lớn tại Việt Nam áp dụng Agile – Scrum trong phát triển sản phẩm, SI, outsource.

Tính đến nay, đã gần 20 năm trôi qua kể từ khi “Tuyên ngôn Agile” ra đời. Nó vẫn tồn tại và được các công ty lớn trên thế giới áp dụng, chứng tỏ nó vẫn có giá trị nào đó trong ngành phát triển phần mềm.

3. Ứng dụng Agile vào dự án

3.1. Mục đích là gì?

Một câu hỏi tưởng như đơn giản, chúng ta có thể kể đến hàng vài trang giấy, lý do mà chúng ta muốn làm một thứ gì đó, nhưng tốt nhất nên để nó rõ ràng và súc tích, dễ hiểu và dễ truyền thông. Ví dụ như “Áp dụng để tránh lạc hậu, vì lạc hậu nghĩa là chết” là một lý do rất hay và có vẻ rất thành thật, đôi khi ta không cần gì nhiều hơn thế, một thứ ta chưa biết rõ, nhưng nó đã thành công ở “trời tây” từ gần 2 chục năm trước. Hoặc có thể là lý do rất vui vẻ như “Sếp tôi muốn anh em OT nhiều hơn và tự giác hơn”,…

Rõ ràng việc “bịa” ra mục đích rất đơn giản, nhưng để phù hợp với tư tưởng Agile, để khả thi thì nên ngắn gọn. Đó có thể là lý do mà các icon đại diện cho các từ khóa “mục đích”, “mục tiêu”… thường là hình bia ngắm và có hồng tâm rõ ràng. Khi mục đích được xác định tốt, “Ngọn hải đăng” đã được dựng lên thì các “con thuyền” sẽ giảm thiểu đáng kể khả năng “lạc đường”.

Ở đây chúng ta không bàn quá sâu về tác dụng của mục đích, nó quá rõ ràng. Hãy cùng nhấn mạnh rằng, mục đích cho việc áp dụng Agile nên được đưa ra một cách ngắn gọn, thành thật. Đôi khi tôi cảm thấy Agile sinh ra là để dành cho OKR (Objectives and Key Results – Quản lí theo mục tiêu) vì điều này.

3.2. Nó có phù hợp với dự án không?

Không có một lời giải hoàn mỹ cho tất cả các bài toán, nếu có, ngành Toán học nợ tất cả học sinh một lời xin lỗi với 12 năm học toán phổ thông, rồi 4 năm đại học. Cả Agile và tư tưởng quản trị dự án truyền thống đều chưa chắc phù hợp với tất cả các loại dự án, tất nhiên là khi ghép vào dự án ta đều có cách cho nó hoạt động, nhưng từ khóa ở đây là “Sự phù hợp”. Có thể hiểu rằng dùng dao bổ củi để điêu khắc cũng được, nhưng mà nó không dễ bằng dùng dao tỉa, hoặc bạn có thể dùng nồi cơm điện để nấu toàn bộ món ăn như thời sinh viên, từ luộc rau, tráng trứng, xào thịt, rồi cuối cùng mới là chức năng chính của nó là nấu cơm. Rõ ràng là LÀM ĐƯỢC nhưng nó KHÔNG PHÙ HỢP.

Xét về việc Agile phù hợp với những loại dự án nào, ta cần một công cụ, tiêu chí để đánh giá dự án thuộc loại nào sau đó mới có thể quyết định. Chúng ta có Cynefin.

Cynefin là một công cụ phân chia độ phức tạp với các phân vùng tạm dịch như sau:

  • Obvious: Rõ ràng.
  • Complicated: Rắc rối.
  • Complex: Phức hợp.
  • Chaotic: Hỗn loạn.

Chúng ta có bảng nhận dạng các loại dự án và cách đối ứng như sau:

Độ phức tạpĐặc điểm nhận dạngĐối ứng
Rõ ràng
  • Các khuôn mẫu (Pattern) và sự kiện lặp đi lặp lại.
  • Các bên liên quan đều nhìn rõ mối quan hệ nhân-quả.
  • Có một câu trả lời đúng đắn.
  • Mọi người biết rõ những thứ cần biết và không có vùng Unknow.
  • Quản lý theo thực tế (Fact-based management).
Sử dụng best practice

  • Phán đoán trước phân loại sau rồi phản hồi.
  • Sử dụng quy trình chuẩn.
  • Ủy quyền.
  • Sử dụng best practices.
  • Truyền đạt rõ ràng và trực tiếp.
  • Giao tiếp 2 chiều có thể không cần thiết.
Rắc rối
  • Cần chuyên gia phân tích.
  • Có thể nhận biết quan hệ nhân quả nhưng không rõ ràng như Hiển nhiên.
  • Có nhiều hơn một câu trả lời.
  • Có vùng Unknow nhưng mọi người biết và kiểm soát được vùng Unknow.
  • Quản lý theo thực tế.
Sử dụng Waterfall

  • Phán đoán trước, phân tích sau rồi phản hồi.
  • Thiết lập đội chuyên gia.
  • Lắng nghe các lời khuyên.
Phức hợp
  • Thay đổi liên tục và không thể tiên lượng.
  • Không có câu trả lời đúng đắn, các khuôn mẫu hoạt động được phát hiện dần trong quá trình làm.
  • Mọi người không gọi tên được những điều mình chưa biết, có vùng Unknow nhưng không biết rõ trong đó có gì và cần gì để xóa bỏ nó.
  • Rất nhiều ý tưởng đối nghịch nhau.
  • Cần những tiếp cận sáng tạo, đột phá
  • Lãnh đạo dựa trên khuôn mẫu (Pattern-based leadership).
Sử dụng Agile

  • Thử nghiệm trước, phán đoán sau rồi phản hồi
  • Tạo môi trường thử nghiệm cho phép các khuôn mẫu xuất hiện.
  • Tăng mức độ giao tiếp và tương tác hai chiều.
  • Dùng các phương pháp để tạo lập nhiều ý tưởng như thảo luận mở, khuyến khích các nhân tố thu hút, khuyến khích sự bất đồng quan điểm và sự đa dạng, quản lý và giám sát các ý tưởng này để hình thành nên khuôn mẫu.
Hỗn loạn
  • Nhiễu loạn cao độ.
  • Không rõ quan hệ nhân-quả, thậm chí không có điểm nào để tìm kiếm manh mối.
  • Hoàn toàn không có tầm nhìn, toàn bộ đều là vùng Unknow.
  • Phải ra nhiều quyết định gấp mà không có thời gian suy nghĩ.
  • Lãnh đạo dựa trên khuôn mẫu.
Không có gợi ý

  • Hành động trước, phán đoán sau rồi phản hồi.
  • Quan sát xem cái nào hiệu quả thay vì tìm kiếm một câu trả lời duy nhất.
  • Hành động dứt khoát để vãn hồi trật tự (mệnh lệnh và kiểm soát).
  • Truyền đạt rõ ràng và trực tiếp.

3.3. Quy trình và framework

Khi bạn đã có mục đích, đã xác định được độ phù hợp, về mặt mindset chúng ta cơ bản đã thông qua. Nhưng mindset là chưa đủ để một bộ máy hoạt động, chúng ta còn cần quy trình và công cụ.

Thật nghịch lý khi chúng ta gọi tên Agile như một sự linh động, thích ứng mà lại áp dụng máy móc quy trình cho toàn bộ các dự án. Cùng nhìn lại tuyên ngôn Agile, có một điều trong đó là “Cá nhân và tương tác hơn là quy trình và công cụ” nhưng hãy để ý một câu không được bôi đậm cuối cùng “Mặc dù các điều bên phải vẫn còn giá trị, nhưng chúng tôi đánh giá cao hơn các mục ở bên trái”.

Chính nhóm tác giả của Agile cũng “rào trước đón sau” để mọi người không hiểu nhầm, không có những suy nghĩ lệch lạc như “quy trình là không cần thiết” hay “face to face là vạn năng”. Bằng chứng là Scrum, nó là một trong số các framework xây dựng dựa trên Agile được nhiều người sử dụng nhất. Scrum có một bộ “dây chuyền sản xuất” gần như khép kín, một loạt các hạn chế về SCRUM BUT, hay một loạt các nguyên tắc áp dụng được viết thành trong “Scrum guide”. Hoặc nếu bạn có tìm hiểu về Scrum, bạn sẽ thấy các sự kiện thường diễn ra trong một thời điểm cố định trong chu kỳ, tạo thói quen, ảnh hưởng tới người thực hiện một cách vô thức,…

Hãy cùng nhấn mạnh lại điều này: Cá nhân và tương tác hơn là quy trình và công cụ, nhưng quy trình và công cụ vẫn có giá trị, và vẫn phải có.

3.4. Scrum Framework

Scrum là một framework không tồi để làm theo Agile.

Đây là một framework nổi tiếng, mức độ sử dụng cao hơn 50% trong số rất nhiều framework được xây dựng dựa trên Agile. Gọi là framework bởi nó bao gồm các best-practices, trải qua quá trình thí nghiệm, thực tế và người ta rút ra bài học kinh nghiệm rằng, các sự kiện, các tạo tác, các vai trò trong đây là thích hợp nhất, là khuôn mẫu cho các dự án khác áp dụng theo, rất vô lý khi cho rằng khuôn mẫu này sẽ phù hợp cho mọi dự án. Đó là suy nghĩ ban đầu của khá nhiều người khi nghĩ “Tôi sắp phải sử dụng Scrum”. Rõ ràng là ý kiến này đúng, như đã nêu phía trên, “không có lời giải hoàn mỹ cho mọi bài toán” nhưng bạn cần hiểu rõ về nó, ứng dụng thực tế và rút kinh nghiệm trước khi sửa đổi nó cho phù hợp với môi trường của bạn. Bạn không thể rót trà vào chiếc chén đặt cao hơn miệng ấm, đi tắt đón đầu thường để lại nhiều khoảng rỗng và rủi ro nghiêm trọng sau này.

Tóm lại ở phần này, bạn hãy áp dụng nghiêm túc Scrum trước khi rút kinh nghiệm và sửa đổi nó cho phù hợp hơn với môi trường của bạn.

Trần Duy Tiến – FPT IS

Tin liên quan: