scrum guide - hanoi scrumhanoiscrum.net/hnscrum/images/resource/scrum guide_vi_beta_tan.pdf ·...

Scrum Guide Tác giả: Ken Schwaber và Jeff Sutherland

Dịch: Dương Trọng Tấn

2 Scrum Guide – Ken Schwaber và Jeff Sutherland

Bản Việt hóa này đang ở trạng thái beta

Lời nói đầu (cho bản dịch )

Với yêu cầu về mặt phương pháp phát triển phần mềm phải đảm bảo sự gọn nhẹ, linh hoạt nhưng hiệu

quả, từ đầu những năm 1990, hàng loạt các phương pháp phát triển phần mềm linh hoạt (agile software

development, còn gọi tắt là Agile) ra đời nhằm đáp ứng yêu cầu ngày càng đa dạng và phức tạp của thực

tiễn phát triển phần mềm trên thế giới. Scrum được phát triển tương đối sớm bởi hai tác giả của nó là Ken

Schwaber và Jeff Sutherland, và sớm trở thành một trong các phương pháp thành công nhất trong các

phương pháp phát triển linh hoạt do sự đơn giản, hiệu quả và thú vị mà nó mang lại. Người dùng Scrum

không chỉ ấn tượng với năng suất cực cao mà còn cảm nhận rõ ràng sự thay đổi trong cách làm việc: trách

nhiệm hơn, hiệu quả hơn, và thú vị hơn.

Vài năm trở lại đây Scrum đã được du nhập vào Việt Nam, trước hết thông qua các công ty có yếu tố nước

ngoài, sau đó đã xuất hiện chủ động ngày càng nhiều ở các công ty làm phần mềm suốt từ Nam chí Bắc.

Nhu cầu về công việc và học tập Scrum vì thế tăng lên đáng kể trong một hai năm gần đây. Tuy vậy, chưa

có tổ chức giáo dục đào tạo nào đưa Scrum vào đào tạo chính quy, cũng như chưa có tài liệu chính quy nào

bằng tiếng Việt được cung cấp cho người dùng và người học Scrum để rút ngắn thời gian tiếp cận với

phương pháp làm việc vô cùng hiệu quả và hấp dẫn này. Trước tình hình đó, một nhóm những người thực

hành Scrum đã tập hợp lại dưới hình thức nhóm những người sử dụng Agile và Scrum để cùng chia sẻ kinh

nghiệm tại Hà Nội (www.HanoiScrum.net ) và Thành phố Hồ Chí Minh (www.AgileVietnam.org). Cùng

chung nỗ lực với cộng đồng, người dịch tài liệu này mong muốn kiến thức về Scrum được giới thiệu tới

người quan tâm đến Scrum bằng chính ngôn ngữ mẹ đẻ - tiếng Việt hòng giúp cho việc học tập và sử dụng

Scrum trở nên hệ thống và có bài bản hơn. Đây là tài liệu dịch từ bản Scrum Guide xuất bản năm 2010 của

chính Ken Schwaber và Jeff Sutherland, công bố trên Scrum.org; và nó sẽ được cập nhật khi bản gốc có sự

chỉnh sửa.

Do đây là một trong số những tài liệu căn bản đầu tiên bằng tiếng Việt về Scrum nên có nhiều thuật ngữ

vẫn chưa được Việt hóa tốt, và vì vậy bạn đọc có thể thấy nhiều chỗ người dịch để cả thuật ngữ tiếng Anh

bên cạnh tiếng Việt. Trong quá trình dịch, người dịch cố gắng bám sát ý nghĩa và văn phong của tác giả.

Đồng thời, để cung cấp thêm thông tin cho người mới tiếp cận Scrum lần đầu, người dịch có chú giải thêm

một số thuật ngữ, và cung cấp phần phụ lục “Thuật ngữ Scrum” để bạn đọc tiện tra cứu. Sử dụng triết lý

tăng trưởng và tiến hóa của Scrum, các thuật ngữ này sẽ sớm được cập nhật dựa theo thực tiễn và sự

chấp nhận rộng rãi của cộng đồng sử dụng Scrum. Tài liệu tuy ngắn nhưng do khách quan hoặc trình độ

của người dịch, bản dịch có thể còn nhiều lỗi hoặc nhiều chỗ có thể cải tiến cho tốt hơn; mọi đóng góp quý

báu về tài liệu này, xin vui lòng gửi về hộp thư [email protected] để người dịch có cơ hội cải tiến

bản dịch ngày càng hoàn thiện hơn, cung cấp thêm giá trị cho người học và sử dụng Scrum.

Cuối cùng, người dịch xin trân trọng cảm ơn hai bạn đồng nghiệp, cũng là hai người thực hành Scrum,

Nguyễn Việt Khoa và Nguyễn Ngọc Tú đã bỏ công đọc và cung cấp nhiều góp ý quan trọng cho tài liệu này.

http://www.hanoiscrum.net/

http://www.agilevietnam.org/

mailto:[email protected]



Mục lục Lời nói đầu .............................................................................................................................................. 2

Giới thiệu ................................................................................................................................................ 4

Tổng quan ........................................................................................................................................... 4

Con người ........................................................................................................................................... 4

Lược sử ............................................................................................................................................... 4

Mục đích ............................................................................................................................................. 4

Lý thuyết Scrum ...................................................................................................................................... 5

Tính minh bạch ................................................................................................................................... 5

Việc thanh tra ...................................................................................................................................... 5

Sự thích nghi ....................................................................................................................................... 5

Nội dung Scrum ...................................................................................................................................... 6

Vai trò trong Nhóm Scrum .................................................................................................................. 7

ScrumMaster ...................................................................................................................................... 8

Product Owner - Chủ Sản phẩm .......................................................................................................... 9

Đội sản xuất - Team ............................................................................................................................ 9

Các Hộp Thời gian (Time-Box) .......................................................................................................... 10

Họp Kế hoạch phát hành - Release Planning Meeting ....................................................................... 10

Sprint – Phân đoạn nước rút ............................................................................................................. 12

Họp Kế hoạch Sprint - Sprint Planning Meeting ................................................................................ 13

Họp Sơ kết Sprint - Sprint Review ..................................................................................................... 15

Họp Cải tiến Sprint - Sprint Retrospective ......................................................................................... 15

Họp Scrum hằng ngày - Daily Scrum ................................................................................................. 16

Đồ nghề Scrum (Scrum Artifacts) ...........................................................................................................17

Product Backlog và Release Burndown ..............................................................................................17

Sprint Backlog và Sprint Burndown ................................................................................................... 19

Hoàn thành (hay Xong - Done) .......................................................................................................... 20

Lời cuối ................................................................................................................................................. 21

Phụ lục – Thuật ngữ Scrum ................................................................................................................... 23



Giới thiệu

Tổng quan

Scrum được xây dựng trên các phương pháp thực hành đã được chấp nhận rộng rãi qua hàng thập kỉ qua. Sau đó nó được coi như là lý thuyết quản lý thực nghiệm (empirical process theory). Jim Coplien có lần đã nhấn mạnh với Jeff “tất cả mọi người sẽ thích Scrum; nó thực sự là những gì mà chúng ta sẽ làm khi bị dồn đến chân tường”.

Con người

Hàng nghìn người đã góp công xây dựng Scrum, chúng tôi chỉ là những người

thử nghiệm nó trong khoảng mươi năm đầu. Những người có thể kể đến gồm

Jeff Sutherland, cùng vời Jeff McKenna, Ken Schwaber cùng với Mike Smith và

Chris Martin. Scrum lần đầu được trình bày chính thức tại OOPSLA 1995. Trong

khoảng năm năm tiếp theo, Mike Beedle và Martine Devos đã có thêm nhiều

đóng góp quan trọng. Và sau đó, rất nhiều người khác đã cùng nhau cải tiến để

Scrum hoàn thiện như hôm nay chúng ta thấy.

Lược sử

Scrum có một lịch sử tương đối dài trong thế giới phần mềm. Những nơi đầu tiên

áp dụng Scrum có thể kể đến Individual, Inc., Fidelity Investments, và IDX (bây

giờ là GE Medical).

Mục đích

Ngay từ những năm 1990, Scrum đã được dùng để phát triển các sản phẩm phức

tạp. Tài liệu này mô tả cách sử dụng Scrum để làm ra các sản phẩm phần mềm.

Scrum không phải là một quy trình hay một kĩ thuật để làm ra sản phẩm, mà là

một khung làm việc (framework) bao gồm nhiều quy trình và kĩ thuật khác.

Scrum có khả năng phát lộ tính hiệu quả của các hoạt động phát triển phần mềm

