Agile là gì? Tổng quan về Agile Scrum

>> Xem ngay khóa học Agile Scrum với nhóm giảng viên uy tín nhất Việt Nam sắp khai giảng

Agile là gì? Scrum là gì? Agile và Scrum có phải là một? Hiểu Agile là một quy trình phát triển phần mềm có đúng không? Bài viết này sẽ giúp bạn làm sáng tỏ tất cả các câu trả lời và giải thích những giá trị cốt lõi nhất của Agile để bạn hoàn toàn có thể hiểu đúng về Agile và Scrum.

Agile là gì?

Agile thực chất  là một triết lý hay một khung tư duy để nhanh chóng thích ứng và phản hồi với thay đổi, từ đó đạt được thành công trong một môi trường liên tục biến động và không chắc chắn.

Làm ngay bài Quiz test để biết bạn đang hiểu Agile đến đâu. 

Triết lý Agile xuất phát từ ngành công nghệ, và đượ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 hay Tuyên ngôn Agile (The Manifesto for Agile Software Development)  mà chúng ta sẽ tìm hiểu phía sau.

 

Triết lí Agile cho đến ngày nay không chỉ đã làm thay đổi diện mạo nền công nghệ thế giới nói riêng mà đang lan tỏa mạnh mẽ và thể hiện giá trị trong rất nhiều lĩnh vực như: Quản lý dự án (với Agile Project Management), nhân sự (với Agile HR và Agile People), marketing (với Agile Marketing), hay quản trị và lãnh đạo (với Agile Management, Agile Leadership)…

 

Agile Software Development là gì?

agile là gì

Agile Software Development là một thuật ngữ chung chỉ tất cả các kỹ thuật và phương pháp phát triển phần mềm theo triết lý Agile.

 

Triết lý Agile được mô tả sơ bộ trong bản Tuyên ngôn Agile (The Manifesto for Agile Software Development) thông qua những giá trị cốt lõi và nguyên tắc có tính phổ quát, tuy nhiên không ghi rõ thực hiện những giá trị và nguyên tắc ấy như thế nào. Vì vậy các phương pháp Agile sẽ làm nhiệm vụ định nghĩa rõ hơn để các cá nhân và tập thể dễ dàng vận dụng vào bối cảnh công việc của mình. Các phương pháp này đều 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 nhằm thích ứng nhanh với sự thay đổi – một điểm yếu cố hữu của các phương pháp phát triển phần mềm truyền thống (waterfall)

 

Dưới đây chúng ta sẽ tìm hiểu về lịch sử ra đời của Tuyên ngôn Agile  và một số phương pháp Agile phổ biến nhất.

 

Tuyên ngôn Agile (Agile Manifesto) 

1, Lịch sử ra đời của tuyên ngôn Agile

Agile ra đời trong bối cảnh ngành phát triển phần mềm gặp nhiều thử thách với cách thức phát triển truyền thống theo mô hình thác nước (waterfall), hoặc dựa theo kế hoạch (plan-driven). 

Đặc trưng của những những phương pháp này là tiếp cận tuyến tính,thực hiện tuần tự các bước theo kế hoạch. Tuy nhiên trong thực tế rất nhiều rủi ro không thể tiên lượng trước. Một trong những lý do chính đó là khách hàng thường xuyên thay đổi yêu cầu (requirement) trong quá trình sản xuất. Nguyên nhân thường do khách hàng không biết mình cần gì cho đến khi trực tiếp sử dụng sản phẩm hoặc cũng có thể những yêu cầu ban đầu đã lỗi thời và không đáp ứng được mục tiêu kinh doanh. Khi yêu cầu thay đổi, toàn bộ các bước thiết kế và phát triển, kiểm thử, viết lại tài liệu…phải tiến hành lại.  Kết quả là sản phẩm làm ra không đúng yêu cầu của khách hàng, bị trễ thời gian, hoặc quá ngân sách.

 

