Estudo de caso 1 2

Prévia do material em texto

FMU – FACULDADES METROPOLITANAS UNIDAS
ANÁLISE E DESENVOLVIMENTO DE SISTEMAS
ESTUDO DE CASO – MÉTODOS ÁGEIS
SÃO PAULO 
2020
GUILHERME BAROM MACARIO – RA 3968553
LAYON SILVA DE OLIVEIRA – RA 3983224
VIVIANE DE CASTRO MOREIRA – RA 3978836
ESTUDO DE CASO – MÉTODOS ÁGEIS
 Trabalho para o curso de graduação 
Análise e Desenvolvimento de Sistemas
Orientador: Prof. Dr. Adilson de Oliveira 
SÃO PAULO
2020
Abstract : In the business environment, quality and agility comprise fundamental principles to keep a company competitive [Boehm & Turner, 2004]; That said, organizations are using agile methods to not only improve product quality, but also to streamline project processes. This study analyzes and indicates an agile method for a software factory scenario, as well as details some relevant points of one of the most used agile methods today
Resumo : No ambiente empresarial, qualidade e agilidade compreendem princípios fundamentais para manter uma empresa competitiva [Boehm & Turner, 2004]; posto isso, as organizações estão a utilizar métodos ágeis para não só melhorar a qualidade do produto ,como também, para agilizar os processos do projeto. Este estudo analisa e indica um método ágil para um cenário de fabrica de software, como também detalha alguns pontos relevantes de um dos métodos ágeis mais utilizados na atualidade.
1 INTRODUÇÃO:
Diante dos desafios de um mundo corporativo, marcado pela alta tecnologia e competitividade, o desenvolvimento de produtos e serviços de software precisou acompanhar esse ritmo. Para isso, surgiram os chamados métodos ágeis. Os métodos ágeis (do inglês Agile Software Development), como o próprio nome diz, envolve um conjunto de metodologias que serve para acelerar o ritmo dos processos de desenvolvimento de software.
Para ser um método ágil é necessário ser um método compatível com o manifesto ágil, portanto, deve estar de acordo com os 4 valores e 12 princípios do manifesto ágil[footnoteRef:1]. [1: O Manifesto Ágil é uma declaração de valores e princípios essenciais para o desenvolvimento de software. Ele foi criado em fevereiro de 2001, onde se reuniram 17 profissionais que já praticavam métodos ágeis como XP, DSDM, SCRUM, FDD e etc.] 
Valor ágil I – Indivíduos e interações acima de processos e ferramentas
Desenvolvimento de software é uma atividade humana e a comunicação em si pode ser uma grande aliada durante todo o processo de desenvolvimento, diminuindo ruídos e aproximando pessoas. Processos e Ferramentas são importantes, claro, mas devem ser usados de forma pragmática.
Valor ágil II – Software funcionando é melhor que documentação abrangente
Software em pleno funcionamento é o melhor indicador possível de que o trabalho foi bem executado. Clientes pagam por resultado e não por um plano bem elaborado que nunca vai sair do papel.
Valor ágil III – Colaboração com o cliente acima de negociação de contratos
Jamais atuar contra o cliente ou colocar ele contra o time de desenvolvimento. A palavra de ordem é: colaboração. A tomada de decisões deve sempre estar de acordo com os objetivos do cliente.
Valor ágil IV – Responder a mudanças ao invés de seguir um plano
Utilizar os feedbacks obtidos durante o processo mais a observação do cenário são fatores fundamentais para darmos respostas rápidas sobre os rumos da operação envolvida.
Além de seus 4 valores, o Manifesto Ágil conta também com 12 princípios para a prática do desenvolvimento ágil:
1- A maior prioridade está em satisfazer o cliente por meio da entrega adiantada e contínua de software de valor.
2- Mudanças de requisitos são bem-vindas, mesmo em fases tardias do desenvolvimento. Os processos Ágeis utilizam a mudança em favor da vantagem competitiva para o cliente.
3- Entregar software em funcionamento com frequência, desde a cada duas semanas até a cada dois meses, com uma preferência por prazos mais curtos.
4- Tanto pessoas relacionadas a negócios como desenvolvedores devem trabalhar em conjunto, diariamente, durante todo o curso do projeto
5- Para construir projetos ao redor de indivíduos motivados, é preciso dar a eles o ambiente e o suporte necessários, confiando que farão seu trabalho.
6- O método mais eficiente de transmitir informações tanto externas como internas para um time de desenvolvimento é por meio de uma conversa cara a cara.
7- Um software funcional é a medida primária de progresso.
8- Processos ágeis promovem um ambiente sustentável, com patrocinadores, desenvolvedores e usuários sendo capazes de manter passos constantes.
9- A contínua atenção à excelência técnica e ao bom design aumenta a agilidade.
10- Simplicidade é a arte de maximizar a quantidade de trabalho que não precisou ser feito.
11- As melhores arquiteturas, os requisitos e os designs emergem de times auto organizáveis.
12- Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e otimizam seu comportamento de acordo.
Basicamente, os métodos ágeis são um conjunto de práticas eficazes que se destinam a permitir a entrega rápida e de alta qualidade do produto, tendo uma abordagem de negócios que alinha o desenvolvimento do projeto com as necessidades do cliente e os objetivos da empresa. Existem diversos métodos ágeis e escolher o método ideal pode ser um desafio, nada obstante, Vale salientar que não há a “melhor metodologia”, mas a solução mais adequada dentro do contexto da empresa.
Uma fábrica de software que desenvolve um produto específico por exemplo, pode ter como o método ágil mais adequado o método Scrum, que é, sem dúvida, o método ágil mais usado nos dias de hoje, principalmente porque pode ser integrado a outros métodos ágeis com facilidade, aplicando-se não só ao desenvolvimento de softwares como a qualquer ambiente de trabalho.
Com foco na gestão do projeto, o Scrum tem como base o planejamento iterativo e incremental, que se dá, pelas reuniões conhecidas como Sprints[footnoteRef:2]. [2: Uma sprint é uma reunião de pessoas envolvidas num projeto para promover um desenvolvimento mais focalizado do projeto. Sprints geralmente duram de uma a três semanas. Sprints têm se tornado eventos populares em alguns projetos open-source.] 
Ele reitera, desde o início do projeto, a lista de funcionalidades a serem desenvolvidas — prática também chamada, no caso, de product backlog[footnoteRef:3]. [3: o Backlog do produto é uma lista ordenada de tudo o que se sabe ser necessário no produto. É a única fonte de requisitos para quaisquer alterações a serem feitas no produto. O Dono do Produto é responsável pelo Backlog do Produto, incluindo seu conteúdo, disponibilidade e pedido.] 
No andamento do processo, cada funcionalidade se torna um Sprint, cujos detalhes a serem criados e desenvolvidos passam do product backlog para o sprint backlog.
Do sprint backlog, as atividades são distribuídas entre os membros do Scrum Team, que devem desenvolvê-las dentro de um prazo que geralmente não leva mais de quatro semanas.
Ao final de cada sprint é realizada a sprint review meeting, uma reunião de alinhamento sobre o que foi entregue. A partir daí, começa-se a planejar o próximo sprint. Essas etapas acontecem sucessivamente até que o produto final esteja pronto para a entrega. Diferentemente dos demais métodos ágeis, o Scrum tem papéis muito bem definidos e absolutamente essenciais para o sucesso do projeto:
· indivíduos e interação mais do que processos e ferramentas;
· software em funcionamento mais do que documentação;
· colaboração com o cliente mais do que contratos e negociações;
· respostas a mudanças mais do que planejamento.
 Product backlog
