Agile là gì?

Agile là tên viết tắt của cụm từ tiếng anh (Agile Software Development), nó là một phương phức hay mô hình phát triển phần mềm (kiểu kiểu như mô hình thác phát triển phần mềm thác nước walterfall) do mốt nhóm 14 nhân vật hàng đâu trong ngành công nghiệp phần mềm.

Tiêu chí của mô hình Agile là làm sao để đưa ra sản phẩm đến tay người tiêu dùng càng nhanh càng tốt, càng sớm càng tốt và theo thống kế trên thế giới thì nó hiệu quả hơn, linh hoạt hơn so với các mô hình phát triển phần mềm trước đó như là "thác nước waterfall" hay "CMMI".

Về cơ bản mô hình phát triển phần mềm Agile là tập hợp các phương thức phát triển vòng lặp nhưng tăng dần trong đó yêu cầu và giải pháp được phát triển thông qua sự cộng tác liên tục của các thành viên trong nhóm (bao gồm lập trình viên, IT, Tester và cả khách hàng) và đặc biệt là công việc được nhóm tự quản và phân chia.


Định nghĩa thi có vẻ khó hiểu nhưng khi đi vào tuyên ngôn của Agile thì rất dễ hiểu, trước khi đi tiếp thì mình xin nói chung chung một chút cách hiểu của mình về Agile.

Agile là mô hình làm việc tương tác giữ người với người chứ không phải giữa người với qui trình, tài liệu, mô hình, ví như khách hàng kêu tôi làm cái A tôi làm cái A không hiểu tôi hỏi liền khách hàng ở bất kỳ thời điểm nào của dự án, hay tại bất kỳ thời điểm làm việc nào tôi cũng có thể nhờ khách hàng xem lại xem có đúng chưa? hay tôi nói với tester kiểm tra cho tôi A tại bất kỳ thời điểm nào tôi đang làm việc, hoặc tester báo bug tôi sẽ xử lý ngay và đưa cho tester xem tại chỗ, tương tự khách hàng cũng có thể yêu cầu thêm hay thay đổi tại bất kỳ thời điểm nào tôi đang làm việc mà yêu cầu này không ảnh hưởng tới tiến độ của dự án nếu ảnh hưởng thì tôi có thể trao đổi trực tiếp lại với khách hàng, và tất cả các quá trình này đều thực hiện qua giao tiếp. Chính vì thế theo tôi để thực hiện được mô hình này thì cần phải có các yếu tố sau:

Đầu tiên theo mình tiêu chuẩn đầu tiên cần phải có phải là sự tin tưởng giữa các thành viên trong nhóm bao gồm cả khách hàng, tại sao vậy? Vì tiêu chí của Agile không tập trung vào tài liêu, qui trình,... mà tập trung vào việc hoàn thành công việc, tuy nhiên nếu giả sử như có sự cố hay vấn đề gì đó phát sinh nếu mọi người chăm chăm tìm lỗi, trách nhiệm thuộc về ai, hoặc sau khi xảy ra sự cố thì lại bắt đầu yêu cầu qui trình xác nhận hay kiểm tra gì đó thì cũng chẳng khác nào quay về mô hình cũ. Bạn cũng xẽ thắc mắc nếu thật sự xảy ra trường hợp này thì sao, nếu xảy ra trường hợp này thì nói lên rằng bạn chưa được hiện đúng tiêu chí của Agile, như mình nói ở trên khách hàng, tester, lập trình, IT, là các thành viên trong nhóm làm việc liên tục để hoàn công việc trong quá trình làm việc xác nhận yêu cầu, kiểm tra lỗi, phát triển phần mềm, phần cứng luôn được liên tục mà đến cuối cùng vẫn xảy ra vấn đề thì phải xem lại vấn đề nằm ở đâu và điều chỉnh lại cho phù hợp.

Thứ 2 là tự giác & trách nhiệm & hỗ trợ làm việc cao, mỗi thành nhiên phải có tinh thần tự giác & trách nhiệm làm việc có tránh nhiệm và luôn luôn hỗ trợ đồng nghiệp, tại sao lại cần? Vì trong Agile công việc được tự các thành viên trong nhóm phân chia và xử lý, và khi hết việc thì phải lượm việc khác làm hoặc hỗ trợ đồng đội xử lý giải quyết vấn đề, vì vậy nếu không có tinh thần làm việc hay giúp đỡ đồng nghiệp thì không thể thực hiện được vì trong Agile chả ai bắt bạn đi làm việc cả mà tự bản thân bạn đi kiếm việc.

