This post was previously published on my employer’s blog.

For a few years now, November has been the month of QCon San Francisco for me. So far it has proven an excellent conference with lots of thought-provoking presentations and conversations. This year was no exception. Read on for my personal high- and lowlights.

The Conference

If you’ve never heard of QCon before, the conference bills itself as a conference for and by software developers and architects of any “denomination”. Walking the hallways you are equally likely to encounter a Rubyist, Javaan or .NET afficionado. This refreshing diversity leads to interesting presentations and coffee-corner conversations. For me as a Java developer, it also meant that the news about Java 7’s closures by and large passed me by.

Given it’s target audience of predominantly teamleads and architects, QCon has less technical depth than, for instance, the Devoxx conference. But with entire tracks dedicated to Ruby and emerging languages (including some C#/F# sessions), it certainly has more breadth. For me personally this is one of the key reasons to attend.

Keynotes

The keynotes this year were a bit of a mixed bag. On Wednesday, two venture capitalists spoke about what they looked for in startups when deciding where to invest. The process they described resembled the Lean Startup ideas of iterating as fast as possible with direct customer involvement. Interestingly, they mentioned Scala and Groovy as developments that they as VCs keep a close eye on.

Don Box experimented with Twitter during his keynote. Not saying a word, he wrote tweets on his laptop for the first 20 minutes. An interesting experiment, but it didn’t manage to hold the attendees’ attention. When the subsequent code demos either failed or proved unable to bring the audience back, Don himself also ran out of steam and brought the keynote to an abrupt and disappointing close. Still good of him to try something new.

The last keynote of the conference was by David Chappel of Oracle who presented and then demonstrated Oracle’s cloud tooling. Way too Oracle-centric for my money.

For next year, I really hope QCon will do away with the vendor keynotes, even if this means going back to 2 keynotes like the last few years. Someone like Kent Beck or Uncle Bob has much more interesting things to say.

Highlights

Dan North’s presentation about a challenging agile project was great. It was filled with lessons about transitional architecture and agile adoption and plenty of humor to boot.

In Lessons learned from Architecture Reviews Rebecca Wirfs-Brock discussed not only how to perform an architecture review, but also how to effectively present an architecture depending on your audience and the political environment.

Eric Evans talked about incorporating modeling and design into the agile development process and presented an early draft of his model exploration process. Eric uses this process when doing DDD consulting for clients and is useful for anyone applying the technique.

There was a lot of interest in lean software development and kanban as well. I attended presentations by Jeff Patton and David Laribee which provided useful practical tips and real-world experience. Though I didn’t attend it myself, I heard a lot of good things about Henrik Kniberg’s talk as well.

One of the most impressive tracks at QCon is Architectures you’ve always wondered about. I’m always inspired by seeing how sites such as eBay or LinkedIn handle their scaling requirements. This year’s session about Amazon S3 was equally impressive, describing design patterns for building applications that can guarantee uptime in the face of hard drive, network or machine failures. To test their service, Amazon regularly holds unannounced “game days” where they take an entire datacenter offline to see if their architecture can handle it. That is some serious testing.

Trends

During the conference, I noticed a lot of interest in:

• teaching people the craft of agile software development. Presentations discussing personal traits required for programming and software apprenticeship were the result.
• JVM-based languages like Scala and Clojure. This is hardly news, but what surprised me was the level of interest there was from non-Java developers. Several people I talked to told me that they were experimenting with these languages in their spare time while working .NET at their dayjob.
• Continuous deployment (meaning continuous deployment to production).

Bucking the trend I’ve been hearing about at other conferences, the wifi at QCon actually worked without a hitch for me.

Conclusion

For me, QCon was about re-discovering the agile software development craft this year. Talking with practitioners and hearing their experiences gave me lots of new ideas and inspiration to bring to my own projects. That said, most of the tracks and topics feel like they’ve been around for a while. Next year I’m hoping to hear about the “next big thing”.

Places are going fast for this year’s Open Source in Finance eXchange on December 15.  Speaking across six expert talks and two parkbench discussions on the day will be Alan Hardy, Rob Davies, Angelo Corsaro and David Vincent.

This year’s eXchange is bringing together the leading experts in Open Source technology and Financial Services software development with innovators, technologists, architects and developers in the developer community.

The day promises to combine deep technical insight with friendly discussion around creating highly scalable, secure systems and leveraging OS technology within the finance sector.

The programme is structured to encourage discussion and bring together the leading thinkers and experts on the use open source technology in Financial Services with passionate members of the developer community in this sector.

To keep it as informal as possible we are strictly limiting the event to 125 delegates, and it is already proving to be popular.  What’s more, on the day we will be raffling off a ticket to this year’s QCon in London.

Book now — and get your tickets for £65.  Just click the banner at the top of the page.

Restrospectivas ágeis são sem dúvida, uma grande oportunidade para que equipes de desenvolvimento de software parem para pensar no trabalho que vem realizando e questionem o que pode se melhorado. É uma execente ferramenta para que o famoso ciclo PDCA (Plan / Do / Check/ Act) possa ser aplicado. O método ágil Scrum sugere que as reuniões de retrospectiva aconteçam no final da iteração (sprint) e que a equipe se faça duas perguntas básicas:

• O que está indo bem?
• O que pode ser melhorado?

Alguns preferem perguntar:

• O que devemos parar de fazer?
• O que devemos continuar fazendo?
• O que devemos começar a fazer?

No fim das contas o que realmente importa é que a reunião tenha como resultado ações a serem tomadas pela equipe para que a melhoria continua seja aplicada, e que na próxima restrospectiva, a equipe seja melhor do que era na última.

Alguns dias atrás o Vinicius Teles da Improveit twitou o link de uma palestra que foi apresentada no Google por by Esther Derby e Diana Larsen sobre restrospectivas ágeis. As duas são especialistas sobre assunto e já até escreveram um livro que pode ser comprado por $20 em PDF. Vale a pena assitir a palestra:

Creio que uma das coisas mais importantes que as duas destacaram na apresentação é a necessidade de dividir as responsabilidades de tomar as ações entre os membros da equipe para que as mudanças realmente aconteçam.  De nada adianta reuniões de retrospectivas que apontam problemas que nunca são resolvidos por ninguém. Para evitar que isso aconteça na Bluesoft, ultimante em toda reunião de restrospectiva nós lemos os itens que identicamos como coisas que poderiam ser melhoradas no sprint anterior e então rapidamente discutimos se realmente já estão resolvidos, e caso não estejam, voltamos a incluir o item e insistímos até que finalmente seja resolvido.

Um outro ponto interessante levantando por meu amigo Ricardo Almeida, é que devemos tomar cuidado para não transoformar a reunião de restrospectiva em uma mera busca de culpados. O foco deve estar sempre na solução.

No inicio desde ano Linda Rising apresentou na QCon Londres 2009 um tutorial sobre retrospectivas, uma de suas dicas, foi que as pessoas anotassem os acontecimentos bons e ruins ao longo do sprint em post-its para que não os esquecessem. Na Bluesoft, reservamos uma área do Kanban para que estes post-its sejam anexados.

Para maiores informações sobre retrospectivas, visite o Agile Restrospective Resource Wiki, um wiki (em inglês) com uma série de dicas, exercícios e ferramentas para realização de retrospectivas. O site cmcrossroads possui uma lista bem completa de sites onde você pode encontrar excelente material sobre o assunto.

Boa Restrospectiva!

Steve Freeman had interesting analogy in TDD 10 years later (17m30s, slide 26: The origins of mock objects). He describes mocked unit test being “rather like particle physics”.

You fire something at a particle, things splinter off and you can detect what happens…

A mock is used to both detect the emissions from the system under test (SUT), and verify expectations. Additionally, a mock object may perform stub duties. This doesn’t quite fit, since fission is one-way.

Testing “by detection” like this is considered behaviour verification: verifying collaborations between the SUT and other objects.

To be testable in such a manner:

• Requires the ability to isolate the SUT sufficiently, i.e., detach it completely from its context and collaborators. A test fixture should be able to create the SUT easily by itself.
• Then the SUT should minimize concrete dependencies.
• Collaborators must be designed in such a way to allow a mock to be generated that can intercept interactions. This means identifying the abstraction(s) for collaborators.
• Mock is a stub in the sense that it needs to stand in for a real (if inert) object. But a mock is also a “detector” and is used as the means of assertion.
• Stub queries and mock actions. “we mock when the service changes the external world; we stub when it doesn’t change the external world – stub queries and mock actions”

References

• Mock Roles, not Objects (Steve Freeman). Define abstractions for a collaboration, leaving concrete implementations until required.
• Slides – TDD 10 years later (QCon London 2009).
• Mocks Aren’t Stubs (Fowler).

Estive na apresentação de Glenn Vanderburg, no QCon London 2009, que falou sobre o Estado da Arte da DSL em Ruby. A apresentação e os slides você pode conferir aqui no site da infoq.


(task “warn if websites is not alive ”
  every 3 seconds
  starting now
  when ( not (website-alive? “http://example.org”))
  then (notify “admin@example.org”, “server down!”))
)


DSL interna também foi um objetivo de design do Haskell


keepleft (p :>: ps)
  | keepleft p = case partitionFL keepleft ps of
    a :> b -> p:>: a :>: b
  | otherwise = case commuteWhatWeCanFL (p :> ps) of
    a :> p’ :> b -> case partitionFL keepleft a of
      a’ :> b’ -> a’ :> b’ +>+ p’ :>: b


Outras frases muito interessantes dessa apresentação:

• Linguagens são para pessoas entenderem o domínio
• Coisas que são implícitas na verdade são complexidades acidentais
• Aprender a linguagem ajuda a entender o domínio

Um bom design de API:

• Criar uma DSL para determinada construção é poderoso
• Você pode refatorar ela quando achar duplicação, complexidade, etc
• DSL interna é apenas uma parte do bom design da API no Ruby

InfoQ posted the London 2008 QCon panel on the topic Transparency: A Great Leap Forward or Exposed Artery? The question addressed by this panel is summarized as follows:

Agile propagandists make great claims about the advantages of being transparent about the state of their projects. They claim that this how mature relationships work and that “Honesty is the best policy”. But is this true? Many of us work in dysfunctional organisations where honesty is the best way to get cheated. Surely Transparency is just not pragmatic?

Quite a few interesting facets are highlighted in the discourse between the audience and panelists Kent Beck, Keith Braithwaite, Steve Freeman, Chris Matts and John Nolan. For example:

• The power of the simple statement “It is what it is.”
• Is the issue deeper than “just” transparency? For example, is it a matter of values?
• The harsh reality in the trenches that revolves around transparency. Meaningless statements like “I need it for SOX compliance” have been known to be made.
• How does one induce organizational change to improve transparency? In particular, how does one do so amidst organizational dysfunction?

I would add one observation to the numerous good points made by the panelists. Ultimately, the most critical form of transparency is with respect to the user. There is no substitute to his/her feedback on an on-going basis. If you need to address transparency as part of your Agile roll-out or evolution, start with transparency to the user. It can be as simple as making the arrangements for some real customers to attend your release planning and bi-weekly demos.

O Junior da Bluesoft também está escrevendo sobre os eventos do QCon London 2009. Podem conferir abaixo:

QCon Londres 2009: resumo do evento

QCon Londres 2009: Tutorial sobre retrospectivas

QCon Londres 2009: outros tutoriais

QCon Londres 2009: palestras da quarta-feira

QCon Londres 2009: palestras da quinta-feira

QCon Londres 2009: sexta-feira (último dia)

In this Qcon 2008 presentation, David Anderson presents a brief history of the kanban system through case study reports from teams at Microsoft and Corbis. Kanban acts to limit work-in-progress and focus the team on achieving a continuous flow of value to the customer and innovates on accepted agile management practices by providing an iteration-less process with a regular release cadence.

Geir Magnusson apresentou sobre  Cloud Data Persistence ou “We’re in a database reneaissance – pay attention” no QCon London 2009. A principal mensagem dessa apresentação foi que limitações físicas da tecnologia de hoje combinada com a complexidade computacional de bancos de dados relacionais convencionais estão nos levando a olhar para espaços novos e excitantes.

Apresentando soluções como Google’s BigTable e Amazon Dynamo , Magnusson diz que banco de dados distribuídos nos permite gerenciar um enorme volume de dados (BigTable é preparado para tabelas petabyte) mas questões de alta disponibilidade, com distribuição através de muitos sistemas, trás alguns requerimentos que geralmente necessitam de uma solução que diverge de um modelo relacional e direciona para modelos de armazenagem de documentos.

Magnusson mencionou alguns projetos interessantes para olhar de perto.

Alternativas Open Source do Google BigTable:

• Hypertable
• Apache Hbase

Alternativas Open Source para o Amazon Dynamo:

• Projeto Voldemort
• Cassandra
• Dynomite

Outros projetos Open Source interessantes:

• MongoDB, armazenagem de documento
  
• CouchDB, armazenagem de documento JSon
  
• MemcachedDB, banco de dados distribuído a armazenagem chave/valor, acessado via api memcached
  
• Drizzle, fork do mysql direcionado a cloud
  
• Hadoop, sistema de arquivo distribuído, framework M/R
  
• LightCloud, banco de dados distribuído a armazenagem chave/valor, baseado no Tokyo Cabinet
  
• Scalaris, escalavel, transacional, armazenagem chave/valor distribuído, em Erlang

Estive no tutorial do QCon realizado por Peter Backlund e Patrik Fredriksson, que falaram sobre DDD e mostraram um exemplo com uma tecnologia atual.

Publiquei a notícia completa no site da Infoq Br nesse link.

Eles começaram com uma frase bem famosa do Eric Evans

“A complexidade crítica de muitos projetos de software está no entendimento do próprio domínio”

O maior desafio está na transferência de conhecimento entre as pessoas.

Domain-Driven Design

É a maneira de aproximar os problemas da complexidade de software através da cooperação próxima entre desenvolvedores e experts no domínio (domain). A complexidade está no domínio. Usamos modelos para manipular o domínio.

Exemplo: DDDSample

Essa aplicação de exemplo tem vários usos:

• Um exemplo “how to” para implementação de uma típica aplicação DDD
• Suporte para discussão e práticas de implementação
• Laboratório para experimentos controlados.

Tecnologia

• Frameworks e componentes baseados em Open Source
• Bom suporte para DDD e OO.
• Java 6
• Spring Core/ORM/JEE/Web
• Hibernate
• ActiveMQ JMS
• Apache CXF Web Services
• Jakarta Commons
• Maven

Eric Evans

Estive no evento QCon London 2009 e assisti a apresentação do Eric Evans sobre o que ele aprendeu após a publicação se seu famoso livro sobre DDD. Escrevi sobre o evento no site da Infoq Br

Publiquei a notícia completa no site da Infoq Br.

Os Slides da apresentação estão disponíveis aqui.

Model é um sistema de abstração que descreve aspectos selecionados de um domínio e pode ser usado para resolver problemas.

Ubiquitous Language é uma linguagem estruturada dentro do domain model e usado por todos membros do time para comunicação.

O que é essencial?

• Colaboração criativa dos experts do domínio e experts em software.
• Exploração e experimentação. Podem surgir idéias ruins, porém a exploração desse domínio é muito importante para um bom compreendimento
• Modelos emergentes de elaboração e re-elaboração de uma ubiquitous language.
• Camadas explícitas de contextos.
• Foco no principal domínio.

Considerações Finais

• Modelagens precisas são frágeis
• Técnicas de Modelagem sofisticadas são gastas em uma bola de lama.
• É necessário uma camada “anti-corrupção”.
• Nem tudo de um grande sistema será bem modelado

Outros relatos dessa apresentação:

http://gojko.net/2009/03/12/qcon-london-2009-eric-evans-what-ive-learned-about-ddd-since-the-book/

http://www.markhneedham.com/blog/2009/03/13/qcon-london-2009-what-ive-learned-about-ddd-since-the-book-eric-evans/

That’s a long time since I didn’t post here. After 4 days at QCon London and one week of ski in Argentière, I decided I would bend the rules of this blog by exposing my feelings, here about QCon.

To make it short, it was a great moment of thoughts and convivial discussions. It is by far the best conference and IT event I attended so far for different reasons:

• It covers an extremely broad spectrum of the IT World. With 5 main tracks at the same time during the whole days, the content is well diversified: Languages (functional, mainstream, …), Architecture, SOA, Agile, Performances, Finance and a newly very original track about Historically bad ideas.
• The panel of speaker is incredible: Sir Tony Hoare (Quicksort inventor and much more), Martin Fowler, Joe Armstrong (father of Erlang), Rich Hickey (Clojure inventor), Ola Bini (JRuby developer and more), Rod Johnson (Spring Inventor), Dan North, Eric Evans (Mister DDD), and many more… Now you have an idea of the amount of experience and research accumulated by such a group of people.
• It is not polluted all around with commercial presentation with stuff to sell.
• The organization was very good, conference center is quite central (my hotel was 20min walk from there) and comfortable, wifi, food (very good for such event!), a free beer night for speakers and audience.
• I had the chance to meet Floyd and other editors from InfoQ (Dionysios, Stefan, Ryan, Diana, Sadek, Werner, Mirko, David, Jon, Roxanne, Alex) and we had a pleasant time in restaurants and pub.

Now getting back to the presentation it started with a Keynote from Sir Tony Hoare about scientist and engineers and how to qualify software development. This is very well summarized by Gojko. This was definitely a great introduction to QCons.

Unfortunately I did a mistake by choosing Architectures in Financial Applications track. As a developer for various financial institution and vendor, I was expecting striking real world finance applications, but I was mostly disappointed. I didn’t learn much from it. And it was a wise decision to part this track and attend Martin Fowler presentation instead. In Three years of real-world Ruby, Martin talked about his feedbacks on the 64 (or 63.. I cannot remember) projects done at ThoughtWorks. Martin is a brilliant speaker and by relying on a nice metric his whole presentation was convincing. That’s too bad I was too shy to ask Martin this question: 10 years ago, cool kids were doing Java, 5 years ago they were doing Ruby, today cool kids are working with Haskell, or Erlang, do you plan to follow the cool kids again and give a presentation about Three years of real-world Functional programming in QCon 2012? But well I had an idea of the answer in the multi-paradigm IT world we live in today.

This first QCon day ended with QCon Conference Party in a pub not far from the conference center, with free beers and serious talks with Stefan Tilkov, Werner, … and less serious ones about wine and miscellaneous stuff with Cameron Purdy, and other attendees. Was nice to see such people like Ola, Kirk Pepperdine or Rod Johnson hanging around with a pint.

I spent the second day on the Functional and Concurrent Programming Languages Applied track which was led by Francesco Cesarini. The high moment of the day was the presentation by Rich Hickey about Persistent Data Structures and Managed References about states, process, identity and applications to Clojure. Multicore Programming in Erlang was also quite interesting. This whole track convinced me to have a closer look at Clojure, but also confirmed my choice to learn a functional language in 2009 which is the reason why I came back in Paris with Real World Haskell book in my bag (Yeah I know, Erlang is cool and was well covered during QCon but a friend advised me to have a look at Haskell). At the end, I learnt many concepts and ideas that could be applied in my day-to-day job or side projects. Second day ended with a pleasant time with InfoQ editors at a restaurant.

Third day was again very rich intellectually. I followed most of the Historically bad ideas track. This track was a very original good idea. But as Aino Corry stated, convincing speakers to participate to such a track was far from being a piece of cake (we all have our egos ), unless… Sir Tony Hoare would be part of the track. His Null References: The Billion Dollar Mistake session was a good historical overview of what lead him to introduce Null References. Later I parted the Historically bad ideas track to join Systems that never stop, with Joe Armstrong introducing Erlang (A language for programming reliable systems). He introduced Erlang and why he invented it (for Ericsson Telecom Infrastructures). Relying on quotes from prestigious sources, Joe outlined the six laws Erlang is based on:

• Isolation
• Concurrency
• Must Detect Failure
• Fault Identification
• Live Code Upgrade
• Stable Storage

If you need all this, Erlang should be a good candidate for you. The presentation was one of the best I attended and Joe made it a very pleasant moment.

To finish this last day, I decided to attend the interview with Tony Hoare and another one about REST for SOA: Using the Web for Integration with Ian Robinson & Jim Webber. Apart from being very charismatic persons, Ian and Jim are very pragmatic architects, and Stefan asked them the perfect questions.

We had a last dinner with Floyd and InfoQ team, and some more beers at the pub.

So well, as soon as the videos are out on InfoQ, you must absolutely have a look at the following presentations:

• Opening Keynote: The Science of Computing and the Engineering of Software by Sir Tony Hoare,
• Null References: The Billion Dollar Mistake by Sir Tony Hoare,
• Erlang: A language for programming reliable systems by Joe Armstrong,
• Persistent Data Structures and Managed References by Rich Hickey.

And interviews:

• REST for SOA: Using the Web for Integration with Ian Robinson & Jim Webber.

Now some random thoughts:

• It’s funny to see the success of retro-engineering and empiric architectures or languages: REST, Erlang. Compared to Sun’s first-specify-then-implement approach.
• QCon is a tasty moment for a computer science enthusiast like me but well it’s so frustrating to see the IT enterprise reality: java, java and java and the rest only for the Happy Few… And in big structures even when you would be pushing to adopt more suited solutions discovered at QCon (or wherever: blogs, …), there will always be a higher ranked guy who is reluctant to changes and everything it implies.

I just wish I had chosen a different track instead of the Financial one on the first day. It should be interesting to have a small fun and provocative introductory session next time on How to schedule your QCon, what to avoid. I already imagine Jim Webber presenting this and nagging Martin Fowler. But seriously this is a very hard task. Basically you’re never disappointed by big names, so you should favor them but still you can be surprised by other small sessions.

All in all, the feedbacks I had from people in the audience, and speakers or people on the net tend to confirm my opinion that QCon London 2009 was a great success. I’d like to thank Floyd, and the whole InfoQ Team for this great moment.

Retrospectivas de times ágeis parecem ser algo bem simples de se fazer, porém na prática muitas dificuldades podem surgir. Durante sua apresentação no QCon 2009, Linda Rising falou sobre aplicar boas Retrospectivas e como não deixar que elas tenham efeitos colaterais.

Na retrospectiva acontece de o time não lembrar das coisas ruins e boas para ser discutidas e, portanto, os problemas podem continuar ocorrendo posteriormente. Outro problema que ocorre é eleger culpados, ao invés de pensar em soluções.

Algumas considerações da Linda Rising abaixo:

Em intervalos regulares, o time reflete sobre como se tornar mais efetivo, então melhora e ajusta seu comportamento em conformidade. Esses intervalos não podem ser muito longos porque os acontecimentos podem cair em esquecimento na hora da retrospectiva. O ideal é que ocorra uma mini-retrospectiva durante todos os dias. Devemos nos perguntar: “O que aconteceu nessa manhã?”. “O que eu deveria fazer para evitar que algo ruim que ocorreu hoje não ocorra mais?”. E para não cair em esquecimento, a pessoa pode escrever a idéia no cartão e colocar na parede para ser discutido na retrospectiva do sprint. Os cartões devem estar em um lugar fácil para todo o time visualizar, assim alguém pode até resolver um problema antes mesmo de ser discutido na reunião de retrospectiva. Usar cartões coloridos para identificar algo bom ou ruim também é interessante.

“Uma retrospectiva é uma oportunidade para os participantes aprender como melhorar. O foco é no aprendizado – não na busca de culpados.” Norm Kerth do livro Project Retrospectives

Reflita e encontre uma melhor maneira.

O que é uma retrospectiva?

“Temos que testar nosso conhecimento constantemente – usando práticas como retrospectivas. Isso deve ser feito depois de cada ciclo iterativo ao invés de esperar o final do projeto.” Jim Highsmith

Por que uma retrospectiva?

Retrospectivas são para aprender do passado. Queremos acreditar que aprender de experiências é automático, mas para isso é necessário habilidades profundas. Experiência fornece dados, não conhecimento.

O objetivo é planejar o futuro para se aprimorar.

“Pessoas querem aprimorar-se mas geralmente elas não sabem em que trabalhar para isso. Quando elas recebem bom feedback em pontos específicos, libera uma inclunação natural interna para melhorar” James Fallows.

“Tenho visto um um time inteiro fazendo reflexão, descobrindo, e ensinando muito. Acredito que não existe melhor maneira de melhorar a performance e qualidade do time.” Norm Kerth

Exemplos de Retrospectivas

Linda apresenta dois exemplos clássicos sobre retrospectivas.

• Post-fire Critiques é um artigo que explica como uma retrospectiva pode ser importante em trabalhos que envolvem a vida de humanos. Bombeiros, tal como todos os seres humanos, cometem erros. Quando bombeiros cometem um erro no emprego, no entanto, pode colocar a própria vida em risco, aos seus colaboradores, e para o público que servem. No entanto, bombeiros vão continuar cometendo erros e podem repetir um erro grave.
• The CEO & The Monk – corporate funeral.

O que retrospectiva não é?

Uma coisa muito importante é o que a retrospectiva não é.

“Não nomeie, não culpe. Mas um louvor é sempre bem vindo.”

Essa frase quer dizer que em uma retrospectiva, nunca devemos “dar nome aos bois”. Não devemos citar nomes em hipótese nenhuma. O objetivo também não é achar culpados. Por mais que todos saibam quem é o culpado, na retrospectiva devemos falar do problema mas sem falar em nomes. Linda deu um exemplo: “Devemos melhorar os processos de banco de dados. Todos sabem quem é o DBA, mas não deve ser citado nomes nunca. O objetivo é de refletir e melhorar”.

Primeira diretiva de Kerth:

“Independentemente daquilo que descobrir, temos de entender e realmente acredito que todos fizeram o melhor trabalho que poderia, dado o que ficou conhecido na época, a sua competência e habilidades, os recursos disponíveis, bem como a situação na mão”

Essa diretiva é excelente para que não sejamos direcionados a achar culpados dos erros.

Por que ter tanto tempo?

Nossa memória é pequena e seletiva. Temos a tendência em focar em eventos recentes, especialmente se eles são dolorosos. Humanos necessitam de ajuda para lembrar, transformar experiência (dados) em aprendizado (conhecimento). Facilitadores externos são requeridos

Horas apropriadas para retrospectivas

Realizar tanto no final do projeto quanto durante o projeto. Durante o projeto pode ser feita depois de um sprint ou em resposta a uma “surpresa”.

Quem deve participar?

Desenvolvedores, Marketing, QA, Gerentes.

Exercício

Linda Rising fez um exercício muito interessante sobre a linha do tempo. Pediu para as pessoas escreverem sobre acontecimentos em cartões, durante um período que representa a linha do tempo. Cartões que representam: Desafio, Surpresa e Felicidade. Cada um com sua cor respectiva. Analisando essa linha do tempo sabemos o que foi bom (What Worked Well), o que tivemos dificuldade e que surpresas ocorreram (What To Do Differently). Essa informação também ajuda a saber se tem algo mehorando, priorando ou algo que sempre ocorre dentro dos sprints.

Linha do Tempo - Sprint 1

Linha do Tempo - Sprint 2

Linha do Tempo - Sprint 3

O que acoontece antes da retrospectiva?

Requisitos de dados de eventos, dados de esforço e artefatos. Conversa com gerentes. Inquéritos com os participantes.

O que acontece durante?

Leituras, analise do passado, e preparo para o futuro. Existem alguns exercícios como: Definir Sucesso, Linha do Tempo. Durante a retrospectiva podemos determinar ações a ser tomadas nos próximos releases ou projetos e criar planos de ação para identificar o próximo “experimento”.

O que acontece depois?

Podem ser feitos Relatórios de Retrospectivas, sobre o que aconteceu bem que não deve ser esquecido. Documentar o que pode ser feito diferentemente, planos de ação, definir experimentos, aplicar patterns.

Crie Segurança

É comum que pessoas se sintam desconfortáveis em falar de problemas, principalmente se estiverem diante de seu chefe. Crie uma atmosfera segura no qual o time se sinta bem confortável para falar abertamente e honestamente.

Como o conhecimento é compartilhado?

Postando na web, encontros de time, foruns técnicos, cursos de treinamento.

Como vender retrospectivas?

Pessoas podem achar que é perca de tempo, mas o propósito de retrospectivas é o aprendizado. Evitar erros recorrentes, identificar e compartilhar práticas bem sucedidas, preparar para a próxima interação e projetos futuros.

“Todos dizem que querem aprender, mas poucos separam tempo para fazer isso”

E finalmente Linda recomenda seu livro sobre patterns:

Fearless Change: Patterns for introducing new ideas, May Lynn Manns & Linda Rising, Addison-Wesley, 2005

Big Ben e London Eye

Semana passada o Junior da Bluesoft , Dairton do Agilcoop e eu estivemos em Londres para participar de um dos maiores eventos de tecnologia: QCon. O evento ocorreu em Londres, local do Big Ben e London Eye. Uma cidade muito bonita que mistura o novo e o velho. Construções muito antigas e belas ao lado de prédios moderníssimos. No evento conhecemos André e Daniel da UOL. Também tive o prazer de encontrar com os TWers Danilo Sato, Francisco Trindade e Carlos Villela.

As apresentações foram de alto nível e os assuntos interessavam em todos os setores da área de desenvolvimento de software, pois abrangeu tópicos como Agile, Java, Ruby, Arquitetura, etc. Interessou tanto para quem trabalha com desenvolvimento como pré-venda, negócios ou gerentes.

O evento foi muito bem organizado. Havia tempo para perguntas no final de cada apresentação. No intervalo de cada palestra havia um coffee-break. Os almoços organizados pelo evento também foram muito bons. Bastante networking entre pessoas das mais diversas nacionalidades. O feedback das palestras eram representadas por cartões verdes, amarelos ou vermelhos que os congressistas colocavam em uma caixa no final de cada apresentação.

Junior e Eu

Começei na segunda e terça assistindo os tutoriais. Terça a noite teve uma apresentação do Ola Bini sobre “Creating a language on the JVM”, na ThoughtWorks. Na quarta-feira, depois das palestras, ocorreu o QCon Conference Party em um pub próximo do evento. Na quinta, logo após o término das palestras, começou o Cloud Camp, uma desconferência onde algumas pessoas apresentaram rapidamente suas experiências com Cloud Computing, seguido por open spaces. Sexta teve as palestras e o encerramento.

Na segunda a tarde, durante o tutorial de DDD, estava passando por perto da conferência a Rainha da Inglaterra. Muitos sinos tocavam. Porém a palestra não foi tão prejudicada, apesar do barulho.

Rainha da Inglaterrra

Os próximos posts nesse blog vou escrever sobre as apresentações do QCon London 2009.

Tutoriais (Segunda):

• “Retrospectives”, Linda Rising.
• “Domain-Driven Design – a complete example in a current technology stack”, Peter Backlund e Patrik Fredriksson.

Tutoriais (Terça)

• “Influence Strategies”, Linda Rising.
• “Behaviour-driven development: writing software that matters”, Dan North.

Extra (Terça)

• Ola Bini sobre “Creating a language on the JVM”, na ThoughtWorks

Conferência (Quarta):

• Painél de discussão sobre performance e escalabilidade, moderado por Floyd Marinescu.
• Programming in the Small, por Mike Hill e Ivan More
• Test Driven Development: Ten Years Later. Por Michael Feathers e Steve Freeman
• Cloud Data Persistence. Por Geir Magnusson
• Three years of real-world Ruby. Por Martin Fowler.
• CI from the trenches: real-world Continuous Integration challenges. Por Julian Simpson.

Conferência (Quinta):

• What I’ve learned about DDD since the book. Por Eric Evans
• Coaching self-organizing teams. Por Joseph Petrine
• The Power of Value Objects in Domain Driven Design. Por San Johnsson
• Is Domain-Driven Design more than Entities and Repositories? Por Jimmy Nilsson

Conferência (Sexta):

• Pimp my architeture. Por Dan North
• Java Enterprise application standards and why the industry moved to lightweight open source. Por Rod Jonson.
• Strategic Design. Por Eric Evans
• DSL in Oslo. Por Amanda Laucher
• The State of DLS Art in Ruby. Glenn Vanderburg