Giả lập qui trình Scrum với trò chơi LEGO

Một trò chơi đa nhóm, chu trình đầy đủ, hướng sản phẩm

Giả lập qui trình Scrum với trò chơi LEGO
Phiên bản dành cho nghiệp vụ vừa và nhỏ
Có thể được dùng để dạy các framework phát triển linh động dựa trên lặp khác

Bài báo gốc được xuất bản vào tháng 2 năm 2009
Tác giả Alexey Krivitsky
Phiên bản hiện tại 2.0, tháng 10 năm 2011

Sản phẩm này được phân phối dưới giấy phép của
Createive Common Attribution 3.0 Unported License


Mục lục
LỜI TỰA ............................................................................................................................................................................... 4
Tại sao lại là giả lập Lego? ...................................................................................................................................... 4
LỜI CẢM ƠN................................................................................................................................................................. 5
PHIÊN BẢN HIỆN TẠI................................................................................................................................................. 5
BẢN QUYỀN CỦA TRÒ CHƠI.................................................................................................................................. 5
CỘNG ĐỒNG MẠNG VÀ DỰ ÁN CHUYỂN NGỮ ............................................................................................ 6
TRÒ CHƠI ........................................................................................................................................................................... 6
THỜI LƯỢNG, KÍCH THƯỚC NHÓM, VẬT DỤNG ........................................................................................... 6
CÁC VAI TRÒ ................................................................................................................................................................ 7
Product owner......................................................................................................................................................... 7
Scrum Masters......................................................................................................................................................... 7
Thành viên của nhóm ........................................................................................................................................... 7
Kiểm chứng viên – Vai trò tùy chọn................................................................................................................ 7
Không cho phép người quan sát ..................................................................................................................... 7
CẦN QUAN SÁT CÁI GÌ............................................................................................................................................. 8
Hành vi ....................................................................................................................................................................... 8

Phong cách giao tiếp............................................................................................................................................ 8
Tiến trình hỏng ....................................................................................................................................................... 8
CÁC GIAI ĐOẠN CỦA TRÒ CHƠI .......................................................................................................................... 8
TRƯỚC KHI CHƠI: Tổ chức nhóm .................................................................................................................... 9
TRƯỚC KHI CHƠI: Xác định phạm vi dự án ................................................................................................. 9
TRƯỚC KHI CHƠI: Xây dựng backlog.......................................................................................................... 10
TRƯỚC KHI CHƠI: Ước lượng......................................................................................................................... 11
TRÒ CHƠI: Lên kế hoạch Sprint..................................................................................................................... 13
Trò chơi: Lên kế hoạch ...................................................................................................................................... 15
Trò chơi: Xét duyệt ............................................................................................................................................. 15
Trò chơi: Chu trình Release ............................................................................................................................. 16
Hậu trò chơi: Tóm tắt ........................................................................................................................................ 17


CÁC BIẾN THỂ ........................................................................................................................................................... 18
Scrum trong doanh nghiệp ................................................................................................................................. 18
Bạn có biến thể của riêng mình? Hãy cho chúng tôi biết. ....................................................................... 18
XIN CẢM ƠN! ............................................................................................................................................................ 18


LỜI TỰA
Tại sao lại là giả lập Lego?
Trong hơn vài năm qua, tôi đã đồng huấn luyện hơn chục lớp Scrum để cấp giấy chứng nhận lẫn
không cấp giấy chứng nhận. Tất cả các lớp này có các phiên giả lâp khác nhau, nhưng tôi luôn
cảm thấy nên có những lớp tốt hơn.

Ở bên dưới tôi liệt kê các đặc điểm của một trò chơi tối thiểu dùng Lego nên có, theo ý kiến của
tôi.
1. Các backlog mở giúp gợi mở ý tưởng hơn là các chỉ dẫn chi tiết để đi theo
Chúng ta muốn bắt đầu một trò chơi với một backlog mở - một lời mời để cộng tác giữa khách

