Origem do Kanban

Entender a origem do surgimento dos príncipios do Kanban pode contribuir de forma significativa para quem pretende aplicar tal metodologia aplicada ao desenvolvimento de software.

Como descrito na última postagem introdutória, Kanban é uma palavra japonesa que significa “cartões coloridos” e foi criado na década de 1950, na fábrica automobilística da Toyota.

A técnica Kanban tem como premissa básica o conceito Just in time, que, resumidamente, corresponde ao conceito de eliminação de estoques através da requisição de quantidades exatas de materiais no momento exato de sua produção ou execução, conhecida como produção “puxada”. Ou seja, ter somente a quantidade de material necessária para a fabricação do que o cliente necessita. 

O documentário a seguir conta de forma bem completa como surgiu o conceito Just in time e Kanban. 

Tendo como base grande parte dos princípios do Manifesto para Desenvolvimento Ágil de Software, bem como a filosofia Lean do Sistema Toyota de Produção (TPS – Toyota Production System), surgiu o Kanban para Desenvolvimento de Software, que veremos com mais detalhes nas próximas postagens!

Referências: 

Kanban no desenvolvimento de projetos de software. Acessado em: 25 de fevereiro de 2016. Disponível em: <http://www.garcia.pro.br/EngenhariadeSW/artigosMA/A6%20-%2045-6-%20Kanbam.pdf> 

Como o Kanban pode ajudar sua empresa a reduzir custo. Acessado em: 25 de fevereiro de 2016. Disponível em: <http://www.sobreadministracao.com/como-o-kanban-pode-ajudar-sua-empresa-a-reduzir-custos/> 

Scrum, uma solução viável à sua empresa

O Scrum é um framework que faz parte do desenvolvimento ágil de projetos, possibilitando às empresas um retorno de investimento, muitas vezes, mais rápido do que nas metodologias convencionais. Isso o torna, à primeira vista, atrativo para as organizações que buscam alternativas rápidas e eficazes para atender tendências de mercado e ter a capacidade de responder às mudanças.

Um Time Scrum é formado por três papéis. O primeiro é o Product Owner (Dono do Produto), que define os itens que devem ser desenvolvidos para um projeto e tem autoridade, inclusive, em relação à alta gerência. O segundo papel é do Scrum Master, este age como mentor do Dono do Produto facilitando a priorização dos itens que serão desenvolvidos em um projeto auxiliando o Time de Desenvolvimento e difundindo o Scrum na empresa. Como terceiro papel, tem-se o Time de Desenvolvimento, composto de três a nove pessoas, também chamados de desenvolvedores, os quais possuem habilidades suficientes para completar o trabalho a eles destinado em um período, geralmente, de duas a quatro semanas, chamado de Sprint.

Mas afinal, quais os benefícios que uma equipe Scrum pode trazer para sua organização? Essa pergunta tem várias respostas, já que o Scrum pode ser aplicado em projetos dos mais variados tipos e tamanhos. Como exemplo, citamos uma empresa cujo foco é realizar uma campanha para acompanhar as tendências do mercado, ou, então, uma empresa com a necessidade de criar um produto de forma rápida e eficaz para seus clientes.

No framework Scrum, em cada Sprint, ou seja, em cada ciclo de trabalho, o serviço deve estar completo e pronto para ser implementado no mercado. No caso da primeira empresa, uma equipe de três a nove pessoas pode desenvolver uma campanha publicitária em poucas semanas, comprometendo-se com o trabalho e entregando ao solicitante a campanha desejada, sem romper, é claro, a interação com seu patrocinador (sponsor).

Já para a segunda empresa, tem-se a criação de um novo produto, a qual requer mais que quatro semanas de trabalho para a sua finalização. Neste caso, a empresa pode, a cada ciclo, entregar parte do produto a seus patrocinadores e ter dentro de poucos meses um produto completo e comercializável.

Apesar dos exemplos acima, cabe ressaltar que a abordagem deste artigo não é explicar detalhadamente o Scrum, mas sim apresentar duas possibilidades de trabalho para sua aplicação, através de equipes de trabalho auto- organizadas e auto- gerenciadas, de forma a propiciar, assim, um resultado de alto valor agregado para a empresa.

Neste framework, são envolvidos todos os stakeholders do projeto, ou seja, os executivos, a gerência e também o Time Scrum, o qual conta com o Dono do Produto (responsável pelos itens do produto), com o Scrum Master (responsável por facilitar a implantação do Scrum) e com a Equipe de Desenvolvimento (responsável pelo desenvolvimento do produto por completo).

Para a aplicação do Scrum, é importante que se tenha uma avaliação e um estudo de sua implantação em cada caso particular, já que há uma mudança cultural na forma de trabalho, o que exige adaptação dos colaboradores. Independe do tipo de projeto elaborado, o Scrum pode ser uma ferramenta extremamente útil à sua empresa, por trazer resultados completos e com alto valor agregado em um curto espaço de tempo.

Artigo publicado originalmente em TI Especialista 

Referência

http://www.tiespecialistas.com.br/2015/10/scrum-uma-solucao-viavel-a-sua-empresa/

SPRINT PLANNING MEETING

O Sprint Planning Meeting é uma reunião na qual estão presentes o Product Owner, o Scrum Master e todo o Scrum Team, bem como qualquer pessoa interessada que esteja representando a gerência ou o cliente.

Durante o Sprint Planning Meeting, o Product Owner descreve as funcionalidades de maior prioridade para a equipe. A equipe faz perguntas durante a reunião de modo que seja capaz de quebrar as funcionalidades em tarefas técnicas, após a reunião. Essas tarefas irão dar origem aoSprint Backlog.

O Product Owner não precisa descrever todos os itens que estão no Product Backlog. Dependendo do tamanho do Product Backlog e da velocidade da equipe, pode ser suficiente descrever apenas os itens de maior prioridade, deixando a discussão dos itens de menor prioridade para o próximo Sprint Planning Meeting.

Coletivamente, o Scrum Team e o Product Owner definem um objetivo para o Sprint, que é uma breve descrição daquilo que se tentará alcançar no Sprint. O sucesso do Sprint será avaliado mais adiante no Sprint Review Meeting em relação ao objetivo traçado para o Sprint.

Depois do Sprint Planning Meeting, a equipe Scrum se encontra separadamente para conversar sobre o que eles escutaram e decidir quanto eles podem se comprometer a fazer no Sprint que será iniciado. Em alguns casos, haverá negociação com o Product Owner, mas será sempre responsabilidade da equipe determinar o quanto ela será capaz de se comprometer a fazer.

Referências

<http://scrumtrainingseries.com/SprintPlanningMeeting/SprintPlanningMeeting.htm>

<http://www.desenvolvimentoagil.com.br/scrum/sprint_planning_meeting>

Práticas em XP

     O objetivo principal do XP é levar ao extremo as práticas que são ditas como boas na engenharia de software. Estas práticas estão diretamente ligadas aos valores (comunicação, simplicidade, feedback e coragem) da metodologia. Estarei trazendo agora para vocês estas práticas e uma breve explicação de cada uma.

Versões Pequenas: Release é algo que é implantado no cliente, ou seja, está pronto para ser utilizado. As Releases normalmente são pequenas e frequentes (a cada 2-3 meses) sendo que funcionalidades prioritárias são desenvolvidas mais cedo para serem entregues mais rapidamente ao cliente, pois prioriza-se o que ele mais precisa no momento. Obviamente que algumas organizações não querem essas entregas frequentes e pequenas, pois precisam dar treinamentos antes do sistema ser entregue e isso leva um certo tempo ou então não faz parte da cultura organizacional. Nesse caso, se a organização não seguir isso não está seguindo realmente o que mandam as metodologias ágeis como o XP.

Jogo do Planejamento: Seu objetivo é determinar rapidamente o escopo da próxima Release, combinando prioridades do negócio e estimativas técnicas. Portanto no XP planejamos o tempo todo, diferente do que alguns pensam. Com um cliente presente ele define o escopo para a próxima Release. Dessa forma, define-se as features, prioridades e o escopo da release

Teste: A prática de teste no XP é bastante técnica, e envolve a presença do cliente no desenvolvimento e na validação de testes. O cliente compartilha com o desenvolvedor sobre o funcionamento do sistema. Os testes também se tornam as especificações da programação, visto que o teste diz o que deve estar de acordo e o que não deve estar de acordo, é como uma especificação.Os testes são escritos antes da funcionalidade, o que também é conhecido como TDD (Test-Driven Design) onde intercala-se a função de testar um pouco e codificar um pouco. Além disso, o TDD impõe o programador à saber o que deve ser verdadeiro no programa e o que não deve ser para que ele funcione corretamente, portanto, pensa-se primeiramente no problema e depois na solução. Dessa forma, os testes são automatizados, diferente de anteriormente onde o desenvolvedor fazia a implementação e entregava para alguém testar. Com os testes automatizados podemos executá-los a qualquer momento, e dessa forma, novas funcionalidade ou alterações podem ser imediatamente testadas para ver se essas mexidas não acarretaram outros problemas. Dessa forma, o teste impõem também confiança ao sistema e dão coragem para altera-lo, pois podemos saber imediatamente se algo introduziu um bug no sistema.

Programação em pares: Trata-se de duas pessoas trabalhando com UMA máquina onde um codifica, e o outro critica ou dá sugestões. Os pares trocam de lugar periodicamente. Essa prática é excelente e favorece comunicação e aprendizado. Com essa troca constante de ideias temos como resultado um Projeto de maior qualidade e como estudos comprovam temos maior produtividade e maior qualidade (com padrão de codificação e entendimento do código e partes do código que não eram entendidos). Essa prática também facilita aprendizado dos novos integrantes.

Projeto Simples: Projetos flexíveis são considerados uma defesa contra mudanças imprevistas no software, porém, projetos flexíveis também têm custos, tempo para desenvolvimento e manutenção, além de um código mais complexo e que muitas vezes nunca será utilizado.

O XP preconiza que a mudança é barata, pois ele utiliza ciclos curtos, projetos simples, refatorações, por isso mantém-se o projeto o mais simples possível, modificando-o quando for necessário suportar mais funcionalidade. Portanto, o XP diz que o melhor e mais simples projeto é aquele que passa em todos os testes, não contém duplicação de funcionalidade, salienta as decisões de projeto importantes e tem o menor número possível de classes e métodos.

Refatoração: A refatoração significa melhorar o código sem alterar sua funcionalidade. Antes de uma mudança sempre refatoramos o código para facilitar a realização de mudanças. Ou seja, se após a refatoração o código continua funcionando como anteriormente, incluímos as novas mudanças. A refatoração contínua possibilita manter um bom projeto, apesar das mudanças frequentes. O Projeto é uma atividade diária, de responsabilidade de todos.

Propriedade Coletiva: Todos podem modificar o código a qualquer momento. Códigos não pertencem a apenas uma pessoa. A melhor forma de evitarmos problemas como trocas de pessoas da equipe e com isso a perda de conhecimento é a propriedade coletiva, onde todos mexem em todas as partes do programa e conhecem de tudo um pouco.

Integração Contínua: Todo código deve ser integrado diariamente e todos testes devem passar antes e depois da integração. Se algum problema é encontra do ele deve ser corrigido imediatamente.

Cliente presente: Clientes devem estar presentes para escrevem testes de aceitação, definirem prioridades e histórias para as futuras iterações.

Semana de 40 horas: O XP preconiza que não se pode trabalhar horas extras por mais de uma semana, pois trabalho extra é sintoma de que algo está errado. Devemos manter um ritmo sustentável.

Padrões de Codificação: Todos mexem em todos os códigos, todos refatoram e todos trabalham em pares. Assim é interessante mantermos um padrão para termos algo solidificado. Por isso a melhor forma é a equipe definir um padrão de codificação sempre no início dos projetos.

Referências: http://www.devmedia.com.br/praticas-em-xp-extreme-programming/29330

Kanban: INTRODUÇÃO

Metodologias ágeis mais populares como Scrum e XP, surgiram com a proposta de melhorar e agilizar os processos envolvidos no desenvolvimento de software. Porém, no mundo real fica claro que os processos ainda não estão “perfeitos”. Mas o que fazer então, sendo que essas ferramentas estão, teoricamente, maduras e eficientes no que se propõe? Como identificar onde estão os “gargalos” que fazem as equipes falharem nos seus sprints? Podemos dizer com que o Kanban pode ajudar a identificar essas falhas e solucioná-las.

O método Kanban para desenvolvimento de software e processos ágeis tem como ênfase não sobrecarregar os membros que compõe a equipe de criação do produto e tem princípios básicos como: a equipe ou membro deve iniciar uma nova tarefa quando é capaz de realizá-la agora, a equipe deve aceitar mudanças incrementais e evolutivas estimuladas pelo método Kanban e respeitar os atuais processos, papéis e responsabilidades.

O Kanban não é um processo e nem descreve papeis e faces para serem seguidos. Podemos dizer que o Kanban é uma abordagem para mudança gerencial do projeto, um conceito para introduzir alterações em um ciclo de desenvolvimento de software ou gerenciamento de projetos.

O nome Kanban é de origem japonesa e sua tradução seria como “sinal” ou “cartão”. Portanto, vamos chamar de sinalizador ou melhor “registro visual”. O nome Kanban surgiu dos sistemas de cartão usados nas indústrias de produção, que tinham como finalidade o gerenciamento do fluxo de trabalho através da organização de desenvolvimento.

O Kanban, com seu mecanismo de sinalização, tem como objetivo apresentar uma atividade de trabalho em processo, ou seja, o número de atividades ou cartões em circulação é equivalente à capacidade do sistema.

A implementação do modelo Kanban se resume em três etapas que são:

• Visualizar os processos;
• Limitar o trabalho em processo do inglês WIP (work in progress);
• Gerenciamento do lead-time, ou seja, tempo que a atividade leva para passar por todas as fases até a sua entrega.

Continua no próximo post!

Referência:http://www.garcia.pro.br/EngenhariadeSW/artigosMA/A6%20-%2045-6-%20Kanbam.pdf  . Acessado em 16 de fevereiro de 2016.

O XP sendo aplicado

Olá pessoal, encontrei esse vídeo super legal sobre o XP. Nele vocês poderão perceber, por meio de uma peça teatral, como este método é aplicado nas empresas desenvolvedoras de softwares.

Os Valores e Princípios do Extreme Programming

    Como citado a alguns posts atrás, o Extreme Programming (XP) é um processo de desenvolvimento de software que adota os valores e princípios. Irei agora trazer agora o detalhamento de cada valor e principio deste método ágil.

VALORES

Comunicação: XP foca em construir um entendimento pessoa-a-pessoa do problema, com o uso mínimo de documentação formal e com o uso máximo de interação “cara -a-cara” entre as pessoas envolvidas no projeto. As práticas de XP como programação em pares, testes e comunicação com o cliente têm o objetivo de estimular a comunicação entre gerentes, programadores e clientes. 

Simplicidade: XP sugere que cada membro da equipe adote a solução mais fácil que possa funcionar. O objetivo é fazer aquilo que é mais simples hoje e criar um ambiente em que o custo de mudanças no futuro seja baixo. O objetivo dessa abordagem adotada por XP é evitar a construção antecipada de funcionalidades, como é feita em muitas metodologias tradicionais, que acabam muitas vezes nem sendo usadas. 

Feedback: Os programadores obtêm feedback sobre a lógica dos programas escrevendo e executando casos de teste. Os clientes obtêm feedback através dos testes funcionais criados para todas as estórias (casos de uso simplificados). O feedback é importante, pois possibilita que as pessoas aprendam cada vez mais sobre o sistema e assim corrijam os erros e melhorem o sistema. 

Coragem: Ela é necessária para que realmente se aplique XP como deve ser aplicado. Exemplos de atitude que exigem coragem são: alterar código já escrito e que está funcionando; jogar código fora e reescrever tudo de novo; e permitir código compartilhado por todos. Estes exemplos de atitudes podem ser necessários para trazer melhorias ao projeto e não devem ser evitadas simplesmente devido ao medo de tentá- las. 

PRINCÍPIOS

Feedback rápido: A idéia de XP é que os participantes de um projeto como clientes, programadores e gerentes devem estar sempre se comunicando para facilitar o aprendizado coletivo sobre o projeto que está sendo desenvolvido e de alertar rapidamente sobre dúvidas, riscos e problemas para facilitar eventuais ações de contingência. 

Assumir simplicidade: Todo problema deve ser tratado para ser resolvido da forma mais simples possível. XP afirma que se deve fazer um bom trabalho (testes, refactoring, comunicação) para resolver hoje os problemas de hoje e confiar na sua habilidade de adicionar complexidade no futuro quando for necessário. 

Mudança incremental: Quando muitas mudanças são realizadas todas de uma vez, não se obtém um bom resultado. Em vez disso, esse princípio de XP diz que as mudanças devem ser incrementais e feitas aos poucos. Os programadores têm a liberdade para estar sempre fazendo alterações de melhoria no código e as mudanças de requisitos são incorporadas de forma incremental. 

Abraçando mudanças (Embracing Change): XP procura facilitar o ato de incluir alterações através do uso de vários princípios e práticas. A idéia de XP é a de que mudanças devem ser sempre bem vindas independentemente do estágio de evolução do projeto. Isso é muito benéfico em projetos cujos requisitos são bastante voláteis devido aos clientes não saberem o que querem. 

Trabalho de qualidade: Em XP, qualidade não é um critério opcional, mas sim obrigatório. Embora a definição de qualidade possa variar de pessoa para pessoa, XP trata qualidade no sentido de se ter um sistema que atenda aos requisitos do cliente, que rode 100% dos casos de teste e que agregue o maior valor possível para o negócio do cliente.

Referências

http://www.cin.ufpe.br/~gamr/FAFICA/Desenvolvimento%20de%20sistemas/XP.pdf

O que é o Product Backlog?

Product Backlog

O Product Backlog é uma lista contendo todas as funcionalidades desejadas para um produto. O conteúdo desta lista é definido pelo Product Owner. O Product Backlog não precisa estar completo no início de um projeto. Pode-se começar com tudo aquilo que é mais óbvio em um primeiro momento. Com o tempo, o Product Backlog cresce e muda à medida que se aprende mais sobre o produto e seus usuários.

Durante o Sprint Planning Meeting, o Product Owner prioriza os itens do Product Backlog e os descreve para a equipe. A equipe então determina que itens será capaz de completar durante a Sprint que está por começar. Tais itens são, então, transferidos do Product Backlog para o Sprint Backlog. Ao fazer isso, a equipe quebra cada item do Product Backlog em uma ou mais tarefas do Sprint Backlog. Isso ajuda a dividir o trabalho entre os membros da equipe. Podem fazer parte do Product Backlog tarefas técnicas ou atividades diretamente relacionadas às funcionalidades solicitadas.

Referências:

<http://www.desenvolvimentoagil.com.br/scrum/product_backlog>

<http://scrumex.com.br/blog/?p=1091>

Scrum - Aprenda Scrum em 9 minutos

Reuniões Diárias - Daily Scrum

A cada dia do Sprint a equipe faz uma reunião diária, chamada Daily Scrum. Ela tem como objetivo disseminar conhecimento sobre o que foi feito no dia anterior, identificar impedimentos e priorizar o trabalho a ser realizado no dia que se inicia.

Os Daily Scrums normalmente são realizadas no mesmo lugar, na mesma hora do dia. Idealmente são realizados na parte da manhã, para ajudar a estabelecer as prioridades do novo dia de trabalho.

Todos os membros da equipe devem participar do Daily Scrum. Outras pessoas também podem estar presentes, mas só poderão escutar. Isso torna os Daily Scrums uma excelente forma para uma equipe disseminar informações sobre o estado do projeto.

O Daily Scrum não deve ser usado como uma reunião para resolução de problemas. Questões levantadas devem ser levadas para fora da reunião e normalmente tratadas por um grupo menor de pessoas que tenham a ver diretamente com o problema ou possam contribuir para solucioná-lo. Durante o Daily Scrum, cada membro da equipe provê respostas para cada uma destas três perguntas:

• O que você fez ontem?
• O que você fará hoje?
• Há algum impedimento no seu caminho?

Concentrando-se no que cada pessoa fez ontem e no que ela irá fazer hoje, a equipe ganha uma excelente compreensão sobre que trabalho foi feito e que trabalho ainda precisa ser feito. O Daily Scrum não é uma reunião de status report na qual um chefe fica coletando informações sobre quem está atrasado. Ao invés disso, é uma reunião na qual membros da equipe assumem compromissos perante os demais.

