SCRUM GUIDE 2020

-A A +A

Tải bản PDF: SCRUM GUIDE 2020

Mục đích của Scrum Guide

Chúng tôi đã phát triển Scrum vào đầu những năm 1990. Chúng tôi đã viết phiên bản đầu tiên của Scrum Guide vào năm 2010 để giúp mọi người trên toàn thế giới hiểu về Scrum. Chúng tôi đã phát triển Scrum Guide kể từ đó thông qua các bản cập nhật nhỏ. Cùng nhau, chúng tôi đứng đằng sau nó. (Ken Schwaber và Jeff Sutherland).

Scrum Guide nêu định nghĩa về Scrum. Mỗi yếu tố của khuôn khổ phục vụ một mục đích cụ thể cần thiết cho giá trị tổng thể và kết quả đạt được với Scrum. Việc thay đổi thiết kế hoặc ý tưởng cốt lõi của Scrum, loại bỏ các yếu tố hoặc không tuân theo các quy tắc của Scrum, sẽ che đậy các vấn đề và hạn chế lợi ích của Scrum, thậm chí có thể khiến nó trở nên vô dụng.

Chúng tôi theo dõi việc sử dụng Scrum ngày càng tăng trong một thế giới phức tạp ngày càng phát triển. Chúng tôi rất vui khi thấy Scrum được áp dụng trong nhiều lĩnh vực có công việc phức tạp về cơ bản, ngoài lĩnh vực phát triển sản phẩm phần mềm vốn là nguồn gốc của Scrum. Đi cùng với việc áp dụng Scrum rộng rãi là lúc các nhà phát triển, nhà nghiên cứu, nhà phân tích, nhà khoa học và các chuyên gia khác thực hiện công việc. Chúng tôi sử dụng từ “nhà phát triển” trong Scrum không phải để loại trừ mà để đơn giản hóa. Nếu bạn nhận được giá trị từ Scrum, hãy coi như bạn được kể là “nhà phát triển”.

Khi Scrum đang được sử dụng, các hình mẫu, quy trình và thông tin chi tiết phù hợp với khuôn khổ Scrum như được mô tả trong tài liệu này, có thể được tìm thấy, được áp dụng và phát minh lại. Mô tả chúng (các hình mẫu, quy trình và thông tin chi tiết) nằm ngoài mục đích của Scrum Guide vì chúng nhạy cảm với ngữ cảnh và khác nhau nhiều giữa các cách sử dụng Scrum. Các chiến thuật để sử dụng trong khuôn khổ Scrum rất khác nhau và được mô tả ở những tài liệu khác.

Định nghĩa Scrum

Scrum là một khuôn khổ hạng nhẹ giúp mọi người, các nhóm và tổ chức tạo ra giá trị thông qua các giải pháp linh hoạt thích ứng cho các vấn đề phức tạp.

Nói ngắn gọn, Scrum yêu cầu Scrum Master phải thúc đẩy một môi trường mà ở đó:

  • Product Owner (Chủ sở hữu sản phẩm) sắp xếp thứ tự các công việc cho một vấn đề phức tạp thành một Product Backlog.

  • Scrum team (Nhóm Scrum) biến một tập hợp công việc thành một Phần sản phẩm gia tăng giá trị sau mỗi Sprint.

  • Nhóm Scrum và các bên liên quan kiểm tra kết quả và điều chỉnh cho Sprint tiếp theo.

  • Lặp lại quá trình nói trên

Scrum rất đơn giản. Hãy thử nguyên trạng và xác định xem triết lý, lý thuyết và cấu trúc của nó có giúp đạt được mục tiêu và tạo ra giá trị hay không. Khuôn khổ Scrum có chủ ý không hoàn chỉnh, chỉ xác định các phần cần thiết để triển khai lý thuyết Scrum. Scrum được xây dựng dựa trên trí tuệ tập thể của những người sử dụng nó. Thay vì cung cấp cho mọi người những hướng dẫn chi tiết, các quy tắc của Scrum hướng dẫn các mối quan hệ và tương tác của họ.

Các quy trình, kỹ thuật và phương pháp khác nhau có thể được sử dụng trong khuôn khổ này. Scrum bao gồm các thực hành hiện có hoặc có thể làm cho các thực hành đó không còn cần thiết. Scrum cho thấy hiệu quả tương đối của các kỹ thuật quản lý, môi trường và công việc hiện tại, để có thể thực hiện các cải tiến.