Cuộc khủng hoảng phương pháp luận phát triển phần mềm vào thập kỉ 90 của thế kỉ XX diễn ra chứng kiến một tỷ lệ thất bại của các dự án phần mềm rất cao. Kết quả là từ ngày 11-13 tháng 2 năm 2001, 17 nhà phát minh và nhà thực hành đã họp với nhau tại bang Utah, Hoa Kỳ để thảo luận về hướng đi mới trong phương pháp luận phát triển phần mềm. Họ đã đi đến thống nhất và cho ra đời bản Tuyên ngôn Agile (The Manifesto for Agile Software Development) và đánh dấu một xu thế mới trong phát triển phần mềm. 

 

Nội dung của bản tuyên ngôn Agile đã trở thành triết lý dẫn đường cho các phương pháp Agile sau này, cụ thể như sau:

2, Tuyên ngôn phát triển phần mềm linh hoạt (gọi tắt là tuyên ngôn Agile)

Chúng tôi đã phát hiện ra cách phát triển phần mềm tốt hơn bằng cách thực hiện nó và giúp đỡ người khác thực hiện. Qua công việc này, chúng tôi đã đi đến việc đánh giá cao:

 

  • Individuals and interactions over processes and tools: Cá nhân và sự tương tác hơn là quy trình và công cụ
  • Working software over comprehensive documentation: Phần mềm chạy tốt hơn là tài liệu đầy đủ
  • Customer collaboration over contract negotiation: Cộng tác với khách hàng hơn là đàm phán hợp đồng
  • Responding to change over following a plan: Phản hồi với sự thay đổi hơn là bám theo kế hoạch

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.

3, Mười hai nguyên tắc phía sau tuyên ngôn Agile

Bên cạnh đó, các nhà phát triển còn nhấn mạnh mười hai nguyên lý phía sau Tuyên ngôn Agile để giúp các nhà phát triển có được gợi ý trong thực hành và vận dụng các phương pháp Agile trong thực tiễn. Các nguyên lý được liệt kê sau đây:

 

  1. Ưu tiên cao nhất của chúng tôi là thỏa mãn khách hàng thông qua việc chuyển giao sớm và liên tục các phần mềm có giá trị.
  2. Chào đón việc thay đổi yêu cầu, thậm chí rất muộn trong quá trình phát triển. Các quy trình linh hoạt tận dụng sự thay đổi trong các lợi thế cạnh tranh của khách hàng.
  3. Thường xuyên chuyển giao phần mềm chạy tốt tới khách hàng, từ vài tuần đến vài tháng, ưu tiên cho các khoảng thời gian ngắn hơn.
  4. Nhà kinh doanh và nhà phát triển phải làm việc cùng nhau hàng ngày trong suốt dự án.
  5. Xây dựng các dự án xung quanh những cá nhân có động lực. Cung cấp cho họ môi trường và sự hỗ trợ cần thiết, và tin tưởng họ để hoàn thành công việc.
  6. Phương pháp hiệu quả nhất để truyền đạt thông tin tới nhóm phát triển trong nội bộ nhóm phát triển là hội thoại trực tiếp.
  7. Phần mềm chạy tốt là thước đo chính của tiến độ.
  8. Các quy trình linh hoạt thúc đẩy phát triển bền vững. Các nhà tài trợ, nhà phát triển và người dùng có thể duy trì một nhịp độ liên tục không giới hạn.
  9. Liên tục quan tâm đến các kỹ thuật và thiết kế tốt để gia tăng sự linh hoạt.
  10. Sự đơn giản – nghệ thuật tối đa hóa lượng công việc chưa xong – là căn bản.
  11. Các kiến trúc tốt nhất, yêu cầu tốt nhất và thiết kế tốt nhất sẽ được làm ra bởi các nhóm tự tổ chức.
  12. Nhóm phát triển sẽ thường xuyên suy nghĩ về việc làm sao để trở nên hiệu quả hơn, sau đó họ sẽ điều chỉnh và thay đổi các hành vi của mình cho phù hợp. 

 

Bạn có thể tìm hiểu kỹ hơn về nội dung bản tuyên ngôn tại đây

