Agile design

Notes de l'éditeur

1. \n
2. \n
3. \n
4. \n
5. How’s one related to another?\n
6. early - link4 software\ncontradiction: early and contin. deliv. quality-wise\ntechnical debt is nearly always a design debt\n\n
7. importance dependent on scale of the project\nmodularity\ntests!, Mach grid story\n\n
8. Elaboration / exploration phase (architectural prototype: do the most risky USs)\nfirst iterations should touch all main modules (coverage): organize first stories by risk, value, coverage\nanswer to: how are we going to implement and test it?\n
9. This is the LEAST we should be doing\nMach doesn’t need cont delivery on PROD, but to dev env\n
10. JEDI - Just Enough Design Initially not to overdesign or get simplistic design\ndomain modelling to visualise concepts, deepen requirements & understanding, keep design close to reqs\n\n\n
11. eliminating complexity by introducing abstractions\norganize essential complexity, minimize accidental\nrigidness (hard to change), fragility (changes result in bugs), immobility (no reuse)\n\n
12. \n
13. CRC - discuss objects and roles not classes, find contextual models, distribute functionality by responsibilities\nOne fact in one place achived by slicing + layering; slices take care of functions, layers of technology\n
14. net of collaborating objects\ncohesion (methods relate to elements of objects, naming, level of abstr)\ncoupling (number, type), heuristics (why I like some code)\n
15. Good side - discussion on improvements, expectations from the design\nBad - easy to make decisions about big refactorings\nHumility important when designing (and deciding about designing)\nNot all people in team are equal, this is not comunism. Have good people onboard!\n
16. 1. do design, deepens understanding, makes realistic planning possible, \n2. whatever you design, don’t think of it final\n
17. \n