Gestão de Projetos com SCRUM

Transcrição

1 Gestão de Projetos com SCRUM Av. Carvalho Leal, N Térreo Edifício Empresarial Objetiva Cachoeirinha. Tel (92)

2 SUMÁRIO FIGURAS... 4 Liderança Entendendo Coaching O que não é Coaching Facilitação Introdução a Agilidade Os Princípios do Manifesto Ágil Alguns Pontos Fundamentais sobre a Agilidade Metodologias Ágeis Produto do Ponto de Vista de Negócio ROI Declaração de Visão Estimativa Inicial Diferencial do Scrum História Como Ganhar essa Vantagem Competitiva E na prática, como isso funciona? O SCRUM O que é SCRUM Papéis ScrumMaster Product Owner Time Gerenciamento de Escopo e Valor Agregado ao Negócio Gerenciamento do Tempo

3 5.5. Fluxo de Trabalho Conceito de Sprint Sprint Planning Meeting Daily Scrum Meeting Sprint Review Meeting Sprint Retrospective Meeting Visibilidade, Inspenção e Adaptação Ajudando o Trabalho da Equipe através da Remoção Contínua de Impedimentos Definição de Pronto Melhoria Contínua Outros Conceitos PDCA Kanban

4 FIGURAS Figura 1 - Visão do Escopo do Negócio Figura 2 - Exemplo de Mapa Mental Figura 3 - Visão Geral do Processo Scrum Figura 4 - História do comprometimento x envolvimento Figura 5 ScrumMaster deve atuar como facilitador Figura 6 - Responsável pela Gestão do Product Backlog Figura 7 - Time Interdisciplinar Figura 8 - Framework Scrum na visão geral Figura 9 - Baralho de Planning Poker Figura 10 - Exemplo de um quadro KanBan Figura 11 - Gráfico de Burndown do Projeto

5 Liderança 1.1. Entendendo Coaching Toda pessoa busca em sua vida, profissional e particular, conseguir alcançar seus objetivos. Para isto, este indivíduo cria metas que irão ajudá-lo durante o seu percurso no alcance de tais objetivos. A meta, que em sua definição representa a maneira que escolhemos para chegar ao nosso objetivo, ajuda as pessoas a terem um norte, mas muitas vezes o caminho para alcançar estas metas é difícil. Neste ponto, o papel de coaching é essencial para ajudar o indivíduo a trilhar o caminho para o alcance das suas metas de uma forma mais simples. Um dos objetivos do coaching é ajudar a desenvolver o potencial das pessoas ao qual ele orienta ou auxilia. Ele ajuda a remover os obstáculos e faz com que cada indivíduo maximize o seu potencial. Mas comumente, o coaching está associado aos esportes. Temos hoje em dia vários exemplos de destaque em diversos esportes como o futebol e o vôlei. Em todos eles o técnico desempenha um papel fundamental para maximizar o potencial do seu grupo levando estes aos seus objetivos. Neste processo é importante também destacar que a pessoa que irá desempenhar o papel de coaching deve trabalhar com a sua equipe, estudando cada indivíduo e ajudando a melhorar os seus pontos fracos, a desenvolver a capacidade de saber resolver os problemas e ajudar a remover os obstáculos que o liderado irá encontrar em seu caminho. Por isso, é importante entendermos que o Coaching não é somente a forma, mais todo um conjunto de qualidades (orientador, colaborativo, influente e entendido) que uma pessoa deve possuir para que possa guiar a sua equipe ou seus liderados para o alcance de suas metas O que não é Coaching Neste processo de coaching, muitas vezes surgem conceitos equivocados. Também o que acontece é que este processo é aplicado de forma incorreta prejudicando e confundindo as pessoas que estão iniciando este aprendizado. A seguir uma explicação do que não é considerado coaching. Consultoria O coach não dá respostas. Ele não resolve os problemas. Ele busca ajudar aos seus liderados a descobrir suas próprias respostas. 5

6 Aconselhamento O coach não dá conselhos e nem soluções prontas. O conselheiro trabalha com o seu cliente, que está desconfortável ou insatisfeito com a vida, lhe dando uma direção e conselhos. Treinamento O coach não ensina aos seus liderados técnicas e ferramentas para percorrer um caminho. Isto é interessante, pois um coach não precisa ser alguém mais capacitado do que seus liderados no assunto a ser desenvolvido. Mentoring Comumente, um mentor ensina tudo que sabe sobre um determinado assunto. Assim, o liderado apenas aprende aquilo que o seu mentor sabe, sendo uma espécie de modelo para o seu liderado. Tratamento psiquiátrico ou análise psicológica O coaching não visa corrigir indivíduos ou resolver alguma disfunção da mente. O coaching não é remediativo, ele é generativo. O coaching não tem foco no passo, mas sim no futuro. 2. Facilitação Facilitação é o processo ou abordagem que busca oferecer meios de tornar fácil e exequível qualquer evento. Com isso, o facilitador busca realizar um trabalho coletivo, criativo e complementar, sempre identificando as competências individuais. Neste tipo de trabalho também podem surgir os indivíduos potencialmente conflitantes e é neste momento que o facilitador, busca o bom senso permitindo que todos possam expressar suas ideias. Através desta prática, o facilitador também resolve os problemas de conflitos interpessoais, a comunicação ineficiente da equipe e pouca clareza nos objetivos do evento. Isto permite que todos possam participar e se tornar responsáveis por um determinado tema em discussão no evento. Isto aumenta o foco das pessoas para o encalce dos objetivos e/ou metas. Em um evento facilitado, é comum haver uma forte comunicação visual. A neurociência explica que nosso cérebro possui dois hemisférios, onde o lado direito é considerado emocional e o lado esquerdo é considerado racional. Com esta premissa, o uso de ferramentas para gerar uma comunicação visual proporciona uma espécie de harmonia entre estes hemisférios, pois são fornecidos subsídios para ajudar o raciocínio lógico a materializar e organizar as emoções e sentimentos peculiares à construção de novas ideias. 3. Introdução a Agilidade Há muito tempo, a maneira de desenvolver software vem evoluindo com a criação de novas metodologias e processos, que visam facilitar o trabalho. Por muito tempo, tem-se usado o processo de desenvolvimento em cascata, mas este mostrou que a maioria dos projetos obtiveram fracasso, pois neste modelo as atividades são mais onerosas e mais burocráticas. Este 6

