Building Minds - o Blog da OnCast

Em 2003 tive a grande oportunidade de conhecer o uso de testes automatizados. Na mesma ocasião fui apresentado ao XP e ao Lean Software Development por um colega chamado Gustavo Hartmann.

Naquele tempo eu trabalhava em meio ao caos, como muitas empresas brasileiras de software, diga-se de passagem. Triste é saber que ainda hoje, não é difícil de encontrar empresas que atrasam sistematicamente suas entregas e, quando entregam, o resultado normalmente é um produto cheio de defeitos que normalmente são descobertos só pelos clientes. Para resolver este problema, as empresas adicionam um período de testes ao final de cada ciclo de desenvolvimento. O problema é que ao invés de apenas testar, elas começam a corrigir problemas. Estas correções, por sua vez geram outros (d)efeitos colaterais, que enfim fazem com que os prazos estourem.

Ainda não comentamos da qualidade do código gerado em tais ambientes caóticos, um código que muitas vezes nem mesmo os programadores mais experientes querem mexer. Eu particularmente já vi métodos com mais de 400 linhas de código, com dezenas de IF’s aninhados e estruturas procedurais - sem contar as classes com mais de 5000 linhas - detalhe: sem documentação de código e com inúmeros comentários que sujam o código e deixam-no praticamente ilegível.

Soma-se a isto uma arquitetura (se é que se pode chamar isto de arquitetura) totalmente acoplada e sem testes. O resultado desta equação é realmente um desastre. Um custo altíssimo de manutenção. A praticamente impossibilidade de responder as mudanças, e também clientes insatisfeitos.

Infelizmente a equação do caos ainda não está completa. Precisamos mencionar que as estimativas foram feitas pelo departamento comercial, que disse ao analista de negócios o que deveria ser feito. Este, criou centenas de documentos e entregou ao analista de sistemas que projetou o sistema e passou um punhado de diagramas para os programadores desenvolverem o código. Os coitados dos programadores tinham que virar noites trabalhando para tentar minimizar o atraso e quem sabe, conseguir entregar o que os clientes realmente necessitavam. Os gerentes, preocupados em dar visibilidade à direção, não paravam de perguntar: e aí… está pronto?

Em ambientes como este, vale a lei do mais forte. Para ser mais forte, é preciso segurar a informação, diminuindo a colaboração. A pressão torna-se opressão e de maneira alguma, criatividade e inovação podem surgir de tais ambientes.

Felizmente, tive a oportunidade de conhecer o Gustavo. O Gustavo é um cara que não fala muito, mas age. Ele chegou novo no time, em meio ao caos, e não disse que tínhamos que escrever testes, simplesmente começou a escrevê-los. Um belo dia eu achei estranho o que ele estava fazendo e resolvi perguntar. A resposta foi: pensas que vou fazer um código sem escrever um teste antes? Fiquei tão intrigado com aquilo que pedi para que me ensinasse. Logo em seguida peguei o rumo do ágil e comecei a praticar e estudar XP. Percebi que XP foi desenvolvido sobre os conceitos do Lean. Nesta oportunidade, a Mary e o Tom Poppendieck tinham acabado de lançar seu primeiro livro, e o Gustavo - esperto que era - já tinha comprado. Eu mais esperto ainda tomei emprestado. Foi então que percebi que aquilo seria realmente um divisor de águas na minha vida, e foi.

A partir daí, os projetos em que participei tiveram uma performance no mínimo 3 vezes melhor do que os projetos a minha volta. A qualidade do código, dos testes, da documentação e principalmente do relacionamento entre a equipe e os stakeholders melhorou muito.

Hoje, com pelo menos 7 anos de experiência com ágil e no mínimo 4 deles com uma incrível equipe que é a equipe da OnCast, venho experimentando projetos de sucesso, um atras do outro. Graças a um conceito que o Gustavo me ensinou e hoje é fundamental na indústria de software. Graças a uma excelente equipe com a qual tenho o prazer de trabalhar todos os dias. Graças ao meu Deus que me possibilitou conhecer o Gustavo

E por tudo isso, e porque sabemos que o Lean fez a diferença, que resolvemos fazer o Pensando Lean, para que outras empresas possam saber como pensamos e como desenvolvemos software na OnCast e, especialmente, para que aprendam e evoluam e ajudem-nos a criar um indústria de software mais saudável.

Aproveitem o evento…

Samuel Crescêncio Outros

