Friday, October 30, 2009
Current number of Unit Tests
I just added a new Gadget in the sidebar, where we'll show the current number of Unit Tests in our project. We're starting now at 21 unit tests.
Friday, October 23, 2009
Presenting XP - our XP
I just held my fourth presentation of XP this month. The first was on the startup meeting, the second with the team, the third was for the customer and today it was for the entire tech department of Creuna Sweden.
The first occation was alot about selling the idea to the company. That presentation was based on the article What is XP by Ron Jefferies along with a couple of slides I added about why this was good for us, both in this project and in the long run. On the rest of the presentations I have just had one slide, One Page XP by Bill Wake, and talked freely about XP from upper left to lower right, adding things as I pass the different stages.
The second occation was to get the team started, trying to figure our the roles and responsibilities among us. What are the Interaction Designer, the Test Leader and the Project Manager supposed to do? We've decided on having the Interaction Designed being in charge of the user stories, and coordinating them with the customer. Along with the Test Leader she then writes proposed Acceptance Tests for each story. The Test Leader is then in charge of implementing the Automated Acceptance Test using Selenium and also doing the manual testing where Selenium can't be used. The Project Manager mainly do XP while playing The Planning Game and keeping the Overall Schedule. Other than that she keeps track of how we're doing with time and estimates and arrange everything around to let the rest of the team focus on producing - she's somewhat like a Scrum Master.
The third was more of a introduction where we wanted the customer to know what to expect and to get to know how much the customer wanted to be involved. We got the customer to agree on sitting one day every week at our office, and also got to know that more involvment in the story creation was wanted. We settled for a process where Angelina will produce the stories and then walk the customer through them in a separate meeting before we plan. It's a solution we all think will work really good.
This last one was more educational to let everyone else at the company know what XP is, what it can do for us and what pros and cons we've found so far. About half of the group knew briefly what XP is on before hand, but only a few had more than shallow knowledge. The most discussion was when I came to the Design Philosophy box in the lower left where we talked about Good Design versus Simple Design. I stated that all Design Principles still are valid and that Simple Design just states that you shouldn't make your design "future proof". An example that came up was that you might not want to use a Factory for creating objects if you only can see need for one implementation, which I agreed to but added that you'd anyway would make that class implement an Interface that others use to access it - making it easy to add a Factory later on if needed while it isn't adding code that isn't needed. I found it peculiar that no discussion at all was raised around Pair Programming - except our thought about how to deal with new developers added to the team.
The first occation was alot about selling the idea to the company. That presentation was based on the article What is XP by Ron Jefferies along with a couple of slides I added about why this was good for us, both in this project and in the long run. On the rest of the presentations I have just had one slide, One Page XP by Bill Wake, and talked freely about XP from upper left to lower right, adding things as I pass the different stages.
The second occation was to get the team started, trying to figure our the roles and responsibilities among us. What are the Interaction Designer, the Test Leader and the Project Manager supposed to do? We've decided on having the Interaction Designed being in charge of the user stories, and coordinating them with the customer. Along with the Test Leader she then writes proposed Acceptance Tests for each story. The Test Leader is then in charge of implementing the Automated Acceptance Test using Selenium and also doing the manual testing where Selenium can't be used. The Project Manager mainly do XP while playing The Planning Game and keeping the Overall Schedule. Other than that she keeps track of how we're doing with time and estimates and arrange everything around to let the rest of the team focus on producing - she's somewhat like a Scrum Master.
The third was more of a introduction where we wanted the customer to know what to expect and to get to know how much the customer wanted to be involved. We got the customer to agree on sitting one day every week at our office, and also got to know that more involvment in the story creation was wanted. We settled for a process where Angelina will produce the stories and then walk the customer through them in a separate meeting before we plan. It's a solution we all think will work really good.
This last one was more educational to let everyone else at the company know what XP is, what it can do for us and what pros and cons we've found so far. About half of the group knew briefly what XP is on before hand, but only a few had more than shallow knowledge. The most discussion was when I came to the Design Philosophy box in the lower left where we talked about Good Design versus Simple Design. I stated that all Design Principles still are valid and that Simple Design just states that you shouldn't make your design "future proof". An example that came up was that you might not want to use a Factory for creating objects if you only can see need for one implementation, which I agreed to but added that you'd anyway would make that class implement an Interface that others use to access it - making it easy to add a Factory later on if needed while it isn't adding code that isn't needed. I found it peculiar that no discussion at all was raised around Pair Programming - except our thought about how to deal with new developers added to the team.
Thursday, October 22, 2009
Planning Poker
Today Tommy brought his Planning Poker deck to our Planning Game session (see previous post). I've only read about planning poker before but never used it in practice.
The Deck:
The Planning Poker deck is like an ordinary deck of cards but instead of clubs, diamonds, hearts and spades with different values there are only numbers representing days. On the back of each card there is a color to group them. Each color consists of thirteen cards numbered 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100. It also have two "wildcards", one coffeecup meaning take a break and one question mark meaning we have to discuss this.
Planning Poker Deck
Game play:
We were four players. Each player picked a pile of cards with the same color. As in most card games you are not supposed to show you cards face to your competitors. Then we read one of our User Stories and each player played the card representing the number of days they believed it would take to finish it. Estimates included automated acceptance tests as this is the definition of done in our case. The card you played was placed at the table with face down, and then turned by all players simultaneously so you wouldn't cheat:) If all players played the same estimate this estimate was written down on the User Story. If all players played different estimates we discussed back and fourth until we all felt comfortable with the estimate. Equally if some player played a much higher or lower value than the rest of us. The coffeecup or the question mark was not used, maybe next time.
Even though there's no real competition as there are no winner, except the whole team if the estimates are good, it was much more fun than just sit down and do estimates. I really recommend you to try it.
The Planning Game
Today we played our first Planning Game. We started this morning with playing Planning Poker to estimate all the stories we've come up with. It turned out really good, but we didn't manage to estimate all the stories on the hour we had before the customer arrived for the Release Planning and Iteration Planning. A small pile of assumed low priority stories remained, but we probably managed to estimate more stories this way than would have been the case if we had estimated the usual way.
Moving on to Iteration Planning we had a bunch of proposed Acceptance Tests prepared to define each story. These were discussed by the Whole Team, including the customer. We slightly redefined a few of the stories by changing details in the proposed tests, and also came up with some extra tests needed to prove the function. Along with the definition of Acceptance Tests we also performed the Task Breakdown of each story. Here it seemed that the developers were the only ones really needed though, so in the future we might do that after the Iteration Planning.
Simon, Tommy and Angelina playing Planning Poker
When the customer arrived we first prioritized all the stories we had, including the ones that we didn't have time to estimate. Once the priorities were in place it was a no-brainer to choose what to include in the first iteration. We simply calculated how much time we would be able to spend during the iteration and then selected stories from the top until we reached the available time. The stories with high priority were all estimated by the morning session. We also created a release plan with some set dates for different parts of the project.
Moving on to Iteration Planning we had a bunch of proposed Acceptance Tests prepared to define each story. These were discussed by the Whole Team, including the customer. We slightly redefined a few of the stories by changing details in the proposed tests, and also came up with some extra tests needed to prove the function. Along with the definition of Acceptance Tests we also performed the Task Breakdown of each story. Here it seemed that the developers were the only ones really needed though, so in the future we might do that after the Iteration Planning.
Continuous Integration
For a few days we've been working to get the build server ready. We find it crucial to the entire project that the build and deploy works flawless, also continuous integration is mandatory in an XP project. Currently we test the continuous integration setup with a small template project for Microsoft Office SharePoint Server 2007 (MOSS).
So far we've managed to get Cruise Control.Net to trigger on commits to our Subversion repository. We already do this for our other projects so it was an easy task. What differs is that it also runs all unit tests and later it will also run all the automated acceptance tests.
It was quite nice to see the red/green bars of failed and successful NUnit tests in Cruise Control after a code commit to Subversion.
Before the build was actually working I was worried MOSS would make me install the whole Share point package on to the build server just to build and create a deploy package.
But, no worries, making it build was quite simple I just had to copy Microsoft.SharePoint.dll to our assemblies folder (this is our lib or libraries folder).
Tommy and I paired up to figure out how to use WSPBuilder without the need to install Windows SharePoint Services (WSS) to the build server. According to the WSPBuilder documentation it is required. First time we run WSPBuilder it complained that some assemblies where missing. By adding the -DLLReferencePath parameter referencing our library assemblies for WSPBuilder it was outputting the wsp file we wanted.
Next up is to get the wsp package to install nightly on the test web server. We don't believe we can do deploys every commit as MOSS is not super fast when deploying wsp packages.
Is this wise or not? Would you put the deployment into the continuous builds? Please give us your opinion.
Friday, October 16, 2009
More about writing user stories
In this project we've decided that I, as Interaction Designer, should write the user stories. I've worked in projects where we've used stories for planning our work before, but then we've mostly focused on the size and the independency of the stories. We've also prioritized functions before writing the stories, and writing them have been done by the whole team as a part of the planning activity.
This time we've been writing stories with the mindset to make them, Independent, Negotiable, Valuable, Estimatable, Small and Testable. We've learned these rules from Bill Wake.
An Interaction Designer should be aware of the user value in everything they do, and I find it useful to formulate the user stories so that they express how every part of our project is of value either to the end user or to the customer. In this way everyone in the team will be reminded of why a function should be developed and it will also be a good help to prioritize the stories later.
The writing of user stories in this project has been much about documenting a prototype that we've created in the pre-study. This work has been good because we've once again been forced to challenge everything we've decided to develop with the question "Why would the end user like to have/do this?"
To me the most difficult part of writing the user stories have been to make them independent. We have a step-by-step flow where the user first signs in, then fills in a form, and at last submits the information. Having a story including filling in a form while excluding the submitting part is not an independent story, but including the submitting part may make the story to big. Instead we’ve tried to split that story into several stories where some is about functions that make it possible to fill in the form (e.g. listing and manipulating information), and another one is about actually filling in the information and submitting it.
It has also been hard to make the stories both small and negotiable. Adding too much detail is easy, especially since we already know a lot about details from the pre-study.
Writing stories alone is hard. After a while you come to the point when you do not question your own writings, if you’ve once thought that a story seems to be, for example, negotiable it is difficult to reconsider it without a second persons view of it. Therefore I’ve had a great help from the developers and the Test Manager in my team. Discussing the stories has lead to new, deleted and rewritten stories.
The next step will be to take the user story draft to discuss with our customer!
To learn more about writing user stories I’ve been reading:
This time we've been writing stories with the mindset to make them, Independent, Negotiable, Valuable, Estimatable, Small and Testable. We've learned these rules from Bill Wake.
An Interaction Designer should be aware of the user value in everything they do, and I find it useful to formulate the user stories so that they express how every part of our project is of value either to the end user or to the customer. In this way everyone in the team will be reminded of why a function should be developed and it will also be a good help to prioritize the stories later.
The writing of user stories in this project has been much about documenting a prototype that we've created in the pre-study. This work has been good because we've once again been forced to challenge everything we've decided to develop with the question "Why would the end user like to have/do this?"
To me the most difficult part of writing the user stories have been to make them independent. We have a step-by-step flow where the user first signs in, then fills in a form, and at last submits the information. Having a story including filling in a form while excluding the submitting part is not an independent story, but including the submitting part may make the story to big. Instead we’ve tried to split that story into several stories where some is about functions that make it possible to fill in the form (e.g. listing and manipulating information), and another one is about actually filling in the information and submitting it.
It has also been hard to make the stories both small and negotiable. Adding too much detail is easy, especially since we already know a lot about details from the pre-study.
Writing stories alone is hard. After a while you come to the point when you do not question your own writings, if you’ve once thought that a story seems to be, for example, negotiable it is difficult to reconsider it without a second persons view of it. Therefore I’ve had a great help from the developers and the Test Manager in my team. Discussing the stories has lead to new, deleted and rewritten stories.
The next step will be to take the user story draft to discuss with our customer!
To learn more about writing user stories I’ve been reading:
- The first three chapters in User stories applied by Mike Cohn. I think I learned the most from this reading, I appreciate that it has several describing examples.
- Advantages of the “As a user, I want” user story template from Mike Cohn’ s blog
- User stories at extremeprogramming.org
- User stories at Wikipedia
- A chapter about User stories in Extreme programming explained by Kent Beck. I found this reading quite brief (probably because I read it after all the other reading), but it may be good to get a first idea of what this is about.
Pair !Programming
The first few weeks of this project a lot of time have been spent in meetings, discussing how to do this, writing stories, prioritizing and setting up the environment. Today we decided to start doing the "pair" part anyway, so today we're doing Pair Build-Machine Configuration.
We've decided to use The Pomodoro Technique while starting with this Pair-thing. To begin we will do three Pomodori development and one Pomodori reflection before lunch, and then another similar set of four Pomodori after lunch. Our guess is that we after a while, when we have gained some experience with this, will add more development and remove at least one of the reflections.
Do you think it sounds like a good way to start?
We've decided to use The Pomodoro Technique while starting with this Pair-thing. To begin we will do three Pomodori development and one Pomodori reflection before lunch, and then another similar set of four Pomodori after lunch. Our guess is that we after a while, when we have gained some experience with this, will add more development and remove at least one of the reflections.
Do you think it sounds like a good way to start?
Friday, October 9, 2009
Writing User Stories
As the first task doing XP we've started writing user stories for our project. We've decided to use the “As a , I want so that ” story template after reading this post by Mike Cohn. We consider the so-that clause required though, since we think it ads a alot of value to think about why we do things - we have allready removed one of the features we had planned after challenging it with that question.
Yes, we have planned features. Actually the entire project is planned up front, which is another challenge for this project. It was preceded by a pre-study and the picture about what should be done is pretty clear to us allready. Our interaction designer and our project manager have spent alot of time with the customer to get this picture, which we know is not very XP-like. The good thing is that these two internal persons have so good understanding about the product that they can act as the on-site customer that we can't have for real.
Yes, we have planned features. Actually the entire project is planned up front, which is another challenge for this project. It was preceded by a pre-study and the picture about what should be done is pretty clear to us allready. Our interaction designer and our project manager have spent alot of time with the customer to get this picture, which we know is not very XP-like. The good thing is that these two internal persons have so good understanding about the product that they can act as the on-site customer that we can't have for real.
Cannonball into XP
A few weeks ago we were finally granted to use eXtreme Programming on a new project. It's a web application with a fair amount of business functionality. We have decided for the Cannonball-approach as Kent Beck refers to in his paper “Getting Started with XP”.
We both have some initial understanding about XP and have been anxious to try it out, but haven’t had support until now. We have experience from some of the practices, but not all, and have spent the first few weeks reading up on more details, like Extreme Programming Explained (Kent Beck) and Scrum and XP from the trenches (Henrik Kniberg).
Currently we use continuous integration on all projects already, and as senior developers we have plenty of experience with refactoring. We have used the Scrum process, and thereby Stories and Iterations amongst other things. Tommy have also been experimenting with TDD for a couple of years.
As for our concerns, none of us have done much pair programming or automated acceptance tests before. Another issue is our organization at Creuna which does not map directly to XP. Being consultants having an on site customer can be difficult for example.
Commenting this post we would love to get your input on how you started with XP. Also, during this project, don't hesitate to give us comments how you would solve similar problems.
Subscribe to:
Posts (Atom)