Sobre o autor:
Daniel Fonseca Reis – danieeel@globo.com – (31) 9753-3402
Cargo atual: Desenvolvedor .NET
Formação Acadêmica:
- Graduando em Administração de Empresas,
- Estudante de Sistemas para Internet,
- Técnico em Informática Gerencial,
- Recém formado no programa Microsoft Student to Businness (S2B) – Turma DEV.
Este artigo tem como objetivo fazer uma breve descrição conceitual sobre a aplicação de Metodologias Ágeis para Desenvolvimento de Softwares baseados no Microsoft Solutions Framework (MSF).
Introdução
No início da década de 80, criou-se um processo unificado para desenvolvimento de software, que acabou evoluindo para o Rational Unified Process (RUP). Foi realizado um estudo que buscava estudar as características de vários projetos de software que haviam fracassado para tentar identificar as principais causas dos erros e elaborar uma forma padronizada e eficiente para o desenvolvimento de softwares. Com base nisso, e em outros processos de software existentes na época, nasceu o RUP, um conjunto de boas práticas de desenvolvimento de software. Uma das principais idéias do RUP é quebrar o desenvolvimento em várias iterações, cada uma das quais podendo conter atividades de análise de requisitos, projetos, implementações e testes, porém em níveis de atividade diferentes dependendo da fase em que o projeto se encontra e do tamanho real do projeto.
Projetos de Software
Definitivamente cada projeto de software é único devido a uma série de fatores que incluem desde o tipo de aplicação a ser construída, necessidades específicas de cada cliente e até restrições de cronograma e recursos. Desde a versão 3.0 do MSF, existe a esperança por parte de seus criadores de que é impossível definir um único processo de desenvolvimento de software que seja adaptável a qualquer situação. Foi devido a isso que o MSF 4.0 foi lançado em duas versões diferentes, uma que aborda processos ágeis e outra que aborda processos tradicionais. Ainda assim, ainda existe muito em comum entre as duas versões. À medida que as duas forem amadurecendo, a tendência é que a diferença entre elas se torne mais notável.
O MSF 3.0 era composto por quatro elementos básicos: Princípios Fundamentais, Modelo de Processo, Modelo de Equipe e Disciplinas. A análise do MSF 4.0 mostra que este continuou bastante semelhante ao seu predecessor em certos aspectos. Estes incluem os princípios fundamentais, a macroestrutura do Modelo de Processo e a maioria das boas práticas. As maiores modificações ocorreram com a concretização do modelo de equipe e das boas práticas do framework, através do estabelecimento de fluxos de trabalho (workstreams). A seguir, os elementos básicos do MSF Ágil são apresentados em mais detalhes.
Microsoft Solution Framework
O Microsoft Solutions Framework (MSF) surgiu em 1994 como um conjunto de boa práticas coletadas pela Microsoft a partir de sua experiência na produção de software e serviços de consultoria. Desde então, o MSF evoluiu, tornando-se um framework flexível para guiar o desenvolvimento de projetos de software. Como principais características, temos o estabelecimento de papéis bem definidos, a definição e implantação das boas práticas em fluxos de trabalho e atividades.
Ainda sobre o contexto da popularização dos processos ágeis, o MSF foi lançado em duas variações, uma abordando metodologias ágeis e a outra, processos tradicionais (metodologias clássicas). A variação “ágil” do MSF recebeu o nome de “MSF For Agile Software Development”, que será chamado a partir daqui de MSF Ágil por questões de simplicidade.
Mindsets – Um mindset é uma coleção de valores que determina como as pessoas envolvidas irão interpretar e reagir às situações do cotidiano de um desenvolvimento de software. Os mindsets devem estar na mente de cada membro da equipe desde o início do projeto até o seu final. Existem oito mindsets no MSF, que estão detalhados abaixo.
1. Qualidade definida pelo cliente - Clientes parceiros e satisfeitos são a prioridade de uma boa equipe e de um bom projeto de software. Focar no cliente durante o desenvolvimento significa um compromisso da equipe em relação à compreensão e resolução dos problemas, pois, uma vez que o problema de negócio foi compreendido, o envolvimento do cliente precisa ser maximizado até um grau que garanta o alinhamento das expectativas deste com o projeto.
2. Orgulho no trabalho individual – Sentir orgulho em contribuir para um projeto é importante na criação de um produto de qualidade, onde motivação e senso de responsabilidade são conseqüências notáveis desta prática.
3. Equipe em pares – Apesar de não ser apreciada pela maioria dos programadores, ao estabelecer valor igual para cada grupo de papéis do modelo de equipe, é necessário que haja comunicação irrestrita entre os papéis, transparência e um conjunto único e visível de pendências. O resultado é um aumento na prestação de contas da equipe e uma comunicação efetiva.
4. Entrega Freqüente de Versões – Com o principal objetivo de estabelecer credibilidade, nada pode ser melhor do que uma entrega freqüente do produto funcionando, mesmo que com apenas parte de suas funcionalidades, pois, além de ter um produto cada dia mais próximo de ser entregue em definitivo, responder às necessidades dos clientes com pequenas versões de qualidade mostrará progresso e comprometimento. Através da entrega de versões freqüentes, o processo e a infra-estrutura são provados e melhorados. Riscos, defeitos e requisitos não-detectados são percebidos com antecedência. Assim, o feedback pode ser dado sempre que necessário.
5. Desejo de aprender – Os membros das equipes podem focar em melhorias pessoais, coletando e compartilhando o conhecimento e as lições aprendidas no dia a dia. Além disso, existirão oportunidades para implementar práticas comprovadas por outros e reservar tempo do cronograma para a aprendizagem e estudos.
6. Tornar-se específico cedo – Vários projetos perdem tempo em busca de soluções genéricas ao invés de lidar com problemas solucionáveis. Este mindset ressalta a necessidade de dar um passo de cada vez, aprendendo do específico ao invés do abstrato.
7. Qualidade de Serviço – Este mindset acompanha a solução do projeto e desenvolve planos baseados em cada aspecto da experiência do cliente. A idéia é que qualidades de serviço como performance e segurança não podem ser consideradas no final do projeto, mas através dele como um todo.
8. Cidadania - Foca no controle de recursos do projeto, corporativos e computacionais. A cidadania pode ser considerada de várias formas, desde a condução do projeto de uma maneira eficiente até a otimização do uso de webservices.
Princípios do Microsoft Solutions Framework para Desenvolvimento Ágil de Softwares
Para uma melhor compreensão, foram definidos 7 (sete) princípios do Microsoft Solutions Framework (MSF) para Desenvolvimento Ágil de Softwares, sendo eles:
1. Parceria com o cliente – Aprovação, acompanhamento e consideração por parte do cliente é a diferença entre valor de negócio real e fictício. Entender a proposta de valor da sua solução e comunicá-la efetivamente é um atributo chave de sucesso.
2. Trabalho em direção a uma visão compartilhada – Uma visão compartilhada garante que todos os membros da equipe enxerguem os objetivos do projeto sob uma mesma ótica.
3. Qualidade é trabalho de todos - Qualidade requer tanto prevenção de “bugs/problemas” quanto verificação de possíveis soluções. Análise de código e revisões em pares são utilizadas para realizar estas duas tarefas. Todos os papéis são responsáveis pela prevenção e verificação dos problemas.
4. Manter-se ágil, adaptar-se às mudanças - Quanto mais uma organização procura maximizar o impacto no negócio de um investimento em tecnologia, mais ela descobre novos ambientes e desafios. Estes ambientes estão sempre sujeitos a mudanças e a experimentação resulta em novas descobertas, que podem ou não serem aplicados no projeto.
5. Encorajar comunicação aberta - Para maximizar a efetividade individual dos membros da equipe, a informação precisa estar prontamente disponível para que assim seja constantemente compartilhada.
6. Faça da implantação um hábito – A equipe deve estar comprometida em criar um produto de qualidade, inclusive enquanto realiza mudanças e atualizaçãoes. Cada mudança deve ser feita com a certeza de que o produto deve estar pronto para ser implantado a qualquer hora.
7. Fluxo de valor - Planejamento, execução e medição do progresso e velocidade devem ser baseados na entrega de valor de negócio sempre agregando valor para o cliente. Atividades que não agregam valor de negócio devem ser minimizadas e deixadas como segundo plano para o projeto.
