05/26/2009

TDD – Test-driven development

Posted in programação tagged , às 19:00 por julianamessias

Este post explica resumidamente o funcionamento do TDD, que é uma técnica de desenvolvimento orientado a testes que tem como objetivo antecipar a identificação e correção de falhas durante o desenvolvimento do software. É muito utilizada em eXtreme Programming (XP). TDD utiliza bastante testes unitários, mas não somente eles. Testes unitários são testes estruturados que executam os métodos das classes e verificam os resultados.

Consiste em pequenas iterações onde testes são escritos antes da codificação de uma funcionalidade. O código é escrito com objetivo de fazer o teste passar. Após isso o código é refatorado para acomodar as mudanças.

Segundo Kent Beck, TDD não trata apenas a escrita de testes antes da codificação. TDD pode ser definida como testes antes da codificação + design incremental. O design do software é criado em pequenos passos (baby steps) seguindo o ciclo descrito abaixo.

Scott W. Ambler define TDD como Refactoring + testes antes da codificação.

Ciclo do TDD

Ciclo TDD

  • Escreva um teste e assegure que ele não funcione introduzindo um erro óbvio no código que está sendo testado. Exemplo: o código não compila porque o método que você está testando ainda não existe;
  • Faça o teste funcionar com a implementação mais óbvia possível;
  • Refatore o método que está sendo testado para inserir a implementação desejada e o método de teste para eliminar duplicidades e melhorar a legibilidade;
  • Execute o teste para verificar se tudo continua funcionando.

Benefícios

  • Melhoria do código: os erros são encontrados rapidamente e o código fica mais simples;
  • Melhoria no design: o código evolui com o tempo;
  • Uso de conceitos da orientação a objetos: as classes tendem a ser menos acopladas e mais coesas. A separação do domínio e camada de apresentação é estimulada;
  • Menor stress: provê maior confiança no código e as alterações são mais simples;
  • Prática do refactoring.

Frameworks de Apoio

Para refletir

“Any program feature without an automated test simply doesn’t exist.” Kent Beck

Mais informações em:

05/21/2009

XP – eXtreme Programming

Posted in Processos tagged , , às 19:16 por julianamessias

XP é um processo ágil de desenvolvimento de software destinado a times pequenos e médios. Kent Beck: “XP é uma maneira leve, eficiente, de baixo risco, flexível, previsível, científica e divertida de desenvolver software”.

Valores

  • Comunicação: é muito importante a comunicação entre todos os envolvidos no projeto para um melhor entendimento do mesmo;
  • Simplicidade: fazer sempre a coisa mais simples que pode funcionar (KISS – Keep It Simple);
  • Feedback: as funcionalidades são entregues no menor prazo possível e com isso o cliente pode verificar se o que ele precisa foi realmente implementado;
  • Coragem: ao invés de evitar mudanças de requisitos, os times XP as consideram inevitáveis e procuram se adaptar com segurança e com coragem, isto é, com confiança em seus mecanismos de proteção, como por exemplo, desenvolvimento orientado a testes, programação em par e integração contínua;
  • Respeito: saber ouvir, respeitar e compreender o ponto de visto do outro é essencial para o sucesso de um projeto.