để từ đó bạn có thể cải tiến chúng trong khi cung cấp một khung làm việc để

phát triển các sản phẩm phức tạp.



Lý thuyết Scrum

Scrum là một lý thuyết kiểm soát tiến trình thực nghiệm (emprical process

control), sử dụng cách tiếp cận lặp (iterative) và tăng trưởng (incremental) để tối

ưu hóa khả năng dự báo (predictability) và kiểm soát rủi ro. Ba giá trị cốt lõi (còn

gọi là Ba chân của Scrum) làm nên quá trình kiểm soát tiến trình thực nghiệm

bao gồm: tính minh bạch, việc thanh tra và sự thích nghi.

Tính minh bạch

Sự minh bạch đảm bảo tất cả các yếu tố của quá trình có ảnh hưởng đến kết quả

được công khai cho tất cả những người có trách nhiệm với dự án. Không chỉ các

yếu tố đó được công khai, mà tất cả những gì đang được quan sát cũng phải

thông suốt tới các bên. Điều đó có nghĩa là khi một người khảo sát một quy trình

tin rằng có việc gì đó được hoàn thành, thì nó phải thỏa mãn tất cả các yêu cầu

trong định nghĩa thế nào là hoàn thành (“Definition of done”).

Việc thanh tra

Rất nhiều yếu tố trong quy trình cần phải được thanh tra thường xuyên để đảm

bảo tất cả các sai sót trong quy trình sớm được phát hiện. Tần suất thanh tra

được xác định sao cho các yếu tố của quy trình phát triển có thể thay đổi được

sau khi thanh tra, từ đó mở đường cho khả năng thích nghi của quy trình. Có vẻ

như càng thanh tra nhiều thì vấn đề càng phát sinh lắm. Nhưng may thay, điều

đó không đúng trong việc phát triển phần mềm. Chất lượng thanh tra không

hoàn toàn do tần suất thanh tra quyết định, mà còn do các yếu tố khác nữa, như

kĩ năng thanh tra hay mức độ cần cù và tỉ mỉ của người thực hiện công tác thanh

tra.

Sự thích nghi

Nếu người thực hiện công tác thanh tra thấy rằng một vài chỗ trong quy trình là

bất thường, và hậu quả của nó có thể là không thể chập nhận được, thì quy trình

hoặc các yếu tố liên quan cần phải được điều chỉnh cho phù hợp. Việc điều chỉnh

phải kịp thời để giảm thiểu các lệch lạc khác có thể xảy ra.

Trong Scrum có ba thời điểm quan trọng cho việc thanh tra và thích nghi. Thứ

nhất là cuộc họp Daily Scrum, được dùng để rà soát tiến độ công việc trong một



Sprint, đồng thời có các hành động thích nghi để tối ưu hóa giá trị của các ngày là

việc tiếp theo. Thứ hai, buổi Họp Sơ kết Sprint (Sprint Review) và Họp kế hoạch

Sprint (Sprint Planning) được dùng để thanh tra tiến trình hướng đến Mục tiêu

Phát hành (Realease Goal) và có các hành động thích ứng để tối ưu hóa Sprint

tiếp theo. Cuối cùng, Buổi họp Cải tiến (Sprint Retrospective) được dùng để khảo

sát kĩ càng Sprint vừa diễn ra và xác định các biện pháp thích ứng cho Sprint kế

tiếp thêm năng suất, hoàn thiện và thú vị.

Nội dung Scrum

Khung làm việc Scrum bao gồm Nhóm Scrum (Scrum Team) với các vai trò được

định nghĩa rõ ràng; các Hộp thời gian (Time-Box), Đồ nghề (Artifact), và các Quy

tắc.

Nhóm Scrum được thiết kế để tối ưu hóa tính linh hoạt và năng suất lao động.

Để làm được điều đó, Nhóm Scrum thực hiện cơ chế tự quản, cơ cấu liên chức

năng (cross-functional) và làm việc tập trung trong các phân đoạn (iteration) lặp

đi lặp lại trong suốt dự án. Mỗi Nhóm Scrum có ba vai trò: một là ScrumMaster –

người chịu trách nhiệm cho các quy trình của dự án, hai là Product Owner (chủ

sản phẩm) – người chịu trách nhiệm cho giá trị của công việc mà Nhóm Scrum

làm, và ba là Đội sản xuất (Team) gồm những người trực tiếp làm ra phần mềm.

Đội sản xuất bao gồm các nhà phát triển (developer) với tất cả các kĩ năng cần

thiết để chuyển đổi yêu cầu của Product Owner thành các gói phần mềm hoàn

chỉnh ở cuối mỗi Sprint.

Scrum sử dụng khái niệm Hộp thời gian (Time-Box) để thiết lập quy tắc cho

nhóm. Trong Scrum, các thành tố được đóng hộp (timeboxed) bao gồm buổi Họp

kế hoạch Phát hành (Release Planning Meeting), Họp Kế hoạch Sprint (Sprint

Planning Meeting), Sprint, Họp Scrum hằng ngày (Daily Scrum), Họp Sơ kết

Sprint (Sprint Review) và Họp Cải tiến Sprint (Sprint Retrospective). Trái tim của

Scrum chính là Sprint – một phân đoạn phát triển diễn ra trong phạm vi ít hơn

một tháng. Tất cả các Sprint trong cùng một dự án sử dụng cùng một khung làm

việc Scrum, Sprint nọ tiếp nối ngay sau Sprint kia và mỗi Sprint đều có kết quả



cuối cùng là các gói phần mềm hoàn chỉnh chuyển giao được (potentially

shippable product increment).

Scrum sử dụng bốn “đồ nghề” (artifact) cơ bản bao gồm Product Backlog, Sprint

Backlog, Release Burndown và Sprint Burndown. Product Backlog chứa danh

sách ưu tiên các yêu cầu của dự án.

Sprint Backlog là danh sách công

việc cần làm để biến Product

Backlog trong mỗi Sprint thành một

gói phần mềm hoàn chỉnh có thể

chuyển giao ngay. Release

Burndown đo phần hạng mục còn lại

trong Product Backlog trong một Kế

hoạch Phát hành. Còn Sprint

Burndown đo các thời gian (ước

tính) cần thiết còn lại để hoàn tất các

tác vụ trong một Sprint.

Các quy tắc của Scrum gắn kết các yếu tố Hộp thời gian, Vai trò và Đồ nghề

(artifact) lại với nhau để Scrum phát huy tác dụng. Chúng ta sẽ dần tìm hiểu các

quy tắc của Scrum trong suốt tài liệu này. Ví dụ, Scrum có đặt ra quy tắc là chỉ

thành viên của Đội sản xuất – tức người có trách nhiệm với việc biến từng hạng

mục trong Product Backlog thành mỗi gói phần mềm (increment) – có thể nói

trong Daily Scrum. Trong tài liệu này, có nhiều gợi ý hữu ích cho việc triển khai

Scrum nhưng không phải là quy tắc của Scrum; chúng được mô tả trong các hộp

văn bản với các tiêu đề “Mẹo”.

Vai trò trong Nhóm Scrum

Nhóm Scrum bao gồm ScrumMaster, Product Owner và Đội sản xuất. Các thành viên Nhóm Scrum được gọi là các chú “lợn”. Chủ Sản phẩm (Product Owner) là “lợn” của Product Backlog. Đội sản xuất là “lợn” của các công việc trong Sprint. ScrumMaster là “lợn” của tiến trình Scrum. Những người khác nếu có tham gia vào dự án thì đều là “gà”. Gà không thể chỉ cho lợn biết phải làm việc ra sao. Hai vai trò “lợn” và “gà” ở đây thực ra có xuất xứ từ một câu chuyện vui như sau:

Mẹo

Nếu không tìm thấy hướng dẫn từ các quy tắc

Scrum, bạn phải tự xác định mình sẽ phải làm

những gì để công việc tiến triển. Do điều kiện

thực tiễn luôn thay đổi khôn lường, nên bạn

đừng cố gắng tìm kiếm một giải pháp hoàn hảo.

Thay vì đó, hãy thử một phương án và xem nó

làm việc ra sao. Hãy để cơ chế thanh tra – thích

nghi (inspect-adapt) trong Scrum hướng dẫn bạn

đi tiếp như thế nào.



“Một chị gà mái và một chú lợn cùng ở

với nhau khi chú gà gợi ý: “Ta cùng mở

một nhà hàng nhé!”.

Chú lợn nghĩ một lúc và nói: “Ta sẽ gọi

tên nhà hàng này là gì nhỉ?”

Chị gà đáp lại: “Nhà hàng Thịt lợn và

Trứng gà!”

Chú lợn kêu lên: “Ồ không, tôi thì bị

