Image Image Image Image Image
Scroll to Top

Topo

agile

10

abr
2012

Sem Comentários

Em Agile
Blog

Por Allison

Precisamos de uma metodologia mais ágil

Em 10, abr 2012 | Sem Comentários | Em Agile, Blog | Por Allison

Fonte: Fabio Camera/IMasters


Desde o princípio, em qualquer relação humana, o indivíduo organizado serve de exemplo, estimula e ensina ao indivíduo menos organizado. É assim com as crianças em relação aos adultos. É assim nas corporações quando inicia um novo funcionário inexperiente. Quem está aberto para crescer sempre busca aprender um método mais eficiente com alguém qualificado.

Dessa afirmação já se justifica a utilidade funcional de uma metodologia. De forma simplista, podemos traduzir metodologia como uma proposta particular de organização de métodos úteis e funcionais a mais de um indivíduo para uma determinada situação.

Nesse contexto, qualquer metodologia é perfeita. Se já funcionou para uma situação específica, depois foi documentada e agora pode ser utilizada por mais pessoas – é uma metodologia perfeita. É uma experiência similar ao princípio do método científico em sua finalidade.

Porém, muitas corporações, muitas equipes falham em atingir resultados satisfatórios com a utilização de uma metodologia. Onde está o problema? Nas pessoas? Na corporação? Na cultura? Muitas iniciativas frustradas têm uma explicação muito simples para o insucesso: quando não se tem a menor ideia daquilo que se está procurando, fica difícil encontrar.

Por que precisamos de um método ágil?

Recentemente, abordei esse assunto com um competente gestor de projetos que veio trabalhar em nossa empresa. Eu sabia que ele havia implantado na empresa anterior e eu precisava descobrir a motivação e os problemas para os quais ele buscava soluções.

Ele citou que o maior problema é que todos faziam a mesma coisa todos os dias, e o problema se tornava maior, ao invés de diminuir. Imagine uma rotina diária: cansativa – aquela ferramenta, aquela linguagem para o mesmo sistema, quase sempre entediante, certamente monótona pela ausência de oportunidades. O mesmo trabalho, as mesmas pessoas, e o que era antes uma vocação tornou-se somente um trabalho como outro qualquer.

Antes de tentar um método ágil, esse gestor acreditava que o problema estava no controle – ou melhor – na falta de controle. Com isso, aumentava a “pressão” por resultados no time, de vez em quando aumentava o time, frequentemente aumentava a quantidade de horas de trabalho diária, entretanto os resultados não se mostravam muito diferentes do que já eram.

Eu o questionei a respeito desta compreensão: se ele entendia que precisava fazer algo diferente, se esperava por resultados diferentes, por que havia resistência à proposta da metodologia ágil?

Resposta do gestor:

Nas iniciativas de implantação de Agile que presenciei ou das quais participei, a maior resistência era o medo de “perder o controle” sobre a qualidade do resultado do projeto. De alguma forma, alguns envolvidos acreditavam que o uso de metodologias ágeis resulta em um produto de baixa qualidade ou que não atende às expectativas.

Por fim, essa falsa crença foi justamente um dos motivadores para encarar o desafio na empresa que implantei. Ter a oportunidade de mostrar que o resultado seria justamente o oposto fazia o esforço mais compensador.

Ao analisar um ambiente que adotou uma metodologia ágil, após longos períodos de utilização de uma metodologia convencional, é possível observar diversos ganhos, dentre os quais destaco:

  • Maior produtividade: Entregar mais em menos tempo. Evitar desperdiçar o tempo com o que não é importante. Em ambientes mais engessados, perdemos muito tempo com um processo burocrático e por vezes ineficiente;
  • Entregas constantes: Proporcionar feedback de todos, dos clientes, dos usuários, dos contratantes e etc., com frequência;
  • Mais qualidade: Menor número de retrabalho e defeitos. Código com melhor “manutenibilidade” e escalabilidade;
  • Maior envolvimento do time: As reuniões diárias e as outras interações sugeridas pela metodologia ágil fizeram o time funcionar como time. Todos se conheciam, sabiam aonde podiam chegar.

Fazendo o mesmo comparativo com um ambiente que antes não seguia metodologia alguma, os ganhos também são expressivos: maior visibilidade, melhor comunicação e enorme incremento de qualidade.

Dessa forma, encontrei a resposta para a minha intenção com esse gestor. Com essas informações, concluí que sem novidade de meios (ferramenta ou linguagem), somente ordenando de uma forma diferente o “como” você faz diariamente, somente utilizando uma técnica diversa ao seu cotidiano, possivelmente podemos alcançar um fim novo.

O hábito que o sujeito carrega dentro de si para o trabalho, com o tempo, torna-se o seu maior algoz, o seu maior limitante. Impede-o de verificar novas opções, alternativas diversas. Implantar mais controle para mudar os resultados é automatizar um ser humano. É como se transformássemos um desenvolvedor em um robô. E como se medíssemos um programador como um atleta, buscando fazer cada vez mais rápido a mesma coisa.

A proposta de uma metodologia deve melhorar a comunicação, a interação entre os partícipes, a sinergia entre expectativas e os resultados. Afinal, processos fabris no universo da informática não deveriam ser “uma linha de montagem” em que pessoas ficam isoladas em suas mesas e computadores conectadas à internet, e ao mesmo tempo desconectadas com o projeto.

Infelizmente, nossos desenvolvedores são formados à margem dessa proposta de comunicação e interação. Um desenvolvedor nunca é estimulado a ser comunicativo ou a trabalhar em equipe de verdade. Na escola superior de ciência da computação, recebe uma educação matemática robótica que o estimula a se tornar um introspectivo cientista lógico.

O que esperar de uma metodologia ágil?

