Tổng quan về Agile

Phương thức phát triển phần mềm linh hoạt (Agile Software Development) – sau đây được gọi vắn tắt là “Agile” – đã trở nên phổ biến trong ngành phát triển phần mềm. Với những phương phức tổ chức và triển khai mới lạ, năng động và linh hoạt, Agile đã thu hút sự quan tâm lớn của cộng đồng làm phần mềm và dĩ nhiên là một kỹ sư kiểm thử mình không thể nào thờ ơ với Agile được.

Trước hết mình xin nói ngay rằng mình không phải là một chuyên gia về Agile cũng không phải là kỹ sư kiểm thử nhiều năm chinh chiến với Agile. Mình chỉ là một kỹ sư kiểm thử với chút kinh nghiệm dự án thực tế và ít kiến thức lụm lặt được về Agile. Tuy nhiên mình vẫn mong muốn được chia sẻ những hiểu biết suy nghĩ của mình và hy vọng nhận được sự chia sẻ từ các anh chị em trong ngành về Agile.

Bài viết “Tổng quan về Agile” sau đây là một phần trong một loạt bài giới thiệu về Agile theo cách nhìn của mình, nội dung được tinh giản nhưng hy vọng vẫn giữ được nguyên giá trị của Agile và…chúng ta bắt đầu thôi.

Phương thức phát triển phần mềm Agile là gì?

Wiki định nghĩa như sau: “Phương thức phát triển phần mềm Agile là một tập hợp các phương thức phát triển lặp và tăng dần trong đó các yêu cầu và giải pháp được phát triển thông qua sự liên kết cộng tác giữa các nhóm tự quản và liên chức năng v.v và v.v”. OK. Bỏ qua phần định nghĩa nhé vì mình thấy không giúp ích gì nhiều. Đại ý là 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 và được xem như là sự cải tiến (ở một khía cạnh nào đó) khi đặt cạnh những mô hình cũ như  Mô hình “Thác nước (waterfall)” hay “CMMI”.

Định nghĩa Agile có thể trừu tượng và bạn có thể không nhớ nhưng bạn không thể không nhớ “Tuyên ngôn của Agile” (Agile manifesto). “Tuyên ngôn của Agile” được xem là cốt lõi là ngôi sao dẫn đường trong Agile. Theo tuyên ngôn, Agile hoạt động dựa trên những tôn chỉ sau:

Tuyên ngôn của Agile

• “Cá nhân và sự tương hỗ quan trọng hơn quy trình và công cụ”
• “Sản phẩm xài được quan trọng hơn tài liệu về sản phẩm”
• “Cộng tác với khách hàng quan trọng hơn đàm phán hợp đồng”
• “Phản hồi với sự thay đổi quan trọng hơn bám theo kế hoạch”

Tuyên ngôn cũng nói rằng mặc dù những mục bên phải vẫn có giá trị nhưng Agile đánh giá cao các mục bên trái hơn (phần in đậm)

4 tôn chỉ trên được dựa trên 12 nguyên tắc sau:

• 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
• 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

• 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)
• Nhà kinh doanh và kỹ sư lập trình phải làm việc cùng nhau hàng ngày trong suốt dự án
• 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
• 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

Tuyên ngôn của Agile

Bốn tuyên ngôn của Agile như sau:

• “Cá nhân và sự tương hỗ quan trọng hơn quy trình và công cụ”
• “Sản phẩm xài được quan trọng hơn tài liệu về sản phẩm”
• “Cộng tác với khách hàng quan trọng hơn đàm phán hợp đồng”
• “Phản hồi với sự thay đổi quan trọng hơn bám theo kế hoạch”

1. “Cá nhân và sự tương hỗ quan trọng hơn 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. Có một câu bằng tiếng Anh khá phổ biến nói về điều này là “a fool with a tool is just a fool”

2. “Sản phẩm xài đượ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 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.

3. “Cộng tác với khách hàng quan trọng hơn đà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.

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”.

12 nguyên tắc trong Agile

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

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)

