Tìm hiểu Agile và Scrum – Phần 1: Tuyên ngôn Agile

      Chức năng bình luận bị tắt ở Tìm hiểu Agile và Scrum – Phần 1: Tuyên ngôn Agile

Thời gian này tôi chuyển sang làm công tác QA (Quality Assurance) và đang tìm hiểu để áp dụng AgileScrum cho công ty. Trong quá trình tìm hiểu, tôi nhận thấy agile và scrum là những chủ đề rất rộng, không dễ dàng áp dụng. Nội dung các bài viết trong seri này do tôi sưu tầm, tổng hợp từ nhiều website khác nhau nhằm hệ thống hóa những vấn đề cơ bản nhất của agile và scrum để khi cần thì đem ra đọc và ngẫm lại. Hi vọng các bài viết này cũng giúp được các bạn mới bắt đầu tìm hiểu agile và scrum như tôi.

Mô hình phát triển truyền thống (water fall)

Qui trình thác nước

Với mô hình phát triển truyền thống, các giai đoạn đượ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. Khi requirement thay đổi, ta phải thực hiện lại các bước thiết kế, phát triển, kiểm thử, viết 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, vượt quá ngân sách.

Sự ra đời của Agile

Thập kỉ 80 của thể kỉ XX chứng kiến một thời kì khủng hoảng phương pháp luận phát triển phần mềm, do tỉ lệ thất bại của các dự án phần mềm quá cao. Hàng loạt nỗ lực nhằm cố gắng tìm ra phương pháp hữu hiệu để đảm bảo tính hiệu quả trong phát triển phần mềm.

Từ ngày 11-13 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ại bang Utah, Mỹ nhằm tìm ra phương pháp xây dựng phần mềm tinh gọn, hiệu qiuả. Thành quả của cuộc họp là một tấm ảnh tự sướng của vài người đàn ông đứng hướng mắt vào màn hình và một bản “tuyên ngôn Agile (The manifesto for Agile Software Development)”.

Ảnh: agilemanifesto.org

Nội dung tuyên ngôn:

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

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.

Theo AgileManifesto.org

4 nội dung của tuyên ngôn Agile

Cá nhân và sự tương tác quan trọng hơn là quy trình và công cụ: Ý tưởng là đặt trọng tâm vào con người và sự tương hỗ giữa những thành viên trong nhóm. Cơ bản là nếu dự án có những thành viên có năng lực, chịu làm việc cùng nhau thì sẽ mang đến thành công cho dự án. Nếu dự án của bạn có quy trình làm việc tốt, được hỗ trợ những công cụ tốt nhất nhưng những thành viên không “cùng nhìn về một hướng” thì khả năng dự án thất bại là rất lớn. Nói điều này không có nghĩa là phủ nhận tầm quan trọng của quy trình và công cụ nhưng trong Agile nó được đặt sau yếu tố con người.

Phần mềm chạy tốt hơn là tài liệu đầy đủ: Trong một số quy trình phát triển phần mềm, việc tạo ra và cập nhật các tài liệu về sản phẩm là bắt buộc. Nhóm Dev không thể hoặc không đồng ý tiến hành công việc nếu không có tài liệu đặc tả về yêu cầu, thiết kế hệ thống. Nhóm Test thì yêu cầu tài liệu về sản phẩm để có thể viết trường hợp kiểm thử và kiểm thử được. Nhóm QA đòi tất cả các tài liệu phải được viết trước khi sản phẩm được giao cho khách hàng nếu không thì không đủ điều kiện, chuẩn để giao sản phẩm cho khách hàng. Thực ra đứng với góc độ khách hàng thì khách hàng chỉ quan tâm đến sản phẩm có hoạt động được và tốt hay không. Trong khi việc tạo và cập nhật tài liệu mất nhiều thời gian và được cho là buồn tẻ. Vậy tại sao mình phải tập trung quá nhiều cho việc không cần thiết mà không dành thời gian đó để trao đổi để hiểu thêm về công việc phải làm. Mọi người đừng hiểu lầm là làm Agile là không viết tài liệu. Ý tưởng là chỉ viết những gì mà mọi người cần đọc.