Các phương pháp Agile 

Như đã đề cập ở trên, Agile có thể có nhiều phương pháp để áp dụng thực hành khác nhau, nhưng triết lý chung thì giống nhau. Theo khảo sát của VersionOne năm 2020, tỉ lệ áp dụng các phương pháp Agile được mô tả trong biểu đồ dưới đây: 

Chúng ta cùng điểm qua về một số phương pháp Agile (gọi chung với phạm vi rộng hơn để chỉ cả phương pháp, khung quản trị, kỹ thuật thực hành) phổ biến nhất trong số này:

 

  • Scrum: theo Tài liệu Hướng dẫn Scrum (The Scrum Guide) được 2 nhà đồng sáng lập Ken Schwaber and Jeff Sutherland định nghĩa, là một khung làm việc (framework) để phát triển bền vững các sản phẩm phức tạp. Có thể nói Scrum là một trong những phương pháp Agile quan trọng nhất sử dụng cơ chế lặp (iterative) và tăng trưởng (Incremental) để tối ưu hóa hiệu quả cũng như kiểm soát rủi ro. Chúng ta sẽ tìm hiểu chi tiết về Scrum ở phần II của series bài viết về nhập môn Agile và Scrum.
  • Kanban: là một phương pháp Agile dựa trên Phương thức Sản xuất Toyota với bốn nguyên lý: Trực quan hóa công việc, giới hạn công việc đang làm, tập trung vào luồng làm việc, cải tiến liên tục. Mô hình Kanban phù hợp cho việc hỗ trợ sản xuất trong quá trình làm việc.  Tìm hiểu thêm về Kanban tại đây.
  • Scrumban: là một phương pháp được Corey Ladas giới thiệu vào năm 2009 trong cuốn sách với tựa đề “Scrumban – Essays on Kanban Systems for Lean Software Development”. Scrumban kết hợp được những ưu điểm của Scrum và Kanban để cho phép nhóm liên tục cải tiến quy trình và khả năng xử lý công việc.
  • Lean Software Development (LSD): hay Phát triển phần mềm tinh gọn là hình thức áp dụng Tư duy tinh gọn (Lean Thinking) và các nguyên lý đặc trưng của Tinh gọn (xuất phát từ ngành sản xuất ô tô – Lean Manufacturing) cho lĩnh vực phát triển phần mềm. Thuật ngữ Lean Software Development có nguồn gốc từ một cuốn sách cùng tên của Mary Poppendieck và Tom Poppendieck. Trong đó, bảy nguyên lý diễn giải tư duy Tinh gọn bao gồm: Loại bỏ lãng phí, Khuếch trương việc học, Quyết định càng muộn càng tốt, Chuyển giao càng nhanh càng tốt, Trao quyền cho nhóm, Tạo ra tính toàn vẹn tự thân, Thấy toàn cảnh là linh hồn cho quá trình phát triển phần mềm tinh gọn. Tìm hiểu thêm về Lean Software Development tại đây.

 

  • XP (Extreme Programming) – Hay lập trình cực hạn là một phương pháp phát triển phần mềm thuộc họ Agile được phát minh bởi Ken Beck – một kỹ sư phần mềm người Mỹ. XP hướng đến việc nâng cao chất lượng phần mềm và khả năng đáp ứng với thay đổi yêu cầu người dùng. XP chủ trương đưa ra các bản phát hành thường xuyên thông qua các chu trình phát triển ngắn. Một số các thực hành của XP như:  Lập trình cặp (Pair programming), Tái cấu trúc mã nguồn (Refactoring), Kiểm thử đơn vị (Unit Testing), Tích hợp liên tục (Continuous Integration), Các bản phát hành nhỏ (Small Release)…. Tìm hiểu thêm về XP tại đây

 

Có thể nhận thấy, trong số các phương pháp Agile, Scrum thuộc loại phổ biến nhất bởi sự hiệu quả và tối ưu của nó. Theo khảo sát ở trên, Scrum và các phương pháp lai với Scrum như Scrumban, Scrum và XP chiếm gần ¾ mức độ phổ biến. Đó là lí do rất nhiều nhóm bắt đầu quá trình tiếp nhận Agile với việc sử dụng Scrum.

