Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
We have 2 developers that are working on 8 applications. Should I split them in separate projects or keep all in one project? If i should split them, than how can I work with aggregated agile board? Keeping separate agile boards is not very useful because since there will be much more agile boards then developers.
My personal preference is to keep TFS projects for a group of related applications. For example, if you have a website, an app, a webservice, and a scheduled task all working on essentially the same data but for different scenarios, I would group those as a single TFS project.
However, if two applications are fundamentally different they should be segregated from each other. For example, one is a mobile eCommerce application, another is a video game about elephants fighting zombies armed only with a canoe paddle.
That way, the task board makes sense from a logical perspective. With related applications, you'll have stories that cut across all of the projects. You may have a common data layer service, or perhaps they all use a common engine that you want to be able to maintain on the same cadence.
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
I have a question concerning the impact of companies acquisition and its impact on the global
information system harmonization. as an example, let's take a company A using ABS ERP
and acquiring:
- Company B using Blue cherry ERP
- Company C using Styleman ERP
How can we harmonize and give company A real time access to data from it's affiliates ERPs?
Thank you !
You can either use ETL to move data from one database to another, and have the same schema but this would be an overkill.
Another option would be to create services which sit on top of one ERP to extract data, and then custom development would be required to be done to the other system to integrate to these services. When data is viewed, data would be picked up from one of the ERP's database, and from the web services of the other.
Or else try to merge the companies using the same system, having a period of time with the systems running in parallel on both systems to make sure everything is running smoothly. Cross checks would need to be done to make sure data is OK.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
Background
I want to create a Cocoa Touch library where others will be limited to a finite number deployment builds using said library. However, there should be no limitations on the number of development builds.
I was considering a remote server which generates license-keys each associated with the library and a number of permitted deployment builds on the library.
When the user of the library builds for deployment, I need to check against the keys on the remote server.
Question
Does this seem like a sound approach for what I want to accomplish? If so, how does one check only for deployment builds while preventing the user from tampering with the script/binary that does the checking? If not, what would make it a sound approach?
Imagine the joy and rapture if every library you used was making calls to some random server, affecting your customers, hurting their experience. Making your development of your product a living hell for testing and distribution. Yea, that'd be a hoot.
Get a lawyer, get a solid contract, reserve the right to audit their sales, etc. Companies have had such arrangements for years, and actually abide by them with little more than a piece of paper and couple of signatures.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
We're using TFS Work Items to manage our bugs and work items.
Would that be possible to use TFS for agile scrum project management? e.g. defining user stores, drawing burn down chart and cumulative chart, etc?
How?
Thanks
Absolutely yes.
Generate a new Team Project choosing the default process template (MSF for Agile Software Development 5.0) during the Wizard execution.
Now within this new Team Project a great deal of ready-baked reports is available, 'agile' work-item type User Story as well. Out-of-the-box sprint planning is also quite nicely delivered.
With a small time-investment for orientation, customizing & tailoring to your own needs should be possible.
A very comprehensive presentation by A.Bjork was really helpful for me.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I'm thinking of giving each part of the agile lifecycle its own project (TFS project, not csproj) as per Microsoft's agile template.
Is it possible to move items (like User Stories or Tasks) from one Project to another?
Does the organization of these projects have any bearing on or affect the actual software build (solutions, csproj, etc)?
What is the recommended organizational structure of Projects, etc for an agile project?
Are there any guides you can recommend for setting TFS up to work with the standard agile process?
Do not set up multiple TFS projects for the same team/product line. You can't move things from one to another and they won't be able to share a common parent source control so you would miss out on much of what source control has to offer. Do some research by reading the links on the other answers.
I have never heard such a strange idea.
You should have one team project for each endeavor. Basically, a team project is the intersection of a team with a project.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I've recently been looking at Extreme Programming and wondering if it would be realistic to implement it where I work.
My question is, if you're pitching to a potential new client and you tell them that you're using XP, and you explain what their responsibilities are as the customer, are they likely to be put off selecting your company if they've never worked within an XP environment before?
What are peoples experiences of selling XP to a client given that it seems to me to be a very customer intensive software development methodology? The context here is selling medium to large websites to a a wide variety of clients.
I usually try to explain it to my clients in non-technical terms, and focus on the benefits of my business model. With XP, you'll always have a higher degree of communication with your clients. This is always a plus for them. They like to know what's going on. Focus on that. Also, focus on the idea that they are able to discuss business requirements with you as the process moves along, so they don't get tied down into doing something the way they first envisioned it 6 months ago when they didn't really know what they wanted. This will also allow your contracts to extend their lifetimes when your clients get comfortable working with you and want to continue improving their products.
I'm working on a project that uses XP. The weekly meeting with our customer and the outcome of these meetings was that good, that our customer decided do try to implement an 'agile like' process as well.
Additionally I think that agile is getting more and more common in IT projects and that more customers are satisfied by the outcome of these projects. So I think that in a couple of years it will be harder to sell a non-agige project than an agile one.