Phân hệ PM Study
  • Tình huốngTình huống thực chiến
  • Kịch bảnRa quyết định tình huống
  • Biểu mẫuKho biểu mẫu tải về
  • Thẻ ghi nhớHọc thuật ngữ PMP
  • Công cụMáy tính EVM, PERT, dự phòng
  • Hỏi đápHỏi đáp & thảo luận
  • Thử tháchMỗi ngày một câu hỏi PMP
  • Lý thuyếtBài học PMBOK 8 & ECO 2026
  • Luyện thiThi thử & ôn tập PMP
  • Bài viếtThư viện bài viết PMP
PM Study
Trang chủLý thuyếtTình huốngLuyện thiBiểu mẫuHỏi đáp
6 chuyên mụcXem tất cả bài viết →
  • Quản lý các bên liên quanTình huống về kỳ vọng, giao tiếp và gắn kết stakeholder.
  • Lãnh đạo & đội nhómXây dựng, dẫn dắt và giải quyết xung đột trong đội dự án.
  • Kế hoạch & tiến độLập kế hoạch, ước lượng, nén tiến độ và kiểm soát baseline.
  • Rủi ro & thay đổiNhận diện, ứng phó rủi ro và kiểm soát thay đổi phạm vi.
  • Agile & HybridLựa chọn và vận hành cách tiếp cận Agile, Predictive, Hybrid.
  • Luyện thi PMPChiến lược ôn tập và mẹo xử lý câu hỏi tình huống PMP.
Công cụBài viết
Trang chủLý thuyếtTình huốngLuyện thiBiểu mẫuHỏi đápChuyên mụcCông cụBài viết
/
PM Study

Học quản lý dự án và ôn thi PMP bằng tiếng Việt: lý thuyết PMBOK® Guide 8, tình huống thực tế và đề luyện thi theo ECO 2026.

Chuyên mục

  • Quản lý các bên liên quan
  • Lãnh đạo & đội nhóm
  • Kế hoạch & tiến độ
  • Rủi ro & thay đổi
  • Agile & Hybrid
  • Luyện thi PMP

Tài nguyên

  • Project Management Institute (PMI)
  • PMP Exam Content Outline
  • The Scrum Guide
  • PMI Vietnam Chapter

PM Study

  • Tất cả bài viết
  • Bài viết nổi bật
© 2026 PM StudyPMP® và PMBOK® là nhãn hiệu đã đăng ký của Project Management Institute.109 người đã truy cậpPhiên bản 1.15.0
  1. /Tình huống
  2. /Quản lý Tiến độ
  3. /Salesforce (2006): chuyển đổi agile toàn bộ khối…
Số 425Quản lý Tiến độ

Salesforce (2006): chuyển đổi agile toàn bộ khối công nghệ khi chu kỳ phát hành ngày càng dài

Từ năm 2000 đến 2006, Salesforce tăng trưởng nhanh nhưng khoảng cách giữa các bản phát hành lớn ngày càng dài và số tính năng mỗi đội giao giảm dần. Năm 2006, sau thí điểm, khối Công nghệ & Sản phẩm chuyển hẳn sang mô hình agile dựa trên Scrum với các đội nhỏ đa chức năng và định nghĩa hoàn thành chung. Ngày nay công ty duy trì ba bản phát hành lớn mỗi năm. Bài học về khôi phục nhịp tiến độ bằng thay đổi cách làm việc.

HP
Nguyễn Thu Hà, PMP
24/09/2026
3 phút đọc 0 lượt xem
Bình luận0

Bối cảnh thực tế

