Agile - Hãy thôi mơ mộng

Nếu bạn đang làm việc trong "ngành", hẳn bạn biết đến một xu hướng được rất nhiều người quan tâm và theo đuổi tên là Agile. Vậy ấn tượng của bạn về Agile như thế nào? Yêu thích, mến mộ hay ghét bỏ?

Nếu bạn đã từng "Agile" rồi, bạn có muốn tiếp tục truyền bá Agile không? hay bạn đã chán nản và muốn bài trừ nó?

Tôi thì sao? xin trả lời luôn, Tôi là anti-fan của Agile.

Agile Risky Adventure

Note trước: Bài viết tổng hợp và biên dịch từ nguồn, kèm theo một số diễn giải từ kinh nghiệm cá nhân.

Link bài viết gốc

Agile, Scrum là gì?

Agile là gì ư? hãy hỏi thẳng những nhà sáng lập, chứ tôi làm sao biết ^.*

Nhưng nhìn chung, cho tới nay - 2017, Agile (bao gồm cả Scrum) đã trở thành một loại tôn giáo trong ngành phần mềm. Và những "chiên gia" (Consultant) về qui trình đang cố bán cho khách hàng loại thuốc an thần "Agile" bất chấp mọi rủi ro.

Xin mời xem qua Tuyên ngôn và Nguyên tắc của Agile trước:

Agile Manifesto

Agile Principles

Scrum: là phiên bản hiện thực hóa của lý tưởng Agile


1. Về 4 tuyên ngôn của Agile

Đoạn này xin mượn ý của Luke Halliwell - 1 Game Developer "chân chính", link bài gốc ở phần tham khảo cuối bài.

1 Individuals and interactions over processes and tools

Vâng, dĩ nhiên con người và sự tương tác là thứ quan trọng hơn. Nhưng ngạc nhiên chưa, Agile hoàn toàn nói về qui trình, và cách áp dụng nó, hiếm khi nào Agile nhắc tới yếu tố con người mới chính là quan trọng nhất trong 1 dự án.

2 Working software over comprehensive documentation

Như Luke nói thì công việc của anh ta chẳng có nhiều tài liệu để nhúng tay vào, hơn nữa nó sẽ khuyến khích dân chúng bỏ bê việc tài liệu, việc đó thì hơi đáng sợ hehe.
Ngoài ra, trong mảng Software service, Maintenance, Support, Security, Cloud-based service... thì Document là cực kỳ quan trọng đối với khách hàng. Cá nhân tôi đã làm những task 40h nhưng chỉ 8h là dev, và 32h còn lại chỉ để documenting... So what?
Như vậy, ưu tiên documentation hay software, cũng tùy theo dự án mà thôi.

3 Customer collaboration over contract negotiation

Đáng buồn là trên thực tế, "Customer collaboration" thường là một câu chuyện thảm họa. Đôi khi 1 task đơn giản, bạn phải bỏ tận 6h chỉ để get confirm từ customer, sau đó dev 2h. Vui vẻ.
Chưa kể là khi được đà custom, change mà ko có evidence, contract, aggrement thì cực kỳ rủi ro và nó xảy ra cũng thường xuyên lắm :))

4 Responding to change over following a plan

Thứ nhứt, tôi xin cam đoan là ko có một thợ code nào khoái sự thay đổi từ khách hàng cả.
Thứ hai, làm việc mà ko có 1 kế hoạch, rất mù quáng, giống như lái xe từ quê lên Saigon chơi mà ko cần bản đồ vậy =))

2. Về 12 nguyên tắc của của Agile

Khi đọc về Triết lý và Tuyên ngôn của Agile, hẳn bạn thấy nó rất hay và hấp dẫn, dĩ nhiên cả với 12 nguyên tắc của Agile nữa, cứ như bạn vừa mới được giác ngộ vậy ahaha. Nhưng xin hãy chậm lại, dừng lại và hãy đọc thật kỹ, một lần nữa: thật kỹ! Nghiền ngẫm và "thấm đòn" đến một lúc, bạn sẽ thấy sự thực, toàn bộ 12 nguyên tắc của Agile sẽ rơi vào 1 trong 2 trường hợp:

