From Kent Beck:
Because culture embodies perception and action together, changing culture is difficult and prone to backsliding.
Is it easier to change your perception or go back to designing the old way?
From Laurent Bossavit:
A process change will always involve a cultural change.
We were also a culture of Conviviality, which you could easily mistake (as I did at first) for a culture of Communication... In Conviviality what is valued is the act of sharing information in a group setting - rather than the nature, quantity, or quality of the information thus shared.
Culture is what remains when you have forgotten everything else.
From Mary Poppendieck and Ron Moriscato:
If there were one thing that Ron's team would do differently next time, it would be to do more refactoring.
XP is a process that doesn't feel like a process.
The theory of punctuated equilibrium holds that biological species are not likely to change over a long period of time because mutations are usually swamped by the genes of the existing population. If a mutation occurs in an isolated spot away from the main population, it has a greater chance of surviving.
From Ken Schwaber:
Agile process management represents a profound shift in the development of products and software. Agile is based on an intuitive feel of what is right, springs from a completely different theoretical basis than traditional development processes, and is in sum a wholly different approach to building products in complex situations.
From Matt Simons and Chaitanya Nadkarny
A fixed-bid contract changes the very nature of the relationship between customer and vendor from collaborative to "contentious". "Embrace change" undergoes a fatal transformation into "outlaw change."
There is no way to pretend everything is fine when you have to deliver software to your customer every few weeks.
From Nancy Van Schooenderwoert and Ron Moriscato:
The advantages of pair programming hit you hard and fast. As you explain an area of code to your partner, you get a deeper understanding of how it fits into the current architecture. You're your own peer reviewer!
After pair programming for a while, we found ourselves in a situation where the entire team had worked somewhere in the module in the recent past. Code reviews became exciting idea-exchanging periods where refactoring tasks were discussed and planned.
With schedule pressure, there is a huge temptation to put off refactoring, and we did too much of that.
It's not enough for the code to work; it also has to serve as a solid base for the next wave of features that will be added.
All through the project, a frequent cause was that unit testing wasn't thorough enough.
No comments:
Post a Comment