Fun Fact: Té Ngửa Với Những Hiểu Lầm Thường Gặp Về Agile

Có một số vấn đề lặp đi lặp lại và đó là kết quả của những câu chuyện “thần thoại” mà mọi người nghĩ về Agile. Do đó, tôi sẽ dành thời gian của mình để debug những huyền thoại này một lần nữa.

Tôi đã lên một danh sách và hàng chục câu chuyện “thần thoại: để tái hiện lại sự thật đằng sau những gì mọi người thường hiểu về Agile. Tôi nói “thần thoại” bởi vì tất cả chúng dường như xuất phát từ một sự thiếu hiểu biết một về Agile hoặc hiểu lầm hoàn toàn phương pháp luận. Tất nhiên, nếu bạn đã thực hiện Agile, từng nhiều lần dạo qua các cộng đồng Agile trong một thời gian, bạn có thể thấy bất ngờ với một trong vài sự thật này. Dưới đây là một số hiểu lầm tôi thường thấy về Agile:

1. Khi làm Agile, bạn không cần bất cứ tài liệu nào

Đó không phải là sự thật. Tuy nhiên: Agile có lẽ có nghĩa là ít tài liệu hơn. Trong cuốn sách năm 2008 – Áp Dụng Những Phương Pháp Phát Triển Phần Mềm, Capers Jones nói: “Đối với các dự án phần mềm lớn, chi phí sản xuất tài liệu giấy đôi khi còn đắt hơn việc trả tiền cho các lập trình viên ngồi code” Thật không may, tài liệu không chỉ tốn kém chi phí, đôi khi nó là một trở ngại trong giao tiếp vì mọi người thường hay có tật “giấu nghề” nếu viết mọi thứ ra giấy. Nếu ai đó sẵn sàng trả tiền cho một tài liệu nào đó, thì nó phải có giá trị và phải được lên lịch và phát triển theo cách phát triển code.

2. Không cần thiết kế khi làm Agile

Không. Agile không có nghĩa là không có “thiết kế”. Tôi nghĩ rằng để luyện tập Agile, có lẽ cần thiết kế thêm. Thiết kế là cách mà mọi quy trình phát triển. Tuy nhiên, Agile có nghĩa là bạn không cần một thiết kế hoành tráng trước mắt mà mất hiệu lực năm phút sau khi ai đó bắt đầu code. Thiết kế hoành tráng không có ý nghĩa lắm với Agile. Agile cần có một khung thiết kế hiện rõ dần qua các công đoạn tái cấu trúc, khi lập trình viên bắt đầu cải thiện thiết kế của code.

3. Làm Agile không cần đến kế hoạch

Một lần nữa, hiểu lầm này là sai hoàn toàn. Chúng ta cần lập kế hoạch nhiều hơn cho từng phần của team. Kế hoạch sẽ phát sinh khi mọi người bắt tay vào làm, giống như thiết kế. Công việc này đương nhiên liên quan đến tất cả mọi người chứ không riêng một vài cá nhân.

Cũng giống như thiết kế – Team Agile không cần những kế hoạch hoành tráng trước mắt. Theo kinh nghiệm của tôi, những kế hoạch kiểu này sẽ nhanh chóng lỗi thời và cần phải đổi mới liên tục. Nhưng nhiều khi khách hàng lại có kế hoạch ngược với Agile. Ví dụ, một kế hoạch cần chuyển giao sản phẩm X vào một ngày nhất định. Nếu không chuyển giao sản phẩm đúng bạn, khách hàng sẽ cho rằng đó là do sự yếu kém của team chứ không phải do kế hoạch. Bạn không cần một kế hoạch trước mắt, nhưng bạn cần một kế hoạch dài hạn.

4. Có một công thức chung cho mọi người dùng Agile

Không có công thức chung nào cho người dùng. Mỗi đội sẽ làm mỗi khác. Tôi có 2 nguyên tắc cho việc phát triển bất cứ phần mềm nào: Trước hết, nó phải đủ nhỏ để được phân phối ngay sau đó, nghĩa là sẽ mất vài tháng. Tiếp theo, nó có giá trị kinh doanh theo cách riêng của nó.

2 nguyên tắc này thường lái những câu chuyện phát triển phần mềm theo nhiều hướng. Nhưng nó chỉ phục vụ cho mục đích tìm ra những công việc thực sự có giá trị. Độ lớn của một dự án thường là tổng hòa của kinh nghiệm và kiến thức của đội ngũ lập trình viên.

5. Tất cả công việc phải khớp vào phân đoạn (sprint)

