Software architecture and agile process
Simon Tegg
Public
Seen by 23
Open-App has invested in upfront software architecture. This practice is controversial!
The 'Agile' perspective on software development focuses on delivering user-value early, then iterating quickly.
The 'upfront architecture' perspective on software development focuses on designing software to meet (often complex) requirements.
What are the tradeoffs in these approaches? Which approach or blend of approaches should the Open-App team follow?
Resources:
It seems there's a book called "Agile Software Architecture". The forewards are available online and discuss both perspectives:
http://www.sciencedirect.com/science/article/pii/B9780124077720099925
http://www.sciencedirect.com/science/article/pii/B9780124077720099858
The whole book is also available via Library Genesis http://libgen.org/get.php?md5=f1ef8ca2376b06e3af712efdbe5f7fc1
Bob Haugen Thu 21 Aug 2014 8:21PM
I'm spinning off from @jonrichter 's comment in the webdpack conversation that we had changed the topic and maybe should move the kanban comments somewhere else. Agile process might be the place.
Jon also asked, "Please tell me, which was the other development methodology that had been mentionned somewhere else before again, in opposition of lean methods? And what’s the difference there?"
Might be waterfall, or six sigma, or this guy makes distinctions between agile and lean (and six sigma), and when you should use one or the other:
http://blog.gardeviance.org/2013/11/oh-not-again-should-we-be-agile-or-six.html
http://blog.gardeviance.org/2014/07/agile-agile-everywhere.html
He did not spell out what he meant by lean as opposed to agile, but in manufacturing, lean production requires well-known repetitive processes and aims at zero non-wip inventory and zero waste. So in Wardley's map, where agile is used when you don't know what you are doing yet, in manufacturing that would be R&D and not lean production. Not sure where the analogy with software fits or breaks down...
Bob Haugen · Mon 4 Aug 2014 6:19PM
We use a combination. We got an overall model that we have used for many years, but we do every project in agile fashion. That is, we work with actual user groups and develop the features they need now, according to some combination of their priorities and the adjacent possibilities of what's already up and running. And then in between projects we re-generalize (go back to the model, redesign, re-architect, clean up, etc.).
Every approach has tradeoffs. Our model might not fit the situation. The communication between us and the user group might be lacking. Sometimes we make messes doing agile dev that we need to clean up.
Good tests help a lot. But are also a lot of work. We don't do unit test, we test chunks of functionality, especially the difficult parts. Sometimes we get lazy about it.
My understanding of the OpenApp roadmap was that it could also be a combination: start with an upfront design, then adjust at each of those roadmap stages. And you already got live users of the first apps to be integrated. So it's not as bad as the classical Big Design Up Front, which deserves its bad reputation. Just keep the upfront design light and don't get too invested in it.