Lý thuyết Scrum

Scrum được thành lập dựa trên chủ nghĩa kinh nghiệm và tư duy tinh gọn. Chủ nghĩa kinh nghiệm khẳng định rằng kiến thức đến từ kinh nghiệm và đưa ra quyết định dựa trên những gì quan sát được. Tư duy tinh gọn giảm lãng phí và tập trung vào những điều cần thiết.

Scrum sử dụng cách tiếp cận lặp đi lặp lại, gia tăng để tối ưu hóa khả năng dự đoán và kiểm soát rủi ro. Scrum thu hút sự tham gia của các nhóm người có tất cả các kỹ năng và chuyên môn để thực hiện công việc và chia sẻ hoặc học hỏi những kỹ năng đó nếu cần.

Scrum kết hợp bốn sự kiện chính thức để kiểm tra và điều chỉnh trong một sự kiện bao trùm chung là Sprint. Các sự kiện này hoạt động vì chúng thực hiện các trụ cột Scrum theo chủ nghĩa kinh nghiệm về tính minh bạch, kiểm tra và thích ứng.

Transparency (Minh bạch)

Quá trình và công việc nổi lên phải được hiển thị rõ ràng cho những người thực hiện công việc cũng như những người nhận công việc. Với Scrum, các quyết định quan trọng dựa trên trạng thái nhận thức của ba sản phẩm (artifact) chính thức của nó. Các sản phẩm có tính minh bạch thấp có thể dẫn đến các quyết định làm giảm giá trị và tăng rủi ro.

Tính minh bạch cho phép kiểm tra. Kiểm tra mà không minh bạch sẽ là lệch đường và lãng phí.

Inspection (Kiểm tra)

Các công cụ (artifact) của Scrum và tiến trình hướng tới các mục tiêu đã thống nhất phải được kiểm tra thường xuyên và cần mẫn để phát hiện các vấn đề hoặc sự sai lệch không mong muốn. Để giúp kiểm tra, Scrum cung cấp lịch hoạt động dưới dạng năm sự kiện của nó.

Kiểm tra cho phép thích ứng. Việc kiểm tra mà không thích ứng được coi là vô nghĩa. Các sự kiện Scrum được thiết kế để kích thích sự thay đổi.

Adaptation (Thích ứng)

Nếu bất kỳ khía cạnh nào của quá trình lệch ra ngoài giới hạn cho phép hoặc nếu sản phẩm tạo thành không được chấp nhận, thì quá trình đang được áp dụng hoặc nguyên liệu được sản xuất phải được điều chỉnh. Việc điều chỉnh phải được thực hiện càng sớm càng tốt để giảm thiểu sai lệch hơn nữa.

Việc thích ứng trở nên khó khăn hơn khi những người liên quan không được trao quyền hoặc không tự quản lý. Nhóm Scrum được kỳ vọng sẽ thích ứng ngay khi học được bất kỳ điều gì mới thông qua kiểm tra.

Giá trị Scrum

Việc sử dụng thành công Scrum phụ thuộc vào việc mọi người trở nên thành thạo hơn trong việc sống với năm giá trị:

Cam kết, Tập trung, Cởi mở, Tôn trọng và Dũng cảm (Commitment, Focus, Openness, Respect, Courage)


Nhóm Scrum cam kết đạt được các mục tiêu của mình và hỗ trợ lẫn nhau. Trọng tâm chính của họ là vào công việc của Sprint để đạt được tiến độ tốt nhất có thể đối với các mục tiêu này. Nhóm Scrum và các bên liên quan cởi mở về công việc và những thách thức. Các thành viên Nhóm Scrum tôn trọng lẫn nhau để trở thành những người có năng lực, độc lập và được những người cùng làm việc tôn trọng. Các thành viên Nhóm Scrum có can đảm để làm điều đúng đắn, và giải quyết những vấn đề khó khăn.
 
Những giá trị này cung cấp định hướng cho Nhóm Scrum liên quan đến công việc, hành động và hành vi của họ. Các quyết định được đưa ra, các bước đã thực hiện và cách sử dụng Scrum phải củng cố những giá trị này, không làm giảm hoặc làm suy yếu chúng. Các thành viên Nhóm Scrum tìm hiểu và khám phá các giá trị khi họ làm việc với các sự kiện và artifact của Scrum. Khi những giá trị này được thể hiện bởi Nhóm Scrum và những người mà họ làm việc cùng, các trụ cột kinh nghiệm của Scrum về tính Minh bạch, Kiểm tra và Thích ứng sẽ trở thành niềm tin xây dựng cuộc sống.