Os impedimentos identificados no Daily Scrum devem ser tratados pelo Scrum Master o mais rapidamente possível.

O que é o Scrum Master?

Scrum é uma metodologia ágil para gestão e planejamento de projetos de software.

O Scrum Master procura assegurar que a equipe respeite e siga os valores e as práticas do Scrum. Ele também protege a equipe assegurando que ela não se comprometa excessivamente com relação àquilo que é capaz de realizar durante um Sprint.

O Scrum Master atua como facilitador nas reuniões diárias e torna-se responsável por remover quaisquer obstáculos que sejam levantados pela equipe durante essas reuniões.

O papel de Scrum Master é tipicamente exercido por um gerente de projeto ou um líder técnico, mas em princípio pode ser qualquer pessoa da equipe.

No Scrum, os projetos são divididos em ciclos (tipicamente mensais) chamados de Sprints. O Sprint representa um Time Box dentro do qual um conjunto de atividades deve ser executado.Metodologias ágeis de desenvolvimento de software são iterativas, ou seja, o trabalho é dividido em iterações, que são chamadas de Sprints no caso do Scrum.

As funcionalidades a serem implementadas em um projeto são mantidas em uma lista que é conhecida como Product Backlog. No início de cada Sprint, faz-se um Sprint Planning Meeting, ou seja, uma reunião de planejamento na qual o Product Owner prioriza os itens do Product Backlog e a equipe seleciona as atividades que ela será capaz de implementar durante o Sprint que se inicia. As tarefas alocadas em um Sprint são transferidas do Product Backlog para o Sprint Backlog.

O objetivo é disseminar conhecimento sobre o que foi feito no dia anterior, identificar impedimentos e priorizar o trabalho do dia que se inicia.

Ao final de um Sprint, a equipe apresenta as funcionalidades implementadas em uma Sprint Review Meeting. Finalmente, faz-se uma Sprint Retrospective e a equipe parte para o planejamento do próximo Sprint. Assim reinicia-se o ciclo. Veja a ilustração abaixo:

7 Hábitos dos Scrum Masters Altamente Eficazes

Os Sete Hábitos das Pessoas Altamente Eficazes é um Best Seller escrito por Stephen R.Covey, que já ajudou diversas pessoas pelo mundo a tornarem-se mais produtivas, eficientes e descobrirem que semeando hábitos é possível colher resultados inesperados.

O Livro resume os 7 hábitos descritos abaixo:

1. Seja Proativo;
2. Começar com o objetivo em Mente;
3. Primeiro o Mais Importante;
4. Mentalidade Ganha-Ganha;
5. Procure Primeiro Compreender, Depois ser Compreendido;
6. Criar Sinergia;
7. Afinar o Instrumento.

Estes hábitos são plenamente aplicáveis para os Gerentes de Projetos Ágeis ou Scrum Masters, como segue:

Hábito 1: Seja Proativo

A meta do Scrum Master deve ser de dar autonomia para o Scrum Team fazer o que precisa ser feito e ainda remover os impedimentos.

Como Scrum Master você deve ser proativo o suficiente não esperando o time comunicar impedimentos, se você já puder proporcionar um bom ambiente de trabalho com clareza no que é preciso ser feito. Vá em frente.

Faça as Daily Scrum (Diariamente, sem procrastinar)

Você deve rodar as Daily Scrum para oferecer a oportunidade ao Scrum Team de relatar o progresso e os respectivos obstáculos.

Nestes 15 minutos, especialmente nas primeiras reuniões, aja como facilitador, talvez até tentando extrair as informações do time. Com o tempo isso será natural.

Hábito 2: Começar com o objetivo em Mente

O objetivo final de um Sprint é a entrega de um produto com alta qualidade, de acordo com aquilo que foi solicitado pelo cliente.

A Visão é o documento que vai te ajudar a perceber tudo o que é esperado neste projeto. A Expectativa do seu cliente, e em alguns casos do cliente do seu cliente, claramente aparecerão na visão do produto.

Torne a visão conhecida pelo ScrumTeam, esclareça eventuais dúvidas junto ao Product Owner e compreendam com exatidão aquilo que se espera alcançar com este produto.

