C'était aux Valtech Days en Novembre dernier, vous pouvez retrouver la présentation en français et en vidéo sur Valtech TV. J'ai mis la présentation sur slideshare:
December 8, 2008
October 4, 2008
What have you tested today ?
Libellés :
Conference,
EN,
Tests
I will be presenting a lightning talk at the Valtech Days 2008 in Paris, the 21st of October.
It will be a "refactored" version of the lightning talk I made at the aa-ftt workshop the 4th of August just before the Agile 2008 conference. There is a low-fi shooting of this talk on google video, thanks to Elisabeth Hendrickson:
One of the attendees also wrote a blog post referring to the talk.
Since then, I went on thinking more and more on how to present these values and the rationale behind them. One of the consultant in Valtech also found a pretty good name for this talk: "What have you tested today ?". I think this question nicely wraps up the 3 values that I emphasize. There is the name of my lightning talk! Come the 21st of October to know more.
It will be a "refactored" version of the lightning talk I made at the aa-ftt workshop the 4th of August just before the Agile 2008 conference. There is a low-fi shooting of this talk on google video, thanks to Elisabeth Hendrickson:
One of the attendees also wrote a blog post referring to the talk.
Since then, I went on thinking more and more on how to present these values and the rationale behind them. One of the consultant in Valtech also found a pretty good name for this talk: "What have you tested today ?". I think this question nicely wraps up the 3 values that I emphasize. There is the name of my lightning talk! Come the 21st of October to know more.
August 9, 2008
The material of the TDR workshop at Agile 2008
Libellés :
Conference,
EN,
TDR
I'm posting here the (electronic) material that I created for my workshop at Agile 2008, Test-Driven Requirements: Beyond Tools. Feel free to reuse it to play the game yourself, I just want you to keep me informed of the output.
Game 1:
I created this game after an experiment in which I participated at the University of Linköping (Sweden) back in 1999. I found the concept interesting enough to make a parallel with software engineering. I named the 2 main players "Product Owner" and "Developer" and I added a couple of roles, the User and the Tester, to add a bit more spice to that game and make it closer to software product development process.
To play the game, you need 2 identical sets of wooden blocks, a table, and a splitter.
Here are the instructions of the game:
- Audience instructions
- Players instructions
Game 2:
I completely made up this one (or think so until someone tells me it's an old game they played at Agile 1975 ...). In this game, groups of 3 to 9 persons try to uncover the requirements of a vague specification that a user (one of the group's member) had read just before. The objective is not so much to uncover real requirements or needs, but rather to use tests to explore the needs and formalise a specification. The users don't know anything concrete, so the specification should be elaborated as a result of a group collaboration.
The game starts with a short presentation reminding the audience about tools and techniques for using tests as specification. Then, one user in each group is given a Memo to read to get to know the context of a system on which the group will work. I allow the group to work 20 minutes and then ask them to write the result of their collaboration on a sheet of white paper. I will post soon the output of the workshop (I have to upload a report on the Agile2008 submissions website).
Game 1:
I created this game after an experiment in which I participated at the University of Linköping (Sweden) back in 1999. I found the concept interesting enough to make a parallel with software engineering. I named the 2 main players "Product Owner" and "Developer" and I added a couple of roles, the User and the Tester, to add a bit more spice to that game and make it closer to software product development process.
To play the game, you need 2 identical sets of wooden blocks, a table, and a splitter.
Here are the instructions of the game:
- Audience instructions
- Players instructions
Game 2:
I completely made up this one (or think so until someone tells me it's an old game they played at Agile 1975 ...). In this game, groups of 3 to 9 persons try to uncover the requirements of a vague specification that a user (one of the group's member) had read just before. The objective is not so much to uncover real requirements or needs, but rather to use tests to explore the needs and formalise a specification. The users don't know anything concrete, so the specification should be elaborated as a result of a group collaboration.
The game starts with a short presentation reminding the audience about tools and techniques for using tests as specification. Then, one user in each group is given a Memo to read to get to know the context of a system on which the group will work. I allow the group to work 20 minutes and then ask them to write the result of their collaboration on a sheet of white paper. I will post soon the output of the workshop (I have to upload a report on the Agile2008 submissions website).
July 31, 2008
Agile 2008: Presentation of Examples stage
Libellés :
Conference,
EN
July 29, 2008
Preparing Agile 2008: TDR workshop
Libellés :
Conference,
EN
Yesterday evening my colleagues and I organized at Valtech office in Paris a rehearsal of my workshop for Agile 2008. This event was open and announced on the XP France web site. My colleagues took this opportunity to videotape the session and we invited a production company to do the same, so hopefully we should post a video abstract in a couple of days on the Valtech website. I would like to thank all the participants that took time to come after the standard office hours. They've been greatly rewarded with pizzas :)
Eric has already posted a summary of the evening (in french).
It was the first time I conducted the second part of the workshop, as I'm already conducting the first part in the TDR courses. This session uncovered lots of interesting points.
About the format and organization first. It lasted approximately 135 mins despite my efforts to shorten some phases, so it is still 45 mins too long. I can to optimize time by writing guiding sheets for the participants so I don't need to explain too much what they're exepected to do, that will also make the instructions clearer. I will also reduce the number of wooden blocks so the first part of the workshop can fit within the expected 30 mins.
Regarding the content I was surprised how unnatural it seems to use tests for exploring needs and formalizing requirements. The participants did use examples in their discussions, but it seems they didn't realize that these examples were already test embryos, so they took note of generic software requirements made after the examples, and then wrote tests from those requirements... Well, exactly the opposite stuff I wanted to see... So I encouraged the groups to work on concrete examples, and start writing tests from those examples.
Then going from examples to concrete tests seemed another uneasy step. I observed that many of the participants proposed to write tables (FIT habits ?) where I felt writing text and progressively maturing a DSL would make more sense and be more efficient for the exercise. As a result, participants were spending lots of time trying to put everything in a couple of tables and thus looking for suitable formats rather than simply writing tests as examples unfold. I also saw the teams progressivelly overwhelmed by the complexity of the requirements and losing track of the basic examples they had discussed at the very beginning of the exercise. They did not want to write tests until they get a sufficient idea of the requirements and they understood their complexity.
This workshop tought me that using tests for exploring needs and specifying software isn't that obvious. We should definitely think of some communication techniques so that teams get some guidance in this field, something like the TDD process applied to requirements (well, we've come a long way, it is the idea of test-driven requirements after all...). TDD does not allow you to write bunch of tests at once and then produce the code, it tells you to do one thing at a time, so you're not overwhelmed by the complexity. What could be the process for TDR ? What about: 1. get an example, 2. write a test, 3. get agreement on that test. We need to think about that and I'm really eager to conduct the workshop at Agile 2008 to check the output.
Eric has already posted a summary of the evening (in french).
It was the first time I conducted the second part of the workshop, as I'm already conducting the first part in the TDR courses. This session uncovered lots of interesting points.
About the format and organization first. It lasted approximately 135 mins despite my efforts to shorten some phases, so it is still 45 mins too long. I can to optimize time by writing guiding sheets for the participants so I don't need to explain too much what they're exepected to do, that will also make the instructions clearer. I will also reduce the number of wooden blocks so the first part of the workshop can fit within the expected 30 mins.
Regarding the content I was surprised how unnatural it seems to use tests for exploring needs and formalizing requirements. The participants did use examples in their discussions, but it seems they didn't realize that these examples were already test embryos, so they took note of generic software requirements made after the examples, and then wrote tests from those requirements... Well, exactly the opposite stuff I wanted to see... So I encouraged the groups to work on concrete examples, and start writing tests from those examples.
Then going from examples to concrete tests seemed another uneasy step. I observed that many of the participants proposed to write tables (FIT habits ?) where I felt writing text and progressively maturing a DSL would make more sense and be more efficient for the exercise. As a result, participants were spending lots of time trying to put everything in a couple of tables and thus looking for suitable formats rather than simply writing tests as examples unfold. I also saw the teams progressivelly overwhelmed by the complexity of the requirements and losing track of the basic examples they had discussed at the very beginning of the exercise. They did not want to write tests until they get a sufficient idea of the requirements and they understood their complexity.
This workshop tought me that using tests for exploring needs and specifying software isn't that obvious. We should definitely think of some communication techniques so that teams get some guidance in this field, something like the TDD process applied to requirements (well, we've come a long way, it is the idea of test-driven requirements after all...). TDD does not allow you to write bunch of tests at once and then produce the code, it tells you to do one thing at a time, so you're not overwhelmed by the complexity. What could be the process for TDR ? What about: 1. get an example, 2. write a test, 3. get agreement on that test. We need to think about that and I'm really eager to conduct the workshop at Agile 2008 to check the output.
June 11, 2008
May 15, 2008
Bent Jensen presented Lean to Valtech consultants
Yesterday evening we had a presentation of Lean Software Development by Bent Jensen at our Valtech premises in Paris. Bent is helping Elisabeth, a colleague from Valtech, in a mission where our client wants to apply Lean techniques to reduce the cost of their product. Bent has spent a couple of days in Paris and we took this occasion to organize this presentation in the context of our weekly evening training agenda.
Bent made a clear and concise presentation of what Lean is and where does it come from, as well as he explained what Lean actually means in the software development field. After the presentation, Elisabeth talked about their ongoing mission and what they achieved so far, illustrating her explanations with pictures from battlefield.
I really appreciated to hear and discuss application of Lean in software development field. After reading the reference book The Machine That Changed The World, that gave me much more concrete examples and analogies in our field. The point of the presentation that I especially recall is when Bent talked about so-called exploration phase (first iterations) and construction phase (after some iterations) in the lean development process he sketched on one of his slide. He pointed out that this is the way Toyota does in their product development process. Lots of talks are going on in the Agile world whether running an "iteration 0" to settle down some architectural components or frameworks. I think he had an interesting point for this debate. To some extent, what Bent presented recalls a bit the RUP (Rational Unified Process) with its elaboration and construction phases (but no idea here of inception and transition).
Bent's company has a blog where he posts news. I found there some of the stories he told during his talk, like the Lego bug tracking system or his trip to Japan.
Bent made a clear and concise presentation of what Lean is and where does it come from, as well as he explained what Lean actually means in the software development field. After the presentation, Elisabeth talked about their ongoing mission and what they achieved so far, illustrating her explanations with pictures from battlefield.
I really appreciated to hear and discuss application of Lean in software development field. After reading the reference book The Machine That Changed The World, that gave me much more concrete examples and analogies in our field. The point of the presentation that I especially recall is when Bent talked about so-called exploration phase (first iterations) and construction phase (after some iterations) in the lean development process he sketched on one of his slide. He pointed out that this is the way Toyota does in their product development process. Lots of talks are going on in the Agile world whether running an "iteration 0" to settle down some architectural components or frameworks. I think he had an interesting point for this debate. To some extent, what Bent presented recalls a bit the RUP (Rational Unified Process) with its elaboration and construction phases (but no idea here of inception and transition).
Bent's company has a blog where he posts news. I found there some of the stories he told during his talk, like the Lego bug tracking system or his trip to Japan.
Subscribe to:
Posts (Atom)
