The tools in the spreadsheet above are required to satisfy the requirements of our new Software Development and Implementation Methodology which has been a pretty long project so far. And, there are some that were very impressed with Microsoft's presentation on TFS last month (I, unfortunately was unable to attend as I am on the other side of the planet).
So, it seems like I have my answer.
Thanks All! Your feedback has been most appriciated!
In my opinion it comes down to these questions:
1.: How much of the features of TFS do you use?
2.: How much effort can you spend on maintaining your system.
3.: How complex is your branching model?
If you use e.g. work items, the test server, the build server, the tracking boards on the web interface and/or you don't want to spend a lot of time configuring stuff, it is better to have TFS. (Assuming a not-too-complex branching model and that most of your SW is targeted for Windows)
If, on the other hand, you would use TFS only as version control and you have another build server and a separate issue-tracking system, or if you have version control needs which go beyond the capabilities of TFS, it is probably more beneficial to use Git served by Stash or sg. else.
I'm not sure how much of TFS is actually used. My gut is telling me that it is only used as a SCM and there is almost no branching (probably none).
The motevation for switching is that we have only a small group using TFS (20 developers) for .NET and over 100 developers using SVN (Java). And..we are looking for a development process management tool as we are revamping our process workflow.
If you all tell me TFS is fine and can handle all of our Java development processes such as increasing our GitFlow branching model usage, issues bugs, enhancements, code completion prediction (road maps), wiki/documentations, knowledge bases, Agile support (sprints/epics/user stories), Traceability matrix, time reporting and estimation, burndown charts, CI, deployment procedures, pull requests, code review, approvals, etc etc. Then yes, it does everything and we don't need to spend +$70K on Jira products (and modules).
BTW: When I say I want Atlassian to sell me JIRA, what I want is for them to come tell me what it does for $70K and how to use it. Not make me go figure it out by watching their video's and buying the $10 starter packages and trying to figure it out myself not knowing anything about the product.
Where did you get the $70k from? JIRA + JIRA Agile is $28k for max license. Git is basically free (but of course Atlassian Stash has it's benefits), build servers are free (Jenkins).
If you go with confluence that's another $24k for max license - but you can use some free wiki as well, or sharepoint if you have it already.
Also do you really need that big licenses? And is it really cheaper than TFS? Let's assume you have < 500 devs, that's $20k for jira & confluence. How much would you pay for TFS? I'm not sure how it is with recent TFS releases, but previously you had to purchase Client Access License (CAL) for each and every user that connects to TFS server (no matter if they only view bugs, register them, work with source code). Those were fairly expensive e.g. $500 ( http://www.microsoftstore.com/store/msusa/en_US/pdp/Visual-Studio-Team-Foundation-Server-2013-User-CAL/productID.284831700) so even for your 100 Java devs purchasing CAL would be around $50k... much more than Jira + Confluence for 500 users.
Oh..yes, you are right...that was my original. I revised the user estimate down.<th colspan="1"> </th>
|Notifyr||Notification to developers of commits to software repositories. Repository "watch" support.||300|
|Bamboo||Automated Unit Testing and Application Build. Continuous Integration for application Release. Maps build to code to issues and requirements (1 remote agent)||800|
|easyBI||BI and custom dashboard widget development (100 user)||1400|
|Gliffy||Graphics and Diagrams in Confluence Documents||1500|
|Zephyr||QA and Testing Platform to support QA test Cycles (100 user)||3000|
|Ad Hoc Workflows||Document Approval and Electronic Signature in Confluence Documents (500 user)||3200|
|JIRA Agile||The Scrum and Kanban agile development support module, Agile dashboard, backlogs (500 user)||4,000|
|Crucible/FishEye||Code Review and Git, SVN repository support (100 user)||4,000|
|Stash||GIT Repository Support (100 user)||6,000|
|JIRA||Base System. Issue and Project Planning, release schedules, roadmaps, versions definition, projects definition, groups and security. (500 user)||8,000|
|Confluence||Document development, Requirements Gathering, Approvals, Lessons learned, User's Guides, Technical Reference Materials (500 user)||8,000|
So, it's a bit more reasonable....I guess.
The point here is to not use "some free wiki". This is a project to impelment a corporate standard for a constent 'look and feel' product to assist us with product development. Not a 'mismatch of junk'.
The current perception and resistence to Atlassian now is base on the comment "Atlassian is endless customization and configuration".
If that's true and TFS is not, then we just might have to use our TFS system and buy more TFS licenses.
A forgot a couple of add-ons...we'll need the TFS connector addon (TFS is probably not going to go away)...and we'll need the SalesForce plugin...and if one exists, the Oracle Agile plugin (does anyone know if one exists?)
Balazs, thanks for your feedback. One more question...I will put this in quotes because this is what I've been asked by our team: Can TFS "do for Java what it does for .Net?"
Oh...and I forgot the Clover plugin.
Plus the infrastructure cost...I have 4 VM's currently running the 5: Jira, Fisheye, Stash, Bamboo, Confluence...will also need to size this for the Enterprise if we decide to move forward. This could be a huge cost.
Please don't say "OnDemand". Not an option.
Based only on my experience - if you have very specific needs than TFS is also endless customization and configuration. But it was so painfull that we often gave up - in Atlassian products you just do it and often works.
Using the phrase "some free wiki" wasn't the best choice, there are really good free alternatives as well as paid ones, but I can't guide you through them since I don't have enought knowledge in this area.
Personally I'd leave Bamboo for Jenkins. Crucible probably can also be replaced with ReviewBoard (haven't used Curcible so I can't compare).
But if you want to keep everything standarized with same look and feel and easy integration that obviously costs. I'm more into having the tools I really need work the way I want no matter if they're not exactly looking the same way. Of course we're talking about enterprise solutions here but for example code review tool and build server primary target are developers, very technical group of people who often want functionality over shiny interface.
> TFS is probably not going to go away
Why would you like to keep that? Source code with history can be easily migrated to Git. Work items are a bit more difficult but possible to export. Even if TFS would be living just to keep the history for some longer time is it worth integrating it with new tools if it's not used anymore? Or otherwise if it's still used than maybe this migration is not that much of improvement.
Not sure about the TFS/Java relationship, but I guess there will be plenty of sources on the net about this.
About the VM's: this is only halfway based on experience, but I think approx. the same amount of HW is enough for all of these as for a TFS instance doing the same functions. Whether you allocate it as several smaller VM's or one powerful VM running all should not make much of a difference.
Also, it sounds like you could pay for any of the available options, so I think it would be more beneficial to think in terms of what fits your company('s workflows) best instead of how much it will be.
Sorry to give the impression that I was only worried about cost. I'm not. The spreadsheet simply outlines the tools that I would need to satisfy the requirements.
What the original question was is "Is Jira better than TFS?"
I was hoping to get some white papers or a success story from someone moving off of TFS onto Atlassian tools and plug-ins.
Again, thanks all.
thanks for the information. I am quite happy with Bamboo. So far it's meeting my needs. But I will register your advice.
I'm still wondering why I need Crucible+Fisheye. It's UI is nice and very cool, but I have been doing well with Pull Requests. But perhaps our previous code review practices were primitive. We recognize this as an issue for us.
As far as keeping TFS..well, this is going to be one of those things... The current .Net/Asp production server environment is manged and developed with this TFS server and has many customizations. I do know that, even though I know nothing of the details of what TFS can or cannot do. If we do decide to go with Atlassian products, then I plan on pushing for the TFS retirement.
One of the reasons I chose Bamboo of Jenkins was the linkages between Jira and Build versions with JIRA "telease" building. Perhaps I could do this with Jenkins. I don't know. But it seemed better to start with an integrated product.
To be honest I can releate with this research technique. I almost automatically reject anyone trying to sell me something having the assumption that they don't care that much for my benefits as for their own profit. These days you can find lot's of different opinions on the net fairly easy for example:
Personally I find Atlassian products better for my purpose, but they both have pros and cons. The main argument for me is that TFS is just huge, bloated I would say - it does everything, it grown over many years, it was built to follow strict corporate procedures. On the other hand JIRA is more "agile" you can choose different complimentary services (e.g. for source control), there's a lot of plugins to extend it. But I'm sure there are people who prefer TFS over JIRA :)
If you have any specific questions feel free to ask.
BTW - what was your motivation to consider switching solution?
Andrzej, I checked first two of your links and found it mostly outdated. The first link points to some very incomplete evaluation of Atlassian stack by someone, who is very much Microsoft-oriented (they chose Jira though). Statements like "Jira is just a issue tracking tool" and ignorance to Confluence, Jira Agile, Jira Capture, Jira ServiceDesk, Stash and so on it just unprofessional. The second link is full of comments where people don't know what they are talking about. Cannot create relationships between user stories and tasks in Jira - what a nonsense! A complaint that Jira spring planning is not allowing to plan the capacity shows a misuse of Sprint ideas where you plan in story points for the whole team. whilst TFS pushes you to plan per person, in hours. If yo still want to do this in TFS though - Tempo Planner has excellent support for this. For me, TFS is a very limited solution. Starting with its product backlog item layout that is hard to customize, the way links are shown, where in VS the first links you see are changesets and tasks come afterwards (complete nonsense) and in the web UI the sorting is reversed (and yes, you cannot change it). Only one Kanban board for everything. No search at all. No content management. Build server configuration is extremely complex. No work logs and timesheets. Lack of plugins. I can continue for a very long time since I have years and years of struggling with TFS.
Alexey, You may be right on the nonsense of someone saying that they "Cannot create relationships between user stories and tasks in Jira" but I interpret that as the process was not intuitive and obvious. Any type of tool (Jira, Rally, ScrumWorks, or TFS) should facilitate firmware/software's efforts, not hinder it. I've used Rally in the past and hated it compared to ScrumWorks. Now using TFS, I find myself wishing I was using at least Rally. The excuse for using TFS was it's customization and templates, but every upgrade was painful due to the customizations so the corporate edict is that they will only use the out of the box templates and so far it feels like I'm using MS-SQL server or MyPHPAdmin directly - can't even make a simple burndown chart. The point is - the tool should alleviate engineering effort, not create new nor hinder efforts.
One of the reasons I chose Bamboo of Jenkins was the linkages between Jira and Build versions with Jire "Release" building. Perhaps I could do this with Jenkins. I don't know. But it seemed better to start with an integrated product.
Yes, you can integrate that to some level with plugins
If you ever decide to try Jenkins make sure you use LTS version, regular releases are often not stable.
If you use visual studio and target Windows systems VSTS or TFS is a no brainer.
You get coverage for the whole dev lifecycle including infrastructure with azure services without having to jump between products from different companies. It is flexible, customizable, has a REST API to interact with pretty much every feature at any time in your lifecycle tasks, integrates with microsoft's products.
I wouldn't discard the fact above for not liking certain default presentation or workflow.
Teams break work down in order to help simplify complex tasks. This is often done iteratively, with tasks being broken down into smaller tasks and so on until the work is accurately captured in well-...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events