Bìa Ebook - Học viện Agile

8 HIỂU LẦM VỀ

Khiến doanh nghiệp

SCRUM

MấtThời gian

Tiền

Người

Cách giải quyết

Xem thêm nhiều bài viết và sách miễn phí về Agile/ Scrum https://hocvienagile.com/kien-thuc-agile/

Mục lục

Không cần lập kế hoạch ..................................................................................................................... 3

Trong Scrum, chúng ta tập trung vào hành động lên kế hoạch hơn là bản thân kế hoạch. ....... 3

Trong Scrum, lập kế hoạch là một hoạt động cộng tác. ................................................................ 3

Trong Scrum, người thực hiện công việc cũng chính là người lập kế hoạch. ............................... 4

Lập kế hoạch trong Scrum là một phần của mọi Sự kiện. .............................................................. 4

Trong Scrum, cách lập kế hoạch giảm thiểu sự lãng phí. ............................................................... 5

Trong Scrum, chúng ta vẫn nhận thức được tính khó lường trong phát triển phần mềm. ......... 5

Không được thay đổi Sprint Backlog trong Sprint ....................................................................... 6

Hiểu lầm về việc Sprint Backlog không thể thay đổi trong suốt Sprint ........................................ 6

“Bắt bệnh” hiểu lầm .......................................................................................................................... 7

Cam kết và Dự đoán ......................................................................................................................... 7

Lời kết ................................................................................................................................................ 8

Trong Scrum, các tính năng mới chỉ được chuyển giao ở cuối Sprint ....................................... 9

“Bắt bệnh” hiểu lầm .......................................................................................................................... 9

Nhầm lẫn bắt nguồn do đâu .......................................................................................................... 10

Còn Sơ kết Sprint thì sao? .............................................................................................................. 11

Thủ thuật ......................................................................................................................................... 11

Lời kết .............................................................................................................................................. 12

Product Backlog buộc phải có các User story .............................................................................. 13

Giải mã hiểu lầm.............................................................................................................................. 14

Đôi điều về user story ..................................................................................................................... 14

Các kĩ thuật để nắm vững công việc trong Product Backlog ....................................................... 15

Thủ thuật ......................................................................................................................................... 16

Lời kết .............................................................................................................................................. 16

Trong Scrum, Product Backlog được ưu tiên ............................................................................... 17

Giải mã hiểu lầm.............................................................................................................................. 17

Ưu tiên hay thứ tự ........................................................................................................................... 17

https://hocvienagile.com/kien-thuc-agile/


Các nhân tố ảnh hưởng tới thứ tự ................................................................................................. 18

Thủ thuật ......................................................................................................................................... 20

Lời kết .............................................................................................................................................. 20

ScrumMaster là Huấn luyện viên Agile cấp thấp......................................................................... 21

Hiểu lầm này liên quan tới một số lý do sau: ................................................................................ 22

Giải mã hiểu lầm.............................................................................................................................. 22

8 tư thế của ScrumMaster .............................................................................................................. 23

Đối mặt với các thử thách “cao cấp” .............................................................................................. 24

Vậy chúng ta có nên sa thải tất cả các HLV Agile không?............................................................ 25

Nếu như chúng ta dùng Kanban/XP/DevOps thì sao? ................................................................. 26

Lời kết .............................................................................................................................................. 27

ScrumMaster giải quyết MỌI VẤN ĐỀ ........................................................................................... 28

Giải mã hiểu lầm.............................................................................................................................. 28

Điều gì tạo ra các “chướng ngại vật”? ........................................................................................... 29

Các vấn đề và trở ngại trong thực tế ............................................................................................. 30

Trở thành một ScrumMaster thành công có nghĩa là… ................................................................ 31

Vậy là ScrumMaster không bao giờ giải quyết các vấn đề?......................................................... 32

Thủ thuật ......................................................................................................................................... 32

Lời kết .............................................................................................................................................. 33

ScrumMaster phải có mặt trong suốt buổi Scrum Hằng ngày.................................................. 34

Hiểu nhầm về việc ScrumMaster phải xuất hiện trong suốt buổi Scrum Hằng ngày ................. 34

Hướng dẫn về Scrum nói gì? .......................................................................................................... 35

Các vấn đề tiềm năng ..................................................................................................................... 35

Thủ thuật ......................................................................................................................................... 36

Lời kết .............................................................................................................................................. 36

Nguồn tham khảo ............................................................................................................................. 37



Không cần lập kế hoạch

Một trong những hiểu lầm thường xuyên lặp lại về Scrum đó là việc người dùng nghĩ rằng không

có lập kế hoạch trong Scrum. Thật không may, hiểu lầm này có thể dẫn tới hai hậu quả tiêu cực

dưới đây:

1. Những người phụ trách các vị trí quản lý ngân sách, sản phẩm, bán hàng hay marketing

sẽ không sẵn sàng thử nghiệm Scrum.

2. Nhóm Scrum có thể không tận dụng được hiệu quả khi sử dụng Scrum

Trong thực tế, chúng ta lập kế hoạch RẤT NHIỀU trong Scrum

Chúng ta chỉ thực hiện việc này khác đi để tối đa hoá hiệu quả.

Trong Scrum, chúng ta tập trung vào hành động lên kế

hoạch hơn là bản thân kế hoạch.

Chúng ta biết rằng kế hoạch sẽ thay đổi. Và đó chính là lối tư duy theo đuổi giá trị Agile về việc

liên tục thích nghi với các thay đổi hơn là bám sát một kế hoạch.

Trong Scrum, lập kế hoạch là một hoạt động cộng tác.

Một Sprint thường phải bắt đầu bằng Lập kế hoạch Sprint với sự tham gia của toàn bộ Nhóm

Scrum. Lập kế hoạch Sprint giống như một cuộc đàm phán hợp tác nhằm đạt được một kết quả

có giá trị. Nhóm Phát triển tạo ra Sprint Backlog trong buổi họp này để xác định những việc cần

hoàn thành và một kế hoạch cởi mở cho các kết quả có giá trị.

Scrum Hằng ngày là một hoạt động lên kế hoạch cộng tác cho Nhóm Phát triển để giám sát quy

trình và điều chỉnh kế hoạch nhằm đạt được Mục tiêu Sprint.

Sơ kết Sprint là một phiên cộng tác nhằm thu thập các thông tin đầu vào cần thiết cho buổi Lập

kế hoạch Sprint tiếp theo.

Cải tiến Sprint là một hoạt động hợp tác nhằm tạo ra và chuẩn bị cho các phát triển liên tục.



Trong Scrum, người thực hiện công việc cũng chính là

người lập kế hoạch.

Nhóm Phát triển sở hữu Sprint Backlog. Họ tạo ra nó và họ cũng có thể điều chỉnh nó. Tính sở

hữu này đồng nghĩa với việc kế hoạch sẽ phản ánh tình trạng thực thế với sự kết hợp chặt chẽ

của những thông tin đầu vào từ những người giỏi nhất. Đối với các kế hoạch ban đầu nhằm mục

đích đự đoán là chính, toàn bộ Nhóm Scrum phải cùng nhau phối hợp thực hiện bởi đây là trách

nhiệm riêng của các vai trò trong Scrum.

Lập kế hoạch trong Scrum là một phần của mọi Sự kiện.

Trong tất cả các Sự kiện, chúng ta đều cần phải thực hiện việc giám sát/thanh tra và thích nghi.

Đó là một phần của việc lập kế hoạch. Nếu chúng ta không thấy sự thích nghi xảy ra trong một

Sự kiện Scrum, thì đó là lúc tìm hiểu lại về mục đích của các Sự kiện.

Chúng ta cũng cần phải nhớ, Khung làm việc Scrum chỉ là một khung làm việc. Nó khuyến khích

các Nhóm Scrum áp dụng các phương pháp bổ sung khi cần trợ giúp trong lúc lập kế hoạch, bao

gồm Lập kế hoạch phát hành sản phẩm và các kĩ thuật làm mịn Product Backlog. Các thành viên



của nhóm chọn cách thực hiện công việc của họ và tạo ra những cuộc thảo luận về việc lập kế

hoạch trong suốt Sprint.

Trong Scrum, cách lập kế hoạch giảm thiểu sự lãng phí.

Một kế hoạch sẽ trở thành quá khứ chỉ một phút ngay sau khi bạn thảo luận chúng. Do vậy, chúng

ta cần giữ kế hoạch đơn giản, dễ dàng bổ sung/cập nhật. Có một vài cách giảm thiểu sự lãng phí

liên quan tới lập kế hoạch bao gồm:

• Tối thiểu thời gian cho việc phân tích những việc sẽ không bao giờ xảy ra. Những

việc càng ở tương lai xa hoặc đang ở phía cuối của danh sách các công việc ưu tiên thì

càng cần ít thời gian hơn để thực hiện chi tiết.

• Giảm thiểu thời gian phân tích độ hoàn hảo bất khả thi. Sẽ có những thời điểm

chúng ta nhận rằng việc thực hiện chính xác một việc sẽ không giúp chúng ta giảm

thời gian cần thiết. Chúng ta cần chấp nhận thực tế rằng bản chất khó lường và phức

tạp của môi trường phát triển phần mềm khiến việc lên một kế hoạch hoàn hảo là

không khả thi.

• Tạo ra các nhận xét/đánh giá ý nghĩa ở tất cả các cuộc họp lập kế hoạch. Bằng

cách thực hiện điều này với việc tạo ra các phần mềm, chúng ta học được các thông tin

giá trị nhất hỗ trợ cho việc thích ứng với các kế hoạch.

Trong Scrum, chúng ta vẫn nhận thức được tính khó

lường trong phát triển phần mềm.

Bằng cách chấp nhận thực tế này, chúng ta có thể minh bạc về quy trình hiện tại, và những ngày

hoàn thành. Việc minh bạch giúp ta xây dựng lòng tin và tạo điều kiện để sử dụng phát triển kinh

doanh linh hoạt, đưa ra các quyết định khó khăn và làm việc chuyên nghiệp.

Tóm lại, việc lập kế hoạch hiệu quả là một phần quan trọng của Scrum. Khi chúng ta thực

hiện tốt Scrum, việc Lập kế hoạch trong Scrum hiệu quả hơn.



Không được thay đổi Sprint Backlog trong Sprint

Scrum được định hướng là một khung làm việc đơn giản nhưng hiệu quả để phân phối các sản

phẩm phức tạp. Scrum không phải là một giải pháp cho mọi vấn đề, một lời giải tuyệt đối cho

những vấn đề hóc búa hay một phương pháp toàn diện. Thay vào đó, Scrum đề ra những giới

hạn tối thiểu trong việc nhóm có thể tự tổ chức để giải quyết một vấn đề phức tạp nào đó theo

hướng thực tiễn, quan sát và thực hành thay vì chỉ lý thuyết chung chung. Sự tối giản này chính

là sức mạnh lớn nhất của Scrum, nhưng cũng chính là nguồn cơn của rất nhiều lời đồn đoán và

sự hiểu lầm xung quanh nó.

Hiểu lầm về việc Sprint Backlog không thể thay đổi

trong suốt Sprint

Rất nhiều người lầm tưởng rằng Sprint Backlog không thay đổi trong suốt Sprint. Nhóm Phát triển

cam kết thực hiện tất cả các hạng mục công việc trong Sprint Backlog, không cho phép có bất kì

sự thay đổi nào điễn ra trong Sprint (không thêm, không bớt). Điều này giúp nhóm có được sự

