8 HIỂU LẦM VỀ SCRUM Khiến doanh nghiệp Mất Tiền - Người - Thời gian và Cách giải quyết

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.. “Bắt bệnh” hiể

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

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

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”

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

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”

Giải mã hiểu lầm

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: