Làm thế nào để quản lý yêu cầu làm việc trong dài hạn với các dự án Agile?

Quản lý yêu cầu trong ngắn hạn cho các dự án Agile có vẻ như là một vấn đề được giải quyết với tôi.

Từ góc Scrum, các yêu cầu mới hoặc thay đổi đối với các yêu cầu hiện có được phân phối thông qua Câu chuyện của người dùng. Và Câu chuyện người dùng được nhóm theo Sử thi hoặc Tính năng tạo điều kiện cho việc cung cấp các yêu cầu phức tạp hơn lớn hơn.

Tất nhiên, Câu chuyện người dùng về mặt kỹ thuật không phải là tài liệu yêu cầu. Đây là một nhóm công việc có thể quản lý được, ánh xạ tới thứ thường được gọi là Slice dọc của chức năng. Và phạm vi của những câu chuyện này có thể được xác định rõ ràng thông qua việc sử dụng Tiêu chí chấp nhận (AC).

Vì vậy, mặc dù Câu chuyện của người dùng không phải là yêu cầu chính thức, việc duyệt qua chúng có thể cho bạn ý tưởng khá rõ ràng về các yêu cầu cơ bản của họ. Trong thời gian ngắn.

Tôi nói trong ngắn hạn bởi vì, khi một dự án tiến triển, số lượng Câu chuyện của người dùng tăng lên. Do đó, việc duyệt qua danh sách Câu chuyện ngày càng tăng để tìm Yêu cầu trở nên ngày càng kém hiệu quả theo thời gian.

Vấn đề này được giải quyết khi bạn xem xét các Câu chuyện của Người dùng mở rộng, thay thế hoặc thậm chí phủ nhận các Câu chuyện trước đó.

Bây giờ, hãy tưởng tượng khoảng cách 2 năm giữa các lần lặp phát triển trong một dự án (ổn định trong sản xuất). Đội ban đầu đã biến mất và tất cả kiến ​​thức của họ cũng vậy.

Nếu nhóm ban đầu biết điều này sẽ xảy ra (ví dụ, đó là bản chất của việc kinh doanh), vậy họ có thể thực hiện những biện pháp nào để giúp các đội tiếp theo?

Chắc chắn, tồn đọng sẽ cung cấp một số thông tin, nhưng nó hầu như không ở dạng dễ đọc.

Vì vậy, những gì có thể được thực hiện để giúp các nhóm tiếp theo hiểu trạng thái của dự án, bao gồm tại sao và làm thế nào nó đạt được điều đó?

Theo kinh nghiệm của tôi, những điều sau đây không hoạt động:

• Backlog chải chuốt để xóa hoặc cập nhật Câu chuyện người dùng trước đó để Backlog có thể được đọc như một tài liệu yêu cầu.
• Tài liệu Sprints nơi các thành viên trong nhóm được giao nhiệm vụ ghi lại trạng thái hiện tại của hệ thống.
• Tài liệu thông qua các bài kiểm tra hành vi . Cách tiếp cận này là cách duy nhất tôi đã thấy gần làm việc. Thật không may, các bài kiểm tra Hành vi được mã hóa là nạn nhân của Vấn đề Đặt tên. Mặc dù các bài kiểm tra có thể ghi lại đúng hệ thống, nhưng việc một nhóm các nhà phát triển biến động viết các bài kiểm tra của họ theo cùng một thuật ngữ, từ ngữ và phong cách miền là gần như không thể.

Vì vậy, để nhắc lại:

Làm thế nào để quản lý các yêu cầu dự án Agile trong dài hạn?

Đây dường như là con voi bất thành văn trong phòng với các dự án Agile: làm thế nào để bạn ngăn chúng phát triển thành hỗn loạn?

Chúng ta hãy nhìn vào Tuyên ngôn Agile một lát. Mong muốn nhanh nhẹn:

1. Giao hàng sớm và liên tục
2. Chấp nhận yêu cầu thay đổi
3. Cung cấp phần mềm làm việc thường xuyên
4. Các nhà phát triển và các bên liên quan kinh doanh làm việc cùng nhau hàng ngày
5. Xây dựng các dự án xung quanh các cá nhân có động lực, cung cấp cho họ môi trường và hỗ trợ họ cần, và tin tưởng họ để hoàn thành công việc
6. Đối thoại trực tiếp như là phương thức giao tiếp chính
7. Phần mềm làm việc là thước đo chính của sự tiến bộ
8. Phát triển bền vững
9. Liên tục chú ý đến sự xuất sắc kỹ thuật và thiết kế tốt
10. Đơn giản - Tối đa hóa công việc bạn không phải làm
11. Trong khoảng thời gian đều đặn, nhóm phản ánh về cách trở nên hiệu quả hơn, sau đó điều chỉnh và điều chỉnh hành vi của nó cho phù hợp