Um critério, válido, que podemos utilizar para definir se uma metodologia nos ajuda ou nos atrapalha em nosso dia-a-dia é a visibilidade que os problemas alcançam. Se somente o time do trabalho sabe/soube dos problemas e para os clientes ficou imperceptível, certamente a metodologia usada está sendo funcional.

Outro critério é a versatilidade das técnicas. Se há baixa aderência com a cultura existente e não há espaço para adaptações, a imposição da disciplina rígida nos proporcionará resultados comportamentais indesejados, como a resistência a mudanças pelas pessoas. O segredo nesse ponto é nunca perder de vista a razão de ser do trabalho, da empresa e de sua cultura. A metodologia deve propor técnicas para incrementar isso, não trazer razões contrárias. Numa metodologia inflexível, com restrições em excesso, você para de pensar no que pode fazer para se preocupar com o que não pode fazer. Se há uma imposição de seguir tudo o que está em manuais para o seu projeto, muita coisa escapará do que está escrito e ninguém saberá o que fazer.

Mais um critério que considero muito válido é o da análise do resultado. Os métodos sugeridos pela proposta metodológica devem trazer uma compreensão real sobre a capacidade de realizar e a capacidade de coordenar um grupo a um único escopo. É conduzir um projeto através de técnicas que não permitam dúvidas sobre o valor, o mérito e a expectativa de sucesso. No fim, sucesso é uma convenção social do grupo que definiu o escopo. O que é inicialmente pensado como sucesso para o time pode não ser sucesso para os contratantes ou para os clientes. A metodologia ágil ensina técnicas para se obter o critério de sucesso de um projeto.

Para não alongar demais com sugestões de critérios, concluindo de forma mais generalista, entretanto muito completa, podemos nos utilizar dos valores do Manifesto Ágil. Ele foi escrito por Kent Beck, James Grenning, Robert C. Martin, Mike Beedle, Jim Highsmith, Steve Mellor, Arie Van Bennekun, Andrew Hunt, Ken Schwaber, Alistair Cockburn, Ron Jeffries, Jeff Sutherland, Ward Cunninghan, John Kern, Dave Thomas, Martin Fowler e Brian Marick

O Manifesto Agil contém quatro valores fundamentais:

  • Os indivíduos e as suas interações acima de procedimentos e ferramentas;
  • O funcionamento do software acima de documentação abrangente;
  • A colaboração dos clientes acima da negociação de contratos;
  • A capacidade de resposta a mudanças acima de um plano pré-estabelecido.

Referência Bibliográfica:

  • MENEGHETTI, A. A Psicologia do Líder. 4ª. Edição. Recanto Maestro, RS: Ontopsicologica Editrice, 2008.
  • MENEGHETTI, A. Sistema e Personalidade. 3ª. Edição. Recanto Maestro, RS: Ontopsicologica Editrice, 2004
  • HEWARD, L. Cirque Du Soleil – A Reinvenção do Espetáculo. 8ª. Edição. São Paulo, SP: Elsevier Editora, 2006
  • ANDERSON, D. Agile Management for Software Engineering. 2ª. Edição. New York, NY: Prentice Hall Editora, 2004

Tags | , , ,

16

fev
2012

Sem Comentários

Em Agile
Blog

Por Allison

Gerentes em Agile: Nocivos ou apenas despreparados?

Em 16, fev 2012 | Sem Comentários | Em Agile, Blog | Por Allison

Fonte: Rafael Buzon

Segundo Joe Little, muitos da comunidade ágil acreditam que os gerentes são nocivos às equipes, mas o problema, ele defende, está mais no despreparo:

É fato que há muitos gerentes que não gerenciam bem… Mas acredito que a principal razão para isso é que não foram bem treinados. Ou ninguém os ensinou, ou foram ensinados de forma errada, ou mesmo aprenderam errado.

Dave McNulla, em comentário no post de Little, reforça o argumento do despreparo dos gerentes para o Agile, sugerindo que este desconforto da comunidade venha da maneira desconexa com que os gerentes tomam decisões no dia a dia:

Decisões gerenciais geralmente não levam em conta o ambiente ágil, pois muitos gerentes não fazem ideia do que seja Agile.

McNulla afirma ainda que muitos gerentes nem sequer conhecem o Manifesto Ágil ou os princípios que norteiam as práticas ágeis, e acrescenta:

Enquanto os gerentes não pararem de pensar no Agile somente como uma técnica, este cenário não mudará.

Joe Little contesta também o sentimento equivocado, tanto dos próprios gerentes, quanto de seus subordinados, de que ninguém deve corrigir os gerentes. Entretanto, ele destaca que a hierarquia e o poder não contribuem tanto em uma indústria de profissionais que trabalham com conhecimento e criatividade.

Para os desenvolvedores, segundo comentário deixado por Sannette Coetzze, muitas vezes o gerente é visto como um impedimento e em outros casos o gerente não se envolve com o trabalho das equipes:

Alguns gerentes não querem “sujar as mãos” ou se comprometer com a equipe e com o produto. Um bom gerente tem que liderar e possuir energia e entusiasmo ao conduzir a equipe.

Sobre a relação entre liderança e gerenciamento, Little cita outra impressão da comunidade ágil: a de que líderes são necessários, mas não gerentes. Mas ele reafirma que os gerentes também são importantes, dentro de um novo contexto:

Estamos em meio a uma mudança na cultura de gerenciamento em todo o mundo. Este será um longo diálogo e há muitas dimensões a serem discutidas. Precisamos argumentar sobre como gerenciar melhor.

Esta discussão ainda será longa, como finaliza Little, pois o modo como gerenciamos hoje ainda está enraizado em antigos conceitos que precisam ser revistos – principalmente dentro do contexto ágil e da indústria do conhecimento.

Tags | , , ,

09

jan
2012

Sem Comentários

