1- A reunião é longa e dura muito mais do que o planejado.

Afinal, não é qualquer um que consegue se manter 100% focado em uma reunião muito longa. Quando os participantes perdem o foco (ou interesse) no que está sendo apresentado, a revisão perde seu propósito.

2- A equipe sai desmotivada da reunião.

Existem ocasiões em que o P.O. sente a necessidade de dar uma “sacudida” na equipe. Tem-se o caso em que estas são tão frequentes ou intensas, que fazem um sentimento de desânimo, ou desmotivação prevalecer na equipe. Aqui deve-se tomar o cuidado de dirigir as críticas aos problemas e não às pessoas diretamente.

3- As discussões da reunião de revisão não são produtivas.

É extremamente fácil fazer com que uma reunião perca o rumo com discussões improdutivas. Para alguns, a tentação as vezes é muito grande quando uma certa história está sendo apresentada, deste “aproveitar o momento” para abordar uma questão sobre alguma regra de negócio polêmica. O Scrum Master deve lembrar a todos que o objetivo da revisão é a inspeção do que foi feito e não questionamentos de requisitos.

4- A equipe sai da reunião sem entender o porquê das histórias reprovadas terem tido este destino.

O P.O. deve conseguir passar para a equipe o motivo pelo qual uma história foi reprovada e a equipe deve se preocupar em saber o que será necessário para corrigi-la. Sem este entendimento, as correções necessárias não serão possíveis, e corre-se o risco de que esta seja reprovada novamente.

5- Atribuições individuais de culpa.

Uma história reprovada não é culpa de um indivíduo específico, mas é uma derrota da equipe como um todo. O objetivo da reunião de revisão não é apontar quem é o culpado de quê. Este tipo de discussão deve acontecer na reunião de retrospectiva, caso pertinente.

6- As pessoas não estão a par do que está acontecendo na sprint.

Se algum membro da equipe chega na reunião de revisão de sprint sem saber que uma história não foi finalizada, o porquê de uma decisão ter sido tomada, ou outros eventos significativos que ocorreram, esta pessoa não conseguirá participar ativamente do que está sendo apresentado, não fará questionamentos pertinentes e logo, não se beneficiará das discussões.

The post 6 sinais de que a sua reunião de revisão é ineficiente appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.

Em projetos ágeis, a missão da equipe de desenvolvimento é entregar continuamente o que o cliente solicita dentro do tempo acordado, a fim de estar sempre agregando valor ao negócio. A equipe de desenvolvimento trabalha de forma a estar sempre pronta para responder às mudanças com agilidade. Já a missão da equipe de infra em geral é manter tudo funcionando de forma estável, a fim de manter e proteger o valor do negócio. Diante deste cenário podemos perceber um conflito, que pode ocorrer em muitas organizações. Vejamos… os desenvolvedores querem subir para produção novas versões da aplicação, entregando novos recursos para o cliente. Ou seja, temos mudanças! Por outro lado, a equipe de infraestrutura impõe algumas barreiras às mudanças com o intuito de evitar incidentes e possíveis downtimes, protegendo o valor do negócio. Assim, temos de um lado uma equipe que está sempre realizando mudanças para agregar valor ao negócio, enquanto de outro lado temos uma equipe evitando mudanças a fim de proteger o valor do negócio. Daqui em diante vou me referir à equipe de desenvolvimento como equipe de dev e equipe de infraestrutura como equipe de infra.

As equipes de infra em geral não tem conhecimento sobre o ambiente de desenvolvimento e trabalha de forma mais manual, enquanto a equipe de dev não tem total conhecimento sobre o ambiente de infra, seus processos e rotinas. Geralmente a equipe de desenvolvimento tem dificuldades e às vezes não tem nem meios de garantir que suas alterações não vão quebrar sua aplicação em produção. Não é à toa que frequentemente deparamos com incidentes após o deploy em produção e, em alguns casos, até rollbacks de release, ferindo a entrega acordada entre equipe e cliente.

Diante das mudanças na TI nos últimos anos e com a ascensão da agilidade no desenvolvimento de software, não se pode mais permitir que este conflito continue impedindo que as entregas sejam feitas de forma rápida e contínua. É preciso que se criem meios para que o negócio flua, evolua e aumente o seu valor agregado ao mesmo tempo em que garanta a proteção do valor alcançado até então. Simplesmente ter uma estrutura que garanta um bom uptime na aplicação não é garantia de sucesso. Pois de que adianta ter um bom uptime se não se pode agregar valor ao negócio com agilidade? 

