At my workplace, we're using Tfs 2010 and CMMI 4.2.
I want to force the check-ins to have 3 types of reviewers.
If some developer check-ins some code, it must be reviewed by 3 senior developers for performance issues, error management issues and localization issues.
So I want to keep the change-set in some sort of pending state, until all reviewers approve the change.
I want to ensure that a change-set is approved due to that 3 aspects and then participate in the build.
Is it possible to have some pending change-sets, or some kind of workflow for check-ins?
Shelvesets are pretty much exactly what you are describing.
This is indeed how TFS 2012 does its own internal code review system. When you request a code review it simply puts it in a shelf. You also have other features when you create the code review, you can specify number of reviewers and who you want to do the reviewing. It might fit your needs.
Alternatively, a manual system utilising shelvesets may also work.
You can define required Check-in notes: "Senior reviewer 1", "Senior reviewer 2", "Senior reviewer 3". Then, in every check-in, the developer will have to fill-in names. Note that there's no hard enforcement - the dev can lie or type "NA".
TFS2012 has a code review system which can formally enforce this process. I don't know the details though.
Related
When checking in TFS under Work\Backlogs\Backlog items, any Sprint, I can see PBIs and linked tasks under them. However bugs I noticed are treated at the same level as PBIs, meaning I can never see a Bug under a PBI, but I can see a task under a Bug.
Is this because the understanding is that Bugs are an occurrence after PBIs are marked as "Done" in a future sprint (since all PBIs should have gone through testing until completely reviewed and accepted).
I'm thinking if this is the logic then Bugs in their own right are like a PBI - a new "Problem" Backlog Item lol.
We are getting confused because we at first wanted to see Bugs under PBIs or Tasks to see what the bug is associated with, but because a bug may occur from an assortment of development done in the future, it's treated as independent on the same level as a PBI. Am I understanding this correctly or is there a way to put bug under a PBI\Task in the backlog when viewing (I know you can link it as so, but I mean for viewing purposes in the backlog). Thanks.
You can configure team settings to set your team's preferences for tracking bugs.
To see Bugs under PBIs, you can select the option Bugs are managed with tasks under Working with bugs tab. See Show bugs on backlogs and boards for details.
On the board settings page, you can configure bugs display behavior.
They can be treated as Tasks, in which case they show as children of PBIs, at the same level as Tasks, and are displayed on the sprint board.
Or, they can be treated as Requirements, in which case they are shown at the same level as PBIs and can have Tasks created underneath them.
It sounds like you currently have the latter behavior enabled, but would prefer the former.
This is configurable at the Team level. You can configure one behavior or the other, but not both. This means that for a given team, bugs can either be Requirements, or they can be Tasks. They cannot be Requirements in some situations and Tasks in some others.
Also note that if you've upgraded from an earlier version of TFS, you may have to manually enable the feature, since it required some changes to the process templates that you or your TFS administrator may not have made.
Is there a way to set up TFS code reviews to be assigned to a random team member?
The motivation for this is that I believe that the team members often assign someone they discussed, or even pair programmed, a problem with. That reduces one of the benefits of code review, namely the spreading of knowledge. Some team members always select a colleague they're close with.
I do realize that there could be issues with the assignee being busy or out of office, but there might be other solutions for that.
I am currently on TFS 2013, but if it is possible in other versions, that is still of interest.
This could not be achieved for now, you should manually add reviewers.
And it's also hard to random assign the code reviewers. There are many limitations, some you have mentioned above. Another important thing, it's hard to determine whether the code reviewer have enough ability or familiar with the area of code under review.
A more easy and valid way is sending the review to a TFS group.Each team has at least a few senior developers that do code review on a regular basis, and you could set a rule such as a code review must be reviewed by two or three reviewers. However it's still on the backlog and there has been a related uservoice. You could vote up and monitor it.
Assign code review to a TFS group
https://visualstudio.uservoice.com/forums/330519-visual-studio-team-services/suggestions/4025842-assign-code-review-to-a-tfs-group
From a "process controls" POV, in a continuous delivery/deployment context, how important is it to mandate that source control commits are associated with an Agile PM (or ticketing tool) "work-item?" Here "work-item" means any of: user story, task, defect, bug, etc.
The end-goal is to ensure that developers are not placing new features into production that were not derived from the product owner. Obviously code reviews are a critical part of a proper process-controls story, but having a code review presumes the reviewer can look at the associated statement of work (e.g. user story) to ensure the code changes reflect the requested work.
Herein lies the issue.
Context
I've always assumed to have a workflow where work-tickets are associated with commits, such as with Jira, but now I'm working with a corporation whose PM tool is incapable of associating work-items or defect-tickets with source commits.
With this client, I'm also seeing a catch-22. First, I'm told by representatives of the PMO that such ticket-to-commit associations are not needed. Second, the engineering org paid for an outside consultancy to audit and flag major process flaws. The #1 flaw that was identified was the inability for management to know if developer commits have any bearing on authorized work.
From my POV, I think the PMO needs to realize that they are the "tail wagging the dog" and that they need to embrace tooling changes or special integrations to overcome this problem (not to mention more maturity with Agile philosophy).
However, perhaps I'm the one who simply is over-concerned about the ticket-to-commit associations, and perhaps there is another way to achieve effective process controls without that particular mechanism?
When dealing with regulated industries, such as health care or governing bodies, full traceability from scope to code is a requirement. I once had to perform an audit to validate that every line of code correlates to a line in the SRS for FDA approval, although generally it's enough to demonstrate that there exists a method of traceability (such as a branch in github that is named to match a task / story in JIRA and code integration is enabled).
If you're not in a regulated industry, requirement-to-code traceability is not a requirement... but it is still immensely helpful. The advantages include, and are not limited to:
Full transparency to everyone on the team, tech or not. The amount of confidence that this evokes is amazing, and the amount of chatter it reduces.
Reports to identify what theme in the requirements are causing the greatest amount of code churn, because there's a heavy cost to that.
Identifying features affected by a PR. This is immensely helpful when a release is planned, some aspects of the release are unattainable or buggy, a lot of the code has already been merged, and the team needs to isolate what to release and what not to.
Confirmation of an opinionated truth by remove the opinion: "I'm sure I did it... let's double check... yup! (or oops, let's rectify that!)". This helps deter CYA behavior, which is drain on morale and negatively influences efficiency.
Simple implementation with existing mainstream toolsets (JIRA, Trello, Asana, Freshdesk for tickets... Github, Bitbucket for repo and tickets... Zapier, IFTTT for integrations across systems that lack built-in integrations)
For every team I have ever managed or established (as dev manager, PMO, product manager, consultant or founder), it has been my explicit expectation that every line of code can be traced to the requirement for the reasons listed above. I advocate implementing this using the branch-per-topic pattern in git (Github or Bitbucket), where the branch is prefixed by the JIRA task/story/bug (eg. XYZ-2443-fix-that-bug) so that JIRA's integration automatically displays a link of the branch to the issue.
Of course, this is not the only way, but it is my preferred process at this time and is meant to illustrate a concrete example.
My team is asking me to add all these states in the PBI workflow.
New,
Prioritization,
Design,
Business Review,
IT Review,
Approved,
Committed,
In Development,
Development Done,
QA Testing,
Ready for UAT,
Released to UAT,
UAT Testing,
Available in UAT,
Ready for Production,
Released,
Reopen,
Resolved.
I know that we can accomplish the same by using Tasks or Reason field and we have to keep the workflow "Simple" but my team is insisting to track that using a single field (State) so that it is clear. I would like to know if it is a good idea.
I appreciate your thoughts and feedback.
We can't say how many states are reasonable or best. TFS is extensible and customizable, it is designed for customers will be able to meet the needs of the organization.
But as we know, the more states you define, the more transitions you must define. The maintenance and further upgrades will be more complex. Changing the workflow states of work items, specifically those in the task and requirement category can cause unexpected challenges in existing functionality as well as future upgrades. Changing to requirement types (Product Backlog Items and Bugs for Scrum, User Stories for Agile and Requirements for CMMI) will require modification of the Agile or Kanban board. They will also most certainly prevent an automatic easy template upgrade.
Customization should be well-thought out, instead of changing the existing State field, you may consider add a new "customStatus" field which won't impact existing reports and upgrades.
A good blog for your reference: http://blog.nwcadence.com/tfs-customization-pitfalls-payoffs/
This is another option for you to think about but you don't necessarily need to amend the states. You could use Board Columns which can be set on the Kanban board. With each column, you can optionally choose to split containing a Doing and a Done which could mean you require less states.
You can then query on Board Column instead of State
I was in a similar scenario to you when setting up our TFS (although not with as many states requested!) and I ended up going with Board Columns. Here is ours, it seems to work for us:
All of these have no split with the exception of In Development because when development is done it is not necessarily ready for test.
This functionality came with TFS 2015 Update 1 so you would need to upgrade if you're not on that version.
Here is how we use each state:
New - New PBI or Bug
Approved - Confirmed the work will be done and complies with the DOR (Definition of Ready)... (Contains enough info, priority assigned, tasks created, test plan created etc)
Committed - Assigned to a future sprint
In Development - Contains a Doing and a Done
In Test - QA
Ready for Release - Signed off and ready for release
Done - Released and DOD (Definition of Done) has been completed.
So far, I've been using TFS only as task management, but never as an time report nor ticketing system. I've been using third party software for each. I want to use more out of TFS if possible to include these reports too.
Is TFS able to handle ticketing system good?
And what about time reports?
What templates can I use for these reports?
Is it be ok to give customer access to TFS to add bug reports?
First of all, any of the work items can be customized. Secondly, in many cases, someone probably has done so already.
I would think it would be good for this. Consider that it already has the ability to have a bug filed against software; have it assigned to a developer; and to record when it's fixed. The Bug work item already keeps track of time (if you fill that in).
I'm not certain about allowing customers in. I suggest you look in to the Web Access for that. You might have to maintain actual Domain accounts for the customers.
Our TFS is one mother-ship where we have our source repository, do our automatic builds/CI, manage our Product and Sprint backlog items (dev task items), and manage bugs - like you would using any full scale bug tracking system like bugzilla or jira (if that is what you meant by a 'ticketing system' - if by ticketing system you meant something like BMC Remedy, then its a different ballgame).
Our firm follows agile methodology and we use Conchango Templates which in my opinion is great for agile shops. Its highly customizable and is easy to learn/follow. As far as reports are concerned, these templates generate reports per day, per project, per team, per person by month, year and all that jazz... depends on what you really want.
Regarding giving customers access, it totally depends on your and your network admins comfort level.
Hope this helps...