[TCC2]Um Metodo Agil Hibrido v11

5/12/2018 [TCC2]Um Metodo Agil Hibrido v11 - slidepdf.com

http://slidepdf.com/reader/full/tcc2um-metodo-agil-hibrido-v11 1/18

Um Método Ágil Híbrido

Marcio PuntelFernando S. Prass – Professor Orientador

Sistemas de Informação - Universidade Luterana do Brasil (ULBRA)Rua Martin Lutero, s/n - CEP 96500-000, Cachoeira do Sul – RS - Brasil

[email protected], [email protected]

Resumo. Com o surgimento dos Métodos Ágeis, o desenvolvimento desoftwares teve um ganho de produtividade significativo. Contudo, váriosmétodos surgiram e com diferentes propostas, deixando empresas edesenvolvedores receosos sobre qual seguir ou usar. Este trabalho apresenta

e traça um comparativo entre as principais características das metodologiaFDD, MSN SCRUM e XP a fim de buscar um conjunto de boas práticas comdiferentes abordagens para, ao final, exibir os resultados e oferecer uma

forma mais simples e mais eficiente de desenvolvimento de sistemas. Alémdisso, mostra os pontos mais críticos, servindo, também, como um checklist básico ao se buscar o desenvolvimento ágil.

Palavras-chave: Métodos Ágeis, Desenvolvimento ágil, ExtremeProgramming, Scrum, Feature Driven Development, Microsoft SolutionsFramework.

1. IntroduçãoO desenvolvimento de software passou por mudanças desde o modo de codificar até ogerenciamento do processo de desenvolvimento como um todo. Vários fatoresestiveram envolvidos para esse quadro, entre eles a Engenharia de Software eProgramação Orientada a Objetos. Contudo, o que ultimamente tem chamado a atençãode programadores, gerentes de projetos e empresas é o desenvolvimento ágil.

O desenvolvimento ágil trouxe um conjunto de abordagens objetivadas aquebrar o paradigma de que o desenvolvimento de software pode ser controlado comouma engenharia tradicional. Ou seja, não se pode planejar o desenvolvimento de umsoftware como se planeja a construção de um prédio. No desenvolvimento de software

as mudanças serão constantes e os stakeholders (todos os envolvidos no projeto) devemestar preparados para isso.

O problema se deu quando várias metodologias começaram a surgir, compeculiaridades diferenciadas que nem sempre são compatíveis com os objetivos eproblemas que micros e pequenas empresas de desenvolvimento enfrentam. Isto épercebido pela baixa efetividade de uso; ainda, pelo uso incorreto das metodologiasquando são usadas.

Uma possível hipótese para esse problema seria agrupar, já que todas as metodologias defendem certa flexibilidade e constante ajuste, alguns dos mais usadosMétodos Ágeis para que fossem analisadas algumas das suas boas práticas para

posteriormente serem usadas num projeto real.



O objetivo de tal “mescla” é verificar se o comportamento será melhor ao usarboas práticas de diferentes Métodos Ágeis (um modelo híbrido), ajustando-se àsituação, ao invés de somente um único Método Ágil, e consequentemente se ter uma

usabilidade eficaz.Uma clara justificativa para procurar realizar esse processo híbrido é fazer com

que a inserção da filosofia ágil possa ser inserida em partes, com processos simples, deforma gradativa e, principalmente, com flexibilidade. Dessa forma, todos poderãoperceber o quão são simples e eficazes as boas práticas ágeis.

Com isso busca-se algumas melhorias significativas para a empresa dedesenvolvimento e verifica-se alguns fatores críticos para o sucesso de uma aplicaçãocorreta e totalmente eficaz de Métodos Ágeis. Para se chegar a esses resultados, são elencadas algumas premissas desde a escolha de práticas condizentes com os problemasde desenvolvimento em cada iteração, até o entendimento e engajamento dos

envolvidos. E também, quanto necessário, ajustar as substituições ou descarte daspráticas que não atendam o propósito.

O artigo apresenta na seção 2 a fundamentação teórica, na qual são vistas asprincipais características do Extreme Programming, Scrum, Feature Driven

Development e Microsoft Solutions Framework . Na seção 3 está descrita a metodologiae como foi aplicada. Na seção 4 estão relatados os resultados do trabalho analisadosdurante, e posterior, a implementação. Na seção 5 são colocadas algumas consideraçõesfinais e na seção 6, as referências.

2. Fundamentação Teórica

Mesmo que as idéias do desenvolvimento ágil venham sendo seguidas há vários anos,foi no ano de 2001 que Kent Beck e outros 16 desenvolvedores, produtores econsultores de software assinaram o Manifesto Ágil no qual declaravam que estavamdescobrindo melhores modos de desenvolver softwares, passando a valorizar [Pressman2006]:

• Indivíduos e Interações em vez de Processos e Ferramentas;

• Software funcionando em vez de Documentação abrangente;

• Colaboração do cliente em vez de negociação de contratos;

• Resposta a modificações em vez de Seguir um plano.

Os pilares do Manifesto Ágil foram criados pensando em valores e princípiosbaseados no bom senso de todos os envolvidos, fazendo um convite a pensar diferente,aceitar mudanças, melhorar continuamente, adaptar-se e ter comprometimento [Fonsecae Campos 2008].

