This thread relates very closely to the following:
http://forums.atlassian.com/thread.jspa?threadID=9317&tstart=0
I thought i'd create a new thread for my discussion, as it is not limited to XP, and hence may have a wider audience.
Using Confluence and Jira to enable our software development process is something we have been focused on doing for about the past year and a half now. A little history of what we do: Our company, 7irene (www.7irene.com) has been focused in the Component Based Development (CBD) space for around 8 years now. We have a very strong focus on process and method ('Urgggghh' - I hear the XP guys spit ;)) For us: Process is Key. The way / method in which we build systems is crucial. Having been involved in both XP and RUP style projects we are aware that both styles have their shortcomings and there is a need for a something between the two. I want to keep this post quite specific to how we use Confluence and Jira to support our process without going into too much detail of what out process actually covers.
How we use Jira:
Weve taken Jira out the box and provided a set of customized workflows that facilitate our Software Development Life Cycle (SDLC). Our process, which can be thought of as a light instantiation of RUP, defines things like
- Features, mapping through to
- Use Cases
- Risks
- Change Requests
- Questions and Answers
- Etc&
In Jira we have created workflows for all of the above and more. Similar to the Atlassian guys, Jira is where we initially create and store everything related to our project. This means that each and everything in our project is tracked using Jira. The details of project artifacts are later added in Confluence. Typically a Project Manager will be responsible for ensuring resources all have enough / not too much workload assigned to them. Features get added to Jira, they move through their workflow, and typically get linked to Use Cases (UCs) once analysed. These are all assigned to individuals with additional tasks being creating as need be. Weve found Jira perfect for recording things like risks and change requests again customized workflows were used. A huge bonus of having all our Features and UCs in Jira is that ALL requirements are accounted for nothing is lost or slips through the cracks. No more does the dreaded cry of a Project Manager ring out in the ninth hour : Arrrrhhhhhhh, that feature should have been in that release!
Customizing the inbuilt notification scheme of Jira gives us the control we needed when deciding on how much information gets sent out to various users (yes&Jira does rock!)
Obviously we use Jira to record bugs, and with the Fixed version field we get the great road map feature. However, we have had a bit of problem in trying to use the Jira road map feature for things like Features and UCs. Typically these things dont quite fit with the concept of having a Fixed Version. Features and UCs are never really fixed rather they are planned for a certain timebox and then worked on. Sometimes Features and UCs are not completed in their designated timebox, in which case they need to be moved into a later timebox. Various new custom fields had to be created to handle the concepts of Timeboxes and Milestones. It also means we lose out on some of the kewl reporting capabilities of Jira when producing the release notes, but were tackling that problem with some custom reports. Enough Jira detail for now.
How we use Confluence:
We use Confluence to store the actual detail of almost everything in a particular project right down to the level of things like whos making the coffee tomorrow
. We create all our UC details in confluence and the other artifacts that make up a Software Requirements are captured or collated in confluence too. Model diagrams are stored in a SCS (Subversion in our case), and then linked into confluence using WebDav. This means we have an incredibly powerful ability to show developers absolutely everything theyd ever need to see for a particular UC on one single page. Weve found this to be a very powerful concept. Using some of Dave Petersons macros has made things like page real-estate so much better&. (Cheers Dave your work is excellent!) The linking capabilities of confluence make this environment almost perfect for us.
UC summaries captured in Jira are then linked directly to the confluence page that stores all the UCs details. Charles mentioned that the Atlassian guys are using a Confluence Page picker thing to link Jira issues to actual confluence pages. We have something very similar, although slightly cruder - We have a custom field in Jira called Software Requirements Homepage, which is a text field, and we simply cut and paste the URL of the confluence page into this field once the confluence page starts getting details added to it. Simple, but effective.
We make extensive use of templates having them for as many repetitive tasks as possible:
- Creating UCs
- Creating UC home page summaries
- Creating meetings
- Creating server / database / environment pages
Providing a detailed structure for a project to use - out the box, gives people the benefit of having structure to the way they work. Tasks can easily repeated and information can always be found. Initially some people may feel restricted in having to conform to a structured confluence site - but after a while the benefits are clearly seen, and we've had really happy project teams working across geographically distributed location.
Right, so now I have rambled....
As i mentioned, we've been working on things for a while now, and I cant cover everything in a single post. Probably the best thing to do, if any are interested, is to have a look at our demo site:
http://archetype.7irene.com/portal/display/APD/Portal+Perspectives
You can log onto this demo site using : clientuser / clientuser as credentials.
The site is not really something we usually exposed to people without some form of consultancy around our process first. However, seeing as its the confluence community, Im sure youll see how things work soon enough. Anyway, Im more interested in showing you guys the Jira / confluence collaboration. Ill be more than happy to chat to anyone in more detail off line.
A few pointers on the demo site:
1. The confluence portion is what we call our Portal product.
- It is made up of perspectives essentially one perspective for each role in a project that we keep context sensitive information about.
- Each perspective contains information about a particular role. A How To so to speak on a specific role.
- There is common information across each perspective weve taken the view that information is global, and should be shared across a project
- In each perspective the main points of interest will possibly be the decks and cards on the left - showing all the workflow products that have been assigned to specific users.
- The right hand cards show content that is specific to:
- The perspective you are currently in, and
- A common view of the project.
- The Software Requirements home page will be of interest to the developer peps as its got all the artifacts grouped together in one place&. So a single point of contact for a developer.
The Use case model, and use case itself
The type model
The component interactions
The component spec architectures
There is also a link taking the user straight to the jira entry so they can see any discussions that have been happening around the Jira entry itself.
- With regard to how we structure our confluence spaces we are making use of the Reusable Asset Spec to define and organize our project artifacts. Essentially artifacts are grouped into:
- Things that are reusable Assets. These consist of most of our archetype content assist information, and
- Things that are not reusable project artifacts. These include project plans, meeting information.
The spec has just been adopted by the OMG, and you can check out more info on it here:
http://www.flashline.com/ras/ras.jsp?sid=1132709233868-1123631142-101
- As I said before, it may appear confusing at first, and ideally someone should really guide you through the various portions of the product. For now the demo site will have to do.
2. The Jira portion is what we call our Workflow product. The default dashboard has been customized for each user, and will have a different look and feel per role. The clientuser logon is a very simplified view on the product.
3. We are playing around with the look and feel of demo site at the moment hoping to make it a more intuitive experience for project members. One of the things you may notice is that on specific Perspectives, the performance may be a bit slow. This is because currently there are loads of filters being loaded into this single page. We may decide to move these filters off onto another page so that each perspective page loads quicker.
Have a look and please feel free to let me know your thoughts you should be able to add comments to all the confluence pages&. So go wild
Regards
Giles Parnell
