Câu chuyện người dùng

Câu chuyện của người dùng là một cách hiệu quả để nêu các yêu cầu đối với phần mềm đang phát triển. Những câu chuyện như vậy chứa những lời khuyên ngắn gọn thay mặt cho người dùng phần mềm.

Vì trong phương pháp Scrum, việc đặt mục tiêu thường là đặc quyền của khách hàng hoặc chủ sở hữu phần mềm, chúng được coi là cách chính để tác động đến quá trình phát triển. Mỗi Câu chuyện của người dùng có giới hạn về số lượng văn bản và độ phức tạp của cách trình bày. Lịch sử thường được viết trên một tờ giấy nhỏ, bản thân nó đã giới hạn âm lượng.

Nhờ các câu chuyện của người dùng, bạn có thể ghi lại mong muốn của khách hàng và nhanh chóng đáp ứng nhu cầu thị trường.

Câu chuyện của người dùng nên được coi là thước đo yêu cầu đơn giản vì nó không bao gồm quy trình kiểm tra chấp nhận. Việc biên soạn câu chuyện của người dùng phải tuân theo thủ tục nhập học. Điều này sẽ đảm bảo rằng Câu chuyện của người dùng đạt được mục tiêu của nó.

Cấu trúc câu chuyện như sau: “As a user <user type>, I want to done <action> to get <result>” (Là chủ sở hữu sản phẩm, tôi muốn…). Cấu trúc như vậy không chỉ đơn giản mà còn dễ hiểu đối với mọi người.

Lợi ích của việc sử dụng Câu chuyện của người dùng:

  • Những câu chuyện nhỏ và dễ tạo.
  • Giúp tất cả các bên liên quan thảo luận về công việc của dự án và sự hỗ trợ của nó.
  • Không yêu cầu bảo trì liên tục.
  • Chỉ liên quan khi được sử dụng.
  • Cải thiện tương tác với khách hàng.
  • Nhờ họ, bạn có thể chia dự án thành các giai đoạn nhỏ.
  • Tạo điều kiện làm việc trên các dự án với các yêu cầu chưa được hiểu rõ.
  • Đơn giản hóa việc đánh giá nhiệm vụ.

Nhược điểm của User Stories:

  • Nếu không có thỏa thuận trước, các thủ tục có thể gây khó khăn cho việc sử dụng làm cơ sở cho một thỏa thuận.
  • Việc sử dụng chúng yêu cầu liên hệ chặt chẽ với khách hàng trong toàn bộ dự án, điều này đôi khi gây khó khăn cho quy trình làm việc.
  • Họ có bất lợi khi nhân rộng trên các dự án lớn.
  • Liên quan trực tiếp đến mức độ chuyên nghiệp của các nhà phát triển.
  • Được sử dụng để bắt đầu một cuộc thảo luận nhưng có thể không kết thúc cuộc thảo luận và không được sử dụng cho tài liệu hệ thống.

tồn đọng

Product backlog là các nhiệm vụ hiện tại ở dạng danh sách, được tổng hợp theo thứ tự ưu tiên. Danh sách được hình thành trên cơ sở lộ trình (lộ trình) của dự án và các điểm đặt ra trong đó. Các nhiệm vụ quan trọng nhất thường ở đầu danh sách. Điều này là cần thiết để hiểu công việc nào nên được thực hiện trước.

Java university

Nhóm phát triển chọn tốc độ hoàn thành các nhiệm vụ tồn đọng bất kể mong muốn của khách hàng, nhưng dựa trên trình độ và kinh nghiệm của họ từ các lần chạy nước rút trước đây. Việc “điều chỉnh” các lập trình viên là điều cực kỳ không mong muốn. Nhóm tự chọn các nhiệm vụ từ công việc tồn đọng theo những cân nhắc và khả năng của riêng mình. Việc thực thi diễn ra không bị gián đoạn (Kanban) hoặc lặp đi lặp lại (Scrum).

Hai điều kiện tồn đọng quan trọng