Práticas do XP

  • Processo de planejamento (“Planning Game”): diálogo constante entre pessoas de negócio e técnicas. Pessoas de negócio são responsáveis por decidir escopo, prioridade, datas de lançamento e composição de releases. Já as pessoas técnicas são responsáveis por decidir estimativas, processo de desenvolvimento do produto, técnicas e cronograma detalhado. O XP define dois níveis de planejamento:
    • Planejamento de release: o cliente explica as estórias (user stories) e o time avalia sua dificuldade;
    • Planejamento de iteração: geralmente a duração de uma iteração varia entre uma a três semanas e cada release pode possuir várias iterações, que implementarão um conjunto de estórias. Caso não seja possível implementar todas as estórias em uma iteração, as que faltaram serão implementadas na próxima iteração;
  • Releases curtos: cada release precisa conter os requisitos de negócio mais importantes para o cliente. O release deve fazer sentido como um todo (um requisito não pode ser implementado pela metade). A entrega das releases é importante no processo de aceitação por parte do cliente, que pode testar a parte do software que está comprando;
  • Metáfora: é uma forma de auxiliar clientes e desenvolvedores a compreender melhor o objetivo do software a ser criado. Ao criar comparações e analogias com o domínio em questão o time passa criar um vocabulário comum, que passa a ser usado para modelar o sistema e definir sua arquitetura;
  • Projeto (design) simples: é importante criar design simples capazes de acolher a mudanças nos requisitos. Somente a funcionalidade que foi solicitada deve ser implementada. Não confundir simples com fácil;
  • Testes: podem ser de diversos tipos: de aceitação, funcionalidade, integração e TDD (test-driven development – testes de unidade automatizados são criados antes da codificação de uma funcionalidade);
  • Refactoring: é uma prática criada por Martin Fowler que tem como objetivo melhorar o design e a arquitetura do código já existente. O XP prega o refactoring constante. Pode ser utilizado em códigos duplicados e métodos longos;
  • On-Site Customer: o cliente deve sempre estar presente auxiliando o time;
  • Programação em pares: todo o design e código é produzido sempre por duas pessoas agindo como um par. Os pares não são fixos, cada membro da equipe irá trabalhar com todos os membros pelo menos uma vez durante o projeto;
  • Propriedade coletiva do código: todos os desenvolvedores do time podem modificar o código, ele é de propriedade do time. Dessa forma todo o time se familiariza com o código.
  • Integração Contínua: é recomendado que no máximo até o final de cada dia todo código produzido seja integrado e testado.
  • Semana de 40 horas: tempo extra é sintoma de problemas. O XP sugere que o tempo extra não deve passar de uma semana seguida. Se problemas graves são descobertos, a iteração ou release devem ser planejados novamente;
  • Padrões de codificação: cada time deve possuir padrões de codificação que deverão adotados por todos.

Direitos do Cliente

  • Definir planos para saber o que será realizado, quando e a que custo;
  • Alcançar o máximo desempenho dos desenvolvedores;
  • Possuir ambientes de testes para monitorar o andamento do desenvolvimento;
  • Possibilidade de mudar de idéias, substituir funcionalidades;
  • Ser informado sobre mudanças de cronograma em tempo de escolher como reduzir o escopo para restaurar a data original;
  • Cancelar a qualquer tempo o projeto e obter o software funcionando refletindo o investimento realizado até o momento.

Direitos do Desenvolvedor

  • Saber o que é necessário, com claras declarações de prioridade;
  • Produzir trabalho de qualidade o tempo todo;
  • Pedir e receber ajuda de seus pares, superiores e clientes;
  • Fazer e atualizar suas próprias estimativas;
  • Aceitar as suas responsabilidades, ao invés de tê-las impostas a você de cima para baixo.

Problemas de desenvolvimento X Práticas do XP

Problemas Desenvolvimento X XP

05/14/2009

Scrum Gathering Brazil 2009 – Resumo

Posted in eventos, Scrum tagged , às 17:44 por julianamessias

O Scrum Gathering Brazil foi muito interessante e bem organizado. O investimento valeu muito a pena! 🙂 Segue abaixo um resuminho do que aconteceu no evento.

Cracha

Primeiro dia

A primeira palestra que assisti foi do Ricardo Vargas (Project Management as a Strategic Competency), representante do PMI. Foi importante saber que o PMI está interessado nas práticas ágeis.

Em seguida vi a do José Papo, meu professor da pós graduação: Contratos e Scrum: The Good, the Bad and the Ugly. Ele comentou sobre os tipos de contratos (preço fixo, escopo variável e aquisição progressiva). Em uma das aulas da pós ele também abordou esse tema.

José Papo 3

José Papo

Ken Schwaber infelizmente não compareceu no evento, fez uma apresentação virtual.

Ken Schwaber 1Ken Schwaber

No início falou sobre o Manifesto Ágil e sobre a importância dos itens da esquerda em relação aos da direito do Manifesto. Comentou que as empresas estão utilizando mais Agile do que Waterfall e o número de CSM (Certified Scrum Masters) aumentou de 2006 para cá, passando de 8000 para 54000. Ele pediu para efetuarmos um exercício dado em treinamentos de CSM (comando controle em que precisamos andar pela sala). Organizamos-nos em pares sendo um o trabalhador e outro o chefe. O chefe foi responsável por dar direções simples: ande, pare, vire a direita, vire a esquerda, corra e ande devagar até o trabalhador dar uma quantidade determinada de passos. Na segunda parte do exercício ele pediu para trabalharmos sozinhos. O objetivo desse exercício foi mostrar que é mais divertido trabalhar de forma auto-gerenciável.

Foi anunciada uma nova certificação: Certified Scrum Developer. É destinada para times e baseada em .NET e Visual Studio Team System. Muitos questionaram a idéia de uma certificação voltada a uma ferramenta específica.

