To achieve good software, documentation is essential – even in agile software development! I would like to highlight two functions of documentation here: (1) Creating a common understanding. (2) Sharpening one’s own thoughts.
(Ad 1) You probably know this too: You talk about a matter and believe that the other person has understood you. However, the other person has many implicit assumptions, with which they fill gaps in explicit communication, and they understand something different than you under the terms used. How often have you left conversations and later regretted that the spoken word was not really understood or misinterpreted? Writing down the spoken word together and finding the right words in dialogue is a very effective method to ensure a common understanding – the result is documentation. So, nothing bad. No overhead. But ensuring a common understanding. In the context of requirements and software engineering, formal languages such as BPMN for business processes and UML/SysML for models of (software) systems help us. If you document a matter with such notations, the probability of really meaning the same thing and understanding each other is significantly higher. It also ensures that all relevant perspectives are addressed. Have you also thought sufficiently about the associations in a class model? Does a customer have no contract, exactly one, or several? Is a person without a contract even considered a customer?
(Ad 2) Writing down your thoughts makes them clearer. Consistency, lack of contradiction, completeness, and correctness often become apparent only when you have put your thoughts into writing – the result is documentation. So, nothing bad. No overhead. But a reflection surface for consistency, lack of contradiction, completeness, and correctness.
Schreibe einen Kommentar