My boss come with a very unique requirement, below is the explanation.
Imagine there is 10 user for a particular project team.
And the work flow is like
Documenting -> Review -> Publish
Now, the requirement is like below.
If I create Ticket with Summary "Version 1.0 Documents" with the above explained workflow, then it should also allow us facility to manager for user regarding each state of workflow like
Documenting assign to User A
Review Assign to User B
Publish Assign to User C
Note: I know I can assign ticket to individual user while changing state, but I want something pre-planned so as soon as I change status of ticket it will automatically assign to user.
I know I can do this using post action of transaction but what I want is, the assignee should be specified at creation of ticket as the same workflow going to use by many project and ticket, and every project will have different team
So , I need something add-on which allow me to manage team for each ticket.
Also, User C should be able to see his/her upcoming work if ticket is in any previous state i,e Documenting or review.
I suggest you should create account role for this and group to each department/team for their flow. you can use account role for separating their works then the department/team is useful for which members/users can see the particular issue/ticket. we already build something like this we have 3 account roles each ticket so i can say this is possible. if you still have question just let me know thanks.
Related
I am running Azure DevOps 2019 RC1 with an Inheritance Collection and a new Agile project.
I have a requirement that when a user creates a work item (task/issue), they must automatically be added as a follower of this work item. How can I achieve this? I have look in the rules for the work item under process customisation but it doesn't appear to be possible this way.
We are using the tickets to track issues. Whoever discovers the issue raises the ticket. The basic requirement is that anyone who raises a ticket should be automatically notified of its progress, even though they are not responsible for the development or testing.
Currently the work around is telling the user that when they create an issue they must click the Follow button, but it is easy for them to forget and then lose their updates. It seems like a very simple customisation so maybe I'm missing the obvious.
Thanks
I think you can't auto follow things currently, but you can add notification setting that will send automatically emails when work item is updated. To do this, go to Project Settings > Notifications page and create new subscription. Select "Work/A work item is changed" and put "Members of ... team by role" in Deliver to selection. Set roles to "Created by" and untick the "Skip initiator".
Your problem would be addressed precisely with the feature requested in the official Azure DevOps' feedback platform here:
479189 - Automatically follow work items I interact with
(That page also mentions workarounds, including per-team one answered here, and a per-person alternative. See this comment. The shortcoming of both is that they don't allow to you to unsubscribe for selected tickets.)
We have 6 people on the project team: 1 Tech-lead and 1 Assistant Tech-lead.
In our branch policy we want to require that only the Tech-lead or Assistant Tech-lead can approve the pull request. We only need approval from one of them to avoid a bottleneck if the other one is on leave.
The problem is there are only 2 choices in the branch policy settings:
Specifying the number of required approvers (which will not work since normal developers would be able to approve as well)
Specifying the actual person to approve (which will not work since both of them will be required and cause a bottleneck when one is on leave)
Can someone please point us in the right direction?
You can provide required reviewers that are automatically added to each PR. These reviewers can also be groups.
Do this:
Create a group that contains your tech lead and assistant tech lead and.
Make that group a required approver under Automatically include code reviewers
You should get something like this:
Your statement normal developers would be able to approve as well is only true if the group that is required contains your normal developers.
This way at least 1 person from provided group (in this case Developers) must approve a PR. If you want you can also provide a path filter to require only reviews on certain changes or assign a different group for files or folders.
for those who are on Bitbucket:
These are available under Repository Settings->Workflow->Branch Permissions
I'm currently working on a project with a small team of 5 users.
I had a users which email address didn't work, so I added a second email address of his, without removing the previous one. The issue with this is, that when I added the second email address, it counted as the 5th free user.
Now that I deleted his unused email address and try to add another 5th free user, it doesn't allow me add him as a contributor anymore, but as a stakeholder.
So basically first I had it like this:
User A
User B
User C
User D
User D2
Then I tried adding user E, but I received the following notification:
NOTE: The user Jef Van Vinckenroye has access to limited functionality
as a Stakeholder. Basic access level is required for access to version
control and Agile tools.
Now I removed user D2 and added E instead so I have the following:
User A
User B
User C
User D
User E
But I still get the same error.
Suggestions? :)
It seems that you are using Visual Studio Team Service not on-premises TFS.
For VSTS, if you haven't paid for any uses, you will have 5 users who get Basic feature and Unlimited users who get Stakeholder features. When there's 5 Basic accounts(email address) added to VSTS, the account after will be set to Stakeholder. These 5 accounts are free.
And if you want to have more Basic users, you need to pay for them. Please refer to this document for more details: https://www.visualstudio.com/en-us/docs/setup-admin/team-services/add-account-users-assign-access-levels-team-services#expando-need-more-basic-users
Update:
Please check the User page and add the Jef Van Vinckenroye set it to Basic Level. Look in my VSTS User page, I have 7 users, 5 Basic and 2 Stackholder. If I add the v-gaxiao account as a Contributor, it will get the error like you. When I change it to Basic at the User page, he could be added to contributor.
I want to enable my team to add comments to issues that can only be seen by my team for the purpose of private conversations related to the issue. For example, to facilitate conversation about the technical requirements for fulfilling the request, or to allow new team members to comment "Hey Joe, I don't know how to do this, can you show me?", without the reporter being able to see those comments. I had this at a former employer, so I know it can be done, but I don't know how to set it up myself.
You can do this by setting the viewing restrictions while creating a comment. Your admin may also need to configure the comment visibility settings first.
I fixed this by creating a new Role of "Team Members", giving that Role the permissions to Comment, and then going into my project and defining that Role as my team's group. Now, when they comment they get the little open padlock icon under the comment that they can click and select "Team Members", and then only we can see the comment.
Reading online material (e.g. Fowler, Gerard), it seems that Specification By Example stories should not be complete specifications of functionality.
Question 1: How does one starting off with SBE's decide how comprehensive their stories need to be in terms of describing all of the functionality of a system? I.e. when can I stop writing stories because I have captured enough?
Question 2: In an organisation where test teams verify products against the product documentation, if the stores are not a complete specification, am I correct in thinking that 'other' product documentation needs to contain all the cases that are not covered by the SBE's?
Regarding question 1:
The most important part of developing any system is that the development team has a conversation with the product owner. First find out the crux of the feature which they require. I'll answer this question by working through an example; let us say that the product owner may want a facility to login to their new website. This requirement could be written as:
In order to gain access to the website's facilities
As a user
I want to be able to login to the website
(Note that I'm using the Gherkin domain specific language for writing the scenarios and features in this answer)
With the product owner's key requirement specified, you should now discuss with them how you think this feature should be implemeneted from a users perspective (keep it high-level, don't use technical jargon, discuss with the business to find out what they want). So the first "happy path" scenario you might identify could be:
Given a user is on the login screen
When they submit valid login credentials
Then they gain access to the main website
After further discussion with the product owner they tell you that as the website contains extremely sensitive information, and that any failed log-in attempts should be reported to a system administrator. This would result in another scenario:
Given a user is on the login screen
When they submit invalid login credentials
Then the system administrator is informed of the failed log-in attempt
And the user is informed that their login attempt failed
At this point the product owner might say that these are the only scenarios they want for logging into the system. So from the development teams perspective no more investigation would need to be done regarding this feature (so you wouldn't need to write any more user stories). Sure, at a later point in the projects development, the product owner might also tell you that they'd like to inform a user when they last logged into their site before reaching the main website, but you'd only need to worry about this when they ask for it.
Regarding question 2:
The organisation should be verifying the products against "living" documentation e.g. using Cucumber(for example) which generates tests from the scenarios detailed above.
Also as I said in the answer to question 1, you should identify "just enough" of the scenarios/use cases to satisfy the product owner. What the product owner asks for is the complete specification. Don't try and second guess what the product owner might want because this may result in be a classic case of YAGNI.