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
marcio@puntel.org, fprass@gmail.com
Resumo. Com o surgimento dos Métodos Ágeis, o desenvolvimento de softwares teve um ganho de produtividade significativo. Contudo, vários métodos surgiram e com diferentes propostas, deixando empresas e desenvolvedores receosos sobre qual seguir ou usar. Este trabalho apresenta e traça um comparativo entre as principais características das metodologia
FDD, MSN SCRUM e XP a fim de buscar um conjunto de boas práticas com
diferentes abordagens para, ao final, exibir os resultados e oferecer uma forma mais simples e mais eficiente de desenvolvimento de sistemas. Além disso, 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, Extreme Programming, Scrum, Feature Driven Development, Microsoft Solutions Framework.
1. Introdução
O desenvolvimento de software passou por mudanças desde o modo de codificar até o gerenciamento do processo de desenvolvimento como um todo. Vários fatores estiveram envolvidos para esse quadro, entre eles a Engenharia de Software e Programação Orientada a Objetos. Contudo, o que ultimamente tem chamado a atenção de programadores, gerentes de projetos e empresas é o desenvolvimento ágil.
O desenvolvimento ágil trouxe um conjunto de abordagens objetivadas a quebrar o paradigma de que o desenvolvimento de software pode ser controlado como uma engenharia tradicional. Ou seja, não se pode planejar o desenvolvimento de um
software 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) devem estar preparados para isso.
O problema se deu quando várias metodologias começaram a surgir, com peculiaridades diferenciadas que nem sempre são compatíveis com os objetivos e problemas que micros e pequenas empresas de desenvolvimento enfrentam. Isto é percebido pela baixa efetividade de uso; ainda, pelo uso incorreto das metodologias quando 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 usados Mé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 usar boas 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, de forma gradativa e, principalmente, com flexibilidade. Dessa forma, todos poderão perceber o quão são simples e eficazes as boas práticas ágeis.
Com isso busca-se algumas melhorias significativas para a empresa de desenvolvimento e verifica-se alguns fatores críticos para o sucesso de uma aplicação correta 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 problemas de desenvolvimento em cada iteração, até o entendimento e engajamento dos envolvidos. E também, quanto necessário, ajustar as substituições ou descarte das prá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 as principais características do Extreme Programming, Scrum, Feature Driven
Development e Microsoft Solutions Framework. Na seção 3 está descrita a metodologia e como foi aplicada. Na seção 4 estão relatados os resultados do trabalho analisados durante, e posterior, a implementação. Na seção 5 são colocadas algumas considerações finais 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 e consultores de software assinaram o Manifesto Ágil no qual declaravam que estavam descobrindo melhores modos de desenvolver softwares, passando a valorizar [Pressman 2006]:
• 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ípios baseados no bom senso de todos os envolvidos, fazendo um convite a pensar diferente, aceitar mudanças, melhorar continuamente, adaptar-se e ter comprometimento [Fonseca e Campos 2008].
A metodologia ágil também pode ser vista como uma forma de se buscar fazer diferente, com mesmos recursos, quando se precisa que resultados sejam diferentes dos que habitualmente são alcançados, já que os requisitos nunca serão os mesmos [Camara e 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, as metodologias: Scrum, por ser bem completa e com forte gerenciamento; Extreme
Programming, 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 ao final da década de 90, por Kent Beck. Vem fazendo sucesso, por ajudar a criar sistemas de melhor qualidade, que são produzidos com mais simplicidade e de forma mais econô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 de funcionalidades feitas a partir da visão do cliente) possam ser ajustadas conforme a mudanç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 busca sempre trabalhar a simplicidade para implementar apenas os requisitos necessários, evitanto funcionalidades complexas que possam ser desnecessárias ou ser criadas no futuro. O feedback constante com o cliente (interações semanais) faz com que o
software 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 é um Método Ágil que tem o nome derivado do jogo de Rugby, onde os jogadores reúnem-se para criar novas estratégias e realizar adaptações. Os princípios do Scrum são bem próximos do Manifeto Ágil. Ele foca em pequenas equipes, processos adaptáveis, frequentes incrementos, divisão do desenvolvimento, testes, documentação e entregas constantes. “O Scrum incorpora um conjunto de padrões de processo que enfatiza prioridades 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 usado em 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 do controle empírico (controle frequente e adaptação) de processos [Camara e Martins 2008].
O Scrum inicia com uma visão que é a base para o planejamento. Nesse planejamento é definido o Backlog do Produto (requisitos e funcionalidades). São realizadas 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ão realizadas reuniões diárias até o final do Sprint. Após o término da iteração deve ser finalizado 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 de retrospectiva (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 de modelagem 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 defende processos á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 o sistema deverá possuir, com base na modelagem dos requisitos. Na sequencia, são planejadas as funcionalidades para cada membro da equipe. Na iteração, cada membro deverá trabalhar especificamente para sua funcionalidade, que deverá ser construída em no máximo duas semanas [Camara e Martins 2008].
O destaque com o desenvolvimento por funcionalidade se deve porque “é uma funçã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 visualizar perante 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 funcionalidades e não como um todo [Pressman 2006].
O FDD parte desde o início com o foco na orientação por objetos. A partir do conhecimento das pessoas especializadas no domínio, é construído o modelo de classes do negócio. Essas classes de negócios são divididas e distribuídas entre os programadores (cada um pode ter uma ou várias classes) que implementarão, quando o Programador Chefe definir, sua codificação; e caso uma funcionalidade exija uma iteração maior que de duas semanas, ela deve ser desmembrada. Veja na Figura 3.
Figura 3. Estrutura do FDD. [Prass e Puntel 2009]
Criado pela Microsoft em 1993, o MSF teve um foco, na época, um pouco diferente do convencional, causando certas opiniões adversas sobre a sua eficácia. Houve diferentes nomes 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. Para fazer um comparativo, seria como se o PMI definisse que o escopo é fixo, os recursos razoavelmente variáveis e tempo variável e no MSF que o tempo é fixo, os recursos razoavelmente variáveis e o escopo variável [Prass e Puntel 2009].
Além disso, o MSF é dividido em duas personalizações: Essential e Agile. O
Essential é o convencional para projetos que requerem um grau maior de detalhes e controle. Já o Agile deu-se após o Manifesto Ágil [Manifesto 2009] e é destinado a projetos 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 constantes a 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 foi executado o trabalho.
3.1. Exposição do paradigma ágil
Conforme previsto, foi realizada uma reunião com a diretoria da empresa Alfa, na qual foi implementado o projeto com uso de boas práticas de diferentes metodologias ágeis.
A reunião mostrou para os diretores as características do desenvolvimento ágil, seus pontos positivos (simplicidade nos processos, melhoria contínua, adaptação predisposiçã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 mais adequadas a serem usadas). Com isso, a empresa ficou ciente de que a participação de todos é importante para uma boa comunicação.
Com essa participação dos diretores os resultados – custo e tempo – poderiam ser melhorados, já que os mesmos faziam um primeiro contato com o cliente e que muitas 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 funcionalidades o custo de desenvolvimento estaria mais preciso.
3.2. Recursos disponíveis
No próximo passo foram definidos os recursos disponíveis (colaboradores que iriam participar). Inicialmente, mesmo que em projetos diferentes, todos os colaboradores se dedicaram em aplicar boas práticas no seu dia-a-dia, para que todos aprendessem e trabalhassem 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, foram usados 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ês analistas 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 (projetos anteriores de sucesso/insucesso) para se guiar. Quanto aos profissionais, já possuiam boa experiência em projetos de diferentes portes. Contudo, nenhum havia se comprometido 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 resultados esperados, 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 os processos. Verificou-se que alguns processos eram executados de forma bem tradicional (Engenharia de Software) e outros sem um padrão, sendo guiados por experiências profissionais. Além dos problemas, buscou-se definir novas maneiras de melhorar os processos que eram considerados problemáticos.
Após as considerações terem sido colocadas e discutidas, chegaram-se às seguintes boas práticas que estão demonstradas na Tabela 1, onde se procurou mostrar o problema no momento inicial do projeto, a boa prática analisada para ele e qual (ou quais) metodologia ágil derivou-se.
Problema Boa prática Metodologia derivada
Levantamento de requisitos/Escopo
Visão (Definição das funcionalidades da iteração)
XP (Estoria), Scrum (Visão), FDD (Modelo) e MSF (Release)
Estimativa de prazo Planing Poker XP e Scrum
Sistema disponível para uso Iteração de 2 semanas FDD Reuniões de
acompanhamento
Reuniões diárias de 15 minutos
Scrum
Feedback do cliente Cliente participa em: Visão, definição de prioridades, testes e aprovação da funcionalidade
XP, Scrum, FDD e MSF
Documento para cliente Relatórios de progresso FDD Responsabilidades Papeis: Product Owner,
Scrum Master e Scrum Team
Scrum
Avaliação de status de
projetos Scrum Master Scrum
Complexidade subjugada Product Owner Scrum
Comunicação Reuniões diárias XP e Scrum
Mudança de requisitos Propriedade coletiva e
Visã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 foi gradual e demorado (mais de um mês) para que os envolvidos se acostumassem às mudanças e, principalmente, pelo correto uso das boas práticas. Devido a isso, buscou-se discutir com conbuscou-senso todas as formas de uso para evitar “choque” de idéias.
Nesse momento, os papéis foram distribuídos para que todos se localizassem no projeto 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ão ampla do sistema), o gerente de projetos seria o Scrum Master (nortear os desenvolvedores) e Scrum Team (demais colaboradores). Os papéis do Scrum foram mais bem vistos pela equipe, já que a distribuição atual dos membros não mudou muito e por possuir uma estrutura mais gerenciável.
Ainda, foi modificada a forma de planejar o tempo de desenvolvimento de cada funcionalidade. 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 analistas determinam o tempo necessário para realizar determinadas funcionalidades.
Sempre ao final de cada iteração deveria ter uma funcionalidade pronta para que o cliente possa testar e, em caso de aceite, implantar. Para isso, a comunicação deveria ser 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 realizadocontato com o cliente para explicar as vantagens 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 acompanhamento onde o cliente teria um status do andamento do projeto perante o tempo destinado às determinadas funcionalidades.
Ao trabalhar com iterações pequenas, a comunicação com o cliente acabaria sendo constante, já que para ter um sistema de acordo com as suas necessidades, de forma simples e objetiva, o cliente deveria dispor um determinado tempo para o projeto e 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 bem objetiva na funcionalidade priorizada praquela iteração. Sempre foram elaborados modelos simples e evitou-se fazer o que não poderia ser usado futuramente, para que em caso 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, que sem demora chegou: mudança de requisitos.
Para que a empresa dispusesse de uma padronização de codificação e de recursos necessários a determinadas tarefas, a propriedade coletiva dos códigos fontes foi escolhida como caminho. Assim, a integração de diferentes partes - módulos do sistema – fosse realizada com mais agilidade e com menor tempo de depuração.
Além disso, sempre houve a responsabilidade de se documentar tudo que fosse criado através de comentários padronizados no código fonte, já que Kent Beck diz que inclusive comentários podem ser considerados documentos, para gerar documentação quando necessário.
3.7. Avaliar e reagir (adaptações)
Essa etapa foi proposta justamente pensando nas mudanças que poderiam surgir no decorrer do desenvolvimento do projeto, devido ao mau uso da boa prática, e até mesmo ela não ser relevante para solução do problema naquele momento.
Para realizar as mudanças da próxima iteração, perante os problemas encontrados no decorrer da iteração atual, a reunião de acompanhamento foi estipulada
para ser realizada diariamente. Ao final da iteração, haveria a reunião de retrospectiva onde os pontos positivos e negativos da iteração passada (ou atual) pudessem ser discutidos 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 a reuniã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 de evitando prejudicar o andamento da iteração ou mesmo uso o indevido pelo membro da equipe.
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 obtidos na aplicação de boas práticas, dos Métodos Ágeis abordados, em um projeto real no período de junho a novembro de 2009.
Junto aos resultados serão vistos os motivos relacionados aos fatores positivos ou negativos encontrados na aplicação do mesmo. Para uma melhor visão da análise realizada, a seção foi dividida em duas subseções, pontuando as observações que ocorreram 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 bom andamento 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 agregando facilidades no dia-a-dia da mesma, quando da exposição do paradigma ágil, já houve o primeiro problema. Isso porque, quando se fala em desenvolvimento ágil, conforme Ambler (2004), as pessoas – leigas – automaticamente assimilam erroneamente que se trata de desenvolvimento rápido: somente que vai fazer em menos tempo.
Mesmo após uma explicação bem cautelosa do que seria implementado com o desenvolvimento ágil e os possíveis resultados que poderiam ser alcançados, ao verificar que não se tratava da visão a qual eles, os diretores, vislumbravam inicialmente, os primeiros empecilhos foram expostos através de perguntas e comentá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 dar continuidade 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
Ao se tratar com a diretoria, que no caso são pessoas de outras áreas e algumas vezes sem conhecimento mais técnico, foi percebido que quando o assunto era fazer mais 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 sua necessidade - e no papel de desenvolvedores – quando ganhariam tempo e rendimento simplificando 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 da equipe 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 com simplicidade 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ções que geraram alguns desconfortos. Neste momento alguns iniciaram gradativamente o abando da proposta e deixaram de fazer o esperado para fazer de forma incorreta ou mesmo não executar suas atividades conforme o programado. Percebe-se que neste momento 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 dos procedimentos 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 era esperado que as boas práticas iniciais adotadas pudessem sofrer alteração no futuro, o que realmente aconteceu. Contudo, o que está sendo exposto como negativo é que não se pode acertar de início e sempre deverá haver ajustes, o que pode ser frustrante para uma equipe desmotivada.
Isto pode ser visto na Tabela 3 – na qual se encontram as principais características das metodologias ágeis abordadas – nas três versões de conjuntos de boas práticas. Nela ainda é possível verificar que houve quatro formas de avaliar o uso das boas práticas: (I) Implantado – quando a mesma foi usada naquela versão; (N) Não implantada – quando não houve o uso ou que não foi necessário; (T) Tentativa de implantação – quando houve a tentativa para verificar se na próxima versão poderia ser efetivamente implantada; (D) Desistência de implantação – quando se percebeu que aquela 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 V3
Estórias T T D
Plano geral I I I
Desenvolvimento iterativo T I I
Iteração de uma semana N N N
Teste antecipado N N N Envolvimento do cliente I T T Propriedade coletiva T I I Código padrão T I I Projeto simples I I I Planning poker T T N
Scrum Visão geral I I I
Sprint de duas semanas T N N
Planejamento do Sprint I I I Equipes auto-organizadas N T I Reunião diária I T D Equipes pequenas I I I Reunião de revisão T D D Reunião de retrospectiva T D D Post-it T D N FDD Iterativo I I I Enfatizar na qualidade N N T
Entregar de resultados tangíveis N I I
Relatório de progresso I T D Divisão/propriedade de classes T I I MSF Comunicação aberta I I T Visão compartilhada N I I Alternar líderes N N N Responsabilidades compartilhadas I I I
Entrega com valor para o negócio (tangível) N I I
Esperar mudanças N T I
Qualidade contínua I I I
Aprender com experiências anteriores N I I Legenda:
I - Implantado
T - Tentativa de implantação D - Desistência de implantação N - Não implantado V1 – 06/2009 – 07/2009
V2 – 08/2009 – 09/2009 V3 – 09/2009 – 11/2009
Com essas mudanças houve, algumas vezes, a perda de características das boas práticas. Isto ocorreu porque quando foi necessário adaptar e trabalhar com diferentes metodologias á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 foi redefinida 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 cliente
A participação do cliente, ou melhor, a falta dela, sem dúvida foi o ponto mais frustrante e marcante para que muitas boas práticas fossem preteridas. Apesar de o cliente ter se colocado disposto a participar no primeiro contato, mesmo que contrariado, posteriormente não aconteceu a interação (comunicação com o cliente ou, ainda, troca de experiências) prometida e necessária para que qualquer Método Ágil consiga ter um mínimo de fundamento.
Nos demais ciclos (além do primeiro), foram apenas levantados novos requisitos para a consequente iteração via e-mail e algumas raras vezes pessoalmente. A definição de 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ão entregue em nenhum momento, sendo que mudanças necessárias ou funcionalidades fora 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 eram os 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 teve motivação para tal.
4.1.5 Gerência
Mesmo que em alguns momentos a empresa tenha optado por equipes auto-organizadas, como defendido pelo Scrum, sempre é importante que se tenha um responsável pelo projeto – mais conhecido tradicionalmente como gerente de projetos. A falta do mesmo fez com que alguns membros da equipe acabassem perdendo tempo em atividades que poderiam estar sendo centralizadas e realizadas de melhor forma.
Sobre este aspecto em muitos momentos houve a carência de tal função, sendo que os desenvolvedores acabaram tendo responsabilidades compartilhadas em vários casos, 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ção fosse realizada em um centralizador – membro da equipe – no qual algumas atividades deixaram de ser realizadas por todos, mas por apenas um. Para exemplificar, tarefas como 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 bom andamento da aplicação ou mesmo que agregaram valores para a empresa no seu âmbito de desenvolvimento.
A padronização foi um ganho bem significativo para os fatores de manutenção e compartilhamento de códigos. Antes à realização de tal boa prática, desenvolvedores trabalhavam 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 novos módulos fosse gradativamente reduzido. Com isso, a performance para desenvolvimento 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 que atendesse todos os interessados, mas houve uma melhora significativa com as boas práticas de simplificar, atualizar e disponibilizar. Depois de várias tentativas frustradas de diferentes documentos (casos de uso, diagramas, templates), chegou-se ao sistema de
Wiki (proposta de XP e Scrum). Com isso se conseguiu um local onde todos podem disponibilizar as principais funções do sistema e ter subsídios atualizados das demais funcionalidades realizadas pelos demais membros.
Além disso, a equipe obteve ganhos de produtividade com esse canal porque puderam ser gerenciados outros pontos que em alguns momentos atrasavam algumas tarefas. 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), entre outros.
4.2.4 Definição de requisitos
Onde, antes da implementação das boas práticas, havia um levantamento de requisitos muito superficial e que muitas vezes era realizado sem a participação dos analistas programadores. Agora existe uma colaboração e comunicação a fim de ter elementos definidos com maior precisão.
Infelizmente, esse ganho foi conseguido somente após um erro que custou caro para a empresa. Embora deva ser um fator básico para desenvolvedores e que deve ser simples para o cliente, não existe uma receita de sucesso para que tal processo seja realizado 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 total satisfação (por falta de compreensão ou vontade de comprometimento), foi aceita. Nesse momento foram buscadas as prioridades do sistema perante o mesmo. Após definir 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 o andamento, 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.
Outro objetivo marcante dos Métodos Ágeis é a capacidade das equipes aceitarem e conseguirem atender às mudanças de requisitos – que cedo ou tarde acontecerão. Esta caracterí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 objetivos específicos das novas demandas. Isso fez com que, automaticamente, todos na equipe recebam 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 na Tabela 4. Essas boas práticas são resultantes das três versões expostas na Tabela 3 e que foram 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ática
XP Plano geral
Desenvolvimento iterativo Propriedade coletiva Código padrão Projeto simples Scrum Visão geral
Planejamento do Sprint Equipes auto-organizadas Equipes pequenas
FDD Iterativo
Entregar de resultados tangíveis Divisão/propriedade de classes MSF Visão compartilhada
Responsabilidades compartilhadas
Entrega com valor para o negócio (tangível) Esperar mudanças
Qualidade contínua
Aprender 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 para ser claro de onde foram buscadas. Além disso, como foi focado em flexibilidade em determinados momentos optou-se por uma ou outra.
5. Considerações finais
Ficou claro que para uma aplicação eficaz e com resultados mais significativos, alguns fatores 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 tempo em 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, as equipes têm mais escolhas para diminuir a resistência e, consecutivamente, reduzir a chance de não continuidade do uso.
Contudo, o envolvimento deve ser completo. Mesmo que a equipe de desenvolvimento esteja disposta a mudar sua forma de trabalho a diretoria deve estar disposta a participar e acompanhar o andamento da forma de trabalho. Ainda mais importante 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 de implementação das diferentes boas práticas propostas no decorrer do trabalho. Para essa avaliação, foi usada a metodologia proposta por Ambler (2004), onde são verificados alguns 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 de requisitos e/ou análise
Sim As mudanças de requisitos são bem-vindas e trabalhadas conforme adequado. Não há “requisitos congelados”. Sim
Você trabalha nos requisitos de maior prioridade primeiro, conforme priorizado pelos clientes, e enfoca os temas de mais alto rico à medida que o trabalho progride.
Sim Você emprega uma abordagem iterativa e incremental de modelagem. Sim Seu foco principal é o desenvolvimento de software, não a documentação dos 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 as ferramentas mais simples disponíveis e cria os modelos mais simples que realizem o trabalho.
Não Você descarta a maioria, se não todos, os seus modelos à medida que o desenvolvimento progride. Sim Os clientes/donos do negócio tomam decisões do negócio. Os desenvolvedores tomam decisões técnicas.
Sim O conteúdo do modelo é reconhecido como sendo significativamente mais importante que seu formato/sua representação.
Sim Como você testa o que descreve com os modelos é um tema crucial continuamente considerado à medida que modela.
Apesar de Ambler (2004) salientar que para o correto engajamento ágil todos os fatores devem estar marcados, ao ver pelo aspecto de que foram usadas diferentes metodologias e boas práticas escolhidas conforme a necessidade – não houve rigorosidade nem foi imposto um Método Ágil específico – pode ser observado que houve 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órmulas mágicas que resolverão seus problemas, mas pensar diferente e ver os seus processos de forma mais simples. Este é o principal fator para comprometimento e aceitação a mudanças (desde software até a forma de trabalho).
É importante salientar que existem projetos onde não se pode abrir mão dos processos rigorosos de uma engenharia de software tradicional. Isso porque ainda existem 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 o cliente sabe o que quer, mas não como quer que seja feito.
Para trabalhos futuros podem ser desenvolvidos (1) uma forma de analisar quais boas práticas causam maior impacto – positivo e negativo – para equipe no desenvolvimento ágil ao usar todas elas sem distinção; (2) alternativas para trazer o cliente para dentro do projeto a fim de respeitar a falta de tempo dele e fazer com que ele participe constantemente; (3) avaliar percentual de redução de desperdícios – evitar desenvolver 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 se a flexibilidade e participação da equipe é mais eficiente do que imposição do que deve ser 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ção
42, p. 56-59, 2007.
______; MARTINS, José Carlos. Um cardápio de metodologias ágeis. DOTNET
Magazine, 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, SCRUM e XP. DOTNET Magazine, Rio de Janeiro, Edição 68, 2009.
SOARES, Michel dos Santos. Metodologias Ágeis Extreme Programming e Scrum
para 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.
