Agile đang giết chết đổi mới phần mềm

• Tại hội nghị Black Hat, nhà sáng lập Signal Moxie Marlinspike cho rằng trong 20 năm qua, đổi mới phần mềm đã biến mất vì phát triển Agile
• Ông chỉ ra rằng các nhà phát triển bị mắc kẹt trong những "lớp trừu tượng hóa hộp đen" và đã đánh mất sự tự do cần thiết cho đổi mới
• "Bất kỳ ai quản lý một tổ chức kỹ thuật đều có một triết lý quản trị hoặc là khái niệm con của Agile, hoặc là khái niệm phái sinh, hoặc nằm trong phạm vi của Agile, hoặc có liên quan đến Agile theo cách nào đó"
  • Thay vì vận động theo hướng từ dưới lên, nơi nhà phát triển kết hợp chuyên môn kỹ thuật với tầm nhìn để nhìn ra những khả năng mới của công nghệ hiện có,
    ông cho rằng các nhóm Agile bị silo hóa (cô lập) thành từng đơn vị riêng lẻ, làm việc tách biệt và không thể nắm được các nhóm khác đang làm gì
• Trong phần kết thúc, Window Snyder, nhà sáng lập kiêm CEO của Thistle Technologies, cũng nói thêm rằng các nhóm hộp đen như vậy thường thiếu khả năng quan sát về nguyên lý vận hành của chính sản phẩm họ làm ra
  • Snyder cũng lập luận rằng sinh viên học lập trình không học cách tương tác với ngôn ngữ cấp thấp hay mã máy, mà chỉ học các ngôn ngữ bậc cao giúp việc phát triển ứng dụng trở nên trơn tru, nên các kỹ sư thiếu bối cảnh cần thiết để hiểu các mảnh ghép của bài toán khớp vào một tổng thể lớn hơn như thế nào

Các nhà nghiên cứu bảo mật đang nắm giữ chìa khóa của đổi mới

• Marlinspike cũng nói rằng trong vài thập niên qua, kỹ nghệ phần mềm ngày càng được trừu tượng hóa để nhanh hơn, linh hoạt hơn và tiến xa hơn, trong khi các nhà nghiên cứu bảo mật vẫn luôn cố gắng nhìn xuyên qua các lớp trừu tượng đó
  • "Bảo mật là quá trình nhìn vào cái trừu tượng để hiểu nó thực sự vận hành như thế nào, bên dưới có gì, và đôi khi còn hiểu rõ hơn cả người đã tạo ra nó từ đầu"
• Vì vậy, ông cho rằng các nhà nghiên cứu bảo mật đang nắm giữ chìa khóa để dẫn dắt làn sóng đổi mới mới
• Ông cũng ví việc hiểu phần mềm giống như hiểu phép thuật, còn các chuyên gia bảo mật là "những người ngồi trong thư viện nghiên cứu phép thuật"

Ý kiến của GN⁺

• Đây là những nhận xét sâu sắc của Marlinspike khi chỉ ra một cách sắc bén các vấn đề cốt lõi của Agile
• Có thể đồng cảm với nhận định rằng việc quá ám ảnh với trừu tượng hóa và tốc độ phát triển nhanh đang khiến các nhà phát triển ngày càng xa rời các khái niệm nền tảng
• Điểm nhấn vào vai trò của các nhà nghiên cứu bảo mật là rất ấn tượng. Vì bảo mật là công việc đào sâu vào thực thể ẩn sau các lớp trừu tượng, nó có thể trở thành động lực của đổi mới
• Xét cho cùng, đây cũng là một thông điệp rằng các kỹ sư phần mềm cần theo đuổi sự hiểu biết sâu hơn
• Dù vậy, Agile rõ ràng cũng có những ưu điểm, nên cần một cách tiếp cận cân bằng. Cần tìm ra phương án vừa duy trì được tính nhanh nhẹn và linh hoạt của Agile, vừa củng cố vững chắc nền tảng
• Để làm được điều đó, cần cải thiện ngay từ chương trình đào tạo phát triển phần mềm. Không chỉ ngôn ngữ bậc cao mà cả ngôn ngữ cấp thấp, kiến trúc máy tính và các môn cơ sở cũng cần được tăng cường giảng dạy