A metodologia ágil também pode ser vista como uma forma de se buscar fazerdiferente, com mesmos recursos, quando se precisa que resultados sejam diferentes dosque habitualmente são alcançados, já que os requisitos nunca serão os mesmos [Camarae Martins 2008].

A filosofia ágil deu origem a várias metodologias, como: Scrum, Extreme

Programming, Feature Driven Development, Microsoft Solution Framework, Crystal, Adaptative Software Development, Dynamic Systems Development Method , entre



outros. Contudo foram usadas como referência, neste presente trabalho, asmetodologias: Scrum, por ser bem completa e com forte gerenciamento; ExtremeProgramming, por priorizar as pessoas e ser bastante flexível; Feature Driven

Development , pelas funcionalidades bem definidas; e Microsoft Solutions Framework ,por sua experiência constante [Camara e Martins 2008].

2.1. Extreme Programming ( XP)

O XP é um Método Ágil de desenvolvimento de software, criado nos Estados Unidos aofinal da década de 90, por Kent Beck. Vem fazendo sucesso, por ajudar a criar sistemasde melhor qualidade, que são produzidos com mais simplicidade e de forma maiseconômica que o habitual [Pressman 2006].

O ciclo do XP é diferente do desenvolvimento convencional porque sua iteração(ciclos em períodos curtos) é incremental, fazendo com que o projeto tenha as suas

funcionalidades acrescidas em cada iteração. Isto faz com que as estórias (descrições defuncionalidades feitas a partir da visão do cliente) possam ser ajustadas conforme amudança dos requisitos. Este ciclo é realizado nas três fases do XP: exploração,compromisso e direcionamento [Prass e Puntel 2009].

As variáveis de controle em projetos realizados com XP são quatro: custo,tempo, qualidade e escopo (requisitos e funcionalidades do sistema). O XP buscasempre trabalhar a simplicidade para implementar apenas os requisitos necessários,evitanto funcionalidades complexas que possam ser desnecessárias ou ser criadas nofuturo. O feedback constante com o cliente (interações semanais) faz com que osoftware desenvolvido seja inspecionado a todo momento podendo ser mudado

rapidamente, sem grandes perdas [Soares 2009].Na Figura 1 pode ser visto esse processo nas três fases do XP: exploração,

compromisso e direcionamento, respectivamente.



Figura 1. Ciclo do XP . [Prass e Puntel 2009]

2.2. Scrum

Criado no início da década de 90, por Jeff Sutherland e sua equipe, o Scrum é umMétodo Ágil que tem o nome derivado do jogo de Rugby, onde os jogadores reúnem-separa criar novas estratégias e realizar adaptações. Os princípios do Scrum são bempróximos do Manifeto Ágil. Ele foca em pequenas equipes, processos adaptáveis,frequentes incrementos, divisão do desenvolvimento, testes, documentação e entregasconstantes. “O Scrum incorpora um conjunto de padrões de processo que enfatizaprioridades do projeto, unidades de trabalho compartimentalizadas, comunicação e

feedback constante com o cliente.” [Pressman 2006].

Devido ao Scrum ter um foco mais gerencial do que técnico, ele pode ser usadoem conjunto com outras metodologias como MSF e XP, que são mais focadas na

engenharia do que na gerência de software. Ele, o Scrum, tem por base a teoria docontrole empírico (controle frequente e adaptação) de processos [Camara e Martins2008].

O Scrum inicia com uma visão que é a base para o planejamento. Nesseplanejamento é definido o Backlog do Produto (requisitos e funcionalidades). Sãorealizadas Reuniões de Planejamento do Sprint para a definição do Backlog do Sprint (seleção dos itens que podem ser construídos até o final da iteração). Na iteração sãorealizadas reuniões diárias até o final do Sprint . Após o término da iteração deve serfinalizado o produto para entregar ao cliente com o incremento no mesmo.Posteriormente devem ser realizadas as reuniões de revisão (rever novos requisitos) e deretrospectiva (rever pontos positivos e negativos). Veja na Figura 2.

Figura 2. Ciclo do Scrum . [Prass e Puntel 2009]

2.3. Feature Driven Development ( FDD)

O FDD foi criado, em 1997, a partir de uma compilação de práticas e da experiência demodelagem orientada por objetos de Peter Coad e de gerenciamento de projetos de Jeff

de Luca. Usa como modelo prático a engenharia de software com ênfase na definição de



funcionalidades (características), sob o contexto de orientação por objetos e defendeprocessos ágeis e adaptáveis para projetos de médio e grande porte [Pressman 2006].

Na primeira etapa é desenvolvido um modelo de classes e objetos do negócio(por especialistas no problema). Em seguida, é criada a lista de funcionalidades que osistema deverá possuir, com base na modelagem dos requisitos. Na sequencia, sãoplanejadas as funcionalidades para cada membro da equipe. Na iteração, cada membrodeverá trabalhar especificamente para sua funcionalidade, que deverá ser construída emno máximo duas semanas [Camara e Martins 2008].

O destaque com o desenvolvimento por funcionalidade se deve porque “é umafunção valorizada pelo cliente que pode ser implementada em duas semanas ou menos”[Pressman 2006]. Com essa abordagem são fornecidos os seguintes benefícios: (1)facilidade na descrição, já que as mesmas serão pequenas; (2) mais fácil de visualizarperante o contexto de todo o sistema; (3) toda funcionalidade será uma entrega que o

cliente terá algo funcional em mãos; (4) como são pequenas, as funcionalidades tornan-se fáceis de inspecionar; (5) planejamento é guiado pela hierarquia das funcionalidadese não como um todo [Pressman 2006].

O FDD parte desde o início com o foco na orientação por objetos. A partir doconhecimento das pessoas especializadas no domínio, é construído o modelo de classesdo negócio. Essas classes de negócios são divididas e distribuídas entre osprogramadores (cada um pode ter uma ou várias classes) que implementarão, quando oProgramador Chefe definir, sua codificação; e caso uma funcionalidade exija umaiteração maior que de duas semanas, ela deve ser desmembrada. Veja na Figura 3.

Figura 3. Estrutura do FDD . [Prass e Puntel 2009]

2.4. Microsoft Solutions Framework (MSF)



Criado pela Microsoft em 1993, o MSF teve um foco, na época, um pouco diferente doconvencional, causando certas opiniões adversas sobre a sua eficácia. Houve diferentesnomes como Microsoft Development Framework e Product Cycle Model que por fim

tornou-se, no atualmente conhecido, Microsoft Solutions Framework [Camara 2007].O MSF partiu da ideologia de fazer produtos de forma diferenciada dando mais

importância para o tempo, a fim de entregar nas datas determinadas, ao escopo. Parafazer um comparativo, seria como se o PMI definisse que o escopo é fixo, os recursosrazoavelmente variáveis e tempo variável e no MSF que o tempo é fixo, os recursosrazoavelmente variáveis e o escopo variável [Prass e Puntel 2009].

Além disso, o MSF é dividido em duas personalizações: Essential e Agile. OEssential é o convencional para projetos que requerem um grau maior de detalhes econtrole. Já o Agile deu-se após o Manifesto Ágil [Manifesto 2009] e é destinado aprojetos com equipes e tempos mais reduzidos. Apenas o que difere os dois é que o

Agile é iterativo e incremental, o que o faz ser mais econômico e com ajustes constantesa cada iteração [Camara 2009].

Na Figura 4 é possível ver as fases do MSF a serem executas em, no máximo,quatro semanas, para atingir as suas funcionalidades – Release.

Figura 4. Ciclo MSF . [Prass e Puntel 2009]

3. Metodologia

Nesta seção serão vistos os métodos utilizados para por em prática os fundamentoságeis no desenvolvimento de software na empresa Alfa1. Para isso, a mesma serádividida em subseções objetivando dar uma sequência à leitura e descrever como foiexecutado o trabalho.

3.1. Exposição do paradigma ágil

Conforme previsto, foi realizada uma reunião com a diretoria da empresa Alfa, na qualfoi implementado o projeto com uso de boas práticas de diferentes metodologias ágeis.

1 Será usado um nome fictício para a empresa conforme solicitado pelos proprietários.



A reunião mostrou para os diretores as características do desenvolvimento ágil, seuspontos positivos (simplicidade nos processos, melhoria contínua, adaptaçãopredisposição a mudanças e satisfação do cliente) e pontos negativos (entendimento,

conscientização, efetividade no uso, aceitação e correta análise das boas práticas maisadequadas a serem usadas). Com isso, a empresa ficou ciente de que a participação detodos é importante para uma boa comunicação.

Com essa participação dos diretores os resultados – custo e tempo – poderiamser melhorados, já que os mesmos faziam um primeiro contato com o cliente e quemuitas vezes estimavam mal o prazo e/ou subjugavam a complexidade dos sistemas.Logo, com a integração de todos os envolvidos no processo de elencar funcionalidadeso custo de desenvolvimento estaria mais preciso.

3.2. Recursos disponíveis

No próximo passo foram definidos os recursos disponíveis (colaboradores que iriamparticipar). Inicialmente, mesmo que em projetos diferentes, todos os colaboradores sededicaram em aplicar boas práticas no seu dia-a-dia, para que todos aprendessem etrabalhassem as idéias. Todas as metodologias, em que se basearam o presente trabalho,relatam que os softwares para o desenvolvimento ágil são indiferentes. Logo, foramusados os mesmos já habituados, porém de maneira que buscasse atender ao planejado(documentos, por exemplo).

Os recursos humanos iniciais disponíveis foram: dois sócios-diretores, trêsanalistas desenvolvedores, um gerente de projeto, um analista de redes e um estagiário.

Outro ponto analisado foi a experiência dos profissionais e da empresa em

desenvolver um projeto de software – desde o levantamento de requisitos até a implantação. Em relação à empresa, era nova e não possuía tempo nem cases (projetosanteriores de sucesso/insucesso) para se guiar. Quanto aos profissionais, já possuiamboa experiência em projetos de diferentes portes. Contudo, nenhum havia secomprometido em aplicar rigorosamente a Engenharia de Software, quiçá MétodosÁgeis.

3.3. Definir boas práticas

Apesar dessa etapa ser muito importante para que o projeto obtivesse os resultadosesperados, ela foi simples de ser realizada já que todos os envolvidos estavam cientes de

que as boas práticas poderiam ser ajustadas numa próxima iteração.Inicialmente foram vistos quais os problemas que a equipe de desenvolvimento

possuía. Em seguida, foram buscadas as boas práticas que pudessem melhorar osprocessos. Verificou-se que alguns processos eram executados de forma bem tradicional(Engenharia de Software) e outros sem um padrão, sendo guiados por experiênciasprofissionais. Além dos problemas, buscou-se definir novas maneiras de melhorar osprocessos que eram considerados problemáticos.

Após as considerações terem sido colocadas e discutidas, chegaram-se àsseguintes boas práticas que estão demonstradas na Tabela 1, onde se procurou mostrar oproblema no momento inicial do projeto, a boa prática analisada para ele e qual (ou

quais) metodologia ágil derivou-se.Tabela 1. Boas práticas iniciais.



Problema Boa prática Metodologia derivada

Levantamento de

requisitos/Escopo

Visão (Definição das

funcionalidades daiteração)

XP (Estoria), Scrum

(Visão), FDD (Modelo) eMSF (Release)

Estimativa de prazo Planing Poker XP e Scrum

Sistema disponível para uso Iteração de 2 semanas FDD

Reuniões deacompanhamento

Reuniões diárias de 15minutos

Scrum

Feedback do cliente Cliente participa em:Visão, definição deprioridades, testes e

aprovação dafuncionalidade

XP, Scrum, FDD e MSF

Documento para cliente Relatórios de progresso FDD

Responsabilidades Papeis: Product Owner,Scrum Master e ScrumTeam

Scrum

Avaliação de status deprojetos

Scrum Master Scrum

Complexidade subjugada Product Owner Scrum

Comunicação Reuniões diárias XP e Scrum

Mudança de requisitos Propriedade coletiva eVisão compartilhada

XP e MSF

3.4. Implementar as boas práticas selecionadas

Com as boas práticas definidas, foi o momento de iniciar o seu uso. O processo foigradual e demorado (mais de um mês) para que os envolvidos se acostumassem àsmudanças e, principalmente, pelo correto uso das boas práticas. Devido a isso, buscou-se discutir com consenso todas as formas de uso para evitar “choque” de idéias.

Nesse momento, os papéis foram distribuídos para que todos se localizassem noprojeto e fizessem sua parte. Para os papéis foram estipulados que um dos sócios-diretores seria o Product Owner (responsável pelas tratativas com o cliente e visãoampla do sistema), o gerente de projetos seria o Scrum Master (nortear osdesenvolvedores) e Scrum Team (demais colaboradores). Os papéis do Scrum forammais bem vistos pela equipe, já que a distribuição atual dos membros não mudou muitoe por possuir uma estrutura mais gerenciável.

Ainda, foi modificada a forma de planejar o tempo de desenvolvimento de cadafuncionalidade. A partir de então, o planejamento deveria ser de duas formas: (1)funcionalidades que deveriam ser desenvolvidas em um tempo já esperado pelo cliente

(nesse caso era planejado o que era possível fazer naquele tempo) e (2) os analistasdeterminam o tempo necessário para realizar determinadas funcionalidades.



Sempre ao final de cada iteração deveria ter uma funcionalidade pronta para queo cliente possa testar e, em caso de aceite, implantar. Para isso, a comunicação deveriaser constante com cliente e membros da equipe para aquisição dos requisitos e

enriquecimento do software através do feedback do cliente.

3.5. Interação com o cliente (a cada iteração)

Como toda metodologia ágil prega, foi realizado contato com o cliente para explicar asvantagens que ambos (empresa e cliente) teriam ao usar um processo iterativo curto,com entregas freqüentes e possibilidade de mudança de requisitos facilitada.

Além disso, planejou-se como seria a entrega dos relatórios de acompanhamentoonde o cliente teria um status do andamento do projeto perante o tempo destinado àsdeterminadas funcionalidades.

Ao trabalhar com iterações pequenas, a comunicação com o cliente acabariasendo constante, já que para ter um sistema de acordo com as suas necessidades, deforma simples e objetiva, o cliente deveria dispor um determinado tempo para o projetoe sempre dar um retorno da sua aceitação do mesmo; e caso necessário, a equipe atenderàs mudanças requisitadas.

3.6. Desenvolvimento (modelagem/codificação)

Buscou-se focar na simplicidade da modelagem das iterações para se ter uma visão bemobjetiva na funcionalidade priorizada praquela iteração. Sempre foram elaboradosmodelos simples e evitou-se fazer o que não poderia ser usado futuramente, para que emcaso de mudança de requisitos fosse ágil tanto a mudança da modelagem, como o

consequente desenvolvimento. Isso para que houvesse a facilidade no ponto crucial, quesem demora chegou: mudança de requisitos.

Para que a empresa dispusesse de uma padronização de codificação e derecursos necessários a determinadas tarefas, a propriedade coletiva dos códigos fontesfoi escolhida como caminho. Assim, a integração de diferentes partes - módulos dosistema – fosse realizada com mais agilidade e com menor tempo de depuração.

Além disso, sempre houve a responsabilidade de se documentar tudo que fossecriado através de comentários padronizados no código fonte, já que Kent Beck diz queinclusive comentários podem ser considerados documentos, para gerar documentaçãoquando necessário.

3.7. Avaliar e reagir (adaptações)

Essa etapa foi proposta justamente pensando nas mudanças que poderiam surgir nodecorrer do desenvolvimento do projeto, devido ao mau uso da boa prática, e até mesmoela não ser relevante para solução do problema naquele momento.

Para realizar as mudanças da próxima iteração, perante os problemasencontrados no decorrer da iteração atual, a reunião de acompanhamento foi estipuladapara ser realizada diariamente. Ao final da iteração, haveria a reunião de retrospectivaonde os pontos positivos e negativos da iteração passada (ou atual) pudessem serdiscutidos e analisados da sua relevância ou não para uma próxima iteração.

Outra flexibilidade adotada foi que durante a iteração, mesmo sem esperar areunião de retrospectiva, poderia ser concordado entre os membros da equipe para que



determinada prática pudesse ser substituída, ou mesmo retornada à anterior, a fim deevitando prejudicar o andamento da iteração ou mesmo uso o indevido pelo membro daequipe.

4. Resultados

Nesta seção são apresentados os resultados obtidos ao por em prática os fundamentoságeis no desenvolvimento de software na empresa Alfa. Esses resultados foram obtidosna aplicação de boas práticas, dos Métodos Ágeis abordados, em um projeto real noperíodo de junho a novembro de 2009.

Junto aos resultados serão vistos os motivos relacionados aos fatores positivosou negativos encontrados na aplicação do mesmo. Para uma melhor visão da análiserealizada, a seção foi dividida em duas subseções, pontuando as observações queocorreram durante o processo de aplicação da “filosofia ágil”.

4.1 Pontos negativos

Em “pontos negativos” estão englobados todos os aspectos que foram contrários ao bomandamento da aplicação ou mesmo a forma correta de serem usados os princípios ágeis.

4.1.1 Direção

Ao procurar a empresa para expor o objetivo que o trabalho buscava alcançar agregandofacilidades no dia-a-dia da mesma, quando da exposição do paradigma ágil, já houve oprimeiro problema. Isso porque, quando se fala em desenvolvimento ágil, conformeAmbler (2004), as pessoas – leigas – automaticamente assimilam erroneamente que setrata de desenvolvimento rápido: somente que vai fazer em menos tempo.

Mesmo após uma explicação bem cautelosa do que seria implementado com odesenvolvimento ágil e os possíveis resultados que poderiam ser alcançados, aoverificar que não se tratava da visão a qual eles, os diretores, vislumbravaminicialmente, os primeiros empecilhos foram expostos através de perguntas ecomentários:

• “Perderemos Documentação?”

• “Vamos ter que gastar quanto?”,

• “Se é simplificar, por que processos?”

•

“Vamos ter que pagar um consultor especialista?”

• “Não temos tempo para envolvimento!”

• “Se o cliente não quiser participar?”

• “Não interferiremos na resistência do cliente!”

• “Tem certeza que é assim?”.

Com as devidas correções e com as respostas adequadas, foi possível darcontinuidade ao trabalho. Um dos diretores (com mais experiência na área de TI)aceitou participar sendo o então analista de negócio (que nos papéis seria o Scrum

Owner ).



Ao se tratar com a diretoria, que no caso são pessoas de outras áreas e algumasvezes sem conhecimento mais técnico, foi percebido que quando o assunto era fazermais rápido, mesmo que simplificando documentos, tudo era válido. Porém, se exposto

que o ganho seria em outros aspectos, a mesma motivação deixou de existir.Para esse problema se buscou argumentar com a diretoria os “pensamentos

ágeis”. Posicioná-los no papel de cliente – que iria ter um produto mais próximo a suanecessidade - e no papel de desenvolvedores – quando ganhariam tempo e rendimentosimplificando processos e evitando desperdício.

4.1.2 Aceitação/entendimento da equipe

Inicialmente houve o problema de falta de entendimento por parte dos membros daequipe diretamente ligados ao desenvolvimento. Existiram três momentos com a equipe:(1) o inicial, que conforme Teles (2009) diz que no início os colegas são extremamente

contrários, (2) a aceitação, que é o momento que a equipe percebeu que mesmo comsimplicidade existiu mudança (que pode gerar desconforto) e (3) a adaptação, que équando os processos começaram a andar no caminho certo.

Infelizmente nem todos entenderam e alguns interpretaram erroneamente.Quando pareceu que havia sido entendido, começaram os problemas de contradiçõesque geraram alguns desconfortos. Neste momento alguns iniciaram gradativamente oabando da proposta e deixaram de fazer o esperado para fazer de forma incorreta oumesmo não executar suas atividades conforme o programado. Percebe-se que nestemomento a direção poderia ter estado mais presente.

Para esses problemas foi buscada a comunicação com os integrantes da equipe.

A instigação de participar e usar comparativos entre os ganhos foram alguns dosprocedimentos adotados para tentar motivar a colaboração do trabalho em equipe.Processo que foi repetidamente realizado.

4.1.3 Escolha das boas práticas

Essa é uma etapa que não deveria ser considerada como ponto negativo porque eraesperado que as boas práticas iniciais adotadas pudessem sofrer alteração no futuro, oque realmente aconteceu. Contudo, o que está sendo exposto como negativo é que nãose pode acertar de início e sempre deverá haver ajustes, o que pode ser frustrante parauma equipe desmotivada.

Isto pode ser visto na Tabela 3 – na qual se encontram as principaiscaracterísticas das metodologias ágeis abordadas – nas três versões de conjuntos de boaspráticas. Nela ainda é possível verificar que houve quatro formas de avaliar o uso dasboas práticas: (I) Implantado – quando a mesma foi usada naquela versão; (N) Nãoimplantada – quando não houve o uso ou que não foi necessário; (T) Tentativa deimplantação – quando houve a tentativa para verificar se na próxima versão poderia serefetivamente implantada; (D) Desistência de implantação – quando se percebeu queaquela boa prática não seria útil para as necessidades.

