Páginas

28 setembro 2007

Scrum FAQ em português

Saudações a todos!

Bem, não sei ao certo o porque fiz isso, talvez pela influência do livro Wikinomics...
Com a intenção de ampliar a divulgação de Scrum e Desenvolvimento Ágil nas empresas brasileiras, o documento escrito por Howard van Rooijen filiado à empresa Conchango, que transcreve entrevistas feitas com Ken Schwaber respondendo perguntas sobre Scrum, foi traduzido para o português por mim.

Vejam o documento: arquivo

editNote: Link já corrigido

[]s

Não tem o que fazer em Dezembro?

Eu tenho a solução!
Como a Agille2007 teve uma procura imensa e todos os ingressos foram vendidos 2 meses antes, o pessoal resolveu promover um novo evento! coisalinda! Principalmente pra quem tem ao menos 1000 dolares pra desembolsar na inscrição, mais passagem e estadia... aproveitem!

A programação está impressionante!
Vale a pena!




27 setembro 2007

Tem certeza que não serve para sua empresa?



Saudações!

Bem, o Clavius Teles, da Fortes Informática, indicou na lista xpRio um documento muito interessante falando sobre a aplicação de práticas Ágeis no Google. Sim, como a própria apresentação diz: "Práticas Ágeis em Projetos Reais"...

Engraçado o título da apresentação, talvez para que as pessoas passem a dar algum crédito para o que está acontecendo no mundo, e como nós estamos avançando na utilização de modelos de desenvolvimentos mais próximos da realidades das empresas. (Desenvolvimento Ágil está mudando o mundo!)

Pontos Importantes sobre a apresentação:

- Existe uma influência muito forte de prática de XP na forma de trabalho das equipes. Praticamente todas as práticas são listadas na apresentação.

- Preocupação em manter o desenvolvimento sobre o olho atento da qualidade, através de métricas e Feedback (Métricas em Desenvolvimento Ágil)

- Desenvolvimento Ágil escalável com certeza!
Num dos exemplos que me chamou a atenção, em que a equipe deveria trabalhar com código legado, vê-se a preocupação com testabilidade, com ciclos de refactoring para possibilitar a criação de testes e ainda a utilização de TDD para qualquer código novo que fosse inserido...

- "Plans are nothing; planning is everything" - Dwight D. Eisenhower

Lembre-se disso:

We do Agile at Google in response to real need, to provide real results, not because someone thought it would be a cool thing to do.


Veja a apresentação na íntegra


Outro exemplo interessante: Yahoo!

Results From Scrum
The benefits of Scrum reported by teams come in various aspects of their experience. At Yahoo!, we have migrated nearly 90 projects to Scrum in the last 30 months, totaling almost 900 people, and the list of teams using it is quickly growing. These projects have ranged from consumer-facing, design-heavy websites like Yahoo! Photos, to the mission-critical back-end infrastructure of services like Yahoo! Mail, which serves hundreds of millions of customers; they range from entirely new products like Yahoo! Podcasts, which used Scrum from concept through launch (and won a Webby Award for best product in its category that year), to more incremental projects, which included work on new features as well as bug fixes and other maintenance; and we’ve used Scrum for distributed projects, where the team is on separate continents. Several times each year we survey everyone at Yahoo! that is using Scrum (including Product Owners, Team Members, ScrumMasters, and the functional managers of those individuals) and ask them to compare Scrum to the approach they were using reviously.


Veja o texto na íntegra


Dúvida: você ainda se acha grande o suficiente para dizer que Desenvolvimento Ágil não serve pra você?


Um abraço

25 setembro 2007

Entenda o Behavior Driven Development



Saudações a todos!

O rapaz simpático do video abaixo é David Astels, que lançou o livro TDD:A pratical Guide, extremamente recomendado se você deseja aprender alguma coisa sobre desenvolvimento orientado a testes.

Entretando, testes não atendem às reais necessidade de se criar um sistema de forma a ter uma especificação executável de comportamento. Ou melhor, "Test Driven Development" não é a melhor maneira de descrever o que se pretende com o TDD. Assim, David Astels discorre sobre o modelo Behavior Driven Development, segundo ele mais próximo do intuíto que ele imagina como sendo o válido.

A idéia é simples, e toda a apresentação pode ser expressa da seguinte forma:

A criação e utilização de Testes automatizados não é o real intuíto do TDD, e uma nomenclatura mais efetiva é necessária.
A criação de testes antes de escrever o código é uma forma de especificar um comportamento que o sistema deverá atingir, sem preocupar-se com a implementação do método. E devem existir frameworks que correspondam a essa expectativa. =)


Com vocês, o vídeo:







Aprenda mais sobre TDD no CodingDojoFloripa



24 setembro 2007

10 Boas Razões para adotar Desenvolvimento Ágil

Saudações!!
Encontrei um site muito bom para referências! Uma série de artigos importante e pertinentes podem ser encontrados no blog All About Agile. Foi de lá que tirei minha última referência para falar a respeito do desenvolvimento Ágil.
Existe alguma razão para se largar um projeto aos moldes tradicionais?? Claro que sim!
Segue abaixo uma lista feita por Kelly Waters, e ao término algumas considerações minhas...

1. Rendimento
A característica iterativa do Desenvolvimento Ágil significa que funcionalidades são entregues incrementalmente, possibilitando o retorno de alguns benefícios à medida que o desenvolvimento do software prossegue.

2. Time-to-market
Acredita-se que 80% de todos os líderes de mercado foram os primeiros a criarem um nicho específico (melhor discutido no livro Estratégia do Mar Azul, e no Artigo The PDMA Handbook of New Product Development). Assim como o rendimento trazido através de entregas constantes e incrementais, a filosofia do Desenvolvimento Ágil permite aproveitar oportunidades mais rapidamente, seguindo tendências e apostando em mercados pouco explorados.

3. Qualidade
Um princípio chave do Desenvolvimento Ágil é a noção de que testes estão inseridos em todo o processo de desenvolvimento, permitindo inspeções regulares do produto em funcionamento à medida que ele está em desenvolvimento. Isto também permite que o dono do produto faça ajustes caso necessário, dando a visibilidade sobre questões de qualidade de software muito cedo no desenvolvimento.

