"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ì? 1518 - 01 Nov 2023 Lệnh thay đổi kỹ thuật (Engineering Change Order - ECO) là gì? 1225
- 01 Nov 2021 Phân tích quy trình hiện tại (AS-IS) là gì? 699
- 11 May 2021 Khác nhau giữa Padding và Buffer trong quản lý rủi ro dự án 674
- 05 Jan 2024 Value-Added Distributors (VAD) là gì? 589
- 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ù” 572
- 01 Mar 2024 "Hồ đồ", "Trung dung", "Vô vi" và "tiêu dao" là gì? 535
- 09 Jan 2024 Domain Knowledge là gì? Ưu và nhược điểm? 493
- 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 481
- 04 Jul 2022 Steve Jobs đến với Đạo phật như thế nào? 471
- 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 464
- 01 Dec 2022 Business Critical là gì? 436
- 01 Jan 2024 Tổng hợp 25 quy luật quan trọng trong quản lý dự án 434
- 28 Dec 2023 "Watered-down version" và "Stripped-down version" là gì? 420
- 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 419
- 01 Nov 2022 Like for like là gì 403
- 01 Jan 2024 Phân tích tổ hợp (Cohort Analysis) là gì? 383
- 02 Jan 2024 Domain Engineering là gì? 367
- 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? 341
- 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? 335
- 08 Dec 2023 Resource Leveling là gì? 328
- 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? 308
- 08 Dec 2022 Phân biệt Cookbook, In a nutshell và Dummies 264
- 02 Nov 2023 "State-of-the-art product" là gì? 256
- 07 Dec 2022 Lean Software Development là gì? 248
- 11 Dec 2022 Sustaining Engineering là gì? 246
- 22 Nov 2023 Phân biệt tư duy hệ thống khác với tư duy thiết kế 218
- 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) 207
- 06 Dec 2023 Loại phần mềm "fire-and-forget" là gì? 202
- 05 Mar 2024 [Học tiếng Anh] "Go with caveats" là gì? 199
- 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 198
- 03 Sep 2020 Hiệu ứng rắn hổ mang, Luật Goodhart, Campbell & Chuyện thi cử 186
- 01 Sep 2023 Định luật Goodhart và định luật Campbell - Nghịch lý về thành tích 184
- 10 Sep 2024 Tại sao những thứ chúng ta muốn lại ít khi có được? 177
- 12 Jan 2024 Tư duy hệ thống trong Quản Lý Dự Án diễn ra như thế nào? 175
- 24 Mar 2023 Mô hình kinh doanh Open-Core là gì? 174
- 15 Mar 2024 Tê liệt vì suy nghĩ quá nhiều (Analysis Paralysis) là gì? 162
- 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 153
- 14 Dec 2022 Phương pháp kiểm tra Fagan Inspection là gì? 152
- 16 Feb 2024 Nghịch lý của sự hoàn hảo: AI có thể quá tốt để sử dụng? 138
- 09 Dec 2023 Phần mềm Best-of-class là gì? 134
- 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 131
- 01 Dec 2023 Microsoft Power Apps là gì? 130
- 01 Nov 2021 Knowldge Base là gì? 130
- 28 Feb 2025 “Học giỏi” hay “giỏi học”? 110
- 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ả 100
- 09 Dec 2024 10 nghịch lý quản trị khiến tổ chức mãi loay hoay 95
- 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 92
- 02 Mar 2024 "Quán chiếu nội tâm" là gì? 77
- 02 Aug 2022 BVP (Billable Viable Product) là gì? 64
- 19 Jul 2023 3 cấp độ của thất bại và bí quyết "cái khó ló cái khôn" 64
- 02 Aug 2022 BVP (Billable Viable Product) là gì? 64
- 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? 57
- 01 Nov 2022 MVF (Minimum Viable Features): Tối ưu tính năng trong giới hạn nguồn lực 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?" 49
- 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? 49
- 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? 48
- 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? 27
- 20 Apr 2025 “3-point messaging rule” là gì? 27
- 16 Apr 2025 Lãnh đạo linh hoạt: Hành động (Bias for Action) hay không hành động (Non-Action)? 25
- 16 Aug 2025 Hoài nghi khoa học với 20 thuật ngữ bi quan về hiệu quả của Scrum 22
- 30 Aug 2024 Friction points (điểm ma sát) là gì? 22
- 15 Aug 2025 Dự án phần mềm bị trì hoãn và vấn đề "akrasia" 22
- 13 Aug 2025 OODA và PDCA: Mô hình nào tốt hơn? 17
- 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. 6
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
Đọ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