thịt còn chị thì chỉ tham gia có thế thôi

ư?”.

ScrumMaster

ScrumMaster chịu trách nhiệm đảm

bảo toàn bộ Nhóm Scrum tuân thủ và

được hưởng lợi từ các giá trị của

Scrum, các kĩ thuật cũng như các quy

tắc của Scrum. ScrumMaster giúp đỡ

Nhóm Scrum cũng như một tổ chức

áp dụng được Scrum vào trong công việc của họ. ScrumMaster dạy cho Nhóm

Scrum bằng cách huấn luyện và dẫn dắt Nhóm để đạt được năng suất cao và làm

ra sản phẩm có chất lượng tốt. ScrumMaster giúp đỡ Nhóm Scrum hiểu và sử

dụng cơ chế tự tổ chức (self-organization) cũng như cơ cấu liên chức năng (cross-

functional) trong nhóm. ScrumMaster cũng giúp đỡ Nhóm Scrum phát huy tối đa

khả năng trong môi trường chưa được tổ chức tốt để vẫn có thể hiệu quả trong

các dự án phức tạp. Các công việc trợ giúp của ScrumMaster có đặc trưng cơ bản

là “loại bỏ trở lực” (removing impediment). ScrumMaster vừa là người lãnh đạo

vừa là đầy tớ của Nhóm Scrum.

Mẹo

Một thành viên, có thể là một lập trình viên,

trong Đội sản xuất có thể giữ vai trò

ScrumMaster. Tuy nhiên, điều này thường dẫn

đến một số xung đột khi ScrumMaster phải lựa

chọn giữa việc “loại bỏ trở lực” hay thực thi

nhiệm vụ đã chọn trong Sprint. ScrumMaster

không được phép làm Product Owner.

Mẹo

ScrumMaster làm việc với khách hàng và bộ phận

quản lý để thiết lập một Chủ sản phẩm (Product

Owner). ScrumMaster sẽ dạy cho Product Owner

cách làm việc trong nhóm. Product Owner sẽ học

được cách quản lý và tối ưu hóa giá trị khi dùng

Scrum. Nếu Product Owner không làm được việc

của mình, ScrumMaster sẽ là người chịu trách

nhiệm.



Product Owner - Chủ Sản phẩm

Product Owner là người duy nhất chịu trách nhiệm cho việc quản lý Product

Backlog và đảm bảo các giá trị cho Đội sản xuất làm việc. Product Owner duy trì

Product Backlog và đảm bảo Product Backlog được hiển thị cho tất cả mọi người.

Mọi người cần phải biết đâu là phần có độ ưu tiên cao hơn, để biết cần phải làm

việc với cái gì.

Chủ Sản phẩm là cá nhân, không phải là một ủy ban. Một ủy ban nào đó có thể

được thành lập để gợi ý hoặc tạo ảnh hưởng tới Product Owner, nhưng quyết

định cuối cùng liên quan đến việc thay đổi Product backlog là của Product Owner.

Các công ty sử dụng Scrum có thể có các cách thức khác nhau để thiết lập các độ

ưu tiên và yêu cầu theo thời gian.

Để đảm bảo thành công cho Product Owner, mọi người trong tổ chức cần phải

tôn trọng quyết định của người đảm nhiệm vai trò này. Không ai khác được

quyền áp đặt cách làm việc cho Đội sản xuất thông qua các bộ ưu tiên khác, và

Đội sản xuất bắt buộc phải lờ đi các áp đặt kiểu như vậy. Quyết định của Product

Owner luôn luôn minh bạch trong nội dung cũng như trong các mức độ ưu tiên.

Sự minh bạch này đòi hỏi Product Owner phải nỗ lực tối đa, và điều đó khiến cho

vai trò Product Owner vừa là yêu cầu, nhưng cũng là phần thưởng cho người

nắm giữ nó.

Đội sản xuất - Team

Đây là nhóm các nhà phát triển với mục tiêu chuyển đổi các yêu cầu trong

Product Backlog thành các gói sản phẩm sẵn sàng chuyển giao ở cuối mỗi Sprint.

Giống như Nhóm Scrum, Đội sản xuất cũng liên chức năng; các thành viên phải

có đầy đủ các kĩ năng cần thiết để

hoàn thành các công việc phát triển.

Thành viên Đội sản xuất thường có

một số kĩ năng chuyên biệt như lập

trình, quản lý chất lượng, phân tích

nghiệp vụ, thiết kế, làm giao diện,

hoặc thiết kế cơ sở dữ liệu. Tuy

Mẹo

Product Owner có thể là một trong số các thành

viên đội phát triển. Trách nhiệm này có thể làm

giảm khả năng làm việc với các bên liên quan.

Product Owner không thể làm ScrumMaster.



nhiên, bộ kĩ năng mà thành viên Đội sản xuất chia sẻ (đó là cách để hiểu yêu cầu

khách hàng và tiến hành chuyển đổi chúng thành sản phảm dùng được) sẽ trở

nên quan trọng hơn các kĩ năng còn lại. Trong Đội sản xuất, kiến trúc sư phần

mềm phải viết code. Không còn các chức danh trong Đội sản xuất, chỉ có nhà

phát triển – developer, không có ngoại lệ. Một Đội sản xuất cũng không có các

phân đội chuyên biệt kiểu như đội kiểm thử hay đội phân tích thiết kế, chỉ có một

đội duy nhất – Đội sản xuất.

Đội sản xuất tự tổ chức lấy các hoạt động của mình. Không một ai, kể cả

ScrumMaster – phải chỉ cho nhóm biết phải làm gì để chuyển đổi yêu cầu thành

sản phẩm dùng được. Nhóm sẽ phải tự chịu trách nhiệm tìm ra giải pháp để làm

việc đó. Mỗi thành viên của nhóm sẽ phải áp dụng các chuyên môn của mình để

giải quyết tất cả các vấn đề gặp phải. Sự hợp lực (synergy) sẽ mang lại kết quả

cuối cùng cũng như tăng độ hiệu quả của nhóm.

Độ lớn tối ưu cho một Đội sản xuất là bảy người, cộng trừ hai. Khi có ít hơn năm

người trong nhóm, sẽ có ít tương tác hơn và đem lại năng suất thấp hơn. Nếu lớn

hơn, nhóm sẽ gặp nhiều trở lực hơn trong Sprint và giảm khả năng hoàn thành

công việc đúng hẹn trong mỗi Sprint. Nếu nhóm có nhiều hơn chín người, quá

trình hợp nhất rất khó khăn, và cần nhiều nỗ lực hơn để quản lý công việc. Tuy

nhiên, trong thực tiễn vẫn có các nhóm lớn mà hiệu quả. Lưu ý là trong khi tính số

lượng thành viên của Đội sản xuất, ta không tính Product Owner và ScrumMaster

trừ khi bản thân họ tham gia Đội sản xuất , tức họ có tham gia vào quá trình thực

hiện các nhiệm vụ trong Sprint Backlog bên cạnh việc giữ các vai trò như Product

Owner hay ScrumMaster.

Cấu trúc nhóm có thể thay đổi khi Sprint kết thúc. Khi đó, mối quan hệ trong

nhóm thay đổi, và năng suất từ quá trình tự tổ chức có thể giảm xuống. Hãy cẩn

thận với các thay đổi kiểu này.

Các Hộp Thời gian (Time-Box)

Họp Kế hoạch phát hành - Release Planning Meeting



Mục đích của buổi họp lập kế hoạch cho phiên bản là tạo ra mục đích cũng như

một bản kế hoạch để cả Nhóm Scrum (bao gồm Product Owner, ScrumMaster và

Đội sản xuất) và phần còn lại của tổ chức có thể hiểu và giao tiếp với nhau. Công

tác lập kế hoạch bao gồm việc trả lời một số câu hỏi căn bản như “Làm sao để

biến tầm nhìn (vision) về sản phẩm thành sản phẩm thực sự theo cách khả thi

nhất?”, “Làm sao để đạt được hoặc làm tốt hơn sự mong đợi và thỏa mãn của

khách hàng cũng như về mặt hiệu quả đầu tư (ROI – Return on Investment)?”.

Bản Kế hoạch phát hành xác lập mục tiêu cho bản phát hành (release), độ ưu tiên

cao nhất cho Product Backlog, các rủi ro căn bản, và các tính năng mà phiên bản

phần mềm sẽ có. Bản kế hoạch đó còn chứa ngày dự định phát hành, chi phí đầu

tư nếu không có gì thay đổi. Tổ chức có thể khảo sát tiến trình phát triển và thay

đổi bản kế hoạch này giữa các Sprint.

