Thank you for the certified scrum master training last week in Beijing. Your training is very impressive, and I appreciate it a lot. I asked you a lot of questions; may I ask one more? In our company, the automation for regression tests hasn’t been set up, yet. Without automation of the regressions tests, unit test, and pair-programming, how can our scrum team improve the quality of the product?
First, let me encourage you to keep up the work to automate your regression tests. Few things have as big a return on investment. Test automation enables the team to move much faster and make improvements fearlessly. The other practices you mention: unit testing and pair programming, are also great practices, and I encourage your team to try them too.
Having said that, your question was what else could your team do. Additional practices I would recommend your team consider are: code reviews, frequent testing by real users, testing bashes, and whole-team ownership of quality and testing.
Read the full article…
“Insanity: doing the same thing over and over again and expecting different results.”
~ Albert Einstein
Are you a survivor of insane software development? Design-code-integrate-test-deploy. Maybe it’s time for a different approach.
Test driven development takes some of the insanity out of the software development process by shifting the emphasis on testing from post-development necessity to the first objective in the project. Create a test and see it fail. Then write enough code so that the test passes. Then refactor mercilessly.
Read the full article…
Chris just published an article on InfoQ called Refactoring is Not A Substitute for Design about the debate over what role design plays in agile development. The worry is that agile processes shortchange the very principles of good design, because so much of agile happens at the granular level while design is seen as a macro-level activity. But is that the case? Here is the bit that I consider Chris' main point: Big Design Up Front is not design; it is just one way to accomplish design.
Agile practitioners tend to prefer a different approach, in which the current design emerges in response to the actual functionality being supported. The design reacts and adapts to the needs of the system, which itself is constantly evolving and adapting to the needs of the customers.
Chris addresses a common misconception, that foregoing up front design in favor of an agile process is tantamount to no design at all. Yes, yes, agile is anarchistic, the sky is falling, and kids these days listen to the darnedest music, we know, we know.
It strikes me that this type of sea-change has all happened before:
When the first impressionist painters broke the rules by dispensing with classical rendering and embracing naturalistic forms and gestures, a great many people refused to call it "art." But in hindsight, we now recognize the equal level of artistry involved in making art that departed from classical norms. Just because Van Gogh didn't block and draw on the canvas with charcoal before he took up his palette knife didn't mean he lacked an eye for shape, perspective and line: in fact, art students now are taught that "You must know the rules by heart in order to break them." The expectation now is that artists will be able to break the rules, and thus they are now expected to know these things at the cellular level.
I predict that we'll look back on this change in our attitudes toward design and software in much the same way–we'll think of the curious olden days when developers were seen as code monkeys wrenching on software that someone else designed. By engaging developers in all aspects of coding, and including design and test, agile actually seeks to elevate design and function to a higher level of importance, to where it's part of everyday practice for everyone who writes code.