Trong bối cảnh phát triển sản phẩm linh hoạt, các tấm lớn đại diện cho những khối công việc đáng kể mang lại giá trị lớn. Tuy nhiên, coi một tấm lớn như một đơn vị thực hiện duy nhất thường dẫn đến trì hoãn, yêu cầu không rõ ràng và bỏ lỡ cơ hội thu thập phản hồi. Việc chia nhỏ các tấm lớn thành các thẻ câu chuyện nhỏ là điều cần thiết để duy trì tốc độ và đảm bảo giao hàng liên tục. Hướng dẫn này khám phá các phương pháp, nguyên tắc và các bước thực tế cần thiết để chia nhỏ các sáng kiến phức tạp thành những đơn vị công việc có thể quản lý, kiểm thử và mang lại giá trị.
🧩 Hiểu rõ mối quan hệ giữa Tấm lớn và Câu chuyện
Trước khi đi sâu vào cơ chế chia nhỏ, điều quan trọng là phải xác định thứ bậc. Một tấm lớn thường là một tính năng hoặc khả năng lớn, quá lớn để hoàn thành trong một lần lặp duy nhất. Nó đóng vai trò là nơi chứa đựng nhiều câu chuyện người dùng. Ngược lại, một câu chuyện người dùng là một đơn vị công việc nhỏ, độc lập, có thể hoàn thành, kiểm thử và giao hàng trong thời gian ngắn.
Hãy hình dung một tấm lớn như một cuốn sách và các câu chuyện người dùng như những chương riêng lẻ. Bạn không thể đọc toàn bộ cuốn sách trong một lần nếu nó quá dày đặc; bạn cần xử lý từng chương một. Tương tự, một đội không thể giao một tấm lớn toàn bộ một lúc mà không rủi ro phải đối mặt với sự phức tạp quá tải.
Tại sao Kích thước lại quan trọng
- Dự đoán được:Các mục nhỏ hơn cho phép ước lượng chính xác hơn. Khi công việc quá lớn, mức độ không chắc chắn sẽ tăng theo cấp số nhân.
- Vòng phản hồi:Các câu chuyện nhỏ hơn có thể được phát hành nhanh hơn, giúp đội thu thập phản hồi từ người dùng sớm hơn.
- Giảm thiểu rủi ro:Các tính năng phức tạp thường ẩn chứa các phụ thuộc ngầm. Việc chia nhỏ chúng sẽ làm lộ ra những rủi ro này sớm trong chu kỳ.
- Tinh thần đội nhóm:Hoàn thành các nhiệm vụ nhỏ, cụ thể sẽ mang lại cảm giác thành tựu và động lực cho đội.
📐 Nguyên tắc chia nhỏ hiệu quả
Không phải mọi lần chia nhỏ nào cũng là tốt. Việc phân mảnh tùy tiện có thể dẫn đến chi phí phát sinh và chuyển đổi ngữ cảnh. Để chia nhỏ hiệu quả, các đội cần tuân thủ các tiêu chí đã được thiết lập. Mô hình INVEST là tiêu chuẩn ngành để đánh giá các câu chuyện người dùng.
Tiêu chí INVEST
Mỗi thẻ câu chuyện nên đáp ứng các đặc điểm sau:
- IĐộc lập: Câu chuyện không nên phụ thuộc vào một câu chuyện khác để được giao, nhằm giảm thiểu các phụ thuộc.
- NThương lượng được: Các chi tiết mở cho thảo luận, cho phép linh hoạt trong triển khai.
- VCó giá trị: Câu chuyện phải mang lại giá trị cho người dùng cuối hoặc doanh nghiệp ngay lập tức.
- ECó thể ước lượng được: Đội phải có khả năng xác định quy mô công việc cần thiết để hoàn thành.
- SNhỏ: Công việc phải đủ nhỏ để hoàn thành trong một lần lặp duy nhất.
- TCó thể kiểm thử được: Phải có các tiêu chí chấp nhận rõ ràng để xác minh câu chuyện đã hoàn thành.
🛠 Các kỹ thuật phân chia các tác vụ lớn
Có một số cách tiếp cận chiến lược để chia nhỏ công việc. Phương pháp phù hợp phụ thuộc vào bản chất của tính năng và các ưu tiên hiện tại của sản phẩm. Dưới đây là những phương pháp hiệu quả nhất.
1. Cắt dọc (dựa trên giá trị)
Đây là phương pháp được ưa chuộng đối với các đội ngũ linh hoạt. Cắt dọc bao gồm việc cung cấp một mảnh chức năng mỏng hoạt động từ giao diện người dùng đến cơ sở dữ liệu. Nó mang lại giá trị toàn diện, ngay cả khi chưa phải là tính năng đầy đủ.
- Ví dụ:Thay vì xây dựng toàn bộ hệ thống thanh toán (cơ sở dữ liệu, giao diện người dùng, cổng thanh toán) cùng một lúc, hãy xây dựng khả năng thêm một mục vào giỏ hàng và xem nó.
- Lợi ích:Cung cấp giá trị tức thì cho người dùng và xác minh kiến trúc sớm.
2. Cắt ngang (dựa trên lớp)
Chia cắt ngang tách biệt công việc theo lớp kỹ thuật. Ví dụ, một câu chuyện xử lý lược đồ cơ sở dữ liệu, một câu chuyện khác xử lý điểm cuối API, và câu chuyện thứ ba xử lý giao diện người dùng phía trước. Mặc dù điều này giúp giảm nợ kỹ thuật, nhưng thường làm chậm việc cung cấp giá trị.
- Ví dụ:Câu chuyện A tạo bảng. Câu chuyện B tạo điểm cuối API. Câu chuyện C xây dựng biểu mẫu.
- Cảnh báo:Tránh phương pháp này trừ khi đội ngũ thiếu kỹ năng để cung cấp các mảnh cắt dọc hoặc có mốc kỹ thuật cụ thể cần đạt được.
3. Chia theo trạng thái
Các tính năng thường có các trạng thái khác nhau. Bạn có thể chia công việc theo quá trình di chuyển của một mục qua các trạng thái này.
- Ví dụ:Trong hệ thống quản lý công việc, một câu chuyện xử lý việc tạo công việc, một câu chuyện khác xử lý chỉnh sửa nó, và câu chuyện thứ ba xử lý lưu trữ nó.
4. Chia theo quy tắc
Nếu một tính năng có các quy tắc kinh doanh phức tạp, hãy chia công việc theo mức độ phức tạp của quy tắc.
- Ví dụ:Một bộ động cơ giảm giá có thể có các câu chuyện cho giảm giá tiêu chuẩn, giảm giá theo phần trăm và giảm giá khi mua số lượng lớn.
5. Chia theo dữ liệu
Khi một tính năng phụ thuộc vào khối lượng dữ liệu, hãy chia công việc dựa trên các tập dữ liệu.
- Ví dụ:Một câu chuyện xử lý dữ liệu từ khu vực A, một câu chuyện khác xử lý dữ liệu từ khu vực B.
📊 So sánh các kỹ thuật chia nhỏ
| Kỹ thuật | Trọng tâm | Sử dụng tốt nhất khi | Lợi ích chính |
|---|---|---|---|
| Cắt dọc | Giá trị kết thúc đến kết thúc | Giao hàng Agile tiêu chuẩn | Phản hồi nhanh và giá trị |
| Cắt ngang | Các lớp kỹ thuật | Cải tổ hạ tầng | Rõ ràng về mặt kỹ thuật |
| Dựa trên trạng thái | Các giai đoạn vòng đời | Hệ thống quản lý quy trình làm việc | Tiến triển rõ ràng |
| Dựa trên quy tắc | Logic kinh doanh | Các bộ tính toán phức tạp | Độ phức tạp có thể kiểm soát |
📝 Một nghiên cứu trường hợp chi tiết: Thanh toán thương mại điện tử
Để minh họa các khái niệm này, hãy xem xét một bản truyện lớn mang tiêu đề “Triển khai quy trình thanh toán an toàn”. Đây là một quy mô quá lớn để bắt đầu phát triển ngay lập tức. Dưới đây là cách chúng ta có thể chia nhỏ nó.
Bản truyện lớn
Tiêu đề: Triển khai quy trình thanh toán an toàn
Mục tiêu: Cho phép người dùng mua hàng trực tuyến một cách an toàn.
Câu chuyện 1: Thanh toán cho khách truy cập (cắt dọc)
- Là mộtngười dùng khách,
- Tôi muốnnhập thông tin giao hàng mà không cần tạo tài khoản,
- ĐểTôi có thể mua hàng nhanh chóng mà không gặp trở ngại.
Tiêu chí chấp nhận:Người dùng có thể nhập tên, địa chỉ và thông tin thẻ. Hệ thống xử lý thanh toán. Email xác nhận được gửi đi.
Câu chuyện 2: Thanh toán cho người dùng đã đăng ký
- Là mộtngười dùng đã đăng ký,
- Tôi muốntự động điền thông tin giao hàng và thanh toán của tôi,
- Để choquy trình trở nên nhanh hơn cho các lần mua lại.
Tiêu chí chấp nhận:Người dùng đã đăng nhập thấy địa chỉ đã lưu. Người dùng có thể chọn từ danh sách thả xuống.
Câu chuyện 3: Tùy chọn quà tặng
- Là mộtngười mua,
- Tôi muốnthêm tin nhắn quà tặng và tắt in giá tiền,
- Để chongười nhận thấy một bất ngờ thú vị.
Câu chuyện 4: Tính toán thuế
- Là mộtngười mua,
- Tôi muốnxem thuế chính xác dựa trên vị trí,
- Để chotôi biết chi phí cuối cùng trước khi thanh toán.
Bằng cách chia nhỏ như vậy, đội có thể triển khai Câu chuyện 1 trước. Điều này xác nhận tích hợp cổng thanh toán và luồng chính. Các câu chuyện 2, 3 và 4 có thể tiếp tục trong các vòng lặp sau, tinh chỉnh trải nghiệm dựa trên dữ liệu sử dụng thực tế từ Câu chuyện 1.
🤝 Hợp tác trong quá trình chia nhỏ
Việc chia nhỏ công việc không phải là nhiệm vụ đơn độc do người quản lý sản phẩm thực hiện một mình. Nó đòi hỏi sự hợp tác. Đội ngũ sẽ thực hiện công việc phải hiểu rõ các giới hạn kỹ thuật và nỗ lực liên quan.
Các buổi tinh chỉnh
Tổ chức các buổi tinh chỉnh danh sách công việc định kỳ. Sử dụng những buổi họp này để thảo luận về các khả năng chia nhỏ. Hỏi các nhà phát triển:
- Rủi ro kỹ thuật nằm ở đâu?
- Có thành phần chung nào cần được xây dựng trước không?
- Có thể giao hàng dưới dạng hai phần không?
Ba người bạn
Với mỗi câu chuyện, hãy đảm bảo có cuộc trao đổi giữa ba vai trò: Sản phẩm (Cái gì), Phát triển (Làm thế nào) và Kiểm thử (Xác minh). Bộ ba này đảm bảo rằng câu chuyện đã chia nhỏ là có thể kiểm thử và khả thi.
⚠️ Những sai lầm phổ biến cần tránh
Ngay cả với những ý định tốt nhất, các đội cũng có thể mắc sai lầm khi chia nhỏ công việc. Nhận thức được những sai lầm này sẽ giúp duy trì chất lượng.
1. Chia nhỏ quá mức
Tạo ra các câu chuyện quá nhỏ sẽ dẫn đến chi phí quản lý quá cao. Nếu một câu chuyện chỉ mất 2 giờ để hoàn thành, đội sẽ dành nhiều thời gian quản lý vé hơn là viết mã. Hãy nhắm đến các câu chuyện mất từ 1 đến 3 ngày công.
2. Bỏ qua các phụ thuộc
Chia một tính năng thành hai câu chuyện có thể tạo ra một phụ thuộc cứng, nơi câu chuyện B không thể bắt đầu cho đến khi câu chuyện A được triển khai. Hãy cố gắng làm cho các câu chuyện độc lập hoặc xác định phụ thuộc sớm.
3. Bỏ qua tiêu chí chấp nhận
Một câu chuyện mà không có tiêu chí chấp nhận rõ ràng thì không phải là một câu chuyện; đó chỉ là một nhiệm vụ. Đảm bảo mọi mục đã chia nhỏ đều có định nghĩa hoàn thành.
4. Chỉ tập trung vào tính năng
Đôi khi việc chia nhỏ sẽ làm lộ ra các yêu cầu phi chức năng. Nếu một câu chuyện đã chia nhỏ yêu cầu tối ưu hiệu suất, thì đó là một câu chuyện hợp lệ. Đừng bỏ qua nợ kỹ thuật hay các yêu cầu bảo mật.
📏 Đo lường chất lượng của việc chia nhỏ
Làm sao bạn biết chiến lược chia nhỏ của mình có hiệu quả không? Hãy xem xét các chỉ số sau trong các buổi tổng kết.
- Tỷ lệ hoàn thành Sprint:Các đội có hoàn thành các câu chuyện họ cam kết không? Nếu không, các câu chuyện có thể quá lớn.
- Thời gian dẫn đầu:Thời gian từ ý tưởng đến triển khai có đang giảm dần không? Các câu chuyện nhỏ thường được xử lý nhanh hơn.
- Tần suất thay đổi:Bạn có triển khai thay đổi thường xuyên hơn không? Điều này cho thấy việc chia theo chiều dọc thành công.
🔄 Bản chất lặp lại của việc chia nhỏ
Việc chia nhỏ không phải là một sự kiện duy nhất. Khi đội học thêm về yêu cầu hoặc công nghệ, kế hoạch có thể thay đổi. Một bản truyện lớn tưởng chừng rõ ràng ban đầu có thể bộc lộ những phức tạp mới trong sprint đầu tiên. Điều này là bình thường. Hãy sẵn sàng đánh giá lại và chia nhỏ thêm nếu cần thiết. Khả năng thích ứng này là một điểm mạnh cốt lõi của các phương pháp luận linh hoạt.
🎯 Định nghĩa hoàn thành cho các câu chuyện đã chia nhỏ
Mỗi thẻ câu chuyện, bất kể kích thước, đều phải đáp ứng Định nghĩa Hoàn thành. Điều này đảm bảo rằng việc hoàn thành một phần không tích lũy nợ kỹ thuật.
- Xem xét mã nguồn:Đã hoàn thành kiểm tra chéo.
- Kiểm thử:Các bài kiểm thử đơn vị và kiểm thử tích hợp đã qua.
- Tài liệu:Đã cập nhật trong cơ sở tri thức.
- Triển khai:Đã triển khai vào môi trường thử nghiệm hoặc sản xuất.
- Bảo mật:Quét bảo mật đã qua.
🧠 Tóm tắt các Thực hành Tốt nhất
Để duy trì tốc độ cao và chất lượng tốt, hãy ghi nhớ những nguyên tắc này:
- Bắt đầu bằng giá trị người dùng:Luôn đặt câu hỏi: ‘Người dùng nhận được gì từ phần cụ thể này?’
- Giữ mức độ phụ thuộc thấp:Những câu chuyện độc lập sẽ vận hành trơn tru hơn.
- Sử dụng cắt dọc:Cung cấp phần mềm hoạt động sớm nhất có thể.
- Tham gia của toàn đội:Các nhà phát triển và kiểm thử cung cấp thông tin quan trọng về nỗ lực và rủi ro.
- Duy trì tính linh hoạt:Điều chỉnh cách chia dựa trên thông tin mới.
🙋 Câu hỏi thường gặp
Câu hỏi: Quá nhỏ đến mức nào là quá nhỏ?
Một câu chuyện mất ít hơn nửa ngày để hoàn thành có thể quá chi tiết. Điều này tạo ra quá nhiều gánh nặng hành chính. Hãy nhắm đến những câu chuyện vừa vặn trong một sprint nhưng đủ lớn để xứng đáng với một ngày làm việc tập trung.
Câu hỏi: Một cốt truyện lớn có thể được chia thành các nhiệm vụ thay vì các câu chuyện không?
Có, nhưng các nhiệm vụ thường là các bước kỹ thuật cần thiết để hoàn thành một câu chuyện. Một cốt truyện lớn nên được chia thành các câu chuyện trước. Các nhiệm vụ được suy ra từ các câu chuyện trong quá trình lập kế hoạch sprint.
Câu hỏi: Nếu cốt truyện lớn phụ thuộc vào một nhà cung cấp bên ngoài thì sao?
Chia công việc dựa trên những gì bạn kiểm soát được. Tạo các câu chuyện cho những phần tích hợp mà bạn có thể xây dựng, và sử dụng các spike hoặc câu chuyện kỹ thuật để tìm hiểu API của nhà cung cấp. Nếu có thể, đừng để toàn bộ cốt truyện lớn bị đình trệ vì tiến độ của nhà cung cấp.
Câu hỏi: Chúng ta nên chia theo mô-đun hay theo luồng người dùng?
Chia theo luồng người dùng. Việc chia theo mô-đun thường dẫn đến việc cắt ngang, làm chậm việc cung cấp giá trị. Việc chia theo luồng người dùng đảm bảo rằng mỗi lần phát hành đều cung cấp một phần chức năng sử dụng được.
🌟 Những suy nghĩ cuối cùng
Chia nhỏ các cốt truyện lớn thành các thẻ câu chuyện nhỏ là một nguyên tắc nền tảng trong việc giao hàng sản phẩm. Nó biến sự phức tạp đáng sợ thành chuỗi các mục tiêu khả thi. Bằng cách tập trung vào giá trị, duy trì tính độc lập và hợp tác chặt chẽ với đội phát triển, các tổ chức có thể đảm bảo tiến độ ổn định và kết quả chất lượng cao. Cách tiếp cận này không chỉ quản lý công việc; nó còn quản lý rủi ro và tối đa hóa lợi nhuận đầu tư cho mỗi dòng mã được viết. Với các kỹ thuật phù hợp và cam kết cải tiến liên tục, các đội có thể vượt qua những dự án tham vọng nhất một cách tự tin và rõ ràng.
