Agile Product Ownership in a nutshell

Hãy nói về phát triển phần mềm Agile từ góc nhìn của Product Owner.
Đây là Pat. Cô ấy là một product owner. Cô có một tầm nhìn về sản phẩm mà cô
rất đam mê. Cô không biết chi tiết về những gì sản phẩm của mình sẽ làm, nhưng
cô biết lý do tại sao chúng ta đang xây dựng sản phẩm này, nó sẽ giải quyết vấn đề
gì và cho ai. Cô nói về điều này mọi lúc.
Đây là những người liên quan. Những người sẽ sử dụng, hỗ trợ, hoặc bằng cách
nào đó bị ảnh hưởng bởi hệ thống đang được phát triển. Tầm nhìn của Pat là những
người này sẽ yêu thích hệ thống của chúng ta và sử dụng nó thường xuyên.
Nhu cầu của những người liên quan được diễn đạt dưới dạng các câu chuyện người
dùng (user stories). Ví dụ, trong một hệ thống đặt vé máy bay, người dùng cần có
thể tìm kiếm chuyến bay. Đó sẽ là một câu chuyện người dùng. Các câu chuyện
thường tương ứng một cách sơ bộ với một tính năng hoặc một trường hợp sử dụng.
Những người liên quan có rất nhiều ý tưởng, và Pat giúp họ chia những ý tưởng
này thành các câu chuyện người dùng riêng biệt.
Bây giờ, ai đó phải xây dựng hệ thống. Đây là nhóm phát triển.
Vì đây là một nhóm agile, họ không để dành cho một lần phát hành lớn ở cuối.
Thay vào đó, họ phát hành sớm và thường xuyên. Họ thường phát hành 4-6 câu
chuyện mỗi tuần, đó là năng lực của họ. Nó dễ đo lường, chỉ cần đếm số câu
chuyện được phát hành mỗi tuần. Một số câu chuyện lớn, nên được tính là hai, một
số nhỏ và được tính là một nửa. Nhưng tất cả tổng cộng, nó cộng lại khoảng 4-6
câu chuyện mỗi tuần.
Để duy trì tốc độ này và không bị kẹt lại bởi việc kiểm thử hồi quy thủ công, nhóm
đầu tư mạnh vào kiểm thử tự động và tích hợp liên tục. Mỗi tính năng đều có kiểm
thử chấp nhận tự động, và hầu hết mã nguồn đều có kiểm thử đơn vị tự động.
Vấn đề là, có rất nhiều người liên quan yêu cầu đủ loại thứ, và chắc chắn họ không
bị giới hạn trong 4-6 ý tưởng mỗi tuần. Họ có RẤT NHIỀU ý tưởng và RẤT
NHIỀU mong muốn. Và mỗi khi chúng ta giao cái gì đó cho họ, họ sẽ có thêm
nhiều ý tưởng và yêu cầu thêm nhiều thứ nữa.
Vậy điều gì sẽ xảy ra nếu chúng ta cố gắng làm tất cả những gì họ yêu cầu? Chúng
ta sẽ bị quá tải. Giả sử nhóm bắt đầu làm việc trên 10 câu chuyện mới mỗi tuần.
Nếu đầu vào là 10, và đầu ra là 4-6, nhóm sẽ bị quá tải công việc. Điều đó sẽ gây
ra việc làm nhiều việc cùng lúc, mất động lực, và cuối cùng là giảm sản lượng và
giảm chất lượng. Đó là một viễn cảnh mất-mất.
Nó giống như cố nhét thêm giấy vào máy in để làm cho nó in nhanh hơn. Hoặc
nhét thêm xe vào hệ thống xa lộ đã chật cứng. Nó không hoạt động, nó chỉ làm mọi
thứ tồi tệ hơn. Đó là một quy luật cơ bản của vũ trụ - nếu Đầu vào lớn hơn Đầu ra,
bạn không thể tránh khỏi việc bị quá tải hoặc rò rỉ.
Cách của Scrum và XP để tránh vấn đề này gọi là "thời tiết hôm qua". Nhóm nói
"chà, những tuần trước chúng ta đã hoàn thành 4-6 tính năng mỗi tuần. Vậy tuần
này chúng ta sẽ xây dựng 4-6 tính năng nào?". Công việc của product owner là tìm
ra, trong tất cả các câu chuyện có thể có trên thế giới, 4-6 câu chuyện nào chúng ta
sẽ giao tiếp theo?
Cách của Kanban là giới hạn công việc đang tiến hành. Giả sử nhóm quyết định
rằng 5 là số lượng tối ưu của các câu chuyện để làm việc cùng lúc, vừa đủ để giữ
mọi người bận rộn mà không gây quá tải. Vậy họ quyết định rằng 5 là giới hạn
WIP của họ. Mỗi khi họ hoàn thành một câu chuyện, họ sẽ nhận một câu chuyện
mới, đảm bảo rằng họ không bao giờ vượt quá giới hạn 5 câu chuyện đang tiến
hành.
Cả hai cách tiếp cận này đều hoạt động tốt. Và chúng sẽ gây ra một hàng đợi hình
thành trước nhóm, mà trong Scrum gọi là Product Backlog.
Hàng đợi này cần được quản lý. Nếu những người liên quan tiếp tục yêu cầu 10
câu chuyện mới mỗi tuần, và các nhóm giao 4-6, hàng đợi sẽ ngày càng dài ra.
Trước khi bạn nhận ra, bạn có một danh sách mong muốn dài 6 tháng trong
backlog. Điều đó có nghĩa là, trung bình, mỗi câu chuyện mà nhóm giao là cái gì
đó mà ai đó đã yêu cầu cách đây 6 tháng. Điều đó có còn agile không?
Chỉ có một cách để ngăn hàng đợi không vượt quá tầm kiểm soát. Đó là từ
"Không". Đó là từ quan trọng nhất đối với một product owner, và Pat luyện tập nó
mỗi ngày trước gương. Nói "có" với một yêu cầu tính năng mới là dễ dàng. Công
việc quan trọng nhất của một product owner là quyết định cái gì KHÔNG xây
dựng, và chấp nhận hậu quả của quyết định đó.
Product owner quyết định cái gì được đưa vào và cái gì được loại bỏ. Product
owner cũng quyết định thứ tự – cái gì chúng ta xây dựng bây giờ, cái gì chúng ta
xây dựng sau? Đây là một công việc khó khăn và cần được thực hiện cùng với
nhóm và những người liên quan.
——–
Để có thể ưu tiên, product owner phải có một số ý tưởng về giá trị của mỗi câu
chuyện, cũng như kích thước của nó. Một số câu chuyện cực kỳ quan trọng, những
câu chuyện khác thực sự chỉ là các tính năng bổ sung. Một số câu chuyện chỉ mất
vài giờ để xây dựng, những câu chuyện khác mất hàng tháng.
Bạn đoán xem mối tương quan giữa giá trị câu chuyện và kích thước câu chuyện là
gì? Đúng rồi – Không có mối tương quan nào cả! Lớn hơn không có nghĩa là tốt
hơn. Hãy nghĩ về bất kỳ hệ thống nào mà bạn đã sử dụng, và tôi cá rằng bạn có thể
nghĩ đến ít nhất một tính năng rất đơn giản mà rất quan trọng, bạn sử dụng nó hàng
ngày. Và tôi cũng cá rằng bạn có thể nghĩ đến ít nhất một tính năng lớn phức tạp
mà hoàn toàn không quan trọng – như cái anh chàng kẹp giấy ngớ ngẩn trong
Microsoft Office vài năm trước.
Giá trị và kích thước là những yếu tố giúp Pat ưu tiên một cách thông minh.
Hai câu chuyện này có kích thước tương đối giống nhau, nhưng có giá trị khác
nhau. Vì vậy, xây dựng cái này trước. Và ở đây – hai câu chuyện này có giá trị
tương đối giống nhau, nhưng kích thước khác nhau. Vì vậy, xây dựng cái này
trước. Và cứ tiếp tục như vậy.
Nhưng khoan đã – làm sao cô ấy biết được giá trị của một câu chuyện? Làm sao cô
ấy biết được kích thước? Vâng, tin xấu là – cô ấy không biết. Đó là một trò chơi
đoán.
Và đó là trò chơi mà mọi người đều tham gia! Pat liên tục nói chuyện với những
người liên quan để tìm hiểu điều họ đánh giá cao. Cô liên tục nói chuyện với nhóm
để tìm hiểu họ nghĩ gì là lớn hoặc nhỏ, về mặt nỗ lực triển khai. Đây là những ước
lượng tương đối, không phải con số tuyệt đối. Tôi không biết quả táo này nặng bao
nhiêu, hay quả dâu kia nặng bao nhiêu. Nhưng tôi khá chắc chắn rằng quả táo nặng
ít nhất gấp năm lần, và quả dâu ngon hơn (đối với tôi). Và đó là tất cả những gì Pat
cần biết để ưu tiên backlog! Cách này khá thú vị.
Khi bắt đầu một dự án mới, các ước đoán của chúng ta sẽ không chính xác. Nhưng
không sao, giá trị lớn nhất thực sự nằm ở các cuộc trò chuyện chứ không phải ở
các con số thực tế. Và mỗi lần nhóm giao một thứ gì đó cho người dùng thực sự,
chúng ta học được điều gì đó và giỏi hơn trong việc đoán cả giá trị và kích thước.
Đó là lý do tại sao chúng ta liên tục ưu tiên và ước lượng. Cố gắng làm đúng ngay
từ đầu là khá ngớ ngẩn, vì đó là lúc chúng ta biết ít nhất. Vòng phản hồi là bạn của
chúng ta.
——–
Ưu tiên thôi là chưa đủ. Để giao hàng sớm và thường xuyên, chúng ta cần chia nhỏ
các câu chuyện thành những phần nhỏ, tốt nhất là chỉ mất vài ngày làm việc mỗi
câu chuyện. Chúng ta muốn có một phễu đẹp, với các câu chuyện nhỏ, rõ ràng ở
phía trước và các câu chuyện mơ hồ hơn ở phía sau. Bằng cách thực hiện việc chia
nhỏ này theo kiểu vừa kịp lúc, chúng ta có thể tận dụng được những hiểu biết mới
nhất về sản phẩm và nhu cầu của người dùng.
Tất cả những điều tôi đã nói – ước lượng giá trị và kích thước của các câu chuyện,
ưu tiên, chia nhỏ – tất cả điều đó thường được gọi là “backlog grooming”. Pat tổ
chức một buổi workshop backlog grooming mỗi thứ Tư từ 11:00 – 12:00. Cả nhóm
thường có mặt, và đôi khi có vài người liên quan tham gia. Chương trình làm việc
thay đổi, đôi khi tập trung vào ước lượng, đôi khi vào việc chia nhỏ câu chuyện, và
đôi khi vào việc viết tiêu chí chấp nhận cho một câu chuyện.
Tôi hy vọng bạn nhận thấy chủ đề ở đây. Giao tiếp! Sở hữu sản phẩm thực sự là tất
cả về giao tiếp. Khi tôi hỏi những product owner có kinh nghiệm cần gì để thành
công, họ thường nhấn mạnh đam mê và giao tiếp. Không phải ngẫu nhiên mà
nguyên tắc đầu tiên của bản tuyên ngôn agile là “Cá nhân và tương tác hơn quy
trình và công cụ”.
Vì vậy, công việc của PO không phải là đút cho nhóm các câu chuyện. Điều đó
thật nhàm chán và không hiệu quả. Thay vào đó, Pat đảm bảo mọi người hiểu tầm
nhìn, nhóm liên hệ trực tiếp với những người liên quan, và có một vòng phản hồi
ngắn qua các lần giao hàng thường xuyên cho người dùng thực. Bằng cách đó,
nhóm học hỏi và có thể tự đưa ra quyết định trao đổi hàng ngày, để Pat có thể tập
trung vào bức tranh lớn.
at và đội của cô ấy cần phải thực hiện nhiều sự đánh đổi. Hãy xem một vài ví dụ.
Trước tiên, có sự đánh đổi giữa các loại giá trị khác nhau. Đầu tiên trong một dự
án, sự không chắc chắn và rủi ro là kẻ thù của chúng ta.
Có rủi ro kinh doanh: chúng ta có đang xây dựng đúng thứ không? Có rủi ro xã
hội: những người này có thể xây dựng nó không? Có rủi ro kỹ thuật: nó có hoạt
động trên nền tảng mà chúng ta muốn chạy không? Nó có mở rộng được không?
Và có rủi ro về chi phí và lịch trình: chúng ta có thể hoàn thành sản phẩm trong
một khoảng thời gian hợp lý và với một khoản tiền hợp lý không?
Kiến thức là ngược lại với rủi ro. Vì vậy, khi sự không chắc chắn cao, chúng ta tập
trung vào việc thu thập kiến thức - chúng ta tập trung vào những thứ như nguyên
mẫu giao diện người dùng và các đột phá kỹ thuật hoặc các thí nghiệm. Không quá
thú vị đối với khách hàng, nhưng vẫn có giá trị vì chúng ta đang giảm thiểu rủi ro.
Từ quan điểm giá trị khách hàng, đường cong nhìn như thế này vào đầu.
Khi sự không chắc chắn giảm, chúng ta dần dần tập trung nhiều hơn vào giá trị
khách hàng. Chúng ta biết mình sẽ xây dựng cái gì và làm thế nào, vì vậy hãy làm
điều đó! Và bằng cách làm những câu chuyện có giá trị cao nhất trước, chúng ta có
được đường cong giá trị tăng mạnh.
Và sau đó, dần dần, đường cong giá trị bắt đầu phẳng hơn. Chúng ta đã xây dựng
những thứ quan trọng nhất, bây giờ chúng ta chỉ đang thêm các "tính năng bổ
sung", lớp phủ kem trên bánh. Đây là một vị trí tốt để ở, vì vào bất kỳ thời điểm
nào, Pat và đội của cô ấy có thể quyết định "cắt ngắn đuôi" và chuyển sang một dự
án quan trọng hơn, hoặc bắt đầu một lĩnh vực tính năng mới trong cùng sản phẩm.
Đó là sự linh hoạt trong kinh doanh.
Vì vậy, khi tôi nói về Giá trị ở đây, tôi có nghĩa là giá trị Kiến thức + giá trị Khách
hàng. Và chúng ta cần phải tìm sự đánh đổi giữa hai điều này.
——–
Một sự đánh đổi khác là suy nghĩ ngắn hạn và dài hạn. Chúng ta nên xây dựng gì
tiếp theo? Chúng ta nên sửa lỗi khẩn cấp đó, hay xây dựng tính năng mới tuyệt vời
sẽ làm người dùng kinh ngạc, hoặc thực hiện nâng cấp nền tảng khó khăn đó sẽ
cho phép phát triển nhanh hơn trong tương lai? Chúng ta cần liên tục cân bằng giữa
công việc phản ứng và công việc chủ động, hoặc giữa dập lửa và ngăn chặn lửa.
Điều này liên quan đến một sự đánh đổi khác. Chúng ta nên tập trung vào "xây
dựng đúng thứ", "xây dựng thứ đúng cách", "xây dựng nhanh chóng"? Lý tưởng là
chúng ta muốn cả ba, nhưng thật khó để tìm thấy sự cân bằng. Giả sử chúng ta ở
đây – cố gắng xây dựng sản phẩm hoàn hảo, với kiến trúc hoàn hảo. Nếu chúng ta
dành quá nhiều thời gian cố gắng để làm cho nó hoàn hảo, chúng ta có thể bỏ lỡ cơ
hội thị trường hoặc gặp vấn đề về dòng tiền.
Hoặc giả sử chúng ta ở đây, vội vã biến nguyên mẫu thành sản phẩm có thể sử
dụng. Tuyệt vời cho ngắn hạn, có lẽ, nhưng về lâu dài chúng ta sẽ chìm đắm trong
nợ kỹ thuật và tốc độ của chúng ta sẽ gần bằng không.
Hoặc giả sử chúng ta ở đây, xây dựng một nhà thờ đẹp trong thời gian kỷ lục. Trừ
khi người dùng không cần nhà thờ, họ cần một xe cắm trại.
Có một căng thẳng lành mạnh ở đây giữa các vai trò Scrum. PO thường tập trung
vào xây dựng đúng thứ. Các đội thường tập trung vào xây dựng thứ đúng cách. Và
Scrum masters, hoặc các huấn luyện viên agile, thường tập trung vào rút ngắn vòng
phản hồi.
Tốc độ là điều đáng nhấn mạnh. Vì một vòng phản hồi ngắn sẽ tăng tốc độ học hỏi,
vì vậy bạn sẽ nhanh chóng học được cái gì là đúng và cách xây dựng nó đúng cách.
Tuy nhiên, cả ba quan điểm đều quan trọng, vì vậy hãy tiếp tục cố gắng tìm sự cân
bằng.
Cuối cùng, có sự đánh đổi giữa phát triển sản phẩm mới và cải tiến sản phẩm cũ.
Product Backlog là một thuật ngữ gây nhầm lẫn, vì nó ngụ ý rằng chỉ có một sản
phẩm. Và dự án là một thuật ngữ gây nhầm lẫn, vì nó ngụ ý rằng phát triển sản
phẩm "kết thúc". Một sản phẩm không bao giờ thực sự "hoàn thành" - luôn có bảo
trì và cải tiến cần phải làm, cho đến khi sản phẩm đạt đến cuối vòng đời và bị tắt.
Vì vậy, khi một đội bắt đầu phát triển một sản phẩm mới, điều gì xảy ra với sản
phẩm cuối cùng của họ? Việc chuyển giao sản phẩm từ một đội sang đội khác rất
tốn kém và rủi ro. Một kịch bản phổ biến hơn là đội tiếp tục bảo trì sản phẩm cũ
trong khi phát triển sản phẩm mới. Vì vậy, không thực sự là một product backlog,
nó giống như một team backlog - một danh sách các công việc mà product owner
muốn đội này thực hiện, và nó có thể là một sự kết hợp của các công việc cho các
sản phẩm khác nhau. Và product owner cần liên tục thực hiện các sự đánh đổi giữa
những điều này.
——–
Thỉnh thoảng, một stakeholder sẽ gọi cho Pat và nói “Này, khi nào công việc của
tôi sẽ hoàn thành?” hoặc “Bao nhiêu công việc của tôi sẽ hoàn thành trước Giáng
sinh?”. Là PO, Pat chịu trách nhiệm quản lý kỳ vọng! Hoặc, quan trọng hơn, quản
lý kỳ vọng thực tế. Điều đó có nghĩa là không nói dối. Tôi biết, thật khó, nhưng ai
nói Agile là dễ?
Không thực sự khó để dự báo, miễn là không cần phải chính xác. Nếu bạn đo
lường tốc độ của đội của bạn, hoặc tốc độ kết hợp của tất cả các đội của bạn, bạn
có thể vẽ biểu đồ burnup câu chuyện. Biểu đồ hiển thị số lượng tích lũy các câu
chuyện được giao qua thời gian (hoặc điểm câu chuyện nếu bạn thích).
Lưu ý sự khác biệt. Đường cong này hiển thị đầu ra. Đường cong đó hiển thị kết
quả. Đó là đầu ra, và đó là kết quả mà chúng ta hy vọng sẽ đạt được. Mục tiêu của
chúng ta không phải là sản xuất càng nhiều đầu ra càng tốt. Mục tiêu của chúng ta
là đạt được kết quả mong muốn, bằng cách sử dụng ít đầu ra nhất có thể. Ít hơn là
nhiều hơn.
Nhìn vào biểu đồ burnup và vẽ một đường xu hướng lạc quan và một đường xu
hướng bi quan. Bạn có thể làm điều đó bằng cách sử dụng thống kê phức tạp, hoặc
bạn có thể chỉ vẽ nó một cách trực quan. Khoảng cách giữa các đường này tất
nhiên liên quan đến mức độ dao động và không thể đoán trước của tốc độ của bạn.
Điều đó có xu hướng ổn định theo thời gian, vì vậy hình nón của sự không chắc
chắn của chúng ta sẽ dần thu hẹp.
Được rồi, quay lại quản lý kỳ vọng.
Giả sử các stakeholder hỏi Pat “Khi nào tất cả những thứ này sẽ hoàn thành?”.
“Khi nào chúng ta sẽ đến đây?”. Đó là một câu hỏi với phạm vi cố định, thời gian
biến đổi. Pat sử dụng hai đường xu hướng để trả lời. “Có khả năng vào khoảng từ
tháng Tư đến giữa tháng Năm”.
Giả sử các stakeholder hỏi Pat “Bao nhiêu sẽ được hoàn thành trước Giáng sinh?”.
Đó là một câu hỏi với thời gian cố định, phạm vi biến đổi. Các đường xu hướng
cho chúng ta biết “Chúng ta có khả năng hoàn thành tất cả những cái này, một số
trong số này, và không có cái này.”
Giả sử các stakeholder nói “Chúng ta có thể có những tính năng này trước Giáng
sinh không”. Đó là một câu hỏi với thời gian cố định, phạm vi cố định. Nhìn vào
các đường xu hướng, Pat nói “Không, xin lỗi, điều đó sẽ không xảy ra”, tiếp theo
là “đây là những gì chúng ta có thể hoàn thành trước Giáng sinh” hoặc “đây là bao
nhiêu thời gian chúng ta cần thêm”. Nói chung, giảm phạm vi tốt hơn là kéo dài
thời gian, vì nếu giảm phạm vi trước, chúng ta vẫn có tùy chọn kéo dài thời gian
sau đó và thêm các câu chuyện còn lại. Ngược lại không hoạt động, vì, chết tiệt,
chúng ta không thể quay ngược thời gian! Thời gian khá phiền phức ở điểm này,
đúng không. Pat làm cho lựa chọn trở nên dễ dàng bằng cách nói “chúng ta có thể
giao một cái gì đó ở đây, và phần còn lại sau đó. Hoặc chúng ta có thể không giao
gì ở đây và phần còn lại sau đó. Bạn thích cái nào?”