Agile 2010 was for me one of the best, if not - the most outstanding agile conference that I’ve ever participated. Besides having the opportunity to give a talk about the Lean Pyramid Concept, which for me is awesome since it was the first time giving  a speech in English, I was also elected for the Agile Alliance Board of Directors.

Agile Alliance (AA) is for me a very respected organization, which have been helping with the transformation of the whole software industry over the last 9 years. AA played a very important role in my life as a software engineer. Since 2003, when I embraced agile, I’ve been able to transform the environments around me by delivering and helping others to deliver better software. In order to deliver better software though, I needed to improve my knowledge, and I remember how the AA article library helped with that. The AA and the Agile Manifesto also have defined a clear vision of what we know as Agile. I quickly understood that XP, Lean and Scrum followed those principles and values. Studying and applying new techniques coming from theses methodologies and understanding the principles behind them, provided me with a much better capacity to faster deliver high quality software products.

The most interesting thing however, is that I recently realized that my goal is not to build software, but just to help people to solve their problems. Sometimes people will need software for that, and I’ll be able to help them solving their problems with software. Although, If I’m able to solve their problems without writing code, it’s certainly much better, easier and cheaper. And I just understood this through a profound reflexion on how the agile movement changed my life.

My involvement with the agile community is just the expression of this desire to help others. I like to share what I know and I like to learn what I don’t know. And now, I want to learn how to help AA, the organization that have helped me to transform my life, to achieve its own mission. Serving the board is certainly going to be a good challenge and also a priceless opportunity to learn from the most brilliant minds in our software industry.

This conference was e really outstanding opportunity to enhancement of my network. I got to know new people and this has provided me a great opportunity to learn. I really learned a lot at this conference, even not attending many sessions.

I arrived in Orlando after a long 10 hours flight, plus more 6 hours waiting connections. As soon as I arrived on my hotel room, I started refactoring my presentation. I had decided to do this 2 days before my departure, stimulated by the feedback that I received from the OnCast folks. I created a whole new flow to explain the the Lean Pyramid Concept which took me till Tuesday morning to finish.

On Sunday I had my first opportunity to meet with the AA board members, followed by nice reception with board members and sponsors. It was really pleasant to meet with a lot of new people at these events..

On Monday morning, I just had a brief opportunity to enjoy the Mary Poppendieck’s workshop about leadership. The most interesting message that I’ve learned at this session was:

“Treat knowledge workers as volunteers!”

Then, on Tuesday I could give my talk and learned a lot from the feedback I received from people who have attended. At the audience I had the illustrious presence of my master - Mary Poppendieck, who also gave me a very important feedback on how to improve my talks. After my session I really felt more relieved, and it was time to start attending some sessions.

The Lean Pyramid on Prezi

I enjoyed the sessions from Gerard Meszaros and Scot Ambler. Both have demonstrated what is important in terms of documentation efforts, when developing software products. Meszaros’ session focused more on what is important before the iteration zero, including steps for product envisioning, product planning and project execution. The Ambler’s session covered also what happens after a product goes to production, what kind of documentation we should keep and specially how to keep this documentation up to date. All the way from concept to cash - in fact. Unfortunately, I still have seen misunderstandings about software documentation, specially from “traditional” companies which are not yet agile. Actually, when developing software products using correctly an agile approach, your software should be much better documented than when using that traditional up-front design, which in turn creates tons of documents that soon will become deprecated and therefore pure waste in your process. We’ve been successfully applying most of the techniques that were presented for several years now, and they have proven to reduce cost of software maintenance over time.

I also had other opportunities to learn from companies that were exposing on the booth area. It was awesome to meet folks from our partner VersionOne and finally get to know people who I’ve been talking to a lot over the last couple of years. It’s good to put a face on a name

Booth Area

This conference has motivated me to create a strategy to make OnCast a real global organization, in order to delivery our services to countries such as from North America and Europe. You can expect to see a slightly different OnCast, with regards to globalization on the next couple of months.

On Friday afternoon, now as a official member of the Agile Alliance Board of Directors, I had my first official board meeting. I’m happy for being able to provide help with the next conference objectives. New things such as the Ágiles 20xx conference series as a program of Agile Alliance are also coming soon. The next board meeting will take place on Sep 30 (my birthday :). I’m looking forward to learn more about how to collaborate with the board.

I believe that the conference organizers have done an outstanding job moving the conference to a completely different venue/location 2 months before the conference. Everything was in place and the conference was really a success. Congratulations for everyone that was committed for that.