7 modelo segue a filosofia do conceito tradicional de desenvolver software, que consiste na ideia de um conjunto de atividades e resultados associados. Outro problema neste modelo, é que a medida em que o trabalho avança, ou seja, a medida em que as fases vão passando, o custo de correção ou ajuste cresce de forma exponencial. O desenvolvimento ágil é um fruto da constatação feita, de forma independente, por diversos profissionais renomados na área de engenharia de software, de que, apesar de terem aprendido segundo a cartilha tradicional, só conseguiam minimizar os riscos associados ao desenvolvimento de software, pensando e agindo de forma muito diferente do que tradicionalmente está nos livros. Com esta ideia, foi criado o Manifesto Ágil que é um documento elaborado com o intuito de determinar qual a visão de uma equipe de desenvolvimento de software e, foi assinado por desenvolvedores e gestores de projetos do software respeitados no mundo todo. Criado por um seleto grupo de pessoas da comunidade, o Manifesto Ágil é formado por princípios e valores que devem servir como diretrizes para as equipes. No manifesto ágil, valoriza-se: Indivíduos e interação entre eles, mais que processos e ferramentas; Software em funcionamento, mais que documentação abrangente; Colaboração com o cliente, mais que negociação de contratos; Responder a mudanças, mais que seguir um plano. De forma mais direta, deve-se valorizar mais os itens em destaque. Mas isto não significa que os itens sem destaque não devem ser valorizados, mas são menos prioritários. É importante observar, que ser Ágil não quer dizer ser radical e nem quer dizer que existe apenas uma solução para os projetos de desenvolvimento de software. Ser Ágil quer dizer, identificar e focar em objetivos bem estabelecidos, cuidar para que haja conscientização dos membros da equipe, unir a equipe e permitir a pró-atividade e auto gerenciamento, garantir feedback continuamente, utilizar soluções simples para problemas simples e, por fim, inspecionar e adaptar Os Princípios do Manifesto Ágil Garantir a satisfação do consumidor, entregando rapidamente e continuamente softwares funcionais; Softwares funcionais são entregues frequentemente (semanas, ao invés de meses); Softwares funcionais são as principais medidas de progresso do projeto; Até mesmo mudanças tardias de escopo no projeto são bem-vindas; 7

8 Cooperação constante entre pessoas que entendem do 'negócio' e desenvolvedores; Projetos surgem através de indivíduos motivados, entre os quais existe relação de confiança; Design do software deve prezar pela excelência técnica; Simplicidade; Rápida adaptação às mudanças; Indivíduos e interações mais do que processos e ferramentas; Software funcional mais do que documentação extensa; Colaboração com clientes mais do que negociação de contratos; Responder às mudanças mais do que seguir um plano Alguns Pontos Fundamentais sobre a Agilidade Praticar agilidade é algo que todos buscam, mas antes de qualquer metodologia ou processo, primeiramente é preciso observar alguns pontos fundamentais que ajudarão na adoção e prática de agilidade. São estes: Fracassos não devem ser encarados como coisas ruins, mas sim como lições aprendidas e assim não cometer o mesmo erro; É imprescindível saber que todos os resultados devem ser mensurados. Não para encontrar culpados, mas para poder realizar melhorias na equipe ou pessoalmente. É um processo de evolução; Dividir para conquistar. Para grandes coisas sempre procure dividir para resolver por partes; Procure sempre trabalhar as ideias. Dê mais tempo; Quanto mais simples o software, mais barato, mais rápido para desenvolver e mais agradável para o usuário. Quando surgir novas funcionalidades diga não; Garantir a satisfação do cliente, entregando rapidamente e de forma contínua o software funcional; Projetos surgem através de indivíduos motivados, entre os quais existe relação de confiança; Rápida adaptação às mudanças; Responder às mudanças mais do que seguir um plano; Até mesmo mudanças tardias de escopo são bem-vindas Metodologias Ágeis 8

