We are using Team Foundation Server 2010 at work and all of our assignments come from TFS tasks.
Right now I have 2 tasks that relate to the same source file. They are two separate feature requests, but I will end up writing common methods for both. I check in the code changes and link the task when I am finished with the task.
There's an issue right now though with the test database that is prohibiting me from actually finishing off on the first task and checking it in. Well the next task is on the same file.
I am curious how other people handle this issue. I know I could shelve the change and work on the other, but I kind of need some of the other methods I wrote in the first task. The body in some of these methods will be changing a little bit to handle the next feature.
Do I shelve my changes, copy my methods over and modify them for the new task? If I do that, how would the merge process work when I un-shelve my changes? How do any of you handle this issue? Am I better off just doing both tasks in the same changeset? However, now the 2nd task has a dependency on the 1st. If for some reason the database doesn't get fixed, that first task is now holding up the 2nd task from being deployed.
Thanks for your input in advance.
If both tasks are destined for the same release, work on them in the same branch, and just associate both task workitems with the checkin. If they are fundamentally separate changes, and my move to the production codebase separately, then you should have two separate branches for the code.
Related
I am searching for a solution to get a automated feedback, when a planner task is changed.
Why? We use a planner to assign task to a person in the team. This person can change the tasks details. I only get a feedback if the person finishes the task.
But not if the person changes the other details. The team is big,so I can‘t check every assigned task.
Powerautomate helps not much in this.
I just started using Microsoft Graph and I prefere scipting over using powerautomate.
My question:
Is there an Object that looks at the changes in a specific planner task globally or do I have to check each detail in the task?
And can I run this hourly every day until the task is closed?
We're looking into setting up web hooks, which I think will be the way to solve this scenario. However, before we have that, I don't think there is much to support to achieve this. Since everything is in the same plan, you can probably remember the etags of the tasks, and see if they have changed, if they have, then send the reports about them. But the etags are going to be updated for any change, even if the change isn't something you care about (e.g. just moving the task around in the board). Also, task and task details have separate etags, the details can be updated without the task etag changing, so this isn't a simple solution.
I've had three items assigned to me for the current sprint, two of them categorized as "blockers." The third item, in 'done status,' had a requirement change today.
I checked on what "blockers" mean, and they are things preventing you from getting a task done, right? So how can a goal itself be a blocker?
Also, I've been forced to do a lot of context-switching this week in the past. This is due to support for a couple of projects. However, it keeps me from settling into the blocker tasks.
By the way, I did get one blocker task reclassified as "major" due to effectively going over the Scrum Master's head. However, it was a non-customer-facing pilot project that I had been pulled into a call on. So both of the blockers came about this way.
The third project had a scope change due to a bug discovered (not my code), which affected me.
I'm not clear how to handle all this. Any ideas?
The word 'blocker' does sometimes get used as a way to describe a very high priority task.
e.g. This ticket is a blocker for another team, so we must get it urgently fixed.
I agree this can be confusing!
When a task (Task_1) is a 'blocker', it means that without solving it, another task (Task_2) in the team cannot be completed.. so 'blocker' tasks usually have a high priority.
So you can imagine both tasks have to be done in series, like in an Airflow DAG:
Task_1 >> Task_2
We have an application which has historically suffered a high number of branches.
These have now been ratified, but a situation has now occurred where we have two development streams (which ideally would be one) and one of these streams requires a number of changes where implementing them will have knock on effects which aren't fixable as part of a single story (or possibly a single sprint).
For example: a high number of database schema changes which require a large number of query logic changes.
These changes aren't easily feature flagged as they systematically break existing functionality until the work if completed. We could theoretically put the system back in a 'building' state, but it would prevent the customer from using the existing functionality.
To cater for this, we're proposing creating a new branch for the 'breaking changes' so that the other development stream isn't broken and can be released intermittently.
Whilst I'm loathed to create new branches, I can't see a better way of doing this at the moment.
Is there a recommended practice, either branch strategy to manage or architecturally to protect from, breaking changes in parallel development?
EDIT: The only other thing which has crossed my mind is to literally 'copy-paste' the existing functionality (including tables/web pages etc) renaming them and working on that in the same branch, behind a feature flag.
This is obviously pretty messy for a number of reasons!
Does anyone have any suggestions for how they have coped with this in the past?
You should deliver the database schema (and other changes) in an incremental fashion. Don't take on the whole change at once, but instead break it down into things that you can deliver.
If your current application architecture does not support this model then that is the first problem to tackle.
Always meet your DoD for every Sprint. All work integrated with no further work required to ship...
Is there a way to set up custom alerts on TFS? I already use the web interface to create alerts, but I need to create custom ones that are not based on work item fields only, but also on the current and past iterations. I know that Power Tools used to have an Alert Explorer in previous versions of Visual Studio, but I don't know if it would have supported what I am trying to do.
Essentially, this is what I need:
An alert that notifies users of unfinished work items assigned to them when the current iteration (sprint in my case) ends.
I know some of you might be concerned about TFS not knowing what the current sprint is, but I have used this workaround http://intellitect.com/transitioning-between-sprintsiterations-with-tfs/ so I don't believe it's an issue.
I know I could simply query for unfinished items and move them to another iteration (sprint) in Excel, but we are trying to get into the habit of getting everyone to finish their work on time, and if not, as quickly as possible, and the notifications would go a long way in helping with that.
Would there even be a way to do this via the TFS API or through the TeamFoundation PowerShell modules? I have searched extensively but I can't seem to find an answer to this question. Any help even with a work-around solution would be appreciated.
If you are trying to get people into the habit of updating their work items then this will cause you more issue than it fixes. They are not doing it because they do not see the value.
However you could write a TfsJob that sends the emails. It would need to be Scheduled job that checks to see if there is outstanding work...
This should get you started: http://blogs.msdn.com/b/chrisid/archive/2010/02/15/introducing-the-tfs-background-job-agent-and-service.aspx
However what you have is a people problem that cant be solved by tooling.
what I like is getting a job thing, whether a SQL server one or a windows service, running, then manipulate workitems by myself.
Using TFS Cloud (myproject.visualstudio.com), there are no Estimated, Completed, Remaining fields to add time to a bug. Do we really have to create a TASK work item basically called 'fix - bugname' for every bug, just to log how long each took to fix?
I appreciate on larger bugs this makes sense, but some are spelling mistakes or other minor problems.
This then doubles the number of work items in lists for all?
any suggestions?
Well, having looked into this, the quick answer is yes.
The benefits of doing so are simple. A TASK is the 'smallest' thing you can do in TFS, and it is always assigned to one person.
Given this, by creating tasks to do the 'work', you can at least see who did the work and account for it (without looking at the history of an item).
You can also 'bounce around' the assigned to for the actual BUG, e.g. to get someone else to verify it, or leave it assigned to whoever 'owns' that bug, while fixing it can be assigned to others (the tasks).
If you are using Agile or CMMI template the bugs will not appear on the task board.
Ideally, you need to create tasks to represent the work that you or team members are doing. For instance you need to create development task for fixing the issues and a QA task for testing.
Also you should keep an eye on the statuses of the bug in parallel to the task. i.e. if the developer is working on the fix the bug should be assigned to the Developer and it should be Active and the development task also should be active as well.
Once the development work is completed the the developer can close the underlying task and Resolve the bug and assigned it to QA for testing. If everything goes well the test engineer will close the testing task and at the same time he/she should close the bug as well.
Technically yes. What we've decided to do (purely for simplicity and not to bog us down with even more user stories in TFS) is we create one user story per sprint and name it: "BUGS - SPRINT#". Under that we will have tasks that track the work/time spent on bugs.
We also name the tasks by category. For example, if there is a bug in the UI, we name it (example) UI - arrows not reappearing.
Not sure if this is the best way to do it, but it accomplishes effort tracking and keeps TFS clean.
I take it that you are using the "Microsoft Visual Studio Scrum" template. The fields in the work items vary based on the template you are using.
For bugs in the Scrum template, we usually cover the effort in the "Effort" field.
We are Using Visual Studio 2012.
This is the way we are handling this situation. We have created a user story “ Resolving, Re-testing bugs.” Every iteration developers who have to fix bugs create a ONE task for all bugs. The developer adds comments to each and every bug resolved, and update time accordingly.
QA person also adding a ONE task for the iteration for re-test bugs. QA person update his task accordingly for each and every bug.
All Developers and all QA personal create child tasks for the same user story.