Trong thế giới phát triển linh hoạt, trọng tâm thường rơi nặng nề vào các yêu cầu chức năng. Chúng ta đặt câu hỏi: “Hệ thống làm gì?” và “Người dùng tương tác với nó như thế nào?”. Mặc dù những câu hỏi này thúc đẩy việc giao hàng tính năng, chúng thường để lại một khoảng trống nghiêm trọng: hệ thống thực hiện nhiệm vụ của mình tốt đến mức nào?. Khoảng trống này chính là nơi các Yêu cầu Phi chức năng (NFRs) tồn tại. Bỏ qua chúng dẫn đến nợ kỹ thuật, hệ thống chậm chạp và người dùng thất vọng.
Hướng dẫn này khám phá cách tích hợp các thuộc tính chất lượng trực tiếp vào các câu chuyện người dùng của bạn. Bằng cách coi chất lượng như một tính năng thay vì suy nghĩ sau, các đội có thể xây dựng phần mềm vững chắc, đáng tin cậy và mở rộng được mà không cần hy sinh tốc độ.
Hiểu rõ sự khác biệt 🧠
Trước khi bước vào tích hợp, chúng ta phải định nghĩa rõ các thuật ngữ. Một Câu chuyện Người dùng mô tả chức năng từ góc nhìn của người dùng.
- Yêu cầu chức năng: Xác định hành vi. Ví dụ: “Là một người dùng, tôi muốn đặt lại mật khẩu của mình.”
- Yêu cầu phi chức năng: Xác định các ràng buộc và đặc tính. Ví dụ: “Liên kết đặt lại mật khẩu phải hết hạn trong 15 phút.” hoặc “Trang phải tải trong dưới 2 giây.”
Các yêu cầu chức năng cho bạn biết gìcần xây dựng. Các yêu cầu phi chức năng cho bạn biết như thế nàonó nên hoạt động ra sao. Khi hai loại này bị tách rời, các NFR thường bị dồn đến cuối sprint hoặc hoàn toàn bị bỏ qua. Điều này dẫn đến sản phẩm “chạy được nhưng chậm” hoặc “chạy được nhưng không an toàn”.
Tại sao các NFR lại bị bỏ qua ❌
Hiểu rõ lý do tại sao các đội gặp khó khăn với các NFR sẽ giúp ngăn chặn vấn đề này.
- Giá trị vô hình:Người dùng hiếm khi phàn nàn về hiệu suất cho đến khi nó trở nên quá chậm. Họ nhận ra khi một tính năng bị thiếu, nhưng thường chấp nhận chất lượng kém trong một thời gian.
- Độ phức tạp kỹ thuật:Các nhà phát triển thích xây dựng tính năng mới. Kiểm thử thời gian tải hoặc các giao thức bảo mật đòi hỏi nỗ lực chuyên biệt, cảm giác như tách rời khỏi câu chuyện người dùng.
- Định nghĩa mơ hồ:Các thuật ngữ như “nhanh” hay “an toàn” mang tính chủ quan. Không có chỉ số đo lường, các tiêu chí chấp nhận không thể được đáp ứng một cách khách quan.
- Các đội làm việc tách biệt:Các kiến trúc sư thiết kế hệ thống, nhưng các Chủ sản phẩm định nghĩa các câu chuyện. Nếu họ không giao tiếp, các tiêu chuẩn chất lượng sẽ bị bỏ sót.
Chiến lược tích hợp 🛠️
Có ba phương pháp chính để đảm bảo các NFR được giải quyết trong quá trình phát triển. Việc sử dụng các phương pháp này đảm bảo chất lượng được tích hợp vào quy trình.
1. Tiêu chuẩn Hoàn thành (DoD) 🏁
Tiêu chuẩn Hoàn thành là một danh sách kiểm tra áp dụng chomỗikể hoạch người dùng. Nó đảm bảo tính nhất quán trong danh sách công việc. Thay vì tạo một vé riêng cho bảo mật, bạn đưa các kiểm tra bảo mật vào DoD.
- Mọi mã nguồn phải vượt qua phân tích tĩnh.
- Tất cả các bài kiểm thử đơn vị phải đạt kết quả.
- Việc xem xét mã nguồn phải được hoàn thành bởi ít nhất hai đồng nghiệp.
- Kiểm tra NFR: Tính năng có đáp ứng ngưỡng hiệu suất không?
- Kiểm tra NFR: Việc tuân thủ khả năng truy cập đã được xác minh chưa?
Cách tiếp cận này ngăn chặn việc đánh dấu một câu chuyện là “Hoàn thành” cho đến khi các tiêu chuẩn chất lượng được đáp ứng. Nó phân bổ trách nhiệm trên toàn bộ đội ngũ.
2. Nhúng vào Tiêu chí Chấp nhận ✅
Một số NFR chỉ liên quan đến một tính năng duy nhất. Những điều này nên nằm trong phần Tiêu chí Chấp nhận của Kể hoạch Người dùng. Điều này giúp yêu cầu chất lượng trở nên rõ ràng và có thể kiểm thử cho câu chuyện cụ thể đó.
Ví dụ Kể hoạch: Là một người mua sắm, tôi muốn lọc sản phẩm theo khoảng giá.
Tiêu chí Chức năng:Thanh trượt điều chỉnh khoảng giá; kết quả được cập nhật động.
Tiêu chí NFR:Kết quả lọc phải xuất hiện trong vòng 500ms kể từ khi di chuyển thanh trượt.
Bằng cách đặt điều này vào tiêu chí, nhà phát triển biết chính xác chỉ số hiệu suất nào cần tối ưu hóa. Người kiểm thử biết chính xác cần đo lường điều gì.
3. Câu chuyện NFR Độc lập 📋
Đôi khi, một NFR quá lớn để vừa vào một câu chuyện chức năng duy nhất. Nếu việc cải thiện kiến trúc cơ sở dữ liệu là cần thiết để hỗ trợ một tính năng mới, nó có thể cần một vé riêng. Điều này thường được gọi làCâu chuyện Kỹ thuật hoặc Câu chuyện Khuyến khích.
- Khi nào nên dùng:Tái cấu trúc mã nguồn, nâng cấp hạ tầng hoặc triển khai một khung bảo mật mới.
- Mục tiêu: Những câu chuyện này cung cấp khả năng đưa các câu chuyện chức năng trong tương lai ra nhanh hơn và an toàn hơn.
- Cân bằng: Đừng để các câu chuyện kỹ thuật chiếm ưu thế trong danh sách công việc. Chúng nên hỗ trợ giá trị kinh doanh, chứ không nên tồn tại một cách cô lập.
Các danh mục chính của yêu cầu phi chức năng 📊
Không phải tất cả các NFR đều có giá trị như nhau. Dưới đây là phân tích các danh mục quan trọng nhất và cách xử lý chúng.
| Danh mục | Câu hỏi cần đặt ra | Chỉ số ví dụ |
|---|---|---|
| Hiệu suất | Nó phản hồi nhanh đến mức nào? | Thời gian tải trang < 2 giây |
| Bảo mật | Dữ liệu có được bảo vệ không? | Yêu cầu mã hóa đầu đến đầu |
| Độ tin cậy | Nó thường xuyên thất bại bao nhiêu lần? | Khả năng hoạt động liên tục 99,9% |
| Khả năng mở rộng | Nó có thể xử lý sự tăng trưởng không? | Hỗ trợ 10.000 người dùng đồng thời |
| Tính dễ sử dụng | Nó có dễ sử dụng không? | Tỷ lệ hoàn thành nhiệm vụ > 90% |
| Khả năng bảo trì | Mã nguồn có dễ thay đổi không? | Độ phức tạp vòng lặp < 10 |
Phân tích sâu: Hiệu suất ⚡
Các yêu cầu phi chức năng về hiệu suất thường là điều dễ thấy nhất đối với người dùng. Hệ thống chậm dẫn đến việc người dùng bỏ cuộc. Để quản lý những điều này:
- Đặt các tiêu chuẩn ban đầu: Sử dụng các chỉ số hệ thống hiện có làm tiêu chuẩn ban đầu. Nếu hệ thống cũ mất 3 giây, hệ thống mới nên mất ít hơn, chứ không phải nhiều hơn.
- Xác định ngưỡng:Phân biệt giữa “được chấp nhận” và “mức nghiêm trọng”. Một độ trễ 200ms có thể chấp nhận được đối với một báo cáo, nhưng không thể chấp nhận được đối với một cuộc trò chuyện thời gian thực.
- Tự động hóa giám sát:Tích hợp các bài kiểm thử hiệu suất vào luồng tích hợp liên tục. Nếu một bản ghi làm giảm tốc độ, quá trình xây dựng phải thất bại.
Phân tích sâu: Bảo mật 🔒
Bảo mật không phải là một tính năng; nó là điều kiện tiên quyết. Tuy nhiên, những nhu cầu bảo mật cụ thể sẽ phát sinh khi có tính năng.
- Xác thực:Câu chuyện này có yêu cầu xác thực đa yếu tố không?
- Bảo mật dữ liệu:Tính năng này có lưu trữ thông tin nhận dạng cá nhân không? Nếu có, nó được che khuất hay mã hóa như thế nào?
- Dòng nhật ký kiểm toán:Các hành động có cần được ghi lại để tuân thủ không?
Đảm bảo các nhà phát triển biết phân loại dữ liệu nào áp dụng cho tính năng mới. Điều này xác định mức độ bảo vệ cần thiết.
Phân tích sâu: Khả năng mở rộng 📈
Khả năng mở rộng liên quan đến cách hệ thống phát triển. Điều này thường là một quyết định về kiến trúc.
- Mở rộng theo chiều dọc so với mở rộng theo chiều ngang:Tính năng này có yêu cầu nhiều sức mạnh hơn trên một máy chủ duy nhất, hay cần thêm máy chủ?
- Điểm nghẽn:Xác định nơi nào tải tăng lên. Có phải cơ sở dữ liệu? API? Việc hiển thị phía frontend?
- Chuẩn bị cho tương lai:Hỏi: “Liệu điều này có hoạt động nếu lưu lượng tăng gấp đôi vào tháng tới?” Nếu câu trả lời là không, câu chuyện cần có thành phần về khả năng mở rộng.
Vai trò của Tiêu chí chấp nhận 📝
Tiêu chí chấp nhận (AC) là hợp đồng giữa bộ phận kinh doanh và nhóm phát triển. Nó định nghĩa thành công. Các yêu cầu không chức năng (NFR) phải được viết dưới dạng AC có thể kiểm thử.
Ví dụ xấu
AC:Hệ thống phải nhanh.
Vấn đề:“Nhanh” là mang tính chủ quan. Điều nhanh đối với người này có thể chậm đối với người khác.
Ví dụ tốt
AC: Trang kết quả tìm kiếm phải tải trong vòng 1,5 giây đối với 95% các yêu cầu.
Lợi ích: Điều này có thể đo lường được. Một bài kiểm thử có thể đạt hoặc không đạt dựa trên con số này.
Lời khuyên khi viết tiêu chí chấp nhận NFR
- Sử dụng con số:Đo lường mọi thứ có thể (thời gian, số lượng, kích thước).
- Sử dụng điều kiện:Xác định điều kiện nào thì chỉ số này áp dụng (ví dụ: “trên kết nối 4G”).
- Xác định thất bại:Rõ ràng nêu rõ điều gì xảy ra nếu NFR không đạt được.
Kiểm thử các yêu cầu phi chức năng 🧪
Kiểm thử chức năng xác minh hành vi. Kiểm thử NFR xác minh chất lượng. Cả hai đều cần thiết.
- Kiểm thử đơn vị:Nhà phát triển viết những kiểm thử này để xác minh logic. Chúng thường không đo lường hiệu suất.
- Kiểm thử tích hợp:Xác minh các thành phần hoạt động cùng nhau. Là nơi lý tưởng để kiểm tra độ trễ API.
- Kiểm thử tải:Mô phỏng lưu lượng người dùng. Bắt buộc đối với các câu chuyện về hiệu suất và khả năng mở rộng.
- Quét bảo mật:Các công cụ tự động có thể quét mã nguồn để tìm lỗ hổng bảo mật. Kiểm thử xâm nhập thủ công có thể được yêu cầu đối với các tính năng nhạy cảm.
- Kiểm thử khả năng truy cập:Các công cụ tự động kiểm tra độ tương phản và cấu trúc. Kiểm thử thủ công bằng máy đọc màn hình xác minh tính khả dụng trong thực tế.
Không nên chỉ dựa vào nhà phát triển để kiểm thử NFR. Các kỹ sư đảm bảo chất lượng cần tham gia vào quá trình lập kế hoạch để đảm bảo môi trường kiểm thử hỗ trợ tải trọng hoặc cấu hình yêu cầu.
Hợp tác và giao tiếp 🤝
Quản lý NFR là một môn thể thao đồng đội. Nó đòi hỏi sự đóng góp từ nhiều vai trò khác nhau.
Người sở hữu sản phẩm
- Ưu tiên các câu chuyện cải thiện chất lượng.
- Đảm bảo danh sách công việc phản ánh các rủi ro kinh doanh (ví dụ: tuân thủ bảo mật).
- Xác định “giá trị” của một hệ thống nhanh so với một hệ thống chậm.
Đội phát triển
- Xác định các hạn chế kỹ thuật trong quá trình tinh chỉnh.
- Đề xuất các thay đổi kiến trúc để đáp ứng các yêu cầu phi chức năng (NFRs).
- Thực thi mã nguồn để đạt được các chỉ số đo lường.
Đảm bảo chất lượng
- Thiết kế các bài kiểm thử cho các yêu cầu phi chức năng (ví dụ: kịch bản tải).
- Xác minh rằng các chỉ số được đáp ứng trước khi phát hành.
- Báo cáo các suy giảm trong các chỉ số chất lượng.
Lãnh đạo kiến trúc / Kỹ thuật
- Đặt ra các tiêu chuẩn về khả năng bảo trì và bảo mật.
- Xem xét lại thiết kế để đảm bảo khả năng mở rộng.
- Tư vấn về các thỏa hiệp khi tốc độ kinh doanh mâu thuẫn với chất lượng kỹ thuật.
Những sai lầm phổ biến cần tránh 🚫
Tránh những sai lầm này để duy trì sự cân bằng lành mạnh giữa tính năng và chất lượng.
- Quá thiết kế:Xây dựng cho 1 triệu người dùng khi bạn chỉ có 100. Điều này tốn thời gian. Điều chỉnh các yêu cầu phi chức năng phù hợp với bối cảnh hiện tại, nhưng vẫn có khả năng mở rộng.
- Bỏ qua hệ thống cũ:Các tính năng mới thường tương tác với mã nguồn cũ. Các yêu cầu phi chức năng phải xem xét tác động đến hệ thống hiện có.
- Tư duy theo mô hình thác nước:Đừng chờ đến cuối dự án mới kiểm thử hiệu năng. Hãy kiểm thử từng bước một.
- Bỏ qua trải nghiệm người dùng (UX):Các yêu cầu phi chức năng về hiệu năng quan trọng, nhưng tính dễ sử dụng cũng quan trọng không kém. Một trang web nhanh nhưng gây nhầm lẫn vẫn là thất bại.
Đo lường thành công 📉
Làm sao bạn biết quản lý yêu cầu phi chức năng của bạn có hiệu quả không? Theo dõi các chỉ số này theo thời gian.
- Thời gian dẫn đầu:Các câu chuyện yêu cầu phi chức năng có làm chậm tiến độ giao hàng không? Nếu có, hãy tinh chỉnh tiêu chí.
- Tỷ lệ lỗi:Các lỗi liên quan đến hiệu năng hoặc bảo mật có đang giảm dần không?
- Mức độ hài lòng của khách hàng:Người dùng có báo cáo ít khiếu nại hơn về tốc độ hoặc sự sập hệ thống không?
- Độ ổn định của bản dựng: Số lượng bản dựng thất bại do các cửa chất lượng có giảm không?
Cải tiến liên tục phụ thuộc vào dữ liệu. Xem xét các chỉ số này trong các buổi tổng kết để điều chỉnh phương pháp của bạn.
Ví dụ thực tế: Tính năng Đăng nhập 🔐
Hãy cùng xem một câu chuyện người dùng hoàn chỉnh bao gồm các yêu cầu phi chức năng (NFRs).
Câu chuyện
Tiêu đề:Đăng nhập người dùng an toàn
Mô tả:Là một người dùng đã đăng ký, tôi muốn đăng nhập một cách an toàn để có thể truy cập tài khoản của mình.
Tiêu chí chấp nhận
- Chức năng:Người dùng nhập địa chỉ email và mật khẩu. Hệ thống xác thực thông tin đăng nhập. Chuyển hướng đến bảng điều khiển khi thành công.
- Chức năng:Hệ thống chặn truy cập nếu thông tin đăng nhập không đúng.
- Yêu cầu phi chức năng (Bảo mật):Mật khẩu phải được mã hóa bằng các thuật toán tiêu chuẩn ngành. Mã thông báo phiên phải hết hạn sau 30 phút không hoạt động.
- Yêu cầu phi chức năng (Hiệu suất):Thời gian phản hồi đăng nhập phải dưới 1 giây.
- Yêu cầu phi chức năng (Bảo mật):Tài khoản phải bị khóa sau 5 lần thử đăng nhập thất bại để ngăn chặn các cuộc tấn công brute force.
- Yêu cầu phi chức năng (Truy cập được):Form đăng nhập phải có thể điều hướng bằng bàn phím duy nhất.
Lưu ý cách các yêu cầu phi chức năng được nêu rõ ràng và có thể kiểm thử. Chúng không phải là điều sau cùng. Chúng là một phần trong định nghĩa về thành công.
Xử lý nợ kỹ thuật 💣
Ngay cả với kế hoạch tốt nhất, nợ kỹ thuật vẫn tích lũy. Điều này xảy ra khi các yêu cầu phi chức năng bị ảnh hưởng để đáp ứng tiến độ.
- Theo dõi nó:Ghi rõ nợ kỹ thuật vào danh sách công việc. Đừng giấu nó.
- Tái cấu trúc thường xuyên:Dành một phần của mỗi vòng lặp để cải thiện chất lượng mã nguồn. Điều này thường được gọi là “vòng lặp tái cấu trúc” hoặc “vòng lặp chất lượng”.
- Trả nợ: Khi một câu chuyện yêu cầu nợ đáng kể để hoàn thành, hãy dành thời gian để khắc phục nợ đồng thời với tính năng.
- Ngăn chặn nợ mới:Thực thi nghiêm ngặt Tiêu chuẩn Hoàn thành. Không cho phép nợ tích tụ nếu có thể tránh được.
Bỏ qua nợ kỹ thuật giống như bỏ qua lãi suất trên khoản vay. Nó sẽ phát triển cho đến khi trở nên không thể trả được. Việc quản lý chủ động các yêu cầu phi chức năng giúp giữ cho nợ ở mức kiểm soát được.
Kết luận: Chất lượng là mặc định 🏆
Việc tích hợp các yêu cầu phi chức năng vào các câu chuyện người dùng không phải là thêm thủ tục rườm rà. Đó là về việc đồng bộ hóa thực hiện kỹ thuật với kỳ vọng của người dùng. Khi hiệu suất, bảo mật và độ tin cậy được coi là các yêu cầu rõ ràng, phần mềm được tạo ra sẽ ổn định và có giá trị hơn.
Bằng cách sử dụng Tiêu chuẩn Hoàn thành, viết các Tiêu chí Chấp nhận đo lường được và thúc đẩy sự hợp tác giữa các vai trò, các đội có thể cung cấp các tính năng chất lượng cao một cách nhất quán. Mục tiêu không phải là sự hoàn hảo, mà là cải tiến liên tục. Mỗi câu chuyện là cơ hội để xây dựng một hệ thống tốt hơn. Xem chất lượng như một thành phần cốt lõi của sản phẩm của bạn, và người dùng sẽ nhận thấy sự khác biệt.
Bắt đầu bằng cách xem xét danh sách công việc cho sprint tiếp theo của bạn. Xác định nơi nào thiếu các yêu cầu phi chức năng. Thêm chúng. Kiểm thử chúng. Cải thiện chúng. Hệ thống sẽ cảm ơn bạn.
