SWR302 - Phần 14: Yêu cầu trong dự án Agile và dự án nâng cấp, thay thế

Trong phát triển agile, các câu chuyện người dùng (user stories) và các câu chuyện lớn (epics) là hai khái niệm quan trọng. Câu chuyện người dùng là những tuyên bố ngắn gọn và rõ ràng về nhu cầu của người dùng, giúp khởi đầu cho các cuộc thảo luận chi tiết. Các câu chuyện lớn, hoặc epics, là những câu chuyện người dùng quá lớn để được triển khai trong một chu kỳ phát triển (iteration) duy nhất. Vì vậy, chúng thường được chia nhỏ thành nhiều câu chuyện người dùng nhỏ hơn để dễ dàng triển khai.

Trong các dự án Agile, một epic là một khái niệm quan trọng trong quản lý dự án. Nó được định nghĩa là một tập hợp các user story liên quan đến nhau, thường quá lớn để hoàn thành trong một chu kỳ phát triển (iteration) duy nhất. Điều này có nghĩa là epic có thể bao gồm nhiều user story khác nhau, và nó có thể được thực hiện trong nhiều chu kỳ phát triển khác nhau. Epic cũng có thể được coi là một trong những tính năng quan trọng nhất của dự án, vì nó thường liên quan đến các yêu cầu chính của khách hàng.

Trong Agile, Epic là một khái niệm quan trọng giúp định nghĩa mục tiêu và yêu cầu của dự án. Nó đại diện cho một nhu cầu của người dùng hoặc yêu cầu kinh doanh ở mức độ cao, có thể được chia nhỏ thành các câu chuyện người dùng (user stories) nhỏ hơn và dễ quản lý hơn. Ví dụ, một Epic có thể là 'Tăng cường trải nghiệm khách hàng' và được chia nhỏ thành các user stories như 'Tạo trang web mới', 'Tối ưu hóa quá trình thanh toán trực tuyến', v.v. Mục đích của Epic là giúp nhóm phát triển hiểu rõ yêu cầu và mục tiêu của dự án, từ đó có thể lập kế hoạch và triển khai các công việc cần thiết.

Một thách thức phổ biến mà cả các dự án cải tiến và thay thế thường gặp phải là sự phản đối từ người dùng. Người dùng đã quen thuộc với cách hệ thống hoạt động hiện tại có thể không thích những thay đổi mà họ sắp phải đối mặt. Điều này có thể dẫn đến sự kháng cự và khó khăn trong việc chấp nhận những thay đổi mới. Người dùng có thể cảm thấy không thoải mái với những thay đổi này, đặc biệt là nếu họ đã quen thuộc với cách hệ thống hoạt động trước đây. Vì vậy, việc hiểu được nhu cầu và mong muốn của người dùng là rất quan trọng trong việc đảm bảo rằng những thay đổi mới được chấp nhận và sử dụng một cách hiệu quả.

Trên các dự án agile, sự hợp tác chặt chẽ giữa khách hàng và nhà phát triển thường dẫn đến việc yêu cầu có thể được ghi chép chi tiết hơn so với các dự án truyền thống. Điều này là vì agile tập trung vào việc phát triển nhanh chóng và linh hoạt, đồng thời đảm bảo rằng khách hàng và nhà phát triển đều hiểu rõ về yêu cầu và mục tiêu của dự án. Quá trình này cho phép khách hàng và nhà phát triển thảo luận và điều chỉnh yêu cầu một cách thường xuyên, từ đó dẫn đến việc yêu cầu được ghi chép chi tiết hơn và chính xác hơn.

Đáp án đúng: "To provide concise, actionable descriptions of features from the user’s perspective". User story là mô tả ngắn một nhu cầu theo góc nhìn người dùng, thường dạng là một vai trò, tôi muốn làm gì để đạt lợi ích gì, kèm tiêu chí chấp nhận; trong agile chúng là đơn vị yêu cầu được đưa vào backlog, ước lượng, xếp ưu tiên và làm rõ dần qua trao đổi. Phương án "To replace the Vision and Scope document" sai vì tầm nhìn và phạm vi ở tầng yêu cầu nghiệp vụ vẫn cần trong agile để định hướng, story ở tầng người dùng nằm bên dưới. Phương án "To prioritize non-functional requirements" sai vì story chủ yếu diễn đạt nhu cầu chức năng, còn ưu tiên là việc làm trên backlog. Phương án "To finalize the system's architecture" sai vì kiến trúc là quyết định thiết kế, user story không chốt kiến trúc.

