QUI TRÌNH PHÁT TRIỂN SCRUM, VISUAL STUDIO TEAM SYSTEM TEAM FOUNDATION SERVER, ỨNG DỤNG QUẢN LÍ KINH DOANH QUÁN COOFFEE

BÁO CÁO ĐỀ TÀI :
QUI TRÌNH PHÁT TRIỂN SCRUM, VISUAL
STUDIO TEAM SYSTEM TEAM
FOUNDATION SERVER, ỨNG DỤNG
QUẢN LÍ KINH DOANH QUÁN COOFFEE
GVHD: Trần Trọng Tuyên
Nhóm SV thực hiện gồm:
1. Lê Kim Hưng (Nhóm trưởng)
2. Đặng Thị Hồng Sâm
3. Huỳnh Lý Ngọc
4. Văn Thị Thùy Trinh
CHƯƠNG I: QUY TRÌNH PHÁT TRIỂN PHẦN MỀM LINH HOẠT SCRUM
I. Định nghĩa: Scrum là một trong các khung làm việc linh hoạt phổ biến nhất
hiện nay. Scrum được dùng để quản lý các dự án phát triển phần mềm, nhưng cũng
được dùng trong các công việc khác với độ phức tạp và tính sáng tạo rất đa dạng.
Dựa trên lý thuyết quản lý thực nghiệm: Scrum sử dụng kỹ năng lặp và tăng
dần để tối ưu hóa sự hiệu quả và kiểm soát rủi ro. Scrum rất đơn giản, dễ học và khả
năng ứng dụng lớn. Vì vậy, để dùng scrum chúng ta cần nghiên cứu các thành phần
sau đây:
II. Các thành tố cấu tạo trong Scrum:
1. Ba giá trị cốt lỗi:
a) Minh bạch (Transparency):
Trong Scrum, minh bạch được xem 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 phải minh bạch và thông suốt. Từ đó mọi người với các
vai trò khá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 bảo đảm
thông tin được minh bạch cho các bên.
b) Thanh tra (Inspection):
Công tác thanh tra liên tục các hoạt động trong Scrum bảo đảm cho việc phát
hiện 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. Với việc 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ải tiến liên tục trong Scrum.
c) Thích nghi (Adaptation):
Scrum là một trong những phương pháp phát triển rất linh hoạt. Nhờ đó nó mang
lại tính thích nghi rất cao. 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 nhiều thành công lớn cho dự án.
2. Ba vai trò:
a) Product Owner (Chủ sản phẩm):
Là người chịu trách nhiệm về sự thành công của dự án, là 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.
b) Scrum master (Đội trưởng):
Là người hiểu biết sâu sắc về Scrum và đảm bảo nhóm có thể làm việc hiệu quả
với Scrum.
c) Team (Đội sản xuất):
Là một nhóm liên chức năng có nhiệm vụ giải quyết các yêu cầu từ Product
Owner để tạo ra các gói sản phẩm tốt nhất.
3. Bốn cuộc họp (Four ceremonies):
a) Sprint Planning (Lập kế hoach cho Sprint):
Đội sản xuất sẽ gặp gỡ với Product Owner để lên kế hoạch làm việc cho một
Sprint. Các công việc như là: chọn lựa các yêu cầu cần phát triển, phân tích và nhận
biết các công việc phải làm kèm theo các ước lượng thời gian cần thiết để hoàn tất
các công việc. Scrum sử dụng phương thức lập kế hoạch từng phần và tăng dần theo
thời gian. Theo đó, việc lập kế hoạch không diễn ra duy nhất một lần trong vòng đời
của dự án mà được lặp đi lặp lại, có sự thích nghi với tình hình thực tiễn trong tiến
trình đi đến sản phẩm.
b) Daily Scrum (Buổi họp hằng ngày):
Scrum Master cùng với Đội sản xuất tổ chức họp hàng ngày để Đội chia sẽ tiến
độ công việc cũng như các khó khăn gặp phải trong quá trình phát triển phần mềm
suốt một Sprint.
c) Sprint Review (Buổi họp đánh giá):
Cuối Sprint, đội sản xuất cùng với Product Owner sẽ rà soát lại các công việc đã