9 Dentro de filosofia de agilidade, há diversas formas de se trabalhar. Ou seja, há diversos processos e metodologias que atendem aos princípios do manifesto ágil e que estes devem ser adaptados a realidade de cada um. Isto é um processo de inspeção e adaptação constante. Os processos ágeis tiveram seu início na década de 90 e eram chamados de processos leves em relação aos processos pesados e burocráticos como o modelo cascata. Dentre eles podemos citar: FDD (Feature Driven Devlopment), XP (extreme Programming), Scrum e Crystal. Abaixo será explicado um pouco sobre cada metodologia. FDD Desenvolvimento Orientado a Funcionalidades, metodologia criada entre 1997 e 1999 por um dos participantes do Manifesto Ágil, tem a sua base o método Coad (metodologia completa para Análise, Desenho e Programação Orientada por Objetos desenvolvida por Peter Coad) e as técnicas de gerenciamento interativo, incremental e enxuto. A sua ideia principal é Resultados frequentes, tangíveis e funcionais ; XP (extreme Programming), metodologia criada em 1996 na corporação Chrysler para ser utilizada por equipes pequenas e médias que irão desenvolver software com requisitos vagos e em constante mudança. Segue os cinco valores fundamentais: comunicação, simplicidade, feedback, coragem e respeito. Scrum, framework criado em 1993 para desenvolvimento interativo e incremental de software. Sua principal ideia é propor um framework com boas práticas e papéis bemdefinidos para ajudar as equipes de desenvolvimento de software a realizarem o desenvolvimento de projetos de forma mais eficiente. No scrum, o mais importante é a atitude das pessoas envolvidas de querer fazer o projeto acontecer. Os principais papéis no scrum são: Scrum Master, Product Owner e a Equipe Produto do Ponto de Vista de Negócio Em termos comerciais de software, o produto resultante de um projeto de desenvolvimento de software é o próprio software. Como profissionais de desenvolvimento de software, não devemos e não queremos nos preocupar com os outros fatores que não sejam a qualidade e a velocidade com o qual o software é entregue. Mas do ponto de vista do cliente, este produto (software) será o responsável pela resolução de alguma necessidade ou apenas irá melhorar o processo de negócio, trazendo benefícios econômicos. Destes dois pontos de vista, pode-se observar que o software tem valores diferentes, dependendo de vários fatores. Diante destes pontos, podemos concluir que o ponto de vista do cliente é a meta que a equipe de desenvolvimento de software deve alcançar e o ponto de vista da equipe (ou profissionais desenvolvimento) é a forma como este software deverá ser desenvolvido, sendo que cada um tem responsabilidades distintas, onde o primeiro ajuda a definir o que será o produto e seus detalhes e o segundo deverá trabalhar em cima destas informações para gerar o produto final. 9

10 Figura 1 - Visão do Escopo do Negócio Normalmente, o escopo vem definido através de termos de negócio. Cabe aos desenvolvedores traduzirem isso para linguagem técnica de forma transparente e assim, ser capaz de praticar sinergia para com o cliente. Para a definição do escopo do produto no contexto do negócio, é essencial que seja definido um representante do cliente que tenha uma visão completa do negócio ROI O cliente deve sempre manter a sua visão de retorno de investimento sobre as aquisições que ele realiza. Isto não seria diferente para software. Por isso, cabe a equipe de desenvolvimento ajudar o cliente a definir o seu produto e desta forma, trabalhar para realizar este produto. Também cabe a equipe, informar ao cliente quando algo que ele venha a definir ou solicitar traga mais custos do que benefícios para o seu negócio. Todo este processo é definido como ROI - Return Of Investiment (retorno sobre o investimento), que é uma ferramenta de avaliação de desempenho sobre o investimento realizado. Através dela o cliente poderá medir, junto com a equipe de desenvolvimento, os benefícios do desenvolvimento de um software para o seu negócio Declaração de Visão A visão do produto é a primeira atividade que qualquer cliente irá realizar antes de solicitar o seu software. Esta visão se tornará a meta do projeto, que a equipe irá quebrar em objetivos menores. Isto em alto nível fará com que todos da equipe de desenvolvimento saibam qual o resultado esperado. Deverá ser um documento sem ambiguidade e inteligível para que toda a equipe possa compreender. Será de grande utilidade a construção de um modelo do fluxo de informações do negócio. Desta forma será útil, principalmente para a equipe, que poderá utilizá-lo para saber como irá adequar o software a realidade do cliente. 10

11 Mais especificamente, o documento de visão do produto deverá ser um documento com no máximo duas (02) folhas. Deve abranger as partes mais importantes do produto e deverá ser gerado pelo cliente ou representante deste. Podemos fazer uso também de outras ferramentas para descrever a visão do produto, como por exemplo, a Modelagem de Mapas Mentais. Este consiste de um diagrama contendo o objetivo, uma estrutura de funcionalidades, metas não funcionais, critérios de sucesso e uma descrição superficial das tecnologias e arquitetura do projeto. Figura 2 - Exemplo de Mapa Mental 3.7. Estimativa Inicial No momento da definição do software, o cliente deverá realizar a priorização das funcionalidades que o produto irá conter. Isto significa que o cliente em conjunto com a equipe deverá realizar uma lista de todas as funcionalidades e a ordem de classificação quanto a sua importância para o negócio. Isso irá auxiliar a equipe no planejamento do desenvolvimento do software. As funcionalidades também poderão ser agrupadas ou então ordenadas em uma só lista, que será considerada o principal documento para construção do software. Toda a equipe irá se basear nesta lista, pois esta define os objetivos da equipe para o alcance da meta final (que é o software construído). Para esta estimativa inicial, não é necessário definir valores para cada funcionalidade (ou requisito). Apenas será definida uma ordem de prioridade a partir da visão do cliente. 4. Diferencial do Scrum 11

12 O Scrum como qualquer outra ferramenta de gestão de projetos, tem como propósito ajudar no desenvolvimento do software de forma mais eficiente e eficaz. Mais por que o Scrum se destaca das outras? Isto será explicado nas próximas seções, onde serão abordados a história, as características que tornaram este framework muito popular no campo do desenvolvimento de software e que hoje já se estende para outras áreas História Abaixo um histórico resumido da elaboração do framework Scrum: Em 1986 Hirotaka Takeuchi e Ikujiro Nonaka descreveram uma nova abordagem para o desenvolvimento de produtos em que todas as fases do processo e a equipe trabalham juntos em diferentes fases; Na década de 90, a metodologia Scrum foi introduzida em algumas companhias, como por exemplo, Easel Corporation onde Ken Schwaber trabalhava. Neste mesmo ano Jeff Sutherland, John Scumniotales e Jeff McKenna chamaram pela primeira vez este processo de Scrum; Em 1995 Ken Schwaber e Jeff Sutherland descreveram e apresentaram para o público Como Ganhar essa Vantagem Competitiva A primeira coisa que devemos observar é a forma como a equipe está trabalhando. Visualizar os pontos fracos, para identificar se este processo realmente irá ajudar a permanecer no mercado. Isto é necessário para que não afete a rentabilidade da empresa. Vale ressaltar que esta avaliação do processo atual da empresa é muito importante, pois o que se tem falado até o momento e também depois só fará sentido, se realmente o processo da empresa precisar ser melhorado. Isto foi o mesmo sentimento que motivou há muito tempo atrás a criação do Manifesto Ágil. Este material foi compilado a partir das boas experiências e resultados positivos em diversos tipos de projetos. As empresas que ainda possuem a visão antiga, de que focar em processo e documentação é a única forma de melhorar o trabalho, estão tendo que rever seus conceitos para poder acompanhar o mercado e se tornar competitivas. A agilidade no desenvolvimento de software, está se tornando cada vez mais um grande diferencial no mercado de software, pois com a velocidade das informações o software está cada vez mais se tornando parte essencial para o negócio. 12