For the next conferences though, I would prioritize a more urban city, that could provide more facilities to the attendees to leave the hotel and do some shopping without having to run miles and miles in a expensive cab. Nevertheless, the program, IMHO, would focus a little bit more on technical stuffs, for two reasons: 1 - to provide a way/environment where people could really build new things at the conference, perhaps new testing strategies or things like that; 2 - to reduce the noising that was generated due to a supposed lack of technical sessions which therefore started feelings like “let’s repudiate agile and plan the revolution”. We need to find a way to keep this community growing in a cohesive and innovative way.

All this is for learning and I’m very happy with the results. I hope you had the opportunity to enjoy the conference as I did.

Samuel Crescêncio Outros

I’m pleased to announce that a couple of months ago I was invited by the Agile Alliance Nominations Committee to run for the Board of Directors of Agile Alliance.

After a careful analysis of the opportunity and it’s requirements, I decided to accept the invitation. I’m pretty sure that by serving to the board, I’ll be able to help Agile Alliance to fulfill its mission and vision throughout South America.

This is a very good step of Agile Alliance towards the creation of a more internationalized organization, in order to provide support and efforts to help other agile communities, such as the South America one, to grow sustainably and effectively.

I would like to invite you to revise the list of candidates and to vote on those you think are more appropriated to accomplish the important duty of serving the board.

I’m quoting a message from Phil Brock where you can find the links to review candidate statements and to vote.

Dear Agile Alliance member:

The Agile Alliance is holding its annual election for individuals to serve on the Agile Alliance Board of Directors.
Please take a few minutes to check out the candidate statements.
You may vote for up to six (6) of the six (6) candidates presented.

CLICK HERE TO VOTE FOR BOTH DIRECTORS AND BYLAWS

Additional nominations will be accepted from the floor at the annual member meeting, to be held during Agile2010 in Orlando, Florida - Wednesday evening, August 11, at 6 pm EDT.

The Board of Directors has proposed updates to the Agile Alliance Bylaws.
You can view the current bylaws here, the proposed bylaws here, and an Executive Summary of the proposed changes here.

CLICK HERE TO VOTE FOR BOTH DIRECTORS AND BYLAWS

Please contact Phil Brock, Agile Alliance Managing Director, with any questions. You can reach me at elections@agilealliance.org.

Thank you very much for taking the time.

Phil Brock
Managing Director
Agile Alliance
“Share the passion to deliver software better every day.”

Samuel Crescêncio Outros

O Agile Brazil 2010 foi sem dúvida o maior evento sobre métodos ágeis já realizado no Brazil.

Mesa de honra na abertura

Fazer parte da equipe de organização deste evento foi para mim uma grande experiência, especialmente por poder comparar esta com minha experiência na organização do Ágiles 2009, evento do qual fui presidente. A equipe de organização foi composta por 14 pessoas e o que mais me impressionou foi que a primeira reunião presencial desta equipe ocorreu no hall do hotel 1 dia antes do evento. Isto demonstra o poder que indivíduos auto-organizados que trabalham em busca de um mesmo objetivo têm, mesmo estando todos trabalhando remotamente. Eu particularmente, só conhecia metade desta equipe. Foi um sentimento muito interessante encontrar as pessoas que eu não conhecia e dar rostos aos nomes. A propósito, trabalhar com estas pessoas foi muito prazeroso e me proporcionou um aprendizado muito grande. Estão todos de parabéns por terem feito um evento desta qualidade.

Comitê de organização

Como organizadores tivemos que trabalhar bastante durante o evento, então não foi possível participar das palestras que gostaríamos. Então, meu feedback sobre o evento parte desta ótica, a de um organizador e não de um atendente.

A missão do Agile Brazil começou para mim no Sábado dia 19/6. Além de agilista e capoeirista eu gosto também de viajar de moto, então aproveitei o evento como desculpa para fazer uma trip de moto para Porto Alegre. Saí de Floripa no Sábado com destino a Orleãns/SC onde passei a noite. No outro dia segui viagem. Consegui escapar da chuva, mas não do frio. Mesmo com equipamento adequado cheguei em Porto Alegre com temperatura abaixo dos 10 graus, ou seja, com muito frio. Mas foi sensacional e uma experiência interessante.

Parada para descançar perto de Torres/RS

