Agilize-se

  A partir da análise do trabalho em progresso podemos começar a ver quanto tempo uma demanda leva para ser entregue ao cliente.  Em desenvolvimento de software, podemos considerar Lead Time como sendo o número de dias entre o início e o fim do processo de entrega de um item de trabalho. É o tempo em dias em que o item de trabalho passa pelo Fluxo de etapas do processo de desenvolvimento. O que é Lead Time ? O Lead time é uma métrica que deve ser coletada para cada demanda a partir da etapa na qual a equipe começa de fato a trabalhar na demanda. Tendo como base o Lead Time das demandas que passaram nos últimos 15 dias pelo fluxo podemos responder quando uma demanda esta pronta. É importante ressaltar que o Lead Time é uma métrica que pode ser medida independente do processo de desenvolvimento adotado pela empresa. A medição do Lead Time nos ajuda: Compreender quanto tempo a Equipe leva para desenvolver um item de trabalho; Analisar a saúde do processo de desenvolvimento, ident...

  É comum ouvirmos sobre times de desenvolvimento que trabalham demais porém parece que nunca conseguem entregar nada de valor para o cliente. Acontece que times que enfrentam esse problema não tem ideia do que estão fazendo, do volume de trabalho, da complexidade do trabalho ou de sua própria capacidade de entrega. São times que vivem com o não cumprimento de prazos, não entrega de demandas, uma alternância de tarefas e contextos provocados pelo excesso de paralelismo nas tarefas.  Muitos desses times aceitam mais trabalho do que realmente podem realizar e acabam com os problemas citados acima. Estes times não entendem que o excesso de trabalho compromete a qualidade do produto e reduz a frequência das entregas.  Analisar o trabalho em progresso  É necessário a análise do trabalho em progresso, também conhecido pela sigla WIP ( Work in Progress ). O WIP se refere a todo trabalho iniciado mas que ainda não foi entregue ao cliente e pode ser desde uma demanda, uma peq...

  O que não pode ser medido não pode ser gerenciado e, consequentemente, não pode ser melhorado.  Todo o trabalho realizado no projeto deve ser medido a fim de que o projeto possa ser gerenciado visando a melhoria contínua.  Assim sempre devemos usar métricas como ferramenta para fazer a gestão com o objetivo de melhorar o trabalho realizado ao longo do projeto. As métricas ajudam a equipe a descobrir onde estão e a comparar com o estado onde querem chegar. Desta forma, nos as métricas nos permitem acompanhar, dia a dia, o rumo que estamos tomando no trabalho e a verificar se estamos indo na direção esperada. Para isso é importante que as métricas estejam visíveis e atualizadas  para toda a equipe podem acompanhar o andamento do trabalho e tomar medidas caso seja necessário. Isso permite que as equipes ágeis se auto gerenciem, como aliás é esperado.  As métricas são representadas visualmente na forma de gráficos que são ótimas ferramentas para análise das métric...

  Você já deve ter lido uma afirmação parecida com essa: "Seu time não é ágil só porque usa um mural com cartões coloridos para as tarefas.". A verdade é que além de todos os eventos, artefatos e papéis, dentre os diferentes frameworks ágeis disponíveis ainda é preciso incorporar um conjunto de práticas que ajudam a equipe a melhorar a qualidade e a produtividade no dia a dia. São boas práticas que se relacionam com a maneira como o trabalho é feito, tecnicamente.  Em desenvolvimento de software existem várias boas práticas que devem ser aplicadas nos times que pretendem ser ágeis. É muito comum o uso de práticas de um framework em outro como por exemplo o uso de práticas da programação extrema no Scrum ou no Kanban. Somente quando usamos frequentemente práticas ágeis é que podemos dizer que somos ágeis. As práticas a seguir podem ajudar seu time a ser ágil de verdade, melhorando a qualidade do seu produto, a produtividade do time de desenvolvimento e isso irá refletir na mo...

  O Planejamento de Releases tem o objetivo de definir em que ordem e quais entregas serão feitas ao cliente. Para se planejar as releases do produto deve ser feita uma reunião, de preferência, mensalmente ou a cada duas semanas. O Planejamento permite dividir um projeto em entregas de acordo com o valor para o negócio, priorizando os itens que devem ser de maior valor para o negócio do cliente. Assim um projeto de seis meses pode ser dividido em 6 entregas, com releases com quatro iterações para cada uma. É importante compreender o que agrega mais valor para o negócio, num determinado momento, e buscar realizar entregas que tragam o máximo de valor para o cliente. O Dono do Produto tem a responsabilidade de buscar essa compreensão e priorizar corretamente os itens que farão parte de cada entrega. Na reunião de planejamento de releases devem estar presentes todos os envolvidos no processo de entrega para ajudar em decisões técnica e para, o mais importante, se definir uma estratégi...

 Você pode aumentar o conhecimento sobre seus usuários e cliente com o uso de Personas. Personas são perfis baseados nos usuários e clientes do produto. A criação de Personas ajuda a identificar os usuários e clientes importantes para o sucesso do projeto. Personas ajudam a melhorar o entendimento dos usuários, suas responsabilidades, suas atividades, seus problemas atuais, suas necessidades de informação e suas expectativas em relação ao produto. Este conhecimento é importante para melhorar a comunicação e o entendimento dos usuários e também a tomada de decisão sobre o projeto. Além disso, ajuda muito a otimizar as funcionalidades do produto  para cada perfil, garantindo que as necessidades, problemas e expectativas de cada perfil sejam atendidas. As personas do produto devem ser identificadas logo no início do projeto a fim de as informações e conhecimento obtidos a respeito das personas possam direcionar e orientar todo o trabalho que será feito durante o projeto. Toda Per...

  Historias do usuário são descrições simples, curtas e objetivas de funcionalidades esperados no software pelo usuário. As Histórias do usuário são escritas pelo Product Owner em linguagem de negócio e devem ser uma breve descrição de uma necessidade do cliente. É importante deixar claro que uma história do usuário não é uma especificação de software e nem tem a intenção de descrever em detalhes aspectos relacionados com a tecnologia usada para construção do software. Aspectos técnicos não devem ser escritos em uma história do usuário, apenas descrições em alto nível em linguagem de negócio e que descrevam brevemente a funcionalidade. Apesar de serem uma breve descrição de funcionalidades esperadas, as histórias do usuário devem ter informações suficientes para que seja possível validar se foram atendidas. Toda história de usuário deve ter critérios de aceite bem definidos. Os critérios de aceite são validações, regras e críticas que deve ser atendidas para que se possa considerar...

  Quando falamos em desenvolvimento de software todo trabalho iniciado e não concluído deve ser considerado um desperdício e deve ser evitado. "Pare de começar a comece a terminar". Sterling Mortensen. A idéia é parar de começar trabalhos que nunca são concluídos, que nunca são entregues ao usuário, e concluir o que foi iniciado, entregando ao usuário algo que agrega valor para o negócio. Quando a equipe está sobrecarregada, atuando em muitas frentes, a produtividade é afetada, a qualidade também pois a mudança de contexto, quando a pessoa muda de tarefa, compromete o foco no trabalho e os erros começam a aparecer e o trabalho nunca é concluído pois o retrabalho é constante e a falta de foco não permite que a pessoa se concentre, se dedique integralmente a uma tarefa para que possa concluí-la no prazo. Segundo a chamada "Lei de Little" existe uma relação diretamente proporcional entre o trabalho em progresso e o tempo para concluir o trabalho. Ou seja, quando mais t...

  Quando falamos de métodos ágeis, o planejamento pode ser feito feito de forma iterativa ou fluxo contínuo. O planejamento feito com iterações permite que as atividades do projeto sejam estruturadas de acordo com o andamento do projeto.  No planejamento do projeto são definidas releases que determinam as entregas do projeto. Cada release, por sua vez, é dividida em uma ou mais iterações que são ciclos curtos de trabalho, onde ao final de cada iteração, a equipe produz algo de valor para o negócio. Em alguns projetos, pode ser necessário várias iterações em uma release antes de se realizar uma entrega com valor para As iterações são chamadas de Sprint no Scrum e tem duração de uma semana a um mês, o que vai depender de cada organização e da complexidade do projeto. Em geral uma iteração deve ser o mais curta possível de forma a permitir que a equipe produza algo de valor para o negócio. Essa abordagem ajuda a equipe a acelerar naturalmente ao longo do projeto. Em toda Sprint é...

  Um dos principais problemas no desenvolvimento de software é o levantamento prematuro de requisitos que é muito comum em processos de desenvolvimento em cascata. Ao se tentar fazer todo o levantamento das necessidades do sistema, no início do projeto, de uma só vez, acabamos por adiar por tempo demais a construção do software, para só depois, após ter o entendimento completo de todas as necessidades do usuário, requisitos funcionais e regras de negócio, dar prosseguimento as demais tarefas do projeto. Esta abordagem gera um desperdício de tempo e recursos pois ao se tentar definir todos os requisitos no início do projeto, de uma única vez, se consome muito tempo e quando o desenvolvimento enfim é iniciado pode acontecer de os requisitos já terem mudado ou não serem mais necessários. Este é o pior tipo de desperdício, quando tudo o que se construiu não atende ao cliente pois a necessidade mudou ou ainda não é mais necessário. Um dos benefícios dos métodos ágeis é que eles usam o p...

 Quantas vezes ouvimos histórias de projetos que foram entregues ao cliente que respondeu dizendo: "Bem o produto está ótimo, mas não era bem isso que eu queria"? Situações como esses acontecem com mais frequência do que imaginamos e são um desperdício de tempo, dinheiro e esforço. Nada mais é tão frustrante para o cliente quanto para a equipe do projeto como um produto que não atende ao cliente, que não agrega valor para o negócio. O planejamento do projeto não pode considerar apenas aspectos técnicos mas deve também, e principalmente, considerar o foco no valor para o negócio, naquilo que poderá de fato trazer benefício para o cliente. A equipe precisa aprender a manter o foco no negócio e se responsabilizar pelo resultado do trabalho tanto em termos técnicos quando em termos de valor agregado para o cliente. Não basta entregar um projeto sem defeitos, com boa qualidade, no prazo e orçamento previstos se o projeto não traz ganho algum para o cliente, se não agrega valor. Po...