Lợi ích khi áp dụng Agile

Agile là triết lý với các phương pháp mới thay thế cho phương pháp theo mô hình truyền thống (Waterfall) đã khẳng định vị thế khi đem đến cho cá nhân và tổ chức những lợi ích nhất định. Vậy những lợi ích đó là gì, tạo sao thế giới đang chuyển mình rất nhanh để thích ứng với Agile? Khảo sát của VersionOne năm 2020 về việc triển khai Agile đã cho thấy có sự cải thiện trong các lĩnh vực sau:

Báo cáo CHAOS của Standish Group năm 2015 đã cho thấy các dự án Agile so với các dự án truyền thống (Waterfall) có tỷ lệ thành công cao hơn 3 lần. Cụ thể trong bảng dưới đây:

 

Quy mô dự án Phương pháp Thành công Thử thách Thất bại
Tổng kết Agile 39% 52% 9%
Waterfall 11% 60% 29%
Lớn Agile 18% 59% 23%
Waterfall 3% 55% 42%
Vừa Agile 27% 62% 11%
Waterfall 7% 68% 25%
Nhỏ Agile 58% 38% 4%
Waterfall 44% 45% 11%

Đặc điểm của các phương pháp Agile

  • Tính lặp (Iterative): Trong khi dự án thực hiện, các phân đoạn sẽ được lặp đi lặp lại (Interation hoặc Sprint). Các phân đoạn này diễn ra trong thời gian ngắn (thường từ một đến bốn tuần). Trong mỗi phân đoạn này, nhóm phát triển thực hiện đầy đủ các công việc cần thiết như lập kế hoạch, phân tích yêu cầu, thiết kế, triển khai và kiểm thử để có được phần nhỏ của sản phẩm. Các phương pháp Agile sẽ không lập kế hoạch dài hạn, thay vào đó sẽ phân chia thành những quá trình lập kế hoạch nhỏ, đơn giản và gọn nhẹ.

 

  • Tính tăng trưởng (Incremental): Cuối mỗi phân đoạn (Sprint), nhóm phát triển thường cho ra các phần nhỏ của sản phẩm cuối cùng. Các phần nhỏ này thường đáp ứng được các yêu cầu, có khả năng chạy tốt do đã được kiểm thử cẩn thận và có thể sử dụng được ngay. Theo thời gian, các phân đoạn sẽ tiếp nối nhau và tích lũy dần tới khi toàn bộ yêu cầu của khách hàng được thỏa mãn. Khác với mô hình truyền thống Waterfall – vốn chỉ cho phép nhìn thấy sản phẩm tới khi gần hoàn thành dự án, sản phẩm trong dự án Agile sẽ được phát triển lớn dần theo thời gian, tăng trưởng cho tới khi đạt được trạng thái đủ để phát hành.

 

  • Vòng phản hồi ngắn và thích ứng thường xuyên: Do các phân đoạn chỉ kéo dài trong một khoảng thời gian ngắn, việc lập kế hoạch hay có những điều chỉnh, thay đổi trong quá trình phát triển đều có thể đáp ứng nhanh để phù hợp. Ngoài ra, việc khách hàng được tham gia vào các quy trình phát triển cũng sẽ giúp ích cho việc đáp ứng và thay đổi ngay những yêu cầu khác từ phía khách hàng. 

 

  • Giao tiếp thường xuyên và hiệu quả: Trong các nhóm Agile luôn đề cao việc giao tiếp thường xuyên và trực diện hơn là việc trao đổi qua tài liệu, giấy tờ. Các nhóm phát triển cũng thường chỉ ở quy mô nhỏ (đối với Scrum là từ 3-9 người), từ đó sẽ đơn giản hóa được quá trình giao tiếp và thúc đẩy hợp tác hiệu quả hơn. 

 

  • Hướng chất lượng: Đảm bảo chất lượng tuyệt đỉnh luôn là một yêu cầu quan trọng trong triết lý Agile. Rất nhiều kỹ thuật và công cụ được sử dụng để hướng đến việc nâng cao chất lượng sản phẩm, chẳng hạn như: Tích hợp Liên tục, Kiểm thử Đơn vị Tự động, Lập trình cặp, Phát triển Hướng Kiểm thử, Mẫu Thiết kế, Tái cấu trúc mã nguồn, v.v..
  • Phát triển dựa trên giá trị:

