Scrum là một khung quản lý dự án nhấn mạnh vào làm việc nhóm, trách nhiệm và tiến triển theo từng giai đoạn hướng đến các mục tiêu rõ ràng. Nó bắt đầu từ một giả định đơn giản: bắt đầu bằng những gì bạn có thể thấy hoặc biết. Sau đó, theo dõi tiến độ và điều chỉnh khi cần thiết.
Ba trụ cột của Scrum
Scrum dựa trên chủ nghĩa thực chứng, khẳng định rằng tri thức đến từ kinh nghiệm và các quyết định nên dựa trên những gì đã biết. Ba trụ cột này kết nối Scrum lại với nhau.
Tại sao lại chọn Scrum?
Scrum cung cấp chức năng theo từng giai đoạn, trong khi Waterfall chỉ cung cấp ở từng giai đoạn. Phát triển Waterfall truyền thống là một quy trình tuần tự, dựa trên các giai đoạn, nơi giá trị không được cung cấp cho đến khi kết thúc dự án. Scrum thay đổi mô hình này bằng cách cung cấp các tính năng mới trong mỗi sprint—thường là mỗi 2–4 tuần—thay vì tập trung vào một bản phát hành lớn trong tương lai.
Scrum chia nhỏ công việc phức tạp thành các phần dễ quản lý, chia các tổ chức lớn thành các nhóm nhỏ, và biến các dự án có tác động lớn thành một chuỗi các giai đoạn ngắn, có thời gian giới hạnsprints.
Thông qua phát triển lặp lại và tăng dần, các công ty có thể cung cấp các sản phẩm và dịch vụ mà khách hàng thực sự cần nhanh hơn và hiệu quả hơn. Với Scrum, bạn có thể nhận và tích hợp phản hồi từ khách hàng vào cuối mỗi sprint, nghĩa là kết quả của bạn được định hình bởi cách sử dụng thực tế thay vì các giả định. Điều này giúp dễ dàng hơn để giữ cho khách hàng và các bên liên quan then chốt tham gia tích cực.
Agile so với Scrum
Agile là một phương pháp giúp thực hiện lặp lại liên tục trong phát triển và kiểm thử suốt vòng đời phát triển phần mềm (SDLC). Agile chia sản phẩm thành các thành phần nhỏ, dễ quản lý.Scrum chỉ là một trong nhiều quy trình phát triển phần mềm Agile lặp lại và tăng dần cho phép chúng tôi tập trung vào việc cung cấp giá trị kinh doanh trong thời gian ngắn nhất có thể.
Scrum thường xử lý các yêu cầu có thể thay đổi hoặc chưa rõ ràng ngay từ đầu dự án. Scrum được đặc trưng bởi:
- Nhẹ nhàng
- Dễ hiểu
- Khó nắm vững
Lợi ích của Scrum
Dưới đây là những lợi ích mà Scrum mang lại cho tổ chức, đội nhóm, sản phẩm và cá nhân:
- Chất lượng tốt hơn: Có một khung để đạt được tầm nhìn hoặc mục tiêu. Scrum cung cấp phản hồi liên tục và minh bạch để đảm bảo chất lượng ở mức cao nhất. Scrum giúp đảm bảo chất lượng thông qua các thực hành như:
- Giảm thời gian đưa sản phẩm ra thị trường: Scrum đã chứng minh khả năng cung cấp giá trị cho người dùng cuối nhanh hơn 30%–40% so với các phương pháp truyền thống.
- Lợi nhuận đầu tư cao hơn (ROI): Thời gian đưa sản phẩm ra thị trường ngắn hơn là lý do chính khiến các dự án Scrum đạt ROI cao hơn. Việc thu được doanh thu và lợi ích sớm dẫn đến lợi nhuận tổng thể cao hơn. Điều này dựa trên nguyên tắc cơ bản của tính toán Giá trị Hiện tại Ròng (NPV).
- Tinh thần đội nhóm cao hơn: Làm việc với những cá nhân hạnh phúc, tích cực là điều mang lại sự thỏa mãn và hiệu quả. Quản lý tự chủ đặt các quyết định thường do quản lý hoặc tổ chức đưa ra vào tay củaĐội Scrum thành viên.
- Hợp tác đội nhóm mạnh mẽ hơn: Khi các đội Scrum sở hữu dự án và sản phẩm, họ có thể đạt được kết quả xuất sắc. Các đội Scrum hợp tác và nâng cao chất lượng cũng như hiệu suất dự án thông qua sự tham gia và giao tiếp được cải thiện.
Khung công tác Scrum
Scrum đơn giản. Nó không phải là một tập hợp các mệnh lệnh cứng nhắc và liên kết chặt chẽ. Scrum không phải là một phương pháp. Scrum thể hiện phương pháp khoa học của chủ nghĩa thực chứng. Nó thay thế các phương pháp thủ tục thuật toán bằng các phương pháp heuristics, tôn trọng con người và tự tổ chức để giải quyết tính không thể dự đoán và giải quyết các vấn đề phức tạp. Sơ đồ dưới đây minh họa Scrum trong hành động, như được mô tả bởi Ken Schwaber và Jeff Sutherland trong cuốn sách “Scrum: Nghệ thuật làm gấp đôi công việc trong nửa thời gian”, minh họa hành trình từ lập kế hoạch đến giao hàng phần mềm.
Các thành phần của quy trình Scrum
Chính khung công tác Scrum là đơn giản. Nó chỉ định ra một vài nguyên tắc chung, với một số lượng nhỏ các quy tắc,vai trò, sản phẩm, vàsự kiện. Tuy nhiên, mỗi thành phần này đều quan trọng cho các mục đích cụ thể và thiết yếu để sử dụng thành công khung công tác.
Các thành phần chính của khung công tác Scrum là:
- Vai trò Scrum: Người điều phối Scrum, Chủ sản phẩm, và đội Scrum
- Sản phẩm: Danh sách công việc Sprint, Danh sách công việc sản phẩm, Biểu đồ giảm dần, nhật ký, v.v.
- Sự kiện Scrum: Lên kế hoạch Sprint, Xem xét Sprint, Scrum hàng ngày, Tổng kết Sprint, v.v.
- Sprints
Sơ đồ dưới đây hiển thị các yếu tố chính của khung Scrum. Quy trình đã được minh họa bằng cách sử dụng Bản đồ quy trình Scrum từ các công cụ phần mềm Agile của Visual Paradigm.
Vai trò Scrum
Khi một tổ chức áp dụng Scrum, điều đầu tiên cần hiểu là vai trò Scrum khác biệt như thế nào so với các vai trò quản lý dự án truyền thống. Mặc dù chỉ có ba vai trò chính trong Scrum, chúng không tự động tương ứng với các chức danh quen thuộc. Hãy bắt đầu bằng các định nghĩa ngắn gọn về từng vai trò:
Người sở hữu sản phẩm
Người sở hữu sản phẩm là vai trò Scrum chịu trách nhiệm đại diện cho cộng đồng doanh nghiệp hoặc người dùng. Họ làm việc sát sao với người dùng để xác định các tính năng trong danh sách công việc sản phẩm. Các trách nhiệm chính bao gồm:
- Xác định tầm nhìn và chiến lược sản phẩm, bao gồm các mục tiêu ngắn hạn và dài hạn;
- Cung cấp hoặc thu thập kiến thức về sản phẩm hoặc dịch vụ;
- Hiểu và truyền đạt nhu cầu của khách hàng đến đội phát triển;
- Thu thập, ưu tiên và quản lý các yêu cầu về sản phẩm hoặc dịch vụ;
- Chịu trách nhiệm về ngân sách sản phẩm hoặc dịch vụ, bao gồm lợi nhuận;
- Xác định ngày phát hành cho sản phẩm hoặc dịch vụ;
- Trả lời câu hỏi và đưa ra quyết định hàng ngày cùng đội phát triển;
- Chấp nhận hoặc từ chối công việc hoàn thành từ Sprint;
- Trình bày các sản phẩm chính của đội vào cuối mỗi Sprint;
- Quản lý danh sách công việc sản phẩm.
Master Scrum
Master Scrum là người điều phối đội phát triển Agile. Scrum cho phép các đội tự tổ chức và thích nghi nhanh chóng dựa trên các nguyên tắc Agile. Master Scrum quản lý luồng thông tin. Các trách nhiệm chính:
- Hoạt động như một huấn luyện viên để giúp đội tuân theo các giá trị và thực hành Scrum;
- Giúp loại bỏ các trở ngại và bảo vệ đội khỏi các yếu tố gây xao nhãng bên ngoài;
- Thúc đẩy sự hợp tác tốt đẹp giữa đội và các bên liên quan;
- Thúc đẩy sự hợp lý và minh bạch trong đội;
- Bảo vệ đội khỏi các sự gián đoạn tổ chức.
Đội Scrum
Đội Scrum (cũng được gọi là Đội Phát triển) bao gồm từ 3 đến 9 thành viên, phải cùng nhau sở hữu tất cả các kỹ năng kỹ thuật cần thiết để cung cấp sản phẩm hoặc dịch vụ. Họ được hướng dẫn trực tiếp bởi Người Chăm sóc Scrum nhưng không được quản lý theo cách truyền thống. Họ phải tự tổ chức, đa chức năng và chịu trách nhiệm hoàn thành tất cả các nhiệm vụ cần thiết.
Đội phát triển chịu trách nhiệm cung cấp một phần sản phẩm có thể triển khai được vào cuối mỗi Sprint—bao gồm phân tích, thiết kế, phát triển, kiểm thử và viết tài liệu kỹ thuật. Những đặc điểm quan trọng của một đội Scrum bao gồm:
- Tự tổ chức: Tất cả các thành viên trong đội tự quản lý công việc của mình để hoàn thành các nhiệm vụ được giao. Trong Scrum Agile, không có người lãnh đạo đội hay quản lý cấp trực tiếp. Mọi người phải cam kết đủ để thúc đẩy hoạt động của bản thân và đóng góp vào thành công của đội. Nếu một người thất bại, thì tất cả đều thất bại.
- Đa chức năng: Tất cả các thành viên trong đội phải có đầy đủ kiến thức và kỹ năng cần thiết để cung cấp một sản phẩm chất lượng cao, có thể triển khai. Các chuyên gia có thể được mời đến để hướng dẫn, nhưng chỉ nhằm truyền đạt kiến thức cho đội để lấp đầy khoảng trống kỹ năng.
- Người sở hữu Sản phẩm cần có tầm nhìn kinh doanh: Người sở hữu Sản phẩm đại diện cho tiếng nói của khách hàng và phải chuyển đổi nhu cầu của họ thành các nhiệm vụ cụ thể cho Người Chăm sóc Scrum và đội phát triển. Đây thường là một vai trò toàn thời gian.
- Người Chăm sóc Scrum không phải là quản lý cấp trực tiếp: Họ hỗ trợ huấn luyện đội phát triển và loại bỏ các rào cản cản trở tiến độ.
Sản phẩm Scrum
Các sản phẩm Scrum giúp xác định công việc đang vào đội và đang được thực hiện. Mặc dù có nhiều sản phẩm khác—như truyện người dùng, danh sách phát hành, biểu đồ tiêu hao—ở đây chúng tôi tập trung vào ba sản phẩm chính:
Danh sách Sản phẩm
Danh sách Sản phẩm là danh sách được ưu tiên các truyện người dùng đại diện cho các tính năng mà đội sản phẩm cần hoặc mong đợi. Thường thì Người sở hữu Sản phẩm sẽ duy trì danh sách này.
Sprint Backlog
Danh sách Sprint bao gồm một tập hợp các mục đã được chọn để hoàn thành trong Sprint hiện tại. Hai điểm quan trọng cần lưu ý về mối quan hệ giữa Danh sách Sprint và Danh sách Sản phẩm:
1. Đội quyết định những gì cần thêm vào Sprint. Do đó, đội sở hữu và chịu trách nhiệm hoàn thành các mục này.
2. Trước khi chuyển một mục từ Danh sách Sản phẩm sang Danh sách Sprint, đội phải đảm bảo họ có đầy đủ thông tin cần thiết. Đội thường xác định một danh sách kiểm tra các tiêu chí phải đạt được trước khi một mục có thể được thêm vào.
Danh sách Sản phẩm so với Danh sách Sprint
Danh sách Sprint Backlog là danh sách các nhiệm vụ mà đội Scrum cam kết hoàn thành trong Sprint. Trong buổi họp lập kế hoạch Sprint, đội thường chọn một vài Mục Danh sách Sản phẩm dưới dạng truyện người dùng và xác định các nhiệm vụ cần thiết để hoàn thành từng mục, như được hiển thị bên dưới:
Biểu đồ tiêu hao
Biểu đồ tiêu hao là một biểu đồ trực quan thể hiện công việc còn lại theo thời gian. Công việc còn lại (hay công việc trong danh sách) được hiển thị trên trục đứng, với thời gian nằm trên trục ngang. Đây là biểu đồ theo dõi công việc còn lại cần làm. Nó có thể được sử dụng để dự đoán thời điểm hoàn thành toàn bộ công việc. Biểu đồ này thường được sử dụng trong các phương pháp phát triển phần mềm Agile như Scrum nhưng cũng có thể áp dụng cho bất kỳ dự án nào có tiến độ đo lường được theo thời gian. Công việc còn lại có thể được đo bằng thời gian hoặc điểm truyện.
Sự kiện Scrum
Giao tiếp là chìa khóa! Scrum dựa vào tính minh bạch trên mọi khía cạnh (Nguyên tắc Scrum #1). Dựa trên nguyên tắc cốt lõi này, khung công tác được xây dựng xung quanh một loạt các sự kiện chính để đảm bảo hai nguyên tắc còn lại—Kiểm tra và Điều chỉnh—như được hiển thị trong bảng dưới đây:
| Sự kiện | Kiểm tra | Điều chỉnh |
|---|---|---|
| Lên kế hoạch Sprint |
|
|
| Cuộc họp hàng ngày |
|
|
| Đánh giá Sprint |
|
|
| Rút kinh nghiệm Sprint |
|
|
Ghi chú: Trong mỗi Sprint, có năm cuộc họp chính trong Scrum, như được hiển thị bên dưới:
Lên kế hoạch Sprint
Mỗi Sprint đều bắt đầu bằng việc lập kế hoạch. Đội ngũ phải xác định và cam kết về những gì họ sẽ hoàn thành trong Sprint. Các mục khả thi luôn được lấy từ Danh sách công việc Sprint, như được hiển thị bên dưới:
Đây chính là nơi Scrum Master thể hiện năng lực. Product Owner xác định những gì cần thiết từ góc độ kinh doanh/khách hàng, đội ngũ Scrum xác định những gì họ tin rằng có thể hoàn thành, và Scrum Master đảm bảo sự phù hợp tối ưu cho cả hai phía.
Buổi họp Daily Scrum
Sau khi đội ngũ cam kết về những gì họ sẽ hoàn thành trong Sprint, họ tổ chức buổi Daily Stand-up. Mục tiêu cốt lõi là đảm bảo mỗi thành viên đội ngũ (và có thể cả những người quan sát) hiểu rõ hoàn toàn tình trạng và tiến độ công việc:
- Tôi đã làm gì hôm qua?
- Tôi sẽ làm gì hôm nay?
- Điều gì đang cản trở tôi?
Cập nhật hàng ngày này cung cấp phản hồi tức thì cho đội ngũ. Các buổi họp ngắn gọn—không quá 3 phút mỗi người.
Ghi chú:Người quan sát có mặt để quan sát. Scrum Master cần giảm thiểu tối đa các yếu tố gây xao nhãng từ bên ngoài và bên trong.
Buổi họp xem xét Sprint
Buổi xem xét Sprint hoặc buổi demo được tổ chức vào cuối Sprint để kiểm tra tiến độ. Đội ngũ trình bày tiến độ dựa trên Định nghĩa Hoàn thành, tập trung vào mục tiêu Sprint. Product Owner xem xét và chấp nhận tiến độ đã hoàn thành.
Buổi tổng kết Sprint
Buổi tổng kết Sprint thường là hoạt động cuối cùng trong Sprint. Nhiều đội tổ chức ngay sau buổi xem xét Sprint. Toàn bộ đội ngũ—kể cả Scrum Master và Product Owner—nên tham gia. Một buổi tổng kết kéo dài một giờ thường là đủ. Buổi họp này giúp đội ngũ phản tư về:
- Chúng ta nên bắt đầu làm gì?
- Chúng ta nên ngừng làm gì?
- Chúng ta nên tiếp tục làm gì?
Mục tiêu là cải tiến liên tục hiệu suất của đội ngũ.
Tối ưu hóa danh sách công việc
Hãy coi Danh sách công việc sản phẩm như bản đồ hành trình của dự án. Khi đội ngũ hợp tác, họ tạo và cập nhật danh sách tất cả các mục cần thiết để hoàn thành dự án, đảm bảo mọi yêu cầu cần thiết đều được đáp ứng.
Sprint
Trong khung Scrum, tất cả các hoạt động cần thiết để triển khai một mục từ Danh sách công việc sản phẩm Scrum đều được thực hiện trong một Sprint (cũng được gọi là “vòng lặp”). Sprint luôn ngắn—thường từ 2 đến 4 tuần. Mỗi Sprint tuân theo một quy trình được xác định, như được hiển thị bên dưới:
Như đã nêu, các mục trong Danh sách công việc sản phẩm được ưu tiên và chọn vào Danh sách công việc Sprint. Một Sprint chỉ chứa một vài mục chính—bất kỳ sự đánh giá thấp công việc nào cho một mục riêng lẻ đều có thể ảnh hưởng đáng kể đến Sprint. Vì các mục lớn thường khó ước lượng và hiểu hơn, rủi ro thất bại của Sprint sẽ gia tăng. Các đội Scrum có kinh nghiệm dành thời gian và công sức để chia nhỏ các mục phức tạp hoặc lớn (ví dụ: tính năng người dùng hoặc Epics) thành các câu chuyện người dùng nhỏ hơn (hoặc thậm chí chia nhỏ hơn thành nhiệm vụ hoặc công việc con).
Epic
Epic ghi lại một khối lượng công việc lớn. Về cơ bản, đây là một “câu chuyện người dùng lớn” có thể được chia nhỏ thành nhiều câu chuyện nhỏ hơn. Việc hoàn thành một Epic có thể mất nhiều Sprint. Do đó, khi sử dụng Epic trong phát triển, chúng phải được chia nhỏ thành các câu chuyện người dùng nhỏ hơn.
Epic được giới thiệu sớm trong vòng đời dự án. Chúng là các điểm chức năng ở cấp độ cao, gần như tập trung vào mục tiêu tiếp thị.
Chúng tôi gọi các câu chuyện lớn là ‘Epic’ để thể hiện quy mô của chúng. Hãy nghĩ giống như một bộ phim. Nếu tôi nói một bộ phim là ‘hành động phiêu lưu’, bạn sẽ hình dung được điều gì đang chờ đợi—có thể là những cuộc truy đuổi xe hơi, bắn súng, v.v. Tương tự, đặt nhãn là ‘Epic’ cho một câu chuyện đôi khi có thể truyền tải thêm bối cảnh.
Câu chuyện người dùng
Câu chuyện người dùng là một tuyên bố ngắn gọn về yêu cầu sản phẩm hoặc trường hợp kinh doanh. Nó thường được viết bằng ngôn ngữ đơn giản để giúp người đọc hiểu được phần mềm cần làm gì. Product Owner tạo ra câu chuyện. Sau đó, các thành viên đội ngũ Scrum chia nhỏ câu chuyện thành một hoặc nhiều nhiệm vụ Scrum.
Các câu chuyện người dùng thường là những tính năng mà người dùng cuối có thể nhìn thấy. Chúng tuân theo định dạng: “Tôi muốn [làm điều gì đó] để [tôi có thể đạt được mục tiêu].” Chúng mang lại giá trị cho khách hàng/người dùng. Đây là yêu cầu sản phẩm từ phía khách hàng.
Ví dụ: “Là một khách hàng, tôi muốn tạo một tài khoản để tôi có thể xem các giao dịch của mình năm ngoái nhằm giúp tôi lập kế hoạch ngân sách cho năm tới.”
Nhiệm vụ
Ngược lại, một Nhiệm vụ mang tính kỹ thuật hơn. Các nhiệm vụ thường liên quan đến mã nguồn, thiết kế, tạo dữ liệu kiểm thử, tự động hóa, v.v. Chúng thường là trách nhiệm cá nhân. Các nhiệm vụ không được viết theo định dạng câu chuyện người dùng. Chúng mang tính kỹ thuật hơn.
Ví dụ: “Đánh giá góc giao diện người dùng bằng Material Design” hoặc “Gửi ứng dụng lên App Store.”
English
Arabic
Chinese (Simplified)
Dutch
French
German
Italian
Japanese
Korean
Portuguese
Russian
Spanish