Team Projects
• Tạo một team project trên một ứng dụng nếu bạn
muốn di chuyển các work item và các phần
khác giữa các version(phiên bản) của ứng dụng.
• Tạo một team project trên một version nếu bạn
muốn khởi động với các work item mới và các asset khác với từng version(phiên bản)
của ứng dụng.
• Chỉ cấp các permission được yêu cầu trên các
project assets.
• Cấu trúc source tree của bạn để hộ trợ
branching.
Tạo Một Team
Project Trên Một ứng Dụng Nếu Bạn Muốn Di Chuyển Các Work Item Và Các Phần Khác Giữa Các Version(Phiên Bản) Của ứng
Dụng
Nếu bạn muốn thực
hiện chuyển tiếp không chỉ là source code mà còn là các work item và các TFS
asset khác giữa các bản phát hành release, hãy xem xét sử dụng một team project
trên một ứng dụng. Khi bạn sử dụng một single team project cho nhiều version của
ứng dụng, tất cả các TFS asset đều được chuyển tiếp một cách tự động cho các bản
phát hành kế tiếp. Khi bạn đã sẵn sàng để phát hành một version mới của ứng dụng
của bạn, bạn có thể tạo một branch với project để đại diện cho các bản phát
hành release và tách riêng phần code đó.
Hãy nhớ các điểm
chính sau khi sử dụng một project trên một application:
- Các bản phát hành song song buộc phải chia sẻ
các sơ đồ work items schema, check in policies, và các hướng dẫn về quy trình.
- Các báo cáo report thì khó hơn; bởi vì các
report mặc định cho toàn bộ dự án project, bạn phải thêm filter bằng các
release.
- Nếu bạn có hàng trăm ứng dụng, từng project
riêng, bạn sẽ khởi động dựa vào giới hạn về hiệu suất và tỉ lệ của TFS.
- Bạn sẽ tích lũy 'baggage' qua nhiều bản phát
hành release. Cách dễ nhất để ghi nhận lại vấn đề này là tạo mới một project và
branch phần code mà bạn muốn thực hiện chuyển tiếp vào project đó.
Tài nguyên bổ
sung
Tạo một team project trên một version nếu bạn muốn khởi động với các
work item mới và các asset khác với từng version(phiên bản) của ứng dụng
Nếu bạn muốn mỗi
bản phát hành bắt đầu một cách mới hoàn toàn mà không thực hiện chuyển tiếp các
work item và các TFS asset khác, thì hãy xem xét sử dụng một project trên một
release. Khi bạn sử dụng một project mới cho từng release, bạn có thể chỉnh sửa
work item schema, workflow, check-in policies, và các asset khác mà không ảnh
hưởng đến các bản phát hành release cũ. Điều này có thể đặc biệt hữu dụng nếu bản
phát hành cũ sẽ không được bảo trì bởi một nhóm riêng nào đó như là một nhóm kĩ
sư được duy trì liên tục mà có thể có một quy trình và tiến trình công việc
workflow khác so với nhóm phát triển chính của bạn.
Hãy nhớ các điểm
chính sau khi sử dụng một project trên một bản phát hành release:
- Mặc dù dễ dàng để di chuyển source code từ một
project sang project khác, nhưng lại khó di chuyển các work item và các TFS
asset khác từ một project sang project khác. Bởi vì các work item chỉ có thể được
copy tại một thời điểm đến project khác, nếu bạn muốn copy một tập các work
item, bạn sẽ cần viết tiện ích của riêng bạn.
- Nếu bạn có hàng trăm các ứng dụng và bản phát
hành, mỗi cái ở trong project của riêng nó, bạn sẽ khởi động dựa trên các giới
hạn về hiệu suất và tỉ lệ của TFS(TFS
performance and scale limit).
- Hãy chọn một cấu trúc mà bạn có thể tương tác
làm việc trong một thời gian dài bởi vì cấu trúc lại các team project rất khó
khăn.
- Source có thể dễ dàng được chia sẻ giữa các
team project như sau:
o Branch
source từ một project này đến project khác.
o Map source
từ project khác vào workspace của bạn.
- Team Foundation Server có thể đạt đến tỉ lệ
~500 project bằng cách sử dụng quy trình mẫu MSF Agile process template hay là
250 project bằng cách sử dụng quy trình mẫu MSF CMMI process template. Nếu bạn
tạo quy trình mẫu của riêng mình hay là tùy chỉnh một quy trình mẫu đã có, hãy
nhớ là các work item schema có ảnh hưởng lớn nhất đến khả năng mở rộng server. Một schema phức
tạp sẽ trả về kết quả trong một server
có khả năng hỗ trợ một số ít các project.
- Bạn sẽ phải thực hiện trên tất cả các area từ
project gốc; và cũng có lẽ thay đổi các
permission ở trong source control.
Tài nguyên bổ
sung
Chỉ cấp các permission được yêu cầu trên các project assets
Khi tạo các team
project, hãy xem lại các security group mặc định được tạo bởi các quy trình, và
nếu cần, hãy tạo các security group với các permission phù hợp. Sau đó bạn phân
chia các thành viên của dự án vào các group tương ứng để đảm bảo là mỗi thành viên
sẽ chỉ nhận các permission mà anh ta hay cô ta yêu cầu trên các project
asset.
Tài nguyên bổ
sung
- Để có thêm thông tin về cấp phát các
permission, hãy xem "How To - Manage Projects in Visual Studio Team Foundation
Server" trong tài liệu này.
Cấu trúc source tree của bạn để hộ trợ branching
Khi tạo cấu trúc
cây source tree của bạn, hãy đảm bảo là nó hỗ trợ branching. Hãy giữ các folder
dành riêng cho source và cho các project asset khác, để nếu các phát triển
isolation development được yêu cầu trong tương lai, bạn có thể branch một cách
đơn giản source folder. Và cũng hảy đảm bão là bạn duy trì các folder dành
riêng cho từng thành phần với source folder, để partial branching có thể được
thực thi nếu có yêu cầu.
Hãy chia các thực
thể khác ra như là shared code, unit tests, library dependencies, và vv... bằng
cách sử dụng các folder mà chúng có thể được loại trừ hoặc gồm có trong suốt
quá trình branch theo yêu cầu.
Sau đây là một
thí dụ của một cấu trúc source tree mà có hỗ trợ branching:
Tài nguyên bổ sung
- Để có thêm thông tin về source tree
structure, hãy xem "Chương 5 - Defining Your Branching and Merging Strategy"
trong tài liệu này.
Work Items
• Nắm bắt các kịch bản/tình huống của bạn ngay
lúc bắt đầu dự án project của bạn.
• Xác định các yêu cầu Quality of Service một
cách thích hợp.
• Phân chia các kịch bản scenarios thành các
task quản lý, mô- đun task phát triển.
• Thiết lập từng tiêu chuẩn cơ bản cho từng
task.
• Liên kết các requirement và các task cho các
kịch bản.
• Sử dụng Microsoft Excel để chỉnh sửa một số
lượng lớn các work item.
Nắm bắt các kịch bản/tình huống của bạn ngay lúc bắt đầu dự án project của
bạn
Tạo và nắm bắt một
tập các kịch bản dự án(project scenarios) vào lúc bắt đầu project cảu bạn. Điều
này giúp bạn đạt được một bức tranh tổng thể về project của bạn và sau này có
thể được sử dụng để theo dõi các tiến bộ
của dự án của bạn. Trong suốt quá trình phát triển, bạn có thể chỉnh sửa các kịch
bản đã có hay thêm mới các kịch bản để miêu tả trình bày cho những gì mà bạn học
được theo thời gian.
Để nắm bắt các kịch
bản vào lúc bắt đầu dự án
1. Sử dụng project back log (PBL) document, là
các document được yêu cầu dựa trên đầu vào từ các stakeholder khác nhau (bao gồm
các customers, business analysts, end users, và các product managers), và phạm
vi của các kịch bản cho project của bạn.
2. Ở trong Team
Explorer, hãy mở rộng nút project node, right-click vào Work Items folder,
trỏ đến phần Add Work Item, và sau
đó click Scenario.
3. Ở trong trang mới New Scenario page, hãy enter các chi tiết cho scenario. Hãy chắc
là để thiết lập Iteration đến Iteration
999.
4. Save kịch bản scenario mới của bạn.
5. Lặp lại các bước trên cho tất cả các kịch bản
scenarios mà bạn đã xác định cho project.
Tài nguyên bổ
sung
- Để có thêm thông tin về capturing scenarios,
hãy xem "How To - Manage Projects in Visual Studio Team Foundation Server"
trong tài liệu này.
Xác định các yêu cầu Quality of Service một cách thích hợp
Hãy xác định các
yêu cầu Quality of Service (QoS) requirement cho từng kịch bản scenarios để được
làm việc trong suốt chu kì lặp iteration cycle. Điều này giúp định nghĩa các
tiêu chuẩn được chấp nhận cho kịch bản scenario. Những đầu vào input cho các
QoS requirement là từ các mục đích của
poject và các yêu cầu và các tài liệu cụ thể, nếu có sẵn.
Để xác định các
yêu cầu QoS requirement của bạn:
1. Right-click vào mục project's Work Items folder, trỏ đến phần Add Work Item, và sau đó click vào Quality of Service Requirements.
2. Trên trang New Quality of Service Requirements page, thêm vào các chi tiết
sau:
a. Gán Type cho một giá trị thích hợp như là
performance, scalability, stress, hay security.
b. Gán Iteration thành current iteration
cycle.
c. Từ tab Links, liên kết QoS đến một kịch bản
scenario cụ thể để truy tìm nguồn gốc dễ dàng hơn.
3. Save yêu cầu QoS requirement mới.
4. Tạo một
QoS requirement cho từng quy tắc hay từng loại yêu cầu chất lượng, và
hãy nhớ là mỗi kịch bản scenario có thể có nhiểu yêu cầu QoS requirements.
5. Hãy chắc là bạn tạo các yêu cầu QoS
requirements cho tất cả các kịch bản scenarios đang được làm việc trong suốt
các vòng lặp cụ thể(iteration cycle)
Quan trọng: Sau này bạn có thể
phân chia các yêu cầu QoS requirements thành các test task.
Tài nguyên bổ
sung
- Để có thêm thông tin về xác định các yêu cầu
QoS requirements, hãy xem "How To - Manage Projects in Visual Studio Team
Foundation Server" trong tài liệu này.
- Để có thêm thông tin về các work item , hãy
xem "Managing Team Foundation Work
Items" tại http://msdn2.microsoft.com/en-us/library/ms181314(VS.80).aspx
Phân chia các kịch bản scenarios thành các task quản lý, mô- đun task
phát triển.
Trong quá trình lập
kế hoạch iteration, hãy chia các kịch bản của bạn thành các câu chuyện của người
dùng và sau đó phân chia các câu chuyện của người dùng thành các tác vụ phát
triển development task. Hãy chắc là các tác vụ phát triển development task mà bạn
tạo ra có thể quản lý được và phân chia thành các modul. Các tác vụ task không
nên là cuối cùng nhiều hơn một hoặc hai ngày. Nếu chúng nhiều hơn, bạn cần phải
phân chia các tác vụ task thành các tác vụ task nhỏ hơn hay các sub-task. Việc
làm này tạo nên các kế hoạch linh hoạt và cải thiện quản lý dự án.
Để chia các kịch
bản scenarios thành các tác vụ phát triển có thể quản lý được và theo từng
modul:
1. Chia các kịch bản scenario đã chọn thành các
developer stories.
2. Chia nhỏ các developer stories thành các tác
vụ developer task.
3. Nắm bắt các tác vụ developer task trong TFS
như là các task work item như sau:
a. Trong Team Explorer, bên dưới project node của bạn,
right-click vào Work Items folder, trỏ đến Add
Work Item, và sau đó click Task.
b. Trên
trang New Task page, thêm các chi tiết sau:
i. Gán Discipline thành Development.
ii. Gán Iteration thành iteration cycle hiện
có.
iii. Trên
tab Links, liên kết task với các
scenario cụ thể để truy tìm nguồn gốc dễ hơn. Trên tab này, cùng với sự mô tả,
bạn có thể nắm bắt các tiêu chuẩn chấp nhận được cho tác vụ task, mà có thể xác
định nếu tác vụ được hoàn thành thành công.
iv. Gán Assigned to field cho lập trình viên mà
sẽ làm tác vụ đó.
c. Save task
mới.
d. Lặp lại
các bước trên cho tất cả các task đã xác định.
4. Lặp lại các bước trên cho tất cả các scenario
đã xác định đối với iteration.
Tài nguyên bổ
sung
Thiết Lập Từng Tiêu Chuẩn Cơ Bản Cho Từng Task
Các tác vụ phát
triển development task, khi xác định, nên gồm có các tiêu chuẩn chấp nhận được
để cho phép một lập trình viên quyết định khi tác vụ task được hoàn thành. Dựa
trên các quy trình mẫu mà bạn đang sử dụng, thì có thể thực hiện được theo 2
cách:
- MSF
Agile - Nếu bạn đang sử dụng MSF Agile mà không có một yêu cầu loại work
item chính thức, tốt nhất là hãy bao gồm
các tiêu chuẩn chấp nhận được(acceptance criteria) như là text trong chính các
work item. Hãy bắt đầu với một danh sách với các gạch đầu dòng và thêm nhiều
chi tiết hơn nếu cần thiết.
- MSF
CMMI - Nếu bạn đang sử dụng MSF CMMI, bạn có thể sử dụng các yêu cầu
formal để xác định các acceptance criteria cho một task. Bước đầu tiên
là xác định các yêu cầu của bạn. Sau đó bạn có thể tạo các development task mà
sẽ được sử dụng để thực thi những yêu cầu này và liên kết các task với các yêu
cầu để các lập trình viên có thể kiểm tra dựa vào đó và để có sự truy tìm nguồn
gốc từ các yêu cầu đến các task.
Các tiêu chuẩn chấp
nhận được acceptance criteria thường hầu hết được xác định như là một yêu cầu
kinh nghiệm người dùng trong một form của một mini-scenario hay một yêu cầu về
QoS(QoS requirement). Sau khi acceptance criteria đã được đáp ứng, các lạp
trình viên có thể đánh dấu các task đã hoàn thành và chuyển sang task tiếp
theo.
Tài nguyên bổ
sung
Liên Kết Các Requirement Và Các Task Cho Các Kịch Bản
Khi tạo mới các
work item như là các tasks, bugs, issues, hay các QoS requirements, hãy chắc là
bạn liên kết những work item này đến các scenario mà điều khiển các sự khởi tạo
của chúng. Điều này giúp đả bảo là mỗi work item được điều khiển bởi một kịch bản
người dùng thật sự(real user scenario) và có thể được sử dụng để theo dõi tiến
độ hoàn thành kịch bản trong suốt quá trình development iteration của bạn.
Để liên kết các
tasks, bugs, issues, hay các QoS work item mới đến kịch bản scenarios
1. Trong trang New work item page, click vào tab Links , trên tab Links
hãy click vào buton Add.
2. Trong hộp thoại Add Link dialog box, bên dưới Link
Type, hãy chọn Scenario.
3. Click vào Browse để tìm kiếm các kịch bản scenarios ở trong team project của
bạn.
4. Trong danh sách list, hãy chọn scenario mà bạn
muốn liên kết đến và sau đó click OK.
5. Trong Comment box, hãy đánh một comment để giải
thích các work item liên quan đến như thế nào. Hộp Description box được điền một cách tự động.
6. Click OK.
Tài nguyên bổ
sung
Sử Dụng Microsoft Excel Để Chỉnh Sửa Một Số Lượng Lớn Các Work Item
Team Foundation
Server không hỗ trợ việc chỉnh sửa work item số lượng lớn. Thay vào đó, bạn phải
chỉnh sửa từng work item một cách riêng lẻ. Nếu bạn cần chỉnh sửa một số lượng
lớn các work item trong một thời gian ngắn-thí dụ, trong một cuộc họp phân loại-hãy
cân nhắc việc sử dụng Microsoft Office Excel®
để giảm bớt các task. Các work item có thể được export từ TFS đến Excel,
chỉnh sửa , và sau đó import trở lại vào TFS để giữ lại bất kì sự thay đổi mà bạn
đã thực hiện.
Để tạo một danh
sách các work item list trong Excel và chỉnh sửa chúng:
1. Trong Microsoft
Office Excel, trên Team menu,
click New List.
2. Bên dưới Connect
to a Team Foundation Server, hãy chọn server để kếtnối đến, hay là click
vào Servers để enter vào thông tin của
server.
3. Bên dưới Team
Projects, hãy chọn team project trên Team Foundation Server mà bạn muốn
làm. Tài liệu này sẽ bị ràng buộc với
team project này.
4. Click OK.
5. Chọn loại danh sách mà bạn muốn. Để tạo một
danh sách truy vấn query list, hãy chọn Query
List option và sau đó chọn một team query từ danh sách drop-down Select a Query drop-down list.
6. Hãy chọn các column mà bạn muốn nó xuất hiện
trong danh sách mới các work item.
7. Import các work item mà bạn muốn. Để có thêm
thông tin, hãy xem How to: Import Work Items in Microsoft Excel or Microsoft
Project tại
http://msdn2.microsoft.com/en-us/library/ms181676(VS.80).aspx
8. Bây giờ bạn có thể chỉnh sửa các work item và
sau đó publish các work item đã cập nhật vào work item database bằng cách click
vào Publish Changes ở trên Team
menu.
Tài nguyên bổ
sung
- Để có thêm thông tin về việc sử dụng Microsoft
Office Excel cho các project-management
tasks, hãy xem "Working with Work Item Lists in Microsoft Excel" tại
http://msdn2.microsoft.com/en-us/library/ms181694(VS.80).aspx
Team Foundation
Project Management Resources
- Để có thêm thông tin về MSF process
templates, hãy xem "Process Templates" tại
http://msdn2.microsoft.com/en-us/teamsystem/aa718801.aspx
