Thỉnh thoảng trong buổi lập kế hoạch sprint (sprint planning) lại có một story mà không ai chấm điểm (story point) nổi. Người chấm 2, người chấm 13, rồi có ai đó buông một câu “ừ thì, còn tùy”, và cuộc thảo luận cứ thế đi vòng vòng. Nên dùng GraphQL hay REST? Hệ thống có thật sự chịu được 10,000 người dùng cùng lúc không? Thư viện bên thứ ba này đã đủ ổn định để đưa lên môi trường production chưa? Với những câu hỏi kiểu này, ngồi ước lượng bao lâu cũng không ra. Bạn phải bắt tay vào tìm hiểu, và spike sinh ra chính là để làm việc đó.

Spike từ đâu mà ra

#

Thuật ngữ này bắt nguồn từ Extreme Programming (XP). Ở đó, spike là một “chương trình rất đơn giản để khám phá các giải pháp tiềm năng”, giống như đóng một cây đinh (spike) xuyên thẳng qua vấn đề. Ngày nay, spike là một nhiệm vụ nghiên cứu ngắn, có khung thời gian cố định (time-box), và đầu ra của nó là kiến thức chứ không phải phần mềm chạy được. Spike không phải user story, tự nó cũng không mang lại giá trị gì cho khách hàng, và như vậy cũng không sao. Nhiệm vụ của nó là trả lời một câu hỏi cụ thể, để phần việc thật sau đó được ước lượng và lên kế hoạch cho sát thực tế.

Trên thực tế có hai loại spike. Spike kỹ thuật trả lời câu hỏi “làm thế nào”: đánh giá một framework hay thư viện, làm bản mẫu (prototype) cho một mẫu kiến trúc, kiểm thử hiệu năng trong điều kiện sát với thực tế, hoặc tìm hiểu xem một bài toán tích hợp thật ra sẽ vất vả đến mức nào. Spike chức năng thì trả lời câu hỏi “làm cái gì”: làm rõ một story còn mơ hồ, thử một ý tưởng giao diện bằng bản mẫu làm xong là bỏ, hoặc mày mò nghiệp vụ phức tạp cho đến khi hiểu ra vấn đề.

Vì sao đáng bỏ thời gian

#

Cố ước lượng một việc còn nhiều ẩn số lớn thì kết quả thường chỉ có hai kiểu: hoặc ước lượng bị độn lên cho chắc, hoặc trễ hạn chót. Spike biến “chẳng biết gì” thành dữ liệu thật, để cả đội có thể cam kết mà không phải chột dạ. Nó cũng thay những cuộc tranh cãi cảm tính bằng bằng chứng: thay vì cãi nhau xem cơ sở dữ liệu nào tốt hơn, bạn bỏ ra hai ngày để đo, rồi đưa kết quả thẳng vào tài liệu quyết định của mình.

Nhưng trên hết, spike là một khoản bảo hiểm rẻ. Bỏ hai ngày làm spike để phát hiện ra giới hạn của một thư viện thì tốn ít hơn nhiều so với việc phát hiện ra đúng giới hạn đó khi đã phát triển được ba sprint.

Khi nào nên (và không nên) dùng spike

#

Hãy dùng spike khi đội không tự tin ước lượng một story vì còn những ẩn số kỹ thuật, khi có nhiều phương án khả thi và bạn cần dữ liệu để chọn, khi bạn đang cân nhắc một công nghệ hay một bài toán tích hợp mới, khi hiệu năng vừa chưa chắc chắn vừa cực kỳ quan trọng, hoặc khi yêu cầu vẫn mơ hồ dù bạn đã ngồi họp với các bên liên quan không biết bao nhiêu lần.

Ngược lại, đừng dùng spike cho những việc đội đã biết cách làm, hay để trì hoãn một quyết định mà bạn hoàn toàn có thể đưa ra với thông tin đang có. Spike cũng không thay thế được việc thu thập yêu cầu cẩn thận hay kiểm thử chấp nhận người dùng: nó trả lời một câu hỏi, chứ không kiểm chứng một sản phẩm.

Tôi làm một spike như thế nào

#