Com o intuito de resolver estes conflitos surgiu a cultura DevOps. A ideia é que infra e dev tenham uma relação saudável de colaboração, sem divisões. O DevOps mantém o alinhamento do time de desenvolvimento (Dev) com o time de infra/operações(Ops) a fim de acelerar as entregas em produção com qualidade. Há diversas formas de aplicar o conceito de DevOps. Mas em linhas gerais trata-se de criar uma linha de produção para o desenvolvimento de qualidade em produção. Idealmente, esta linha de produção deve ser construída de forma a permitir que os desenvolvedores possam realizar o deploy sem a necessidade de requisitar operações da equipe de infra, uma vez que o processo deve ser automático. Além disso, esta linha de produção deve estar preparada para responder aos possíveis incidentes com agilidade e de forma confiável.

O conceito de DevOps é em geral aplicado com o auxílio de ferramentas de deploy automatizado, gerência de configuração, orquestração de servidores e mecanismos e ferramentas de controle e monitoramento da aplicação em produção. É recomendável que o especialista em DevOps seja um profissional experiente, que tenha conhecimento da aplicação e do ambiente de desenvolvimento, além de ser um profissional sênior em infraestrutura. Ter bom background em desenvolvimento e metodologias ágeis também são fatores importantes para o especialista em DevOps.

A implantação da cultura DevOps traz ganhos tanto para as equipes de dev quanto para as equipes de infra. A infra se torna mais organizada e ao mesmo tempo mais eficiente e ágil. A equipe de infra deixa de administrar e passa a desenvolver a infraestrutura. A criação de novos ambientes se torna mais rápida e segura ao mesmo tempo em que todos os ambientes são mantidos de forma padronizada e sob controle. Já para a equipe de dev podemos enumerar ganhos como um ambiente de trabalho mais adequado e padronizado ao mesmo tempo em que o deploy da aplicação se torna mais rápido, padronizado e seguro. Para a organização como um todo podemos enumerar ganhos como o fim da divisão entre infra e dev, participação de ambas as equipes no planejamento do ambiente de produção, facilitando o alinhamento das equipes e o monitoramento da aplicação.

A cultura DevOps pode trazer muitas melhorias para o desenvolvimento de software, facilitando o trabalho de todas as equipes e permitindo entregas contínuas e com qualidade, que é um dos pilares do Lean Startup.

E na sua empresa, como é implantada o DevOps? Compartilhe com a gente nos comentários! 

Até o próximo post!

The post Já ouviu falar em DevOps? appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.

No post Business Model Canvas, o Igor Araujo apresentou uma maneira simples, ágil, objetiva e visual de elaborarmos um modelo de negócios para nossa empresa ou produto. Mas e se adaptássemos este Canvas para projetos de software? Será que é possível transmitir em uma só folha objetivos, fases, custos, benefícios e envolvidos de um projeto e utilizá-la como apoio para a gerência desse projeto? Bom, essa é a promessa do Project Model Canvas e é sobre ele que vamos falar no post de hoje.

Inspirado no Business Model Canvas, o objetivo desta nova metodologia é trazer para o Plano do Projeto os benefícios alcançados por aqueles que passaram a usar a Canvas para seus negócios: construir um plano de forma rápida e colaborativa, além de garantir visualmente o entendimento comum dos fatores envolvidos no projeto. Utilizando apenas um papel e post-its, o Project Model Canvas busca envolver gerente, cliente e equipe num processo de brainstorming que resulta nas definições que orientarão o desenvolvimento do projeto. A intenção é ter um artefato que apenas olhando para ele seja possível entender as premissas, restrições, custos e cronogramas do projeto. Dessa forma, acredita-se ser possível diminuir alguns velhos problemas dos projetos de software tradicionais, como a necessidade de uma extensa documentação para iniciar o projeto e a falta de envolvimento do cliente durante a fase de concepção do mesmo.

Para alcançar esse objetivo, a Canvas voltado para projetos busca responder os seguintes questionamentos: por quê?, o quê?, quem?, como?, quando e quanto?. 

Cada um dos 13 bloquinhos dispostos na folha possui foco em uma informação necessária para definir o projeto. E cada um deles deve ser preenchido com post-its de textos curtos e objetivos, formulados por equipe, cliente e/ou gerente do projeto. Após avaliações e discussões das ideias levantadas, o resultado final obtido é um retrato do projeto a ser desenvolvido apresentado de forma clara e concisa. E acima de tudo, visual.

Um ponto importante da Canvas é o fato de ser flexível e facilmente mutável. Por ser construído com base em post-its, cada nova ideia discutida e problema levantado pode gerar mudanças no Plano sem grandes impactos no seu entendimento e atualização. Rapidamente os posts-its podem ser reposicionados, alterados e retirados da Canvas sem acarretar um alto custo de manutenção do Plano.

Esta nova metodologia proporciona, acima de tudo, uma nova forma de comunicação e junção de ideias para a construção da concepção de um projeto. A partir de tudo o que foi coletado, é possível estabelecer relacionamentos e implicações do resultado do projeto e mapear essas conclusões para ferramentas utilizadas pelo gerente durante a execução do mesmo.

