Bài Tập Lớn Môn Quản Lý Dự Án: Xây Dựng Hệ Thống Nhà Sách

TRƯỜNG ĐẠI HỌC KINH TẾ QUỐC DÂN BÀI TẬP LỚN
MÔN QUẢN LÝ DỰ ÁN
Học viên thực hiện: Trần Bùi Thu Thủy
Mã học viên: CH301095 Lớp:
Quản lý Kinh tế và Chính sách
Hà Nội, tháng 10 năm 2022
XÂY DỰNG HỆ THỐNG QUẢN LÝ NHÀ SÁCH TIỀN PHONG I. Giới thiệu dự án 1.1 Thông tin dự án
- Tên Dự Án: Xây dựng hệ thống quản lý nhà sách Tiền Phong.
- Khách Hàng: nhà sách Tiền Phong
- Bên cung cấp sản phẩm: Công ty CP Giải pháp phần mềm Biplus Việt Nam 1.2 Phạm vi dự án
Hệ thống được thiết kế và xây dựng tốt có thể được nâng cấp, thay đổi phù hợp với nhiều nhà sách.
Khu vực ảnh hưởng trong nhà sách Tiền Phong: quầy thanh toán, nhóm quản lý
xuất nhập, quản lý trên mạng. Phạm vi dữ liệu:
- Dữ liệu về sách và thông tin giao dịch được giữ nguyên - Làm mới thông tin khác - Công nghệ thực hiện: - Java Application - SQL Server
- Ước lượng thời gian thực thi dự án : 4 tháng ( 18/10/2021 – 18/03/2022) tương
đương với 8 Sprint (Mỗi Sprint dài 2 tuần)
1.3 Sản phầm bàn giao cuối
- Phần mềm quản lý sách với đầy đủ chức năng yêu cầu
- Hệ thống cơ sở dữ liệu của dự án do khách hàng cung cấp - Mã nguồn chương trình - Tài liệu phát triển
1.4 Các bên liên quan Vai trò Họ tên Nhà tài trợ dự án Nhà sách Tiền Phong Khách hàng Nhà sách tiền phong
Công ty Cổ phần Giải pháp phần mềm BiPlus Việt Bên nhà thầu Nam
Đại diện: Bùi Xuân Hiền – Giám đốc
1.5 Tổng quan về dự án
Hiện nay công việc quản lý các đầu sách ở các nhà sách lớn nếu không có sự hỗ
trợ của công nghệ thông tin sẽ gặp rất nhiều khó khăn. Với số lượng các đầu sách lớn,
thường xuyên thay đổi cũng như cập nhật, bên cạnh đó số sách bán ra hàng ngày đều rất
lớn. Dự án của chúng tôi sẽ được triển khai trong phạm vi của nhà sách Tiền Phong, và
đối tượng tập trung là quản lý về thông tin các đầu sách trong nhà sách, cũng như danh
mục các đầu sách bán ra.
Các chức năng chính của hệ thống:
- Quản lý nhập-xuất sách
- Quản lý bán sách tại quầy - Quản lý khách hàng 1.6 Mục tiêu Mục tiêu doanh nghiệp
- Hỗ trợ công việc tính toán khi bán sách được nhanh và hiệu quả hơn.
- Quản lý sách nhập xuất trong mỗi nhà sách, tránh gian lận, sai thiếu trong việc
quản lý một số lượng lớn sách.
- Kết nối giữa các nhà sách Tiền Phong với nhau được thuận tiện
- Chương trình có giao diện dễ sử dụng, cài đặt với đầy đủ chức năng quản lý một
nhà sách cần và có thể bổ sung những chức năng mới khi nhà sách yêu cầu.
Mục tiêu về công nghệ
- Xây dựng một trang web mới để nhận gửi thông tin phản hồi với khách hàng.
- Di chuyển cơ sở hạ tầng công nghệ cũ trong vòng 1 ngày và không làm ảnh hưởng
tới quá trình buôn bán, quản lý của nhà sách.
- Đẩy nhanh tốc độ xử lý hiện tại lên 20%
1.7 Yêu cầu nghiệp vụ
- Dự án phần mềm phát triển ở đây là hệ thống quản lý bán sách nhà sách Tiền Phong.
- Người sử dụng phần mềm : Nhân viên quản lý nhà sách và nhân viên thu ngân.
- Mục đích của dự án là thiết kế chương trình quản lý bán sách dễ sử dụng, dễ cài
đặt, chương trình có nhiều tính năng linh hoạt như tìm kiếm thông tin sách theo
nhiều tùy chọn như chuyên nghành, tên sách, tác giả… cập nhật thêm các đầu sách
mới, tính tổng tiền mỗi hóa đơn sách một cách nhanh chóng và chính xác.
1.8 Thước đo thành công của dự án
- Tiết kiệm chi phí tổng thể >5%
- Giảm thời gian làm việc >15%
- Hệ thống hoạt động tốt với đầy đủ chức năng trong tuần chạy thử
- Tốc độ xử lý nhanh hơn hệ thống cũ >5%
1.9 Tổng quan về nội dung dự án
- Kỹ thuật và phương pháp phát triển dự án: theo Triết lý Agile
Khái niệm Agile (viết tắt của Agile Software Development) có nghĩa là phương
thức phát triển phần mềm linh hoạt, được ứng dụng trong quy trình phát triển phần mềm
với mục tiêu là đưa sản phẩm đến tay người dùng càng nhanh càng tốt.
Rất nhiều nơi định nghĩa Agile như một phương pháp. Thực chất, Agile giống như
một phương pháp luận, một triết lý dựa trên hơn nguyên tắc phân đoạn vòng lặp (iterative)
và tăng trưởng (incremental). Quy trình Agile hoàn chỉnh
Các giai đoạn phát triển của sản phẩm sẽ được chia nhỏ ra thành những phần tăng
trưởng cụ thể mà người dùng có thể tương tác được. Nhờ đó sản phẩm sẽ có được phản
hồi cần thiết để tránh khỏi những vấn đề nghiêm trọng và được cải tiến tốt hơn.
Thêm vào đó, quy trình quản lý sản phẩm có tính chất lặp lại này còn giúp cho cả
nhóm có thể chuyển sang một phần tăng trưởng khác trong khi những vấn đề của phần
tăng trưởng hiện tại đang được giải quyết.
- Khung tổ chức công việc: Scrum team
Phương pháp quản lý Scrum là một Framework về quy trình và quản lý, giúp
giải quyết các vấn đề phức tạp. Phương pháp này đảm bảo tính hiệu quả, sáng tạo và sản
phẩm được tạo ra phải đạt được giá trị cao nhất. Bản thân Scrum là một Framework đơn
giản, nhằm giúp việc phối hợp hiệu quả nhất giữa các thành viên trong đội phát triển, khi
thực hiện những sản phẩm phức tạp.
Với phương pháp quản lý Scrum, sản phẩm được xây dựng trên 1 chuỗi các quy
trình lặp lại (gọi là Sprint). Các sprint diễn ra đều đặn, mỗi một sprint là cơ hội để học hỏi
điều chỉnh nhằm đạt được sự phù hợp và kết quả tốt nhất.
Khi áp dụng Scrum, có 4 cuộc họp (Meetings or Ceremonies) quan trọng tạo nên cấu trúc trong mỗi Sprint như sau:
Sprint planning: Cuộc họp lên kế hoạch của đội dự án, nhằm xác định những gì cần hoàn
thành trong Spring sắp tới.
Daily stand-up: Cũng được biết đến như “Daily Scrum”, một cuộc họp nhỏ 15 phút mỗi
ngày để trao đổi công việc giữa đội phát triển.
Sprint demo: Một cuộc họp chia sẻ, nơi mà các thành viên chỉ ra những gì họ đã làm được trong Sprint đó.
Sprint retrospective: Sự đánh giá, nhìn lại những điều đã làm được và chưa làm được của
Sprint hiện tại, và đưa ra giải pháp hành động cho Sprint tiếp theo được tốt và hoàn thiện hơn. - Tài nguyên sử dụng
- Kinh phí đầu tư: 800.000.000 VNĐ bao gồm:
• Lương nhân viên tham gia
• Tiền thuê cơ sở vật chất • Các chi phí phát sinh • Dữ trữ 10%
• Số thành viên tham gia dự án: 9 người. - Công cụ thực hiện:
• Trọn bộ Microsoft office: lập kế hoạch dự án
• Eclipse : Cài đặt chương trình
• Visual Paradigm: Phân tích, thiết kế, vẽ biểu đồ trong chương trình
• SQL Server: Lưu trữ CSDL
- Kỹ thuật sử dụng trong dự án • J2EE • SQL II.
Quản lý nhân sự dự án
2.1 Lập kế hoạch nhân sự
Dự án xây dựng phần mềm này được vận hành theo Scrum. Scrum - phương pháp
phổ biến nhất của Agile - là một framework cơ bản giúp việc tiếp cận, phát triển công
việc/sản phẩm phức tạp một cách nhanh nhất, hiệu quả nhất. Theo kinh nghiệm thu được
trong quá trình triển khai dự án với Scrum, để cho Scrum đạt được hiệu quả cao nhất thì
nên tổ chức các team có ít nhất 3 người và tối đa 9 người (với những nhóm lớn, có thể
chia thành những nhóm Scrum nhỏ hơn - Scrum of Scrums - sẽ được giới thiệu trong 1 bài viết khác).
Scrum bao gồm một tập các phương pháp thực hành (practices), vai trò (roles), sự
kiện (events), tạo tác (artifacts) và quy tắc (rules) được thiết kế để làm “kim chỉ nam” cho team thực hiện dự án.
Những vai trò trong Scrum Team
Mỗi Scrum team sẽ có ba vai trò tương ứng với trách nhiệm, quyền hạn rõ ràng giúp
cho công việc được tối ưu hóa. Ba vai trò của Scrum team bao gồm: Development
Team, Product Owner và Scrum Master. Và khi ba bộ phận này kết hợp với nhau chúng
ta sẽ có được toàn bộ Scrum team. 1. Development Team
Là những thành viên cùng tham gia trực tiếp vào quá trình phát triển những tính năng cụ
thể của phần mềm/sản phẩm.
Các thành viên của Development Team tự tổ chức - nghĩa là họ được trao quyền để quản
lý công việc của chính họ. Scrum cũng khuyến khích mỗi thành viên đều “đa di năng”, có
thể đảm nhiệm nhiều hơn một vai trò nhất định miễn là cần thiết để hoàn thành công việc,
chẳng hạn như phân tích, thiết kế, xây dựng, kiểm thử phần mềm/sản phẩm. Yêu cầu vị trí
Business Analysis - Nhà phân tích nghiệp vụ kinh doanh
Mô tả công việc :
- Trực tiếp làm việc với khách hàng để lấy yêu cầu về nghiệp vụ cần xây dựng cho hệ thống phần mềm
- Trao đổi với giám đốc dự án về yêu cầu của khách hàng, độ khả thi của các yêu cầu
- Trao đổi yêu cầu nghiệp vụ với nhóm dự án để xây dựng các chức năng tương ứng
- Giám sát quá trình xây dựng chức năng để đảm bảo các module được xây dựng
phù hợp với yêu cầu khách hàng đưa ra
- Trực tiếp làm việc với khách hàng trong qua trình xây dựng giao diện phần mềm,
lấy các yêu cầu về giao diện của khách hàng đưa ra Yêu cầu khả năng :
- Có khả năng giao tiếp tốt, biết truyền đạt thông tin
- Biết lập trình cơ bản, có hiểu biết về quá trình xây dựng hệ thống thông tin
- Có thẩm mỹ cao, sáng tạo tốt trong xây dựng giao diện cảm quan
- Tốt nghiệp đại học chuyên ngành công nghệ thông tin
QA - Quality Assurance (Quản lý chất lượng)
Mô tả công việc :
- Chịu trách nhiệm quản lý dự án
- Chịu trách nhiệm quản lý nhóm dự án
- Kiểm tra chất lượng công việc được hoàn thành của nhóm dự án
- Đưa ra các báo cáo về quá trình phát triển dự án cho giám đốc dự án
- Đưa ra các gợi ý trong việc xây dựng phần mềm, các quyết định về phương pháp
phát triển phần mềm áp dụng. Yêu cầu khă năng :
- Có khả năng giao tiếp, truyền đạt thông tin tốt.
- Nhiều năm kinh nghiệm trong lập trình, phát triển phần mềm (tối thiểu 5 năm)
- Có kinh nghiệm trong việc đảm bảo chất lượng dự án (tối thiểu 2 năm trong nhóm
QA, 1 năm ở vị trí quản lý QA)
- Tốt nghiệp đại học chuyên ngành công nghệ thông tin
Người thiết kế giao diện
Mô tả công việc :
- Trao đổi với nhà phân tích nghiệp vụ kinh doanh
- Đưa ra các quyết định trong việc xây dựng giao diện cảm nhận dựa trên yêu cầu khách hàng tươn ứng
- Trao đổi với lập trình viên trong quá trình xây dựng giao diện
- Đảm bảo việc xây dựng chức năng của lập trình viên phù hợp với giao diện cảm quan đưa ra Yêu cầu khả năng :
- Có khả năng giao tiếp, truyền đạt thông tin tốt
- Có khả năng lập trình tốt (2 năm kinh nghiệm)
- Có kinh nghiệm trong xây dựng giao diện người dùng
- Có thẩm mỹ tốt, sáng tạo
- Tốt nghiệp đại học, cao đẳng chuyên ngành công nghệ thông tin
Người quản trị cơ sở dữ liệu
Mô tả công việc :
- Trao đổi với nhà phân tích nghiệp vụ kinh doanh
- Thiết kế mô hình cơ sở dữ liệu
- Lập tình cở sở dữ liệu
- Trao đổi với các lập trình viên trong quá trình xây dựng cơ sở dữ liệu. Yêu cầu khả năng :
- Có khả năng giao tiếp, truyền đạt thông tin tốt.
- Có khả năng lập trình tốt (2 năm kinh nghiệm)
- Có kinh nghiệm xây dựng cơ sở dữ liệu.
- Tốt nghiệp đại học, cao đẳng chuyên ngành công nghệ thông tin. Lập trình viên
Mô tả công việc :
- Tiếp nhận các công việc từ cấp trên
- Lập trình các module chức năng của phần mềm
- Trao đổi với các thành viên trong nhóm trong quá trình xây dựng - Yêu cầu khả năng : - Biết lập trình
- Có khả năng tiếp thu tốt
- Chăm chỉ với công việc, có trách nhiệm với công việc của mình
- Tốt nghiệp đại học, cao đăng, trung cấp chuyên ngành công nghệ thông tin. 2. Product Owner
Giúp nhóm hiểu được nhu cầu của khách hàng/người dùng, từ đó nhóm có thể xây
dựng sản phẩm/phần mềm có giá trị nhất.
Product Owner chịu trách nhiệm tối đa hóa giá trị của sản phẩm/phần mềm bằng
cách quản lý Product Backlog hoặc danh sách công việc cần thực hiện. Điều này bao gồm
việc đảm bảo các mục con trong product backlog (backlog items) được cập nhật liên tục
và sắp xếp theo mức độ ưu tiên, giúp cho các thành viên trong nhóm hiểu được các tính
năng, yêu cầu được liệt kê trong Product Backlog và tại sao người dùng cần chúng. Đây
là một công việc thực sự quan trọng vì nó giúp nhóm xây dựng sản phẩm/phần mềm giá trị nhất có thể.
Product Owner cũng chịu trách nhiệm đảm bảo rằng khách hàng/người dùng và
nhóm có sự hiểu biết chung về tầm nhìn dự án, mục tiêu dự án và chi tiết công việc sẽ
được thực hiện, để nhóm có thể lập kế hoạch và xây dựng các hạng mục công việc một
cách hiệu quả. Mặc dù Product Owner chịu trách nhiệm cuối cùng trong việc sắp xếp
mức độ ưu tiên và cập nhật Backlog items, nhưng Scrum Master hoặc Development Team
cũng phải hỗ trợ quá trình này bằng cách chia sẻ thông tin về ước lượng (thời gian, chi
phí, nguồn lực), tính phụ thuộc, các mục công việc kỹ thuật, v.v.
3. Scrum Master: chịu trách nhiệm giúp nhóm hiểu và sử dụng Scrum hiệu quả
Scrum mô tả có thể đơn giản, nhưng không phải lúc nào cũng dễ dàng để hiểu
đúng. Đó là lý do tại sao trong một nhóm cần có Scrum Master - người nắm toàn bộ
công việc từ việc lên kế hoạch, phân công công việc, tổ chức các cuộc họp giúp Product
Owner, Development Team và phần còn lại của công ty thực hiện Scrum một cách chính xác, hiệu quả nhất.
Điều này có nghĩa là người trong vai trò này dành toàn bộ thời gian của mình để
giúp đỡ (hoặc “phục vụ”) cho Product Owner, Development Team và mọi người trong
toàn tổ chức, giúp loại bỏ bất kỳ trở ngại nào đối với quá trình thực hiện và tạo điều kiện
thuận lợi nhất cho họ, bao gồm:
- Giúp Product Owner tìm ra các cách hiệu quả để quản lý Backlog.
- Truyền đạt tầm nhìn dự án, mục tiêu dự án và chi tiết Backlog items cho
Development Team, giúp Development Team hiểu các hoạt động đặc thù của
Scrum và thực hiện chúng nếu cần.
- Giúp phần còn lại của tổ chức hiểu Scrum và phối hợp tốt với nhóm.
- Tạo điều kiện cho việc áp dụng Scrum không chỉ trong một dự án mà trên phạm vi
rộng hơn là trong toàn tổ chức.
2.2 Xây dựng nhân sự dự án Vai trò Trách nhiệm Số lượng
Quản lý toàn bộ hoạt động của Product Owner 1 nhóm dự án
Phân công công việc, tổ chức
các cuộc họp Team thực hiện Scrum master 1
Scrum một cách chính xác, hiệu quả nhất.
Nhà phân tích nghiệp Thu thập yêu cầu nghiệp vụ từ 1 vụ kinh doanh khách hàng Kĩ sư đảm bảo chất
Đảm bảo chất lượng công việc 1 lượng trong suốt dự án
Người thiết kế giao Xây dựng giao diện cảm quan 1 diện cho hệ thống
Thiết kế, xây dựng hệ thống Cơ Người quản trị CSDL 1 sở dữ liệu Lập trình viên
Cài đặt, tích hợp các module 3 Tổng 9
2.3 Phát triển đội dự án
Scum master là người có nhiệm vụ điều phối, tổ chức để chắc chắn các thành viên
trong nhóm dự án thực hành Scrum một cách chính xác, hiệu quả nhất.
Scrum hoạt động dựa trên ba giá trị cốt lõi, còn gọi là Ba chân của Scrum bao gồm
Minh bạch, Thanh tra và Thích nghi.
- Minh bạch (transparency): Trong Scrum, tính minh bạch được đề cao như là giá
trị cốt lõi cơ bản nhất. Muốn thành công với Scrum, thông tin liên quan tới quá
trình phát triển phải minh bạch và thông suốt. Các thông tin đó có thể là: tầm nhìn
(vision) về sản phẩm, yêu cầu khách hàng, tiến độ công việc, các khúc mắc và rào
cản v.v. Từ đó mọi người ở các vai trò các nhau có đủ thông tin cần thiết để tiến
hành các quyết định có giá trị để nâng cao hiệu quả công việc. Các công cụ và
cuộc họp trong Scrum luôn đảm bảo thông tin được minh bạch cho các bên.
- Thanh tra (inspection): Công tác thanh tra liên tục các hoạt động trong Scrum
đảm bảo cho việc phát lộ các vấn đề cũng như giải pháp để thông tin đa dạng và
hữu ích đến được với các bên tham gia dự án. Truy xét kĩ càng và liên tục là cơ
chế khởi đầu cho việc thích nghi và các cải tiến liên tục trong Scrum.
- Thích nghi (adaptation): Scrum rất linh hoạt như các phương pháp phát triển linh
hoạt (agile software development) khác. Nhờ đó nó mang lại tính thích nghi rất
cao. Dựa trên các thông tin minh bạch hóa từ các quá trình thanh tra và làm việc,
Scrum có thể phản hồi lại các thay đổi một cách tích cực, nhờ đó mang lại thành công cho dự án.
Trong một nhóm Scrum, có ít nhất ba bên được phép chỉ định xử lý công việc: PO,
Scrum Master và nhóm phát triển. Mỗi bên bị ràng buộc bởi về trách nhiệm riêng biệt và
họ phải làm việc cùng nhau để đạt được một sự cân bằng giữa yêu cầu và sản phẩm cuối.
Nhóm Scrum bắt buộc là nhóm liên chức năng, hay nói cách khác nhóm Scrum phải có
tất cả các nguồn lực cần thiết để hoàn thành công việc.
Trên một bảng Scrum, các cột được dán nhãn để phản ánh các giai đoạn của dòng
chảy công việc. Các task lần lượt theo thứ tự, làm tất cả mọi việc mỗi sprint trong một vài
tuần (khoảng thời gian thông thường cho sprint) và chuyển chúng sang trạng thái hoàn
thành (cột Done) và cuối cùng sẽ xử lý hết những sprint còn ở trạng thái chờ.
Để thực hiện được điều này một cách dễ dàng, team sử dụng các công cụ quản lý dự án như:
- Trello: Đây là một trong những ứng dụng quản lý dự án nổi tiếng và được sử dụng
nhiều nhất. Nó có cả tài khoản miễn phí và cao cấp mang đến cho bạn cơ hội tuyệt
vời để sử dụng hầu hết các chức năng phổ biến.
Cấu trúc của Trello dựa trên phương pháp kanban. Tất cả các dự án được đại diện bởi
các bảng, có chứa danh sách. Mọi danh sách đều có các thẻ lũy tiến mà bạn được tạo dưới
dạng kéo và thả. Người dùng có liên quan đến bảng, có thể được gán cho thẻ. -​
- Jira: JIRA là một công cụ được phát triển để theo dõi lỗi, theo dõi vấn đề và quản
lý dự án cho các quy trình phát triển phần mềm và di động. Bảng điều khiển JIRA
có nhiều chức năng & tính năng hữu ích có thể xử lý các vấn đề khác nhau một cách dễ dàng.
Các cuộc họp là rất quan trọng trong việc phát triển đội dự án cũng như trong quá
trình phát triển dự án. Các cuộc họp đó bao gồm:
- Sprint Planning Meeting (Họp kế hoạch Sprint): Được thực hiện đầu mỗi Sprint,
trong Sprint Planning Meetings, mọi người sẽ quyết định lựa chọn những tính
năng cần thực hiện, phân công công việc, phân rã những tính năng đó thành các
nhiệm vụ (tasks) và lên kế hoạch xem công việc đó sẽ được thực hiện như thế nào trong Sprint này.
Product Owner sẽ cập nhật Backlog items và nhóm (Development Team + Scrum
Master) sẽ thảo luận để đảm bảo tất cả mọi người cùng hiểu đúng về mục công việc đó.
Dựa trên ước tính, hiệu suất dự kiến và hiệu suất trong quá khứ, Development
team sẽ dự đoán được khối lượng công việc có thể hoàn thành trong Sprint và từ
đó sẽ xác định mục tiêu của Sprint - Sprint goal. Sau đó, Development team xác
định cách xây dựng các chức năng cho sản phẩm/phần mềm và cách họ sẽ thực
hiện để hoàn thành Sprint goal.
Sprint Planning Meetings sẽ có timeboxed thường là 2 - 4 tiếng. Cả nhóm sẽ tập
trung phân rã, lập kế hoạch công việc cho ít nhất 1 tuần đầu của Sprint.
- Daily Scrum and Sprint Execution (Họp hằng ngày)
Là cuộc họp có timeboxed thường kéo dài khoảng 15 phút, diễn ra mỗi ngày giúp
nhóm hướng tới Sprint goal. Scrum Master đảm bảo cuộc họp diễn ra hàng ngày
và theo dõi các trở ngại được xác định được trong cuộc họp. Daily Scrum chủ yếu
dành cho các thành viên của Development team để đồng bộ hóa công việc và báo
cáo bất kỳ những vấn đề, vướng mắc mà họ đang gặp phải. Phạm vi của cuộc họp
này được giới hạn nghiêm ngặt, mỗi thành viên trong nhóm trả lời ngắn gọn ba
câu hỏi về những gì họ đang làm để đáp ứng Sprint goal:
▶ Tính từ thời điểm kết thúc cuộc họp Daily cuối cùng đến nay bạn đã làm gì?
▶ Bạn dự định sẽ làm gì hôm nay?
▶ Có những cản trở, khó khăn nào trong quá trình thực hiện của bạn không
- Sprint Review Meeting (Họp sơ kết)
- Sprint Retrospective Meeting (Họp cải tiến Sprint)
Với 2 cuộc họp cuối, em sẽ trình bày cụ thể ở phần 2.4
2.4 Điều chỉnh hoạt động dự án:
Sẽ có rất nhiều Sprint trong dự án, vì vậy kết thúc của 1 Sprint sẽ là thời gian cho
Review và Retrspective, để nhân sự có thể đánh giá lại quá trình và hiệu quả làm việc của mình
- Sprint Review Meeting (Họp sơ kết)
Sprint Review meeting được tổ chức vào cuối Sprint với sự tham gia gồm
Development team, Product Owner và Scrum Master (và các bên liên quan khác).
Trong cuộc họp này, nhóm sẽ giới thiệu về những tính năng mà họ đã xây dựng
trong Sprint cho Product Owner. Product Owner sẽ kiểm tra công việc để xem liệu
là sản phẩm/phần mềm có thật sự hoạt động tốt và được chấp nhận hay không.
Nhóm và Product Owner thảo luận về phần gia tăng tính năng này và các mục còn
lại trong Product Backlog, sẽ cùng nhau thực hiện những thay đổi cần thiết cho Backlog.
- Sprint Retrospective Meeting (Họp cải tiến Sprint)
Được diễn ra sau Sprint Review nhưng trước Sprint Planning meeting tiếp theo.
Nội dung cuộc họp có thể bàn về bất kỳ điều gì đã xảy ra trong Sprint vừa qua,
bao gồm các vấn đề về con người, quy trình và sản phẩm. Các thành viên trong
nhóm khám phá những bài học kinh nghiệm tốt, những điều làm chưa tốt, tìm
kiếm cơ hội để cải thiện và quyết định những thay đổi nào sẽ được thực hiện trong Sprint tiếp theo.
3.1 Nhận diện rủi ro Category Description ID
• Yêu cầu của khách hàng không đặc tả được chức 1.1 năng hệ thống.
• Quy trình sử dụng sai so với yêu cầu khách hàng 1.2 Khách
• Quá nhiều yêu cầu thay đổi của khách hàng 1.3 hàng
• Yêu cầu của khách hàng vượt quá khả năng của dự 1.4
án phát triển (về chi phí, nhân lực,công nghệ)
• Sử dụng mô hình phát triển phần mềm mới 2.1
• Có thể sử dụng công nghệ không phù hợp với dự 2.2 Phát triển án
• Thời gian phát triển dự án quá lâu so với dự kiến 2.3
• Thị trường có sự đổi mới đột ngột về công nghệ 3.1
• Chi phí việc duy trì ,triển khai hệ thống quá cao 3.2
Lợi nhuận • Khả năng cạnh tranh của các hệ thống quản lý nhà 3.3
sách đã có trên thị trường
• Chi phí cho dự án vượt quá ngân sách 4.1
• Xuất hiện những chi phí không thống kê được 4.2 Ngân sách trong dự án
(chi phí giao tiếp, tìm hiểu yêu cầu ngoài luồng)
• Người quản lý không có kĩ năng phù hợp với dự án 5.1
• 1 số programmer không có khả năng làm việc 5.2 nhóm tốt Nhân lực
• Sự ra đi của 1 số thành viên chủ chốt 5.3
• Thiếu những thành viên có kĩ năng tương ứng với 5.4 công nghệ
• Xảy ra bất đồng giữa các thành viên trong dự án
• Thiếu các công cụ phát triển lập trình 6.1
• Mất mát về tài nguyên vật chất 6.2
Tài nguyên • Sự cố mất internet, cắt điện luân phiên 6.3
• Vấn đề bản quyền phần mềm 6.4
3.2 Risk Analyze (Phân tích rủi ro)
3.2.1 Likelihood (Khả năng xảy ra rủi ro)
Bảng dưới đây mô tả tỉ lệ khả năng xảy ra của các rủi ro trong dự án : Title Rate Description
Rủi ro khả năng xảy ra rất thấp và sẽ được ghi lại Very Low 20 nhưng không theo dõi
Rủi ro ít khả năng xảy ra nhưng vẫn sẽ được theo dõi Low 40 trong suốt dự án Medium 60
Rủi ro có thể xảy ra rõ ràng trong dự án
Rủi ro rất có khả năng xảy ra đặc biệt trong các hoàn High 80 cảnh của dự án
Rủi ro có thể tỉ lệ xảy ra rất cao, trong các trường hợp Very High 100
của dự án nếu có rủi ro này thì chắc chắn xảy ra
3.2.2 Impact (Mức độ ảnh hưởng của các rủi ro)
Bảng dưới đây mô tả tỉ lệ tác động của các rủi ro trong dự án : Title Rate Description Very Low 20
Rủi ro không có ý nghĩa lắm trong dự án
Rủi ro có tác động nhỏ trong dự án ( < 5% chệch hướng Low 40
dự án như ngày kết thúc , chi phí dự án , … )
Rủi ro có tác động từ 5% - 10% làm chệch hướng dự án Medium 60
Rủi ro có tác động từ 10% - 25% làm chệch hướng dự High 80 án
Rủi ro có tác động lớn từ 25% trở lên làm chệch hướng Very High 100 dự án
3.2.3 Mức ưu tiên giữa các rủi ro
Bảng dưới đây mô tả sự ưu tiên của các rủi ro bên trên trong dự án theo công thức :
Priority = (Likelihood + Impact)/2 ID Likelihood Impact Priority Score Rating 1.1 60 100 80 High 1.2 40 100 70 High 1.3 20 80 50 Medium 1.4 40 40 40 Medium 2.1 100 80 90 Very High 2.2 20 40 30 Low 2.3 60 60 60 Medium 3.1 80 100 90 Very High 3.2 100 60 80 High 3.3 80 100 90 Very High 4.1 40 80 60 Medium 4.2 20 80 40 Low 5.1 40 100 70 High 5.2 80 80 80 High 5.3 40 100 60 Medium 5.4 60 60 60 Medium 6.1 20 60 40 Low 6.2 20 40 30 Low 6.3 40 40 40 Medium 6.4 20 20 20 Low
3.2.4 Kế hoạch xử lý các rủi ro (Xử lý theo các mức ưu tiên) Rating ID Action Reduced Action Reduced Impact Action Likelihood Resource Very 2.1
Cần có người quản lý giám Project High
sát bảo đảm các nhóm làm Manager
việc thực hiển đúng theo
mô hình mới.Đảm bảo vấn
đề chuyển giao, tích hợp trong mô hình mới Very
3.1 Luôn cập nhật Khi có sự thay đổi công Project High
mọi thông tin về nghệ , hoặc rút ngắn thời Manager,
công nghệ và đưa gian hoàn thiện dự án hoặc Developer
ra các dự đoán chuyển qua công nghệ mới trước Very 3.3
Tổ chức hội thảo cho phía Project High
khách hàng biết được Manager những tính năng mà các
chương trình quản lý nhà
sách khác không có được High
1.1 Yêu cầu phía Thực hiện những buổi nói All member
khách hàng có chuyện thường xuyên hơn
những người am với khách hàng hiểu về hệ thống để đưa ra các yêu cầu cụ thể hơn High
3.2 Áp dụng các kỹ Cắt giảm 1 số server không Quality
thuật mới , yêu cần thiết trong việc duy trì Manager
cầu vấn để kiểm hệ thống thử sản phẩm kỹ nhằm giảm dung lượng hệ thống High
5.2 Yêu cầu khi chọn Cần tổ chức training
thành viên cho dự phương pháp làm việc
án cần những nhóm cho các thành viên
người có khả năng mới, chưa quen vơi phong
làm việc theo cách làm việc nhóm nhóm High
1.2 Nhóm phân tích Nhanh chóng ra review lại
yêu cầu trong pha yêu cầu nhằm so sánh với
kế hoạch phải làm yêu cầu khách hàng chính xác High 5.1 Chỉ xét tuyển các PMer có kỹ năng phù hợp với dự án, lựa chọn tối ưu trong nhiều PM
Medium 2.3 Hạn chế các sự Thường xuyên kiểm tra ,
thay đổi về nhân thúc đẩy tiến độ làm việc,
sự , địa điểm làm triển khai các mốc để làm việc , …
việc.Thực hiện việc khen
thưởng thúc đẩy làm việc nhân viên
Medium 4.1 Gặp gỡ trao đổi Tăng giá thành sản phẩm
với đối tác nhằm lên mức độ phù hợp với chi
đạt được một mức phí bỏ ra kinh phí hợp lý. Xác định rõ việc phân chia kinh phí hợp lý, đầu tư đúng mức
Medium 5.3 Cần có chế độ đãi Có các nhân viên khác dự
ngộ hợp lý. Trả phòng cho tình huống xấu lương xứng đáng nhất cho những người đóng vai trò quan trọng trong quá trình dự án phát triển Medium 5.4
Tiến hành giải quyết các vấn đề mâu thuẫn trong
nhóm để đảm bảo tiến độ
dự án được thuận lợi
Medium 1.3 Tư vấn đầy đủ Thiết kế mỗi lần yêu cầu thông tin
cho của khách hàng thành các
khách hàng, tránh module riêng biệt trường hợp khách hàng thay đổi yêu cầu. Đồng thời có những ràng buộc chắc chắn với khách hàng về điều khoản thay đổi yêu cầu Medium 6.3
Nếu sự cố mất điện luân
phiên, thì có thể phải triển
khai làm thêm giờ hoặc bù
giờ những lúc có điện hoặc có internet Low 2.2 Nghiên cứu giữa chi phí và lợi ích của công nghệ đó so với dự án của mình Low
6.4 Mua phần mềm Khi Cty chưa kịp mua bản
bản quyền cần quyền, thì tạm thời dùng
thiết khi triển khai các freeware hoặc bẻ khóa dự án
nếu thấy cần thiết trong thời gian tạm thời.