4. Visbilidade
A participação efetiva do usuário ou cliente no ciclo de desenvolvimento do produto é um dos principais princípios descritos no Manifesto Ágil de uma forma colaborativa. Possibilidanto a real visibilidade do projeto para stakeholders importantes, através de um ambiente informativo que permite enxergar objetivamente "Onde estamos" e "Para onde Vamos" no projeto. Expectativas podem ser facilmente gerenciadas desta maneira, e o envolvimento de todos torna-se maior à medida que equipe, gerência e clientes possuem as mesmas informações para tomada de decisão.

5. Gerência de Risco
Pequenos incrementos no produto permitem à equipe e ao Produtc Owner identificar problemas mais cedo e mais facilmente fazer os ajustes necessários responsando à mudança. A visibilidade clara e objetiva no Desenvolvimento Ágil auxilia nas decisões de mudança o mais cedo possível, enquanto ainda da tempo de criar algum material para que o produto seja lançado.

6. Flexibilidade / Agilidade
No desenvolvimento de software tradicional, uma grande especificação inicial é criada com o intuíto de mostrar aos clientes o quão caro é fazer qualquer tipo de mudança no projeto, especialmente no momento em que ele já estiver em andamento. Em medo a alterações de escopo e projetos que nunca terminam, resiste-se a mudanças criando comitês para controlar qualquer item que possa sair da especificação inicial. Não funcionamos deste jeito. Embrace change!!
Seguimos um modelo onde mudanças são esperadas. Afinal, a única certeza que temos neste mundo é a mudança. Obviamente que para isto ocorrer de forma coerente, é necessário que um stakeholder entenda estes princípios fazendo ajustes necessários, modificando expectativas e requisitos iniciais do sistema.


7. Controle de Custos
Muitos projetos em desenvolvimento possuem o conceito de Custo Fixo - Escopo mutável, bastante importante para possibilitar os princípios acima.


8. Satisfação do Cliente
O envolvimento ativo do cliente ou usuário, a visibilidade dada sobre o progresso e ainda a flexibilidade à mundança quando mudanças são necessárias criam um vínculo muito maior entre empresa e cliente, ampliando ainda mais a satisfação dos stakeholders. Este efeito colateral é pode ser de suma importância para a perenidade da empresa e futuros contatos de negócio.


9. O produto correto
Incorporando a mudança aos projetos, permitindo que requisitos emerjam das necessidade e oportunidades de agregar valor ao cliente, a equipe termina por construir o produto mais próximo o possível ao que o cliente precisa. É comum encontrar casos em que um projeto mesmo sendo bem sucedido do ponto de vista do Desenvolvimento, acaba nem sendo utilizado pelo cliente devido à mudanças ocorridas nas necessidades dos usuário finais. Em Desenvolvimento Ágil a ênfase é absolutamente em construir o produto correto.

10. Mais agradável!
O ambiente de envolvimento, cooperação e colaboração criado num projeto Ágil permite uma experiência muito mais agradável para a maior parte das pessoas. Ao invés de grandes especificações, nós discutimos requisitos em workshops. Ao invés de relatórios gigantescos, nós colaboramos ao redor de um processo de discussão mais simples e informal. Ao invéis de longos e custosos planos de trabalho e comitês de controle de mudanças, nós discutimos o que é melhor para o produto e para o projeto, ampliando o poder de decisão da equipe.
Você espera que seu time torne-se altamente motivado? Deveria começar a prestar atenção no que estamos discutindo há anos...


Considerções:

Particularmente vi pouca ênfase do Mrs Waters no que diz respeito ao perfil auto-gerenciável das equipes no desenvolvimento Ágil. Um modelo que permita a interação contínua entre as pessoas faz com que todos na equipe cresçam de uma forma que ninguém espera, já que são obrigados a conversar, entrar em acordos, tomar decisões difíceis e entender a liguagem existênte na área de Desenvolvimento de Produtos, e não apenas de software.
Caso sua empresa queira que um profissional evolua no decorrer de sua carreira, e lembrando das 12 Competências para um bom profissional de TI, o caminho e deixá-lo crescer através das próprias pernas, possibilitando apenas um ambiente em que ele exerça faculdades além do simples desenvolvimento de software.
O poder colaborativo dos projetos Ágeis traz à empresa uma questão nova relacionada ao modelo de gerenciamento que existe há alguns anos. Dar aos desenvolvedores o poder de decisão e a capacidade de responder rapidamente a mudanças de mercado acarretará um demanda por modelos mais enxutos de gerenciamento e controle da instituição, para que se possa atender a velocidade com que os projetos serão entregues ao mercado. Será necessário que a empresa como um todo suporte o modelo Ágil: RH e planejamento estratégico devem estar alinhados para trabalharem em conjunto com as equipes. Acredite, o trabalho não é fácil, mas muito motivador.

20 setembro 2007

O Futuro (será?)



Essa semana estive conversando com um grande amigo, o Ivan do DojoFloripa, e comentávamos sobre como nossos modelos (brasileiros) estão atrasados em relação ao resto do mundo... ao menos dois anos nos separam dos demais modelos produtivos ao redor do mundo...

Até que comecei a ler um livro... e acabei reafirmando essa afirmativa... temos muito que aprender ainda... livro de mais de um ano atrás apresenta exemplos bem sucedidos de colaboração para a geração de valor...


A Internet de ontem, só para leitura, do tipo "publique e navegue", está se tornando um lugar onde o conhecimento, os recursos e a capacidade computacional de bilhões de pessoas estão se agregando para formar uma força coletiva maciça. Energizada por blogs, wikis, salas de bate-papo, transmissões pessoais e outras formas de criação e comunicação peer-to-peer, essa força extremamente descentralizada e amorfa cada vez mais se auto-organiza para fornecer as próprias notícias, o próprio entreterimento e os próprios serviços. À medida que esses efeitos permeiam a economia e cruzam com mudanças estruturais profundas como a globalização, veremos o surgimento de um tipo totalmente novo de economia, no qual as empresas coexistem com milhões de produtores autônomos que se conectam e criam conjuntamente valor em redes livres acopladas. Chamamos isso de economia da colaboração.

Wikinomics




17 setembro 2007

Atendendo a um mercado ágil



Saudações!
Na última edição da revista Época Negócios, observei uma frase bastante interessante atribuída a Kevin Kelly, fundador da revista Wired:
"Não estamos mais numa época de mudanças, mas numa mudança de épocas"