Como mencionado o Scrum tem como base o planejamento iterativo e incremental e o modelo iterativo e o modelo incremental são bastantes famosos.
No modelo de processo de software incremental tem-se a ideia de se desenvolver uma implementação inicial, apresentá-la ao usuário e evoluir o software ao longo do tempo de acordo com o feedback do usuário.
Cada incremento representaum subconjunto completo de funcionalidades. O incremento pode ser pequeno ou grande, e pode variar de uma simples tela de login a um conjunto altamente flexível de telas de gerenciamento de dados.
O processo iterativo é aquele que progride através de refinamentos sucessivos. A equipe de desenvolvimento apresenta uma parte de um sistema, ciente de que está incompleto ou deficitário em algumas (talvez muitas) partes.
A equipe então refina estas partes até o produto apresentar um nível satisfatório. A cada iteração, o software é melhorado através da adição de um maior nível de detalhe.
Ou seja, um processo iterativo é aquele que faz progresso através de tentativas sucessivas de refinamento. Por exemplo, uma equipe de desenvolvimento faz sua primeira tentativa para construção de um software, porém, existem pontos de informação falhos ou incompletos em algumas partes.
A equipe de forma iterativa refina essas partes até que o produto esteja satisfatório. Com cada iteração, o software é melhorado através da adição de mais e mais detalhes.
O modelo iterativo, muitas vezes, é confundido com o modelo incremental. Um processo de desenvolvimento de software é incremental quando a cada rodada é desenvolvido um pedaço inteiro do software.
Já no iterativo, a cada iteração, se avança no conhecimento do projeto, novos requisitos são elicitados e a arquitetura do software é revisada. No modelo incremental, necessariamente teremos entrega de software ao término de uma iteração, o que não é verdade para o modelo iterativo.
2 UTILIZAÇÃO DE SCRUM PARA O CENÁRIO ESCOLHIDO:
Para o desenvolvimento de um software especifico o método Scrum se encaixaria pois em cada Sprint a equipe chegaria mais próximo do que necessitam e não precisariam se preocupar tanto com mudanças de planos pois saberiam que o produto que estão a desenvolver pertence a uma classe especifica. Assim sendo, um método que tem como base o planejamento iterativo e incremental, seria um método considerado ideal para um cenário de uma fábrica de software que desenvolve um produto específico; e ainda com a utilização de um método como o Scrum em um cenário desse tipo, não seria tão difícil incluir a utilização de algum outro método ágil como o FDD por exemplo, imaginemos uma fabrica de software que desenvolve um produto especifico cujo o foco deve se apresentar no desenvolvimento, o Scrum nesse cenário, seria uma ferramenta que poderia ser utilizada para o gerenciamento mas, poderíamos incluir a utilização do FDD, Por se tratar de uma ferramenta com foco no desenvolvimento — assim como o XP. Métodos são como ferramentas, você deve usar o que melhor se encaixar no contexto da organização.
3 Referência de empresa que utiliza o Scrum :
Atualmente, são muitas as empresas que utilizam o Scrum, entre elas têm-se: Microsoft, Yahoo, Google, Philips, Nokia, Sabre, Siemens, BBC, Oce, Capital One, First American Real Estate, Nielsen Media, Xerox, HP, Borland, Globo, Abril, Uol, Locaweb, Datamace Informática, entre outras. 
Utlizamos como referência a Chemtech ; A Chemtech, empresa brasileira pertencente ao grupo Siemens, oferece soluções e prestação de serviços em digitalização, TI e engenharia – tanto no Brasil quanto no exterior – com foco em Indústrias de Processo.
A Chemtech implantou processos aderentes ao CMMI-DEV [footnoteRef:4] Nível 3 e MPS.BR [footnoteRef:5] Nível C. O objetivo era melhorar a qualidade dos processos e reduzir custos. Para isso, a empresa precisava definir os  processos de acordo com a cultura da organização. Buscavam por inovação e agilidade. Além disso, também precisavam integrá-los aos processos já definidos para a ISO 9001:2008 e queriam muito fazer com que os próprios colaboradores fossem responsáveis pelos processos definidos. [4: O CMMI para Desenvolvimento (CMMI-DEV) é um modelo de maturidade para melhoria de processos, destinado ao desenvolvimento de produtos e serviços, e composto pelas melhores práticas associadas a atividades de desenvolvimento e de manutenção que cobrem o ciclo de vida do produto desde a concepção até a entrega e manutenção.] [5: O MPS.BR, Melhoria do Processo de Software Brasileiro, é um programa da Softex com apoio do Ministério da Ciência, Tecnologia, Inovações e Comunicações (MCTIC). Com inicio em dezembro de 2003, o programa tem como objetivo melhorar a capacidade de desenvolvimento de software, serviços e as práticas de gestão de RH na indústria de TIC.] 
Foi utilizado um processo ágil baseado em práticas definidas no framework do Scrum na área de processo do CMMI-DEV e do MPS.BR, baseado nos objetivos, metas e recursos disponíveis durante o planejamento do projeto; e também nas necessidades e problemas encontrados ao longo da execução dos sprints na Chemtech. Para apoiar esta abordagem, foi definido um processo contendo uma descrição detalhada das atividades e das tarefas propostas. O processo definido, contém tarefas organizacionais e é composto pelos seguintes subprocessos: (i) Planejamento do Projeto; (ii) Planejamento do Sprint #N; (iii) Execução do Sprint #N; (iv) Encerramento do Sprint #N; e (v) Encerramento do Projeto.
Foram definidas 10 mini equipes para compor a equipe do projeto, cada uma com 3 colaboradores da empresa e segundo as seguintes áreas de interesse: Requisitos, Gerência de Projetos, Medição e Análise, Qualidade, Testes, Gerência de Portfólio de Projetos, Recursos Humanos, Compras, Arquitetura e Melhoria de Processos. Cada mini equipe tinha 20 horas dedicadas a cada Sprint de 2 semanas.
A figura do Scrum Master[footnoteRef:6] de cada mini equipe era assumida por um dos membros da Chemtech, enquanto o Product Owner6 era um membro de consultoria da equipe ProMove. [6: O Scrum Master é uma das figuras mais badaladas no mercado de projetos. ... “Enquanto o Product Owner está focado em construir o produto correto e a equipe de desenvolvimento está focada em produzir corretamente o produto, e o Scrum Master é o cara que ajuda todos a compreender os valores, princípios e práticas do Scrum.] 
Um Product Backlog foi definido e priorizado para cada mini-equipe com auxílio dos Products Owners. Além disso, o projeto de melhoria teve seus objetivos e equipe divulgados para todos os membros da organização.
O primeiro Product Backlog baseava-se no estudo e discussões sobre as áreas de processo de cada mini-equipe. Os Products Backlog seguintes tratavam da definição de processos, guias, templates discussões e aprovações para as diversas áreas de processo.
Ao longo dos Sprints que tinham duração de duas semanas, as tarefas eram detalhadas em post-its afixados em um quadro, e dúvidas eram esclarecidas pelos Product Owners.
As tarefas que não eram finalizadas no atual Sprint, retornavam para o Product Backlog e eram planejadas novamente pelo Product Owner e Scrum Master do projeto. Nos cinco primeiros Sprints, reuniões eram realizadas com o Scrum Master do projeto (Scrum de Scrums) e os Scrum Masters das mini-equipes, para o acompanhamento do projeto.
Após o quinto Sprint estas reuniões envolviam todos os membros das mini-equipes disponíveis, principalmente pela necessidade de discussão dos pontos de integração das mini-equipes. Ao final de cada Sprint, um relatório de Status do Projeto era elaborado, com o objetivo de acompanhar o progresso de todas as mini-equipes envolvidas.
A fase de “Implantação da Biblioteca de Ativos” foi encerrada no Sprint #8. Em seguida, foi iniciada a fase de “Acompanhamento dos Processos nos Projetos”.
4 Características do método ágil que justificam a aplicação no cenário escolhido:
Com a possibilidade de se ter reuniões diárias para a discussão do projeto, temos a capacidade de fazer com que todos os membros da equipe de desenvolvimento saibam o que os demais estão fazendo e se auxiliarem a todo momento. Com uma definição clara das prioridades definidas pelo PO descritas no Sprint backlog temos mais confiança na hora de demonstrar o que foi implementado nas reuniões com a diretoria.
5 Detalhamento dos pontos mais relevantes do método ágil escolhido:
A proposta do Scrumde Integração das pessoas respeitando as reuniões de planejamento do projeto. Quando a equipe se reúne e apresenta entre todos como está indo sua produtividade, o senso de responsabilidade e direção sobre a entrega aumenta muito, mesmo que as pessoas não percebam inicialmente. Todas as reuniões são benéficas, e, a proposta garante que os envolvidos no projeto entendam tudo o que deve ser feito e como as atividades serão realizadas. Assim, cada integrante sempre fica sabendo quando o outro está com mais dificuldades e se propõe a ajudar.
Cria uma rotina de trabalho no time, permitindo assim medir e manter o ritmo de cada integrante da equipe de desenvolvimento. Por ser um método ágil, existe a exigência que a equipe aumente suas horas produtivas, o que reduz atrasos e aumenta o desempenho individual. Com isso, as pessoas logo se habitam a ver as atividades existentes com a obrigação de concluí-las, já que o produto de entrega só é válido se as tarefas forem finalizadas por completo. Considerando que as equipes são multidisciplinares e as etapas de documentação, desenvolvimento e testes ocorrem simultaneamente, temos mais dinamismo no processo e deixando o time hábil a seguir esse novo fluxo.
Ampliar a disseminação da informação entre o PO e o time de desenvolvimento. Quando o Scrum é aplicado de maneira correta, a forma como as pessoas se comunicam e se preocupam em saber o que está acontecendo aumenta com uma eficiência surpreendente.
A utilização de instrumentos de apoio como o Sprint backlog, user story e gráfico de burn down permitem acompanhar o que está sendo criado em cada tempo de Sprint. A familiarização desses dados e com as boas práticas ao manipulá-los é uma ótima maneira de mostrar como todos são diretamente responsáveis pelo que está sendo realizado, já que todos os envolvidos podem acompanhar o andamento do Projeto. 
6 Criar possíveis cenários nos quais seriam aplicados mais de um método ágil:
No nosso caso, anteriormente, nosso desenvolvimento de projetos ocorria de modo tipo waterfall, onde o trabalho segue, de certa forma, um cenário em que uma etapa só se inicia quando a outra termina por completo. Devido aos atrasos nas entregas das solicitações, após aprovação da diretoria, implementamos o uso da metodologia Scrum, aliada ao Kanban. Tivemos um grande salto na produtividade e nas entregas das solicitações dos nossos clientes. Mas, dada a evolução do nosso produto, como os testes são muito extensos e críticos, analisamos a possibilidade de utilizar como apoio ao desenvolvimento o FDD, Desenvolvimento Dirigido por Funcionalidades (Feature Driven Developement) que consiste em entregar uma funcionalidade pequena, que possui valor para o cliente no contexto do seu domínio de negócio. Comumente, para a equipe de projeto, uma iteração é ocupada por vez para ser desenvolvida, ou seja, geralmente cada entrega dura em torno de 2 semanas (o mesmo tempo de um Sprint), já que entendendo onde a funcionalidade se encaixa, podemos decompor em macroprocessos ou macro áreas de processos, como Vendas, Marketing, Operações, Compras, entre outras, que são as Áreas de Negócio. Assim, que identificamos as necessidades e os vários processos ou Atividades de Negócio, que são desempenhadas por cada área (total ou parcialmente), cada atividade composta por tarefas ou Passos, manuais ou automatizados por sistemas (software, hardware etc.). Os passos que precisarem de auxílio do sistema tornam-se as funcionalidades para o projeto FDD. Feito isso, cada funcionalidade é entregue à área de testes e posteriormente, remetida aos clientes.
BIBLIOGRAFIA
https://blog.geekhunter.com.br/manifesto-agil/
https://www.culturaagil.com.br/o-que-sao-metodos-ageis/
https://www.projectbuilder.com.br/blog/quais-sao-os-principais-tipos-de-metodos-ageis/
https://robsoncamargo.com.br/blog/Entenda-como-funciona-um-planejamento-iterativo-e-incremental
https://www.scrum.org/resources/what-is-a-product-backlog
https://www.promovesolucoes.com/portfolio/como-a-chemtech-implantou-processos-de-software-com-metodos-ageis-scrum-em-15-meses/
https://mindmaster.com.br/scrum-master/