Документирование Agile Requirements¶
Автор раздела: Ivan Zakrevsky
В Scrum, PBI является основным, хотя и не исчерпывающим, способом документирования требований. Способы документирования остаются на усмотрение самоорганизующихся команд.
📝 "Documentation does provide value, but only when it's written to match its intended purpose. Agile business analysis practitioners produce documentation as they implement a change and use it to facilitate and support discussions with stakeholders.
<...>
Avoid producing documentation before it is needed, and when documentation is needed do just enough."
—Agile Extension to the BABOK® Guide version 2 (actual)
📝 "The close collaboration of customers with developers on agile projects generally means that requirements can be documented in less detail than on traditional projects. Instead, BAs or other people responsible for requirements will develop the necessary precision through conversations and documentation when it is needed (IIBA 2013).
People sometimes think that agile project teams are not supposed to write requirements. That is not accurate. Instead, agile methods encourage creating the minimum amount of documentation needed to accurately guide the developers and testers. Any documentation beyond what the development and test teams need (or that is required to satisfy regulations or standards) represents wasted effort. Certain user stories might have little detail provided, with only the riskiest or highest-impact functionality being specified in more detail, typically in the form of acceptance tests."
—"Software Requirements (Developer Best Practices)" 3rd Edition by Karl Wiegers
📝 "Views and Beyond and Agile agree emphatically on the following point: If information isn't needed, don't spend the resources to document it. All documentation should have an intended use and audience in mind, and be produced in a way that serves both.
One of our fundamental principles of technical documentation is "Write for the reader." That means understanding who will read the documentation and how they will use it. If there is no audience, there is no need to produce the documentation. This principle is so important in Agile methods that it has been given its own name: YAGNI. YAGNI means "you ain't gonna need it," and it refers to the idea that you should only implement or document something when you actually have the need for it. Do not spend time attempting to anticipate all possible needs."
—"Software Architecture in Practice" 3d edition by Len Bass, Paul Clements, Rick Kazman
📝 "Create Minimal but Sufficient Documentation. Document-based approaches to managing solution intent and context do not scale. Indeed, they quickly become obsolete and inconsistent with one another. The alternative is a set of related digital models that define, design, analyze, and document the system under development. Some models specify system requirements and design, while others are domain-specific (e.g., electrical, mechanical, or some systems property).
—"SAFe® 5.0: The World's Leading Framework for Business Agility" by Richard Knaster, Dean Leffingwell
📝 "The preparation of specifications, design artifacts, and information items or documentation during agile projects is often limited, while software developers apply their time and skills to transform a scenario or narrative of a function ("user story") into a working, testable software element. Rather than preparing elaborate review packages for briefing at infrequent major milestone reviews, the team meets with stakeholders frequently to present informal evidence of completing a set of functions and to agree on the content of the next iteration. Documented information items focus on what will be needed for transition, operation and maintenance, such as operator and end‐user documentation and baselines of tested and released versions of software with test plans and test cases. Projects reuse organizational procedures for configuration and release management, verification, and incident and problem management. Where possible, bidirectional traceability is enabled and enforced by integrated automated systems and procedures for requirements management, architecture and design, configuration management, measurement, and information management."
—"ISO/IEC/IEEE 12207:2017 Systems and software engineering - Software life cycle processes"