hàng và nhóm phát triển.
Backlog có thể được chuẩn bị bởi những người huấn luyện, nhưng chúng không nên quá gần
hoặc quá chính xác như là “Hãy làm cái này, rồi làm cái này”. Điều này nghe có vẻ giống như
việc ra lệnh và điều khiển theo kiểu cũ.
Chúng ta muốn dạy và minh họa một kiểu quan hệ hoàn toàn khác giữa khách hàng và các
nhóm.
2. Để tâm vào phát triển sản phẩm hơn là một chuỗi các tác vụ phải hoàn thành
Chúng ta cần dạy cách phát triển sản phẩm, không phải quản lí vi mô ở mức tác vụ.
Vì vậy, backlog hoặc các chỉ dẫn không nên bao gồm một chuỗi các công việc, thay vì vậy nó
nên cung cấp một tầm nhìn cho sản phẩm, một thứ gì đó lớn mà nhóm sẽ phải tạo ra.
3. Nhóm cộng tác hướng về thành công chung hơn là cạnh tranh vì điểm
Trò chơi nên được thiết kế để mở rộng được cho lớp học từ 20 người hoặc hơn. Dĩ nhiên, điều
này sẽ dẫn đến việc chia ra thành các nhóm nhỏ. Tuy nhiên cũng có thể xem đây là một cơ hội
để luyện tập các kĩ năng cộng tác giữa các nhóm.
Việc này cần được thực hiện một cách có chủ đích, với nếu không có chỉ dẫn cụ thể, lẽ tự nhiên
là các nhóm sẽ bắt đầu cạnh tranh với nhau.
4. Các độ đo hữu ích để đánh giá lợi ích của mô hình phát triển linh động hơn là các bảng
biểu mà người huấn luyện yêu cầu thu thập.
Tất cả các độ đo mà người huấn luyện yêu cầu người tham gia thu thập đều cần phải có một lợi
ích hiển nhiên cho cả nhóm, vì tất các các trò chơi cần phải dạy họ làm chủ tiến trình của mình.
5. Liên tục cải tiến với việc thắng và thua trò chơi chỉ với một lần thử


Trò chơi nên được thiết kế sao cho các nhóm có thể thử nhiều lần. Mỗi lượt chơi nên tạo ra các
bài học tự rút ra và giúp sinh viên tìm ra các tiến trình tốt hơn.

LỜI CẢM ƠN
Mykola Gurov, người đã giúp tôi vào đầu năm 2009 nhận ra tiềm năng của bộ trò chơi LEGO
như là một API trong việc giả lập phát triển sản phẩm.
Cuối năm đó, tôi tạo ra một phiên bản đầu tiên của trò chơi gọi là “LEGO dành cho giả lập

Scrum mở rộng” sau khi thảo luận các ý tưởng với William Wake, Jurgen De Smet, Yves Hanoulle
và Xavier Quesada Allue.
Kể từ lần xuất bản đầu tiên trên trang web Liên minh Scrum, tôi đã nhận được hàng tá email
cảm kích về việc này. Bây giờ đến lượt mình, tôi muốn sử dụng cơ hội này để cảm ơn tất cả mọi
người đã liên lạc với tôi để chia sẻ các ý tưởng và kinh nghiệm khi thực hiện các giả lập.
Gerry Kirk, Tim Yevgrashyn, Steve Rogalsky, Andriy Yevtushenko, Geoff Watts, Laurent
Godé, Radu Davidescu, Martine Devos, Jo Newcombe Cook, Jakob Frandsen Martin
Muntzing, Ola Ellnestam, Dusan Kocurek, Danny (Danko) Kovatch, Gustavo Quiroz, Jukka
Lindström, Eduardo Bregaida, and Nathaniel Cadwell.
Tôi muốn gởi lời cảm ơn đặc biệt tới Robin Dymond và Sergey Dmitriev vì đã để tôi dùng trò
chơi này trong các lớp học cấp chứng chỉ Scrum Master của họ.

PHIÊN BẢN HIỆN TẠI
Kể từ khi bài báo đầu tiên được xuất bản năm 2009, hàng tá các nhà huấn luyện đã thử trò chơi
này. Phiên bản hiện tại đã được cải tiến của trò chơi mô phỏng được mô tả trong bài báo này
phản ánh các phản hồi và các quan sát.

BẢN QUYỀN CỦA TRÒ CHƠI
Trò chơi này được phân phối dựa trên giấy phép Creative Common Attribution 3.0 Unported
License.
Giấy phép này cho phép người khác phân phối, pha trộn, tinh chỉnh và tạo ra sản phẩm dựa trên
kết quả công việc của bạn, thậm chí thương mại hóa, miễn là họ ghi nhận bạn là người tạo ra
nguyên bản. Đây là giấy phép dễ dãi nhất được đề nghị, được khuyến khích nhằm tối đa hóa sự
phổ biến và sử dụng các tài nguyên có bản quyền.