Tabela 3 – Características das metodologias versus usadas.

Versões

Metodologia Boa prática V1 V2 V3XP Programação em par N N N



Estórias T T DPlano geral I I IDesenvolvimento iterativo T I I

Iteração de uma semana N N NTeste antecipado N N NEnvolvimento do cliente I T TPropriedade coletiva T I ICódigo padrão T I IProjeto simples I I IPlanning poker T T N

Scrum Visão geral I I ISprint de duas semanas T N NPlanejamento do Sprint I I I

Equipes auto-organizadas N T IReunião diária I T DEquipes pequenas I I IReunião de revisão T D DReunião de retrospectiva T D DPost-it T D N

FDD Iterativo I I IEnfatizar na qualidade N N TEntregar de resultados tangíveis N I IRelatório de progresso I T DDivisão/propriedade de classes T I I

MSF Comunicação aberta I I TVisão compartilhada N I IAlternar líderes N N NResponsabilidades compartilhadas I I IEntrega com valor para o negócio (tangível) N I IEsperar mudanças N T IQualidade contínua I I IAprender com experiências anteriores N I I

Legenda:I - ImplantadoT - Tentativa de implantação

D - Desistência de implantaçãoN - Não implantado

V1 – 06/2009 – 07/2009V2 – 08/2009 – 09/2009V3 – 09/2009 – 11/2009

Com essas mudanças houve, algumas vezes, a perda de características das boaspráticas. Isto ocorreu porque quando foi necessário adaptar e trabalhar com diferentesmetodologias ágeis, o risco de se perder o foco de como realmente deveria ser aplicado,aumentou.

Para contornar esse problema, a partir da segunda versão de boas práticas foiredefinida a forma de planejar e escolher as mesmas. Ou seja, não foram apenas



levantadas as hipóteses para teste e sim, devido a experiência anterior (versão 1),analisadas apenas as características que realmente pudessem resolver os problemas.

4.1.4 Participação do clienteA participação do cliente, ou melhor, a falta dela, sem dúvida foi o ponto mais frustrantee marcante para que muitas boas práticas fossem preteridas. Apesar de o cliente ter secolocado disposto a participar no primeiro contato, mesmo que contrariado,posteriormente não aconteceu a interação (comunicação com o cliente ou, ainda, trocade experiências) prometida e necessária para que qualquer Método Ágil consiga ter ummínimo de fundamento.

Nos demais ciclos (além do primeiro), foram apenas levantados novos requisitospara a consequente iteração via e-mail e algumas raras vezes pessoalmente. A definiçãode prioridades acabou ficando por conta da equipe bem como a análise da importância

para o sistema do que iria ser entregue. Também não houve avaliação da versãoentregue em nenhum momento, sendo que mudanças necessárias ou funcionalidadesfora do escopo foram constatadas em uso.

O principal problema acabou sendo falta de tempo para participar do projeto.Pelo fato de o mesmo estar pagando ele se viu no direito de cobrar e de não querer se“incomodar”. Para isso, os mais indicados para doutrinar e insistir com o cliente eramos diretores da empresa (que não o fizeram) enfatizando a importância para um software bem sucedido. Porém, como a direção também não estava participando, não tevemotivação para tal.

4.1.5 GerênciaMesmo que em alguns momentos a empresa tenha optado por equipes auto-organizadas,como defendido pelo Scrum, sempre é importante que se tenha um responsável peloprojeto – mais conhecido tradicionalmente como gerente de projetos. A falta do mesmofez com que alguns membros da equipe acabassem perdendo tempo em atividades quepoderiam estar sendo centralizadas e realizadas de melhor forma.

Sobre este aspecto em muitos momentos houve a carência de tal função, sendoque os desenvolvedores acabaram tendo responsabilidades compartilhadas em várioscasos, o que trouxe alguns desconfortos e informações distorcidas em alguns momentos.

Esse problema não pôde ser contornado, já que era uma decisão que envolvia a

direção da empresa. O máximo que se conseguiu foi fazer com que a auto-organizaçãofosse realizada em um centralizador – membro da equipe – no qual algumas atividadesdeixaram de ser realizadas por todos, mas por apenas um. Para exemplificar, tarefascomo primeiro caso de uso da iteração, publicação das atualizações para o cliente,contato técnico dos desenvolvedores com a direção.

4.2 Pontos positivos

Em “pontos positivos” estão englobados todos os aspectos que foram favoráveis ao bomandamento da aplicação ou mesmo que agregaram valores para a empresa no seu âmbitode desenvolvimento.

4.2.1 Padronização



A padronização foi um ganho bem significativo para os fatores de manutenção ecompartilhamento de códigos. Antes à realização de tal boa prática, desenvolvedorestrabalhavam de forma “parecida”. Isto tornava a forma de análise de tempo de

desenvolvimento sempre diferenciada.Além disso, com o decorrer do tempo, o ganho com reaproveitamento e

aprendizagem através de experiências anteriores, fez com que o tempo para novosmódulos fosse gradativamente reduzido. Com isso, a performance paradesenvolvimento e modificações de funcionalidades tiveram uma redução de custo.

