Can someone tell me please if is a good idea to use TFS as ticket manager for end users and in the same time as backlog for team developpers?
Not totally sure which kind of ticket manage system you are referring. For tickets, if you mean the ones raised by the end users of an organization whenever they encounter an event that interrupts their workflow.
Then seems you are looking for a helpdesk ticketing system, acts as a documentation of a particular problem, its current status, and other associated information. These tickets are routed to a ticketing software where they are categorized, prioritized, and assigned to different agents according to the organizational norms.
The agents then analyze these tickets and suggest appropriate fixes or workarounds and resolve the issue. As a central repository of all these tickets, an IT Ticketing Software helps in providing the context of the issue history and its resolution.
Then to be honest, this is not what TFS should do. You may have to look for some other system to handle this.
TFS provides integrated tools to support collaborative software development, including Git repositories, continuous integration and continuous deployment (CI/CD), and interactive Kanban boards.
You could also collect bug/feature request and related info from end users, then track them in TFS.
But it's not suggest to let them directly access your TFS system and fire work items by themselves. Cause you need to assign them license and corresponding permission.
TFS fully supports bug tracking and traceability though the code that was changes.
Create your product backlog
The out of the box bug work item is specifically designed to work with the test tools and the planning tools. Besides, you could also use them and add a few customization to meet your requirements.
If you want to use the TFS for the ticketing system. you need create task as a bug /Task in the child link for that particular backlog item or feature. Each task / Bug has to be tracked based on the sprint.
Related
What we know:
Tfs allows us to manage bugs. We can add bugs and move it through different states.
What we need:
We need to have different states in bug, which TFS 2015 doesn't allow out of the box, particularly
"Not a Bug" (which is after NEW > ACTIVE and then if Developer says, its not a bug)
"RE-Opened" (where a bug has traversed from NEW > ACTIVE > RESOLVED > CLOSED and then Re-Opened in another Release / Sprint).
Which approach mentioned below we could use ?
A- We are currently on TFS 2015. We do the customization through WITAdmin approach (https://www.visualstudio.com/en-us/docs/work/customize/add-modify-field ) and it's impact on Database, Reporting and going forward, towards migration would be another effort.
B- We migrate our TFS 2015 to TFS 2017 and get the new feature of adding our new states out of the box as per (https://www.visualstudio.com/en-us/docs/work/process/customize-process-field#add-a-custom-field)
C- We need to change our practice of logging bugs, and we need to study proper Agile Implementation through TFS, since AGILE process does have this scenario of What We need mentioned above.
A,B,C are the approaches, I have thought about. I would appreciate if the experts could share their experiences, thoughts and / or new approaches.
The "States" that you want to add should not be States, but at most "Reasons". You will find default reasons set that are close to what you want out of the box.
Since for the Agile Planning tools to work you need to have the same states for Bug as either User Story or Task depending on your configuration there are much wider ramifications to adding additional states. Try and avoid it.
Use A to add additional Reasons for specific transitions, and focus on C for the long term.
Approach B only exists in Visual Studio Team Service, TFS 2017 doesn't have this feature currently.
Approach A will be a good option. But you might need to modify your custom process for the wizard to run, or you might have to update your team project manually after a TFS upgrade.
Check more information of Maintenance and upgrade implications (TFS) on the website below, which tell us what should we avoid during customizations:
https://www.visualstudio.com/en-us/docs/work/customize/customize-work#maintenance-and-upgrade-implications-tfs
Different developers check in the code touching the same file or different branches could be getting merged. I am new to TFS from the admin side but I do know how to do basic check-in of the code. How can I avoid the code collision from admin side? We are using Microsoft Team foundation server as version control.
Version control systems are made to allow different users to edit the same files and so that when merging, it provides a reasonable experience upon merge. The ability to check out the same file by multiple developers is one of the things that allows teams to become highly productive. When multiple versions of the same product are being developed or maintained, it's impossible to prevent conflicts altogether.
There is a lot of additional guidance available through the ALM RAngers' guides. I highly recommend you and your developers read this.
Note:
Visual Studio 2013 offers a much better merge experience than older versions. 3rd party tools like Semantic Merge further improve the experience by parsing the code being merged and applying some additional intelligent logic to prevent conflicts.
For certain notoriously hard to merge files, like SSIS packages, there are additional specialist tools such as BIDS Helper Smart Diff.
Some things you can do:
Make sure developers communicate
Teams that do a daily scrum (stand-up meeting) or have the ability to use Team Rooms in TFS can signal intent and keep others up to date on what they're doing pro-actively. Making sure that there is a dedicated communication channel available and that the users have the Team Rooms extension installed in case they're not co-located. Communication prevents many of these type of issues and is the best solution once such a merge issue occurs.
Have developers perform a get-latest and check-in frequently
While there is no server setting for this, having your developers trained on branching, merging and general source control patterns can help a lot. If a user regularly checks for incoming changes (get latest) and checks in as soon as he is relatively confident about his code (say after the first test passes when using TDD), then chances of conflicts is substantially lower.
The Incoming Changes Lens
Codelens has been updated with a new Lens as one of the updates that was released after RTM. The lens requires both the Client and the Server to be upgraded to at least Update 2 and at least Visual Studio 2013 Ultimate Update 2. It's recommended that when you start applying the Updates, you always stay current, thus I'd recommend you install Update 4.
While Code Lens is an Ultimate feature, it will be moved into Professional with the release of Visual Studio 2015.
Use Exclusive Checkout
If users use the Checkout and lock option to check out a file, they can signal other users that the file is undergoing major changes. This feature requires that all users have their workspace type set to "Server Workspace". Local workspaces, given their disconnected nature, ignore the Lock flag. Though individual users can always override their workspace type, it is possible to set the default workspace type at the collection level.
Disable Merging and Multiple checkout for individual file types
A better solution is to mark file types that are hard to merge, the old style SSIS packages with lots of XML and GUIDs are agood candidate here. Open the Source Control settings and add the extensions of "bad files". This setting applies partially in Visual Studio regardless of the workspace setting (Visual Studio will only offer Take Local or Take Server and will not offer to merge.
Disable Multiple Checkout
It is possible to set the Project's Source Control option not allow "Multiple Checkouts", this will automatically acquire a Lock when a file is checked out. It's not recommended to turn this feature on, as it introduces a lot of frustrating things while working in Visual Studio (most importantly when adding any file, one has to acquire a lock on the project file). As with Exclusive Checkout, this requires all users to use Server Workspaces.
As this feature will prevent any file from being checked out by multiple people, it's often trying to apply way to much force to solve this issue. Only in case your developers mess up on a high frequency, you may enable this feature temporarily while they receive training.
I currently work in a company that uses FogBugz for issue and bug tracking and SourceGear Vault for source control.
We are now introducing Team Foundation Server. Clearly TFS will replace Vault for source control. My question is, with the following requirements:
Large existing base of FogBugz cases (some obviously open) that we need to support ongoing
Support desk needs to be able to raise bugs / support calls
Want changes to source to be linked to a case number
... what is the best split between using FogBugz cases and TFS WorkItems?
Is it possible to totally migrate from FogBugz to TFS?
If it is not possible to migrate from FogBugz to TFS then what is the best way to use the FogBugz case and TFS workitems together?
Initially I'd say bugs and defects stay in FogBugz, stuff on the project plan as work items. You could manually get the developers to create a work item for each case in FogBugz and associate the code with that work item but I can hear the howls of derision already :-)
You might want to take a look at the TFS Integration platform. I don't know if there are any tools that link directly to FogBugz but these tools are highly extensible. You could then decide to either migrate everything in to TFS or run both systems and synchronise. Running both is nice as each discipline can use the tool they are most familiar with, devs use TFS for everything and the testers / support can continue to use Fogbugz and the toolkit keeps everything in step.
I finally was able to complete the installation of TFS and started the creation of my first team project which introduced me to the process template.
After following to the link to Microsoft's site for process template information I was inundated with new information to consider. What templates have all of you had experience with that either worked out very well for you or were more of a stumbling block to the project? What were the biggest advantages and disadvantages you've encountered?
Some information about my project, I'm the lead developer for a small company and will be using TFS/VSTS to create an intranet portal to consolidate the end users day to day and increase automation to enhance productivity etc. It's entirely new development taking advantage of C#, ASP.NET and SQL Server 2008.
Ideally I'd like to take advantage of features to enhance collaboration with the stake holders to help add desired features and to track the status of development and offer feedback etc. I was also looking to take advantage of JetBrain's TeamCity for my TFS so if any specific template / software really adds cohesion between TFS, TeamCity, Developers, and Stakeholders that would be ideally what I'm interested in.
Are you already using a software development process like scrum? If yes you can try this Team Process Template over here.
How large is your project team and the project? Microsoft has published one of it's internal Process Templates (MPT) over here. You can get some guidiance and inspiration from this template.
As tangurena mentioned. People use the standard templates, change the bug a bit and store some documents there. I would recommend to keep the process 'light' as well.
However the process template isn't all.
Here are some ideas what I would do (in your case):
Create some high order workitems (features/stories) which stakeholdes can create (constraints and TFS user groups are your friend). They can then access their requested features via the TFS Work Item Web Access. That way you don't need a CAL for them
Create some reports which show planned work accodring to releases.
Setup the build automation and create Reports (a.k.a. Release Notes) from your workitems according to the builds.
What were the biggest advantages and disadvantages you've encountered?
Imho the biggest disadvantage is that you start believing that the template is your silver bullet. It's not, it's your starting point.
The TFS ecosystem offers you alot opportunities to create own bits of software that fit your needs. Just check out the TFS API.
Here is another nice agile-based template (original is on SSW, but you have to get around a login wall).
This template helps enhance cohesion between developers, managers, and other stakeholders by including more robust support for project process (documentation, reviews, &c., &c.). For example, there are types built in for process elements like release plans.
In general terms, I'd favour as small a process as you can manage. The more states, the more fields you have, the more likely the information in them is just plain wrong.
We're running with our own version on the Agile template. Most of what we did to it was delete stuff.
You can use the TFS API to log builds into the database, which should enable you to bridge TeamCity and TFS. Other than that, I'd probably just go with the web interface that comes with TFS, I don't think you need third party software for this.
K.I.S.S.! I created a custom work item based off the Agile one. And thats it, just one work item. There is a "System Severity" that IT uses and a "Business Priority" that the client/customer uses. There is also a "Request Type". With those three along with the built in Area and Iteration the entire team, including the clients can query the work items to get only the items they care about for the release they are concerned with (or all of them regardless of the release).
I did not modify the state machine much at all. This left us with something that is very flexible for everyone. Everything from blue sky requests to the mundane content/visual bugs can be logged there.
The client uses TFS Web Access (unlimited CAL) and the devs (me and 1 other) use VS. At my last job I created the same setup, the dev team was a team of 5 and it worked even better there! I was dev lead there as well and technical PM.
The biggest advantage was having a very flexible system for everyone, when using 1 work item type for everything. The disadvantage would be a learning curve for the client, but once they knew how to use it most like it. A suggestion would be to look into cheaper tools out there for a similar implementation, but, our .edu discount with MS cant be beat.
I would have to say that you must identify the system you will use for your company's SDLC first. The process template is merely a tool and without a good understanding of the underlying process it will not help and can make things more difficult. User adoption is crucial to the success of the SDLC and process template.
We use Scrum for Team System. We chose this due to our experience with Scrum as an SDLC methodology. There are several excellent books and articles on the web to help you get up to speed. Scrum will tie together the business stakeholders into the process.
In our system the Product Manager is in total charge of Product Backlog Items and works with myself and the CTO to prioritize them into Sprint Backlog Items.
The only change we have made to the process template was to add a "Failed Test" state and corresponding workflow.
It might not be the best template for you but I still wanted to mention it here: XP for Team System. It is basically a simplified version of MSF for Agile Software Development:
[...] it removes some of the setup tasks that an XP project will probably not want to undertake and changes the Work Item Type name Scenario to Story.
My company are imposing Jira and Zephyr on us for defect tracking and test management. We're quite happily using TFS 2008 for both these jobs at the moment, but management have never let the fact that something isn't broken stop them from trying to fix it.
Are there any tools/plug-ins that will allow us to synchronise between the remotely hosted repositories and our in-house TFS server?
Probably too late, but the company might want to look at the new features for bug tracking and manual tests coming in the 2010 release. Nice as Jira is, I doubt it will integrate well with the historical debugger and the ability to include a video of the test, as well as information on the test environment, and have it all be part of the work item.