1 / 17

Rally: One Writer’s Perspective

Rally: One Writer’s Perspective. Background. 28 years in technical communications including Symantec, Autodesk, and Cisco. Participated in Rally-based projects for past three years. Seen varied approaches to Rally:

leanna
Download Presentation

Rally: One Writer’s Perspective

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Rally:One Writer’s Perspective

  2. Background • 28 years in technical communications including Symantec, Autodesk, and Cisco. • Participated in Rally-based projects for past three years. • Seen varied approaches to Rally: • Rally-to-the-letter approach with daily scrums, calculated burn rates, task balancing, and more • Sophisticated “to do” lists

  3. What is Rally? The Agile Manifesto • In February, 2001, 17 software developers met at in Snowbird, Utah, to discuss lightweight development methods. • They published the Manifesto for Agile Software Developmentto define anapproach now known as agile software development.

  4. What is Rally (contd)? Agile Manifesto: We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: • Individuals and interactions over processes and tools • Working software over comprehensive documentation • Customer collaboration over contract negotiation • Responding to change over following a plan

  5. What is Rally (contd)? The Agile Manifesto is based on twelve principles: • Customer satisfaction by rapid delivery of useful software • Welcome changing requirements, even late in development • Working software is delivered frequently (weeks rather than months) • Close, daily cooperation between business people and developers • Projects built around individuals, who should be trusted • Face-to-face conversation is the best form of communication (co-location) • Working software is the principal measure of progress • Sustainable development, able to maintain a constant pace • Continuous attention to technical excellence and good design • Simplicity—the art of maximizing the amount of work not done—is essential • Self-organizing teams • Regular adaptation to changing circumstances

  6. Personal Thoughts • Agile is simply another development model • Others: • Rapid Application Development (RAD) developed in the mid-1970s • Structured Systems Analysis and Design Method (SSADM) • Waterfall • Dozens more

  7. Personal Thoughts (contd) • Models are simply…..models • Regardless of model, software development goals are the same: produce quality software that meets the needs of customers in the shortest amount of time possible. • Every engineering team has an approach that reflects their management and unique collection of engineering personalities.

  8. Personal Thoughts (contd) As a documentation writer, the methodology really should not matter; our goals are the same: to help customers: • Use the application quickly and efficiently. • Get the most benefit from their investment.

  9. Personal Thoughts (contd) To that end, getting the information and understanding to produce accurate, high quality documentation….is always a struggle!

  10. Personal Thoughts (contd) Waterfall Method---Engineers (should) prepare functional specs to allow the writer to complete the user documentation. The reality? • Some specs are great; others are less so. • Some engineers are great writers; others less so. • Engineers often not native English speakers. • Specs prepared at start of a release but not updated.

  11. Personal Thoughts (contd) Agile---User stories (should) contain sufficient information to allow the writer to complete the user documentation. Details can be in the story or in docs attached to the story. The reality? Some user stories contain detailed information; others do not.

  12. Demo Cisco Prime Performance Manager: • All user stories have a Doc Required flag. • If set to true, in the opinion of the engineer, the user story requires user documentation changes. • If the Doc Required flag is on, the engineer (should) add a Doc Notes task to the story describing the documentation impact.

  13. Demo (contd)

  14. Demo (contd) • Rally stories are in one of four states: • Defined • In Progress • Completed • Accepted • Doc development begins with Accepted stories, then moves to Completed ones.

  15. Demo (contd) Rally stories with Doc Required = True should contain a Doc Note task explaining what the documentation changes are.

  16. Demo (contd) • Doc Required stories allow accurate completion reporting at weekly program team meetings: • Completed program: • Program just started:

  17. Final Thoughts • It’s not the methodology; it’s the people. • Communicative, articulate engineers make documentation development easy. • Non-communicative, inarticulate engineers make one feel like a detective looking for clues in a murder case. • But that’s what makes tech doc writing….. • So much fun!!!

More Related