4.2.3 Documentação

A documentação não chegou ao objetivo de um modelo totalmente atualizado e queatendesse todos os interessados, mas houve uma melhora significativa com as boaspráticas de simplificar, atualizar e disponibilizar. Depois de várias tentativas frustradas

de diferentes documentos (casos de uso, diagramas, templates), chegou-se ao sistema deWiki (proposta de XP e Scrum). Com isso se conseguiu um local onde todos podemdisponibilizar as principais funções do sistema e ter subsídios atualizados das demaisfuncionalidades realizadas pelos demais membros.

Além disso, a equipe obteve ganhos de produtividade com esse canal porquepuderam ser gerenciados outros pontos que em alguns momentos atrasavam algumastarefas. Foram criadas seções onde puderam ser armazenados erros em geral(aprendizagem com experiências anteriores), particularidades de funções(compartilhamento de conhecimento), workflows de implantação (comunicação), entreoutros.

4.2.4 Definição de requisitos

Onde, antes da implementação das boas práticas, havia um levantamento de requisitosmuito superficial e que muitas vezes era realizado sem a participação dos analistasprogramadores. Agora existe uma colaboração e comunicação a fim de ter elementosdefinidos com maior precisão.

Infelizmente, esse ganho foi conseguido somente após um erro que custou caropara a empresa. Embora deva ser um fator básico para desenvolvedores e que deve sersimples para o cliente, não existe uma receita de sucesso para que tal processo sejarealizado corretamente. Contudo, uma boa prática ágil é bem-vinda: fazer pouco aos

poucos e continuamente.4.2.5 Cliente

Num primeiro momento a participação do cliente, mesmo não sendo com totalsatisfação (por falta de compreensão ou vontade de comprometimento), foi aceita.Nesse momento foram buscadas as prioridades do sistema perante o mesmo. Apósdefinir o que queria, ele estipulou o que era mais importante ter disponível primeiro.

Com isso, foi constatado como a interação com o cliente é eficiente para oandamento, redução de riscos e maior objetividade do projeto. Mesmo que rapidamente– já que o cliente não participou somente no primeiro ciclo – a troca de experiências foi

impactante e agregou uma boa experiência.4.2.6 Aceitação de mudanças



Outro objetivo marcante dos Métodos Ágeis é a capacidade das equipes aceitarem econseguirem atender às mudanças de requisitos – que cedo ou tarde acontecerão. Estacaracterística se deu pela documentação ser suficientemente eficaz, pela padronização

adquirida e, um pouco, pela maturidade atingida pela equipe.Mesmo com a carência da participação do cliente e de uma gerência de projeto,

sempre que necessário, as mudanças solicitadas foram atendidas sem grandes perdas –mesmo que inicialmente tenham sido contrárias e aos poucos foram sendo bem-vindas.Para se conseguir isso, bastou apenas sempre “pensar simples” e focar em objetivosespecíficos das novas demandas. Isso fez com que, automaticamente, todos na equiperecebam bem as mudanças. Ainda, nos casos de exceções em receber de bom agrado,foi buscado o foco de ver como melhorias/aprendizado.

4.3 Versão final

Até a finalização do presente trabalho foram usadas as boas práticas demonstradas naTabela 4. Essas boas práticas são resultantes das três versões expostas na Tabela 3 e queforam analisadas durante a seleção das mesmas para aplicação no projeto.

Tabela 4 – Versão final das boas práticas sendo usadas.

Metodologia Boa práticaXP Plano geral

Desenvolvimento iterativoPropriedade coletivaCódigo padrãoProjeto simples

Scrum Visão geralPlanejamento do Sprint Equipes auto-organizadasEquipes pequenas

FDD IterativoEntregar de resultados tangíveisDivisão/propriedade de classes

MSF Visão compartilhadaResponsabilidades compartilhadasEntrega com valor para o negócio (tangível)Esperar mudançasQualidade contínuaAprender com experiências anteriores

Apesar de muitas das boas práticas vistas acima serem muito semelhantes –mesmas características –, foram expostas divididas em suas devidas metodologias paraser claro de onde foram buscadas. Além disso, como foi focado em flexibilidade emdeterminados momentos optou-se por uma ou outra.

5. Considerações finais

Ficou claro que para uma aplicação eficaz e com resultados mais significativos, algunsfatores são fundamentais. Eles são: participação do cliente no projeto, engajamento da



diretoria da empresa e comprometimento da equipe. Foi percebido que ao mesmo tempoem que os processos são simples de realizar, na prática isso não é real por vários fatores,como, por exemplo, a falta de tempo sendo o fator de maior relevância.

Mesmo assim é possível utilizar diferentes boas práticas de diferentes MétodosÁgeis. Com isso alguns processos mais rígidos da empresa podem ser simplificados, asequipes têm mais escolhas para diminuir a resistência e, consecutivamente, reduzir achance de não continuidade do uso.

Contudo, o envolvimento deve ser completo. Mesmo que a equipe dedesenvolvimento esteja disposta a mudar sua forma de trabalho a diretoria deve estardisposta a participar e acompanhar o andamento da forma de trabalho. Ainda maisimportante para o sucesso, é a interação do cliente com a equipe do projeto. Isto porqueé ele que dará o rumo adequado conforme suas necessidades.

