I am looking for a way to combine several project lists in SharePoint so that I can display all open tasks associated with any project in one table and have a Gantt chart reflecting the same.
Any other suggestions for keeping track of a team of project managers are more than welcome!
Thanks,
Karl
I went to great lengths to prototype a PM like tool using three (3) Lists: Projects, Deliverables and Tasks. Long story is below, short version... if you looking for a complex PM solution (say 10 projects, with 5 deliverables per project, and 10 tasks per deliverables) with dependencies, I would try to buy an external SharePoint plugin. The issue is I haven't found a way to create dependencies. So if you get a request for a high priority project, you insert your new project, it won't push out the other items. We are looking into some of these SharePoint plugins, but nothing concrete yet.
Long Story... I created a page, with the 3 web part being those lists, and using connections, I tied the lists together to filter down. That work pretty well, but again the issue is the lack of dependencies and being able to easily shift projects/deliverables/tasks.
Related
we are currently using VSTS to store all our projects.
At the start, we decided to put every work into the same project, and split them using area when creating epics, pbis etc. For multiple reasons, we have decided to split our work into different project that now represent clients.
Moving the cards is quite painful, because the option given only moves the card to a given sprint, and do not move the parent cards or the child card. For exemple: I'm moving the PBI1 from the project ACME to the project EMCA, both have the same number of sprint, EMCA is a duplicate of ACME in that sense. The problem is when moving PBI1 in ECMA, all the child tasks stayed in ACME.
Is there a better way to transfer all my work to the new project?
Thank you
One way to do it is to connect VSTS to Excel to make the transfer.
Marketplace Add-in VSTS Open in Excel
Once you have done that, you can Save your original Project's Epics, Stories, etc. in Excel format.
Then open your other Project and Insert your Epics, Stories, etc. from that Excel document.
You can use VSTS Sync Migration Tools, this tool support bulk migration of work items with the links:
LinkMigrationContext - Migrates all the work item links, both
between work items and external links.
There are two ways to use these tools:
Install from Chocolatey
Download the latest release from GitHub and unzip.
Find here the documentation and how to migrate the work items with the links.
I have been reading a lot on the recommended project structure in TFS. I am considering moving my company to Visual Studio Team Services (was VS Online) and have been trying to set up and test to get my head around how it will work. Based on articles I have been reading, it is recommended to have one team project with many areas/iterations/teams (http://nkdagility.com/one-team-project/, http://nkdagility.com/working-within-a-single-team-project-with-team-foundation-server-2012/).
What I am struggling with is how to make this work for my specific environment and what I would like to see. We are a small development team consisting of myself as a manager and 2 developers. With our current structure (outlined below), I cannot see across team projects for our full backlog. To see how individual work is progressing, I would have to go into the individual team projects.
Current Structure
TFS (Server)
Accounting (Collection)
Application 1 (Team Project)
Release
Test
Application 2
Engineering
Application 3
Application 4
I like the idea of being able to see a master backlog and then assign work items to the individual projects. However, I would still want to be able to manage sprints and see burndown charts down to the individual project level. For example, if developer 1 is working on Project 2, I would like to assign PBI's to that project and see the burndown chart at that level.
New Structure
Team Services (Service)
DefaultCollection (Collection)
DefaultProject (Team Project)
Accounting (Area)
Application 1 (Application)
Application 2
Engineering
Application 3
Application 4
Basically, as a manager, I am looking to be able to see a status of where we as a department stand in our overall backlog. As a developer, I want to know what items are assigned to me, regardless of which application they are related to. Am I on the right track for this? In typing this question, I've almost convinced myself that I don't actually need to know backlog of an individual application. Rather, I should be managing all of the work across all applications and using that as a sprint backlog. Sometimes this sprint will be multiple releases in larger application and sometimes this sprint will be updates across multiple smaller applications. Any help that can be provided to help point me in the right direction will be appreciated.
You can create multiple teams in the same Team Project and you can nest them to facilitate hierarchy.
http://nkdagility.com/creating-nested-teams-visual-studio-alm/
You can see how to configure this in my post above. It's fairly easy to use...
The new structure is good. And you can create two teams from your project Control Panel\Overview: one for Accounting and one for Engineering. Check "Create an area path with the name of the team" option when you create the team. Then you will have 1 overall project page for your team project and 2 sub project page for Accounting and Engineering like following:
In the overall project page, you can manage your overall backlogs, check the Burndown charts for the whole project. And in the sub project page, you can manage the backlogs and check the Burndown chart for individual project.
This may have been asked before but i was not able to address my needs in all previous posts (I've been searching it for couple of hours). All posts are so specific to its special needs. (I've been writing projects for couple of years but a newbie to TFS)
My Need Is:
I have one common helper project under default collection. (simple helper class and functions which helps me to avoid rewriting everything)
I am trying to use this helper project in every tfs project under different collections.
What is the best scenario to use?
Default Collection
-- HelperProj
Collection 1
-- Project 1
-- Project 2
Collection 2
-- Project 3
-- Project 4
Thanks in advance
Onur
Here is a link that may help you with your needs. Take a look at the work-space mapping and branching features to achieve what you need.
Code Sharing in Team Foundation Server
Organizing Your Server with Team Project Collections
My advice would be to use a single project in a single collection unless you have a compelling reason not to.
The reason is that although TFS looks in many ways like one large file-system, there are some things that don't work very well across project and collection boundaries. In my experience putting code into different projects/collections only works cleanly if there isn't (and never will be) a dependency between the lumps of code, so you can work on a single project/collection in isolation.
Our company started off with a TFS project for each "real" project, but we constantly ran up against problems due to this until we reorganised our entire codebase into one collection containing 3 projects, for Documents, Assets, and Code (three distinct areas with no interdependencies)
Within a project you can still organise the code into folders so IMO there really isn't much point in using different projects and collections unless you have very different access/security requirements for the different codebases (which is unlikely if they have no dependencies).
The other approach is to use the 3 collections you describe, but eliminate the "live" dependencies between them by pre-building the libraries in DefaultCollection to provide a shared repository of binaries that you can link to from the code in the other collections. This could also help with versioning, where the library code could be updated but the binary not merged into one of your other collections immediately, allowing the teams that work on the other collections to pull in updates to the library code only when it suits them. This can help stop problems being caused by changes for team A being immediately used by team B.
I am pretty new to TFS but I have some experience with VSS. I like to know your opinions of what would be the best way of working with TFS in the following scenario:
We are a group of developers working on projects. All projects starts from a common base code. All projects are one man only, no code sharing until the project is done. A project can last from a few hours to several months, no code is merged until done. Any developer works simultaneously on more than one project, usually 7-10 projects at a time. Usually the projects only involve a small numbers of files that are changed/created (10-20) but rely on a large group of infrastructure files that change quite often. However, any change in infrastructure is not considered until the merge, so we don't get latest version from server until the final build.
An additional request is that, when merged, we’d like to use a 3 way merge tool. We use this approach in VSS, via a custom made application and it works very well. However this involves special file management, for example every file that has to be changed must have an original version saved somewhere that will be used as the “root” file for the 3 way merge process.
What do you think?
You should take a look at the Visual Studio TFS Branching Guide 2010. (direct download). In that package, there is a PowerPoint deck that walks you through a series of possible branching structures.
It sounds like you want either "Branch by project" or "Branch by developer" (since you only have one developer per project, these are effectively the same).
Regarding the 3-way merge tool, take a look at this list to see how to configure your favorite diff/merge tools.
In Team Foundation Server is there a way to have work items in one project linked to other projects so they show up in the reports in both. We are thinking about keeping release engineering items in their own project and want them linked to the project they are actaully for as well. Is this possible? So for instance I would create the item under release engineering assign it to an engineer and then link it to Product X so it showed up as a work item for Project X as well.
This is possible in TFS 2010 at least: link tfs work item to different project
Not sure on the effects on reporting though.
Not out of the box as projects are discrete. However there is nothing to stop you from writing against the API to fulfill this need, although this would take some considerable work.
Now for the good news. If you keep your eyes here, you may find the answer in time. As I see cross project reports are planned in Rosario