Evoluímos mais do que os modelos de desenvolvimento pudessem suportar. Atualmente necessidades de mercado fazem com que produtos novos sejam lançados a cada seis meses (Apple, Panasonic, Sony, Google, Peugeot, etc já seguem esse padrão), ou até menos. E como nós, no desenvolvimento de software, reagimos a isso? Como nos tornamos eficientes o suficiente para que, a cada ciclo curto de mudanças de mercado, possamos responder com alto valor de negócio a requisitos de sistema?
Desenvolvimento Ágil é a única solução? Resposta clara: não! Mas pode ser uma ótima saída ao engessamento que nossas empresas vem passando. Europa e EUA já fazem isso há algum tempo, quando cairemos na real?

Visando a melhoria contínua de processos, e tendo em mente que algumas práticas de Desenvolvimento Ágil são realmente importantes, algumas sugestões de melhorias. Vejam as práticas:

1) institucionalizar reuniões de feedback, sejam elas em término de uma iteração ou no término de um projeto.

2) melhorar stand-up meetings!
- feitas ao lado do quadro
- ampliar complexidade do quadro informativo
- foco na resolução do problema

3) Pair Programming com maior frequencia...

4) revisão de código (como alternativa e complemento ao uso do TDD/Pair programming)
- sessões rápidas (pouca quantidade de código)
- validação de padrões de código
- possíveis melhorias em algoritmos
- visando ampliar comunicação sobre design/arquitetura

5) iniciar testes automatizados... nem que sejam simplificados
- incentivar a utilizacao de ferramentas de teste
- buscar informações sobre o tema
- implantar TDD

6) formar a cultura em volta da qualidade de software("what does 'done' mean?")
- definicao clara do que é uma funcionalidade terminada, e que possa ser realmente questionada
- deixar os próprios funcionários gerarem conteúdo de valor para a organização
- documentos e mais documentos para leitura e formação
- wikis
- foruns
- listas de discussão

7) Tentar aplicar os principios de desenvolvimento(necessário cobrança/inspeção)
- principio DRY (dont repeat yourself)
- principio KISS (keep it sweet and simple)
- principio "Don´t live with Broken window"/"Stop the line"
- principio YAGNI (you ain´t gonna need it!)


Vou explicar a relação entre as práticas, mostrando como elas se encaixam para tornarem-se uma opção concreta de melhoria para a empresa.

É excepcionalmente importante colocar o feedback no topo da lista de práticas a serem adotadas. A informação gerada durante uma reunião de término de iteração pode ser definida como:
  • O que de "bom" fizemos nesta Iteração? (se tivéssemos que repetir a iteração, seria mantido igual)

  • O que poderia ter sido feito diferente? (se tivéssemos que repetir a iteração, esses itens deveriam ser feitos de outra forma)

  • Em que podemos melhorar? (Idéias concretas sobre como melhorar para o futuro)


Assim, pode-se identificar necessidades e ataca-las com maior conhecimento na próxima iteração. Mais do que isso, é a forma de cultivar a motivação da equipe dentro do projeto, já que suas sugestões de melhoria são realmente ouvidas e podem ser efetivamente aceitas. Até mesmo reuniões de término de projeto, podem dar luz a problemas que possam ter ocorrido durante seu trajeto. Soluções e acordos encontrados nessas reuniões podem servir de base para a melhoria contínua que os métodos Ágeis se propõe.
Este item está intrinsecamente ligado à idéia de formar uma cultura sobre qualidade de software, pois a equipe estará focada em verificar formas de melhorar o próprio trabalho, e aliar essa motivação à Informação é o caminho mais rápido para o desenvolvimento do grupo. Um canal que possa disponibilizar conteúdo relevante sobre práticas de desenvolvimento e qualidade de software pode servir de referência para que todos participem da mudança que a empresa se propõe. É necessário envolvimento real das pessoas para que a cultura se instale na empresa. Como conseguir isso? Responsabilidade! Todos devem tornarem-se responsáveis pela manutenção do modelo de desenvolvimento de software com qualidade. Essa cultura surge à partir da relação que todos tem com o trabalho. Um profissional saberá sempre como tornar seu trabalho mais produtivo. Se existe uma formam dele conhecer mais sobre como melhorar a própria produtividade, ele o fará. E ainda, se lhe for dada a oportunidade de decidir sobre como tornar seu trabalho mais produtivo, ele assumirá o risco.
Assim, também a melhoria do processo de Reuniões Diárias tenta fomentar a melhor circulação de informações entre a equipe. Deve-se criar um Ambiente informativo, onde o número de dados é o mais relevante e o necessário para a tomada de decisão. O aproveitamento da prática pode ser muito ampliado se ela possuir a intenção de alinhar todos da equipe e remover entraves ao desenvolvimento, além de ser o real status do projeto.

Ligado à melhoria do código produzido (entre outros benefícios), as demais práticas estão fortemente ligadas.
Pair programming e ciclos revisão de código são grandes aliados, complementando um ao outro. Essas práticas vão ajudar a divulgar padrões de codificação, formatação, convensões de código e auxiliam na definição de Modelos de Objetos e Arquitetura de software que o projeto pode assumir. São práticas muito ricas para o terminamento de novos desenvolvedores e para criar o que chamamos de Código Coletivo no projeto, pois qualquer um dos desenvolvedores poderá manter o código do sistema, já tudo está padronizado e que, muito provavelmente, algumas pessoas já tenham trabalhado com o código.
Pair programming é a prática mais complexa de se justificar para gerentes, e existe uma forma de tornar a transição menos dramática para todos: inicie ciclos de revisão de código em dupla. Pouco código por vez, apenas o mais crítico à aplicação. Com o tempo, torne uma rotina a resolução de problemas complexos do sistema utilizando uma dupla. O resultado é bastante motivador, e poderá ser assumido pelos desenvolvedores e gerência de maneira mais orgânica.

Simplicidade é a alma do negócio.
Testes de software, inicialmente com poucas pessoas, apenas para validar a utilização da prática no ambiente de produção, já são um motivo para que a codificação fique simplificada. Aliado à programação em dupla/revisão, é o que eu chamo de "Combo da Qualidade Ágil"...
Princípios de desenvolvimento (KISS, DRY, YAGNI,etc) não precisam ser obrigatórios, pois eles naturalmente ganharão notoriedade à medida que as outras práticas estiverem sendo implantadas: utilizar testes obriga a pensar de maneira desacoplada, tentando criar a maior independência possível entre funcionalidades, facilitando a reutilização de código. Por outro lado, como as implementações tem que ser simples e de fácil compreensão, a revisão de código possibilita que sejam feitos refactorings de código apoiados em testes para garantir que tudo continua fucionando após a mudança. Programar em dupla auxilia no que é chamado "pressão da dupla", em que o código produzido pela dupla tende a ser melhor, já que sempre existe uma pessoa ao lado para inspecionar informalmente o código produzido.

