Trong thế giới phát triển phần mềm đầy tốc độ, khoảng cách giữa một ý tưởng lớn và một tính năng có thể giao nộp thường được lấp đầy bởi một chuỗi các nhiệm vụ phức tạp. Khi một câu chuyện người dùng đơn lẻ trở nên quá lớn, nó trở thành điểm nghẽn. Nó làm chậm tiến độ, che giấu rủi ro và khiến việc kiểm thử trở thành ác mộng. Hiện tượng này thường được gọi là một spike hoặc một epic được che giấu dưới dạng một câu chuyện. Thách thức nằm ở việc chia nhỏ chúng thành những phần dễ quản lý mà không làm mất đi mục đích ban đầu hay mạch truyện kết nối chúng lại với nhau.
Hướng dẫn này khám phá nghệ thuật và khoa học của việc chia nhỏ các câu chuyện người dùng lớn một cách hiệu quả. Chúng ta sẽ xem xét các chiến lược để duy trì bối cảnh, đảm bảo mỗi phần nhỏ đều mang lại giá trị và giữ cho đội nhóm thống nhất. Bằng cách nắm vững các cơ chế phân rã, các đội nhóm có thể cải thiện độ dự đoán và chất lượng mà không hy sinh cái nhìn toàn diện về sản phẩm.
⚠️ Chi phí ẩn giấu của các câu chuyện quá lớn
Trước khi tìm kiếm giải pháp, điều quan trọng là phải hiểu tại sao các câu chuyện lớn lại gây vấn đề. Một câu chuyện quá lớn sẽ không vượt qua được thử thách của thời gian. Nó không thể hoàn thành trong một lần sprint duy nhất, dẫn đến công việc chưa hoàn thiện bị treo lơ lửng. Điều này tạo ra nợ kỹ thuật và sự bất định.
Hãy cân nhắc các rủi ro liên quan đến việc giữ các câu chuyện lớn:
- Phản hồi bị chậm trễ:Các bên liên quan không thấy phần mềm hoạt động cho đến tận cuối chu kỳ. Lúc đó, hướng đi có thể đã thay đổi.
- Độ phức tạp kiểm thử:Các đội QA gặp khó khăn khi kiểm chứng một tập hợp tính năng khổng lồ trong một lần duy nhất. Các trường hợp biên tăng lên theo cấp số nhân.
- Rủi ro tích hợp:Kết hợp nhiều thành phần chưa được kiểm thử làm tăng khả năng xảy ra xung đột trong cơ sở mã nguồn.
- Suy kiệt đội nhóm:Làm việc với một nhiệm vụ đồ sộ trong nhiều tuần làm cạn kiệt động lực. Sự thiếu vắng những thành công nhỏ làm tổn thương tinh thần đội nhóm.
- Sai lệch ước lượng:Các câu chuyện lớn vốn dĩ rất khó ước lượng chính xác. Điều này dẫn đến việc bỏ lỡ tiến độ và giảm tốc độ phát triển.
Để giảm thiểu những vấn đề này, các đội nhóm cần áp dụng một cách tiếp cận có kỷ luật trong việc phân rã. Mục tiêu không chỉ là làm cho các nhiệm vụ nhỏ lại, mà còn phải làm cho chúng mang lại giá trị.
🧱 Các nguyên tắc cốt lõi cho việc chia nhỏ hiệu quả
Việc chia nhỏ không phải ngẫu nhiên. Nó đòi hỏi tuân thủ các nguyên tắc cụ thể để đảm bảo các câu chuyện được tạo ra vẫn hữu ích. Khung mô hình được công nhận rộng rãi nhất cho điều này là INVESTmô hình. Khi chia nhỏ, mỗi câu chuyện mới nên phù hợp với các tiêu chí này:
- IĐộc lập: Câu chuyện không được phụ thuộc vào các câu chuyện khác để hoạt động.
- N
- VCó giá trị: Mỗi phần nhỏ phải mang lại giá trị cho người dùng hoặc bên liên quan.
- E
- SNhỏ: Nó phải vừa vặn trong một sprint.
- TXác định rõ: Các tiêu chí chấp nhận phải rõ ràng.
Khi một câu chuyện được chia nhỏ, tiêu chíGiá trị là yếu tố quan trọng nhất. Một câu chuyện chia nhỏ không thể hoạt động độc lập sẽ không mang lại giá trị. Nếu người dùng không thể sử dụng tính năng, thì việc chia nhỏ là sai.
📊 So sánh các tiêu chí chia nhỏ
| Tiêu chí | Trọng tâm | Ứng dụng ví dụ |
|---|---|---|
| Cắt dọc | Chức năng kết nối đầu đến cuối | Thêm một trường mới duy nhất vào biểu mẫu và hiển thị nó. |
| Cắt ngang | Triển khai theo lớp | Tái cấu trúc lược đồ cơ sở dữ liệu cho toàn hệ thống. |
| Xử lý ngoại lệ | Các trường hợp biên và lỗi | Xử lý thời gian chờ mạng hết hạn hoặc nhập dữ liệu không hợp lệ. |
| Sự biến đổi dữ liệu | Sự khác biệt về nội dung | Hỗ trợ các loại tiền tệ hoặc ngôn ngữ khác nhau. |
🔪 Chiến lược cắt dọc
Cắt dọc là tiêu chuẩn vàng để chia nhỏ các câu chuyện người dùng. Nó bao gồm việc cắt xuyên suốt tất cả các lớp của ứng dụng (cơ sở dữ liệu, logic kinh doanh, giao diện người dùng) để cung cấp một phần chức năng cụ thể và hoạt động. Điều này đảm bảo rằng mỗi câu chuyện tạo ra một bước tiến có thể triển khai.
1. Chia theo tính năng
Nếu một câu chuyện mô tả một quy trình phức tạp, hãy chia nhỏ theo các hành động cụ thể mà người dùng có thể thực hiện. Thay vì xây dựng toàn bộ quy trình thanh toán cùng một lúc, hãy tách riêng từng bước.
- Câu chuyện gốc: Là một người mua sắm, tôi muốn hoàn tất việc mua hàng để có thể mua các mặt hàng.
- Phân chia 1:Là một người mua sắm, tôi muốn thêm các mặt hàng vào giỏ hàng để có thể xem xét lựa chọn của mình.
- Phân chia 2:Là một người mua sắm, tôi muốn nhập thông tin giao hàng để có thể tiến hành thanh toán.
- Phân chia 3:Là một người mua sắm, tôi muốn chọn phương thức thanh toán để có thể hoàn tất đơn hàng.
Mỗi phần này là một giá trị độc lập. Giỏ hàng hoạt động mà không cần thông tin giao hàng. Giao hàng hoạt động mà không cần thanh toán (dành cho mục đích xem trước). Điều này cho phép triển khai từng bước.
2. Phân chia ngoại lệ
Thường thì con đường chính (happy path) đơn giản, nhưng các trường hợp biên lại khiến câu chuyện trở nên lớn hơn. Việc tách biệt con đường chính khỏi con đường ngoại lệ có thể làm rõ yêu cầu và giảm thiểu rủi ro.
- Câu chuyện gốc:Là một người dùng, tôi muốn đặt lại mật khẩu của mình để có thể lấy lại quyền truy cập.
- Phân chia 1 (Con đường chính):Là một người dùng, tôi muốn nhận một liên kết đặt lại mật khẩu qua email để có thể thay đổi mật khẩu của mình.
- Phân chia 2 (Ngoại lệ):Là một người dùng, tôi muốn được thông báo nếu email của tôi không được tìm thấy để có thể sửa lại đầu vào của mình.
- Phân chia 3 (Ngoại lệ):Là một người dùng, tôi muốn khóa tài khoản của mình sau nhiều lần thử đăng nhập thất bại để đảm bảo an toàn.
3. Phân chia sự thay đổi dữ liệu
Hỗ trợ các loại dữ liệu khác nhau thường làm cho câu chuyện trở nên cồng kềnh. Bằng cách tách biệt các loại dữ liệu, các đội có thể đơn giản hóa việc xác thực và logic.
- Câu chuyện gốc:Là một quản trị viên, tôi muốn tải lên các báo cáo ở định dạng CSV, PDF và Excel.
- Phân chia 1:Là một quản trị viên, tôi muốn tải lên các báo cáo CSV.
- Phân chia 2:Là một quản trị viên, tôi muốn tải lên các báo cáo PDF.
- Phân chia 3:Là một quản trị viên, tôi muốn tải lên các báo cáo Excel.
🏗️ Khi nào nên sử dụng phân chia ngang
Phân chia dọc không phải lúc nào cũng là giải pháp. Đôi khi, phân chia ngang là cần thiết. Điều này bao gồm việc xây dựng chức năng từng lớp một trên toàn bộ hệ thống. Mặc dù điều này không tạo ra giá trị cho người dùng ngay lập tức, nhưng nó hữu ích cho nền tảng kỹ thuật.
Sử dụng phân chia ngang khi:
- Tái cấu trúc: Bạn cần cập nhật một thư viện được sử dụng bởi mọi tính năng.
- Hạ tầng: Bạn đang thiết lập một lược đồ cơ sở dữ liệu mới hoặc cổng API.
- Bảo mật: Bạn đang triển khai xác thực trên toàn bộ ứng dụng.
- Hiệu suất: Bạn đang tối ưu lớp bộ nhớ đệm cho tất cả các điểm cuối.
Ngay cả khi sử dụng các mảnh ngang, hãy cố gắng giữ chúng nhỏ đến mức có thể kiểm thử độc lập. Một phân chia ngang ảnh hưởng đến mọi module vẫn nên được coi là một câu chuyện duy nhất.
🧭 Bảo tồn ngữ cảnh trong quá trình phân tách
Rủi ro lớn nhất khi phân tách là mất đi ngữ cảnh. Nếu một thành viên đội ngũ nhận một câu chuyện nhỏ mà không hiểu nó phù hợp như thế nào vào bức tranh lớn, việc triển khai có thể lệch khỏi tầm nhìn ban đầu. Điều này được gọi là chuyển đổi ngữ cảnh hoặc phân mảnh.
1. Liên kết các câu chuyện lại với nhau
Sử dụng mối quan hệ cha-con trong hệ thống quản lý danh sách chờ. Đánh dấu câu chuyện lớn ban đầu là một epic hoặc cha. Mỗi câu chuyện được chia nhỏ nên tham chiếu đến ID cha. Điều này tạo ra một chuỗi truy xuất nguồn gốc.
- Epic: Triển khai quản lý hồ sơ người dùng.
- Câu chuyện A: Thêm chức năng tải lên ảnh hồ sơ.
- Câu chuyện B: Cập nhật thông tin liên hệ.
- Câu chuyện C:Thay đổi cài đặt mật khẩu.
Cấu trúc này đảm bảo rằng khi xem xét Câu chuyện A, nhà phát triển sẽ thấy Câu chuyện B và Câu chuyện C đang đến. Nó cung cấp bản đồ hành trình cho toàn bộ tính năng.
2. Tiêu chí chấp nhận chung
Một số quy tắc áp dụng cho toàn bộ tính năng, chứ không chỉ riêng phần nhỏ. Xác định những quy tắc này trong tài liệu chung hoặc phần chung trong mẫu câu chuyện. Điều này đảm bảo tính nhất quán.
- Bảo mật:Mọi cập nhật hồ sơ đều phải yêu cầu xác thực lại.
- Hiệu suất:Thời gian tải trang phải luôn dưới 2 giây.
- Khả năng truy cập:Tất cả các trường biểu mẫu phải có nhãn phù hợp cho trình đọc màn hình.
Bằng cách liệt kê những điều này ở cấp độ toàn cục, mỗi câu chuyện được chia nhỏ sẽ kế thừa các ràng buộc. Điều này ngăn chặn một phần nhỏ gây ra lỗi bảo mật ảnh hưởng đến toàn bộ hệ thống.
3. Bản đồ trực quan
Bản đồ câu chuyện người dùng là một kỹ thuật mạnh mẽ để trực quan hóa luồng hoạt động. Tạo danh sách công việc theo trục ngang với các hoạt động của người dùng và các câu chuyện hỗ trợ chúng theo trục dọc. Điều này tạo nên khung xương cho tính năng.
Bản đồ này đóng vai trò như một hợp đồng trực quan. Khi chia nhỏ một câu chuyện, đội có thể tham khảo bản đồ để biết điều gì xảy ra trước và sau. Điều này ngăn đội xây dựng một câu chuyện một cách cô lập làm gián đoạn luồng trải nghiệm người dùng.
🚫 Những sai lầm phổ biến cần tránh
Ngay cả với những ý định tốt, việc chia nhỏ cũng có thể sai. Dưới đây là những sai lầm phổ biến mà các đội thường mắc phải khi cố gắng giảm kích thước câu chuyện.
- Chia nhỏ quá mức:Chia nhỏ câu chuyện đến mức chỉ mất 2 giờ để hoàn thành. Điều này làm tăng chi phí cho các cuộc họp và cập nhật. Nhắm đến các câu chuyện mất từ 1 đến 3 ngày.
- Chia nhỏ theo công nghệ:Không chia nhỏ một câu chuyện chỉ vì nó bao gồm nhiệm vụ phía backend và phía frontend. Nếu nhiệm vụ phía frontend yêu cầu backend phải hoàn thành trước, đó là một phụ thuộc, chứ không phải là sự chia nhỏ theo giá trị. Điều này tạo ra mô hình thác nước trong sprint.
- Mất đi người dùng:Chia nhỏ câu chuyện thành các nhiệm vụ kỹ thuật (ví dụ: “Tạo bảng cơ sở dữ liệu”) mà không có tuyên bố giá trị cho người dùng (ví dụ: “Là người dùng, tôi muốn lưu tiến độ của mình”).
- Bỏ qua các phụ thuộc:Không kiểm tra xem một câu chuyện được chia nhỏ có làm tắc nghẽn câu chuyện khác hay không. Điều này dẫn đến thời gian rảnh cho các thành viên trong đội.
- Tiêu chí chấp nhận bị trùng lặp:Sao chép và dán tiêu chí chấp nhận mà không cập nhật cho phần cụ thể. Điều này dẫn đến sự nhầm lẫn trong quá trình kiểm thử.
📋 Danh sách kiểm tra cho việc chia nhỏ câu chuyện
Trước khi hoàn tất việc chia nhỏ, hãy đi qua danh sách kiểm tra này để đảm bảo chất lượng và sự rõ ràng.
- ☐ Câu chuyện được chia nhỏ này có mang lại giá trị độc lập không?
- ☐ Có thể kiểm thử độc lập không?
- ☐ Ước tính nỗ lực có thực tế cho một sprint không?
- ☐ Các phụ thuộc có được xác định rõ ràng không?
- ☐ Câu chuyện có liên kết trở lại cốt truyện gốc không?
- ☐ Các tiêu chí chấp nhận có cụ thể cho phần này không?
- ☐ Nó có duy trì bối cảnh luồng người dùng không?
- ☐ Chúng ta đã cân nhắc các đường dẫn ngoại lệ chưa?
🔄 Kỹ thuật tinh chỉnh
Việc chia nhỏ không phải là một sự kiện duy nhất. Đó là một cuộc trò chuyện liên tục trong quá trình tinh chỉnh danh sách công việc. Khi đội học thêm nhiều về vấn đề, các câu chuyện có thể cần được chia nhỏ hơn nữa hoặc kết hợp lại.
1. Cuộc tranh luận về “Làm thế nào” so với “Điều gì”
Đảm bảo câu chuyện tập trung vào điều gì (giá trị người dùng) thay vì làm thế nào (thực hiện kỹ thuật). Nếu một câu chuyện lớn vì đội không biết cách xây dựng nó, thì đó là một nghiên cứu, chứ không phải một câu chuyện. Tách phần nghiên cứu ra thành một nhiệm vụ nghiên cứu.
- Xấu: Là một người dùng, tôi muốn hệ thống sử dụng bộ nhớ đệm Redis để đọc nhanh hơn.
- Tốt: Là một người dùng, tôi muốn bảng điều khiển tải trong dưới 1 giây.
- Nghiên cứu đột phá: Đánh giá các tùy chọn triển khai Redis và ước tính nỗ lực.
2. Tinh chỉnh theo từng bước
Bắt đầu bằng việc chia nhỏ thô. Khi sprint bắt đầu, đội có thể nhận ra phần chia nhỏ vẫn quá lớn. Được phép chia nhỏ một câu chuyện trong sprint nếu rủi ro quá cao. Tuy nhiên, điều này nên xảy ra hiếm khi. Các buổi tinh chỉnh định kỳ trước khi lập kế hoạch sprint sẽ giúp ngăn ngừa điều này.
🤔 Câu hỏi thường gặp
Dưới đây là những câu hỏi phổ biến mà các đội thường đặt ra khi xử lý các câu chuyện lớn.
Câu hỏi: Làm sao để biết một câu chuyện quá lớn?
Trả lời: Nếu đội không thể thống nhất về ước tính, hoặc nếu câu chuyện đòi hỏi hơn một sprint để hoàn thành, thì nó quá lớn. Ngoài ra, nếu kiểm thử cảm giác quá áp lực, thì có khả năng nó quá lớn.
Câu hỏi: Tôi có nên chia nhỏ câu chuyện dựa trên ai thực hiện công việc không?
Trả lời: Không. Chia theo vai trò (ví dụ: “Nhiệm vụ Frontend”, “Nhiệm vụ Backend”) sẽ tạo ra các phụ thuộc. Hãy chia theo giá trị hoặc chức năng để bất kỳ thành viên nào trong đội cũng có thể nhận công việc và tiến triển nó.
Câu hỏi: Nếu khách hàng muốn toàn bộ tính năng một lúc thì sao?
Trả lời: Truyền đạt các rủi ro. Giải thích rằng việc giao hàng theo từng phần giúp nhận phản hồi sớm và giảm khả năng xây dựng sai thứ. Đề xuất phần nhỏ nhất cung cấp lợi ích cốt lõi trước tiên.
Câu hỏi: Tất cả các câu chuyện có cần phải được chia theo chiều dọc không?
Trả lời: Hầu hết nên như vậy. Các mảnh dọc mang lại giá trị. Các mảnh ngang dành cho nợ kỹ thuật hoặc cơ sở hạ tầng. Nếu một mảnh ngang quá lớn, hãy chia nó theo thành phần hoặc mô-đun, nhưng đảm bảo nó vẫn là một câu chuyện kỹ thuật.
🏁 Những suy nghĩ cuối cùng
Việc chia nhỏ các câu chuyện người dùng lớn là một sự cân bằng. Nó đòi hỏi sự phán đoán, kinh nghiệm và giao tiếp rõ ràng. Mục tiêu không chỉ là làm cho công việc nhỏ lại, mà còn làm cho nó có giá trị hơn. Khi thực hiện đúng, việc chia nhỏ sẽ giảm rủi ro, cải thiện chất lượng và giúp đội ngũ tập trung vào việc cung cấp những điều thực sự quan trọng với người dùng.
Bằng cách tuân thủ các nguyên tắc chia theo chiều dọc, duy trì bối cảnh thông qua liên kết và bản đồ hóa, và tránh những sai lầm phổ biến, các đội có thể điều hướng các tính năng phức tạp một cách tự tin. Kết quả là dòng chảy ổn định của phần mềm hoạt động và một bên liên quan hài lòng. Tiếp tục tinh chỉnh cách tiếp cận của bạn, và để dữ liệu từ các đợt sprint dẫn dắt quyết định chia nhỏ trong tương lai.
