I first started thinking seriously about software development process after reading Extreme Programming Explained (embrace change) by Kent Beck (I believe I read this in 2002).
Since then, I've been interested in being involved in moving the software industry forward as far as process and communication with customers and users.
The Agile movement is a great step towards improving this relationship.
Lately, Scrum seems to have the best chance of giving non-software developers (and developers alike) visibility into iterative software development.
Personal thoughts on Software development methodology
- Software has infinite potential - and therefore is NEVER done (individual releases can obviously be completed)
- Building software is not like building a building or bridge
- Minimize the time before the first release - this is the time when it's easiest to get off the path to revenue / valuable software, become extremely inefficient, etc
- Customer(and especially end user) feedback is probably the most important input into great software
- An attempt to write equation for the value of a piece of software:
- Value = (Number of users) * (value/user factor) + (Number of iterations/releases) * (feedback responsiveness factor)
- Embrace Change (on the principle: the only thing constant is change)
- It's better to strive to maximize efficiency than to strive to maximize output
- Estimation: Stop trying harder: http://geepawhill.org/?p=98
- The most effective way to get people to follow your process is to make it easier (or otherwise more beneficial to them) to follow than not. This approach also doesn't require any special authority to implement.
- Ken Schwaber of the The Scrum Alliance's a value packed Scrum Guide
- Of course the XP Explained book
- Martin Fowler - The New Methodology
- Agile Manifesto
- Chad Fowler (not related to Martin) - The Passionate Programmer
- Spotify's approach to scaling Agile: https://dl.dropboxusercontent.com/u/1018963/Articles/SpotifyScaling.pdf
- Why are software development task estimates regularly off by a factor of 2 to 3?
- Some info on appropriately sizing user stories: Something I came across through Agile San Diego group on splitting user stories: http://www.agileforall.com/wp-content/uploads/2012/01/Story-Splitting-Flowchart.pdf
- It’s a bit detailed, but the idea is to put some rules around how big your stories should be. And apply a mnemonic test: INVEST (Independent, Negotiable, Valuable, Estimable, Small, Testable).
- Some interesting stuff to think about. Couldn’t figure out what the meaning of Negotiable was, but it appears to be suggesting that it’s not good to over-specify: http://xp123.com/xplor/xp0308/index.shtml Obviously there’s a tension between that and testable acceptance criteria.
- article: why crunch time doesn't work