Mais uma vez: não estamos aqui brincando de fazer software! Apoiamos um modelo de desenvolvimento bem formulado e com base suficiente para suprir a necessidade do mercado: inovação, respostas rápidas às necessidades do mercado e crescimento sustentável do software.


Referências:


14 setembro 2007

Daily Meeting Anti-Patterns



Olá!
Bem, com o DojoFloripa de cara nova e bem aceito pelas pessoas eu estou me empolgando mais em escrever... vamos ver se esse negócio dá resultados mais pra frente...

Mais Anti Patterns!!
Estava lendo o famoso artigo de Martin Fowler intitulado: It's Not Just Standing Up, e percebi um artigo de 2003 nas referência que tratava sobre anti padrões na prática.

Bala de Prata (Magic Bullet)

Problema: Reuniões diárias podem ser vistas como substitutas das tradicionais reuniões, ou ainda para qualquer tipo de interação entre os desenvolvedores.

Discussão: Reuniões diárias devem ser momentos para que a equipe alinha-se sobre o que cada um dos membros está fazendo. É a maneira de manter-se informado diariamente do progresso de todos, e também dos problemas que cada um está enfrentando em suas tarefas. O problema principal vem da não compreensão da prática ou mesmo a não aplicação deste entendimento.
Acreditar que qualquer outro tipo de interação do grupo seja desnecessárias é ilusão. 10 minutos de conversa por dia não elimam a necessidade de encontros mais formais, onde idéias mais complexas e assuntos mais complicados são feitos, apresentações e inspeções são realizadas.
Determine momentos em que é realmente necessário passar mais tempo discutindo ou apresentando progressos. É importante para a equipe o lado formal de reuniões tradicionais.

Sermões (Sermon on the mount)

Problema: Gerentes adotam a reunião diária como forma de apresentar seu discurso. Após o discurso, a reunião acaba.

Discussão: Situações em que a participação de alguém é improdutiva e frustrante pode ser o reflexo de problemas muito maiores. Uma solução (não atrativa para mim) pode ser encontrar-se às escondidas. Talvez o horário do café seja o momento exato de para dar um feedback para a equipe, e saber o que todos estão fazendo.

Perdendo Foco (Aching legs)

Problema: Reuniões duram muito tempo

Discussão: Argumentações entre desenvolvedores podem facilmente sair do controle. Seja pela ânsia causada por um problema ou pela excitação de novas descobertas a equipe inteira vira refém da tentativa de resolução de um único domínio. Qualquer pessoas que não esteja envolvida com a discussão perde a atenção facilmente, desejando voltar para sua estação de trabalho fazer algo de mais produtivo com sua vida.
Existem sugestões de diversificar e tornar o ambiente mais dinâmico: que tal um reloginho ovo (cooking watch)? Ou alguém da equipe ser o responsável por manter as discussões no limite do aceitável? Ou para sugerir que as discussões sejam tratadas em outro lugar?
É importante que o gerente não interfira completamente nessa questão, pois a equipe pode ser influenciada e perder o tino para a auto-organização, deixando nas mão desse gerente a tarefa de cuidar de todos.

Caos (Chaos)

Problema: Reuniões são desorganizadas

Discussão: Falta de estrutura para as reuniões pode ser extremamente problemático para o time. Sem um horário marcado, muitas pessoas chegando atrasadas, não existe uma definição clara de quem eh o primeiro a falar e por ai vai...
Uma boa solução é tornar a reunião divertida com algumas práticas simples. Algo semelhante àquela brincadeira com a garrafa no jogo da verdade(estou ficando velho...) pode ser bom para definir quem é o primeiro a falar. Punições simples aos atrasados (que tal os atrasados falarem primeiro) pode ser ótimos motivadores para a pontualidade. Importante que tudo seja feito com cuidado e diversão.


Questões emocionais (Sensitivity Issues)

Problema: algumas pessoas podem ter sérios problemas expressando-se em público (dificuldades com o idioma ou vergonha excessiva), tornando-se uma barreira para toda a equipe.

Discussão: Se na equipe alguém constantemente nao participar das reuniões você pode ter um problema muito grande no foco da reuinão: saber o que todos estão fazendo. Entretanto, deve-se reforçar o ambiente amigável das reunião (por isso ações para descontração), facilitando que todos participem sem receios.





Você pode citar mais algum anti padrão?? Comente!

Enquete: O que o DojoFloripa pode fazer por você?



Saudações!
Já que o WordPress não nos dá a possibilidade de colocar enquetes no site, colocamos aki mesmo!!!

Eu e o Ivan queremos melhorar o conteúdo do site, e com o número grande de pessoas que acessam aceitamos o desafio de perguntar a todos: O que temos que melhorar?!

Por favor votem! Conto com a sinceridade e a compreensão de todos que queremos realmente gerar conteúdo de qualidade!

Obrigado!




O que você gostaria que fosse melhor tratado no codingDojoFloripa?









 


13 setembro 2007

Desenvolvimento de software igual Jardinagem, não engenharia!



Essa vai doer fundo na alma de alguma pessoas...
Gostei muito da entrevista de Dave Thomas, ou melhor, Pragmatic Dave como foi dito na Agile2007, feita para a Artima Developers por Bill Venners , acredito que todos deveriam ler na íntegra o artigo.
Mas uma coisa me chamou a atenção durante a leitura do texto (bastante longo por sinal): A tentativa de definição do desenvolvimento de software como sendo Jardinagem, não engenharia... simples não é mesmo? E pra mim acabou fazendo sentido.
Nas próprias palavras de Dave Thomas:
There is a persistent notion in a lot of literature that software development should be like engineering. First, an architect draws up some great plans. Then you get a flood of warm bodies to come in and fill the chairs, bang out all the code, and you're done. A lot of people still feel that way. I saw an interview in the last six months of a big outsourcing house in India where this was how they felt. They paint a picture of constructing software like buildings. The high talent architects do the design. The coders do the constructing. The tenants move in, and everyone lives happily ever after. We don't think that's very realistic. It doesn't work that way with software.

