Ý tưởng của nhà sáng lập thường xuất hiện dưới dạng một tập hợp màn hình: bảng điều khiển, giao diện điện thoại, bảng thông báo và trợ lý. Chúng có thể hữu ích về sau nhưng chưa định nghĩa sản phẩm hoạt động. Sản phẩm bắt đầu khi một người cụ thể hoàn thành được việc có ý nghĩa và nhóm giải thích được tại sao việc ấy quan trọng. AI có thể giúp triển khai khi con đường đã rõ.
Chương 1 xác lập ranh giới kỹ thuật với AI. Chương này áp dụng chúng vào lát cắt hoạt động đầu tiên. Với công cụ quản lý yêu cầu bảo trì giả định, ta sẽ đi từ ý tưởng mơ hồ đến bản phát hành nhỏ có thể trình diễn, kiểm thử và sửa đổi. Mục tiêu là quy trình nhất quán với giới hạn đã biết.
Chuyển ý tưởng thành kết quả quan sát được
Bắt đầu từ sự kiện cụ thể: điều phối viên nhận yêu cầu bảo trì và cần giao người chịu trách nhiệm. Kết quả mong muốn là yêu cầu có chủ sở hữu và trạng thái nhìn thấy được. “Xây bảng điều khiển vận hành thông minh” không cho nhóm biết kết quả ấy đã đạt hay chưa.
Viết một câu cho từng bước quan trọng: nhập yêu cầu, giao kỹ thuật viên và thấy xác nhận đã lưu. Sau đó mô tả thất bại quan trọng nhất: không được hiển thị đã lưu khi thao tác ghi thất bại. Những câu này mở đầu danh sách điều kiện chấp nhận.
Yêu cầu tác nhân tìm quyết định còn thiếu trước khi viết mã. Nó có thể hỏi kỹ thuật viên có phải thuộc cùng tổ chức không, hoặc yêu cầu có được sửa sau phân công không. Trả lời phần ảnh hưởng lát cắt đầu và ghi rõ phần hoãn lại.
Chọn lát cắt đi qua các ranh giới thực
Lát cắt dọc có đủ giao diện, xử lý máy chủ và lưu trữ để hoàn thành một việc. Với công cụ này, đó có thể là tạo và xem yêu cầu đã phân công. Một tập màn hình mẫu rời rạc dễ tạo hơn nhưng không chứng minh phân quyền, kiểm tra dữ liệu và lưu trữ phối hợp đúng.
Giữ phạm vi hẹp. Nhận email, tự động xếp lịch, phân tích và hoạt động ngoại tuyến có thể chờ nếu không thiết yếu cho phép thử đầu. Một biểu mẫu nhập thủ công có thể đủ để biết hàng đợi chung có hữu ích không. Ghi lại khả năng bị loại để không ai nhầm bản đầu là hệ thống hoàn chỉnh.
Kinh doanh và kỹ thuật cần thống nhất đánh đổi. Nhà sáng lập có thể chấp nhận nhập thủ công trong thử nghiệm. Họ không nên phải chấp nhận mất dữ liệu âm thầm hoặc người khác xem yêu cầu của tổ chức mình chỉ vì sản phẩm còn sớm.
Tạo gói giao việc để tác nhân kiểm tra
Mô tả hành vi và ràng buộc
Nêu người dùng, quy trình, điều kiện thành công, lỗi quan trọng và quy ước hiện có. Chỉ rõ phần cần dùng lại. Nếu đã có lớp dữ liệu và mẫu kiểm tra hợp lệ, yêu cầu xem chúng trước khi thêm cách làm khác.
Yêu cầu kế hoạch triển khai nhỏ
Kế hoạch cần gọi tên mô-đun và kiểm tra liên quan, không dự đoán từng dòng mã. Xem xét hạ tầng thừa và giả định ẩn. Nếu sửa một biểu mẫu bỗng cần hàng đợi, dịch vụ và nhà cung cấp danh tính mới, hãy tìm hiểu lý do trước khi chấp nhận mở rộng.
Giữ quyết định cùng nhiệm vụ
Lưu câu trả lời trong kho mã hoặc hồ sơ công việc thay vì chỉ dựa vào cuộc chat dài. Công việc sau này cần tìm lại được vì sao chỉ phân công trong cùng tổ chức và vì sao hoãn email. Ngữ cảnh này tránh để người hoặc tác nhân tiếp theo vô tình đảo ngược quyết định có chủ đích.
Định nghĩa giao ước dữ liệu trước khi làm đẹp giao diện
Bản ghi đầu có thể cần mã định danh, mã tổ chức, tóm tắt, mã người phụ trách, trạng thái và giờ tạo. Quyết định giá trị nào do máy chủ cấp, giá trị nào từ người dùng. Mã định danh và tư cách thành viên phải được xác minh phía máy chủ, không tin trường ẩn của biểu mẫu.
Định nghĩa phản hồi thành công và lỗi dự kiến. Lỗi kiểm tra cần cho phép điều phối viên sửa biểu mẫu mà không mất phần nhập. Lỗi lưu trữ phải thể hiện rõ yêu cầu chưa được lưu. Đây là hành vi sản phẩm, không phải việc dọn dẹp tùy chọn.
Dùng bản ghi giả kiểm tra giao ước: người phụ trách không tồn tại, tóm tắt quá dài và thiếu giá trị bắt buộc. Yêu cầu tác nhân giải thích mỗi tình huống đến ranh giới kiểm tra như thế nào và người dùng nhận được gì.
Triển khai từng bước để dễ rà soát
Một thứ tự thực dụng là truy cập dữ liệu, hành vi máy chủ, nối giao diện rồi kiểm chứng trọn luồng. Thứ tự có thể đổi theo ứng dụng nhưng mỗi bước nên để lại bằng chứng. Tránh gộp tái cấu trúc rộng vào tính năng đầu trừ khi thiếu nó thì không thể triển khai an toàn.
Sau thay đổi có giới hạn, xem phần khác biệt. Tìm kiểm tra trùng lặp, thư viện mới, tuyến xử lý cũ bị đổi nhầm và cấu hình chứa giá trị nhạy cảm. Yêu cầu giải thích sửa đổi bất ngờ bằng yêu cầu mà nó phục vụ.
Khi kiểm thử thất bại, giữ thông tin lỗi trước khi sửa. Kiểm thử không khởi động do dịch vụ vắng mặt khác với kiểm thử đã chạy tới tính năng rồi thấy hành vi sai. Chẩn đoán đúng giúp tránh sửa nhầm lớp.
Trình diễn gần với công việc thực
Buổi trình diễn hữu ích bắt đầu từ yêu cầu mới và kết thúc khi người có quyền khác tìm thấy việc được giao. Nên có ít nhất một lần sửa hoặc thất bại: đổi người phụ trách không hợp lệ hoặc thử lại sau lỗi lưu giả lập. Những luồng này phơi bày lỗi sử dụng và quản lý trạng thái mà ảnh chụp thành công che khuất.
Dùng môi trường thử riêng và giải thích giới hạn. Thông báo giả lập phải có nhãn giả lập; dữ liệu tạm phải nói rõ. Người tham gia cần biết phần nào sẵn sàng dùng thực tế, phần nào chỉ để khám phá quy trình.
Ghi quan sát bằng ngôn ngữ thường: “Điều phối viên không biết bấm Lưu hai lần có tạo hai yêu cầu không.” Đó là nhiệm vụ tiếp theo rõ hơn “cải thiện trải nghiệm” vì kỹ sư có thể xác định hành vi cần đổi.
Giữ ghi chú phát hành và đường quay lại
Trước bản phát hành nhỏ, ghi phần đã có, phần còn thủ công và điều nhóm sẽ theo dõi. Nêu nơi giữ phiên bản trước có thể triển khai và thay đổi dữ liệu ảnh hưởng khôi phục. Quay lại mã cũ không tự đảo ngược di chuyển dữ liệu.
Ghi chú có thể nêu: điều phối viên tạo yêu cầu, giao kỹ thuật viên cùng tổ chức và xem yêu cầu đã lưu. Nhập email và nhắc việc tự động nằm ngoài phạm vi. Cần có người nhận câu hỏi hỗ trợ, dù đó cũng là lập trình viên.
Thỏa thuận làm việc ở Chương 1 vẫn áp dụng: người duyệt phát hành phải hiểu hành vi triển khai. Thông báo hoàn tất của tác nhân là ngữ cảnh hữu ích; bằng chứng phát hành đến từ mã, kiểm tra và trình diễn.
Chọn việc tiếp theo từ kết quả
Sau trình diễn, phân phản hồi thành điều kiện chấp nhận chưa đạt, yêu cầu mới hoặc quan sát cần tìm hiểu. Sửa phần thất bại trước khi tuyên bố hoàn tất. Tìm hiểu sự nhầm lẫn lặp lại trước khi thêm tính năng không liên quan. Không xem mọi đề xuất là cam kết cho bản tiếp.
Nếu người dùng không tìm được việc được giao, hãy sửa luồng đó trước khi thêm tóm tắt AI. Nếu hàng đợi chung không ai dùng vì yêu cầu vẫn đến từ kênh không truy cập được, xem lại giả định quy trình. Kết quả có thể đòi hỏi tìm hiểu thêm thay vì viết thêm mã.
Kết luận: biến mơ hồ thành con đường nhỏ, đáng tin
Sản phẩm hoạt động đầu tiên là con đường được chọn cẩn thận xuyên qua một việc thực. Định nghĩa kết quả, nối ranh giới cần thiết, thử lỗi có ý nghĩa và giữ quyết định giải thích kết quả. AI tăng tốc được từng bước khi phạm vi vẫn đủ rõ để con người rà soát.
Bài tập tiếp theo là viết lát cắt đầu thành danh sách chấp nhận ngắn và đi qua cùng người dùng tiềm năng. Chương 3 xem cách tổ chức hệ thống để thay đổi về sau vẫn kiểm soát được khi lát cắt lớn lên.