tập trung cần thiết để hoàn thành các cam kết đã đề ra.

Vậy, tại sao việc này lại là một sự hiểu lầm?



“Bắt bệnh” hiểu lầm

Sprint Backlog trình bày các công việc mà một Nhóm Phát triển cần thực hiện để đạt được Mục

tiêu Sprint. Mục tiêu Sprint được đặt ra bởi Nhóm Scrum trong cuộc họp Lập kế hoạch Sprint.

Mục tiêu Sprint cần thể hiện được giả thuyết mà nhóm muốn thử nghiệm và muốn đạt được. Mặc

dù Mục tiêu Sprint là cố định, nhưng Sprint Backlog thì không. Điều này có vẻ không đúng, nếu

chúng ta nhìn lại những tiền đề cốt lõi của Scrum: Chúng ta không thể tạo ra các bản kế hoạch

chi tiết cho tương lai. Thậm chí tương lai chỉ gói gọn trong một Sprint, hoàn toàn vẫn có thể xuất

hiện những vấn đề mới hay các trở ngại Sprint khi Nhóm Phát triển thực hiện các công việc trong

Sprint Backlog.

Một nhóm có thể biết rằng, công nghệ mà được chọn vẫn có thể không được như mong muốn.

Hoặc một hạng mục quan trọng cần thiết để đạt được Mục tiêu Sprint lại bị bỏ sót khi thực hiện

Lập kế hoạch Sprint. Khi các vấn đề xuất hiện, những thay đổi với Sprint Backlog cần được đảm

bảo nhằm đạt được Mục tiêu Sprint.

Nhóm Phát triển sẽ đàm phán lại về Sprint Backlog với Product Owner. Tóm lại, một Sprint Backlog

có thể linh hoạt, miễn là những thay đổi không ảnh hưởng tới Mục tiêu Sprint.

Scrum Hằng ngày giúp các nhóm có cơ hội để thanh tra và thích nghi với tiến độ đạt được Mục

tiêu Sprint và tạo ra các điều chỉnh thích hợp cho Sprint Baclog khi cần thiết.

Cam kết và Dự đoán

Liên quan tới vấn đề này, Hướng dẫn Scrum (Scrum Guide) đã và đang thay đổi kể từ một vài năm

trước đây. Trong khuôn khổ nội dung về Sprint Backlog, từ “Cam kết” được thay thế bằng từ “Dự

đoán”. Trong cuốn hướng dẫn mô tả Sprint Backlog như là một dự đoán của Nhóm Phát triển về

chức năng có thể sẽ là một phần của Gói tăng trưởng tiếp theo và các công việc cần làm để hoàn

thành chức năng đó và đưa vào Gói tăng trưởng phần mềm “Hoàn thành”. Điều này nhấn mạnh

rằng các thông tin và các vấn đề không mong đợi có xu hướng xảy ra trong giai đoạn phát triển,

dù cho đó chỉ là trong khuôn khổ của một Sprint.

Tuy nhiên, các nhóm vẫn duy trì các Cam kết. Họ tự cam kết với các việc:

• Hoàn thành Mục tiêu Sprint;

• Tạo ra các phần mềm chất lượng cao, có thể sử dụng được, đáp ứng được mong đợi

của khách hàng và người dùng;

• Chỉ làm việc trên các hạng mục Product Backlog với giá trị cao nhất;



• Tập trung vào cải tiến, học tập liên tục, và kĩ thuật xuất sắc;

• Thanh tra và thích nghi liên tục với những trải nghiệm được hỗ trợ;

• Hợp tác với tất cả nhân sự thuộc mảng kinh doanh có liên quan;

• Giá trị và các thành phần cơ bản của Khung làm việc Scrum.

Khi Sprint Backlog là đầu ra được trông đợi, Mục tiêu Sprint chính là kết quả mà chúng ta muốn

đạt được. Thay vì cố gắng “nhồi” nhiều hạng mục nhất có thể vào một Sprint, chúng ta nên đạt

được một kết quả đáng trông đợi (Mục tiêu Sprint) với số lượng hạng mục ít nhất (Sprint Backlog).

Bám lấy bản chất thay đổi của Sprint Backlog. Khuyến khích Nhóm Phát triển thay đổi, cải thiện

và điều chỉnh Sprint Backlog trong suốt Sprint. Nếu một công việc mới phát sinh, Nhóm Phát triển

cần đưa vào Sprint Backlog. Ngược lại, loại bỏ khỏi Sprint Backlog nếu công việc đó được chứng

minh là không cần thiết. Những điều chỉnh với các thay đổi này hoàn toàn phụ thuộc vào nhóm,

và họ có thể thông báo với Product Owner nếu thấy điều đó là cần thiết. Bất kì sự thay đổi nào

trong Sprint Backlog được “hoàn thành” thì Mục tiêu Sprint cũng “hoàn thành” và tạo ra Phần

tăng trưởng “hoàn thành”.

Lời kết

Trong nội dung này, chúng tôi đã miêu tả hiểu lầm về việc Sprint Backlog là không thay đổi trong

Sprint. Chúng tôi đã gỡ bỏ các hiểu lầm này bằng cách đưa ra góc nhìn từ Hướng dẫn Scrum và

mô tả sự khác biệt giữa Dự đoán và Cam kết.



Trong Scrum, các tính năng mới chỉ được chuyển

giao ở cuối Sprint

Ngày nay vẫn tồn tại rất nhiều những nhầm lẫn về Scrum, đặc biệt khi những hiểu lầm kiểu “Scrum

linh hoạt do những Bản phát hành mới chỉ có sau khi kết thúc Sprint” hoặc “DevOps/Kanban phù

hợp tốt hơn cho chúng ta bởi vì chúng cho phép phát hành nhanh hơn”. Ở cả hai trường hợp

trên, cốt lõi của sự nhầm lẫn nằm ở chỗ Scrum chỉ cho phép các nhóm phát hành phần mềm ở

cuối Sprint, việc này làm giảm tốc độ và giảm sự linh hoạt nếu các nhóm có khả năng thực hiện

nhanh hơn.

“Bắt bệnh” hiểu lầm

Sự nhầm lẫn này là một ví vụ việc tạo ra một khung làm việc quan trọng hơn mục tiêu, mặc dù ở

trường hợp này là xuất phát từ sự hiểu lầm về khung làm việc. Mục đích của khung làm việc Scrum

là phát triển các sản phẩm, giải quyết các vấn đề phức tạp bằng cách sử dụng quy trình thực

nghiệm để thúc đẩy các phản hồi nhanh chóng. Ở những phân đoạn ngắn, chúng ta sử dụng cả

nhận xét/đánh giá từ bên trong và bên ngoài nhóm. Do vậy chúng ta tránh được việc giải quyết

nhầm vấn đề và/hoặc thực hiện một giải pháp chưa tối ưu. Với mục tiêu đó, làm thế nào mà Scrum

buộc các nhóm chỉ được chuyển giao phần mềm ở cuối Sprint?



Mục tiêu của Sprint là tạo ra khoảng thời gian tối ưu cho Nhóm Phát triển để chuyển một số các

đầu mục công việc từ Product Backlog sang Phần tăng trưởng Hoàn thành, hoàn toàn mới và có

thể sử dụng được. Quan điểm “Hoàn thành” phụ thuộc vào những góc nhìn khác nhau của các

nhóm liên quan. Đối với một số nhóm, Phần tăng trưởng “Hoàn thành” là khi mã đã được viết

xong và nằm trong một nhánh chia sẻ của Kho chứa (Repossitory). Đối với các nhóm khác, Phần

tăng trưởng “Hoàn thành” là khi họ đã triển khai tới môi trường tiền sản xuất (Staging, Q&A và

Tích hợp – Integration) hoặc là đã tới môi trường sản xuất.

Việc hoàn thành của Phần tăng trưởng được xác định bởi lượng thời gian cần thiết để đưa được

Phần tăng trưởng đó tới người dụng (Ví dụ, tới sản xuất).

Nếu cần nhiều thời gian hơn, tổ chức sẽ kém Agile hơn. Sau cùng, Phần tăng trưởng chỉ thật sự

có giá trị nếu chúng đến được tay của người dùng. Đồng thời, chất lượng và việc hoàn thành các

nhận xét/đánh giá cũng bị giảm, giống như sự hoàn thành phần tăng trưởng.

Như vậy, Sprint đại diện cho một giới hạn tối thiểu để chuyển giao một Phần tăng trưởng “Hoàn

thành”. Trong một Khung làm việc Scrum, không gì có thể ngăn cản các Nhóm Scrum phát hành

phần mềm chạy suốt trong Sprint, miễn là Product Owner gắn liền tới việc ra quyết định phát

hành. Scrum thực sự khuyến khích các nhóm mở rộng khái niệm “Hoàn thành” các Phần tăng

trưởng của họ tới phiên bản đầy đủ nhất (ví dụ như Phát hành ra Sản xuất). Điều này giúp tối đa

hoá giá trị của Lý thuyết thực nghiệm, cũng chính là nền tảng của Scrum, khi nhận xét/ đánh giá

trở nên thực tế hơn, có tính ứng dụng cao hơn.

Nhầm lẫn bắt nguồn do đâu

Sự nhầm lẫn trước tiên nằm ở sự hiểu nhầm về cái gọi là “Phần tăng trưởng” (increment). Hướng

dẫn Scrum (Scrum Guide) định nghĩa đơn giản Phần tăng trường là tổng của tất cả các hạng mục

Product Backlog đã hoàn thành trong Sprint. Phần tăng trưởng có thể là một gói các tính năng

mới dự định sẽ được triển khai cùng nhau vào cuối Sprint. Nhưng không bắt buộc phải là như

vậy. Một phần tăng trưởng cũng có thể là tổng của các chức năng được phát hành trong Sprint.

Thứ hai, việc sử dụng các thuật ngữ như “Phần tăng trưởng sản phẩm có thể phát hành được” hay

“Phần tăng trưởng sản phẩm có thể chuyển giao được” cũng góp phần tạo ra những hiểu nhầm

về Phần tăng trưởng. Mặc dù không phải do cố ý, vô tình những người làm nhiệm vụ kiểm định

có thể tạo ra một niềm tin rằng các Phần tăng trưởng đó chỉ có tiềm năng “phát hành” hay “chuyển

giao” ở cuối một Sprint.

Ngoài ra, nhiều sự hiểu nhầm khác xuất phát từ việc phân biệt giữa Scrum và DevOps. Có nhiều

người tin rằng DevOps tối ưu hơn Scrum bởi vì nó cho phép các nhóm phát hành phần mềm



nhanh hơn. DevOps không có khái niệm Sprint, do vậy DeveOps tin rằng việc ra mắt phần mềm

có thể thực hiện ở bất kì thời điểm nào mà nhóm thấy “sẵn sàng”.

Nhưng Scrum và DevOps có mối quan hệ gần gũi, cả hai đều cố gắng để thực hiện lý thuyết thực

nghiệm với chu kỳ phản hồi ngắn nhất có thể. Trong khi Scrum tập trung nhiều hơn vào quy trình

cần thiết để xây dựng những nhu cầu của bên liên quan. DevOps tập trung giải quyết những yếu

tố về kĩ thuật và thực hành cho phép điều đó xảy ra. Theo một cách diễn giải khác, Scrum cung

cấp một chiếc la bàn, một đích đến, còn DevOps cung cấc những đôi ủng chắc chắn để hỗ trợ

cho việc thực hiện một hành trình mà không gặp trở ngại. Cả hai giống như hai mặt của một đồng

