#agile

How To Measure Developer Productivity?

Việc đo lường năng suất lập trình viên thông qua các chỉ số như lines of code, commits, pull requests hay AI tokens là cách tiếp cận lỗi thời, thậm chí trong kỷ nguyên AI. Những chỉ số này chỉ phản ánh hoạt động chứ không đo lường giá trị thực, dẫn đến lãng phí và động cơ sai lệch. Thay vào đó, nên tập trung vào kết quả kinh doanh hoặc hành vi người dùng, vì chỉ khoảng 33% ý tưởng phần mềm thực sự mang lại giá trị.

Lập trình viên nên đọc bài này để hiểu cách đo lường hiệu quả thực sự của công việc, thay vì bị lừa bởi chỉ số sản lượng, giúp họ tập trung vào giá trị tạo ra cho dự án và doanh nghiệp chứ không phải chỉ số giả tạo.

We Changed the Tool. Not Yet the Way We Work.

Scrum vốn không sinh ra từ lĩnh vực phần mềm, nhưng 40 năm sau, nó lại bộc lộ những hạn chế trong cách chúng ta áp dụng AI. Việc thay đổi công cụ (tool) không đồng nghĩa với thay đổi phương thức làm việc (way we work).

Bài viết giúp bạn nhận thức rõ cách Scrum—một khái niệm ban đầu trong quản lý dự án truyền thống—có thể phản ánh những sai lầm cơ bản trong cách hiện nay chúng ta sử dụng AI, từ đó giúp bạn tránh những rủi ro về quy trình và hiệu quả khi áp dụng công nghệ mới.

The Hyper-Velocity Trap: Why AI-Driven Feature Factories Are Killing User Experience

AI-driven feature factories đang sản xuất quá nhiều tính năng (features) nhờ tốc độ phát triển siêu nhanh, khiến trải nghiệm người dùng (UX) bị "bẫy" bởi sự hỗn loạn kỹ thuật số. Thay vì tập trung cải thiện chất lượng, các sản phẩm trở nên phức tạp, gây khó khăn cho người dùng trong việc tìm kiếm giá trị thực sự.

Lập trình viên nên đọc bài này để hiểu cách AI tự động hóa quá trình phát triển tính năng có thể làm mất đi sự trải nghiệm người dùng thiết thực, giúp họ cân bằng tốc độ phát triển với chất lượng và ý nghĩa thực tế trong ứng dụng.

InfoQ Culture and Methods Trends Report - 2026

Báo cáo xu hướng Culture and Methods 2026 của InfoQ tóm lược những xu hướng nổi bật và mới nổi trong lĩnh vực văn hóa và phương pháp phát triển phần mềm.

Những xu hướng mới về văn hóa và phương pháp làm việc trong năm 2026 sẽ giúp bạn dự đoán và ứng dụng tốt hơn cách phát triển ứng dụng, tăng hiệu suất và giữ chân đội ngũ kỹ thuật trong môi trường công nghệ đang thay đổi nhanh chóng.

August 6, 2026

Bài viết ngắn trên The Old New Thing nhắc đến loạt bài nhiều phần về cách tạo lớp "agile" giả mạo, với nội dung sơ sài chỉ gồm tiêu đề và ghi chú tạm thời về việc sắp xếp lại công việc.

Lập trình viên nên đọc bài này để hiểu cách giấu các quy trình phức tạp của Agile dưới dạng lớp vỏ đơn giản, giúp tiết kiệm thời gian và tránh rủi ro khi áp dụng các phương pháp quản lý dự án thực tế.

Agile Isn’t Dead. It won.

Agile không chết mà đã chiến thắng trong ngành phát triển phần mềm. Thuật ngữ này trở nên phổ biến đến mức xuất hiện liên tục trên LinkedIn và các nền tảng công nghệ.

Lập trình viên nên đọc bài này để hiểu cách Agile không chỉ là một phương pháp quản lý dự án mà còn là một phương pháp sống và làm việc hiệu quả giúp tối ưu hóa sự linh hoạt, chất lượng sản phẩm và sự hài lòng của đội ngũ trong công việc phát triển phần mềm.

How Two Nights of After-Work Coding Cut Our Sprint Planning From Three Days to Half a Day

Sau hai buổi code sau giờ làm, nhóm đã rút ngắn thời gian lập kế hoạch sprint từ ba ngày xuống còn nửa ngày bằng cách giải quyết vấn đề upstream thay vì đổ lỗi cho developer.