We paint a different picture. Instead of that very neat and orderly procession, which doesn't happen even in the real world with buildings, software is much more like gardening. You do plan. You plan you're going to make a plot this big. You're going to prepare the soil. You bring in a landscape person who says to put the big plants in the back and short ones in the front. You've got a great plan, a whole design.

But when you plant the bulbs and the seeds, what happens? The garden doesn't quite come up the way you drew the picture. This plant gets a lot bigger than you thought it would. You've got to prune it. You've got to split it. You've got to move it around the garden. This big plant in the back died. You've got to dig it up and throw it into the compost pile. These colors ended up not looking like they did on the package. They don't look good next to each other. You've got to transplant this one over to the other side of the garden.


Que tal?

12 setembro 2007

Métricas em Desenvolvimento Ágil



Saudações!
Estive atrás de informações sobre métricas aliadas ao desenvolvimento Ágil, já que é necessário mensurar o desempenho e validar o estado atual de um projeto.
A pesquisa foi muito melhor do que eu imaginava. Além de regras e fórmulas, encontrei um material bastante pertinente a respeito, inclusive uma edição inteira do Agil Journal falando sobre o tema
Farei uma pequena contextualização antes de continuar:

Deviado ao custo elevado em se manter um departamento de TI (profissionais caros e equipamentos mais caros), são necessários métodos de mensurar o desempenho e garantir que o dinheiro investido não está indo para o ralo. Infelizmente à medida que nos aprofundamos no assunto, seguindo modelos tradicionais de desenvolvimento e desempenho, verificamos que falta clareza na utilização de ferramentas de mensuração, e que estamos a todo momento medindo aquilo que não é importante, deixando de lado o que realmente justifica a utilização da TI: a agregação de valor ao negócio. Ao invés disso, o foco das medidas está em atributos de software e quantidade de dinheiro dispendido. Entre essas medidas podemos citar: pontos de função criados, horas trabalhadas, número de linhas de código por desenvolvedor ou ainda orçamento gasto. Aliado à falta de estrutura para receber tais dados esse relatórios fazem que os itens tenham seu valor superestimado, criando uma visão míope do projeto.

Medidas como linhas de código por desenvolvedor ou horas trabalhadas sempre levam a problemas muito maiores para o projeto. Um programador, quando cobrado em linhas de código, evitará qualquer tipo de reutilização ou refactoring que aumente a qualidade do código para que possa parecer produtivo. Ou ainda ele poderá degradar-se completamente ao trabalhar a mais do que o necessário, criando dificuldades de relacionamento e de participação no projeto (lembrem da prática: Semana de 40 horas). Perceba a complexidade que é criar e fomentar tais medidas.

Tradicionalmente atribuimos uma medida de produtividade aos indivíduos do projeto. É pior ainda! Uma equipe deve possuir uma identidade única, que é projetada ao mundo externo como reflexo de seu comprometimento com o projeto, e não como uma série de indivíduos que trabalham por si em detrimento do grupo. Pois é isso que acontece ao medir produtividade individual das pessoas da equipe. Uma equipe deve competir para ser a melhor dentro de toda a organização. Não acredito que gerentes queiram uma equipe que disputa para ver quem é o melhor dentro dela mesma.
Mike Griffths apresenta sua visão sobre isso de forma bastante interessante em seu artigo. Baseado no Efeito Hawthorne, que demonstrou a mudança de produtividade de trabalhadores através do simples fato deles terem conhecimento da medição de produtividade, Mike apresenta a idéia de que uma medição efetiva não deve em nenhum momento atrapalhar a qualidade do projeto (medir linhas de código não é o caso), e deve estar direcionado a elementos chave para o desenvolvimento. Ele cita também um modelo de seleção de métricas definido por Donald Reinertsen:
Primeiro, deve ser simples, métricas ideais são geradas automaticamente no sentido de que não é necessário esforço extra para serem produzidas. Segundo, elas deve ser relevantes. Isto é, o controle deve ser feito pelas mesmas pessoas que estão sendo medidas. Psicólogos já descobriram que quando as pessoas acreditam que podem controlar alguma coisa, elas estarão mais motivadas para controlá-la. Mensurar uma equipe por algo que ela não tem controle apenas causará estresse, insatisfação e alienação. Terceiro, deve ser focado em indicadores de condução. Meça olhando para o futuro, e utilizando tais dados para relatar o passado. É mais fácil medir o tamando de uma fila de testes do que é medir o tempo de processamento dos testes individuais pelo fato de que o tamanho da fila é um indicador de condução para futuros atrasos no processamento do teste.


Modelos ágeis em sua concepção já promovem um jogo completo de métricas que podem ser coletadas de forma trasparente. Testes unitários, análise da qualidade de código e outras medidas técnicas podem ser automatizadas no processo de Integração Contínua. A unidade comum de trabalho - o história - é o fundamento para medidas de gerenciamento de projetos e qualidade de alinhamento de negócio. É importante lembrar que todo o ferramental existe para dar suporte a isso, e que se deve encarar este modelo de métricas com uma visão global.

Ross Pettit, em seu artigo, propõe a seguinte categorização:

  • Excelência em desenvolvimento: Consolidando objetivos para medição de código. Não deve ser analizado em separado, pois causará distorções graves.

  • Qualidade: medidas de defeitos que possam escapar ao desenvolvimento bem como o alinhamento entre desenvolvimento e especificações funcionais.

  • Sensibilidade ao negócio: para os modelos ágeis, requisitos são assumidos como user stories, tornando-se a real expressão do valor de negócio. Podem ser medidas como o grau de valor objetivado e o grau entregue.



Exemplos reais de métricas e relatórios

CFD - Cumulative Flow Diagrams
Bastante Interessante! Ele seria o complementar ao BurnDown Chart do Scrum, trazendo a relação de requisitos completos, requisitos restantes e requisitos em desenvolvimento.

No exemplo acima, o progresso é indicado pela completude da faixa verde no decorrer do projeto. Importante notar a mudança de proporção relacionada à faixa superior, indicando aumento de user stories no decorrer do projeto. Esta mudança pode indicar um problema relacionado à comunicação entre produto e desenvolvedores.

