Agile là gì? (Phần 1)

Agile là gì? (Phần 1)
Bạn nghe nói nhiều về Agile và muốn biết Agile là gì? Trong phần đầu này, tôi sẽ giới thiệu về lịch sử ra đời Agile và đưa ra định nghĩa ngắn gọn về Agile.
Agile là gì? (Phần 1)

I. Cuộc khủng hoảng đầu thập niên 1990

  • Quy trình phát triển phần mềm không phù hợp

waterfall-394x300

Mô hình kiểu thác nước (waterfall)

Được giới thiệu vào năm 1970 bởi Winston Royce, mô hình thác nước (Waterfall) chia việc phát triển phần mềm thành các giai đoạn tuần tự. Mỗi giai đoạn được thiết kế để thực hiện một hoạt động cụ thể và phải được hoàn thành trước khi giai đoạn tiếp theo có thể bắt đầu mà không có sự chồng chéo giữa các giai đoạn.

Mô hình trên có thể được sử dụng được khi:

1. Yêu cầu được mô tả rõ ràng và không thay đổi thường xuyên

2. Công nghệ ổn định, ít biến động

3. Nhân sự được đào tạo và sẵn sàng hoàn thành công việc

Nhưng thực tế là:

1. Một dự án phần mềm thường có hơn 35% yêu cầu ban đầu sẽ phải thay đổi.

2. Các công nghệ chưa từng sử dụng hoặc phải thay đổi trong quá trình thực hiện dự án.

3. Nhân sự có trình độ kỹ năng khác nhau, thái độ làm việc khác nhau, cách thực hiện công việc cũng rất khác nhau và khó dự đoán.

  • Kết quả các dự án làm theo mô hình waterfall

Chaos-waterfall-473x300

Báo cáo của Chaos, năm 1994

Báo cáo CHAOS năm 1994 cho thấy gần 84% số dự án được mô tả là thất bại một phần hoặc hoàn toàn, trong khi chỉ có khoảng 16% tổng số dự án được phân loại là thành công.

Các vấn đề phổ biến khiến dự án thất bại là:

  • Thời gian phát hành chậm
  • Trể hẹn
  • Khó đáp ứng với các thay đổi đưa ra ở giữa thời gian phát hành
  • Việc lập kế hoạch mất quá nhiều thời gian nhưng không chính xác
  • Mất nhiều thời gian để sản phẩm ổn định sau khi phát hành
  • Chất lượng ngày càng giảm sút

Nguyên nhân thất bại - phân tích từ đồ thị Stacey

Đồ thị Stacey là một công cụ hữu ích để đánh giá tính chắc chắn hoặc khả năng dự đoán của công việc. Nó có thể được sử dụng để mô hình hóa ba chiều trong phát triển phần mềm: yêu cầu, công nghệ và con người.

stacey-341-300

 

 

 

 

 

 

 

 

 

Đồ thị Stacey

Yêu cầu: Từ “làm theo thỏa thuận”, không có rủi ro thay đổi  ==> “khác xa với thỏa thuận”, hay các mô tả mơ hồ và có nhiều thay đổi.

Công nghệ: Từ “gần như chắc chắn” ==> “rất ít chắc chắn” liên quan nhiều công nghệ khác nhau trong các dự án phức tạp.

Con người: Từ “biết rõ và ổn định” với một số lượng nhỏ người trong một nhóm  ==> các dự án phần mềm liên quan đến hơn năm người, hoặc hàng trăm người và hay thay đổi.

Như vậy, sử dụng đồ thị Stacey, chúng ta thấy rằng các dự án phát triển phần mềm ít nhất là ở vùng phức tạp và đôi khi đến vùng hỗn loạn. Như vậy, mô hình waterfall khó mà giải quyết được các vấn đề phức tạp và biến động trong phát triển sản phẩm phần mềm.

II. Cách tiếp cận tăng trưởng và lặp lại (iterative & incremental)

