Tổng quan về Scrum

Tổng quan về Scrum

Trong Scrum, người quản lý dự án được gọi là Scrum Master, và đội dự án được gọi là Đội Scrum. Có một Chủ sở hữu Sản phẩm (Product Owner) sẽ ưu tiên các tính năng và yêu cầu cần phát triển trên Danh sách công việc Sản phẩm (Product Backlog).

Phương pháp Scrum sử dụng các giai đoạn Sprint để cung cấp các bước tiến nhỏ trong công việc và thu thập phản hồi từ khách hàng.

Có ba trụ cột của Scrum:

SCRUMáp dụng một phương pháp thực nghiệm (đôi khi gọi là chủ nghĩa thực nghiệm) để thích nghi với nhu cầu khách hàng luôn thay đổi. Chủ nghĩa thực nghiệm là việc đưa ra quyết định dựa trên trải nghiệm thực tế. Một phương pháp thực nghiệm có nghĩa là làm việc theo cách dựa trên sự thật, dựa trên kinh nghiệm và dựa trên bằng chứng—đặc biệt là khi tiến độ dựa trên quan sát thực tế thay vì các kế hoạch chi tiết ban đầu dựa trên các yêu cầu ban đầu phức tạp.

Tóm lại, chúng ta học hỏi và cải thiện từ những sai lầm và kinh nghiệm trong quá khứ. Ba trụ cột của Scrum hỗ trợ kiểm soát quá trình thực nghiệm trong mọi triển khai là: Minh bạch, Kiểm tra và Điều chỉnh, như minh họa trong sơ đồ dưới đây:

The Three Pillars of Scrum

  • Minh bạch — Một ngôn ngữ chung và các tiêu chuẩn để đảm bảo tính nhất quán và sự hiểu biết chung.
  • Kiểm tra — Đánh giá thường xuyên tiến độ và sản phẩm đầu ra của Scrum để thu thập phản hồi. Rất quan trọng là không được che giấu tiến độ của dự án.
  • Điều chỉnh — Dễ dàng tích hợp phản hồi nhận được và xử lý các vấn đề khi chúng phát sinh.

Các thành phần của quy trình Scrum

Các khung Scrumtự nó rất đơn giản. Nó chỉ định ra một vài nguyên tắc chung, cùng với một bộ quy tắc nhỏ, vai trò, sản phẩm, và các sự kiện. Tuy nhiên, mỗi thành phần này đều quan trọng, có một mục đích cụ thể và là yếu tố then chốt để sử dụng thành công khung này.

Các thành phần chính của khung Scrum là:

Sơ đồ dưới đây minh họa các yếu tố chính của khung công tác SCRUM. Quy trình này đã được triển khai trongCông cụ phần mềm Agile — Bản đồ quy trình Scrum.

Scrum Framework
Khung công tác Scrum

Vai trò Scrum

Khi một tổ chức quyết định áp dụng Scrum, một trong những đ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ò thực hiện dự án truyền thống. Mặc dù Scrum chỉ có ba vai trò chính, nhưng chúng không tự động phù hợp với các chức danh mà phần lớn chúng ta quen thuộc. Hãy bắt đầu bằng một đị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 và làm việc với các nhóm người dùng để xác định những tính năng nào sẽ được đưa vào các phiên bản sản phẩm. Các trách nhiệm chính của người sở hữu sản phẩm là:

  • Xác định định hướng và chiến lược cho sản phẩm hoặc dịch vụ, 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ụ;
  • Giúp đội phát triển hiểu và diễn giải nhu cầu của khách hàng;
  • Thu thập, ưu tiên và quản lý các yêu cầu cho sản phẩm hoặc dịch vụ;
  • Chịu trách nhiệm đối với bất kỳ nhiệm vụ nào liên quan đến ngân sách sản phẩm hoặc dịch vụ, bao gồm cả lợi nhuận;
  • Xác định ngày phát hành cho các tính năng của sản phẩm hoặc dịch vụ;
  • Trả lời các 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ác tính năng đã hoàn thành liên quan đến Sprint;
  • Trình bày các sản phẩm chính của đội phát triển vào cuối mỗi Sprint;
  • Chịu trách nhiệm về Danh sách Sản phẩm.

Scrum Master

Scrum Master là người điều phối đội phát triển linh hoạt. Scrum là một phương pháp giúp các đội tự tổ chức và thực hiện những thay đổi nhanh chóng theo các nguyên tắc linh hoạt. Scrum Master quản lý quá trình trao đổi thông tin. Các trách nhiệm chính của Scrum Master bao gồm:

  • 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 sự can thiệp từ 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ý trong đội;
  • Che chắn đội khỏi sự can thiệp từ 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 người, những ngườ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 huấn luyện trực tiếp bởi Scrum Master nhưng không bị quản lý trực tiếp. Họ phải tự tổ chức, linh hoạt và có 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 các phần tăng trưởng sản phẩm có thể giao được trong mỗi Sprint—từ phân tích, thiết kế, phát triển, kiểm thử đến viết tài liệu kỹ thuật. Các đặc điểm chính của Đội Scrum bao gồm:

  • Đội phải tự tổ chức. Tất cả các thành viên đội phải tự quản lý nỗ lực của mình để hoàn thành các nhiệm vụ được giao. Trong Scrum linh hoạt, không có vị trí 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 hiện các hoạt động của mình và đóng góp vào thành công của đội. Nếu một người thất bại, tất cả đều thất bại.
  • Đội phải đa chức năng. Tất cả các thành viên đội phải có kiến thức và kỹ năng cần thiết để cung cấp một dịch vụ hoặc sản phẩm hoàn chỉnh, sẵn sàng sử dụng. Các chuyên gia có thể được sử dụng khi cần thiết, nhưng chỉ với vai trò huấn luyện viên để truyền đạt kiến thức cho đội và lấp đầy các khoảng trống cụ thể.
  • 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 truyền đạt nhu cầu của họ đến Scrum Master và Đội Phát triển. Đây thường là một vai trò toàn thời gian.
  • Scrum Master không phải là quản lý cấp trực tiếp. Họ cung cấp huấn luyện cần thiết cho Đội Phát triển và giúp loại bỏ bất kỳ trở ngại nào mà đội phải đối mặt.