Parking-Lot Chart
Ouvi falar a primeira vez desse gráfico com Mike Cohn no livro Agile Estimating and Planning, e achei extremamente interessante! A ideia é utilizar agrupadores para reunir requisitos com o mesmo domínio e montar um grafico contendo Dominio, Numero de historias em cada dominio, numero de pontos de historia e a completude. A coisa fica mais ou menos assim:


Retirado do site Feature Driver Development

Pode-se ter uma visão bastante real do estado atual do projeto.

Ambiente Informativo
Apresentado na xpRio, na discussão a respeito de um Ambiente Informativo, Alisson Vale mostrou um modelo muito claro para trabalhar com a equipe:

Acredito que a imagem seja suficientemente auto explicativa.

RTF: Running, Tested Features
Representa a quantidade de requistos estão passando em todos os testes de aceitação. É facilmente gerado utilizando ferramentas automatizadas de teste e Teste de aceitação. Idealmente deve parecer com a imagem abaixo:

Também conhecido como Burn-Up chart. Qualquer anomalia no comportamente desta imagem deve ser encarada como um problema, já que, teoricamente, os requisitos implementados devem passar em todos os testes sempre.
Uma ótima referência para este tipo de teste pode ser encontrado aqui.


Outras medidas

Satisfação do Cliente: Determinada nos encontros entre de definição das iterações, podendo ser feita com um questionário simples de satisfação e representada através de imagens/cores. Medida interessante de ser trabalhada, pois deixa a equipe com o real estado de aceitação que o cliente se encontra.

Code coverage (quantidade de código coberto por testes)

Builds feitos com sucesso (por sprint, por semana, por dia)

Builds não realizados (por sprint, por semana, por dia)




É isso senhores... espero que tenha sido proveitoso.

11 setembro 2007

Anti Padrões de motivação de equipes



Saudações!
Seguindo a linda Anti-Patterns (já escrito sobre Testes), e voltando ao post sobre a diferença entre times e equipes (lembram do video dos malucos do All Black?) vou tratar sobre os padrões de gerência e posturas que uma empresa pode tomar para minar completamente a formação de equipes auto-gerenciáveis.
Mais uma vez, influenciado por Paul Glen, escrevo uma lista:


  • Exclusão do processo de tomada de decisão

  • Inconsistência

  • Monitoramento excessivo

  • Foco na tarefa, e não em objetivos

  • Motivadores externos desalinhados

  • Deadlines artificiais

  • Desinteresse organizacional

  • Equipes sem habilidade


Exclusão do processo de tomada de decisão
Dada a própria característica de nosso trabalho, em que muitas vezes um desenvolvedor possui muito mais conhecimento sobre sua atividade que seu gerente, deixá-lo de lado durante a tomada de decisão é, antes de mais nada, a afirmação de que este profissional é dispensável, e que sua opinião pouco importa no progresso de um projeto.
Por favor entendam, não estou dizendo que numa equipe gigante todos tenham que ter voz ativa na tomada de decisão (e também nao acredito em equipes grandes dentro de um projeto...), mas a equipe técnica ou um representante deve ser consultado quando o assunto forem medidas que impactam diretamente no projeto.
Já passei por essa experiência, e realmente é incômodo não ser ouvido a respeito de decisões que influenciam diretamente em seu trabalho. O sentimento é realmente esse: dispensabilidade. E a reação é clara: tratando-me como um recurso substituível não existe necessidade de cumprimento de metas e prazos ou de comprometimento.

Inconsistência
"Mesmo peso, duas medidas"
Complicadíssimo lidar com situações em atitudes tomadas contradizem comportamente pré-determinados. Como líderes, ou como empresa, uma coisa deve ser clara: tenha corrones de assumir o que for determinado para a equipe, e evite ao máximo contradizer-se, pois assim conseguirá um apoio muito maior de todos.

Monitoramento Excessivo
Isso é claro e já bastante batido: microgerenciamento não é produtivo. Acreditar que manter os olhos sobre os ombros de seus empregados 24horas por dia vai torná-los mais produtivos é um conto de fadas. Além de sempre causar a impressão de que a empresa não confia na equipe, que precisa ser monitorada para que seja produtiva. Um conselho: a procrastinação sempre vence. A equipe vai encontrar um jeito de tornar-se improdutiva, nem que seja fingir estar trabalhando.
Já ouvi discussão na lista xpRio sobre a microgerência executada em scrum/xp/lean, mas é completamente diferente pelo princípio das Equipe Auto Gerenciáveis. Todos são responsáveis pela execução, decisões e controle do projeto. Microgerência do projeto e não das pessoas, esse é o ponto!

Foco na tarefa, não nos objetivos
Acredito que apenas os mais cabeças-duras ainda não entenderam isso. Para aqueles que ainda não entenderam, vai uma lista algumas coisas atuais (outras nem tanto) para estudar:

Se você, como um líder, direciona o desenvolvimento apenas através de tarefas, sem que a equipe tenha conhecimento dos objetivos do projeto, talvez após ler os links acima você acabe entendendo.
É necessário que a equipe tenha a visão de onde se pretende chegar com o projeto. Nisso o Desenvolvimento Ágil dá um salto na tentativa de aproximar a equipe do cliente, criando uma visão e metáforas do projeto.
Tarefas devem ser encaradas como passos para alcançar objetivos. Paul Glen faz uma ótima comparação:
Without any understanding of the goals for a task, geeks start to feel like technology vending machines, dispending solutions on demand. Under these circunstances, they engage in the creative work task with the same exciment as a soft drink vending machine dispensing a drik. It may work, but don´t expect anything more than you ask for, and you may not get anything at all


Motivadores externos desalinhados
Motivação é um assunto complicado, e pretendo tratar melhor em outros posts.
Mas é importante verificar de que maneira a equipe está sendo recompensada por sua produtividade, tomando muito cuidado para que este processo não perturbe a convivência do grupo. Valorizar recompensas individuais em detrimento dos objetivos do grupo é assinar o atestado de problemas internos, já que será criado um sentimento não coeso de disputa entre os membros da equipe, o que é péssimo para o projeto.

