Xoá mù Agile và Scurm – Phần 1 – Tìm hiểu về Agile

Phần mềm không tự nó sinh ra cũng không tự nó nâng cấp, mà phải được phát triển và bảo trì bởi các lập trình viên. Nhiều qui trình được thành lập để giúp việc phát triển phần mềm trở nên dễ dàng và bài bản hơn.

Mỗi lập trình viên điều phải hiểu về các qui trình này để có thể làm việc một cách hiệu quả. Tuy nhiên, mình thấy đa số bạn sinh viên chỉ hiểu mang máng về các qui trình này. Một số bạn đã đi làm nhưng cũng chỉ mù quáng tuân theo qui trình mà không hiểu rõ mục đích cũng như ý nghĩa của nó.

Bài viết này sẽ cho bạn cái nhìn rõ ràng hơn về các qui trình phát triển phần mềm, cũng như cách các công ty áp dụng chúng trong thực tế.

Lưu ý: Bản thân Agile và Scrum là những chủ đề rất rộng, cần đến vài quyển sách và khóa học để nói về chúng. Trong phạm vi bài viết, mình chỉ đưa ra những điểm chính yếu để bạn đọc có nền tảng kiến thức và có thể tự tìm hiểu sâu hơn.

Qui trình phát triển phần mềm

Để hiểu hơn về Agile, trước hết ta hãy xem lại qui trình thường dùng để phát triển phần mềm. Qui trình này thường bao gồm 5 quá trình:

  1. Lấy yêu cầu (requirement) từ khách hàng
  2. Thiết kế hệ thống
  3. Developer phát triển hệ thống
  4. Tester kiểm thử hệ thống và để khách hàng xác nhận
  5. Bảo trì, sửa chữa hoặc thêm chức năng cho hệ thống

Với mô hình phát triển truyền thống (còn gọi là waterfall), các quá trình này được thực hiện tuần tự từ đầu đến cuối. Tuy nhiên, rất khó để lấy chính xác yêu cầu (requirement) của khách hàng ở giai đoạn đầu, vì họ thường không biết mình cần gì cho đến khi nhìn thấy sản phẩm (phần mềm).

Khi requirement thay đổi, ta phải làm lại các bước thiết kế và phát triển, kiểm thử, viết lại tài liệu… Kết quả là sản phẩm làm ra không đúng yêu cầu của khách hàng, hoặc bị trễ thời gian, quá ngân sách.

Sự ra đời của Agile

Vì lẽ đó, vào tháng 2 năm 2001, 17 nhân vật có tiếng tăm trong ngành phần mềm đã có một cuộc họp để tìm ra phương pháp xây dựng phần mềm tinh gọn, hiệu quả.

Thành quả của cuộc họp là một tấm hình tự sướng của vài người đàn ông chổng mông vào màn ảnh và một bản “Tuyên ngôn Agile”.

Ảnh gốc của Tuyên Ngôn Agile
Nội dung tuyên ngôn:

Cá nhân và tương tác hơn là quy trình và công cụ
 Phần mềm chạy tốt hơn là tài liệu đầy đủ
 Cộng tác với khách hàng hơn là đàm phán hợp đồng
 Phản hồi với thay đổi hơn là bám sát 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.

Bản dịch từ hocvienagile.com. Bản gốc từ: agilemanifesto.org

Những điểm hay của Agile