Việc lập Kế hoạch phát hành là không bắt buộc. Nếu Nhóm Scrum bắt đầu công

việc mà không họp lập kế hoạch phát hành, thì sự thiếu vắng kế hoạch đó có thể

coi như một trở ngại cần được loại bỏ (bằng cách nào đó) trong quá trình triển

khai Sprint sắp tới.

Các sản phẩm được xây dựng theo từng phân đoạn trong Scrum, ở đó mỗi Sprint

tạo ra một phần tăng trưởng cho sản phẩm, bắt đầu từ các phần có giá trị cao

nhất và ít rủi ro nhất. Cứ sau mỗi Sprint, sản phẩm sẽ lớn dần lên. Và các phần

tăng trưởng đóp góp cho sự hoàn thiện của sản phẩm đó phải luôn luôn ở trạng

thái có thể chuyển giao được khi Sprint kết thúc. Khi nào có đủ các phần tăng

trưởng cần thiết, và đáp ứng được yêu cầu của các nhà đầu tư thì sản phẩm sẽ

được phát hành (released) tới người dùng.

Hầu hết các tổ chức hiện nay đều có quy trình lập kế hoạch phát hành sản phẩm

của mình, mà trong hầu hết các quy trình này thì phần lập kế hoạch hoàn tất

trước khi bắt đầu quy trình sản xuất và không thay đổi gì sau đó. Trong Scrum,

buổi Họp kế hoạch Phát hành xác lập mục tiêu căn bản và đầu ra khả thi cho quy

trình. Phần này thường chỉ chiếm khoảng 15-20% thời gian so với thời gian mà

một tổ chức dành ra để lập kế hoạch theo kiểu truyền thống. Scrum thực hiện cơ

chế lập kế hoạch thời gian thực (just-in-time planning) thông qua các hộp thời



gian khác như Họp Sơ kết Sprint (Sprint Review), Họp Kế hoạch Sprint (Sprint

Planning), hay việc lập các kế hoạch chi tiết trong các buổi họp Daily Scrum. Về

tổng thể, Scrum có thể mất nhiều thì giờ hơn để lập kế hoạch phát hành so với

phương pháp truyền thống. Việc lập kế hoạch này bao gồm cả việc ước lượng và

sắp thứ tự ưu tiên cho các hạng mục trong Product Backlog cho bản phát hành

sắp tới. Có nhiều kĩ thuật để thực hiện

việc ước lượng này, Scrum không loại

trừ bất kì phương pháp nào mà bạn biết,

miễn là nó hữu ích cho dự án.

Sprint – Phân đoạn nước rút

Mỗi Sprint là một phân đoạn (iteration)

trong quá trình phát triển phần mềm.

Các Sprint được đóng hộp thời gian.

Trong suốt Sprint, ScrumMaster cần đảm bảo không có sự thay đổi nào ảnh

hưởng đến mục tiêu của Sprint. Cả cấu trúc của Đội sản xuất và tiêu chuẩn về

chất lượng cũng không được thay đổi trong suốt Sprint. Sprint bao gồm buổi

Họp lập kế hoạch, Các công việc được thực hiện trong Sprint, Họp Sơ kết Sprint

và Họp Cải tiến Sprint (Sprint Retrospective). Các Sprint nối tiếp nhau, không có

thời gian ngừng nghỉ.

Một dự án thường có một mục đích xác định; trong việc phát triển phần mềm,

mục đích là tạo nên một sản phẩm hay một hệ thống. Mọi dự án đều xác định rõ

những thứ phải làm ra, kế hoạch để làm chúng, các công việc phải làm theo kế

hoạch đã vạch ra, và sản phẩm cuối cùng. Mỗi dự án đều có một tầm nhìn để tạo

một khung thời gian cho dự án. Nếu tầm nhìn quá xa, các mục tiêu có thể thay

đổi, và rất nhiều yếu tố gây nhiễu khác có thể khiến rủi ro có thể trở nên không

thể kiểm soát nổi. Scrum là một khung làm việc cho một án có tầm nhìn không

dài hơn một tháng, vì nếu kéo dài hơn một tháng, độ phức tạp và rủi ro sẽ tăng

lên. Khả năng dự tính của dự án cần được kiểm soát ít nhất mỗi lần trong tháng

để tránh khả năng các yếu tố rủi ro có thể vượt khỏi tầm kiểm soát.

Mẹo

Nếu Đội sản xuất cảm thấy quá tải, có thể

gặp Product Owner để giảm bớt số yêu cầu

cần triển khai. Nếu nhóm thấy mình còn dư

thời gian, có thể trao đổi với Product Owner

để chọn thêm hạng mục trong Product

Backlog để triển khai tiếp trong Sprint.



Sprint có thể bị hủy bỏ trước khi vượt khỏi hộp thời gian của Sprint. Chỉ có

Product Owner mới có đủ thẩm quyền để hủy bỏ một Sprint, mặc dù người đó

không chịu sức ép của bất kì ai như các bên liên quan, Đội sản xuất, hoặc

ScrumMaster. Câu hỏi đặt ra là: trong tình cảnh nào thì Sprint cần phải bị hủy bỏ?

Có thể là khi các hoàn cảnh về thị trường hay công nghệ thay đổi, khiến cho Mục

tiêu Sprint trở nên lỗi thời. Nói chung, Sprint nên bị hủy nếu như nó không có ý

nghĩa gì trong hoàn cảnh đó. Tuy nhiên, do mỗi Sprint chỉ diễn ra trong thời gian

ngắn nên ít khi ta phải làm như vậy.

Khi một Sprint bị hủy, các hạng mục đã hoàn tất được xem xét lại. Chúng sẽ được

chấp nhận nếu như chúng là một gói tăng trưởng có thể chuyển giao được. Tất

cả các hạng mục trong Product Backlog khác được đặt ngược trở lại trong

Product Backlog với ước lượng ban đầu của chúng. Các phần công việc hoàn tất

liên quan đến các hạng mục này coi như mất. Tài nguyên sẽ bị lãng phí khi Sprint

bị dừng, và mọi người phải họp lại để lập kế hoạch và bắt đầu một Sprint mới.

Việc hủy Sprint thường khiến Đội sản

xuất bị sốc, nhưng rất ít khi nhóm phải

trải nghiệm điều này.

Họp Kế hoạch Sprint - Sprint

Planning Meeting

Các cuộc họp Kế hoạch Sprint xảy ra khi

ta lập kế hoạch cho một phân đoạn. Đó

là thời gian đóng hộp đến tám giờ cho một Sprint một tháng. Với các Sprint ngắn

hơn, phân bổ thời gian ít hơn cho việc lập kế hoạch Sprint (ví dụ, Sprint hai tuần

chỉ cần bốn giờ cho họp lập kế hoạch Sprint). Họp kế hoạch Sprint bao gồm hai

phần. Phần đầu tiên để lựa chọn các hạng mục cần hoàn thành trong Sprint. Phần

thứ hai (kéo dài bốn giờ cho một Sprint một tháng) xác định các hành động cần

thiết trong Sprint để xây dựng các phần tăng trưởng cho sản phẩm.

Có thể phân cuộc Họp kế hoạch Sprint thành hai phần đặc trưng: phần “Cái gì” và

phần “Thế nào”. Một số Nhóm Scrum gộp hai phần này làm một. Ở phần đầu

tiên, Nhóm Scrum trả lời cho câu hỏi “Cái gì?”. Ở đây, Product Owner trình bày

Mẹo

Khi bắt đầu với Scrum, Đội sản xuất có thể

chọn Sprint hai tuần để giảm bớt khả năng sa

lầy vào sự bất định. Sprint kiểu này có thể

được đồng bộ hóa với các nhóm khác để cùng

làm ra hai gói tăng trưởng khác nhau.



phần ưu tiên trong Product Backlog cho Đội sản xuất hiểu. Họ cùng hợp tác để

xác định các chức năng cần phải phát triển trong Sprint sắp tới. Đầu vào cho cuộc

họp này chính là Product Backlog và năng lực hiện có của Đội sản xuất. Lượng

Product Backlog mà Đội sản xuất lựa chọn hoàn toàn phụ thuộc vào nhóm với

năng lực xác định của nó. Chỉ Đội sản xuất mới có thể xác định nó có khả năng

làm được những gì trong Sprint sắp tới.

Sau khi lựa chọn được các hạng mục trong Product Backlog, Mục tiêu Sprint

(Sprint Goal) sẽ được hình thành. Mục tiêu này sẽ đóng vai trò như kim chỉ nam

để Đội sản xuất làm ra các gói tăng trưởng cho dự án. Mục tiêu Sprint chính là

