WAY TO ENTERPRISE
Lesson 31
Quản lý yêu cầu
Agenda
I. Quản lý yêu cầu
II. Ma trận truy vết yêu cầu (RTM) III. Quản lý thay đổi
IV. Workflow khi có thay đổi
I. Quản lý yêu cầu
Quản lý yêu cầu liên quan đến việc thiết lập và duy trì thỏa thuận giữa khách hàng và nhà phát triển về cả yêu cầu kỹ thuật và phi kỹ thuật. Để đảm bảo rằng tất cả các yêu cầu của khách hàng được đáp ứng và cung cấp bằng chứng để biết công việc đã được thực hiện và thực hiện một cách chính xác.
II. Ma trận truy vết (RTM)
- Làm thế nào để đảm bảo việc test đã cover được hết các case?
- Làm thế nào để đạt test coverage đã đề ra?
- Trong quá trình kiểm thử, có thể team test mắc một nhầm lẫn nào đó hay miss một requirement và không viết TCs cho nó?
=> Làm thế nào để Manager có thể quản lý được?
II. Ma trận truy vết (RTM)
Ma trận truy xuất nguồn gốc các requirement(RTM) Requirement Traceability Matrix đảm bảo rằng tất cả mọi thứ trong phạm vi của các tài liệu có liên quan được sử dụng để theo dõi các yêu cầu và kiểm tra các yêu cầu này đã được đáp ứng đủ hay chưa.
Đơn giản hơn, RTM là một tài liệu cập nhật các yêu cầu và được đối chiếu với việc kiểm định hệ thống (test cases). Nó đảm bảo rằng tất cả các yêu cầu của khách hàng đều được team kiểm thử viết TCs thực hiện đầy đủ trong quá trình kiểm thử.
II. Ma trận truy vết (RTM)
Mục đích của RTM:
• Sự tin tưởng của khách hàng: Đầu tiên và quan trọng nhất là xây dựng lòng tin của khách hàng rằng sản phẩm đang được phát triển và kiểm thử theo yêu cầu.
• Đảm bảo độ bao phủ tuyệt đối: Tất cả requirement cần phải được bao phủ trong Test Design và trong quá trình thực hiện test. Mục đích là đảm bảo cover được 100% trường hợp kiểm thử.
• Theo dõi thay đổi yêu cầu: Duy trì trong suốt vòng đời của việc phát hành, thay đổi các yêu cầu này cũng được ghi lại và theo dõi trong RTM.
II. Ma trận truy vết (RTM)
Mục đích của RTM:
• Quản lý rủi ro: đảm bảo rằng mỗi requirement có thể được test và cuối cùng phải được test.
• Phát hiện và đề xuất chức năng bị miss.
• Tasks: Trợ giúp trong việc tạo ra các tài liệu về yêu cầu, spec, các tài liệu bàn giao, và plan dự án.
• Khả năng bảo trì: Bất kỳ sự thay đổi yêu cầu nào đều có thể theo dõi được để cập nhật trong Test Design.
• Bám theo scope: Sử dụng việc đảo ngược việc truy xuất để đảm bảo rằng không có kiểm thử thêm nào được thực hiện mà không có một yêu cầu tương ứng
II. Ma trận truy vết (RTM)
Giới thiệu về một Template RTM
III. Quản lý thay đổi
Quản lí sự thay đổi dự án la
• Quá trình xem xét tất cả các đề xuất thay đổi, phê duyệt thay đổi và thực hiện thay đổi về sản phẩm dự án, về các nguồn lực dự án, về tài liệu dự án và kế hoạch quản lí dự án.
• Quản lí sự thay đổi dự án được thực hiện từ giai đoạn đề xuất ý tưởng dự án cho đến khi dự án hoàn thành.
• Đề xuất thay đổi có thể bắt nguồn từ bất kì chủ thể nào có liên quan đến dự án như từ
khách hàng, chủ đầu tư, nhà quản lí dự án, thành viên đội quản lí dự án, và các sự kiện rủi ro.
III. Quản lý thay đổi
Tuy nhiên, nếu quản lý thay đổi yêu cầu không tốt, kết hợp và truyền đạt không phù hợp sẽ gây ra những vấn đề nghiêm trọng và tác động tiêu cực đến tổ chức. Để xem xét cách quản lý các yêu cầu thay đổi để đưa ra quyết định có chấp nhận thay đổi hay không và cách đưa chúng vào dự án với ít sự gián đoạn nhất thông qua 4 bước sau:
III. Quản lý thay đổi
1. Xác định phạm vi thay đổi
• Câu hỏi đầu tiên là phạm vi của yêu cầu thay đổi là gì?
• Một yêu cầu thay đổi có thể liên quan đến kinh doanh, các bên liên quan hay các yêu cầu chức năng.
• Bước này khá giống với việc khám phá các yêu cầu mới cho dự án ở giai đoạn đầu.
• Bạn sẽ muốn tất cả các bên liên quan bị ảnh hưởng tham gia vào việc nêu ra yêu cầu của sự thay đổi, phân tích các yêu cầu đó và xác thực chúng.
III. Quản lý thay đổi
2. Xác định phạm vi kết hợp thay đổi (ảnh hưởng)
• Khi bạn hiểu thay đổi được đề xuất là gì và tại sao nó quan trọng, nhóm dự án của bạn sẽ hình thành phản hồi với thay đổi được đề xuất. Điều này thường có nghĩa là xác định tác động của thay đổi đối với thiết kế kỹ thuật và tiến độ dự án, đưa ra kế hoạch thực hiện cấp cao và xác định mức độ nỗ lực để thực hiện thay đổi.
• Với thông tin này thường được ghi lại trong Change Request Form (biểu mẫu yêu cầu thay đổi), bạn có thể nói rõ liệu thay đổi có ảnh hưởng ngân sách dự án, lịch trình hay phạm vi.
III. Quản lý thay đổi
3. Có được sự chấp thuận hoặc từ chối
• Một thay đổi yêu cầu một giờ làm việc có thể được nhà tài trợ kinh doanh chính chấp thuận trong nhóm dự án.
• Một thay đổi yêu cầu một tuần làm việc có thể được chấp nhận bởi quản lý trung cấp, người cho phép những thay đổi có ít tác động đến các dự án khác trong lộ trình.
• Một thay đổi đến yêu cầu kinh doanh chính cần nhiều hơn một tháng làm việc chỉ được chấp nhận bởi cấp độ điều hành vì nó ảnh hưởng nhiều đến các sáng kiến của tổ chức.
III. Quản lý thay đổi
4. Triển khai một yêu cầu thay đổi được chấp thuận
Khi một yêu cầu thay đổi được chấp thuận, nhóm dự án cần được thông báo và các sản phẩm cần được cập nhật
• Requirements Documentation
• Technical Design Documentation
• Software or Programming Code
• Project Plans and Schedules
• Test Plans or Test Cases
=> Người quản lý dự án hoặc nhà phân tích kinh doanh thông báo cho nhóm dự án về sự
III. Quản lý thay đổi
• Mặc dù, “thay đổi” thường gây sự khó chịu nhưng thực tế thay đổi xảy ra vì những lý do chính đáng. Trong thị trường cạnh tranh và chuyển động nhanh như ngày nay, sẽ
không thực tế khi trông đợi vào các bên liên quan có kiến thức hoàn hảo về những điều họ cần để đạt mục tiêu kinh doanh.
• Điều quan trọng nhất là một quyết định sáng suốt được đưa ra về việc có hay không?
làm thế nào để kết hợp sự thay đổi? Quản lý được các thay đổi để những người có liên quan hiểu được nó là gì, tầm quan trọng và tác động của nó?
IV. Workflow khi có thay đổi
IV. Workflow khi có thay đổi
STT Hoạt động Người
thực hiện Thời điểm
thực hiện Đầu ra
1 Tiếp nhận yêu cầu thay đổi/ trả lời Q&A
Khi có yêu cầu thay đổi từ Stakeholders hoặc member trong đội dự án hoặc những trả lời từ Q&A (Q&A phát sinh do thay đổi không rõ ràng được đội dự án lập thành Q&A và gửi khách hàng), những yêu cầu thay đổi này sẽ được gửi cho cả team của đội dự án. Khách hàng cũng có thể gửi qua RM, hoặc gửi vào file excel hoặc update trực tiếp vào file tài liệu spec của dự án. Ngoài ra khi khách hàng gửi các feedback thì trong các feedback đó cũng bao gồm cả các yêu cầu thay đổi.
Team KH gửi Change
request
IV. Workflow khi có thay đổi
STT Hoạt động Người
thực hiện Thời điểm
thực hiện Đầu ra
2 Phân tích yêu cầu thay đổi
BA sẽ thực hiện phân tích các yêu cầu thay đổi/ trả lời Q&A được gửi đến từ bước 1, Nếu không hiểu các yêu cầu thay đổi thì sẽ lập thành Q&A và gửi lại khách hàng. Comter sẽ thực hiện dịch các Q&A (nếu khách hàng là người nước ngoài ) và gửi Q&A cho khách hàng. Nếu hiểu rõ các yêu cầu thay đổi thì chuyển sang bước tiếp theo
Team KH gửi Change
request
3 Cập nhật file Change Log
Sẽ thực hiện cập nhật vào file Change Log sau khi bước phân tích đã hiểu được rõ yêu cầu thay đổi, khi thực hiện xong thì
BA Change_log
IV. Workflow khi có thay đổi
STT Hoạt động Người
thực hiện
Thời điểm thực hiện
Đầu ra
4 Ảnh hưởng đến effort
Nếu không ảnh hưởng thì chuyển sang bước 7 Nếu ảnh hưởng đến effort thì chuyển sang bước 5 Khi phân tích xong cũng cần cập nhật vào file change log.
BA, TL/PM
5 Ước lượng effort
TL/PM sẽ thực hiện ước lượng lại về effort cho phù hợp với sự thay đổi
TL/PM Sau khi có kết quả phân tích
IV. Workflow khi có thay đổi
STT Hoạt động Người
thực hiện Thời điểm thực hiện
Đầu ra
6 Review
Sau khi thực hiện bước 5 thì sẽ gửi nội bộ review. Nếu nội bộ review chưa đạt thì sẽ thực hiện lại bước 5. Nếu nội bộ review đạt thì chuyển cho Comter dịch (nếu khách hàng là người nước ngoài) và gửi khách hàng Khách hàng review chưa đạt thì cũng quay lại bước 5 Nếu khách hàng review đạt thì chuyển sang bước 7
Nội bộ/ KH
7 Cập nhật tài liệu BA Sau khi KH
chốt thực hiện
V. Quản lý thay đổi trong một số mô hình phần mềm
Dự án Product:
Issue:
• Spec thay đổi liên tục
• Tài liệu spec không được chi tiết
• Việc test không rõ ràng, không có kế hoạch
Giải pháp: Cố gắng làm rõ ràng quy trình Change request, suggest chia làm 3 phần:
1. Before change:
• Xác định vùng thay đổi và xác định các vùng ảnh hưởng
• Estimate và lên plan cho change request ( test ảnh hưởng và hồi quy)
• Tạo tài liệu Change request (note ảnh hưởng)
V. Quản lý thay đổi trong một số mô hình phần mềm
2. Implement change:
• Update code nếu cần
• Viết Change request document: business change + note thay đổi ảnh hưởng
3. After change:
• Update plan
• Update ma trận truy vết
• Test hồi quy
V. Quản lý thay đổi trong một số mô hình phần mềm
Dự án Agile/ Scrum: welcome thay đổi
Issue:
• Spec thay đổi liên tục
• Tài liệu thường không chi tiết, làm hết sprint này thì mới tạo spec của sprint tiếp theo
• Test không rõ ràng, không có kế hoạch
V. Quản lý thay đổi trong một số mô hình phần mềm
Giải pháp:
• Cho khách hàng ngồi cùng đội phát triển
• BA có thể chạy trước 2~ 3 sprint để phân tích trước yêu cầu để clear các phần cần làm ( mỗi sprint thường 2 tuần)
V. Quản lý thay đổi trong một số mô hình phần mềm
Dự án V-model: chạy tuần tự
Issue:
• Tiến độ bị nén lại các giai đoạn sau (thường là tiến độ sau)
• Kế hoạch luôn bị nén lại (kế hoạch 4 tuần test, tuy nhiên các bên thường bàn giao sang cho đội test muộn -> còn ít time để test)
• Đội dev bàn giao không ổn định và không test được
• Team test tham gia muộn trong dự án
• Tài liệu có rõ ràng, chi tiết hơn các mô hình khác
V. Quản lý thay đổi trong một số mô hình phần mềm
Giải pháp:
Luôn luôn update test plan
• Request khách hàng lùi deadline
• Request thêm resource test Đổi chiến lược test:
• Thứ tự ưu tiên của Functions
• Bỏ testcase -> test khám phá Trao đổi với team:
• Đảm bảo các khâu làm đúng deadline để đảm bảo các khâu có đủ thời gian để thực
V. Quản lý thay đổi trong một số mô hình phần mềm
Giới thiệu một Template về Quản lý thay đổi