Một trong những nguyên tắc cơ bản của Agile chính là “phần mềm chạy tốt là thước đo chính của tiến độ”. Nguyên tắc này giúp nhóm luôn cố gắng để đạt được kết quả cuối và có thể bỏ đi những công việc dư thừa không trực tiếp đem lại giá trị cho sản phẩm. 

 

Theo cách tiếp cận truyền thống, phạm vi công việc sẽ cố định, thời gian và chi phí sẽ thay đổi để hoàn thành được phạm vi công việc. Theo cách tiếp cận của các phương pháp Agile, thời gian và chi phí sẽ là những phần cố định, khi đó các nhóm Agile luôn cộng tác trực tiếp và thường xuyên với khách hàng để liên tục ưu tiên những hạng mục tạo ra nhiều giá trị nhất. Nguyên tắc này giúp nhóm dám loại bỏ đi các công việc dư thừa không trực tiếp mang lại giá trị cho sản phẩm rút ngắn thời gian để đi đến sản phẩm cuối cùng.Nhờ đó, các dự án Agile luôn gia tăng được sự hài lòng của khách hàng và cho ra những sản phẩm tối ưu nhất.

Một số câu hỏi phổ biến về Agile và Scrum

 

1- Hỏi:  Agile và Scrum có phải là một?

    Trả lời: Scrum là một phương pháp Agile (phổ biến nhất) nhưng không phải là Agile. Agile định nghĩa các giá trị cốt lõi và nguyên tắc định hướng, còn Scrum là một phương pháp cụ thể chia sẻ các nguyên tắc đó. Scrum và một số phương pháp định hình và ra đời trước Agile, nhưng Agile lại là tiếng nói chung, là nguyên lý của các phương pháp này.

 

2- Hỏi: Triết lý Agile chỉ áp dụng cho phát triển phần mềm?

  Trả lời: Agile không chỉ ảnh hưởng trong Phát triển phần mềm (Agile Software Development) mà còn đang thể hiện giá trị trong các lĩnh vực khác như:

  • Quản lý dự án: Agile Project Management
  • Nhân sự: Agile HR và Agile People
  • Marketing: Agile Marketing
  • Quản trị: Agile Management
  • Lãnh đạo: Agile Leadership
  • Sản xuất: Agile Manufacturing
  • Giáo dục: EduScrum, Agile Classroom
  • Khởi nghiệp: Lean Startup
  • Thiết kế (Lean UX, Design Thinking)
  • Gia đình: Agile Family
  • Cá nhân: Personal Kanban & Agile Mindset

 

3- Hỏi: Agile Project Management và Agile Business Analysis là gì?

 

Trả lời: Như đã nói ở trên, Agile được hiểu là một triết lý hay một khung tư duy để nhanh chóng thích ứng và phản hồi với thay đổi.

 

Vì vậy khi chúng ta nói đến Agile Project Management và Agile Business Analysis, hãy đặt câu hỏi rằng “Đâu là cách chúng ta thực hiện dự án hay phân tích nghiệp vụ mà cho phép chúng ta thích ứng với sự thay đổi và sống chung với những điều không chắc chắn”. 

 

“Scrum dễ hiểu nhưng khó tinh thông” 