Tôi đã nhấn mạnh bốn cái cuối cùng. Tại sao? Bởi vì họ là những người sẽ ngăn dự án sụp đổ dưới sức nặng của chính nó.

Phát triển bền vững có nghĩa là bạn (hy vọng) có ai đó giám sát quá trình phát triển tổng thể, một người có thể điều khiển con tàu vượt ra ngoài phát triển phần mềm một chút, một người có tầm nhìn bao quát về toàn bộ dự án, một người có kiến ​​thức sâu sắc về kiến ​​trúc phần mềm, thiết kế hệ thống, các nguyên tắc logic kinh doanh và công thái học UI. Một kiến ​​trúc sư, nói cách khác.

Kiến trúc sư là người nói rằng "Tôi biết bạn đã yêu cầu điều này, nhưng nếu chúng tôi xây dựng điều này khác, chúng tôi có thể tránh ba tính năng khác gây nhầm lẫn và tập trung vào yêu cầu cốt lõi." Anh ấy là người giúp đội có thời gian giảm nợ kỹ thuật. Anh ấy là người mang lại một cấu trúc và tổ chức bao quát cho dự án. Anh ấy là người gọi các cuộc họp nơi nhóm làm việc với nhau và hỏi "Làm thế nào chúng ta có thể làm mọi thứ tốt hơn?"

Và anh ấy là người duy trì tài liệu yêu cầu tổng thể.

Trong cuốn sách Làm chủ quy trình yêu cầu , các tác giả cho rằng có ba loại khách hàng, ba loại dự án phần mềm: Thỏ, Ngựa và Voi. Thỏ là các dự án phần mềm nhỏ chỉ cần các yêu cầu không chính thức; bạn làm việc trực tiếp với khách hàng trong những lần chạy nước rút nhỏ, phạm vi của dự án bị hạn chế một cách hợp lý và phần mềm được thực hiện trong một khung thời gian tương đối ngắn. Voi là những dự án voi ma mút đòi hỏi nhiều kế hoạch trước, một lượng lớn tài liệu và một chân trời dài. Chúng được cho là không nhanh nhẹn, mặc dù bạn có thể chia chúng thành các dự án nhỏ hơn có thể được xây dựng bằng cách sử dụng nhanh.

Đó là các dự án Ngựa có phần khó hiểu từ góc độ nhanh nhẹn. Chúng vẫn có thể được xây dựng lặp đi lặp lại, bạn vẫn có thể sử dụng nước rút ngắn, nhưng không có một số kỷ luật trong quy trình thu thập và lập kế hoạch yêu cầu, chúng có thể dễ dàng chạy ra khỏi đường ray. Đây là những dự án có thể được hưởng lợi từ quy trình thu thập yêu cầu có kỷ luật, sau đó thích nghi và sửa đổi cẩn thận những yêu cầu đó khi dự án phát triển, trong khi vẫn duy trì tầm nhìn bao quát cho toàn bộ dự án.

Từ quan điểm cá nhân, tôi làm việc với một nhóm nhỏ gồm khoảng một chục nhà phát triển. Tại bất kỳ thời điểm nào, chúng tôi có thể làm việc trên ba dự án phần mềm cùng một lúc, từ bất kỳ nơi nào từ vài nghìn dòng mã đến hơn 100.000. Khách hàng của chúng tôi nghĩ rằng họ là một con thỏ, nhưng họ thực sự là một con ngựa. Khách hàng được tham gia, nhưng không phải trên cơ sở hàng ngày.

Cho đến nay, khu vực yếu nhất của chúng tôi đang thu thập các yêu cầu cụ thể, có thể kiểm chứng, có thể đo lường và quản lý các kỳ vọng của khách hàng liên quan đến phạm vi dự án. Nhưng chúng tôi đang làm việc trên đó.

