Trường Đại học Kinh tế Đà Nẵng

Khoa Thống kê Tin học

Bài giảng

Thực hành Quản trị dự án

Công nghệ thông tin
Software Project Management – Practice

Giảng viên: Nguyễn Huỳnh Thiện, PMP®, MS

(Lưu hành nội bộ)

07/2023
Giới thiệu môn học
• Mục tiêu: Thực hành các kiến thức lý thuyết đã học trong môn học
Quản trị dự án CNTT, chú trọng vào các kĩ năng:
• Quản lý phạm vi dự án
• Lập kế hoạch dự án
• Quản lý thời gian
• Quản lý tài nguyên dự án (chủ yếu tập trung vào quản lý tài liệu, source code)
• Làm việc nhóm
Kế hoạch môn học
• Dựa trên Đề cương môn học của Khoa
Thống kê Tin học:
• SCRUM: Khái niệm, quy trình, tài liệu, công cụ
(Jira, Confluence)
• Lên ý tưởng dự án
• Phân tích yêu cầu dự án, tạo Backlog và ước
lượng
• Thiết kế kiến trúc hệ thống và phần mềm
• Xây dựng môi trường phát triển phần mềm:
IDE, quản lý phiên bản (Git), kho lưu trữ
(Github),…
• Báo cáo dự án và đánh giá kết quả học tập
Phương thức đánh giá
• Học và làm bài tập theo nhóm và theo cá
nhân
• Các nhóm lên ý tưởng dự án và thực hiện
các công việc quản lý dự án, xây dựng tài
liệu, báo cáo, thực hiện task...
• Giảng viên sẽ phản biện các tài liệu, kế
hoạch, báo cáo…
• Điểm thành phần:
• Thành phần 1: Đi học đầy đủ 10% (cá nhân)
• Thành phần 2: Thực hiện đúng bài tập thực
hành trên lớp 30% (nhóm)
• Thành phần 3: Báo cáo cuối kỳ, gồm
• 3.1: Báo cáo dự án 20% (nhóm)
• 3.2: Báo cáo thực hành 40% (cá nhân)
Tài liệu tham khảo
1. Agile Practice Guide, Project Management Institute (2017)
2. A Guide to the Project Management Body of Knowledge 6th edition
(PMBOK® Guide), Project Management Institute (2017)
3. A Guide to the Project Management Body of Knowledge 7th edition
(PMBOK® Guide), Project Management Institute (2021)
4. The Scrum Guide, Ken Schwaber & Jeff Sutherland (2020)
5. viblo.asia, atoha.com, pma.edu.vn, hocvienagile.com
Làm chủ các khái niệm!
• Khi gặp các khái niệm mới hãy hiểu và nhớ
chúng
• Không nắm được các khái niệm đồng nghĩa với
mất căn bản
 Sơ lược về Agile