13 4.3. E na prática, como isso funciona? Tudo isso é muito bom, parece ser a salvação das indústrias de software. Mas o que realmente pode-se constatar é que essa maravilha toda não é tão fácil de implantar ou trazer resultados em curto prazo. Além das práticas e processos das metodologias ágeis, ainda há o fator humano envolvido. Muitas vezes a implantação pode levar muito tempo ou até mesmo ficar inviável devido a cultura da empresa e das pessoas envolvidas. É importante lembrar, que as metodologias ágeis são uma filosofia, uma forma de trabalho bem diferente do modelo tradicional, que vai depender das atitudes dos envolvidos no projeto para que este venha a ter sucesso. Atualmente muitas empresas conseguiram implantar e adequar o framework aos seus projetos, gerando ótimos resultados. Mas há outras que ainda não conseguiram e ainda lutam para quebrar paradigmas antigos que atrapalham muito esta nova forma de trabalho. Por isso é muito importante que esta filosofia seja seguida desde a alta direção até o desenvolvedor, para que todos possam ganhar com esta nova forma de abordagem de desenvolver software. 5. O SCRUM 5.1. O que é SCRUM O scrum não é uma metodologia, não é uma nova tecnologia, não é uma ferramenta e nem um cheklist de avaliação de processo. Trata-se apenas de um framework, que baseia-se em um processo iterativo e incremental para o desenvolvimento de qualquer produto e gerenciamento de qualquer projeto (Certified Scrum Master, 2009). Mas também deve ser considerada, uma filosofia de trabalho que envolve a atitude das pessoas envolvidas no projeto. Algumas características do Scrum: Processo empírico de gerenciamento e controle; Deve-se praticar a inspeção e adaptação em loops de feedbacks; Baseia-se na filosofia de entregas frequentes de funcionalidades com valor para o cliente; Escalável a projetos distribuídos, grandes e largos; Extremamente simples, mas resistente. O scrum é fundamentado na teoria de controle de processos empíricos, que emprega uma abordagem iterativa e incremental para aperfeiçoar a previsibilidade e controlar riscos. Três pilares sustentam qualquer implementação de controle de processos empíricos: Transparência, Inspeção e Adaptação. 13

14 Primeiro pilar é a TRANSPARÊNCIA Este pilar informa que todo o processo que afeta o resultado deve transcorrer de forma transparente, principalmente para aqueles que realizam a gestão. Além da transparência este processo deve ser conhecido para que qualquer inspeção no processo possa ser facilmente visto todos os pontos. Segundo pilar é a INSPEÇÃO Este pilar informa que devem ser realizadas inspeções com frequência suficiente para que variações inaceitáveis do processo possam ser detectadas, ou seja, qualquer ponto de melhoria deve ser visualizado e corrigido o mais breve possível. Terceiro pilar é a ADAPTAÇÃO Este pilar informa que caso seja encontrado algum ponto do processo fora dos limites aceitáveis e que o produto resultante será inaceitável, deverá ser ajustado o mais breve possível para minimizar desvios posteriores. Conforme o framework Scrum, este possui três pontos de inspeção e adaptação. A primeira é a reunião diária que é utilizada para avaliar o progresso do projeto em direção à Meta da Sprint e também se pode realizar adaptações que otimizem o valor do próximo dia de trabalho. Em seguida temos a reunião de Revisão da Sprint e de Planejamento da Sprint que são utilizadas para inspecionar o progresso em direção à meta da versão. Por último temos a reunião de Retrospectiva da Sprint, que tem o objetivo de avaliar e revisar a Sprint passada, para definir as adaptações que tornarão a próxima mais produtiva e gratificante. O framework Scrum é formado pelo Time e outros papéis (que veremos em seguida), eventos com durão fixa (conhecidos como Time-Boxes), os artefatos e regras. Figura 3 - Visão Geral do Processo Scrum O Time do Scrum é projetado para ser eficiente, tanto na sua produtividade quanto a sua flexibilidade. Por este motivo, este time deve ser interdisciplinar, auto-organizado e que saiba trabalhar em iterações. 14

15 Neste time os principais papéis são: Scrum Master: Responsável por garantir que todas as regras e atividades do scrum sejam seguidas e sejam entendidos por todos os envolvidos; Product Owner: Responsável por definir as entregas e por maximizar o valor do trabalho do time; Time: Responsável por executar o trabalho propriamente dito. Geralmente o Time é formado por desenvolvedores com todas as habilidades necessárias que irão garantir que todos os requisitos definidos na Sprint irão gerar um pedaço potencialmente entregável em relação ao produto final. Quanto a sua gestão de linha temporal, o scrum emprega eventos com duração fixa (time-boxes) para criar uma regularidade. Mas dentro desta duração fixa, temos os principais elementos de inspeção do Scrum dentro da linha de tempo do projeto que são: a Sprint, a Reunião Diária, a Revisão da Sprint e a Retrospectiva da Sprint. Já os artefatos que o Scrum trabalha são: Product Backlog, Sprint Backlog, Burndown da Sprint e um Burndown do Projeto Papéis Dentro do scrum, o time é formado pelos seguintes papéis: Scrum Master, Product Owner e pelo Time. Dentro deste contexto temos antes que explicar qual a visão do framework scrum em relação a todos estes papéis. Primeiramente vamos observar a figura abaixo: Figura 4 - História do comprometimento x envolvimento Como observamos, dentro do scrum temos aqueles papéis que são os comprometidos e os que são apenas envolvidos. Como papel de comprometido, ou seja, aqueles que irão se comprometer com os 15