xu vậy.

Còn Sơ kết Sprint thì sao?

Nếu mọi thứ được phát hành ở trong Sprint, vậy mục đích của Sơ kết Sprint là gì? Nếu Sơ kết

Sprint chỉ dành để trình diễn phần tăng trưởng, vậy thì sự kiện sẽ diễn lại những việc bạn đã biết.

Nhưng trình diễn phần mềm hoạt động tốt chỉ là một phần nhỏ của Sơ kết Sprint. Mục đích căn

bản của cuộc họp là nhằm thanh tra những công việc đã hoàn thành trong Sprint và để ra quyết

định cho Sprint tới, nhằm tối đa hoá giá trị.

Càng nhiều Phần tăng trưởng “Hoàn thành”, càng nhiều phản hồi có giá trị được thu thập.

Do đó, nếu một nhóm đã phát hành phần mềm sử dụng được trong Sprint thì sẽ giúp cho Sơ kết

Sprint trở thành một cơ hội tuyệt vời để thanh tra các phản hồi từ người dùng thật và thích ứng

dựa trên những thông tin thu thập được từ đó. Giá trị của Sơ kết Sprint thật sự tăng lên khi “Định

nghĩa về Hoàn thành” của nhóm chuyển thành “Phát hành tới Sản phẩm”.

Thủ thuật

• Nếu bạn là một ScrumMaster, hãy huấn luyện nhóm của mình liên tục mở rộng

“Định nghĩa Hoàn thành”. Nói đơn giản, ScrumMaster hãy giúp nhóm giảm đi khối

lượng công việc còn lại sau khi xem xét nó là đã hoàn thành ( ví dụ: kiểm thử, giám sát

chất lượng, phát hành, viết tài liệu).

• Đầu tư vào việc tìm hiểu sâu về DevOps và phương pháp liên quan, ví dụ kiểm thử

tự động, nền tảng như là mã nguồn (infrastructure as code), ảo hoá và chuyển giao liên

tục. Đó là những yếu tố quan trọng cho phép việc phát hành nhanh hơn mà không

phải thoả hiệp về chất lượng hay sự ổn định.

• Nếu Sơ kết Sprint chỉ là để trình diễn phần mềm, và nhóm của bạn có khả năng phát

hành trong Sprint, hãy sử dụng Sơ kết Sprint cho mục đích nhằm thu thập các phản



hồi về những phần tăng trưởng đã được chuyển giao, Product Backlog, điều kiện kinh

doanh và thúc đẩy hợp tác giữa những người liên quan.

• Trong khuôn khổ nhóm và tổ chức của bạn, rà soát lại khối lượng công việc cần hoàn

thành sau khi nhóm cân nhắc về một phần tăng trưởng “Hoàn thành” ( ví dụ QA, triển

khai). Giúp đỡ nhóm/tổ chức để thay đổi các quy trình và phương pháp nhằm giảm đi

khối lượng các công việc “chưa hoàn thành”.

Lời kết

Trong phần này, chúng ta đã thảo luận về sự hiểu nhầm rằng các Nhóm Scrum cung cấp bản phát

hành tốt nhất vào cuối Sprint, do vậy giới hạn năng lực các nhóm có khả năng thực hiện nhanh

hơn việc phát hành. Trong nội dung này chúng tôi đã chỉ ra rằng Scrum thật sự khuyến khích các

nhóm cải thiện quy trình, cơ sở hạ tầng và phương pháp để phát hành sản phẩm có thể thực hiện

trong suốt cả Sprint.



Product Backlog buộc phải có các User story

Hiều lầm mà ngày hôm nay chúng ta nghiên cứu sẽ lấy được lấy từ nhóm mà chúng tôi làm việc

cùng gần đây. Trong Product Backlog của họ có một hạng mục như sau: “Là một nhà thiết kế, tôi

muốn tạo ra một bản hướng dẫn về phong cách (style), để giúp cho tất cả các nhà phát triển có

thể tự thực hiện được những thiết kế đơn giản.”

Khuôn mẫu phổ biến của một user story như sau: “Là [ai/vai trò gì đó] tôi muốn [hành động/chức

năng gì đó] để [lí do/mục đích gì đó]”. Ngoài ra, có các ví dụ tương tự khác: “Là một khách viếng

thăm, tôi muốn xem trang web trên điện thoại di động, để tôi có thể xem trên đường về nhà” và

“Là một lập trình viên tôi muốn có một API, để tôi có thể truy vấn các lệnh từ backend của ứng

dụng.” Tại sao lại không viết ba hạng mục trên ngắn gọn hơn theo cách như sau: “Tạo hướng dẫn

phong cách”, “Hỗ trợ các thiết bị điện thoại di động”, và “Cho phép truy vấn các lệnh từ backend

(API) ”. Thay vào đó, họ phải tốn công sức để trình bày tất cả mọi thứ trong Product Backlog theo

định dạng là các user story.

Khi chúng tôi thử thách họ thực hiện theo cách trên, họ trả lời rằng đó là cách họ hiểu về Scrum.

Họ đã được giải thích rằng Product Backlog bao gồm các user story. Ngay cả khi cảm thấy như bị

bắt buộc phải thực hiện và khiến nhóm chán nản vì các “nghĩa vụ hành chính” trong việc trình bày

các nhiệm vụ hiển nhiên sang thành các user story.

Ngày hôm nay, chúng ta sẽ giải mã hiểu lầm này bằng cách quay trở lại với mục đích của Product

Backlog và các user story. Trong quá trình tìm hiểu, chúng ta cũng sẽ giải đáp một hiểu lầm khác

có quan hệ mật thiết tới hiểu lầm này; đó là các user story là một phần cần thiết vốn có của Scrum.



Giải mã hiểu lầm

Theo Hướng dẫn Scrum (Scrum Guide), Product Backlog bao gồm tất cả các tính năng, chức năng,

yêu cầu, nâng cấp và sửa chữa mà có ta có thể tạo ra các thay đổi đối với sản phẩm trong các bản

phát hành tương lai. Nói một cách ngắn gọn, Product Backlog bao gồm các tất cả các công việc

cần thiết cho sản phẩm.

Cách mà các Nhóm Scrum quyết định thực hiện công việc này như thế nào sẽ phụ thuộc hoàn

toàn vào nhóm. Họ có thể viết các user story, sử dụng một loạt các từ khoá, viết các đối tượng

người dùng hay thậm chí vẽ ra hình ảnh. Như tôi đã nhấn mạnh trong các bài viết trước, Khung

làm việc Scrum chỉ mô tả những việc cần phải hoàn thành, nhưng lại không nhấn mạnh chúng

cần được hoàn thành như thế nào. Trong thực tế việc phát triển sản phẩm quá phức tạp để đưa

ra một giải pháp hoàn hảo cho tất cả.

Đôi điều về user story

Theo năm tháng, user story đã trở thành một kĩ thuật “đáng tin cậy” đối với hầu hết các nhóm

Scrum. Cách thực hiện của họ hầu như dựa nhiều vào các thực hành được nhắc đến trong sách,

các trang blog (bao gồm cả trang của chúng tôi) và từ các huấn luyện viên. Giống như ý nghĩa

của chúng, các user story được nhắc đến như những “best practice”.Việc sử dụng các user story

trở nên phổ biến trong phương pháp XP (eXtreme Programming) từ năm 1998 bởi Alistair

Cockburn. Cùng với sự nổi tiếng của Scrum, không có gì ngạc nhiên khi user story mang tới Scrum

những ý tưởng khác từ XP (như Điểm và Stand-up).

Khá dễ để hiểu sự thịnh hành của user story. Chúng khác xa với các đặc tả mở rộng về các cách

tiếp cận dựa trên kế hoạch. Thay vì cố nắm bắt mọi chi tiết của một tính năng bằng các yêu

cầu/đầu mục dài cả trang, các user story đơn thuần mô tả bản chất của các tính năng dưới góc

nhìn của một người dùng: “Là người mua hàng, tôi muốn đặt sản phẩm tôi quan tâm vào giỏ

hàng để tôi có thể mua nhiều sản phẩm cùng một lúc”. Sức mạnh của user story nằm ở sự đơn

giản. Theo thiết kế, chúng có khả năng cho phép triển khai mọi chi tiết từ những thứ cần dùng.

Khi mà một Nhóm Scrum bắt đầu làm việc với Product Backlog, chuyển giao các hạng mục như

một phần của các Phần tăng trưởng, họ sẽ cần thảo luận về những việc cần thực thi cho một hạng

mục sắp tới mà user story đó mô tả. Nhưng họ sẽ có một cuộc thảo luận như vậy khi họ chuẩn bị

thực hiện, chứ không phải ngay tại lúc bắt đầu. Các hạng mục trong một Product Backlog cần có

gợi mở để thảo luận trong tương lai, dựa trên các kiến thức, thông tin hữu ích tiếp thu từ lúc đó.

Việc này rất tương đồng với lối tiếp cận thực nghiệm của Scrum trong phát triển sản phẩm và với

Mô hình hình nón về sự bất định (Cone of Uncertainty).



Các kĩ thuật để nắm vững công việc trong Product

Backlog

Chúng ta có thể kết luận rằng không có vấn đề gì với user story. Đây là môt kĩ thuật tốt để nắm

bắt các yêu cầu chức năng, nhưng cần hiểu theo nghĩa “đủ tốt để dùng”, và chúng có chỗ dành

cho các thảo luận sâu hơn trong tương lai. Nhưng Scrum không ép buộc/yêu cầu phải thực hiện.

Các kỹ thuật khác cũng rất tốt, miễn là chúng giúp thúc đẩy ba thứ:

• Chúng giúp cho Product Backlog có-thể-hiểu được đối với Nhóm Scrum và các bên

liên quan. Bên liên quan có thể hiểu được Product Backlog và có cái nhìn tốt về những

điều sắp đến và những việc cần đề xuất.

• Mức độ chi tiết mà những kĩ thuật này yêu cầu cần phù hợp với tính bất ổn trong phát

triển sản phẩm. Các hạng mục cần hoàn thành muộn hơn nên đòi hỏi ít chi tiết hơn các

hạng mục cần phải thực hiện sớm trong một Sprint.

• Chúng nên khuyến khích các giao tiếp, hội thoại liên tục giữa Nhóm Scrum và các bên

liên quan (mà bao gồm cả người dùng)

Một vài công việc có thể được giải trình bằng vài từ khoá hay một câu ngắn gọn. Nếu cả Nhóm

Scrum và các bên liên quan hiểu ý nghĩa của cụm từ “Responsive Website”, tại sao lại phải bắt

buộc phải đưa ra định dạng user story như đã nhắc tới ở phần giới thiệu. Và các công việc kĩ thuật

thì sao? Giống như việc xây dựng một API hay là thiết lập hạ tầng? Nếu được sử dụng ở mức

trung bình, một mô tả về kĩ thuật của một công việc sẽ tốt nếu như chúng được thực hiện theo

cách dễ hiểu nhất, đơn giản nhất. Có rất ít giá trị trong một user story mơ hồ kiểu “Là một công

ty, chúng tôi muốn ba thể hiện của một trang web, do vậy việc nếu một thể hiện bị sập sẽ không

khiến tất cả mọi thứ phải dừng hoạt động”. Nếu câu này cũng được hiểu như sau “Thiết lập Cân

bằng tải cho trang” trên giấy ghi chú. Nhìn tổng thể Product Backlog cần phải dễ hiểu đối với