Um dos fatores de sucesso em um projeto ágil é o entendimento correto do trabalho a ser feito por todos na equipe. Embora pareça óbvio é muito comum que nem todas as histórias do usuário tenham o detalhamento suficiente ou estejam bem escritas para que possam ser consideradas no Backlog de uma Sprint. Por regra geral, nenhuma história deveria ser discutida em um Sprint Planning sem antes ter sido refinada adequadamente de forma que tenha todas as informações suficientes para que possa ser compreendida sem margem para dúvidas. Infelizmente, muitas vezes as Histórias do Usuário ficam com uma informação muito superficial do trabalho que deve ser feito. Em muitos casos, apenas uma descrição rápida e a menos que o Time de Desenvolvimento tenha uma bola de cristal isso pode comprometer seriamente o resultado do Sprint. Refinamento do Backlog do Produto Para evitar que isso aconteça o Product Owner deve trabalhar continuamente junto com o Time de Desenvolvimento em Sessões de Refin...

Os valores do SCRUM são  essenciais e formam a força vital do SCRUM. Eles estão entrelaçados, relacionados e se complementam. Sem eles os artefatos, os eventos e papeis do SCRUM perdem seu propósito. Estes 5 valores dizem respeito ao comportamento, à atitude que todos os que praticam SCRUM devem ter no dia a dia. Dizem respeito sobretudo a forma como todos na equipe devem trabalhar. São eles: Comprometimento Foco Transparência Respeito Coragem Comprometimento Esse é o primeiro valor e diz respeito a o nível de entrega de cada pessoa em uma equipe. Cada pessoa precisa se comprometer com as outras, com a meta da Sprint, com o trabalho a ser feito, com a produção de valor, em melhorar a cada Sprint. Não adianta dizer que vai tentar pois a tentativa sem o comprometimento é vazia em si, acaba sempre sendo apenas uma tentativa. Este princípio se torna evidente quando todos em uma equipe entendem que o sucesso ou o fracasso é de todos e não apenas individual. Não há pensamento nem descul...