Deadlines Artificiais
Tudo precisa ter um fim. O sentimento de completude de uma tarefa deve ser real, para que possamos passar para uma nova etapa do projeto. Assim, de qualquer maneira, a idéia de prazos que não são cumpridos e datas limites que não são respeitadas fazem com que a equipe não se motive para alcançar um objetivo. Não existe nem o desafio de completar uma tarefa, já que caso ela não seja completada, os prazos serão extendidos.
Aqui existe forte influência do Desenvolvimento Ágil e as iterações curtas. Cria-se um microcosmo de uma iteração em que toda a equipe está focada em realizar os objetivos que ela se propôs a atingir. Insconscientemente a equipe estará comprometida pois os prazos não se alteram. "Done is done", segundo Ken Shwaber.

Desinteresse Organizacional
A falta de significado é a maior barreira para a equipe. Isto é, uma empresa que demonstra não ter interesse em um projeto, é o principal motivo para que ele vá de mal a pior.
IMPORTANTÍSSIMO: Nunca subestime o poder de observação de uma equipe. Mesmo não informando a equipe de que o projeto será descontinuado, cancelado ou deixado de lado, é simples de perceber quando um projeto não está mais nas graças da empresa. E pior ainda, não faça com que sua equipe trabalhe em um projeto já cancelado, apenas para deixa-los trabalhando. É a maneira mais fácil de perder todas as pessoas da equipe e eliminar qualquer respeito que a equipe tenha pela empresa ou qualquer outro projeto futuro.

Equipes sem habilidade
Quando um projeto é criado sem que a equipe tenha as capacidades técnicas e gerenciais de alcançar os objetivos é certo seu insucesso.
Um azarão com chance de vitória é excitante; uma derrota garantida não é.

10 setembro 2007

Entre Padrões de Código e a Programação Literária



Dentro da programação, uma coisa é certa: padrões são muito bem vindos. Uma vez que normalmente não estamos sozinhos num projeto, é importante que todos os desenvolvedores possam entender completamente o código produzido por qualquer um da equipe, evitando criar a idéia de propriedade de código para um único programador.
No processo de definição de padrões de desenvolvimento, deve-se levar em consideração os aspectos: Consistência, Estilo e ferramentas de suporte aos padrões.
Não me entendam mal, mas acreditar que sua equipe possue um padrão de código apenas por utilizar convenções de linguagem (ex: Java Code ConventionsM) é ingenuidade pura! (isso mesmo, ingenuidade). Code Conventions definem apenas a forma em que o código será escrito. Entretando devemos ir além, muito além disso.

Consistência
O código produzido utilizando padrões deve ser a marca da equipe e não o código produzido pelo Joãozinho ou a Mariazinha. Deve-se ter o entendimento de que qualquer um dentro da equipe pode ter desenvolvido aquele código, sem que se faça distinção de quem o escreveu.
Uncle Bob escreve muito bem essa definição ao afirmar que "Esta não é a fantasia de igualdade para que se possa sobrepujar a individualidade em detrimento do grupo, é uma necessidade básica". Como todo indivíduo possui seus próprios vícios e fetiches relacionados ao desenvolvimento, imagine 10 programadores trabalhando num mesmo código ao longo do projeto. Conforme o tempo passa, a mistura de padrões e estilos diferentes dentro do código tornará impossível sua leitura.

Estilo
Sim, uma parte importante do processo de desenvolvimento. Muitos podem se perguntar: "Qual a utilidade de definir o número de espaços que o tab representa? Por que determinar a identação correta para todos da equipe??". Falo aqui apenas da forma, não do conteúdo.
E neste ponto é importante diferenciar estilo de consistência pois eles existem para diferentes motivos. E graças a Deus nós temos o Eclipse e a capacidade de exportar um padrão determinado para arquivos xml que serão importados pelos outros desenvolvedores.

Para trasmitir o conhecimento sobre padrões é necessário um ambiente em que a comunicação possa fluir livremente, ferramentas automatizadas são importantes, mas esse conhecimento deve estar na cabeça dos desenvolvedores. Assim, práticas de Pair Programming e Code review podem ser de grande valia. Durante uma sessão de PP, para um programador mais novo, é importante que ele seja apresentado aos padrões existentes para o projeto. De forma oral, e imediata ao que ele estiver produzindo. Esqueça documentação escrita sobre padrões de código, nomes de métodos, etc... Seu código é a documentação! Um exemplo vivo dos padrões determinados em sua aplicação. Explore-o!

Acredito realmente que times devem ousar em adotar os próprios padrões de desenvolvimento, e que devam encorajar outras equipes a fazerem o mesmo. É também uma questão de identidade do grupo.

E a programação literátia?? Pois bem, falemos dela agora.

Bem, definida há quase 30 anos, a Programação Literária diz respeito à promessa de tornar o código fonte de um sistema tão fácil de compreender quanto um livro. Parece impossível? Mas não é...
Talvez seja uma herança dos tempos do Cobol, em que reduzir o nome de um método ao máximo era sinônimo de performance e economia de bytes do programa. Mas já superamos essa fase. Entretanto os problema continuam, e tentamos reduzir o nome dos métodos apenas por preguiça de escrever. Assim, um método simples com o nome: validaSenhaUsuaria() pode tornar-se algo mais complicado de se entender: valPwd(), expressando pouco sobre o significado do método.

Métodos e variáveis devem expressar seu real significado, facilitando e muito a leitura do código. Existem pessoas bastante adiantadas nesse processo, entre elas Martin Fowler, que já trata da questão com o nome: Language-oriented Programming (vale a pena ver a palestra promovida por ele)

Parece besteira, certo? Mas nem tanto. Imagine-se como um programador que, 6 meses depois, é designado a fazer manutenção de um código escrito apenas com abreviações... lhe desejo sorte para compreender o que foi produzido.
Devemos pensar no desenvolvimento como um processo contínuo de garantir a manutenção sadia para os futuros programadores, garantindo que qualquer um possa compreender e trabalhar dentro do sistema, idenpendentemente de quanto tempo atrás ele tenha sido escrito.


É isso...

06 setembro 2007

Os princípios do Manifesto Ágil


Muito já foi falado sobre o Manifesto Ágil(cujos valores estão transcritos abaixo), muitas críticas e muita, muita discussão a favor. Gostaria de acrescentar minha contribuição a toda essa conversa, apresentando uma análise simples feita por David Astels em seu livro: Test Driven Development A Pratical Guide. Seguindo justamente o princípio KISS, Astels conseguiu determinar até onde queremos chegar com iniciativas como CodingDojo, TDD, BDD, StandUp Meetings, dentre outros valores e técnicas.

