Bàn về 12 nguyên tắc trong Agile (Phần 2)

***Ở phần một mình và các bạn đã trao đổi về 6 nguyên tắc đầu tiên trong Agile với bài : Bàn về 12 nguyên tắc trong Agile (Phần 1) Hôm nay chúng ta hãy cùng tiếp tục bàn về 6 nguyên tắc còn lại *

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

“Working software is the primary measure of progress.”

Kể cả bạn đang quản lý dự án non-software thì cũng đừng bỏ qua nguyên tắc này bời vì nó nói đến software. Working ở đây chính là nói đến kết quả, đến việc mình tạo được những thứ mà có thể đo lường được hay nó hoàn thành được một vấn đề nào đó. Việc có các phần được hoàn thành không chỉ giúp mọi người có thể nhìn thấy được tiến độ mà còn là chất xúc tác cho những nguyên tắc khác, đặc biệt là việc sẽ có được những feedback hay hơn nữa là sự chấp nhận từ khách hàng cho những tính năng đó. Việc test những Working Model giúp team có được sự thống nhất trong giải pháp. Và nó dễ dàng hơn rất nhiều để đi đến những sự chấp thuận hay không chấp thuận, sự lựa chọn và thay đổi. Một điều chúng ta cần lưu ý trong nguyên tắc này đó là: Khi ta cần giành nhiều thời gian hơn để tạo ra working software thì khi đó ta cần dùng ít thời gian hơn cho việc viết tài liệu hay các bản design phức tạp. Chúng quan trọng tuy nhiên với đặc thù về sự thay đổi liên tục của agile project không cho phép chúng ta dùng quá nhiều thời gian để làm tài liệu, thứ mà có thể thay đổi ngay trong tương lai gần

8. Agile Project khuyến khích phát triển bền vững, Khách hàng, team và người dùng nên duy trì được nhip độ phát triển một cách liên tục

“Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.”

Khi các dự án bắt đầu, chúng ta thường cảm thấy rất sung sức và tràn đầy năng nượng, và khao khát thể hiện thật tốt. Đặc biệt thường thấy ở những dự án mà cần độ cấp bách về tiến độ. Khi đó chúng ta sẽ đẩy áp lực làm việc mạnh lên để có được tiến độ dự án chạy một cách nhanh chóng. Nó có thể tạo ra những kết quả tốt ngắn hạn, nhưng sẽ phá hỏng kế hoạch dài hạn. Rõ ràng là không thực tế nếu kỳ vọng team sẽ làm việc với hiệu suất cao trong thời gian dài. Làm việc quá sức có thể tạo ra nhiều sai lầm và lỗi hơn. Khi con người làm việc quá tải và có ít thời gian để nghỉ ngơi, tập luyện thể dục hay hồi phục sức khoẻ, môi trường làm việc sẽ trở nên xấu đi, thậm chí là độc hại. Khi đó từng cá nhân sẽ trở nên kém kiên nhẫn và xung đột lẫn nhau, chúng ta sẽ khó có thể quản lý và giải quyết được các vấn đề. Do đó, một môi trường làm việc cân bằng giữa công việc và cuộc sống cần được lưu ý. Cần nhận thấy rằng Agile projects không chỉ cho những khoảng ngắn hạn mà còn cần thiết để thành công trong dài hạn. Nên việc thiết lập và duy trì nhịp độ phát triển chính là những gì nguyên tắc này muốn nói đế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

“Continuous attention to technical excellence and good design enhances agility.”

Nguyên tắc số 9 nhắc nhở tất cả chúng ta rằng chúng ta cần xây dựng các dự án dựa trên những kiến thức về kỹ thuật. Điều này rất dễ được nhận thấy và được chú ý trong dự án phát triển phần mềm.

Việc có được những design , technique tốt và thường xuyên cải tiến chúng là việc làm mang tính quyết định. Nếu team chúng ta không thể nghĩ về bức tranh tổng thể lớn của dự án và nhận thấy những điều tốt nhất, con đường hiệu quả nhất để giải quyết các vấn đề hay design một chiến lược phát triển dự án thì bạn đã vô tình thiết lập cho bạn để làm rất nhiều những việc không cần thiết sau đó. Và có thể kết thúc với sự lãng phí rất lớn, thứ mà ta có thể tránh được.

Các dự án Agile hầu hết đều chưa được làm trước đó bao giờ nên chắc chắn là không thể chỉ có một con đường đúng đắn. Do đó chúng ta cần thử nghiệm, lựa chọn và refactor chúng. Refactor giống như là việc dọn dẹp nhà cửa, là cách để chúng ta làm mọi thứ trở nên tốt hơn, đơn giản và chắc chắn hơn. Nó có lẽ không phải là phần đẹp đẽ lôi cuốn trong coding nhưng dùng thời gian cho việc đó thực sự quan trọng. Khi làm việc trong môi trường agile, nếu chỉ nhìn về phía trước chúng ta sẽ đánh mất tầm nhìn, tổng quan về mọi thứ dự án. Cần dọn dẹp và tối ưu hoá, kể cả những thứ không thể nhìn thấy được bởi khách hàng.

10. Sự đơn giản là cần thiết - nghệ thuật tối đa hoá lượng công việc chưa hoàn thành

