Olá! No post de hoje falarei sobre a adaptação – o terceiro pilar, que em conjunto com a transparência, que citei no post Os Pilares do Scrum: Transparência e com a inspeção onde comentei no post Os Pilares do Scrum: A inspeção, fazem o processo de gerenciamento de projeto muito mais saudável, fácil de detectar eventuais desvios e evita retrabalho, sempre tentando agregar o máximo de valor ao cliente.

    As características da adaptação estão fortemente presentes no processo Scrum através das cerimônias do Scrum e na estipulação do timebox das Sprints.

    Na duração das Sprints, o timebox é relativamente pequeno, de aproximadamente duas semanas, em relação ao processo prescritivo de desenvolvimento. Isso permite que os pilares do Scrum dêem um retorno mais rápido do que está sendo feito. Se o que está sendo feito agregar algum valor ou se não agregar valor para o cliente, o processo é rapidamente reajustado através das demais práticas do Scrum.

    Já as reuniões diárias servem para sinalizar a todos os membros da equipe o progresso do dia anterior, a existência de impedimentos e para traçar uma estratégia de curto prazo para o dia que se segue. Sendo caracterizada como uma adaptação, ao nível da Sprint, com o objetivo de se adaptar para chegar à meta estabelecida.

    No caso dos desvios em relação à meta do projeto, a transparência que a reunião de revisão fornece junto com a inspeção que é feita pelo Product Owner, a tendência é que o P.O. repriorize o Product Backlog, o que também é considerada uma forma de adaptação, desse modo alterando a estratégia do que será feito nas próximas Sprints e retomando o caminho certo.

    Um outro tópico muito importante sob o ponto de vista da adaptação é a reunião de retrospectiva. Nela, a adaptação é feita no aspecto da equipe, corrigindo possíveis problemas que estão ocorrendo internamente, reorganizando a dinâmica da equipe. Sob o meu ponto de vista, essa é uma das adaptações mais importantes, pois se a equipe não estiver organizada, o esforço para se finalizar uma Sprint será muito maior.

   Esse é o último post da trilogia dos Pilares do Scrum. Meu enfoque foi em como os Pilares do Scrum estão presentes em todos os artefatos e cerimônias do Scrum, e como é importante dar a devida atenção a todos os detalhes que estão por trás, para que o gerenciamento do seu projeto seja o mais consistente possível.

The post Os Pilares do Scrum: Adaptação appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.

No meu primeiro post sobre os pilares do Scrum, eu falei sobre a importância da transparência para o processo, que junto com a inspeção se torna uma grande aliada para gerenciar o trabalho e evitar desperdícios.​

A inspeção do produto é uma prática muito importante e que deve ser levada em consideração para todo e qualquer processo que deseja ser bem sucedido. Se feita com a frequência correta, ela dá a possibilidade de identificar rapidamente qualquer desvio sobre a meta que deve ser atingida e ainda garante que o valor agregado ao cliente possa ser medido e aprimorado junto com a adaptação, que é o terceiro pilar do Scrum.

No Scrum a reunião de revisão se apoia nesse pilar, fazendo com que o incremento de produto, resultante da Sprint, seja apresentado pela equipe de desenvolvimento e inspecionado pelo P.O que, dependendo do combinado em relação a definição de história pronta, aprova ou reprova as histórias implementadas. No post da Paula, "O que é Reunião de Revisão?"  é explicado em detalhes a contribuição que a reunião de revisão dá ao processo.

O Scrum Guide tem a seguinte definição para a inspeção:

​Scrum users must frequently inspect Scrum artifacts and progress toward a goal to detect undesirable variances.

Os usuários do Scrum devem, frequentemente, inspecionar os artefatos Scrum e o progresso em direção ao objetivo, para detectar indesejáveis variações.

Isso quer dizer que o processo inteiro deve ser inspecionado constantemente para evitar desvios, não apenas o produto em si através das reuniões de revisão, mas a dinâmica da equipe também deve ser inspecionada, e é claro que apenas pelos membros da própria equipe e pelo Scrum Master, na reunião de retrospectiva.