Nếu bạn đang làm hardcore Scrum thì đúng, mọi quy trình sẽ xuất phát và kết thúc trong phân đoạn. Nhưng phần lớn các đội không làm như vậy, mà xen kẽ hoặc phá vỡ những quy trình theo cách nào đó. Tôi khuyên các đội nên chia nhỏ những mục tiêu định hướng về kinh doanh thành các nhiệm vụ phát triển.

Tôi khuyến khích việc mở rộng phân đoạn để cải thiện luồng công việc nhưng không thể làm điều đó quá thường xuyên. Việc áp dụng nguyên tắc “hoàn thành tất cả trong một phân đoạn” chỉ thích hợp với những công việc quy mô nhỏ.

6. Developer có thể làm bất cứ điều gì họ thích

Không, các lập trình viên không thể thích gì làm nấy. Nếu bạn thấy bản thân mình trong đó, chắc chắn bạn đang làm sai. Agile cần những đội có ỷ luật. Những gì được thực hiện phải được dẫn dắt từ một chỉ đạo cụ thể, tùy theo khách hàng.

Agile là một quá trình cộng tác, thảo luận và đàm phán giữa những người đang xây dựng hệ thống và người yêu cầu hệ thống.

7. Scrum và Kanban là kẻ thù truyền kiếp

Các bạn có thể nghe thấy nhiều người nói điều này, nhưng tôi hoài nghi rằng, những cạnh tranh trong nỗ lực tiếp thị đằng sau cả hai phương pháp chỉ để chứng minh phương pháp nào hữu hiệu nào hơn thôi.

Theo kinh nghiệm của tôi, nhiều đội đang kết hợp ý tưởng từ các phương pháp lặp đi lặp lại (Scrum và XP) với những ý tưởng từ Kanban. Ví dụ như Scrumban được phát minh bởi Corey Ladas hay Xanpan của riêng tôi (sự hợp nhất của XP và Kanban).

8. Agile không thích hợp cho những dự án có thời hạn cố định

Thực tế là, Agile hoạt động tốt nhất trong môi trường dự án có thời hạn xác định. Khi các thành viên trong đội sử dụng Agile, đặc biệt là các phiên bản Scrum và XP, họ sẽ nhận được nhiều quyền lực từ sức ép của thời hạn: kiểm điểm công việc đến hạn chót, động lựa cá nhân và sẵn sàng đàm phán lại những gì đang được xây dựng để đáp ứng thời hạn.

Phương pháp Agile cũng thích hợp cho những công việc cố định giá do chi phí dự án thường bằng chi phí tiền lương nhân với thời gian.

9. Agile không thích hợp với những dự án có vốn đầu tư nước ngoài (kể cả Greenfield và Brownfield)

Agile hoạt động tốt nhất trong môi trường với một thứ gì sẵn có, được gọi là Brownfield. Việc thêm các bài kiểm tra tự động vào một hệ thống sẵn có khó hơn nhiều so với việc tạo những kiểm thử mới cho hệ thống mới, nhưng không phải không làm được.

Nhiều người cũng nói, Agile không thích hợp với các dự án Greenfield, tức là những dự án đầu tư mới hoàn toàn. Nhưng hãy nhớ rằng mục tiêu của bạn là đạt được trạng thái ổn định cho dự án, khi đó bạn có thể điều hành tương tự như các dự án Brownfield. Kiểm thử tự động trong môi trường Greenfield dễ hơn, nhưng việc phát triển mà không có codebase hay sản phẩm nào có sẵn chứa đựng nhiều khó khan. Các lập trình viên cần loại bỏ suy nghĩ “Được ăn cả, ngã về không”. Thêm vào đó, các thành viên cần chấp nhận việc thay đổi một thiết kế liên tục trong quá trình người dùng trải nghiệm sản phẩm.

10. Khi làm Agile, bạn có thể trì hoãn lại một lúc cũng được

Bản thân tôi cũng thường xuyên bào chữa cho sự chậm trễ về thời gian với Agile. Bạn có thể luôn viện ra một cớ gì đó để không làm nó ngay hôm nay. Tôi tin rằng bạn sẽ thay đổi khi bạn quyết định bắt tay vào làm ngay khi bạn thấy cần thiết. Tôi nghi một dự án Agile lý tưởng được thực hiện với hệ thống Brownfield, có thời hạn cố định trong khoảng 3 đến 6 tháng (đương nhiên chưa nói đến những yêu cầu của khách hàng).

Tổng kết

Trên đây là 12 hiểu lầm phổ biến nhất về Agile tôi thường gặp. Có thể bạn từng thấy hoặc chưa từng thấy một trong số ấy. Hy vọng tôi đã “khai quật” được những điều thầm kín mà ít người tiết lộ ra bấy lâu nay.

                               Nguồn: AgileConnection & Potato