Vào những năm 1990, nhiều phương pháp phát triển phần mềm kiểu mới ra đời để vận hành các dự án phần mềm phức tạp. Các phương pháp mới dựa trên lý thuyết kiểm soát quy trình thực nghiệm hay còn gọi là chủ nghĩa kinh nghiệm. Chủ nghĩa kinh nghiệm khẳng định kiến thức có được từ kinh nghiệm và đưa ra quyết định dựa trên những gì đã biết.

Các phương pháp mới sử dụng cách tiếp cận lặp đi lặp lại, gia tăng để tối ưu hóa khả năng dự đoán và kiểm soát rủi ro.

iterative-360x200

Agile iterative-incremental delivery

Scrum

Scrum đã được sử dụng để quản lý công việc trên các sản phẩm phức tạp từ đầu những năm 1990 sau đó được xuất bản vào năm 1995 bởi hai đồng sáng lập Jeff Sutherland và Ken Schwaber.

sprint-350x250

Tham khảo thêm bài viết “Scrum là gì

Crystal Method

Crystal Method được phát triển bởi Alistair Cockburn vào những năm 1990, là một nhóm các phương pháp Agile tinh gọn. Chúng được coi là tinh gọn bởi vì những phương pháp này xem quy trình là thứ yếu và thay vào đó đặt trọng tâm vào các yếu tố khác. Các yếu tố này là:

  • People (con người)
  • Interaction (tương tác)
  • Community (cộng đồng)
  • Skills (kỹ năng)
  • Talents (tài năng)
  • Communications (giao tiếp)

Crystal có tám màu sắc khác nhau, tượng trưng cho "tầm quan trọng" của dự án. Tám màu sắc này là:

  1. Crystal Clear
  2. Crystal Yellow
  3. Crystal Orange
  4. Crystal Orange Web
  5. Crystal Red
  6. Crystal Maroon
  7. Crystal Diamond
  8. Crystal Sapphire

Một dự án nhỏ, đơn giản có thể sử dụng phương pháp như Crystal Clear, Crystal Orange hoặc Crystal Yellow. Nếu dự án là một nhiệm vụ quan trọng, nơi tính mạng con người có thể bị đe dọa thì các phương pháp Crystal Diamond hoặc Crystal Sapphire sẽ được sử dụng.

Nếu dự án không liên quan đến nguy cơ tiềm ẩn đến tính mạng con người mà chỉ thay đổi về số lượng con người. Crystal sử dụng 5 màu sắc khác nhau tương ứng với 5 quy mô của dự án.

crystal-colors-800x17405 màu sắc tướng ứng với 5 quy mô khác nhau của dự án Crystal

Các phương pháp Crystal cùng chia sẻ 7 thuộc tính:

1. Phát hành thường xuyên (frequent delivery)

Thường xuyên cung cấp phần mã đã qua kiểm thử, làm việc được cho người dùng thực. Bằng cách này, nhà phát triển sản phẩm đảm bảo đã không đầu tư sức lực và thời gian vào sản phẩm mà không ai muốn mua.

2. Cải tiến (Reflective improvement)

Với phương pháp Crystal, ý tưởng về các nhóm tổ chức các cuộc họp cải tiến vài tuần một lần được khuyến khích. Các cuộc họp này giúp tìm ra các quy trình đang hoạt động không tốt và giúp nhóm sửa đổi chúng.

3. Giao tiếp gần/thẩm thấu (Close or osmotic communication)

Giao tiếp thẩm thấu nghĩa là thông tin hữu ích chảy giữa các thành viên trong nhóm khi họ làm việc gần nhau và họ tình cờ nghe được các cuộc trò chuyện của nhau.

Nhóm phải ở trong cùng một phòng để thông tin được truyền đi nhanh chóng trong nhóm. Các câu hỏi có thể được trả lời nhanh chóng và tất cả các thành viên trong nhóm đều biết chuyện gì đang xảy ra cũng như có khả năng sửa chữa mọi quan niệm sai lầm có thể phát sinh.