một phần của Mục tiêu Phát hành (Release Goal). Ví dụ như một mục tiêu cho

Sprint có thể được phát biểu như:” Tự động hóa việc chỉnh sửa tài khoản của

khách hàng thông qua một middleware với khả năng giao dịch an toàn”. Khi làm

việc, Đội sản xuất cần ghi nhớ mục tiêu này và thực hiện các công việc kĩ thuật

cần thiết để đạt được nó. Nếu công việc khó khăn hơn nhóm dự tính, thì Nhóm

cần hợp tác với Product Owner để phát triển một phần của mục tiêu đó.

Trong phần hai của Họp kế hoạch Sprint, nhóm trả lời câu hỏi “Thế nào?”. Nhóm

sẽ phải chỉ ra làm sao để biến các hạng mục đã được lựa chọn từ Product Backlog

trong phần trước của Họp kế hoạch Sprint thành ra các phần tăng trưởng của dự

án. Đội phát triển thường bắt đầu với việc thiết kế các công việc phải làm. Khi

thiết kế, Đội phát triển sẽ nhận biết các tác vụ phải thực hiện trong suốt Sprint

đó. Các tác vụ này chính là các công việc cụ thể cần thiết để biến Product Backlog

thành ra phần mềm chạy được. Tác vụ cần đủ nhỏ để chúng có thể được hoàn tất

trong vòng một ngày. Danh sách công việc này được gọi là Sprint Backlog.

Nhóm sẽ tự tổ chức để thực hiện các công việc trong Sprint Backlog, cả khi họp

kế hoạch Sprint và khi làm việc trong Sprint.

Product Owner phải hiện diện trong phần hai của Họp kế hoạch Sprint để làm rõ

Product Backlog và giúp đỡ Đội phát triển đưa ra các quyết định tối ưu. Nếu

Nhóm phát triển phát hiện ra có quá ít hay quá nhiều công việc, thì nhóm có thể

thương thảo lại với Product Owner về Product Backlog. Đội sản xuất có thể mời

một số người khác tham gia để cung cấp các trợ giúp về chuyên môn hay công



nghệ nếu thấy cần thiết. Một nhóm mới thường nhận thấy họ có thể bơi hay chết

chìm ngay trong buổi họp đầu tiên này. Nhóm sẽ sớm nhận ra rằng họ phải tự lực

cánh sinh. Và khi biết được điều đó, nhóm sẽ bắt đầu tự tổ chức với đặc thù và

hành động của một nhóm hiệu quả thực sự.

Họp Sơ kết Sprint - Sprint Review

Nhóm tổ chức một buổi họp Sơ kết Sprint (Sprint Review). Đây là một buổi họp

được đóng hộp trong bốn tiếng đối với Sprint một tháng. Với các Sprint ngắn

hơn, thời gian cho Sơ kết có thể rút ngắn lại (ví dụ, với Sprint hai tuần, có thể ta

chỉ cần khung thời gian hai giờ là đủ). Khi Sơ kết, Nhóm Scrum và những người

có liên quan cùng trao đổi về những thứ vừa hoàn thành trong Sprint vừa rồi.

Dựa trên cơ sở đó, cùng với các thay đổi trong Product Backlog khi Sprint diễn ra,

họ có thể cùng hợp tác để xác định những thứ cần phải hoàn tất trong Sprint tiếp

theo. Đây là một buổi họp không trang trọng, nên việc thuyết trình về các chức

năng vừa hoàn tất chỉ để phục vụ cho việc bàn bạc về những gì sẽ làm trong

Sprint tới chứ không phải để báo cáo như các buổi tổng kết thường thấy.

Cuộc họp cần phải có ít nhất các yếu tố sau đây để đảm bảo thành công. Product

Owner nhận biết được những gì đã hoàn thành, những gì chưa. Đội sản xuất thảo

luận những gì đã thành công trong Sprint và có những vấn đề nào phát sinh, và

làm sao để giải quyết các vấn đề đó. Đội sản xuất trình diễn các công việc họ đã

hoàn tất và trả lời các câu hỏi từ những người tham dự cuộc họp. Product Owner

sau đó thảo luận về Product Backlog, ngày dự kiến hoàn thành với nhiều giả định

về tốc độ phát triển của dự án. Toàn bộ nhóm sẽ hợp tác để cùng thấy hiện trạng

của dự án và xác định những công việc cần phải làm trong Sprint tới. Sprint

Review sẽ cung cấp các dữ liệu đầu vào vô cùng quan trọng cho buổi Họp kế

hoạch Sprint (Sprint Planning) tiếp theo.

Họp Cải tiến Sprint - Sprint Retrospective

Ngay sau khi Sơ kết Sprint, và trước khi buổi Họp kế hoạch cho Sprint tiếp theo,

Nhóm Scrum họp Sprint Retrospective. Buổi họp này đóng hộp trong khoảng

thời gian ba giờ đồng hồ cho một Sprint một tháng (phân bổ thời gian hợp lý cho

các Sprint ngắn hơn). Trong cuộc họp này, ScrumMaster khuyến khích Nhóm



Scrum chỉnh sửa lại quy trình trong khuôn khổ của khung làm việc Scrum nhằm

cải tiến quy trình, khiến cho quy trình trở nên hiệu quả hơn và thú vị hơn vào

Sprint sau. Bạn có thể tham khảo rất nhiều tài liệu và sách vở đã được xuất bản

đề cập đến các kĩ thuật hữu ích để thực hiện công tác Retrospective.

Mục đích của Retrospective là để khảo sát kĩ lưỡng tất cả các yếu tố tham gia vào

quy trình trong Sprint vừa qua, bao gồm con người, các mối quan hệ, quy trình và

công cụ. Quá trình khảo sát này cần phải nhận ra và ưu tiên hóa các điểm tốt và

những thứ có thể tốt hơn. Các thứ cần cải tiến gồm cấu trúc của Nhóm Scrum,

việc họp hành, các công cụ, định nghĩa “hoàn thành”, cách thức giao tiếp, và các

quy trình phát triển để chuyển đổi các Product Backlog thành các công việc được

đánh dấu là “hoàn thành”. Kết thúc buổi Sprint Retrospective, Nhóm Scrum phải

xác định được các hành động cải tiến lượng hóa được để tiến hành trong Sprint

sau. Những thay đổi này sẽ trở thành sự thích nghi cho quá trình khảo sát thực

nghiệm (empirical inspection) vừa hoàn tất.

Họp Scrum hằng ngày - Daily Scrum

Đội sản xuất sẽ Họp Scrum hằng ngày (Daily Scrum) trong vòng mười lăm phút

mỗi ngày để triển khai kĩ thuật thanh tra-thích nghi cho các công việc hằng ngày

của mình. Daily Scrum diễn ra ngay tại nơi nhóm làm việc hằng ngày với ba câu

hỏi cho các thành viên của nhóm:

1. Bạn đã làm được những gì kể từ buổi họp trước đến giờ;

2. Bạn sẽ làm gì trước buổi họp tới đây; và

3. Bạn đã gặp phải những trở ngại nào trong khi làm việc.

Daily Scrum sẽ cải thiện sự giao tiếp, giảm thiểu thời gian họp hành khác không

cần thiết, nhận biết và loại bỏ các rắc rối trong quá trình phát tiển, nhấn mạnh và

khuyến khích các quyết định nhanh chóng, và tăng mức độ hiểu biết của tất cả

mọi người về dự án.

ScrumMaster tạo điều kiện để Đội sản xuất họp Daily Scrum thật hiệu quả. Còn

Đội sản xuất phải chịu trách nhiệm về Daily Scrum. ScrumMaster phải dạy cho

Đội sản xuất giữ được sự nhanh gọn của Daily Scrum bằng các quy tắc cần thiết



và đảm bảo mọi người nói vắn tắt đủ hiểu. ScrumMaster cũng phải áp dụng các

quy tắc cho “các chú gà” để đảm bảo chúng không kêu quang quác khiến cuộc

họp bị gián đoạn (Quy tắc: “gà không được kêu”).

Daily Scrum không phải là buổi họp báo cáo trạng thái công việc. Nó không dành

cho ai khác ngoài những người chịu trách nhiệm việc biến đổi Product Backlog

thành ra các gói phần mềm dùng được

(tức Đội sản xuất). Đội sản xuất cần phải

bám sát Mục tiêu Sprint (Sprint Goal) và

Product Backlog để làm việc. Daily

Scrum là phần thanh tra (inspection) trên

tiến trình tiến tới Mục tiêu Sprint. Mục

đích của nó là để tận dụng các khả năng

mà Đội sản xuất có thể đạt được mục

tiêu. Đây là chìa khóa của buổi họp thanh