CỘNG ĐỒNG MẠNG VÀ DỰ ÁN CHUYỂN NGỮ
Chúng tôi quyết định tạo ra một nơi mà những người yêu thích việc dạy Scrum với LEGO có thể
đến và cộng tác với nhau.
www.lego4scrum.com – Hãy gia nhập cộng đồng và giúp chúng tôi lan truyền lời này.

Một trong số các dự án đang được tiến hành của cộng đồng là dịch bài báo này thành các ngôn
ngữ khác trên thế giới. Hãy kiểm tra trạng thái hiện tại và xem xét việc giúp đỡ chúng tôi. Chúng
tôi thật sự cảm kích nỗ lực của bạn.

TRÒ CHƠI
THỜI LƯỢNG, KÍCH THƯỚC NHÓM, VẬT DỤNG
Trò chơi đã được chứng minh là có thể thay đổi để tương thích với các nhu cầu riêng biệt từ
phía các huấn luyện viên và phục vụ nhiều kích cỡ khán giả khác nhau.
Một trò chơi tiêu chuẩn được mô tả bên dưới, nhưng bạn được khuyến khích thay đổi để phù
hợp với nhu cầu của riêng bạn.
Thời gian: 100-120 phút.



100 phút - khi sử dụng kĩ thuật ước lượng nhóm nhanh
120 phút - khi sử dụng planning poker hoặc công cụ ước lượng khác

Kích thước nhóm: 4-25 người



Lí tưởng là từ 2-3 nhóm, mỗi nhóm từ 4-6 người (khoảng 8-18 người)
Có thể mở rộng ra cho Scrum Masters

Hộp LEGO: Một hộp LEGO cho mỗi nhóm từ 4-6 người



Tôi sử dụng bộ “Basic Brick Set #6177”
Cần khoảng bốn hộp cho mỗi 20 người

Văn phòng phẩm: bộ đào tạo tiêu chuẩn



Miếng dán sticker, bảng đứng dùng kẹp giấy trình bày, bút để ghi
Thẻ poker dùng để lên kế hoạch (hoặc tự làm bằng tay)

Chuẩn bị phòng: một bàn cho mỗi nhóm 4-6 người


Không gian thêm (một bàn hoặc khoảng trống trên sàn) cho sản phẩm được tích hợp sẽ
tốt hơn.


CÁC VAI TRÒ
Product owner
Huấn luyện viên sẽ đóng vai trò Product Owner.
Mục tiêu là minh họa cách cư xử của Product Owner, học thường mong đợi và yêu cầu điều gì,
các hành vi nào của nhóm mà họ đánh giá cao và hành vi nào thì không.

Scrum Masters
Trò chơi này có thể được chơi mà không có Scrum Masters.
Thỉnh thoảng tôi cũng có Scrum Masters trong trò chơi bằng cách mời các đồng hướng dẫn.
Một lựa chọn khác là bạn yêu cầu nhóm chọn Scrum Masters.
Bằng việc dùng các người trợ giúp có kĩ năng tốt đóng vai trò Scrum Masters – người mà vốn
liên tục tập trung vào tiến trình – và là một huấn luyện viên toàn diện, đóng vai trò liên quan
đến nghiệp vụ, ta sẽ khiến trò chơi trở nên tự nhiên hơn và thành một hoạt động dễ dàng.

Thành viên của nhóm

Các sinh viên khác sẽ là thành viên của nhóm

Kiểm chứng viên – Vai trò tùy chọn
Bạn có thể có các kiểm chứng viên trong nhóm. Trách nhiệm chính của họ là giúp các nhóm
hoàn thiện tài liệu thống nhất về yêu cầu và thiết kế để thực hiện kiểm chứng chấp nhận.
Mặt trái của việc này mà tôi đã từng được trải nghiệm là thay vì xây dựng cái gì đó từ bộ LEGO,
các kiểm chứng viên chỉ quan sát chất lượng của sản phẩm. Vì mục đích của các trò chơi như vầy
là để học thông qua thực tập làm cái gì đó, tôi nghĩ sẽ có ý nghĩa hơn nếu khuyến khích mọi
người tham gia vào tiến trình xây dựng.