[jeokrang]

Có vẻ như mọi người đang nhầm vấn đề của những nhà quản lý hiểu sai về Agile thành vấn đề của chính Agile.

[yangeok]

Dường như theo dòng chảy của thời đại, vì học kiến thức cấp thấp không còn mang lại ROI nên người ta chỉ dừng lại ở việc học kiến thức cấp cao.

[andrewchaa]

Tại sao lại đi bắt bẻ Agile vô cớ như vậy ...

[lordang]

Có vẻ đang nói lẫn lộn giữa khái niệm north-south và east-west nên nội dung khá khó hiểu.
Việc không biết các nhóm khác đang làm gì thì có lẽ vấn đề nằm ở cấu trúc tổ chức cross-functional hơn là bản thân Agile.

Còn chuyện không hiểu rõ low level thì, nhìn nội dung có vẻ chỉ đang nói kiểu “như vậy thì cũng có xu hướng không biết rõ low level”.

Dù cho việc không biết nhóm khác làm gì có thể coi là ít nhiều liên quan đến Agile đi nữa, thì tôi vẫn không hiểu chuyện không biết low level thì có liên quan gì đến Agile hahaha

[lordang]

Nếu buộc phải phân biệt cho kỹ thì có lẽ nói rằng khi mã nguồn mở đã lan rộng, không còn cần phải tự tay làm tất cả nữa, nên không còn reinventing wheel, và vì phía low level thì cứ mang về dùng sẵn hết nên thành ra không cần học, có lẽ còn đúng hơn.

Nếu cố hiểu câu đó thì có thể hiểu theo kiểu vì Agile nên chỉ lo làm cho nhanh, thành ra không học low level, nhưng chẳng phải nói là vì không cần nên không học mới đúng hơn sao.

[bbulbum]

Tôi nghĩ việc sử dụng Agile đang khiến những lựa chọn giúp nhìn vấn đề từ góc độ rộng hơn và duy trì tính bền vững lâu dài dần bị xem nhẹ, và từ góc độ phần mềm, điều đó cũng khiến người ta ngày càng chỉ tập trung vào việc giải quyết những vấn đề trước mắt. Dĩ nhiên, làm cho nó chạy được bằng mọi giá không phải là Agile, nhưng có vẻ đang xuất hiện xu hướng đưa ra những lựa chọn quá thiên về tốc độ, và tôi nghĩ đây có thể là một yếu tố khiến việc theo đuổi sự thấu hiểu sâu sắc trở nên khó khăn hơn.

[savvykang]

Tôi không hiểu vì sao người ta lại cố tìm nguyên nhân của vấn đề các tổ chức kỹ thuật không có quyền ra quyết định ở Agile.

[galadbran]

Không biết tình trạng không biết đội khác đang làm gì thì có liên quan gì đến Agile nữa... ;;;

Nhưng mà cái tên Window Snyder đúng là khá đặc biệt...

[xguru]

Tôi muốn xem video gốc nhưng hình như vẫn chưa có. Có lẽ sau một thời gian nữa nó sẽ được đăng lên YouTube chính thức. https://www.youtube.com/@BlackHatOfficialYT/

[GN⁺]

Ý kiến trên Hacker News

• Nguồn gốc vấn đề nằm ở cấu trúc doanh nghiệp hiện đại

  • Có một lý thuyết quản trị hiện đại cho rằng trách nhiệm và việc ra quyết định phải đi lên theo hệ thống phân cấp của công ty
  • Nhân viên cấp dưới bị xem là những người biết ít nhất về sản phẩm
  • Nhưng trên thực tế, những nhân viên ở tuyến đầu lại là người nắm nhiều thông tin nhất
  • Khi biến kỹ thuật phần mềm thành một quy trình kiểu dây chuyền lắp ráp, sự đổi mới sẽ dừng lại
  • Cấu trúc quản lý hoàn toàn bình đẳng không phải là câu trả lời, nhưng cần một cách không làm mất quyền của nhân viên tuyến đầu
  • Cuốn sách <i>Reinventing Organisations</i> giải thích về các cấu trúc doanh nghiệp mang tính đổi mới