Nhóm Scrum

Đơn vị cơ bản của Scrum là một nhóm nhỏ các thành viên gọi là Nhóm Scrum. Nhóm Scrum bao gồm một Scrum Master, một Product Owner và các Nhà phát triển. Trong Nhóm Scrum, không có nhóm con hoặc hệ thống phân cấp. Nhóm Scrum là một tổ chức gắn kết của các chuyên gia tập trung vào một mục tiêu tại một thời điểm gọi là Mục tiêu Sản phẩm.

Các thành viên nhóm Scrum có khả năng hoán đổi nghiệp vụ (cross-functional) , nghĩa là các thành viên có tất cả các kỹ năng cần thiết để tạo ra giá trị cho mỗi Sprint. Họ cũng có năng lực tự quản lý, nghĩa là họ tự quyết định ai làm gì, khi nào và làm như thế nào.

Nhóm Scrum đủ nhỏ để luôn linh hoạt và đủ lớn để hoàn thành công việc quan trọng trong một Sprint, và thường là có 10 người trở xuống. Nói chung, chúng tôi nhận thấy các nhóm nhỏ giao tiếp tốt hơn và làm việc hiệu quả hơn. Nếu các nhóm Scrum trở nên quá lớn, nên xem xét tổ chức lại thành nhiều nhóm Scrum có sự gắn kết với nhau, mỗi nhóm tập trung vào cùng một sản phẩm. Do đó, các nhóm này nên chia sẻ cùng một Mục tiêu Sản phẩm, một Product Backlog và một Product Owner.

Nhóm Scrum chịu trách nhiệm về tất cả các hoạt động liên quan đến sản phẩm: gồm việc hợp tác với các bên liên quan, kiểm tra, bảo trì, vận hành, thử nghiệm, nghiên cứu và phát triển và bất kỳ hoạt động nào khác có thể được yêu cầu. Họ được tổ chức và trao quyền để quản lý công việc của chính họ. Làm việc thông qua các Sprint với một nhịp độ bền vững giúp cải thiện sự tập trung và nhất quán của Nhóm Scrum.
Toàn bộ Nhóm Scrum phải chịu trách nhiệm về việc tạo ra Phần sản phẩm gia tăng hữu ích và có giá trị sau mỗi Sprint. Scrum xác định ba vai trò trách nhiệm cụ thể trong một Nhóm Scrum: Developers, Product Owner và Scrum Master.

Developers

Các nhà phát triển là những người trong Nhóm Scrum cam kết tạo ra mọi khía cạnh của một Phần sản phẩm gia tăng có thể sử dụng được sau mỗi Sprint.