Na terça feira tive o grande prazer de ser “O Anfitrião” (visto que sou gaúcho) e levar o David Hussman vulgo “The Dude” para conhecer o mercado público de Porto Alegre. Conversamos muito sobre agilidade, música e idiomas. O Dude já arrísca umas frases em Português. Depois fomos jantar no galpão criolo e comer a autêntica costela de 12 horas (de fogo). Sensacional! A melhor coisa que eu extraí deste momento foi ouvir do Dude que ele gostaria de ver nos EUA um clima e uma comunidade unida como a nossa. Ele disse que na opinião dele, nós como um grupo, deveríamos ganhar o Gordon Pask Award este ano. Foi muito bom saber que estamos construindo estória e melhor ainda saber que eu faço parte dela. Muito gratificante.

Jantar com The Dude

Neste mesmo dia iniciaram os cursos de XP, CSPO e CSM - todos lotados. Só tive feedback concreto do XP, visto que alguns dos ministrantes eram também organizadores. Me parece que foi muito bom e mesmo em 6 (ou mais) instrutores conseguiram se organizar bem, sem nenhuma preparação antecipada. No dia seguinte, houve o curso de Coaching com o Dude. Este eu pude participar e gostei bastante, especialmente pela forma como o Dude apresenta-se a si mesmo e pela forma descontraída e jovial que ele nos conduz a reflexão e ao aprendizado. Penso que este curso foi um tanto quanto curto, e seria melhor se fosse feito em dois dias ao invés de apenas um.

Coaching Agility com The Dude

Após o curso fomos jantar no Parrilla Del Sur Na Brasa e participei da mesa mais comprida da minha vida até hoje (se não me engano 48 pessoas). Foi muito bom ver todo mundo reunido e descontraindo em torno de um mesmo objetivo - comer e beber, além de falar de agilidade é claro

Bom, o dia seguinte era o dia D. O dia de abertura do evento. Consigo imaginar como o Rafael se sentiu pois creio que senti o mesmo na abertura do Ágiles 2009. Uma mistura de emoção, nervosismo, frio na barriga e outras coisas que não te deixam dormir direito. Eu particularmente também estava preocupado pois ainda não tinha terminado de preparar minha palestra, como muitos outros palestrantes que estavam na organização. O Giovanni Bassi era um deles e como estávamos dividindo o quarto de hotel, combinamos de acordar às 5:30 da manhã para trabalhar. Assim fizemos, mas nem assim consegui terminar minha palestra. Resolvi não almoçar para terminá-la no horário do almoço. E felizmente consegui, às 14hs ela estava pronta.

A minha sessão foi um tutorial onde apresentei o conceito da Pirâmide Lean, que criamos na OnCast para demonstrar como funciona o equilíbrio entre os princípios e prática ágeis distribuídos na hierarquia organizacional de uma empresa. O feedback que recebi foi bem bom. Quem assistiu disse que o conceito é bastante esclarecedor e mostra bem como criar uma cultura que proporcione um fluxo de valor constante. Tive o privilégio de dividir a palavra com Rodrigo Branas, engenheiro de software senior da OnCast onde lidera uma de nossas equipes. O Rodrigo falou sobre Kanban, na verdade apenas uma introdução ao conceito que ele explicaria em detalhes na sua palestra no dia seguinte. Minha sessão serviu também para eu saber se o conceito que criamos está no caminho certo e também para eu melhorar algumas partes que identifiquei como necessárias. Esta mesma sessão será apresentada no Agile 2010 em Orlando este ano.

Quanto a abertura do evento, casa lotada e eu correndo de um lado para o outro. Infelizmente perdi as palavras do Rafael que eu tanto queria ver. Mas foi muito interessante ver todo aquele povo reunido esperando ansiosamente para ouvir o guru Martin Fowler. Gostei da parte em que ele falou de Branching e Configuration Management. Acho um tema fundamental e ainda tenho visto muitas equipes falharem na criação de boas estratégias para Continuous Delivery.

Keynote Martin Fowler

Vale apena resaltar aqui que o pessoal local da equipe da PUCRS fez um excelente trabalho. Na realidade, nos livrou de um árduo trabalho operacional que precisa ser realizado durante a conferência. No Ágiles 2009 não tivemos este privilégio, mas contamos com uma ótima equipe de voluntários que nos ajudou com isso.