Đầu tiên là viết câu hỏi ra. Không phải “nghiên cứu về bộ nhớ đệm (cache)” mà là “cụm Redis có đáp ứng được yêu cầu độ trễ 50ms của mình không?”. Xác định phạm vi rõ ràng, cái gì nằm trong, cái gì nằm ngoài; đặt khung thời gian từ một đến ba ngày (nếu cần lâu hơn thì câu hỏi đang quá rộng); và đặt tiêu chí thành công để biết khi nào thì xong.

Sau đó bắt tay vào tìm hiểu: đọc tài liệu và các nghiên cứu điển hình (case study), dựng một bản chứng minh khái niệm (proof of concept) tối giản, hỏi chuyện những người từng làm rồi, và đo đạc bằng mã thật. Mã viết trong spike vốn dĩ là để vứt đi.

Khi hết khung thời gian, hãy viết lại những gì tìm được, một đề xuất kèm lý do, và mọi rủi ro bạn phát hiện ra, cùng đường liên kết tới bản mẫu, ghi rõ đó là sản phẩm của spike. Trình bày cho cả đội, trả lời các câu hỏi, rồi điều chỉnh danh sách việc tồn đọng (backlog): tạo story mới, chỉnh sửa, hoặc bỏ hẳn story dựa trên những gì đã học được. Cũng nên dành chút thời gian nhìn lại xem bản thân spike đó đã diễn ra thế nào trong buổi họp nhìn lại (retrospective) tiếp theo; làm spike càng nhiều thì đội càng làm tốt hơn thấy rõ.

Mẫu tài liệu tôi dùng

#

## Spike: [Title]

**Time-box**: [X days]
**Owner**: [Name]
**Sprint**: [Sprint number/name]

### Question to Answer
[Single, focused question this spike will answer]

### Background
[Why this spike is needed; what triggered the uncertainty]

### Assumptions
- [Assumption 1]
- [Assumption 2]

### Scope
**In Scope**:
- [Item 1]
- [Item 2]

**Out of Scope**:
- [Item 1]

### Success Criteria
- [ ] [Criterion 1]
- [ ] [Criterion 2]

### Findings
[To be completed during spike]

### Recommendation
[To be completed after spike]

### Follow-up Stories
- [ ] [Story 1]
- [ ] [Story 2]

Phần Assumptions (các giả định) rất đáng có. Trước khi bắt đầu, nếu bạn viết ra những giả định như “mô hình dữ liệu của mình chủ yếu là dạng quan hệ” hay “lượt đọc sẽ gấp 10 lần lượt ghi”, bạn được hai cái lợi. Một là mọi người có thể phản biện cách bạn đặt vấn đề trước khi bạn tiêu hết khung thời gian. Hai là nếu giữa chừng có giả định hóa ra sai, thì bạn đã học được một điều có giá trị, chứ không phải phí mất hai ngày.

Những kiểu spike đi chệch hướng

#

Thất bại kinh điển nhất là phình phạm vi (scope creep): spike lặng lẽ biến thành một dự án nghiên cứu không có điểm dừng. Khi câu hỏi mới xuất hiện (và chắc chắn sẽ có), hãy ghi chúng lại thành ứng viên cho những spike sau, thay vì nới rộng spike hiện tại. Thất bại thứ hai là làm quá mức cần thiết (goldplating): khi bắt gặp mình đang thêm xử lý lỗi hay viết kiểm thử cho mã spike, là bạn đã bước từ khám phá sang hiện thực hóa rồi đấy. Thứ ba là bỏ qua phần viết lại kết quả: sáu tháng sau sẽ có người gặp đúng câu hỏi đó, và hai ngày tìm hiểu của bạn coi như mất trắng. Và cuối cùng là coi spike như một lời cam kết cho một câu trả lời định sẵn. Một spike chứng minh được một hướng đi không khả thi là đã làm tròn vai của nó rồi.

Đưa spike vào buổi lập kế hoạch sprint

#

Khi lên kế hoạch sprint, tôi thấy vài thói quen sau khá hiệu quả. Nếu một story có những ẩn số thật, hãy làm spike trong sprint này và xếp phần việc thật vào một sprint sau. Mỗi sprint chỉ nên có một hai spike, nhiều hơn thì đội sẽ mất tập trung. Đừng chấm điểm story cho spike; spike tạo ra kiến thức chứ không tạo ra phần mềm, nên hãy theo dõi chúng bằng khung thời gian. Và hãy trình bày kết quả spike trong buổi làm rõ story (refinement), trước khi đội ước lượng các story liên quan, chứ không phải sau đó.

