Gerenciamento de Projeto com Metodologias Ágeis

Diante dos desafios de gerenciar projetos, convido todos a observar porque o modelo em cascata já não é tão adequado a nossa realidade. E observar os outros tantos aspectos do Scrum.

Guia do Scrum

Sempre que tiver dúvidas, tenha em mãos o guia do scrum.

Primeiro pensamento importante que deve manter na sua cabeça é que o Scrum é para todos, e não somente para profissionais de TI, ou departamentos de TI.

Scrum não é uma metodologia, é um framework.

As variáveis do gerenciamento do projeto são definidas pelo seu ambiente

O que são projetos? Essa é uma pergunta que talvez muito de nós não façamos. Mas e ai, pensou? O que são projetos?

Como podemos definir o que é um projeto? Temos 3 elementos que podemos pensar, para primeiro definir se estamos lidando com um projeto, ou não:

• Um projeto tem começo, meio e fim
• Um projeto é temporário.
• Um projeto tem um objetivos de criar produto ou serviços e/ou trazer resultados novos e diferentes.

E o que não é projeto? Bom, o que não é projeto é operação:

• Rotinas
• Operações diárias (ex: fechar o caixa, gerar balancete, etc)
• Resolução de negócios e adaptações ao ambiente (Integração continua é um ótimo exemplo)

Operações e Projetos

Operação: Dia-a-dia, manutenção e processos elaborados para trazer o resultado planejado no projeto em uma visão macro. A operação é que vai trazer agilidade, mas vale lembrar que agilidade só vem com a descoberta de rotinas no decorrer do desenvolvimento do projeto.

Projeto:
Inovação, resgate de resultado e a busca do melhor caminho para uma operação funcionar. Também influencia diretamente na organização e capacidade de adaptação para os desafios futuros.

Itens que considero que devem ser primordiais na influência da organização e capacidade de adaptação que possa trazer sucesso a um projeto (seu fim ou alcançar o objetivo)

• Agilidade
• Gestão de Projetos
• Integração Continua

Vamos ao Manifesto ágil

No ano de 2001, em Fevereiro eu ainda estava iniciando timidamente no mundo do desenvolvimento, enfiando tabelas em sites, e coisas do tipo (não lembro se era isso que eu fazia realmente ☺ ). Enquanto isso acontecia, uns caras muito bons naquilo que faziam se reuniram para apresentar um documento. Se chamava Agile Manifesto

Para ser mais especifico, foram 17 membros de uma comunidade mundial de desenvolvimento de software que discutiram, entre outras atividades, apresentaram um documento que apresenta boas práticas adotadas por cada profissional no desenvolvimento dos seus trabalhos.

Foram colocadas questões em mesa que caracterizavam fatores para o sucesso dos projetos de software que esses membros tinham atuado, em diversos momentos de suas carreiras. Muito do comportamento e ações dos profissionais eram comuns, e chamando a atenção para esses fatos nos desempenho dos projetos:

• Indivíduos e interações mais que processos e ferramentas
• Software que funciona mais que documentação abrangente
• colaboração do cliente mais que negociação do contrato
• respostas as mudanças mais que seguir um plano

O que mais é priorizado são indivíduos, softwares e colaboração com o cliente para ter respostas as mudanças mais rápido. Porem não esquecemos os valores dos processos e ferramentas nos trazem, e negociação do contrato e seguir um plano, não é tão prioritário seguir um plano se ele não faz o sentido, não é mesmo?

Negociar um contrato que corre o risco de nem se concluir não é uma prioridade. Fazer o contrato dar certo deveria ser a prioridade.

Diante de cenários diferentes, entre projetos dolorosos e custosos, o método em cascata de se gerenciar projetos vem sendo abandonado cada vez mais.