hoàn thành 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.
d) Sprint Retrospective (Buổi họp cải tiến):
Dưới sự chỉ đạo của Scrum Master, Đội sản xuất sẽ rà soát lại toàn diện Sprint
vừa kết thúc và tìm cách cải tiến quy trình làm việc cũng như bản thân sản phẩm.
4) Ba công cụ (Artifacts):
a) Product backlog:
Có thể hiểu như là danh sách các yêu cầu của dự án. Product Owner chịu trách
nhiệm sắp xếp độ ưu tiên cho từng hạng mục trong Product Backlog dựa trên các giá
trị do Product Owner định nghĩa.
b) Sprint backlog:
Là kết quả của buổi họp lập kế hoạch cho một Sprint với sự kết hợp giữa Product
Owner và Đội sản xuất. Họ sẽ cùng nhau phân tích các yêu cầu theo độ ưu tiên từ
cao xuống thấp để hiện thực hóa các hạng mục trong Product Backlog dưới dạng
danh sách công việc.
c) Burndown Chart:
Đây là biểu đồ hiển thị xu hướng của dự án dựa trên lượng thời gian cần thiết để
hoàn tất công việc. Burndown Chart còn được dùng để theo dõi tiến độ của một
Sprint hoặc của cả dự án.
III. Nguyên lý hoạt động của Scrum:
Với mỗi dự án thì nhiệm vụ của Product Owner là tạo ra các Product Backlog
chứa các yêu cầu của dự án với các hạng mục được sắp xếp theo thứ tự ưu tiên. Đội
sản xuất sẽ có nhiệm vụ hiện thực hóa các hạng mục do Product Owner yêu cầu với
sự lặp đi lặp lại các giai đoạn nước rút trong vòng 2 đến 4 tuần, với đầu vào là các
Product Backlog và đầu ra là các gói sản phẩm có thể chuyển giao được. Trong lúc
cùng nhau đua nước rút thì Đội sản xuất cùng họp với Product Owner để lên kế
hoạch cho từng Sprint. Kết quả của mỗi buổi họp là các Sprint Backlog. Trong quá
trình phát triển Đội sản xuất sẽ thường xuyên cập nhật Sprint Backlog và thực hiện
công việc này hằng ngày để cùng nhau chia sẽ tiến độ công việc cũng như các khó
khăn trong quá trình làm việc. Mỗi Sprint kết thúc là lúc nhóm tạo ra các gói phần

mềm có thể chuyển giao được. Cuối mỗi Sprint, Đội sản xuất sẽ cùng họp đánh giá
với Product Owner để thấy được Đội sản xuất đã chuyển giao được những gì, còn
những gì phải làm hoặc phải thay đổi, cải tiến. Sau khi cuộc họp đánh giá kết thúc,
Scrum Master và Đội sản xuất sẽ tổ chức họp cải tiến để tìm ra các cải tiến mới
trước khi Sprint tiếp theo bắt đầu.
Các Sprint sẽ được lặp đi lặp lại cho tới khi các hạng mục trong Product
Backlog được hoàn tất hoặc khi Product Owner quyết định dừng dự án căn cứ vào
tình hình thực tế. Với chiến thuật “quan trọng làm trước” nên các hạng mục mang lại
giá trị lớn cho dự án. Do đó, Scrum luôn mang lại giá trị tốt nhất cho người đầu tư
cho dự án. Qui trình luôn được cải tiến nên nhóm Scrum thường có năng suất hoạt
động cao và đây là lợi ích mà Scrum mang lại cho các tổ chức.
IV. So sánh Scrum và các quy trình phần mềm truyền thống:
1. Các quy trình truyền thống:
a) Quy trình thác nước(Waterfall): chia dự án phần mềm gồm các giai
đoạn: đặt tả yêu cầu, thiết kế hệ thống, cài đặt (lập trình), kiểm thử và bảo trì. Quy
trình này dễ quản lí nhưng kém linh hoạt và không hiệu quả bởi có sự thay đổi trong
giai đoạn sau sẽ có sự ảnh hưởng rất lớn đến các giai đoạn trước. Tất cả các yêu cầu
công việc được xác định trong quá trình lập kế hoạch gồm những việc cơ bản như:
xác định các yêu cầu sản phẩm, chi phí sản phẩm, ngày hoàn thành… Dẫn đến khả
năng thành công thấp nếu có những yêu cầu mới hoặc chỉnh sửa sản phẩm sẽ có sự
ảnh hưởng rất lớn đến các giai đoạn trước.
b) Quy trình xoắn ốc (Spiral): chia dự án thành các giai đoạn như: lập kế
hoạch, phân tích rủi ro, giao tiếp khách hàng, đánh giá lại, sản xuất và phân phối.
Nhưng chưa được sử dụng rộng rãi.
2. Đối với quy trình Scrum:
Điểm mạnh nhất đó là việc linh hoạt, dự án không được cố định từ đầu về
thời gian hoàn thành hay những yêu cầu mà nó sẽ được xác định khi phát triển thực
tế.
Phân phối sản phẩm mềm dẻo: nội dung sản phẩm chuyển giao được xác định
linh hoạt theo môi trường sử dụng thực tế.

