At my company we use the default agile process template with some modificiations. One modification we have made is added a field that indicates how to report time spent on a work item.
What customisations of the default process templates have you made? Have you customised a third party process template or maybe rolled your own from scratch?
I think it would be interesting to learn from others customisations of Team System's process templates.
I've done a number of different modifications for several different clients. The majority of them are to add new "States" and "Transitions" to support the client's change control, and SOX Compliance in once case. That particular client also wanted to enforce security on WHO could change the states in certain transitions - and who the Work Item could be assigned to.
I've also added a number of fields, common is an indicator of an "Emergency Change", additional priority fields - and fields specific to the clients line-of-business.
If you use the "Template Editor" power tool - it is very easy. But follow normal best practices of any development. Have a development server seperate from your production TFS Server (or at very least - a test Team Project). Put your template(s) under version control (I like a seperate Team Project for "TFS Implementation" And make small changes incrementally.
Related
We have had a restructure of our engineering teams and a wide ranging change to process, as a result we have decided to start a new Jira Project.
We want to keep the existing Ticket Types but our new process will require changes to Jira Workflows. However as we dont want to lose our old project in case there are tickets we decide to Migrate over we want to ensure that the workflows etc for that board do not change.
Is it possible to have different workflows for the same ticket types in Jira at a project level, or am I going to have to create everything from scratch again (Tickets, workflows, screens).
In Jira you can reuse every mentioned thing.
Create another one workflow scheme for second project and make you own issue type<>workflow mapping inside it scheme. Create new workflow if you want make another process for your issues. You can do it a bit easy if changes is minor - just copy base workflow and make you changes instead creating new.
Docs
In our work place we use Team foundation server as the main server used for source control, work tracking, build server etc.
We develop in house software with many teams working on different projects.
Sometimes we develop applications or libraries which can and should be shared in our company including the ability to have more than one team contributing. Unfortunately due to nature of the applications being developed they cannot be shared outside our company.
I would like to know if tfs can help in that respect or do I need to add other tools.
For instance if our teams work in different areas or team projects how can open source projects be shared without risking editing permissions or such. How can projects be shared, cataloged, published?
How can issues be published for the project? How can pull request be done as they are done in github?
Share projects or source code in TFS is accomplished mostly through a combination of using the Area hierarchy and Teams functionality.
Then we can use the Area field to filter all reports and queries. Each Team is tied to the related Area and is used to provide each Team/Sub-Project with it’s own Product Backlog. And Security can be granted based on Area and/or Source Control Path.
Update
Permission is a very important concept in TFS. The simplest and safe way is using permission to restrict and help other team contributing to the share projects. One main team/group which have all permissions for the contributing to the share project.
Most of the teams/groups which have visibility into the share projects. They need to create pull requests to review and merge code in project. Pull requests let your team give feedback on changes in feature branches before merging the code into the master branch. Reviewers can step through the proposed changes, leave comments, and vote to approve or reject the code. The same thing as GitHub.
And many times a request or issue fix will come from the share project managers , but they are not sure what team or project it should be assigned to. Then you could use share product backlog items (pbi, or user story if you are using agile template) across team projects within TFS. Since you are using a multiple team strategy under a single team project. You could collect the pbi’s and place them in an oversight queue that will be reviewed by either an individual or committee. Then these pbi’s will get moved as they get assigned to teams and projects. However, you also need to setup security in way so that the individual teams don’t have permissions to get in and monkey around with other teams backlog, queries, or code.
Otherwise, there are no built-in share project process or tool inside TFS, if you really need this, could add a uservoice.
I will shortly be looking for a technical partner to build my business to business productivity tool but want to ensure we are using the right framework to ensure a great user experience. I have researched myself but I am still really not sure what kind of framework best suits my needs. So maybe there are people out there that could give me pointers!
At the moment I am looking at a combination of Ruby On rails, HTML5, CSS and MySQL
The key characteristics of the project are:
- it is a business to business web application based on projects, admins and users
- you can create a "project" that can be responded to by a number of different users
- each project can have:
- ability to manage, preview and embed business documents e.g. word, pdfs etc.
- action buttons that allows comments, approvals etc to be carried out
- ability to create simple forms with text fields, radio buttons etc.
- ability to drag and drop options from a menu to include in the process e.g. a blank text box
Ruby on Rails is a good fit for such projects . You will have write less code , easy to manage , lots of plugins that will help you do most of the things .
I would like to know if it is possible to set other tasks to "pending" or "inactive" when the user (contributor) set one to active.
I was wondering if i can do that using Workflow or another kind of customization in TFS.
Regards
There's no way to do that if you use the product as it is...
Back in the days of TFS 2005/2008 I wrote a tool to do what you need with very complex possibilities of workflow between work items, but I didn't have the time to rewrite it for 2010 (the typed links introduced in 2010 would change a lot of things).
If you're not afraid to write a custom tool you can read this post and the source code of my codeplex project.
Team Foundation Server 2008 allows that every check-in is associated with a work item, but what do you do if you are developing some features which span several Team Projects?
For example, you're developing a specific product for a client and that product has its own Team Project, but is also using some of your other components or tools which are maintained independently in another Team Project.
Where do you create work items for requirements which involve a change in both projects?
Separated, every work item in its own Team Projects
All work items in clients Team Project, regardless of associated source code
The latter seems easier to maintain and control, but it involves associating check-ins from one Team Project to work items in another.
For a start I would say that having each check-in associated with a work item is good practice and more important that where exactly that work item lives.
From the TFS point of view it is really irrelevant whether the work item is in the same project or another - where it makes a real difference is the reporting side.
Therefore one way of looking at this is to look at reporting. For instance
if all work on the project and on the components/tools is charged to the project then it would make sense to create all work items within the project.
if changes to the components are funded separately - it would make more sense to create separate work items withing individual projects
Another way of looking at it is for historical reasons - if you want to be able to go back and see what was changed in a particular tool/component it is easier to see the work items also within the project.
Probably there is a way to sensibly split the work items and create the work items for the components in the component project and work items for the projects (if they relate to using the component) in the main project. You could always link the two work items together.