Scrum là một trong các khung làm việc linh hoạt phổ biến nhất hiện nay
Trang 1BÁ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
Trang 24 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
Trang 32 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
Trang 4d) 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:
Trang 5Vớ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
Trang 6cô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:
Trang 7Đặ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
Trang 8Thí 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
Trang 9Hình 2: Thành phần và các tầng trong TFS
TFS có một kiến trúc ba tầng một cách logic bao gồm: một tầng Client, một tầng Application và một tầng Data Tầng Client tương tác với tầng Application qua các Web Services khác nhau, tầng Application sử dụng các Database khác nhau trong tầng Data
Sự triển khai cấu trúc cơ bản: phần lớn phụ thuộc vào kích cỡ nhóm của bạn Nếu các thành viên tham gia trong nhóm ít hơn 50 người thì bạn tiến hành triển khai cấu trúc Single-server Nhưng với một máy chủ đủ mạnh có thể hỗ trợ tối
đa 400 người sử dụng
Nếu các thành viên tham gia trong nhóm với số lượng lớn vài ngàn người thì bạn tiến hành triển khai cấu trúc Dual-server
I Thành phần cấu tạo nên các tầng Client, Application và Data:
Trang 101 Tầng Client:
Hình 2.1 Mô hình tầng Client
Chứa các thành phần quan trọng sau đây:
Team Foundation Server Object Model: Đây là public API được sử dụng
để tương tác với TFS Bạn có thể sử dụng mô hình đối tượng để tạo những ứng dụng trong Client-side cho riêng bạn mà tương tác với TFS
Những thành phần Visual Studio Industry Partners (VSIP): Đây là những
công cụ của bên thứ ba (third-party tools), add-ins và những ngôn ngữ được sử dụng trong Visual Studio
Microsoft Office tích hợp: bao gồm một bộ các add-ins dành cho Microsoft
Office excel và Microsoft Office Project cho phép bạn truy vấn và cập nhật các Work Item trong cơ sở dữ liệu TFS Work Item Tracking Điều này đặc biệt hữu ích cho các nhà quản lí dự án đã sử dụng rộng rãi các công cụ này
Command-line tools: là những công cụ cho phép bạn tương tác với TFS từ
những dòng lệnh (Command-line) Phần lớn các công cụ này cung cấp các chức năng kiểm soát mã nguồn và chúng hữu ích trong việc tự động hóa các tác vụ lặp và các tác vụ cố định
Check-in Policy Framework: thành phần này hỗ trợ check-in policy feature,
là một cơ chế mở rộng cho phép bạn xác nhận tính hợp lệ của Code trong suốt Check-in process
Trang 112 Tầng Application:
Hình 2.2 Mô hình tầng Application
Những Web Services này được nhóm vào các tập sau:
Team Foundation Data Services.
Team Foundation Integration Services.
a) Team Foundation Data Services: Những Services này gồm có các thành
phần sau:
Version control Web Services: Tầng Client sử dụng Web Services này để
thực thi các chức năng kiểm soát mã nguồn (Source Control Features) TFS khác nhau và để tương ứng với Source Control Database
Work Item Tracking Web Services: Tầng Client sử dụng Web services này
để tạo, cập nhật và truy vấn các Work Item trong Work Item Tracking Database
Team Foundation Build Web services: Tầng Client và MS Build
Framework sử Web Services này để thực thi các quy trình thiết kế
b) Team Foundation Integration Services:
Tập các Web Services này cung cấp các chức năng tự động và thống nhất Những Web Services này không tương tác với tầng Data Những thành phần trong Team Foundation Integration Services này gồm có:
Registration Web Services: Service này được sử dụng để đăng kí các dịch vụ
TFS khác Nó gìn giữ thông tin trong một cơ sở dữ liệu đăng kí Những Web
Trang 12Services sử dụng thông tin này để khám phá và xác định xem bằng cách nào để tương tác với Web Services khác
Security Web Service: Service này bao gồm Group Security Service và
Authorization Service Group Security Service được dùng để quản lí tất cả các User
và Group của TFS Authorization Service cung cấp một hệ thống truy cập cho TFS
Linking Web Service: Service này cho phép các công cụ thiết lâp một mối
quan hệ được liên kết lỏng lẻo giữa các phần tử dữ liệu mà chúng đang chứa
Ví dụ: Mối quan hệ giữa một Work Item sai soát và Source Code được
thay đổi để sửa chữa sự sai soát được tổ chức bởi TFS sử dụng một Link
Eventing Web Service: Service này cho phép một công cụ hay một dịch vụ
đăng kí các loại sự kiện Người sử dụng có thể đồng ý để nhận được những sự kiện này và thông báo qua e-mail hay sự dẫn ra của một Web Service
Ví dụ: Bạn có thể sử dụng một Check-in event để kích hoạt một
Continuous Integration Build
Classification Web Service: Service này làm việc với Linking Web Service
để kích hoạt những TFS Artifact để phân loại tùy theo những nguyên tắc phân loại
đã được định nghĩa trước Thành phần này giúp hỗ trợ Cross-tool Reporting ngay cả đối với những Artifacts mà không chia sẽ một nguyên tắc phân chia thông thường để
tổ chức dữ liệu của họ
Ví dụ: Nếu các Work Item được tổ chức bình thường bởi nhóm của
bạn, trong khi Test được tổ chức bởi các thành phần Component, bạn cũng có thể tổ chức Test bởi nhóm của bạn để các Test đó có thể được báo cáo cùng với các Work Item
Trang 133 Tầng Data:
Hình 2.3 Mô hình tầng Data
TFS không hỗ trợ truy cập trực tiếp đến dữ liệu mà được lưu trữ trên tầng Data từ những ứng dụng Client Thay vào đó, tất cả các yêu cầu về dữ liệu được thực hiện thông qua các Web Services trên tầng Application
Tầng Data của TFS bao gồm các dữ liệu sau được lưu trữ tương ứng với các Data Services trên tầng Application
Work Item Tracking: Phần này lưu trữ tất cả các dữ liệu có liên quan đến
Work Items
Version Control: Phần này lưu trữ tất cả các dữ liệu có liên quan đến Source
Control
Team Foundation Build: Phần này lưu trữ tất cả các thông tin liên quan đến
các chức năng của TFS Team Build
Reporting Warehouse: Phần này lưu trữ tất cả các thông tin liên quan đến tất
cả các công cụ và chức năng của TFS Reporting Warehouse giúp việc tạo ra các báo cáo đơn giản hơn bằng cách kết hợp dữ liệu từ nhiều công cụ khác nhau