“Simplicity — the art of maximizing the amount of work not done— is essential.” Ta có thể giải thích nguyên tắc này cũng theo một cách đơn giản đó là: Sau tất cả thì mục đính chính đó là việc hoàn thành nhiều hơn trong thời gian ngắn hơn.

Có một câu nói mà chúng ta thường được trích dẫn từ Leonardo da Vinci là "Sự đơn giản cũng là sự tinh tế tột cùng" (Simplicity is the ultimate sophistication.) hay là nguyên tắc KISS: “Keep It Simple, Silly” . Việc phát triển phần mềm hay những hệ thống bất kỳ đều nên đơn giản và trực giác.
Lấy ví dụ đó là: bạn 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ững bản kiến trúc, yêu cầu, thiết kế tốt nhất được tạo ra từ những team tự tổ chức

“The best architectures, requirements, and designs emerge from self organizing teams.”

Đây là điểm khác biệt hoàn toàn với team trong quản lý dự án truyền thống. Trong quản lý dự án Agile, chúng ta làm việc với những member hiểu biết với trình độ và kinh nghiệm của họ, họ không cần chúng ta phải thúc ép hay chỉ dẫn nhỏ nhặt trong công việc. Những người làm việc hiểu biết hiện đại ngày nay, đặc biệt nếu là những người kinh nghiệm trong công việc sẽ đạt hiệu quả công việc tốt hơn nếu chúng ta tin tưởng trao cho họ quyền quyết định, sáng tạo. Các cá nhân vẫn cần người hướng dẫn, cần leader, nhưng lãnh đạo tốt nhất ở trong môi trường này đó là việc dẫn dắt bằng các ví dụ hay sự hướng dẫn trong quan hệ bình đẳng. Mà chúng ta có thể gọi là "lãnh đạo đầy tớ" (servent leadership)

Việc cho phép team tự tổ chức, cho phép họ làm việc gần gũi với nhau hơn, họ sẽ hiểu được giá trị của việc làm việc gắn kết chặt chẽ và học hỏi từ nhau. Một team gắn kết xuyên suốt dự án sẽ tạo ra những bản thiết kế và xử lý chúng một cách dễ dàng hơn. Nếu có lỗi xảy ra, team tự quản lý cũng dễ nhận biết nó và tìm giải pháp khác phục nhanh hơn.

Dĩ nhiên việc tự tổ chức không phải là một việc dễ dàng là việc tập hợp các thành viên và tuyên bố tự tổ chức. Đó là một quá trình phải được hướng dẫn, đào tạo để có thể tự tổ chức, và việc "tự tổ chức" đến đâu còn tuỳ 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 của người hướng dẫn Agile, sự tin tưởng của ban lãnh đạo

12. Thường xuyên nhìn nhận đánh giá làm sao để hiệu quả hơn, từ đó thay đổi và thích ứng

“At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”

Đây là nguyên tắc cuối cùng nên có lẽ nó nhắc nhở chúng ta cần phải thường xuyên nhìn lại và nghĩ về những giừ chúng ta đã làm tốt và chúng ta có thể làm gì để tốt hơn.

Tôi nghĩ rằng đây là điều mà chúng ta thường quên nhất. Chúng ta làm việc trong dự án, hoàn thành và chuyển sang dự án khác mà quên đánh giá mọi thứ đã đi như thế nào. Chúng ta có thể học được rất nhiều thứ khi chúng ta đánh giá những sai lầm và những thành công của chúng ta. Đó là một phần của cuộc sống và là một phần của dự án. Bạn rút ra được gì từ những lỗi, những sai lầm đó sẽ làm cho bạn, team của bạn, tổ chức của bạn mạnh hơn, tốt hơn và phù hợp hơn.

Để nhìn về phía trước, chúng ta cần nhìn lại. Nếu chúng ta không giành thời gian định kỳ để kiểm tra và đánh giá những gì đã làm, thì chúng ta sẽ không học được bài học gì cả. Tuy nhiên thì **những bài học chúng ta rút ra được cũng cần được chia sẻ để mọi người cùng biết và đúc rút kinh nghiệm. **

KeyWord

Qua 12 nguyên tắc mà mình tìm hiểu và chia sẻ, hi vọng chúng ta sẽ hiểu hơn về chúng và áp dụng vào trong các dự án để đem lại hiệu quả trong công việc. Tuy nhiên 12 nguyên tắc khá là dài và khó nhớ, vì vậy chúng ta chỉ cần nhớ key word của chúng theo cách như sau:

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

→ “continuous value"

2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

→ “welcome change"

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

→ “Deliver frequently”

4. Business people and developers must work together daily throughout the project.

→ “Work together”

5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

→ “Motivate people”

6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

→ “Communicate face-to-face”

7. Working software is the primary measure of progress.

→ “Working product”

8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

→ “Maintain pace”

9. Continuous attention to technical excellence and good design enhances agility.

→ “Good design”

10. Simplicity--the art of maximizing the amount of work not done--is essential.

→ “Keep in simple”

11. The best architectures, requirements, and designs emerge from self-organizing teams.

→ “Self-organizing teams”

12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

→ “Reflect”

Tham Khảo