Ngày nay, Tuyên ngôn Agile đã trở thành slogan của nhiều team phát triển phần mềm. Nó bao gồm 12 nguyên tắc chỉ ra cho chúng ta cách tổ chức phát triển phần mềm. Những nguyên tắc này đã được phát minh vào năm 2001. Nói chung, hầu hết mọi người đều thích và đồng ý với tất cả chúng. Tuy nhiên, trên thực tế, hầu hết các team phát triển phần mềm đều hiểu sai về chúng. Do đó, dưới đây là một bản tóm tắt về những gì đang xảy ra và giải thích về mỗi nguyên tắc.

Nguyên tắc số 1

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Tạm dịch: Ưu tiên cao nhất của chúng ta là thỏa mãn khách hàng thông qua việc delivery sớm và liên tục sản phẩm phần mềm có giá trị.

Nếu khách hàng không hài lòng, chúng ta tìm thấy một khách hàng khác. Bằng cách tập trung vào "làm hài lòng khách hàng", những tín đồ Agile hoàn toàn quên đi phần "thông qua". Họ nghĩ rằng một khách hàng hạnh phúc là mục tiêu thực sự của họ, trong khi "giao hàng liên tục" là cái gì đó rõ ràng là hữu ích, nhưng lại bị xem là không quan trọng. Tuy nhiên, điều này hoàn toàn trái ngược - khách hàng sẽ hài lòng NẾU sản phẩm được tạo ra hoàn hảo và được delivery. Nếu khách hàng không hài lòng, chúng tôi tìm thấy một khách hàng khác - đó là tinh thần thực sự của team Agile chuyên nghiệp. Tôi tin rằng đó là những gì Tuyên ngôn hàm ý trong đó. Chúng ta đảm bảo rằng quá trình của chúng ta là "sớm và liên tục", chính điều này sẽ dẫn tới sự hài lòng của khách hàng. Chúng ta tập trung vào việc cải tiến quy trình, chứ không tập trung vào thỏa mãn khách hàng. Sự hài lòng là kết quả chứ không phải là mục tiêu chính.

Nguyên tắc #2

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Tạm dịch: Hoan nghênh việc thay đổi requirement, thậm chí là bị trễ deadline phát triển. Quy trình Agile khai thác khía cạnh thay đổi, miễn là nó mang lại lợi thế cạnh tranh cho khách hàng.

Hầu hết các nhóm Agile hiểu từ "hoan nghênh" ở đây như là một sự cho phép để QUÊN đi requirement. Cách dễ nhất để hoan nghênh sự thay đổi là gì? Rõ ràng, chỉ cần bỏ qua tất cả các tài liệu về requirement! Trong trường hợp này, mọi thay đổi sẽ được hoan nghênh vì nó sẽ không ảnh hưởng đến bất cứ điều gì. Đó là cách đơn giản sẽ không để bất cứ điều gì bị ảnh hưởng. Nhưng đây không phải là điều mà Tuyên ngôn thực sự hàm ý bên trong! Nguyên tắc này có nghĩa là quy trình quản lý yêu cầu của chúng ta mạnh mẽ đến mức mà ta có thể chấp nhận thay đổi bất cứ lúc nào.

Nguyên tắc # 3

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Tạm dịch: Deliver sản phẩm một cách thường xuyên, từ vài tuần đến vài tháng, ưu tiên cho việc deliver càng sớm càng tốt.

Quy tắc tuyệt vời này thường được hiểu thành một mệnh lệnh cho cả team. Team phải delivery thường xuyên, trong khi dev thì chưa hiểu rõ là có thể cam kết deliver khi nào và cái gì. Tôi nghĩ rằng Tuyên ngôn ở đây nhấn mạnh đến trách nhiệm cá nhân và team để thường xuyên thực hiện. Tôi cũng nghĩ rằng tần số này không nên vượt qua một "vài tuần". Ngày nay, với công nghệ và công cụ hiện đại, chúng tôi có thể deliver nhanh hơn, Aglie cũng đã cho phép có sprint trong vài ngày.

Nguyên tắc #4

Business people and developers must work together daily throughout the project. Tạm dịch: Team/người làm business và dev phải làm việc cùng nhau hàng ngày trong suốt dự án.

Làm việc cùng nhau có nghĩa là sự thay đổi nhanh chóng trong giao tiếp không lack vai trò và trách nhiệm. Làm việc cùng nhau không có nghĩa là làm việc mà không có quy tắc và quy trình rõ ràng. Tuy nhiên, hầu hết các team đều hiểu nguyên tắc này là cho phép sự hỗn loạn. Họ nghĩ rằng kể từ khi chúng tôi làm việc cùng nhau, chúng tôi không cần phải xác định vai trò nữa, chúng tôi không nên document spec nữa, chúng ta không nên quan tâm đến trách nhiệm. Cuối cùng, chúng ta không biết ai đang làm gì, cũng như không rõ team được tổ chức ra sao. Đó không phải là điều Tuyên ngôn đang nói tới! "Làm việc cùng nhau" có nghĩa là quay vòng nhanh hơn trong communication và thời gian chờ feedback ngắn hơn; nó chắc chắn không có nghĩa là thiếu vai trò và trách nhiệm.

