Giới thiệu: Mâu thuẫn Linh hoạt
Trong bối cảnh phần mềm hiện đại, ‘Linh hoạt’ đã trở thành một từ khóa phổ biến, đồng nghĩa với tốc độ, tính linh hoạt và đổi mới. Tuy nhiên, đối với nhiều tổ chức, thực tế lại hoàn toàn khác biệt. Các đội nhóm cảm thấy mình bị mắc kẹt trong một vòng lặp các nghi thức cứng nhắc, các mốc thời gian bị bỏ lỡ và kiệt sức—một hiện tượng thường được gọi là ‘Mâu thuẫn Linh hoạt’. Tại sao một khung công tác được thiết kế để tăng cường khả năng thích nghi lại thường dẫn đến sự mong manh?
Vấn đề cốt lõi nằm ở sự phân biệt giữa thực hiện Scrum và trở thành Linh hoạt. Nhiều đội nhóm tuân thủ cẩn thận các thao tác—tổ chức các cuộc họp hàng ngày, lập kế hoạch sprint và họp rút kinh nghiệm—nhưng lại bỏ qua tư duy cốt lõi. Họ coi Scrum như một bộ quy tắc cần tuân theo thay vì một khung công tác cần được hiểu rõ. Hướng dẫn này nhằm mục đích lấp đầy khoảng cách đó. Chúng ta sẽ khám phá không chỉ lý thuyết và các thao tác của Scrum, mà còn cả yếu tố con người then chốt quyết định thành công hay thất bại của nó. Bằng cách vượt qua tư duy chỉ kiểm tra từng mục trên danh sách, bạn có thể biến cách làm việc của đội nhóm mình từ một thói quen mong manh thành một động cơ thực sự linh hoạt để tạo giá trị.
Hình 1: Các đội Linh hoạt hiệu quả ưu tiên hợp tác và giao tiếp cởi mở hơn là tuân thủ nghiêm ngặt quy trình.
Phần I: Những trụ cột cốt lõi (‘Cái gì’ và ‘Tại sao’)
Khung Scrum trong tầm nhìn tổng quan
Scrum được xây dựng trên ba trụ cột nền tảng: Minh bạch, Kiểm tra, và Thích nghi. Không có minh bạch, kiểm tra sẽ gây hiểu lầm. Không có kiểm tra, thích nghi sẽ trở thành phỏng đoán. Những trụ cột này được hỗ trợ bởi năm giá trị cốt lõi: Cam kết, Dũng cảm, Tập trung, Cởi mở, và Tôn trọng. Những giá trị này không chỉ là điều mong muốn; chúng là nền tảng văn hóa giúp khung công tác vận hành hiệu quả.
Hãy xem chu kỳ Sprint như một nhịp tim. Nó cung cấp một nhịp điệu đều đặn cho đội nhóm để tạo ra, kiểm tra và thích nghi. Một sơ đồ luồng trực quan của chu kỳ này cho thấy một vòng lặp liên tục gồm lập kế hoạch, thực hiện, đánh giá và phản tư, đảm bảo sản phẩm phát triển dựa trên phản hồi từ thế giới thực thay vì những giả định cố định.
Hình 2: Chu kỳ Scrum nhấn mạnh vào phản hồi liên tục và cải tiến theo từng bước.
Đội Scrum – Ai Làm Gì?
Đội Scrum là một tập hợp các chuyên gia gắn kết, tập trung vào một mục tiêu tại một thời điểm: Mục tiêu Sản phẩm. Đội gồm ba trách nhiệm cụ thể:
Người sở hữu Sản phẩm (PO): Tiếng nói của Khách hàng
Người sở hữu Sản phẩm chịu trách nhiệm tối đa hóa giá trị của sản phẩm. Điều này đòi hỏi phải đưa ra những quyết định khó khăn về việc gì không cần xây dựng. Ví dụ, một PO hiệu quả có thể từ chối yêu cầu tính năng từ một bên liên quan bằng cách giải thích cách nó lệch khỏi mục tiêu chiến lược hiện tại, đồng thời đề xuất đưa nó vào danh sách chờ để xem xét trong tương lai. Điều này bảo vệ sự tập trung của đội và đảm bảo sự phù hợp với mục tiêu kinh doanh.
Trợ lý Scrum (SM): Nhà lãnh đạo phục vụ và người bảo vệ quy trình
SM không phải là người quản lý mà là một huấn luyện viên giúp đội hiểu và áp dụng lý thuyết và thực hành Scrum. Vai trò của họ là loại bỏ các trở ngại. Hãy tưởng tượng một tình huống mà một phụ thuộc bên ngoài làm cản trở tiến độ. Một SM chủ động có thể liên hệ ngay với bộ phận khác, đàm phán để giải quyết trong vòng 24 giờ nhằm duy trì tiến độ sprint.
Các Nhà phát triển: Động cơ tự tổ chức
Các nhà phát triển là những người sáng tạo ra Increment. Họ tự quản lý, nghĩa là họ quyết định nội bộ ai làm gì, khi nào và như thế nào. Ví dụ, nếu một đội nhận ra giữa sprint rằng họ còn năng lực, họ có thể cùng nhau quyết định đưa thêm một yêu cầu người dùng từ danh sách chờ vào, thể hiện tinh thần sở hữu và khả năng thích ứng.
Hình 3: Vai trò rõ ràng và sự tôn trọng lẫn nhau là điều kiện thiết yếu cho một đội Scrum hiệu suất cao.
Phần II: Các sản phẩm Scrum (Những thứ bạn quản lý)
Danh sách Sản phẩm – Bản thiết kế sống động
Danh sách Sản phẩm là một danh sách có thứ tự, phát sinh theo thời gian, liệt kê những gì cần thiết để cải thiện sản phẩm. Nó chưa bao giờ “hoàn chỉnh”. Một danh sách chờ lành mạnh là DEEP: Dchi tiết phù hợp, Ephát sinh, Eđược ước lượng, và Pưu tiên.
Quản lý một cốt truyện lớn, đơn nhất có thể gây áp lực. Chìa khóa nằm ở việc phân tách. Ví dụ, một cốt truyện như “Cải thiện quá trình giới thiệu người dùng” có thể được chia thành các yêu cầu người dùng thực hiện được như: “Là một người dùng mới, tôi muốn bỏ qua bài hướng dẫn để có thể khám phá ứng dụng ngay lập tức,” hoặc “Là một người dùng mới, tôi muốn thấy các gợi ý dần dần để học các tính năng một cách bối cảnh.” Điều này giúp công việc trở nên dễ quản lý và có thể ước lượng được.
Danh sách Sprint – Lời hứa Sprint
Danh sách Sprint là tập hợp các mục từ danh sách Sản phẩm được chọn cho Sprint, cộng với một kế hoạch để giao chúng. Nó đại diện cho một dự báo từ phía các Nhà phát triển, chứ không phải một hợp đồng ràng buộc. Tuy nhiên, nó được dẫn dắt bởi một cam kết: Mục tiêu Sprint.
Việc điều chỉnh giữa sprint là điều bình thường. Nếu một đội phát hiện nợ kỹ thuật đáng kể khi đang làm một yêu cầu, họ có thể điều chỉnh danh sách Sprint của mình. Họ có thể thay thế một mục ưu tiên thấp hơn để giải quyết nợ kỹ thuật, đảm bảo mục tiêu Sprint vẫn đạt được mà không làm ảnh hưởng đến chất lượng. Sự linh hoạt này là một điểm mạnh, chứ không phải điểm yếu.
Increment – Định nghĩa về “Hoàn thành”
Increment là bước đệm cụ thể hướng tới Mục tiêu Sản phẩm. Mỗi Increment phải bổ sung vào tất cả các Increment trước đó và được kiểm thử kỹ lưỡng. Từ “Hoàn thành” là nguy hiểm nếu không được định nghĩa rõ ràng.
Có sự khác biệt lớn giữa “Dev Done” (mã được viết và kiểm thử cục bộ) và “Production Ready Done” (mã hóa, kiểm thử, tài liệu hóa và triển khai lên môi trường thử nghiệm). Một Định nghĩa rõ ràng về Hoàn thành (DoD) ngăn ngừa tích tụ công việc ẩn và đảm bảo mỗi bước tiến đều mang lại giá trị thực sự.
Hình 4: Một Định nghĩa rõ ràng về Hoàn thành đảm bảo chất lượng và giảm nợ kỹ thuật.
Phần III: Các Sự kiện Scrum (Nhịp điệu)
Lập kế hoạch Sprint – Chuẩn bị cho thành công
Lập kế hoạch Sprint khởi động Sprint bằng cách xác định công việc cần thực hiện. Nó trả lời hai câu hỏi:Cái gìcó thể được giao trong Sprint này? (do PO dẫn dắt) vàLàm thế nàocông việc đã chọn sẽ được hoàn thành như thế nào? (do các Nhà phát triển dẫn dắt).
Lập kế hoạch hiệu quả bao gồm lập kế hoạch năng lực. Thay vì chỉ xem xét điểm truyện, các đội nên cân nhắc số giờ có sẵn, tính đến ngày lễ, cuộc họp và các nhiệm vụ hỗ trợ. Ví dụ, một đội có thể nhận ra rằng do một sự kiện toàn công ty, năng lực của họ giảm 20%, và họ điều chỉnh dự báo tương ứng, đặt ra kỳ vọng thực tế.
Buổi họp hàng ngày – Sự đồng bộ 15 phút
Buổi Daily Scrum là một sự kiện 15 phút dành cho các Nhà phát triển để đồng bộ hóa hoạt động và xây dựng kế hoạch cho 24 giờ tiếp theo. Nó không phải là báo cáo tình trạng cho Scrum Master.
Vượt qua câu hỏi máy móc “Bạn đã làm gì hôm qua?”, các đội nên tập trung vào tiến độ hướng tới Mục tiêu Sprint. Sử dụng hiệu quả ba câu hỏi giúp phát hiện sớm các điểm nghẽn. Ví dụ, một nhà phát triển có thể nói: “Tôi bị mắc kẹt ở tích hợp API vì tài liệu đã lỗi thời. Hôm nay tôi cần sự hỗ trợ từ đội backend.” Việc báo động ngay lập tức này giúp giải quyết nhanh chóng.
Hình 5: Buổi họp hàng ngày là điểm đồng bộ, chứ không phải báo cáo tình trạng.
Đánh giá Sprint – Bản trình diễn (Mà Không Phải Là Trình diễn)
Buổi Đánh giá Sprint được tổ chức để kiểm tra kết quả của Sprint và xác định các điều chỉnh trong tương lai. Mục tiêu là hợp tác và nhận phản hồi, chứ không chỉ đơn thuần là giới thiệu mã nguồn.
Đây là nơi các bên liên quan có thể thay đổi định hướng sản phẩm. Ví dụ, trong một buổi đánh giá, một bên liên quan có thể nhìn thấy một tính năng mới và nhận ra rằng nó giải quyết một vấn đề khác so với suy nghĩ ban đầu. Họ có thể đề xuất chuyển hướng tập trung của Sprint tiếp theo để tận dụng lợi ích bất ngờ này, minh chứng cho tính linh hoạt của quy trình.
Buổi Tổng kết Sprint – Động cơ cải tiến
Buổi Tổng kết Sprint có lẽ là sự kiện quan trọng nhất cho cải tiến dài hạn. Nó tập trung vào con người, mối quan hệ, quy trình và công cụ. An toàn tâm lý là điều tối quan trọng; các thành viên đội phải cảm thấy an toàn khi thừa nhận sai sót và đề xuất thay đổi.
Sử dụng các bài tập như “Bắt đầu/Dừng lại/Tiếp tục” có thể mang lại những hiểu biết có thể hành động. Ví dụ, một đội có thể nhận ra rằng quy trình kiểm thử của họ đang bị hỏng. Họ đồng ý:Bắt đầuviết kiểm thử tự động cho các đường đi quan trọng, Dừng lạibỏ qua việc kiểm tra mã nguồn, vàTiếp tụccác buổi lập trình cặp đôi của họ. Điều này dẫn đến những cải tiến quy trình cụ thể.
Hình 6: Các buổi tổng kết thúc đẩy cải tiến liên tục thông qua đối thoại cởi mở.
Phần IV: Ứng dụng thực tế (Cách thức)
Ước lượng và Tốc độ
Các đội sử dụng Điểm Truyện để ước lượng tương đối vì con người giỏi hơn trong việc so sánh độ phức tạp thay vì dự đoán thời gian tuyệt đối. Poker Lập kế hoạch là một kỹ thuật phổ biến, nơi các thành viên đội thảo luận và bỏ phiếu về độ phức tạp của một truyện cho đến khi đạt được sự đồng thuận.
Tuy nhiên, tốc độ thường bị lạm dụng. Đó là một công cụ lập kế hoạch giúp đội dự đoán khối lượng công việc họ có thể xử lý trong các vòng lặp tương lai, chứ không phải là một chỉ số hiệu suất để so sánh các đội hay đánh giá cá nhân. Sử dụng tốc độ như một KPI sẽ dẫn đến việc thổi phồng điểm số và làm suy yếu niềm tin.
Danh sách công việc “chín muồi” (tinh chỉnh)
Tinh chỉnh danh sách công việc là hành động chia nhỏ và làm rõ hơn các mục trong danh sách sản phẩm. Bạn nên dành bao nhiêu thời gian cho việc này? Thường thì từ 5-10% năng lực của đội.
Sử dụng mô hình INVEST giúp tạo ra các câu chuyện chất lượng cao: IĐộc lập, NCó thể thương lượng, VCó giá trị, ECó thể ước lượng, SNhỏ gọn, và TCó thể kiểm thử. Ví dụ, một câu chuyện phụ thuộc vào API của một đội khác thì không độc lập. Việc chia nhỏ nó hoặc tạo một spike để điều tra API trước có thể giúp nó dễ quản lý hơn.
Xử lý nợ kỹ thuật
Nợ kỹ thuật là điều không thể tránh khỏi, nhưng bỏ qua nó là tai họa. Các đội trưởng thành dành một phần của mỗi vòng lặp để giải quyết các yêu cầu phi chức năng và nợ kỹ thuật. Ví dụ, một đội có thể đồng ý dành 20% mỗi vòng lặp để tái cấu trúc, cập nhật thư viện hoặc cải thiện độ bao phủ kiểm thử. Cách tiếp cận chủ động này ngăn chặn các tình huống viết lại toàn bộ hệ thống “big bang” vốn làm đau đầu nhiều dự án.
Hình 7: Thường xuyên xử lý nợ kỹ thuật đảm bảo sức khỏe sản phẩm lâu dài.
Phần V: Những sai lầm phổ biến và các mẫu hành vi phản tác dụng (điều cần tránh)
“ScrumBut…”
“ScrumBut” chỉ những đội tuyên bố làm Scrum nhưng bỏ qua các yếu tố then chốt. Ví dụ: “Chúng tôi làm Scrum, nhưng chúng tôi có các vòng lặp 4 tuần và không có buổi tổng kết.” Điều này thường được gọi là Scrum ma quỷ – những động tác có mặt, nhưng tinh thần đã mất. Để khắc phục, các đội cần quay về cơ bản: rút ngắn vòng lặp để nhận phản hồi nhanh hơn và khôi phục các buổi tổng kết để thúc đẩy cải tiến.
Chủ sản phẩm quá bảo thủ
Một mẫu hành vi phản tác dụng xảy ra khi PO chỉ đạo cách thứccông việc phải được thực hiện như thế nào, bỏ qua chuyên môn của các nhà phát triển. Ví dụ, một PO kiên quyết yêu cầu một lược đồ cơ sở dữ liệu cụ thể hoặc cấu trúc mã nguồn. Điều này làm suy yếu bản chất tự tổ chức của đội. PO nên xác định điều gì và tại sao, để lại cho làm thế nào đến các nhà phát triển.
Trợ lý Scrum như một nhà quản lý
Một sai lầm phổ biến khác là trợ lý Scrum hành xử như một người giám sát công việc. Nếu trợ lý Scrum phân công nhiệm vụ cho từng cá nhân, họ sẽ phá hủy khả năng tự quản lý. Trợ lý Scrum nên hỗ trợ quá trình ra quyết định của đội, đặt câu hỏi như ‘Ai cảm thấy tự tin đảm nhận việc này?’ thay vì nói ‘John, cậu làm việc này.’
Hình 8: Tránh các mẫu hình phản tác dụng đòi hỏi sự cảnh giác và cam kết với các giá trị Scrum.
Phần VI: Vượt ra ngoài khuôn khổ (Chủ đề nâng cao)
Mở rộng Scrum
Khi nhiều đội làm việc trên cùng một sản phẩm, việc phối hợp trở nên phức tạp. Các khung công tác như LeSS (Scrum quy mô lớn) hoặc Nexus cung cấp cấu trúc cho điều này. Ví dụ, phối hợp ba đội trên cùng một danh sách sản phẩm yêu cầu một người Chủ sản phẩm thống nhất và các chu kỳ Sprint được đồng bộ. Các cuộc họp Scrum of Scrums định kỳ có thể giúp đồng bộ hóa các phụ thuộc và chia sẻ kinh nghiệm giữa các đội.
Tích hợp UX/Thiết kế với Scrum
Việc tích hợp thiết kế vào Scrum có thể gây khó khăn. Một quy trình Agile “Hai đường ray” có thể giúp, trong đó khám phá (nghiên cứu và thiết kế) diễn ra hơi trước so với việc triển khai (phát triển). Ví dụ, các nhà thiết kế có thể làm việc trên các bản mô phỏng cho các tính năng của Sprint tiếp theo trong khi các nhà phát triển xây dựng các mục của Sprint hiện tại. Điều này đảm bảo rằng các nhà phát triển có các thiết kế được nghiên cứu kỹ lưỡng, đã được xác thực sẵn sàng để triển khai, giảm thiểu công việc phải làm lại.
Hình 9: Agile hai đường ray giúp thiết kế và phát triển luôn đồng bộ và hiệu quả.
Kết luận: Hành trình, chứ không phải điểm đến
Thành thạo Scrum không phải là đạt được trạng thái tuân thủ hoàn hảo; mà là chấp nhận một tư duy học hỏi và thích nghi liên tục. Tư duy Agile nhắc nhở chúng ta rằng quy trình phục vụ con người, chứ không phải ngược lại.
Khi bạn bắt đầu hoặc tiếp tục hành trình Scrum của mình, hãy nhớ rằng những thất bại là cơ hội để kiểm tra và thích nghi. Sử dụng danh sách kiểm tra cuối cùng bên dưới để chuẩn bị cho Sprint tiếp theo, nhưng hãy duy trì sự linh hoạt đủ để thay đổi khi tình hình đòi hỏi. Sự linh hoạt thực sự nằm ở khả năng phản ứng với thay đổi trong khi vẫn giữ vững mục tiêu cung cấp giá trị.
Danh sách kiểm tra cuối cùng cho Sprint tiếp theo của bạn:
-
Mục tiêu Sprint có rõ ràng và thuyết phục không?
-
Đội đã cam kết thực hiện một lượng công việc hợp lý chưa?
-
Các phụ thuộc đã được xác định và giảm thiểu chưa?
-
Mọi người đã hiểu rõ Định nghĩa Hoàn thành chưa?
-
Cuộc họp tổng kết đã được lên lịch và điều phối một cách an toàn chưa?
Bằng cách tập trung vào những nền tảng này và nuôi dưỡng văn hóa tin tưởng và minh bạch, đội của bạn có thể chuyển từ trạng thái mong manh sang thực sự linh hoạt.
Hình 10: Hành trình Agile là liên tục, đòi hỏi sự phản tư và thích nghi không ngừng.
Phụ lục
A: Từ điển thuật ngữ chính
-
Sản phẩm: Các sản phẩm hữu hình được tạo ra trong quá trình dự án.
-
Sự kiện: Cơ hội chính thức để kiểm tra và thích nghi.
-
Tăng trưởng: Tổng số các mục trong Product Backlog được hoàn thành trong một Sprint.
-
Tốc độ: Số lượng công việc mà một đội có thể xử lý trong một Sprint duy nhất.
B: Mẫu: Kiểm tra mục tiêu Sprint
-
Tình trạng hiện tại: [Đang đúng tiến độ / Có rủi ro / Sai tiến độ]
-
Rào cản: [Liệt kê bất kỳ trở ngại nào]
-
Cần điều chỉnh: [Mô tả bất kỳ thay đổi nào đối với kế hoạch]
C: Mẫu: Các hoạt động khởi động cho buổi tổng kết
-
“Điểm nổi bật nhất của Sprint vừa rồi của bạn là gì?”
-
“Nếu Sprint này là một bộ phim, tiêu đề sẽ là gì?”
-
“Một từ để mô tả cảm giác của bạn ngay lúc này.”
Tham khảo
- Agile và Scrum là gì?: Một hướng dẫn toàn diện giải thích các khái niệm cốt lõi của phương pháp Agile và khung làm việc Scrum, chi tiết vai trò của chúng trong phát triển phần mềm hiện đại.
- Làm thế nào để sử dụng bảng Scrum cho phát triển Agile: Một hướng dẫn thực hành về việc sử dụng bảng Scrum để trực quan hóa luồng công việc, quản lý nhiệm vụ và nâng cao sự hợp tác giữa các thành viên trong các Sprint Agile.
- Các công cụ Scrum Agile chuyên nghiệp hiện đã có sẵn trong phiên bản Chuẩn của Visual Paradigm: Một thông báo và tổng quan về việc tích hợp các công cụ quản lý Agile và Scrum cấp chuyên nghiệp vào phiên bản Chuẩn của Visual Paradigm.
- Các công cụ Agile miễn phí và thương mại tốt nhất: Một bài so sánh đánh giá các giải pháp phần mềm hàng đầu miễn phí và trả phí được thiết kế để hỗ trợ quản lý dự án Agile và hiệu suất đội nhóm.
- Quản lý tính năng Agile: Một khám phá về các kỹ thuật và công cụ để quản lý tính năng trong môi trường Agile, đảm bảo sự phù hợp với giá trị khách hàng và mục tiêu sản phẩm.
- 1000 tài nguyên và công cụ Agile hàng đầu: Một bộ sưu tập rộng lớn hoặc bảng xếp hạng các tài nguyên Agile, công cụ và thực hành tốt nhất dành cho các đội muốn mở rộng khả năng quản lý dự án của mình.
- Công cụ bản đồ câu chuyện người dùng Agile: Chi tiết về tính năng bản đồ câu chuyện người dùng của Visual Paradigm, giúp các đội trực quan hóa hành trình người dùng và ưu tiên các mục trong danh sách chờ một cách hiệu quả.
- Bản đồ câu chuyện người dùng: Trực quan hóa con đường hướng đến giá trị khách hàng: Một bài viết sâu sắc thảo luận về cách bản đồ câu chuyện người dùng đóng vai trò là công cụ chiến lược để đồng bộ hóa nỗ lực phát triển với nhu cầu khách hàng và mang lại giá trị tối đa.
- Quản lý dự án Scrum: Một bài đăng blog nêu bật những yếu tố cốt lõi trong việc quản lý dự án bằng Scrum, bao gồm vai trò, sự kiện và sản phẩm để đảm bảo giao hàng thành công.
- Danh sách sản phẩm so với Danh sách Sprint: Sự phân biệt rõ ràng giữa danh sách sản phẩm và danh sách Sprint, giải thích cách mỗi thứ hoạt động trong khung Scrum để tổ chức công việc.
- Hiểu về Thẻ Kể chuyện Người dùng Agile: Một Hướng dẫn: Một hướng dẫn về cách tạo và quản lý thẻ kể chuyện người dùng Agile, tập trung vào các thực hành tốt nhất để viết những câu chuyện hiệu quả thúc đẩy phát triển.
- Các công cụ Scrum tốt nhất cho các đội Agile: Danh sách được chọn lọc các công cụ Scrum được đề xuất giúp tự động hóa các buổi họp đứng, theo dõi tiến độ và cải thiện giao tiếp trong các đội Agile.
- Công cụ Bản đồ Kể chuyện Người dùng Agile: (Điền trùng lặp) Tính năng và lợi ích khi sử dụng công cụ chuyên dụng của Visual Paradigm để tạo và quản lý bản đồ kể chuyện người dùng trong các dự án Agile.
- Scrum là gì?: Một hướng dẫn giới thiệu (trong bối cảnh Trung Quốc/Anh) định nghĩa Scrum, các nguyên tắc cốt lõi của nó và cách nó hỗ trợ phát triển theo từng vòng lặp.
- Tổng quan về Phát triển Agile: Một cái nhìn tổng quan rộng về các thực hành phát triển Agile, nhấn mạnh lợi ích của quy trình lặp lại và các vòng phản hồi liên tục.
- Chinh phục TOGAF ADM: Một hướng dẫn toàn diện: Một hướng dẫn chi tiết về Phương pháp Phát triển Kiến trúc TOGAF (ADM), cung cấp cái nhìn sâu sắc về lập kế hoạch và thực hiện kiến trúc doanh nghiệp.
- Quản lý dự án Agile là gì?: Một giải thích về các nguyên tắc quản lý dự án Agile, so sánh chúng với phương pháp truyền thống kiểu thác nước và nhấn mạnh tính linh hoạt cũng như sự hợp tác với khách hàng.
- Theo dõi tính năng Agile: (Bối cảnh tiếng Trung truyền thống) Thông tin về việc theo dõi và quản lý các tính năng trong quy trình làm việc Agile để đảm bảo giao hàng đúng hạn và đảm bảo chất lượng.
- Từ các đội nhỏ đến việc mở rộng Agile: Các chiến lược và khung công tác để mở rộng các thực hành Agile từ các đội nhỏ, đơn lẻ đến các tổ chức lớn, giải quyết các thách thức về phối hợp và tính nhất quán.