Scrum và đối với các bên liên quan và điều này không có nghĩa là mọi hạng mục cũng phải như

vậy. Product Backlog vẫn là câu hỏi mở chưa có đáp án.

Dĩ nhiên Product Backlog cần phải dễ hiểu với nhóm Scrum và các bên liên quan nhưng không

cần thiết mọi sản phẩm đơn lẻ đều phải như vậy.

Một Product Backlog tốt cần có sự pha trộn của các hạng mục. Một vài hạng mục là về các nhiệm

vụ kĩ thuật (ví dụ như “Cài đặt một server mới” hoặc “Tạo lịch backup cho cơ sở dữ liệu”), trong

khi các nhiệm vụ khác có thể thuộc về phần chức năng (ví dụ “Người đăng kí có thể lưu trữ các

hạng mục trong danh sách đọc của họ để đọc vào thời điểm khác”). Các user story là một cách

tốt để nắm bắt được các yêu cầu về chức năng nếu chúng nảy sinh tự nhiên ngay từ lúc đã được

nhận định ở trong các cuộc thảo luận, và phải không tạo cảm giác ép buộc hay đó là “một nhiệm



vụ hành chính”. Nếu cảm thấy như bị bắt buộc phải thực hiện theo một khuôn mẫu user story,

bạn cũng nên cân nhắc tới các kĩ thuật khác.

Thủ thuật

• Nếu thấy mình áp đặt các yêu cầu vào một mẫu user story có sẵn, cân nhắc lại mục

đích của story đó. Đây có phải là cách tốt nhất để khiến Product Backlog có-thể-hiểu-

được với cả Nhóm Scrum và các bên liên quan?

• Một mẫu user story chỉ mang tính chất hướng dẫn. Bạn không sai khi viết nhanh gọn

như kiểu “Khách viếng thăm có thể đăng kí nhận tin”;

• Khám phá những cách khác để thể hiện các yêu cầu trong Product Backlog.Thay vì sử

dụng các user story, chúng tôi thích đặt những câu hỏi này hơn cho mọi hạng mục:

“Điều gì biến thành “khả thi” hay “dễ dàng hơn” sau khi thực thi xong hạng mục này?”.

Chúng tôi viết câu trả lời và gọi là “Các Thẻ Tính Năng”. Mặt sau của tấm thẻ bao gồm

2 câu hỏi chi tiết hơn, chúng thường được trả lời trong buổi Lập kế hoạch Sprint hay

buổi họp Làm mịn Product Backlog: “Tiêu chí gì áp dụng với tính năng này?” (Ví dụ:

Tiêu chí chấp nhận) và “Làm thể nào mà chúng ta biết được tính năng này hoạt động

như dự kiến?” (Ví dụ:Các trường hợp thử). Một lần nữa, đây cũng chỉ là một kĩ thuật;

• Bản chất của user story được thể hiện khá rõ ràng trong một môi trường none-IT.

Chúng được dùng để nắm bắt các yêu cầu thuộc về chức năng, bản mẫu không phải

sẽ hữu ích cho tất cả lĩnh vực nào ngoài lĩnh vực IT. Điều này thường đẫn tới các hạng

mục thường định hướng nội bộ, không rõ ràng hoặc được thể hiện khá kì quặc. Ví như

“Là một Marketer, tôi muốn gửi một email tới nhóm X để họ biết được các Sản phẩm

mới” hoặc “Là một thành viên nhóm, tôi muốn viết một bản kế hoạch để thấy cách mà

Y có thể được hoàn thành”. Chúng tôi thích yêu cầu các nhóm none-IT nên tập trung

vào việc đặt các đầu ra mà họ muốn đạt được trong Product Backlog, chứ không phải

việc họ định làm, ví dụ như “Nhắc nhở Nhóm X về các sản phẩm mới” và “Chiến lược

để đạt được Y”.

Lời kết

Trong nội dung này, chúng ta đã giải mã được hiểu lầm về việc phải đưa toàn bộ các hạng mục

Product Backlog theo định dạng user story. Bằng cách mô tả mục đích, đặc tính của Product

Backlog, chúng ta cũng giải đáp hiểu lầm liên quan – rằng user story là một phần cần thiết, vốn

có của Scrum.



Trong Scrum, Product Backlog được ưu tiên

Ngày hôm nay chúng ta cùng khám phá hiểu lầm về việc Product Backlog được “ưu tiên”, “sắp

xếp theo thứ tự ưu tiên” hay “sắp xếp theo tầm quan trọng”.


Hướng dẫn Scrum (Scrum Guide) đã nói ra rằng “Product Backlog là một danh sách có thứ tự” của

tất cả mọi việc cần được đưa vào trong sản phẩm. Đó không phải là một danh sách được ưu tiên

hóa. Sự khác biệt giữa hai cách hiểu dù nhỏ, nhưng hậu quả để lại có thể rất lớn. Trong thực tế,

sau khi đọc bài này bạn sẽ thấy việc sắp xếp thứ tự các hạng mục đơn lẻ dựa theo sự ưu tiên

thường không phải là các tốt nhất để tối đa hoá giá trị.

Để công bằng hơn, hiểu lầm này mô tả cách Scrum không ngừng cải tiến và thay đổi (như được

nêu ra trong Hướng dẫn Scrum). Trước năm 2011, Khung làm việc Scrum đã xác định Product

Backlog như là một “danh sách ưu tiên”. Điều này đã thay đổi sau năm 2011, trong đó phản ánh

rõ ràng hơn cách mà việc sắp xếp thứ tự các hạng mục của Product Backlog được tính toán

Ưu tiên hay thứ tự

James Coplien có một cách nhằm phân biệt rõ ràng hai định nghĩa tưởng chừng như giống nhau

này trở nên rõ ràng hơn, ông lấy ví dụ của việc xây dựng một ngôi nhà ở các vùng nhiệt đới. Tại

đây thường hay xảy ra mưa lớn vào các buổi chiều, do vậy xây một mái che là vô cùng quan trọng



và cần thực hiện càng sớm càng tốt. Product Backlog cho ngôi nhà của bạn sẽ bao gồm tất cả các

hạng mục để tạo thành một ngôi nhà, ví dụ – cửa ra vào, cửa sổ, tường, và hiển nhiên có mái nhà.

Nếu bạn được lệnh sắp xếp Product Backlog đơn lẻ theo sự ưu tiên, mái ngói chắc chắn sẽ nằm

trên đầu danh sách. Chúng nhằm giúp bạn tránh mưa. Nhưng việc sắp đặt này không phải cách

bạn thực sự định xây nhà như thế nào. Bạn không thể xây một mái nhà bền vững mà không có

các bức tường, càng không thể xây tường nếu chưa làm nền móng. Thứ tự của Product Backlog

sẽ bị ảnh hưởng bởi các yếu tố như sự phụ thuộc lẫn nhau, sử dụng hiệu quả nguyên vật liệu, sự

sẵn có của các bên thứ ba và các yếu tố xây dựng. Nếu chỉ sắp đặt dựa trên mức độ ưu tiên sẽ

không giúp bạn có được một ngôi nhà an toàn, ổn định và vững chắc để vượt qua những buổi

chiều mưa to gió lớn.

Tập trung vào Thứ tự (hơn là Ưu tiên) cũng nhấm mạnh vai trò thường trực của một Product

Owner trong việc sắp xếp thứ tự và tái-sắp-xếp thứ tự của công việc khi muốn tối đa hoá giá trị.

Nếu một Product Backlog đơn giản chỉ là một danh sách ưu tiên, rất dễ để đưa đến một kết luận

kiểu “15 tính năng này cần được đặt Ưu tiên cao, 23 tính năng kia thì ở ưu tiên ở mức độ trung

bình, 10 tính năng khác thì ưu tiên thấp hơn”. Đồng thời dễ dẫn đến việc một Product Owner tự

cho rằng, tính năng có ưu tiên cao được chuyển giao ở kì Sprint nào cũng được (không phải là

vấn đề), miễn là chúng được “ưu tiên” chuyển giao trước những hạng mục khác. Việc này nghiễm

nhiên đã đóng lại những cơ hội cho việc tối đa hoá giá trị, giống như ở ví dụ trên về mái nhà.

Chúng ta đã tạo sai lầm ngay từ lúc đặt câu hỏi cho Product Owner về những Hạng mục mà anh

ấy cảm thấy quan trọng nhất, bởi vì chúng sẽ quyết định thứ tự trong Product Backlog – “Tất cả

đều quan trọng đối với tôi. Tôi không muốn phải đưa ra lựa chọn.” là một câu trả lời tệ hại. Bằng

cách đóng khung Product Backlog như một danh sách ưu tiên, chúng ta đã đơn giản hoá vai trò

của một Product Owner. Thay vào đó, chúng ta hay hỏi “Việc sắp xếp thứ tự các hạng mục sẽ giúp

bạn đạt được lợi nhuận nhanh chứ?”

Bằng cách đóng khung Product Backlog như một danh sách ưu tiên, chúng ta đã đơn giản hoá vai

trò của một Product Owner.

Cuối cùng, tập trung vào thứ tự (hơn là ưu tiên) nhấn mạnh rằng khi sắp xếp thứ tự của các hạng

mục cần thực hiện, Product Backlog cần được xem xét một cách toàn diện. Product Backlog thể

hiện thứ tự của việc chuyển giao các hạng mục, do vậy cũng thể hiện cách giá trị được tạo ra theo

thời gian. Mọi thay đổi về thứ tự, tạo ra các thay đổi về giá trị. Nếu chúng ta chỉ đơn giản tập

trung vào ưu tiên, ta sẽ bị “chìm” trong các nỗ lực tối đa hoá giá trị nhỏ, ví dụ như hai hạng mục

được ưu tiên có liên quan tới nhau, “Hạng mục này quan trọng hơn hạng mục kia?”.

Các nhân tố ảnh hưởng tới thứ tự

Có vô số những nhân tố ảnh hưởng tới thứ tự tiềm năng của một Product Backlog, bao gồm:



• Sự phụ thuộc lẫn nhau giữa các hạng mục Product Backlog, sự phụ thuộc giữa các bộ

phận nội bộ với Nhóm Phát triển cũng có thể ảnh hưởng tới thứ tự. Một số hạng mục

nhất định có thể thực thi dễ dàng hơn nếu các hạng mục khác được thực hiện trước.

Hoặc bên cung cấp cần thực hiện một công việc trước khi các hạng mục được hoàn

thành;

• Những rủi ro liên quan tới việc thực thi hoặc không thực thi một hạng mục cụ thể. Có

lẽ việc triển khai một hạng mục sẽ giúp chúng ta học hỏi thêm về sản phẩm mà chúng

ta đang phát triển. Một công nghệ cụ thể có đưa ra nền tảng tốt cho sự phát triển

trong tương lai không? Người dùng có phản hồi tốt với mẫu thử của tính năng mới

trước khi đưa vào công việc thực tế hay không?

• Kiến thức của một Nhóm Phát triển cũng cần tính đến. Việc triển khai một hạng mục

có thể giúp cho nhóm học thêm điều mới cần thiết cho sự phát triển xa hơn. Hoặc một

số hạng mục chỉ có thể thực thi khi Nhóm Phát triển đạt được kiến thức cần thiết;

• Các nhu cầu của khách hàng ảnh hưởng tới thứ tự, bởi vì các hạng mục chỉ ra được nhu

cầu khách hàng sẽ tạo ra các giá trị cho công việc kinh doanh của chúng ta ( ví dụ: gia

tăng doanh số, lợi nhuận, thu hút một nhóm khách hàng mới …);

