Metodologias Ágeis
Um overview sobre FDD, MSF, SCRUM e XP
Márcio Daniel Puntel (marciopuntel@yahoo.com.br) é acadêmico de Sistemas de Informação na Universidade Luterana do Brasil (ULBRA), Campus Cachoeira do Sul, trabalha no desenvolvimento de sistemas desde 2003. Atualmente é analista programador (.NET C#), integrante da equipa da Elevata Tecnologias de Projetos.
Fernando Sarturi Prass (fernando@fp2.com.br) é Mestre em Ciência da Computação pela UFSC. Professor da Universidade Luterana do Brasil (ULBRA) nos campus de Santa Maria e Cachoeira do Sul. Diretor da FP2 Tecnologia (www.fp2.com.br), empresa que presta serviços de desenvolvimento de sistemas e de consultoria em Bancos de Dados e Metodologias de Desenvolvimento.
Do que trata o artigo
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 artigo apresenta as semelhanças e diferenças existentes nas principais metodologias ágeis de desenvolvimento usadas atualmente: FDD, MSF, SCRUM e XP.
Para que serve
O desenvolvimento ágil contribui para que equipes e empresas consigam desenvolver sistemas de forma mais simples e eficiente, visando com isto atender às constantes mudanças de requisitos que cada vez mais são necessárias nos projetos atuais.
Em que situação o tema é útil
Apesar das metodologias ágeis basearem-se na simplicidade, para se possa efetivamente aplicar uma delas em projetos reais fatores devem ser considerados e premissas devem ser seguidas. Por defenderem a flexibilidade, ou seja, a facilidade de adaptar-se perante as mudanças necessárias e/ou unir esforços com outros processos a fim de atingir o seu objetivo – satisfação do cliente, as metodologias ágeis podem ser usadas em qualquer projeto de desenvolvimento.
Resumo do DevMan
O cotidiano do desenvolvimento de software apresenta projetos cada vez maiores e mais complexos, entretanto o tempo disponível para o desenvolvimento desses sistemas está cada vez menor e com mudanças significativas desde a concepção até a finalização. As metodologias de desenvolvimento tradicionais não conseguem adaptar-se a essa realidade já que nelas os processos são mais detalhados, exigem maior documentação (em geral, pode-se dizer que são mais “amarradas”).
Esta complexidade de tempo versus mudanças fez com que os projetos menores, e que exigem resultados mais imediatos, fossem prejudicados pelo excesso de tarefas impostos pelo método tradicional. Mesmo em alguns projetos grandes pode se encontrar pontos em que a demasia de rotinas, dos métodos tradicionais, gera atrasos desnecessários.
Esse panorama começou a ser alterado em 2001 com o surgimento do Manifesto Ágil [Manifesto 2009] que fez com que o processo de desenvolvimento de softwares fosse visto de maneira diferente quando desenvolvedores, empresas e consultores propuseram novas formas de desenvolver. Essa “Aliança Ágil” fez com que uma nova filosofia fosse vislumbrada, já que ela propõe uma ideologia diferente e mais “simples”. Nesse momento despontam vários métodos ágeis com suas características marcantes, ou nem tanto, com a ideia de ajudar empresas e desenvolvedores a “trilhar um novo caminho para o sucesso” [Pressman 2006].
Consequentemente várias metodologias ágeis começaram a serem usadas, cada uma com seu enfoque, mas que nem sempre são compatíveis com os objetivos e problemas que micro e pequenas empresas de desenvolvimento enfrentam. Isto é percebido pela grande variedade de características específicas e pela aceitação e/ou rejeição pelas equipes, de tais metodologias. Neste cenário, destacam-se, pela maior aceitação devido às boas práticas sugeridas, os métodos ágeis Extreme Programming (XP), Scrum, Feature Driven Development (FDD) e Microsoft Solutions Framework (MSF) [Camara e Martins 2008].
Visto que existem práticas que são bem aceitas e com características positivas no processo de desenvolvimento, conhecendo os detalhes de cada uma delas, o desenvolvedor pode escolher as práticas que melhor se adéquam ao seu dia a dia e, de certa forma, criar uma metodologia própria para a equipe para um determinado projeto.
Este artigo busca mostrar as semelhanças e diferenças entre as quatro metodologias citadas anteriormente, trazendo assim subsídios para que o leitor possa definir qual (ou quais) possam ser aplicadas para simplificar o seu trabalho.
2. Metodologias Ágeis
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 eles 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, citados acima, foram criados pensando em ter 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].
Metodologia Ágil é uma forma de se buscar o que fazer diferente quando são necessários resultados diferentes [Camara e Martins 2008]. Ainda, uma boa visão do que pode ser definido como agilidade no desenvolvimento de software:
Agilidade tornou-se atualmente uma palavra mágica quando se descreve um processo moderno de software. Tudo é ágil. Uma equipe ágil é esperta, capaz de responder adequadamente às modificações. Modificação é aquilo para qual o desenvolvimento de software está principalmente focado. Modificações no software que está sendo construído, modificações de todas as espécies que podem ter impacto no produto que eles constroem ou no projeto que cria o produto. O apoio para modificações deveria ser incorporado em tudo que fazemos em software, algo que se adota porque está no coração e na alma do software. Uma equipe ágil reconhece que o software é desenvolvido por indivíduos trabalhando em equipe e que as especialidades dessas pessoas e sua capacidade de colaborar estão no âmago do sucesso do projeto [Pressman, p. 59, 2006].
A filosofia ágil deu origem a várias metodologias ágeis como: Scrum, Extreme Programming,
Feature Driven Development, Microsoft Solution Framework, Crystal, Adaptative Software Development, Dynamic Systems Development Method, entre outros. Contudo, aqui trataremos apenas de: 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 ter sido cria pela empresa que mais desenvolve no mundo.
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, produzidos em menos tempo e de forma mais econômica que o habitual [Pressman 2006].
O ciclo proposto é diferente do desenvolvimento convencional porque sua iteração (ciclos de determinados períodos) é incremental, fazendo com que o projeto tenha as suas funcionalidades acrescidas em cada interação e 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. Na Figura 1 o método pode ser visto nas suas três fases: exploração, compromisso e direcionamento, respectivamente.
Figura 1. Ciclo do XP. Adaptação de Camara e Martins (2008)
As variáveis de controle em projetos realizados com XP são quatro: custo, tempo, qualidade e escopo (requisitos e funcionalidades do sistema). Como pode se notar há forte ligação com o tripé básico do gerenciamento de projeto proposto pelo Project Management Institute (PMI): custo, tempo e escopo.
O XP busca sempre trabalhar a simplicidade para que se implemente apenas os requisitos necessários, evitando funcionalidades complexas que podem ser desnecessárias ou ser criadas no futuro porque considera que requisitos são mutáveis. O feedback constante com o cliente (interações semanais) faz com que o software desenvolvido seja inspecionado a todo momento, com reuniões diárias, o que faz com que possa ser mudado rapidamente sem grandes perdas [Soares 2004].
O XP trabalha com várias práticas, mas devido à sua proposta de flexibilidade não é necessário seguir todas e com isso adotam-se as mais expressivas e mais usadas nos projetos [Camara e Martins 2008]. Contudo, as 12 práticas do XP são descritas a seguir [Soares 2004].
• Programação em par: visa redução de erros durante a implementação e códigos melhor elaborados.
• Estórias: detalhamento das funcionalidades sem uso de termos técnicos de uma forma para que seja mais o entendimento.
• Planejamento: plano geral do projeto, priorizando o que pode ser feito no momento e deixando em segundo plano o que pode ser adiado.
• Desenvolvimento iterativo: ciclos de reavaliação das interações para que os stakeholders (equipe envolvida no projeto) estejam em sintonia e que processos possam ser revistos e/ou refeitos.
• Iterações de uma semana: feedback mais rápido. Faz com que, ao cliente perceber algo que esteja fora da estória, possa se tomar ações reativas mais rapidamente.
• Teste antecipado: em todas as iterações e em cada funcionalidade realizar testes a fim de reduzir ou eliminar erros na entrega.
• Refactoring: melhoria contínua no código sempre que necessário buscando que os sistemas cada vez sejam mais eficazes e com maior chance de reuso.
• Envolvimento do cliente: cliente deve participar de todas as interações para validar as funcionalidades. Caso a funcionalidade não tenha sido atingida ou que esteja fora da estória, o cliente poderá intervir fazendo com que a mesma seja corrigida num tempo hábil e sem custos demasiados.
• Propriedade coletiva: o código do projeto pertence a todos os membros da equipe com a finalidade de que todos conheçam todas as partes do software.
• 40 horas semanais: não deve ser feito horas-extras, pois isso demonstra que existe erro no projeto e deve ser corrigido.
• Código padrão: para que possa ser compartilhado entre todos os programadores com facilidade.
• Projeto simples: realizar sempre pensando no mais simples para que seja desenvolvido mais rapidamente.
Não existe padrão para os papéis (atividade que uma pessoa da equipe desempenha) no XP, já que podem variar conforme o projeto. Ou seja, uma mesma pessoa pode assumir diferentes papéis, sendo que eles podem ser: testador, designer de interação, arquiteto, gerente de projeto, gerente de produto, executivo, documentador técnico, usuário e programador. Não é necessário haver todos num projeto, mas o XP defende que devem ser equipes de no máximo sete pessoas. Para esses papéis, o foco é: comunicação, simplicidade, feedback, coragem, respeito, ser mais humano, benefício mútuo, reutilização, melhoria contínua, diversidade, qualidade, desenvolvimento em pequenos passos e responsabilidade [Camara e Martins 2008].
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 ao do Manifeto Ágil. Ele foca em pequenas equipes, processos adaptáveis, frequentes incrementos, divisão do desenvolvimento, testes e documentação constantes 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 tem por base a teoria do controle empírico (controle frequente e adaptação) de processos e
seus fundamentos são originados nas dez melhores práticas da indústria japonesa (para maiores detalhes sobre ela consulte o artigo “O jogo de desenvolvimento de novos produtos” escrito por Takeuchi e Nonaka).
Embora o XP tenha sido criado com base no Scrum, eles diferem em alguns pontos. O Scrum é dividido em Sprints (iterações de trinta dias), equipes pequenas de no máximo sete pessoas (projetistas, programadores, engenheiros e gerentes de qualidade) que trabalham as funcionalidades definidas no início de cada Sprint [Camara e Martins 2009]. Além disso, no Scrum as reuniões são diárias e de no máximo quinze minutos e o ciclo é um pouco maior [Soares 2004].
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 produto. Posteriormente devem ser realizadas as reuniões de revisão (rever novos requisitos) e de retrospectiva (rever pontos positivos e negativos) [Camara e Martins 2008]. Veja o clico na Figura 2.
Figura 2. Ciclo do Scrum
O Scrum possui três papéis: Product Owner (Dono do Produto), Scrum Master (Líder do Projeto) e Scrum Team (Equipe) e suas responsabilidades são desmembradas (diluídas) nas fases Pré-game,
Game e Pós-game e determinado o uso das seguintes práticas [Fonseca e Campos 2008]:
• Plano de jogo: visão geral e vaga no início do projeto. Serve de norteador para o Product
Owner.
• Sprint: período da iteração de cada conjunto de requisitos (Backlog de Produto).
• Planejamento do Sprint: levantar e selecionar os requisitos que podem ser realizados até o final do Sprint (Backlog do Sprint).
• Equipes auto-organizadas e auto-dirigidas: cada um sabe o que fazer e como fazer.
• Reunião diária: em pé e de no máximo 15 minutos onde todos da equipe devem responder: (1) O que você fez? (2) O que você fará? (3) Há algum obstáculo?
• Equipes de até 7 pessoas: para ser mais fácil de gerenciar a equipe. Caso seja necessário, o Scrum defende o escalonamento em várias equipes.
• Reunião de revisão do Sprint: revisar se houve um incremento no produto que possa ser demostrado e que funcione.
• Reunião de retrospectiva do Sprint: são levantados os pontos positivos e negativos do
Sprint para que futuras ações sejam mais bem aplicadas.
Com isso, o processo é iniciado no pré-game com pontos levantados onde o Product Owner terá a responsabilidade de repassar para o Scrum Team, que realizarão a reunião (Release Planning) para criação do Backlog de Produto. Em seguida, o Scrum Team selecionará as funcionalidades consideradas capazes de ser realizadas no Sprint e criarão o Backlog Sprint. No game, que é totalmente flexível, serão
realizadas as reuniões diárias para verificar se a meta está sendo seguida, se o escopo segue sua conformidade e se não haverá empecilhos para continuidade do projeto. E no pós-game, ter-se-á entrega de um incremento “útil e usável” para o projeto e revisão de problemas que decorreram durante o Sprint [Fonseca e Campos 2008].
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 Figura 3 é possível verificar que 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. Os papéis podem ser atribuídos a diferentes membros em diferentes projetos e são: Gerente de projeto, Gerente de desenvolvimento, Arquiteto-chefe, Programadores-chefe, Proprietários de código/classe (Desenvolvedores), Especialistas do domínio (detentores do conhecimento do funcionamento do sistema). 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].
Figura 3. Estrutura do FDD
O FDD enfatiza os valores de comunicação, redução de complexidade e qualidade a fim de atingir resultados frequentes, tangíveis e funcionais. Um ponto marcante, com relação à qualidade, é a relação que o FDD faz com a experiência da equipe, já que defende ser melhor um número menor de pessoas, com bastante conhecimento, a várias inexperientes. Coloca também que as equipes sejam de no máximo dez pessoas. Além disso, possui as seguintes características [Camara e Martins 2008]:
• Enfatiza na qualidade: profissionais especializados acima de tudo.
• Entrega resultados tangíveis e frequentes: todas as funcionalidades devem ser “vistas” pelo cliente na entrega agregando algum valor para o sistema.
• Relatórios de progresso: para o cliente poder acompanhar o andamento do projeto e requerendo pouca demanda dos programadores sendo realizado em períodos curtos. 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 tornam-se fáceis de inspecionar; (5) planejamento é guiado pela hierarquia das funcionalidades e não como um todo.
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.
2.4. Microsoft Solutions Framework (MSF)
Criado pela Microsoft em 1993, o MSF teve um foco, na época, um pouco diferente do convencional causando 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 de uma ideologia de fazer produtos de forma diferenciada dando mais importância para o tempo, a fim de entregar nas datas determinadas, ao escopo. Sendo assim, verifica-se que ele difere do princípio do PMI que a importância maior é do 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 [Camara e Martins 2008].
O MSF é um conjunto de boas práticas testadas nos projetos da Microsoft e de seus parceiros e não deve ser vista como um processo de software. Possui oito princípios que são [Mendes 2007]:
• Manter a comunicação aberta: boa comunicação entre os envolvidos. • Trabalhar com uma visão compartilhada: todos devem ter a mesma visão. • Fornecer mais poderes aos membros do time: alternar líderes.
• Estabelecer responsabilidades compartilhadas: dividir resultados positivos ou negativos. • Focar na entrega de valor no negócio: entregar sempre para o cliente algo que seja
“usável”.
• Manter a agilidade e esperar mudanças: estar pronto, rapidamente, para realizar as mundaças que acontecerão.
• Focar em qualidade continuamente: sempre fazer melhor do que já foi feito.
• Aprender com as experiências passadas: usar cases passados para melhorar processos ou evitar falhas.
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.
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. Em Envisioning é onde é vista a visão geral do escopo e definido como será o projeto; na fase de Planning têm-se as especificações funcionais e os cronogramas de desenvolvimento dos produtos; na fase Developing é quando as funcionalidades serão criadas, checadas e testadas; a fase Stabilizing é para reparos em requisitos não atendidos ou desenvolvidos incorretamente e esta fase será encerrada quando não houver mais versões betas ou alfas [Viana 2009].
Figura 4. Ciclo MSF
Para executar um projeto, o MSF defende que é necessário o uso das seguintes responsabilidades: Program Manager, Product Manager, User Experience, Tester, Developer, Architect e Release Manager. Essas responsabilidades podem ser vistas como papéis a fim de se ter uma visão genérica em relação às demais metodologias [Camara e Martins 2008].
3. Implantando Metodologias Ágeis
É relevante verificar que na visão tradicional de desenvolvimento de softwares o objetivo é o sucesso do projeto. Já na visão Ágil, esse objetivo é a satisfação do cliente. Por isso, deve ser realizada uma reunião com a empresa para expor, defender e fazer o entendimento da mudança de paradigma, onde não serão apenas práticas, mas também uma nova filosofia.
Segundo Camara e Martins (2008), essa “conquista” da empresa é importante para que uma metodologia ágil seja implementada. Sem que proprietários entendam a real visão do que se pretende realizar, pode haver ideias distorcidas ou uma ilusão de alguma coisa que não existe.
Para usar boas práticas, indiferente da metodologia, são necessários diferentes recursos. Sejam recursos de softwares ou pessoas que devem ser elencados para que se tenha uma previsão do que se precisa e do que se dispõe. Isso é estritamente necessário porque algumas boas práticas são baseadas em premissas para sua aplicabilidade ou não. Visto isso, é necessária essa verificação dos recursos antes de identificar o que será usado.
O desenvolvimento ágil veio com o propósito de entregas incrementais, rápidas e com equipes motivadas. Por isso, além de fazer com que a equipe esteja encorajada a participar será necessário, também, fazer com que haja participação – indivíduos e interações ao invés de processos e ferramentas [Manifesto 2009] – para que eles se sintam parte importante do projeto. Com base nessa integração deve ser possível definir as boas práticas que poderão ser usadas para três objetivos: (1) satisfação do cliente; (2) motivação da equipe; (3) melhoria dos processos da empresa.
Visando facilitar a escolha sobre qual metodologia (ou sobre quais boas práticas) usar, a Tabela 1 apresenta uma comparação entre as principais características das metodologias vistas aqui. Essa escolha deve ser tomada com cuidado e, de preferência, em conjunto com outros membros da equipe, uma vez que isto guiará as decisões perante o modo de trabalho da equipe, comportamento de clientes, tempos médios de projetos, experiência dos envolvidos, envolvimento da empresa e entendimento das mesmas (o quão simples será a aceitação da proposta).
O processo de definição do modelo não é um processo simples pelo fato das boas práticas diferirem. Além disso, cabe lembrar que não é necessário expor todas as boas práticas das metodologias e sim as mais significativas e relevantes, ao menos num primeiro momento.
Com o modelo elaborado, é possível iniciar a implementação. Nesse momento deve ser criado um planejamento onde constarão os passos a serem seguidos, as etapas, os papéis ou responsabilidades, modelo de documentação e tratativas com o cliente. É importante deixar a equipe ciente que no desenvolvimento ágil existe a flexibilidade de projeto para projeto – com algumas exceções – e com isso os passos poderão ser ajustados no decorrer das atividades.
Na implementação é necessário a interação com o cliente, para que haja iterações pequenas e entregas de algo tangível. Isso deve ser bastante divulgado na equipe para que não se perca o foco ou que haja falhas na comunicação e nas prioridades previstas pelo cliente.
Sobre a comunicação, ela será constante. É uma boa prática intrínseca em todas as metodologias ágeis. Segundo Fonseca e Campos (2008) ela é um dos pilares para que a integração da equipe ocorra com sucesso. Perante isso, a cada final de iteração é importante que seja realizada uma reunião para que membros da equipe possam expor suas idéias sobre os processos, frustrações e fatores positivos.
Deve ser realizada uma exposição ao cliente onde o mesmo ficará informado do que se trata o desenvolvimento ágil, suas premissas e suas consequências. Isso para que o cliente possa se engajar corretamente desde a primeira etapa do desenvolvimento. Caso esse passo não seja realizado, ou mesmo que não consiga atingir seu objetivo, poderá haver mudanças radicais em qualquer uma das boas práticas adotadas.
Em se tratando de interação com o cliente, deve ser constante, não somente porque é pregado pelas metodologias ágeis, mas também porque é necessário e agregar valor ao andamento de um projeto de software. É necessário que o cliente saiba que estará participando de um novo conceito de desenvolvimento onde ele é parte fundamental para a melhor qualidade e que sua interação fará com que as funcionalidades do software fiquem muito mais próximas das reais aspirações dele.
O modelo deve ser avaliado constantemente nas iterações, para que se possa saber se está sendo usado de forma correta e se o resultado parcial está de acordo com a proposta da devida metodologia ágil. Por consequência, deverá haver uma reação para a avaliação realizada na iteração. Ou seja, se houve problema deve ser feito o ajuste necessário para que não se repita. Uma alternativa em caso de insucesso de alguma boa prática é buscar uma solução para substituí-la – somente as analisadas – para que os requisitos sejam atendidos.
Devido ao feedback constante do cliente, é possível analisar os resultados das iterações sem que o projeto esteja finalizado. Isso se deve ao fato de que existem entregas constantes, com os ajustes
pedidos pelo cliente e com melhorias continuas, fazendo com que o objetivo do desenvolvimento ágil seja verificado: satisfação do cliente.
Tabela 1. Comparativo das boas práticas das metodologias ágeis.
Boa prática Extreme
Programming Scrum Feature Driven Development Microsoft Solutions Framework Iteração 1 semana 4 semanas 2 semanas 4 semanas
Ciclo incremental Iterativo e incremental Iterativo e incremental Iterativo e incremental Iterativo e
Papéis necessários Gerente de produto Product Owner Especialistas do
domínio Manager Product
Executivo Gerente de projeto Scrum Master Gerente de projeto Program Manager Designer de interação Gerente de desenvolvimento
Arquiteto Arquiteto-chefe Architect
Programador Scrum Team Programadores-chefe Developer Documentador técnico Proprietários da classe Release Manage Testador Tester Usuário User Experience Participação
do cliente Constante Constante Constante Constante Tamanho das
equipes Até 7 pessoas Até 7 pessoas Até 10 pessoas - Etapas da
iteração Exploração
Visão Modelo Geral Envisioning
Planejamento
Lista de Features Planning Backlog do
Compromisso Planejamento do Sprint Planejar por Feature Developing Backlog do
Sprint Projetar por Feature Sprint Direcionamento Release do Produto Contruir por Feature Stabilizing Revisão Retrospectiva Reuniões
Diária (15 min) Diária Início da iteração Semanal Em pé Em pé Ambiente externo Em pé Documentos Estória Backlog do Produto e do Sptint UML e Relatórios de acompanhamento Release
Conclusão
Implantação de uma Metodologia Ágil (ou de partes dela) traz benefícios a equipe e ao projeto como um todo, mas requer cuidados. Este artigo apresentou um overview sobre as quatro principais metodologias ágeis em uso: FDD, MSF, SCRUM e XP.
Cabe, mais uma vez, ressaltar que a implantação de qualquer uma delas requer duas coisas: equipe engajada e cliente participar. Ambos são críticos para o bom andamento dos projetos ágeis e ambos são os pontos mais problemáticos ao tentar o uso eficaz de metodologias ágeis. Logo, mesmo que se consiga achar boas práticas que possam satisfazer suas necessidades, se não houver a “integração” dos mesmos não se terá um desenvolvimento ágil.
Links
Camara, Fabio. “Microsoft Solutions Framework”, DOTNET Magazine: Mini-curso de Ajax, Rio de Janeiro, Edição 42, p. 56-59, 2007.
Camara, Fabio; Martins, José Carlos. “Um cardápio de metodologias ágeis”, DOTNET Magazine: Suas aplicações ASP.NET tem performance?, Rio de Janeiro, Edição 48, p. 26-35, 2008.
Fonseca, Isabella e 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”. http://agilemanifesto.org/principles.html. 2001
Mendes, Marco. “Uma introdução ao MSF - Microsoft Solutions Framework - e por que ele não conflita com o RUP ou CMMI”. Disponível em: blog.marcomendes.com. Acessado em Maio de 2009.
Pressman, Roger S. Engenharia de software, McGraw-Hill, 6ª ed. São Paulo: Pearson, 2006.
Soares, Michel dos Santos. “Metodologias Ágeis Extreme Programming e Scrum para o Desenvolvimento de Software”, Resi: Revista Eletrônica de Sistemas de Informação, nr.19, 2004,
Viana, Mauro. “Conheça o Microsoft Solutions Framework (MSF)”, www.linhadecodigo.com.br/Artigo.aspx?id=78, Acessado em Setembro de 2009.