Atualmente, esta metodologia já está sendo utilizada por grandes empresas para iniciar seus projetos.

E você? Acha que essa ideia vai dar certo nos seus projetos?

Referências:

Mundo Project Management

Project Model Canvas

The post Project Model Canvas appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.

Qualquer equipe responsável por construir um produto busca entregar ao cliente qualidade. Para equipes de desenvolvimento de software, o aumento da qualidade do que é produzido está intimamente ligado à mudanças no seu processo de desenvolvimento. Existem diversas técnicas que buscam auxiliar as equipes a atingir este objetivo e que podem ser incorporadas ao processo utilizado, como, por exemplo, a criação de testes automatizados, o uso de integração contínua, o TDD etc. Hoje falaremos de uma dessas técnicas, a refatoração.

Já conversamos sobre refatoração aqui no blog anteriormente. Em Débitos técnicos e a Refatoração, Rodrigo Aguas falou sobre como a refatoração nos ajuda a evitar o acúmulo de débitos técnicos e como esse acúmulo pode ser perigoso para o futuro do projeto. Depois disso, o post A importância da refatoração do Marcelo Areas nos mostrou que a refatoração tem por objetivo manter o código simples, claro e sem duplicações. Neste post, vamos colocar a mão na massa e falar um pouco sobre ferramentas que podem auxiliar o processo de refatoração de código dos nossos projetos.

Essas ferramentas são conhecidas como ferramentas de análise de código estático, ou seja, análise do código fonte de um programa sem precisar executá-lo. Dentre os objetivos desta técnica estão a verificação da estrutura do código em relação à estrutura padrão recomendada pela linguagem utilizada, a detecção de bugs e a realização de medições do software, como o cálculo das médias da complexidade ciclomática e da quantidade de linhas por método, por exemplo. Esse tipo de análise nos permite identificar pontos do código altamente suscetíveis a falhas, a problemas de performance, escritos de maneira não recomendada e que estão gritando por mudanças, ou seja, pontos que precisam ser refatorados.

Toda essa análise pode ser realizada por nós mesmos, manualmente. O problema é que nem sempre conseguimos escutar os gritos daqueles trechos de código. Às vezes a necessidade de refatoração não está clara para todos, às vezes estamos tão envolvidos no novo código que não damos a atenção necessária à refatoração dentro do nosso processo. Ou às vezes simplesmente não temos tempo. Quando a revisão de código passa a fazer parte do processo de desenvolvimento de uma equipe, há muito código ainda não revisado e nem sempre é possível fazer a equipe parar para analisar tudo o que já foi codificado. E aí está a grande vantagem do uso dessas ferramentas. Elas não dispensam a atividade manual e a revisão do código pelos desenvolvedores, mas elas nos ajudam imensamente por serem capazes de analisar todo o código existente e identificar maus cheiros muito mais rápido do que nós conseguiríamos.

Na Wikipédia, podemos encontrar uma lista dessas ferramentas, divididas por linguagem de programação. Como nos projetos em que trabalho utilizamos Java, as ferramentas que mostrarei para vocês neste post estão voltadas para esta linguagem. Todas as 3 ferramentas mostradas a seguir foram testadas por mim brevemente através de plugin para a IDE Eclipse e, após breve descrição de cada uma delas, passarei a vocês a impressão que tive do uso de tais ferramentas.

1. Checkstyle: esta ferramenta nasceu com o objetivo de analisar problemas de layout de código, como espaços indevidos, por exemplo, e a sua configuração default trata justamente disso. A partir de versão 3, ela incorporou em sua análise a busca por bugs, códigos duplicados etc e para fazer com que o plugin varra seu código atrás desses problemas é preciso criar uma configuração customizada indicando quais são os módulos que você deseja utilizar. Os problemas encontrados são apresentados na aba Problems do Eclipse e te mostram a linha do arquivo onde o problema foi encontrado e o que eles sugerem que seja feito para resolver a questão. Ela também possui um módulo de métricas e permite que você construa um módulo customizado de análise de código. 

2. FindBugs: esta ferramenta é bastante robusta e é mantida pela Universidade de Maryland. Ela classifica os problemas encontrados em diversas categorias, o que permite que o desenvolvedor foque inicialmente naqueles que parecem ser mais perigosos para o seu software, e permite selecionar quais detectores de bugs devem ser utilizados. Os problemas encontrados são apresentados em aba própria do plugin e apresentam o problema que pode acontecer no trecho de código examinado, em vez da sugestão de correção. Além disso, se clicarmos em cada um dos itens apresentados, ele apresenta uma breve descrição do bug encontrado detalhando por quê aquele uso é ruim para o código. Esta ferramenta é utilizada em grandes projetos, como o Java Server Faces.