Không cho phép người quan sát
Trò chơi này khi chơi sẽ mang lại nhiều niềm vui đến độ người quan sát sẽ mất nhiều hơn là
được theo quan điểm của tôi. Tuy nhiên tôi muốn nghe các câu chuyện ở mặt tích cực về
chuyện này từ bạn.


CẦN QUAN SÁT CÁI GÌ
Hành vi
Từ quan sát của tôi, các hành vi nhất định của con người minh họa trong trò chơi này là hình
chiếu của thói quen làm việc. Và dưới áp lực con người có xu hướng quay lại với các hành vi bản
chất của mình.
Trò chơi này được thiết kế gây ra áp lực một cách có chủ đích, vì nó sẽ giúp bộc lộ các thói quen
xấu mà có thể gây hại tới việc áp dụng mô hình phát triển linh động. Mục tiêu của một huấn
luyện viên là chỉ ra điều này cho nhóm và chuyển chúng thành các luận điểm học tập và cảnh
báo cho nhóm lưu ý.

Phong cách giao tiếp
Cẩn thận với “người quản lí”, “người thống trị”, “giọng nói to” và các sự phản chiếu tương tự.
Đây là một khu vực màu mỡ cần khai phá và nhiều chủ đề cho việc huấn luyện cá nhân.

Tiến trình hỏng
Chú ý đến các phần của tiến trình mà các nhóm không làm tốt.
Ví dụ, trong suốt quá trình thảo luận lấy yêu cầu nhóm có thể không hỏi đủ số lượng câu hỏi
nhằm làm rõ vấn đề mà họ cần.
Nhiều khả năng họ cũng sẽ gặp vấn đề này, hoặc sẽ có vấn đề này, trong một lĩnh vực nhất định
của một dự án thật sự. Làm rõ việc này thông qua các câu hỏi là một cách để giải quyết.

CÁC GIAI ĐOẠN CỦA TRÒ CHƠI
Trò chơi này về bản chất gồm ba phần: trước khi chơi, trong khi chơi và sau khi chơi (còn gọi là
quá trình rút kinh nghiệm)
Trước khi chơi






Tổ chức nhóm
Định nghĩa tiến trình
Định nghĩa phạm vi dự án
Tạo ra backlog
Ước lượng

Trong khi chơi


Lên kế hoạch cho Sprint






Thực thi Sprint
Đánh giá SprinT

Sau khi chơi


Rút kinh nghiệm

TRƯỚC KHI CHƠI: Tổ chức nhóm
Cần 5 phút.
Không có lý do gì hoạt động này không phải là một phần của trò chơi – một tiến trình dùng cho
việc học.
Khi cố gắng minh họa việc tự tổ chức trong thực tế, tôi thường yêu cầu nhóm tự tổ chức để có
từ 4-6 người và tự tạo ra không gian làm việc.
Đây là một hoạt động khởi động tốt vì nó yêu cầu di chuyển bàn xung quanh và dọn dẹp.

TRƯỚC KHI CHƠI: Xác định phạm vi dự án
Cần 10 phút. Đến đây bạn đã tham gia trò chơi được 5 phút rồi.
Là một huấn luyện viên đóng vai trò Product Owner tôi cần truyền tải được các thông điệp sau:
1. Tất cả các nhóm sẽ xây dựng một sản phẩm duy nhất – họ không phải cạnh tranh nhau,
thay vào đó các nhóm sẽ làm việc cho cùng một người bán.
2. Sản phẩm là một THÀNH PHỐ với các tính năng nhất định.
3. Các yếu tố cho việc xây dựng là các mảnh LEGO, mặc dù bất kì vật dụng nào cũng có thể
được sử dụng thêm.
4. Tôi là người ra quyết định chính của sản phẩm – đây là thành phố của tôi.
5. Tôi sẽ liên quan đến tiến trình phát triển thông qua việc trả lời các câu hỏi và cung cấp
các phản hồi.
Thực hiện hoạt động này thông qua việc lập kế hoạch cộng tác có thể là một cách tốt.