16 resultados e objetivos a serem alcançados tem o Time scrum. O restante é apenas envolvido no projeto. Por isso dizemos que no projeto scrum, temos os Porcos e as Galinhas. Com este conceito definido, pode-se dizer que as Galinhas não podem dizer aos Porcos como estes devem fazer seu trabalho ScrumMaster É o principal responsável por garantir que todos do time estejam aderindo aos valores do scrum, como as práticas e regras. Ele também é o responsável por ajudar a organização e o time na adoção do framework. Deve ter como visão a educação do time scrum no seu treinamento quanto ao scrum, levando-o a ser mais produtivo e a desenvolver produtos com maior qualidade. O ScrumMaster deve ajudar o time a ser autogerenciado e interdisciplinar. Como princípio o ScrumMaster não gerencia o time, pois este deve ser auto-organizável. Além destes pontos descritos anteriormente, o ScrumMaster deve ser um líder/facilitador, pois atua fortemente na remoção dos impedimentos e principalmente protege o time das interferências externas para que a meta de entrega seja alcançada. Figura 5 ScrumMaster deve atuar como facilitador É interessante notar que o ScrumMaster trabalha junto aos clientes e gerentes da organização para auxiliar na preparação e identificação de um Product Owner. O ScrumMaster facilitará o trabalho do Product Owner e também servirá ao time de forma que o mesmo esteja protegido durante uma Sprint Product Owner É a pessoa responsável pela gestão do Product Backlog (que será falado nas próximas seções), por garantir valor ao trabalho do time e por garantir o retorno sobre o investimento do projeto. Este 16

17 deve manter o backlog atualizado e disponibilizar a todos os envolvidos para que estes saibam onde devem chegar e quais itens são prioritários. Figura 6 - Responsável pela Gestão do Product Backlog O product owner deve ser uma pessoa escolhida pelo cliente, mas jamais deverá ser um grupo ou comitê. Isto não quer dizer que se o cliente define um grupo, este não possa influenciar ou apoiar o product owner, mas só quem pode mudar a prioridade de um requisito é o Product Owner. Como sugestão, pode ser um Gerente de Produto ou então um Gerente da função de negócios, por estar mais próximo do cliente. Um ponto importante para o sucesso do product owner em um projeto scrum é que toda organização deve respeitas as decisões feitas pelo product owner Time É o responsável por dividir o product backlog em incrementos de funcionalidades potencialmente entregáveis em cada Sprint. A visão de cada membro do time é de ser interdisciplinar, ou seja, devem possuir o conhecimento necessário para criar um incremento de trabalho. Figura 7 - Time Interdisciplinar 17

18 Apesar de em muitos casos as pessoas do time atuarem em atividades especializadas como, por exemplo, programação, arquiteto de software, projetista de banco de dados, analista de requisitos e outros, o mais importante é que estes saibam pegar um requisito e transformá-lo em um produto utilizável, mesmo que isso signifique ter que atuar em outra atividade. Os membros do time que não se adequam a este tipo de filosofia não conseguem adaptar-se ao time. Não há títulos em time, não divisão por funções todos são iguais, ou seja, muitas vezes um analista de requisitos terá que testar ou até mesmo programar (claro isso irá requerer que este relembre a programa ou até mesmo desenvolva esta habilidade.). O time deve ser auto organizável, ou seja, nem mesmo o scrum master pode dizer como o time deve trabalhar para transformar o product backlog em incrementos entregáveis. Isto é algo que o time terá que fazer sozinho. Isto fica mais fácil ao aplicar a habilidade de cada membro em cima do product backlog e com isso saberão o que será necessário fazer para realizar as entregas. Isto leva o time a melhorar a sua eficiência e eficácia. Em um time scrum, o número ideal de pessoas são sete (07) e mais ou menos duas (02). Caso o time possua menos de cinco pessoas, isto pode causar menor interação entre as pessoas do time levando a um menor ganho de produtividade. Mais do que o limite superior (de sete mais duas pessoas) também não é bom, pois isto causará grandes problemas em coordenar este time muito grande Gerenciamento de Escopo e Valor Agregado ao Negócio Para o projeto Scrum, um dos artefatos mais importantes é o Product Backlog que reúne a lista de requisitos de forma priorizada realizada pelo Product Owner (como dito anteriormente). Para a composição deste artefato, o ideal é usar as práticas da engenharia de requisitos. Com as metodologias ágeis, através da sua abordagem simples e enxuta dos requisitos, pode ajudar na especificação e definição dos requisitos, já que este framework incentiva a comunicação através de um texto claro e usando uma linguagem única de negócios. Uma das ferramentas utilizadas pelo scrum é a estória de usuário (user story). Esta ferramenta oriunda da metodologia XP é utilizado para elicitação dos requisitos e sua estrutura é a seguinte: Como um(a) <PAPEL> gostaria /devo de <FUNÇÂO> para/por <VALOR DE NEGÓCIO>. Abaixo vejamos alguns exemplo: Como supervisor eu gostaria de autorizar um desconto em uma venda. Como um instrutor eu devo apontar a lista de presença dos alunos para manter as informações do treinamento atualizadas. 18