Foi possível, também, verificar o quão a empresa se tornou ágil ao final deimplementação das diferentes boas práticas propostas no decorrer do trabalho. Para essaavaliação, foi usada a metodologia proposta por Ambler (2004), onde são verificadosalguns fatores que podem determinar a agilidade da equipe/empresa (ver Tabela 5).

Tabela 5. Fatores para avaliar o engajamento ágil.

Status Fator

Não Os clientes/usuários são participantes ativos do trabalho de modelagem derequisitos e/ou análise

SimAs mudanças de requisitos são bem-vindas e trabalhadas conforme

adequado. Não há “requisitos congelados”.

SimVocê trabalha nos requisitos de maior prioridade primeiro, conformepriorizado pelos clientes, e enfoca os temas de mais alto rico à medida queo trabalho progride.

Sim Você emprega uma abordagem iterativa e incremental de modelagem.

SimSeu foco principal é o desenvolvimento de software, não a documentaçãodos modelos em si.

Sim Você modela como uma equipe na qual o retorno de todos é vem-vindo.

Sim Você tenta manter as coisas tão simples quanto possível. Você usa asferramentas mais simples disponíveis e cria os modelos mais simples querealizem o trabalho.

NãoVocê descarta a maioria, se não todos, os seus modelos à medida que odesenvolvimento progride.

SimOs clientes/donos do negócio tomam decisões do negócio. Osdesenvolvedores tomam decisões técnicas.

SimO conteúdo do modelo é reconhecido como sendo significativamente maisimportante que seu formato/sua representação.

Sim Como você testa o que descreve com os modelos é um tema crucialcontinuamente considerado à medida que modela.



Apesar de Ambler (2004) salientar que para o correto engajamento ágil todos osfatores devem estar marcados, ao ver pelo aspecto de que foram usadas diferentesmetodologias e boas práticas escolhidas conforme a necessidade – não houve

rigorosidade nem foi imposto um Método Ágil específico – pode ser observado quehouve um resultado significativo para a empresa, mais precisamente, 81% da avaliação.

Isso comprova o que vários autores defendem ao dizer que desenvolvimento ágilé uma “filosofia” e não uma nova técnica. As equipes não podem esperar fórmulasmágicas que resolverão seus problemas, mas pensar diferente e ver os seus processos deforma mais simples. Este é o principal fator para comprometimento e aceitação amudanças (desde software até a forma de trabalho).

É importante salientar que existem projetos onde não se pode abrir mão dosprocessos rigorosos de uma engenharia de software tradicional. Isso porque aindaexistem projetos em que, por exemplo, os requisitos não podem ser mudados durante o

desenvolvimento e que devem ser definidos todos, e corretamente, no início do projeto.Logo, desenvolvimento ágil deve ser destinado a projetos fora desse contexto, onde ocliente sabe o que quer, mas não como quer que seja feito.

Para trabalhos futuros podem ser desenvolvidos (1) uma forma de analisar quaisboas práticas causam maior impacto – positivo e negativo – para equipe nodesenvolvimento ágil ao usar todas elas sem distinção; (2) alternativas para trazer ocliente para dentro do projeto a fim de respeitar a falta de tempo dele e fazer com queele participe constantemente; (3) avaliar percentual de redução de desperdícios – evitardesenvolver funcionalidades desnecessárias para o sistema apenas por desejo do cliente– ao desenvolver de forma interativa com o cliente; (4) utilizar todas as boas práticas –

sem opção de escolha pela equipe – e comparar com o resultado obtido neste trabalho sea flexibilidade e participação da equipe é mais eficiente do que imposição do que deveser feito.

6. Referências

AMBLER, Scott W. Modelagem Ágil. São Paulo: Bookman, 2004.

CAMARA, Fabio. MSF Essentials e MSF Agile. Disponível em:<http://www.linhadecodigo.com/Artigo.aspx?id=1471>. Acesso em: 29 abr. 2009.

______. Microsoft Solutions Framework . DOTNET Magazine, Rio de Janeiro, Edição42, p. 56-59, 2007.

______; MARTINS, José Carlos. Um cardápio de metodologias ágeis. DOTNETMagazine, Rio de Janeiro, Edição 48, p. 26-35, 2008.

FONSECA, Isabella; CAMPOS, Alberto. Por que Scrum? Engenharia de Software

Magazine, Rio de Janeiro, Edição 4, p. 30-35, 2008.

MANIFESTO, Agile. Principles behind the Agile Manifesto. Disponível em:<http://agilemanifesto.org/principles.html>. Acesso em: 10 abr. 2009.

PRASS, Fernando; PUNTEL, Márcio Daniel. Um overview sobre FDD, MSF, SCRUMe XP. DOTNET Magazine, Rio de Janeiro, Edição 68, 2009.

PRESSMAN, Roger S. Engenharia de software. São Paulo: McGraw-Hill, 2006.



SOARES, Michel dos Santos. Metodologias Ágeis Extreme Programming e Scrumpara o Desenvolvimento de Software. Disponível em:<http://www.facecla.com.br/revistas/resi/edicoes/ed4artigo06.pdf>. Acesso em: 10

abr. 2009.TELES, Vinicius. Palestra sobre Extreme Programming na TDC 2008. Disponível

em: <http://www.viddler.com/explore/vinicius/videos/2/>. Acesso em: 05 jul. 2009.

Documents

[TCC2]Um Metodo Agil Hibrido v11