We are considering to switch from FogBugz to YouTrack.
So far YouTrack ticks all our boxes except automatic time tracking. In FogBugz we just select that we started to work on a feature and it tracks time for us, while in YouTrack logging time is a manual process. Is it possible to automate time tracing with YouTrack, perhaps by using a third party app?
For a reference, here is how "working on" automatic time tracking feature works in FogBugz: http://www.fogcreek.com/fogbugz/docs/70/topics/schedules/Workingon.html
Thanks in advance
there's a workflow called workTimer available that you can attach to your project. It starts a timer each time you move an issue to 'In progress' state and logs a work item each time you trasfer from 'In progress' to 'Fixed'. Hope this helps.
You may use https://github.com/kleder/timetracker. This allows you to record the time you spend on your tasks and synchronize it with youtrack.
My team uses YouTrack, but we've decided to go with TMetric for time tracking. Both systems connect with each other via a browser plugin, and then you can record time spent working in YouTrack by clicking the TMetric button inside each task.
Related
Is there a nice way in TFS to see all the Stories/Tasks I have worked on and what day I committed/closed them out and maybe did associated check-ins for them. I want this because I work on many different client projects and need to track my time in a time sheet and sometimes forget what I did each day if I don't fill my timesheet out daily.
There is no out of box feature for this. A similar feature request on VSTS User Voice can be found here: User Activity Stream.
As an alternative solution, there is an TFS Timetracker extension in VSTS Marketplace which you can try to use. This extension will allow you to record the time you spend on every work item and generate a report.
I believe TFS is unlikely to enable this capability in the nearest future.
You can try out time sheet extensions to TFS.
For example, TX Chrono (https://www.teamexpand.com/product/tfs-timesheet) allows to log hours directly from a Work Item tab in TFS and get a work time day-by-day breakdown over the selected period (So you can make a report where you'll see hours spent on a particular WI, how many hours were spent each day, WI current state, etc.)
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.
I like to track time spent on JIRA issues when I click on Start Progress and then Stop Progress, or Resolve.
Is it possible to get JIRA to automatically allocate time to the task, like say:
14:20: Clicked on Start Progress
14:45: Clicked on Stop Progress > Logs 25 minutes to the task
15:30: Clicked on Start Progress
15:45: Clicked on Resolve > Logs 15 minutes to the task.
Is this possible?
Yes, it is possible.
You might want to have a look at Listeners:
"A Listener is a class that implements one of the Listener interfaces. It is then called whenever events occur in JIRA. Using those events, you can then perform any action you want."
In your case you could implement the issueStarted, issueStopped and issueResolved method.
On issueStarted you could somehow save the current timestamp (e.g. in an invisible customfield) and on issueStopped/issueResolved you could trigger the creation of a worklog-entry.
There is an app on the Atlassian Marketplace, Clockwork Automated Timesheets, that does exactly that.
It fully integrates with Jira's workflow so that the time logged corresponds to how much time an issue was In Progress or had any other active status.
If necessary, the timers can always be started or stopped manually by using Start/Stop buttons.
There are also reports available.
At the moment the app is free.
Cheers,
Jacek
How to avoid that that a user has two opened issues in Jira?
It's possible that Jira treat issue management in this way:
when a user has a issue opened and will open another issue, this first one must be automatically paused?
Technically, you can do that with Behaviours plugin.
It needs a Groovy script that looks up the reporter's other issues and transitions them to a paused.
Hovewer, I don't advise doing this, because you'll also need a carefully crafted workflow that supports your "Pause" transition on all statuses, a working Groovy script (needs programming experience, and intense knowledge how JIRA API works). Also needs another script that reopens the previous issue when the newest one is closed, etcetc, there are a lot of pitfalls.
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.