Bài viết giúp bạn hiểu cách cải thiện hiệu quả Sprint Planning bằng cách chuyển đổi từ việc chờ đợi các lập trình viên (như một vấn đề "downstream") sang việc tối ưu hóa quá trình chuẩn bị từ trước, từ đó tiết kiệm thời gian và năng lượng cho cả đội.

Build First, Discuss Later: How Prototypes Speed Up Product Decisions

Kubomi, kỹ sư iOS tại Merpay, chia sẻ trong sự kiện Merpay & Mercoin Tech Openness Month 2026 rằng việc xây dựng nguyên mẫu (prototypes) giúp đẩy nhanh quá trình đưa ra quyết định sản phẩm bằng cách "xây dựng trước, thảo luận sau".

Lập trình viên nên đọc bài này để hiểu cách prototyping không chỉ là cách thử nghiệm ý tưởng nhanh chóng mà còn là công cụ giúp tránh rắc rối về thời gian và chi phí khi phải điều chỉnh thiết kế sau khi sản phẩm đã được triển khai.

August 4, 2026

Bài viết trên blog The Old New Thing phần 2 giới thiệu cách tạo lớp wrapper giả lập Agile bằng Global Interface Table (GIT) trong lập trình COM của Windows, nhằm chuyển tiếp các tham chiếu interface COM giữa các apartments trong khi vẫn đáp ứng yêu cầu kỹ thuật của interface Agile.

Lập trình viên hãy đọc để khám phá cách khắc phục thách thức marshaling COM giữa các apartment bằng GIT, giúp tối ưu hóa hiệu suất và bảo đảm tính đồng bộ trong ứng dụng đa-thể tích (multi-apartment) theo tiêu chuẩn Agile.

“Culture Is Built in the Small Moments”: A Conversation with Practice Makes Culture Coauthor Ronica Roth

Bài phỏng vấn với Ronica Roth, đồng tác giả cuốn Practice Makes Culture, nhấn mạnh văn hóa tổ chức được hình thành từ những hành vi nhỏ hàng ngày chứ không phải từ các chương trình chuyển đổi lớn. Roth giới thiệu khung ba trụ cột của cuốn sách — giải quyết vấn đề nhạy cảm, tạo quyền sở hữu và thúc đẩy thực hành hàng ngày — và nhấn mạnh rằng các cuộc họp là một trong những công cụ mạnh mẽ nhất để thay đổi văn hóa.

Bài này giúp cho lập trình viên hiểu rằng thay vì chỉ tập trung vào công nghệ, văn hóa tổ chức—đặc biệt là những hành vi nhỏ trong code review, teamwork và giao tiếp—là yếu tố quyết định sự thành công lâu dài của dự án, vì nó tạo nên môi trường mà code thực sự phát triển và được chấp nhận.

Big Design Up Front Is Responsible Again · Los Techies

AI đã loại bỏ hai chi phí chính khiến Big Design Up Front (BDUF) trở nên bất khả thi: viết đặc tả kỹ thuật và xây dựng phần mềm. Giờ đây, một đặc tả hoàn chỉnh có thể được tạo ra trong vài giờ thay vì vài tuần, bao gồm nhu cầu của các bên liên quan, kiến trúc và các ticket cấp thành phần, sau đó được chuyển thành video thuyết minh để khách hàng xem xét trước khi viết code. Quy trình đề xuất: duy trì đặc tả sống, tạo video review từng cấp, biên dịch thành ticket cuối cùng, rồi để AI triển khai trong khi xác minh theo đặc tả đã thống nhất.

Lập trình viên nên đọc bài này để hiểu cách AI thay đổi mô hình thiết kế trước tiên (Big Design Up Front) thành một quá trình nhanh chóng, linh hoạt và giảm thiểu rủi ro sai sót khi chuyển từ khái niệm sang mã, giúp tiết kiệm thời gian và nguồn lực trong quá trình phát triển.

Canon 3X: Explore/Expand/Extract

Bài viết giới thiệu loạt bài về Canon 3X, nơi tác giả trình bày ý tưởng một cách rõ ràng, không dùng phép ẩn dụ hay thuyết phục, chỉ tập trung vào sự thật.

Bài viết này sẽ giúp bạn hiểu rõ cách Canon xây dựng logic và ngôn ngữ đơn giản để truyền tải ý tưởng trực tiếp, giúp bạn tránh rắc rối khi giải quyết vấn đề lập trình bằng cách học cách diễn đạt rõ ràng và phân tích vấn đề từ những nguyên lý cơ bản.

Welcome to the Age of Irrationality