19 Depois de identificado estes requisitos estes deverão ser reunidos e priorizados no Product Backlog. Este artefato representará a visão do produto e assim, o time poderá estabelecer uma estratégia para as entregas. A priorização dos itens do Product Backlog serão definidos através de uma nota numérica que é definido pelo Product Owner. Esta pontuação é definida a partir da sua visão de importância para o negócio. Abaixo veremos um exemplo de um Product Backlog: Item Como candidato gostaria de visualizar os cursos disponíveis pela instituição Valor de Negócio 100 Como candidato gostaria de fazer minha inscrição no vestibular. 80 Como candidato gostaria de emitir o boleto para pagamento das taxas de inscrição no vestibular Gerenciamento do Tempo O principal paradigma oferecido pelo framework scrum é o conceito de TimeBox. Ele funciona como uma caixa de tempo em vários níveis (diário, semana e mensal) e está presente em praticamente todas as seções de trabalho do scrum. Estes eventos de duração fixa no scrum são a Sprint, a Reunião de Planejamento da Sprint, a Revisão da Sprint, a Restrospectiva da Sprint e a Reunião Diária. Dentre estes eventos o que melhor representa o TimeBox é o Sprint, pois é uma iteração que será realizada várias vezes durante o projeto, com o principal objetivo de entregar algo potencialmente usável ao seu final Fluxo de Trabalho O fluxo de trabalho do scrum oferece um processo bem simples de entender. Porém o mais difícil é implementar este processo, pois incide na mudança de cultura da empresa onde se está adotando o scrum. Abaixo uma visão de todo o framework. 19

20 Figura 8 - Framework Scrum na visão geral 5.6. Conceito de Sprint A Sprint é um timebox de uma (1) a quatro (4) semanas de duração no qual o time do projeto irá produzir uma parte do produto definida pelo cliente. Cada Sprint deve ter uma meta específica que represente o desejo do cliente em incremento de software para aquele timebox específico e os membros do time do Sprint são os responsáveis por estimar os itens que compõe o desejo do cliente e dar a palavra final do que será possível ser desenvolvido naquele timebox. Com isso a Sprint é uma iteração. Durante a Sprint o ScrumMaster garante que não será feito nenhuma mudança que possa afetar a meta do Sprint. Tanto a composição do time quanto as metas de qualidade que devem permanecer constantes durante a Sprint. As sprints podem ser canceladas antes que o prazo fixo da Sprint tenha acabado. Somente o Product Owner tem a autoridade de cancelar uma Sprint, embora ele possa fazer sob a influência de partes interessadas e do ScrumMaster. Em geral, uma Sprint deve ser cancelada se ela não fizer mais sentido dadas as circunstâncias atuais. A partir do momento que uma Sprint é cancelada, todos os itens do Product Backlog que foram completados são revisados. Eles são aceitos se representarem um incremento potencialmente entregável. O restante dos itens volta para o product backlog com as estimativas iniciais. 20

21 5.7. Sprint Planning Meeting A Reunião de Planejamento da Sprint (Sprint Planning Meeting) é quando a iteração é planejada. É fixada em oito (08) horas de duração para uma Sprint de um mês. Para Sprints mais curtas, aloca-se para essa reunião aproximadamente 5% do tamanho total da Sprint e consiste de duas partes. Estas duas reuniões são facilitadas ou lideradas pelo ScrumMaster. Na primeira reunião, que tem duração de quatro (04) horas, o Product Owner apresenta os itens de maior valor de negócio para o time, o time irá estimar o tamanho/complexidade desses itens e é decidido o que será feito na Sprint. Todos os itens de backlog tem sua estimativa de esforço definidas através de uma técnica chamada de planning poker. Esta técnica consiste em definir em conjunto (time) o esforço necessário para realizar certa atividade em horas. Figura 9 - Baralho de Planning Poker A segunda reunião, que também de duração de quatro (04) horas, é quando o time entende como desenvolverá essa funcionalidade de incremento do produto durante a Sprint, para cada item o time irá criar tarefas que o time entende que precisa realizar para completar o item de backlog. Estas duas reuniões podem ser dividas em o quê? e como?, ou seja, a primeira reunião irá se definir o que será realizada na Sprint que se inicia. Este é um trabalho em conjunto com o time e o product owner. O ScrumMaster é apenas o facilitador da reunião. Se for o primeiro Sprint, o item que deve ser utilizado nesta reunião é o product backlog. Se for o segundo Sprint em diante deve-se utilizar além do product backlog, a capacidade do time em desenvolver as tarefas em um Sprint (quantos itens é possível realizar) e também o histórico de desempenho (velocidade). Na segunda parte da reunião o time ira tratar da questão do como desenvolver os itens selecionados e transformá-los em um incremento pronto. Neste momento, enquanto o time projeta como serão realizado os itens, o time identifica as tarefas necessárias para realizar cada item do Sprint. Estas tarefas devem ser decompostas para serem realizadas em menos de um dia e após a conclusão destas atividades é que irá converter os itens do product backlog em pedaços funcionais do produto final. Ao final teremos uma lista das tarefas do Sprint que serão chamados de Sprint Backlog. 21