O fato da dinâmica da equipe ser inspecionada através da reunião de retrospectiva, faz com que problemas que estejam ocorrendo dentro da equipe sejam resolvidos. No entanto nem sempre há uma solução de imediato, só que o problema precisa ser conhecido para poder se encontrar uma solução à posteriori. Isso evita que o atrito da equipe atrapalhe o andamento do processo.

Uma outra citação muito importante é:

 Their inspection should not be so frequent that inspection gets in the way of the work.

 Esta inspeção, não deve no entanto, ser tão frequente que atrapalhe a própria execução das tarefas.

É dessa forma que o timebox das cerimônias são estabelecidos para respeitar essa ideia: são 15 minutos para as reuniões diárias (independente do timebox da Sprint) e em Sprints de 2 semanas são 2 horas para cada uma das outras reuniões (revisão, planejamento 1 e 2 e retrospectiva) ou 1 hora em Sprint de 1 semana.

Citei apenas algumas das razões que fazem a inspeção ser um dos pilares para tornar o processo mais produtivo, evitando desgastes e desperdícios, mas existem muitas outras ações que podem ser seguidas e que vou falar no meu próximo post, sobre o pilar da adaptação.

Referências:

• Scrum Guide

The post Os Pilares do Scrum: Inspeção appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.

Olá, hoje iremos falar um pouco sobre os pilares Scrum. Um assunto de grande importância para quem ainda não conhece ou quem ainda possui dúvidas sobre o framework Scrum. Assim como as demais métodologias ágeis, o Scrum é um processo empírico, e suas práticas são fortemente apoiadas sobre os três pilares que vou falar mais detalhadamente, que  são: Trasparência, Inspeção e Adaptação. O pilar que iremos abordar hoje é o da Transparência.

Este é com certeza um dos conceitos mais difíceis de ser implementados, principalmente quando o Scrum está sendo adotado por equipes habituadas a métodos tradicionais de gestão de projetos.

O Scrum Guide tem a seguinte definição para a transparência no Scrum:

“Significant aspects of the process must be visible to those responsible for the outcome. Transparency requires those aspects be defined by a common standard so observers share a common understanding of what is being seen.”

“Aspectos significativos do processo devem estar visíveis aos responsáveis pelos resultados. Esta transparência requer aspectos definidos por um padrão comum para que os observadores compartilharem um mesmo entendimento do que está sendo visto.”

Isso quer dizer que todas as pessoas interessadas no produto, através dos papéis do Scrum precisam ter uma visão comum e clara do processo inteiro, isso nos leva a reforçar que os conceitos de história pronta e história preparada do Scrum são muito importantes sobre este ponto de vista.

E uma das cerimônias que ajudam a tornar transparente o trabalho feito durante a Sprint, entre os integrantes da equipe de desenvolvimento é a reunião diária, que foi explicada nesse post do Marcelo Arêas. A reunião diária não é só uma forma de comunicação e transparência entre os membros da equipe de desenvolvimento mas também ajuda a traçar a estratégia de curto prazo da equipe.

Uma outra ferramenta bastante utilizada para dar transparência é o Kanban, ele não é um artefato do Scrum mas é sempre bem vindo para transparecer o trabalho que está sendo feito e podendo se estender à todo ciclo de vida da Sprint, desde tarefas que não ainda não foram feitas até aquelas que já foram testadas e estão prontas para liberação, esse post do Daniel Pereira, melhor define a importância do uso do Kanban no Scrum.

Enfim, através desses exemplos espero ter convencido de que a transparência é um conceito chave na gerência de um projeto, não sendo limitado as métodologias ágeis. E ter visibilidade do projeto acaba evitando retrabalhos e insatisfação com relação ao produto que está sendo construído.

The post Os Pilares do Scrum appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.

• Acerto/correções de bugs que são reportados por clientes e que são prioridade para o P.O.;
• Problemas de infra-estrutura;
• Atendimento ao suporte e outros mais.