Câu hỏi không hoàn toàn rõ ràng nhưng có vẻ như bạn quan tâm đến yêu cầu truy xuất nguồn gốc . Một ý tưởng có xu hướng bị mất trong Agile theo kinh nghiệm của tôi là các yêu cầu kinh doanh là những gì khách hàng muốn hệ thống thực hiện, trong khi các câu chuyện của người dùng thực sự là các yêu cầu chức năng nêu rõ cách thức hoạt động của hệ thống. "Là người dùng, tôi muốn có thể X." Nhưng điều đó được thực hiện để đáp ứng một yêu cầu, có thể bị mất trong câu chuyện của người dùng.

Những gì hoạt động tốt trong kinh nghiệm của tôi là liên kết các yêu cầu kinh doanh và câu chuyện của người dùng theo cả hai hướng. BR # 1 có thể được nhận ra bởi các câu chuyện A và B. Câu chuyện C có thể bao gồm BR # 2 và # 3. Đặt cái này trong trình theo dõi dự án, bảng tính của bạn, bất cứ thứ gì bạn đang sử dụng.

Về lâu dài, điều này giúp liên kết những gì khách hàng đang yêu cầu (BRs) với những gì hệ thống làm (câu chuyện) để đạt được những yêu cầu đó. Đây phải là tài liệu khá tối thiểu không gây khó khăn để duy trì, theo tư duy Agile về việc không sản xuất tài liệu mà không ai cần và là một việc vặt để cập nhật.

Nó cũng cung cấp một cách để các thành viên dự án mới tăng tốc vì họ có một cái gì đó để xem xét để có được lịch sử đằng sau lý do tại sao phần mềm làm những gì nó làm.

Tôi thực sự đang làm việc trong một dự án bảo trì kanban của một cửa hàng web lớn nơi các nhà phát triển ban đầu không còn nữa.

mỗi userstory / request / bugfix đều có một số vé và mọi thay đổi mã nguồn được liên kết với một số vé trong trường sourcecontrol-bình luận.

sourcecontrol-checkin-s (svn) cập nhật một cách tự nhiên vé coressponding để trong vé tôi có một liên kết đến tất cả các thay đổi sourceconrtol.

Nếu một modul / chức năng mới được triển khai, cũng có người bán vé trong mã nguồn.

Trong hệ thống vé (redmine), các vé được liên kết với nhau như (trùng lặp, là lỗi, là sàng lọc của, ....)

để bạn có thể theo dõi vé và xem yêu cầu thay đổi theo thời gian.

Ví dụ: tôi phải trò chuyện một cái gì đó trong "orderConf Confirmation-Web-page". Trong mã nguồn của trang tôi thấy một nhận xét: 'được tạo cho "# 4711"' để tôi có thể liên kết vé mới của mình với vé cũ "4711" hoặc một trong những người kế nhiệm của nó.

Cá nhân, tôi loại bỏ các câu chuyện của người dùng như một nguồn tài liệu về những gì hệ thống có thể làm. Trừ khi các bước hoạt động đã được thực hiện để tạo tài liệu (mà chúng tôi đã thực hiện cho một số khách hàng truyền thống hơn của chúng tôi), cơ sở ứng dụng thực sự là tài liệu tốt nhất hiện có.

Mặc dù, điều đó không có gì mới.

Nếu bạn đang sử dụng phiên bản Agile thu nhỏ hơn (như SAFe ), bạn sẽ có các hồ sơ tồn đọng khác không phải là tồn đọng thực hiện. Về cơ bản nó trông như thế này:

1. Danh mục đầu tư tồn đọng (hoạch định chiến lược sử thi và ngân sách)
2. Chương trình / Phát hành tồn đọng (Tính năng và sử thi)
3. Dự án / Nhóm tồn đọng (Câu chuyện, gai, lỗi)

Tôi sẽ không đề xuất tài liệu ở cấp độ Team Backlog. Nó quá chi tiết và hiếm khi có ai muốn đi đến mức độ chi tiết đó. Chưa kể rằng có thể có những câu chuyện trong Bản phát hành mâu thuẫn với những câu chuyện trước đó trong hồ sơ tồn đọng của Đội.

Thay vào đó, tôi khuyên bạn nên làm việc ở cấp Phát hành tồn đọng của bạn để cung cấp tài liệu cấp Phát hành. Những câu chuyện này hiếm khi nổ ra một khi được chỉ định cho một bản phát hành cụ thể, và có thể là một cách ổn định và nhanh chóng để xem xét những gì đang được thực hiện trong một bản phát hành nhất định.