Raimond Garcia

FALSO!

En Japón se puedo fumar en muchísimos sitios.
Si algo estoy descubriendo de los japoneses es que son unos tipos muy sensatos!

En Tokyo viven unos 13 millones de personas, las calles están petadas de gente, y no es la primera vez que le enchufan un cigarro a un chavalín en todo el jepeto. Además creen que la gente que no fuma no tiene porque ir por la calle respirando el humo de los demás. Así que los fumadores se meten en calles laterales, poco concurridas, se echan un piti y siguen su camino.

En las calles principales hay puntos de fumadores, donde te encuentras un montón de japos dándole duro.

En los bares y restaurantes suelen haber zonas de fumadores y no fumadores, bien separadas y ventiladas.

O si el dueño quiere se puede fumar en todo el establecimiento.

Así que no dejéis de fumar porque vengáis a Japón, que no tendréis problemas ;)

Greetings,
last week we endeavored into a pair-programming 3-2-1 launch. We had most of the features written in cucumber and the css/html before starting to write a single line of code. Features where split into three categories: necessary, nice to haves and upcoming needs. No specific number of features had to be developed, instead we worked full time for a week on a prioritized list of requirements. I traveled to Girona, Spain, to develop this project with Raul Murciano.
Here are some highlights of what seems to be an excellent start-up approach.

Pair Programming
As usual this technique proved to be very efficient and productive. The complementary knowledge between us improved our acting vs researching ratio. Silly mistakes where rapidly spotted by the 4 eyes looking at the screen and the correct measure taken faster. The Chain of Thought to solve a problem was accelerated, we connected the dots rapidly with simple out loud thinking. And reassured each other of the correct way to implement features. Email, twitter and other distractions didn’t have a space during development, focus reigned the project.

Stand Ups
One or twice a day we went to the terrace, and discussed how the rest of the morning or afternoon was to unfold. Some features which once looked like obviously needed, turned out to be unnecessary and the unclearly defined functionalities had to be improvised with user friendly interfaces. Other requirements where modified with the knowledge gained from developing for a couple of days, leading to features being simplified, providing more value and reducing its cost. For us, point estimates made not as much sense as minutes and hours, Our initial point estimates in Pivotal Tracker became irrelevant, 30 minutes and 1 hour features became the norm.

CSS-HTML
We started with half the site ready in css/html format. Features looked right and pretty from the beginning, improving the perception of our work. Unfortunately, the other half of the design arrived the last day of the sprint. This increased our work load, having to first create a plain vanilla html and then integrate it with the new html. The design was in any case very poorly structured (over 14 css stylesheets), unclosed tags and an unprofessional look which we decided to polish, in the interest of not feeling uncomfortable with showing the site. Design Fail.

Cucumber
Testing with Cucumber was the flip site of the css/html integration. We used the plugin Mundo Pepino, created by Fernando Garcia Samblas. This gave us a set of highly reusable steps ranging from views to database including email steps and many other pleasant surprises. Steps had to be translated to English, initially slowing us down considerably, but after the main steps where ready to be reused, our test and development speed became outstanding.

Improvements
All design should be ready and agreed by the client, before starting the sprint. A custom script to completely setup and deploy staging, production and CI environments is imperative, there is no time to waste setting up servers. All main functionality should be written before hand in cucumber, a minimum of time should be spend writing stories during the sprint. Creativity is essential to come up with the best and fastest solution, we think pressure kills creativity, thus, the necessary requirements should be reduced and nice to haves should be increased, developing as many of them as possible. Working less hours would also help, this is not a marathon its a working style that shouldn’t burn you up, working less hours but with fresher minds would be an improvement. Last but not least, after the sprint, time should be allocated to collect and share new cucumber step definitions, deployment scripts should be tweaked, and plugins extracted from our work.

Conclusions
It has been an excellent experience, I’m convinced that this hybrid of agile vs up front preparation is very valuable for clients. Testing and development in pairs was more than twice as productive, the quality of code resulting was very high and we had a lot of fun working. Even though there is still room for improvement I think it has been my most successful and enjoyable first release of a project.

A final thank you to my inspiration sources and open minded people that made this experience possible.

http://intersource.ch