Yes, claims Jean-Luc Mazet at WritersUA, user documentation can be developed using the Agile method.
But the project must be built on a foundation of all stakeholders buying in to the approch. They must understand the benefits and successful outcomes of such Agile development, but over "selling" the approach seldom works. Instead show the results.
The writing should be very modular and re-usable. A Collaborative and pair authoring environment may work best. Regular meetings where team members report progress and discuss roadblocks are important. Peer review of writing and flow must be built into the process. Use times when software development makes documentation difficult to go back to some traditional processes and refine and organize the materials you have developed.
Your team motivation should be based on the five values of Scrum:
- Openness
- Courage
- Respect
- Focus
- Commitment
A mature, self motivated, self organized team works best in this environment. Documentation should be based on User Stories and show how features of the software fulfill those user stories. This kind of team will provide the most ROI for the stakeholder and customers.
Agile Terminology:
- Scrum: An iterative, incremental framework for project management often seen in agile software development, a type of software engineering.
- Pig: Person committed to building the product on a regular basis.
- Chicken: Person with an interest in the product and what the pig delivers.
- Product Owner: Representative of the customer's interest in the product. This person needs to be available at all times to answer questions and make decisions. Sometimes called the "single-wringable neck."
- Stakeholder: Internal or external customers and vendors or suppliers who will not be directly involved with the project, but may weigh in on the results of each Sprint Review.
- ScrumMaster (or Facilitator): Daily Scrum Meeting facilitator. Person who removes impediments (distractions, external influences) and enforces Scrum practices and rules.
- User Stories: Customer-centric, product requirements or features that can be summarized into one or two sentences. For example: "As a user of this product, I want to be able to log in and out from a central point."
- Sprint: Work iteration that lasts between 14 to 30 days.
- Sprint Planning Meeting: First meeting at the beginning of a Sprint to negotiate the work that can be achieved during that Sprint.
- Product Backlog or Backlog: Prioritized product requirements for customer-deliverable features and internal technical requirements.
- Sprint Backlog: Represents the tasks for the Sprint and the Product Backlog items.
- Daily Scrum Meeting or Standup Meeting: The short (15 minutes) team meeting where each "pig" participant reports their progress from the day before, what they have scheduled for the day ahead, and the impediments that prevent their progress. "Chickens" listen in and do not report status.
- Sprint Review Meeting: Held at the end of the Sprint to show the accomplishments of the team, usually a prototype or potentially shippable product that demonstrates the tasks and goals set at the beginning of the Sprint.
- Sprint Retrospective Meeting: Held by the team and the ScrumMaster after the Sprint Review Meeting to assess what went well and what can be improved for the next Sprint.
5 dimensions that should affect what method you use, according to Boehm and Turner's book, “Balancing Agility and Discipline: A Guide for the Perplexed”:
- Critically: If the end result includes failure, what would the cost be? The scale ranges from just the lost of comfort to the loss of many lives.
- Personnel: The skill level of the project team members.
- Size: How many people are on your team?
- Dynamism: The number of requirement changes per month (How well can youir team define the requirements?)
- Culture: Is your team used to handling change, taking their own initiative, or are they used to order, to having thier work laid out in plans for them?
Additional Readings:
No comments:
Post a Comment