Para que não esqueçamos nunca:

Agile Manifesto
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Mas será apenas isto? Não existirá algo maior por trás dessas quatro premissas?
Sim! Toda a discussão a respeito do desenvolvimento Ágil pode ser resumida nas linhas que se seguem, excelentemente transcritas no livro do David Astels:


Nossa maior prioridade é satisfazer os clientes através de rápidas e contínuas entregas de software com valor agregado.

Mudanças de requisitos são bem vindas, até mesmo tarde no desenvolvimento. O processo Ágil assume a mudança como parte da vantagem competitiva de seus clientes.

Entregar software funcionando frequentemente, em algumas semanas ou meses, com a preferência ao menor tempo possível.

Homens de negócios e Desenvolvedores devem trabalhar juntos durante todo o projeto.

Construa projetos através de indivíduos motivados. Dê à equipe um ambiente que atenda suas necessidades, e confie em sua capacidade para realizar o trabalho.

A forma mais eficiente e efetiva de circular, criar consenso, uma informação para a equipe de desenvolvimento é através da comunicação cara-a-cara.

Software em funcionamento é a primeira medida de progresso.

O processo Ágil promove o desenvolvimento sustentável. Os clientes, desenvolvedores e usuários devem ser capazes de manter uma paz constante indefinidamente.

Atenção contínua a excelência técnica e bom design inspira Agilidade.

Simplicidade - a arte de maximizar a quantidade de trabalho não feito - é essencial.

As melhores arquiteturas, requisitos e designs surgem a partir de equipes auto-gerenciáveis.

Em intervalos regulares a equipe reflete sobre como tornar-se mais eficiente, então adaptando seu comportamento de acordo.

CppUnit e Borland C++ Builder 6


Bem, como vocês já sabem, estou em uma nova empresa, a Audaces. Em princípio trabalharei com integração contínua, e estou no momento fazendo testes com o ambiente da Borland. É um mundo completamente novo para mim, e estou bastante animado com os resultados! C++!! Segue abaixo um pequeno(e simples) tutorial sobre como iniciar seus testes utilizando Borland C++ Builder 6.

Configuracao de ambiente para testes utilizando o CPPUnit e Borland C++ Builder 6 (BCB6)

Referências:
Requisitos:
Instalação
Será apresentada a utilização do cppUnit para o C Builder através da criação de uma aplicação simples. Seguem os passos para tal:

1. Descompactar CPPUnitBCB6 (Ex: C:\CPPUnitBCB6)

2. Iniciar um projeto novo no BCB (File> New >Application)

2.1 Vincular ao projeto os Headers relativos ao CppUnit.
Faça isso adicionando os diretórios ao projeto em "Project> Options> Directories/Conditionals >Include path"
Selecione os diretórios:

%cppunit_dir%\borland\TestRunner
%cppunit_dir%\test\textui
%cppunit_dir%\test\framework
%cppunit_dir%\test\framework\extensions


2.2 Remover o formulário inicial (Form1) em "Project> Remove from Project...> Unit1.cpp"

3. Adicione ao projeto as bibliotecas do CppUnit (podem ser copiados para o diretório raiz do projeto de exemplo):

%cppunit_dir%\bin\culib.lib
%cppunit_dir%\bin\TestRunnerDlg.lib
%cppunit_dir%\bin\TestRunnerDlg.dll


4. Crie uma classe de testes Simples:

A primeira classe a ser criada será chamada de FirstTest. Iniciaremos por seu Header, que deve extender a classe TestCase. É necessário declarar os métodos setUp() e tearDown() para que o funcionamento ocorra normalmente.

#ifndef FIRST_TEST_H
#define FIRST_TEST_H

#include "TestCase.h"
#include "TestCaller.h"

class FirstTest: public TestCase
{
public:
FirstTest(std::string name);
void setUp();
void tearDown();
static Test *suite();
protected:
void testAssertTrue();
void testAssertFalse();
void testFalhara();
void testAssertMaisUmExemplo();


};

typedef TestCaller FirstTestCaller;
#endif


Abaixo segue a implementação dessa classe. FirstTest.cpp
#include "FirstTest.h"
#include "TestSuite.h"

FirstTest::FirstTest(std::string name): TestCase(name) {
}

void FirstTest::setUp() { }

void FirstTest::tearDown() { }
Test* FirstTest::suite() {
// All tests have to be explicity added to TestSuite to be executed
TestSuite *suite ;
suite = new TestSuite("nameFirstTest");
suite->addTest(new FirstTestCaller("assert True", &FirstTest::testAssertTrue));
suite->addTest(new FirstTestCaller("assert False", &FirstTest::testAssertFalse));
suite->addTest(new FirstTestCaller("teste que falha", &FirstTest::testFalhara));
suite->addTest(new FirstTestCaller("teste equals", &FirstTest::testAssertMaisUmExemplo));
return (suite);
}



void FirstTest::testAssertTrue()
{
assert( true );
}

void FirstTest::testAssertFalse()
{
assert( !false );
}

void FirstTest::testFalhara()
{
assert( false );
}

void FirstTest::testAssertMaisUmExemplo()
{
assertDoublesEqual(0, 0, 0);
}



6. Testando o funcionamento do CppUnit:

O método suite() serve para que se possa adicionar todos os métodos de testes que a classe possui e que devem ser executados. Caso um método nao seja adicionado ao TestSuite neste método, ele não serpa executado.
Edite o código inicial do projeto ("Project> View Source"), adicionando a chamativa ao CppUnit após a compilar a aplicação. Exemplo exemplo.cpp:
#include 
#pragma hdrstop

#include "ITestRunner.h"
#include "FirstTest.h"
//---------------------------------------------------------------------------
WINAPI WinMain(HINSTANCE, HINSTANCE, LPSTR, int)
{
try
{
ITestRunner runner;

runner.addTest(FirstTest::suite());

runner.run();

}
catch (Exception &exception)
{
Application->ShowException(&exception);
}
catch (...)
{
try
{
throw Exception("");
}
catch (Exception &exception)
{
Application->ShowException(&exception);
}
}
return 0;
}



Pressione F9. Uma ferramenta gráfica aparecerá e você terá como visualizar todos os testes escritos na classe FirstTest. Clique em run e divirta-se.
Obs: propositalmente neste tutorial eu inseri um teste que falhará, para que você possa ver o funcionamento da ferramenta...

=)