Uma de suas falhas é que em sua natureza, toda e qualquer absorção de mudanças rápidas do escopo e das regras do negócio é difícil, custosa e muitas vezes impossível. Diante disso, prova-se que o modelo em cascata não apresenta uma solução para a colaboração do cliente e ciclos de feedback. Falta adaptabilidade nesse modelo de cascata, e o torna uma péssima opção para projetos dinâmicos.

“Times com hierarquia em pirâmide não funcionam em tecnologia, profissionais da informação não oferecem mão de obra física e sim intelectual.”

Foi proposta uma equipe de valor. As pessoas ficam ao lado uma das outras, e não acima uma das outras. Já passou da hora de esquecer essa ideia de pirâmide um tanto quanto feudal. Não precisamos de nenhum rei, nem rainha do projeto. Precisamos gerar valores e o mais importante, entrega-los a nossos clientes.

A proposta do time de valor veio mudar isso, e criar papéis. Papéis como o Product Owner, o Scrum Master e seu time de desenvolvimento (modelo mais focado para tecnologia).

Em sua essência, o Scrum busca conceitos de time-box, desenvolvimento iterativo e incremental, gerando valor em cada entrega. Agrega valores científicos e filosóficos como Lean Empírico e T.a.C e a teoria da complexidade.

Uma vez que não estamos mais ligados a uma chefia direta, podemos desenvolver uma nova organização. Nos livrar das heranças que não funcionam ou não se enquadram em nossas necessidades.

Entenda Incremental x Iterativo

Incremental é: Construir pedaços, mas mantendo uma visão do todo.
Imagine um quadro cortado em 4, e cada pedaço desse quadro é preenchido um por sua vez.

Iterativo é: Rascunha, valida e ajuda. Antes criamos os contornos, um primeiro esboço para melhorar nossas idéias e o formatos aplicados.

Após isso validamos se estamos no caminho certo, e continuamos a transformar o produto em busca dos nossos novos objetivos e resultados a serem alcançados e ajustados com nossa realidade.

Aplicamos as cores até que tudo esteja preenchido (gerando resultado, nada parcial). O resultado é o objetivo, e não todos os aspectos envolvidos executados com máxima perfeição ou respeitando todos os requisitos. Isso é valor.

Benefícios dos projetos ágeis

• Maior visibilidade da execução dos projetos.
• Maior previsibilidade dos resultados.
• Maior produtividade.
• Melhor qualidade do produto
• Melhorar habilidade para gerenciar complexidade.
• Melhor ambiente de trabalho e satisfação das pessoas envolvidas.
• Atender a necessidade é uma busca constante da evolução do nosso processo atual.
• Atingir resultados esperados.

Scrum é fácil de entender, os conceitos são simples, mas a prática é zero. Aqui onde aplicamos o Lean Empírico. É preciso que a equipe veja os objetivos e a visão para que uma cultura não seja imposta, e sim implantada.

Não é bom ter o escopo fechado, e sim a visão do resultado que quer obter.

Te proponho a seguinte reflexão:

Ao ir ao médico, por meio de observação e exames, ele entende o problema e propõe soluções para o problema. Agora proponho para você que é um profissional da informação, pense assim também.

Vamos entender a visão do problema, e ai sim vamos propor soluções para essa doença; Entender o problema, vai permitir que as definições de prioridades mais importantes que geram valor mais agregado ao negócio venham acontecendo naturalmente. Coisas que fazem sentido são muito mais propostas, e a interatividade de todo o grupo com isso também aumenta.

O escopo não pode ser fechado, porém sua visão a respeito da solução ou resultado sim. Ou seja, minha visão é solucionar uma dor no peito. O meu escopo pode ser adaptável dependendo do diagnóstico (problema cardiaco, pulmões, gases, etc). Ou seja, para cada problema, há uma uma solução adequada, mas isso depende do seu diagnóstico.

É preciso adaptar o escopo a uma realidade verdadeira do projeto. É preciso transferir entre todos da equipe e inclusive com o cliente, a responsabilidade do compartilhamento de todas as informações, transferindo responsabilidades aos papéis que devem existir no projeto. Pois é a equipe que sabe como faz para curar, mas o cliente que sabe onde dói mais.