• Chi phí của việc thực thi cũng ảnh hưởng tới thứ tự. Có lẽ, những việc trong Product

Backlog một khi thực hiện được sẽ đơn giản các công việc của các hạng mục tương lai.

Giống như việc thiết lập các luồng triển khai liên tục, tái cấu trúc các thành thần của

sản phẩm hoặc thực thi các script nhập tự động. Chi phí cũng cần phải cân nhắc tùy

theo các hạng mục cá nhân, bởi vì có thể chi phí phát triển lớn hơn nếu so sánh với độ

ưu tiên/ giá trị/ rủi ro;

• Các điều kiện kinh doanh có thể thay đổi, yêu cầu một vài hạng mục phải thay đổi thứ

tự lên hoặc xuống trong Product Backlog;

• Chi phí trì hoãn cũng ảnh hưởng tới thứ tự. Donald Reinertsen coi đây là chi phí trì hoãn

việc thực thi một tính năng nào đó.

Sameer Patil đã viết một bài sâu hơn về những điều cần cân nhắc khi sắp xếp thứ tự trong Product

Backlog. Thông điệp chính ở đây là chúng ta cần liên tục sắp xếp thứ tự và tái-sắp-xếp thứ tự

nhằm tối đa hoá giá trị được chuyển giao sau mỗi Sprint. Nhưng điều gì được coi là giá trị sẽ phụ

thuộc vào các nhân tố nêu trên. Scrum không và không thể đưa ra một kĩ thuật có thể giải quyết

tất cả các trường hợp nhằm tạo ra được một thứ tự “tốt nhất”.



Thủ thuật

• Là một ScrumMaster, bạn có thể giúp Product Owner đưa ra một thứ tự tối ưu nhất

bằng cách đặt các câu hỏi đúng: “Hạng mục nào đi đúng các mong đợi lớn nhất mà

chúng ta đang thực hiện? ”, “Nếu anh dừng ba Sprint từ bây giờ, hạng mục nào chắc

chắn cần có?”, “Nếu anh chỉ có thể giữ 20% trong Product Backlog, những hạng mục

nào anh sẽ giữ?” Hoặc “Làm thế nào chúng ta tối ưu thứ tự để xác định được các phụ

thuộc?”

• Liberating Structure ‘Min Spec’ có thể được dùng để giúp nhận ra những hạng mục

chắc chắn cần hay không cần thiết cho việc thành công.

• Là một Scrum Master, giúp Product Owner tìm ra các chiến lược khác để sắp xếp thứ

tự các hạng mục Product Backlog, huấn luyện Product Owner giám sát thứ tự thường

xuyên, dựa trên các thông tin hữu ích có phát sinh trong được trong quá trình phát

triển.

• Sơ kết Sprint là một cơ hội tuyệt vời để thanh tra và thay đổi thứ tự Product Backlog

cùng với Nhóm Phát triển và các bên liên quan;

Lời kết

Trong nội dung này, chúng ta đã giải mã hiểm lầm rằng Product Backlog được ”ưu tiên hóa”. Dù

với sự thay đổi nho nhỏ về từ ngữ, nhưng Product Backlog được hiểu là “một danh sách được sắp

xếp theo thứ tự”. Bằng cách mặc định Product Backlog là “danh sách ưu tiên”, chúng ta đã rút gọn

vai trò quan trọng của Product Owner cần thể hiện. Anh ấy/cô ấy cần có trách nhiệm liên tục trong

việc tạo ra thứ tự/ tái-sắp-xếp thứ tự của Product Backlog nhằm tối đa hoá giá trị chuyển giao

trong mỗi Sprint khi triển khai công việc, hay khi có những thông tin hữu ích tìm thấy. Chúng tôi

đã đưa ra một vào thủ thuật giúp bạn hiểu được Product Backlog ở một bức tranh rộng hơn.



ScrumMaster là Huấn luyện viên Agile cấp thấp

Bạn có phải là một ScrumMaster và đã sẵn sàng cho những bước tiếp theo để trở thành một Huấn

luyện viên Agile (Agile Coach)? Bạn có cần một Huấn luyện viên Agile giúp đỡ trong việc thay đổi

mang tính tổ chức trong khi ScrumMaster tập trung vào các Nhóm Scrum? Bạn có kinh nghiệm

làm ScrumMaster và muốn trở thành một chuyên gia huấn luyện Agile sau một khoá học 3-ngày?

Bạn đã từng có ý định thay đổi chức vụ của mình sang thành “Huấn luyện viên Agile” để đạt được

mức lương cao hơn không?

Những nhận định này minh hoạ cho hiểu lầm ngày hôm nay chúng ta sẽ khám phá; ý tưởng về

việc ScrumMaster chính là Huấn luyện viên Agile mới vào nghề (Junior Agile Coach). Hoặc đơn

giản hơn, Huấn luyện viên Agile có xu hướng giải quyết các vấn đề về tổ chức lớn hơn, trong khi

ScrumMaster tập trung nhiều vào các Nhóm Scrum. Chúng tôi đã theo đuổi việc giải thích hiểu

lầm này trong nhiều năm. Trong quá trình đó chúng tôi đã xem xét rất nhiều yếu tố.

Chúng tôi đã viết một số bài báo, thuyết trình ở các hội hảo, cung cấp các buổi workshop và

facilitated workshop; tất cả đề nhằm giải thích về mục đích của ScrumMaster. Trong bài viết này,

chúng tôi sẽ chia sẻ quan điểm của mình về chủ đề này và đưa ra lí do tại sao hiểu lầm này cần

được giải thích rõ ràng.



Hiểu lầm này liên quan tới một số lý do sau:

• Xuất phát từ việc hiểu biết nghèo nàn và không đầy đủ về công việc mà một

ScrumMaster thật sự cần làm và nên làm dựa theo Khung làm việc Scrum;

• Vị trí Huấn luyện viên Agile được đặt cao hơn so với cấu trúc kiểu thứ bậc truyền thống.

Đặc biệt khi bên trong các tổ chức vẫn đi theo lộ trình phát triển sự nghiệp theo chiều

thẳng đứng. Theo cách hiểu như vậy ScrumMaster ở vị trí cấp dưới (junior), Huấn luyện

viên Agile giữ vị trí ở giữa (medior) và Huấn luyện viên doanh nghiệp (Enterprise Coach)

ở vị trí cấp cao (senior).

• Các doanh nghiệp về tư vấn/huấn luyện khuyến khích cách này bởi sẽ dễ dàng điều

chỉnh các chương trình huấn luyện đắt đỏ với mức phí trả theo giờ (có xu hướng gia

tăng). Hãy để ý sự trái nghịch giữa các dịch vụ mà những doanh nghiệp này cung cấp:

khuyên nhủ khách hàng hãy nghĩ theo “cấu trúc theo chiều ngang” nhưng lại quảng bá

cho “cấu trúc theo chiều thẳng đứng” bởi vì mô hình này phù hợp hơn dưới góc độ

thương mại và marketing.

Hiểu lầm này dẫn tới những ranh giới được tạo ra giữa các ScrumMasters và các Huấn luyện viên

Agile. ScrumMaster chỉ “được phép” làm việc trong khuôn khổ nhóm. Do đó sẽ gây khó khăn

trong việc tạo ra văn hoá Scrum thân thiện, những thay đổi cần cho việc áp dụng Scrum thành

công từ đó cũng giảm đi. Huấn luyện viên Agile được trông đợi sẽ thực thi những thay đổi mang

tính tổ chức cần thiết, nhưng lại thất bại bởi kinh nghiệm có hạn và không biết cách xử lý các thay

đổi quản lý từ trong ra ngoài.


Hiểu lầm ngày hôm nay khá dễ dàng để giải mã và chỉ yêu cầu bạn đọc kĩ Hướng dẫn Scrum. Như

những trường hợp hiểu lầm mà chúng tôi đã chỉ ra từ trước tới giờ. Trong Hướng dẫn Scrum đã

đưa ra một mô tả rất rõ ràng về những việc mà ScrumMaster tạo ra cho Nhóm Phát triển, Product

Owner và toàn bộ tổ chức. Điều này bao gồm việc huấn luyện Nhóm Phát triển để trở thành nhóm

tự-tổ chức và liên chức năng, giúp đỡ Product Owner tìm kiếm các kĩ thuật quản lý Product

Backlog hiệu quả, hỗ trợ tổ chức trong việc chuyển giao các sản phẩm có giá trị cao thông qua

quá trình thực nghiệm Scrum. Để điều này diễn ra, ScrumMaster làm việc cùng với các

ScrumMaster khác, các Product Owners cũng như những người khác trong tổ chức.



8 tư thế của ScrumMaster

Một góc nhìn hữu ích khác về vai trò của ScrumMaster được giới thiệu trong tài liệu “8 tư thế của

một ScrumMaster”. Trong đó mô tả những trọng trách khác nhau của ScrumMaster trong 8 tư thế

hay vị trí công việc được liên kết khá chặt chẽ với Hướng dẫn Scrum.

ScrumMaster là …

• Một người loại bỏ các trở ngại – người giúp giải quyết các vấn đề đang cản trở tiến độ

của nhóm, để ý tới năng lực tự tổ chức của Nhóm Phát triển;

• Một hỗ trợ viên – người vẽ ra các giai đoạn, cung cấp những ranh giới rõ ràng mà nhóm

có thể hợp tác. Công việc này bao gồm các trợ giúp các sự kiện Scrum nhằm đảm bảo

họ sẽ đạt được kết quả mong muốn và quan trọng hơn cả là quy trình thực nghiệm

được tối đa hoá;

• Một huấn luyện viên – người giúp cho các cá nhân/ nhóm đội phát triển một cách liên

tục giúp họ chuyển giao các đầu ra giá trị như là một nhóm hoặc như một tổ chức;

• Một nhà giáo – Người đảm bảo Scrum cũng như các kĩ thuật liên quan được hiểu tốt

và có thể được thực hiện;

• Một lãnh đạo đầy tớ (servant leader) – người tạo ra không gian làm việc hiệu quả cho

các nhóm cùng với các bên liên quan để tạo ra các kết quả có giá trị;

• Một nhà quản lý – người chịu trách nhiệm để quản lý các trở ngại (thực), loại bỏ các

lãng phí, quản lý quy trình, quản lý sức khoẻ của nhóm, quản lý ranh giới trong việc tự

tổ chức, và quản lý văn hoá;

• Một Nhân tố thay đổi – người giúp kích hoạt văn hoá nơi mà Nhóm Scrum có thể phát

huy rực rỡ – hoặc mọi cấp bậc của tổ chức;

• Một Mentor – người truyền kiến thức Agile và kinh nghiệm sang cho nhóm.

Các ScrumMaster nên nhận thức các vị trí/vai trò trên cũng như sự đa dạng của các vị trí này. Họ

nên biết khi nào và làm thế nào để áp dụng chúng, phụ thuộc vào các ngữ cảnh khác nhau. Nhưng

mục tiêu của tất cả các vị trí này đó là nhằm giúp mọi người hiểu được tinh thần của Scrum.



Đối mặt với các thử thách “cao cấp”

“Một ScrumMaster giỏi giúp cho Nhóm Scrum sống sót trong văn hoá của một tổ chức. Một

ScrumMaster giỏi giúp thay đổi văn hoá, do vậy các Nhóm Scrum có thể lớn mạnh.”- Geoff Watts.

Cả Hướng dẫn Scrum và “8 tư thế của ScrumMaster” đều cho ta biết về những thử thách của một