Trường hợp thứ nhất, nó chỉ là "Common Sense"? tức là những lẽ thường, dễ dàng nhận thấy, nếu bạn đủ khôn ngoan để nhận ra.

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

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

Continuous attention to technical excellence and good design enhances agility.

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

Và triết lý Agile chỉ đúc kết, cường điệu những điều đó mà thôi. Chúng ta đều biết nó đúng, hay, và bổ ích, và hiện tại chúng ta vẫn đang "Agile"!

Còn "Agile" đến mức độ nào ư? Nó còn tùy thuộc vào văn hóa, môi trường, phong cách của từng công ty, Ví dụ như Google

Trường hợp thứ hai, dưới góc độ là developer, chỉ cần bạn làm việc đủ lâu trong ngành phần mềm thì bạn sẽ thấy: những nguyên tắc này mơ hồ, thiếu thực tế, nó chỉ đúng trong môi trường lý tưởng. Nghĩa là ko áp dụng được nhiều như quảng cáo, ko phù hợp với đại đa số dự án...

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

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

Welcome changing requirements, even late in development

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

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

Bạn có nghĩ là dev có thể giao tiếp "ngang cấp" với khách hàng của họ? 2 bên thấu hiểu nhau? Riêng tôi cho rằng: thiếu thực tế!

Tôi ko biết bạn là ai: dev, tester, leader, designer, taxi driver, police officer... nhưng bạn có "welcome changing requirements" ko?

Cuối cùng, bạn có tin việc liên tiếp giao "một phiên bản hoạt động đc" của sản phẩm là khả thi? Tôi e rằng câu trả lời là không, cho đại đa số dự án.

3. Kể tội Agile/Scrum

Nếu phải liệt kê toàn bộ những chỉ trích của lập trình viên chuyên nghiệp - những người trong cuộc, dành cho Agile/Scrum, thì có lẽ phải tổng hợp và biên dịch thành series chục bài. Để khởi động - hâm nóng máy móc, mời các bạn đọc qua 2 blog và 1 Q&A trên Quora trước:

  1. Tại sao dev ở những cty sừng sỏ như Google coi Agile là điều vô nghĩa?

  2. Agile và đặc biệt là Scrum, những thứ khủng khiếp

  3. Bệnh dịch Agile

Ở mỗi bài viết, các bạn hãy chú ý đọc thêm câu trả lời và bình luận phía dưới, bạn sẽ thấy một Agile/Scrum xấu xí như thế nào.

Và thực trạng Agile/Scrum ở Việt Nam, còn khủng khiếp hơn. Trên mặt báo, website, blog, hầu hết cái bài viết đều kể về một Agile lý tưởng, đẹp đẽ. Nhưng đằng sau đó thì sao? Các bạn có thực sự hài lòng, yêu thích Agile, mong muốn Scrumming everyday? Hãy thành thật với bản thân, nếu câu trả lời vẫn là có, thì mời bạn tiếp tục đọc một vài phân tích nữa, bên dưới.

Agile là sản phẩm thương mại

Trong bài viết của Luke, anh ấy gợi ý bạn đọc hãy xem qua website của những "nhà sáng lập" Agile, hãy xem và cảm nhận mức độ thương mại của những website đó. Muốn học Agile? Hãy mua sách của của tôi. Muốn tìm hiểu, hãy đến seminar của chúng tôi. Muốn áp dụng Rapid Development? Hãy thuê Scrum Master về để cải thiện Scrum...

