Tema 2 - Projeto Ágil

Prévia do material em texto

<p>DEFINIÇÃO</p><p>Fundamentos da agilidade representados pelos valores e princípios do Manifesto Ágil assinado em</p><p>2001, Conceitos e características de dois métodos ágeis muito utilizados mundialmente, Extreme</p><p>Programming (XP) e Scrum.</p><p>PROPÓSITO</p><p>Compreender a essência do conceito de agilidade, que possui em seu cerne a cultura de frequente</p><p>entrega de valor, com qualidade e foco em pessoas, seja o cliente ou quem produz o produto.</p><p>Compreender as principais características dos métodos ágeis XP e Scrum.</p><p>OBJETIVOS</p><p>MÓDULO 1</p><p>Reconhecer valores e princípios do Manifesto Ágil</p><p>MÓDULO 2</p><p>Identificar as principais características do método Extreme Programming</p><p>MÓDULO 3</p><p>Reconhecer as principais características do framework Scrum</p><p>INTRODUÇÃO</p><p>O tema apresenta inicialmente o conceito da agilidade baseada nos valores e princípios do Manifesto</p><p>Ágil, com o objetivo de ressaltar que, antes de pensarmos em métodos, temos que entender a cultura de</p><p>entrega de valor no desenvolvimento de produtos, com ciclos curtos de feedback, para validação</p><p>frequente da expectativa do usuário. Após este entendimento, apresentaremos as principais</p><p>características dos métodos ágeis Extreme Programming e Scrum.</p><p>MÓDULO 1</p><p> Reconhecer valores e princípios do Manifesto Ágil</p><p>Foto: NicoElNino / Shutterstock.com</p><p>LIGANDO OS PONTOS</p><p>Você sabe o que é um Alinhamento de Valores e Princípios em um Projeto Ágil? Você, como gerente de</p><p>projetos, conseguiria conduzir um projeto baseado na Metodologia Ágil em que não está totalmente claro</p><p>para o cliente quais são os principais valores e princípios de um Projeto Ágil e como todas as entregas</p><p>serão realizadas até o final do projeto? Para entendermos esse conceito na prática, vamos analisar o</p><p>case da empresa SPE – Serviço Brasileiro de Suporte a Empresas.</p><p>A empresa SPE é uma entidade privada que promove o desenvolvimento sustentável e a</p><p>competitividade das empresas brasileiras, atuando há mais de 30 anos com foco no fortalecimento e na</p><p>aceleração do processo de formalização da economia por meio de parcerias entre o sistema público e</p><p>privado. As soluções desenvolvidas pela empresa atendem desde o pequeno empreendedor que deseja</p><p>abrir seu primeiro empreendimento até empresas consolidadas e que buscam um novo posicionamento</p><p>no mercado. A SPE oferece consultorias, cursos, seminários e outros tipos de assistências para</p><p>empresas de diversas áreas de negócio. A empresa possui sua própria área de TI, que é responsável</p><p>pelo desenvolvimento de alguns sistemas internos, manutenção de todos os sistemas existentes e todo</p><p>o suporte que se faz necessário para as demais áreas de negócio da empresa.</p><p>Durante sua longa trajetória, a empresa SPE contratou diversas consultorias externas para desenvolver</p><p>parte dos seus sistemas de informação e muitos projetos fracassaram. A maioria dos projetos</p><p>conduzidos pelas consultorias externas seguia o modelo cascata, também conhecido como modelo</p><p>waterfall, em que todas as atividades do projeto são divididas entre etapas que costumam ser longas e</p><p>cada fase somente será iniciada após a conclusão e entregas da etapa anterior, fazendo com que o</p><p>cliente espere um longo tempo até que de fato receba software funcionando como entregável. Como nos</p><p>métodos ágeis as entregas ocorrem de forma rápida e contínua em que o principal foco é naquilo que</p><p>gera valor ao cliente (software), a empresa SPE estava bem otimista com relação à nova consultoria</p><p>externa que foi contratada e que desenvolveria um software seguindo a Metodologia Ágil, mas seria</p><p>necessário um alinhamento dos valores e princípios do Manifesto Ágil no início do projeto, para que</p><p>todos entendessem como o novo Projeto Ágil seria conduzido.</p><p>APÓS A LEITURA DO CASE, É HORA DE APLICAR SEUS</p><p>CONHECIMENTOS! VAMOS LIGAR ESSES PONTOS?</p><p>1. QUAL O PRINCIPAL OBJETIVO DE UM ALINHAMENTO DE VALORES E</p><p>PRINCÍPIOS?</p><p>A) Deixar claro para o cliente como as regras do projeto serão impostas pelo fornecedor.</p><p>B) Tem como objetivo o mapeamento de todos os processos de negócio da organização.</p><p>C) Esse tipo de alinhamento é necessário somente no início do projeto para que todos fiquem alinhados</p><p>de como os processos serão conduzidos do início ao fim do projeto.</p><p>D) É extremamente importante para que o cliente e o fornecedor fiquem alinhados de como os</p><p>processos serão conduzidos do início ao fim do projeto. Durante esse alinhamento, pode ser identificada</p><p>a necessidade de treinamentos como pré-requisitos para que se inicie o projeto. O Alinhamento de</p><p>Valores e Princípios poderá ocorrer sempre que houver algum desentendimento da forma como o</p><p>projeto está sendo conduzido.</p><p>E) É uma reunião entre cliente e fornecedor que ocorre somente no início do projeto, na qual serão</p><p>alinhados todos os processos legais necessários para a realização de um Projeto Ágil.</p><p>2. QUAIS OS PRINCIPAIS BENEFÍCIOS DE UM PROJETO ÁGIL COM RELAÇÃO A</p><p>UM PROJETO BASEADO NO MODELO TRADICIONAL (CASCATA –</p><p>WATERFALL)?</p><p>A) Processos mais flexíveis e sem burocracia.</p><p>B) Entregas contínuas e adiantadas de software com valor agregado com menor foco em documentação</p><p>e maior foco no que realmente gera valor ao cliente.</p><p>C) Maior liberdade em desenvolver um projeto sem documentação.</p><p>D) Comunicação mais eficiente durante todo o processo.</p><p>E) O custo do projeto será mais acessível, pois não será produzida uma documentação extensa.</p><p>GABARITO</p><p>1. Qual o principal objetivo de um Alinhamento de Valores e Princípios?</p><p>A alternativa "D " está correta.</p><p>Um dos maiores motivos que levam qualquer tipo de projeto ao fracasso é a falta de comunicação. A</p><p>comunicação entre todos deve ser clara e objetiva. Todas as equipes envolvidas no processo devem</p><p>possuir um vocabulário único. Gerenciar as expectativas e a comunicação de todas as partes</p><p>interessadas é um dos maiores desafios de um gerente de projetos que conduz um projeto por meio de</p><p>Metodologia Ágil ou Cascata. O gerente de projetos não precisa ser um especialista na Metodologia Ágil,</p><p>mas sempre que houver qualquer tido de “ruído” com relação aos processos seguidos e durante a</p><p>condução de qualquer projeto, ele deverá requisitar a presença do especialista em processos para que</p><p>se realize qualquer tipo de alinhamento necessário com toda a equipe envolvida. Um dos maiores riscos</p><p>de qualquer projeto é a falta de alinhamento e comunicação, por isso é fundamental o alinhamento de</p><p>valores e princípios do Manifesto Ágil.</p><p>2. Quais os principais benefícios de um Projeto Ágil com relação a um projeto baseado no</p><p>modelo tradicional (cascata – waterfall)?</p><p>A alternativa "B " está correta.</p><p>Um dos principais benefícios de um Projeto Ágil com relação a um projeto tradicional, com certeza, é a</p><p>entrega contínua de software com valor agregado ao cliente. Possuir um menor foco em documentação</p><p>não significa dizer que nenhuma documentação será produzida ao longo do processo. Muito pelo</p><p>contrário, toda documentação necessária e que agregue valor à entrega final do projeto deve ser</p><p>produzida. O que deve ser descartado é documentação desnecessária e que não agregue nenhum valor</p><p>ao projeto. É um erro muito comum acreditar que em projetos ágeis existe a liberdade de não seguir</p><p>processos e que não haverá nenhuma burocracia. Em qualquer tipo de projeto, os processos devem ser</p><p>seguidos para que se alcance o resultado esperado.</p><p>3. UMA DAS PRINCIPAIS CARACTERÍSTICAS DE UM</p><p>PROJETO ÁGIL É O ESCOPO ABERTO, OU SEJA, DURANTE</p><p>A CONDUÇÃO DO PROJETO, NOVOS REQUISITOS PODEM</p><p>SER DESCOBERTOS E O CLIENTE TERÁ A LIBERDADE DE</p><p>PRIORIZAR OU DESPRIORIZAR REQUISITOS PARA QUE</p><p>ESTES FAÇAM PARTE DAS ENTREGAS DE CADA SPRINT</p><p>PLANEJADA. O GRANDE PROBLEMA DO ESCOPO ABERTO</p><p>É QUE NÃO EXISTE UMA VISÃO CLARA DO ORÇAMENTO</p><p>NECESSÁRIO NO INÍCIO DO PROJETO PARA A ENTREGA</p><p>DE TODOS OS REQUISITOS QUE O CLIENTE POSSA VIR A</p><p>DESEJAR DURANTE A CONDUÇÃO DE TODO O PROJETO. É</p><p>IMPORTANTE DESTACAR QUE NOS PROJETOS ÁGEIS NÃO</p><p>EXISTE UM FOCO EM PRODUZIR DOCUMENTAÇÃO, MAS,</p><p>POR OUTRO LADO, COMO PODE UMA ESTIMATIVA</p><p>REALIZADA EM APENAS DOIS DIAS TER SIDO TÃO</p><p>ASSERTIVA SEM NENHUMA OU</p><p>tanto</p><p>em qualidade quanto em redução de tempo para receber seus produtos. Por isso, o Product Owner (PO)</p><p>deve ficar atento às constantes mudanças de prioridades de negócio exigidas pelo mercado ou clientes</p><p>e fazer com que essas mudanças sejam refletidas no Product Backlog. Por isso, constantemente o PO</p><p>deve refinar o product backlog.</p><p>REFINAMENTO DO BACKLOG DO PRODUTO</p><p>O refinamento é um processo para deixar o backlog sempre com PBI preparados para serem</p><p>apresentados para a reunião de planejamento da sprint. Enquanto o time de desenvolvimento trabalha</p><p>na Sprint atual para desenvolver as entregas, o PO deve preparar os PBI candidatos para as próximas</p><p>sprints. Os PBI candidatos são os prioritários que representam mais valor para o negócio naquele</p><p>momento.</p><p>BACKLOG DA SPRINT</p><p>Consiste nos PBI que foram selecionados do product backlog na reunião de planejamento para compor</p><p>o trabalho a ser realizado na sprint.</p><p>INCREMENTO (INCREMENT)</p><p>É o produto do trabalho realizado na sprint. Este incremento deve estar pronto segundo o padrão de</p><p>qualidade estipulado na definição de pronto (DoD). O incremento é um produto potencialmente utilizável</p><p>após sua aceitação na reunião de revisão da sprint.</p><p>DEFINIÇÃO DE “PRONTO”</p><p>A definição de pronto (definition of done) fornece transparência para o time Scrum e partes interessadas</p><p>sobre o trabalho da sprint. É uma definição sobre o padrão de qualidade que a entrega possuirá. Na</p><p>estimativa das histórias, o time de desenvolvimento deve ter em mente o esforço que precisará</p><p>dispender para aplicar em cada entrega os critérios de qualidade definidos na definição de pronto. Na</p><p>review, todos sabem que os itens entregues devem atender à definição de pronto.</p><p>COMO RODAR O SCRUM</p><p>Pessoas com perfil de SM e PO, devem ser identificadas e, se necessário, capacitadas para</p><p>exercerem as responsabilidades de cada papel.</p><p>Os especialistas devem decidir os melhores componentes para a composição do time de</p><p>desenvolvimento.</p><p>O SM deve apoiar o PO na criação do product backlog que represente valor para o negócio.</p><p>O PO deve apresentar as histórias de usuário candidatas a entrarem na sprint, e na reunião de</p><p>planejamento do time, puxa as histórias de usuário para comporem a sprint backlog.</p><p>O PO e o time devem definir a meta da sprint.</p><p>O time desenvolve o incremento do produto durante a sprint e realiza as reuniões diárias para</p><p>inspecionar o andamento do desenvolvimento do incremento.</p><p>Ao final da sprint, na reunião de revisão, o time apresenta a entrega para o PO, que pode aceitar</p><p>ou rejeitar os itens.</p><p>O time Scrum realiza uma reunião de retrospectiva para identificar oportunidade de melhoria no</p><p>processo.</p><p>O ciclo se repete até a entrega de todo o backlog e, consequentemente, o produto.</p><p>Agora, aprenda um pouco mais sobre o Scrum assistindo ao vídeo abaixo:</p><p>TEXTO</p><p>VERIFICANDO O APRENDIZADO</p><p>1. EM UMA REUNIÃO DE REVISÃO DO PRODUTO, O DONO DO PRODUTO</p><p>INFORMA QUE A ENTREGA NÃO ESTÁ TOTALMENTE DIFERENTE DO QUE FOI</p><p>PEDIDO E AINDA DIZ QUE NÃO SABE DO QUE SE TRATA A ENTREGA.</p><p>DADO O CONTEXTO ACIMA, QUAL PILAR DO SCRUM FOI DESCONSIDERADO?</p><p>A) Transparência</p><p>B) Respeito</p><p>C) Inspeção</p><p>D) Adaptação</p><p>2. QUAL ITEM ABAIXO NÃO É UM PAPEL DO SCRUM?</p><p>A) Scrum Master</p><p>B) Product Owner</p><p>C) Gerente de projeto</p><p>D) Time de desenvolvimento</p><p>GABARITO</p><p>1. Em uma reunião de revisão do produto, o dono do produto informa que a entrega não está</p><p>totalmente diferente do que foi pedido e ainda diz que não sabe do que se trata a entrega.</p><p>Dado o contexto acima, qual pilar do Scrum foi desconsiderado?</p><p>A alternativa "A " está correta.</p><p>A transparência é um pilar que deve ser perseguido constantemente por todo o time Scrum. A</p><p>transparência faz com que não existam surpresas na revisão do produto. No cenário acima, se o dono</p><p>do produto tivesse participado da reunião de planejamento, respondido às perguntas do time, ajudado a</p><p>elucidar as dúvidas e ainda ficado disponível para o time durante a sprint, provavelmente não ocorreria</p><p>problema de falta de transparência sobre o que foi entregue.</p><p>2. Qual item abaixo não é um papel do Scrum?</p><p>A alternativa "C " está correta.</p><p>O time Scrum é composto dos seguintes papéis: Scrum Master, Product Owner e Time de</p><p>Desenvolvimento. Isso não quer dizer que em um projeto não possamos ter um gerente de projeto, mas</p><p>ele não é um papel preconizado no Scrum.</p><p>CONCLUSÃO</p><p>CONSIDERAÇÕES FINAIS</p><p>Durante nossa jornada, vimos um marco importante da criação do conceito da Agilidade, o Manifesto</p><p>Ágil. Assinado por 17 expoentes do ramo de desenvolvimento de software, os valores e princípios do</p><p>Manifesto apontam a necessidade de pensarmos primeiramente nas pessoas, tanto as que</p><p>desenvolvem produtos, quanto as que usam os produtos; a necessidade de colaborarmos com o cliente;</p><p>a necessidade de frequentemente validarmos se o que está sendo entregue está alinhado com as</p><p>expectativas do cliente, entre outras.</p><p>Na sequência, vimos o método ágil de desenvolvimento Extreme Programming (XP), que também possui</p><p>seus valores, mas inteiramente aderentes aos valores do Manifesto. Estudamos as práticas</p><p>preconizadas pelo XP que apoiam o desenvolvimento de software com qualidade. Por fim, vimos o</p><p>método ágil Scrum, seus valores, pilares, papéis, responsabilidades, eventos e artefatos.</p><p>AVALIAÇÃO DO TEMA:</p><p>REFERÊNCIAS</p><p>AGILE MANIFESTO. Agile Manifesto. Consultado em meio eletrônico em: 29 set. 2020.</p><p>JEFFRIES, R. What is extreme programming? In: Ronjeffries. Publicado em: 16 mar. 2011.</p><p>KENNETH, S. R. Scrum essencial: Um guia prático para o mais popular processo ágil. Traduzido por</p><p>Roberto Rezende. Rio de Janeiro: Alta Books, 2017.</p><p>MASSARI, V. Gerenciamento Ágil de Projetos. Rio de Janeiro: Brasport, 2014.</p><p>SCRUM GUIDES. Guia do Scrum. Publicado em: out. 2017.</p><p>SUTHERLAND, J. Scrum: A arte de fazer o dobro do trabalho na metade do tempo. São Paulo: LeYa,</p><p>2016.</p><p>TELES, V. M. Extreme Programming: Aprenda como encantar seus usuários desenvolvendo software</p><p>com agilidade e alta qualidade. Rio de Janeiro: Novatec, 2004.</p><p>WILDT, D. eXtreme Programming: Práticas para o dia a dia no desenvolvimento ágil de software. São</p><p>Paulo: Casa do Código, 2015.</p><p>EXPLORE+</p><p>Para saber mais sobre os assuntos tratados neste tema, pesquise na internet:</p><p>Scrum e XP direto das Trincheiras, Infoq.</p><p>Leia:</p><p>Aplicação do método ágil Scrum no desenvolvimento de produtos de software em uma pequena</p><p>empresa de base tecnológica, Scielo.</p><p>Uma estratégia baseada em aquisição de conhecimento para o gerenciamento de riscos nos</p><p>requisitos em um desenvolvimento XP distribuído, Scielo.</p><p>Orientações para o processo de certificação SCM (Scrum Master Certified) da Scrum Alliance.</p><p>Orientações para o processo de certificação PSM (Professional Scrum Master) da Scrum.org.</p><p>Orientações para o processo de certificação EXIN Agile Scrum Foundation.</p><p>CONTEUDISTA</p><p>Wagner Rodrigues Ribeiro</p><p> CURRÍCULO LATTES</p><p>javascript:void(0);</p><p>POUCA DOCUMENTAÇÃO</p><p>EXISTENTE? QUAIS SERIAM SUAS AÇÕES COMO</p><p>GERENTE DE PROJETOS PARA QUE FOSSE MINIMIZADO</p><p>QUALQUER TIPO DE RISCO DEVIDO À CRIAÇÃO DE UMA</p><p>FALSA EXPECTATIVA AO CLIENTE COM RELAÇÃO A PRAZO</p><p>E CUSTO TOTAL?</p><p>RESPOSTA</p><p>Um dos principais problemas em qualquer tipo de projeto é a criação de falsas expectativas com relação a</p><p>prazo e custo. Por outro lado, dificilmente uma empresa iniciará um projeto sem ter uma visão clara de</p><p>quanto será necessário investir e quando será a entrega do projeto. Por essa razão, é fundamental que todos</p><p>javascript:void(0)</p><p>os envolvidos estejam devidamente alinhados com relação a todos os processos e a metodologia que será</p><p>seguida, antes mesmo do início do projeto. O maior risco de um projeto é a execução do próprio projeto. Se</p><p>não houver uma concordância sobre os processos e a metodologia a ser seguida, é mais prudente que nem</p><p>se inicie um projeto. Não existe garantia nenhuma de prazo e custo em um levantamento superficial que foi</p><p>realizado em apenas dois dias, isso com certeza criou uma falsa expectativa na empresa SPE com relação a</p><p>prazo e custo e o gerente de projetos e toda a equipe enfrentaram muitos problemas durante toda a</p><p>execução do projeto. Se o projeto foi contratado no modelo de “escopo aberto”, então deveria ter ficado claro</p><p>para o cliente que não há garantia nenhuma com relação a prazo e custo total. O prazo e o orçamento</p><p>variarão com o andamento e as entregas do projeto, o cliente poderá ter total liberdade de solicitar o</p><p>encerramento do projeto se não houver mais orçamento disponível.</p><p>MANIFESTO ÁGIL</p><p>O Manifesto Ágil configura um marco no contexto do desenvolvimento de software e consequentemente</p><p>na gestão de projetos para esta indústria. O documento foi assinado em um encontro nos dias 12 e 13</p><p>de fevereiro de 2001 em Snowbird, Utah, EUA, pelos seguintes expoentes desse nicho: Kent Beck, Mike</p><p>Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim</p><p>Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Bob Martin, Stephen Mellor, Jeff</p><p>Sutherland, Ken Schwaber e Dave Thomas.</p><p>Os signatários já atuavam com alguns métodos como: XP (Extreme Programming), DSDM (Dynamic</p><p>System Development Model), ASD (Adaptive Software Development), FDD (Feature-Driven</p><p>Development), Crystal e Scrum.</p><p>Esses métodos compartilhavam conceitos que foram incorporados ao manifesto por meio de suas ideias</p><p>como valores e princípios.</p><p>A figura 1 apresenta o que ficou popularizada como “cebola ágil”. As camadas simbolizam a relevância</p><p>na transformação ágil em uma organização. As camadas internas são mais fáceis de mostrar, mas não</p><p>representam criação de cultura ágil. Os processos e ferramentas podem ser impostos por uma gestão</p><p>autoritária, por exemplo. Já as camadas como valores e princípios são fundamentais para a criação do</p><p>mindset, ou seja, da forma de pensar ágil.</p><p>Os valores e princípios do manifesto foram criados na ocasião basicamente para atender às dores</p><p>conhecidas no desenvolvimento de software, mas com a propagação dos métodos ágeis, o mercado foi</p><p>percebendo os benefícios da agilidade em diversas áreas, como: RH, jurídico, comercial, inovação, entre</p><p>outras.</p><p>Imagem: Shutterstock.com</p><p> Figura 1- “Cebola” Ágil”.</p><p>Adaptada de Adventures With Agile pelo Autor.</p><p>Foto: SeventyFour / Shutterstock.com</p><p>VALORES</p><p>Segundo o Agile Manifesto (2001), estamos descobrindo maneiras melhores de desenvolver software,</p><p>fazendo-o nós mesmos e ajudando outros a fazerem o mesmo. Através deste trabalho, passamos a</p><p>valorizar:</p><p>Foto: Shutterstock.com</p><p>VALOR 1 - INDIVÍDUOS E INTERAÇÕES MAIS QUE</p><p>PROCESSOS E FERRAMENTAS</p><p>Com esse valor, o manifesto apresenta a preocupação em colocarmos mais foco nas pessoas e nas</p><p>relações entre elas, do que ficarmos apoiados em processos e ferramentas. A ideia é fornecermos</p><p>condições para que os times executem suas tarefas e não perdermos tempo em engessar o trabalho</p><p>com processos. Outro ponto é a supervalorização das ferramentas. Ferramentas, como o próprio nome</p><p>diz, devem servir de apoio.</p><p>Foto: Shutterstock.com</p><p>VALOR 2 - SOFTWARE EM FUNCIONAMENTO MAIS QUE</p><p>DOCUMENTAÇÃO ABRANGENTE</p><p>A má interpretação deste valor foi responsável pelo mito que projetos ágeis não possuem</p><p>documentação. Mas o que o valor quer dizer é que mais do que documentação abrangente devemos</p><p>priorizar produto na mão do cliente, mas isso não quer dizer que não se documenta em projetos ágeis.</p><p>Se a entrega esperada pelo cliente contempla documentação, esta deverá ser adicionada ao conjunto</p><p>de critérios de aceitação.</p><p>Foto: Shutterstock.com</p><p>VALOR 3 - COLABORAÇÃO COM O CLIENTE MAIS QUE</p><p>NEGOCIAÇÃO DE CONTRATOS</p><p>É óbvio que a relação entre empresas deve ser baseada em contratos, mas se não houver colaboração</p><p>com o cliente, com preocupação em entender suas dores e expectativas, e com ciclos curtos de</p><p>feedback para validação de que as entregas atendem às necessidades, o contrato não será suficiente</p><p>para segurar a relação.</p><p>Foto: Shutterstock.com</p><p>VALOR 4 - RESPONDER A MUDANÇAS MAIS QUE SEGUIR</p><p>UM PLANO</p><p>A má interpretação deste valor também foi responsável pelo mito de que a agilidade não possui</p><p>planejamento. Na verdade, o que este valor apresenta é que, como atuamos muitas vezes em contextos</p><p>complexos, com muitas incertezas, devemos, mais do que seguir um plano, experimentar, validar e</p><p>adaptar.</p><p>Imagem: PopTika / Shutterstock.com</p><p>PRINCÍPIOS</p><p>Os princípios são preceitos básicos para a condução de práticas de agilidade ou utilização de métodos</p><p>ágeis. Para que um método possa ser chamado de ágil, este não pode infringir nenhum dos doze</p><p>princípios abaixo:</p><p></p><p>1. NOSSA MAIOR PRIORIDADE É SATISFAZER O CLIENTE</p><p>ATRAVÉS DA ENTREGA CONTÍNUA E ADIANTADA DE</p><p>SOFTWARE COM VALOR AGREGADO</p><p>Com ciclos curtos de desenvolvimento, conseguimos ter inspeção e adaptação, que possibilitam validar</p><p>frequentemente se o que está sendo entregue atende à expectativa de valor pelo cliente.</p><p>2. MUDANÇAS NOS REQUISITOS SÃO BEM-VINDAS,</p><p>MESMO TARDIAMENTE NO DESENVOLVIMENTO.</p><p>PROCESSOS ÁGEIS TIRAM VANTAGEM DAS MUDANÇAS</p><p>VISANDO À VANTAGEM COMPETITIVA PARA O CLIENTE</p><p>A mudança faz parte do contexto de complexidade do mundo em que vivemos atualmente. Logo, se o</p><p>cliente deseja mudar, é porque ele precisa. Seja porque aquele requisito não atende mais à necessidade</p><p>ou ele aprendeu que o que foi solicitado pode ser melhorado para agregar mais valor ao produto.</p><p></p><p></p><p>3. ENTREGAR FREQUENTEMENTE SOFTWARE</p><p>FUNCIONANDO, DE POUCAS SEMANAS A POUCOS MESES,</p><p>COM PREFERÊNCIA À MENOR ESCALA DE TEMPO</p><p>Este princípio reforça a necessidade de software funcionando (produto) como medida de progresso,</p><p>ainda que com períodos curtos entre a solicitação e a entrega, para rapidamente colhermos feedback do</p><p>cliente, nos adaptarmos e melhorarmos o produto.</p><p>4. PESSOAS DE NEGÓCIO E DESENVOLVEDORES DEVEM</p><p>TRABALHAR DIARIAMENTE EM CONJUNTO POR TODO O</p><p>PROJETO</p><p>Durante o desenvolvimento de um produto em um projeto, quanto menor ruído de comunicação entre</p><p>quem define os requisitos e quem desenvolve os incrementos de produto, menor será o risco de não</p><p>aceitação da entrega. Assim, devemos promover constantemente a comunicação face a face, a fim de</p><p>reduzirmos a perda de entendimento entre a definição de requisitos e o desenvolvimento do produto.</p><p></p><p></p><p>5. CONSTRUA PROJETOS EM TORNO DE INDIVÍDUOS</p><p>MOTIVADOS. DÊ A ELES O AMBIENTE E O SUPORTE</p><p>NECESSÁRIO E CONFIE NELES PARA FAZER O TRABALHO</p><p>Este princípio demonstra a preocupação em criarmos um ambiente favorável ao trabalhador do</p><p>conhecimento. O líder precisa entender o propósito de cada colaborador, se suas atividades estão</p><p>alinhadas com esse propósito, se a pessoa que está desenvolvendo as atividades está motivada com o</p><p>que está fazendo, para propiciar o engajamento, dedicação, comprometimento dos membros do time no</p><p>desenvolvimento do produto.</p><p>6. O MÉTODO MAIS EFICIENTE E EFICAZ DE TRANSMITIR</p><p>INFORMAÇÕES PARA E ENTRE UMA EQUIPE DE</p><p>DESENVOLVIMENTO É ATRAVÉS DE CONVERSA FACE A</p><p>FACE</p><p>Reforçado por este princípio,</p><p>o conceito de times ágeis pressupõe equipes pequenas, para facilitar a</p><p>comunicação. Só com equipes pequenas podemos ter a comunicação face a face. Quando precisamos</p><p>executar grandes projetos com agilidade, é necessário escalarmos, ou seja, utilizarmos técnicas para</p><p>que vários pequenos times trabalhem juntos em um mesmo produto.</p><p></p><p></p><p>7. SOFTWARE FUNCIONANDO É A MEDIDA PRIMÁRIA DE</p><p>PROGRESSO</p><p>Ao contrário do que é apresentado geralmente em relatórios de status de projetos com percentual de</p><p>evolução de atividades, este princípio preconiza que software funcionando ou produto na mão do cliente</p><p>é a melhor medida de progresso. Melhor que uma informação de percentual de completude de uma</p><p>atividade é a entrega para o cliente de parte do produto potencialmente utilizável.</p><p>8. OS PROCESSOS ÁGEIS PROMOVEM DESENVOLVIMENTO</p><p>SUSTENTÁVEL. OS PATROCINADORES,</p><p>DESENVOLVEDORES E USUÁRIOS DEVEM SER CAPAZES</p><p>DE MANTER UM RITMO CONSTANTE INDEFINIDAMENTE</p><p>Agilidade pressupõe qualidade. Qualidade no produto entregue, mas também qualidade de vida para as</p><p>pessoas que trabalham no produto. Processos ágeis não incentivam sobrecarga de trabalho, como</p><p>horas extras, por exemplo. Em processos ágeis, as pessoas devem manter um ritmo de trabalho</p><p>sustentável constante indefinidamente.</p><p></p><p></p><p>9. CONTÍNUA ATENÇÃO À EXCELÊNCIA TÉCNICA E BOM</p><p>DESIGN AUMENTAM A AGILIDADE</p><p>Quando não é dada a devida atenção à qualidade técnica no desenvolvimento do produto, ocorre o que</p><p>chamamos de dívidas técnicas. Em desenvolvimento de softwares, essas dívidas técnicas podem ser</p><p>código mal feito, sem testes necessários, entre outros fatores, que com o passar do tempo irão consumir</p><p>o prazo da equipe para corrigi-los, com isso a capacidade da equipe em entregar novas funcionalidades</p><p>é comprometida com dívidas técnicas.</p><p>10. SIMPLICIDADE É ESSENCIAL</p><p>Muitas vezes a resolução de um problema está em uma solução simples. Ao apresentar uma solução</p><p>simples, o time estará sendo Lean (enxuto), quer dizer: Entregando valor com menos recursos e menos</p><p>tempo. Soluções elaboradas podem requerer um custo agregado de testes elaborados e risco de</p><p>aumento de dívida técnica.</p><p></p><p></p><p>11. AS MELHORES ARQUITETURAS, REQUISITOS E</p><p>DESIGNS EMERGEM DE EQUIPES AUTO-ORGANIZÁVEIS</p><p>Em times ágeis, devemos buscar a auto-organização. Times auto-organizados recebem o objetivo da</p><p>entrega e se auto-organizam para definirem a melhor forma de construir o produto. Com isso, as</p><p>melhores arquiteturas emergem dessa união de perfis diferentes em prol do objetivo comum de construir</p><p>uma melhor arquitetura para suportar a entrega do produto.</p><p>12. EM INTERVALOS REGULARES, A EQUIPE REFLETE</p><p>SOBRE COMO SE TORNAR MAIS EFICAZ E ENTÃO REFINA</p><p>E AJUSTA SEU COMPORTAMENTO DE ACORDO</p><p>Este princípio preconiza que os times ágeis, por exemplo ao final de um ciclo de entrega, devem realizar</p><p>uma retrospectiva com o objetivo de entender o que deu certo, o que deu errado e como podem</p><p>melhorar para o próximo ciclo.</p><p></p><p> ATENÇÃO</p><p>O manifesto ágil, com sua definição de valores e princípios, configurou um marco no contexto do</p><p>desenvolvimento de software e, consequentemente, na gestão de projetos para esta indústria.</p><p>Posteriormente, entendeu-se que em outras áreas, os métodos ágeis também poderiam ser utilizados</p><p>com sucesso, e atualmente temos agilidade em processos financeiros, de RH, comercial, marketing,</p><p>inovação entre outros.</p><p>Assista ao vídeo a seguir para saber mais sobre valores e princípios do Manifesto Ágil.</p><p>VERIFICANDO O APRENDIZADO</p><p>1. DE ACORDO COM O QUE VOCÊ ESTUDOU NESTE MÓDULO, SELECIONE A</p><p>SENTENÇA QUE NÃO REPRESENTA UM VALOR DO MANIFESTO ÁGIL:</p><p>A) Em detrimento de muita documentação, entregue software funcionando.</p><p>B) Priorize a relação com seu cliente ao invés de recorrer constantemente ao contrato.</p><p>C) Siga seu plano à risca e defina um processo que não acate mudanças.</p><p>D) O processo não é mais importante que as pessoas e suas relações.</p><p>2. ASSINALE O PRINCÍPIO DO MANIFESTO ÁGIL QUE NÃO ESTÁ DE ACORDO</p><p>COM A REALIZAÇÃO DE EXCESSIVAS HORAS EXTRAS.</p><p>A) Nossa maior prioridade é satisfazer o cliente através da entrega contínua e adiantada de software</p><p>com valor agregado.</p><p>B) Os processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, desenvolvedores e</p><p>usuários devem ser capazes de manter um ritmo constante indefinidamente.</p><p>C) Simplicidade é essencial.</p><p>D) Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e então refina e ajusta seu</p><p>comportamento de acordo.</p><p>GABARITO</p><p>1. De acordo com o que você estudou neste módulo, selecione a sentença que não representa</p><p>um valor do Manifesto Ágil:</p><p>A alternativa "C " está correta.</p><p>O quarto valor do Manifesto Ágil diz para respondermos às mudanças mais que seguirmos um plano. As</p><p>mudanças devem ser acatadas, porque os ciclos curtos permitem a adaptação para responder às</p><p>mudanças. Este valor não fala de não seguir um plano, mas, sim, de responder às mudanças ser mais</p><p>importante que seguir um plano.</p><p>2. Assinale o princípio do Manifesto Ágil que não está de acordo com a realização de excessivas</p><p>horas extras.</p><p>A alternativa "B " está correta.</p><p>O oitavo princípio do Manifesto Ágil diz que a equipe deve manter um ritmo sustentável</p><p>indefinitivamente, logo não devemos ter variações de carga de trabalho, como horas extras, para que a</p><p>equipe possa manter esse ritmo. O ritmo sustentável de um time ágil é determinado pelo respeito à sua</p><p>capacidade durante o tempo da construção do produto. Este ritmo deve evitar variações como sobre ou</p><p>subcarga de trabalho para que não tenhamos períodos de ociosidade, bem como não devemos permitir</p><p>sobrecarga para que não tenhamos problemas de saúde dos membros do time e também má qualidade</p><p>na entrega do produto.</p><p>MÓDULO 2</p><p> Identificar as principais características do método Extreme Programming</p><p>Imagem: Profit_Image / Shutterstock.com</p><p>LIGANDO OS PONTOS</p><p>Você sabe o que é uma Programação em Par? Você, como o gerente responsável pela área de</p><p>desenvolvimento de uma empresa de TI, recebe a missão de desenvolver um software que será uma</p><p>inovação para o mercado financeiro e, para isso, resolve adotar a programação em par, que é uma das</p><p>práticas da metodologia Extreme Programming, com o objetivo de criar um ambiente de</p><p>desenvolvimento mais colaborativo. Para entendermos esse conceito na prática, vamos analisar o caso</p><p>da empresa HW Consulting.</p><p>A empresa HW Consulting é uma empresa privada que atua na área de Tecnologia da Informação. A HW</p><p>Consulting é estruturada basicamente em duas verticais de negócio, produção e comercialização de</p><p>hardware (servidores, computadores pessoais, impressoras e dispositivos bancários) e desenvolvimento</p><p>de sistemas voltados para instituições financeiras, principalmente bancos financeiros.</p><p>A HW Consulting nasceu da aquisição de uma empresa especializada na produção e comercialização de</p><p>dispositivos bancários (impressoras, leitoras de cartão, PIN pads e outros) em 1992. Em 2004, a HW</p><p>Consulting iniciou o desenvolvimento de uma plataforma bancária aberta conhecida como Open</p><p>Banking. O Open Banking era uma ideia totalmente inovadora em termos de negócio e das tecnologias</p><p>utilizadas. Cada banco possuía seu sistema financeiro próprio por meio da utilização de diferentes tipos</p><p>de protocolos e tecnologias da informação.</p><p>A principal ideia do Open Banking era criar um sistema baseado em um protocolo comum de</p><p>comunicação e de uma tecnologia inovadora e altamente escalável – ser escalável significa ser aberto à</p><p>implementação de futuras melhorias de acordo com a necessidade do mercado global. A tecnologia</p><p>selecionada foi a linguagem C# da plataforma de desenvolvimento Microsoft .NET. Essa linguagem de</p><p>programação é uma das tecnologias mais promissoras da Microsoft e tem evoluído de forma constante</p><p>ao longo dos anos.</p><p>Outro grande desafio do Open Banking era que todo o sistema deveria ser executado por meio da Web,</p><p>ou seja, todas as transações financeiras mais comuns (saque, depósito, extrato, abertura e</p><p>encerramento de conta, pagamentos,</p><p>transferências e outros) deveriam ser executadas em qualquer</p><p>navegador de Internet, tais como o Internet Explorer do Windows e o Safari do Mac OS. Como havia a</p><p>necessidade de muita comunicação com hardware, boa parte das interfaces com o hardware havia sido</p><p>desenvolvida nas linguagens C e C++. Sendo assim, era um ambiente de desenvolvimento de alta</p><p>complexidade que necessitava estar sob um ambiente altamente colaborativo para que o projeto fosse</p><p>bem-sucedido.</p><p>APÓS A LEITURA DO CASE, É HORA DE APLICAR SEUS</p><p>CONHECIMENTOS! VAMOS LIGAR ESSES PONTOS?</p><p>1. O QUE VEM A SER O EXTREME PROGRAMMING (XP)?</p><p>A) O Extreme Programming é uma metodologia focada no desenvolvimento de softwares que somente</p><p>pode ser adotada por empresas experientes na área de TI.</p><p>B) O Extreme Programming é uma metodologia focada no desenvolvimento de softwares que deu</p><p>origem ao Scrum.</p><p>C) O Extreme Programming é um conjunto de processos que possibilita o desenvolvimento padrão de</p><p>softwares.</p><p>D) O Extreme Programming é um conjunto de boas práticas no desenvolvimento de softwares.</p><p>E) O Extreme Programming é uma metodologia focada no desenvolvimento de softwares que possui</p><p>valores e princípios, que são fundamentados por um conjunto de práticas.</p><p>2. NO QUE CONSISTE A PROGRAMAÇÃO EM PAR?</p><p>A) A Programação em Par consiste em dois programadores que trabalharão juntos para resolver o</p><p>mesmo problema. O desenvolvedor que assume o teclado e digita é chamado condutor, enquanto o</p><p>outro que acompanha é chamado de navegador, que fará um trabalho de estrategista.</p><p>B) A Programação em Par consiste em dois programadores que trabalharão de forma separada para</p><p>resolver o mesmo problema.</p><p>C) A Programação em Par consiste em dois programadores que trabalharão para resolver o mesmo</p><p>problema, mas em diferentes etapas. Um dos programadores será responsável pela codificação</p><p>enquanto o outro será responsável pela revisão.</p><p>D) A Programação em Par consiste em dois ou mais programadores que trabalharão juntos para</p><p>resolver o mesmo problema.</p><p>E) A Programação em Par consiste em dois programadores que trabalharão juntos para resolver</p><p>diferentes tipos de problemas. A troca de ideias será constante entre os programadores.</p><p>GABARITO</p><p>1. O que vem a ser o Extreme Programming (XP)?</p><p>A alternativa "E " está correta.</p><p>A metodologia de desenvolvimento de softwares Extreme Programming (XP) é leve e pode ser</p><p>facilmente adotada por diferentes níveis de equipes de desenvolvimento (iniciantes a experientes) e em</p><p>qualquer tamanho de equipe. O XP é considerado uma excelente metodologia de desenvolvimento de</p><p>softwares, que pode ser facilmente adaptável aos requisitos de negócio que podem mudar facilmente.</p><p>2. No que consiste a Programação em Par?</p><p>A alternativa "A " está correta.</p><p>A Programação em Par consiste em dois programadores que trabalharão para resolver o mesmo</p><p>problema e este será um grande benefício para a modelagem da solução, pois quando uma solução é</p><p>modelada por dois programadores, ela tende a ser mais eficiente do que quando modelada por uma só</p><p>pessoa. Geralmente, os programadores utilizam de conhecimentos e experiências que se acumularam</p><p>ao longo de suas carreiras, então, acaba ocorrendo um somatório dessas experiências, o que é muito</p><p>bom para o projeto.</p><p>3. NA SUA VISÃO COMO GERENTE DE DESENVOLVIMENTO</p><p>DA HW CONSULTING, A ADOÇÃO DA METODOLOGIA</p><p>EXTREME PROGRAMMING TROUXE EXCELENTES</p><p>RESULTADOS PARA A EMPRESA, PRINCIPALMENTE COM A</p><p>ADOÇÃO DA PROGRAMAÇÃO EM PAR – PAIR</p><p>PROGRAMMING. ACONTECE QUE ESTÁ OCORRENDO</p><p>MUITO RUÍDO NAS OUTRAS ÁREAS DA EMPRESA, DE QUE</p><p>OS RECURSOS HUMANOS ESTÃO SENDO UTILIZADOS DE</p><p>FORMA INEFICIENTE, SENDO QUE SEMPRE UM</p><p>DESENVOLVEDOR PROGRAMA, ENQUANTO O OUTRO FICA</p><p>PARADO CONVERSANDO. QUE EXEMPLO DE AÇÃO VOCÊ</p><p>TOMARIA PARA CONSCIENTIZAR O RESTANTE DA</p><p>EMPRESA DE QUE A PROGRAMAÇÃO EM PAR ESTÁ, DE</p><p>FATO, GERANDO BONS RESULTADOS PARA OS</p><p>PROJETOS?</p><p>RESPOSTA</p><p>javascript:void(0)</p><p>A técnica da Programação em Par pode parecer estranha para muitas pessoas, principalmente para aqueles</p><p>que desconhecem a metodologia Extreme Programming. Como gerente de desenvolvimento, uma das</p><p>primeiras ações necessárias para reduzir o ruído seria a elaboração de workshops internos apresentando os</p><p>benefícios da metodologia Extreme Programming para toda a empresa. Ruídos devem ser eliminados o mais</p><p>rápido possível, pois um dos maiores problemas que levam ao fracasso é a falta de comunicação e esses</p><p>ruídos podem impactar negativamente na tomada de decisão por parte das principais partes interessadas –</p><p>Stakeholders dos projetos. Mas, como um bom gerente de desenvolvimento, não bastaria somente um</p><p>workshop focado em conceitos. Seria muito importante o levantamento de dados reais (horas de esforço,</p><p>tamanho de equipe, prazos, custos e indicadores de qualidade) nos quais fossem apresentadas as</p><p>diferenças do antes e do depois da implementação da metodologia Extreme Programming. Com certeza,</p><p>uma justificativa baseada em indicadores reais tem um peso muito maior do que simplesmente a</p><p>apresentação de conceitos.</p><p>EXTREME PROGRAMMING</p><p>O Extreme Programmig (XP) é um método de desenvolvimento de software criado por três dos</p><p>signatários do Manifesto Ágil: Kent Beck, Ward Cunningham e Ron Jeffries. O XP, além de ser</p><p>inteiramente aderente aos valores e princípios do Manifesto Ágil, fato que o credencia como um método</p><p>ágil, também é fundamentado em seus próprios valores e práticas.</p><p>VALORES</p><p>Os valores denotam o grau de importância de um determinado tema e representam as melhores ações a</p><p>serem tomadas no contexto deste tema. De acordo com Wildt (2015), o XP define cinco valores para</p><p>que seus papéis e práticas atuem de acordo com sua essência ágil: A comunicação, o feedback, a</p><p>simplicidade, o respeito e a coragem.</p><p>Foto: Shutterstock.com</p><p>COMUNICAÇÃO</p><p>A comunicação figura como a principal causa em fracasso em projetos de software na maioria das</p><p>pesquisas do ramo. O contexto de desenvolvimento de software envolve muitas incertezas, logo</p><p>precisamos dar muita atenção à comunicação, ainda mais em ambientes de equipes remotas onde a</p><p>comunicação face a face ocorre por meio de recursos eletrônicos, podendo acarretar perda de</p><p>informação.</p><p>FEEDBACK</p><p>O feedback rápido e frequente é outra forma de minimizar riscos em ambiente de desenvolvimento de</p><p>software. Muitas vezes, o cliente só percebe o que realmente precisa ao receber as primeiras versões</p><p>do que pediu, e quanto mais cedo o time receber o feedback, mais cedo fará as adaptações</p><p>necessárias.</p><p>Foto: Black Salmon / Shutterstock.com</p><p>Foto: sutadimages / Shutterstock.com</p><p>SIMPLICIDADE</p><p>A simplicidade é um valor que ajuda o time a manter o foco no valor que realmente precisa entregar. O</p><p>foco é essencial para evitar desperdícios no processo de desenvolvimento de software.</p><p>RESPEITO</p><p>Este valor deve ser praticado por todos. Tanto os membros dos times quanto clientes e outras partes</p><p>interessadas. Criar um ambiente onde se pratica o respeito, sem necessidade de encontrar culpados e</p><p>focado em criar um ambiente agradável de trabalho certamente contribuirá para a formação de um time</p><p>de alta performance, mais motivado e com empatia, que pratica o respeito tanto com seus pares, quanto</p><p>com a qualidade do produto que está sendo desenvolvido, que se traduz em respeito com o cliente.</p><p>Foto: sutadimages / Shutterstock.com</p><p>Foto: fizkes / Shutterstock.com</p><p>CORAGEM</p><p>As práticas dos valores anteriores, principalmente o respeito, estimulam a formação de um ambiente</p><p>onde os membros do time tenham coragem para fazer o que é preciso, por exemplo, refatorar um código</p><p>(ver prática: refatoração). Os membros dos times precisam se sentir em um ambiente safe to fail, que</p><p>significa, em livre tradução, um ambiente seguro para falhar, para que possam ter coragem de fazer o</p><p>que é preciso, sem se sentirem inseguros e com medo de serem penalizados.</p><p>PRÁTICAS</p><p>No Extreme Programmig, membros do time e cliente interagem para definir, priorizar e entregar o</p><p>produto utilizando as práticas de desenvolvimento de software. Segundo</p><p>Teles (2004), o time precisa ter</p><p>coragem e acreditar que a utilização dessas práticas e valores do XP fará o software evoluir com</p><p>segurança e agilidade.</p><p>Imagem: Jeffries, 2011.</p><p> Figura 2 - Práticas Extreme Programming.</p><p>Veja um pouco mais sobre cada uma dessas práticas:</p><p>EQUIPE INTEIRA</p><p>Colaboração com partes interessadas, como cliente, deve ser uma prática constante da equipe com o</p><p>objetivo de promover a interação com o time para fornecer requisitos e prioridades para o time de</p><p>desenvolvimento.</p><p>Foto: George Rudy / Shutterstock.com</p><p>Segundo Massari (2014), o princípio de equipe inteira ou equipe unida parte da premissa de que a</p><p>equipe deve ser formada por generalistas e não por especialistas.</p><p>Foto: George Rudy / Shutterstock.com</p><p>JOGO DE PLANEJAMENTO</p><p>Oportunidade na qual cliente e time de desenvolvimento se reúnem para decidir quais entregas entrarão</p><p>na próxima release e iterações. Uma release pode ser uma versão de um software ou um módulo do</p><p>software.</p><p>No jogo do planejamento, o cliente e o time trabalham juntos, colaborativamente para planejarem a</p><p>entrega de uma release. Uma release poderá ter várias iterações. No jogo, o cliente definirá o escopo, a</p><p>prioridade e a expectativas de data de entrega. O time estima o trabalho apresentado em forma de</p><p>história de usuário e aponta dependências técnicas, caso existam. Os desenvolvedores puxam as</p><p>histórias e se comprometem com sua entrega.</p><p> ATENÇÃO</p><p>Os incrementos de produto são definidos em um plano de release e as iterações são definidas em um</p><p>plano de iterações. Um incremento pode ser desenvolvido em uma ou mais iterações.</p><p>PEQUENAS ENTREGAS</p><p>Entregas pequenas e frequentes são essenciais para a obtenção de feedback.</p><p> COMENTÁRIO</p><p>Com essa prática, o time valida se está indo no caminho correto ou precisa corrigir parte do produto para</p><p>atender à expectativa do cliente.</p><p>TESTES DE ACEITAÇÃO (CLIENTE)</p><p>Ao definir o requisito, o cliente define os critérios de aceitação para o requisito. A equipe deve</p><p>desenvolver o objeto do requisito à luz dos critérios de aceitação, e implementar testes automatizados</p><p>para validar se o que foi desenvolvido está de acordo com o que foi pedido pelo cliente.</p><p>Foto: George Rudy / Shutterstock.com</p><p>Foto: George Rudy / Shutterstock.com</p><p>PROPRIEDADE COLETIVA DO CÓDIGO</p><p>Os códigos desenvolvidos em times XP são compartilhados entre os membros da equipe evitando que</p><p>indivíduos sejam seus proprietários. Isso é muito importante para que a produtividade não caia quando,</p><p>por algum motivo, um membro esteja indisponível. Outro ponto importante é que a qualidade aumenta</p><p>quando mais de uma pessoa trabalha no código, em razão do compartilhamento do conhecimento.</p><p>PADRÃO DO CÓDIGO</p><p>Os times XP seguem um padrão de codificação para manter a produtividade coletiva.</p><p> COMENTÁRIO</p><p>Assim, quando um membro for trabalhar em um código desenvolvido por outro membro, não haverá</p><p>problema de entendimento.</p><p>RITMO SUSTENTÁVEL</p><p>De acordo com o WHAT IS EXTREME PROGRAMMING, assim como abordamos no módulo anterior, os</p><p>times XP devem manter um ritmo de trabalho que possa perdurar por muito tempo, evitando grandes</p><p>variações de carga de trabalho, como, por exemplo, com a realização de horas extras.</p><p>Foto: George Rudy / Shutterstock.com</p><p>METÁFORAS</p><p>As metáforas são utilizadas para manter uma linguagem comum entre os membros do time XP.</p><p>É uma técnica para que todos saibam identificar rapidamente uma determinada rotina ou sistema.</p><p>Quando alguém se referir a determinado nome, não deixará dúvida sobre o que ele está mencionando.</p><p>Isso é mais fácil do que explicar sobre o que se está falando.</p><p> COMENTÁRIO</p><p>Segundo Wildt (2015) usamos metáforas em nosso cotidiano para facilitar nosso entendimento, como o</p><p>carrinho de compras de uma loja virtual ou a área de trabalho de nosso computador com nossas pastas.</p><p>INTEGRAÇÃO CONTÍNUA</p><p>Os times XP integram seus códigos várias vezes ao dia.</p><p> ATENÇÃO</p><p>Quanto mais tempo levar para integrar os códigos escritos, mais difícil será para ajustar erros. Por isso,</p><p>é muito importante integrar continuamente o código.</p><p>Foto: George Rudy / Shutterstock.com</p><p>TESTES UNITÁRIOS</p><p>Os testes unitários servem para fornecer feedback imediato ao desenvolvedor ou ao par de</p><p>desenvolvedores. Na execução do código principal, o código do teste também é executado, informando</p><p>se o código feito está com erro ou não.</p><p>REFATORAÇÃO</p><p>A melhoria contínua é uma preocupação dos métodos ágeis e no XP não é diferente.</p><p>A refatoração ou melhoria contínua é uma técnica para melhorar o código minimizando problemas como</p><p>duplicidade de código.</p><p>Para Massari (2014), o princípio da refatoração consiste em melhorar a qualidade do código existente,</p><p>tornando-o mais elegante e legível, porém sem alterar o comportamento da funcionalidade.</p><p>DESIGN SIMPLES</p><p>Alinhado ao valor simplicidade, o XP preconiza que o design do software comece simples e continue</p><p>assim, mesmo com o incremento de funcionalidades no sistema.</p><p> COMENTÁRIO</p><p>As práticas como testes unitários, programação em par e refatoração ajudam a evoluir com o software e</p><p>manter seu design simples.</p><p>PROGRAMAÇÃO EM PAR</p><p>De acordo com Massari (2014), os códigos produzidos por times que adotam o XP são desenvolvidos</p><p>em par, mas em uma mesma máquina.</p><p> ATENÇÃO</p><p>Está técnica propicia não só um melhor compartilhamento de código, mas também de conhecimentos, o</p><p>que propicia alcançar melhor qualidade, identificar riscos e formar equipes de alto desempenho.</p><p>Outra técnica muito utilizada no Extreme Programmig, que também aparece no Scrum, é a história de</p><p>usuário.</p><p>Seu formato simples requer uma conversação face a face para coletar detalhes do cliente pelo time de</p><p>desenvolvimento. Exemplos de histórias de usuários:</p><p>Eu, como médico, quero pesquisar prontuário do paciente pelo número do CPF.</p><p>Eu, como cliente, quero pesquisar restaurantes próximos à minha casa.</p><p>As práticas do Extreme Programmig de desenvolvimento de software foram tão consolidadas pelo</p><p>mercado que atualmente é comum serem utilizadas em conjunto com outros métodos ágeis, por</p><p>exemplo, o Scrum.</p><p>Foto: Lipik Stock Media/ Shutterstock.com</p><p>PAPÉIS DO XP</p><p>O Extreme Programming preconiza alguns papéis que objetivam equilibrar as responsabilidades</p><p>inerentes ao desenvolvimento de software. Conforme Wildt (2015), em alguns casos, um indivíduo pode</p><p>acumular papéis, desde que não haja conflito de interesses, por exemplo, um indivíduo que atua em um</p><p>papel de gerente, sendo pressionado para realizar uma determinada entrega, e este mesmo indivíduo</p><p>atuando como coach com necessidade de trabalhar com mais paciência e foco na evolução</p><p>comportamental do time.</p><p>DESENVOLVEDOR</p><p>O desenvolvedor, também conhecido como programador, é um papel com atribuições ligadas</p><p>diretamente à criação do software com qualidade. As atribuições do desenvolvedor vão desde a</p><p>estimativa das atividades até a entrega do produto. Em times ágeis multidisciplinares é comum termos</p><p>desenvolvedores com especialidades específicas como front-end ou back-end. Mas podemos ainda ter</p><p>indivíduos que possuem competência para atuar em todas essas áreas, como os chamados atualmente</p><p>de full stacks. Obviamente, este perfil é muito interessante para um time ágil, mas não é fácil montar</p><p>times com vários indivíduos assim, pelo fato de geralmente pedirem uma remuneração maior e serem</p><p>mais difíceis de ser encontrados no mercado para contratação, uma vez que são profissionais que</p><p>costumam possuir um nível mais elevado de conhecimentos.</p><p>CLIENTE</p><p>O cliente é o papel que mais conhece do negócio. No Scrum, existe um papel semelhante a este, que é</p><p>conhecido como Product Owner. O cliente do Extreme Programming é quem define os requisitos em</p><p>formato de histórias de usuário, bem como sua priorização para os desenvolvedores materializá-las em</p><p>produto. O papel do cliente é fundamental para fornecer o feedback rápido em relação ao produto.</p><p>Sabemos que mesmo com uma boa definição do requisito e frequente comunicação do cliente com a</p><p>equipe, ainda é possível que, ao utilizar</p><p>o produto, a experiência possa não atender à expectativa do</p><p>cliente, por isso é importante que o cliente alimente o time de desenvolvimento com constantes</p><p>feedbacks sobre a sua percepção de utilização do produto.</p><p>COACH</p><p>O XP é intimamente orientado ao lado comportamental do time. Isso quer dizer que além da capacidade</p><p>técnica, o time precisa respeitar valores, aderir às práticas, ter disciplina com os ritos necessários do</p><p>método. Para ajudar o time a criar essa cultura, o XP conta com o papel do coach. O coach precisa</p><p>conhecer bem de desenvolvimento de sistemas e ser um técnico capaz de ajudar o time a assimilar os</p><p>valores e utilizar as práticas do XP. O coach é o líder servidor, ele facilita cerimônias, como jogo do</p><p>planejamento, reuniões diárias e retrospectivas e é o guardião dos valores do XP. Ele serve à equipe XP,</p><p>identifica necessidades de cada membro, como a realização de um treinamento para que um</p><p>desenvolvedor possa melhor realizar suas atividades. O coach também pode acumular o papel com um</p><p>desenvolvedor, por exemplo.</p><p>TESTADOR</p><p>O testador é um papel importante para garantir a qualidade do software. Dentre suas responsabilidades,</p><p>ele apoia o cliente a escrever testes de aceitação. O testador faz parte da equipe e pode apoiar a</p><p>automatização dos testes, bem como realizar testes funcionais para minimizar a probabilidade de</p><p>liberação de software com erros.</p><p>CLEANER</p><p>O cleaner é o indivíduo responsável por melhorar o código sempre apoiado nas práticas do XP. Ele deve</p><p>ter como característica a excelência técnica porque precisa enxugar o código sem obviamente perder</p><p>sua consistência. O cleaner deve encorajar o time a desenvolver códigos mais limpos e com qualidade</p><p>para minimizar problemas com dívida técnica. A dívida técnica ocorre quando o time não prima pela</p><p>qualidade do código e posterga ações de melhoria de qualidade. Com o tempo, os problemas vão se</p><p>acumulando e consumindo a capacidade do time de desenvolver novas funcionalidades, pelo fato de</p><p>ficarem ocupados corrigindo problemas causados por falta de atenção à qualidade no passado.</p><p>TRACKER</p><p>O tracker é responsável por coletar medições do time durante o projeto. Essas medições servem para</p><p>avaliar a evolução do time e suas entregas. Por exemplo, a medição da quantidade de histórias de</p><p>usuários entregues com sucesso. Quando um time começa a entender seu padrão de entregas por</p><p>iteração (ciclos de entregas), é possível utilizar essa métrica para prever entregas de produtos no futuro.</p><p>GERENTE</p><p>O gerente é um papel que auxilia o time XP com a comunicação com clientes e partes interessadas do</p><p>projeto. Ele é responsável pela elaboração e manutenção de relatórios sobre a evolução do projeto. Seu</p><p>papel não é o de chefe do time XP, mas, sim, o de líder servidor, sempre procurando avaliar as</p><p>necessidades do time para prestar suporte naquilo que for necessário para melhorar o seu desempenho</p><p>e motivação para a entrega de produtos de qualidade.</p><p>Antes de finalizar o módulo, assista ao vídeo abaixo e tenha mais clareza sobre o que é Extreme</p><p>Programmig e seus valores.</p><p>TEXTO</p><p>VERIFICANDO O APRENDIZADO</p><p>1. CARLOS É UM DESENVOLVEDOR EM UM TIME QUE UTILIZA O MÉTODO</p><p>EXTREME PROGRAMMING. ELE DESENVOLVEU UM CÓDIGO E ESTÁ MUITO</p><p>ORGULHOSO DO QUE FEZ, A PONTO DE NÃO QUERER MOSTRAR PARA</p><p>NINGUÉM SEU CÓDIGO COM RECEIO QUE COPIEM SUAS IDEIAS. QUAL DAS</p><p>PRÁTICAS LISTADAS ABAIXO FOI DESRESPEITADA NO CENÁRIO</p><p>APRESENTADO?</p><p>A) Metáforas</p><p>B) Design simples</p><p>C) Padrão de código</p><p>D) Propriedade coletiva do código</p><p>2. OS TIMES DE DESENVOLVIMENTO DE EMPRESA QUE UTILIZAM O MÉTODO</p><p>ÁGIL EXTREME PROGRAMMING REFEREM-SE AO SISTEMA QUE MAIS GERA</p><p>RECEITA PARA A EMPRESA COMO “MINA DE OURO” PARA QUE TODOS</p><p>SAIBAM SOBRE QUAL SISTEMA ESTÃO FALANDO. DADO O CONTEXTO ACIMA,</p><p>QUAL PRÁTICA DO EXTREME PROGRAMMING ESTÁ SENDO UTILIZADA?</p><p>A) Jogo do planejamento</p><p>B) Pequenas entregas</p><p>C) Metáforas</p><p>D) Ritmo sustentável</p><p>GABARITO</p><p>1. Carlos é um desenvolvedor em um time que utiliza o método Extreme Programming. Ele</p><p>desenvolveu um código e está muito orgulhoso do que fez, a ponto de não querer mostrar para</p><p>ninguém seu código com receio que copiem suas ideias. Qual das práticas listadas abaixo foi</p><p>desrespeitada no cenário apresentado?</p><p>A alternativa "D " está correta.</p><p>O código em equipes Extreme Programming deve ser desenvolvido em par para que não haja</p><p>propriedade de código. Este deve ser compartilhado para que o time tenha conhecimento que o risco de</p><p>só uma pessoa conhecer o código seja minimizado.</p><p>2. Os times de desenvolvimento de empresa que utilizam o método ágil Extreme Programming</p><p>referem-se ao sistema que mais gera receita para a empresa como “mina de ouro” para que</p><p>todos saibam sobre qual sistema estão falando. Dado o contexto acima, qual prática do Extreme</p><p>Programming está sendo utilizada?</p><p>A alternativa "C " está correta.</p><p>As metáforas são utilizadas pelo time para relacionar algo no ambiente de desenvolvimento de sistemas</p><p>a uma coisa fora deste ambiente. Por exemplo, a lixeira na área de trabalho, a própria área de trabalho,</p><p>o carrinho de compras em um site de buscas, a lupa como símbolo de buscas. As metáforas auxiliam na</p><p>criação de uma linguagem comum entre o time para referenciar objetos no sistema.</p><p>MÓDULO 3</p><p> Reconhecer as principais características do framework Scrum</p><p>Foto: Panchenko Vladimir/ Shutterstock.com</p><p>LIGANDO OS PONTOS</p><p>Você conhece as práticas do Scrum? Imagine você sendo o líder técnico de uma fábrica de softwares e</p><p>tomando a decisão de utilizar as práticas do Scrum em uma empresa que até então possui toda sua</p><p>metodologia de desenvolvimento de sistemas baseada em modelos tradicionais como o CMMi (Modelo</p><p>de Capacidade e Maturidade Integrado – Capability Maturity Model Integration). Para entendermos esse</p><p>conceito na prática, vamos analisar o caso da empresa FSW RS Ltda.</p><p>A empresa FSW RS Ltda. é uma filial gaúcha de uma fábrica de softwares brasileira com presença</p><p>global. Criada em 2009, a empresa surgiu como vencedora de um edital de licitação para atender a</p><p>diversos tipos de projetos de toda a rede pública do estado do Rio Grande do Sul.</p><p>Todos os processos e a principal metodologia de desenvolvimento de sistemas da FSW RS Ltda. eram</p><p>baseados nas práticas do modelo CMMi (Modelo de Capacidade e Maturidade Integrado – Capability</p><p>Maturity Model Integration), no qual era certificada como nível 5. O modelo CMMi é extremamente formal</p><p>e muito mais aderente ao modelo cascata, também conhecido como modelo Waterfall, em que</p><p>geralmente os projetos são organizados em grandes etapas e uma etapa só inicia após a aprovação</p><p>formal de toda documentação ou código da etapa anterior. O modelo CMMi envolve um processo</p><p>extremamente burocrático em que praticamente tudo que se produz necessita de aprovação e revisão</p><p>formal.</p><p>Processos formais são muito eficientes para grandes projetos, principalmente projetos para órgãos</p><p>públicos onde existe a necessidade da formalização dos requisitos por diversos níveis de</p><p>departamentos. As áreas da FSW RS Ltda. eram organizadas pelos seguintes processos: Gestão,</p><p>Análise, Desenvolvimento e Testes. Cada área possuía um líder técnico e deveria seguir a metodologia</p><p>de sua etapa, que era baseada no modelo CMMi. O líder técnico da área de desenvolvimento tinha</p><p>muita experiência com a utilização do Scrum e teve uma ideia muito interessante, que era utilizar as</p><p>práticas do Scrum na etapa de desenvolvimento de sistemas, ou seja, utilizar práticas, como a</p><p>organização das entregas por Sprints, criar a figura do Scrum Master, utilizar o Planning Poker para</p><p>estimar o tamanho dos requisitos (histórias de usuário) etc. Essa ideia foi muito bem recebida pela alta</p><p>gestão da FSW RS Ltda. e aplicada na prática, mas era um grande desafio conciliar as práticas do</p><p>Scrum com as práticas da atual metodologia baseada no CMMi.</p><p>APÓS A LEITURA DO CASE, É HORA DE APLICAR SEUS</p><p>CONHECIMENTOS! VAMOS LIGAR ESSES PONTOS?</p><p>1. O QUE VEM A SER O SCRUM?</p><p>A) O Scrum é uma metodologia de desenvolvimento de sistemas.</p><p>B) O Scrum</p><p>é um guia que reúne todos os processos necessários para que se desenvolva sistemas.</p><p>C) O Scrum é um framework ágil de desenvolvimento de produtos e serviços.</p><p>D) O Scrum é uma metodologia de desenvolvimento de sistemas baseada no modelo tradicional de</p><p>desenvolvimento.</p><p>E) O Scrum é uma Metodologia Ágil de desenvolvimento de sistemas que foi baseada no Extreme</p><p>Programming.</p><p>2. QUAIS SÃO OS TRÊS PILARES DO SCRUM?</p><p>A) Transparência, inspeção e adaptação.</p><p>B) Transparência, controle e adaptação.</p><p>C) Planejamento, controle e direção.</p><p>D) Planejamento, inspeção e adaptação.</p><p>E) Transparência, respeito e colaboração.</p><p>GABARITO</p><p>1. O que vem a ser o Scrum?</p><p>A alternativa "C " está correta.</p><p>O framework Scrum define uma estratégia flexível do desenvolvimento de produtos e serviços. Dada a</p><p>sua natureza flexível e de fácil implementação, o Scrum acaba por ser o framework ágil mais utilizado no</p><p>mundo inteiro. Um dos princípios-chave do Scrum é o reconhecimento de que os clientes podem, e vão,</p><p>mudar de ideia. Ou seja, mudar de ideia sobre o que eles querem, como eles querem e quando eles</p><p>querem. Em consequência, é de se esperar que desse modo os requisitos não possam ser gerenciados</p><p>da forma tradicional como prevista no modelo CMMi, por exemplo, em que esse tipo de modelo gerencia</p><p>os requisitos da maneira inicialmente planejada e aprovada pelo cliente.</p><p>2. Quais são os três pilares do Scrum?</p><p>A alternativa "A " está correta.</p><p>A transparência é um dos pilares-chave do Scrum e deve ser perseguida constantemente por todo time</p><p>Scrum. A inspeção será realizada por meio de cerimônias presentes no Scrum com o objetivo de</p><p>inspecionar o incremento do produto e do atingimento da meta da Sprint, garantindo que a Sprint seja</p><p>entregue conforme o esperado pelas partes interessadas no projeto. Projetos ágeis são utilizados em</p><p>projetos em que existe um nível muito alto de incerteza. Dessa forma, o pilar de adaptação permite que</p><p>o produto seja adaptado de modo rápido e de acordo com a expectativa das partes interessadas.</p><p>3. VOCÊ, COMO O LÍDER TÉCNICO QUE PROPÔS A</p><p>UTILIZAÇÃO DAS PRÁTICAS DO FRAMEWORK SCRUM NA</p><p>ETAPA DE DESENVOLVIMENTO DA FÁBRICA DE</p><p>SOFTWARES, PODERÁ TER UM GRANDE DESAFIO AO</p><p>CONCILIAR AS PRÁTICAS ÁGEIS DO SCRUM COM AS</p><p>PRÁTICAS DA METODOLOGIA ATUAL, QUE É BASEADA NO</p><p>MODELO CMMI. NA SUA VISÃO, QUAIS SERIAM OS</p><p>MAIORES DESAFIOS DESSE “MODELO HÍBRIDO”?</p><p>RESPOSTA</p><p>A atual metodologia da fábrica de softwares é baseada no modelo CMMi, que é um dos modelos mais</p><p>maduros e respeitados em nível global. Um dos prováveis requisitos que levou a empresa a ser a ganhadora</p><p>do processo de licitação foi o fato de a empresa ser certificada como nível 5. Geralmente, essas certificações</p><p>possuem validade, então, de tempos em tempos, a empresa deverá ser avaliada novamente para que essa</p><p>certificação seja mantida. Sendo assim, é extremamente importante que todos da empresa sigam as práticas</p><p>previstas nesse modelo. O framework Scrum, por sua vez, é baseado nas práticas ágeis e muito mais focado</p><p>em gerar resultado do que seguir processos extremamente burocráticos. Com a implantação do Scrum na</p><p>etapa de desenvolvimento, a equipe se sentirá mais motivada a colaborar. A natureza do Scrum já prevê um</p><p>ambiente colaborativo onde todos se sentem responsáveis por aquilo que está sendo produzido. Como líder</p><p>técnico, é extremamente importante garantir que o Scrum “rode” normalmente gerando os resultados</p><p>esperados pelas partes interessadas, mas, ao mesmo tempo, as saídas geradas pela etapa devem estar</p><p>100% aderentes ao que o modelo CMMi exige. Com certeza, é um grande desafio conciliar esses dois</p><p>modelos e fazer com que esse “modelo híbrido” atenda às expectativas de todas as partes interessadas e</p><p>javascript:void(0)</p><p>que esteja totalmente alinhado aos processos do modelo CMMi. Nesse “modelo híbrido”, é inevitável que o</p><p>esforço seja maior.</p><p>SCRUM</p><p>Segundo Sutherland (2016), Ken Schwaber e Jeff Sutherland, dois dos signatários do Manifesto Ágil</p><p>criaram o Scrum sob influência do artigo de nome The New New Product Development Game, de</p><p>Nonaka e Takeuchi. Neste artigo, eles apresentaram um estudo de equipes de algumas das empresas</p><p>mais produtivas e inovadoras do mundo: Honda, Fuji-Xerox, 3M, Hewlett-Packard, entre outras. O</p><p>desenvolvimento de software precisava de uma nova abordagem, pois o ciclo de vida em cascata já não</p><p>era eficiente para um cenário de complexidade.</p><p> VOCÊ SABIA</p><p>O nome Scrum vem de uma forma de reinício de jogada no rugby, na qual os jogadores dos dois times</p><p>se juntam e se empurram com o objetivo de ganhar a posse de bola. Esta jogada onde o time trabalha</p><p>unido com um objetivo comum influenciou a atribuição do nome da jogada para o método ágil.</p><p>A primeira apresentação pública formal do Scrum ocorreu quando Ken Schwaber e Jeff Sutherland</p><p>fizeram uma palestra do Scrum na Conferência OOPSLA de 1995.</p><p>De acordo com o Scrum Guide (2017), O Scrum pode ser considerado um framework usado para</p><p>gerenciar o trabalho em produtos complexos. O Scrum é leve, simples de entender, mas difícil de aplicar.</p><p>Foto: fizkes/ Shutterstock.com</p><p>TEORIA DO SCRUM</p><p>O Scrum é baseado no empirismo para controle de processo, isso quer dizer que o conhecimento vem</p><p>da experiência. Ao invés de fazermos previsões de entregas sem grande função em ambientes</p><p>complexos, cuja principal característica é a incerteza, com o empirismo, nós fazemos, aprendemos e aí</p><p>sim temos a condição de projetar uma entrega futura, mas como norte, como um objetivo a ser buscado,</p><p>pois não esqueçamos que ainda estamos em contexto complexo com muitas incertezas.</p><p> EXEMPLO</p><p>Por exemplo: Para que um time de desenvolvimento forneça uma estimativa para término de um</p><p>produto, ele precisará conhecer a velocidade média do time nas últimas iterações para poder projetar a</p><p>previsão.</p><p>PILARES</p><p>A implementação do controle de processo empírico é apoiada em três pilares</p><p>Imagem: Creative Stall / Shutterstock.com</p><p>TRANSPARÊNCIA</p><p>A transparência deve ser perseguida constantemente por todo o time Scrum. Por exemplo, não deve</p><p>haver dúvida sobre a situação da entrega do incremento de produto ao final de uma iteração (sprint).</p><p>Todos devem saber o que é um incremento pronto, isso é fornecido pela transparência. Por exemplo, se</p><p>o Product Owner (PO) reclamar ao final de uma sprint que o produto não está com a qualidade</p><p>esperada, provavelmente temos um problema de transparência sobre o que é uma entrega pronta. Se</p><p>houvesse transparência nesse time Scrum, o PO saberia qual era o acordo para entrega pronta. A</p><p>transparência garante que todos ao final de uma sprint saibam o que é um incremento pronto.</p><p>INSPEÇÃO</p><p>O Scrum, como veremos mais adiante, possui cerimônias que possibilitam a inspeção do incremento do</p><p>produto e do atingimento da meta da sprint. Por exemplo, em uma reunião diária, o time possui a</p><p>oportunidade de inspecionar se o trabalho que está sendo realizado está evoluindo no sentido de atingir</p><p>a meta, e caso não esteja, o time deverá adaptar seu plano para maximizar as chances de atingimento</p><p>do objetivo. Na reunião de revisão, o time possui outra oportunidade de inspecionar a entrega.</p><p>ADAPTAÇÃO</p><p>Como vimos nos módulos anteriores, os métodos ágeis são utilizados em ambientes complexos, com</p><p>muita incerteza. Nesses contextos, é necessário validar rapidamente se estamos no caminho certo e</p><p>corrigir o rumo. O Scrum não é diferente, o pilar adaptação possibilita a rápida adequação do que não</p><p>está de acordo. O framework Scrum preconiza iterações de até 30 dias para que possamos ter ciclos de</p><p>desenvolvimento curtos e consequentemente feedbacks curtos. A resposta rápida sobre o produto</p><p>propicia a adaptação do mesmo no sentido de se adequar à expectativa do cliente.</p><p>VALORES</p><p>Como vimos, no Extreme Programming os valores denotam o grau de importância de um determinado</p><p>tema e representam as melhores ações a serem tomadas no contexto deste tema. No Scrum não é</p><p>diferente, os valores precisam ser vividos e praticados por todos para que possamos criar um ambiente</p><p>de confiança e, consequentemente, fortalecer os pilares transparência, inspeção e adaptação.</p><p>CORAGEM</p><p>FOCO</p><p>COMPROMETIMENTO</p><p>RESPEITO</p><p>ABERTURA</p><p>CORAGEM</p><p>Os membros de um time Scrum precisam ter coragem para fazer a coisa certa, fazer o que é preciso.</p><p>Por exemplo: Informar que não estão confiantes em entregar a meta e apresentar os motivos ou ouvir</p><p>opiniões mesmo que sejam contrárias às suas.</p><p>FOCO</p><p>O time Scrum durante um ciclo de desenvolvimento mantém o foco nas entregas prioritárias ao negócio.</p><p>O time procura entregar o que é esperado com simplicidade e objetividade.</p><p>COMPROMETIMENTO</p><p>Como o Scrum é um método ágil, e como já vimos que métodos ágeis geralmente são utilizados para</p><p>problemas complexos, cuja principal característica é o contexto com muitas incertezas, o</p><p>comprometimento refere-se ao empenho, atitude e engajamento do time com os resultados, mas não</p><p>necessariamente com o atingimento dos resultados.</p><p>RESPEITO</p><p>Este valor refere-se não somente ao evidente respeito que devemos ter com qualquer pessoa com a</p><p>qual nos relacionamos, mas também respeito para com o cliente ao desenvolver software de qualidade.</p><p>ABERTURA</p><p>O time Scrum deve estar aberto a ser transparente constantemente durante a construção do produto; a</p><p>colaborar sem problemas em ser assertivo para dizer o que precisa ser dito. Abertura para ouvir críticas</p><p>construtivas que podem melhorar o comportamento profissional, bem como melhorar o processo ou o</p><p>produto.</p><p>TIME SCRUM</p><p>O time Scrum compõe um modelo desenhado para otimizar a flexibilidade, criatividade e produtividade.</p><p>Este modelo composto de papéis muito bem equilibrados com responsabilidades inerentes às atividades</p><p>de construção de produto em ambientes complexos.</p><p>Os times Scrum são auto-organizáveis e multifuncionais.</p><p>AUTO-ORGANIZÁVEIS</p><p>Auto-organizáveis no sentido de se organizarem para desenvolver o produto necessário, sem</p><p>precisar de chefe ou gerente para dizer como desenvolver as atividades</p><p>MULTIFUNCIONAIS</p><p>javascript:void(0)</p><p>javascript:void(0)</p><p>Multifuncionais no sentido que o time deve possuir os perfis necessários para o desenvolvimento</p><p>do produto de modo iterativo e incremental, maximizando o valor de suas entregas.</p><p>Imagem: NicoElNino/ Shutterstock.com</p><p>Muito embora o time Scrum não possua outros papéis além dos citados acima, o Scrum pode ser</p><p>utilizado em projetos com um gerente de projetos, por exemplo. O gerente de projetos pode trabalhar</p><p>com o Product Owner ou Scrum Master para apoiar no relacionamento com o restante da organização;</p><p>pode criar relatórios de evolução de projetos e pode trabalhar com o time Scrum para criar previsões</p><p>para entregas de projetos.</p><p>Os papéis de um time Scrum são: Product Owner, Scrum Master e Time de Desenvolvimento.</p><p>PRODUCT OWNER (DONO DO PRODUTO)</p><p>O Product Owner ou PO é o dono do produto. Ele define, transmite a visão do produto ao time de</p><p>desenvolvimento e é responsável por representar a visão do produto em um product backlog.</p><p>O PO é responsável por gerenciar o product backlog. Ele deve garantir que a necessidade mais</p><p>premente do negócio esteja refletida no topo da pilha de forma a garantir o retorno sobre o investimento</p><p>feito no produto. Imaginem que o patrocinador está financiando o produto e espera receber em entregas</p><p>parciais e frequentes o que mais representa valor naquele momento, por exemplo, uma entrega para</p><p>atender a uma promoção.</p><p>Imagem:Sakaidasan/ Shutterstock.com</p><p> ATENÇÃO</p><p>O PO deve interagir sempre com stakeholders, como clientes ou departamento de marketing para</p><p>identificar novas features ou tendências que poderão influenciar o produto. Ele deve também identificar,</p><p>por exemplo, com o help desk as reclamações dos usuários para retroalimentar o backlog com essas</p><p>necessidades. Com essa dinâmica, o PO gerencia a entrada e saída dos itens no backlog.</p><p>O PO é responsável por definir os PBI (product backlog items) e esclarecer as dúvidas do time de</p><p>desenvolvimento durante a sprint planning meeting (reunião de planejamento) sobre os itens que</p><p>entrarão na próxima sprint (ciclo de desenvolvimento).</p><p> RECOMENDAÇÃO</p><p>Ainda nesta reunião, o PO entra em acordo com o time de desenvolvimento sobre o objetivo da sprint.</p><p>Muito embora a sprint possa conter vários PBI, ela deve possuir um objetivo de entregar um incremento</p><p>de produto.</p><p>O PO é o único papel com autoridade para cancelar uma sprint. Ao detectar que o objetivo, meta da</p><p>sprint não faz mais sentido para o negócio, o PO pode cancelar a sprint.</p><p>SCRUM MASTER (LÍDER SCRUM)</p><p>O Scrum Master, SM, é quem mais conhece o Scrum dentre todos os papéis do Scrum.</p><p>Imagem: Sakaidasan/ Shutterstock.com</p><p>Ele é um líder servidor e deve apoiar todos no entendimento do Scrum, tanto o time Scrum quanto a</p><p>organização.</p><p>Assim como o PO está focado em criar um product backlog alinhado com as necessidades do cliente</p><p>para o time de desenvolvimento criar o produto certo, o SM é focado em apoiar o time Scrum a abraçar</p><p>os valores, princípios e práticas do Scrum, além de remover impedimentos e interagir com stakeholders</p><p>no sentido de apoiar o uso do Scrum dentro da organização. Isso tudo como líder servidor, sem fazer</p><p>uso de autoridade.</p><p> ATENÇÃO</p><p>O SM atua para o PO e time de desenvolvimento líder servidor, coach, facilitador dos eventos Scrum,</p><p>removedor de impedimentos e agente de mudança. Para o PO, por exemplo, o SM pode apoiar nas</p><p>atividades de criação e refinamento e ordenação do product backlog, que proporcione o</p><p>desenvolvimento do produto certo; para o time de desenvolvimento, pode atuar fazendo que ele</p><p>descubra as melhores formas para resolver os problemas encontrados na utilização do Scrum.</p><p>DEV TEAM (TIME DE DESENVOLVIMENTO)</p><p>Um time de desenvolvimento Scrum deve ter entre 3 e 9 componentes.</p><p>Imagem: Sakaidasan/ Shutterstock.com</p><p>Os times precisam ser pequenos para não perderem a capacidade de comunicação e também a auto-</p><p>organização.</p><p>Fórmula de canais de comunicação:</p><p>N * ( N - 1 ) / 2</p><p>Atenção! Para visualização completa da equação utilize a rolagem horizontal</p><p>Logo:</p><p>Para um time com 5 pessoas, temos: 5 * ( 5 - 1 ) / 2 canais de comunicação, mas se colocarmos uma</p><p>pessoa a mais no time, temos 6 * (6 - 1) / 2 = 15 canais de comunicação. Percebam neste exemplo</p><p>que, ao aumentarmos uma pessoa no time, aumentamos em 50% a quantidade de canais de</p><p>comunicação.</p><p>O time de desenvolvimento auto-organizado não precisa de um gerente para fazer microgestão de</p><p>atividades. Após a criação do forecast (previsão) da meta da sprint durante a sprint planning o time se</p><p>auto-organiza para a criação de um plano para desenvolvimento das entregas que compõem a meta da</p><p>sprint, sem precisar que um gerente diga como fazer.</p><p>O time de desenvolvimento pode incrementar o framework Scrum utilizando técnicas de</p><p>desenvolvimento de software como algumas abordadas no Módulo 2.</p><p>Imagem: Quick Creative / Shutetrstock.com</p><p> Figura 3 - Framework scrum.</p><p>A figura 3 apresenta o ciclo do Scrum com os artefatos: Product Backlog, sprint backlog e incremento,</p><p>bem como os eventos sprint planning, daily, sprint review e sprint retrospective.</p><p>Foto: Pra Chid/ Shutterstock.com</p><p>EVENTOS</p><p>O Scrum preconiza eventos que possibilitam oportunidades de transparência e inspeção. Cada evento</p><p>possui seu propósito claro dentro do Scrum e também um tempo limite (time-boxed), para que não se</p><p>perca o foco em cada evento.</p><p>SPRINT PLANNING (REUNIÃO DE PLANEJAMENTO)</p><p>A reunião de planejamento da sprint é o primeiro evento dentro da sprint. Nele o time e o PO debatem</p><p>sobre a meta da sprint e os PBI, ou seja, os itens que farão parte do backlog da sprint. Esta reunião de</p><p>time-box dura no máximo oito horas para uma sprint de um mês de duração.</p><p>Imagem: MicroOne / Shutterstock.com</p><p>META OU OBJETIVO DA SPRINT</p><p>O conceito de meta ou objetivo da sprint é bastante relevante para entendermos o que deve ser entrega</p><p>na sprint. Quando o time Scrum não trabalha com esse conceito, ele atua como um time “tarefeiro” ou</p><p>seja, preocupa-se com entrega de histórias do sprint backlog (histórias</p><p>que compõem o escopo da</p><p>sprint). Desta forma, o PO chega a um acordo com o time sobre quantas histórias eles puxam para a</p><p>sprint e, ao final, na reunião de revisão, é verificado quantas histórias foram entregues. Já um time</p><p>orientado à meta define com o PO a meta, o objetivo, ou seja, qual a entrega relevante para o negócio</p><p>será realizada ao término da sprint. Essa entrega obviamente é composta por histórias de usuário, mas</p><p>podemos ter dentro da sprint histórias que não fazem parte da meta. Assim, o time deve priorizar a</p><p>entrega da meta, o compromisso é com a meta. Esta é a diferença de um time orientado a meta e um</p><p>time orientado a tarefas.</p><p>É importante entender que o time possui uma capacidade de trabalho durante a sprint. O trabalho</p><p>puxado pelo time de desenvolvimento deverá ser factível de ser executado dentro do período da sprint.</p><p>Percebam que usei o verbo “puxar”. Em agilidade não se empurra trabalho. Isso significa que o time de</p><p>desenvolvimento avalia os itens com o PO, estima um a um e só puxa do backlog do produto para o</p><p>backlog da sprint a quantidade de itens que a capacidade de trabalho da equipe comporta realizar com a</p><p>qualidade acordada (definição de pronto) dentro da duração da sprint.</p><p>ESTIMATIVA</p><p>Não existe um padrão para estimativa, mas uma forma muito usada são os pontos por história. Os</p><p>pontos por história são uma forma de estimativa relativa na qual o time de desenvolvimento atribui</p><p>tamanho de cada história de usuário. Exemplo: Para um item simples o time pode atribuir tamanho 1,</p><p>para um maior pode atribuir tamanho 3. Uma técnica muito utilizada para isso é o planning poker, na</p><p>qual o time utiliza um baralho com uma numeração, geralmente com a série de Fibonacci e cada</p><p>membro, após entender o que é para ser feito na história, joga uma carta com uma numeração, sem que</p><p>os outros vejam para não influenciá-los. Caso haja discrepância na numeração jogada, os membros</p><p>argumentam sobre os motivos da estimativa de cada e jogam novamente até chegaram ao consenso,</p><p>com isso o tamanho da história de usuário é atribuído.</p><p>Como a duração da sprint é fixa e o time só puxa para o sprint backlog a quantidade de itens que</p><p>consegue entregar, o time de desenvolvimento começa a conhecer sua velocidade (velocity). A</p><p>velocidade é uma métrica que serve para estimativas de demandas futuras.</p><p>Uma vez que conhecemos a capacidade de trabalho do time de desenvolvimento em uma sprint,</p><p>podemos fazer previsões.</p><p>Segundo Kenneth (2017), é importante determinar a capacidade do time porque só conhecendo a</p><p>capacidade poderemos saber o que o time pode entregar.</p><p>Após definir os itens que entrarão no backlog da sprint, o time se auto-organiza para definir um plano</p><p>para atingimento da meta ao final da sprint.</p><p>SPRINT</p><p>A sprint é o evento que contém outros eventos, ou seja, os outros eventos ocorrem dentro de uma sprint.</p><p>A sprint deve ter no máximo um mês de duração e, ao definir esta duração, o ideal é que não seja</p><p>alterada durante a evolução do produto ou projeto. Este tempo máximo de um mês é para permitir ciclos</p><p>de feedbacks curtos, para validação da entrega, que possibilitem inspeção e adaptação.</p><p> VOCÊ SABIA</p><p>Assim como não se deve alterar a duração sprint, da mesma forma, não se altera escopo que possa</p><p>comprometer a meta da sprint, também não se altera o padrão de qualidade acordado para as entregas.</p><p>A sprint só pode ser cancelada pelo PO se a meta (objetivo) da sprint se tornar obsoleta.</p><p>Durante a sprint, geralmente o time utiliza um quadro físico ou virtual para acompanhamento da</p><p>evolução do trabalho. Não existe regra para a confecção desses quadros, mas normalmente são criadas</p><p>as colunas: sprint backlog para colocar os post-its com as histórias de usuário contidas na sprint</p><p>backlog; Fazendo, para as histórias de usuários que estão sendo feitos e Feitas para as histórias de</p><p>usuário prontas. À medida que as histórias vão sendo desenvolvidas, os post-its são movidos nas</p><p>colunas, até todas migrarem para a coluna Feitas.</p><p>Imagem: Iconic Bestiary / Shutterstock.com</p><p>DAILY MEETING (REUNIÃO DIÁRIA)</p><p>É um evento de time-box de no máximo 15 minutos no qual o time de desenvolvimento aproveita a</p><p>oportunidade para inspecionar a evolução do trabalho em direção ao atingimento da meta da sprint.</p><p>Neste evento, cada membro do time de desenvolvimento responde:</p><p>O que eu fiz ontem que ajudou a atingir a meta da sprint?</p><p>O que eu farei hoje para ajudar a atingir a meta da sprint?</p><p>Existe impedimento que atrapalhe a mim ou o time de desenvolvimento para atingir a meta da sprint?</p><p>A reunião diária é um evento do time de desenvolvimento, logo não há necessidade de mais ninguém</p><p>participar além do time, à exceção se for convidado pelo time ou o Scrum Master perceber que o time</p><p>precisa para seguir os valores e pilares do Scrum. O time também pode pedir apoio ao PO para</p><p>participar e esclarecer algo da sprint backlog que, por ventura, não tenha ficado claro.</p><p> ATENÇÃO</p><p>Obviamente, a meta da sprint é obtida por meio da conclusão das histórias de usuário contidas na sprint,</p><p>mas o time deve sempre se focar no atingimento da meta. Este é um ponto de atenção, pois pode</p><p>acontecer de o time se focar em atividades e descolar da meta. A priorização da execução das</p><p>atividades dentro da sprint deve ser orientada à meta.</p><p>SPRINT REVIEW (REVISÃO DA SPRINT)</p><p>É um evento de time-box de no máximo 4 horas para uma sprint de um mês.</p><p>Neste evento, o time de desenvolvimento apresenta para o PO e stakeholders o que foi feito durante a</p><p>sprint e o PO aprova ou não o incremento do produto que visa a atender a meta da sprint.</p><p>Este evento visa a inspecionar o produto e os participantes colaborarem sobre o que deverá ser</p><p>considerado para a próxima sprint.</p><p> ATENÇÃO</p><p>O Scrum quando é implementado por um responsável sem experiência pode gerar várias disfunções</p><p>capazes de prejudicar muito o entendimento do framework. Não é difícil encontrarmos no mercado</p><p>sprints de testes, ou após a Reunião de Revisão da Sprint fazerem a “homologação”. Como disse, são</p><p>disfunções, porque ao final de uma sprint, deve ser entregue um incremento de produto potencialmente</p><p>utilizável, ou seja, os itens contidos da Definição de Pronto (ver definição de pronto) devem ser</p><p>executados. O padrão de qualidade definido deve ter sido atingido para o item ser aceito na reunião de</p><p>revisão.</p><p>SPRINT RETROSPECTIVE (RETROSPECTIVA DA</p><p>SPRINT)</p><p>É o último evento de uma sprint e possui um time-box de no máximo 3 horas para uma sprint de um</p><p>mês. Seu propósito é inspeção do próprio time. É comum nesse evento o time colaborar para identificar</p><p>coisas que deram certo, que deram errado e criar um plano de melhoria para as próximas sprints.</p><p>A retrospectiva da sprint é uma oportunidade para o time refletir sobre o processo, sobre o como foi a</p><p>sprint que se encerra com o evento desta reunião. O Scrum Master deve facilitar esta reunião de modo</p><p>que o time encontre um ambiente favorável para falar. Muitas vezes, os membros não falam dos</p><p>problemas para evitarem o conflito, mas o conflito respeitoso é saudável, ele traz foco ao problema e</p><p>fornece transparência (vejam o pilar transparência novamente) aos pontos de atenção. Detectada a</p><p>causa raiz, é possível traçar plano de ação para o time corrigir o problema e melhorar continuamente.</p><p>Imagem: Shutterstock.com</p><p>ARTEFATOS</p><p>Segundo o Scrum Guide (2017), os artefatos representam o trabalho ou o valor para o fornecimento de</p><p>transparência e oportunidades para inspeção e adaptação. Os artefatos definidos para o Scrum são</p><p>especificamente projetados para maximizar a transparência das informações-chave de modo que todos</p><p>tenham o mesmo entendimento dos artefatos.</p><p>BACKLOG DO PRODUTO</p><p>Consiste em uma pilha de PBI (product backlog items) que pode conter histórias de usuários, itens</p><p>técnicos e correções, ordenados por valor, onde o que está no topo da pilha corresponde aos itens com</p><p>mais valor para o negócio.</p><p>O backlog do produto é um artefato em constante mudança. O cliente está cada vez mais exigente</p>