Thời gian biểu linh hoạt: có thể muộn hoặc sớm hơn so với kế hoạch ban đầu.
Chất lượng sản phẩm tốt và giảm rủi ro sản xuất, chi phí thấp. Khả năng trao
đổi giữa khách hàng và nhà phát triển, giữa những thành viên trong đội được đặt lên
mức cao.
Tốc độ phát triển nhanh, tiết kiệm thời gian. Việc chuẩn bị hành động cho
những thay đổi trong quá trình phát triển tốt hơn vì hầu như hàng ngày luôn có
những buổi họp đánh giá lại ở những vòng lặp phát triển.
Các bugs (lỗi) và các vấn đề được phát hiện sớm hơn rất nhiều so với các
phương pháp truyền thống bởi vì khách hàng được tham gia đánh giá rất nhiều và
đầu ra của sản phẩm rất nhanh. Và khi đi sai hướng, có thể hủy ngay Sprint đó để
quay lại với bản kế hoạch.
Bảng so sánh các quy trình phần mềm:
Đặc điểm Waterfall Spiral Scrum
Xác định các
giai đoạn phát
triển
Bắt buộc Bắt buộc Chỉ có giai đoạn
lập kế hoạch và
kết thúc
Sản phẩm cuối
cùng
Được xác định
trong quá trình
lập kế hoạch
Được xác định
trong quá trình lập
kế hoạch
Xác định trong
quá trình xây
dựng dự án

Chi phí sản
phẩm
Được xác định
trong quá trình
lập kế hoạch
Thay đổi cục bộ Xác định trong
quá trình xây
dựng dự án
Ngày hoàn
thành sản phẩm
Được xác định
trong quá trình
lập kế hoạch
Thay đổi cục bộ Xác định trong
quá trình xây
dựng dự án
Đáp ứng với
môi trường sử
dụng
Trong kế hoạch
ban đầu
Trong kế hoạch
ban đầu
Xuyên suốt từ kế
hoạch đến xây
dựng và kết thúc
Kinh nghiệm
trao đổi
Đào tạo trước
cho đến khi bắt

tay làm dự án
Đào tạo trước cho
đến khi bắt tay
làm dự án
Thực hiện trong
quá trình làm dự
án
Khả năng thành
công
Thấp Trung bình thấp Cao
CHƯƠNG II: VISUAL STUDIO TEAM SYSTEM, TEAM FOUNDATION
SERVER
Giới thiệu: Visual Studio Team System, Team Foundation Server là phần
mềm hỗ trợ để nâng cao hiệu quả của đội ngũ phát triển phần mềm cơ bản của bạn.
Thí dụ bạn đang sử dụng Team Foundation Server hay đã áp dụng từ lâu, thì trong
tài liệu này bạn sẽ tìm thấy những hướng dẫn cụ thể và hiểu thấu đáo để điều chỉnh
cho phù hợp với tình huống cụ thể của bạn. Những hướng dẫn cụ thể đó được trình
bày trong những phần sau đây:
Phần I: Trình bày cho chúng ta một cái nhìn tổng quát một cách nhanh chóng
của Team Development với Team Foundation Server. Bạn cũng sẽ hình dung ra bức
tranh lớn trong những điều kiện của môi trường phát triển phần mềm của bạn, bao
gồm môi trường phát triển và kiểm thử. Bạn cũng sẽ tìm hiểu kiến trúc cơ bản của
Team Foundation Server.
Phần II: Trình bày cho bạn bằng cách nào để kết cấu Source Code của bạn và
quản lí những phần phụ thuộc. Nó cũng trình bày cho bạn bằng cách nào để quyết
định một chiến thuật Branching và Merging…. Và nhiều phần khác nữa.
Mục đích:
Mô tả cấu trúc Microsoft Visual Studio Team System (VSTS) và Team
Foundation Server (TFS).
Xác định những thành phần cấu tạo nên các tầng Client, Application và Data.

Làm rõ sự khác nhau giữa việc triển khai một Single-server và Multi-server.
Tổng quan về kiến trúc Team Foundation Server:
Chương này giới thiệu với các bạn kiến trúc TFS và sự triển khai cấu trúc liên kết cơ
bản.