4 Lên kế hoạch
5.7 Tool support (Putty, Jing, Win SCP )
5.7.2 Jing
Công cụ chụp hình đồng thời up load hình ảnh lên server định sẵn.
5.7.3 Win SCP
6 Quản lý chất lượng
Sử dụng free software TRAC nhằm lưu lại tất cả các test cases, bugs, những comments trong từng tickets giúp qa và devs có thể dễ dàng contact với nhau về tình trạng của tickets đó. TRAC tự động chuyển trạng thái khi devs fix task/issue …, kết hợp với Jing tool để upload bugs’ images to server.
6.1 Tickets
Nơi quản lý những công việc PM đã liệt kê cho devs viết chương trình và QA dựa theo nó mà test. Đồng thời tickets cũng là những issues QA tìm ra trong quá trình test hoặc những test cases qa viết để chuẩn bị test khi nhận được document từ PM
6.1.1 Bugs/Task/Test cases
Tất cả những tickets (bugs/tasks/testcases) khi được tạo sẽ được người tạo assign tới tên của developers, thì developer đó sẽ nhận được một email thông báo nội dung của ticket. Sau khi commit (hoàn thành một ticket nào đó) trên hệ thống GIT sẽ tự động cập nhật tình trạng của ticket xuống qa. Sau khi qa test sẽ manual cập nhật tình trạng của ticket (fixed, reopen tùy theo ticket đó fix hay chưa) đồng thời comment vào ticket cho rõ ràng hơn. Lúc này developer sở hữu ticket nay sẽ nhận được nội dung về tình trạng của ticket này để xem có fix tiếp hay không.
Task
Bugs
6.1.2 Công cụ chụp ảnh (Jing)
Công cụ được thiết kế để phục vụ QA chụp ảnh và upload ảnh lên server của mình.
7 Quản lý rủi ro
Thời gian ngắn e rằng không kịp:
Làm thêm giờ + cuối tuần
Kĩ thuật khó:
Hỏi người có kinh nghiệm (bên US) hoặc được train trực tiếp ở US
Phụ thuộc database, network (đây là những lãnh vực do bộ phận riêng đảm nhiệm)
Contact với họ ngay khi có sự cố (email, chat)
Thời gian 2 tuần không đủ cho việc học cách test hiệu quả vì không có nhiều milestone trong 2 tuần trên một ứng dụng
Flexible bằng cách học cách test trên nhiều ứng dụng. 7.1 Quy trình quản lý rủi ro
7.2 Nhận diện rủi ro
Khi bắt đầu, trưởng dự án tổ chức buổi hợp với tất cả các thành viên trong nhóm để đề ra tất cả các rủi ro của dự án.
Trưởng dự án tổ chức các buổi họp định kỳ sáng thứ hai hàng tuần để phát hiện rủi ro mới.
Xác định rủi ro dựa trên các nguồn sau:
Ngân sách/ nguồn tài trợ cho dự án.
Thời gian thực hiện dự án
Thay đổi về phạm vi yêu cầu của dự án
Khó khăn về kỹ thuật
Vấn đề về nhân lực
Hợp đồng giữa hai bên trong kinh doanh
Môi trường, pháp luật, văn hóa …
Sử dụng phương pháp:
Ý kiến chuyên gia (Product manager khác).
Sử dụng lịch sử của những ứng dụng khác (đã trải qua các thời kì như thế nào)
7.3 Phân tích rủi ro
7.3.1 Phân tích khả năng xuất hiện của rủi ro. Likelihood Level table Likelihood Level table
Value Description
1 Hiếm khi xuất hiện
2 Khả năng xuất hiện thấp, chỉ xuất hiện trong những điều kiện nhất định. 3 Khả năng xuất hiện trung bình.
4 Khả năng xuất hiện cao, trong nhiều dự án. 5 Khả năng xuất hiện rất cao trong hầu hết dự án.
7.3.2 Phân tích mức tác động của rủi ro. Impact Level table Impact Level table
Value Description
7.3.3 Ước lượng và phân loại rủi ro.
Risk points = Impact * Likelihood
Priority Rank
Low: Risk point<=3
Medium: 3< risk points <10
High: risk points>=10
PRIORITY RANK Impact Likelihood 1 2 3 4 5 1 2 3 Low 4 Normal 5 High 7.4 Kiểm/Giám sát rủi ro
Thời gian ngắn có thể không kịp -> làm thêm giờ vào thứ 7 cuối tuần.
Kĩ thuật khó-> hỏi người có kinh nghiệm (bên US) hoặc được train trực tiếp ở US
Phụ thuộc database, network (đây là những lãnh vực do bộ phận riêng đảm nhiệm) -> contact với họ ngay khi có sự cố (email, chat)
Học cách test (qa) đôi khi không đủ trong 2 tuần vì không có nhiều milestone trong 2 tuần trên 1 app -> flexible bằng cách học cách test trên nhiều app
2 Chi phí tăng dưới 5% , tiến độ trượt dưới 5%. 3 Chi phí tăng: 5-10% , tiến độ trượt: 5-10%. 4 Chi phí tăng: 10-20% , tiến độ trượt: 10-20%. 5 Chi phi tăng và tiến độ trượt vượt 20%