1. During permissions testing .... always make sure that at least 2 of TFS admins are full admins on the TFS server and in the TFS security settings.
2. Define the security groups you want for TFS.
3. Create these groups as Windows groups on the server that's running TFS.
4. Create corresponding TFS server groups for these Windows groups and assign one member (i.e. the Windows group) to each of these TFS server groups (see first 2 snapshots).
5. Create team project security groups and by default assign TFS server groups as members of these groups (see 3rd snapshot).
6. Assign security permissions by team project security group at the Team Project level or at the Area levels.
7. On the Windows server, assign roles/permissions for SQL Server Reporting Services that correspond to the Windows Server groups you've created.
8. On the Windows server, assign roles/permissions for Windows SharePoint Services that correspond to the Windows Server groups you've created.
9. Remember to "keep it simple". Think of having a handful of Windows server groups that correspond 1:1 with TFS server groups that in turn correspond 1:1 with Team Project groups. Then in turn these Team Project groups have all the team project level and areas' security permissions based back on those Windows server groups as the standard. Anything else should be thought of as an exception. What this will do is handle the cascading of all permissions for SharePoint, SQL Server Reporting Services and TFS throughout all the services associated with TFS/SharePoint.
Warning: It can be disastrous to NOT "keep it simple". And keep in mind that this article assumes you are running a single server solution with all the databases and web front ends on the same Windows server.
Friday, February 27, 2009
Wednesday, February 25, 2009
Questions every CEO should ask their CIO
What plaform do you use to provide real-time integration of all information on source code control, source changes, builds, tasks, bugs, issues, project plans, documentation, test scripts and metrics reporting?
How are your project managers aware of all saved code changes in other projects that may regressively impact their projects?
How many minutes would it take you to find out what specific code changes were made in relation to an invoice line item charged to a customer?
How many minutes does it take your organization to start tracking new metrics and have reporting procedures in place at both the high-level project and low-level task detail levels?
They should have a definitive answer or plan on the first two questions. And they should be able to say a very small number as the answer on the second two questions. If the answer isn't TFS then I'd like to know what it is.
How are your project managers aware of all saved code changes in other projects that may regressively impact their projects?
How many minutes would it take you to find out what specific code changes were made in relation to an invoice line item charged to a customer?
How many minutes does it take your organization to start tracking new metrics and have reporting procedures in place at both the high-level project and low-level task detail levels?
They should have a definitive answer or plan on the first two questions. And they should be able to say a very small number as the answer on the second two questions. If the answer isn't TFS then I'd like to know what it is.
TFS Learning Curve for Project Managers
TFS often comes with a steep learning curve for project managers, CIO(s), CTO(s) and others in business and IT management. This is unnecessary if approached correctly. One word describes the key in overcoming this barrier. It's SharePoint.
Show TFS and VSTS to developers, DBA(s) and other techies and you'll see them get excited and see the magic of having a one-stop place to do all their work in Visual Studio. Show VSTS to project managers and you'll often see blank stares and confusion as they imagine that this new tool is only going to give them more headaches and work to do. The facts are that TFS was designed with the intent of making life easier for the IT technical workers, especially those who have worked with Visual Studio. Its much like why Boeing and Airbus design cockpits with the needs of airplane pilots in mind rather than the realtime needs of their management back in the office building. During airplane takeoffs, landings and emergency crash landings the last thing a pilot needs is to be called out of the cockpit to file some status report that some office building manager deems as necessary to help them do their job. Well that's how techies often feel about their management. And that's why nearly all project teams and IT organizations struggle with communication.
In my opinion the best way to get Project Managers up/running with TFS is to not tell them they're using TFS. Approach it as a SharePoint site deployment. Setup your Process Template to include the libraries in SharePoint they need to get the starting Project/Excel files they'll need to do their job, the Word templates for documentation/processes, process guidance, reports and organizational links. Get them very familiar with SharePoint.
Once they know SharePoint well enough to be productive then show them how to use some of the tools they'll need to access TFS work items. Start with MS Excel by launching some of the Excel files in the SharePoint libraries that come out of the box in a Team Project site. Train them on how to use Excel with TFS work items. Then show them MS Project with TFS work items. Then show them the reports they can get. Finally introduce them to TSWA, Team Explorer and other tools that can help them see how work items integrate with version control files and builds.
Show TFS and VSTS to developers, DBA(s) and other techies and you'll see them get excited and see the magic of having a one-stop place to do all their work in Visual Studio. Show VSTS to project managers and you'll often see blank stares and confusion as they imagine that this new tool is only going to give them more headaches and work to do. The facts are that TFS was designed with the intent of making life easier for the IT technical workers, especially those who have worked with Visual Studio. Its much like why Boeing and Airbus design cockpits with the needs of airplane pilots in mind rather than the realtime needs of their management back in the office building. During airplane takeoffs, landings and emergency crash landings the last thing a pilot needs is to be called out of the cockpit to file some status report that some office building manager deems as necessary to help them do their job. Well that's how techies often feel about their management. And that's why nearly all project teams and IT organizations struggle with communication.
In my opinion the best way to get Project Managers up/running with TFS is to not tell them they're using TFS. Approach it as a SharePoint site deployment. Setup your Process Template to include the libraries in SharePoint they need to get the starting Project/Excel files they'll need to do their job, the Word templates for documentation/processes, process guidance, reports and organizational links. Get them very familiar with SharePoint.
Once they know SharePoint well enough to be productive then show them how to use some of the tools they'll need to access TFS work items. Start with MS Excel by launching some of the Excel files in the SharePoint libraries that come out of the box in a Team Project site. Train them on how to use Excel with TFS work items. Then show them MS Project with TFS work items. Then show them the reports they can get. Finally introduce them to TSWA, Team Explorer and other tools that can help them see how work items integrate with version control files and builds.
Thursday, February 5, 2009
Essay on Team Foundation Server Capabilities
Team Foundation Server (TFS) provides all the capabilities to fully manage the full software development lifecycle (SDLC). I've successfully implemented it in several environments and seen it perform well in meeting the needs of an IT organization. I've yet to run across any scenario for software development in a Windows-based environment (i.e. not counting Macs, Unix, etc.) where TFS couldn't be used effectively.
Out-of-the-box TFS fully implements the CMMi-3 and Agile Scrum methodologies. Implementing it for an organization is just a matter of starting a new TFS Team Project, setting up a list of tasks in the TFS Work Items catalog to accomplish the organizational mandates and setting up organizational folders & document templates in the team project SharePoint portal site that gets auto-generated when a new TFS team project is created. If an organization seeks to invest in automating the project launch/management process then one of the out-of-the-box TFS process templates can be customized/imported into TFS so that whenever a new team project is created that all the organizational mandates will be there (i.e. document templates, work items, workflow, control policies, reports, etc.).
TFS is a back end for IT project workers using Visual Studio in the same way that MS Exchange is the back end for end users using Outlook for email. There are 4 primary editions of Microsoft Visual Studio Team Suite (VSTS) for developers, architects, testers and database modelers/administrators. Learning/using the TFS capabilities in Visual Studio is quite intuitive for those already familiar with the Microsoft Visual Studio platform. In fact TFS was specifically built with Visual Studio users in mind.
Some of the key TFS features are:
(1) Robust work items tracking is provided. Each work item has attributes (i.e. Fields, Columns) to store information such as Title, Description, Iteration, Area, Discipline, AssignedTo, Priority, Hours Completed, Hours Remaining, Start Date, End Date, Related Builds, Related Work Items, related Version Control Items, related Version Control Changesets, Hyperlinks, Attachments, etc. The attributes available depend on the work item type (WITs). For the Agile process template the WITs are QoS requirements, bugs, tasks, scenarios, and tests. The CMMi process template includes Requirements and Review WIT's. The Process Template Editor can be used to create/modify WIT templates in order to allow you to track almost anything in a work item and to setup workflow rules/procedures with the work items of these WIT's.
(2) Robust version control using true client/server and web services technology. The TFS version control data is stored in SQL Server. Earlier version control systems such as SourceSafe and PVCS are much like dBase or ISAM files where data corruption, uncleared locks and other processing errors are more commonplace. That's because these legacy products have no true, reliable client/server processing. Performance is noticably improved in TFS over SourceSafe. Features such as shelving, changesets processing, branching, merging and reporting are quite effective/useful in TFS.
(3) SQL Server Reporting Services is used by TFS. There are about 2 dozen reports out-of-the-box that meet most project management needs. Reports can be created/modified to meet the needs for a specific project for the organizational purposes. A data warehouse that integrates all the version control, project management, work item tracking, attachments, builds, integration and reporting information is provided. Its cubes with measures/dimensions are auto-refreshed according to a configurable schedule.
(4) Microsoft Excel and Microsoft Project integrate well with TFS. Its easily possible to add/edit work items in these tools for any TFS team project. Project plans can be generated in MS Project and imported into TFS. To Do lists can be created in MS Excel and imported into TFS. Or to do lists or checklists can be copied/pasted into Excel from some other program in order to create TFS work items.
(5) A SharePoint portal site is created for each new TFS team project. In this portal a user on the team (or in the management & project users communities) can participate with as limited/open collaboration functionality as needed. The documents/reports available through Visual Studio (or other front ends using TFS data) are available in this portal. All WSS 3.0 functionality/capabilities is available in each TFS team project portal site.
(6) TFS Build Management is versatile glue for marrying programming/testing, bugs/resolutions, development/maintenance and implementations together. As many build projects as needed can be created for a team project. Build parameters such as schedule, build machine, destination, source code snapshot, notifications and build errors handling can be made out-of-the-box. As work items for bugs, development tasks, tests, etc. are completed then builds where the bugs were found or resolved will be related.
(7) TFS is fully extensible. All features are available in .NET namespaces and/or server configuration utilities where customizations, extensions and integration with any application/process/workflow can be made. The market is starting to see many TFS third party tools being built for purposes such as timesheet entry, task time tracking, resource planning, status reporting, integration with CRM/ERP suites, integration with accounting systems (i.e. GL, AP, AR, OE, etc.), integration with system admin utilities, etc. are being performed. Developers building apps in platforms such as Java, Oracle, Mainframes, etc. can still use TFS thanks to the extensibility capabilities of the TFS core.
(8) Security can be handled at the server-level, team project level or area level. In each team project a hierarchy of areas can be created. It can be as simple as one node or as complex with N-generations of M+ nodes per generation or however complex the security needs are for a team project to restrict/grant access to read/edit information or grant/revoke rights at the server, team project or area level. Just a FYI that there is an Area attribute for each work item in TFS and only an end user with change rights on both the old Area and new Area can change a work item's Area. Also keep in mind that the rights assigned at root node levels trickle down to their children/leaf nodes. And at any server/project/area node the rights can be assigned to either a TFS user or a TFS group. A TFS group is a collection of Active Directory users and/or Active Directory groups that has been created at the server level or at the team project level. This security model can handle any realistic security requirement for all enterprise-wide SDLC processes. However an important thing to keep in mind is that the server-level administrators can get access to ALL data on the TFS server where they have server-level access. Its also important to remember that a VSTS user (or any Excel/Project/SharePoint/3rd party user of TFS) can use multiple/unlimited TFS servers at the same time without incurring extra per-seat costs for Visual Studio and CAL’s.
(9) Perhaps the greatest feature of TFS is how well it integrates the core SDLC processes elements contained therein - work item tracking, version control, build management, reporting and external integration. One example on how well this works is the need to set a policy that developers will regularly report what tasks they're working on and what code is associated. In this case a policy can be established that a developer can only checkin changes by first associating work item(s) and entering changeset comments. In addition as every checkin/change is timestamped its possible to provide very robust/detailed time/effort reporting. Rules can also be put in place (out of the box for simple rules, customize for complex rules) to immediately notify certain users when certain events occur such as a user reporting a bug, a build not being successful, certain work items being marked as "done", critical path tasks not being done in time, certain versioned items being checked in or someone making a change to work items assigned to you.
If you have any other questions on TFS then please let me know.
Out-of-the-box TFS fully implements the CMMi-3 and Agile Scrum methodologies. Implementing it for an organization is just a matter of starting a new TFS Team Project, setting up a list of tasks in the TFS Work Items catalog to accomplish the organizational mandates and setting up organizational folders & document templates in the team project SharePoint portal site that gets auto-generated when a new TFS team project is created. If an organization seeks to invest in automating the project launch/management process then one of the out-of-the-box TFS process templates can be customized/imported into TFS so that whenever a new team project is created that all the organizational mandates will be there (i.e. document templates, work items, workflow, control policies, reports, etc.).
TFS is a back end for IT project workers using Visual Studio in the same way that MS Exchange is the back end for end users using Outlook for email. There are 4 primary editions of Microsoft Visual Studio Team Suite (VSTS) for developers, architects, testers and database modelers/administrators. Learning/using the TFS capabilities in Visual Studio is quite intuitive for those already familiar with the Microsoft Visual Studio platform. In fact TFS was specifically built with Visual Studio users in mind.
Some of the key TFS features are:
(1) Robust work items tracking is provided. Each work item has attributes (i.e. Fields, Columns) to store information such as Title, Description, Iteration, Area, Discipline, AssignedTo, Priority, Hours Completed, Hours Remaining, Start Date, End Date, Related Builds, Related Work Items, related Version Control Items, related Version Control Changesets, Hyperlinks, Attachments, etc. The attributes available depend on the work item type (WITs). For the Agile process template the WITs are QoS requirements, bugs, tasks, scenarios, and tests. The CMMi process template includes Requirements and Review WIT's. The Process Template Editor can be used to create/modify WIT templates in order to allow you to track almost anything in a work item and to setup workflow rules/procedures with the work items of these WIT's.
(2) Robust version control using true client/server and web services technology. The TFS version control data is stored in SQL Server. Earlier version control systems such as SourceSafe and PVCS are much like dBase or ISAM files where data corruption, uncleared locks and other processing errors are more commonplace. That's because these legacy products have no true, reliable client/server processing. Performance is noticably improved in TFS over SourceSafe. Features such as shelving, changesets processing, branching, merging and reporting are quite effective/useful in TFS.
(3) SQL Server Reporting Services is used by TFS. There are about 2 dozen reports out-of-the-box that meet most project management needs. Reports can be created/modified to meet the needs for a specific project for the organizational purposes. A data warehouse that integrates all the version control, project management, work item tracking, attachments, builds, integration and reporting information is provided. Its cubes with measures/dimensions are auto-refreshed according to a configurable schedule.
(4) Microsoft Excel and Microsoft Project integrate well with TFS. Its easily possible to add/edit work items in these tools for any TFS team project. Project plans can be generated in MS Project and imported into TFS. To Do lists can be created in MS Excel and imported into TFS. Or to do lists or checklists can be copied/pasted into Excel from some other program in order to create TFS work items.
(5) A SharePoint portal site is created for each new TFS team project. In this portal a user on the team (or in the management & project users communities) can participate with as limited/open collaboration functionality as needed. The documents/reports available through Visual Studio (or other front ends using TFS data) are available in this portal. All WSS 3.0 functionality/capabilities is available in each TFS team project portal site.
(6) TFS Build Management is versatile glue for marrying programming/testing, bugs/resolutions, development/maintenance and implementations together. As many build projects as needed can be created for a team project. Build parameters such as schedule, build machine, destination, source code snapshot, notifications and build errors handling can be made out-of-the-box. As work items for bugs, development tasks, tests, etc. are completed then builds where the bugs were found or resolved will be related.
(7) TFS is fully extensible. All features are available in .NET namespaces and/or server configuration utilities where customizations, extensions and integration with any application/process/workflow can be made. The market is starting to see many TFS third party tools being built for purposes such as timesheet entry, task time tracking, resource planning, status reporting, integration with CRM/ERP suites, integration with accounting systems (i.e. GL, AP, AR, OE, etc.), integration with system admin utilities, etc. are being performed. Developers building apps in platforms such as Java, Oracle, Mainframes, etc. can still use TFS thanks to the extensibility capabilities of the TFS core.
(8) Security can be handled at the server-level, team project level or area level. In each team project a hierarchy of areas can be created. It can be as simple as one node or as complex with N-generations of M+ nodes per generation or however complex the security needs are for a team project to restrict/grant access to read/edit information or grant/revoke rights at the server, team project or area level. Just a FYI that there is an Area attribute for each work item in TFS and only an end user with change rights on both the old Area and new Area can change a work item's Area. Also keep in mind that the rights assigned at root node levels trickle down to their children/leaf nodes. And at any server/project/area node the rights can be assigned to either a TFS user or a TFS group. A TFS group is a collection of Active Directory users and/or Active Directory groups that has been created at the server level or at the team project level. This security model can handle any realistic security requirement for all enterprise-wide SDLC processes. However an important thing to keep in mind is that the server-level administrators can get access to ALL data on the TFS server where they have server-level access. Its also important to remember that a VSTS user (or any Excel/Project/SharePoint/3rd party user of TFS) can use multiple/unlimited TFS servers at the same time without incurring extra per-seat costs for Visual Studio and CAL’s.
(9) Perhaps the greatest feature of TFS is how well it integrates the core SDLC processes elements contained therein - work item tracking, version control, build management, reporting and external integration. One example on how well this works is the need to set a policy that developers will regularly report what tasks they're working on and what code is associated. In this case a policy can be established that a developer can only checkin changes by first associating work item(s) and entering changeset comments. In addition as every checkin/change is timestamped its possible to provide very robust/detailed time/effort reporting. Rules can also be put in place (out of the box for simple rules, customize for complex rules) to immediately notify certain users when certain events occur such as a user reporting a bug, a build not being successful, certain work items being marked as "done", critical path tasks not being done in time, certain versioned items being checked in or someone making a change to work items assigned to you.
If you have any other questions on TFS then please let me know.
Subscribe to:
Posts (Atom)