O que é o Scrum?

Projeto ad-hoc — Quando inovamos mas não temos a expertise de inovação, pois não é nossa área de atuação.

Desafio: Transformar Requisitos em escopo, e transformar o escopo em Produto.

O processo atual é: Abstração do Problema -> Desenvolvimento-> Produto Final.

Vamos rever isso tudo?

A vida está exigindo novos meios de se realizar e entregas resultados, elas, as equipes vão precisar possuir ou desenvolver novas habilidades para solucionar os novos problemas:

• Auto gerenciável
• Todos participam das escritas das regras em comum
• Multifuncional completo.

O Framework

O Scrum é um framework com processos, papéis especificos e artefatos. É um framework pequeno e enxuto. Por isso as vezes precisamos trazer recursos externos para complementar o que nos falta.

O foco no gerenciamento é sempre importante, porem não deve influenciar na engenharia. As escolhas e opções são de total controle dos profissionais das suas áreas especificas, e não de quem nos escreve a necessidade (cliente).

O framework mantém o seu foco com o maior valor de negócio possível e sempre em menor tempo possível, maximizando o gerenciamento e otimizando a entrega no menor tempo possível. Gerando Valor.

Construimos incrementalmente e vamos nos adaptando as mudanças que vão ocorrer e não podemos prever. Para que esse item seja superado é necessário que as equipes tenham a liberdade e se auto-gerenciam, e que aprendam a fazer isso com a ajuda de todos.

Pois todos da equipe se comprometem com o resultado, e buscam a se ajudar para que o resultado seja entregue, automaticamente a equipe apoia seus membros mais fracos e não compromete o resultado da Entrega. Scrum também é importante pois distribui responsabilidades e soluções a seus papéis mais próximos. Cliente é cliente, programador é programador, e por ai vai.

Engenharia tradicionais colocam grande ênfase em projetar antes de construir. Funciona muito bem pois segue uma lógica simples que não podemos colocar um teto, sem antes uma fundação. Então levantamos os requisitos, e produzimos uma parte, e planejamentos novamente, e vamos construindo mais. É o desenvolvimento em cascata. Pois antes todos os requisitos foram preenchidos como por exemplo: Terreno, numero de andares, burocracia, etc.

Então temos o planejamento, uma alteração do planejamento a cada fase avançada, e a entrega do que foi levantado e requisitado nos requisitos e o escopo.

Cascata

Requisitos -> Design -> Implementação -> Testes -> Disponibilização -> Suporte e Manutenção.

Quem usa Scrum?

Quem usa o scrum são pessoas que não querem mais o modelo de cascata. Heheh brincadeira, são pessoas que querem na verdade uma abordagem ágil e resultamos mais realistas para os cenários de seus problemas. Querem agilidade. Querem o controle do caos e de suas mudanças de necessidades diárias e que fazem parte do seu negócio. Crescer e aprender rápido define muito sobre o sucesso ou não sucesso de qualquer negócio.

Quem usa scrum é quem busca uma evolução e adaptações a mudanças e novas idéias suas e do próprio cliente, e na sua avaliação dos seus processos e melhorias. Quem usa Scrum busca evolução e a adaptação, duas coisas que andam sempre juntas. Não há evolução sem nenhuma mudança.

Características

Uma das características que apontariam que o scrum é ideal para seu projeto, quando sua realidade é modificada e seu escopo é modificado.

Alguns itens importantes das características do framework

• Não há prática nenhuma de engenharia prescrita;
• Não usamos mais nada que o necessário. Menos é mais. Acreditem;
• Metodologias encapsuladas como projeção, codificação e testabilidade durante o sprint;
• Tempo limitado e ênfase na comunicação;
• Trabalho em equipe exige flexibilidade. As pessoas acabam se tornando flexíveis. Decisões em equipes são sempre mais confiáveis do que o feeling de uma pessoa só;
• Não excluímos as opiniões pessoais, mas priorizamos as opiniões da equipe;
• Equipes de 06 a 10 membros;
• Equipes podem obter alto grau de maturidade em pouquíssimo tempo;