22 O Product Owner está presente nas duas reuniões, e se o time identificar nestas reuniões que há trabalho de mais ou de menos, ele deve renegociar com o Product Owner. O time também pode convidar outras pessoas para participarem da reunião para fornecer conselhos técnicos ou sobre o domínio da questão Daily Scrum Meeting Na Reunião Diária do Scrum (Daily Scrum Meeting) o time se encontra para uma reunião de 15 minutos e deve ser feita sempre no mesmo horário e local. Durante a reunião, que é conduzida pelo ScrumMaster, cada membro deve responder a três perguntas: O que fizemos de ontem para hoje? O que iremos realizar de hoje para amanhã? Existe algum impedimento? As reuniões diárias melhoram a comunicação, eliminam outras reuniões, ajudam a identificar e remover impedimentos para o desenvolvimento do Sprint, ressaltam e promovem a tomada rápida de decisões e melhoram o nível de conhecimento de todos acerca do projeto. O ScrumMaster deve garantir que o time realize a reunião e é responsável por conduzir a reunião. Deve ensinar o time a manter a reunião em curta duração, reforçando as regras e garantindo que as pessoas falem brevemente. Deve ser o facilitador da reunião. A reunião diária não é para reportar status e sim, uma forma de inspecionar o progresso do time em direção à meta do Sprint. Essa reunião é fundamental para inspecionar e adaptar o processo Scrum Sprint Review Meeting A Reunião de Revisão do Sprint (Sprint Review Meeting) é o evento realizado ao final da Sprint. Para Sprints de um mês, a reunião deverá ter uma duração de quatro (04) horas e para Sprint mais curtos a reunião não deve tomar mais do que 5% do tempo total do Sprint. Durante a revisão da Sprint o time apresenta o que foi realizado e desenvolvido durante a Sprint para o Product Owner e também outros envolvidos (Stakeholders, caso haja necessidade). É uma reunião informativa e também neste momento os stakeholders podem sugerir novos itens de backlog. Nesta reunião inclui pelo menos os seguintes itens: O Product Owner identifica o que foi feito e o que não foi feito durante a Sprint. O Time demonstra o trabalho que está pronto e responde a questionamentos. O Product Owner discute o Product Backlog da maneira como ele se encontra. Ele faz projeções de datas de conclusões prováveis a partir de várias hipóteses de velocidade. Em 22

23 seguida, o grupo inteiro colabora sobre o que foi visto e o que isso significa com relação ao que fazer em seguida. A Revisão da Sprint fornece várias entradas valiosas para as próximas reuniões de Planejamento de Sprints Sprint Retrospective Meeting A Reunião de Retrospectiva da Sprint (Sprint Retrospective Meeting) é realizada após a reunião de revisão da Sprint e antes da próxima reunião de planejamento da Sprint. Nesta reunião com duração fixa em três (03) horas, o ScrumMaster encoraja o time a revisar, dentro do modelo de trabalho e das práticas do processo Scrum, o seu desenvolvimento, de forma a torná-lo mais eficaz e gratificante para a próxima Sprint. A finalidade desta reunião é inspecionar como ocorreu a última Sprint em se tratando de pessoas, das relações entre elas, dos processos e ferramentas. É nesta reunião que o time tem a chance de refletir o que aconteceu na Sprint que passou e responder as seguintes questões: O que funcionou bem?, O que não funcionou bem? e O que pode ser melhorado?. É neste ponto que entra a inspeção da adoção do processo. Ao final da reunião o time deve ter identificado medidas de melhoria factíveis de se implementar na próxima Sprint. Estas mudanças se tornam a adaptação para a inspeção empírica Visibilidade, Inspenção e Adaptação O Scrum se apoia em três pilares (como já foi dito na seção 5.1 O que é SCRUM) para realizar entregas constantes: Visibilidade, Inspeção e Adaptação. Dentre estes, o mais interessante dentro do processo Scrum e que realmente traz uma mudança forte no cotidiano é a visibilidade. Com isso uma das principais missões do Scrum é tornar visível para a equipe e também outros interessados como está o progresso e quais os problemas que precisam ser resolvidos para melhorar os resultados. Para isso, o Scrum oferece algumas opções muito interessantes para estimular uma comunicação mais direta e simplificada dentro de um projeto. A partir deste ponto é necessário observar o desafio cultural para promover as melhorias nas atitudes de cada membro do time, visto que agora qualquer pequena variação do projeto será percebida dentro de uma Sprint. Dessa forma, uma das principais ferramentas para promover essa visibilidade é o famoso KanBan (quadro de atividades), que é uma herança muito interessante que as metodologias ágeis tiveram do Pensamento Lean. Dentre outras coisas, essa ferramenta estimulará psicologicamente atitudes auto organizadas para puxar itens para a produção e tornar visível o seu progresso ou qualquer impedimento durante o trabalho. Abaixo um exemplo de quadro KanBan: 23

24 Figura 10 - Exemplo de um quadro KanBan Outra ferramenta interessante e típica do Scrum é o gráfico de Burndown, que mostra quando de valor de negócio, tamanho e esforço já foram realizados (entregues) durante a Sprint e do projeto inteiro. Abaixo uma imagem do Burndown: Figura 11 - Gráfico de Burndown do Projeto 5.9. Ajudando o Trabalho da Equipe através da Remoção Contínua de Impedimentos 24

25 Como é natural na área de Tecnologia da Informação, vivemos em um universo de problemas. Mas Scrum tem uma maneira muito interessante de tratar estes problemas. Isto também pode ser visto de outra forma, como impedimentos que atuam como barreiras para que o trabalho iniciado não vá adiante. Estes impedimentos podem ser de diversas naturezas como, por exemplo, questões técnicas, políticas e pessoais. O tratamento destes impedimentos é baseado em um dos princípios do modelo Toyota que estimula o controle visual para permitir que qualquer problema esteja visível dentro do processo. Desta forma, através deste controle visual (como mostrado no KanBan), o ScrumMaster poderá exercer umas das suas responsabilidades que é de remover os obstáculos ou impedimentos. Isto não significa que ele vai sempre saber como remover estes impedimentos, mas ele é o responsável por buscar meios necessários para remoção destes Definição de Pronto O Scrum, como framework ágil, estimula fortemente que se use o conceito de Pronto para nortear quando os itens de uma Sprint estão realmente prontos e dentro da qualidade desejada para o produto gerado. É importante compreender que essa definição de pronto é fortemente desenvolvida quando se usa, junto ao Scrum, alguma metodologia que ofereça práticas fortes de engenharia como XP ou FDD. No desenvolvimento de produtos, afirmar que a funcionalidade está pronta pode levar alguém a presumir que ela está, pelo menos, codificada, refatorada, que tenha passado por testes unitários, que tenha sido feito o build e que tenha passado por testes de aceitação. Outros podem presumir que apenas o código tenha sido desenvolvido. Se ninguém sabe qual a definição de pronto, os outros dois pilares do controle de processos empíricos não funcionam. Quando alguém descreve algo como pronto, todos devem entender o que pronto significa. Pronto define o que o Time quer dizer quando se compromete a aprontar um item de Backlog do Produto em uma Sprint. Alguns produtos não contêm documentação, de forma que sua definição de pronto não inclui documentação. Um incremento completamente pronto inclui toda a análise, projeto, refatoramento, programação, documentação e testes para o incremento e todos os itens do Backlog do Produto no incremento. Os testes incluem testes de unidade, de sistema, de usuário e de regressão, bem como testes não-funcionais como de performance, de estabilidade, de segurança e de integração. Pronto inclui também qualquer internacionalização necessária, além disso, Pronto significa que o Product Owner pode utilizar de alguma forma o item. Alguns Times ainda não são capazes de incluir em sua definição de pronto tudo o que é necessário para a implantação. Isto deve estar claro para o Product Owner. Esse trabalho restante deverá ser feito antes que o produto possa ser implantado e utilizado. 25