Trong phương pháp Agile, Product Backlog thường được biểu diễn dưới dạng các User Story. User Story là một mô tả ngắn gọn về một yêu cầu của khách hàng hoặc người sử dụng. Mỗi User Story thường bao gồm ba phần: người sử dụng (User), hành động (Action) và kết quả mong muốn (Expected Result). Ví dụ, một User Story có thể là: “Là người sử dụng, tôi muốn có thể đăng nhập vào hệ thống để có thể thực hiện các chức năng khác.” Mục đích của User Story là giúp các thành viên trong nhóm hiểu rõ yêu cầu của khách hàng và có thể triển khai các tính năng phù hợp.

Đáp án đúng: "A prioritized list of features, bugs, and tasks to be worked on". Trong dự án agile, product backlog là danh sách động mọi hạng mục công việc còn chờ làm cho sản phẩm (user story, tính năng, lỗi cần sửa, công việc kỹ thuật), được sắp theo độ ưu tiên và liên tục điều chỉnh; mỗi vòng lặp nhóm kéo các hạng mục ưu tiên cao nhất vào làm. Phương án "A detailed list of project risks" sai vì danh sách rủi ro là sổ rủi ro (risk list) trong quản lý dự án, không phải backlog. Phương án "A set of predefined user stories" thiếu ý cốt lõi: backlog không cố định từ trước mà được thêm, bớt, sắp lại liên tục, và ngoài story còn chứa lỗi, công việc kỹ thuật. Phương án "A document outlining system architecture" sai vì tài liệu kiến trúc thuộc thiết kế, không phải danh sách công việc ưu tiên.

Đáp án đúng: "To help determine the best approach to document the backlog and facilitate its prioritization with the product owner and team". Trong môi trường agile, product backlog là danh sách công việc được xếp ưu tiên; product owner là người chịu trách nhiệm cuối cùng về thứ tự ưu tiên, còn người phân tích nghiệp vụ hỗ trợ: chọn cách ghi backlog (user story, tiêu chí chấp nhận, mô hình) và điều phối (facilitate) việc xếp ưu tiên cùng product owner và nhóm. "To eliminate the backlog entirely." sai vì backlog là công cụ trung tâm của agile, không thể bỏ. "To solely manage and prioritize the backlog without customer input" sai vì người phân tích nghiệp vụ không tự quyết một mình, ưu tiên phải dựa vào ý kiến khách hàng và product owner. "To ensure the backlog never changes" sai vì backlog được tinh chỉnh liên tục, đón nhận thay đổi là tinh thần của agile.

Đáp án đúng: "The number of loans that loan processors can enter per day". Chỉ số hiệu suất chính (key performance indicator, KPI) đo kết quả nghiệp vụ mà tổ chức quan tâm; khi thay thế một hệ thống (replacement project), yêu cầu quan trọng là hệ mới phải giữ hoặc cải thiện các KPI đó, và năng suất nhập hồ sơ vay mỗi ngày của nhân viên xử lý chính là thước đo trực tiếp hiệu quả nghiệp vụ cho vay. "The number of user interface changes per day" không phải chỉ số nghiệp vụ, nó chỉ đo tần suất thay đổi giao diện. "The number of features added to the system" là thước đo hoạt động phát triển, nhiều tính năng không đồng nghĩa nghiệp vụ hiệu quả hơn. "The total amount of data processed by the system" là chỉ số kỹ thuật về khối lượng xử lý, không gắn trực tiếp với kết quả mà người cho vay cần đạt.

Đáp án đúng: "It t is one in which new capabilities are added to an existing system.". Enhancement project (dự án nâng cấp) bổ sung khả năng mới vào hệ thống đang chạy; yêu cầu ở đây tập trung vào tính năng mới, tác động tới phần đang có và việc tránh làm hỏng chức năng cũ. Phương án "It replaces an existing application with a new custom-built system, a commercial off-the-shelf (COTS) system, or a hybrid of those." mô tả replacement project (dự án thay thế), khi ứng dụng cũ bị thay bằng hệ thống tự xây, phần mềm đóng gói hoặc kết hợp. Phương án "It is most commonly implemented to improve performance, cut costs" nêu các lý do thường gặp để tiến hành dự án thay thế, không định nghĩa dự án nâng cấp. Phương án "It is building new releases of established commercial products." mô tả bối cảnh phát triển sản phẩm thương mại theo từng bản phát hành; các bản này có thể chứa cải tiến, nhưng dự án nâng cấp được xác định bởi việc thêm khả năng mới vào một hệ thống hiện có.