Salesforce thành lập năm 1999 và tăng trưởng nhanh về khách hàng, doanh thu và sản phẩm. Theo tài liệu đào tạo chính thức của công ty:

  • Giai đoạn 2000–2006, thời gian giữa các bản phát hành lớn tăng dần trong khi số tính năng mỗi đội giao giảm; những việc từng dễ dàng trở nên khó khăn khi tổ chức lớn lên.
  • Đội ngũ khó mở rộng giao tiếp và cộng tác mà vẫn giữ được ngày phát hành; cách làm thác nước (waterfall), lên kế hoạch toàn bộ từ đầu, tỏ ra kém linh hoạt.
  • Năm 2006, lãnh đạo thí điểm agile ở một số đội dù có phản đối, rồi tổ chức lại khối Công nghệ & Sản phẩm thành mô hình agile: tư duy giao hàng mới, quy trình chuẩn hoá, nguyên tắc Lean và định nghĩa hoàn thành (definition of done) chung.
  • Scrum là quy trình chính; nhân sự được chia thành các đội nhỏ đa chức năng làm việc theo sprint.
  • Ngày nay Salesforce duy trì ba bản phát hành lớn mỗi năm. Các bài trình bày tại hội nghị Agile 2007 của những người dẫn dắt cũng mô tả đây là một đợt triển khai đồng loạt (big bang) trên toàn tổ chức.

Phân tích nguyên nhân theo chuẩn PMP

  • Chu kỳ dài làm rủi ro và độ trễ tích tụ

    Bản phát hành lớn và thưa nghĩa là mỗi lần phải tích hợp nhiều thay đổi, dễ trễ và khó dự báo. Tiến độ bị chi phối bởi khâu tích hợp cuối thay vì tốc độ làm việc của từng đội.

  • Tăng quy mô làm tăng chi phí phối hợp

    Số kênh giao tiếp tăng theo cấp số khi số người tăng. Đội nhỏ đa chức năng giảm phụ thuộc chéo và giúp ước tính đáng tin hơn.

  • Nhịp cố định biến tiến độ thành ràng buộc, phạm vi thành biến số

    Với lịch phát hành cố định (release train), câu hỏi không còn là "khi nào xong" mà là "kịp chuyến nào". Điều này tăng khả năng dự báo cho khách hàng.

  • Chuyển đổi đồng loạt có rủi ro riêng

Thay đổi mọi đội cùng lúc tạo ra giai đoạn hỗn loạn và đòi hỏi huấn luyện, hỗ trợ mạnh. Thí điểm trước giúp có bằng chứng và người dẫn dắt nội bộ.

Cách áp dụng cho PM

  1. 1

    Bước 1: Đo trước khi chuyển đổi

    Ghi lại chỉ số nền: khoảng cách giữa các bản phát hành, số tính năng giao, tỷ lệ trễ mốc, để chứng minh hiệu quả sau chuyển đổi.

  2. 2

    Bước 2: Thí điểm rồi mở rộng theo tiêu chí

    Quyết định mở rộng dựa trên kết quả thí điểm:

    • Mở rộng

      Đội thí điểm giao đều mỗi sprint, chất lượng không giảm, có người hướng dẫn nội bộ.

    • Điều chỉnh

      Giao đều nhưng phụ thuộc chéo nhiều: thiết kế lại ranh giới đội trước khi mở rộng.

    • Chưa mở rộng

      Không có định nghĩa hoàn thành chung, tích hợp vẫn dồn cuối: củng cố thực hành kỹ thuật trước.

  3. 3

    Bước 3: Chuẩn hoá định nghĩa hoàn thành

    Một định nghĩa hoàn thành chung cho mọi đội để "xong" có cùng ý nghĩa và tích hợp không dồn về cuối.

PM Takeaway (Bài học rút ra)

Khi tổ chức lớn lên mà nhịp giao hàng chậm lại, vấn đề thường ở cách làm việc chứ không ở nỗ lực của từng người. Nhịp phát hành cố định, đội nhỏ đa chức năng và định nghĩa hoàn thành chung giúp tiến độ dự báo được trở lại.

Nguồn tham khảo

  • Salesforce Trailhead — Understand Why Salesforce Adopted Agile
  • Greene & Fry — Salesforce.com Agile Transformation (Agile 2007)