tra-thích nghi (tức Daily Scrum) trong

quy trình thực nghiệm (empirical

process) Scrum.

Đồ nghề Scrum (Scrum

Artifacts)

Các đồ nghề (artifacts) được dùng trong Scrum gồm có Product Backlog, Release Burndown, Sprint Backlog và Sprint Burndown.

Product Backlog và Release

Burndown

Yêu cầu của khách hàng được liệt kê trong Product Backlog. Product Owner chịu trách nhiệm tạo lập, quản lý và ưu tiên hóa (prioritization) cho các hạng

Mẹo

Các Nhóm Scrum thường bỏ ra 10% thời gian

mỗi Sprint cho việc làm mịn Product Backlog

để đạt tiêu chuẩn của một Product Backlog

tốt. Khi làm mịn, hạng mục Product Backlog

thuộc phần trên (có độ ưu tiên cao nhất, có

giá trị nhất) được tách ra để có thể thực hiện

trong phạm vi một Sprint. Chúng có thể được

phân tích kĩ càng hơn trong quá trình làm mịn

đó. Cho tới khi họp Kế hoạch Sprint, các hạng

mục ưu tiên này đã đủ rõ ràng và dễ dàng

được lựa chọn để đưa vào phát triển.

Mẹo

Trong một số tổ chức, có nhiều phần việc

được thêm vào backlog hơn là các phần việc

đã hoàn thành. Điều này có thể dẫn đến

đường biểu diễn xu hướng trong Burndown đi

lên thay vì đi xuống như thường thấy. Để giải

quyết trường hợp này và để đảm bảo tính

minh bạch, sàn (floor) mới được thiết lập khi

thêm hoặc bớt công việc phải làm. Sàn mới

này cần phải thêm vào hoặc bớt đi các thay

đổi quan trọng, và cần được tài liệu hóa cẩn

thận để tất cả mọi người nắm được.



mục trong Product Backlog. Product Backlog không bao giờ là đầy đủ. Theo đó, các lát cắt ban đầu của nó được đem đi phát triển thường là phần rõ ràng hơn cả. Product Backlog sẽ tiến hóa trong quá trình phát triển sản phẩm và theo kịp sự thay đổi của tình hình thực tiễn. Product Backlog là một thực thể động, nó biến đổi liên tục để thể hiện cho được điều gì thực sự là cần thiết, phù hợp, có tính cạnh tranh và hữu ích. Product Backlog còn tồn tại chừng nào sản phẩm tồn tại.

Product Backlog chứa tất cả những thứ cần thiết phải phát triển và tạo thành một sản phẩm thành công. Nó chứa danh sách tất cả các tính năng, chức năng, công nghệ, các cải tiến, sửa lỗi cần phải thực hiện để làm thành sản phẩm trong lần phát hành (release) tới đây. Các hạng mục (Product Backlog item) trong Product Backlog thường được viết ra với các thuộc tính như: mô tả, độ ưu tiên và ước lượng. Độ ưu tiên được xác định dựa trên các yếu tố như rủi ro, giá trị, và mức độ cần thiết của yêu cầu. Ta có thể dùng nhiều kĩ thuật để đánh giá các thuộc tính này. Product Backlog được sắp xếp dựa trên mức ưu tiên (priority). Phần ưu tiên cao nhất trong Product Backlog sẽ trực tiếp được đưa vào quá trình phát triển. Càng có độ ưu tiên cao hơn thì mức độ quan tâm tới phần Product Backlog đó càng phải khẩn trương và kĩ càng hơn; cũng như độ nhất trí về giá trị của phần đó sẽ cao hơn. Các hạng mục có độ ưu tiên cao thì rõ ràng và được mô tả chi tiết hơn so với các mục có độ ưu tiên thấp. Khi đó, việc ước lượng đối với các hạng mục này sẽ chính xác hơn. Đối với các hạng mục ưu tiên thấp, thì thông tin sẽ ít hơn, cho tới khi bạn bỏ công tìm hiểu kĩ hơn về chúng. Khi sản phẩm được đem ra sử dụng, giá trị của nó sẽ tăng lên, và khi thị trường có những phản hồi đối với sản phẩm, thì các hạng mục trong Product Backlog sẽ tăng dần. Yêu cầu thì không ngừng thay đổi. Product Backlog là một tài liệu sống do nó liên tục được cập nhật để phản ánh các thay đổi trong yêu cầu nghiệp vụ, điều kiện thị trường, công nghệ hay thay đổi nhân sự trong dự án. Để giảm thiểu việc phải làm lại các thứ đã mất công tạo ra, chỉ các mục có độ ưu tiên cao nhất

Mẹo

Kiểm thử chấp nhận (Acceptance Test)

thường là một trong số các thuộc tính quan

trọng được mô tả trong mỗi hạng mục

Product Backlog. Chúng cho biết chi tiết về

việc sản phẩm phải đạt được tiêu chí gì để

người dùng chấp nhận khi chức năng (hay

sản phẩm) được hoàn tất.



được đem ra phân tích kĩ. Còn lại, các hạng mục mà ta dự định sẽ triển khai trong các Sprint sau này sẽ được phân tách kĩ sao cho mỗi hạng mục có thể được hoàn thành trong phạm vi một Sprint.

Nhóm Scrum thường chỉ làm việc trên cùng một sản phẩm. Mỗi Product Backlog được dùng để mô tả công việc sắp tới cho sản phẩm đó. Căn cứ trên tính chất của các hạng mục trong Product Backlog mà ta có thể nhóm chúng lại với nhau. Việc phân loại này có thể căn cứ theo tập các tính năng, công nghệ, kiến trúc. Đó cũng là cách mà các Nhóm Scrum dùng để tổ chức công việc của mình. Biểu đồ Release Burndown ghi lại tổng số nỗ lực (effort) ước tính cho các hạng mục còn lại trong Product Backlog qua thời gian. Các nỗ lực được ước lượng có thể được đo bằng nhiều loại đơn vị khác nhau tùy quyết định từng Nhóm Scrum hoặc tổ chức. Đơn vị về thời gian thường chỉ dùng cho các Sprint. Ước tính (estimate) cho các hạng mục trong Product Backlog được tính toán lần đầu trong Release Planning (Họp kế hoạch Phát hành) khi Product Backlog được tạo ra. Sau đó, các mục này thường xuyên được đánh giá lại (thao tác này gọi là Product Backlog grooming – làm mịn Product Backlog). Do đó, các ước lượng này sẽ thường xuyên được cập nhật trong dự án. Đội sản xuất chịu trách nhiệm cho việc thực hiện ước tính cho tất cả các hạng mục trong quá trình làm việc. Product Owner chỉ có thể gây ảnh hưởng lên nhóm bằng cách giúp họ hiểu thêm và lựa chọn các phương án tối ưu phù hợp với thực tiễn, còn quyết định cuối cùng về các giá trị ước lượng hoàn toàn phụ thuộc vào Đội sản xuất. Product Owner cần phải đảm bảo cho chi tiết về việc cập nhật Product Backlog hay Release Backlog Burndown luôn luôn được công khai tại mọi thời điểm. Một đồ thị biểu diễn xu hướng của dự án dựa trên sự thay đổi về lượng công việc còn lại phải làm có thể được vẽ ra để mọi người tiện theo dõi tiến độ của dự án.

Sprint Backlog và Sprint Burndown

Mẹo

Đường vẽ xu hướng có thể không đáng tin

cậy lắm trong một hai Sprint đầu tiên, trừ khi

Nhóm đã làm việc với nhau từ trước, hiểu

biết tốt về sản phẩm và tường tận công nghệ

được sử dụng.



Sprint Backlog chứa danh sách các công việc mà Đội sản xuất cần thực hiện để chuyển đổi các hạng mục Product Backlog thành phần tăng trưởng được xác nhận là “hoàn thành”. Rất nhiều các tác vụ đó được thiết lập ngay trong buổi Họp kế hoạch Sprint. Sprint Backlog chính là tất cả các công việc mà Đội sản xuất phải làm việc trong suốt Sprint đó để đạt đến Mục tiêu Sprint. Công việc được liệt kê trong Sprint Backlog phải được tách nhỏ để tiện theo dõi sự thay đổi trong quá trình làm việc (ví dụ để báo cáo và theo dõi trong Daily Scrum). Công việc sau khi phân tách nên có ước lượng không nên dài quá một ngày.

