Tóm tắt
Cuốn sách là một thuật toán tường thuật để thực hiện quá trình phát triển từ ý tưởng đến triển khai bằng các kỹ thuật linh hoạt. Quy trình được trình bày theo các bước và ở mỗi bước, các phương pháp cho bước quy trình được chỉ ra. Tác giả chỉ ra rằng hầu hết các phương pháp đều không phải là nguyên bản, không tự nhận là nguyên bản. Nhưng phong cách viết hay và tính toàn vẹn của quy trình khiến cuốn sách trở nên rất hữu ích.
Một kỹ thuật quan trọng của việc lập bản đồ câu chuyện của người dùng là cấu trúc các ý tưởng và cách trình bày khi người dùng di chuyển trong suốt quá trình.
Đồng thời, quá trình này có thể được mô tả theo nhiều cách khác nhau. Bạn có thể xây dựng các bước khi đạt được giá trị chính hoặc bạn có thể chỉ cần lấy và tưởng tượng ngày làm việc của người dùng trong quá trình sử dụng hệ thống. Tác giả tập trung vào thực tế là các quy trình cần phải được phác thảo, diễn đạt dưới dạng câu chuyện của người dùng trên bản đồ quy trình, chính điều này đã đặt cho chúng ta cái tên bản đồ câu chuyện của người dùng.
Ai cần nó
Dành cho các nhà phân tích CNTT và quản lý dự án. Phải đọc. Dễ dàng và thú vị để đọc, cuốn sách có kích thước trung bình.
hồi tưởng
Ở dạng đơn giản nhất, đây là cách nó hoạt động.
Một vị khách đến quán cà phê, chọn món, gọi món, nhận đồ ăn, ăn và thanh toán.
Chúng tôi có thể viết các yêu cầu cho những gì chúng tôi muốn từ hệ thống ở từng giai đoạn.
Hệ thống sẽ hiển thị danh sách các món ăn, mỗi món ăn có thành phần, trọng lượng, giá cả và có thể thêm vào giỏ hàng. Tại sao chúng tôi tự tin vào những yêu cầu này? Điều này không được mô tả trong phần mô tả yêu cầu “tiêu chuẩn” và điều này tạo ra rủi ro.
Những người biểu diễn không hiểu tại sao điều này lại cần thiết thường làm sai. Người thực hiện không tham gia vào quá trình tạo ra ý tưởng sẽ không tham gia vào kết quả. Agile nói, chúng ta hãy tập trung chủ yếu không phải vào hệ thống mà vào con người, người tiêu dùng, nhiệm vụ và mục tiêu của họ.
Chúng tôi tạo ra các cá tính, cung cấp cho họ thông tin chi tiết để tạo sự đồng cảm và bắt đầu kể những câu chuyện từ phía cá tính đó.
Nhân viên văn phòng Zakhar đi ăn trưa và muốn ăn nhanh. Anh ấy cần gì? Ý tưởng là có lẽ anh ấy muốn một bữa trưa bàn công việc. Một ý tưởng khác là anh ấy muốn hệ thống ghi nhớ sở thích của mình vì anh ấy đang ăn kiêng. Một ý tưởng khác. Anh ấy muốn cà phê được mang đến ngay vì anh ấy quen uống cà phê trước bữa trưa.
Và còn có doanh nghiệp (nhân vật tổ chức là nhân vật đại diện cho lợi ích của một tổ chức). Các doanh nghiệp muốn tăng mức kiểm tra trung bình, tăng tần suất mua hàng và tăng lợi nhuận. Ý tưởng là - hãy cung cấp những món ăn khác thường của một số nền ẩm thực. Một ý tưởng khác - hãy giới thiệu bữa sáng.
Các ý tưởng có thể và nên được cụ thể hóa, chuyển đổi và trình bày dưới dạng câu chuyện của người dùng. Với tư cách là nhân viên của Trung tâm Thương mại Zakhar, tôi muốn hệ thống nhận ra tôi để tôi có thể nhận thực đơn dựa trên sở thích của mình. Với tư cách là người phục vụ, tôi muốn hệ thống thông báo cho tôi khi đến bàn để khách hàng hài lòng với dịch vụ nhanh chóng. Và như thế.
Hàng chục câu chuyện. Tiếp theo là ưu tiên và tồn đọng? Jeff chỉ ra những vấn đề nảy sinh: sa lầy vào những chi tiết nhỏ và mất đi sự hiểu biết về khái niệm, cộng với việc ưu tiên chức năng sẽ tạo ra một bức tranh rời rạc do không nhất quán với mục tiêu.
Con đường của tác giả: Chúng tôi không ưu tiên chức năng mà ưu tiên kết quả = những gì người dùng nhận được cuối cùng.
Một điểm hiển nhiên không thể thấy rõ: phiên xác định mức độ ưu tiên không phải do cả nhóm thực hiện vì nó không hiệu quả mà do ba người thực hiện. Người đầu tiên chịu trách nhiệm kinh doanh, người thứ hai chịu trách nhiệm về trải nghiệm người dùng và người thứ ba chịu trách nhiệm triển khai.
Chúng ta hãy chọn mức tối thiểu để giải quyết một vấn đề của người dùng (giải pháp khả thi tối thiểu).
Chúng tôi trình bày chi tiết các ý tưởng ưu tiên hàng đầu bằng cách sử dụng câu chuyện của người dùng, bản phác thảo thiết kế, các ràng buộc và quy tắc kinh doanh trên bản đồ câu chuyện của người dùng bằng cách kể và thảo luận với nhóm những gì mọi người và các bên liên quan cần ở mỗi bước của quy trình. Chúng tôi để lại những ý tưởng còn lại chưa được xem xét trong các cơ hội tồn đọng.
Quy trình được viết trên thẻ từ trái sang phải, với các ý tưởng trên thẻ bên dưới các bước của quy trình. Điều bắt buộc là con đường xuyên suốt toàn bộ câu chuyện phải được thảo luận cùng với các thành viên trong nhóm để đảm bảo sự hiểu biết lẫn nhau.
Việc xây dựng theo cách này tạo ra tính toàn vẹn trong việc tuân thủ các quy trình.
Những ý tưởng nhận được cần phải được thử nghiệm. Một thành viên không thuộc nhóm đội chiếc mũ của người đó và sống trong đầu người đó một ngày, giải quyết vấn đề của người đó. Có thể anh ta không nhìn thấy diễn biến, tạo ra các thẻ lần nữa và nhóm đã tìm ra giải pháp thay thế cho chính mình.
Sau đó là chi tiết để đánh giá. Ba người là đủ cho việc này. Chịu trách nhiệm về trải nghiệm người dùng, nhà phát triển, người thử nghiệm với câu hỏi yêu thích: “Điều gì sẽ xảy ra nếu…”.
Ở mỗi giai đoạn, cuộc thảo luận tuân theo một bản đồ quy trình về lịch sử của người dùng, cho phép ghi nhớ nhiệm vụ của người dùng để tạo ra sự hiểu biết mạch lạc.
Theo tác giả, tài liệu có cần thiết không? Vâng tôi cần nó. Nhưng như những ghi chú cho phép bạn nhớ những gì bạn đã đồng ý. Việc lôi kéo người ngoài vào một lần nữa đòi hỏi phải thảo luận.
Tác giả không đi sâu vào chủ đề tính đầy đủ của tài liệu mà tập trung vào nhu cầu thảo luận. (Có, tài liệu là cần thiết, cho dù những người không hiểu biết sâu sắc về Agile có khẳng định điều đó như thế nào). Ngoài ra, việc chỉ xây dựng một phần khả năng có thể dẫn đến nhu cầu làm lại toàn bộ hệ thống. Tác giả chỉ ra nguy cơ xây dựng quá mức trong trường hợp ý tưởng sai.
Để loại bỏ rủi ro, cần nhanh chóng tiếp nhận những phản hồi về sản phẩm được tạo ra để giảm thiểu thiệt hại do tạo ra sản phẩm “nhầm”. Chúng tôi đã phác thảo ý tưởng - xác thực nó với người dùng, phác thảo các nguyên mẫu giao diện - xác thực nó với người dùng, v.v. (Riêng biệt, có một ít thông tin về cách xác thực nguyên mẫu chương trình). Mục tiêu của việc tạo ra phần mềm, đặc biệt là ở giai đoạn đầu, là học hỏi thông qua việc nhận phản hồi nhanh chóng, theo đó, sản phẩm đầu tiên được tạo ra là những bản phác thảo có khả năng chứng minh hoặc bác bỏ một giả thuyết. (Tác giả dựa vào tác phẩm của Eric Ries “Khởi nghiệp sử dụng phương pháp Lean”).
Bản đồ câu chuyện giúp cải thiện khả năng giao tiếp khi việc triển khai được thực hiện trên nhiều nhóm. Những gì nên có trên bản đồ? Những gì bạn cần để tiếp tục cuộc trò chuyện. Không chỉ là câu chuyện của người dùng (ai, cái gì, tại sao), mà còn là ý tưởng, sự kiện, bản phác thảo giao diện, v.v...
Bằng cách chia các thẻ trên bản đồ lịch sử thành nhiều đường ngang, bạn có thể chia tác phẩm thành các bản phát hành - đánh dấu mức tối thiểu, một lớp chức năng tăng dần và cung tên.
Chúng tôi kể những câu chuyện trên bản đồ quy trình.
Một nhân viên đến ăn trưa.
Anh ấy muốn gì? Tốc độ dịch vụ. Vì vậy, bữa trưa của anh ấy đã đợi sẵn trên bàn hoặc ít nhất là trên khay. Rất tiếc - đã bỏ lỡ một bước: nhân viên muốn ăn. Anh đăng nhập và chọn tùy chọn bữa trưa bàn công việc. Anh thấy hàm lượng calo và hàm lượng dinh dưỡng giúp anh ăn kiêng và không tăng cân. Anh xem ảnh món ăn để quyết định có ăn ở chỗ đó hay không.
Tiếp theo, anh ấy sẽ đi ăn trưa và ăn tối chứ? Hoặc có thể bữa trưa sẽ được chuyển đến văn phòng của anh ấy? Sau đó, bước của quy trình là chọn địa điểm ăn uống. Anh ấy muốn biết khi nào nó sẽ được giao cho anh ấy và chi phí là bao nhiêu, để anh ấy có thể chọn nơi dành thời gian và sức lực của mình - đi xuống cầu thang hoặc đi làm. Anh ấy muốn xem quán cà phê đông đúc như thế nào để không phải chen lấn khi xếp hàng.
Sau đó nhân viên đến quán cà phê. Anh ấy muốn xem khay của mình để có thể cầm lấy và đi thẳng vào bữa tối. Quán cà phê muốn nhận tiền để kiếm tiền phục vụ. Nhân viên muốn mất ít thời gian nhất cho việc giải quyết với quán cà phê, để không lãng phí thời gian quý báu một cách vô ích. Làm thế nào để làm nó? Thanh toán trước hoặc ngược lại sau khi sử dụng dịch vụ từ xa. Hoặc thanh toán tại chỗ bằng ki-ốt. Điều quan trọng nhất về điều này là gì? Có bao nhiêu người sẵn sàng trả tiền ăn trưa bằng thẻ ngân hàng? Có bao nhiêu người tin tưởng căng tin này lưu trữ số thẻ của họ để thanh toán nhiều lần? Không có nghiên cứu thực địa thì không rõ ràng, cần phải thử nghiệm.
Ở mỗi bước của quy trình, bạn cần cung cấp chức năng bằng cách nào đó; để làm được điều này, bạn cần lấy một người nào đó làm cơ sở và chọn điều gì quan trọng hơn đối với anh ta (ba bộ chọn giống nhau). Theo dõi câu chuyện đến cùng = đưa ra giải pháp khả thi.
Tiếp theo là chi tiết. Khách hàng muốn xem quán cà phê đông đúc như thế nào để không phải chen lấn khi xếp hàng. Chính xác thì anh ấy muốn gì?
Xem dự đoán có bao nhiêu người sẽ có trong 15 phút nữa khi anh ấy đến đó
Xem thời gian phục vụ trung bình trong quán cà phê và hoạt động của nó trước nửa giờ
Xem tình hình và động lực sử dụng bàn
Điều gì sẽ xảy ra nếu hệ thống dự báo đưa ra kết quả không rõ ràng hoặc ngừng hoạt động?
Xem qua video hàng đợi trong quán cà phê cũng như số lượng bàn trống. Hmm, tại sao không làm điều đó trước nhỉ?!
Tác giả chỉ ra một bài tập nhỏ để luyện tập: hãy thử tưởng tượng xem bạn làm gì vào buổi sáng sau khi thức dậy. Một thẻ = một hành động. Phóng to các thẻ (thay vì xay cà phê, hãy uống một thức uống tiếp thêm sinh lực) để loại bỏ các chi tiết riêng lẻ, không tập trung vào phương pháp thực hiện mà vào mục tiêu.
Cuốn sách này dành cho ai: Các nhà phân tích CNTT và quản lý dự án. Phải đọc.
ứng dụng
Thảo luận và ra quyết định có hiệu quả trong nhóm từ 3 đến 5 người.
Viết trên thẻ đầu tiên những gì cần phát triển, trên thẻ thứ hai - sửa những gì bạn đã làm ở thẻ đầu tiên, trên thẻ thứ ba - sửa những gì đã làm trong thẻ thứ nhất và thứ hai.
Chuẩn bị những câu chuyện giống như những chiếc bánh - không phải bằng cách viết ra công thức mà bằng cách tìm hiểu xem chiếc bánh dành cho ai, cho dịp nào và bao nhiêu người. Nếu chia nhỏ doanh số bán ra thì không phải sản xuất bánh ngọt, kem,… mà là sản xuất bánh nhỏ làm sẵn.
Phát triển phần mềm cũng tương tự như làm một bộ phim, khi bạn cần phát triển và trau chuốt kịch bản một cách cẩn thận, sắp xếp bối cảnh, diễn viên, v.v. trước khi bắt đầu quay.
Sẽ luôn có sự thiếu hụt nguồn lực.
20% nỗ lực tạo ra kết quả rõ ràng, 60% cho kết quả không thể hiểu được, 20% nỗ lực là có hại - đó là lý do tại sao điều quan trọng là phải tập trung vào việc học và không tuyệt vọng trong trường hợp kết quả tiêu cực.
Giao tiếp trực tiếp với người dùng, cảm nhận chính mình trong hoàn cảnh của họ. Tập trung vào một số vấn đề.
Chi tiết và phát triển câu chuyện để đánh giá là phần buồn tẻ nhất của scrum, hãy để các cuộc thảo luận diễn ra ở chế độ bể cá (3-4 người thảo luận tại bảng, nếu ai muốn tham gia thì thay thế người khác).
Nguồn: www.habr.com