Em Agile
Blog

Por Allison

Agile das equipes à organização: o papel do gerente, estratégias e dicas para a adoção

Em 09, jan 2012 | Sem Comentários | Em Agile, Blog | Por Allison

Para os gerentes de projetos de TI seguindo a linha tradicional, não resta muito tempo até que ouçam algo como “Lembra-se daquele projeto? Decidimos usar nele método ágeis”, e na semana seguinte chegar à empresa uma consultoria em Agile e começar a explicar Scrum, XP, User Stories, Sprints, TDD e uma série de outras técnicas e conceitos. Enquanto isso, o gerente provavelmente irá começar a revirar a internet tentando entender o que fazer, e pode se surpreender ao descobrir que gerentes de projetos aparentemente não são indispensáveis nessas metodologias.

Tenho presenciado muitos gerentes nesta situação, alguns chegando a temer seriamente os métodos ágeis. Por isso a inspiração de escrever um artigo que apresente o Agile para os gerentes de projetos que estão usando práticas mais tradicionais.

Benefícios das metodologias ágeis

Metodologias ágeis, nunca é demais lembrar, são um conjunto de práticas baseados em princípios e valores descritos no Manifesto Ágil. Em 2001 um grupo de experientes líderes de TI, insatisfeitos com o gerenciamento tradicional de projetos de software, reuniu-se e compartilhou novas maneiras para se fazer bom software. Entre as várias metodologias consideradas ágeis, o Scrum e o Extreme Programming (XP) são as mais utilizadas.

O Agile pode resolver alguns dos principais problemas encontrados por um gerente de projetos e trazer diversas vantagens; por exemplo:

  • Identificar, com facilidade e clareza, as funcionalidades do software sendo construído e o que ainda falta fazer;
  • Mostrar de forma efetiva os resultados e o progresso real do projeto;
  • Entregar versões funcionais do sistema, ao invés de somente anunciar atrasos e problemas;
  • Lançar o software antes da data final e mostrar aos usuários que podem contar com novas funcionalidades poucas semanas após a requisição, ao invés de meses ou até anos depois.

O objetivo das metodologias ágeis, portanto, é simples mas ao mesmo tempo desafiador: satisfazer o cliente por meio de entregas contínuas e antecipadas de software, com valor agregado. Entre os benefícios podemos citar:

  • Disponibilizar uma nova versão do software regularmente, a cada duas ou quatro semanas;
  • Poder lidar com pedidos de mudanças e replanejar o projeto em poucas horas;
  • Descobrir os principais riscos e problemas de integração durante as primeiras semanas do projeto, enquanto ainda há tempo de lidar com eles;
  • Visualizar o progresso e o resultado efetivo do projeto a partir de versões intermediárias do software;
  • Manter um alto comprometimento da equipe de TI durante todo o projeto;
  • Conseguir um maior grau de satisfação e de comprometimento da equipe do projeto em sua execução;
  • Reduzir a necessidade de microgerenciamento das atividades.

Para potencializar esses benefícios, é preciso uma grande mudança na forma de pensar e de agir, por parte de todos os envolvidos no projeto e na organização.

O escopo do projeto vai mudar

Tradicionalmente, para garantir um bom projeto o gerente gasta muito tempo reunindo todos os possíveis requisitos que os usuários possam ter em suas mentes. Com o intuito de evitar surpresas, é feito um grande esforço para se construir o plano perfeito. O trabalho é planejado para que tudo possa ser controlado rigorosamente, sem mudanças.

Mas isso quase sempre é impossível. No entanto, este tipo de pensamento tem se tornado comum em grandes empresas, onde planejar, especialmente em conjunto com outras equipes e áreas, é algo muito difícil.

Em um projeto ágil, por outro lado, podemos:

  • Lançar o software regularmente e em datas marcadas (pelo menos em um ambiente de testes), para que os usuários possam verificar rapidamente o trabalho realizado;
  • Permitir aos usuários finais que solicitem mudanças e novas funcionalidades, desde que deixem as menos importantes para depois;
  • Disponibilizar versões intermediárias com frequência, para que os usuários possam utilizar antecipadamente as primeiras funcionalidades do sistema.

Além disso, surpresas são bem-vindas, pois podem criar ideias e favorecer a inovação.

Em projetos ágeis, para controlar o projeto e comunicar o progresso, são contabilizadas as funcionalidades implementadas e não a porcentagem de realização das tarefas, o que é muito mais fácil de entender. Em um projeto tradicional o gerente de projetos diria algo como, “consumimos 45% do orçamento e estamos duas semanas atrasados”. Em um projeto ágil, poderia dizer: “com 45% do orçamento temos hoje uma aplicação capaz de executar estas 12 funcionalidades das 20 previstas”.


A adoção de uma metodologia ágil é um verdadeiro projeto de mudanças

Os métodos ágeis, entretanto, podem ser difíceis de implementar em grandes empresas. Normalmente a gestão de TI acredita que os métodos ágeis dizem respeito apenas aos desenvolvedores e à equipe técnica. Isto é um grande erro, pois elas também envolvem as equipes de gestão e de negócios.

O uso de práticas ágeis apenas no âmbito dos desenvolvedores não vai necessariamente reduzir os prazos globais dos projetos. Os ganhos de produtividade podem ser desperdiçados por outras equipes em outras funções. Se as atividades de testes de integração, por exemplo, durarem muito tempo, os desenvolvedores terão que fazer vários merges das diferentes versões de testes realizadas.

Em muitos casos, o primeiro projeto na adoção de uma metodologia ágil falha devido à falta de envolvimento do patrocinador, à falta de capacitação e treinamento, ou a uma má atuação de alguns “falsas consultorias” em Agile. (Existem consultores que simplesmente rotulam suas ofertas de serviços com a palavra “ágil” sem ter o conhecimento apropriado.)