Chúng tôi – Những Scrum Trainer có một thử thách đó là lượng kiến thức về Scrum khá lớn – nhưng người học khi được giới thiệu luôn cảm giác rằng nó đơn giản chỉ là 1 vài khái niệm nhỏ. Đó là lý do tại sao ai khi học Scrum cũng như mình đã biết rồi, nhưng khi áp dụng hoặc thảo luận cứ thấy bị thiếu lý luận. Có một số người còn rơi vào tình trạng không phân tích được thiệt hơn cho từng chi tiết của Scrum và chỉ có thể nói đó là quy định. Đó là khi bạn đang ở mức “được nghe” về Scrum chứ chưa thực sự “hiểu” Scrum.

Vậy làm sao chúng tôi có thể giúp anh chị em với những kinh nghiệm và kiến thức nền khác nhau làm được. Nhiệm vụ của giảng viên phải liên tục chuyển học viên nhìn toàn bộ kiến thức ở mức độ tổng quan, sau đó lại đi vào vấn đề cụ thể. Do đó giảng viên phải không chỉ có nhiều kinh nghiệm ở những nhóm, loại hình công ty khác nhau mà còn phải yêu cầu rất cao ở kiến thức quản trị để có thể liên kế, lý giải những yêu cầu về mặt quy tắc, quy trình của Scrum, Agile.

Đó lí do mà chúng tôi được anh Tạ Vũ Long – CEO của Pirago (https://pirago.vn) nói “Mọi người vẫn bảo Scrum dễ hiểu nhưng khó tinh thông. Khóa học Pragmatic Scrum giúp mình giải đáp được những thắc mắc mà chưa được giải quyết trong suốt 2 năm sử dụng Scrum.”

Từ đó Học Viện Agile đã lựa chọn phương pháp giảng dạy theo phương pháp lặp và tăng trưởng để người học tiếp nhận kiến thức dần, cũng như chúng tôi có cơ hội xác nhận được kiến thức của mỗi học viên đang là đúng hay sai.

Chúng ta xem ví dụ để học về nhiệm vụ của Scrum Master.

Bước 1) Giảng tổng quan về Scrum và các vai trò trong vòng 15′ cùng với một case study ở một công ty cụ thể. Sau phần này, hầu hết học viên đều có cảm giác rằng mình đã hiểu.

Bước 2) Các học viên làm một bài kiểm tra trên hệ thống Kahoot để mỗi học viên ôn tập và tìm ra những hiểu nhầm của mình.

Bước 3) Giảng viên giải thích chi tiết trách nhiệm, công việc và minh họa một ngày điển hình của mỗi vai trò để học viên đi vào chi tiết. Lúc này học viên thực sự cảm giác như mình đã hiểu hết chương trình. Nhưng hãy khoan, hầu hết vẫn còn nhiều hiểu lầm.

Bước 4) Lớp học luôn có một hoạt động, ở đó mỗi nhóm học viên là một nhóm chuyên gia, tư vấn cho một tình huống cần viết mô tả công việc cho từng vai trò. Khi mỗi nhóm làm việc này, lời giải của mỗi học viên sẽ được thảo luận trong nhóm, sau được phản hồi của các nhóm khác cũng như nhìn lời giải của nhóm khác và sau cùng được giảng viên chữa bài. Tổng cộng mỗi học viên được chữa bài tới ít nhất 3 lần ở bước 4 này. Bạn đã nghĩ học viên hiểu kỹ chưa?

Bước 5) Còn một thử thách gần cuối cùng là đưa ra những tình huống khó nhưng khá phổ biến như Scrum Master kiêm nhiệm để cả lớp đưa ra phân tích thiệt hơn.

Bước 6) Bài kiểm tra cuối cùng để xác nhận lần cuối học viên đã hiểu.

Cách thiết kế như thế này, chúng tôi đã được sự ghi nhận của anh Hoàng Phan Bảo Trung – CEO của DEHA Software: “Những anh em đi học bài bản thay vì tự học giúp cho việc áp dụng hiệu quả hơn rất nhiều vì tránh được nhiều hiểu nhầm nhỏ – nhưng quan trọng trong quá trình làm việc”.

Liên hệ ngay tư vấn viên đào tạo: 

Ms. Trang Nhung

Email:   vivian@hocvienagile.com
             096-997-2469