12 nguyên tắc trong Agile

Bài viết được sự cho phép của vntesters.com

“12 nguyên tắc trong Agile” và “tuyên ngôn của Agile” là những phần cốt lõi trong Agile. “Tuyên ngôn của Agile” có thể chung chung và “cao cấp” nhưng 12 nguyên tắc trong Agile sẽ mang tính thực tiễn nhiều hơn.

Agile_Elephant

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

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

  Agile là gì? Scrum là gì? Các công cụ quản lý dự án theo Agile mà bạn nên biết
  Digital Messaging - Giải Pháp Quản Lý Toàn Diện Dữ Liệu Người Dùng

Xem thêm việc làm Agile lương cao trên TopDev

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

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.

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.

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.

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.

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 đề.

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

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

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

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? Trong phần tới mình sẽ giới thiệu các bạn “tuyệt chiêu” trong Agile – SCRUM.

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

Bài viết gốc được đăng tải tại vntesters.com

Có thể bạn quan tâm:

Xem thêm tuyển dụng CNTT hấp dẫn trên TopDev