Negociação do escopo

A negociação de um contrato em Agile é talvez o ponto mais complexo na adoção de práticas ágeis em uma empresa. Isso porque em Agile as mudanças no escopo são bem vindas e constantes. Mas os gerentes de projetos têm muitas dúvidas e resistência ao trabalhar com um escopo variável, principalmente quando não existe uma relação de confiança com o fornecedor.

Há no entanto novos modelos de contratos que procuram criar uma relação de confiança. Entre os pontos abordados nesses contratos, podem estar a definição de escopo fechado por iteração; medidas precisas para controlar a qualidade das entregas; e a possibilidade de o cliente cancelar o projeto ao final de qualquer iteração, sem multas ou penalidades.

A adoção de uma metodologia ágil é na verdade um “projeto de gestão de mudanças”, que requer um forte comprometimento dos patrocinadores e gestores. Esse processo de mudanças pode ser feito gradualmente, implementando-se primeiro as práticas ágeis para desenvolvimento de software, e depois seguindo com práticas mais avançadas e focadas em planejamento, organização e gestão.

O papel do gerente de projetos

O gerente de projetos ganha novas atribuições em um contexto ágil, pois a filosofia do time e os novos papéis exigem uma nova postura e uma nova forma de lidar com as atividades do dia a dia.

Para ganhar em rapidez, as metodologias ágeis dão grande importância à equipe de projetos e à forma como ela pode colaborar de modo eficiente para a resposta às mudanças. Busca-se desenvolver equipes autônomas, capazes de lidar com todas as questões sob sua alçada. Além disso, as equipes têm a liberdade de tratar diretamente com os usuários e alguns patrocinadores.

Outro papel que cresce e ganha importância, a medida que cresce o Scrum, é o de Product Owner (PO), que é responsável pelo produto sendo construído e pelos benefícios e o valor que serão proporcionados ao negócio e aos usuários finais. O Product Owner pode complementar o trabalho do gerente de projetos focando nas funcionalidades já entregues e analisando os benefícios do lançamento do produto em cada iteração.

Mas com equipes autônomas e a presença do Product Owner, quais seriam as responsabilidades de um gerente de projetos? O gerente de projetos continua responsável por várias áreas da gestão, como integração, gestão do tempo, orçamento, qualidade, recursos humanos, comunicação, risco e contratos. E aparecem outras atividades importantes em um contexto ágil; por exemplo:

  • Integrar o projeto ágil com outros projetos da empresa: Em empresas grandes e complexas como bancos e operadoras de telecomunicações, projetos ágeis terão sempre alguma dependência com projetos ditos mais tradicionais.Se você precisa que uma equipe “não-ágil” crie um novo serviço na web, terá que entregar a especificação do projeto com meses de antecedência. O gerente de projetos ágil precisa buscar, nesse contexto, envolver e “evangelizar” outros gerentes, buscando disseminar a filosofia e o funcionamento das equipes ágeis, além de coordenar atividades entre diversas áreas.
  • Proteger a equipe na empresa: Departamentos externos e outros funcionários certamente demandarão suporte e manutenção de sua equipe em outros projetos. Muitas vezes questões urgentes podem levar dias, e gerar atrasos e quebras no ritmo da equipe. Conseguir “blindar” o time de interferências externas e criar mecanismos para tratar estas questões é outro papel importante do gerente de projetos.
  • Aperfeiçoar o processo e as práticas: Metodologias ágeis estimulam o aperfeiçoamento das práticas, técnicas e ferramentas de forma continuada. O gerente de projetos é convidado a criar iniciativas que aprimorem os processos que vão além da sua equipe, e podem buscar otimizar até práticas e processos mais estratégicos. (Em Scrum, o Scrum Master assume esta última responsabilidade.)

Voltando ao Scrum, um gerente de projetos pode assumir o papel do Scrum Master desde que esteja disposto a trabalhar perto da equipe, e a auxiliá-la a aperfeiçoar processos e práticas e a desenvolver suas habilidades. (Veja definições em português de Product Owner e Scrum Master)

Em grandes projetos, um gerente pode assumir o papel de Scrum Master, mas atuando em nível mais estratégico. Em um projeto simples (por exemplo, com uma equipe interna de quatro a oito pessoas), o gerente pode até assumir o papel do Product Owner também. Mas isso somente se conseguir ao mesmo tempo pensar no projeto e no produto em construção.

Comece com um projeto piloto

Como todo projeto de mudanças, a adoção das metodologias ágeis deve ser planejada e ter patrocinadores importantes dentro da organização. É recomendável que o primeiro passo seja um projeto piloto, que permita aos patrocinadores entender melhor as metodologias envolvidas, e identificar possíveis benefícios e dificuldades na sua implementação em larga escala na empresa.