• Agile thực chất là một triết lý hay một khung
tư duy để nhanh chóng thích ứng và phản
hồi với thay đổi, từ đó đạt được thành công
trong một môi trường liên tục biến động và
không chắc chắn.
• Tuyên ngôn Agile
• Cá nhân và sự tương tác hơn là quy trình và
công cụ
• Phần mềm chạy tốt hơn là tài liệu đầy đủ
• Cộng tác với khách hàng hơn là đàm phán hợp
đồng
• Phản hồi với sự thay đổi hơn là bám theo kế
hoạch
Mặc dù các điều bên phải vẫn còn giá trị, nhưng
chúng tôi đánh giá cao hơn các mục ở bên trái.
Giới thiệu về SCRUM
• SCRUM là gì?
• Scrum là một khung làm việc (framework) cho các quy trình
quản lý dự án, bản thân Scrum không phải là một quy trình
(process). Scrum là một khung làm việc trong họ Agile
• Giúp phát hành (release) sản phẩm sớm và thường xuyên
• Làm mới sản phẩm liên tục
• Là một phương pháp phát triển lặp lại (iterative) và tăng
trưởng (incremental)
• 3 trụ cột của Scrum : TIA
• Transparency (Minh bạch): không giấu thông tin, kể cả tin
tốt lẫn tin xấu
• Inspection (Kiểm tra): kiểm tra suốt quá trình làm việc
• Adaptation (Thích nghi): thích ứng với sự thay đổi liên tục
Các vai trò trong nhóm Scrum
• Product Owner: quyết định các tính năng của sản phẩm, đánh
giá và sắp xếp độ ưu tiên của Backlog
• Scrum Master: phục vụ nhóm Scrum làm việc hiệu quả, quản
lý các quy trình của nhóm (không quản lý người). Là vị trí gần
giống với người quản lý dự án nhất
• Development Team: đội ngũ trực tiếp làm ra sản phẩm (lập
trình viên, tester,…)
• Không cho phép các vai trò khác
• Scrum Master có thể là Dev
• Không có vị trí Project Manager truyền thống thực thụ trong
mô hình Scrum, công việc của Project Manager được chia sẻ
khắp các vị trí trong Scrum
• Trên thực tế, các doanh nghiệp sẽ tự xây dựng một mô hình
nhóm làm việc riêng phù hợp với hoạt động của mình
Các vai trò trong nhóm Scrum (tt)
• Nhóm làm việc Agile nên có từ 3-9 thành viên,
cùng làm việc trong một văn phòng, và được
phân bổ 100% thời gian cho team
• Product Owner là người duy nhất có thể nói
cho Dev team biết cần phải chuyển giao cái gì
cho khách hàng
• Scrum Master là người phục vụ cho nhóm, gỡ
bỏ chướng ngại cho nhóm, là người thay mặt
nhóm để giao tiếp với bên ngoài và bảo vệ
nhóm khỏi bên ngoài
• Cả Dev team chịu trách nhiệm cho sản phẩm
chung (không phải từng cá nhân chịu trách
nhiệm cho phần của mình)
Hai đặc điểm của Nhóm Scrum
• Tự quản (self-managing): còn gọi là tự tổ
chức (self-organized), nhóm sẽ cùng ra
quyết định sẽ làm gì, ai sẽ làm và làm
như thế nào mà không bị sự chỉ đạo bởi
ai đó bên ngoài nhóm.
• Liên chức năng (cross-functional): gồm
nhiều cá nhân với các chuyên môn khác
nhau đủ năng lực được kết hợp lại cùng
làm việc hướng tới một mục tiêu chung
Chuẩn bị trước khi bắt đầu Sprint
• Sprint: một vòng lặp trong quá trình phát triển sản phẩm,
thường kéo dài 4-6 tuần
• Product Roadmap: lộ trình sản phẩm, thể hiện các tính năng
chính cần được chuyển giao, do Product Owner phụ trách
• Các User Story: là một cách trình bày yêu cầu của sản phẩm,
được tạo ra bởi Product Owner
• Product Backlog: danh sách các Story được sắp xếp thứ tự ưu
tiên
• Backlog refinement – Product owner và dev team rà soát, sắp
xếp các hạng mục trong backlog
 Chạy Sprint
• Gồm có 4 quy trình (hoạt động) chính:
• Sprint Planning – Lập kế hoạch cho Sprint
• Daily Scrum – Họp Scrum hằng ngày, còn
được gọi là Daily Standup, Standup
Meeting
• Sprint Review – Review lại sản phẩm của
Sprint đã làm được, trình bày (demo) sản
phẩm cho các bên liên quan
• Sprint Retrospective – Họp rút kinh
nghiệm
• Một khi Sprint được bắt đầu, Sprint
Backlog sẽ không được phép thay đổi
Sprint Planning
• Sprint Planning – Họp lập kế hoạch Sprint
• Thường diễn ra trong 8h đối với Sprint dài 4 tuần
• Thành phần tham gia: toàn bộ nhóm Scrum
• Mục tiêu: Xác định năng lực của nhóm, xác định mục
tiêu của Sprint (đầu ra), các định nghĩa hoàn thành
(DoD – Definition of Done), Sprint Backlog
• Sprint Backlog là danh sách các Story cần phải được
thực hiện trong Sprint, được lấy ra từ Product Backlog,
thường lấy những Story quan trọng làm trước (các
story nằm ở đầu danh sách Product Backlog)
• Dev team không cần đợi Product Backlog hoàn chỉnh
mà chỉ cần đủ số lượng story cần thiết là có thể triển
khai Sprint
• Không chốt được DoD thì không làm!
 Bảng Kanban