Agile, xuất phát từ những chuyên gia tư vấn này mà ra, và chỉ thực sự phù hợp với một số dự án đặc thù, nhưng họ đã nâng tầm Agile/Scrum lên, mục đích có lẽ để biến nó thành một sản phẩm thương mại. Cũng với hình hài đó, ở Việt Nam, phía sau những bài viết hay ho về Agile, đa số là bán khóa học, bán sách, bán vé hội thảo. Tôi xin phép ko nêu rõ, nhưng bạn hãy thử truy tìm mà xem.

Scrum Master chính là một minh chứng cho tính thương mại của Agile/Scrum, một vị trí thừa thải, ko có thực quyền nhưng lại phải nhận trách nhiệm để suốt ngày ba hoa về qui trình cải thiện, về stand-up meeting, về estimate...và rất sùng đạo (đạo Agile ahaha). Kể cả với một vai trò nửa mùa như vậy, nhưng dân tình vẫn bán các khóa training "Path to Scrum Master", Oh money talks?

Có một điều rất thú vị về Agile/Scrum mà Tôi thường gặp. Nếu bạn tranh cãi với fan cuồng Agile/tín đồ Scrum về tính khả thi của Scrum, sau một hồi dẫn chứng về các dự án áp dụng Scrum thất bại, team chao đảo vì Scrum, dẫn lời những bôi bác của ltv dành cho Scrum, thì bạn luôn luôn nhận được câu trả lời: "Đó là tại tụi mày ko biết cách áp dụng Scrum và Agile thôi, do tụi mày làm sai qui trình..." Tôi đã rất bối rối, rằng thứ Methodology kiểu méo gì mà khó áp dụng thế??? Tại sao tốn quá nhiều thời gian, tiền bạc và nhân lực mà vẫn ko làm đúng được, Tôi đã quên cái gì chăng?

Chôm chỉa đâu đó trên reddit:

  • Nếu mày bê nguyên si mô hình Scrum vào dự án và thất bại, đó là tại mày ko biết cuztum Scrum.

  • Nếu mày chế biến Scrum để áp dụng và thất bại, đó là tại mày Cuztum mà ko follow đúng theo Scrum.

  • Nếu mày Scrum thành công, thì do Scrum hoàn hảo.

Kidding me?

Môi trường làm việc mà Agile hướng tới

High-talent people is more important and success than micro - managed team & processes

Trích từ bài viết của Michael, trong ngành Software Engineering, tồn tại 2 thể loại công ty: Business-driven và Engineering-driven.

Khi công ty được điều hành bởi kỹ sư (Engineering-driven), sẽ rất khó khăn và nhiều thách thức, điều đó ko phải lúc nào cũng tốt. Nhưng trong môi trường đó, nơi mà vai trò của kỹ sư được đề cao và tin tưởng. Sản phẩm, công việc anh ấy hoàn thành được tôn trọng và công nhận. Và ai cũng sẽ happy với task/job của mình. Như vậy cty có khả năng lớn sản sinh ra những sản phẩm chất lượng cao (Yếu tố con người)

Ok, còn với công ty dạng Business-driven thì sao? Ổn thôi, theo Michael, thì trong trường hợp này bạn nên tìm đến contractors, tuyển lính đánh thuê theo job, và đó là lựa chọn tốt nhất nếu bạn muốn có những kỹ sư chất lượng cao. Vì những kỹ sư tài năng đã chọn những công ty engineering-driven mất rồi.

Trong ngữ cảnh này, rất tiếc Scrum (Agile implemented) thường hướng công ty theo con đường Business-driven, nơi mà lời nói của khách hàng là tối thượng, dev ko có tiếng nói và được setup để vào the-same-team-of-low-lvel, tức là 1 đội ko có thứ hạng, kỹ năng của người trong đội được coi là như nhau. Chi tiết công việc hằng ngày dev làm sẽ phải giải trình với Scrum master (the big scam of Scrum) hay Product Owner, 1 dạng qui trình micro-managed mà ko dev nào muốn bị áp đặt cộng thêm 1 loại non-technical manager ko dev nào muốn dưới quyền.