Antes de iniciar o desenvolvimento do produto, comece com uma lista de critérios mínimos de qualidade, também conhecida como Definition of Done ou DoD. Este processo vai ajudá-lo a vislumbrar quais são os respectivos critérios de qualidade que todo o time vai seguir ao entregar um produto.

Hábito 3: Primeiro o Mais Importante

Isso faz parte da essência do Scrum!

E é um dos motivos que faz da abordagem ágil muitas vezes mais vantajosa do que a tradicional.

Todo o esforço de desenvolvimento deve ser priorizado, permitindo assim maior foco naquilo que tem mais importância.

O Product Owner é o responsável por ajudar na definição destas prioridades.

O Product Backlog priorizado em harmonia com o planejamento adequado do Sprint garantem que o mais importante seja entregue primeiro e com isso o nível de percepção da qualidade do seu cliente só irá aumentar.

Hábito 4: Mentalidade Ganha-Ganha

O ambiente de desenvolvimento de projetos possui uma série de desafios, especialmente no que tange à comunicação.

A mentalidade ganha-ganha é uma abordagem que só trás benefícios, tanto para a equipe do projeto, como para os demais stakeholders.

Abordagem Ganha/Perde – Neste cenário se o seu time ganha, quem perde é seu cliente. Um exemplo disso é não cumprir com a Definition of Done somente para cumprir o prazo do Sprint e acabar entregando um produto com defeitos.

Abordagem Perde/Ganha – Um exemplo deste cenário é quando mais trabalho é imposto para o ScrumTeam, além daquilo que eles orçaram e se comprometeram no planejamento, apenas para agradar o cliente.

Abordagem Ganha/Ganha – O que é combinado não sai caro e ainda assim surpreende. Normalmente quando os sprints são desenvolvidos com priorização adequada e o progresso é relatado aos stakeholders de modo claro (por exemplo usando Kanban e Burndown Charts) todo mundo sai feliz.

A abordagem ganha-ganha é a mais adequada para o mundo de projetos ágeis.

Hábito 5: Primeiro Compreender, Depois ser Compreendido

Muitos de nós podem ter o mau hábito de bloquear as conversas e não permitir a livre comunicação nos times.

Isso pode ocorrer muitas vezes pelo fato de que o Product Owner quer desesperadamente impor sua opinião, esquecendo que a escuta ativa e a auto-organização são as chaves para a condução adequada de um projeto ágil.

Além das Daily Scrum, ao longo do projeto procure promover a comunicação, solicite a participação do time no Sprint Planning.

Promova as discussões no Sprint Review e Colete o Feedback na Retrospectiva.

Você só tem a ganhar e sua imagem como líder do projeto será cada vez mais sólida.

Hábito 6: Crie Sinergia

Sinergia é alcançada por meio de um alinhamento entre o ScrumTeam e o Scrum Master.

Uma forma de promover isso claramente é utilizando ferramentas de compartilhamento de informação, de modo que todos estejam sempre na mesma página.

Utilize um Calendário Compartilhado (e.g: Google Calendar), uma ferramenta de Tarefas (eg.: Wunderlist), Gestão de Documentos (eg.: Dropbox) e outras ferramentas que possam promover a sinergia.

Hábito 7: Afinar o Instrumento

Equipes ágeis produtivas estão sempre fortalecendo suas habilidades e adoram aprender novas técnicas, melhorias práticas e a vivência com cases práticos.

Um treinamento para todo o time somente tem a contribuir com o desempenho da equipe e ainda vai oferecer uma gama de oportunidades de motivação e de entrega de produtos com qualidade mais apurada.

A busca por afiar o instrumento deve ser uma constante, garantindo assim um time de alta performance.

Treine sua equipe nos fundamentos do método ágil e prossiga com tópicos focados visando atender às necessidades específicas do seu projeto.

Parafraseando a citação de Stephen R.Covey, autor do besteseller ‘Os 7 Hábitos das Pessoas Altamente Eficazes':

“Plante um pensamento, colha uma ação; plante uma ação, colha um hábito; plante um hábito, colha um caráter; plante um caráter, colha um destino.”

* Denis Pedro é Mentor & Advisor da MindMaster Treinamentos. Este artigo foi publicado originalmente pela MindMaster.

Referências: 

,

<http://www.mindmaster.com.br/7-habitos/>