A seguir é apresentada uma lista de ações que podem ajudar o gerente de projetos a organizar um primeiro projeto piloto com metodologias ágeis. São incluídas também algumas dicas gerais que podem ajudar os projetos ágeis a serem bem-sucedidos.

  • Defina o projeto piloto com o objetivo de testar o uso de métodos ágeis. Deixe claro que um dos objetivos é experimentar uma nova metodologia. Custos, cronogramas e riscos devem ser avaliados neste contexto.
  • Explicite os motivos para utilizar o Agile. Evite metodologias ágeis, se não houver um real motivo no momento. As dificuldades em adotá-las podem desencorajar a equipe e a gestão. Documente os motivos e analise, junto aos usuários finais e patrocinadores, quais benefícios são possíveis com a entrega do projeto, meses antes.
  • Garanta o comprometimento dos patrocinadores. Envolva-os em revisões regulares do projeto e em reuniões de duas a quatro horas por semana. Com esse grau de envolvimento, os patrocinadores poderão ajudar a obter apoio de outros departamentos mais rapidamente, entre outras vantagens. Também é importante que os patrocinadores avaliem junto com você os passos seguintes ao projeto piloto.
  • Faça treinamentos em Agile, com empresas com experiência comprovada. O Agile parece simples, mas leva algum tempo para dominar práticas reais. Uma opção complementar é o Coaching: existem empresas com profissionais experientes que podem ajudar na condução de projetos seguindo práticas ágeis. Verifique a experiência destas empresas e considere adquirir seus serviços para um primeiro projeto piloto.
  • Avalie a experiência em métodos ágeis reais dos fornecedores que contratar. Algumas empresas de serviços de TI utilizam o termo Agile com propósitos comerciais, mas suas equipes não possuem conhecimento ou capacidade para trabalhar efetivamente com as práticas ágeis. Para reduzir o risco de cair nessas armadilhas, é importante entender os principais conceitos e acompanhar as decisões sobre a metodologia ágil a ser utilizada, além de ter uma noção geral das práticas de planejamento, desenvolvimento e testes mais adequados à realidade da empresa.
  • Construa uma equipe com pessoas orientadas a resultados e dispostas a tentar coisas novas.

Conclusões

As metodologias ágeis continuam ganhando popularidade e aceitação. A pergunta não é mais se funcionam ou não, e sim se podem ajudar sua empresa a realizar mais e melhores projetos de TI. A melhor maneira de testar estas metodologias é realizando um projeto piloto para identificar os potencias benefícios e as prováveis dificuldades na sua implementação.

A adoção do Agile é um verdadeiro projeto de mudanças para o departamento de TI e para as áreas de negócio. Nesse processo, o gerente de projetos pode cumprir um papel fundamental, assumindo a liderança das mudanças e ajudando as equipes técnicas a entregar software de maior qualidade em menor tempo, e com funcionalidades de maior valor para a empresa.

Fonte: Ignacio Lizarralde/InfoQ

Tags | , , , , ,

20

dez
2011

Sem Comentários

Em Agile
Blog

Por Allison

Scrum o que realmente é

Em 20, dez 2011 | Sem Comentários | Em Agile, Blog | Por Allison

O Scrum é um processo de gestão e desenvolvimento ágil que se desenvolveu como uma abordagem iterativa e incremental para otimizar a previsibilidade e controle de riscos, fortemente sustentado por três pilares:

  • Transparência: garante que aspectos do processo que afetam o resultado devem ser visíveis para aqueles que gerenciam os resultados;
  • Inspeção: diversos aspectos do processo devem ser inspecionados com uma frequência suficiente para que variações inaceitáveis no processo possam ser detectadas;
  • Adaptação: se um ou mais aspectos do processo estão fora dos limites aceitáveis e que o produto resultante será inaceitável, o inspetor deverá ajustar o mais rápido possível o processo ou o material sendo processado.

A metodologia Scrum consiste em um conjunto formado por Times e seus papéis, Time-Boxes, Artefatos e Regras. Os Times de Scrum são projetados para otimizar flexibilidade e produtividade, são auto-organizáveis, multidisciplinares e trabalham com iterações. Um Time de Scrum conta com três papéis definidos:

  • o ScrumMaster: responsável por garantir que o processo seja seguido e compreendido por todos, trabalhando na remoção de impedimentos, incentivando e levando a equipe a ser mais produtiva e garantindo a qualidade do código gerado;
  • o Product Owner: é a única pessoa responsável pelo gerenciamento do Product Backlog e por garantir o valor do trabalho realizado pelo Time. Deve manter a lista de prioridades sempre atualizada com as tarefas de maior valor de negócio.
  • o Time: são os desenvolvedores que transformam o Product Backlog em incrementos de funcionalidades potencialmente entregáveis em cada Sprint. Frequentemente possuem conhecimentos especializados, como programação, controle de qualidade, análise de negócios, arquitetura, etc. Cada membro do time aplica sua especialidade a todos os problemas. A sinergia que resulta disso melhora a eficiência e eficácia do time como um todo.