Mục tiêu của tôi là đảm bảo các nhóm thực tập Scrum bằng cách xây dựng “các sản phẩm” với
các khối LEGO. Bây giờ câu hỏi rắc rối là làm sao kết hợp hai vai trò: một Product Owner (người
không sở hữu tiến trình) và một người huấn luyện lớp học (người mà có sở thích vận hành nó
với Scrum).
Có nhiều cách tôi đã thử để thực hiện việc này:
1. Đổi vai trò – giải thích các luật Scrum cho nhóm
Tôi chỉ ra một cách tường minh là rôi hiện tại đang là một Product Owner hay là một
huấn luyện viên để cho mọi người không bị lẫn lộn.


2. Đóng vai trò là một người mới làm Product Owner – Để cho nhóm thực hiện Scrum
Hầu hết thời gian tôi đóng vai trò là một Product Owner người không biết gì về phát
triển linh động hoặc Scrum và sau khi trình bày tầm nhìn về thành phố tôi yêu cầu nhóm
giúp thiết kế một tiến trình phù hợp.
Cá nhân mà nói tôi thích cách tiếp cận thứ hai hơn vì nó giúp gia tăng việc học trong lớp và
giúp các sinh viên thực tập trong việc đạt được các giá trị của qui trình phát triển linh động.

TRƯỚC KHI CHƠI: Xây dựng backlog
Sẽ cần 15 phút. Bạn đã chơi được 15 phút rồi.
Một khi bạn đã phác thảo được điều luật chung và đồng ý với tiến trình, đã đến lúc chia sẻ các
đặc điểm của thành phố.
Tôi thường làm điều này bằng cách cho nhóm thấy một tập hợp các mảnh giấy ghi chú dính
được chuẩn bị trước trên một tờ giấy của bảng lật.
Thông thường sẽ có các công trình sau:














Nhà một tầng (có nhiều nhà như vậy, mỗi nhà trong một miếng giấy ghi chú dính)
Nhà hai tầng
Cửa hàng
Trường học
Nhà thờ
Bệnh viện
Nhà trẻ
Trạm dừng xe buýt
Giao lộ (có thể vẽ)
Công viên (có thể vẽ)
Sông (có thể vẽ)
Cầu

Một vài công trình có thể được vẽ trên giấy của bảng lật, và sau đó một số món làm từ LEGO có
thể đặt ở trên.
Đến đây bạn có thể sáng tạo và xây dựng thú gì đó thú vị hơn là một thành phố đơn
giản.
Có lần chúng tôi đã chơi trò chơi này với một nhóm khởi nghiệp, vì vậy chúng tôi đã xây
dựng “ngôi làng silicon”.
Hiển nhiên là có nhiều công trình khác có thể xây, giống như một phòng trình bày với
một cái ipad (thể hiện màn hình), một số khu vực cộng tác làm việc trong thành phố,

một tòa nhà an ninh cho các máy chủ web và một tượng đài tưởng niệm người hùng
khởi nghiệp (một tượng đài thú vị với các thanh chắn). Rất vui!
Trong khi trình bày backlog tôi giải thích ngắn gọn mỗi công trình sẽ trông ra sao. Và tôi cũng
cố gắng trì hoãn việc thảo luận cho đến khi tôi nói xong.

TRƯỚC KHI CHƠI: Ước lượng
Sẽ cần 20 phút. Bạn đã ở trong trò chơi được 30 phút.
Các ước lượng, theo khía cạnh nào đó, là phần khó nhất.
Tôi sẽ muốn:
1. Hạ các ước lượng xuống
2. Làm nhanh hơn và đơn giản hơn
3. Dành nhiều thời gian luyện tập sử dụng kĩ thuật planning poker
RT @RonJefffries: “Mỗi năm lại có một kĩ thuật ước lượng mới. Cách tiếp cận Phát
triển linh động thật sự sẽ loại bỏ việc ước lượng đi.” - @agilemanager [ĐÚNG]
Dựa trên thời gian mà chúng ta có tôi quyết định thực hiện kĩ thuật đơn giản nhất hoặc là poker.
Kĩ thuật đơn giản nhất – Xác định kích thước dùng các đường bơi
Tôi đã học thuật ngữ này từ www.theagilepirate.net. Hiển nhiên là tôi sẽ thực hiện với theo cách
ít phức tạp hơn.
Hãy thử nhìn vào hình bên dưới.
Dựa trên khái niệm phép đạc tam giác và xác định kích thước dùng đường bơi chúng ta sắp xếp
các cột để đánh dấu các kích thước câu chuyện khác nhau (1 2 3 5 8 13 nếu bạn thích Fibonacci
hơn – một chút hơi hướng khoa học lúc nào cũng tốt), và yêu cầu các sinh viên kéo thả các câu
chuyện vào các cột đại diện cho kích thước câu chuyện. Chúng ta sẽ làm việc này cùng nhau
hoặc là theo nhóm.


