1 – The meeting is very time consuming and lasts much longer than planned.

After all, it is not anyone who manages to remain 100% focused on a very long meeting. When participants lose focus (or interest) in what is being presented, the review meeting loses its purpose.

2 – The team leaves the review meeting demotivated.

There are times when the P.O. feels the need to "shake" the team a little bit. This is normal, but sometimes these are so frequent or intense that make the team feel demotivated or discouraged. The P.O. needs to be careful here to direct the criticism to the problems and not the people.

3 – Discussions at the review meeting are not productive.

It is extremely easy to make a meeting misdirect with unproductive discussions. For some people, the temptation to just take the time to address an issue on some business rule controversy when a certain story of the same topic is being presented is too overwhelming. The Scrum Master should remind everyone that the purpose of the review meeting is the inspection of what was done and not inquiries on requirements.

4 – The team leaves the meeting without the understanding of why the stories have been reproved.

The P.O. should be able to explain to the team why a story was rejected and the team should be concerned about what will be needed to correct it. Without this understanding, the necessary corrections will not be possible, and the story can be rejected again.

5 – People in the meeting pointing out whose fault is that the story have been reproved.

A failed story is not the fault of a specific individual, but the team as a whole. The purpose of the review meeting is not to point out who is guilty of what. This kind of discussion should happen in the retrospective meeting, if appropriate.

6 – People are not aware of what is happening in the sprint.

If any team member arrives at the sprint review meeting without knowing that a story wasn't finished, why a decision has been taken, or other significant events that occurred, this person will not be able to actively participate in what is being presented, nor will pose relevant questions and will thus not benefit from the discussions.

The post 6 signs to show that your review meeting is inefficient appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.

Em um post anterior falei sobre os princípios do Lean Startup. Um deles trata-se do deploy contínuo. A ideia deste princípio é que o tempo desde a finalização da construção de um recurso até a sua disponibilização em produção seja o menor possível. No post de hoje eu falo sobre o DevOps, uma cultura importante no desenvolvimento de software para facilitar a agregação contínua de valor ao produto em desenvolvimento.

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 (Português) Já ouviu falar em DevOps? appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.

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.

A few days ago, on a post called Business Model Canvas, Igor Araujo wrote about a simple, agile, objective and visual way to elaborate a business model for our company or product. But what if we wanted to adapt this Canvas to software projects? Would it be possible to communicate everything there is to know about a project in just one sheet? Well, that is what a new methodology called Project Model Canvas promises to do and that is why it is the subject of today’s post.

Inspired by the Business Model Canvas, this new methodology aims at bringing into the Project Plan the benefits obtained by those using this Canvas for their business: to build a plan in a fast and collaborative way and still guarantee common understanding of all features envolved in the project by making it visual. Making use of only paper and post-its, Project Model Canvas envolves manager, stakeholders and team in a brainstorming process that results on the definitions that will lead the project’s construction. The intention is to build an artifact that makes it possible to understand the project’s concept, restrictions, costs and schedules by just staring at it. It’s a new model that believes it’s possible to diminish some old problems of traditional software project, as the need for an extensive documentation to initiate the project and the lack of stakeholder’s involvement during the conception phase.

To reach this goal, the Canvas for projects tries to answer the following questions: why?, what?, who?, how?, when? and how much?. 

Each one of the 13 little squares disposed on the sheet is focused on an information necessary to define the project. And each one of them must be filled with post-its containing short and objective texts, formulated by the team, the stakeholders and/or the project manager. After evaluating and discussing the raised ideas, the final result is a portrait of the project to be developed presented in a clear and concise shape. And, above all, visual.

Another important matter is the fact of being flexible and easily changeable. Since it’s constructed with post-its, each new idea and problem can generate changes in the plan without great impacts on its understanding and update. You can reorganize and remove post-its quickly enough to not result in a high cost of maintenance of the plan.

This new methodology provides, above all, a new means of communication and connection of ideas to build the concept a project. From all that has been collected, it is possible to establish relationships and implications of  the project’s outcome and map these conclusions to tools frequently used by the project manager.

Currently, this methodology is already being used by great companies in Brazil to initiate their projects.

How about you? Do you think this idea would work in your company?

References:

Mundo Project Management

Project Model Canvas

The post Project Model Canvas appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.

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 (Português) 3 Ferramentas para Auxiliar seu Processo de Refatoração appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.

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 (Português) Gerência de Riscos no SCRUM appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.