Lần tới, khi một story đặt ra nhiều câu hỏi hơn là câu trả lời, hãy nghĩ tới khả năng một spike lại chính là việc hữu ích nhất trong sprint. Đôi khi, cách nhanh nhất để đi tiếp là dừng lại và tìm hiểu.

Nói ngắn gọn

#

Spike là một đợt tìm hiểu gói trong khung thời gian cố định, từ một đến ba ngày, xoay quanh đúng một câu hỏi mà chỉ ngồi ước lượng thì không giải quyết được. Nên làm spike khi chính những ẩn số đang chặn việc ước lượng: có nhiều phương án khả thi nhưng thiếu dữ liệu để chọn, đang cân nhắc một công nghệ hay một bài toán tích hợp mới, hiệu năng vừa chưa chắc chắn vừa quan trọng, hoặc yêu cầu cứ mơ hồ mãi. Đừng làm spike cho những việc đội đã biết cách làm, hay để trì hoãn một quyết định mà thông tin đang có đã đủ để đưa ra.

Đầu ra của spike là kiến thức chứ không phải phần mềm: kết quả tìm hiểu, đề xuất kèm lý do, những rủi ro phát hiện được và một bản mẫu làm xong là bỏ. Danh sách việc tồn đọng sau đó được điều chỉnh theo. Không chấm điểm story cho spike, chỉ theo dõi bằng khung thời gian; và kết quả nên được trình bày ở buổi làm rõ story, trước khi đội ước lượng các story liên quan.

Đọc thêm

#

Bài viết liên quan trên blog này:

• Họp nhìn lại: đánh giá kết quả spike - Đưa những gì học được từ spike vào quá trình cải tiến liên tục
• Kiểm thử chấp nhận người dùng - Kiểm chứng xem các quyết định dựa trên spike có đáp ứng đúng nhu cầu người dùng không
• Tài liệu quyết định - Tổ chức các quyết định rút ra từ kết quả spike
• Lên kế hoạch API - Spike giúp định hướng các quyết định thiết kế API ra sao

Tài liệu bên ngoài:

• Spikes - Scaled Agile Framework (SAFe) - Hướng dẫn của SAFe về spike ở quy mô lớn
• Spike Solutions - Extreme Programming - Khái niệm gốc trong XP
• The Scrum Guide - Spike nằm ở đâu trong buổi lập kế hoạch sprint
• Martin Fowler bàn về nợ kỹ thuật - Spike giúp ngăn nợ kỹ thuật như thế nào

Những buổi họp nhìn lại (retrospective) tệ nhất mà tôi từng ngồi đều giống nhau ở một điểm: đội không đạt mục tiêu sprint (sprint goal), thế là cả tiếng đồng hồ biến thành một buổi truy xét xem vì sao lại trượt. Còn những buổi tốt nhất thì gần như chẳng nhắc gì đến mục tiêu. Chúng tôi nói về cách mình đã làm việc, cái gì đã cản trở, và lần sau sẽ thử làm khác đi ra sao. Khác biệt đó chính là cái mà người ta gọi là tư duy không phụ thuộc vào kết quả (outcome-independent mindset). Sau một thời gian tự mình điều phối sprint, tôi nghĩ đây là thái độ hữu ích nhất mà một Scrum Master có thể có.

Nói cho rõ: kết quả là quan trọng. Chẳng ai trả lương cho chúng ta để có một quy trình đẹp đẽ mà không làm ra được gì. Nhưng hoàn thành sprint là việc của đội. Còn việc của Scrum Master là cải thiện cỗ máy làm ra các sprint. Đó là hai việc khác nhau, và phần lớn những trục trặc xoay quanh Scrum mà tôi từng thấy đều bắt nguồn từ chuyện nhầm lẫn giữa hai việc này.

Scrum Master khác quản lý dự án (project manager) thế nào

#

Hai vai trò này hay bị nhầm lẫn, một phần vì nhiều công ty giao cả hai cho cùng một người. Khác biệt cốt lõi nằm ở đây:

