Are there any GreenHopper plugins out there enhancing the Agile capabilities of JIRA? I'm specifically looking for a better solution to the current "Sprint" field in GreenHopper.
The new GreenHopper Rapid Board feature is a large step forward (IMHO) for the sprint planning and sprint management -- and this from someone who used to be 30-50% frustrated with the agile features of Jira/GH. You do need to upgrade your Jira to 5.x and then use the "Labs" features to enable the latest Greenhopper, and you need to re-index your Jira issue database.
The Rapid Board is a fresh start for GreenHopper. We are building it to take advantage of the latest in web technology and provide you, the customer, with an awesome experience for planning, tracking and reporting on the progress of your agile projects and teams.
The Greenhopper team within Atlassian has been working towards their new road map for Greenhopper very quickly and our team has been very impressed with the progress. One of our favorite improvements (there are many) is the ability to add stories/tasks from multiple projects to your current sprint.
One thing is absolutely clear: your agile project does not necessarily map to a single JIRA Project. For that reason we have addressed the most common feature request — GHS-1800, support for more than one JIRA project in GreenHopper. Not being folks to sit still, we are taking this opportunity to introduce a new user experience with fewer page reloads and more useful URLs — users will be able to have a URL for the displayed page (GHS-990).
It's as if they have actually listened to their customers in developing the latest GH.
The new planning board also has been a big timesaver - I would say that our sprint planning time has been reduced by about half.
Related
In Microsoft's VSTS, is there a way to have User Story as a child of Epic in the Agile process template, eg including when performing "mapping", without creating a VSTS custom process template? In the image below in the main content area, hide / remove Feature, and in the "Mapping" panel on the right, have Epics for mapping User Stories.
I'm asking because in my org's agile practice we have epics and user stories but we don't see the need / benefit to the extra layer of Feature WIT.
OOTB Agile process template has Epic > Feature > User Story and when you view Product Backlog (aka user stories) you can map them to Features and when you view Feature portfolio backlog you can map them to Epics, but you can't (that I know of) turn off the Feature WIT so that User Stories can be mapped directly to Epics in the GUI.
Btw, it isn't possible to rename OOTB WITs otherwise I would simply turn off Epic WIT and rename it to "Epic OOTB", and rename Feature WIT to "Epic My Org".
UPDATE: Per Add a portfolio backlog level it is possible to add a portfolio backlog level with a new WIT:
You'll first export your process, add or update definition files, and
then import that process to either update existing team projects or
use it to create a team project.
but I want to remove one. I may try the reverse using this procedure but first I'd like some reassurance that it likely works for removing an OOTB level.
Some of the docs I've consulted include:
Agile process work item types and workflow - Microsoft Docs
Define features and epics - Microsoft Docs
There isn’t such feature in VSTS, also you can’t custom too: Modify the backlog and boards
Why don't you use tools like Jira or Rally to map in your agile practices? It will be immensely beneficial in long run.
Agile, by its very definition, means that you should be flexible. As such, ignoring the User Story as a sub-class of feature can be done. However, I think that if the focus of your delivery has a strong user-component to it, then marrying that up in deliverables will give a better indicator to your product owners.
If you're scrumming it, then you'd generally be working on a feature-task loop anyway, so I wouldn't worry, VSTS seems to cope well with both.
VSTS doesn't really concentrate heavy on Workflows OOTB like JIRA pushes (I've seen some crazy JIRA workflows in my time), although it is quite extensible, I believe the VSTS Team have gone Zen Agile in terms of offering a service that helps teams develop code first and foremost, and consigns the machinations of the upper tier management of software delivery and work tracking second.
See the process guidelines for more info: https://learn.microsoft.com/en-us/vsts/boards/work-items/guidance/choose-process?view=vsts
Rarely in an organization's lifetime is it easy to choose development platforms. Now is the time for my startup - we have to commit to a version control platform / service and set up some form of ticketing and project planning.
Every year brings new developments in these fields so I feel justified in asking what may well be a FAQ. My question is specific to:
Now (mid 2011)
A small software startup (1-2 developers) but likely to grow
Very low cost (especially to start with)
The latest trends seem to be distributed version control with git and mercurial front runners. And in 2011, it seems no-one hosts their own version control - just pay monthly for the service. Amalgamation of issue tracking and planning/estimation is another current theme, with this also hosted in the cloud.
Right now I am thinking of a paid, private github repo for source control - this would make it easier to bring open source developers into the team. And FogBugz for issue tracking/planning - I'm impressed by the UI and evidence-based milestone estimation.
So my question in a nutshell: what are the forerunners for version control and planning in 2011? What are the themes that are shaping this space?
Pick the ones that you think might work, try them out (most options have a "trial" if they are not free services), and then go with what works for your team. The best way to figure out what works is to try it.
My recommendation is to start with the simplest things you can and only add additional tools if you need them (try them out, sure, but don't require their use). The overhead of most tools is very large for small teams just starting out. Focus on your business value-added items. Time and effort spent working with / configuring various tools is time you are not building things your customers want.
That said, use whatever tools you are used to using right now, and build out from there. Go with the strengths of your team first, and then look to remove pain points as you go.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
We use Trac as our bug tracking / development / wiki system and I was wondering if anyone has experience and uses some of the Trac Agile/Scrum plugins or functionalities? Anything you'd recommend?
Or would it be better to duplicate Trac tickets as dead-tree user story index cards and a hand-drawn burndown chart?
Note that I found a similar question here. Though it's specifically about Scrum. They recommend Agilo. Has anyone tried Agilo yet?
With a collocated team, I'd always duplicate user stories on index cards. A wall of cards is much more collaborative and simple to use than any software tool. And what's most important, it's in your face.
The same is true for a burn chart. In my experience, a software chart gets online looked at by a small number of people, and typically is a pull medium. A big, handdrawn poster (that changes regularly) gets noticed by everyone, and serves as an incubator for ad hoc discussions.
It's also quite valueable to be able to point at them during your daily scrum meeting.
This is how we use Trac for our scrum like sprints:
We use the milestones in Trac to identify sprints.
There is a default Backlog milestone where we gather all new tickets.
Before each sprint we move tickets from the backlog the current release.
On the milestone page, we can add retrospectives and other info about the sprint using wiki syntax.
So just the default Trac functionality without any plugins for now to keep it lightweight. As we get better we may add features like burndown charts or maybe switch to another tool, but we want to get the proces in place first.
Answering late, but this more of sharing my experience with Trac+Agilo so far.
To quickly answer your question, perhaps Agilo is the best option available for Agile development with Trac.
Now comes to install and usining install was just very easy. We used their latest release 0.7.3.3. It installs flawless on Trac 0.11 and Python 2.5. Don't forget to install libjpeg and python imaging library. It would be useful to note that we used virtualenv which took a made things easier.
Further usage is very simple. For wiki I kind of prefer Trac's old clean look over Agilo's customization. Other than that all things just works.
On thier mailing list I have noticed that they are planning to offer multi-project support in future. In all I recommend Agilo plugin for Trac.
Yep, I installed Agilo on our Trac installation.
Seems very cool, includes nice burndown charts.
Unfortunately I left the company where I installed it before I could get any serious usage out of it.
Installation was a pain (Ubuntu Ibex) - I documented precise steps on the Agilo Google Group.
The problem (as always) is integration into the business end of things that PMs and CEOs like to see (e.g. estimated vs actual hours). There are (as has been mentioned) other products out there that cover this off (FogBugz covers this off I believe), but I (and the team) love Trac so we worked around this.
Oh, one more thing; it looks like it introduces quite a lot of overhead (i.e. you have to spend more time in trac to get the most out of it), but like I say I didn't have an opportunity to really use it in anger.
We used Trac before with a burndown plugin then went to Redmine. We've found Redmine to be miserable for repository viewing and the issue interface. We're actually looking to move back to Trac again.
Bitten is a Trac plugin for continuous integration that can be harnessed to do automatic builds on check-in, which provides a critical part of the Agile process (rapid feedback). I haven't used any other plugins for Trac personally, so I can't comment on them. However, the native Trac functionality of milestones could be leveraged fairly easily, I suspect, to be used as iteration markers (where each milestone represents the end of an iteration). Since milestones can be used to mark a 'due date' for features already, you shouldn't need much in the way of modification to use them as such.
From there, using tickets as user stories, and tying them to milestones (I'm sure this can be done manually at worst) would give you a basic method of tracking velocity and keeping the team aware of progress (and changes that need to be made as well).
We use the Trac wiki for:
List of requirements for each feature
List of technical specs (if any) for the features
List of Releases and their features
Deployed environments, with links to all instances
There's a macro for making web requests, so we can list which version, etc. each env have
(there's a GraphViz plugin which is quite helpful for simple drawings)
There's also a ticket in the ticketing system for each "feature", for keeping a gross backlog and the current/next sprint planned.
Then we write a bunch of cards during sprint planning for each feature.
There's also a more operational side to things. We keep one person each sprint on Ops, so we have one person who's dedicated to be interrupted by people outside the team. The rest of the team can focus on delivering features.
Each bug/ops task gets a ticket, but as soon as we start working on it, it gets a card and starts moving across the board. That way it gets visibility and we don't forget to involve the testers, etc.
Scrum is pretty tactile, so I don't think it would work great to put too much stuff outside of the physical working environment. But in the end your team needs to find a balance that works.
For something completely different, the best way to do Agile Development with Trac may be to simply migrate everything to Redmine. It supports Trac's core features with some extras including multiple projects, Gantt charts, forums, DCVS, etc. though it looks like it's not completely there yet. Some good things in the pipeline.
Daniel Srb (in the comments) has a redmind agile plugin he's been working on that looks promising. You may be able to contact and see if he's planning to release it (was a long time ago).
We've had success using two products in concert in the past, Trac for tickets, xplanner for planning.
Agilo for Scrum rocks, the latest versions are using client side generated charts, so there is no dependency anymore, much easier to install :-) agile42 just release a Pro version that enriches the Agilo experience with a nice and intuitive Planning Board, very cool screencast :-)
We recently started using Scrumban.
Basically a Kanban board, with the daily stand-up meetings covering the classic Agile Scrum questions - what did you work on the previous day? what do you plan to work on today? do you have any blockers?
We do this around a physical Kanban board, it is great for visualizing the work flow and for team synergy, but we also wanted a digital form of our Kanban board to be able to double check trac usage vs. the physical board.
In search for something that would work, I found this clever post on re-creating a digital version of the Kanban board in trac.
It is very straight forward and simple, I was able to easily manipulate this approach for our work flow, and you could probably tailor it to your Agile Scrum iterative approach (or if your able to ditch the time boxed approach, give Scrumban a try).
We have a small 3 developer team that is currently using Subversion for our source control. We expect the team to group to 8 members within the next 6 to 12 months. We are considering changing our source control to either TFS or Mercurial for improved branching. I know TFS is overkill for just branching, but that is the immediate need, and the other features of TFS could aid our team. One of our main concerns with TFS is we've heard that there is a lot of overhead deploying it, especially on a small team. I'm hoping to get some community insight into just how much overhead there may be involved, suggestions to make the process easier, and anything else the community may feel is useful in making the decision to implement.
In my experience, TFS works really well, even for small teams. If your total number of developers is five or less, you can use the relatively affordable Workgroup edition: above that, you'll have to pony up for the real thing, pricing for which is definitely in the 'Enterprise' realm...
The biggest hurdle to starting to use TFS is installing the darn thing: this process seems to be designed for maximum aggravation. (The extent to which the 'designers' of the 2005-to-2008 upgrade 'process' despise their users even manages to go beyond that: fortunately, you'll be able to start with TFS2008 and won't have to worry about upgrading for a while).
If you follow the instructions exactly, you should manage in 2-3 tries, though, and the hardware requirements aren't as bad as they seem. My 3-developer TFS setup runs quite comfortable on a previous-generation Dell laptop with 4GB of RAM.
One of the big advantages of TFS is the VS integration: this works just really, really well, and shelving and branching are implemented in a more straightforward way than with any other systems I've seen.
The process guidance and support in TFS are a bit less polished, but still quite usable. The pluggable support for several development methodologies is quite nice, and several third-party add-ons (for example for Scrum) are available already.
All in all, it definitely won't hurt to try TFS: if you have a MSDN subscription, you probably already have the Workgroup edition as well as a trial of the full version: otherwise, you can downloaded the latter from Microsoft as well.
UPDATE, April 12th, 2010: With the release of Team Foundation Server 2010, the installation and upgrade procedures have improved a lot. A new TFS2010 install shouldn't take you more than a few minutes (assuming you already have an instance of SQL Server 2008 up and running) and even an in-place upgrade of my TFS2008 setup proved to be entirely painless.
Setup of TFS is not too complicated, when you exactly follow the given guide step by step. We are using it on a small team for about one year now and i don't want to miss it any more.
Especially when you use more than one part of tfs like version control and work item tracking and maybe even teambuild, your team will benefit of the tight integration of the seperate parts.
For example, you can link to workitems when checking in code changes.
Then you run an automated build with teambuild and it will automatically update your workitems with the build number.
So afterwards you can see for example in a bug workitem the buildnumber which contains the bugfix.
We also use the sharepoint wiki for documentation and planning although i'm not the biggest sharepoint fan...
The main point is the great integration into the IDE and for workitem tracking the Teamsystem Web Access which allows you to control at least your workitems over a webinterface.
It's been awhile, but I'm thinking that it takes about a half-day to get setup, plus some time reading the manuals beforehand to make sure you know what you're doing. Configuration doesn't take too long -- you need to add all of your developers in as licensed users. Setting up projects is not too hard. I usually set up AD groups to map on the project roles and add those groups to the appropriate roles. I set up a new project in about 1/2 hour.
Note: I don't use any of the features of TFS except source control. If you plan to item tracking, use the project sharepoint site, etc., your mileage will vary quite a bit. I've found that on our projects (2-3 developers) a wiki works just as well for project management.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 7 years ago.
Improve this question
While using Aptana and Eclipse for the first time in my programming life for PHP projects, I am wondering how these projects get funded. There is a lot of activity in the Eclipse community and the IDE itself is very good. I came across various Eclipse IDE sites and I am not able to decide which one is the official site of the Eclipse project. There is also news that the community is also working on dynamic language integration and one Aptana product is already out there.
How the full-time and part-time programmers get funded in these projects? I came to know that Aptana has withdrawn it's PHP support. Will Eclipse continue supporting PHP?
From the Eclipse "About" page:
The Eclipse Foundation is funded by
annual dues from our members and
governed by a Board of Directors.
Strategic Developers and Strategic
Consumers hold seats on this Board, as
do representatives elected by Add-in
Providers and Open Source committers.
The Foundation employs a full-time
professional staff to provide services
to the community but does not employ
the open source developers, called
committers, which actually work on the
Eclipse projects. Eclipse committers
are typically employed by
organizations or are independent
developers that volunteer their time
to work on an open source project.
Support for various languages in Eclipse is through Plugins. There are a number of plugins to provide PHP coding support.
Aptana on the other hand is a for profit company spun out of the Eclipse code base. I believe their current business model is selling hosting and support. They used to sell a "pro" edition of the editor, but I can't seem to find that anymore.
The homepage of the eclipse project is http://www.eclipse.org.
As to the funding: some programmers are paid (for example by IBM which originally started the eclipse project, or companies that use Eclipse as part of their own product or strategy), and as with almost all open-source projects a lot of programmers really just work in their free time on a part.
Eclipse consists of a rather small core, and a lot of plugins, which are all developed by different individuals.
Open source projects get funded because the companies and individuals involved believe that it is in their best interests. For some, it is a matter of building reputation so that they can sell services in other contexts. Some companies fund the Eclipse Foundation in exchange for goodwill, business opportunities, advertising, and whatnot.
Pragmatically, creating and running an open source project is a good way of bring like-minded individuals together to share a development burden. Much of what is created at Eclipse, for example, is infrastructure and frameworks upon which applications can be be built. If you think about it, most of the software we use contains tonnes of functionality that you only really care about if it isn't there. You probably don't use Eclipse because of the fantastic component model (OSGi referenced implementation), or the ability to stack views, manage editors, workbench, etc. However, if all those things weren't there, you probably wouldn't use Eclipse. In general, it's probably the case that upwards of 80% of the functionality in any given application just isn't all that interesting unless it's not there. Some 80% of functionality is "plumbing". So instead of having a dozen separate organizations each spend time and money building infrastructure/plumbing that the end user only cares about if it isn't there, these companies come together in open source to work together on those shared bits of infrastructure that they ultimately use to compete against each other in the marketplace. They do it in open source so as to invite additional like-minded organizations to participate.
Other organizations get involved with open source to help develop a market. If you think of all the millions of people who just use Eclipse. If some small number of them choose to buy a useful plug-in or two, that can turn into a good business.
Some organizations bet their business on the technology. Eclipse RCP, for example, is used by--literally--hundreds of organizations to deliver applications. If an organization depends so much on a technology, it makes sense to invest time, energy, and money in it to make sure that it continues to exist and grow.
Here's an article that I found interesting:
http://news.cnet.com/8301-13505_3-10387512-16.html?tag=mncol;title
There are other reasons, but these are some of my favourite.
Often projects like this are simply people with an interest giving their own time, sweat and tears to produce great software.
Some bigger ones (Mozilla Foundation) form non-profit organisations and may get donations. Mozilla gets millions of $s through their referral to Google in their search bar - every search from that to google counts for cash.
Very occasionally it's in a company's benefit to produce something open source and even pay their workers to work on it. Take Google Chrome for example. It makes sense for Google to make their browser, and indeed pay their employees for it. But to keep people trusting them, and to allow for other developers to play and add to it, they've released the source code in the Chromium project, and anyone can download, compile and use that.
In regards to Aptana - that's a company, and they write open source free plugins to Eclipse etc so that people can write for and use their products. It makes sense for them to contribute as they'll get something back. I can't see any reference to them pulling their support though, but you may well have better sources.
Hope that helps!
They outsource everything to offshore cubicles.