26 5.11. Melhoria Contínua De acordo com o manifesto ágil: Em intervalos regulares a equipe reflete sobre como se tornar mais eficaz e então ajusta seu comportamento de acordo. Isso significa que em pequenos ciclos o time aprende sobre seus erros e acertos para gerar melhoria na forma de trabalho do próximo ciclo. Através desta idéia, que na agilidade chamamos de visibilidade, inspeção, e adaptação, temos uma base sólida, com muita sinergia histórica e prática para a aplicação do ciclo PDCA (Plan, Do, Check e Action) nas atividades de Planejamento, Execução, Verificação e Ações corretivas ou preventivas dentro de projetos de desenvolvimento de software. Esse ciclo PDCA é efetivo num projeto ágil (isso inclui Scrum), pois há um planejamento a cada Sprint e a cada dia de trabalho de um time. Para assegurar esse ciclo, também fazemos uma verificação constante em busca de melhoria no produto e no processo (forma de trabalho) a cada dia e ao final de cada Sprint. 6. Outros Conceitos Abaixo serão descritos mais conceitos importantes para o conhecimento da gestão de projetos com Scrum. Estes conceitos ajudarão a entender melhor a filosofia por trás da ideia do framework scrum PDCA O ciclo PDCA, ciclo de Shewhart ou ciclo de Deming, é um ciclo de desenvolvimento que tem foco na melhoria contínua. O PDCA foi idealizado por Shewhart e divulgado por Deming, quem efetivamente o aplicou. Inicialmente deu-se o uso para estatística e métodos de amostragem. O ciclo de Deming tem por princípio tornar mais claros e ágeis os processos envolvidos na execução da gestão, como por exemplo, na gestão da qualidade, dividindo-a em quatro principais passos. O conceito do Ciclo evoluiu ao longo dos anos vinculando-se também com a idéia de que, uma organização qualquer, encarregada de atingir um determinado objetivo, necessitava planejar e controlar as atividades a ela relacionadas. O ciclo começa pelo planejamento, em seguida a ação ou conjunto de ações planejadas são executadas, checa-se se o que foi feito estava de acordo com o planejado, constantemente e repetidamente (ciclicamente), e toma-se uma ação para eliminar ou ao menos mitigar defeitos no produto ou na execução. Os passos são os seguintes: 26

27 Plan (planejamento): Deve-se estabelecer uma meta ou identificar o problema (um problema tem o sentido daquilo que impede o alcance dos resultados esperados, ou seja, o alcance da meta); analisar o fenômeno (analisar os dados relacionados ao problema); analisar o processo (descobrir as causas fundamentais dos problemas) e elaborar um plano de ação. Do (execução): Deve-se realizar e executar as atividades conforme o plano de ação. Check (verificação): Deve-se monitorar e avaliar periodicamente os resultados alcançados, avaliar processos e resultados, confrontando-os com o planejado, objetivos, especificações e estado desejado, consolidando as informações, eventualmente confeccionando relatórios. Act (ação): Deve-se agir de acordo com o avaliado e de acordo com os relatórios, eventualmente determinar e confeccionar novos planos de ação, de forma a melhorar a qualidade, eficiência e eficácia, aprimorando a execução e corrigindo eventuais falhas Kanban Kanban é uma expressão japonesa com origem nos cartões utilizados nas empresas japonesas para solicitar componentes a outras equipes da mesma linha de produção, e que designa um método de fabricação em série, desenvolvido pela Toyota Motor Company, aplicado aos processos de aprovisionamentos, produção e distribuição, seguindo os princípios do Just-in-Time (JIT). Podemos dizer que o método Kanban é um método que determina a produção a partir da procura: de fato, o ritmo de produção é determinado pelo ritmo de circulação de Kanban s, o qual, por sua vez, é determinado pelo ritmo de saída dos produtos juntamente com o fluxo de produção. Objetivos do método Kanban Podemos identificar como principais objetivos do método Kanban os seguintes itens: Regular internamente as flutuações da procura e o volume de produção em cada seção de forma a evitar a transmissão e ampliação dessas flutuações; Minimizar as flutuações dos estoques do produto acabado com o objetivo de reduzir os custos de estocagem; Descentralizar a gestão da fábrica, criando condições para que as chefias diretas desempenhem um papel de gestão efetiva da produção e dos estoques; Produzir as quantidades solicitadas no momento em que são solicitados. Aplicação do método Kanban Pelas suas características, o método Kanban apenas pode ser aplicado em sistemas de produção repetitiva, em que os produtos são padronizados e a produção é relativamente estável, sendo obrigatório que o processo de produção esteja organizado em série. 27