• Do Toyota phát triển
• Story cần làm sẽ ở trong cột To Do
• Dev kéo các Story đang thực hiện vào
Doing
• Khi hoàn thành sẽ kéo Story vào Done
• Mục Doing thường sẽ được giới hạn số
lượng
• Có thể có các biến thể 4-5 cột tuỳ dự án
(VD: To Do – Doing – Testing – Done)
• Phần mềm Jira có hỗ trợ sẵn bảng Kanban
để quản lý task
Daily Scrum (Daily Standup, Standup Meeting)
• Là cuộc họp kéo dài 15 phút hằng ngày, để thanh tra công
việc của các thành viên và dự tính công việc cho ngày tiếp
theo
• Thành phần tham gia: Dev team, Scrum Master không bắt
buộc tham gia
• Hỏi và trả lời 3 câu hỏi:
• Hôm qua làm được gì
• Hôm nay sẽ làm gì
• Có vấn đề, sự cố gì cản trở hoặc ảnh hưởng tới công việc không?
• Daily scrum không phải để thảo luận chuyên môn
• Nên đứng họp để dễ tiến hành (không cần book phòng) và
không bị quá thời gian (ngồi họp thường sẽ nói nhiều), vì thế
nên còn được gọi là Daily Standup, Standup Meeting
Sprint Review (Sơ kết Sprint)
• Thường kéo dài 4h đối với Sprint dài 4 tuần
• Thành phần tham gia: toàn bộ nhóm Scrum
và các bên liên quan (cấp quản lý, nhà tài
trợ, khách hàng…)
• Là buổi để Dev team demo sản phẩm
• Chỉ làm việc với các công việc đã “Done”
• Product Owner sẽ rà soát lại Product
Backlog
Sprint Retrospective
• Thường kéo dài 3h cho Sprint dài 4 tuần
• Diễn ra sau Sprint Review, trước khi bắt đầu
Sprint mới
• Một buổi rút kinh nghiệm (cả về kỹ thuật,
chuyên môn lẫn quản lý) và tìm cách cải tiến
công việc
• Thành phần tham gia: Dev Team và Scrum
Master. Product Owner không bắt buộc
• Tuyệt đối không dùng Sprint Retrospective để
kiểm điểm, kỷ luật
• Bài học kinh nghiệm sẽ được ghi vào Bản ghi
kinh nghiệm (Lesson Learned Register)
Tổng kết quy trình thực hiện Scrum
Suy luận yêu cầu và tạo Story
• Đặc tả yêu cầu phần mềm – Software
Requirement Specification (SRS)
• User story là một mẩu yêu cầu đối với bất kỳ
chức năng hoặc tính năng nào của sản phẩm
• Một user story thường được hoàn thành trong
vòng vài ngày làm việc
• Format cả một User story:
Là một <vai trò người dùng/khách hàng>, tôi muốn
<mục tiêu cần đạt được> để tôi có thể <lý do của mục
tiêu>.
As a ..., I want .... so that .....
Ví dụ:
Là một người dùng trang web, tôi muốn trang web có
tính năng tìm kiếm nội dung để tôi có thể dễ dàng tìm
được nội dung mà tôi muốn nhanh chóng.
 Nguyên tắc tạo User Story
• 3C:
• Card – ngắn gọn vừa đủ để viết trong một tấm thẻ
• Conversation – đủ chi tiết để đem đi giao tiếp với đối tác
• Confirmation – phải được khách hàng xác nhận (là phù hợp,
đã hoàn thành...)
• Nguyên tắc INVEST: một user story hiệu quả sẽ đảm
bảo nguyên tắc sau:
• Independent – có thể được sắp xếp theo độ ưu tiên bát kỳ
• Negotiable – có thể đàm phán được
• Valuable – đem lại giá trị cho khách hang
• Estimatable – có thể ước lượng được
• Small – đủ nhỏ để được hoàn thành trong vài ngày, nếu quá
lớn thì phải chia nhỏ
• Testable – có thể kiểm thử được
Tạo Product Roadmap
• Đưa ra bức tranh toàn cảnh theo thời
gian của sản phẩm
 Ước lượng User Story