3. CodePro AnalytiX: esta ferramenta é mantida pelo Google em parceria com o Eclipse Project e apresenta funcionalidades similares ao FindBugs. A diferença está no módulo de geração de casos de testes automatizados e no módulo de métricas, que permite a visualização de gráficos e a configuração de valores considerados limites para cada uma das métricas. Se esse limite é ultrapassado, no relatório a métrica é apresentada em vermelho para evidenciar o problema encontrado. Outro diferencial é que ela une aspectos das duas ferramentas anteriores em relação ao resultado apresentado: ela mostra o problema, por quê ele é ruim para o código e a sugestão de melhoria. 

Após utilizar as 3 ferramentas tive a impressão de que a última, a CodePro AnalytiX, é a que mais se encaixa nas necessidades de quem está incluindo a análise de código estático no seu processo de desenvolvimento. Apesar da FindBugs me parecer a mais robusta dentre as 3, a CodePro AnalytiX não fica atrás nos problemas encontrados e, para quem está começando, explicar por quê o código está ruim e sugerir a solução é muito importante. Isso faz com que, com o tempo, a equipe aprenda com aqueles erros e os evite no futuro. Além disso, em casos em que não se sabe o que fazer para resolver o problema, a própria ferramenta pode apontar a direção. Algumas pessoas recomendam o uso tanto da FindBugs quanto da CodePro AnalytiX. Eu acredito que, inicialmente, a CodePro AnalytiX é suficiente para levar a equipe para o caminho da refatoração, dando um apoio maior e fornecendo resultados mais claros e fáceis de serem compreendidos.

Como dito anteriormente, o uso dessas ferramentas não exclui a revisão manual do código. Até mesmo os erros encontrados automaticamente podem representar falsos problemas e devem ser analisados para decidirmos se devemos aplicar alguma correção ou não. O ideal é que essa análise passe a fazer parte do processo de desenvolvimento da equipe e a cada nova funcionalidade a preocupação de refatorar exista. Acredito que o uso de ferramentas de análise de código estático podem despertar essa preocupação na equipe e ser o pontapé inicial que estava faltando. E para aqueles que gostam do assunto não deixem de ler o livro “Refatoração – Aperfeiçoando o Projeto de Código Existente” de Martin Fowler.

E no seu projeto? Vocês utilizam este tipo de ferramenta? Conte sua experiência para nós.

The post 3 Ferramentas para Auxiliar seu Processo de Refatoração appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.

A gerência de riscos é uma atividade importante a ser realizada no decorrer de um projeto. Ela tem o objetivo de manter o controle sobre possíveis entraves que possam ameaçar a boa execução deste. Além disso, é imperativa a sua realização para alcançar o nível de maturidade de processos G e C do MPS-BR (Melhoria de Processos de Software Brasileiro) e  3 do CMMI (Capability Maturity Model Integration).

 

Em projetos tradicionais, a Gerência de Riscos segue um processo de identificação, análise, desenvolvimento de respostas e monitoramento dos riscos. Estas atividades são realizadas antes do  início do desenvolvimento e revisadas, posteriormente, em marcos pré-definidos do projeto. Todo o processo é documentado formalmente e comunicado às partes interessadas no gerenciamento dos riscos.

 

O SCRUM não fala explicitamente sobre um processo formal de Gerência de Riscos, mas é possível realizá-lo sem sacrificar a agilidade desta metodologia. Sendo assim, ele pode ser realizado de maneira orgânica ou evidente. No primeiro caso, os riscos são identificados naturalmente, frutos de reuniões diárias, plannings ou revisões. No segundo caso, basta incluir a realização desta atividade, explicitamente, na pauta de alguma cerimônia do SCRUM. Seja qual for o caso, após a identificação, é necessário realizar as demais atividades do processo.

 

Uma boa prática é a manutenção de um quadro de riscos. A idéia por trás deste é de funcionar como o quadro de tarefas do SCRUM, porém dividido em três partes: mitigar, aceitar e evitar, que são as categorias básicas de respostas aos riscos.

• Evitar um risco é a ação de eliminar a causa deste inviabilizando a sua ocorrência (ex: mudança de estratégia de projeto).
• Mitigação de um risco é a suavização das consequências, ou a diminuição da probabilidade de um risco por meio de um plano de mitigação (ex: compra de um seguro).
• Aceitação de um risco é a ação de simplesmente aceitar suas consequências, podendo haver ou não um plano de contingência para o caso deste ocorrer.

A medida que os riscos vão sendo identificados, eles vão sendo adicionados ao quadro, de acordo com o modo de gerenciamento escolhido para os mesmos. O mais importante é que o quadro esteja acessível para as partes interessadas e responsáveis pelo gerenciamento dos riscos.

 

Referência: Relating PMBOK Practices to AGile Practices 

The post Gerência de Riscos no SCRUM appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.