Na noite de quinta estávamos todos muito exaustos. Havia uma reunião que eu deveria participar com o David, o Daniel Wildt o Parzianello e outras pessoas que não consegui ir. Precisava fazer algo para renovar as forças. Então decidi dar um treino de capoeira. Em frente ao hotel havia um seminário com uma pista de atletismo e um campo de futebol. Quem via de fora deveria pensar “quem é aquele louco lá de cabeça pra baixo!”. Depois de ativar a endorfina e um bom banho eu estava novo e pude ir para o John Bull Pub onde foi a confraternização do evento. A banda que estava tocando era realmente muito boa. Mas antes dela começar a tocar, tive uma conversa muito interessante com o Klaus, que me contou sua teoria sobre computação soberana e como ele vê uma mudança no mundo digital em favor das redes P2P. Trocamos experiências sobre desenvolvimento de sistemas de alta performance, servidores de tuplas e eu pude aprender bastante com ele.

Pessoal descontraindo no John Bull Pub

No dia seguinte, novamente dormindo pouco, acabei perdendo o Keynote do Kruchten. Pude particpar do Café Kaizen ministrado pelo Rafael e pelo Parzianello. Excelente diga-se de passagem. Eu já conhecia o conceito que o Luiz tinha me apresentado mas nunca tinha visto funcionando. Muito bom mesmo.

A palestra do Rodrigo Branas foi outra grande surpresa. Ele apresentou de uma forma descontraída conceitos muito interessantes que fisgaram a mente de quem esteve presente. De fato, tanto os conceitos da Pirâmide Lean quanto os que o Branas apresentou sobre Kanban são coisas que testamos na OnCast, por isso aprendemos, por isso compartilhamos.

Palestra do Branas sobre Kanban

Agora, o Gran Finalle foi magnífico. Na minha opinião, o Keynote do Klaus foi sem dúvida a melhor parte do evento. Ele reduziu todos os valores do XP para apenas 2: coolness and learning. Ou, aprendizado e ducaralhisse (foi o termo encontrado para traduzir coolnes :D) Ele apresentou a visão dele sobre ser ágil e eu concordo com ela. Houve um ponto paradoxal, onde ele, de certa forma, contrariou o que o Martin disse a respeito de branching. Na verdade ele disse para se possível não usar branching e o Martin disse, se usar, use direito.

Keynote de encerramento com o Klaus

Após o encerramento, distribuição de brindes, etecetera, pousamos para fotos e ainda tivemos energia para fazer uma retrospectiva sobre o evento. De forma geral o evento foi muito bom, alto nível. Encontramos espaço para melhoria é claro, mas nada que desabone a qualidade do evento. Em minha humilde opinião, o programa do evento é a parte em que precisaremos concentrar mais atenção para o ano que vem.

Retrospectiva dos organizadores

A minha missão de volta acabou só no Domingo, quando retornei de POA com um tempo inspirador. Voltei pela rota do sol para pegar um caminho de montanhas e às 20hs cheguei, são, salvo, cansado e com muito aprendizado.

Paradinha para descançar no caminho de volta.

É isso pessoal, até o próximo Agile Brazil.

Samuel Crescêncio Outros

Meu amigo Manoel Pimentel me fez este questionamento hoje e me pediu para que brevemente explicasse o que penso a respeito da essência do desenvolvimento ágil.

Penso que a real essência de ser ágil está em como nos relacionamos com o nosso próximo. Ao longo dos anos, aprendi que entender os princípios que sustentam as práticas, dominar as ferramentas de gestão, conhecer profundamente e aplicar as técnicas de engenharia são itens que estão entre os essenciais no desenvolvimento ágil. Entretanto, observo que ao aplicar o desenvolvimento ágil, muitas empresas pecam por não equilibrar corretamente as forças entre princípios, cultura, gestão e engenharia. Certamente, entender as necessidades em cada uma destas áreas é muito difícil e isto só pode ser alcançado com uma comunicação fluida entre os diversos setores da empresa. Comunicação fluida, todavia, não dignifica memorandos, e-mails, gráficos ou qualquer coisa do gênero. Comunicação fluida é a conversa franca e direta, de modo que possa criar relacionamentos fortes. Ainda, a predisposição de ambos os lados para entender os motivos alheios e a colaborar mutuamente em busca de um único objetivo é imprescindiível para se obter o sucesso. Portanto, concluo que não há como atingir o sucesso no desenvolvimento ágil de software sem que construamos relacionamentos empáticos e verdadeiros, sendo esta, em minha opinião, a pura essência do desenvolvimento ágil.

Samuel Crescêncio Metodologia

What should you, as a developer, deliver at the end of each iteration?