Nguyên tắc #5

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. Tạm dịch: Xây dựng các dự án xung quanh các cá nhân có motivation. Cung cấp cho họ môi trường và hỗ trợ khi họ cần, và tin tưởng họ có thể hoàn thành được công việc của họ.

Sự tin cậy không có nghĩa là thiếu kiểm soát. Niềm tin là một từ và khái niệm tuyệt vời, nhưng nó không thay thế một từ tuyệt vời khác - kiểm soát. Hầu hết các team Agile nghĩ rằng sự tin tưởng có ý nghĩa chính xác - hoàn toàn thiếu bất kỳ xác nhận, xác minh, trách nhiệm và kiểm soát. "Chúng tôi tin tưởng các dev của chúng tôi đều đã viết code tốt" - Tôi đã nghe rằng vô số lần, mà chỉ đơn giản là sai. Nguyên tắc này có nghĩa là một cái gì đó hoàn toàn khác; nó có nghĩa là khi các task được xác định rõ ràng được giao cho người đảm nhiệm, thì lúc này chúng ta hoàn toàn ủy thác trách nhiệm cho họ. Chúng ta động viên họ phải hoàn toàn chịu trách nhiệm cho kết quả cuối cùng của họ. Tuy nhiên, chúng ta không giúp họ. Thay vào đó, chúng ta tin tưởng họ là những cá nhân tự túc, có khả năng tự hoàn thành các task được giao.

Nguyên tắc #6

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Tạm dịch: Cách thức hiệu quả nhất để chuyển tải thông tin đến dev team là cuộc đối thoại trực tiếp.

Mặt đối mặt không có nghĩa là ở cùng một văn phòng, đặc biệt là bây giờ. Mặt đối mặt không có nghĩa là ngồi trong cùng một văn phòng. Tuyên ngôn không nói gì về các team kiểu hợp tác hoặc distributed team. Rõ ràng trong các dự án phần mềm hiện đại, truyền thông ảo (qua cuộc gọi video) có hiệu quả hơn ở cùng một quốc gia, cùng một thành phố, cùng văn phòng và cùng một phòng. Do đó, hầu hết các tín đồ Agile vẫn phát huy phong cách phát triển tại chỗ, sử dụng Tuyên ngôn Agile làm bằng chứng. Đó là một sai lầm; mặt đối mặt có nghĩa là một điều gì đó hoàn toàn khác với ý nghĩa của nó 15 năm trước, khi Tuyên ngôn được viết ra.

Nguyên tắc #7

Working software is the primary measure of progress. Tạm dịch: Sản phẩm có thể chạy được là thước đo đầu tiên của tiến độ

Điều này không có nghĩa là chúng ta không nên đo lường hay đánh giá bất cứ điều gì khác. Tất nhiên, sản phẩm có thể chạy được là thước đo chính, nhưng có nhiều biện pháp khác mà chúng ta có thể và phải sử dụng. Ví dụ, số lượng các tính năng được document, implement và deliver; hoặc số dòng code được thêm vào dự án; hoặc số lượng bug bị phát hiện; hoặc số tiền chi tiêu. Có rất nhiều chỉ số khác. Chúng ta có thể sử dụng nhiều trong số chúng. Tuy nhiên, một sai lầm điển hình nhiều team Agile đang làm chỉ là bỏ qua tất cả. Họ nói rằng "chúng tôi chỉ đo được kết quả cuối cùng". Đó không phải là điều mà Tuyên ngôn hàm chứa.

Nguyên tắc #8

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Tạm dịch: Agile thúc đẩy phát triển bền vững. Các nhà tài trợ, các developer và người dùng sẽ có thể duy trì một tốc độ không đổi vô hạn.

Chúng ta phải nhớ rằng bất kỳ dự án nào trước hết là một máy đốt tiền. Điều này không có nghĩa là chúng ta nên đốt tiền của khách hàng không thời hạn. Vâng, chúng ta nên phát triển ở một số tốc độ nhất định, nhưng chúng ta nên luôn nhớ rằng mình đang chi tiêu tiền của ai - tiền của khách hàng. Tuyên ngôn không nói gì về chi phí phát triển và đó có lẽ bởi vì nó được viết bởi những người kiếm tiền (dev) chứ không phải là những người chi tiêu nó (khách hàng). Vì vậy chúng ta phải nhớ rằng bất kỳ dự án nào trước hết là máy đốt tiền. Đó là lý do tại sao team phải luôn luôn đo tỷ lệ đốt tiền của mình và đảm bảo rằng nó phù hợp với số tiềnnmà team đó có thể mang sẽ mang về được cho công ty. Chỉ cần là một team happy không phải là điều mà Tuyên ngôn gợi ý, nhưng chính xác là có bao nhiêu người hiểu được nguyên tắc này.