Hoạt động này có thể được thực hiện trong im lặng.

Hình 1- Các đường bơi dùng để ước lượng cho nhóm

Nếu một nhóm đủ lớn mà không thể vừa phía trước của bảng, tôi yêu cầu mỗi nhóm gởi ra một
cặp. Khi các cặp này xong, các cặp kế tiếp sẽ lên, cho đến khi tất cả mọi người đều có cơ hội
chạm vào bảng.
Một khi đã xong, tôi sẽ hỏi nhóm liệu đã đủ tốt để bắt đầu và liệu họ có muốn làm cái gì đó thật
sự bây giờ hay chưa.

Lên kế hoạch theo kiểu poker với nhiều nhóm
Việc thực hiện lên kế hoạch theo kiểu poker với nhiều nhóm đầu tiên đòi hỏi việc đồng thuận
trên các kích thước mẫu trong toàn bộ nhóm.
Việc đồng ý với kích thước khá đơn giản: chọn một công trình đủ nhỏ và đơn giản nhưng không
quá tầm thường và gán kích thước “2” cho nó. Thông thường mọi người đồng ý các toàn nhà
một tầng có kích thước 2.
Cách tiếp cận khác là chọn các câu chuyện mẫu để thực hiện việc ước lượng theo kích cỡ áo
thun (XS, S, M, L, XL) và đánh dấu tất cả các câu chuyện có kích thước S là “2” và tiếp tục với việc
lên kế hoạch theo kiểu poker.
Tôi muốn chia sẻ các gợi ý đã giúp tôi thực hiện các phiên ước lượng theo kiểu poker dành cho
nhiều nhóm hiệu quả:


Tổ chức bức tường các đường bơi (xem hình vẽ ở trên)






Yêu cầu các nhóm chọn lần lượt từng câu chuyện để ước lượng.
Yêu cầu các nhóm thêm các chi tiết cho mỗi câu chuyện khi họ có được các giải thích
nhằm làm rõ từ Product Owner (bởi vì có thể là nhóm khác sẽ xây dựng công trình).
Chủ động khuyến khích và ngợi khen các thành viên của nhóm đã hỏi các câu hỏi nhằm

làm rõ vấn đề và giúp ích cho việc xác định kích thước.
Khi ước lượng xong, cần đặt lên tường một câu chuyện để các nhóm khác có được lợi ích
từ thông tin mới này.
Khi hoàn thành yêu cầu mọi người đến tường và thực hiện việc kiểm tra ôn hòa với các
thay đổi cần thiết (theo kinh nghiệm cá nhân của tôi hiếm khi cần các thay đổi).
Nếu các nhóm không biết nhiều về cách lên kế hoạch theo kiểu poker, cũng đáng
để thực hiện một bài kiểm tra để bạn có thể quan sát xem liệu họ có sử dụng kĩ
thuật này một cách đúng đắn hay không. Tôi thường yêu cầu các nhóm phán
đoán xem:
“Một 0.57 lít Guinness có giá bao nhiêu ở Anh?”

Điều thú vị là trong cả hai kĩ thuật: đường bơi và lên kế hoạch theo kiểu poker đều cung cấp sự
chính xác cần thiết cho việc lên kế hoạch phát hành vì nó đã được chứng minh bởi hàng trăm
các biểu đồ phát hành burn-down.

TRÒ CHƠI: Lên kế hoạch Sprint
Bạn đã tham gia trò chơi được 50 phút.
(Và chưa có thứ gì được tạo ra! Liệu điều này có đủ để chứng minh là việc ước lượng thật sự
lãng phí?)
Bây giờ khi các câu chuyện đã được ước lượng, bạn phải di chuyển chúng từ bức tường các
đường bơi quay ngược về Backlog.
Bởi vì chúng ta muốn việc lên kế hoạch sprint có thể dễ dàng nhìn thấy, chúng ta tạo ra một bức
tường lên kế hoạch đặc biệt tổng hợp kế hoạch của tất cả các nhóm cho tất cả các sprint trong
trò chơi.