Sau khi Agile ra đời, nó nhanh chóng nhận được sự ủng hộ và đón nhận của cộng đồng. Tuân theo những nguyên lý Agile góp phần làm tăng tỷ lệ thành công của dự án. Bản thân Agile cũng mang lại những góc nhìn rất mới mẻ trong việc phát triển phần mềm:

  • Xây dựng phần mềm theo kiểu “cuốn chiếu”: Với Agile, ta phát triển phần mềm theo các iteration khoảng 2-4 tuần. Trong mỗi iteration, ta thực hiện đầy đủ các qui trình: lấy yêu cầu, thiết kế, code, test,… Sản phẩm được xây dựng dần dần nên khách hàng có thể thấy sản phẩm để đưa ra góp ý hoặc requirement mới.
  • Sự tham gia của khách hàng: Trong qui trình waterfall, ta chỉ lấy yêu cầu của khách hàng lúc ban đầu và đưa sản phẩm cho họ sau khi hoàn thành. Với Agile, ta trực tiếp đưa khách hàng tham gia vào việc phát triển phần mềm ở mỗi iteration. Khách hàng trực tiếp tham gia những buổi họp với cả nhóm.
  • Tập trung vào sản phẩm, phần mềm chứ không phải tài liệu: Một trong những yếu điểm của waterfall chính là phải viết quá nhiều tài liệu dư thừa trước khi viết code. Mỗi thay đổi từ requirement sẽ dẫn đến việc thay đổi cả tài liệu lẫn code, làm qui trình trở nên chậm chạp và nặng nề.
  • Coi trọng sự giao tiếp giữa các thành viên và tầm quan trọng của team: Thay cho các tài liệu khô cứng, việc nói chuyện trực tiếp, mặt đối mặt sẽ giúp trao đổi thông tin hiệu quả hơn
  • Giảm chi phí thay đổi: Bản chất của phần mềm là thay đổi. Tất cả những điều trên giúp góp phần giảm “Cost of Change” (Chi phí khi thay đổi). Với qui trình waterfall, rất khó để khách hàng thay đổi requirement sau khi hệ thống đã được design. Với Agile, ta phát triển dự án theo iteration ngắn nên khách hàng dễ dàng thấy được thành phẩm, đưa ra yêu cầu mới ở mỗi iteration.

Kết luận

Nhiều bạn thường lầm tưởng Agile và Scrum là một, nhưng thực ra không phải vậy:

  • Agile không phải là một qui trình hoàn thiện mà chỉ là một tập hợp các nguyên lý chung chung mà chúng ta nên tuân theo để phát triển phần mềm một cách uyển chuyển tinh gọn.
  • Dựa theo những nguyên lý của Agile, người ta đề ra những bộ khung (framework) hoặc qui trình phát triển phần mềm như: Lean, Kanban, XP, Crystal, Scrum.

Hiện tại, Scrum là qui trình phổ biến nhất và được áp dụng ở nhiều công ty phần mềm trong và ngoài nước. Cùng tìm hiểu về Scrum trong phần 2 nhé.

30s quảng cáo

book.jpg

Đây là một bài viết được trích dẫn từ cuốn sách “Code dạo kí sự – Lập trình viên đâu phải chỉ biết code” do mình viết. Quyển sách bao gồm những kĩ năng từ mềm đến cứng mà mỗi developer phải có, đảm bảo sẽ rất có ích cho các bạn sinh viên hoặc lập trình viên đã đi làm. Các bạn xem thông tin và đặt mua sách tại đây nhé: Sách Code Dạo Ký Sự.

11 thoughts on “Xoá mù Agile và Scurm – Phần 1 – Tìm hiểu về Agile”

  1. Thanks. Qua bài viết em phần nào hiểu được Agile là gì. Theo em hiểu thì Agile sẽ được áp dụng cho công ty và doanh nghiệp là chính. Còn đối với cá nhân, khi mình tự phát triển phần mềm cho mình thì có mô hình phát triển nào không anh?

    Like

  2. Mình cũng có khoảng 6 năm làm dự án, nhưng với các dự án mình tham gia thì không áp dụng agile và scrum vì 1 vài lý do:
    1. Dự án bị bắt buộc cam kết tiến độ theo 1 kế hoạch dự án có sẵn (thậm chí có khi nó xuất hiện ngay khi chưa biết rõ yêu cầu là gì).
    2. Khách hàng thường muốn rất nhiều (đôi khi chỉ là những thứ tưởng tượng theo kiểu “làm sẵn cho tương lai”), mình từ chối thì họ lại call cho sếp và sếp bảo phải làm.
    3. Đi kèm với 2 cái trên là, thường thì cho dù giải trình, giải thích các kiểu thì kế hoạch vẫn không được phép đổi.
    4. Yêu cầu thì thay đổi liên tục, nhưng lại bắt buộc bàn giao đủ và đúng tài liệu theo hạn định.
    Còn nhiều cái khác nữa. Ai có kinh nghiệm xử lý mấy cái tình huống giống như trên thì share cho mình với.

    Like

Leave a comment