Essas tarefas podem ou não ser de conhecimento do P.O., mesmo assim não podem ser negligênciadas e acabam afetando o andamento de outras histórias da Sprint.

Para que esse trabalho "extra" não seja ignorado é recomendado que histórias sejam incluídas na Sprint, caso o planejamento da mesma não tenha sido previsto. Isso também favorece de forma que tais tarefas "extras", não influenciem na velocidade da equipe e dar a falsa impressão de improdutividade.

Outros pontos onde podemos evitar as interrupções são nas cerimônias do Scrum. Se há perda de foco que cause atrasos nas reuniões de início e final de Sprint, que possuem timebox de 2 ou 4 horas, haverá atrasos em cascata e com reuniões mais longas a tendência é serem menos produtivas por cansaço e estresse.

Para evitar esse problema é imprescindível que o Scrum Master, como facilitador e defensor do processo Scrum intervenha de forma a fazer com que as reuniões não percam o foco principal.

É sempre possível reduzir a perda com simples ações mas é claro que as interrupções podem ocorrer durante o desenvolvimento em si já que na área de T.I. é muito comum fazermos dezenas de coisas ao mesmo tempo e com isso perdemos o foco. Mas se as interrupções estão afetando as entregas combinadas pela Equipe é preciso avaliar a situação e fazer as adaptações necessárias no processo, já que é um dos princípios do Manifesto Ágil (At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly), como foi visto nesse post sobre o 12º Princípio do Manifesto Ágil – Retrospectiva da Ester Lima.

The post Tratando as interrupções que afetam a Equipe Scrum appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.

A equipe de desenvolvimento de um projeto Scrum deve ser uma equipe auto-organizada e multidisciplinar, composta por sete mais ou menos dois integrantes. Equipes com mais membros necessitam de mais esforço para se coordenarem.

Dizer que a equipe é multidisciplinar significa que todos os integrantes detêm as competências necessárias para realizar todas as histórias de uma determinada Sprint, os membros podem se , tendo cada membro da equipe contribuído com o trabalho na Sprint. O que é diferente de termos equipes com cada membro possuindo diferentes conhecimentos (Designers, Desenvolvedores, DBA’s, etc…) e trabalhando no desenvolvimento do mesmo produto.

Ter membros altamente especialistas na equipe ou múltiplas equipes com dependências entre si no mesmo projeto não é ideal por causa de gargalos que podem surgir durante o desenvolvimento, reduzindo e impactando no desenvolvimento do produto. Um desses problemas é que se temos equipes que geram entradas para a Sprint de outra(s) equipe(s), problemas de atraso na entrega de funcionalidades ao final da Sprint podem impactar seriamente na Sprint de outras equipes.

O modelo de equipe multidisciplinar e auto-organizada terá muito mais facilidade para agregar valor ao produto, com rápida adaptação à mudança de requisitos e ao desenvolvimento vertical que é um dos focos das métodologias ágeis. Com o desenvolvimento vertical uma determinada funcionalidade do produto pode ser desenvolvida numa Sprint, passando por todas as camadas, desde a camada de persistência até a camada de apresentação. A Equipe de desenvolvimento tem toda a liberdade na forma de implementação da história, isto é, nem o Scrum Master e nem o Product Owner poderão ditar como ela deve ser feita mas isso não significa que eles não possam ajudar a validar eventuais dúvidas que forem surgindo.

Com todas essas qualidades a Equipe de desenvolvimento é uma equipe que consegue agregar mais valor ao produto devido à dinâmica de trabalho. Ela realiza esse trabalho fazendo sua própria organização e planejamento, do mesmo modo que na reunião de Planning 1 é dito pelo P.O o que deve ser feito, na reunião de Planning 2 a equipe diz como vai ser feito. Isso tudo sem deixar a responsabilidade e o comprometimento com o produto, que é o se espera de Equipe de desenvolvimento Scrum.

The post Equipe de desenvolvimento Scrum: Uma equipe auto-organizada e multidisciplinar appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.