Nhanh nhẹn trong quản lý yêu cầu
Agile chắc chắn đang trở thành một phương pháp luận phát triển được ưa thích vì ngày nay trọng tâm tiếp tục hướng tới việc cung cấp sớm hơn. Trọng tâm của Agile là các cá nhân tương tác và cộng tác với khách hàng để tạo ra phần mềm hoạt động. Agile cũng cung cấp phản ứng nhanh chóng với sự thay đổi và thực sự khuyến khích sự thay đổi. Các phương pháp truyền thống tập trung hơn vào các công cụ và quy trình, cụ thể là xác định và quản lý các yêu cầu. Vấn đề là kết hôn hai người này với nhau theo cách bao hàm những gì tốt đẹp nhất của cả hai thế giới. Quá nhiều phương pháp luận có thể dẫn đến các vấn đề trong một dự án.
Một số người nghĩ rằng Agile có nghĩa là “không có tài liệu” và vô kỷ luật. Không đúng. Agile khuyến khích tài liệu cần thiết cho dự án, nhưng không khuyến khích “tài liệu vì lợi ích của tài liệu”. Agile đòi hỏi rất nhiều kỷ luật. Nó không phải là miễn phí cho tất cả. Bất kỳ phương pháp luận nào cũng có thể trở nên Agile bằng cách tập trung vào thông tin phù hợp, cộng tác trong các nhóm mở rộng cả kinh doanh và CNTT và làm việc lặp đi lặp lại để đạt được kết quả cuối cùng.
Triển khai Agile trong quy trình Quản lý Yêu cầu của bạn
Một số thách thức lớn với Agile tập trung vào con người thay vì phương pháp luận. Các đội không yêu cầu sự giúp đỡ và chỉ nhận ra những kết quả có vấn đề mà thường họ sẽ quay lại với cách làm cũ của mình. Các nhóm không có cách nào có cấu trúc để chia sẻ những gì họ đã học được. Các đội không có cách nào để đo lường sự thành công của phương pháp nhanh nhẹn. Agile có kỷ luật mở rộng sự phát triển Agile cho toàn bộ vòng đời. Nó không chỉ tập trung vào giai đoạn phát triển phần mềm.
Đây là một số những điểm chính cần nhớ nếu bạn đang cân nhắc chuyển sang Agile.
- Biết mức độ phức tạp của dự án của bạn. Xem xét quy mô, thời gian và nỗ lực ước tính, số lượng người tham gia và vị trí của những người đó.
- Nhờ các chuyên gia giúp bạn và đừng ngại nhờ họ giúp đỡ. Nếu quy trình của bạn hiện đang hỗn loạn, việc chuyển sang Agile mà không có một số cấu trúc và kỷ luật sẽ chỉ tạo ra sự hỗn loạn Agile.
- Cảm ơn về các cách tách biệt định nghĩa yêu cầu công việc. Thực hiện các yêu cầu khi cần thiết thay vì cố gắng hoàn thành tất cả chúng trước. Có một số cách để chia nhỏ công việc, các tính năng là một trong số đó.
- Bắt đầu cách tiếp cận Agile ngay từ đầu và sử dụng nó trong suốt vòng đời, từ yêu cầu đến phát triển và thử nghiệm.
- Xem xét các cách để đo lường sự thành công của Agile và luôn duy trì các chỉ số về các biện pháp này.
Agile - Quy trình Scrum với công cụ Quản lý Yêu cầu
Một trong những quy trình nổi tiếng nhất trong thế giới linh hoạt là Cuộc đánh nhau. Về lý thuyết, Scrum không cần bất kỳ công cụ phần mềm nào để quản lý “sử thi”, “câu chuyện của người dùng”, “sản phẩm tồn đọng” hoặc “nước rút”. Nói một cách đơn giản, bạn chỉ cần một tấm bảng trắng và nhiều mẩu giấy®. Nhưng điều gì sẽ xảy ra nếu nhóm Scrum của bạn bị phân tán? Hoặc nếu bạn muốn hưởng lợi từ công việc đã làm trong quá khứ? Sau đó, sẽ hữu ích nếu dữ liệu được lưu trữ ở đâu đó…
Tại sao không sử dụng một giải pháp quản lý yêu cầu linh hoạt có khả năng thực thi bất kỳ loại quy trình nào. Hãy lấy quy trình sau đây làm ví dụ cho việc triển khai quy trình Scrum:
Chủ sở hữu sản phẩm sẽ mô tả “sử thi” và “câu chuyện của người dùng” bắt nguồn từ chúng (truy xuất nguồn gốc!) Trong đó “câu chuyện của người dùng” sẽ tự động được đưa vào “product backlog” nhận một số thuộc tính cụ thể của product backlog (ví dụ: ngày giao hàng, mức độ ưu tiên, nhóm được chỉ định ). Mỗi nhóm Scrum có thể dễ dàng tìm thấy “câu chuyện của người dùng” được chỉ định cho nhóm của họ và quyết định câu chuyện nào họ muốn cung cấp trong sprint tiếp theo. Ngay sau khi câu chuyện được chỉ định cho một sprint chuyên dụng (nhưng không phải trước đó), nhóm scrum được phép lấy các “nhiệm vụ” riêng lẻ được giao cho các thành viên nhất định trong nhóm. Mỗi “nhiệm vụ” cũng sẽ có một trạng thái (đang làm à đang thực hiện).
Sử dụng giải pháp quản lý yêu cầu chuyên nghiệp sẽ cho phép:
- Chủ sở hữu sản phẩm để xem “câu chuyện của người dùng” nào được / được triển khai trong sprint:
- Product Owner để xem trạng thái hiện tại của các nhiệm vụ bắt nguồn từ “câu chuyện của người dùng” cho một sprint cụ thể:
- Thành viên nhóm Scrum tập trung vào các nhiệm vụ của mình:
Các giải pháp quản lý yêu cầu chuyên nghiệp cho phép xác định các quan điểm dựa trên vai trò trên dữ liệu giúp cải thiện hiệu quả rất nhiều.
Hơn nữa, việc tạo ra các báo cáo khác nhau (ví dụ như biểu đồ burndown) từ dữ liệu thực tế chỉ là một cú nhấp chuột - nếu không được thực hiện ở chế độ hàng loạt. Các báo cáo đó có thể ở định dạng HTML để đưa chúng vào mạng nội bộ.
