Confluence is a wiki. It has rich text creation tools and a very simple html-like editor. It has rudimentary content management tools, allows RSS feeds and works very well in as an Agile Project Document creator, distributor and workflow handler. Atlassian also makes Jira, an issues tracker, project management tool that integrates with pretty much anything but works especially well with Confluence (obviously). Each has add-ins for customization (free and paid). And you get the source code. There may be other tools as good or better, but I've used these to great advantage.
This time we look at Confluence from a conventional BA's point of view.
You just lost control of all the documentation, my friend, the one thing you thought you should never do. This was the hardest thing for me to let go when I was learning the Agile mindset. Heavy with Waterfall and Iterative (RUP/UML) methods, the idea of other people actually laying hands on my stuff (it is a wiki, you know) was horrifying.
I should have relaxed. The original is always there and you can set the wiki to allow the author to approve or reject changes. And remember: Agile and its various offshoots recognize something. The application has to support the business and mounds of paper do not support the business. Instead, killing trees does three things: 1. Makes the discovery and requirements gathering phases way, way, way too long, 2. Allows higher-up muckety mucks to point fingers at each other at UAT, Implementation or Hand-Over time to ruin your project and 3. Pretty much waste time and energy because Use Case creation always misses the hidden requirements.
Hopefully, you'll have admin rights in Confluence. You'll set up two tracks for your project in Confluence- Technical and Functional. The Architect and Lead Developer start the Technical side with architecture, coding and developer standards. Later, Open Source Application docs, control packages, parsers, database schemas, web services, objects and other things are added by Developers.
You (and the Information Architect and the web master if you're lucky enough to have the help) use the Functional Side, creating the master Functional Requirements, Non Functional Requirements, User Stories (anyone really have an end user or stake holder actually write a story and associated test(s)? I thought not.) specifications (the other stuff User Stories left out that used to be in Use Cases but the Developers want more detail as they code). Here's whatcha do:
Create a single Sprint page for each Sprint. Include the following:
At the top:
Fill in the table with your proposed Sprint list of work and your team has instant access to the documentation they need to ask questions, determine if there's enough detail to work the feature/issue or if the BA/IA needs to better develop the documentation (and find out which questions the Developer needs answers), make preliminary complexity estimates and prepare for the kick-off with the client. Do the same with the client. Allow comments but no changes on these pages.
After the kick-off and the sprint work list negotiation, adjust the wiki list appropriately (and do NOT be offended if the DevTeam recreates it on large chart paper and hangs it up in your war room- it helps in focus and people love to cross stuff off a list). You'll probably end up keeping the Status column up to date, but it only takes a few seconds.
Now you have a single source for your DevTeam, the Business Team and the Design Team (You and whomever is is helping you) to access any documentation on the current sprint. And you can drop issues and features the client wants onto your next Sprint Page because you create that one now since you're a sprint ahead of the DevTeam, aren't you?
Next I'll talk about creating User Stories and Specifications in the wiki.
This time we look at Confluence from a conventional BA's point of view.
You just lost control of all the documentation, my friend, the one thing you thought you should never do. This was the hardest thing for me to let go when I was learning the Agile mindset. Heavy with Waterfall and Iterative (RUP/UML) methods, the idea of other people actually laying hands on my stuff (it is a wiki, you know) was horrifying.
I should have relaxed. The original is always there and you can set the wiki to allow the author to approve or reject changes. And remember: Agile and its various offshoots recognize something. The application has to support the business and mounds of paper do not support the business. Instead, killing trees does three things: 1. Makes the discovery and requirements gathering phases way, way, way too long, 2. Allows higher-up muckety mucks to point fingers at each other at UAT, Implementation or Hand-Over time to ruin your project and 3. Pretty much waste time and energy because Use Case creation always misses the hidden requirements.
Hopefully, you'll have admin rights in Confluence. You'll set up two tracks for your project in Confluence- Technical and Functional. The Architect and Lead Developer start the Technical side with architecture, coding and developer standards. Later, Open Source Application docs, control packages, parsers, database schemas, web services, objects and other things are added by Developers.
You (and the Information Architect and the web master if you're lucky enough to have the help) use the Functional Side, creating the master Functional Requirements, Non Functional Requirements, User Stories (anyone really have an end user or stake holder actually write a story and associated test(s)? I thought not.) specifications (the other stuff User Stories left out that used to be in Use Cases but the Developers want more detail as they code). Here's whatcha do:
Create a single Sprint page for each Sprint. Include the following:
At the top:
- Sprint Number
- Date Started
- Date Ending
- Feature Name or Issue ID Number as a link to the Confluence-held User Story or Issue Tracker source page
- Description- VERY short description of the issue or feature
- Documentation: Links to specifications and/or associated issues or technical/architecture pages
- Assigned- this is whom the development team assigns to the work
- Status- I used the two Confluence statuses which were basically Complete and Not Started. I know there's a way to use the Jira Status field to trip this but never had a chance to play with it and make it work. Since we were doing all the time estimates and Statuses (Jeez, between the two PMs on one project and the Visionary Client, did WE have statuses).
- Trace- trace features to the Functional Requirements or Technical Architecture Documents you wrote or helped write during the Discovery Phase.
Fill in the table with your proposed Sprint list of work and your team has instant access to the documentation they need to ask questions, determine if there's enough detail to work the feature/issue or if the BA/IA needs to better develop the documentation (and find out which questions the Developer needs answers), make preliminary complexity estimates and prepare for the kick-off with the client. Do the same with the client. Allow comments but no changes on these pages.
After the kick-off and the sprint work list negotiation, adjust the wiki list appropriately (and do NOT be offended if the DevTeam recreates it on large chart paper and hangs it up in your war room- it helps in focus and people love to cross stuff off a list). You'll probably end up keeping the Status column up to date, but it only takes a few seconds.
Now you have a single source for your DevTeam, the Business Team and the Design Team (You and whomever is is helping you) to access any documentation on the current sprint. And you can drop issues and features the client wants onto your next Sprint Page because you create that one now since you're a sprint ahead of the DevTeam, aren't you?
Next I'll talk about creating User Stories and Specifications in the wiki.
Posts
No comments:
Post a Comment