Quem pode usar o Scrum?

Todos desde que siga as premissas:

• Aceite trabalhar com o ciclo de vida iterativo-incremental.
• É necessário ter um ponto focal para o projeto, qual o resultado deseja trazer?
• Tenha uma equipe responsável, experiente, e capaz de ser auto-gerenciável.
• É possivel ter Scrum’s of Scrum’s. Dividir para conquistar ☺ ;

O Framework Scrum

• Papéis
• Artefatos
• Produto incrementado
• Cerimônia

Papéis

Imagine um projeto em uma fazenda, e no momento, apenas dois personagens, o porco e a galinha. Fazemos de conta que:

• O porco está comprometido com o projeto
• A galinha é apenas envolvida (observadora)

Analisando, temos vários porquinhos envolvidos: Temos o PO, o SM, e Dev Team.

Product Owners (Ou gerente de produtos, se preferir)

Product Owner vai fazer a sua macro gestão e analisar itens importantes da estratégia, fornecimento de material e prioridades. Sua Macro gestão é importante para o inicio do processo. Product Owner tem que travar a visão do cliente e trazer suas histórias fechadas com o nível de prioridade definido. O Product Owner tem que saber o que é importante agora e tem o poder de negociar possibilidades com o cliente e usuários;

O Product Owner é representante do cliente com ponto focal das demandas e entende o negócio, Define a visão e requisitos do produto. A definição do produto são também de sua responsabilidade, criando assim a visão e os requisitos do produto (parecido com o escopo e chamado aqui de visão).

A definição do que faz parte do projeto é também sua responsabilidade, e também é o responsável pela avaliação da aceitação dos pacotes de entrega. Poduct Owner também participa muito no Sprint Backlog. Ainda assim o aceite da entrega não quer dizer que a mesma coisa vai para produção ou entra em sí na integração final do produto.

Entregar para seu cliente o valor é o item mais importante do seu papel; Progete o cliente e seus objetivos;

Scrum Master

Scrum Master vai ficar responsável por desenrolar tudo, Vai gerenciar as pessoas e processos, estabelecendo assim um fluxo continuo das entregas e retirando impedimentos.

Processos e pessoas são sua responsabilidade, assim como o fluxo de comunicação e resolve problemas de sua equipe; A resolução de conflito do scrum master não intefere na macro-gestão. Ela ajuda pessoas e separa papeis que possa gerar conflito entre a hierarquia tradicional das empresas

É de papel do scrum master gerenciar sobre interferências externas e garante uma produtividade e o compromisso com a entrega que o time se responsabilizou;

O seu papel também da poderes de mediar/moderar reuniões diárias e auxilia em grande nivel a priorização dos requisitos disponiveis ou faltantes.

O Scrum master apenas auxilia no papel das priorizações, a definição é feita pelo Product Owner. Somente ajuda e opinião não conta no momento da priorização

Scrum master gerencia as pessoas, que executam os processos. Esse papel pode ser definido como servidor da equipe. E através do seu papel ele sugere melhorias, sendo o maior conhecedor dos processos. É importante o uso de técnicas de couching e outras técnicas políticas para que ocorra tudo bem.

Scrum master é o que mais conhece o Scrum em sua essência; ele precisa também precisa entender todos os processos, mas ele ajuda as pessoas a seguir em sua parte. E o lado humano é importante pois é um gestor ‘people-care’ e geralmente é um tech-líder e sabe lidar com políticas e social da empresa. Tornando ela a mais capacitada a ocupar esse papel dentro do framework.

Dev Team — Os seus engenheiros

Scrum Dev Team vai fazer o micro gerenciamento observando os comprometimentos estão sendo cumpridos com o resto da organização, explicando os impedimentos e absorvendo e explicando problemas e resolvendo e entregando

