Kế hoạch dự án Trang 1 CMI - BOOK STORY KẾ HOẠCH DỰ ÁN Phạm vi áp dụng: Những khách hàng có nhu cầu mua sách ebook hoặc audio, Những người dùng muốn thảo luận những vấn đề về sách.. Kế
Trang 1ĐẠI HỌC QUỐC GIA THÀNH PHỐ HỒ CHÍ MINH
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN
Quản trị dự án TMĐT
Dự án: Book Story
GVHD: Ths Huỳnh Đức Huy Lớp: EC208.N11.TMCL.ST6 Tên Nhóm: Nhóm 9
Trang 2Kế hoạch dự án Trang 1
CMI - BOOK STORY
KẾ HOẠCH DỰ ÁN
Phạm vi áp dụng: Những khách hàng có nhu cầu mua sách ebook hoặc audio, Những người dùng muốn
thảo luận những vấn đề về sách
Phiên bản 2.1.3
Công ty startup BOOK STORY
Trang 3Kế hoạch dự án Trang 2
Nhận Xét
···
···
···
···
···
···
···
···
···
···
···
···
···
···
···
···
···
···
···
···
···
···
···
···
···
···
···
Trang 4Kế hoạch dự án Trang 3
LỜI CẢM ƠN
Trong quá trình học tập môn Quản trị dự án TMĐT, chúng em đã học hỏi được rất nhiều kiến thức về mặt lý thuyết, cũng như các phương pháp thực hành thực tế trong việc quản
lý dự án phần mềm công nghệ thông tin
Vì vậy, chúng em xin gửi lời cảm ơn đến thầy Huỳnh Đức Huy đã luôn luôn tận tình trong việc hướng dẫn và truyền đạt nội dung môn học đến với chúng em
Trong quá trình làm đồ án, khó tránh khỏi những sai sót Chúng em rất mong nhận được
sự góp ý của thầy để có thể hoàn thiện đồ án tốt hơn nữa
Xin trân thành cảm ơn TP.HCM, tháng 12 năm 2022
Trang 5Kế hoạch dự án Trang 4
Quản lý tài liệu
Ngày tạo: 25/11/2022 Thời gian lưu: 13/12/2022 13:52:48
Lịch sử thay đổi
Người thực hiện Ngày thực hiện Nội dung Phiên bản
Nguyễn Thanh Hiếu 25/11/2022 Lập tài liệu, trang bìa, lời
Trương Quốc Thắng 25/11/2022 Cập nhập mô hình phát triển
Nguyễn Thanh Hiếu 27/11/2022 Vai trò và trách nhiệm 0.0.2
Trương Quốc Thắng 27/11/2022 Giả định, điều kiện và rủi ro 0.0.2
Đỗ Công Lâm 29/11/2022 Tính toán chi phí dự kiến 0.0.4
Trương Quốc Thắng 30/11/2022 Yêu cầu nguồn lực 0.0.7
Đỗ Công Lâm 30/11/2022 Yêu cầu đào tạo nhận sự dự
Đỗ Công Lâm 2/12/2022 Kế hoạch thực hiện dự án 0.0.9
Nguyễn Thanh Hiếu 30/11/2022 Lập lịch làm việc 0.1.1 Nguyễn Thanh Hiếu 30/11/2022 Xác định các cột mốc, work
Trang 6Trương Quốc Thắng 7/12/2022 Phương pháp, công cụ, công
Trương Quốc Thắng 9/12/2022 Xác định yêu cầu người
Trương Quốc Thắng 10/12/2022 Nghiệm thu sản phẩm 1.9.2
Đỗ Công Lâm 11/12/2022 Kiểm tra chất lượng sản
Nguyễn Thanh Hiếu 13/12/2022 Kế hoạch quản lý rủi ro 2.1.1
Đỗ Công Lâm 14/12/2022 Bổ sung tài liệu liên quan 2.1.2 Mai Quốc Bảo 14/12/2022 Chỉnh sửa format word, sửa
Trang 7Kế hoạch dự án Trang 6
Lịch sử kiểm tra
Người kiểm tra Ngày kiểm tra Nhận xét/đánh giá Phiên bản
Nguyễn Thanh Hiếu 29/11/2022
Đánh giá chung về bản kế hoạch (bản chưa hoàn thiện)
Các góp ý bao gồm:
- Về các định dạng bài kế hoạch,phông chữ, ngôn ngữ sử dụng
- Cần xác định lại thời gian và chiphí chính xác hơn, dựa vào WBS
-Bổ sung thêm các tài liệu liênquan
2.1.1
Trang 8Kế hoạch dự án Trang 7
Mục Lục
1 Giới thiệu _ 10 1.1 Từ ngữ viết tắt và thuật ngữ 10 1.2 Tham khảo 10 1.3 Tổng quan dự án _ 11 1.4 Phạm vi, mục tiêu dự án 11 1.5 Các bên liên quan và nhân sự chính _ 14 1.6 Điều phối dự án _ 15
2 Tổ chức dự án _ 16 2.1 Mô hình phát triển phần mềm _ 16 2.2 Cơ cấu tổ chức dự án 19 2.2.1 Tổ chức dự án _ 19 2.2.2 Vai trò và trách nhiệm 19
3 Quản lý dự án _ 22 3.1 Giả định, điều kiện và rủi ro 22 3.1.1 Giả định _ 22 3.1.2 Các hạn chế 22 3.1.3 Chi phí dự kiến 22 3.2 Khởi tạo dự án 23 3.2.1 Ước lượng _ 23 3.2.2 Yêu cầu nguồn lực 23 3.2.3 Yêu cầu đào tạo nhân sự (nếu có) _ 24 3.2.4 Các quy tắc của nhóm 24 3.3 Kế hoạch thực hiện dự án _ 26 3.3.1 Phân rã công việc (WBS) 26 3.3.2 Lập lịch làm việc _ 32 3.3.3 Các cột mốc (milestone) và các work product chính 35 3.3.4 Điều phối nguồn lực _ 38
Trang 9Kế hoạch dự án Trang 8
3.4 Kế hoạch kiểm soát dự án _ 40 3.4.1 Kiểm soát kế hoạch thực hiện _ 40 3.4.2 Kế hoạch quản lý yêu cầu 41 3.4.3 Kế hoạch quản lý quy trình phát triển phần mềm 41 3.4.4 Kiểm tra chất lượng sản phẩm _ 45 3.4.5 Báo cáo dự án _ 46 3.4.6 Đo lường dự án 47 3.5 Quản lý rủi ro 47 3.5.1 Nhận diện rủi ro 48 3.5.2 Phân tích rủi ro 50 3.5.3 Phân tích rủi ro 52
Trang 10Kế hoạch dự án Trang 9
Mục Lục Hình Ảnh
Hình 2.1-1: Mô Hình Agile 16 Hình 2.1-2: Phương pháp Scrum _ 17 Hình 2.2-1: Tổ chức dự án 19 Hình 3.3-1: Sơ đồ gantt _ 35 Hình 3.5-1: Quy trình quản trị rủi ro _ 48 Hình 3.5-2: Mối quan hệ và trình tự các bước trong quy trình kiểm soát rủi ro 48 Hình 3.5-3: Phân tích rủi ro 50 Hình 3.5-4: Bảng đánh giá khả năng xuất hiện 51 Hình 3.5-5: Bảng đánh giá khả năng tác động _ 51 Hình 3.5-6: Bảng sắp xếp độ ưu tiên _ 52 Hình 3.5-7: Bảng kế hoạch đối phó rủi ro với độ ưu tiên 1 53 Hình 3.5-8: Bảng kế hoạch đối phó rủi ro với độ ưu tiên 2 54 Hình 3.5-9: Bảng kế hoạch đối phó rủi ro với độ ưu tiên 3 56
Trang 11Kế hoạch dự án Trang 10
1 Giới thiệu
Tài liệu này là báo cáo đồ án môn học Quản trị dự án thương mại điện tử của nhóm 9 bao gồm toàn bộ quá trình lên kế hoạch và cách sử dụng phần mềm để phân chia và quản lý tiến độ công việc của các thành viên trong nhóm
1.1 Từ ngữ viết tắt và thuật ngữ
PM Project Manager – Trưởng dự án
Work Products Tất cả các tài liệu/source của dự án như tài liệu yêu cầu người dùng,
tài liệu kỹ thuật, source code, hướng dẫn sử dụng
Ebook Sách điện tử
Audio Sách nói
PO Product owner : Người sở hữu sản phẩm
IDE (Integrated Development Environment) là môi trường tích hợp dùng
để viết code để phát triển ứng dụng UIT Trường đại học công nghệ thông tin TP.HCM
UAT (User acceptance testing) Kiểm thử chấp nhận
Dev (Developer) là những lập trình viên
OT (over time) là làm thêm giờ
CSDL Cơ sở dữ liệu
YCND Yêu cầu người dùng
WBS (Work Breakdown Structure) Cấu trúc phân rã công việc
1.2 Tham khảo
1.2.1 Những Tài liệu mà nhóm tham khảo
(CheckMeIn)_Final_vP.pdf
Báo cáo môn học QLDA Nhóm trưởng: Nguyễn Hồng Phúc
2 Template báo cáo QTDA ThS Huỳnh Đức Huy
3 Book Story_Đặc Tả Tính Năng.docx
Trang 12Kế hoạch dự án Trang 11
1.2.2 Tài liệu của nhóm
4 Book Story_ Product Backlog.xlsx Product_Backlog của dự án
5 Book Story_QLRR _A.B.docx Tài liệu quản lý rủi ro
6 Book Story_Đặc Tả Tính Năng.docx Đặc tả những tính năng quan trọng
10 Book Story _ Sơ đồ usecasse.docx Sơ đồ use case của dự án
11 Book Story_ Kiểm thử.docx Kiểm thử chương trình
12 Book Story _ Read Me.docx File hướng dẫn dự á: cách setup, mô
tự viết lên câu chuyện và cuốn sách của chính họ
1.4 Phạm vi, mục tiêu dự án
1.4.1 Mục tiêu và phạm vi dự án
Trang 13Kế hoạch dự án Trang 12
1.4.1.1 Mục tiêu
- Tạo ra 1 website giúp công ty
+ Tiếp thị hiệu quả sản phẩm và dịch vụ của mình ra khắp thế giới + Tạo kênh bán hàng trực tiếp tới khách hàng với quy mô rộng, tốc độ nhanh và chi phí ít
+ Ngoài quy mô Việt Nam thì mong muốn mở rộng ra quy mô toàn cầu
+ Đơn giản hóa được các thủ tục hành chính, các công việc giấy tờ, tăng hiệu quả giao dịch thương mại
+ Với Website Thương mại điện tử, doanh nghiệp tạo cho mình khả năng kinh doanh liên tục 24/24 giờ, liên tục 07 ngày trong tuần với chi phí rất thấp Không cần nhân viên giám sát khách hàng như tại các siêu thị bình thường, không cần bỏ tiền thuê địa điểm bán hàng, không cần hệ thống kiểm tra, giới thiệu sản phẩm, không cần hệ thống tính tiền, Tất cả đều được Website làm tự động, nhanh chóng
và với độ chính xác tuyệt đối
+ Tại cùng 1 thời điểm, Website Thương mại điện tử có thể phục vụ hàng triệu lượt người mua hàng ở khắp nơi trên thế giới với các yêu cầu rất khác nhau về thông tin sách, loại sách, giá cả, hình ảnh, chất lượng, mẫu mã,
+ Thông tin, giá cả sản phẩm được cập nhật, thay đổi một cách tức thời theo sự biến động của thị trường
+ Đem lại khả năng kinh doanh mới cho doanh nghiệp: "Kinh doanh ngay cả khi bạn đang ngủ"
- Tạo ra 1 website giúp những người quan tâm đến ebook (sách điện tử):
+ Có thêm một hình thức mua hàng thuận tiện, dễ dàng, nhanh chóng + Có thêm một hình thức thanh toán mới tiện lợi, an toàn
+ Người dùng có thể xem list sách có và xếp theo từng loại sách Comment được những sách mà mình đã mua
+ Có cơ hội mua sản phẩm và dịch vụ trực tiếp từ nhà sản xuất hoặc nhà cung cấp chính không qua trung gian
Trang 14Kế hoạch dự án Trang 13
+ Giúp kết nối những người yêu sách, quan tâm đến sách lại với nhau Với chức năng giúp người dùng tạo blog về những chủ đề sách mà mình quan tâm Còn có thể sửa và xóa được blog, tìm kiếm blog và xem những blog được đăng gần nhất
+ Người mua trở thành người chủ với toàn quyền lựa chọn sản phẩm, tìm kiếm bất kỳ thông tin nào về sản phẩm theo nhu cầu, so sánh giá
cả, đặt mua hàng với hệ thống tính toán tiền tự động, đầy đủ, rõ ràng, trung thực và chính xác nhất
1.4.1.2 Yêu cầu
- Ứng dụng tiện dụng, dễ dùng cho người dùng Cả người có nền tảng tin học
và người không có nền tảng tin học
- Website có giao diện thân thiện, đẹp mắt để người dùng thấy hứng thú khi vào website
- Website có thể hoạt động trên nhiều hệ điều hành
- Có tính bảo mật cao Không gây rò rỉ thông tin người dùng Quyền hạn mỗi User được bảo vệ chặt chẽ Chỉ có Admin mới có quyền tạo mới các User
1.4.1.3 Đối tượng người dùng
- Người quản lý người dùng, sản phẩm (Admin)
- Người dùng muốn xem, mua sách ebook (User)
1.4.2 Phương pháp, công nghệ sử dụng:
1.4.2.1 Phương pháp
Quy trình Agile (Scrum): Nhóm phát triển phần mềm thông qua các phân đoạn lặp (sprint) kéo dài hơn 3 tuần Tất cả các thành viên cùng nhau làm việc từ công đoạn thu thập, phân tích yêu cầu, tạo product backlog, lên
kế hoạch, coding, thực hiện các chức năng trong mỗi sprint cho đến việc testing Trong mỗi sprint ngoài việc phân công việc(task) cho từng thành
Trang 15Kế hoạch dự án Trang 14
viên thì sau mỗi sprint các thành viên sẽ ghi những vấn đề gặp phải khi thực hiện sprint đó và viết cách giải quyết (nếu có) đồng thời các thành viên cũng viết những điểm tốt của sprint đó Sau đó PO sẽ nhận xét qua lại về tổng sprint đó Sau khi kết thúc sprint thì sẽ có 1 buổi họp để review lại sprint trước và lên kế hoạch cho sprint mới
1.4.2.2 Công nghệ
- Ngôn ngữ: HTML, CSS, Javascript, SCSS
- Framework: Reactjs
- Cơ sở dữ liệu: Firebase
- Công cụ thiết kế: Figma, Draw.io
- Công cụ quản lý: Trello, Excel, Git
- IDE: Visual Studio Code
- Kiến trúc mô hình: Client-Server
1.5 Các bên liên quan và nhân sự chính
STT Họ Tên Bộ phận Vai trò & trách
1 Nguyễn Thanh
Hiếu
Phòng điều hành
- Quản lý dự án -Chịu trách nhiệm lên kế hoạch và điều phối công việc
Email:
20521328@gm.uit.edu.vn SĐT:
0382279474
2 Trương Quốc
Thắng
Phòng phân tích nghiệp
vụ
-Chịu trách nhiệm thiết kế và kiểm soát chất lượng
Email:
20520930@ms.uit.edu.vn SĐT:
0916036287
3 Đỗ Công Lâm
Phòng kỹ thuật
-Chịu trách nhiệm
kỹ thuật
Email:
20521001@gm.uit.edu.vn SĐT:
0866161226
Trang 16Kế hoạch dự án Trang 15
4 Tống Khánh Linh Phòng hỗ
trợ
- Hỗ trợ người dùng kịp thời
Email:
20521537@gm.uit.edu.vn
5 Mai Quốc Bảo
Phòng lưu trữ
-Chịu trách nhiệm lưu trữ, bảo mật những thông tin người dùng
1 Tài liệu YCND Tuần 1, 11/2022 UIT Chuyển qua Trello
2 Tài liệu danh sách giao
3 Xác nhận tài liệu YCND Tuần 1, 11/2022 UIT
4 Tài liệu thư viện dữ liệu Tuần 2, 11/2022 UIT Chuyển qua email
5 Tài liệu hướng dẫn sử
6 Tài liệu hướng dẫn cài
7 Tài liệu kỹ thuật Tuần 3, 11/2022 UIT Chuyển qua email
8 Tài liệu xác nhận triển
khai kỹ thuật
Tuần 3, 11/2022
UIT Chuyển qua email
9 Biên bản nghiệm thu Tuần 1, 12/2022 UIT
10 Tài liệu kế hoạch UAT Tuần 1, 11/2022 UIT Chuyển qua Trello
11 Triển khai UAT Tuần 3, 11/2013 UIT Chat, Chuyển qua
Trello
Trang 17Kế hoạch dự án Trang 16
2 Tổ chức dự án
2.1 Mô hình phát triển phần mềm
Dự án này sử dụng mô hình Agile Agile là phương pháp phát triển phần mềm linh hoạt
để làm sao đưa sản phẩm đến tay khách hàng càng nhanh càng tốt, là một hướng tiếp cận cụ thể cho việc quản lý dự án phần mềm Scrum là 1 dạng của mô hình Agile và là Framework phổ biến nhất khi thực hiện mô hình agile Scrum là mô hình phát triển phần mềm lặp đi lặp lại Những khoảng lặp cố định thường kéo dài 1,2 tuần được gọi lại Sprint hoặc Iteration Trong dự
án này mỗi Sprint sẽ tương ứng với 1 tuần
Hình 2.1-1: Mô Hình Agile
Trang 18- Daily Scrum (họp scrum hằng ngày): Vì các thành viên không có nhiều thời gian nên trong đồ án này cuộc họp này không được diễn ra
- Sprint review (họp sơ kết sprint): Sau cuối mỗi sprint nhóm phát triển cũng với product owner sẽ rà soát lại các công việc đã hoàn tất trong sprint vừa qua và đề xuất các chỉnh sửa hoặc thay đổi cần thiết cho sản phẩm
- Sprint Retrospective (họp cải tiến sprint): Scrum master hỗ trợ cùng nhóm phát triển sẽ
rà soát lại toàn sprint vừa kết thúc Cuộc họp này được diễn ra qua tin nhắn
Vai trò
- Trong scrum đội ngũ tham gia phát triển phần mềm được phân chia ra ba vai trò với trách nhiệm rõ ràng để đảm bảo tối ưu hóa các công việc đặc thù Ba vai trò này bao gồm:
Trang 19Kế hoạch dự án Trang 18
+ Product Owner (PO): là người chịu trách nhiệm về sự thành công của dự án, người định nghĩa các yêu cầu và đánh giá cuối cùng đầu ra của các nhà phát triển phần mềm
+ Scrum Master(Quản lý dự án): là người phải đảm bảo các sprint được hoàn thành đúng mục đích, bảo vệ đội làm việc và loại bỏ các trở ngại
+ Development Team(Dev, Test ): Gồm 5 người Trong đó có 1 Teamleader giúp quản lý đội ngũ code
Giá trị
- Minh bạch: Mọi kế hoạch và công việc của các thành viên tất cả mọi người đều phải biết
và công khai kể cả PO
- Thanh tra: Phải thường xuyên thanh tra kiểm soát tiến độ công việc của mình xem đã hoàn thành đến đâu rồi có phát hiện điều gì bất thường không để kịp thời xử lý, đảm bảo tiến độ công việc
- Thích nghi: Là đảm bảo rằng khi có một vấn đề mới hay có sự thay đổi nào từ phía khách hàng thì mọi người trong team sẽ có thể xử lý và đáp ứng theo cách thích hợp Luôn phải thích nghi trong mọi hoàn cảnh
Lợi ích
- Cải thiện chất lượng phần mềm, dễ học và dễ sử dụng
- Rút ngắn thời gian phát hành phần mềm, cho phép khách hàng sử dụng sản phẩm sớm hơn
- Nâng cao tinh thần đồng đội, tối ưu hóa hiệu quả và nỗ lực của đội phát triển
- Kiểm soát dự án tốt, cải tiến liên tục
- Giảm thiểu rủi ro khi xây dựng sản phẩm
Chúng tôi đã quản lý dự án theo Agile bằng Trello
Link Trello: Dự án Book Story
Link Product-Backlog: Product Backlog
Trang 201 Nguyễn Thanh Hiếu
Email:
20521328@gm.uit.edu.vn
Product Owner, dev
-Chịu trách nhiệm quản lý, điều phối toàn bộ dự án
- Thẩm định, phê duyệt các vấn đề, tài chính, điều chỉnh ngân sách và định mức chi phí của dự án
- Chịu trách nhiệm phân tích nhu cầu của bên khách hàng, và các đối tác liên quan
để tìm hiểu và đề xuất các giải pháp giải quyết vấn đề phát sinh về việc quản lý tham gia sự kiện Viết tài liệu phân tích
hệ thống
- Đảm bảo dự án đúng tiến độ và chất lượng sản phẩm
- Tham gia vào việc lập trình phần mềm của dự án
Trang 21- Đảm bảo các sprint được hoàn thành đúng mục đích, bảo vệ đội làm việc và loại bỏ các trở ngại
- Lập kế hoạch triển khai dự án trực thuộc phạm vi quản lý: qua đó tiếp nhận, lập dự trù nguồn lực thực hiện, thông báo, phối hợp với các phòng ban liên quan và quan để triển khai thực lực thực hiện dự án, đề xuất phương án dự phòng không được triển khai theo đúng kế hoạch Tham gia đánh giá, dự phòng rủi
ro và các biện pháp phòng tránh, khắc phục rủi ro
- Tham gia vào việc lập trình phần mềm của dự án
3 Đỗ Công Lâm
Email:
20521001@gm.uit.edu.vn
TeamLeader, dev
- Quản lý việc lập trình phần mềm của
dự án Phân chia việc lập trình từng chức năng cho mỗi thành viên trong team code
- Đảm bảo code của từng Sprint đúng tiến độ, đạt hiệu quả
- Merge code và deploy
- Viết tài liệu hướng dẫn dự án
- Training và hướng dẫn team dev code đạt hiệu quả
- Đưa ra ý kiến, đề xuất cho các vấn đề của nhóm dự án
- Tham gia vào việc lập trình phần mềm của dự án
- Phân tích và thiết kế hệ thống thông tin
Trang 22- Phân tích nhu cầu của bên khách hàng,
và các đối tác liên quan để tìm hiểu và đề xuất các giải pháp giải quyết vấn đề phát sinh về việc quản lý tham gia sự kiện Viết tài liệu phân tích hệ thống
5 Mai Quốc Bảo QA, Tester - Điều hành, tổ chức thực hiện kiểm soát
- Phân tích nhu cầu của bên khách hàng,
và các đối tác liên quan để tìm hiểu và đề xuất các giải pháp giải quyết vấn đề phát sinh về việc quản lý tham gia sự kiện Viết tài liệu phân tích hệ thống
Trang 23Kế hoạch dự án Trang 22
3 Quản lý dự án
3.1 Giả định, điều kiện và rủi ro
3.1.1 Giả định
- Thông tin về email đã được chứng thực
- Mọi nội dung về sách đã có bản quyền
- Server/ database/ network hoạt động ổn định, không xảy ra sự cố
- Người dùng sử dụng máy tính, laptop (chưa hỗ trợ thiết bị di động)
3.1.2 Các hạn chế
- Nhóm chưa có nhiều kinh nghiệm với những dự án thực tế nên trong quá trình phát triển gặp nhiều khó khăn trong việc thiết kế, code Vậy nên đã có 1 số thay đổi về yêu cầu chức năng
- Vì hạn chế về tài chính nên khi sử dụng figma vẫn có 1 số ý chưa truyền tải được hết cho team dev
- Ứng dụng không hỗ trợ trên thiết bị di động
- Tất cả các thành phần trong ứng dụng được xây dựng mới hoàn toàn, không có thể tái sử dụng từ các dự án trước là 1 trong những nguyên nhân đội chi phí dự án lên cao
- Vì là đội ngũ sinh viên nên chi phí ít, chưa có nhiều kỹ năng trong việc quản lý, thiết kế cũng như code
3.1.3 Chi phí dự kiến
Các chi phí tổng quan trong dự án:
STT Nội dung công việc Chi phí (đồng) Ghi chú
1 Công tác chuẩn bị 10.420.000 Giai đoạn chuẩn bị và xác định
yêu cầu
2 Phân tích yêu cầu 5.195.270 Giai đoạn phân tích
Trang 24Kế hoạch dự án Trang 23
5 Kiểm thử 5.125.000 Giai đoạn kiểm thử hệ thống,
kiểm thử chấp nhận
6 Hoàn thiện 2.125.000 Giai đoạn hoàn thiện lại sản
phẩm sau khi kiểm thử
7 Kết thúc dự án 4.679.950 Giai đoạn vận hành và bảo trì
Đây là chi phí tối thiểu, cần tính thêm khoảng 30% khi ký hợp đồng
3.2 Khởi tạo dự án
3.2.1 Ước lượng
3.2.1.1 Thời gian
- Thời gian thực hiện dự án dự kiến: 2 tháng
- Thời gian thực hiện dự án tối đa: 3.5 tháng
- Thời gian tập huấn sử dụng hệ thống: 1 ngày
- Thời gian sử dụng thử nghiệm hệ thống: 0.5 tháng
- Phương pháp sử dụng: Ước lượng dựa theo lịch sử
3.2.1.2 Chi phí
- Chi phí dự kiến:
- Chi phí tối đa:
- Phương pháp sử dụng: Parametric estimating (Ước tính tham số)
3.2.2 Yêu cầu nguồn lực
- Gồm 5 nhân viên với vai trò được phân chia xuyên suốt quá trình phát triển mềm:
+ Nguyễn Thanh Hiếu (1.5 năm kinh nghiệm) + Đỗ Công Lâm (1.5 năm kinh nghiệm) + Trương Quốc Thắng (2 năm kinh nghiệm) + Tống Khánh Linh (3 tháng kinh nghiệm) + Mai Quốc Bảo (3 tháng kinh nghiệm)
- Thời gian sử dụng nhân lực: Từ khi bắt đầu đến khi kết thúc hợp đồng
- Nguồn nhân lực:
Trang 25Kế hoạch dự án Trang 24
+ Nguyễn Thanh Hiếu: Tái ký hợp đồng 1 năm + Đỗ Công Lâm: Tái ký hợp đồng 1 năm + Trương Quốc Thắng: Tái ký hợp đồng 1 năm + Tống Khánh Linh: Ký hợp đồng mới 5 tháng + Mai Quốc Bảo: Ký hợp đồng mới 5 tháng
- Toàn bộ tài nguyên được sử dụng đều thuộc quyền sở hữu của công ty
- Các thành viên đều có kinh nghiệm làm việc nên cần đáp ứng mức lương tương xứng năng lực Số tiền thực hiện dự án bị giới hạn
3.2.3 Yêu cầu đào tạo nhân sự (nếu có)
- Tiến hành đào tạo để các nhân viên nhất quán trong quy trình làm việc và các quy tắc lập trình để tiện cho việc bảo hành, bảo trì sau này
- Loại hình đào tạo:
+ Làm việc theo mô hình Scrum
+ Quy trình xin nghỉ phép và làm việc OT
+ Sử dụng Clean Code
- Yêu cầu đạt được sau khóa học: Các nhân viên hiểu rõ quy trình làm việc
- Phương pháp đào tạo: Team leader trình bày thông qua docs trên google meet Hằng tuần họp team vào sau 1 sprint để đánh giá tiến độ và kiểm soát chất lượng quy trình làm việc
- Việc đào tạo là cần thiết trong việc kiểm soát chất lượng sản phẩm và mở rộng tính năng
• Có tinh thần trách nhiệm, tập trung vào những gì tốt nhất cho nhóm dự án
• Tránh đề cao cái tôi cá nhân, mang các vấn đề cá nhân vào công việc
Trang 26Kế hoạch dự án Trang 25
Quy tắc khi làm việc:
• Trung thực và cởi mở trong tất cả các hoạt động dự án
• Khuyến khích sự đa dạng các ý tưởng trong khi làm việc theo nhóm
• Làm việc bình đẳng
• Cởi mở với cách tiếp cận mới và xem xét những ý tưởng mới
• Tham gia đầy đủ các buổi họp nhóm, nếu vắng mặt phải có lý do chính đáng và phải tự cập nhật lại nội dung của buổi họp đầy đủ
• Tránh không hoàn thành công việc được giao, gây trễ tiến độ làm việc của các thành viên khác
Quy tắc trao đổi thông tin – Họp nhóm:
• Quyết định hình thức trao đổi thông tin và dự án: Họp online qua Google meet; nhắn tin trao đổi qua Trello; Lưu trữ các báo cáo, tệp tin, dự án qua Google Drive, GitHub, Trello
• Thống nhất thời gian họp nhóm sao cho có nhiều thành viên tham gia nhất
• Các thành viên có mặt đầy đủ theo lịch họp đã được thống nhất
• Luôn có thành viên ghi lại các biên bản cuộc họp
• Các thành viên phải chuẩn bị, tập hợp báo cáo nội dung, tiến độ công việc trước buổi họp
Quy tắc giải quyết vấn đề:
• Khuyến khích tất cả mọi người tham gia giải quyết các vấn đề
• Chỉ sử dụng những lời chỉ trích mang tính xây dựng và tập trung vào giải quyết vấn đề, không
đổ lỗi cho người khác
• Thống nhất ý tưởng của nhau và đưa ra một giải pháp thích hợp nhất
• Khi có tranh chấp hay bất đồng ý kiến phải tìm cách giải quyết thỏa đáng và hoà nhã nhất
Trang 27Người chịu trách nhiệm
nguyên
Chi phí (ngàn đồng)
quyết rủi ro và chốt yêu
Lâm, Hiếu, Thắng
26/11/2022 30/11/2022 Trello 250