• Những ý tưởng hay của Agile đã được hấp thụ vào kỹ thuật phần mềm nói chung

  • Lập trình viên Agile thường bị xem là những người tuân theo các buổi standup cứng nhắc, bảng Kanban, v.v.
  • Không cho rằng Agile đã gây ra sự phân mảnh tri thức và làm suy giảm tay nghề trong kỹ thuật phần mềm
  • Đây là vấn đề phát sinh từ xu hướng sản xuất hàng loạt
  • Hiện tượng tương tự cũng xuất hiện ở các công ty ô tô hay nhà máy nội thất

• Sự bất mãn với Agile, Scrum và OKR

  • Tất cả đều hứa hẹn sẽ trao tự do và trách nhiệm cho nhân viên cấp dưới, nhưng trên thực tế lại dẫn đến tập trung quyền lực
  • Muốn thử áp dụng OKR theo cách ngược lại
  • Mọi nhân viên nên tự định nghĩa các kết quả chủ chốt trong phạm vi của mình, và quản lý nên dựa vào đó để xác định hướng đi của nhóm
  • Cần một cách tiếp cận từ dưới lên thay vì từ trên xuống
  • Cần tuyển dụng tốt, đào tạo tốt và tin tưởng nhân viên

• Trải nghiệm trong cuộc họp grooming backlog

  • Phải ước lượng việc sửa một lỗi trong phần code không quen thuộc
  • Vì khó ước lượng nên đã nói đại một con số
  • Agile được vận hành tương tự như vậy ở ba nơi khác nhau

• Một giả thuyết về vấn đề của Agile

  • Chia công việc thành các phần nhỏ là điều có ích, nhưng lập trình đòi hỏi tính sáng tạo
  • Trong quá trình chia nhỏ công việc, rất nhiều thông tin bị mất đi
  • Lập trình viên phải tìm ra giải pháp sáng tạo nhưng lại không có được thông tin cần thiết
  • Cần những lập trình viên giàu kinh nghiệm hơn hoặc sơ đồ thiết kế và tài liệu tốt hơn

• Chất lượng phần mềm suy giảm

  • Phần mềm đã trở nên tệ hơn trong vài chục năm qua
  • Dù dùng những cỗ máy mạnh hơn nhưng độ phản hồi lại kém hơn
  • Điều này có thể có liên quan đến sự trỗi dậy của Agile

• Nên để kỹ sư "sở hữu" một phần của code

  • Đó là giai đoạn phần mềm của nhóm đạt chất lượng tốt nhất

• Trải nghiệm né tránh các cuộc họp standup hằng ngày

  • Việc liên tục hồi cứu và chia nhỏ công việc là không hiệu quả
  • Chỉ có lợi cho các quản lý không có nền tảng kỹ thuật

• Vấn đề của các tổ chức quy mô lớn

  • Các lập trình viên không còn là người dẫn dắt nữa
  • Tầm nhìn, sản phẩm, UX và quản lý dự án đều được quyết định từ cấp trên
  • Lập trình viên chỉ làm việc bằng cách sử dụng công nghệ cloud
  • Họ không thể hiểu được bức tranh tổng thể hoặc đưa ra những đề xuất quan trọng

• Ý kiến cho rằng cần lấy lại "phép màu" của phát triển phần mềm

  • Có thể thấy người này đã ở trong ngành hơn 20 năm
  • Khi dành thời gian với các lập trình viên trẻ, vẫn có thể thấy phép màu ấy tồn tại
  • Cả 20 năm trước cũng đã có những lời phàn nàn tương tự, nhưng mọi người vẫn làm việc một cách vui vẻ

[savvykang]

> Có một lý thuyết quản trị hiện đại cho rằng trách nhiệm và việc ra quyết định phải được đẩy lên theo hệ thống phân cấp của doanh nghiệp

Chẳng phải đây là đặc trưng của một tổ chức quan liêu sao?