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.
Đọ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