ScrumMaster.

• Làm thế nào để giúp mọi người chuyển đổi từ lối tiếp cận dựa trên kế hoạch sang một

quy trình thực nghiệm công bằng hơn cho sự phức tạp của công việc mà họ làm?

• Làm thế nào để thúc đẩy tính minh mạch, thanh tra và thích nghi trong một tổ chức

“đóng” truyền thống?

• Làm thế nào để huấn luyện các tổ chức theo cách hợp tác “thực sự” với các Nhóm

Scrum của họ?

• Làm thế nào để quản lý được các giới hạn của việc tự tổ chức trong những môi trường

quen theo lối mệnh lệnh?

• Làm thế nào để tạo ra một môi trường “an toàn để học tập và thất bại” từ thực nghiệm?

• Làm thế nào để truyền bá văn hoá Scrum để các Nhóm có thể lớn mạnh?

Là một ScrumMaster nghĩa là phải đối diện với những thức thách khó khăn đó và ảnh hưởng văn

hoá tổ chức theo một cách mà…

• Thành công nhóm được đánh giá cao hơn thành công cá nhân

• Cải tiến liên tục và khuyến khích sự thực nghiệm;

• Khuyến khích “các hợp đồng Agile”;

• Hỗ trợ sự ổn định của nhóm;

• Thưởng theo hành vi hơn là thành tích cá nhân;

Việc tạo ra môi trường Scrum thân thiện sẽ phụ thuộc vào ScrumMaster. Thật may mắn là

ScrumMaster đang ở vị trí hoàn hảo để thực hiện công việc này bởi anh/cô ấy có thể thay đổi từ

trong ra ngoài.

Là một phần của Nhóm Scrum, ScrumMaster biết chính xác những điều cần được thay đổi và tại

sao việc thay đổi này là cần thiết. Họ giúp các nhóm tìm ra các trở ngại đang kéo họ lại, và những

cách thức mà nhóm có thể chuyển giao nhiều giá trị hơn với Scrum. Vị trí này cũng hoàn hảo cho



họ để làm việc với bộ phận nhân sự để tìm ra các hoạt động phù hợp hơn, tốt hơn với Scrum.

Hoặc nhằm giúp cho bộ phận bán hàng chuyển đổi các hợp đồng với “giá cố định/ quy mô cố

định” sang các hợp đồng Agile thân thiện hơn. Hoặc nhằm gia tăng sự hợp tác giữa các Nhóm

Scrum và các bên liên quan. Làm việc với các ScrumMaster khác, họ sẽ thúc đẩy các thay đổi mang

tính tổ chức cần thiết, bằng cách ảnh hưởng lên hệ thống từ trong ra ngoài. Từ góc nhìn của

Nhóm Scrum, ScrumMaster thực sự là một “Nhà Hỗ trợ Thay đổi”.

“Các cơ hội của việc áp dụng Scrum thành công sẽ gia tăng nhanh chóng khi bạn coi ScrumMaster

như là những Nhà Hỗ trợ Thay đổi từ trong ra ngoài!”

Khi các tổ chức lựa chọn thực hiện quy trình thực nghiệm lớn với Scrum thì gần như sẽ không cần

sự có mặt của các Huấn luyện viên Agile. Thay vào đó, ScrumMaster nên có mặt và hỗ trợ nhằm

thúc đẩy quy trình thực nghiệm trên mọi cấp bậc trong tổ chức. Nếu họ có thể, và nếu họ làm

điều đó, không có một vai trò nào khác là cần thiết để giúp các tổ chức tạo ra các kết quả có giá

trị với Scrum.

“Khi các tổ chức chọn làm việc với Scrum, họ gần như sẽ không cần thiết phải có các Huấn luyện

viên Agile.”

Vậy chúng ta có nên sa thải tất cả các HLV Agile không?

Không, bạn không nên. Bằng cách giải thích kĩ lưỡng hiểu lầm rằng ScrumMaster là “HLV Agile

cấp thấp”, chúng tôi không đánh đồng nó với việc HLV Agile không có giá trị. Chúng tôi nói rằng

sự cần thiết cho các HLV Agile sẽ giảm đi đáng kể khi các ScrumMaster được phép thể hiện vai

trò vốn có của mình. Chúng tôi cũng muốn nói rằng, các sự khác biệt liên quan tới thứ bậc mà

chúng ta hay thấy giữa các HLV Agile và các ScrumMaster đều xuất phát từ việc thiếu hiểu biết về

Scrum.

Trong khi các ScrumMaster sử dụng cách tiếp cận “từ trong ra ngoài”, thì các HLV Agile sử dụng

lối tiếp cận “từ ngoài vào trong”. Hiển nhiên chúng ta sẽ thích cách tiếp cận đầu tiên khi thực hiện

thay đổi tổ chức. Nhưng cả hai cách đều thêm giá trị cho tổ chức dưới góc nhìn thay đổi thuộc tổ

chức. Chúng chỉ khác về góc nhìn trong cách tạo ra môi trường Scrum thân thiện (nếu đó là mục

tiêu của HLV Agile).

Sử dụng phương pháp từ ngoài vào trong chắc chắn sẽ hiệu quả, nhưng cũng cực kỳ khó khăn.

Kinh nghiệm của chúng tôi cho thấy rằng nhiều HLV Agile (bên ngoài) thường đưa ra ít giá trị hơn

khi thực hiện cách này. Họ khá bất lực để ảnh hưởng lên các thay đổi, và chỉ hiểu biết ở bề ngoài

của công việc bên trong Nhóm Scrum (chỗ các giá trị được tạo ra). Họ không phải là một phần

của nhóm, thiếu sự hỗ trợ cần thiết từ ban quản lý và không có kiểu kinh nghiệm cần thiết để

thúc đẩy thay đổi từ “Ngoài vào trong”.



Hơn nữa, nhiều HLV Agile hầu như ít có kinh nghiệm với Scrum hoặc làm ScrumMaster. Nhưng

việc huấn luyện ScrumMaster thường xuyên là công việc hằng ngày của họ.

“Thực tế là, hầu hết các HLV Agile là những ScrumMaster non tay nghề”

Vì vậy, lời khuyên của chúng tôi cho các tổ chức đó là:

• Tập trung vào thúc đẩy các ScrumMaster nhằm hỗ trợ các thay đổi “từ trong ra ngoài”.

Hỗ trợ các ScrumMaster trong việc tạo ra các nhóm tuyệt vờ, sáng tạo ra các sản phẩm

tuyệt vời. Giúp cho họ tạo ra các trải nghiệm cũng như công cụ để cùng nhau thực hiện

công việc này;

• Loại bỏ những “HLV hải âu” – những người có thể đến và gây náo loạn khắp nơi, thậm

chí có thể “bay” tới vị khách hàng tiếp theo mà để lại đằng sau một đống lộn xộn;

• Nếu bạn thật sự muốn thuê một HLV Agile ngoài các ScrumMaster đã sẵn có trong

công ty, hãy đảm bảo rằng họ có kinh nghiệm thực sự đối với việc ảnh hưởng những

thay đổi “từ ngoài vào trong”. Đảm bảo họ tập trung nỗ lực vào việc giúp đỡ nhóm và

ScrumMaster có thể tự thay đổi. Đừng tạo ra sự phân biệt không có thực giữa “thay đổi

ở cấp quản lý” ( bởi các HLV Agile) và “thay đổi ở cấp nhóm” (bởi ScrumMaster).

Nếu như chúng ta dùng Kanban/XP/DevOps thì sao?

Scrum không chỉ là một khung làm việc để cải thiện năng lực tổ chức và tạo ra nơi làm việc gắn

kết mọi người cùng với các bên liên quan để tạo ra các sản phẩm tuyệt vời. Như Geoff Watts mô

tả “Scrum có mục đích điều khiển năng lượng của các nhóm gắn kết, tự chủ và tự tổ chức – những

người có trách nhiệm chuyển giao và hợp tác trực tiếp với các khách hàng”.

“Scrum bản thân không chỉ là một mục tiêu. Dù bạn chọn bất cứ loại Khung làm việc hoặc Phương

pháp nào, bạn sẽ luôn phải có sự thay đổi liên quan tới tổ chức. Những ai đang ở vị trí tốt nhất để

ảnh hưởng lên các thay đổi này, sẽ là một phần của nhóm đang làm việc. Họ có thể có các chức

danh như ScrumMaster, Kanban God, XP Dude, DevOps Guru hoặc không có chức danh gì: chúng

tôi không quan tâm.

“Thay đổi tổ chức nên được thực hiện từ trong ra ngoài bởi đội ngũ thật sự thuộc về các nhóm”



Lời kết

Trong bài này, chúng ta đã giải mã hiểu lầm rằng “ScrumMaster là một HLV Agile cấp thấp”. Thay

đổi hiệu quả sẽ xuất phát từ trong ra ngoài. ScrumMaster là một phần của Nhóm Scrum, là vị trí

tốt hơn cả để thúc đẩy thay đổi hơn là một HLV Agile (người ngoài). Điều này đã được mô tả

trong Hướng dẫn Scrum như là vai trò của một ScrumMaster.

Khi các tổ chức chọn thực thi một quy trình thực nghiệm thông qua Scrum, họ sẽ không cần có

các HLV Agile. Thay vào đó, các ScrumMaster nên được thông qua và được hỗ trợ để thúc đẩy

quy trình thực nghiệm trên mọi cấp bậc ở trong tổ chức. Nếu họ có thể, và nếu họ thực hiện thì

không có vai trò nào là cần thiết để giúp các tổ chức này tạo ra đầu ra có giá trị thông qua Scrum

nữa.



ScrumMaster giải quyết MỌI VẤN ĐỀ

Hiểu lầm này là về cách giải quyết vấn đề đang cản trở Nhóm Phát triển thực hiện công việc của

họ. Từ những vấn đề như hỏng bộ phát wifi cho tới các yêu cầu liên quan đến từ các cuộc họp

bên ngoài nhóm. Từ làm rõ các công việc không hiểu rõ tới giải quyết mâu thuẫn nội bộ.

Chúng tôi đã gặp khá nhiều nhóm mà ở đó ScrumMaster phải dành toàn bộ thời gian để giải

quyết các vấn đề nêu trên, hay nói cách khác là giải quyết các “trở ngại”. Một vài ScrumMaster đã

mất rất nhiều thời gian để thiết lập “Impediment Board” (bảng các trở ngại) và mời các thành viên

Nhóm Phát triển điền thêm các cản trở mới vào để “xử lý” chúng. Ngày hôm nay, chúng ta sẽ tìm

hiểu khi hiểu lầm rằng trách nhiệm của ScrumMaster là giải quyết mọi vấn đề đang cản trở Nhóm

Phát triển.


Trong Hướng dẫn Scrum (Scrum Guide) mô tả các “dịch vụ” khác nhau mà một ScrumMaster cung

cấp. Một trong số những đó là loại bỏ các trở ngại xuất hiện trong quá trình làm việc của Nhóm

Phát triển. Trước tiên, chúng ta thấy việc này dường như củng cố cho vấn đề của ngày hôm nay.

Nhưng trở ngại là một từ khoá quan trọng ở đây. Những cản trở dường như xuất hiện quá thường

xuyên, do đó bất cứ vấn đề gì xuất hiện trong Sprint sẽ mặc định được coi là “chướng ngại vật”.

Nhưng đây không phải là cách mà chúng ta hiểu về trách nhiệm này của ScrumMaster.



