Lợi nhuận:
- Khả năng chuyển đổi các yêu cầu kinh doanh mơ hồ thành các yêu cầu phần mềm rõ ràng, có thể kiểm tra được và câu chuyện của người dùng với sự hỗ trợ của AI
- Khả năng so sánh ưu và nhược điểm của thiết kế hệ thống, mô hình dữ liệu và các quyết định kiến trúc theo cách có cấu trúc với AI
- Khả năng xác nhận nghiêm túc thiết kế được đề xuất của AI dựa trên các yêu cầu, khả năng mở rộng và ràng buộc
Phần lớn các dự án phần mềm thất bại không phải vì mã xấu mà vì hiểu sai yêu cầu. Yêu cầu một câu như “Cho phép người dùng tải xuống báo cáo” để lại hàng tá câu hỏi chưa được trả lời: Ở định dạng nào? Ai chịu trách nhiệm? Có bao nhiêu bản ghi? Nếu nó chậm thì sao? Phân tích yêu cầu (chuyển yêu cầu kinh doanh thành các nhu cầu kỹ thuật rõ ràng, có thể kiểm tra được) và thiết kế phần mềm (xây dựng cấu trúc trên giấy để đáp ứng các nhu cầu này) là giai đoạn ngăn ngừa những sai lầm đắt giá nhất trước khi viết mã. Trong phần này, chúng ta sẽ học cách sử dụng AI như một “đối tác tư tưởng” ở giai đoạn này: một đối tác làm sáng tỏ sự không chắc chắn, sắp xếp các lựa chọn nhưng để bạn đưa ra quyết định cuối cùng.
AI tạo ra hai giá trị lớn ở đây. Đầu tiên, nó hỏi những câu hỏi bạn bỏ qua; Nó làm nổi bật các giả định ẩn và các trường hợp khó khăn trong một yêu cầu. Thứ hai, nó nhanh chóng lập bảng những ưu và nhược điểm của một quyết định thiết kế. Nhưng đó chính là mối nguy hiểm: AI sẽ đưa ra các khuyến nghị chung chung là "phương pháp hay nhất" mà không biết đầy đủ về bối cảnh của bạn (ngân sách, nhóm, hệ thống hiện có, ràng buộc pháp lý). Công việc của bạn là sàng lọc lời khuyên này dựa trên sự thật của chính bạn.
Khái niệm: Câu chuyện của người dùng: Một câu ngắn thể hiện nhu cầu dưới dạng "... như, tôi muốn có thể... bởi vì...". Tiêu chí chấp nhận: Các điều kiện có thể kiểm tra phải được đáp ứng để một công việc được coi là "hoàn thành". Yêu cầu phi chức năng: Các yêu cầu liên quan đến "nó sẽ hoạt động như thế nào" hơn là "nó sẽ làm gì", chẳng hạn như tốc độ, bảo mật, khả năng mở rộng.
Từ yêu cầu mơ hồ đến yêu cầu có thể kiểm tra được
Một yêu cầu tốt là có thể đo lường được và kiểm chứng được. Không phải "để hệ thống nhanh" mà là "để kết quả tìm kiếm trả về trong vòng 500 mili giây". Dưới đây là cách từng bước sử dụng AI để thu hẹp sự không chắc chắn:
- Đưa ra yêu cầu nguyên trạng và tạo ra câu hỏi. Hỏi AI không phải về giải pháp mà trước tiên hãy "liệt kê bất kỳ điều gì chưa rõ ràng trong yêu cầu này dưới dạng câu hỏi".
- Bạn đưa ra câu trả lời. Chỉ có bạn biết bối cảnh; Trả lời các câu hỏi của AI với những ràng buộc kinh doanh thực sự của bạn.
- Dịch nó thành câu chuyện của người dùng và tiêu chí chấp nhận. Chuyển nhu cầu đã được làm rõ thành các mục có thể kiểm chứng được.
- Thêm các trường hợp đặc biệt và kịch bản tiêu cực. "Kết quả trống", "người dùng trái phép", "tệp quá lớn", v.v.
Lời nhắc trích xuất sự mơ hồ: "Chúng tôi sẽ chuyển yêu cầu kinh doanh sau đây thành yêu cầu phần mềm. Chưa đề xuất giải pháp. Trước tiên, hãy trích xuất TẤT CẢ những điểm mơ hồ và giả định ẩn chưa được trả lời trong yêu cầu này dưới dạng danh sách các câu hỏi. Nhóm các câu hỏi theo các tiêu đề sau: phạm vi, người dùng/quyền, khối lượng dữ liệu, hiệu suất, điều kiện lỗi, bảo mật. Yêu cầu: 'Cho phép người dùng tải xuống lịch sử đơn hàng dưới dạng báo cáo.'"
Lời nhắc về câu chuyện của người dùng + tiêu chí chấp nhận: "Chia nhu cầu đã được làm rõ sau đây thành các câu chuyện của người dùng tuân thủ nguyên tắc ĐẦU TƯ. Viết 3-5 tiêu chí chấp nhận có thể kiểm chứng cho mỗi câu chuyện (ở định dạng Cho trước khi nào). Thêm ít nhất 2 tình huống tiêu cực (truy cập trái phép, dữ liệu trống). Cần: [viết nhu cầu được làm rõ ở đây]"
So sánh các quyết định thiết kế với AI
Thiết kế là một sự đánh đổi liên tục: tốc độ so với tính linh hoạt, đơn giản so với khả năng mở rộng? AI đưa những sự đánh đổi này vào một bảng tính nhanh chóng. Ví dụ: đối với tính năng "gửi thông báo", bạn có thể tranh luận xem nên sử dụng phương pháp đồng bộ (gửi theo yêu cầu) hay không đồng bộ (xếp hàng, gửi trong nền).
Lời nhắc so sánh thiết kế: "Tôi đang thiết kế tính năng 'gửi thông báo email tới người dùng'. So sánh hai cách tiếp cận: (A) phân phối đồng bộ trong yêu cầu HTTP, (B) phân phối không đồng bộ ở chế độ nền bằng cách đặt nó vào hàng đợi tin nhắn. Tạo một bảng trên các trục sau: thời gian chờ đợi của người dùng, khả năng chịu lỗi, độ phức tạp, chi phí cơ sở hạ tầng, khó gỡ lỗi. Tóm tắt trong 2 câu mà cuối cùng tôi sẽ chọn. Đừng đưa ra quyết định thay tôi."
trục
truyền đồng bộ
Không đồng bộ (hàng đợi)
Thời gian chờ đợi của người dùng
Dài (chờ giao hàng)
Ngắn (trả về ngay)
Khả năng chịu lỗi
Thấp (yêu cầu bùng nổ nếu gửi bùng nổ)
Cao (có thể thử lại)
sự phức tạp
thấp
Trung bình-cao (cơ sở hạ tầng hàng đợi)
Chi phí cơ sở hạ tầng
thấp
Các thành phần bổ sung cần thiết
Nó phù hợp ở đâu
Khối lượng thấp, ứng dụng đơn giản
Khối lượng lớn, giao hàng quan trọng
Mẹo: Việc yêu cầu AI “đừng đưa ra quyết định thay tôi, chỉ cho tôi xem các lựa chọn và điều kiện” buộc bạn phải suy nghĩ và giảm nguy cơ chấp nhận một đề xuất một cách mù quáng. Quyết định thiết kế tốt nhất là quyết định của người hiểu rõ bối cảnh của bạn (chính bạn).
Nhắc yếu / Nhắc mạnh
YẾU: "Thiết kế cơ sở dữ liệu cho hệ thống đặt hàng." (Kết quả: quy mô nào, mối quan hệ nào, ràng buộc nào không rõ ràng; một sơ đồ chung chung, không thực tế.) MẠNH MẼ: "Đề xuất mô hình dữ liệu dự thảo cho một thương mại điện tử nhỏ. Các thực thể: Khách hàng, Đơn hàng, Sản phẩm, Mặt hàng trong đơn hàng. Ràng buộc: có thể có nhiều sản phẩm trong một đơn hàng; giá sản phẩm có thể thay đổi theo thời gian, nhưng giá hiện tại phải được giữ nguyên theo đơn hàng trước đó; dự kiến có ~500 đơn hàng mỗi ngày. Mối quan hệ và lý do" Giải thích rằng bạn đã đưa ra quyết định. Chỉ định cách bạn giải quyết vấn đề lịch sử giá. Cung cấp nó dưới dạng danh sách các thực thể và trường chứ không phải mã."
Sự khác biệt của một lời nhắc mạnh mẽ; quy mô (500 đơn hàng mỗi ngày), quy tắc kinh doanh (phải duy trì giá trước đây) và định dạng đầu ra mong muốn. Một câu như “Phải giữ nguyên giá cũ” đã thay đổi hoàn toàn thiết kế; Nếu bạn không chỉ định điều này, AI sẽ tạo ra một sơ đồ không chính xác nhưng trông có vẻ hợp lý.
Hộp đựng nhỏ
Trường hợp 1 - Giả định ẩn. Một nhóm trực tiếp mã hóa yêu cầu "người dùng có thể tải ảnh hồ sơ lên". Một nhóm khác hỏi AI về sự không chắc chắn: "kích thước tối đa? định dạng được phép? kiểm soát nội dung không phù hợp? xóa ảnh cũ?" Nó tạo ra 8 câu hỏi như thế nào. Nhóm đầu tiên biết được sự cố trong quá trình sản xuất khi tệp 20 MB lấp đầy máy chủ; Đội thứ hai giải quyết nó trong thiết kế.
Trường hợp 2 - Giả định thang đo không chính xác. AI đề xuất lớp bộ nhớ đệm phức tạp cho tính năng báo cáo. Khi kỹ sư chỉ ra rằng dữ liệu thực chỉ có 30 báo cáo mỗi ngày, AI sẽ đơn giản hóa việc đề xuất. Không chỉ định thang đo sẽ gây ra sự phức tạp không cần thiết; chỉ định tiết kiệm 2 tuần làm việc không cần thiết.
Trường hợp 3 - Khoảng cách tiêu chí chấp nhận. "Điều gì xảy ra nếu thanh toán không thành công?" Vì câu hỏi chưa bao giờ được hỏi nên hệ thống đặt hàng vẫn sẽ đánh dấu đơn hàng là "đã xác nhận" trong trường hợp thanh toán không thành công. Danh sách các tình huống tiêu cực do AI tạo ra đã nắm bắt được khoảng trống này; Tiêu chí chấp nhận 1 dòng ngăn ngừa mất tiền thật.
Những lỗi thường gặp
- Chuyển yêu cầu trực tiếp tới mã. Mã được viết trước khi sự mơ hồ được giải quyết sẽ nhanh chóng giải quyết được vấn đề sai.
- Đi theo “phương pháp hay nhất” chung về AI một cách mù quáng. Nếu bạn không chỉ định bối cảnh của mình (quy mô, ngân sách, nhóm) thì đề xuất sẽ không phù hợp với bạn.
- Bỏ qua các yêu cầu phi chức năng. Nếu tốc độ, bảo mật và quy mô không được chỉ định thì thiết kế sẽ không đầy đủ.
- Chỉ nghĩ đến viễn cảnh hạnh phúc thôi. Các tình huống tiêu cực như dữ liệu trống, người dùng trái phép, trạng thái lỗi nên được đưa vào thiết kế.
- Giao quyền quyết định cho AI. AI tạo ra các lựa chọn; Bạn quyết định sự đánh đổi nào phù hợp với doanh nghiệp của bạn.
Tóm lại
Phân tích và thiết kế yêu cầu là giai đoạn mà các lỗi ít xảy ra nhất được phát hiện. Tại đây, AI tạo ra các câu hỏi bộc lộ sự không chắc chắn, phác thảo câu chuyện của người dùng và tiêu chí chấp nhận cũng như sự đánh đổi trong thiết kế biểu đồ. Nhưng chỉ có bạn biết bối cảnh; Công việc của bạn là lọc các đề xuất của AI dựa trên các ràng buộc về quy mô, ngân sách, nhóm và pháp lý của bạn rồi đưa ra quyết định cuối cùng. Kỷ luật “đừng đưa ra quyết định thay tôi, hãy chỉ cho tôi các lựa chọn” dẫn đến thiết kế tốt hơn và học hỏi sâu hơn.
Nhiệm vụ ứng dụng
Chọn một yêu cầu công việc một câu từ ngữ cảnh của bạn. Đầu tiên, áp dụng lời nhắc mơ hồ cho AI và trả lời các câu hỏi với những ràng buộc thực sự của bạn. Sau đó chuyển nhu cầu đã được làm rõ thành ít nhất 2 câu chuyện của người dùng và 3 tiêu chí chấp nhận cho mỗi câu chuyện; Bao gồm ít nhất 1 tình huống tiêu cực. Cuối cùng, tạo bảng so sánh cho quyết định thiết kế (đồng bộ/không đồng bộ, cấu trúc bảng, v.v.) và viết quyết định của riêng bạn trong 2 câu.
danh sách kiểm tra
- [ ] Tôi đã loại bỏ những câu hỏi mơ hồ trước khi chuyển yêu cầu vào mã.
- [ ] Tôi đã đưa ra bối cảnh (quy mô, thẩm quyền, hiệu suất, ràng buộc pháp lý) cho AI.
- [ ] Tôi đã chia câu chuyện của người dùng thành các tiêu chí chấp nhận có thể kiểm chứng được.
- [ ] Tôi đã thêm ít nhất một tình huống bất lợi/có lợi.
- [ ] Tôi đã đánh giá quyết định thiết kế bằng bảng đánh đổi.
- [ ] Tôi đưa ra quyết định cuối cùng dựa trên bối cảnh của mình, tôi không giao việc đó cho AI.