Agile sẽ gây tổn hại đến career path của 1 Developer

Tiếp tục trích dẫn blog của Michael O Church

Instead of working on actual, long-term projects that a person could get excited about, they’re relegated to working on atomized, feature-level “user stories” and often disallowed to work on improvements that can’t be related to short-term, immediate business needs (often delivered from on-high)

Khi bước vào tuổi chín của sự nghiệp (khoảng 30), bạn - 1 kỹ sư phần mềm, mong muốn mình có thể gánh vác những công việc tầm cỡ về hạ tầng hệ thống, kiến trúc, nghiên cứu, và khả năng lãnh đạo. Trong khi với Agile/Scrum, ngày qua ngày bạn được giao những công việc ngắn hạn theo "User story" (khoảng 2 tuần), và những công việc này - như Michael nói, chính là "grunt work". Những "User Story" này sẽ giết chết tính sáng tạo, cũng như con đường nghiên cứu phát triển (R&D).

Grunt, làm tôi nhớ tới con orc cầm búa trong Warcraft 3, grunt orc chỉ biết cầm búa và lao vào đối thủ, không có 1 kỹ năng nào khác =)). Và grunt work - chính là loại công việc mà 1 anh grunt đảm nhận. Những feature tẻ nhạt, lặp đi lặp lại, ngắn hạn, thiếu sáng tạo để đáp ứng ngay cho nhu cầu cấp thiết của Client.

4. Vậy khi nào nên áp dụng Agile/Scrum?

Agile/Scrum dành cho những dự án đột xuất, khẩn cấp và yêu cầu hàng đầu là delivery, tức là phải xong việc thật nhanh.

Khi nhận dự án kiểu này, cty sẽ lập 1 team với những chiến binh kinh nghiệm nhất: Dev nhanh, chịu OT, có trách nhiệm cao, ko phàn nàn với sự thay đổi liên tục từ khách hàng.

Team sẽ có 1 Leader, hoặc Executive có lẽ tốt hơn -> xin gọi tắt là Osin. Trách nhiệm chính của Osin là làm cầu nối giữa client và dev team. Công việc chủ yếu của Osin:

  1. Lắng nghe yêu cầu/thay đổi của khách hàng (User Story) sau đó chuyển dịch nó ra thành technical-task cho dev team.
  2. Giải thích technical thing sao cho dễ nghe với khách hàng và giúp họ lựa chọn giải pháp kỹ thuật.
  3. Dựa trên estimation của team (hoặc member) để thỏa thuận với khách hàng về thời gian hoàn thành.
  4. Overview toàn bộ mọi thứ team đang làm để đảm bảo "all jobs will be done"!

Hãy luôn ghi nhớ rằng, bản chất của những dự án này là "Rapid", "Short-term", "Deliver First". Tham gia quá nhiều dự án dạng này sẽ ảnh hưởng lớn đến sự phát triển của 1 kỹ sư chuyên nghiệp. Vậy hãy lưu ý khi thực hiện:

  1. Nó chỉ nên xảy ra 1 hoặc 2 lần trong năm cho mỗi cá nhân tham gia. Nếu cty áp dụng Rapid Development quá nhiều cho 1 cá nhân thì chắc chắn có gì đó sai sót, hãy xem xét lại những vấn đề ở thượng tầng (như cách quản lý Client Relationship chẳng hạn).
  2. Trong thời gian diễn ra, mọi người phải thống nhất rõ ràng trước là ko đánh giá hiệu suất cá nhân mà chỉ tập trung vào nhiệm vụ.
  3. Giảm tối thiểu Micro-manage, 1 điều ko tránh khỏi đối với Agile