Usually developers using Scrum are concerned with measuring velocity and providing visiblity over the evolution of the iteration by using story points. Therefore, what they are really concerned is to deliver that right amount of story points at the end of the iteration. Is there something wrong with that? Well, maybe! let’s see:

The agile manifesto says that:

Working software is the unique measure of progress.

Most of developers that are starting doing agile strugle to deliver working software every iteration. They also have a speciall attention in doing “correct” estimates, so that they can provide visibility of what is going on. In the other hand, the customer will also be happy due to the fact that he knows that, at the end of the iteration, he will get 35 story points delivered as planned by the team. In fact there is nothing wrong with measuring velocity and keeping a good level of visibility for what is going on your project. The problem happens when you deliver working software that corresponds to the velocity that you’ve estimated, but this working software does not deliver value to the customer.

This sometimes is simply a misunderstading of what value really means to the customer. If the team practices a little bit of empathy, you may get this problem solved very quickly. However, if the problem is caused by a lack of a common vision of the product, you probably are incurring in a much worse problem. If developers are just being told by the product owner customer what to do and they can’t see the whole, they certainly won’t be able to understand what value really is. In this case, a cultural change might be needed in order to deliver value. In both ways, selecting the right priorization criteria will actually determine that value you deliver.

So, the answer for the question is: developers should must deliver value at the end of each iteration, not only story points. Think about that!

A big thank you to David Hussman who gave me these insights at Ágiles2009.

Samuel Crescêncio Metodologia

Now that most of the labor related to the two best conferences that I’ve ever been has gone, I’ll take time to organize my thoughts and share with you. I’m talking about Agile2009 Conference that took place in Chicago, which I had the opportunity to work as a volunteer, and Ágiles2009, the second Latin American Conference about agile methodologies. This last one took place in my beautiful Florianópolis, and I had the honor to be the Chairman. I’m gonna first describe my experience about Agile2009 in Chicago.

“I’m gonna write in English from now on in order to make it possible to friends that I’ve made abroad communicate with us through this blog.”

I’ve really learned a tremendous amount of new things this year, specially  by dedicating a considerable part of my time working to make these conferences a great experience to myself and to everyone that had the opportunity to attend to them.

Volunteers applying Lean Principles

As a volunteer in Chicago, I could work on the backstage of the one that is the most famous agile conference in the world, and learn how they’ve organized such a great conference. I could then apply what I learned in the Ágiles2009 organization. As I’ve never organized a conference before, every detail that I could learn in Chicago was tremendously valuable for me. One of the greatest experiences I had there, was applying Lean principles in the bag assembly. We, as a whole team of volunteers, created a production line, applying the concepts of continuous flow and an integrated chain of material suppliers. Also, sometimes we used the stop the line concept during the work, aiming to continuously improve the process. One of the goals for this production line was to keep small inventories of materials in the assembling line.

I remember that there was a box full of books boring me in my way, therefore preventing me to be faster. I was not responsible to provide materials for the production line, this was a task of another group of volunteers. My job was to work in the production line assembling bags. As that box was really boring me, I decided to stop what I was doing, take the books out of the box and put them in the production line. Then, the guy who was responsible to keep the inventory in the production line arrived with another bunch of books and noticed that something was wrong. There was too many books in the line now. He looked to me with that face, and I said: opssss! I broke the system :s - sorry. This was one of the times that we stopped to analyze the root cause of the problem and improve the system. That box placed in the wrong place was the root couse of the problem. It was very funny, productive and an outstanding way to check out new Lean ideas, while working and making new friends.

What we brougt from Agile2009 to improve Ágiles2009

Keynote - Alistair Coockburn - photo by Tom Poppendieck

The Agile2009 conference joined more than 1.300 professionals that were there to learn, teach and to improve their networking. With this big number of people, keeping things flowing smoothly amongst speakers, volunteers, organizers and attendees is a really hard job, and I also wanted to learn how they did that. This conference is incomparable with Ágiles2009 in terms of budget, structure and size. Consequently, it’s a perfect place to learn from. I can securely affirm that the success of the volunteers organization at Ágiles2009 came from what I learned at Agile2009 as a volunteer. I just gave the tips to the volunteers leads and they have really done a good job. Thank Alex, Rafael and all the team for that. The Jam Session we had at Ágiles2009 was a smaller and different version of the Music Mastik that we had in Chicago. And the open spaces that we created for Ágiles2009, well, this idea originally was created in the first Ágiles2008, but I also saw that in Chicago, and wanted to repeat at Ágiles2009. One of the most famous guy that used this space was Brian Marick while pair programing with other guys. Awesome!  I want these conferences to be a great place for management to learn, but also a perfect environment to geeks dig deeply into the code and really do agile development.

