FACULDADE LOURENÇO FILHO
BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO
BRUNA KELLY GOMES BARBOSA BESSA
PRÁTICAS ÁGEIS APLICADAS À ELABORAÇÃO DE UMA MONOGRAFIA
Fortaleza 2016
SUMÁRIO 1 INTRODUÇÃO... 2 METODOLOGIA ÁGIL... 2.1 História... 2.2 Manifesto Ágil... 2.3 Princípios Ágeis... 3 MÉTODOS ÁGEIS... 3.1 Scrum... 3.1.1 O Framework Scrum... 3.1.2 Papéis e Artefatos do Scrum... 3.1.3 Os Eventos do Scrum... 3.2 Kanban... 3.2.1 O que é o Kanban... 3.2.2 Sinalizador Visual Kanban... 3.3 Lean Software Development (LSD)... 3.3.1 Os Princípios da Metodologia Lean... 4. ESTUDO DE CASO...
4.1 Ferramenta Utilizada... 4.2 Forma de Trabalho... 4.3 Montagem e Evolução do Quadro... 4.4 Análise dos Resultados...
5 CONCLUSÃO... REFERÊNCIAS...
1 INTRODUÇÃO
O surgimento das metodologias ágeis é fruto da crescente demanda por resultados rápidos, mudanças constantes no ambiente de negócio e novas exigências de qualidade no gerenciamento dos projetos.
Segundo Bernardo (2015), método ágil é um conjunto de práticas eficazes que se destinam a permitir a entrega rápida e de alta qualidade do produto. Alinha o desenvolvimento do projeto com as necessidades do cliente e os objetivos da empresa
Ágil é uma nova forma de gestão e desenvolvimento que utiliza uma abordagem de planejamento e execução iterativa e incremental voltado para processos empíricos, dividindo o problema em produtos menores a fim de entregar um produto funcionando regularmente. As metodologias ágeis visam à aproximação e maior colaboração do time de desenvolvimento com os responsáveis pelo negócio, a redução dos riscos associados às incertezas dos projetos, responder as mudanças de forma mais rápida e natural e, por fim, a satisfação dos clientes por meio da adoção de práticas de gestão com foco nos valores e princípios do Lean e do Agile. (STEFFEN, 2012)
Tendo como base estes princípios, é fácil perceber que a metodologia ágil tem muito a contribuir para a realidade dos ambientes das organizações. Assim como nos projetos, um departamento, um processo de negócio ou um serviço também precisam entregar valor para o cliente, reduzir desperdícios dentro de seus processos e ser capaz de aceitar e responder às mudanças. As metodologias ágeis são muito úteis para organização de tarefas, mas não somente no ambiente de trabalho. Uma viagem de férias, o planejamento de um casamento, as prioridades de estudos, a divisão das tarefas domésticas, o planejamento de metas pessoais e profissionais, por exemplo, são atividades que podem ser facilmente organizadas e monitoradas com o uso de práticas ágeis. As práticas ágeis podem ser aplicadas no trabalho ou em casa e possibilitar um maior controle de tempo, despesas e riscos.
Uma maneira de garantir a satisfação tanto do cliente quanto da equipe é a adoção de ferramentas, técnicas e modelos, os quais são utilizados por diversas
empresas com o objetivo de melhorar os processos organizacionais e gerenciais. No entanto, algumas empresas encontram dificuldades na implantação das metodologias, ora por falta de conhecimento, ora por dificuldade na adaptação de tais metodologias ao contexto de seus projetos.
Neste trabalho serão apresentados os principais conceitos envolvendo as metodologias ágeis e será proposta a utilização de um processo adaptado em conjunto com Scrum, Lean Software Development e Kanban, a fim de mostrar como é possível adaptar algumas práticas dos métodos ágeis e utilizá-las, inclusive, em projetos pessoais. O estudo de caso apresentado mostra como as metodologias ágeis podem ser aplicadas na elaboração de um trabalho de conclusão de curso. Inicialmente o tema deste trabalho era outro e a orientação foi baseada no modelo tradicional, mas devido a dificuldade desse modelo o projeto não foi iniciado. A ideia para este trabalho surgiu a partir dessa dificuldade. Com a definição do modelo ágil usando conceitos de pronto, datas de entregas bem definidas e com as tarefas divididas em tarefas com escopos menores facilitou o início da escrita e todo o desenvolvimento do projeto. A proposta deste trabalho foi bem ousada, pois o estudo de caso foi a própria elaboração do trabalho e corria o risco de não ser uma solução eficiente para o problema.
Como justificativas para elaboração deste trabalho podem ser citadas: o estudo e aprendizado de metodologias ágeis, uma vez que práticas ágeis são de grande interesse no mercado e pouco exploradas no meio acadêmico; avaliação da aplicabilidade de metodologias ágeis através da elaboração desse trabalho; e contribuir com um novo processo para a escrita de um trabalho de conclusão de curso, visando melhorar o fluxo de trabalho entre orientandos e orientadores.
Esse trabalho tem como objetivo geral estudar e aplicar as metodologias ágeis na elaboração de um trabalho de conclusão de curso. Como objetivos específicos têm-se: realizar um estudo sobre os conceitos, valores e princípios do manifesto ágil; realizar estudo sobre os métodos ágeis Scrum, Kanban e Lean Software Development; e aplicar os conceitos e boas práticas da metodologia ágil em uma solução para elaboração e acompanhamento de uma monografia.
Ele está dividido em cinco capítulos e está organizado como descrito a seguir. O primeiro é essa introdução, onde foram apresentadas as motivações, justificativas e os objetivos da monografia. O segundo capítulo apresentará a revisão bibliográfica sobre o histórico e os princípios das metodologias ágeis. No capítulo 3, serão descritos os métodos ágeis Scrum, Kanban e Lean Software Development analisando as características e processos de cada um. A ferramenta utilizada durante o desenvolvimento dessa monografia e o estudo de caso serão mostrados no capítulo quatro. E, por fim, as conclusões e trabalhos futuros são apresentados no capítulo seguinte.
2 METODOLOGIA ÁGIL
Este capítulo apresentará a história das metodologias ágeis e o surgimento do Manifesto Ágil no Brasil, assim como seus valores e princípios. A organização deste capítulo seguirá a seguinte estrutura: a seção 2.1 relata a história das metodologias ágeis e o surgimento do Manifesto Ágil no Brasil, a seção 2.2 descreve o Manifesto ágil e define os seus valores e a seção 2.3 relata todos os princípios do Manifesto Ágil, que complementam os valores e juntos, formam os pilares sobre os quais são construídos os Métodos Ágeis.
2.1 História
A Engenharia de Software surgiu na segunda metade do século XX e buscou nos setores da indústria daquela época, grande parte das teorias que serviram de inspiração para a criação e consolidação dos seus próprios métodos de trabalho.
O campo automobilístico estava em grande ascensão industrial e teve um importante papel na indústria da TI. Com o surgimento do modelo de produção em série de Henry Ford, inspirado por Frederick Taylor, o pensamento tradicional do desenvolvimento de software teve seu foco voltado para a padronização dos componentes, processos e na mecanização do movimento (PRIKLADNICKI, WILLI & MILIANI, 2014).
Em meados dos anos 90 começaram a surgir processos alternativos de desenvolvimento de software, conhecidos inicialmente como Métodos Leves (Lightweight Methods) (PRIKLADNICKI, WILLI & MILIANI, 2014). Os métodos leves evoluíram como uma reação contra os métodos pesados (Heavyweight Methods), caracterizados por uma regulamentação rígida utilizada no Modelo em Cascata e às suas contradições na forma em que os engenheiros desenvolviam seus projetos.
Os métodos ágeis inicialmente criados incluíam: Scrum (1986), Crystal Clear (1992), Dynamic Systems Development Method (1995), Extreme Programming
(1996), Adaptive Software Development (1997) e Feature Driven Development (1997).
Em fevereiro de 2001, um grupo composto por 17 especialistas em processos de desenvolvimento de software reuniu-se em Utah nos EUA, a fim de discutir sobre as boas práticas adotadas pelos profissionais de desenvolvimento e nas maneiras de como melhorar o desempenho de seus projetos (HIGHSMITH, 2001).
Os representantes discutiram durante a reunião assuntos como a relação entre o XP e os outros processos semelhantes conhecidos como Métodos Leves, e decidiram então encontrar um novo nome que expressasse bem o significado daquele movimento. O termo Métodos Leves deixaria de ser uma opção válida, já que não expressava o significado desejado. O único inglês presente, Martin Fowler, foi quem sugeriu o termo Ágil para descrever o que estava sendo discutido, mesmo se mostrando preocupado com o fato de que a maioria dos americanos tinha dificuldade em pronunciar o termo (HIGHSMITH, 2001). Após considerar várias opções, decidiram que o termo sugerido por Martin era o que melhor captava a abordagem proposta.
As conclusões levaram à criação de um documento intitulado Manifesto Ágil, documento este que reúne os valores, princípios e as práticas dessa metodologia de desenvolvimento. Mais tarde, em 2014, esse grupo de inovadores intitularam-se como Agile Alliance, uma organização não lucrativa que promove o desenvolvimento ágil (PRIKLADNICKI, WILLI & MILIANI, 2014).
As idéias ágeis vêm sendo adotadas desde os anos 70 em vários países e acredita-se que no Brasil o pensamento ágil já era utilizado na indústria de software antes mesmo do surgimento do Manifesto Ágil em 2001.
No ano de 1999, os pioneiros na agilidade no país, Klaus Wuestefeld e Vinícius Teles começaram a procurar novas abordagens que permitissem aumentar as chances de um projeto de desenvolvimento ser concluído com sucesso. Eles acreditavam que as técnicas voltadas para pessoas teriam um retorno mais positivo, por abordarem práticas que trabalhavam com aspectos humanos, sociais, a criatividade e a comunicação entre os envolvidos (PRIKLADNICKI, WILLI & MILIANI, 2014).
Com o surgimento do Manifesto Ágil em 2001, o movimento no Brasil ganhou força e alguns professores universitários e profissionais da indústria conseguiram contatos com o movimento internacional. Em 2002, aconteceu o primeiro evento ágil no Brasil, o “Programação Extrema 2002” e contou com palestras de convidados internacionais como Scott Ambler, Rob Mee e Kent Beck, um dos membros da aliança ágil. No evento, os profissionais participantes descreveram as suas primeiras experiências com os novos métodos de desenvolvimento. Dois anos depois, a segunda edição do evento teve a participação de Mary e Tom Poppendieck e contou com um público bem maior do que a primeira edição (PRIKLADNICKI, WILLI & MILIANI, 2014).
Em 2010, profissionais da indústria de software em parceria com alunos de pós-graduação organizaram a primeira edição do Agile Brazil. O evento promove palestras, cursos, workshops e maratonas e é considerado hoje a conferência brasileira mais importante sobre o desenvolvimento ágil de software.
2.2 Manifesto Ágil
O Manifesto para Desenvolvimento Ágil de Software, ou como é mais conhecido, o Manifesto Ágil, é um documento no qual serve como base para ser seguido em um processo de desenvolvimento de software. Ser ágil não significa obedecer a todos os protocolos preestabelecidos sem nenhuma modificação, mas sim aderir a novos padrões de comportamento que auxiliam na organização do projeto. Cada Método Ágil define as suas próprias técnicas, mas em algum momento compartilham dos princípios e valores definidos pelo manifesto ágil que diz (MANIFESTO AGIL, 2002):
Estamos descobrindo maneiras melhores de desenvolver software, fazendo-o nós mesmfazendo-os e ajudandfazendo-o fazendo-outrfazendo-os a fazerem fazendo-o mesmfazendo-o. Através deste trabalho passamos a valorizar:
• Indivíduos e interações mais que processos e ferramentas. • Software em funcionamento mais que documentação abrangente • Colaboração com o cliente mais que negociação de contratos • Responder a mudanças mais que seguir um plano.
A declaração dos valores possui um formato: a primeira sentença indica a preferência, o que é mais valorizado, enquanto a segunda diz respeito a um fator, que embora seja importante, tem uma menor prioridade. Durante muito tempo os processos de desenvolvimento focaram mais em documentação, ferramentas, contratos e planos e deixaram de lado os outros pontos, os itens da esquerda, que tinham uma grande importância. O Manifesto tem a finalidade de tentar equilibrar todos esses itens para garantir o sucesso dos projetos.
A seguir, será analisado cada um dos valores do Manifesto (AGILE MANIFESTO, 2001):
a) Indivíduos e interação mais que processos e ferramentas
No ambiente dos projetos, muitas pessoas adotam uma postura defensiva resguardando-se através de processos e ferramentas. A documentação é de fato um item muito importante, mas não comunica tão bem quanto uma boa conversa presencial (PRIKLADNICKI, WILLI & MILIANI, 2014). Da mesma forma que as ferramentas e os processos, afinal é muito mais difícil manter uma organização sem eles, mas ainda assim, valorizar as pessoas e a comunicação entre elas é mais prioritário.
Os processos, a documentação e as ferramentas são importantes para formalizar ou documentar as decisões, mas a primeira forma de comunicação deve ser feita de forma pessoal e interativa. O sucesso de um projeto depende de conseguir captar as necessidades e expectativas do cliente final. As necessidades, por serem algo objetivo, podem ser entendidas através de papéis, documentos e e-mails, mas as expectativas não. Para captar algo subjetivo e pessoal é necessário fazer bom uso da comunicação e da interatividade (MASSARI, 2014).
b) Software em funcionamento mais que documentação abrangente
Muitas empresas exigem que seus processos de desenvolvimento apenas comecem após o time de negócios escrever toda a documentação. O problema
acontece quando estes documentos tornam-se o principal canal de comunicação entre o time de análise e o time de desenvolvimento.
A idéia por trás deste item diz que para o usuário, é mais importante que o software esteja funcionando do que várias páginas demonstrando como o software deveria funcionar. O Manifesto não é contra a importância da documentação e ela não deve ser ignorada, pois ainda representa o melhor guia para o entendimento de como o software deve ser construído e como utilizá-lo. Porém, este é um objetivo secundário no processo de desenvolvimento, sendo o primário, garantir a entrega de um software funcionando.
É necessário refletir mais sobre o que documentar e quando documentar, e sobre o que é realmente útil e o que ficará obsoleto rapidamente (PRIKLADNICKI, WILLI & MILIANI, 2014).
c) Colaboração com o cliente mais que negociação de contratos
É muito comum nos projetos detectar certa preocupação com os contratos assinados, pois existe uma grande chance do cliente mudar de idéia sobre o que foi acordado.
Escopo é uma questão muito complexa e difícil de ser definida com precisão, já que na maioria das vezes o cliente não sabe exatamente o que deseja. Então, ao definir o escopo de um projeto com o cliente são criadas várias cláusulas na tentativa de fechar ao máximo o escopo do projeto e resguardar as partes envolvidas de possíveis mudanças que implicariam em custos adicionais.
Para minimizar os riscos dos contratos que necessitam de alguma modificação, uma alternativa é criar “pontos de controle” que servem para reavaliar o contrato e decidir pela continuidade ou não do compromisso (PRIKLADNICKI, WILLI & MILIANI, 2014).
Existem outras formas contratuais, como por exemplo, contratos por iteração (sprints), onde se determina a quantidade de iterações e o que será entregue em cada uma delas, podendo ou não o contrato ser renovado por mais um ciclo ao final de cada entrega.
O Manifesto diz que é muito difícil definir todas as questões do desenvolvimento previamente em contratos. A negociação contratual, sendo o acordo para um projeto interno ou um contrato legal, não é uma prática ruim, apenas insuficiente (MANIFESTO AGIL, 2002), o que significa que um contrato é importante para formalizar as relações entre contratante e contratado, mas o foco deve ser em entregar valor ao cliente.
d) Responder a mudanças mais que seguir um plano
Mudanças continuam sendo a única certeza existente em um projeto, elas vão aparecer e precisam ser aceitas e levadas em consideração. É mais importante responder rápido e corretamente a uma mudança, do que seguir com um plano que já perdeu o seu sentido e gerar conseqüências e gastos que não foram previstos mais à frente.
As mudanças são necessárias para que o sistema em desenvolvimento seja mais favorável às necessidades dos clientes, pois até mesmo a própria concepção sobre do problema que se deseja resolver, sofre alterações a medida que a solução é construída. É comum ter a idéia de que no início de um novo projeto deve-se traçar um plano e que ele deverá ser seguido a risca até o final, mas é muito difícil tomar decisões e prever o andamento do projeto quando ainda não se conhece a solução que será necessária para a resolução do problema (PRIKLADNICKI, WILLI & MILIANI, 2014).
Não é errado ter um plano de projeto para seguir, contudo para evitar que o resultado final não resolva o problema do cliente, o plano deve ser maleável e suscetível a mudanças e replanejamentos, caso contrário, pode tornar-se rapidamente irrelevante.
2.3 Princípios Ágeis
A fim de ajudar as pessoas a entenderem melhor o desenvolvimento ágil, os membros da Agile Alliance aprimoraram o Manifesto com a criação dos 12 Princípios Ágeis, que fornecem uma idéia melhor do conjunto de técnicas e abordagens propostas que devem ser seguidas no desenvolvimento de software. Os 12 princípios do Manifesto Ágil complementam os valores, formando os pilares sobre os quais são construídos os Métodos Ágeis (PRIKLADNICKI, WILLI & MILIANI, 2014). Os princípios do Manifesto Ágil são os seguintes:
a) Nossa maior prioridade é satisfazer o cliente através da entrega contínua e adiantada de software com valor agregado
A evolução da engenharia de software tem trazido diversos processos, técnicas e ferramentas, que apesar de organizarem e documentarem o ciclo de vida do desenvolvimento, tornaram-se mais importante que o próprio software a ser entregue (PRIKLADNICKI, WILLI & MILIANI, 2014). O foco no desenvolvimento do produto está na satisfação dos clientes.
Desde o começo de um projeto espera-se um retorno ao investimento dos clientes a partir da entrega de partes do produto que atendam às suas necessidades. Esse princípio se opõe à prática de se seguir um plano predefinido, sugerindo que a prioridade está em buscar o que de fato trará valor aos clientes. Contudo, esse princípio não impede a criação da documentação e nem entra em conflito com equipes formadas pelos especialistas de cada área. Apenas diz que a construção das documentações e as fases pré-desenvolvimento não podem ser consideradas como uma parte do produto e ser entregue ao cliente.
O primeiro princípio do Manifesto Ágil afirma que a equipe tem como principal objetivo entregar software funcionando com qualidade, com iterações rápidas e contínuas, sempre agregando valor de negócio ao cliente.
b) Mudanças nos requisitos são bem-vindas, mesmo tardiamente no desenvolvimento. Processos ágeis tiram vantagem das mudanças visando vantagem competitiva para o cliente
Aceitar mudanças deve ser algo natural no processo de desenvolvimento a fim de atender melhor as necessidades dos clientes. Ao se utilizar ciclos menores e feedbacks no desenvolvimento, permite-se evoluir o produto e adaptá-lo às mudanças de acordo com a real necessidade do cliente.
É comum achar que um desenvolvimento vai seguir um plano predefinido e irá tornar-se o software que foi pensado inicialmente, mas a medida em que ele é construído encontram-se formas melhores de se resolver o problema do que as previstas no início do projeto.
A maior dificuldade encontrada no uso desse princípio é de como atrelar o recebimento de novos requisitos à necessidade de aumento de prazo ou de custo do projeto. Os Métodos Ágeis utilizam técnicas e ferramentas para responder o mais rápido possível as mudanças (PRIKLADNICKI, WILLI & MILIANI, 2014), como por exemplo, manter um product backlog corretamente priorizado facilitando alterações nos requisitos e a visibilidade do que será removido do projeto com a entrada de uma nova necessidade.
c) Entregar frequentemente software funcionando, de poucas semanas a poucos meses, com preferência à menor escala de tempo
A prática de entregas freqüentes é útil por uma razão: não é possível ter a certeza de que estamos avançando pelo caminho certo enquanto o software não tiver usuários reais.
Entregar frequentemente partes do produto funcionando ao cliente, agregando valor e sendo capaz de responder rapidamente a mudanças só é possível com ciclos curtos (PRIKLADNICKI, WILLI & MILIANI, 2014). O uso de time-boxes possibilita que a equipe tenha uma boa visão da sua velocidade de trabalho e possa definir com mais precisão, o que será entregue em cada ciclo. Esse tipo de entrega possibilita o
retorno dos investimentos dos clientes e permite que a equipe obtenha feedbacks sobre o que foi entregue.
O feedback constante permite criar uma situação em que os métodos tradicionais tratam como um grande problema: o cliente sempre irá fazer novos pedidos e mudanças no que havia sido acordado. E como o último princípio afirma, os agilistas tratam essas mudanças como acontecimentos naturais e necessários para suprir as exigências dos clientes.
Esse princípio opõe-se a realizar uma entrega de valor único, apenas ao final do projeto. Assim, pode-se adaptar o produto às necessidades dos clientes incrementalmente, reduzindo os riscos do projeto.
d) Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto
Esse princípio opõe-se ao cenário mais comum entre os projetos de desenvolvimento de software, nos quais os clientes preferem definir no início do projeto todos os requisitos e durante a fase de desenvolvimento do produto, clientes e desenvolvedores raramente se comunicam.
Apenas quando o produto é entregue na fase final o cliente se dá conta de que o produto desenvolvido não satisfaz as suas necessidades. Mesmo que os requisitos tenham sido bem definidos e documentados, as necessidades de negócio mudam, porque a realidade do ambiente em que o sistema está inserido também muda.
Uma das formas de evitar problemas como este, é aderir um processo onde seja permitido que os clientes e a equipe de desenvolvimento interajam com freqüência e cooperam uns com os outros a fim de alcançarem um objetivo comum: garantir a geração de valor no produto a ser entregue.
Esse princípio pode ser um pouco difícil de implementar nos processos, pois normalmente a equipe de desenvolvimento não se comunica diretamente com o cliente. “Isso só quem faz é o gerente ou os analistas de requisitos” (PRIKLADNICKI, WILLI & MILIANI, 2014). O trabalho simultâneo das equipes de desenvolvimento
com o cliente permite entregas de produtos com valor e o retorno de feedbacks, elemento necessário para um bom funcionamento do projeto.
e) Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e o suporte necessário e confie neles para fazer o trabalho
O produto é construído por pessoas. O ambiente, o suporte e a confiança necessários para realizar seu trabalho são fatores fundamentais para a motivação dos envolvidos. Equipes ágeis são auto-gerenciáveis e o gerente perde o papel de alguém que cobra resultados e dá ordens e passa a ser um líder facilitador que ajuda e apóia a equipe. Em um time ágil, o ambiente é de comunicação direta e constante com os clientes e o retorno de feedbacks é constante. A prioridade da equipe de desenvolvimento continua sendo a entrega contínua de software funcionando para os clientes (PRIKLADNICKI, WILLI & MILIANI, 2014).
Não há uma fórmula mágica para a motivação das pessoas (NASCIMENTO, 2011), mas algumas práticas podem ajudar a melhorar a satisfação da equipe, como por exemplo:
i) Dar autonomia ao time para decidir como uma determinada tarefa será executada e confiar que essa decisão trará o melhor resultado possível. Essa atitude traz para a equipe auto-confiança, estímulo a buscar as melhores soluções.
ii) O sentimento de colaboração deve ser garantido entre os membros da equipe e entre ela e seus superiores. Promover um senso de igualdade dentro do ambiente de trabalho é importante e apresentar o porquê das decisões e ouvir o que a equipe tem a dizer sobre elas faz com que os envolvidos se comprometam com o projeto.
iii) O ambiente de trabalho e os recursos disponíveis também são fatores de muita influência na motivação da equipe. Os recursos necessários para o desempenho do trabalho devem estar disponíveis e serem de um nível adequado às necessidades da equipe.
iv) Por fim, o aprendizado. As pessoas atualmente estão em busca de trabalhos que possam também lhes trazer retorno intelectual, por isso investir em cursos e treinamentos para a equipe sempre que possível e desafiá-la com novas atividades é fundamental.
f) O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de desenvolvimento é através de conversa face a face
A melhor forma de comunicação entre membros do time que desenvolve o produto e entre eles e o cliente, é a comunicação direta. Quando a comunicação presencial não pode ser feita, é uma boa prática usar a tecnologia disponível para se aproximar da comunicação direta, como ferramentas de videoconferência, por exemplo.
Com o aumento da tecnologia o problema de comunicação também tem aumentado, as conversas face a face estão sendo substituídas por ferramentas que assumem esse papel da comunicação.
Toda essa tecnologia tem sim o seu valor, afinal, uma mensagem que antes levava alguns dias para chegar ao seu destino, hoje é entregue quase instantaneamente, mas essas tecnologias apenas facilitaram as formas de se comunicar e garantem mais rapidez na entrega, mas problemas como falta de clareza e dificuldades no entendimento, por exemplo, ainda acontecem. A compreensão das mensagens trocadas depende da interpretação de quem a recebe, e nem sempre as mensagens são interpretadas de forma correta.
O Manifesto Ágil afirma que, dentre todos os tipos de troca de mensagens entre equipes de desenvolvimento de software e entre a equipe e os clientes, a mais eficaz é a comunicação face a face. Quanto menos comunicação indireta, menores serão os riscos de má interpretação e quanto mais freqüentes acontecerem as conversas presenciais, menos conflitos surgirão (PRIKLADNICKI, WILLI & MILIANI, 2014).
g) Software funcionando é a medida primária de progresso
O progresso do projeto ocorre à medida que partes do produto, contendo algum valor, são entregues aos clientes. Esse princípio esclarece que para um bom andamento de um projeto, as partes de softwares entregues funcionando são mais importantes do que um grande e complexo volume de documentos.
Com o uso de curtas iterações, a metodologia ágil permite ao cliente ter o conhecimento de como o projeto está caminhando. Ao final de cada iteração é esperado um incremento do produto, ou seja, mais uma parte do software funcionando (CAMPOS, 2011).
O trabalho de uma iteração não pode fazer com que o que já está funcionando pare de funcionar e deverá agregar mais valor ao que tinha na iteração anterior. Portanto, o importante é entregar ao final de cada iteração o produto funcionando com o que foi priorizado a ser feito.
A medida que o software é incrementado, o dono do produto consegue avaliar se o que se tem está de acordo com o esperado. Nem sempre a especificação do software consegue expressar de forma exata o que se espera do software. Mas ao vê-lo funcionando, o cliente e a equipe podem discutir o que ficou bom e como melhorar o que não ficou bom. Afinal, o objetivo do desenvolvimento de um projeto, acima de tudo, é ser bem-sucedido.
h) Os processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante indefinidamente
Ter uma velocidade constante no trabalho da equipe de desenvolvimento do produto é possível apenas com a participação de todos os envolvidos que trabalham na criação do produto, inclusive os usuários e os patrocinadores do projeto. Para isso, também é necessário muito esforço e estimativas precisas.
Com iterações menores as atividades precisam ser divididas em tarefas menores para que possam ser implementadas no tempo de uma iteração, assim é possível avaliar ao final de cada entrega se a estimativa para a execução das
atividades foi coerente ou não. Esse conhecimento permite ajustar as estimativas para os próximos trabalhos a serem implementados (CAMPOS, 2011).
Recebendo o software funcionando ao final de cada iteração, o cliente passa a confiar nas estimativas da equipe, que consegue se manter em um ritmo constante com o produto entregando incrementalmente mais valor ao produto.
A equipe também se sente mais motivada quando trabalha dessa forma, pois sabe que o trabalho de uma iteração foi estimado para caber no seu horário de trabalho, não sendo necessárias horas extras, trabalho em fins de semana e a pressa para se cumprir o prazo de entrega. No entanto, ao se exigir do time um compromisso com mais trabalho do que ele é capaz de produzir, essas práticas podem levar à insatisfação dos membros do time, a uma menor produtividade e a uma menor qualidade no produto gerado.
i) Contínua atenção à excelência técnica e bom design aumenta a agilidade O nono princípio do manifesto ágil mostra como o acompanhamento incremental do desenvolvimento do produto aliado a um design intuitivo torna o processo mais ágil.
Um código bem feito aliado a um projeto de qualidade elimina a necessidade de documentação ampla, reduz o retrabalho e facilita a tomada de decisões (PRIKLADNICKI, WILLI & MILIANI, 2014). Muitos desenvolvedores implementam códigos complexos que mostram superioridade técnica, mas que não são considerados como uma boa prática no desenvolvimento do produto. Um produto projetado com qualidade e técnica, pode ser facilmente modificado quando necessário e aceita mudanças naturalmente durante seu desenvolvimento. Assim, a alta qualidade no produto em criação é essencial para se manter a Agilidade.
Um design intuitivo e uma boa técnica são essenciais no desenvolvimento e devem agregar valor ao produto. É necessário certificar-se constantemente se o design está implantado corretamente e se a tecnologia está adequada aos requisitos especificados. Esse princípio opõe-se à crença de que, para se obter velocidade e flexibilidade no desenvolvimento do produto, a qualidade deve ser sacrificada.
j) Simplicidade – a arte de maximizar a quantidade de trabalho não realizado – é essencial
Esse princípio busca desenvolver um produto com o mínimo possível, incluindo “o que todo mundo precisa” e não apenas “o que alguém precisa”, dessa forma a chance do projeto fracassar é menor e o produto criado certamente atenderá aos clientes apenas com o que de fato ele precisa.
Em um projeto ágil é importante usar abordagens simples por serem mais facilmente adequadas as modificações que surgem ao longo do desenvolvimento. É mais fácil incluir algo em um processo que é criado de forma simples do que tirar algo de um processo muito complexo.
A manutenção de um projeto que possui apenas as funcionalidades necessárias é bem mais simples e reduz o risco de insatisfação do cliente e o desperdício no desenvolvimento, assim a equipe de desenvolvimento tem mais tempo para aprimorar o produto e implementar algumas funcionalidades que agregam valor extremo (PRIKLADNICKI, WILLI & MILIANI, 2014).
k) As melhores arquiteturas, requisitos e designs emergem de equipes auto-organizáveis
A auto-organização é uma das principais características de uma equipe ágil. Equipes com maior autonomia costumam ser mais eficientes e geram resultados melhores. As equipes auto-organizáveis trabalham de acordo com os requisitos e as metas acordadas, mas com total liberdade de decidir as melhores formas de realizar o trabalho, como ele será distribuído e quem vai trabalhar em cada componente, ao invés de um gerente fazer isso (PRIKLADNICKI, WILLI & MILIANI, 2014).
Essas equipes gerenciam, estimam atividades, definem padrões, tecnologia, arquitetura e resolvem conflitos entre si. Esse tipo de processo requer um time com mais autonomia e responsabilidade, pessoas com essas características são mais comprometidas e motivadas, o que gera melhores resultados, produtividade no desenvolvimento e a qualidade do produto.
Uma das grandes diferenças entre projetos ágeis e tradicionais, é que a equipe ágil é desafiada a pensar não só em criar o produto, mas nas melhores formas de como criá-lo, em vez de apenas receber instruções prontas e executá-las. O envolvimento de toda a equipe é fundamental para o entendimento do que é necessário na criação do produto (OSIEK, 2011).
l) Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e então refina e ajusta seu comportamento de acordo
É a inspeção e adaptação que o time realiza em seus processos de trabalho. Nos projetos tradicionais são feitas reuniões para analisar as lições aprendidas no final das fases durante o processo ou no final do projeto. O Modelo Ágil faz o mesmo. Para se tornar cada vez mais efetiva, a equipe regularmente inspeciona suas formas de trabalho, identifica pontos de melhoria e se adapta de acordo, promovendo a melhoria incremental e contínua.
Ao final de cada iteração a equipe olha para o trabalho que foi feito e reflete sobre o que deu certo e o que deu errado. O que deu certo é mantido e o que deu errado é corrigido imediatamente já para a próxima iteração (CAMPOS, 2011).
Em projetos tradicionais normalmente, esse processo é feito somente depois que muito trabalho já foi feito ou até mesmo no final de todo o projeto. Deste modo perdem-se oportunidades de fazer as melhorias necessárias ainda no desenvolvimento do projeto, onde elas são mais importantes e mais fáceis de serem adaptadas.
As primeiras iterações do projeto serão de grande aprendizado. Passados os primeiros ajustes, a tendência é de manter o ritmo das atividades do desenvolvimento e as prioridades da equipe (PRIKLADNICKI, WILLI & MILIANI, 2014). Após a finalização de um projeto, contabilizar as lições aprendidas não é mais válido, mas é útil para os projetos futuros.
REFERÊNCIAS
AGILE MANIFESTO. Manifesto para Desenvolvimento Ágil de Software. 2001. Disponível em: <http://agilemanifesto.org/iso/ptbr>. Acesso em: 10 out. 2015. BERNARDO, Kleber dos Santos. O que são métodos ágeis? 2015. Disponível em:
<http://www.culturaagil.com.br/o-que-sao-metodos-ageis/>. Acesso em: 15 fev. 2016.
CAMPOS, E. 12º Princípio do Manifesto Ágil – Retrospectiva, 2011. Disponível em: <http://blog.myscrumhalf.com/2011/09/12%C2%BA-principio-do-manifesto-agil-retrospectiva/>. Acesso em: 24 out. 2015.
HIGHSMITH, J. History: The Agile Manifesto. 2001. Disponível em: < http://agilemanifesto.org/history.html>. Acesso em: 10 out. 2015.
MANIFESTO AGIL. O Manifesto Ágil. 2002. Disponível em:
<http://paginapessoal.utfpr.edu.br/frufrek/pos-web/p/arquivos/O_manifesto_agil.pd f>. Acesso em: 21 set. 2015.
MASSARI, V. Gerenciamento Ágil de Projetos. Rio de Janeiro: Brasport Livros e Multimídia Ltda, 2014. 256p.
OSIEK, B. 11º Princípio do Manifesto Ágil - Equipes Auto-organizáveis. 2011. Disponível em: <http://blog.myscrumhalf.com/2011/09/11%C2%BA-principio-do-manifesto-agil-equipes-auto-organizave/>. Acesso em: 24 out. 2015.
PRIKLADNICKI, R.; WILLI, R.; MILANI, F. (Org.). Métodos ágeis para
desenvolvimento de software. Porto Alegre: Bookman, 2014. 312p.
STEFFEN, Juliana Berossa. O que são essas tais de metodologias ágeis? 2012. Disponível em: <https://www.ibm.com/developerworks/community/blogs/rational brasil/entry/mas_o_que_s_c3_a3o_essas_tais_de_metodologias__c3_a1geis?lan g=en>. Acesso em: 10 fev. 2016.