Điều gì tạo ra các “chướng ngại vật”?

“Chướng ngại vật” là những vấn đề gây cản trở cho tiến trình của một Nhóm Phát triển và nằm

ngoài khả năng giải quyết của họ. Điều này có nghĩa rằng, các trở ngại có mối quan hệ mật thiết

tới một khái niệm quan trọng khác của Scrum đó là Tự tổ chức (self-organization). Những ý nghĩa

đứng đằng sau các trách nhiệm này đó là – phát triển phần mềm là nỗ lực rất phức tạp và khó

tiên lượng – nhiều loại vấn đề không mong đợi có xu hướng xảy ra trong Sprint. Những vấn đề ví

dụ như:

• Thành viên nhóm bị ốm

• Các vấn đề với môi trường phát triển

• Một chiếc máy tính bị hỏng

• Product Owner vắng mặt

• Mâu thuẫn trong nội bộ nhóm

• Bug xảy ra trong môi trường sản xuất

Một yêu cầu được đặt ra cho các Nhóm Phát triển, đó là sử dụng chuyên môn, khả năng sáng tạo

và trí thông minh để giải quyết các vấn đề. Trong Scrum, bản chất tự tổ chức của một nhóm có

thể hiểu bằng đó là năng lực giải quyết các vấn đề khi họ gặp phải mà không phải phân bổ quyền

giải quyết vấn đề đó cho người ngoài nhóm. Với cách đó, chúng tôi muốn giải thích các cản trở

như những vấn đề mà khi được giải quyết xong sẽ cải thiện các cơ hội, do đó Nhóm Phát triển có

thể tự giải quyết các vấn đề tương tự trong tương lai.

Nhiều dạng vấn đề có thể giải quyết được bởi Nhóm Phát triển, như làm rõ các đặc tả không rõ

ràng, sửa lỗi trên sản phẩm đã triển khai hoặc thậm chí đưa ra giải pháp cho một mâu thuẫn trong

nhóm.

Sự khác nhau là rất nhỏ nhưng hậu quả thì không. Liệu một Nhóm Phát triển có thật sự tự tổ chức

khi tất cả các vấn đề xảy đến đều cần ScrumMaster giải quyết? Điều gì xảy đến khi chỉ ScrumMaster

có thể giúp Nhóm Phát triển làm rõ với Product Owner các đặc tả chưa rõ ràng, hoặc phân tách

một công việc có khối lượng quá lớn? Điều gì sẽ xảy đến khi chỉ ScrumMaster mới có thể giải

quyết các vấn đề liên quan tới cơ sở hạ tầng? Một ScrumMaster giải quyết hầu hết các vấn đề xảy

đến thì không phải là đang giúp đỡ cho nhóm. Mà anh ấy đang chủ động cản trở khả năng (sự

trưởng thàng) của Nhóm Phát triển trong việc giải quyết vấn đề của riêng họ.



Các vấn đề và trở ngại trong thực tế

Sẽ rất mơ hồ nếu như toàn bộ bài viết này dành để nói về “tự tổ chức” và “các trở ngại”, do vậy

chúng ta sẽ đi vào tìm hiểu thông qua các ví dụ thực tế.

VÍ DỤ #1: Các vấn đề liên quan tới cơ sở vật chất / hạ tầng

Giả sử một Nhóm Phát triển gặp vấn đề về hạ tầng. Nhóm không thể triển khai các ứng dụng, do

vậy họ phụ thuộc vào một nhóm khác. Vào ngày trước buổi Sơ kết Sprint, Nhóm Phát triển có vấn

đề với một bản triển khai. Trở ngại này được đưa ra trong buổi Scrum Hằng ngày, ScrumMaster

đã phải tự mình giải quyết vấn đề này.

Vấn đề này chỉ là một triệu chứng của một trở ngại sâu xa hơn; đó là khả năng không thể tự

giải quyết của Nhóm hoặc ít nhất giải quyết vấn đề liên quan tới việc triển khai. Bằng cách chỉ giải

quyết vấn đề khi cấp bách, ScrumMaster không thực sự giúp cho Nhóm Phát triển cải thiện khả

năng giải quyết các vấn đề tương tự. Thay vào đó, ScrumMaster có thể chỉ ra trở ngại thực sự

bằng cách giúp Nhóm tìm ra các cách giải quyết cho những vấn đề đó. Một giải pháp có thể là

bổ sung kĩ năng hoặc nhân sự cần thiết vào nhóm để giải quyết vấn đề. Một giải pháp khác có

thể cho Nhóm Phát triển thiết lập và quản lý cơ sở hạ tầng của riêng họ (DevOps). Một giải pháp

“low-tech” hơn đó là tạo ra các kênh giao tiếp giữa Nhóm Phát triển và người có khả năng giải

quyết vấn đề với việc triển khai (ví dụ như các liên lạc viên). Dù gải pháp là gì đi chăng nữa, chúng

nên xuất phát từ Nhóm Phát triển với sự trợ giúp của ScrumMaster.

VÍ DỤ #2: Mâu thuẫn nội bộ

Một ví dụ khác. Giả sử Nhóm Phát triển đang phải đối mặt với sự mẫu thuận giữa hai thành viên.

Thay vì nói về bản thân những vấn đề, ScrumMaster được giao cho nhiệm vụ giải quyết mâu

thuẫn. Trở ngại thật sự ở đây là việc nhóm không có khả năng giải quyết mâu thuẫn của mình. Có

lẽ bên trong nhóm có tâm lý không an toàn để có thể nói về việc đó. Hoặc mọi người không biết

cách để nói ra mâu thuẫn hay không dũng cảm để thực hiện điều đó. Bằng cách chỉ giải quyết

vấn đề, ScrumMaster không giúp nhóm phát triển kĩ năng giải quyết các vấn đề nếu nó tái diễn

trong tương lai. Thay vào đó, ScrumMaster có thể hỗ trợ tổ chức một phiên “giải quyết căng

thẳng”, trong phiên đó, những cảm xúc khó chịu được nêu ra và nhóm sẽ dàn xếp cùng nhau

(thay vì được giao cho vấn đề). ScrumMaster có thể làm mẫu cho hành vi cần thiết để giải quyết

mâu thuẫn, như hỏi các câu hỏi mở, thể hiện sự cảm thông và tìm ra điểm chung, sau đó mời các

thành viên nhóm làm điều tương tự.

VÍ DỤ #3: Thiếu việc

Ví dụ cuối cùng, giả sử Nhóm Phát triển thấy rằng một nửa thành viên không có gì để làm. Điều

này được đưa ra như một trở ngại trong buổi Scrum Hằng ngày, khi mà ScrumMaster được giao



thêm nhiệm vụ là tìm công việc cho họ làm. Trở ngại thật sự ở đây là Nhóm Phát triển hiển nhiên

không hợp tác nhằm thúc đẩy tất cả mọi người đóng góp, để đạt được Mục tiêu Sprint. Thay vì

tìm kiếm công việc, ScrumMaster nên điều tra xem điều gì đang thật sự xảy ra trong nhóm. Anh

ấy sẽ chỉ ra điều này trong một chủ đề của buổi Cải tiến Sprint. Hoặc có lẽ Nhóm Phát triển không

biết đến các phương pháp có thể thúc đẩy việc hợp tác, ví dụ như lập trình cặp hoặc theo nhóm,

hay chia nhỏ công việc, hoặc kiểm tra công việc của nhau. Hoặc có thể trong nhóm có những

người đang cư xử như là “trụ cột của nhóm” và làm số lượng lớn công việc, và những người còn

lại thực hiện các công việc nhỏ nhặt khác. Dù theo cách nào đi chăng nữa, ScrumMaster có thể

giúp Nhóm Phát triển trở nên tự tổ chức hơn bằng cách tìm ra các giải pháp cho những trở ngại

đó chứ không phải cho các vấn đề được nêu ra trong Scrum Hằng ngày.

Trở thành một ScrumMaster thành công có nghĩa là…

Các ScrumMaster thành công giúp cho Nhóm Phát triển phát triển được khả năng giải quyết các

vấn đề của riêng họ. Đây là điều mà các nhóm phải học và ScrumMaster giúp họ thực hiện được

điều đó. Những điều có thể được coi là trở ngại ở Sprint 1 rất có thể sẽ trở thành vấn đề thật sự

mà nhóm có thể dễ dàng xử lý trong Sprint 5. Nếu bạn muốn biết bạn có đang làm tốt nhiệm vụ

của một ScrumMaster hay không hãy giám sát năng lực của một Nhóm Phát triển khi họ giải

quyết các vấn đề của riêng họ trong một thời gian. Nếu thấy năng lực có tiến triển, bạn đang làm

rất tốt công việc của mình.



Vậy là ScrumMaster không bao giờ giải quyết các vấn

đề?

Liệu điều này có đồng nghĩa với việc ScrumMaster không giải quyết vấn đề gì? Dĩ nhiên là không.

ScrumMaster vẫn là một phần của Nhóm Scrum. Một ScrumMaster có thể sẽ phải sửa bộ phát

wifi bị hỏng nếu Nhóm Phát triển đang hoàn toàn tập trung vào giải quyết một vấn đề lớn liên

quan tới kĩ thuật. Hoặc một ScrumMaster có thể hỗ trợ Nhóm Phát triển trong buổi họp phân

tách công việc để họ có thể dễ dàng thực hiện trong Sprint, Giải quyết các vấn đề cho Nhóm Phát

triển hoàn toàn có thể chấp nhận được nếu được thực hiện đúng mục đích, nhưng cần lưu ý không

làm điều này quá thường xuyên. Trước khi giải quyết một vấn đề, cân nhắc nếu như bạn đang

thật sự giúp cho Nhóm Phát triển gia tăng năng lực giải quyết các vấn đề tương tượng của riêng

họ. Hãy nhớ rằng “Một ScrumMaster nên Gợi mở, chứ không Giải quyết.”

Thủ thuật

• Đừng đợi đến buổi Scrum Hằng ngày mới đưa ra các trở ngại. Hãy coi Scrum Hằng

ngày là cơ hội tối thiểu nhất để thảo luận các trở ngại. Những cản trở thực sự tới tiến

trình của nhóm cần được thảo luận ngay lập tức.

• Bất cứ khi nào một chướng ngại tiềm năng được nêu ra, hãy cân nhắc những việc có

thể xảy đến nếu như bạn không làm gì cả. Sẽ có ai khác trong Nhóm Phát triển lo việc

này chứ?

• Không có vấn đề gì nếu phải dùng tới “Impediment Board”, nhằm giúp minh bạch

những trở ngại đã được loại bỏ. Nhưng cần đảm bảo rằng chúng được dùng cho những

trở ngại thực, chứ không phải dành cho bất cứ vấn đề gì mà Nhóm Phát triển thấy cần

phải “đùn đẩy” sang cho ScrumMaster. Ngoài ra, hãy đảm bảo rằng chiếc bảng là của

toàn bộ Nhóm Scrum, chứ không phải dành riêng cho ScrumMaster.

• Không phải mọi trở ngại đều quan trọng. Sử dụng Mục tiêu Sprint như một kim chỉ

nam hướng dẫn. Là ScrumMaster, bạn đặc biệt nên làm việc với các trở ngại đang có

khả năng cản trở Nhóm Phát triển đạt được Mục tiêu Sprint. Tập trung vào những trở

ngại trước khi giải quyết bất cứ thứ gì khác;

• Hãy dũng cảm và sáng tạo trong việc xoá bỏ các trở ngại. Hãy nhớ “Một ScrumMaster