Chi phí giao tiếp được giảm đáng kể bằng cách sử dụng loại hình giao tiếp này. Nhu cầu cập nhật email, tài liệu bổ sung, v.v. được giảm xuống. Bằng cách tập hợp nhóm lại với nhau, mỗi thành viên biết những người khác đang làm gì để họ có thể đảm nhận các phần của đồng đội trong dự án nếu cần.

4. Môi trường an toàn (Personal safety)

Môi trường an toàn, mọi người không e ngại chia sẻ quan điểm cá nhân và thoải mái lên tiếng về các vấn đề hoặc bất cứ điều gì phát sinh.

5. Sự tập trung (Focus)

Tập trung vào công việc để đạt được tiến độ và tập trung mục tiêu chung của dự án

6. Dễ dàng tiếp cận người dùng chuyên gia (Easy access to expert users)

Điều này liên quan đến việc các nhà phát triển làm việc với một chuyên gia trong lĩnh vực dự án để chuyên gia trả lời bất kỳ câu hỏi nào, đề xuất giải pháp cho các vấn đề, v.v. Người dùng chuyên gia phải là người dùng thực tế chứ không chỉ là tester từ nhóm phát triển.

7. Môi trường kiểm thử tự động và tích hợp thường xuyên (Technical environment with automated tests, configuration management and frequent integration

Ý tưởng đằng sau điều này là cần có sự tích hợp và kiểm thử liên tục để nếu có bất kỳ thay đổi nào xảy ra thì các lỗi, sự cố, v.v. có thể được phát hiện. Nếu điều này được thực hiện thường xuyên, các sự cố ít xảy ra hơn vì chúng đã được phát hiện và xử lý sớm trong dự án.

(Nguồn: Wikiversity)

Extreme Programming (XP)

XP là một phương pháp phát triển phần mềm đặt trọng tâm vào sự hài lòng của khách hàng. Điều này đảm bảo rằng những gì đang được sản xuất dựa trên nhu cầu của khách hàng. Một trong những cách để thực hiện điều này là chuyển đổi câu chuyện người dùng (user stories) thành sản phẩm kinh doanh có giá trị (valuable business assets).

Một đặc điểm quan trọng của phương pháp XP là giao tiếp liên tục và cởi mở. Nếu không có khía cạnh quan trọng này, việc áp dụng sẽ không hiệu quả như mong đợi. Một lợi ích quan trọng của phong cách giao tiếp này là tăng sự tự tin cho cả khách hàng và nhóm dự án.

XP được tạo ra để đáp ứng nhu cầu trên thị trường nhằm đáp ứng những thay đổi liên tục mà các nhà cung cấp dịch vụ đang phải đối mặt trong khi phát triển một sản phẩm hoặc dịch vụ mới. Thành công của nó có thể là do khía cạnh giao tiếp và hợp tác giữa tất cả các bên tham gia vào dự án. Điều này có nghĩa là khách hàng, người quản lý, các nhóm và bất kỳ ai khác có liên quan sẽ làm việc cùng nhau từ thời điểm thiết lập phạm vi, câu chuyện người dùng, cho đến kiểm thử và phát hành cuối cùng.

Phương pháp này được thiết kế cho các dự án nhỏ, mặc dù cũng được áp dụng thành công ở các dự án lớn.

Extreme Programming (XP) làm việc như thế nào?

XP-815x250

Bước đầu tiên trong XP là thu thập các user stories cũng như tiến hành các giải pháp thử nghiệm với các user stories có rủi ro cao.

Sau đó, một cuộc họp lập kế hoạch phát hành phải được lên lịch. Ở giai đoạn này, phải mời tất cả những người quan trọng bao gồm khách hàng, các nhóm dự án và người quản lý. Mục tiêu chính ở giai đoạn này là xác định một mục tiêu chung mà mọi người đều có thể chấp nhận được. Cuộc họp và thiết lập mục tiêu này được theo sau bởi các cuộc họp lập kế hoạch lặp đi lặp lại để thống nhất về các bản phát hành tiếp theo.

Chỉ với vài bước này, nhóm dự án đã đi theo hướng phát triển các tính năng cần thiết.

Các quy tắc của XP (XP rules)

1. Lập kế hoạch

  • Thiết lập user stories
  • Lập kế hoạch phát hành
  • Các bản phát hành nhỏ.
  • Thiết lập các chu trình.
  • Lập kế hoạch chu trình

2. Quản lý

  • Dành không gian mở và dành riêng cho nhóm dự án
  • Thiết lập tốc độ bền vững
  • Tổ chức cuộc họp standup hàng ngày
  • Đo tốc độ dự án
  • Chia sẻ kiến thức
  • Cải tiến quy trình

3. Thiết kế

  • Chú trọng sự đơn giản
  • Chọn một ẩn dụ hệ thống
  • Sử dụng thẻ CRC cho các phiên thiết kế
  • Tạo ra các phiên bản thử nghiệm để giảm thiểu rủi ro
  • Không thêm chức năng sớm
  • Tái cấu trúc mã bất cứ khi nào và bất cứ nơi nào có thể

4. Viết mã

  • Khách hàng luôn luôn sẵn sàng
  • Mã phải được viết theo các tiêu chuẩn đã thống nhất
  • Viết mã kiểm thử đơn vị (unit test) trước
  • Tất cả các mã sản xuất được lập trình cặp (pair-programming)
  • Chỉ duy nhất một cặp được tích hợp mã tại một thời điểm
  • Tích hợp thường xuyên
  • Thiết lập một máy tính dành cho tích hợp mã
  • Đồng sở hữu code (collective ownership)

5. Kiểm thử

  • Tất cả các mã phải có unit test
  • Tất cả mã phải trải qua unit test trước khi được phát hành
  • Khi một lỗi được tìm thấy, tạo ra các bước kiểm thử
  • Kiểm thử chấp nhận được chạy thường xuyên và công bố kết quả cho nhóm dự án

Các giá trị trong XP (XP values)

1. Giao tiếp

Mọi người đều là một phần của nhóm và giao tiếp với nhau hàng ngày trong công việc.

2. Đơn giản

XP khuyến khích làm những gì cần thiết và được yêu cầu, không làm thêm. Điều này giúp tối đa hóa giá trị mang lại cho khoản đầu tư.

3. Phản hồi

XP công bố phần mềm của mình sớm, lắng nghe cẩn thận các phản hồi và thực hiện bất kỳ thay đổi nếu cần thiết.

4. Sự dũng cảm

Sự dũng cảm thể hiện ở việc nói thật về tiến độ và ước tính, không nêu lý do cho sự thất bại, và sẵn sàng thích ứng với những thay đổi.

5. Tôn trọng

Mọi thành viên đều được tôn trọng như nhau vì những cống hiến và đóng góp có giá trị dù chỉ đơn giản là sự nhiệt tình. Nhóm phát triển tôn trọng chuyên môn của khách hàng và ngược lại.

Nguồn: extremeprogramming.org

DSDM (Dynamic Systems Development Method)

DSDM là một khung làm việc tập trung vào toàn bộ vòng đời của dự án, chỉ những công việc tối thiểu được thực hiện ở mỗi bước rồi chuyển tiếp cho bước tiếp theo. Tư duy đằng sau điều này là để thích nghi với những thay đổi liên tục của các dự án. Chẳng hạn, yêu cầu kinh doanh có thể thay đổi ngay lập tức, do đó, chỉ thực hiện các công việc cần thiết để tiết kiệm được công sức, nguồn lực và thời gian của nhóm dự án.

Các nguyên tắc của DSDM

  1. Sự tham gia tích cực của người dùng là bắt buộc
  2. Nhóm DSDM phải được trao quyền để đưa ra quyết định
  3. Phát hành sản phẩm thường xuyên
  4. Sự phù hợp yêu cầu kinh doanh là tiêu chí cần thiết để chấp nhận các sản phẩm được giao
  5. Phát triển lặp lại và gia tăng là cần thiết để tạo ra sản phẩm đúng
  6. Mọi thay đổi trong quá trình phát triển đều có thể đảo ngược
  7. Các yêu cầu được cố định ở mức “high-level”
  8. Kiểm thử được tích hợp trong suốt vòng đời
  9. Một cách tiếp cận hợp tác và tương tác giữa tất cả các bên liên quan là cần thiết

Nguồn: Agile Business Consortium

III. Sự ra đời của Agile

Tất cả các phương pháp mới đều có điểm chung là tinh gọn, chú trọng vào yếu tố con người, đề cao tinh thần làm việc theo nhóm, phát hành phần mềm thường xuyên,  hợp tác với khách hàng và khả năng phản ứng nhanh với sự thay đổi.

agile-values-518x165

Từ ngày 12/2-14/2 năm 2001, 17 nhà sáng lập và chuyên gia trong lĩnh vực phát triển phần mềm đã gặp nhau tại một khu nghỉ mát ở Snowbird, Utah để bàn về các phương pháp phát triển kiểu mới. Sau nhiều lần thảo luận, họ đã tìm thấy sự đồng thuận xung quanh bốn giá trị cốt lõi, hình thành tuyên ngôn Agile về phát triển phần mềm, được tất cả những người tham gia ký kết.

agile-manifesto-750x450

Agile manifesto 2001

Xem lại bản gốc tuyên ngôn Agile tại https://agilemanifesto.org/

Xem 12 nguyên lý đằng sau tuyên ngôn Agile tại https://agilemanifesto.org/principles.html

Xem thêm phần giải thích các giá trị và nguyên tắc của Agile ở bài viết “Agile là gì?” phần 2.

IV. Lời kết - Agile là gì?

Agile trước hết không phải là quy trình, công cụ, hay phương pháp. Agile là tư duy, triết lý, cách tiếp cận mới đề cao con người và hướng đến việc xây dựng các nhóm dự án hay tổ chức mang lại sản phẩm, dịch vụ tốt nhất cho khách hàng, có khả năng thích nghi nhanh với sự thay đổi.

Scrum, XP, Crystal, DSDM là các công cụ triển khai tư duy và triết lý Agile. Một công cụ có thể phù hợp ở môi trường hoặc sản phẩm này nhưng có thể không làm việc tốt với môi trường hoặc sản phẩm khác. Tuy nhiên, nếu hiểu đúng và vận dụng thành thạo tư duy Agile, bạn có thể tự xây dựng quy trình, công cụ hoặc phương pháp phù hợp với tổ chức hoặc nhóm dự án của bạn.

agile-umbrella-359x300

Agile umbrella

Cảm ơn các bạn đã đọc bài viết này.

Đón đọc Agile là gì? (phần 2) - Ý nghĩa tuyên ngôn Agile và 12 nguyên lý đằng sau bản tuyên ngôn Agile

Nếu bạn có câu hỏi, đánh giá, hay góp ý cho tác giả, xin vui lòng để lại comment bên dưới.

About Khiem Huynh
About Khiem Huynh

Khiêm có hơn 13 năm thực hành Agile Scrum, là một chuyên gia Scrum đã sở hữu chứng chỉ PSM III. Với nhiều năm kinh nghiệm tư vấn, huấn luyện Agile cho các công ty lớn và tập đoàn đa quốc gia ở những lĩnh vực khác nhau, Khiêm có sự linh hoạt trong cách tiếp cận để phù hợp với đặc thù từng nhóm dự án, môi trường kinh doanh và văn hóa của tổ chức.