Danh sách Sản phẩm

Đây là danh sách được sắp xếp của tất cả công việc cần thực hiện trên dự án. Nó được trình bày dưới dạng các câu chuyện, thường được gọi là câu chuyện người dùng.

Câu chuyện người dùng — Những cách biểu diễn khác nhau về cách người dùng tương tác với sản phẩm đầu ra của dự án (sản phẩm, dịch vụ hoặc kết quả). Thông qua các câu chuyện người dùng, đội xác định các tính năng và chức năng cần thiết cho sản phẩm đầu ra.

Do đó, Danh sách Sản phẩm chứa các câu chuyện người dùng được ưu tiên (tính năng và chức năng) cho sản phẩm/dịch vụ/kết quả. Người sở hữu sản phẩm chịu trách nhiệm ưu tiên danh sách này.

Lưu ý: Bạn không cần phải tạo tất cả các câu chuyện cho toàn bộ dự án trước khi bắt đầu công việc (đây là một trong những lợi thế của phương pháp linh hoạt). Bắt đầu với những câu chuyện bạn đã biết, và khi học được thêm nhiều điều, hãy thêm vào danh sách công việc còn lại và sắp xếp lại ưu tiên khi cần thiết.

Lên kế hoạch Sprint

Khác với phương pháp thác nước, các đội linh hoạt không lên kế hoạch mọi thứ từ đầu. Ở đây, đội lên kế hoạch một chút: những gì cần thiết cho Sprint hiện tại (Sprint thường kéo dài từ 2 đến 4 tuần), thực hiện nó, học hỏi từ nó, rồi lên kế hoạch cho Sprint tiếp theo.

Đội Scrum xem xét danh sách công việc sản phẩm và chọn số lượng câu chuyện người dùng mà họ có thể hoàn thành trong khung thời gian Sprint. Các câu chuyện người dùng được chọn sẽ trở thành danh sách công việc Sprint. Danh sách công việc Sprint đại diện cho mục tiêu của Sprint.

Tiêu chuẩn hoàn thành cũng được xác định. Tiêu chuẩn hoàn thành có thể được xem như là các tiêu chí chấp nhận cho các mục trong danh sách công việc.

Chỉ lên kế hoạch cho công việc phù hợp với năng lực của đội—tức là công việc đội có thể hoàn thành một cách thực tế trong mỗi Sprint.

Buổi họp Scrum hàng ngày (Buổi đứng hàng ngày)

Đội sử dụng buổi họp này để đưa ra các cam kết nhỏ với nhau, xác định các vấn đề và đảm bảo công việc Sprint được thực hiện trơn tru trong đội. Buổi họp thường kéo dài 15 phút. Đội trả lời các câu hỏi sau:

  • Tôi đã hoàn thành gì kể từ buổi họp Scrum trước?
  • Kế hoạch của tôi hôm nay là gì? Tôi dự định hoàn thành những gì từ bây giờ đến buổi họp Scrum tiếp theo?
  • Có có trở ngại nào (vấn đề, sự cố hoặc rủi ro) nào đang cản trở tôi không?

Hãy nhớ, buổi họp này không phải là buổi họp cập nhật tiến độ—nó không nhằm mục đích giải quyết vấn đề, mà để nhận thức được vấn đề (nếu có). Nếu cần một buổi họp để giải quyết vấn đề, hãy tổ chức một buổi họp riêng biệt.

Buổi họp xem xét Sprint

Vào cuối mỗi Sprint, đội trình bày tất cả các mục công việc đã hoàn thành. Buổi họp xem xét này được dùng để nhận phản hồi từ các bên liên quan dự án và các yêu cầu thay đổi.

Rất quan trọng cần lưu ý rằng các mục công việc chưa hoàn thành 100% theo Tiêu chuẩn hoàn thành được xác định trong quá trình lập kế hoạch sẽ không được trình bày, vì chúng chưa thực sự “hoàn thành”.

Buổi họp tổng kết Sprint

Buổi họp này diễn ra sau buổi họp xem xét Sprint. Mục đích là giúp đội học hỏi từ Sprint. Quy trình tập trung vào cải tiến liên tục thay vì đổ lỗi cho đội nếu mọi thứ không diễn ra tốt trong Sprint.

Đội phản ánh về cách trở nên hiệu quả hơn và xác định các khu vực khác cần cải thiện.

Người Điều phối viên Scrum xếp hạng mức độ quan trọng của từng mục cải tiến, sau đó đội chọn một số lượng phù hợp các mục cải tiến để triển khai trong Sprint tiếp theoSprint.

Leave a Reply