Cốt lõi của sản phẩm tồn đọng bao gồm lộ trình, đề xuất và điều kiện thực hiện. Sử thi chứa các điều kiện và Câu chuyện của người dùng. Chúng ta hãy xem xét kỹ một ví dụ điển hình về lộ trình.

Việc tạo trang web “Nhóm trong không gian” là đề xuất đầu tiên trong lộ trình. Nó cần được chia thành các sử thi (trong hình, chúng được hiển thị bằng các màu xanh lá cây, xanh dương và xanh ngọc) và Câu chuyện của người dùng cho mỗi sử thi.

Khách hàng phần mềm tạo thành một danh sách từ một số Câu chuyện của người dùng. Nếu cần, anh ấy có thể thay đổi thứ tự thực hiện các câu chuyện, để các nhà phát triển trước tiên sẽ xử lý một trong những sử thi quan trọng nhất (trái) hoặc kiểm tra cách thức hoạt động của việc đặt vé giảm giá. Để làm điều này, bạn cần triển khai các câu chuyện từ sử thi (phải). Cả hai tùy chọn có thể được nhìn thấy dưới đây.

Khách hàng nên ưu tiên dựa trên những yếu tố nào?

  • Mức độ phù hợp với người dùng.
  • Sự hiện diện của thông tin phản hồi.
  • Sự phức tạp của sự phát triển.
  • Mối quan hệ giữa các nhiệm vụ (để hoàn thành "B", trước tiên bạn cần thực hiện "A").

Các ưu tiên trong công việc được xác định bởi khách hàng, nhưng các bên khác có thể bày tỏ ý kiến ​​​​của họ về điều này. Sự thành công của backlog phụ thuộc, trong số những thứ khác, vào ý kiến ​​của khách hàng và lập trình viên. Cùng nhau, họ có thể đạt được kết quả tốt hơn và đảm bảo giao thành phẩm kịp thời.

Làm thế nào để giữ một công việc tồn đọng

Nếu công việc tồn đọng đã được tạo, thì sau đó bạn cần định kỳ thay đổi nó trong quá trình làm việc tiếp theo. Khách hàng phần mềm nên đảm bảo rằng công việc tồn đọng được biên soạn đúng cách trước mỗi lần lập kế hoạch lặp lại mới. Điều này sẽ giúp làm rõ các ưu tiên hoặc thay đổi điều gì đó sau khi phân tích lần lặp lại cuối cùng. Điều chỉnh công việc tồn đọng trong Agile đôi khi được gọi là “chải chuốt” hoặc “sàng lọc” hoặc “bảo trì công việc tồn đọng”.

Nếu công việc tồn đọng đã tương đối lớn, thì khách hàng cần nhóm các nhiệm vụ theo thời gian thực hiện ngắn hạn và dài hạn. Các nhiệm vụ ngắn hạn nên được xem xét kỹ lưỡng trước khi chúng được đưa ra trạng thái này. Bạn sẽ phải soạn Câu chuyện của người dùng, tìm hiểu tất cả các sắc thái trong nhóm.

Đối với các nhiệm vụ dài hạn, các nhà phát triển rất mong muốn đưa ra đánh giá của họ. Điều này sẽ làm cho nó dễ dàng hơn để ưu tiên. Có thể sẽ có điều gì đó thay đổi, nhưng nhóm sẽ nâng cao hiểu biết về các nhiệm vụ và hoàn thành công việc nhanh hơn.

Công việc tồn đọng là một thành phần quan trọng giữa khách hàng và nhóm lập trình. Khách hàng luôn có thể thay đổi các ưu tiên dựa trên phản hồi, dự báo hoặc yêu cầu mới của khách hàng.

Nên tránh thực hiện các thay đổi trực tiếp trong quá trình vận hành. Điều này có ảnh hưởng xấu đến quy trình làm việc và trạng thái cảm xúc của các lập trình viên.

tăng tốc