In Chicago I could meet and talk to gurus such as Alistair Cockburn, Martin Fowler, Diana Larsen, David Hussman, Brian Marick and several other guys that are my favorites sources of knowledge.

From Left to Right, Pedro and Thiago from São Paulo, Eduardo a very nice guy that is from Floripa but lives in Chicago, Alistair Coockburn, Rodrigo and Samuel from OnCast and Hugo from São Paulo.

Another priceless opportunity was to meet again Mary and Tom Poppendieck, and to have a break fest at the venue with them. Rodrigo (my partner) and I enjoyed this time to talk about what would be the best release time-frame for a complex product that we want to develop at OnCast. With this conversation we discovered that our thoughts regarding release time were correct

Also, as I’m a wannabe photographer, I asked some questions to Tom about what would be the best first professional camera to buy, and following his suggestions I bought a Cannon Rable XS before leaving Chicago.

Me getting photografic tips with Tom Poppendieck

I’ll soon take more time to post more information about the specific sessions that I’ve attended at both conferences, as well as to dedicate a post like this to Ágiles2009. Hope you enjoyed this first introduction.

Samuel Crescêncio Comunicação

Uma das principais características da complexa tarefa de desenvolver produtos de software que funcionem corretamente e atendam as expectativas do cliente é a imprevisibilidade. Na tentativa de diminuir esta imprevisibilidade processos tradicionais de desenvolvimento confiam em planejamentos intensivos para longos períodos, tentando identificar e mitigar todos os riscos possíveis logo de início. Ao longo dos anos descobriu-se que esta estratégia não é eficaz devido à própria natureza incerta do desenvolvimento de software e dos negócios onde normalmente softwares são aplicados.
Através deste aprendizado, as metodologias ágeis propõem ciclos curtos de planejamento e entrega, nos quais uma parte do produto final é projetada, desenvolvida e testada dentro de um período curto, chamado iteração. Nota-se, neste ponto, que não se fala de protótipos, fala-se de uma parte do produto final que pode potencialmente ser utilizada em produção e será continuamente melhorada e incrementada, iteração após iteração, respondendo às mudanças impostas pelo mercado e pela tecnologia, até que atinja o escopo necessário. A figura abaixo demonstra os vários ciclos que ocorrem durante o desenvolvimento do software e quais aspectos são tratados em cada um deles:

Ciclos de desenvolvimento

Ciclos curtos de desenvolvimento proporcionam maior feedback e aprendizado para todos os envolvidos no processo de desenvolvimento. Com mais informações, as equipes passam a diminuir a incerteza e trabalhar ancoradas em um processo confiável de entregas de produto de alta qualidade e valor agregado. A figura abaixo demonstra o ganho de produtividade do time de desenvolvimento, no uso de ciclos curtos:

Ganho de produtividade em ciclos curtos

Com maior confiabilidade e previsibilidade é possível fazer um planejamento de releases para o projeto, sempre considerando as regras adequadas de priorização e a velocidade da equipe de desenvolvimento. Desta forma, os releases são entregas maiores que contemplam o que foi desenvolvido durante algumas iterações e, associado a um objetivo bem definido, o planejamento de releases passa a ser uma forma valiosa de satisfazer as necessidades de mercado do cliente. Como são priorizadas principalmente as funcionalidades que geram maior valor e tem maior risco para o projeto, os ciclos curtos propiciam um produto de alto valor agregado, diminuindo os riscos e o time-to-market. Consequentemente, a vantagem competitiva do cliente torna-se indiscutível.

Samuel Crescêncio Metodologia

Eu vi uma discussão interessante sobre priorização x estimativas x risco em uma lista da OnCast hoje. Gostei bastante do aprendizado e resolvi transcrever algumas coisas aqui.

Podemos ter diversas formas de priorizar nosso backlog, em geral analisamos o custo de desenvolvimento, o valor gerado para o cliente e o risco inserido numa estória. Sendo assim, considerando apenas valor gerado e risco, temos o seguinte:

- Primeiro desenvolve-se o que gera maior valor e tem maior risco para o cliente;
- Depois desenvolve-se o que gera maior valor e tem menor risco para o cliente;
- Em terceiro desenvolve-se o que gera menor valor e tem menor risco para o cliente;
- E, aquilo que tem maior risco e menor valor procuramos não executar.