Đáp án đúng: "It is a project in which new capabilities are added to an existing system.". Dự án nâng cấp (enhancement project) bổ sung chức năng mới hoặc cải tiến cho một hệ thống đang vận hành; khi làm yêu cầu cho loại dự án này, chuyên viên phân tích phải hiểu hệ thống hiện tại, phân tích tác động lên chức năng cũ và giữ tương thích. Phương án mô tả việc "replaces an existing application with a new custom-built system" là định nghĩa dự án thay thế (replacement project), khi hệ cũ bị thay bằng hệ tự xây, sản phẩm thương mại mua sẵn hoặc kết hợp, chứ không phải nâng cấp hệ đang có. "It is a project which costs less than planned." chỉ nói về kết quả tài chính, không phải một loại dự án. "It is a project which generates more revenues." cũng là kết quả kinh doanh mong muốn chứ không định nghĩa đặc điểm của dự án nâng cấp.

Đáp án đúng: "They represent small, actionable pieces of functionality". Trong agile, câu chuyện người dùng (user story) là mô tả ngắn một nhu cầu từ góc nhìn người dùng, thường theo dạng tôi là ai, muốn gì, để làm gì; mỗi câu chuyện là một phần chức năng nhỏ, đủ cụ thể để ước lượng, làm xong và kiểm thử trong một vòng lặp, kèm tiêu chí chấp nhận. "They define the system architecture" sai vì kiến trúc là quyết định thiết kế kỹ thuật, không do câu chuyện người dùng xác định. "They specify project deadlines" sai vì hạn chót thuộc kế hoạch dự án và phát hành; câu chuyện chỉ được xếp vào vòng lặp theo ưu tiên. "They describe the business goals in detail" sai vì mục tiêu kinh doanh thuộc tầng yêu cầu kinh doanh như tầm nhìn và phạm vi, còn câu chuyện người dùng là yêu cầu ở mức người dùng, ngắn gọn chứ không chi tiết.

Đáp án đúng: "Users who are familiar with how the system works today might like the changes they are about to encounter.". Câu hỏi tìm phát biểu sai về thách thức của dự án nâng cấp và thay thế hệ thống; thách thức thật là người dùng đã quen cách hệ thống đang chạy thường không thích thay đổi và có thể phản đối, nên nói họ có thể thích thay đổi không phải một thách thức. Phương án "degrade the performance to which users are accustomed" đúng vì thay đổi có thể làm chậm hệ thống so với điều người dùng đã quen. Phương án "Little or no requirements documentation might be available" đúng vì hệ thống cũ thường thiếu tài liệu yêu cầu. Phương án "unknowingly break or omit functionality that is vital" đúng vì dễ vô tình làm hỏng chức năng quan trọng với một nhóm. Phương án "request new functionality that seems like a good idea" đúng vì các bên dễ nhân dịp xin thêm tính năng không cần cho mục tiêu nghiệp vụ. Các phát biểu đúng này không được chọn.

Đáp án đúng: "Involving customers throughout the development process to continuously refine and validate requirements.". Cách tiếp cận agile coi yêu cầu sẽ thay đổi và được hiểu dần, nên điều cốt lõi để sản phẩm đúng nhu cầu là khách hàng tham gia liên tục: làm rõ story trước mỗi vòng lặp, xem bản demo và phản hồi để điều chỉnh, tức là khơi gợi và thẩm định yêu cầu diễn ra suốt dự án. Phương án "Documenting all requirements in detail before development begins." sai vì đó là cách làm kiểu thác nước, trái với tinh thần agile là chi tiết hoá đúng lúc. Phương án "Prioritizing speed over accuracy to deliver functionality quickly." sai vì giao nhanh mà sai nhu cầu thì vô ích, agile giao nhanh để nhận phản hồi chứ không hy sinh độ đúng. Phương án "Focusing solely on the technical aspects." sai vì bỏ qua góc nhìn nghiệp vụ và người dùng.