Chạy nước rút là một khoảng thời gian ngắn trong đó phải hoàn thành một khối lượng công việc đã thỏa thuận trước đó. Sprint dựa trên các phương pháp Scrum và Agile. Chọn đúng giai đoạn chạy nước rút sẽ giúp một nhóm nhanh nhẹn phát triển phần mềm chất lượng.

“Sử dụng Scrum, bạn có thể phát triển một sản phẩm trong nhiều lần lặp lại với thời lượng rõ ràng - chạy nước rút. Nó giúp chia nhỏ các dự án lớn thành các nhiệm vụ nhỏ hơn,” Megan Cook, Trưởng nhóm Jira tại Atlassian cho biết.

Scrum lập kế hoạch và thực hiện chạy nước rút như thế nào?

Theo các tác giả của phương pháp Scrum, để lập kế hoạch chạy nước rút trong tương lai, mọi người cần gặp nhau tại một cuộc họp riêng. Tại sự kiện này, các thành viên trong nhóm phải tìm câu trả lời cho hai câu hỏi chính: cần làm gì trong Sprint này và làm như thế nào là tốt nhất?

Khách hàng phần mềm, Scrum master và các lập trình viên tham gia vào việc xác định danh sách các nhiệm vụ công việc. Khách hàng giải thích mục tiêu của lần chạy nước rút và các nhiệm vụ từ công việc tồn đọng.

Sau đó, nhóm phát triển một kế hoạch theo đó các nhiệm vụ trong giai đoạn nước rút sẽ được hoàn thành. Kế hoạch này, cùng với các hạng mục công việc đã chọn, được gọi là công việc tồn đọng của nước rút. Sau cuộc họp lập kế hoạch, nhóm bắt đầu làm việc. Các nhà phát triển chọn các nhiệm vụ từ hồ sơ tồn đọng, khi công việc được hoàn thành, trạng thái của từng nhiệm vụ sẽ thay đổi từ “Đang tiến hành” thành “Hoàn thành”.

Trong giai đoạn nước rút, nhóm tổ chức các cuộc họp Scrum hàng ngày (đứng) để thảo luận về các vấn đề hiện tại và tiến độ. Những cuộc họp như vậy là cần thiết để xác định những khó khăn có thể ảnh hưởng đến việc hoàn thành Sprint.

Nếu Sprint hoàn thành, thì nhóm sẽ hiển thị kết quả công việc của họ khi xem xét kết quả (bản demo). Mỗi người tham gia dự án có thể làm quen với kết quả. Việc làm quen nên được thực hiện trước khi mã hoàn thành được hợp nhất vào môi trường sản xuất.

Quá trình hồi tưởng hoàn thành chu trình chạy nước rút. Trên đó, nhóm xác định các khu vực cần được cải thiện trong một lần chạy nước rút trong tương lai.

Cần chú ý những gì và không nên làm gì

Hầu hết các nhóm trẻ lần đầu tiên gặp khó khăn khi đưa chạy nước rút vào quy trình làm việc của họ. Để tránh các vấn đề, chúng tôi khuyên bạn nên xem lại danh sách các hành động cần chú ý ưu tiên.

Chúng ta phải làm gì đây:

  • Kiểm tra xem nhóm có hiểu mục đích của Sprint và nó sẽ thành công như thế nào không. Điều này là cần thiết để mọi người cùng nhau hướng tới một kết quả thành công.
  • Bạn nên có một hồ sơ tồn đọng rõ ràng và dễ hiểu. Nếu công việc tồn đọng không được duy trì đúng cách, điều này có thể trở thành sự cố có thể làm hỏng quy trình làm việc.
  • Đảm bảo rằng ước tính của bạn về tốc độ làm việc là chính xác, có tính đến kỳ nghỉ hè và các yếu tố khác.
  • Tích cực tham gia lập kế hoạch chạy nước rút. Khuyến khích các thành viên trong nhóm mở rộng kế hoạch cho các câu chuyện, lỗi và bài tập.
  • Từ chối các nhiệm vụ trong đó các nhà phát triển sẽ không thể giải quyết các vấn đề phụ thuộc.
  • Sau khi kế hoạch được phê duyệt, hãy chỉ định một nhân viên chịu trách nhiệm nhập dữ liệu vào chương trình quản lý dự án (thẻ Jira, v.v.).