Se a estimativa para uma dada estória/tema é de 13sp, parece bastante razoável e adequada em termos de estimativa para um trabalho que leva aproximadamente uma semana de esforço. Agora, se apenas 3 é a estimativa e uma semana é o tempo de esforço, indica que o risco pode ter sido subestimado. Neste último caso, me parece que um pouco mais de aprendizado sobre o que precisa ser feito, vai melhorar as estimativas e auxiliar a identificar melhor o risco.

Em geral, não alteramos nossas estimativas iniciais durante a iteração. Usamos esta informação para melhorar as estimativas da próxima iteração e, ao longo de iterações subsequentes, a velocidade vai equalizar-se e as estimativas passam a se tornar “quase certeiras”.

Uma estória, idealmente, é feita pelo time todo ao mesmo tempo (cada membro pega uma tarefa da estória mais prioritária no momento), e neste contexto o tamanho de estória ideal para proporcionar um boa granularidade e uma boa visibilidade no seu burndown chart é de 3 a 5 story points. Estórias pequenas não deveriam ter mais story points do que isto e deveriam levar em média 2 dias para serem implementadas, lembrem-se - pelo time todo. Então esta dica mostra que uma estória com maior risco, digamos 13 story ponits, projeta um período de aproximadamente 1 semana para ser implementada, o que me leva a crer que as estimativas do time estavam bem assertivas, considerando os 13 story points estimados na discussão que observei.

Dado que estamos usando a escala Fibonacci, utilizamos os gaps que existem entre estimativas maiores para acomodar a incerteza do risco. Então, se não tenho muita idéia do que pode vir a ser o meu risco, utilizo estimativas maiores e os gaps da Fibonacci vão me ajudar a equalizar minhas estimativas, mesmo em estórias com risco - num futuro próximo.

Samuel Crescêncio Auto-gestão, Riscos

Há pouco mais de uma semana Adriano e eu tivemos o privilégio de participar do Agile Weekend em Porto Alegre. Particularmente para mim foi uma honra participar de um evento tão inspirador na cidade em que nasci. O evento organizado por nossos irmãos galdérios foi pra lá de excelente, especialmente por ter sido organizado em um período tão curto e por uma equipe de apenas 4 pessoas. Meus sinceros parabéns aos seus organizadores.

Tivemos o prazer de conduzir duas das palestras mais concorridas do evento. A palestra sobre o Lobo - Continuous Tuning, ferramenta open-source desenvolvida pela OnCast para o monitoramento e testes automatizado de performance, foi muito interessante. Mesmo em um espaço de tempo curtíssimo - 45 minutos, pudemos apresentar alguns conceitos que dão fundamento ao uso de testes automatizados, com foco principal na automatização dos testes de performance. Finalizamos esta palestra com uma apresentação “In Action” do Lobo, demonstrando seu funcionamento e instigando o público presente a baixar a ferramenta e a colaborar no seu desenvolvimento.

Já a palestra de Scrum superou totalmente as expectativas, pois este era um tema que acreditava-se, não teria muito quorum no evento. Para a nossa agradável surpresa, esta foi uma das palestras mais concorridas do evento, ao ponto de os organizadores colocarem cadeiras adicionais no auditório. Algumas pessoas queriam inclusive ficar em pé atrás do auditório mais foram impedidas para que a qualidade do evento pudesse ser mantida.

Além desta nossa pequena contribuição para ajudar a construir as mentes do evento, pudemos construir muito as nossas próprias, aprendendo e trocando experiência com um público tão cativante. Conhecemos pessoas, geramos oportunidades e trocamos idéias com gente muito experiente, o que enriqueceu muito o evento em minha opinião.

Além do imensurável valor de ter reencontrado e conhecidos importantes players do cenário ágil nacional, gostaria de destacar o Jaime, um paraense muito envolvido que nos fez uma entrevista sobre como fazemos ágil na OnCast. Esta entrevista deverá ser publicada em breve em seu blog, mas enquanto isto, convido os nosos leitores a conhecer o excelente e completo relato do Jaime, que cobriu o evento como um reporter profissional, apesar de eu descobrir que ele é um excelente programador

É isso aí pessoal, semana que vem tem o Scrum Gathering em Sampa. O Adriano irá conduzir uma excelente palestra sobre Scrum em um ambiente não ágil e eu estarei lá para dar uma força. Esperamos encontrá-los por lá.

Samuel Crescêncio Outros