Đội sản xuất chỉnh sửa Sprint Backlog trong suốt Sprint. Khi một thành viên Đội sản xuất lựa chọn nhiệm vụ để thực hiện, thành viên đó có thể nhận thấy mình phải làm nhiều tác vụ khác, hoặc thời gian cần thiết có thể nhiều hơn dự tính ban đầu. Khi có tác vụ mới, nhóm thêm nó vào trong Product Backlog. Khi có ai đó chọn một việc để làm, thì trạng thái của nó (đang làm hay đã hoàn tất) và thời gian ước tính còn lại (estimated remaining work) phải được cập nhật liên tục. Khi có tác vụ nào đó là không cần thiết nữa, Nhóm có thể loại bỏ nó khỏi danh sách công việc. Chỉ có Đội sản xuất mới có quyền chỉnh sửa Sprint Backlog trong khi Sprint diễn ra. Chỉ có họ mới đủ quyền để cập nhật các ước lượng trong đó. Sprint Backlog cần phải được công khai. Nó là bản kế hoạch thời gian thực về công việc mà nhóm làm việc trong Sprint, và nó chỉ thuộc về Đội sản xuất. Sprint Burndown là biểu đồ thể hiện lượng công việc còn lại trong một Sprint qua thời gian. Để tạo biểu đồ này, ta tính tổng các ước lượng cho mỗi công việc hằng ngày trong Sprint. Các số liệu về ước lượng đó được lấy từ Sprint Backlog. Hằng ngày ta tính lại các số liệu và cập nhật lại đồ thị để thấy được lượng công việc còn lại qua thời gian. Dựa vào đó, ta có thể quản lý tiến độ công việc trong Sprint. Trong Scrum, thời gian đã bỏ ra khi làm việc không được quan tâm.Thay vì đó, Scrum chỉ để ý tới lượng công việc còn lại và bao nhiêu ngày còn lại để làm việc. Một trong những quy tắc để đảm phải mục đích của mỗi Sprint là việc tuân thủ Định nghĩa về “Hoàn thành”. Tất cả các mục được đánh dấu là “hoàn thành” đều phải phù hợp tiêu chuẩn được định nghĩa từ trước.

Hoàn thành (hay Xong - Done)

Scrum yêu cầu các nhóm phải làm ra các phần tăng trưởng (increment) hoàn chỉnh của sản phẩm ở cuối mỗi Sprint. Đây là gói có thể chuyển giao được (shippable) cho Chủ sản phẩm (Product Owner). Muốn vậy, mỗi phần đó phải thực sự là một phần của sản phẩm cuối cùng. Chúng phải thỏa mãn định nghĩa



“hoàn thành” của nhóm. Mỗi phần tăng trưởng cần phải tích hợp được với các phần trước đó, được kiểm thử tích hợp (integration test) cẩn thận; và chúng phải làm việc suôn sẻ với nhau như một khối thống nhất. Trong quá trình phát triển sản phẩm, cần lưu ý rằng chức năng được gọi là “hoàn thành” thường có nghĩa là được viết code sạch (cleanly coded), tái cấu trúc cẩn thận, kiểm thử mức đơn vị (unit test), build, và kiểm thử chấp nhận. Một số người khác có thể chỉ nghĩ rằng “hoàn thành” có nghĩa là có code và chức năng chạy được là đủ. Nếu tất cả mọi người không cùng hiểu “hoàn thành” theo cùng một cách thì mô hình quản lý thực nghiệm của Scrum sẽ bị vô hiệu hóa. Khi ai đó trong nhóm gọi một cái gì đó là “hoàn thành” thì những người khác cần phải biết rất rõ “hoàn thành” như thế nghĩa là như thế nào. Định nghĩa “hoàn thành” xác định những điều mà Đội phát triển sẽ phải tuân thủ khi thực thi một nhiệm vụ trong Sprint. Một số sản phẩm không cần phải tài liệu hóa, vì thế Định-nghĩa-hoàn-thành có thể không có việc phải tài liệu hóa chức năng vừa viết ra. Một gói phần mềm được nói là “hoàn toàn xong” nếu như tất cả chức năng trong đó đã được phân tích, thiết kế, tái cấu trúc, lập trình, tài liệu hóa và kiểm thử. Việc kiểm thử có thể bao gồm nhiều mức độ khác nhau: đơn vị (unit), hệ thống, người dùng, kiểm thử hồi quy (regression test), hay kiểm thử phi chức năng như hiệu năng (performance test), độ ổn định (stability), bảo mật, và tích hợp. Định-nghĩa-hoàn-thành có thể bao gồm cả việc quốc tế hóa sản phẩm nữa. Một số Đội sản xuất không có khả năng thực hiện tất cả các hạng mục trong Định-nghĩa-xong đó do hạn chế về năng lực kĩ thuật hoặc một nguyên nhân khách quan khác. Điều này cần phải được thông báo cho Product Owner biết. Đó là các công việc phải hoàn thành trước khi sản phẩm có thể bắt đầu được xây dựng và đưa vào sử dụng.

Lời cuối

Một số tổ chức không thể làm ra một phần tăng trưởng hoàn chỉnh có thể chuyển

giao được trong một Sprint. Họ có thể không có hạ tầng kiểm thử tự động để

hoàn thành tất cả các công việc kiểm thử. Trong trường hợp này, có hai loại công

việc: phần “đã xong” và phần “chưa xong”. Phần việc chưa xong cần phải được

hoàn tất trong thời gian sau đó. Product Owner biết chắc chắn sẽ phải khảo sát

cái gì ở cuối mỗi Sprint bởi đó là người nắm rất rõ thế nào là “hoàn thành”. Phần



chưa xong sẽ được đưa ngược trở lại Product Backlog với tên gọi “công việc

chưa xong” (undone) và biểu đồ tương ứng sẽ được thể hiện đúng trên Release

Burndown. Kĩ thuật này tạo ra sự minh bạch trong tiến trình tiến tới phát hành.

Kĩ thuật Thanh tra – Thích nghi trong Sprint Review phải đảm bảo tính minh bạch

giống như vậy.

Ví dụ như nếu một Đội sản xuất không thể thực hiện các công việc kiểm thử hiệu

năng, hồi quy (regression), ổn định, bảo mật hay tích hợp cho mỗi hạng mục

trong Product Backlog, thì phần công việc cũng có thể tính là xong (tức là đã qua

phân tích, thiết kế, tái cấu trúc, lập trình, tài liệu hóa, kiểm thử đơn vị và mức

người dùng). Giả sử có sáu phần việc là xong, bốn phần là chưa; thì có nghĩa là

Đội sản xuất đã hoàn thành sáu hạng mục Product Backlog , còn lại bốn hạng

mục kia sẽ được đánh dấu là “chưa xong” trong Product Backlog vào cuối Sprint.

Qua nhiều Sprint, phần việc “chưa xong” cho mỗi phần tăng trưởng được gom lại

và phải được xử lý trước khi phát hành sản phẩm ra thị trường. Các phần công

việc này thường được tích tích lũy kiểu tuyến tính, nhưng đôi khi chúng tích lũy

theo hàm mũ. Khi đó Release Sprint được tạo ra để làm nốt các công việc “chưa

xong” này. Số lượng Sprint là không thể đoán được nếu như các phần công việc

“chưa xong” ấy cứ tích lũy phi tuyến qua các Sprint.



Phụ lục – Thuật ngữ Scrum

Agile Software Development – Phát triển phần mềm linh hoạt

Một họ các phương pháp phát triển phần mềm dựa theo các giá trị và nguyên

tắc được định nghĩa bởi AgileAlliance.org.

Burndown Chart – Biểu đồ Burndown (đốt cháy)

Là biểu đồ thể hiện xu hướng của công việc còn lại theo thời gian trong một

Sprint, một bản phát hành (release), hoặc sản phẩm. Dữ liệu cho Burndown

Chart được lấy từ Sprint Backlog và Product Backlog, với công việc còn lại

được theo dõi trên trục tung và khoảng thời gian (các ngày trong một Sprint,

hoặc nhiều Sprint) theo dõi trên trục hoành. Biểu đồ Burndown được dùng

cho Bản phát hành (khi đó gọi là Release Burndown) hoặc cho Sprint (gọi là

Sprint Burndown).

Chicken - Gà

Một người nào đó quan tâm đến dự án nhưng không có trách nhiệm trong dự

án (không giữ các vai trò Đội sản xuất, Product Owner hay ScrumMaster).

Daily Scrum – Buổi họp Scrum hằng ngày

Một cuộc họp ngắn được tổ chức hàng ngày của mỗi Đội sản xuất. Trong thời

gian đó, các thành viên của nhóm rà soát công việc của mình, đồng bộ hóa

công việc với người khác và báo cáo tiến độ công việc cũng như các vấn đề

gặp phải để cùng nhau giải quyết. Đội sản xuất và ScrumMaster có thể phải