2 nguyên tắc trên mình gom lại với nhau vì cơ bản nó chia sẻ ý tưởng giống nhau là giao hàng sớm, liên tục và chạy được cho khách hàng. Dĩ nhiên 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. Do đó sẽ giúp tránh được tình huống dở khóc dở cười sau khi hoàn thành sản phẩm như “tôi tưởng anh muốn ABC”, “tôi nghĩ mặc định anh sẽ làm XYZ”, v.v

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

4. Nhà kinh doanh và kỹ sư lập trình phải làm việc cùng nhau hàng ngày trong suốt dự án

“Nhà kinh doanh” ở đây được hiểu nôm na là khách hàng của dự án, những người tài trợ cho 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.

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ẻ, 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.

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

Sự giao tiếp trao đổi giữa những cá nhân là rất quan trọng và để giao tiếp hiệu quả thì không gì có thể hơn được trực tiếp trao đổi mặt-đối-mặt hay dùng những biểu tượng hình ảnh để chuyển tải thông tin. Bạn sẽ dễ bắt gặp một không khí nhộn nhịp hay những hình ảnh minh họa, biểu tượng, hình vẽ đầy màu sắc trong các dự án Agile vì những điều đó giúp trao đổi thông tin hiệu quả hơn.

7. Phần mềm chạy được là thước đo chính của tiến độ

Thông tin về tiến độ của dự án rất quan trọng, đặc biệt là đối với Ban quản lý hay các nhà đầu tư cho dự án vì những thông tin đó sẽ giúp họ có thể đưa ra những quyết định. Tuy nhiên, suy cho cùng điều mà họ quan tâm thực ra là sản phẩm đang phát triển có hoạt động tốt hay không. Bạn có thể báo tiến độ là “Đúng kế hoạch” nhưng khi được hỏi sản phẩm chạy được chưa thì câu trả lời là “sắp chạy được” hay “chưa chạy được” sẽ làm khách hàng hoang mang. Do đó, trong Agile bạn phải chuẩn bị tinh thần để “show hàng” cho khách hàng xem.

8. Phát triển bền vững và duy trì được nhịp độ phát triển liên tục

Trong Agile ưu tiên phát triển bền vững và duy trì nhịp độ phát triển liên tục. Đôi khi dự án cần phải làm thêm giờ nhưng chắc chắc bạn không thể làm 10-12 tiếng/ngày trong nhiều tháng liên tục. Theo mình thấy thì thời gian thực sự cho công việc để mang lại hiệu quả cao nhất là khoảng 4-5 tiếng. Nhiều bạn khi làm thêm giờ thì tự nhủ hay “được hứa” rằng đây chỉ là tạm thời nhưng có khi nhìn lại thì sự tạm thời đó đã được vài tháng rồi. Khi bạn cảm thấy mệt mỏi với cường độ làm việc liên tục và thường xuyên thì đó là dấu hiệu cho thấy dự án Agile của bạn đang có vấn đề.

9. Liên tục quan tâm đến kĩ thuật và thiết kế để cải tiến sự linh hoạt

Liên tục cải tiến các quy trình, phương pháp, công cụ để tăng mức độ linh hoạt trong dự án. Luôn nghĩ đến những phương pháp mới để code tốt hơn, kiểm thử tốt hơn như  TDD (Test-driven development) , ATDD (Acceptance Test-driven development), kiểm thử tự động, CI v.v

10. 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

Agile có nghĩa là linh hoạt và để linh hoạt uyển chuyển thì bạn phải tối giản hóa các công việc mình làm. Những việc nào cần thiết và mang lại giá trị thì mọi người sẽ cùng làm. Tuy nhiên việc xác định việc nào mang lại giá trị nhiều khi không đơn giản. Do đó, để đơn giản thì việc có giá trị là việc mà cả nhóm thống nhất và sẽ cam kết thực hiện. Chẳng hạn cả nhóm có thể thống nhất không phải viết “Báo cáo tiến độ hàng ngày” nếu như mọi người đều biết tiến độ của nhau và sếp của bạn cũng không có nhu cầu đọc. Tương tự, bạn cũng không nhất thiết phải mô tả một con bug dài lê thê chỉ để theo đúng định dạng của hệ thống bug trong khi bạn đã báo và trao đổi với Dev về con bug đó và họ đã sửa nó. Tuy nhiên hãy cẩn thận. Không phải bạn bỏ đi là bạn linh hoạt và tối ưu hóa công việc. Vấn đề là bạn bỏ đi những thứ không mang lại giá trị.

