In my company..
In my company, we do use scrum with our development team. In most cases it works very well and the management are very happy. In some cases, where emergency support is involved, not so much, but they still like the structure of it and the fact that people commit to finishing things.
In all cases, very little testing is being applied and almost no documentation is written. I do realize that in the case of documentation, agile is suppose to cut down on those, but some form of documentation or changing some charts will be fine by me. In the case of testing, I think since I made a fuss about it, more testing has been done. But, I still think we could do much more about testing.
I spoke with my boss about it and how he looked at it was that, we had applied a process that brought in positive results and now we are at the next stage where we evaluate some of the problems that rose to the surface. Meaning, we are doing so well that we are fine tuning the process. I tend to agree with him on that. Even though technically, scrum does say that you need continuous integration testing, most places I have seen have been struggling with the testing sides of it. Oh, I did the self assessment on the nokia test and got a 5 out of 10.
Oh noes!! we must write tests now!
To be perfectly honest, its quite difficult to sell people on the idea of testing in general. Sometimes, when I mention testing, everyone thinks I am talking about moving everyone to test-driven-development. So in any case everyone is scared I am making earth-shaking changes to the whole process they are used to.
The (slight) Downsides of Tests
Tests themselves have issues that you need to maintain them. If you write a test with very specific parameters and values and then one day you change the actual behavior of the code, you will need to re-write your tests. You can avoid that by making your tests flexible for those changes, but you need to be aware and somewhat experienced in testing to do that.
Also, when you develop something new, writing tests can be much more simpler then writing tests when you are trying to fix old code. That is something I am particularly struggling with, since a lot of the work we need to do is patchwork to existing code. Just to add tests to existing code means you have to go into it, understand it and then apply some tests to it.
Conclusion
I need to study the issue more and try to apply it to my teams.
In any case, we need more testing and documentation (documentation is something I also plan to write about).
What I have decided to do is to try to do some of the following things:
1) Add certain tests as a requirement on the user stories
2) Do user stories that the whole process is to write tests for a problematic part of the code (the 20% of the code that causes 80% of the problems)
3) Do a face-off between 2 teams. One will use TDD and the other one won't. This will be a proof of concept that TDD is faster to develop then with regular development or even it is slower, only marginally slower and has the addition of all the extra tests.
Here are some questions I have asked on stackoverflow:
How do you apply Scrum to maintenance and legacy code improvements?
Scrum, but with no testing or documentation
No comments:
Post a Comment