Hình 2 – Tường dùng lên kế hoạch cho các đội, trước khi lên kế hoạch cho Sprint #1

Hình 3 – Tường lên kế hoạch của các đội, trong Sprint #2

Chúng ta sẽ giới hạn thời gian cho hoạt động lên kế hoạch của một Sprint trong vòng 3 phút để
yêu cầu các đội kéo các câu chuyện vào các khung Sprint của mỗi đội.
Khi tất cả đã xong, chúng ta sẽ hỏi các đội liệu đã đủ không hài lòng với kế hoạch của mình
trước khi thử hay chưa?

Trò chơi: Lên kế hoạch
Sẽ cần 7 phút.
Mỗi một sprint kéo dài 7 phút được ưa chuộng hơn bởi vì khoảng thời gian này là tạm đủ để tạo
ra nhiều món đồ với nhiều người cộng tác mà không cần phải cải tiến kết quả quá nhiều.
Để khiến cho các sinh viên cảm thấy có đủ áp lực, chúng ta có thể dùng đồng hồ đếm ngược
thời gian từ máy tính xách tay hoặc từ máy chiếu.

Hình 4 – Đồng hồ đếm ngược từ trang online-stopwatch.com – đồng hồ có thể ở nhiều dạng khác nhau, có thể được sử
dụng offline

Trò chơi: Xét duyệt
Cần 5 phút.
Khi hết giờ, tôi yêu cầu các sinh viên dừng thật sự việc xây dựng lại và bắt đầu đưa ra đòi hỏi:
“Thành phố của tôi đâu?”


Như đã được quan sát trước đó, chỉ sau khi sprint thứ hai các đội mới bắt đầu thực hiện triển
khai liên tục các câu chuyện ra môi trường minh họa (một tờ giấy trên bảng lật). Vì vậy trong
hầu hết các trường hợp sau sprint đầu tiên, không ai nghĩ đến việc tổ chức một buổi minh họa.
Nghe có vẻ giống với tình huống trong thực tế chứ?
Tôi thường nhận được nhận xét khi phỏng vấn là mình đang đóng vai trò một Product Owner tử
tế nhất từng được thấy. Trong hầu hết các trường hợp không có gì được chấp nhận sau sprint
đầu tiên, bởi vì sau khi các sinh viên cho tôi xem các tòa nhà, tôi “chợt nhận ra”:







Tôi thích đối xứng cơ
“Tất cả phải cùng màu” có nghĩa là “màu đồng nhất cho tất cả các tòa nhà, nhưng mỗi
toàn nhà phải khác nhau”.
Các tòa nhà khi thì quá nhỏ, khi thì quá lớn, có lúc lại quá khác nhau
Cửa sổ ở các tầng khác nhau không thẳng hàng.
<Nghĩ ra các lí do riêng của bạn>

Các món đồ chưa hoàn thành sẽ được đưa trở về ngược trong Backlog từ Bức tường lên kế
hoạch. Các công việc còn lại có thể được ước lượng lại, mặc dù chúng ta hiếm khi cập nhật các
ước lượng.
Một khi các câu chuyện đã được chấp nhận, sơ đồ Release Burndown sẽ được cập nhật bởi PO,
người chịu trách nhiệm thông báo lớn và rõ ràng là một phiên bản release sẽ phải được hoàn
thành trong 3 sprint và bây giờ có vẻ chúng ta sẽ không thể hoàn thành tất cả các câu chuyện.
Sẽ cần có vài phút dành cho việc hồi tưởng về chủ đề “làm sao chúng ta có thể làm việc tốt hơn
cho sprint kế tiếp”.

Trò chơi: Chu trình Release
Không nên phí quá nhiều thời gian thảo luận các thất bại của sprint đầu tiên, vốn hầu như luôn là
một thảm họa, chúng ta sẽ quay lại pha Lên kế hoạch cho Sprint.
Tôi đã rút ra bài học là cần trung bình 3 sprint để hoàn thành 80% backlog với chất lượng được
dự đoán trước, vì vậy một chu trình đầy đủ sẽ trông giống như thế này:
1. Sprint #1
a. Lên kế hoạch – 3 phút
b. Thực thi sprint – 7 phút
c. Xem xét lại – 5 phút