#Quản lý tiến độ#Phát triển phần mềm#Chuyển đổi agile#scrum#Nhịp phát hành

Nguồn: Salesforce Trailhead — Understand Why Salesforce Adopted Agile ↗ (mở trong thẻ mới)

Trắc nghiệm tình huống PMP

Câu 1/1
Công ty phần mềm tăng gấp ba nhân sự trong ba năm, nhưng số bản phát hành lớn mỗi năm giảm và lần nào cũng trễ ở giai đoạn tích hợp. Lãnh đạo hỏi PM cách khôi phục nhịp giao hàng. Đề xuất nào phù hợp nhất?

Bạn chọn phương án nào?

Chuyển đổi agile cho 150 người: bạn chọn cách nào?

Tình huống này hữu ích với bạn?

Bình luận0

Bình luận (0)

Đăng nhập để tham gia thảo luận.

Tình huống tương tự

Số 511Quản lý Tiến độ

World Cup 2014 (Brazil): sáu sân vận động lỡ hạn chót 31/12/2013 của FIFA và tối hậu thư cho Curitiba bốn tháng trước khai mạc

FIFA yêu cầu 12 sân vận động của World Cup 2014 hoàn thành trước 31/12/2013. Đến tháng 12/2013, sáu sân xác nhận lỡ hạn; sân ở São Paulo — nơi đá trận khai mạc — vừa gặp tai nạn cần cẩu, sân Arena da Baixada ở Curitiba chậm nhất tới mức FIFA ra tối hậu thư đến 18/2/2014. Curitiba được giữ lại nhờ tăng thêm hàng trăm công nhân. Bài học về tiến độ khi hạn chót là cố định và không thể dời: dự trữ thời gian phải được lập từ đầu, không phải tìm ra ở cuối.

0 lượt thích 0 lượt đánh giá hữu ích 0 bình luận16/10/2026
Quản lý Tiến độ

Windows Longhorn thành Vista: "tái lập" năm 2004, khi phụ thuộc chéo giữa các đội làm mọi mốc trượt dần

Longhorn ban đầu được hình dung là bản phát hành nhỏ vào cuối 2003, rồi dần gánh thêm cả những tính năng vốn dành cho thế hệ sau. Tháng 8/2004 Microsoft quyết định làm lại từ nền Windows Server 2003 SP1, cắt hoặc hoãn WinFS và phần lớn Palladium; Vista chỉ đến tay người dùng tháng 1/2007. Phân tích dưới góc nhìn quản lý tiến độ: phụ thuộc giữa các đội, nợ kỹ thuật và quyết định "đặt lại đường cơ sở".

0 lượt thích 0 lượt đánh giá hữu ích 0 bình luận14/10/2026
Số 491Quản lý Tiến độ

Tổng điều tra dân số Scotland (2020–2022): lùi một năm so với phần còn lại của Anh quốc, gia hạn thu thập một tháng mà vẫn hụt mục tiêu phản hồi

Tháng 7/2020, Scotland quyết định lùi tổng điều tra dân số từ 3/2021 sang 3/2022 vì COVID-19, trong khi Anh, xứ Wales và Bắc Ireland vẫn làm đúng hạn. Việc lùi lịch làm chi phí tăng 21,6 triệu bảng (18%). Đến năm 2022, tỷ lệ phản hồi ban đầu chỉ 79%; gia hạn một tháng tốn thêm khoảng 6 triệu bảng và đưa tỷ lệ lên 89%, vẫn dưới mục tiêu 90%. Bài học về quyết định lịch biểu khi mốc thời gian gắn với một sự kiện quốc gia.

0 lượt thích 0 lượt đánh giá hữu ích 0 bình luận12/10/2026

Nội dung

Bối cảnh thực tếPhân tích nguyên nhân theo chuẩn PMPCách áp dụng cho PMPM Takeaway (Bài học rút ra)Nguồn tham khảoTrắc nghiệmBình chọn
Quảng cáoBộ đề thi thử PMP (mẫu)