Discuss Software User Assistance in Open Source and Agile Development http://antitechwriter.com/antitechwriter-blog/59-software-user-assistance-in-open-source-and-agile-development.html Sun, 05 Sep 2010 07:07:15 +0100 FeedCreator 1.7.3 http://antitechwriter.com/antitechwriter-blog/59-software-user-assistance-in-open-source-and-agile-development.html#comment-2 I mostly agree with you, too. It's true that agile doesn't say to skimp on user doc. It doesn't really say anything about user assistance at all. Agile was designed as an approach to software development, not user assistance development. In a waterfall process there are tried and true ways of creating user assistance that fit within the software development process. But with agile, we have new opportunities for creating better user assistance than ever before. I believe that those of us who are working to help users with new software products have to think about helping users get access to the most accurate information in a timely manner. Going straight to the source -- the developers -- is the answer. And thanks to the agile philosophy of getting feedback from customers at every stage, user assistance professionals can provide just what the customer needs and not try to second guess those needs by producing volumes of user docs. And so, I agree with you again, when you say "... the key point is about producing the right doc at the right time." That's why I believe user assistance professionals must now learn to provide accurate and easy-to-access user assistance in and on-demand fashion. It may mean becoming more of an editor and a project manager than just a tech writer. Administrator Tue, 14 Jul 2009 17:24:03 +0100 http://antitechwriter.com/antitechwriter-blog/59-software-user-assistance-in-open-source-and-agile-development.html#comment-1 I mostly agree with you. But I will note that Agile doesn't say skimp on user doc. What people sometimes get confused by is that agile does indeed say not to produce endless *developer* doc. For example, the agile manifesto says that we alue "working software over comprehensive documentation". In context, what fowler/highsmith were clearly talking about is engineering documentation. They clarify this when they say " We also want to restore a balance: We embrace modeling, but not merely to file some diagram in a dusty corporate repository. We embrace documentation, but not to waste reams of paper in never-maintained and rarely-used tomes. We plan, but recognize the limits of planning in a turbulent environment." Another example: "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. In a recent workshop, a software development manager questioned the feature or story approach to iterative cycle planning. "But aren't requirements specifications and architecture documents important?" he asked. "Yes," Jim replied, "They are important, but we need to understand that customers don't care about documents, UML diagrams or legacy integration. Customers care about whether or not you're delivering working software to them every development cycle‹some piece of business functionality that proves to them that the evolving software application serves their business needs." So, the key point is that agile is about producing the right doc at the right time. Just like it's about producing the right code at the right time. Norm Gundersen Tue, 14 Jul 2009 17:04:36 +0100