Sometime over the last weekend I was confronted with a thought that hadn’t occurred to me before. This thought might’ve been the missing piece of the puzzle that prevented me from being able to effectively grapple with the ongoing decay of the tech industry. So what was the thought? It was simple: The presence of rationality in our industry is no longer guaranteed. Why is that important? Well it’s important because most of my opinion pieces, regardless of how you consume it or where you get it, rely heavily on the premise that regardless of whatever insane off the wall shit is happening right now, eventually the system will correct the issue because the system itself tends to move towards a more rational state over time. But what if that is no longer true? How does that change things?

How to Choose the Right Mobile App Development Services in 2026

Bài viết hướng dẫn cách lựa chọn dịch vụ phát triển ứng dụng di động phù hợp vào năm 2026, do Durapid Development xuất bản.

Lập trình viên nên đọc bài này để hiểu cách chọn đội ngũ phát triển ứng dụng chất lượng, từ đó tối ưu hóa thời gian và chi phí cho dự án của riêng mình mà không phải phụ thuộc vào những nhà cung cấp không chuyên nghiệp.

Phased Design Doesn't Have A Finish Line

Thiết kế không bao giờ có điểm kết thúc. Thay vì thiết kế theo giai đoạn là giao sản phẩm chậm hơn, quan trọng là tránh giao nhầm sản phẩm đúng tiến độ.

Lập trình viên nên đọc bài này để hiểu cách thiết kế phần mềm theo giai đoạn không chỉ là một chiến lược quản lý thời gian mà còn là cách tránh rủi ro về chất lượng và tính tương thích lâu dài khi phát triển.

Every Product Requirement is a P1

Mọi yêu cầu sản phẩm đều được ưu tiên hàng đầu (P1) dẫn đến việc chúng trở nên vô nghĩa, biến mỗi sprint thành cuộc đàm phán kéo dài.

Bài viết giúp lập trình viên hiểu cách các yêu cầu sản phẩm thường bị biến đổi trong quá trình triển khai, từ đó nhận thức rõ vai trò của họ trong việc điều chỉnh và tối ưu hóa các giải pháp kỹ thuật trước khi triển khai thực tế.

Agile UX and its associated challenges

Nhóm thiết kế sản phẩm thường gặp tình huống dự án khởi động, đội ngũ hình thành nhưng ngay cả buổi họp đầu tiên cũng chưa diễn ra, trong khi Agile UX đặt ra nhiều thách thức khi tích hợp quy trình linh hoạt với thiết kế trải nghiệm người dùng.

Lập trình viên nên đọc bài này để hiểu cách UX Agile giúp tối ưu hóa giao diện ứng dụng theo yêu cầu thực tế, giảm thiểu sự khác biệt giữa ý tưởng ban đầu và sản phẩm cuối cùng mà họ sẽ phát triển.

Steering by Value: You Can Kill a Bet, Not Confirm One

Bài viết chỉ ra rằng giá trị (value) không thể đóng vai trò tín hiệu điều khiển vì giá trị cụ thể của một hành động không đảm bảo sự thành công, thay vào đó, cần tập trung vào "kill a bet" (loại bỏ rủi ro) hơn là "confirm one" (xác nhận lợi nhuận).

Những lập trình viên cần đọc bài này để hiểu cách tránh sai lầm trong việc xây dựng hệ thống dựa trên giá trị (value-driven) mà thường dẫn đến những quyết định sai lầm, thay vì chỉ tập trung vào việc xác nhận hoặc thực hiện các dự án theo cách truyền thống.

Release Planning Explained: Coordinating Multiple Sprints Into Successful Releases

Release Planning là quá trình phối hợp nhiều Sprint để hoàn thành các bản phát hành phần mềm thành công. Nó giúp các nhóm hiện đại quản lý tiến độ, ưu tiên tính năng và đảm bảo deliverables đúng hạn.

Lập trình viên nên đọc bài này để hiểu cách tổ chức và đồng bộ hóa các sprint nhỏ thành các bản phát hành thành công, giúp tối ưu hóa tiến trình phát triển và đảm bảo chất lượng sản phẩm trong môi trường phát triển nhanh chóng.

Expanding International Career Opportunities Through Global Certifications

Chứng chỉ toàn cầu giúp mở rộng cơ hội nghề nghiệp quốc tế nhờ xu hướng tuyển dụng từ xa và làm việc xuyên lục địa. Những chứng chỉ này nâng cao kỹ năng và uy tín, giúp ứng viên cạnh tranh trên thị trường lao động toàn cầu.

Lập trình viên nên đọc bài này để khám phá cách các chứng chỉ quốc tế mở rộng cơ hội việc làm toàn cầu, giúp tăng giá trị chuyên môn và cạnh tranh trên thị trường lao động quốc tế.

Build Alignment Using a Product Requirements Document

