"Yin Yang Agile" là gì?
Last updated: August 29, 2025 Xem trên toàn màn hình
Recommended for you
- 03 Nov 2022
BAU (Business-As-Usual) là gì? 1670 - 01 Nov 2023 Lệnh thay đổi kỹ thuật (Engineering Change Order - ECO) là gì? 1321
- 01 Nov 2021 Phân tích quy trình hiện tại (AS-IS) là gì? 798
- 11 May 2021 Khác nhau giữa Padding và Buffer trong quản lý rủi ro dự án 770
- 15 Apr 2023 Nghịch lý từ câu chuyện “một chén gạo dưỡng ơn, một đấu gạo gây thù” 654
- 05 Jan 2024 Value-Added Distributors (VAD) là gì? 638
- 01 Mar 2024 "Hồ đồ", "Trung dung", "Vô vi" và "tiêu dao" là gì? 608
- 18 Jul 2020 Lợi ích cận biên (Marginal Utility) là gì? Qui luật lợi ích cận biên giảm dần 577
- 09 Jan 2024 Domain Knowledge là gì? Ưu và nhược điểm? 575
- 12 Mar 2024 Khám Phá Triết Học: Hai Nguyên Lý Cơ Bản và Những Quy Luật Đằng Sau Sự Phát Triển 571
- 04 Jul 2022 Steve Jobs đến với Đạo phật như thế nào? 509
- 01 Dec 2022 Business Critical là gì? 496
- 28 Dec 2023 "Watered-down version" và "Stripped-down version" là gì? 470
- 01 Jan 2024 Tổng hợp 25 quy luật quan trọng trong quản lý dự án 469
- 09 Aug 2022 Hiệu ứng “rắn hổ mang” (Cobra effect): Khi giải pháp trở thành vấn đề, tưởng vui lại hóa xui 468
- 01 Jan 2024 Phân tích tổ hợp (Cohort Analysis) là gì? 441
- 01 Nov 2022 Like for like là gì 437
- 02 Jan 2024 Domain Engineering là gì? 407
- 22 May 2022 Tư duy ngoài hộp (Thinking out of box) là gì? Tại sao quan trọng với sự phát triển của doanh nghiệp? 399
- 21 Jan 2022 SSO (Single Sign On) là gì? Bạn đã hiểu đúng và đẩy đủ vè chìa khóa thông minh SSO? 364
- 08 Dec 2023 Resource Leveling là gì? 359
- 01 Aug 2021 Hiện tượng Gold plating (mạ vàng) là gì? Tại sao có ảnh hưởng quyết định đến chất lượng dự án? 328
- 22 Nov 2023 Phân biệt tư duy hệ thống khác với tư duy thiết kế 313
- 08 Dec 2022 Phân biệt Cookbook, In a nutshell và Dummies 312
- 11 Dec 2022 Sustaining Engineering là gì? 275
- 07 Dec 2022 Lean Software Development là gì? 266
- 02 Nov 2023 "State-of-the-art product" là gì? 264
- 01 Dec 2023 Microsoft Power Apps là gì? 259
- 06 Dec 2023 Loại phần mềm "fire-and-forget" là gì? 245
- 02 Oct 2023 Ngôi Chùa Trăm Năm và Viên Gạch Vỡ: Bài Học Thấm Thía Về Lỗi Nhỏ Trong Bức Tranh Lớn 222
- 05 Mar 2024 [Học tiếng Anh] "Go with caveats" là gì? 214
- 08 Aug 2023 Mất kiểm soát phạm vi dự án (Scope Creep) và hiệu ứng quả cầu tuyết (snowball) 211
- 15 Mar 2024 Tê liệt vì suy nghĩ quá nhiều (Analysis Paralysis) là gì? 199
- 12 Jan 2024 Tư duy hệ thống trong Quản Lý Dự Án diễn ra như thế nào? 196
- 10 Sep 2024 Tại sao những thứ chúng ta muốn lại ít khi có được? 190
- 03 Sep 2020 Hiệu ứng rắn hổ mang, Luật Goodhart, Campbell & Chuyện thi cử 190
- 01 Sep 2023 Định luật Goodhart và định luật Campbell - Nghịch lý về thành tích 190
- 24 Mar 2023 Mô hình kinh doanh Open-Core là gì? 181
- 24 Apr 2025 Chính sách sở hữu đất đai của Trung Quốc: Động lực thúc đẩy người dân làm việc chăm chỉ và hiệu quả 174
- 09 Jan 2025 10 Nghịch Lý Cuộc Sống Từ Phim Upstream (nghịch hành nhân sinh): Đối Mặt Rủi Ro Trong Thời Đại VUCA 165
- 16 Feb 2024 Nghịch lý của sự hoàn hảo: AI có thể quá tốt để sử dụng? 160
- 09 Dec 2023 Phần mềm Best-of-class là gì? 140
- 01 Nov 2021 Knowldge Base là gì? 139
- 11 Sep 2020 Nghịch lý kinh doanh tại Mỹ: Chăm sóc khách hàng không tốt, nhưng công ty lại lãi lớn 136
- 02 Mar 2024 "Quán chiếu nội tâm" là gì? 119
- 28 Feb 2025 “Học giỏi” hay “giỏi học”? 113
- 09 Dec 2024 10 nghịch lý quản trị khiến tổ chức mãi loay hoay 108
- 10 Aug 2020 Bạn có biết quy tắc thất bại nhanh: Fail early, fail often, fail cheap, but always fail forward 101
- 11 May 2025 Từ điển kỹ thuật trong quản lý tài nguyên truy cập hệ thống (System Access Resource Management) 82
- 01 May 2025 Vì Sao Các Cửa Hàng Trung Quốc Không Vội Vã Phục Vụ Khách Hàng? 78
- 19 Jul 2023 3 cấp độ của thất bại và bí quyết "cái khó ló cái khôn" 73
- 02 Aug 2022 BVP (Billable Viable Product) là gì? 71
- 02 Aug 2022 BVP (Billable Viable Product) là gì? 71
- 01 Nov 2022 MVF (Minimum Viable Features): Tối ưu tính năng trong giới hạn nguồn lực 53
- 11 Mar 2025 Thiên hướng Hành động (Bias for Action) và Thiên hướng Quy trình (Bias for Process) tác động tiêu cực tới "đổi mới và sáng tạo" như thế nào? 53
- 02 May 2025 Vì sao học giỏi mà vẫn nghèo, học dốt lại thành đạt trong cuộc sống? 52
- 17 Feb 2025 "Minh triết" là gì? Có Phải Minh Triết Giúp Bạn Thành Công Hơn Trí Thông Minh?" 50
- 30 Aug 2024 Friction points (điểm ma sát) là gì? 37
- 06 Dec 2025 Sức mạnh của phương pháp 30-for-30: Bạn đã bao giờ cam kết 30 ngày liên tục cho một mục tiêu? 33
- 16 Apr 2025 Lãnh đạo linh hoạt: Hành động (Bias for Action) hay không hành động (Non-Action)? 30
- 20 Apr 2025 “3-point messaging rule” là gì? 28
- 15 Aug 2025 Dự án phần mềm bị trì hoãn và vấn đề "akrasia" 27
- 13 Aug 2025 OODA và PDCA: Mô hình nào tốt hơn? 24
- 16 Aug 2025 Hoài nghi khoa học với 20 thuật ngữ bi quan về hiệu quả của Scrum 23
- 13 Sep 2025 Vanity Metrics: Follower tăng vọt nhưng doanh thu đứng yên 23
- 05 Sep 2025 “Lời Khuyên”: Thuận lý thì ít, nghịch lý thì nhiều. Suy nghĩ không giống nhau thì không nên khuyên nhau. 21
- 19 Sep 2025 Luật chống ôm đồm (WIP limits): Làm ít hơn và chất hơn 16
- 11 Sep 2025 📚 Từ điển thuật ngữ về DevOps 15
- 17 Aug 2025 Giải mã 50+ thuật ngữ Khắc Kỷ: Điều gì khiến Khắc Kỷ tồn tại hơn 2.000 năm mà vẫn được giới trẻ tìm đến? 5
Bốn nguyên tắc chỉ đạo của quản lý dự án Agile có thể được so sánh với khái niệm âm-dương (yin-yang) trong triết lý Trung Hoa. Chúng là: “đối lập… có nguồn gốc lẫn nhau… biến đổi lẫn nhau… và cùng nhau tăng giảm.” Khi hiểu rõ cách các nguyên tắc này hoạt động hài hòa, các nhà quản lý dự án có thể chuyển từ khái niệm sang hành động cụ thể.
Triết lý âm-dương của Trung Quốc dựa trên bốn định luật:
- Âm-dương là đối lập — chúng mô tả các hiệu ứng cực của hiện tượng; ví dụ, mùa đông và mùa hè là âm và dương của một năm.
- Âm-dương có nguồn gốc lẫn nhau — chúng là những phẩm chất bổ sung tạo nên toàn bộ hiện tượng, giống như ngày và đêm cùng tạo nên một ngày.
- Âm-dương biến đổi lẫn nhau — sự thay đổi ở một phẩm chất sẽ gây thay đổi ở phẩm chất kia; ví dụ, tuyết tan vào mùa xuân làm mực nước sông dâng lên.
- Âm-dương cùng nhau tăng giảm — có một trạng thái cân bằng động giữa Âm và Dương; như ngày ngắn lại vào mùa đông thì đêm sẽ dài ra.
Các nhà quản lý dự án được giao nhiệm vụ chuyển đội ngũ sang thực hành Agile có thể cảm nhận được tính đối lập giữa Agile và các phương pháp quản lý dự án hiện tại, đặc biệt nếu Agile được áp đặt bởi một CIO mới hoặc xuất phát từ một phong trào nội bộ trong nhóm phần mềm.
Chuyển sang Agile đồng nghĩa với việc vai trò trong đội dự án sẽ thay đổi. Công việc quản lý dự án sẽ chuyển từ chỉ huy và kiểm soát sang hợp tác. Hiểu rõ các nguyên tắc chỉ đạo của Agile và cách áp dụng chúng là bước đầu tiên để chuyển đổi thành công sang Agile.
Giống như âm-dương, Agile có bốn nguyên tắc chỉ đạo: đối lập, có nguồn gốc lẫn nhau, biến đổi lẫn nhau và cùng nhau tăng giảm. Những nguyên tắc này được thể hiện trong Tuyên ngôn Agile (Agile Manifesto).
“Chúng tôi đang khám phá những cách phát triển phần mềm tốt hơn bằng cách thực hành và giúp người khác thực hành. Qua công việc này, chúng tôi nhận ra giá trị:
- Cá nhân và sự tương tác hơn quy trình và công cụ
- Phần mềm hoạt động hơn tài liệu đầy đủ
- Hợp tác với khách hàng hơn đàm phán hợp đồng
- Phản ứng với thay đổi hơn là tuân theo kế hoạch
Tức là, mặc dù có giá trị ở những mục bên phải, chúng tôi coi trọng những mục bên trái hơn.”
Một nhà quản lý dự án có thể chuyển cụm từ “đánh giá cao cá nhân và sự tương tác hơn quy trình và công cụ” thành các hành động cụ thể. Nếu có thể, loại bỏ các vách ngăn và giữ nhóm làm việc trong một khu vực chung. Lên lịch họp đứng hàng ngày (daily stand-up) để mỗi thành viên báo cáo: hôm qua đã làm gì, hôm nay làm gì, và những gì đang cản trở công việc. Tất nhiên, một trong những nhiệm vụ chính của bạn là loại bỏ các rào cản đó. Điều này có thể bao gồm việc triển khai công cụ và quy trình để khuyến khích năng suất.
Ví dụ, nếu các cải tiến sản phẩm được thêm vào nhưng ảnh hưởng đến công việc đã lên lịch cho một iteration, thì nhà quản lý dự án cần tạo một quy trình để chuyển các thay đổi và ghi lại công việc bị hoãn theo cách mà cả nhóm và khách hàng đều hiểu. Agile không chống lại quy trình. Là một nhà quản lý dự án Agile, bạn cần tự nhìn nhận lại. Xem xét tất cả quy trình do tổ chức phát triển và đặt câu hỏi về chúng. Các buổi đánh giá iteration là lúc các thay đổi trong quy trình được xem xét, giữ lại những gì hiệu quả và loại bỏ những gì không hiệu quả.
Mục tiêu của mọi dự án phần mềm là phần mềm hoạt động. Các phương pháp truyền thống như waterfall hay spiral dựa trên giả định rằng yêu cầu sản phẩm có thể được định nghĩa chính xác trước khi triển khai. Agile khác ở chỗ mọi hoạt động dự án phần mềm từ yêu cầu đến cài đặt mã sẵn sàng sản xuất đều được thực hiện trong các khoảng thời gian ngắn gọi là iteration.
Một iteration có thể kéo dài từ 1 đến 4 tuần. Điều này nghĩa là chỉ có những yêu cầu mà nhóm phát triển đang làm việc trong iteration mới được định nghĩa đầy đủ. Không có hình phạt nếu chờ đến khi yêu cầu sẵn sàng mới phát triển. Điều này giúp giảm bớt tài liệu như sơ đồ kiến trúc, use case, và đặc tả chức năng. Nhóm Agile chỉ tạo và duy trì tài liệu khi cần. Nếu tài liệu không còn hữu ích, nhóm sẽ loại bỏ. Nhà quản lý dự án Agile tập trung nhóm vào kết quả cuối cùng, là phần mềm hoạt động. Họ đặt câu hỏi về giá trị của tài liệu và giải thích khi nào cần thiết. Việc tạo tài liệu không xấu, miễn là hỗ trợ phần mềm hoạt động.
Tất cả dự án phần mềm đều có hợp đồng, dù ngầm hay rõ ràng. Hợp đồng ngầm thường dùng cho các nhóm nội bộ, còn hợp đồng rõ ràng dùng khi thuê nhóm ngoài cho dự án tạm thời. Điểm chung của cả hai là ngày hoàn thành.
Như các nhà quản lý dự án đều biết, tam giác ràng buộc gồm ba yếu tố: phạm vi, thời gian và chất lượng. Khi thời gian cố định và chất lượng ưu tiên, chỉ có phạm vi là có thể thỏa hiệp. Thương lượng với khách hàng hoặc product owner về phạm vi là một thành phần quan trọng của Agile. Chỉ có product owner biết tầm quan trọng của tính năng, quyết định thứ tự ưu tiên và quyết định liệu sửa đổi tính năng hiện có quan trọng hơn phát triển tính năng mới. Cho phép product owner xem tiến độ công việc giúp nhóm Agile giao giá trị sớm hơn so với các phương pháp phần mềm truyền thống.
Như ai từng xây nhà đều biết, có bộ bản vẽ chi tiết chỉ là bắt đầu. Trên hành trình còn nhiều thay đổi và thỏa hiệp trước khi bàn giao cuối cùng. Điều này cũng đúng với phần mềm. Giống như chủ nhà không chỉ đưa bản vẽ cho thợ mà không nhìn công trình, product owner nên xem tiến độ khi code bắt đầu hoạt động. Trong các buổi showcase Agile, nhà quản lý dự án là cầu nối giữa nhóm phát triển và product owner. Vì dự án Agile có giới hạn thời gian, nhóm chỉ cần chi tiết cho công việc cam kết trong iteration. Điều này cho phép yêu cầu mơ hồ được để lại cho đến khi product owner xác định tầm quan trọng và giúp nhóm hoàn thiện chi tiết. Nếu product owner quyết định cần thay đổi cái đã phát triển và quan trọng hơn tính năng mới, nhóm dự án thực hiện thay đổi. Nhóm Agile, giống như thợ xây, ứng phó với thay đổi.
Giống như Âm không thể tồn tại nếu không có Dương, các nguyên tắc Agile có tính bao gồm lẫn nhau. Nguyên tắc Agile là đối lập — cần có kế hoạch nhưng kế hoạch sẽ thay đổi. Nguyên tắc Agile có nguồn gốc lẫn nhau — hợp đồng, dù ngầm hay rõ ràng, sẽ cần thương lượng, vì vậy hãy mời khách hàng hợp tác cùng nhóm. Nguyên tắc Agile biến đổi lẫn nhau — cần một số tài liệu để nhóm có bản vẽ xây dựng, nhưng chỉ vừa đủ và hợp lý để duy trì. Cuối cùng, nguyên tắc Agile cùng nhau tăng giảm — tất cả nhóm phần mềm cần quy trình và công cụ để biết giới hạn, nhưng chính cá nhân tương tác hằng ngày mới tạo ra phần mềm tốt nhất.
Jann Thomas
Chuyên gia quản lý dự án
Khám phá thêm các chủ đề sau
19082021092841_thumb.png "Tại sao các dự án phần mềm sản xuất trong nước chậm nghiệm thu, ngay cả khi đã hoàn thành đúng tiến độ, thậm chí là vượt xa mong đợi? Bài viết sau đây sẽ cho chúng ta câu trả lời.")
Đọc thêm: Hướng dẫn hợp tác viết bài (guest blogging)
Các chủ đề được quan tâm nhiều nhất
CHIA SẺ BÀI VIẾT
Mới cập nhật