Tổng quan về mô hình Agile
Bài đăng này đã không được cập nhật trong 8 năm
1 - Agile là gì?
Agile Software Development - gọi tắt là Agile đã trở nên rất phổ biến trong ngành phát triển phần mềm
Với ý tưởng khắc phục nhược điểm của các phương pháp phát triển phần mềm truyền thống, với mục tiêu mang đến cho phần mềm khả năng biến đổi, phát triển linh hoạt theo từng giai đoạn, phương pháp Agile đã ra đời góp phần tạo ra một phần mềm thật đơn giản đáp ứng đúng yêu cầu của khách hàng hôm nay và sẵn sàng cho những thay đổi vào ngày mai. Hiểu một cách đơn giản Agile là cách thức làm phần mềm linh hoạt để làm sao đưa sản phẩm đến tay người dùng càng nhanh càng tốt càng sớm càng tốt
2 - Bốn tôn chỉ của Agile:
Agile hoạt động dựa trên những tôn chỉ sau:
2.1 - Cá nhân và sự tương hỗ quan trọng hơn quy trình và công cụ:
Trong Agile, không phải lúc nào cũng có giải pháp cho mọi vấn đề và để tìm ra được giải pháp thì không chỉ dựa vào lý thuyết mà phải trải qua thực tiễn. Tất nhiên sẽ không thể có một phần mềm tốt nếu không có quy trình và công cụ tốt nhưng Agile luôn đề cao vai trò của từng cá nhân và mối quan hệ giữa các cá nhân trong đội ngũ phát triển phần mềm. Nếu dự án có những thành viên có năng lực, luôn sẵn sàng chia sẻ kiến thức, hỗ trợ lẫn nhau trong công việc thì sẽ mang đến thành công. 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.
2.2 - Phần mềm sử dụng được quan trọng hơn tài liệu về sản phẩm
Trong một số quy trình phát triển phần mềm, việc tạo và cập nhật các tài liệu về sản phẩm là bắt buộc. Nhóm phát triển 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 kiểm thử 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 kiểm soát quy trình thì đò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, tiêu 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.
2.3 - Cộng tác với khách hàng quan trọng hơn đàm phán hợp đồng
Vẫn dựa trên tiêu chí "Khách hàng là thượng đế" nhưng khách hàng có rất nhiều loại, 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, chính vì vậy mà Agile luôn luôn chú trọng việc cộng tác thường xuyên chặt chẽ 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.
2.4 - Phản hồi với sự thay đổi quan trọng hơn bám theo kế hoạch
Có một điểm chung mà mình thấy trong hầu hết những dự án mình đã trải qua đó là 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. Bạn hãy chuẩn bị tinh thần để thay đổi khi tham gia vào dự án Agile nhé.
Có một điều thú vị là đa số trong chúng ta đều cơ bản đồng ý với 4 tuyên ngôn của Agile. Nhiều người hiểu tầm quan trọng của “cá nhân” hay “cá nhân là tài sản quý giá nhất công ty” nhưng sẳn sàng thay đổi nhân lực để tương thích với quy trình/công cụ hiện có. Nhiều người hiểu “khách hàng là thượng đế” và “phải thích nghi với sự thay đổi” nhưng sẵn sàng tuyên bố “Dẹp, không làm nữa” vì khách hàng thay đổi yêu cầu liên tục. Hay như “sản phẩm xài được là quan trọng “ nhưng vẫn cố gắng viết thêm tài liệu với ý nghĩ rằng “biết đâu/lỡ sau này có ai cần thì có cái mà cung cấp”. 4 tuyên ngôn của Agile nói dễ hơn làm nhưng khi bạn theo Agile thì bạn hãy chuẩn bị tinh thần để “làm” chứ không phải để “nói”.
3 - 12 nguyên tắc của Agile
-- Nguyên tắc 1: Thỏa mãn yêu cầu của khách hàng thông qua việc giao hàng sớm và liên tục
-- Nguyên tắc 2: Giao phần mềm chạy được cho khách hàng một cách thường xuyên (giao hàng tuần hơn là hàng tháng)
--> Mục đích của dự án phát triển phần mềm là phát triển phần mềm và làm khách hàng hài lòng và không có gì làm khách hàng hài lòng hơn việc cho khách hàng thấy được sản phẩm của mình thường xuyên và chạy được. Trong Agile, sản phẩm sẽ được demo cho khách hàng thường xuyên (thường là hàng tuần) để cho khách hàng thấy được sản phẩm của mình như thế nào. Nếu có chỗ nào không ổn hay cần cải tiến thì sẽ phản hồi với đội dự án ngay lập tức.
-- Nguyên tắc 3: Chào đón việc thay đổi yêu cầu, thậm chí là những thay đổi yêu cầu muộn
--> Dù bạn thích hay không thì việc thay đổi yêu cầu từ khách hàng là dường như không thể tránh khỏi và nhiệm vụ của bạn là phải thích ứng với sự thay đổi đó. Thích ứng không có nghĩa là khách hàng yêu cầu gì mình làm cái đó. Khi khách hàng thay đổi yêu cầu, chắc chắn phải có lý do của họ và nhiệm vụ của đội dự án là phải hiểu được lí do đó để có thể điều chỉnh sự thay đổi, tư vấn hay đề nghị giải pháp cho khách hàng tương ứng
-- Nguyên tắc 4: Khách hàng của dự án và đội phát triển phải làm việc cùng nhau hàng ngày trong suốt dự án
--> Đội phát triển phải làm việc thường xuyên và gần gũi với khách hàng để hiểu được nhu cầu của họ cũng như cho phép khách hàng hiểu về công việc của đội phát triển. Đó là một trong những lí do mà Agile dường như khó triển khai trong các dự án offshore trong đó rào cản về địa lý, thời gian, ngôn ngữ là một trở ngại lớn.
-- Nguyên tắc 5: Các dự án được xây dựng 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
--> Như đã chia sẻ ở trên, Agile đặt trọng tâm là con người. Con người ở đây chỉ những cá nhân có động lực làm việc với tinh thần cộng tác, chia sẻ và giúp đỡ lẫn nhau. Song song đó, đội dự án sẽ được hỗ trợ những công cụ, môi trường, sự tin tưởng và những đãi ngộ cần thiết để hoàn thành công việc.
-- Nguyên tắc 6: Trao đổi trực tiếp mặt đối mặt là phương pháp hiệu quả nhất để truyền đạt thông tin
- Phần mềm chạy được là thước đo chính của tiến độ
- Phát triển bền vững và duy trì được nhịp độ phát triển liên tục
- Liên tục quan tâm đến kĩ thuật và thiết kế để cải tiến sự linh hoạt
- Sự đơn giản là cần thiết – nghệ thuật tối đa hóa lượng công việc chưa hoàn thành
- Nhóm tự tổ chức
- Thích ứng thường xuyên với sự thay đổi
4 - Quy trình thực hiện:
Agile phát triển dựa trên quy trình phát triển lặp. Mỗi dự án được chia thành nhiều giai đoạn nhỏ dễ dàng đáp ứng khi có yêu cầu thay đổi từ khách hàng.
Sản phẩm được bàn giao cho khách hàng theo từng giai đoạn, cứ mỗi khi một mảng nhỏ được bàn giao, khách hàng có thể đưa ra các thay đổi hoặc yêu cầu mới cho dự án và nhóm phát triển sẽ cập nhật sản phẩm theo đúng yêu cầu của khách hàng mà không cần làm lại từ đầu
Quy trình của từng giai đoạn sẽ như sau:
a - Lập kế hoạch:
Kế hoạch tổng thể của dự án được vạch ra trong những tuần đầu tiên. Khách hàng và đội dự án sẽ cùng nhau bàn bạc để chia dự án thành các giai đoạn phát triển nhỏ, ước lượng thời gian, công sức và lịch phát triển cho từng giai đoạn phát triển nhỏ đó.
Mỗi một giai đoạn phát triển nhỏ có một kế hoạch cụ thể được vạch ra vào đầu mỗi giai đoạn
Đội dự án sẽ họp mặt hàng ngày để cập nhật tình hình công việc
b - Phân tích:
Việc phân tích yêu cầu không cố định vào một khoảng thời gian nào mà nó diễn ra trong suốt thời gian phát triển dự án. Đại diện phía khách hàng và đội dự án sẽ làm việc chung với nhau, cùng nhau trao đổi để đưa ra cách làm tốt nhất trước khi bàn giao cho đội phát triển
c - Thiết kế và lập trình:
Thiết kế của sản phẩm được cải tiến liên tục. Mã nguồn được coi là sở hữu tập thể. Mọi thành viên được yêu cầu sửa lỗi bất kể lỗi đó là do ai gây ra.
d - Kiểm thử:
Tất cả các thành viên trong dự án đều có trách nhiệm đảm bảo chất lượng của sản phẩm. Khi có lỗi, cả đội cùng nhau phân tích nguyên nhân và cùng nhau xử lý.
e - Bàn giao sản phẩm:
Phần mềm sẽ được demo hàng tuần và đưa cho khách hàng xem xét, góp ý kiến
Nguồn tham khảo:
All rights reserved