Tài liệu Yêu cầu Sản phẩm (PRD) là phương pháp nhanh nhất để xác định liệu một nhóm có thực sự thống nhất hay không, khi vẫn còn dễ dàng điều chỉnh nếu phát hiện bất đồng.

Một lập trình viên nên đọc bài này để hiểu cách sử dụng tài liệu yêu cầu sản phẩm (PRD) không chỉ là công cụ định hướng mà còn là công cụ để xác minh sự thống nhất về mục tiêu và chi tiết kỹ thuật từ phía khách hàng trước khi bắt đầu phát triển, tránh những sai lệch hoặc thay đổi cuối cùng gây ra chi phí và thời gian dư thừa.

Integrating FMEA into Sprint Planning

Bài viết giới thiệu cách tích hợp FMEA (Failure Mode and Effects Analysis) vào Sprint Planning, nối tiếp phần 1 (nền tảng) và phần 2 (tích hợp CI/CD pipeline) trong loạt series về FMEA cho tự động hóa kiểm thử.

Lập trình viên nên đọc bài này để hiểu cách áp dụng phân tích rủi ro chức năng (FMEA) vào việc lên kế hoạch sprint, giúp tối ưu hóa chất lượng dự án và giảm thiểu lỗi trong quá trình phát triển ứng dụng.

The Great Software Regress: How "Move Fast and Break Things" Broke Our Lives

Just yesterday morning, my brand-new MINI Countryman auto-installed software update 03/2026.54. How exciting! The release notes promised groundbreaking chang...

From Output to Outcome: A Conversation with Mik Kersten

Mik Kersten, tác giả cuốn Project to Product, giới thiệu cuốn sách mới Output to Outcome, chỉ ra nghịch lý AI khi doanh nghiệp đầu tư mạnh vào AI nhưng vẫn đo lường sản lượng thay vì kết quả kinh doanh. Ông đề xuất Outcome Management như một phương pháp lãnh đạo cấp hệ thống, cùng ba mô hình nền tảng: Product Operating Model, Outcome Loop và Outcome Tree.

Lập trình viên nên đọc bài này để hiểu cách chuyển từ việc tối ưu hóa công việc kỹ thuật sang xây dựng hệ thống thực hiện kết quả kinh doanh thực tế, giúp họ ứng dụng kiến thức về Outcome Management trong dự án của mình để nâng cao hiệu quả và giá trị cho tổ chức.

The Beginnings of an Idea: XP is Long Volatility

Ý tưởng này cho rằng XP (có thể là một dự án tiền điện tử) hoạt động giống như "long volatility" (chiến lược đầu tư hưởng lợi từ biến động giá), nghĩa là nó hưởng lợi khi thị trường biến động mạnh thay vì ổn định.

Lập trình viên nên đọc bài này để hiểu cách quản lý dự án với các rủi ro không xác định thời gian diễn ra, giúp họ xây dựng chiến lược phát triển phù hợp với các dự án có tính chất không tuyến tính và biến động.

Governance Without Uniformity:

Bài viết bàn về thách thức lãnh đạo khi các team trong doanh nghiệp hoạt động theo những cách khác nhau, thay vì áp đặt một quy trình uniform.

Là người viết code và quản lý dự án, bạn cần hiểu cách điều hành đội ngũ đa dạng theo các phương pháp Agile khác nhau để tối ưu hiệu suất và tránh rủi ro khi sự đồng nhất không phải là chìa khóa.

Design Doesn’t Have A Finish Line

Thiết kế theo giai đoạn (phased design) với toàn bộ công việc thiết kế hoàn thành trước khi bước vào giai đoạn phát triển dài là cách tiếp cận thiếu sót, vì những quyết định khó nhất thường nảy sinh trong quá trình phát triển khi dữ liệu thực tế, trường hợp ngoại lệ và người dùng bộc lộ những lỗ hổng trong giả định ban đầu. Thay vào đó, nên duy trì nguồn lực thiết kế liên tục xuyên suốt dự án thay vì tập trung giai đoạn đầu, giúp giảm thiểu rủi ro đưa ra sản phẩm sai lệch đúng tiến độ.

Lập trình viên nên đọc bài này để hiểu cách thiết kế tốt nhất không phải là một quá trình hoàn thành trước khi bắt đầu xây dựng, mà là một quá trình liên tục, giúp phát hiện và khắc phục những rủi ro thực tế khi sản phẩm đang được triển khai.

“We Are 90% Done” Is the Most Expensive Sentence in Software Delivery