Những gì để tránh:

  • Đừng lạm dụng một số lượng lớn các câu chuyện, hãy tỉnh táo đánh giá tiến độ công việc và không giao những nhiệm vụ khó hoàn thành trong nước rút.
  • Hãy quan tâm đến chất lượng công việc của bạn. Kiểm tra xem bạn có đủ thời gian để kiểm soát chất lượng và sửa lỗi trong mã không.
  • Đảm bảo tất cả các thành viên trong nhóm hiểu rõ nội dung của sprint. Đừng đuổi theo tốc độ. Cả đội phải di chuyển cùng nhau.
  • Đừng tạo gánh nặng cho các nhà phát triển với công việc làm thêm. Sắp chạy nước rút khác.
  • Nếu nhóm bày tỏ lo ngại về khối lượng công việc hoặc thời hạn, bạn nên cân nhắc ý kiến ​​của họ. Xử lý các vấn đề và sửa chữa chúng nếu cần thiết.

bảng scrum

Scrum Board là một công cụ cho biết cách thức thực hiện công việc của Nhóm Scrum. Bạn có thể hiển thị thông tin trên bảng như vậy trên giấy, trên tường hoặc ở dạng điện tử (JIRA, Trello).

Một bảng Scrum có ít nhất ba cột: To Do, In Progress và Done. Đây là một bảng ví dụ:

Bảng Scrum chứa tất cả thông tin từ hồ sơ tồn đọng, đã được phê duyệt trước đó để lập kế hoạch. Theo quy định, thẻ nhiệm vụ kinh doanh được ghim vào bảng theo thứ tự ưu tiên từ trên xuống dưới. Bạn có thể chia chúng thành các loại công việc cụ thể (làm việc về mã, thiết kế, v.v.).

Sau khi hoàn thành một phần công việc, thẻ được chuyển qua bảng sang cột tiếp theo. Để hiển thị khả năng hiển thị tiến độ công việc của nhóm, “công việc còn lại” theo ngày trên Biểu đồ Burndown sẽ giúp ích.

Bạn cũng có thể sử dụng bảng flipchart. Trên đó, tên các tác phẩm được viết trên giấy dán và gắn lên bảng. Ngay sau khi công việc hoàn thành, các nhãn dán được chuyển sang cột khác.

biểu đồ burndown

Biểu đồ burndown hiển thị số lượng công việc đã hoàn thành và số lượng công việc còn lại. Nó được cập nhật hàng ngày và có sẵn cho tất cả các bên quan tâm. Biểu đồ là cần thiết để hiển thị tiến trình trong công việc khi chạy nước rút.

Có hai loại biểu đồ:

  • Biểu đồ Burndown hiển thị tiến độ công việc trong một lần chạy nước rút.
  • Biểu đồ Burndown hiển thị tiến độ công việc cho đến khi phát hành sản phẩm (dữ liệu được tóm tắt từ một số lần chạy nước rút).

Ví dụ về biểu đồ:

Ví dụ này sử dụng tâm lý học: biểu đồ không hiển thị số nhiệm vụ đã hoàn thành, mà là số nhiệm vụ còn lại (chưa hoàn thành).

Nghĩa là, nếu nhóm đã hoàn thành 90 nhiệm vụ trên 100 nhiệm vụ, thì có thể có cảm giác sai lầm rằng mọi thứ đã sẵn sàng. Rốt cuộc, tiến trình từ 90 đến 100 nhiệm vụ không thực sự thay đổi bất cứ điều gì.

Nếu bạn hiển thị số lượng nhiệm vụ còn lại, thì bạn không thể không nhận thấy chúng ngày càng ít đi như thế nào. Điều này trong tiềm thức thúc đẩy những người tham gia dự án đạt được mục tiêu nhanh hơn - không nên có những nhiệm vụ chưa hoàn thành trên bảng.