From waterfall style having extensive documentation for each SDLC phase till the Extreme programming \/ SCRUM with very basics like user stories<\/p>\n
I must add here, when teams say we’re going \u2018Agile\u2019, so don’t need anything except for user stories, that does not make me happy<\/p>\n
Too much we run into problems of maintaining them,<\/p>\n
Too little, and as soon as one or two key people leave their position, everyone is in trouble<\/p>\n
It should be enough to sustain development, and keep the process lean enough<\/p>\n
I guess everyone would agree on all the aforementioned, the problem is \u201cStriking the right balance\u201d..<\/p>\n
I’d like to propose the following as a yard stick:<\/p>\n
– Anyone wishing to understand any part of the code should not have the need to hunt down people to understand. Sufficient commenting and coding practices should be used<\/p>\n
– Anyone wishing to learn about how the system should behave in a certain scenario, can find that info without bugging every single developer.<\/p>\n
For application domain, one can utilize user stories, gherkin feature files (BDD), mind maps, test cases, client specifications<\/p>\n
For code understanding, code documentation, commenting, coding practices, architecture documents<\/p>\n
Thoughts?
\n#QsDaily #RedefiningSoftwareQuality<\/p>\n<\/div>