The phrase '90% done' is deceptive in software delivery because it measures visible code completion, not actual shippability. The final 10% routinely contains edge cases, real-data bugs, third-party integration failures, client sign-off, and deployment/rollback procedures — often representing 40–50% of the real effort. The recommended fix is to replace percentage-based progress reporting with a binary 'done-done' standard: a feature is only done when it's deployed to production, verified on real data, and signed off by someone other than the builder. Tracking shippable slices ('8 of 12 features live') instead of vague percentages gives teams an auditable, honest view of progress.

Focusing Where Mountain Goat Software Can Have the Most Impact

Mountain Goat Software, founded by Mike Cohn, is discontinuing public Scrum and agile training classes after more than two decades. The company is shifting its focus entirely to private client engagements — including private courses, workshops, and follow-through coaching — where teams can work on their actual backlogs, planning challenges, and leadership dynamics. Cohn argues that individual training alone doesn't improve team performance; real change requires working with entire teams and leaders together over time on their specific problems. The company will continue producing free content like blog posts and YouTube videos, and is reorganizing its website around ten topic-based agile guides.

The Seven Organizational Shifts That Determine Whether Your AI Investment Pays Off

Drawing on Mik Kersten's forthcoming book 'Output to Outcome', this piece outlines seven interdependent organizational shifts enterprises must make to realize ROI from AI investments. The shifts cover restructuring around value streams instead of functions, connecting work to strategic outcomes, unifying planning cadences, applying software modularity principles to org design, aligning objectives to shared ownership, segmenting value streams by domain (core, platform, incubation, transformation), and evolving leadership from oversight roles to hands-on 'outcome managers'. The core argument is that AI amplifies existing organizational dysfunction — adding AI to an unrestructured system produces more output without better outcomes — and that all seven shifts must be made as a system, not selectively.

We Tried Agile and It Didn’t Work

When teams say 'we tried agile and it didn't work,' leaders should treat it as diagnostic data rather than resistance. Common failure modes include adopting agile ceremonies without changing decision-making, weak product ownership, excessive work in progress, symbolic empowerment, and leaders delegating agile to teams without changing the surrounding system. The post outlines a five-pillar diagnostic framework (mindset, practices, roles, teamwork, outside-the-team support) and a practical recovery path: acknowledge the previous experience honestly, name a concrete outcome, pick one small visible improvement, maintain an improvement backlog, and inspect results. Skeptics should be engaged as sources of information rather than dismissed. If the word 'agile' carries too much baggage, leaders can pursue agile goals under different framing.

A Seasoned Tester's Crystal Ball: Appropriate speed for the conditions, deliberately

A veteran tester reflects on lessons learned during an agile transformation at F-Secure in the early 2000s, drawing parallels to today's AI-driven overwhelm. The key insight: when CI/CD eliminated natural waiting periods that had fostered team learning and cross-pollination, the team had to deliberately carve out time for improvement. The same principle applies now — developers and testers have agency to choose an appropriate pace when adopting AI, rather than feeling compelled to match the fastest adopters.

A Seasoned Tester's Crystal Ball: Faking plans is easier than fighting plans

Kinh nghiệm từ một tester dày dặn cho thấy việc lập kế hoạch kiểm thử chi tiết bị bỏ qua trong dự án giá cố định, dù phát hiện lỗi €25.000 sớm. AI hỗ trợ giao tiếp nhưng thay thế sự hợp tác thật sự, khi lập kế hoạch chỉ là hình thức. Bài học: AI khiến mọi người lười xây dựng mô hình tư duy riêng, hợp tác trực tiếp quan trọng hơn giao nộp tài liệu, và đôi khi nên chấp nhận kế hoạch hình thức để hoàn thành công việc thực tế.

Lập trình viên nên đọc bài này để hiểu cách quản lý dự án thực tế khi các quy trình kiểm thử bị bỏ qua, và cách cân nhắc giữa sự hợp tác trực tiếp với đội và việc tuân thủ các tài liệu giả tạo để tránh bị bỏ ngỏ trong môi trường công việc cạnh tranh.

Why Scrum Isn’t Working Even Though You’re Doing Scrum

Organizations often implement all the Scrum ceremonies and roles yet still fail to see the expected benefits. The core problems are: Scrum events becoming empty rituals rather than value-generating activities, sprint interruptions being treated as costless when they erode team trust and focus, organizational lack of prioritization pushing too many demands onto teams, leaders not creating the right environment for self-managing teams, Scrum Masters staying too close to the team instead of removing organizational impediments, and excessive rules making Scrum feel like bureaucracy. The recommended approach is to apply Scrum's own inspect-and-adapt principle to improve Scrum itself — identifying the biggest root cause and experimenting with one change at a time rather than attempting a big-bang reset.