Cộng tác với khách hàng hơn là đàm phán hợp đồng: “Khách hàng là thượng đế” hay “khách hàng luôn luôn đúng”. Tuy nhiên thì khách hàng có đủ loại khách hàng. Có khách hàng am hiểu về công nghệ, có người không. Có người suy nghĩ nhất quán có người thay đổi xoành xoạch, có người lạnh lùng có người cười nói suốt ngày, v.v…. và cách duy nhất để có thể làm việc tốt là phải cộng tác với khách hàng để hiểu được khách hàng muốn gì và cần gì để có thể tư vấn và điều chỉnh thay vì chỉ dựa vào những điều đã quy định trong hợp đồng.

Phản hồi thay đổi hơn là bám sát kế hoạch: Hầu hết những dự án, không có dự án nào không có sự thay đổi điều chỉnh khi thực thi. Sự thay đổi đó có thể là thay đổi về yêu cầu, thay đổi công nghệ, thay đổi nhân sự, thay đổi deadline, thay đổi phương thức làm việc, v.v mặc dù kế hoạch đã được định ra rõ ràng từ đầu. Agile không khuyến khích cho sự thay đổi nhưng khuyến khích chúng ta tập thích nghi với thay đổi.

Lưu ý: Mặc dù các điều bên phải vẫn có giá trị. Nhưng các mục ở bên trái luôn được đánh giá cao hơn:

Ví dụ: Cá nhân và sự tương tác hơn là quy trình và công cụ. Agile hướng sự tập trung vào Cá nhân và sự tương tác mà không hề phủ nhận quy trình và công cụ cũng như các phương thức truyền thống. Đó là lý do tại sao sử dụng từ hơn là chứ không phải thay vì hay bất kỳ từ nào khác với mục đích phủ định, loại bỏ cái cũ. Cách hiểu này cũng áp dụng cho các tuyên ngôn còn lại.

12 nguyên lí phía sau tuyên ngôn Agile

  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 cho 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 và 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. Đội sản xuất 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.

Ưu điểm và nhược điểm của mô hình Agile.

Ưu điểm

  • Agile là sự lựa chọn rất tốt cho những dự án nhỏ bởi những dự án nhỏ thường có những yêu cầu không được xác định rõ ràng và có thể thay đổi thường xuyên.
  • Với Agile khách hàng có thể được xem trước từng phần dự án trong suốt quá trình phát triển vì Agile phát triển phần mềm theo hướng tăng dần, có thể đưa cho khách hàng xem từng phần đã thực hiện hoàn thành. Từ đó có thể bám sát dự án và luôn sẵn sàng cho bất kỳ thay đổi nào từ phía khách hàng yêu cầu về dự án.
  • Agile chia dự án thành những phần nhỏ và giao cho mỗi người, hàng ngày tất cả mọi người phải họp với nhau trong khoảng thời gian ngắn để thảo luận về tiến độ và giải quyết những vấn đề nảy sinh nếu có nhằm đảm bảo đúng quy trình phát triển dự án.
  • Tỉ lệ thành công của các dự án sử dụng Agile thường cao hơn các quy trình khác.

Nhược điểm

  • Thiếu sự nhấn mạnh về thiết kế và tài liệu cần thiết
  • Quy mô nhân lực thường giới hạn từ 7 đến 10 người, sẽ có trở ngại lớn nếu nguồn nhân lực yêu cầu vượt quá con số này ví dụ trong các cuộc họp trao đổi.
  • Số lượng yêu cầu có thể nhiều và khó quản lý nếu như nó bao gồm nhiều khía cạnh khác nhau về dự án.
  • Số lượng nhân lực càng tăng, chất lượng càng khó kiểm soát hơn. Việc kiểm tra mã thường xuyên và thiết lập các chỉ tiêu đánh giá năng lực của lập trình viên cho phép giảm thiểu nhược điểm này.

Bài viết có tham khảo và sử dụng nội dung từ các nguồn sau:

  • https://viblo.asia/p/tong-quan-ve-agile-va-kiem-thu-phan-mem-trong-mo-hinh-agile-Az45bpBQZxY
  • http://agilemanifesto.org/principles.html
  • Sách cẩm nang Scrum – Nhà xuất bản thế giới