• Mục tiêu là ước lượng được thời gian và chi phí của
các story
• Các thành viên trong nhóm sẽ tham gia ước lượng
• Các phương pháp ra quyết định của nhóm
• Voting (Biểu quyết): Các thành viên trong nhóm sẽ biểu
quyết về các ước lượng để chọn kết quả cuối cùng
• Fist of Five Voting: biểu quyết bằng 5 ngón tay, càng nhiều
ngón thì càng đồng ý
• Wideband Delphi: biểu quyết kín
• Affinity Diagram: viết các Story lên bảng, nhóm sẽ so sánh
với nhau và phân các story vào các nhóm tương tự nhau
Story Point
• Story points là một con số để ước lượng độ lớn, độ
khó, độ phức tạp cho công việc triển khai một user
story nhất định, là một thước đo trừu tượng về nỗ
lực cần thiết để thực hiện nó
• Nhóm Scrum sẽ thảo luận để quyết định số Story
point cho mỗi Story
• Các phương pháp đo lường:
• Dãy Fibonacci: sử dụng chuỗi số Fibonacci cho các giá trị
story point: 1, 2, 3,5, 8, 13, 21...
• T-shirt size: sử dụng các cỡ áo: S, M, L, XL, XXL...
• Phương pháp:
• Xác định Story cơ sở - Base Story, thường có story point = 1
• Ước lượng các story còn lại
• Nhóm đưa ra quyết định để chốt
Team Velocity
• Velocity là thước đo tốc độ hoàn thành
công việc trong lịch sử của nhóm
• Được đo bằng Số Story point nhóm
hoàn thành được trong một Sprint
• Dùng để ước đoán thời điểm hoàn
thành dự án và kiểm soát hiệu năng
của nhóm
Burn-down chart và Burn-up chart
• Burn-down chart và Burn-up chart là hai loại biểu đồ được sử dụng để
theo dõi và truyền đạt tiến độ dự án
• Burn-down chart giúp nhóm biết lượng công việc còn lại
• Burn-up chart thể hiện tiến độ và phạm vi dự án tách biệt với nhau
Backlog refinement (Sắp xếp backlog)
• Product Owner chịu trách nhiệm sắp xếp độ ưu
tiên
• Backlog được update liên tục suốt dự án
• Tiêu chí sắp xếp:
• Giá trị cho khách hàng: nhiều giá trị nhất xếp trước
• Chi phí
• Rủi ro: rủi ro cao nhất xếp trước
• Độ khó: an toàn nhất xếp trước
• Khả năng thành công: cao nhất xếp trước
• Pháp lý
• Độ khẩn cấp: cao hơn xếp trước
• MoSCow: Must have – Should have – Could have –
Would like to have (but not now)
• ...
V-model và thiết kế phần mềm
• V-model: Mô hình phát triển phần mềm
dựa trên 2 quá trình song song là Xác
thực (Verification) và Xác minh
(Validation) tương ứng nhau.
• Được chuẩn hoá thành tiêu chuẩn ISO/IEC
15504, ASPICE...
Tham khảo: UML - Unified Modeling
Language
• UML - Ngôn ngữ mô hình hóa thống nhất,
là hệ thống các ký hiệu và biểu đồ giúp
thiết kế các hệ thống thông tin một cách
nhanh chóng
• Tham khảo them trên google
• Chương trình học sẽ tập trung vào Use case
diagram, Component Diagram, Class
Diagram, và Sequence Diagram
Unit test
• Unit Test (UT) là một loại kiểm thử phần mềm
trong đó các đơn vị hay thành phần riêng lẻ của
phần mềm được kiểm thử
• Một Unit là một thành phần PM nhỏ nhất mà ta có
thể kiểm tra được như các hàm (Function), thủ tục
(Procedure), lớp (Class), hoặc các phương thức
(Method).
• UT case được xây dựng dựa trên SDD
• Kiểm thử tích hợp (Integration Testing - IT) là một
giai đoạn kiểm thử phần mềm mà tất cả các
môđun phần mềm riêng biệt được kết hợp lại và
kiểm thử theo nhóm.
• IT case được xây dựng dựa trên SAD
Quản lý phiên bản
• Phần mềm trong quá trình phát triển
sẽ có rất nhiều phiên bản khác nhau
• Cần một công cụ để quản lý các
phiên bản để đảm bảo nhất quán,
toàn vẹn
• Git là một công cụ quản lý phiên bản
phân tán
• Học cách sử dụng Git trong file
hướng dẫn
 CI/CD