Các kỹ năng cụ thể mà Nhà phát triển cần có thường rất rộng và sẽ thay đổi theo lĩnh vực công việc. Tuy nhiên, các Nhà phát triển luôn phải chịu trách nhiệm về:

  • Lập kế hoạch cho Sprint, Sprint Backlog;
  • Nâng cao chất lượng bằng cách tuân thủ Định nghĩa Hoàn thành DOD - Definition Of Done (DOD có quan hệ với OKR. Xem tại đây: https://portal.tigosoftware.com/en/node/72 và https://tigosoftware.com/okrs-vs-smart-goals)
  • Điều chỉnh kế hoạch của họ hằng ngày sao cho đạt được Mục tiêu của Sprint; và
  • Chịu trách nhiệm với nhau với tư cách là những người chuyên nghiệp.

Product Owner

Product Owner có trách nhiệm tối đa hóa giá trị của sản phẩm tạo ra bởi công việc của Nhóm Scrum. Cách thực hiện điều này có thể rất khác nhau giữa các tổ chức, Nhóm Scrum và cá nhân Product Owner.

Product Owner cũng chịu trách nhiệm về việc quản lý Product Backlog hiệu quả, bao gồm:

  • Phát triển và truyền đạt rõ ràng Mục tiêu Sản phẩm; 
  • Tạo ra và truyền đạt rõ ràng các hạng mục Product Backlog;
  • Sắp xếp thứ tự ưu tiên các hạng mục Product Backlog; và,
  • Đảm bảo rằng Product Backlog là minh bạch, dễ thấy và dễ hiểu.
     

Product Owner có thể tự thực hiện công việc nói trên hoặc có thể giao phó cho người khác. Bất kể cách nào, Product Owner vẫn phải là người chịu trách nhiệm.

Để cho các Product Owner thành công, toàn bộ tổ chức phải tôn trọng quyết định của họ. Những quyết định này được hiển thị trong nội dung và thứ tự của Product Backlog, và thông qua Phần sản phẩm gia tăng có thể kiểm tra được trong buổi Sprint Review.

Product Owner là một người, không phải là một ủy ban. Product Owner có thể đại diện cho nhu cầu của nhiều bên liên quan trong một Product Backlog. Những người muốn thay đổi Product Backlog có thể thực hiện sự thay đổi bằng cách thuyết phục Product Owner.

Scrum Master

Scrum Master có trách nhiệm thiết lập Scrum như được định nghĩa trong Scrum Guide. Họ làm điều này bằng cách giúp mọi người hiểu lý thuyết và thực hành Scrum, cả trong Nhóm Scrum và tổ chức.

Scrum Master chịu trách nhiệm về hiệu quả của Nhóm Scrum. Họ thực hiện điều này bằng cách cho phép Nhóm Scrum cải thiện các phương pháp thực hành của mình, trong khuôn khổ Scrum.

Scrum Master là những nhà lãnh đạo thực sự phục vụ Nhóm Scrum và rộng hơn là phục vụ tổ chức. Scrum Master phục vụ Nhóm Scrum theo một số cách, bao gồm:

  • Huấn luyện các thành viên trong nhóm về tự quản lý và hoán đổi chức năng;
  • Giúp Nhóm Scrum tập trung vào việc tạo ra các Phần sản phẩm gia tăng có giá trị cao đáp ứng Định nghĩa Hoàn thành;
  • Gây ra việc loại bỏ các trở ngại đối với tiến trình công việc của Nhóm Scrum; và,
  • Đảm bảo rằng tất cả các sự kiện Scrum được diễn ra một cách tích cực, có hiệu quả và giữ được trong khung thời gian cố định.


Scrum Master phục vụ Product Owner theo một số cách, bao gồm:

  • Giúp tìm ra các kỹ thuật để xác định Mục tiêu Sản phẩm hiệu quả và quản lý Product Backlog;
  • Giúp Nhóm Scrum hiểu được sự cần thiết của việc làm cho các hạng mục Product Backlog trở nên rõ ràng và ngắn gọn;
  • Giúp lập kế hoạch sản phẩm thực nghiệm cho một môi trường phức tạp; và,
  • Tạo điều kiện cho sự hợp tác của các bên liên quan khi được yêu cầu hoặc khi cần thiết. Scrum Master phục vụ tổ chức theo một số cách, bao gồm:
  • Lãnh đạo, đào tạo và huấn luyện tổ chức trong việc áp dụng Scrum;
  • Lập kế hoạch và tư vấn triển khai Scrum trong tổ chức;
  • Giúp nhân viên và các bên liên quan hiểu và đưa ra phương pháp tiếp cận thực nghiệm cho các công việc phức tạp; và,
  • Loại bỏ các rào cản giữa các bên liên quan và Nhóm Scrum.

Sự kiện Scrum

Sprint là nơi chứa tất cả các sự kiện khác. Mỗi sự kiện trong Scrum là một cơ hội chính thức để kiểm tra và điều chỉnh các artifact của Scrum. Những sự kiện này được thiết kế đặc biệt để tạo ra sự minh bạch cần thiết. Nếu không thực hiện một sự kiện nào đó trong số những sự kiện đã chỉ dẫn sẽ dẫn đến hậu quả mất cơ hội để kiểm tra và thích ứng. Các sự kiện trong Scrum nhằm tạo ra nhịp điệu công việc đều đặn và giảm thiểu các cuộc họp không được qui định trong Scrum.

Một cách tối ưu, thì mỗi sự kiện Scrum nên được tổ chức tại cùng một thời điểm và địa điểm để giảm bớt sự phức tạp.

Sprint

Sprint là nhịp tim của Scrum, nơi các ý tưởng được biến thành giá trị.
Chúng có độ dài cố định từ một tháng trở xuống để tạo sự nhất quán. Một Sprint mới bắt đầu ngay sau khi kết thúc Sprint trước.



Tất cả các công việc cần thiết để đạt được Mục tiêu Sản phẩm, bao gồm cả các buổi Sprint Planning, Daily Scrums, Sprint Review, và Sprint Retrospective, đều diễn ra trong Sprint.

Trong Sprint:

  • Không có thay đổi nào được thực hiện mà có thể làm chệch mục tiêu Sprint;
  • Chất lượng không giảm;
  • Product Backlog được tinh chỉnh khi cần thiết; và,
  • Phạm vi có thể được làm rõ và thương lượng lại với Product Owner khi Nhóm học hỏi và biết thêm nhiều hơn.


Các Sprint cho phép khả năng dự đoán bằng cách đảm bảo kiểm tra và điều chỉnh tiến độ thực hiện Mục tiêu sản phẩm ít nhất mỗi tháng một lần. Khi khung thời gian của Sprint quá dài, Mục tiêu Sprint có thể trở nên không hợp lệ, độ phức tạp và rủi ro có thể tăng lên. Các Sprint ngắn hơn có thể được sử dụng để tạo ra nhiều chu kỳ học tập hơn và hạn chế rủi ro về chi phí và công sức. Mỗi Sprint có thể được coi là một dự án ngắn.

Có nhiều phương pháp thực hành khác nhau để dự báo tiến độ, chẳng hạn như các biểu đồ burn-down, burn-up hoặc biểu đồ dòng chảy tích lũy (cumulative flow). Mặc dù đã được chứng minh là hữu ích, nhưng những phương pháp thực hành này không thay thế được tầm quan trọng của chủ nghĩa kinh nghiệm. Trong môi trường phức tạp, điều sẽ xảy ra là không thể biết trước. Chỉ những gì đã xảy ra mới có thể được sử dụng để ra quyết định trong tương lai.

Một Sprint có thể bị hủy bỏ nếu Mục tiêu Sprint trở nên lỗi thời. Chỉ Product Owner mới có quyền hủy Sprint.

Sprint Planning

Lập kế hoạch Sprint khởi đầu Sprint bằng cách sắp xếp công việc cần thực hiện cho Sprint. Kế hoạch kết quả này được tạo nên bởi sự cộng tác của toàn bộ Nhóm Scrum.

Product Owner đảm bảo rằng những người tham dự được chuẩn bị để thảo luận về các hạng mục Product Backlog quan trọng nhất và cách chúng liên kết với Mục tiêu Sản phẩm. Nhóm Scrum cũng có thể mời những người khác tham gia Lập kế hoạch Sprint để nhận được lời khuyên.

Lập kế hoạch Sprint giải quyết các chủ đề sau:

Chủ đề 1: Tại sao Sprint này lại có giá trị?
Product Owner đề xuất cách sản phẩm có thể tăng giá trị và tiện ích của nó trong Sprint hiện tại. Sau đó, toàn bộ Nhóm Scrum sẽ cộng tác để xác định Mục tiêu Sprint nhằm truyền đạt lý do tại sao Sprint lại có giá trị đối với các bên liên quan. Mục tiêu Sprint phải được chốt lại trước khi kết thúc buổi Lập kế hoạch Sprint.

Chủ đề 2: Công việc gì có thể hoàn thành trong Sprint này?
Thông qua thảo luận với Product Owner, các Nhà phát triển chọn các hạng mục từ Product Backlog để đưa vào Sprint hiện tại. Nhóm Scrum có thể tinh chỉnh các mục này trong quá trình chọn này, nhằm tăng cường sự hiểu biết và sự tự tin.

Việc chọn số lượng hạng mục có thể hoàn thành trong một Sprint có thể là một thách thức. Tuy nhiên, khi các Nhà phát triển càng biết nhiều về hiệu suất làm việc trong quá khứ, năng lực sắp tới và Định nghĩa Hoàn thành của họ, thì họ càng tin tưởng vào các dự báo Sprint của mình.

Chủ đề 3: Công việc đã chọn sẽ được hoàn thành bằng cách nào?
Đối với mỗi hạng mục Product Backlog đã chọn, các Nhà phát triển lập kế hoạch công việc cần thiết để tạo ra Phần sản phẩm gia tăng đáp ứng Định nghĩa Hoàn thành. Điều này thường được thực hiện bằng cách chia nhỏ các hạng mục Product Backlog thành các mục công việc nhỏ hơn sẽ được làm trong một ngày hoặc ngắn hơn. Việc này được thực hiện như thế nào là do các Nhà phát triển quyết định. Không ai khác chỉ cho họ cách biến các hạng mục Product Backlog thành các Phần sản phẩm gia tăng về giá trị.

Mục tiêu Sprint, các hạng mục Product Backlog được chọn cho Sprint, cùng với kế hoạch thực hiện chúng được gọi chung là Sprint Backlog.

Lập kế hoạch Sprint có khung thời gian tối đa là tám giờ cho Sprint một tháng. Đối với Sprint ngắn hơn, sự kiện thường ngắn hơn.

Daily Scrum

Mục đích của Daily Scrum là kiểm tra tiến độ thực hiện Mục tiêu Sprint và điều chỉnh Sprint Backlog khi cần thiết, điều chỉnh kế hoạch công sắp tới.

Daily Scrum là một sự kiện kéo dài 15 phút dành cho các Nhà phát triển của Nhóm Scrum. Để giảm bớt sự phức tạp, nó được tổ chức vào thời gian cố định và diễn ra hằng ngày trong Sprint. Nếu Product Owner hoặc Scrum Master đang tích cực làm việc với các hạng mục trong Sprint Backlog, họ sẽ tham gia với tư cách như là một Nhà phát triển.

Các nhà phát triển có thể chọn bất kỳ cấu trúc và kỹ thuật nào họ muốn, miễn là Daily Scrum của họ tập trung vào tiến độ hướng tới Mục tiêu Sprint và đưa ra một kế hoạch khả thi cho ngày làm việc tiếp theo. Điều này tạo ra sự tập trung và cải thiện khả năng tự quản lý.

Daily Scrums cải thiện thông tin liên lạc, xác định các trở ngại, thúc đẩy việc ra quyết định nhanh chóng và do đó loại bỏ nhu cầu về các cuộc họp khác.

Daily Scrum không phải là cơ hội duy nhất các Nhà phát triển được phép điều chỉnh kế hoạch của họ. Họ thường gặp nhau suốt cả ngày để thảo luận chi tiết hơn về việc điều chỉnh hoặc lập kế hoạch lại phần việc còn lại của Sprint.

Sprint Review

Mục đích của Sprint Review là kiểm tra kết quả công việc của Sprint và xác định các sự điều chỉnh trong tương lai. Nhóm Scrum trình bày kết quả công việc của họ cho các bên liên quan chính và tiến trình hướng tới Mục tiêu Sản phẩm sẽ được thảo luận.

Trong sự kiện này, Nhóm Scrum và các bên liên quan rà soát lại những gì đã đạt được trong Sprint và những gì đã thay đổi trong môi trường của họ. Dựa trên thông tin này, những người tham dự cùng nhau xác định những việc cần làm tiếp theo. Product Backlog cũng có thể được điều chỉnh để đáp ứng các cơ hội mới. Sprint Review là một phiên làm việc và Nhóm Scrum nên tránh biến nó thành một buổi thuyết trình.

Sprint Review là sự kiện gần sát cuối cùng của Sprint và có khung thời gian tối đa là bốn giờ cho Sprint có khung một tháng. Đối với Sprint ngắn hơn, sự kiện này thường ngắn hơn.

Sprint Retrospective

Mục đích của Sprint Retrospective là hoạch định biện pháp để tăng chất lượng và hiệu quả.

Nhóm Scrum kiểm tra xem Sprint đã diễn ra như thế nào trên các khía cạnh các cá nhân, sự tương tác, quy trình, artifact và Định nghĩa Hoàn thành (DOD). Các yếu tố được kiểm tra thường thay đổi theo lĩnh vực công việc. Các giả định khiến họ lạc lối cần được xác định và tìm hiểu nguồn gốc của chúng. Nhóm Scrum thảo luận về những gì diễn ra tốt đẹp trong Sprint, những vấn đề mà họ gặp phải và cách những vấn đề đó đã được giải quyết (hoặc không được giải quyết).

Nhóm Scrum xác định những thay đổi hữu ích nhất để cải thiện hiệu quả của nhóm. Những cải tiến có ảnh hưởng nhất nên được thực hiện càng sớm càng tốt. Chúng thậm chí có thể được đưa vào Sprint Backlog của Sprint tiếp theo.

Sprint Retrospective là sự kiện cuối cùng của Sprint. Nó có khung thời gian tối đa là 3 giờ cho Sprint có khung một tháng. Đối với Sprint ngắn hơn, sự kiện thường ngắn hơn.

Scrum Artifacts

Các artifact (công cụ) của Scrum đại diện cho công việc hoặc giá trị. Chúng được thiết kế để tăng cường tính minh bạch của các thông tin chính. Vì vậy, tất cả mọi người kiểm tra chúng đều có cơ sở như nhau để thích ứng.

Mỗi artifact chứa đựng một sự cam kết rằng chúng cung cấp thông tin để nâng cao tính minh bạch và tập trung vào cái đích mà theo đó tiến độ thực hiện được đo lường:

  • Đối với Product Backlog, cam kết là Mục tiêu Sản phẩm.
  • Đối với Sprint Backlog, cam kết là Mục tiêu Sprint.
  • Đối với phần sản phẩm gia tăng, cam kết là Định nghĩa Hoàn thành (DOD).

Những cam kết này tồn tại để củng cố chủ nghĩa kinh nghiệm và các giá trị Scrum cho Nhóm Scrum và các bên liên quan của họ.

Product Backlog

Product Backlog là một danh sách được phát triển dần và có thứ tự về những thứ cần thiết để cải thiện sản phẩm. Đây là nguồn duy nhất các công việc mà Nhóm Scrum phải thực hiện.

Các hạng mục Product Backlog mà có thể được Nhóm Scrum hoàn thành trong một Sprint được coi là sẵn sàng để được lựa chọn trong sự kiện Lập kế hoạch Sprint. Chúng thường đạt được mức độ minh bạch như vậy sau các hoạt động tinh chỉnh (refinement). Tinh chỉnh Product Backlog là hành động chia nhỏ và xác định rõ hơn các hạng mục Product Backlog thành các mục nhỏ hơn và chính xác hơn. Đây là một hoạt động liên tục để thêm các chi tiết, chẳng hạn như thêm mô tả, sắp xếp lại thứ tự và ước lượng qui mô. Các thuộc tính thường thay đổi theo lĩnh vực công việc.

Các nhà phát triển, những người thực hiện công việc, chịu trách nhiệm ước lượng qui mô công việc. Product Owner có thể ảnh hưởng đến Nhà phát triển bằng cách giúp họ hiểu và lựa chọn sự cân bằng.

Cam kết: Mục tiêu Sản phẩm

Mục tiêu Sản phẩm mô tả trạng thái tương lai của sản phẩm được dùng làm mục tiêu để Nhóm Scrum lập kế hoạch thực hiện. Mục tiêu Sản phẩm nằm trong Product Backlog. Những phần còn lại của Product Backlog lộ diện dần để xác định “cái gì” sẽ hoàn thành Mục tiêu Sản phẩm.

Sản phẩm là phương tiện để cung cấp giá trị. Nó có một ranh giới rõ ràng, có các bên liên quan được biết rõ, có người dùng hoặc khách hàng được xác định. Một sản phẩm có thể là một dịch vụ, một sản phẩm vật lý hoặc một cái gì đó trừu tượng hơn.

Mục tiêu Sản phẩm là mục tiêu dài hạn của Nhóm Scrum. Họ phải hoàn thành (hoặc từ bỏ) một mục tiêu trước khi thực hiện mục tiêu tiếp theo.

Sprint Backlog

Sprint Backlog bao gồm Mục tiêu Sprint (“Why”), tập hợp các hạng mục Product Backlog được chọn cho Sprint (“What”), và một kế hoạch hành động để cung cấp Phần sản phẩm gia tăng (“How”).

Sprint Backlog là một kế hoạch dành cho các Nhà phát triển. Đó là một bức tranh thời gian thực, có thể nhìn thấy rõ ràng về công việc mà các Nhà phát triển dự định hoàn thành trong Sprint để đạt được Mục tiêu Sprint. Do đó, Sprint Backlog được cập nhật trong suốt Sprint khi các nhà Phát triển học được nhiều điều hơn. Nó phải có đủ chi tiết để họ có thể kiểm tra tiến trình của mình trong Daily Scrum.

Cam kết: Mục tiêu Sprint

Mục tiêu Sprint là mục tiêu duy nhất của Sprint. Mặc dù Mục tiêu Sprint là cam kết của Nhà phát triển, nhưng nó cung cấp sự linh hoạt về công việc cụ thể cần thực hiện để đạt được nó. Mục tiêu Sprint cũng tạo ra sự gắn kết và tập trung, khuyến khích Nhóm Scrum làm việc cùng nhau thay vì dựa trên các sáng kiến riêng biệt.

Mục tiêu Sprint được tạo ra trong sự kiện Lập kế hoạch Sprint và sau đó được thêm vào Sprint Backlog. Khi các Nhà phát triển làm việc trong Sprint, họ luôn ghi nhớ Mục tiêu Sprint. Nếu công việc diễn ra khác với họ mong đợi, họ sẽ cộng tác với Product Owner để thương lượng về phạm vi của Sprint Backlog trong Sprint sao cho không ảnh hưởng đến Mục tiêu Sprint.

Increment

Phần sản phẩm gia tăng là một bước đệm cụ thể để hướng tới Mục tiêu Sản phẩm. Mỗi Phần sản phẩm gia tăng được cộng vào tất cả các Phần sản phẩm gia tăng trước đó và được kiểm tra kỹ lưỡng, đảm bảo rằng tất cả các Phần sản phẩm gia tăng hoạt động cùng nhau trơn chu. Để cung cấp giá trị, Phần sản phẩm gia tăng phải có thể sử dụng được.

Nhiều Phần sản phẩm gia tăng có thể được tạo ra trong một Sprint. Tổng các Phần sản phẩm gia tăng được trình bày tại phiên Sprint Review, và bằng cách đó hỗ trợ chủ nghĩa kinh nghiệm. Tuy nhiên, mỗi Phần sản phẩm gia tăng có thể được bàn giao cho các bên liên quan trước khi kết thúc Sprint. Sprint Review không bao giờ được coi là một cánh cổng để bàn giao giá trị.

Công việc không thể được coi là một phần của Phần sản phẩm gia tăng chừng nào nó còn chưa đáp ứng Định nghĩa về Hoàn thành.

Cam kết: Định nghĩa Hoàn thành (DOD)

Định nghĩa Hoàn thành là một mô tả chính thức về trạng thái của Phần sản phẩm gia tăng khi nó đáp ứng các chỉ tiêu chất lượng cần thiết của sản phẩm.

Thời điểm một hạng mục Product Backlog đáp ứng Định nghĩa Hoàn thành, thì một Phần sản phẩm gia tăng được tạo ra.
 
Định nghĩa Hoàn thành tạo ra sự minh bạch bằng cách cung cấp cho mọi người sự hiểu biết chung về những công việc gì đã được hoàn thành như một phần của Phần sản phẩm gia tăng. Nếu một hạng mục Product Backlog không đáp ứng Định nghĩa Hoàn thành, nó không thể được phát hành hoặc thậm chí sẽ không được trình bày tại phiên Sprint Review. Thay vào đó, nó quay trở lại Product Backlog để xem xét trong tương lai.

Nếu Định nghĩa Hoàn thành cho một Phần sản phẩm gia tăng là nằm trong một tiêu chuẩn của tổ chức, thì tất cả các Nhóm Scrum phải tuân thủ nó như một điều tối thiểu. Nếu Định nghĩa Hoàn thành không phải là một tiêu chuẩn tổ chức, Nhóm Scrum phải tự tạo ra một Định nghĩa Hoàn thành phù hợp cho sản phẩm.

Các nhà phát triển được yêu cầu tuân thủ Định nghĩa Hoàn thành. Nếu có nhiều Nhóm Scrum cùng làm việc trên một sản phẩm, họ phải cùng nhau xác định và tuân thủ cùng một Định nghĩa Hoàn thành.

Lịch sử Scrum Guide

Ken Schwaber và Jeff Sutherland lần đầu tiên đồng trình bày về Scrum tại Hội nghị OOPSLA năm 1995. Về cơ bản, nó ghi lại những gì Ken và Jeff đã học được trong vài năm trước đó và công khai định nghĩa chính thức đầu tiên về Scrum.
Scrum Guide là tài liệu về Scrum như cách nó đã được phát triển, tiến hóa và duy trì bền vững trong hơn 30 năm qua bởi Jeff Sutherland và Ken Schwaber. Các nguồn khác cung cấp các mẫu, quy trình và thông tin chi tiết bổ sung cho khuôn khổ Scrum. Chúng có thể làm tăng năng suất, giá trị, sự sáng tạo và sự hài lòng về kết quả.
 

Category
Methodology

Tags