Reuniões de Planejamento da Release, a Sprint, Reuniões de Planejamento da Sprint, a Revisão da Sprint, a Retrospectiva da Sprint e a Daily Scrum estão incluídos nos Time-Boxes da Scrum.

  • Reunião de Planejamento da Release: estabelece a meta da release, estimativas e as maiores prioridades do Product Backlog, os principais riscos e as características gerais e funcionalidades que estarão contidas na release. Estabelece também uma data de entrega e os custos prováveis se nada mudar. A organização pode inspecionar o progresso e fazer mudanças nesse plano a cada Sprint. Esse planejamento é inteiramente opcional, onde iniciando os trabalhos sem essa reunião, a ausência de seus artefatos aparecerá como um impedimento que deverá ser resolvido. Na maior parte dos caso o processo de planejamento é feito no início do trabalho da release e não é modificado com o passar do tempo. São definidos uma meta geral e resultados prováveis.
  • Sprint: é uma iteração de duração fixa. Durante um Sprint, o ScrumMaster garente que não será feita nenhuma alteração de escopo que possa afetar a Meta da Sprint. Uma Sprint consiste do Planejamento da Sprint, o trabalho de desenvolvimento, a Revisão da Sprint e a Retrospectiva da Sprint. As Sprints ocorrem uma após a outra, sem intervalos entre elas. Uma Sprint pode ser cancelada antes do prazo fixo, mas somente o Product Owner tem autoridade para isto. Uma Sprint pode ser cancelada se a Meta da Sprint se tornar oblsoleta, pela empresa mudar de direção ou se as condições do mercado ou tecnologia mudarem.
  • Reunião de Planejamento da Sprint: é o momento no qual a iteração é planejada. É fixada oito horas de duração para uma Sprint de um mês. Para Sprints mais curtas, deve-se alocar proporcionalmente ao tamanho total da Sprint para essa reunião. Ela consiste em duas partes, a primeira parte – o quê? – é o momento no qual é decidido o que será feito na Sprint e a segunda parte – como? – é o momento no qual o Time entende como desenvolverá as funcionalidades em um incremento do produto. Para a primeira parte o Product Owner apresenta ao Time o que é mais prioritário no Product Backlog. Cabe ao Time a decisão de avaliar quanto do Backlog deverá ser selecionado para a Sprint. Uma vez selecionada as atividades do Backlog, a Meta da Sprint é delineada, sendo ela o objetivo que será atingido no Sprint. Na segunda parte da reunião o Time geralmente começa projetando o trabalho, identificando tarefas. As tarefas devem ser decompostas para que possam ser feitas em menos de um dia. Essa lista de tarefas é chamada de Sprint Backlog. O Product Owner estará presente nesta segunda parte da reunião para esclarecer e ajudar a efetuar trocas de tarefas caso as estimativas excedam ao tempo da Sprint ou o haja algum impedimento ainda não resolvido para a execução daquela tarefa. Caso o Time finalize a Sprint antes do prazo, será negociado com o Product Owner uma nova tarefa que será adicionada ao atual Sprint Backlog.
  • Revisão da Sprint: ao final da Sprint, é feita uma reunião de Revisão, com duração proporcional à duração da Sprint – quatro horas para Sprints de um mês. Nesta reunião o time colabora sobre o que acabou de ser feito e baseado nisso eles colaboram sobre quais são as próximas tarefas que podem ser feitas. Trata-se de uma reunião informal, com a apresentação das funcionalidades. O Product Owner identifica o que foi feito e o que não foi feito. O Time discute sobre o que ocorreu bem e quais foram os problemas enfrentados, além de como esses problemas foram resolvidos. O Time demonstra o trabalho que está pronto e responde a questionamentos. O Product Owner faz projeções de datas prováveis a partir de várias hipóteses de velocidade. A Revisão de Sprint fornece entradas valiosas para as reuniões de Planejamento de Sprints seguintes.
  • Retrospectiva da Sprint: logo após a revisão da Sprint e antes da próxima reunião de Planejamento da Sprint o ScrumMaster encoraja o Time a revisar seu processo de desenvolvimento, de forma a torná-lo mais eficaz e gratificante para a próxima Sprint. A finalidade é inspecionar como ocorreu a última Sprint em se tratando de pessoas, das relações entre elas, dos processos e ferramentas. Deve identificar e priorizar os principais itens que ocorreram bem e aqueles que, feitos de modo diferente, poderiam ter deixado as coisas ainda melhores. No final desta reunião o time deve ter identificado medidas de factíveis melhoria que implementarão na próxima Sprint.
  • Daily Scrum: o Time se encontra diariamente para uma reunião de no máximo 15 minutos, sempre no mesmo horário e no mesmo local durante as Sprints. Durante a reunião cada membro explica:
    • O que ele realizou desde a última reunião;
    • O que ele vai fazer antes da próxima reunião;
    • Quais obstáculos estão em seu caminho.

As Daily Scrums melhoram a comunicação, eliminam outras reuniões, identificam e removem impedimentos para o desenvolvimento, ressaltam e promovem a tomada rápida de decisões e melhoram o nível de conhecimento de todos acerca do projeto. É uma inspeção e adaptação do progresso na direção da Meta da Sprint. Os Artefatos do Scrum incluem o Product BackLog, o Burndown da Release, o Sprint Backlog e o Burndown da Sprint.

  • Product Backlog e Burndown da Release: os requisitos para o produto estão listados no Product Backlog, por seu conteúdo, por sua disponibilidade e por sua priorização. O Product Backlog evolui à medida que o produto e o ambiente em que ele será usa evoluem, ele é dinâmico, no sentido de que ele está constantemente mudando para identificar o que o produto necessita para ser apropriado, competitivo e útil. O gráfico de Burndown da Release registra a soma das estimativas dos esforços restantes do Product Backlog ao longo do tempo. O Product Owner mantém o Product Backlog e o Burndown do Backlog da Release atualizados e publicados todo o tempo.
  • Sprint Backlog e Burndown da Sprint: o Sprint Backlog consite nas tarefas que o time executa para transformar itens do Product Backlog em incremento pronto. É todo trabalho que o Time identifica como necessário para alcançar a Meta da Sprint. Os itens do Sprint Backlog devem ser decompostos suficientemente para que mudanças no progresso possam ser entendidas na Daily Scrum. Um dia ou menos é um tamanho comum para um item do Sprint Backlog. O Sprint Backlog é um retrato em tempo real altamente visível do trabalho que o Time planeja efetuar durante a Sprint. O Burndown do Sprint Backlog é um gráfico da quantidade restante de trabalho do Sprint Backlog em uma determinada Sprint ao longo do tempo da Sprint.

O Scrum exige que os Times desenvolvam um incremento de funcionalidade do produto a cada Sprint. Esse incremento deve ser potencialmente integrável, pois o Product Owner pode optar por implantar a funcionalidade imediatamente. Para isso ser possível, o incremento deve ser um pedaço completo do produto. Ele deve estar “pronto”. Cada incremento deve ser adicionado a todos os incrementos anteriores e exaustivamente testado, garantindo que todos os incrementos funcionem juntos.

Fonte: Elton Kuzniewski

Tags | , ,

12

dez
2011

Sem Comentários

Em Agile
Blog

Por Allison

Programação em Pares: Lado a lado ou frente a frente?

Em 12, dez 2011 | Sem Comentários | Em Agile, Blog | Por Allison