giỏi sẽ thúc đẩy các ý kiến nhằm xoá bỏ những cản trở tới năng suất nhóm. Một

ScrumMaster vĩ đại sẽ luôn sẵn sàng để xin được tha thứ.” (Geoff Watts – Scrum

Mastery)



• Một trong những công cụ mạnh mẽ nhất của một huấn luyện viên là sử dụng quyền

im lặng. Giữ im lặng và quan sát điều gì sẽ xảy đến tiếp theo. Đó cũng là cách mà

ScrumMaster nên hành động. Như là một thí nghiệm bạn không cần làm gì và hãy quan

sát điều gì sẽ xảy ra.

• Hợp tác với Product Owner.Các trở ngại thường liên quan tới các vấn đề như quản lý

sản phẩm, việc hợp tác giữa bên liên quan và nhà cung ứng. Product Owner là nhân tố

quan trọng trong vấn đề này. Do vậy, hãy đảm bảo duy trì mối quan hệ gắn bó với

Product Owner.

• Hiểu sự khác biệt giữa “cản trở” (block) và “trở ngại” (impediment). Một cản trở chỉ ảnh

hưởng tới nhiệm vụ đơn lẻ, trong khi các trở ngại hoạt động như một chiếc dù với việc

ảnh hưởng từ từ làm chậm dần cả quá trình. Thường xuyên, Nhóm Phát triển tự mình

có thể giải quyết các cản trở trong khi các trở ngại cần được xử lý bởi ScrumMaster

(IIan Goldstein – Scrum Shortcuts with cutting corners)

• Tập trung vào các vấn đề thực sự, không phải vấn đề xảy đến đầu tiên. Hỏi các câu hỏi

nhằm hiểu hơn về tình huống. Kiểm tra xem đó thực sự là trở ngại hay là một cơ hội

để học tập cho Nhóm Phát triển

“Tập trung vào vấn đề thực sự, không phải vấn đề xảy đến đầu tiên”

Lời kết

Ngày hôm nay chúng ta đã giải mã một hiểu lầm khác đó là ScrumMaster chịu trách nghiệm giải

quyết mọi vấn đề có thể cản trở tiến trình của Nhóm Phát triển trong việc đạt được Mục tiêu

Sprint. Thay vào đó, ScrumMaster nên giúp Nhóm Phát triển gia tăng khả năng tự giải quyết các

vấn đề tương tự (tự-tổ chức). ScrumMaster thực hiện điều đó bằng cách chỉ ra các vấn đề đang

“hoạt động như một chiếc dù” đối với nhóm, không chỉ xuất hiện bất cứ lúc nào. Trong nội dung

này chúng tôi đã đưa ra vài ví dụ cụ thể và làm rõ các loại vấn đề mà nhóm nên giải quyết, cũng

như các vấn đề thực sự là “các trở ngại” được chọn bởi chính ScrumMaster. Chúng tôi cũng cung

cấp một vài mẹo cho bạn để ứng dụng.



ScrumMaster phải có mặt trong suốt buổi Scrum

Hằng ngày

Scrum được định hướng là một khung làm việc đơn giản nhưng hiệu quả để phân phối các sản

phẩm phức tạp. Scrum không phải là một giải pháp cho mọi vấn đề, một lời giải tuyệt đối cho

những vấn đề hóc búa hay một phương pháp toàn diện. Thay vào đó, Scrum đề ra những giới

hạn tối thiểu trong việc nhóm có thể tự tổ chức để giải quyết một vấn đề phức tạp nào đó theo

hướng thực tiễn, quan sát và thực hành thay vì chỉ lý thuyết chung chung. Sự tối giản này chính

là sức mạnh lớn nhất của Scrum, nhưng cũng chính là nguồn cơn của rất nhiều lời đồn đoán và

sự hiểu lầm xung quanh nó. Trong loạt bài viết này, chúng tôi – Christiaan Verwijs và Barry

Overeem – sẽ “giải mã những hiểu lầm” của bạn, sẽ đề cập đến những đồn đoán và hiểu lầm phổ

biến nhất. Thea Schukken là tác giả của những minh họa tuyệt vời cho loạt bài viết này.

Hiểu nhầm về việc ScrumMaster phải xuất hiện trong

suốt buổi Scrum Hằng ngày

Mọi người thường hiểu nhầm về việc ScrumMaster phải luôn xuất hiện trong suốt buổi Scrum

Hằng ngày. Ở một vài nhóm, ScrumMaster được giao nhiệm vụ tổ chức các buổi Scrum Hằng

ngày. Trong khi, các đội khác cảm thấy rằng ScrumMaster cần đứng ra giải quyết các trở ngại. Dù

bằng cách nào thì luôn đòi hỏi sự hiện diện của ScrumMaster.



Hướng dẫn về Scrum nói gì?

Theo như Hướng dẫn Scrum (Scrum Guide), Nhóm Phát triển chịu trách nhiệm về các buổi Scrum

Hằng ngày. Scrum được xây dựng dựa trên sự quan sát rằng phát triển sản phẩm là một tiến trình

khó khăn và phức tạp. Sự phức tạp này thể hiện rõ ở tính khó đoán định cao. Ngay cả như trong

quy mô của một Sprint riêng lẻ thì mọi thứ cũng rất có thể không theo như kỳ vọng. Một thành

viên cốt cán của nhóm bị ốm trong Sprint. Một lỗi nghiêm trọng được phát hiện và cần phải sửa

chữa ngay lập tức. Hay một ý tưởng mới nảy ra và phù hợp hơn với Mục tiêu của Sprint. Giao tiếp

thường xuyên trong Nhóm Phát triển là rất quan trọng để đối phó với những thay đổi ngay khi

chúng xảy ra.

Các buổi Scrum Hằng ngày là một trong những ranh giới của Scrum và đem đến cho Nhóm Phát

triển ít nhất một cơ hội mỗi ngày để cập nhật công việc và lập kế hoạch cho ngày tiếp theo. Cả

nhóm sẽ làm việc cùng nhau như thế nào cho đến buổi Scrum Hằng tiếp theo để đạt được Mục

tiêu Sprint? Kết quả của buổi Scrum Hằng ngày là một bản kế hoạch cho mỗi ngày và có thể là

một vài thay đổi với Sprint Backlog để đạt được Mục tiêu Sprintl. Mặc dù ScrumMaster có thể xuất

hiện để tổ chức Scrum Hằng ngày, tuy nhiên điều này là không bắt buộc. ScrumMaster phải đảm

bảo rằng một buổi Scrum Hằng ngày diễn ra, nhưng Nhóm Phát triển là người chịu trách nhiệm

thực hiện cuộc họp. Không ai ngoài Nhóm Phát triển và có thể là cả ScrumMaster được phép

tham gia. Nếu Scrum Hằng ngày dẫn đến quyết định ảnh hưởng đến người khác (ví dụ như

Product Owner), họ có thể được Nhóm Phát triển hỏi ý kiến sau.

Do vậy ScrumMaster có thể tham gia Scrum Hằng ngày, nhưng điều này là không bắt buộc trong

Scrum.

Các vấn đề tiềm năng

Khi mà ScrumMaster xuất hiện trong mọi buổi Scrum Hằng ngày, sẽ có một vài “dấu hiệu” chỉ ra

những vấn đề trong việc áp dụng Scrum:

• ScrumMaster hoạt động như là một quản lý của nhóm, và sử dụng Scrum Hằng ngày

để chia sẻ công việc và ra quyết định thay cho Nhóm Phát triển;

• Nhóm Phát triển không hỗ trợ hoặc cam kết với Scrum, và cần ScrumMaster để “đảm

bảo chắc chắn rằng điều đó xảy ra”. Trong trường hợp này, cần xác định được động lực

sâu xa đằng sau của nhóm để làm việc với Scrum;

• Nhóm Phát triển dựa vào ScrumMaster để tạo điều kiện giao tiếp trong nhóm. Điều

này có thể gây cản trở khả năng học cách tự tổ chức của Nhóm Phát triển.


https://hocvienagile.com/tai-nguyen/huong-dan-scrum/


• ScrumMaster sử dụng Scrum Hằng ngày để cảm thấy ý nghĩa. Là một người đầy tớ lãnh

đạo, sự thành công của một ScrumMaster thường bộc lộ theo những cách gián tiếp

(phát triển theo thời gian, bầu không khí thân thiện, học hỏi). Với một vài ScrumMaster,

Scrum Hằng ngày tạo cơ hội cho họ chiếm lấy sân khấu chính nhằm tạo ra đóng góp

nổi bật – ngay cả khi điều đó không có lợi cho Nhóm Phát triển vì những lý do kể trên.

Thủ thuật

Những thủ thuật sau đều rất hữu ích để khiến Scrum Hằng ngày (cũng như ScrumMaster) hiệu

quả hơn:

• Nhấn mạnh lại mục đích của Scrum Hằng ngày ngay từ lúc ban đầu.

• Lùi lại (theo đúng nghĩa đen) phía sau trong buổi Scrum Hằng ngày, đặt bản thân bên

ngoài Nhóm Phát triển

• Giới hạn bản thân chỉ đặt những câu hỏi mở xuyên suốt Scrum Hằng ngày;

• Giới hạn bản thân chỉ đặt những câu hỏi liên quan đến sự minh bạch, kiểm tra và thích

nghi: “Cách nhìn mới này ảnh hưởng đến Mục tiêu Sprint của chúng ta như thế nào?”,

“Công việc mới nào cần phải được minh bạch?” hoặc “Chúng ta có thể làm gì hôm nay

để giúp nhau đạt được Mục tiêu Sprint?”

• Đừng quá chủ động thực hiện Scrum Hằng ngày bằng việc yêu cầu mỗi thành viên trả

lời 3 câu hỏi của Scrum Hằng ngày. Thay vào đó, hãy để mọi người tự quyết định ai là

người tiếp theo;

• Đừng tham dự vào Scrum Hằng ngày. Hãy quan sát những gì xảy ra sau đó;

• Nhờ ai đó trong Nhóm Phát triển hỗ trợ triển khai Scrum Hằng ngày;

• Hãy để Nhóm Phát triển lựa chọn thời gian bắt đầu và địa điểm. Đây là sự kiện của họ

vì vậy hãy để họ chọn thời điểm phù hợp nhất với mình. Điều này làm tăng cảm giác

được tự chủ và khuyến khích nhóm bắt đầu đúng giờ.

Lời kết

Trong nội dung này, chúng tôi đã mô tả hiểu lầm về việc Scrum Master phải xuất hiện trong buổi

Scrum Hằng ngày. Chúng tôi đã cung cấp cái nhìn từ Hướng dẫn Scrum, mô tả một vài ví dụ về

vấn đề có khả năng xảy ra trong việc áp dụng Scrum và chia sẻ những mẹo về việc thực hiện

Scrum Hằng ngày hiệu quả hơn.



Nguồn tham khảo

Nhiều phần trong tài liệu được dịch và tham khảo từ linkedin.com và medium.com theo loạt bài

viết của Christiaan Verwijs và Barry Overeem về “giải mã những hiểu lầm” về Scrum, đề cập đến

những đồn đoán và hiểu lầm phổ biến nhất. Thea Schukken là tác giả của những minh họa tuyệt

vời cho loạt nội dung này.

Barry Overeen và Christiann Verwjis, những người “giải mã” các hiểu lầm về Scrum.


Bìa Ebook - Học viện Agile

Documents

Transcript of Bìa Ebook - Học viện Agile