O Guilherme Chapiewski não pode comparecer ao evento por problemas de saúde. Foi uma pena porque faz tempo que acompanho o blog dele e gostaria muito de assistir sua palestra. Para substituí-lo o Rodrigo Yoshima apresentou “Scrum para desenvolvimento interno e produtos de software”.

Rodrigo Yoshima 8

Rodrigo Yoshima

Ele falou sobre as dificuldades e facilidades de implentar Scrum em 3 tipos de ambientes: outsourcing (fábricas de software), desenvolvimento interno e ISVs (empresas de produtos).

Um dos pontos interessantes na palestra foi a citação do Ken Schwaber: “Scrum é tua sogra”. O scrum sempre deixa os problemas visíveis e não os resolve. O sucesso do projeto está na maneira que você vai resolver o problema.

Eu

Nessa palestra foi comentado sobre o papel do Product Owner (“desgraçado ganancioso“). Este termo foi discutido no blog do Rodrigo e gostei da abordagem.  O Product Owner precisa que o software seja entregue de maneira rápida e econômica e não pode tomar as dores do time. Ele deve se preocupar com o retorno do investimento (ROI).

O Keynote do Danilo Bardusco (os desafios de escalar Scrum) mostrou como a Globo.com utiliza o Scrum.

Adorei conversar com umas pessoas que trabalham na OnCast, aproveitei a oportunidade para tirar muitas dúvidas sobre Scrum. 🙂 A palestra deles foi sobre Co-sourcing em ambiente no-Agile.

OnCast

Samuel Crescêncio, Rodrigo Machado e Adriano Campestrini

Segundo dia

Cristian Couto e Manoel Pimentel falaram sobre Como fazer Scrum acontecer em ambientes corporativos. Eles trabalham no banco Bancoob em Brasília e comentaram como foi a implantação do Scrum dentro da corporação e deram várias dicas.

Fabiano Milani falou sobre Como apresentar Scrum para o cliente. Ele fez a analogia sobre o projeto de uma viagem e fábrica de automóvel. Em uma viagem ocorrem imprevistos e o percurso pode mudar. Já em uma fábrica de automóvel dado uma especificação o carro é construído. Deixou claro que documentos servem para auxiliar a comunicação e não para substituí-la. A reunião diária (scrum daily meeting) serve para a visibilidade e comunicação, não como um relatório de status.

Renato Willi e Alexandre Gomes apresentaram A agilidade está no ar – Experiências implantando e usando métodos ágeis em projetos da FAB (Força Aérea Brasileira). As experiências deles são muito interessantes, principalmente pelo desafio de lidar com culturas diferentes como a do exército e aeronáutica. Uma história que não irei me esquecer foi quando eles comentaram sobre um integrante do time que pediu autorização para participar de um evento e tiveram problemas com o cliente (FAB).

Após o último coffee break tive a oportunidade de assistir a um mini curso ministrado pela Katia da VersionOne sobre a ferramenta de gerenciamento de projetos ágil: V1 – Agile Enterprise. A ferramenta é bem completa e uma versão trial pode ser experimentada.

No final do evento Jim Cundiff, diretor da Scrum Alliance, vestiu uma camiseta da seleção brasileira de futebol e tirou fotos conosco.

Samuel Crescêncio, Rodrigo Machado e Adriano Campestrini

05/11/2009

Uncle Bob – RailsConf

Posted in eventos, programação tagged às 17:23 por julianamessias

Programadores de plantão, vejam o trecho da palestra do Uncle Bob (Robert Martin) no evento RailsConf. O Fabio Akita gravou essa declaração destinada aos programadores brasileiros.

Fonte: Uncle Bob Martin na RailsConf 2009 from Fabio Akita.

05/05/2009

Processos Ágeis – Scrum

Posted in Processos, Scrum tagged , , às 18:00 por julianamessias

Para começar a discutir sobre processos ágeis é importante ler o manifesto ágil disponível em Agile Manifesto:

Nós estamos descobrindo melhores maneiras de desenvolver software, criando-os e ajudando outros a criá-los. Através deste trabalho passamos a valorizar:

  • Indivíduos e interações sobre processos e ferramentas.
  • Software funcionando sobre documentação extensa.
  • Colaboração do cliente sobre negociação contratual.
  • Responder a mudanças sobre seguir um plano.
  • Assim, enquanto há valor nos itens à direita, nós damos mais valor aos itens à esquerda

    Os autores do manifesto são: Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick,    Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland e Dave Thomas.

    O manifesto ágil cita doze princípios ágeis. São eles:

    1. A principal prioridade é satisfazer o cliente através de entregas contínuas e rápidas de software de valor;
    2. Abrace mudanças de requisitos, mesmo quando tarde no ciclo. Processos ágeis alavancam as mudanças para gerar vantagem competitiva;
    3. Entregue software funcionando freqüentemente, com preferência de curto prazo;
    4. Pessoas de negócio e desenvolvedores devem trabalhar em conjunto diariamente no projeto;
    5. Faça projetos em torno de indivíduos motivados. Dê a eles o ambiente e suporte que necessitam, e confie que eles darão o trabalho bem feito;
    6. A melhor forma de transmitir informações no time é através de conversas face a face;
    7. Software funcionando é a medição principal de progresso;
    8. Processos ágeis promovem desenvolvimento sustentável;
    9. Atenção contínua a excelência técnica e ao design aumenta a agilidade;
    10. Simplicidade é essencial;
    11. As melhores arquiteturas, designs e requisitos emergem de times auto-organizados.
    12. Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e ajusta seu comportamento de forma apropriada.

    Exemplos de processos ágeis são: Scrum, XP (eXtreme Programming), FDD (Feature Driven Development), Crystal Clear, entre outros. Este e os próximos posts abordarão o Scrum.

    Scrum é um framework de gestão de projetos criado na década de 90 com foco em como organizar uma equipe de projeto. Contempla conceitos do processo Lean, desenvolvimento iterativo e estudo dos japoneses Hirotaka Takeuchi e Ikujiro Nonaka. Os principais criadores são Ken Schwaber e Jeff Sutherland. A seguir serão mostrados os principais conceitos do Scrum. Cada ciclo do Scrum tem duração de 30 dias.

    Papéis

    Product Owner: é responsável pela visão de negócios do projeto, definição e priorização do Product Backlog. Geralmente é o papel desempenhado pelo cliente e analista de requisitos.

    Scrum Master: é responsável por remover obstáculos do time e assegurar que as práticas do Scrum estão sendo executadas corretamente. Deve dar suporte à equipe, é um facilitador e líder.

    É importante destacar que não existe gerente de projeto no Scrum. O papel que mais se assemelha ao gerente de projetos é o Scrum Master. Ele não é responsável por designar tarefas aos desenvolvedores, sua atuação é ser um mediador e facilitador.

    Time: é responsável pela entrega de soluções, composto por desenvolvedores de software, analistas de teste, designers, entre outros. Trabalha de forma auto-gerenciada.

    Product Backlog

    É uma lista priorizada de requisitos/estórias que devem ser implementados. Henrik Kniberg sugere os seguintes campos para uma estória:

    • ID: uma única identificação, apenas um número com auto incremento;
    • Nome: um nome curto e descritivo para a estória.. Normalmente de 2 a 10 palavras;
    • Importância: a pontuação de importância dessa estória para o Product Owner sendo que quanto maior forem os pontos, mais importante é a estória;
    • Estimativa inicial: as estimativas iniciais do time sobre quanto tempo é necessário para implementar uma determinada estória, se comparada a outras estórias. A unidade é pontos por estória e geralmente corresponde mais ou menos a “relação homem/dias” ideal;
    • Como demonstrar: uma descrição em alto nível de como a estória será demonstrada na apresentação do sprint. Isso é simplesmente uma simples especificação de teste. “Faça isso, então faça aquilo e então isso deverá acontecer.”;
    • Notas: quaisquer outras informações, esclarecimentos e referências a outras.

    a

    Sprint

    Representa a iteração.

    Sprint Backlog

    Refere-se aos itens do Product Backlog escolhidos pelo time para serem implementados a cada Sprint (iteração). O Sprint Backlog é dividido em tarefas pequenas (Backlog tasks).

    2

    Sprint Planning Meeting

    É uma reunião em que são definidos os itens do Product Backlog que serão implementados na próxima iteração.

    • Sprint Planning 1

    Os objetivos (metas) devem ser definidos e o Product Backlog, as estimativas e prioridades são atualizados. A participação do cliente é importante, pois ele deve escolher os itens de Backlog que farão parte do Sprint.

    • Sprint Planning 2

    Essa reunião pode ocorrer no mesmo dia que a reunião do Sprint Planning 1, porém o cliente não deve participar. O foco é a quebra do Product Backlog em tarefas pelo time do projeto. Devem ser definidas todas as tarefas necessárias, como por exemplo, codificação, testes, revisões de código, etc..

    É recomendado que a duração da tarefa seja de um dia. Isso é importante para evitar a síndrome do estudante. Geralmente a duração dessa reunião é de 4 horas. Para a representação das tarefas são utilizados post-its, conforme mostrado na figura abaixo.

    3

    Sprint Review

    O resultado do Sprint é mostrado para o cliente e usuários após o ciclo de 30 dias. É uma demonstração do projeto em que obrigatoriamente o cliente deve estar presente para validar o que foi feito até o momento. Geralmente nesta reunião de 2 horas os requisitos são modificados (incluídos, alterados ou removidos).

    Daily Scrum

    É uma reunião diária com duração de 15 minutos na qual todos os participantes do projeto devem ficar em pé e responder as seguintes perguntas:

    1. O que eu fiz desde o último Daily Scrum?
    2. O que eu vou fazer hoje?
    3. Existe algum impedimento/problema que me impeça de fazer o meu trabalho?

    Backlog de Impedimentos

    São listados os problemas (impedimentos) enfrentados pelo time. Esta listagem é obtida no Daily Scrum.

    Scrum Estimation Meeting

    É uma reunião que demora entre 4 a 8 horas. Este tempo varia de acordo com o tamanho do projeto. Para esta reunião os principais requisitos devem ter sido descobertos. Tem como objetivo estimar todo o Product Backlog de um release (ou mais de um). Para cada item no backlog:

    • O Product Owner explica a estória por trás do item;
    • O time joga o Planning Poker (esta técnica sera abordada em um outro momento);
    • A estimativa é adicionada ao Backlog

    Scrum of Scrums

    Representa uma reunião realizada entre Scrum Masters.

    Exemplo: o time do projeto é grande e é inviável realizar reuniões diárias com todo o time. O arquiteto divide o projeto em partes, como por exemplo, em componentes e camadas. Para cada subprojeto é alocado um Scrum Master e time. Existe um Scrum Master “top” responsável por todos os times. Cada time realiza as reuniões diárias e uma segunda reunião (Scrum of Scrums) é realizada com o Scrum Master “top” e os Scrum Masters de cada time.

    Retrospective

    Nesta reunião deve ser discutido aquilo que deu certo no Sprint e o que pode ser melhorado para os próximos. Devem-se verificar quem está no controle das melhorias detectadas: o time ou a organização. Ocorre a separação em melhoria interna (o próprio time pode resolver) e melhoria externa (o Scrum Master deve resolver).

    A figura abaixo mostra o fluxo do Scrum.

    4

    O Product Owner revela os detalhes do negócio e os requisitos são priorizados e inseridos no Product Backlog. O resultado da reunião Sprint Planning 1 é a listagem dos itens do Product Backlog que serão implementados no próximo Sprint. No Sprint Planning 2 são definidas as tarefas a serem executadas e o Sprint Backlog é criado. O time deve desenvolver (codificar) os itens escolhidos do Product Backlog. Essas novas funcionalidades devem ser mostradas ao cliente e a reunião de retrospectiva deve ser realizada.

    04/30/2009

    Brazil Scrum Gathering 2009

    Posted in Scrum tagged , às 13:00 por julianamessias

    Scrum gathering

    A Scrum Alliance realizará o evento “Brazil Scrum Gathering 2009” em São Paulo nos dias 12 e 13 de maio no Grand Hyatt Hotel.

    O objetivo deste evento é discutir as melhores práticas de desenvolvimento ágil com Scrum. Contará com palestrantes reconhecidos no mundo ágil, como por exemplo, Ken Schwaber (um dos criadores do Scrum) e Boris Glober (o primeiro Scrum Master treinado pelo Ken Schwaber).

    Para maiores informações visite o site do evento.

    01/08/2009

    Apresentação

    Posted in diversos às 17:15 por julianamessias

    Ingressei no mundo virtual aos doze anos de idade. Desde então criei blogs, flogs e sites sobre assuntos que me interessavam no momento, como por exemplo, música e futebol (corinthians).

    Ultimamente acompanho alguns blogs da área de informática, principalmente os sobre desenvolvimento de software. Com estes blogs estou aprendendo bastante e conhecendo os pensamentos de pessoas muito interessantes. Isso me motivou a criar este blog.

    Sou graduada em ciência da computação e pós graduanda em engenharia de software. Pretendo abordar todas as áreas da engenharia de software, em especial arquitetura de software que estou estudando para o meu TCC.

    Fiquem a vontade para me enviar críticas e sugestões.