A programação em pares é uma técnica de desenvolvimento ágil em que dois programadores trabalham juntos em apenas uma estação de trabalho. Seus benefícios são bem conhecidos e a técnica é amplamente praticada. Entretanto, qual é o melhor posicionamento das pessoas quando se trabalha em pares?

Uma maneira comum é sentar-se lado a lado, mas este modelo traz alguns inconvenientes, como sugere Josh Susser:

Embora sentar-se lado a lado seja um bom modelo em vários aspectos, o mesmo se mostra pouco ergonômico. Primeiro, os programadores acabam ficando de lado para o monitor, o que requer inclinação e torção para se sentarem em uma posição em que ambos possam tanto ver quanto digitar. Também é difícil olhar para o parceiro sem contorcer o pescoço.

Uma maneira alternativa de se programar em pares é sentar-se frente a frente. A organização alternativa se parece com o desenho abaixo, onde as áreas destacadas representam os pares.

Diz Susser sobre esse layout:

É muito mais confortável, pois ambos temos uma visão melhor da tela e se pode ver um ao outro com facilidade. Ficamos sentados próximos o suficiente para que seja possível se comunicar, sem que seja necessário levantar a voz. Facilitou muito nossa interação.

Brian e Corey experimentaram este modelo e o acharam bastante efetivo. De acordo com Brian, ele acabou preferindo esta forma de parear ao modelo convencional:

Acabei preferindo este estilo ao pareamento lado a lado, de frente a uma única tela. E ainda prefiro este modelo, no lugar de sentar-se em frente a dois monitores com dois teclados. O trabalho tem um fluxo mais livre e é mais fácil perceber a linguagem corporal da outra pessoa. Também fica mais natural parar de codificar, levantar a cabeça e conversar. A troca entre os pares também melhorou; houve poucas situações em que se tentou mexer no cursor ao mesmo tempo.

Tim Ottinger tentou este arranjo mas não ficou tão impressionado. De acordo com Tim,

Não foi tão ruim assim, mas nos sentimos menos conectados um ao outro neste modelo e era necessário apontar com o mouse ao invés das mãos. Funciona, mas parece mais com a experiência de se programar em pares remotamente.

Será que este arranjo tem desvantagens?

Josh Susser diz que é um pouco difícil perceber sinais sutis, como quando a outra pessoa está pronta para assumir o controle do teclado ou pequenos movimentos das mãos, que são mais visíveis quando se está sentado lado a lado. O layout também aumenta o custo, pois requer mais equipamentos e espaço físico.

Postado por Vikas Hazrati, traduzido por Rafael Buzon

Fonte: InfoQ

Tags | , , ,

13

nov
2011

Sem Comentários

Em Blog

Por Allison

O desenvolvimento ágil funciona em projetos de hardware?

Em 13, nov 2011 | Sem Comentários | Em Blog | Por Allison

Vários profissionais de TI tem trazido à tona recentemente a questão da aplicação das práticas ágeis no desenvolvimento de hardware. Nil Johnson escreveu um artigo na Electronic Engineering Times (EETimes): Desenvolvimento ágil de hardware – sem sentido ou necessidade?

Ele colocou a questão:

Deve haver um debate quando se trata de aplicar o Agile no desenvolvimento de hardware? Deveriam os valores e princípios que guiam as equipes ágeis de software também guiar os times que desenvolvem para sistema operacional (System on Chip teams) ; ou as diferenças entre estas duas disciplinas seria muito grande?

Ele continua com uma discussão sobre os valores do Manifesto Ágil e como estes valores formam a base da abordagem ágil no desenvolvimento de software. Ele coloca a questão – Poderia o mesmo funcionar para o desenvolvimento de hardware? – e comenta:

Para qualquer um que vê o desenvolvimento de hardware como um processo criativo, é difícil negar que os valores do manifesto são diretamente aplicados. Mas apenas considerar um conjunto de valores não é suficiente. De certo modo, valores abstratos precisam se traduzir na prática. Felizmente, times de software têm criado práticas que abordam os valores ágeis e muitas delas podem ser aplicadas diretamente também no desenvolvimento de hardware.

Ele reconhece as diferenças entre as abordagens do desenvolvimento de software e de hardware encorajando os times de hardware a abraçarem as práticas ágeis. Ele usa a prática do continuous delivery (entrega contínua) como um exemplo:

Uma prática de destaque é aquela de implantação rápida e contínua aos clientes. Para muitos times ágeis de software, implantação contínua é absolutamente crítico para o sucesso. Infelizmente, sua aplicabilidade no desenvolvimento de hardware – ou a falta dela – tende a ser usado para desacreditar o Agile totalmente. Para desenvolvimento ASIC em particular, implantação contínua não é realista; mas uma prática não ser realista não deve ser motivo de descrédito do conjunto de práticas. Nenhum time ágil de software realiza todas as práticas ao pé da letra; logo não se pode esperar o mesmo de um time de desenvolvimento de hardware.

Ele conclui com um pedido de mudança no foco das organizações de hardware:

Mudanças acontecem no desenvolvimento de hardware. Independentemente se são mudanças nas especificações, na rotatividade de funcionários, na dinânica do time ou novas tecnologias. Não há como evitar isso. As equipes que deixarem de lado os conceitos de Dilbert e as políticas internas para uma forma mais apurada e uma visão mais humana do desenvolvimento de hardware, retratada pelo manifesto, vai fazer desta mudança uma vantagem. Aos times que não se abrirem a esta mudança, irá restar o exercício fútil de tentar encaixar o “quadrado” dos tradicionais processos bem definidos no “buraco redondo” que é o desenvolvimento de hardware atual.

Larry Maccherone escreveu recentemente algo similar sobre as As 10 questões principais sobre quando usar Agile em projetos de hardware.