Thức 3 là chịu trách nhiệm chung, nói hơi cường điệu tuy nhiên đối với Agile việc nhóm bạn không hoàn thành công việc hay yêu cầu luôn phải là vấn đề của cả đội, điều này giúp tính tự giác của các thành viên trong nhóm được cao hơn, thí dụ thế này khi một dự án được phân cho nhiều người làm thì nếu ai không hoàn thành tốt thì chỉ người đó chịu tránh nhiệm, với Agile thì không cả nhóm phải chịu chính vì thế yêu cầu các thành viên có tính cảnh giác cao với các công việc chưa hoàn thành hay các vấn đề phát sinh của thành viên khác thì dụ thằng kia làm không tốt thì sẽ nhóm họp báo cáo, còn như mạnh ai mấy làm thì chắc ăn rằng chả ma nào đi nói làm gì cho mất công mất lòng. Điều quay lại vấn đề đầu tiên là phải có sự tin tưởng nếu ai đó thấy bạn làm không tốt nhắc nhở bạn thì bạn bực tức rồi thờ ơ làm cho xong việc hoặc chăm chăm tìm sai lầm của kẻ thù thì cũng không thể thực hiện mô hình Agile này được.

Trên đây là 3 tiêu chuẩn mà mình cho rằng cần phải có và cũng là khó nhất khi thực hiện Agile, mà công nhận nếu có hoặc ở một đội như vây thì tuyệt. Nói tào lao nãy giờ ^^! có thể sai hoặc đúng các bạn đọc xong cho qua xin đừng gạch đá, giờ để hiểu rõ hơn ta đi qua các khái niệm và tuyên ngôn của Agile.

Tuyên ngôn Agile

Theo tuyên ngôn Agile thì phương pháp phát triển phần mềm tốt hơn được xây dựng thông qua cách thức thực hiện tốt hơn và giúp đỡ những người khác thực hiện nó. Qua cách thức này, họ đã đánh giá cao:

  • Con người và sự tương tác tốt hơn 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 tốt hơn là đàm phán hợp đồng.
  • Phản hồi với các thay đổi tốt hơn là bám sát kế hoạch.


Các giá trị trên chính là bốn giá trị cốt lõi của Agile. Các giá trị này được xây dựng dựa trên 12 nguyên lý:

  • Ư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ị.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • Phần mềm chạy tốt là thước đo chính của tiến độ.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.


Tuy nhiên xét theo một khía cách khác là quản lý dự án thì Agile có thể là chưa đủ vì vậy người ta đưa ra một tuyên ngôn khác để hỗ trợ cho tuyên ngôn Agile gọi là "tuyên ngôn tương hỗ" cái này thì mình không rành lắm copy & paste lại thôi :>>

Tuyên ngôn Tương hỗ

Trong khi Tuyên ngôn Agile giải quyết việc phát triển phần mềm thì "tuyên ngôn tương hỗ" tập trung nhiều hơn vào khía cạnh quản lý dự án. Theo Tuyên ngôn Tương hỗ, lãnh đạo dự án đã đạt được thành công trong việc chuyển giao kết quả thông qua việc họ:

  • Tăng tỷ lệ hoàn vốn đầu tư bằng cách biến những luồng giá trị liên tục thành trọng tâm của mình.
  • Chuyển giao những kết quả đáng tin cậy bằng cách lôi kéo khách hàng thường xuyên tương tác và chia sẻ quyền sở hữu.
  • Chờ đợi các bất ổn và quản lý chúng qua các phân đoạn, dự đoán và thích ứng
  • Giải phóng sức sáng tạo và đổi mới bằng cách công nhận rằng các cá nhân là nguồn gốc cao nhất của giá trị và tạo ra một môi trường nơi họ có thể làm nên sự khác biệt
  • Tăng hiệu suất thông qua phân nhóm trách nhiệm đối với các kết quả và chia sẻ trách nhiệm về hiệu quả của nhóm.
  • Nâng cao hiệu quả và độ tin cậy thông qua các chiến lược, qui trình và thực tiễn cụ thể trong từng tình huống.



Tham khảo: quanlyduan.edu.vn/



Đây là một trong bài viết tổng hợp và giải thích đơn giản các thuật ngữ công nghệ thông tin, máy tính, hay các thuật ngữ trên internet,... trong bài viết này mục tiêu của mình là giúp cho những bạn không thuộc lãnh vực này có nắm bắt và hiểu được các định nghĩa ở mức cơ bản.

Vì thế mình cố gắng giải thích một cách đơn giản nhất, dễ hiểu nhất. Tuy nhiên sẽ nhược điểm là sẽ không thể giải thích đủ hoặc chính xác hoàn toàn các thuật ngữ, vì muốn hiểu rõ chúng bạn cần phải học tập và tìm hiểu một cách chuyên sau hơn, tuy nhiên cũng không phải ai cũng cần biết chuyên sâu làm chi.

Nếu bài viết khó hiểu, hoặc bạn không hiểu một phần nào đó, hoặc sai, xin hãy phản hồi (comment) tại đây mình sẽ biên chỉnh lại cho phù hợp hơn, việc này sẽ giúp mình hoàn thiện bài viết hơn nữa, cảm ơn các bạn đã quan tâm.




No comments:

Post a Comment