• CI - Continuous Integration: tích hợp liên tục
• CD - Continuous Delivery: chuyển giao liên tục
• Developer chỉ cần commit code, còn lại tất cả quy
trình bao gồm chạy build, test, deploy, phân tích
số liệu, báo cáo sẽ được tự động thực hiện hoàn
toàn.
• Ưu điểm:
• Tránh lỗi, phát hiện sớm lỗi
• Nâng cao chất lượng code
• Sớm phát hành sản phẩm
Xây dựng môi trường phát triển phần mềm
• Các dự án lớn thường sẽ áp dụng CI/CD, DevOps
• Môi trường phát triển thường được set up bởi nhân
viên IT helpdesk hoặc DevOps
• IDE: Sử dụng Visual Studio Code hoặc Eclipse, nếu là
ngôn ngữ Python có thể sử dụng Jupyter Notebook
• Unit test: Chọn framework tuỳ theo từng ngôn ngữ
• Quản lý dự án: Jira, MS Project, Trello, Monday.com,
Asana...
• Quản lý văn bản (Document management) Confluence,
IDM DOOR, Codebeamer, MS Sharepoint, Google
Drive...
• Repository và Code Review: Github, Gerrit, Gitlab,
Bitbucket...
• Quản lý phiên bản (Version controller): Git, SVN,
Mecurial, Dimension CM...
Trong chương trình học sẽ sử dụng Github làm repository
và Code review tool.
 Quy trình thực hiện task
1. Quản lý/Leader tạo 1 task mới (có thể là 1 hoặc một phần của user story, bug cần fix, tài liệu cần viết...) trong Jira,
gọi là ticket, mô tả rõ ràng nội dung của task, thiết lập deadline nếu cần, Task sẽ ở trong cột To Do
2. Quản lý sẽ assign một thành viên (dev, tester...) phụ trách ticket này (assignee)
3. Thành viên sẽ ước lượng thời gian dự kiến hoàn thành rồi trả lời (comment) vào ticket
4. Thành viên kéo Task vào cột Doing và tiến hành nghiên cứu (investigate, study) vấn đề
5. Thành viên đưa ra giải pháp (solution) khả thi rồi đính kèm vào ticket, comment vào ticket để quản lý review
6. Quản lý (hoặc Leader) xem xét giải pháp được đề xuất rồi duyệt hoặc thảo luận thêm với thành viên để chốt
7. Thành viên pull source code mới nhất, tạo một branch mới và thực hiện giải pháp được chốt (coding...)
8. Test tích hợp, unit test... để đảm bảo vấn đề được giải quyết và không ảnh hưởng đến các thành phần khác của
sản phẩm, viết báo cáo test rồi cập nhật vào ticket, nếu có vấn đề thì quay lại bước 4
9. Thành viên commit code lên repository rồi add quản lý vào reviewer
10. Quản lý/Leader sẽ review code, nếu OK thì phê duyệt rồi Merge với branch chính, xoá branch dev đi nếu cần.
11. Sau khi Merge, thành viên lại pull toàn bộ source code mới nhất về test lại toàn bộ để đảm bảo vấn đề được giải
quyết và không phát sinh thêm vấn đề khác, viết báo cáo test và các case study (kiến thức mấu chốt) rồi cập nhật
vào ticket, nếu có vấn đề thì quay lại bước 4
12. Quản lý set trạng thái của ticket là Đã hoàn thành (Done, Fixed, Resolved...) và đóng (Close) ticket lại, ticket sẽ
được đưa vào cột Done
Lưu đồ: Quy trình thực hiện task
Tạo 1 task Assign thành Nghiên cứu
Bắt đầu Ước lượng
mới viên vấn đề

Đề xuất giải Xem xét giải S

OK?
pháp pháp
Đ
Pull, tạo dev
Test, báo Pass S
branch,
cáo ?
implement
Đ
Commit code, S
request Review OK?
reviewer
Quản lý/ Leader
Đ
thực hiện
Phê duyệt, Pull, test xác
merge main, nhận, báo Pass S
Thành viên nhóm (Dev,
Tester...) thực hiện xoá dev cáo, ghi case ?
branch study Đ

Báo cáo, ghi Set Done,

Kết thúc
case study close task
Chúc các em thành công!