Bản thân Scrum không có vai trò quản lý dự án. Nhiều việc mà một người quản lý dự án thường làm được chia cho Product Owner, người quyết định làm cái gì và làm theo thứ tự nào, và các Nhà phát triển, những người lên kế hoạch làm như thế nào.

Điều gì thay đổi khi bạn thôi bám chặt vào kết quả

#

Đội có không gian để thật sự làm chủ công việc. Về lý thuyết, Scrum dựa trên những đội tự tổ chức, nhưng một Scrum Master lo sốt vó cho từng kết quả thì rốt cuộc sẽ đi lái mọi quyết định, và đội sẽ sớm nhận ra quyết định thật ra không nằm trong tay họ. Còn khi bạn tập trung vào quy trình, bạn có thể để mọi người thử nghiệm, thỉnh thoảng quyết định sai, rồi rút kinh nghiệm từ đó. Đó cũng là cách duy nhất để tinh thần làm chủ thật sự hình thành.

Các buổi họp nhìn lại trở nên thẳng thắn hơn. Khi câu hỏi đặt ra trong phòng là “sao mình không đạt con số?”, những câu trả lời thật sẽ lẩn đi hết. Còn khi câu hỏi là “cái gì làm mình chậm lại, và lần tới nên thử gì?”, mọi người sẽ chịu nói. Với những vướng mắc phát sinh giữa sprint cũng vậy: một Scrum Master bị ám ảnh bởi kết quả sẽ cuống lên vì hạn chót, còn người tập trung vào quy trình thì cứ thế bắt tay vào gỡ vướng mắc. Nếu vướng mắc là một điều mà chưa ai nắm rõ, họ sẽ đề xuất một spike có giới hạn thời gian để tìm hiểu cho ra.

Các bên liên quan cũng bớt căng thẳng. Nếu thứ duy nhất bạn đem ra báo cáo là biểu đồ burndown, thì mỗi lần nó chững lại trông đều như thất bại. Nhưng nếu bạn kể thêm được đội đã học được gì và đang thích nghi ra sao, kỳ vọng của mọi người sẽ thực tế hơn, và đội cũng được che chắn khỏi rất nhiều áp lực mà nếu không thì sẽ đổ ập xuống giữa chừng sprint.

Nếu bạn đã lỡ bị ám ảnh bởi một kết quả nào đó

#

Tôi biết là nói thì dễ. Khi bạn đã dồn nhiều tâm huyết để một việc diễn ra theo đúng ý mình, thì câu “cứ tập trung vào quy trình thôi” nghe chẳng khác gì một câu khẩu hiệu dán trên tủ lạnh.

Có vài điều thật sự giúp được. Thứ nhất, đừng tự trách mình vì đã quan tâm. Muốn có kết quả là chuyện bình thường, và giả vờ là mình không muốn thì chẳng ích gì. Thứ hai, chuyển mục tiêu về kết quả thành những mục tiêu về quy trình mà bạn kiểm soát được: không phải “thắng cuộc thi” mà là “luyện tập 30 phút mỗi ngày”. Bạn không kiểm soát được bản phát hành có suôn sẻ hay không, nhưng bạn kiểm soát được việc nó đã được rà soát, kiểm thử và trình diễn (demo) sớm hay chưa. Thứ ba, để ý xem điều gì đang nuôi nỗi ám ảnh đó. Nếu một ngày bạn mở lại một bảng điều khiển (dashboard) hay xem giá cổ phiếu cả chục lần, hãy đặt ra vài khung giờ cố định để xem, ngoài giờ đó thì thôi. Và hãy ăn mừng những thành công nhỏ trên đường đi, vì cái mục tiêu xa xôi kia sẽ sẵn sàng nuốt trọn sự chú ý của bạn nếu bạn để nó làm vậy. Còn nếu nỗi ám ảnh thật sự ảnh hưởng tới giấc ngủ hay sinh hoạt hằng ngày của bạn, thì nên tìm đến chuyên gia để được hỗ trợ. Chẳng có gì phải ngại cả.

Kết quả vẫn quan trọng. Nhưng những đội mà tôi thấy đạt kết quả đều đặn là những đội có người chăm lo cho phần “làm thế nào”, chứ không chỉ phần “làm cái gì”.