A week ago I was looking at the presentation Integration Tests are a Scam.
First thing that came to my mind: Is he cynical with the title? (How can we blame integration tests?) The problem is using integration tests for things that should be tested at the unit level. In other words, the problem is not using integration tests for what they should be used: Just to verify that the integration between the different components is not generating any problem (well.... he is not talking about functional tests, right? Functional tests are integration tests, but everybody recommends having them as way to check that the business features are constructed the way they are supposed to be. )
Second thing: Why is it so hard to define a strategy that makes heavy use of unit tests? (e.g. as suggested by Cohn's pyramid). Is it because TDD is very difficult to learn? Is it because QA departments define the strategy (and they are more into the functional aspects/tests). Is it because of the managers?
Who can we blame for this scam? I think that we all as a community need to take responsibility. We need to understand better the benefits of unit testing, we need to be trained and we need to DO THEM!
Wednesday, September 30, 2009
Sunday, September 27, 2009
Tuesday, September 22, 2009
Agile brushstrokes
Agile Transitions, by Joshua Keriesvky :-)
I between this weird comparison, Keriesvky said that in his actual project (where I assume there was not very junior people) they are not using fixed time iterations, they are not calculating velocity, they are not dividing the user stories in tasks, they were not holding retrospectives (formally, they would do it whenever it's necessary). That was pretty amazing to hear. No rules, just what works. I guess you need to be VERY mature to do such a thing.
 | Agile Baroque Transition |
 | Agile Impressionist Transition |
 | Agile Expressionist Transition |
 | Agile Graffiti Transition |
I between this weird comparison, Keriesvky said that in his actual project (where I assume there was not very junior people) they are not using fixed time iterations, they are not calculating velocity, they are not dividing the user stories in tasks, they were not holding retrospectives (formally, they would do it whenever it's necessary). That was pretty amazing to hear. No rules, just what works. I guess you need to be VERY mature to do such a thing.
Thursday, September 17, 2009
Yet Another Bug Versus Feature Post
A couple of weeks ago I was talking with the Requirement Analyst of the project. He was basically complaining that some members of the team are too rigid in their definition of bug. Everything that is not explicitly specified in the acceptance criteria of the user story is a bug. It is deterministic. But is it really like that?
The way I see it, a user story goes through different phases of understanding and its scope is refined in each of these phases. First, it starts as an idea of something that can contribute value to the application in mind. At this moment, everybody is living in the world of ideas and that world doesn't have any restrictions or constraints. The scope of this user story is completely blurred.
When the story is estimated for the first time, it transitions to the second phase. Developers go through it for the first time, providing hints on the feasibility of the user story (or what would need to be changed in order to be feasible). QAs also help refine the story because of their ability to think of the different scenarios this user story could apply to. This is the first time (usually) the team (or at least a representative part of it) look at the user story and discuss about it. The user story takes shape. Acceptance criteria are usually added (based on the questions and discussions that arise) and the scope is radically refined to a point where the team should understand at least what needs to be done.
The planning meeting represents the third phase of refinement for the user story. At this point, the product owner explains the user story to the whole team. This should be the last phase because a scope is agreed on and a final estimation, to which the team commits to, is made based on it. But is it?
When the user story begins to roll and QAs start thinking about scenarios and test cases, developers start designing and something starts to emerge, the understanding of the user story changes a great deal. Even more, seeing something concrete triggers new ideas or unveils constraints that were overlooked. Continuous communication and collaboration between the team and the product owner is vital to overcome problems and accommodate all necessary changes. Finally, the user story is completed and with it, the user story transitions to its last phase.
All of these phases happen usually in a very short period of time in most agile projects. There isn't a big upfront analysis and design period and the project start with just the vision and a bunch of user stories understood. The rest is decided on the road. Even more, in many cases, the requirements will change and a successful agile team should be prepared to handle this. The key to be successful in this environment is to have a gelled team with a lot of criteria.
So what happens when after the user story is completed, some part of the functionality doesn't meet the expectations of the product owner or some of the stakeholders. The question: is a bug or a feature always arises. The easy answer is: if it's not among the acceptance criteria listed, is a feature request. I don't think it should be that easy. I believe the team should use its best criteria to determine if the issue is far enough of the core of the user story to be considered a new feature request. I believe Agile relies on a bunch of crafted people that add value during the whole life of the user story and I believe that a shared framework of understanding should exist between the product owner and the rest of the team (this is key for the success of the project). In other words, a successful team understands what is being expected of the product, which is the criticality of it and what is the level of necessary quality. Having all of these things in mind, the team can make a decision and my opinion is that if the issue belongs to the core of the user story, it is just healthier for the group to recognize it was missed and track it as a bug.
Changing the perspective, perhaps it doesn't even make sense to make this distinction. A new level of understanding has been reached for the user story and what is important is to decide if the missing functionality is required for the next release or not. This makes the decision even easier. One of the reasons the team has to categorize something as a bug is that if it’s a bug, it will probably need to be addressed for the release and so it implies more work. If it is a new feature request, it will probably go to the next release. If the product owner, who is the person responsible for the ROI of the project, decides this need to be included, the decision falls to how it is going to be tracked.
The way I see it, a user story goes through different phases of understanding and its scope is refined in each of these phases. First, it starts as an idea of something that can contribute value to the application in mind. At this moment, everybody is living in the world of ideas and that world doesn't have any restrictions or constraints. The scope of this user story is completely blurred.
When the story is estimated for the first time, it transitions to the second phase. Developers go through it for the first time, providing hints on the feasibility of the user story (or what would need to be changed in order to be feasible). QAs also help refine the story because of their ability to think of the different scenarios this user story could apply to. This is the first time (usually) the team (or at least a representative part of it) look at the user story and discuss about it. The user story takes shape. Acceptance criteria are usually added (based on the questions and discussions that arise) and the scope is radically refined to a point where the team should understand at least what needs to be done.
The planning meeting represents the third phase of refinement for the user story. At this point, the product owner explains the user story to the whole team. This should be the last phase because a scope is agreed on and a final estimation, to which the team commits to, is made based on it. But is it?
When the user story begins to roll and QAs start thinking about scenarios and test cases, developers start designing and something starts to emerge, the understanding of the user story changes a great deal. Even more, seeing something concrete triggers new ideas or unveils constraints that were overlooked. Continuous communication and collaboration between the team and the product owner is vital to overcome problems and accommodate all necessary changes. Finally, the user story is completed and with it, the user story transitions to its last phase.
All of these phases happen usually in a very short period of time in most agile projects. There isn't a big upfront analysis and design period and the project start with just the vision and a bunch of user stories understood. The rest is decided on the road. Even more, in many cases, the requirements will change and a successful agile team should be prepared to handle this. The key to be successful in this environment is to have a gelled team with a lot of criteria.
So what happens when after the user story is completed, some part of the functionality doesn't meet the expectations of the product owner or some of the stakeholders. The question: is a bug or a feature always arises. The easy answer is: if it's not among the acceptance criteria listed, is a feature request. I don't think it should be that easy. I believe the team should use its best criteria to determine if the issue is far enough of the core of the user story to be considered a new feature request. I believe Agile relies on a bunch of crafted people that add value during the whole life of the user story and I believe that a shared framework of understanding should exist between the product owner and the rest of the team (this is key for the success of the project). In other words, a successful team understands what is being expected of the product, which is the criticality of it and what is the level of necessary quality. Having all of these things in mind, the team can make a decision and my opinion is that if the issue belongs to the core of the user story, it is just healthier for the group to recognize it was missed and track it as a bug.
Changing the perspective, perhaps it doesn't even make sense to make this distinction. A new level of understanding has been reached for the user story and what is important is to decide if the missing functionality is required for the next release or not. This makes the decision even easier. One of the reasons the team has to categorize something as a bug is that if it’s a bug, it will probably need to be addressed for the release and so it implies more work. If it is a new feature request, it will probably go to the next release. If the product owner, who is the person responsible for the ROI of the project, decides this need to be included, the decision falls to how it is going to be tracked.
In conclusion, a successful scrum team should first ask the product owner if s/he thinks the functionality missing is important for the release and then track and prioritize the work that needs to be done. A team should be fond of their work and their craft and it should use its best criteria to make the decision. And finally, if it is a new requirement, it needs to be prepared to change. We live in a very competitive world where business conditions change all the time. The success of the team depends on being able to accommodate those changes.
The success of the team relies on being really Agile.
Monday, September 14, 2009
The Agile Mantra
The Agile Mantra
It's undeniable that our professional life creates paradigms and structures that we then follow in our day to day life. Agile has influence me. Schwaber's and Poppendieck's book's concepts come to my mind frequently, in aspects of my life that have nothing to do with software development.
For example
- I am constantly trying to eliminate waste - What is waste in my everyday? Well, plans that keep hanging in my head forever. They are waste, because I keep thinking about them and I never do them. Also, I tried to do things well for the first time. If I don't do them well, it is highly probable that I will have to in the future (they are bugs!).
- Value Stream Mapping - Whenever I am following a process, I try to optimize. Look for the places I'm just waiting, try to identify things to improve etc. I am talking about the most stupid things like the process I follow to lock my bike when I go to work (including where I hang the key after locking, to be able to find it faster when I get out!)
- Continual Introspection - I am continually trying to find better ways of doing things. It doesn't matter whether it is the diswhashing, the path to the train/work or a more serious task. I continually introspect and act on the results.
- Look for the value on the things I do - I started to ask the question "what is the value of this" instead of doing things automatically. This was a big change. I was very used to doing the things they told me to do, not inquiring much on the reasons. Today, I have a much more critiquing attitude.
Maybe, I am going to far, but Beck's TDD book has influenced me in the way I tackle a problem. Before, I wanted to get it all solved in one shot. Now I do it in steps, taking checkpoints in the middle. Other things that I value more now are quality. Bake quality in or do things better. I value communication and I understood the difficulty of it.. What else? Well, this whole Agile world has an impact on our everyday life, right agilists?
For example
- I am constantly trying to eliminate waste - What is waste in my everyday? Well, plans that keep hanging in my head forever. They are waste, because I keep thinking about them and I never do them. Also, I tried to do things well for the first time. If I don't do them well, it is highly probable that I will have to in the future (they are bugs!).
- Value Stream Mapping - Whenever I am following a process, I try to optimize. Look for the places I'm just waiting, try to identify things to improve etc. I am talking about the most stupid things like the process I follow to lock my bike when I go to work (including where I hang the key after locking, to be able to find it faster when I get out!)
- Continual Introspection - I am continually trying to find better ways of doing things. It doesn't matter whether it is the diswhashing, the path to the train/work or a more serious task. I continually introspect and act on the results.
- Look for the value on the things I do - I started to ask the question "what is the value of this" instead of doing things automatically. This was a big change. I was very used to doing the things they told me to do, not inquiring much on the reasons. Today, I have a much more critiquing attitude.
Maybe, I am going to far, but Beck's TDD book has influenced me in the way I tackle a problem. Before, I wanted to get it all solved in one shot. Now I do it in steps, taking checkpoints in the middle. Other things that I value more now are quality. Bake quality in or do things better. I value communication and I understood the difficulty of it.. What else? Well, this whole Agile world has an impact on our everyday life, right agilists?
Tuesday, September 1, 2009
Can't image Agile 10 years ago
A few days ago, I was taking an interview to a person that never ever had hear about Agile. All of his life he worked with waterfallish methodologies. So after he explained the way he used to work, we explained him the way we were working. We told him that he had 3 weeks iterations, during which we wrote the tests cases, implemented the user stories and tested them. He looked with an incredulous face and ask: "but do you actually implement that functionality or just think about it?". Wow!!! Right away, I started thinking about those first pioneers and the reactions they must have faced 10 years ago. They must have think they were out of their minds, totally crazy. If I think about it, I would have think the same. Imagine yourseld doing 6 to 12 months projects and all of a sudden someone comes and say we need to this in 3 weeks cycles.. Knowing my limitations, I am sure I wouldn't have understand him....
Subscribe to:
Posts (Atom)