2. Sprint #2
a. Lên kế hoạch – 3 phút
b. Thực thi sprint – 7 phút


c. Xem xét lại – 5 phút
3. Sprint #3
a. Lên kế hoạch – 3 phút
b. Thực thi sprint – 7 phút
c. Xem xét lại – 5 phút
Tổng cộng: 45 phút.
Do việc chuẩn bị sẽ mất khoảng 1 giờ (từ lúc xác định phạm vi dự án đến ước lượng backlog),
thực hiện theo các sprint mất 45 phút, sẽ cần thêm 15 phút để tóm tắt lại, trò chơi đầy đủ sẽ cần
120 phút.
Một khi đã luyện tập và có sự trợ giúp của các đồng huấn luyện, người mà sẽ đóng vai trò Scrum
Master, trò chơi có thể được chơi nhanh hơn.

Hậu trò chơi: Tóm tắt
Có lẽ sẽ tốt hơn nếu có một khoảng tạm dừng ngắn ngay khi sprint cuối cùng được xem xét và
trước khi đi vào phần tóm tắt để giảm các cảm xúc và có một khoảng thời gian nghỉ ngắn (Tôi có
nói với bạn trò chơi được thiết kế cho các đội trở nên kiệt sức chưa? Không chỉ cho các đội chơi…)
Khi tập hợp lại trong một vòng tròn, chung ta thực hiện một thảo luận xung quanh các câu hỏi
mở sau:













Các sinh viên quan sát thấy điều gì?
Là một nhóm Scrum cho các bạn cảm giác gì?
Các vòng lặp ngắn diễn ra ra sao?
Các lượng ước chính xác ra sao? (miễn là có Burndown Release ở đó)
Nếu chúng ta có cơ hội chơi lại trò chơi một lần nữa thì chúng ta đã có thể làm khác đi
điều gì ngay từ đầu?
Công việc của Product Owner là gì?
Cảm giác ngay sau sprint đầu tiên, khi tất cả các món đồ được yêu cầu làm lại là gì?
Scrum Masters đã làm gì?
Chiến lược của bạn thay đổi ra sao, nếu bạn biết Product Owner không có sẵn trong suốt
các sprint?
Việc giao tiếp giữa các nhóm diễn ra như thế nào? Liệu có sự phụ thuộc nào hay không?
Nó đã được giải quyết như thế nào?
Các sinh viên học được điều gì?


CÁC BIẾN THỂ
Thêm vào các thay đổi bất thường
Những người bạn tốt của tôi (Askhat Urazbaev và Nikita Filippov) đã thiết kế một trò chơi tương
tự, trong đó có thêm vào các thay đổi ngẫu nhiên bất thường với kích thước của nhóm và độ
phức tạp.
Chỉ đơn giản là sau khi lên kế hoạch cho sprint và ngay trước khi bắt đầu sprint, các nhóm đổ
xúc sắc hoặc là sẽ nhân điểm số câu chuyện lên hoặc khiến cho một số thành viên trong nhóm
bị “bệnh” trong suốt sprint trong khi nhóm phải giữ sao cho mọi thứ đi theo kế hoạch ban đầu.
Quan điểm của trò chơi là việc cộng tác trong nhóm là cần thiết để có thể cân bằng các công

việc trong suốt các sprint, bởi vì nhiều thứ có thể diễn ra khác hẳn với kế hoạch.

Scrum trong doanh nghiệp
Tôi có thể mở rộng trò chơi giả lập với LEGO cho 100 sinh viên chơi thành 12 đội xây dựng 4
thành phố đồng thời. Việc này sẽ cần có hàng tấn LEGO nhưng có vẻ nó là một cách tốt để
minh họa Scrum ở mức độ doanh nghiệp. Cái này xứng đáng có một bài báo khác đề cập đến
tất cả luật lệ và thiết lập.

Bạn có biến thể của riêng mình? Hãy cho chúng tôi biết.
Chúng tôi muốn nghe các câu chuyện của bạn, biến thể của bạn đối với trò chơi giả lập này –
hãy tham gia với chúng tôi tại www.lego4scrum.com và gởi thư điện tử ý tưởng của bạn tại


XIN CẢM ƠN!


Chúc bạn có được những dự án vui!

Alexey Krivitsky
www.lego4scrum.com