É geralmente composto pelas pessoas diretamente ligadas ao projeto e garante que o projeto seja entregue e com todas as funcionalidades necessárias.

Sua participação é na definição do objetivo do sprint, fazendo o que é necessário dentro das diretrizes pré estabelecidas do projeto a alcançar o objetivo proposto inicialmente no Sprint.

Dev Tem tem seu micro-gerenciamento e eles mesmos se cobram pelo seu trabalho e para isso, é utilizado a daily meeting para definir e expor os avanços, atrasos e a equipe começa a identificar os pontos fracos do processo e expõe esse problema.

Como a equipe mesmo se gerencia, existe cobranças implícitas nesse processo e separamos as galinhas dos porcos, filtrando os envolvidos e os observadores, dando o valor e peso necessário para o que e quem é importante em cada cenário de todo o processo.

O Scrum Team é quem define em quanto tempo, consegue cumprir os objetivos, definindo o objetivo no Sprint.

Os papéis do scrum são de grande importância e trás consigo a alma do framework. Sem os papéis o scrum torna-se irrelevante e confuso, pois mescla-se com outros aspectos de cultura ruim e gera diversos problemas;

Artefatos

O ciclo de vida do Scrum na sua essência implementa uma entrega continua, muito conhecido hoje em departamentos de tecnologia.

Iniciando o Product backlog

• Lista de requisitos do projeto a serem desenvolvidas (conhecido também como wish list)
• Pode ser alterado a cada sprint

Nesse momento as primeiras priorizações são as que mais trazem um resultado ao cliente, algum objetivo deverá ser cumprido. É costume alguns sprint’s iniciais demorarem mais que o normal

O Product Backlog é algo vivo, está em constante transformação, e suas priorizações devem mudar com frequência, em vista dos objetivos a serem alcançado;

Quando você perceber que seu product backlog está grande, e seu tempo não é tão grande. Lançamos mão do recurso chamado Release Backlog.

Release Backlog

Define na que entregas serão realizadas na versão do produto em trabalho.

A priorização e estimativas são mensuradas em entregas. E a partir do release Plan cria-se o Product Backlog. A prática de mercado atualmente é que a definição do release seja feita já dentro do Product Backlog

Agora temos dois artefatos completos e em andamento, vamos para o nosso terceiro artefato.

Sprint Backlog

• Lista de tarefas a serem realizadas no sprint
• Itens do sprint backlog são extraídos do release backlog e pela equipe. Com base nas prioridades definidas pelo P.O.
• A equipe determina a quantidade dos itens do product backlog e serão trazidos para o sprint backlog.

Boa parte das empresas usa post-it’s em quadros com atividades pendentes, em andamento e realizados. Existem ferramentas modernas e online que ajudam a equipe a ter essa mesma interface, mas virtual como o trello, Jira, Redmine e outros.

Burndown Graph

• Como o rendimento/andamento diário do projeto anda
• Mostra o tempo restante para conclusão de tarefas e algumas variações mostram o story point
• Permite projetar a data final do Sprint e até a release
• Mostra a velocidade do projeto

O burndown é uma soma do trabalho ou da quantidade do que falta, e sua queda, mostra os avanços e a aproximação do ponto final do projeto.

Permite verificações para ajustes de itens enquanto o trabalho é executado;

Daily Scrum

• Reunião deve durar no máximo 15 minutos e precisa ser resumida e sucinta
• Também conhecida como Stand Up meeting
• É realizada em frente ao Sprint Backlog
• Todos tem direito e obrigações de falar
• O SM e o facilitador e mediador
• Deve garantir que as 3 pergntas sejam respondidas
• Também deve resolver os impedimentos

Por Bruno Pereira, Diretor de Inovação da Mandic Cloud Solutions.

Gostou do conteúdo? Tem alguma dúvida? Entre em contato com nossos Especialistas Mandic Cloud, ficamos felizes em ajudá-lo.