Muita gente acha que não precisa dar muita atenção à qualidade na escrita dos testes. Mas o nível de qualidade dos testes deve ser tão alto quanto o do código de produção, afinal, os testes também tem que ser mantidos por tanto tempo quanto o código de produção. No seu livro Clean Code, Uncle Bob conta a história de uma equipe que decidiu abrandar as regras de qualidade nos testes. Traduzindo livremente:
As variáveis não tinham que ser bem nomeadas, os métodos não tinham que ser pequenos e descritivos. O código de teste não tinha que ter um bom design. Contanto que o código de teste funcionasse e cobrisse o código de produção, estava tudo bem.
Quanto mais o tempo passava, mais difícil era alterar os testes e adicionar novos. Vez ou outra alguns testes falhavam quando a equipe mudava o código de produção, e corrigi-los também se tornou uma tarefa árdua e demorada. As estimativas ficaram cada vez mais altas, porque mexer nos testes era muito custoso. Depois de um tempo, eles jogaram fora toda a suite de testes. Mas sem os testes, muitos bugs começaram a aparecer, a equipe perdeu a confiança em alterar o código, e no final, clientes e desenvolvedores ficaram frustados.
Moral da história, se o código será mantido – seja de produção ou de testes – então ele tem que ser bem escrito.
Então, vamos botar em prática essa regra. A seguir, temos um exemplo de como podemos melhorar a qualidade de um teste. No último projeto que participei, uma classe de testes estava nos incomodando. Cada vez que tínhamos que alterá-la, era uma demora. Toda vez que abríamos essa classe, demorávamos entendendo novamente a sua difícil lógica. Vou mostrar a evolução do seguinte método de teste:
@Test
public void actionOriginatedInClientShouldNotBeExecutedIfReceivedFromServer()
O código original:
actionSyncServiceTestUtils.getActionExecutionServiceMock()
.addActionExecutionListener(new ActionExecutionListener( {
public void onActionExecution(Action action,
ProjectContext context,
Set inferenceInfluencedSet, boolean isUserAction) {}
});
loadProjectContext(new ProjectContextLoadCallback() {
public void onProjectContextLoaded(ProjectContext context) {
actionSyncServiceTestUtils.getActionExecutionServiceMock()
.onUserActionExecutionRequest(
new Action(context.getProject().getId(), "filho"));
}
public void onProjectContextFailed(Throwable caught) {
assertEquals(SAME_CLIENT_EXCEPTION_MESSAGE, caught.getMessage());
}
});
Depois da primeira refatoração:
final ArgumentCaptor eventHandlerCaptor = getEventHandlerCaptor();
createInstance();
final ActionSyncEvent eventHandler = eventHandlerCaptor.getValue();
final UUID clientId = new UUID("123");
clientHasId(clientId);
try {
eventHandler.onEvent(new ActionSyncEvent(createRequest(clientId)));
} catch (final RuntimeException e) {
final String sameClientExceptionMessage = "This client received the same action it sent to server.";
assertEquals(sameClientExceptionMessage, e.getMessage());
}
assertNoActionWasExecutedInClient();
I came across my notes from the Agile2009 conference and found a very interesting advice that reminded me how important is to have the right rigor in agile software development.
Scrum without the “R” of Rigor becomes SCUM, which acronym stands for Slow, Confusing, Unreliable and Missing. But missing what? Missing confidence, assertiveness, productivity and other important aspects which make Scrum the preferred choice of agile project management framework for most agile companies.
The rigor and discipline when using any agile methodology is more than essential, it’s vital to the sake of the /company/product/project/team/. The right rigor in understanding the values and applying the principles and practices accordingly is just the difference between failure and success. Without rigor teams tend to shift the focus from valuable deliverables to wasteful rituals, which in turn aggregate nothing to them.
Mature agile leadership in the other hand foments discipline in taking responsibility and demonstrating ownership. Modern agile management delegates the decision making to the people who are actually performing ground work with dirty hands on the code. This is the way to foster a flexible governance and create innovation in the company.
However, when ground workers have no discipline in applying the technical and methodological agile standards, they are prone to generate an immeasurable loss to the business, usually overengineering the solution and making wrong decisions.
Great developers make a move when, and only when they understand the value behind that move. If you understand the value, then rigorously do the minimum movement necessary to achieve that value, never more and never ever less than that.
If you consider becoming yourself a good agile developer/leader/whatever, think and act with discipline and rigor, providing responsibility and restlessly pursuing the goals you and your team have agreed with.
Remember: work hard, fail sometimes, fail fast, make your failures visible, try again, fail again, fail better.
What makes a good developer great? Writing good code or delivering value? Which one would you prefer?
How could delivering value be sustainable without writing good code? Is that possible? In this sense, good code means to me clean code, well documented, easy to read, to understand and to extend. Moreover, good code is well tested, is simple, is cheap to change and is part of a robust architecture, capable of delivering an unfair competitive advantage to the business. Nevertheless, good code is essential to sustainably and reliably deliver value over time. But what if I have all that and have not delivered value? Is that sustainable? Can you keep doing that forever? Probably not.
And in the other hand, is it possible to deliver value with poor code? The answer is: It depends! Usually it is, but in a very short term, since it wouldn’t be sustainable in a long term. It usually depends on what kind of business you’re working on. If people may die if something goes wrong in your software, I would recommend not to rely on poor code to deliver value. But if your business can live with a poor code base for a while, just during the barely enough period you need to generate value, I would say: go for it. Seek the simplest way that could possibly generate value. Sometimes this way is so stupid that we can’t even think about it.
What happens though if you can deliver value in a short term with poor code? Remember that value is the only thing that can keep a business existing. If you have value, you survive. However, if you have no value, even with the best possible architecture, you do not survive – your legacy becomes waste. So, if you’re capable of delivering value with poor code, and you’re intelligent enough to apply the agile engineering practices such as refactoring to improve the existing poor code base, you can transform it into a good code base that will sustain your business in the long run.
Some developers may also argue that the complexity of businesses and the complexity of the human beings with ever changing minds running their business make it even worse to deliver value. These developers are right! Therefore, whether you have good or bad code, you’ll have to deal with numerous aspects other than technology in order to deliver good value. In my humble opinion, there is nothing more important in software development than delivering value. You just have to carefully think what kind of value you’re looking for and to whom it will serve.
So, what kind of developer you are? The one that writes good code or the one that delivers value?
Esse post trata de um assunto que foge um pouco do foco do blog. É sobre uma discussão sobre motivação e tendências mundiais que tivemos na OnCast – apesar de não sermos (nem eu) conhecedores de sociologia ou história.
Tudo começou com um vídeo do Dan Pink que o Vinicius Nunes mandou para o pessoal sobre motivação:
Então, lembrei de uma discussão que tive em uma disciplina no MBA a alguns dias, chamada arquitetura organizacional. Em princípio achei que iria ser um sacrifício ir para a aula, ouvir o professor falando sobre organogramas, etc… Maaaasss, foi sensacional!
Apesar de não ser exatamente sobre motivação, o assunto da discussão trata de tendências mundiais, que podem ser percebidas claramente através do conceito de motivação apresentado no vídeo. A pouco tempo, esse tipo de motivação – pelo propósito, pelo conhecimento – era praticamente inexistente. As empresas e as pessoas (pense em nossos pais ou avós) trabalhavam para ganhar dinheiro, adquirir coisas. A motivação era o dinheiro.
Porém, estamos em transição! A anos atrás (200 ou 300 talvez) vivíamos em uma sociedade seguindo uma tendência artesã onde a padronização e a produção era muito pequena. Os trabalhos eram bastante manuais. Depois entramos na era do industrialismo, onde a padronização foi muito forte, tínhamos produção em massa e trabalhos bem mecânicos. E o que está acontecendo hoje? Pare para pensar quem são as empresas mais admiradas ou valorizadas no mundo: Apple, Google, Microsoft… indústrias onde o conhecimento é a base. Estamos entrando na era do conhecimento!
Essa mudança de onda ajuda a explica a crise nos países “desenvolvidos” (EUA, Grécia, Espanha…). Não há mudança sem crise. E isto está só no começo. Mas onde estão as indústrias? Na China, que, “atrasada” com a evolução, entrou na era industrial a pouco. O que acontece lá hoje já, e que muitos consideram um absurdo com os direitos humanos, aconteceu em outros países que já passaram por esse processo, porém hoje é mais aparente com o avanço da comunicação e a globalização. Outros países nem na era industrial estão.
A China é o país que mais cresce por ano, e portanto é considerado o “novo gigante”. Porém, o que define quem é o maior? O PIB? A qualidade de vida? Há um balanço entre IDH, PIB e poluição? E qual o papel dos países que investem fortemente na mão de obra chinesa?
Para quem se interessar mais sobre o assunto, existem dois livros, ambos do Alvin Toffler, que estou prestes a ler:
Neste vídeo Caju e eu explicamos como foi montado um processo bastante maduro de integração contínua e o que seria necessário para torná-lo num processo efetivo de Continuous Delivery.
Praticamente toda a comunidade ágil, ou da indústria de TI, sabe (ou pelo menos deveria saber) da importância dos testes automatizados.
Porém, apesar da importância dos testes automatizados, raros são os projetos de software que se utilizam deles, ou se utilizam com uma quantidade/qualidade satisfatória.
No último projeto em que estive envolvido aqui na Oncast chegamos na marca de quase 79% de cobertura de testes no nosso código, com testes unitários, de interface (quando relevante) e integração.
Não irei justificar a importância dos testes automatizados. Se você ainda não os julga importante, ou não investe o suficiente, meus pesâmes para você.
Ao invés disso, baseado na minha experiência nesse projeto, vou tentar descrever resumidamente como chegamos nesse número de cobertura de testes, tentando responder a uma simples pergunta que eu mesmo me fiz:
“O que esse projeto teve de diferente de outros para que isso fosse possível?”
O projeto teve duração de 7 meses, onde estávamos em parceria com o nosso cliente, reformulando um dos maiores portais de entretenimento do Brasil atualmente.
Além de um novo visual para o usuário final, também íriamos migrar os dados do portal legado e prover uma nova aplicação administrativa para a geração de conteúdo. A nossa responsabilidade foi da implementação dessa nova solução administrativa e da migração dos dados. Para o desenvolvimento dessa nova ferramenta administrativa foi utilizado Ruby on Rails.
Lembrando que tivemos uma série de desafios nesse projeto, como: distância com o cliente/PO, data definida para o lançamento do novo portal, mudanças na equipe, arquitetura complexa, integração tardia e por aí vai. Enfim, um cenário real que faz parte do cotidiano não só da área de TI como de outras indústrias.
Logo já sabemos que isso não foi o diferencial desse projeto para outros os quais já trabalhei.
Então, como chegamos nesse número de quase 80% de cobertura de testes?
Algumas das diferenças que encontrei, comparando com outros projetos que trabalhei, foram:
Sabíamos da importância ainda maior de testes automatizados utilizando linguagens dinâmicas, nesse caso Ruby;
Apoio do nosso cliente e “product owner” Claudio Br (@oclaudiobr – http://blog.claudiobr.com/), na verdade um dos poucos PO de verdade com quem já trabalhei. Além de priorizar de maneira eficiente, sabe da importância dos testes e sempre nos incentivou;
Os frameworks utilizados (Rails, rspec, e várias outras gems) na maioria das vezes facilitaram a nossa vida para se implementar os testes. Ao contrário de outras linguagens e frameworks (Exemplo: java/javaee/ejb);
A disciplina e o profissionalismo da equipe foi fundamental. Pois mesmo com pressão de prazos, entregas, todos da equipe não abriam mão dos testes;
Equipe madura com uma mentalidade voltada para o TDD/BDD;
Integração contínua (Hudson) funcionando desde do início do projeto;
Atenção com a integração contínua, sempre que uma build quebrava alguém verificava o problema;
Não existe regra ou receita mágica, acredito que nossas experiências (positivas ou negativas) são as melhores ferramentas para que possamos evoluir.
Portanto esse post, nada mais é do que um lembrete para mim, para me ajudar a não esquecer dessa experiência.
E meus sinceros agradecimentos a todos os meus companheiros de equipe da Oncast, que provaram que é possível sim, mesmo com as dificuldades e os obstáculos, ter um projeto com uma excelente cobertura de testes.
A indústria de software está mudando, já mudou – e tem muita gente que ainda não notou. Ouço com freqüência (e também repito) uma citação que diz que Ágil virou mainstream. De fato é a pura verdade. Este ano o Manifesto Ágil completa 10 anos e a Agile Alliance está preparando umabreakthrough conference para comemorar, avaliar o que ficou para traz e refletir sobre o que vem pela frente na indústria de software.
Entretanto me espanta constatar que uma parte significativa das empresas que desenvolvem software, especialmente aquelas que não tem o desenvolvimento de software como fim, ainda sofrem em ambientes caóticos e desumanos. Muitas ainda usam métodos que há pelo menos mais de uma década foram caracterizados como ineficazes para o desenvolvimento de software.
Em desenvolvimento de software há apenas uma grande certeza, a de que existe muita incerteza. Não existe previsibilidade em desenvolvimento de software e também não existe fórmula mágica para isto. Existe sim um conjunto de técnicas, princípios e valores que permitem um processo de desenvolvimento adaptativo e evolucionário, onde o aprendizado precisa ser reconhecido como uma base essencial para que se possa entregar valor de forma contínua e iterativa.
Existe também a necessidade pela colaboração irrestrita entre clientes e desenvolvedores, pela criação de ambientes maduros, onde a visibilidade é total e a confiança mútua é possível. Também não estamos livres dos desafios de conciliar as necessidades de mercado em definir orçamentos claros (e muitas vezes fixos) para escopos que geralmente são mutantes e imprevisíveis.
Porém, tudo isto é possível, e as respostas você encontra na pura essência do Manifesto Ágil, nos princípios do Lean, nas práticas imprescindíveis do XP e nas ferramentas do Scrum. Ainda assim, um equilíbrio vital é necessário. A aplicação inadequada todavia pode também levar projetos à morte. Portanto, se você quer sobreviver num mundo onde não temos chance de errar, mova-se agora. O mundo mudou!
A OnCast Technologies é uma empresa que nasceu com o intuito de promover mudança nos antigos hábitos da indústria de software; promover a colaboração, a responsabilidade compartilhada e a disciplina; tratar as pessoas como seres humanos e não como recursos; estimular a iniciativa e a inovação. Com isso, criamos uma cultura impar, fundamentada nos princípios e valores do Pensamento Lean e do Manifesto Ágil.
Com o crescimento da OnCast e fortalecimento de nossa marca, precisávamos de um espaço que pudesse materializar a nossa cultura e fomentar a disseminação dos nossos valores. Com a ajuda da designer Fernanada Dill, estávamos muito bem amparados para um novo e ambicioso projeto, a criação da nossa nova casa, o #OnCastLab. Confira abaixo algumas fotos e relatos:
Fernanda Dill – a Oncast é uma empresa cuja filosofia, apaixona todas as pessoas que tem a oportunidade de conhecê-la. E comigo, mesmo não trabalhando diretamente, não foi diferente. Assim, foi um grande desafio criar um espaço de trabalho que representasse os valores dessa equipe, mas também, um prazer enorme desenvolver um ambiente comercial tão inovador.
A recepção teve como objetivo principal expôr a identidade visual da empresa, explorando as cores escolhidas para levarem a marca Oncast. Simultaneamente os nichos com formas orgânicas e assimétricas, transparecem a leveza e a irreverência da equipe.
Rodrigo Branas – A nova sede da OnCast Technologies reflete a essência dos valores fundamentais da empresa. É um ambiente onde o incentivo a comunicação e colaboração são levados ao extremo! Esse novo espaço consegue unir valores como profissionalismo e liberdade, proporcionando a todos o melhor ambiente possível para se trabalhar e desenvolver suas carreiras.
Fernanda Dill – Na sala de reuniões buscamos um ambiente um pouco mais tradicional e sofisticado afim de receber clientes e abrigar reuniões de planejamento da empresa. Nas salas da presidência, marketing comercial e diretoria de operações, o conceito foi a personalização. As salas são temáticas, estampando nas paredes literalmente a identidade dos seus colaboradores.
Vitor Pelizza – O OnCastLab é mais que um ambiente de trabalho. É um ambiente onde estamos trocamos experiências, nos divertimos e exploramos nossas idéias, aproveitando todo o apelo criativo. É a materialização da “cara” da OnCast!
Foi sensacional a primeira reunião de integração (nossa reunião geral) com todos confortáveis nos puffs, apresentando o material caminhando sobre a grama, jogando um video-game no intervalo… Sem dúvida encontramos nossa casa para tornar nossa cultura cada vez mais forte, nosso software cada dia com mais qualidade e definitivamente o local para conseguirmos alcançar a realização profissional e pessoal de cada um.
Fernanda Dill – A área de desenvolvimento comporta até 35 pessoas. As equipes ficam integradas, porém inúmeros quadros brancos entre elas, garantem a privacidade para que cada uma possa discutir seu projeto. Os Open Spaces, posicionados na área de desenvolvimento, trazem um conceito lúdico, representado na utilização de grama sintética, puffs coloridos e adesivagens nas paredes. Esses materiais e cores, estimulam a criatividade, a interação entre os colaboradores e proporcionam momentos de descontração que potencializam os resultados das equipes.
Fernanda Dill – Por fim, o Living, sem dúvida o espaço preferido da equipe nas horas de descanso, é um lugar de entretenimento e de convivência. Conta com uma pequena cozinha, espaço para tomar uma café, “Bater um papo” com os amigos e distrair a mente e o corpo descansando em um puff ou jogando video game.
É importante destacar que aspectos ergonômicos foram a base de todo o projeto, proporcionando maior conforto aos usuários e gerando um espaço propício para que cada um desenvolva suas atividades com a máxima qualidade e performance.
Fernanda Dill – Um espaço nada convencional, nada tradicional, mas pronto para receber a melhor equipe de desenvolvedores e demais profissionais que a Oncast possa ter. Um ambiente pronto para fazer com que cada pessoa tenha prazer de fazer parte da Família Oncast.
Este espaço é um pouco do que estamos fazendo para mudar a indústria de software. Faça parte desta mudança você também, venha nos fazer uma visita e descobrir como. Grande abraço…
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.
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.
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.