11. Nhóm tự tổ chức

Đây là nguyên tắc cốt lõi trong Agile đồng thời cũng là nguyên tắc gây đau đầu nhất. Ý tưởng là nhóm và cách thành viên sẽ tự quyết định việc mình làm, tự cam kết và tự chịu trách nhiệm cho chất lượng công việc mình làm. Mục đích là để tăng tính chủ động trong công việc. Dĩ nhiên “tự tổ chức” không phải là bạn tập hợp các thành viên và tuyên bố “nào, nhóm tự tổ chức nhé”. Do đó, ban đầu nhóm cũng phải được hướng dẫn, đào tạo để có thể “tự tổ chức”. Quá trình đó có thể gian nan và việc nhóm bạn “tự tổ chức” đến đâu còn tùy thuộc vào nhiều yếu tố như năng lực, nhận thức của thành viên, khả năng hướng dẫn của người hướng dẫn Agile, sự tin tưởng và tôn trọng của ban lãnh đạo, v.v

12. Thích ứng thường xuyên với sự thay đổi

Nhóm thường xuyên nhìn nhận đánh giá về tình hình dự án sản phẩm để có thể điều chỉnh và thích ứng. Ý tưởng là nhìn lại để tiến lên. Đó là những buổi họp tập trung vào những cái hay cái dở trong những việc mình đang làm để rút tỉa kinh nghiệm và học hỏi lẫn nhau. Những buổi họp dạng vậy thường là những câu hỏi và tự trả lời. Chẳng hạn như:

“Việc gì chúng ta làm chưa tốt” – Trả lời: “Nhóm không tự tổ chức và làm việc có sức ỳ”

“Chúng ta đã làm tốt những việc gì” – Trả lời: “Nhóm sau đó tự tổ chức và làm việc sung hơn”

“Chúng ta đã học được bài học gì” – Trả lời: “Tăng lương giúp giải quyết nhiều vấn đề”

Mình vừa chia sẻ xong 12 nguyên tắc trong Agile. Tới đây thì các bạn cơ bản đã có thể hình dung về Agile về những giá trị cốt lõi trong Agile cũng như những nguyên tắc để trở nên linh hoạt. Nhưng vấn đề là làm thế nào để có thể trở lên linh hoạt?

Rất vui nếu nhận ý kiến đóng góp, phê bình, chia sẻ từ các bạn.

Theo: Thanh Huynh/vntesters

DVMS chuyên:
- Tư vấn, xây dựng, chuyển giao công nghệ Blockchain, mạng xã hội,...
- Tư vấn ứng dụng cho smartphone và máy tính bảng, tư vấn ứng dụng vận tải thông minh, thực tế ảo, game mobile,...
- Tư vấn các hệ thống theo mô hình kinh tế chia sẻ như Uber, Grab, ứng dụng giúp việc,...
- Xây dựng các giải pháp quản lý vận tải, quản lý xe công vụ, quản lý xe doanh nghiệp, phần mềm và ứng dụng logistics, kho vận, vé xe điện tử,...
- Tư vấn và xây dựng mạng xã hội, tư vấn giải pháp CNTT cho doanh nghiệp, startup,...

Vì sao chọn DVMS?
- DVMS nắm vững nhiều công nghệ phần mềm, mạng và viễn thông. Như Payment gateway, SMS gateway, GIS, VOIP, iOS, Android, Blackberry, Windows Phone, cloud computing,…
- DVMS có kinh nghiệm triển khai các hệ thống trên các nền tảng điện toán đám mây nổi tiếng như Google, Amazon, Microsoft,…
- DVMS có kinh nghiệm thực tế tư vấn, xây dựng, triển khai, chuyển giao, gia công các giải pháp phần mềm cho khách hàng Việt Nam, USA, Singapore, Germany, France, các tập đoàn của nước ngoài tại Việt Nam,…

Quý khách xem Hồ sơ năng lực của DVMS tại đây >>

Quý khách gửi yêu cầu tư vấn và báo giá tại đây >>