Ele elenca uma lista de questões e respostas a fim de auxiliar nas decisões sobre a aplicação de abordagens ágeis em projetos de hardware:

  1. As práticas e processos ágeis são efetivos na condução de projetos que não são de software (firmware, eletrônicos, mecânicos, etc.)?
  2. Quais ajustes são necessários no framework de processo Scrum para funcionar bem para estes projetos?
  3. Quais ajustes são necessários em nossas expectativas sobre funcionalidades comerciais mínimas, design emergente e definição de Scrum?
  4. Quais ajustes em nossas expectativas são necessárias acerca de histórias?
  5. Como fica a questão de priorizar histórias estritamente pelo valor gerado ao usuário final?
  6. Deveriam as histórias de usuário ser nossa única ferramenta de gerenciamento de requisitos?
  7. Se histórias de usuário não são nem requisitos oficiais do Scrum, então porque não devemos usar somente nossas práticas tradicionais de requisitos?
  8. O que fazer quando precisamos enviar um protótipo ao fornecedor e não é possível ser feito dentro de uma iteração?
  9. O que fazer com dependências e analise do caminho crítico?
  10. Talvez não precisemos da analise contínua do caminho crítico, mas ainda temos especialistas que não são dedicados permanentemente ao time. Como lidar com isso?

Para cada questão que ele lista uma resposta curta é dada seguida de uma discussão de abordagens práticas para resolver as potenciais incompatibilidades e como endereçá-las.

As práticas ágeis poderiam ser usadas no desenvolvimento de hardware? Quais mudanças seriam necessárias fazê-las funcionar neste contexto?

Tags | , , , ,

15

set
2011

Sem Comentários

Em Blog

Por Allison

Sete virtudes do Desenvolvimento Direcionado por Testes (TDD)

Em 15, set 2011 | Sem Comentários | Em Blog | Por Allison

Não me entenda mal, este não é mais um artigo do tipo “você deve praticar TDD porque…”. Meu objetivo é atingir aqueles que desejam iniciar nisso, mas precisam de um guia sobre como tirar o máximo benefício dele e evitar desastres típicos. Diferentes tipos de testes (e práticas de testes) fornecem benefícios diferentes, e eu pensei que talvez eu pudesse escrever algo a que você possa se referir de tempos em tempos. Portanto, estas são as virtudes prometidas, em ordem cronológica.

01. Testes te ajudam a criar o design da API da sua classe

Você pode ter ideias elaboradas sobre seus métodos e propriedades, mas os usuários que de fato usam suas coisas pensam diferente. Seja o primeiro usuário da sua classe antes de escrevê-la, e você a deixará pronta e correta antes que qualquer pessoa a veja.

02. Testes te ajudam a criar o design da arquitetura do seu sistema

Você acha que é inteligente. Aqueles diagramas DML deixam sua mãe orgulhosa de você. Até você voltar para o seu app depois de um ou dois anos e ter que fazer algumas mudanças. Você descobre alguns métodos LOC 2000, statements goto, e até procedimentos armazenados. Meu Deus, que bagunça!

Não existe prova rigorosa, mas várias fontes nos dizem que designs direcionados para testes são muito mais flexíveis e sustentáveis. Existem muitos motivos para acreditarmos nisso, o que vale até um artigo separado.

De qualquer maneira, se você parar de fingir que é a prova de falhas, e começar a escutar os seus testes, você poderá melhorar o seu design além dos seus sonhos mais improváveis. Isso é considerado o maior benefício do TDD, apesar de não ser óbvio desde o início, pois isso não está diretamente relacionado a testes.

03. Testes te ajudam a implementar os membros da sua classe

Direcionado a testes, seu método eventualmente se torna a coisa mais simples do mundo que funciona. A maior parte do que dissemos acima se aplica ao design no nível de membros também.

04. Com testes, você tem certeza de que sua aplicação ainda vai funcionar corretamente depois que você mudá-la

Depois de fazer uma pequena mudança à implementação subjacente de um certo recurso menor, você testa manualmente todo o sistema… ou seus usuários finais fazem isso por você. De qualquer maneira, você passa o fim de semana tentando entender os dados corrompidos de um backup que você fez acidentalmente alguns dias atrás (não estou inventando isso, realmente aconteceu comigo!).

Testes, quando feitos apropriadamente, podem ser uma rede de proteção que te protege de acidentes infelizes. Você pode refatorar seu código livremente com o objetivo de melhorar o seu design, sem ter medo de introduzir um bug de regressão.

05. Testes documentam a sua API

Ao estruturar seus testes em volta de classes (o que não é a melhor ideia, mas é ok para começar), você pode olhar para um teste em particular e compreender o que o método correspondente faz. Isso é, se o teste estiver nomeado e escrito devidamente.

06. Testes documentam o seu sistema

Isso não quer dizer a mesma coisa que o falado no tópico anterior. Ao olhar para um sistema novo, estou tentando entender como fazer as coisas com ele, não o que uma classe em específico faz. Portanto, ao estruturar os seus testes em volta de recursos do sistema, você fornece uma boa maneira para documentar seu comportamento, “como usar o recurso x” e “o que acontece se eu de fato usá-lo”.

Já deram sete?

Se você souber de outros benefícios, por favor, escreva-os nos comentários!

Ok, e agora?

Espero que você não use o TDD só porque te falaram para usar, mas porque você quer tirar vantagens dele. Agora que você conhece esses benefícios, você não os usa cegamente. Você tenta escrever seus testes de modo que eles deixem a refatoração mais fácil, não difícil. De modo que eles de fato influenciem seu design, e não o contrário. De modo que eles sejam fáceis de entender, e façam com que você compreenda o sistema mesmo se for um completo estranho.

Como você consegue isso? Ah, isso é outra história.

Texto original disponível em http://ivonna.biz/blog/2011/6/10/seven-virtues-of-test-driven-development.aspx

Fonte: IMaster

Tags | , , , ,