Micro-manage là vấn đề thường xuyên gặp trong các môi trường khác kể cả ngoài Agile và ngoài lĩnh vực Software. Văn hóa làm việc kiểu này sẽ làm những chiến binh ưu tú khó chịu và giảm hiệu quả khi bị giám sát/theo dõi. Rủi ro thay, Scrum rất đề cao sự minh bạch và thanh tra (a.k.a micro-manage)

Note: Ở trong blog của Michael, có một phần khá dài về Violent Transparency Culture, chính là đang đề cập tới vấn đề trên.

Chống chỉ định

Những kiểu dự án như sau là thể loại ko nên áp dụng Agile/Scrum:

  • Dự án có độ phức tạp lớn, về mặt technical có nhiều vấn đề cần giải quyết và cần thời gian dài (ko thể xác định hay ước lượng rõ ràng) để giải quyết. Khi đó rất khó để đưa giải thích hoặc deliver thường xuyên cho khách hàng.

  • Dự án về Game, tương tự như trên. Bạn ko thể giao 1 phần gì đó để khách hàng có thể xem xét và chỉnh sửa đc.

  • Những dự án sáng tạo, nghiên cứu & thử nghiệm.

[put here more]


Lời kết

Nếu bạn là leader/manager, hãy tỉnh táo và cân nhắc thật kỹ, lựa chọn sáng suốt, trước khi đưa toàn bộ đoàn tàu vào đường hầm...

Nếu bạn là developer, cảm thấy Agile hay ho, vui vẻ? Hãy cứ tận hưởng, nhưng chỉ vậy thôi, đừng dấn thân. Hãy thôi mơ mộng và nghiêm túc nhìn nhận lại những gì Agile/Scrum mang đến cho bạn.

References

https://michaelochurch.wordpress.com/2015/06/06/why-agile-and-especially-scrum-are-terrible/

https://lukehalliwell.wordpress.com/2008/11/16/the-agile-disease/

https://www.quora.com/Why-do-some-developers-at-strong-companies-like-Google-consider-Agile-development-to-be-nonsense

Bình luận


White
{{ comment.user.name }}
Bỏ hay Hay
{{comment.like_count}}
Male avatar
{{ comment_error }}
Hủy
   

Hiển thị thử

Chỉnh sửa

White

Phuoc-Thanh Do

6 bài viết.
82 người follow
Kipalog
{{userFollowed ? 'Following' : 'Follow'}}
Cùng một tác giả
White
26 0
(Ảnh) Satoshi Nakamoto cùng câu chuyện đắt giá: Bitcoin, có lẽ đã ko còn quá xa lạ trong giới công nghệ nữa, vậy "Blockchain" thì sao? Có phải côn...
Phuoc-Thanh Do viết 2 năm trước
26 0
White
16 1
Chào các bạn, trong chuỗi nghiên cứu của mình về Blockchain, có một bài viết khá thú vị về Database mà mình nghĩ nên chia sẽ ở đây, mong nhận đc nh...
Phuoc-Thanh Do viết hơn 1 năm trước
16 1
White
10 1
1. Câu chuyện lập trình hàm (Ảnh) Note: Để tiện cho việc đọc hiểu, tôi xin giữ nguyên ko dịch một số từ như: Functional Programming, Declarative,...
Phuoc-Thanh Do viết 2 năm trước
10 1
Bài viết liên quan
White
2 1
Lập trình đôi (pair programming) là hình thức lập trình trong đó 2 người cùng hợp tác làm việc trên cùng màn hình (có thể khác bàn phím v.v.). Bài ...
Ngoc Dao viết hơn 4 năm trước
2 1
{{like_count}}

kipalog

{{ comment_count }}

bình luận

{{liked ? "Đã kipalog" : "Kipalog"}}


White
{{userFollowed ? 'Following' : 'Follow'}}
6 bài viết.
82 người follow

 Đầu mục bài viết

Vẫn còn nữa! x

Kipalog vẫn còn rất nhiều bài viết hay và chủ đề thú vị chờ bạn khám phá!