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...
Related
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.
We are currently trying to find a new bug tracking and integration software and we were looking at FogBugz, Jira and TFS. My question is about TFS.
I have done some research and found that TFS has "Power Tools" in which Non IT users can log on and get some information, but all the examples and tools I have found didnt really give them the kind of UI that other bug tracking software provides such as estimates, full fledged reporting on hours, P&L, Bugs Released, When A feature will be complete. For example Fogbugz has a feature that will predict when a feature will go live off past estimates, is there any way to get that kind of functionality from TFS? Or Any of the functionality listed above in a web interface?
Team Web Access is built into TFS 2010 (grab a trial and try)
Urban Turtle is the best Web UI for dealing with Work Items in TFS.
Reporting and Bug reports are available, though everyone, everywhere wants something different.
P&L reports are not available out of the box.
There are minimal prediction reports, but it's all BS anyways :). Burndown reports give you information about your likelihood to delivery.
As you mention, there is a tool called Team System Web Access Power Tool with following features:
* Direct links to work items, query results, diffs, change sets and more
* Display custom controls on work item forms
* View queued builds new, queue new builds
* Add new work items or edit existing ones
* Work with any type of work item, including custom ones
* Add new work item queries or edit existing ones
* View, download, upload, check-in and check-out documents on SharePoint team portal
* View reports, export as PDF or Excel
* Browse source control repositories, download files, view changesets, diffs, histories, and annotated views
* View build results, start or stop builds
* Search for keywords in work items
If you need more than that you'll have to integrate the TFS with SharePoint server which will give you all you asked for in your question and much more...
I'm looking for a work-item-tracking/bug-tracking system (or JIRA plugin, or TFS plugin, or...) which makes it easy to stack-rank work items without having to manually assign priority values to each work item.
Instead, our team wants to be able to see a list of open work items and be able to drag-n-drop one or a multiple selection of work items until the order matches the team's prioritization. This would be much easier than arguing about priority numbers and dealing with ties (e.g. "which of the 5 bugs marked priority=2 should I work on today?").
Our team is considering switching work-item-trackers (we use Gemini now) and availability of a good drag-n-drop prioritizer is high on our requirements list.
I realize drag-n-drop ranking is non-trivial because no team will stack rank all work items. Instead, we'll want to take a subset (e.g. work items for one sprint sprint or iteration, or bugs assigned to one developer) and stackrank those, then later look at a different subset and stackrank those, etc. And I'm sure we'll sometimes need to mix and match different stacks, so there'd need to be heuristics (ideally configurable) about how to show a stack of items previously stacked separately.
Pivotal Tracker is close to the drag-n-drop UI I'm thinking of from a UI perspective, but Pivotal's model of separating user stories from the underlying work items (plus a few other issues) doesn't match how we want to work. We don't want to have to deal with different artifacts (stories vs. JIRA/BugZilla work items)-- instead we just want a drag-n-drop UI to automatically fill out a "priority" field in the issue tracker, and which we can use later when sorting and filtering. And we wouldn't want to use Pivotal as our only work item tracker, because it seems to lack common features like bulk editing which are critical for large projects.
Anyone know of a tool like what I describe above?
Urban turtle is the best TFS add-on, making ranking/prioritizing a sane activity. Priority by number is a disaster so don't think you're alone there.
http://urbanturtle.com/
Urban Turtle is updated every month and used by quite a few teams including a number of my teams.
Eylean Board has what you are looking for. They offer a task board where the tasks are prioritized by moving them around, the priority tasks being on top. Interface is nice and clean and they offer other features such as integration with TFS, reports, etc.
The greenhopper plugin for JIRA has this feature. It's worked well for me ...though I'm not a big fan of JIRA in general.
http://www.atlassian.com/software/greenhopper/tour/backlog-management.jsp
Previous to this, I just used excel.
One of the best (and fastest) web UI's I've seen is on AgileZen, which supports something similar to this. Last I knew it did not have built-in integration with TFS, but it does have a REST API. It's basically a web-based, shareable Kanban board.
My company is a Software development company.
We planned to use TFS 2010 for our future customers development.
TFS 2010 introduce Team Project Collection in order to split related Team Projects.
So my question is, should i use Project Collection per Customers or should i use a unique Project Collection with a Team Project per Customers which will contains some customer solution projects in it
It depends on how independent your projects and customers are.
For example do you what change set number series to increment within a project, per customer or within your farm? See the following link for some of the implications:
http://blogs.msdn.com/bharry/archive/2009/04/19/team-foundation-server-2010-key-concepts.aspx
Here's what we've decided to do, since we're a pretty small company...
We're going to have very few collections. Our primary collection is called "Production" and we'll have a few others called "Playground", "Proof of Concepts", and "Educational References".
The reason for doing it this way is that our rules/workflow/data needed for work items/etc. for how we handle things is very consistent company-wide and rather than recreating this customized configuration for many different collections, we'll just use different projects for that. The collections will be for when we need to go by different rules (for example, there will probably be no check-in requirements in the "Playground" collection but there obviously will be for the "Production" collection.
So in case it's not obvious at this point, it sounds like a different project per customer is what I'm suggesting for you. But of course, it really depends on your company, how large you are, how similar your project management style is (if you do CMMI for some projects and agile for some others, you might want to separate them), and some other needs.
For example team A and team B are working on different applications that need to implement a similar feature. The feature in question relies on a database and the database is under the control of team B. Even though the user interfaces of the two applications are based on different technologies, the functionality is supposed to be roughly the same. Both teams have their own requirements and design documents. The functionality can be changed based on feedback from either team but then both teams have to update their requirement and design documents.
The teams are geographically distributed and members of each team itself are also geographically distributed. Both teams work with the same client entity but different people. Each team has their own business analyst (requirements specialist).
I am trying to make the technical communication between the teams more formal than email so that we can avoid misunderstandings.
How do you make sure that if team B changes the database and or the feature functionality, the other team gets properly notified about it? Do you use some formal text based documents such as interface contracts? Can you share any templates for those? Or do you use some other mechanism?
A couple of things from my own experience (which sounds very similar to yours)
You should try and have a single design document for the database part of the solution which as djna suggests should be posted on a wiki or similar, with a defined public contract for interaction with the data. This is a good step in the right direction, as it will give everybody a kind of 'shared vision' which helps people converge towards doing the right thing. The contracts should try to ensure that the data access is done in a standardised way.
However, from experience, the code does not always follow the spec exactly, so i would also assign a single owner from one of the teams, whose responsibility is the integration of both systems to the database.
i would then implement a continuous nightly build process with tests, and this build should include the database. This will hopefully flag any issues earlier in the process.
From the project i worked on, you may still have occasional disagreements and breakdowns, eventually we merged both teams. This was the best solution of all for us!!
Hope this helps a little
What about having a Team site (both as one team) or a Wiki so that both teams are aware of the change.
Regular stand-up meetings. Via a conference call. Stand-up == brief, highly focused, information centered. Delegate discussion to individual discussion outside meeting, reporting back at next.
There does need to be an overall authority though, to mediate where agreement cannot be reached and to ensure overall solution integrity.
I agree with Wiki or other collaborative site for publishing the current reality.