|
Yes and no. Testing is a very important part of agile, yet if you don't have a somewhat final internal design, you will find yourself changing your unit tests every time you refactor your code. As a rule of thumb, changing your unit tests is a no-no. First off, it means your code is brittle. Second is that you can't trust tests that must change every time your code changes. Might as well not even have them. Unit tests are supposed to tell you if your refactoring is still working. For the most part, you should only refactor implementation details, not the "API". There is also a design to uncertainty trade off. The less you know about something, the less time you should spend designing because you can't design something you don't understand. But the more your understand something, the more time you should probably spend designing. Knowing how much design is too much is subjective and personal. I forget where I read it, XP(Extreme Programming) or Code Complete, but someone worth listening said, to paraphrase, "I've never regretted spending more time on design before I started coding". And I'm pretty sure it was part of XP that said the main purpose of XP(Agile) is to deal with the unknown. The more you know, the less Agile and the more waterfall you should be, saying that for some projects, a 6 month sprint is perfectly valid. I am in an interesting situation where I am both the programmer and the domain expert. Generally customers come to our team describing a problem that other companies can't figure out. We're pretty much allowed to design everything how we feel like because we're the best at it. We can do virtually any project in a single go of it without feedback from the customer, but we still do agile because it helps with scheduling, planning, prioritization, etc. We're a "value add" team, which makes things really interesting. None of our work is sold, but the work is important to land large contracts for the companies core services. |