tiến hành các hoạt động tiếp nối (follow-up) Daily Scrum để thích ứng với tình

hình sắp tới tối tưu hóa Sprint.

Done – Hoàn thành

Định nghĩa về sự hoàn thành (Done Definition, hay gọi tắt là Done – Hoàn

thành) được đồng thuận giữa tất cả các bên và phù hợp với tiêu chuẩn, quy

ước của tổ chức cũng như các chỉ dẫn khác. Khi một công việc được ghi nhận



là “hoàn thành" tại cuộc họp Sơ kết Sprint, nó phải phù hợp với định nghĩa về

sự hoàn thành này.

Estimated Work Remaining (Công việc ước tính còn lại)

Số giờ mà một thành viên của nhóm ước lượng để thực hiện một công việc

nào đó. Ước lượng này được cập nhật hằng ngày khi thành viên đó thực hiện

công việc trong Sprint Backlog. Đây là con số ước tính tổng số giờ còn lại để

hoàn thành công việc, không kể đến số lượng người thực hiện công việc hay

số giờ đã bỏ ra cho công việc ấy trong quá khứ.

Empirical Process Control – Quản lý tiến trình thực nghiệm

Đây là phương pháp quản lý các tiến trình (process) không dựa trên giả định

và tính toán lý thuyết (Predictive management) mà dựa trên các khảo sát kĩ

lưỡng và thích nghi với các biến động trên thực tiễn.

Increment – Phần tăng trưởng

Là phần tăng trưởng của sản phẩm được phát triển bởi Đội sản xuất trong mỗi

Sprint. Đôi khi increment được dịch gần đúng là “gói phần mềm”, hay đơn

giản là gói.

Increment of Potentially Shippable Product Functionality – Phần tăng

trưởng hoàn chỉnh chuyển giao được

Một phần nhỏ nhưng hoàn chỉnh của sản phẩm tổng thể hoặc hệ thống có thể

được sử dụng bởi chủ sở hữu sản phẩm hoặc các bên liên quan.

Iteration – Phân đoạn

Trong các phương pháp phát triển linh hoạt, iteration chỉ một phân đoạn với

khoảng thời gian ngắn nhằm phát triển một phần nhỏ của hệ thống. Một dự

án sẽ gồm nhiều phân đoạn lặp đi lặp lại.

Sprint – Phân đoạn nước rút

Một phân đoạn (iteration) trong Scrum; là một chu kỳ phát triển nhằm tạo ra

các phần tăng trưởng cho hệ thống. Sprint thường kéo dài từ một tuần tới



một tháng.Trong suốt dự án, thời gian cho một Sprint là cố định. Từ “sprint”

có nghĩa là giai đoạn nước rút, ám chỉ sự gấp gáp và tập trung cao độ trong

khoảng thời gian ngắn để làm việc.

Pig – lợn

Một người nào đó thực hiện một trong ba vai trò của Scrum (Đội sản xuất,

Product Owner hoặc ScrumMaster), người đã có những cam kết và có quyền

để thực hiện cam kết của mình.

Product Backlog

Một danh sách ưu tiên của các yêu cầu với thời gian ước tính để biến chúng

thành các tính năng hoàn chỉnh của sản phẩm. Các hạng mục được ưu tiên

hơn trong Product Backlog được ước lượng cẩn thận hơn, và thường chính

xác hơn các phần khác. Danh sách này có thể thay đổi khi có sự thay đổi trong

điều kiện kinh doanh hoặc công nghệ. Trong tiếng Anh, backlog có nghĩa là

phần việc tồn đọng, cần phải giải quyết.

Product Backlog Item – Hạng mục Product Backlog

Một yêu cầu chức năng hay phi chức năng, và các vấn đề được sắp độ ưu tiên.

Độ chính xác của ước lượng phụ thuộc vào tầm quan trọng và độ chi tiết của

hạng mục đó. Phần có độ ưu tiên cao nhất sẽ được chọn trong Sprint tiếp

theo để làm việc.

Product Owner – Chủ Sản phẩm

Một trong ba vai trò của Nhóm Scrum. Là người chịu trách nhiệm quản lý

Product Backlog để tối đa hóa giá trị của dự án. Chủ sở hữu sản phẩm có trách

nhiệm đại diện cho lợi ích của tất cả mọi người có quyền lợi trong dự án và sản

phẩm được tạo ra sau dự án.

Release – Bản phát hành

Là sản phẩm đầy đủ các chức năng theo yêu cầu của chủ sản phẩm, có khả

năng bán ra thị trường hay chuyển tới người dùng.



Scrum (trong môn bóng bầu dục)

Đây không không phải là từ viết tắt, mà là cơ chế trong trò chơi bóng bầu dục

để đưa “bóng chết” vào cuộc chơi. Từ “scrum” có nghĩa là chen lấn, hàm ý sự

hỗn độn, liên chức năng và tự quản cao độ trong các tình huống thực tiễn.

ScrumMaster

Là một trong ba vai trò của Nhóm Scrum; là người chịu trách nhiệm cho quy

trình Scrum, bao gồm việc triển khai đúng quy tắc, và tối hóa lợi ích từ Scrum.

Sprint Backlog

Danh sách các nhiệm vụ xác định công việc của nhóm trong một Sprint. Danh

sách này được cập nhật trong suốt Sprint. Nhóm tự quản lý Sprint Backlog

bằng việc cập nhật trạng thái thực thi các nhiệm vụ với người chịu trách

nhiệm và thời gian còn lại để hoàn tất công việc tính tới thời điểm cập nhật.

Sprint Backlog Task – Công việc trong Sprint Backlogs

Một trong những nhiệm vụ mà nhóm hoặc một thành viên xác định theo yêu

cầu để chuyển đổi các yêu cầu trong Product Backlog thành chức năng của hệ

thống.

Sprint Planning meeting – Họp Kế hoạch Sprint

Cuộc họp diễn ra trong phạm vi tám giờ đồng hồ để khởi động mỗi Sprint.

Họp lập kế hoạch được chia thành hai phân đoạn bốn giờ.Trong bốn giờ đầu

tiên Product Owner trình bày các yêu cầu có độ ưu tiên cao nhất cho nhóm

phát triển. Nhóm và Product Owner sẽ kết hợp để xác định số lượng các hạng

mục sẽ được chọn để tiến hành phát triển trong Sprint tới. Sau bốn giờ đầu

tiên, Nhóm và Product Owner xác định mục tiêu của Sprint sắp tới. Trong suốt

bốn giờ thứ hai của cuộc họp, Nhóm lập kế hoạch để đạt được mục đích của

Sprint bằng các kĩ thuật phân tích và thiết kế cần thiết, và sau đó ghi lại chi tiết

công dưới dạng một bản kế hoạch có tên Sprint Backlog.

Sprint Review meeting - Họp Sơ kết Sprint



Đội sản xuất cùng với Product Owner đánh giá lại công việc của Sprint vừa kết

thúc. Trong khi đánh giá, Đội sản xuất trình bày các phần việc đã hoàn tất, các

chức năng đã hoàn thành; lắng nghe các phản hồi từ Product Owner và thảo

luận về các chỉnh sửa (nếu có) sẽ thực hiện trong Sprint tiếp theo.

Sprint Retrospective meeting - Họp Cải tiến Sprint

Trong phạm vi ba giờ, ScrumMaster sẽ tổ chức cho nhóm thực hiện công việc

khảo sát lại toàn bộ quy trình làm việc của Sprint vừa qua để tìm ra các cải tiến

trong Sprint tới, nhằm mang lại hiệu suất cao hơn cho nhóm.

Stakeholder – người liên quan

Người có sự quan tâm đến kết quả của một dự án (có tài trợ cho nó, sẽ sử

dụng, hoặc sẽ bị ảnh hưởng bởi sản phẩm tạo ra từ dự án).

Team – Đội sản xuất

Một nhóm liên chức năng (cross-functional) tự quản lý để tiến hành chuyển

đổi các Product Backlog item thành chức năng của hệ thống.

Time box - Hộp thời gian

Là khoảng thời gian tối đa dành cho một hoạt động nào đó trong Scrum. Khi

nói Daily Scrum là đóng hộp trong mười lăm phút thì có nghĩa là Đội dự án

không thể dùng quá mười lăm phút cho cuộc họp hằng ngày Daily Scrum. Các

Hộp thời gian trong Scrum có thể kể đến là Release Planning, Sprint Planning,

Sprint, Daily Scrum, Sprint Review và Sprint Retrospective.

scrum guide - hanoi scrumhanoiscrum.net/hnscrum/images/resource/scrum guide_vi_beta_tan.pdf ·...

Documents