Nguyên tắc #9

Continuous attention to technical excellence and good design enhances agility. Tạm dịch: Chuyên tâm liên tục đến sự xuất sắc về mặt kỹ thuật và thiết kế tốt giúp tăng tính nhanh nhẹn.

Đó là một nguyên tắc hoàn hảo mà nói rất nhiều và không nói bất cứ điều gì cùng một lúc. Chính xác là "chuyên tâm"? Tôi có thể giải thích. Nó có nghĩa là các quy tắc và chính sách. Trước hết, bất kỳ chính sách nào cũng có nghĩa là trừng phạt đối với những người vi phạm các quy tắc. Do đó, nếu một team Agile thực sự có ý nghĩa là team liên tục chú ý đến sự xuất sắc về kỹ thuật, nó phải có một chính sách chất lượng. Chính sách đó phải xác định rõ thiết kế nào là tốt và xấu, phần code nào là xuất sắc, xấu xí, vv . Ngoài ra, chính sách phải nói điều gì sẽ xảy ra với những người vi phạm nguyên tắc xuất sắc.

Nguyên tắc #10

Simplicity — the art of maximizing the amount of work not done — is essential. Tạm dịch: Sự đơn giản - nghệ thuật tối đa hóa số lượng công việc chưa làm - là điều thiết yếu.

Đó là một quy tắc tuyệt vời mà hầu hết các team Agile không làm theo. Nguyên tắc này có nghĩa là các task của chúng ta là nhỏ và đơn giản, đủ để đảm bảo rằng chúng có thể thực hiện được hoặc không thể hủy bỏ. Task lớn là mối đe dọa lớn nhất đối với khả năng quản lý của bất kỳ team nào, dù là Agile hay không. Nguyên tắc này khuyến khích chúng ta cung cấp cho các dev các task nhỏ, mà dev có thể dễ dàng hoàn thành. Tuy nhiên, hầu hết team Agile đều cho chúng là một. Chúng không giống nhau. Một task đơn giản không có nghĩa là một task ngu ngốc hoặc không quan trọng. Một task đơn giản là một trật tự công việc được xác định rõ ràng, nhỏ và khả thi.

Nguyên tắc #11

The best architectures, requirements, and designs emerge from self-organizing teams. Tạm dịch: Các kiến trúc, yêu cầu và thiết kế tốt nhất xuất hiện từ các nhóm tự tổ chức.

Tự tổ chức không có nghĩa là không tổ chức. Quy tắc này thường được dịch là hợp pháp hóa sự vô chính phủ. Chúng ta không cần một kiến trúc sư phần mềm - các dev của chúng ta có thể thực hiện tất cả các quyết định kỹ thuật tại các cuộc họp thường xuyên! Hơn nữa, chúng ta không muốn dev của mình chịu trách nhiệm một cách cá nhân riêng lẻ về bất cứ điều gì - họ luôn ở bên nhau trong mọi rủi ro và các vấn đề. Dừng lại điều vô nghĩa đó! Đây không phải là điều mà Tuyên ngôn hàm ý. Một team tự tổ chức là một team không cần giám sát từ bên ngoài; một team đã xác định rõ vai trò từ bên trong; một team với một kỷ luật hoàn hảo bên trong; một team với quản lý chuyên nghiệp. Chứ không phải với sự thiếu sót được nêu ra ở trên.

Nguyên tắc #12

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. Tạm dịch: Trong khoảng thời gian thường xuyên, team phải phản ánh cách thức để trở nên hiệu quả hơn, sau đó điều chỉnh cho phù hợp.

Đó là một nguyên tắc tuyệt vời mà được dịch sang các cuộc họp được gọi là retrospective meeting. Họ chỉ làm việc tốt nếu các quyết định làm cho team tốt hơn. Thật không may, trong hầu hết các trường hợp, các dev trong các team Agile đang cố gắng để tồn tại, thay vì làm cho team của họ hiệu quả hơn. Mặc dù nguyên tắc nói rằng team phải nghiên cứu để trở nên hiệu quả hơn, những cuộc retro meeting này giúp các dev trở nên hiệu quả hơn trong nhóm. Đó là điều hoàn toàn tự nhiên đối với mỗi con người, nhưng dẫn đến sự suy thoái toàn diện của team. Tôi tin rằng những gì Tuyên ngôn mang ý nghĩa là ở đây không phải là những cuộc họp, mà nó có nghĩa là team phải nghiên cứu ra một cơ chế tự chủ và tự cải thiện có hiệu quả. Thêm vào đó, các buổi retro meeting không nên tổ chức một cách có máy móc, như vậy không mang lại value gì cho team cả.

Trên đây là 12 sai lầm mà nhiều team Agile đang mắc phải, hãy xem lại team Agile của bạn đi. Đã đến lúc chuẩn hóa mọi thứ.