Processos Ágeis para desenvolvimento de Software – Parte 03
4. MSF Agile Software Development 4.0
Por mais semelhanças que um projeto possa ter em relação a outros, 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.
Já existe desde o MSF 3.0, a consciência 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. O MSF 4.0 sustenta os seguintes elementos básicos: Princípios Fundamentais, Modelo de Processo, Modelo de Equipe e Disciplinas.
A seguir, os elementos básicos do MSF Ágil são apresentados em mais detalhes.
4.1. Mindsets
O MSF Ágil é muito mais do que um conjunto de atividades a serem seguidas. Ele busca a criação de uma cultura que encorage projetos bem sucedidos. Um mindset é uma coleção de valores que determina como os indivíduos irão interpretar e reagir às situações. Mindsets devem estar na mente de cada membro da equipe desde o início do projeto até o seu final quando da tomada de decisões, priorização de trabalho, representação do seu grupo de papéis e interação dos membros da equipe com outros participantes. Existem oito mindsets no MSF, que estão detalhados abaixo.
4.1.1. Qualidade é definida pelo cliente. Clientes satisfeitos são prioridade primordial de uma boa equipe. Esta satisfação inclui clientes internos e externos. Focar no cliente durante o desenvolvimento significa um compromisso da equipe em relação a compreensão e resolução dos problemas de negócio do mesmo. 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.
4.1.2. Orgulho do trabalho individual. Sentir orgulho em contribuir para uma solução é importante na criação de um produto de qualidade. Motivação e senso de responsabilidade são produtos diretos deste orgulho. Criar um orgulho focado nas habilidades individuais é uma responsabilidade tanto do indivíduo quanto da organização.
4.1.2. Equipe de parceiros. O mindset “equipe de parceiros” estabelece 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.1.3. Entrega Freqüente de Versões. Nada consegue ser mais efetivo para estabelecer credibilidade do que uma entrega freqüente do produto. Ainda que tiver um produto cada dia mais próximo de ser entregue em definitivo seja importante, responder às necessidades dos clientes com pequenas versões de qualidade mostrará progresso. Através da entrega de versões freqüentes, a infra-estrutura e o processo são provados e melhorados. Riscos, defeitos e requisitos não-detectados são percebidos mais cedo. Assim, o feedback pode ser dado quando necessário.
Entrega freqüente de versões é um mindset que estimula a disciplina em uma equipe de desenvolvimento de software.
4.1.4. Desejo de aprender. Uma vez que todo projeto de desenvolvimento, ambiente e time são únicos, cada projeto e iteração criam uma oportunidade de prendizado. Entretanto, não pode haver aprendizado sem um feedback honesto e reflexão. A não ser que haja um ambiente que dê suporte e estimule a coragem e a segurança pessoal, o feedback será limitado e não contribuirá para o engrandecimento. Postos estes fatores, indivíduos e equipes podem focar em melhorias pessoais, coletando e compartilhando o conhecimento e as lições aprendidas.
Adicionalmente, existirão oportunidades para implementar práticas comprovadas por outros e reservar tempo do cronograma para a aprendizagem. Técnicas para gerar o feedback necessário para o princípio do desejo de aprender incluem revisão por companheiros e análises retrospectivas.
4.1.5. Tornar-se específico cedo. Muitos 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. Definir o projeto em termos cotidianos é a chave para construção efetiva de código que funcione de modo a satisfazer os testes e criar um produto pronto para ser entregue.
4.1.6. Qualidade de Serviço. O mindset qualidade de serviço observa a solução 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 devem ser consideradas tardiamente no projeto, mas através dele como um todo. Quando ignorados, estas qualidades de serviço são geradoras de insatisfação dos clientes e são usualmente fruto de considerações implícitas sobre como a solução vai se comportar. Com este mindset, a solução é contemplada como um todo e considerações implícitas se transformam em requisitos de qualidade de serviço.
Técnicas que suportam este mindset incluem usar o conhecimento de um especialista quando se necessita e descobrir riscos o mais cedo possível.
4.1.7. Cidadania. O mindset cidadania foca no controle de recursos do projeto, corporativos e computacionais. A cidadania se manifesta de várias formas, desde a condução do projeto de uma maneira eficiente até a otimização do uso de web services.
Técnicas que suportam o mindset cidadania incluem: realocação de defeitos com toda a informação necessária para que outra pessoa possa começar bem e prover boas estimativas da quantidade de trabalho que uma tarefa de desenvolvimento ou de teste irá tomar.
4.2. Princípios
4.2.1. Parceria com clientes. Validação pelo cliente é comumente 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 fator chave de sucesso.
4.2.2. Encorajar comunicação aberta. Para maximizar a efetividade individual dos integrantes, a informação precisa estar prontamente disponível ser ativamente compartilhada no time.
4.2.3. Trabalho em direção a uma visão compartilhada. Visão compartilhada garante que todos os membros do time enxergam os objetivos que eles pretendem alcançar com o projeto sob uma mesma ótica.
A colaboração é aprimorada, porque as decisões do projeto não são tomadas para atender as vontades de um indivíduo e sim para atender a um objetivo que é visto e aceito por todos.
4.2.4. Qualidade é trabalho de todos, todo dia. Qualidade requer tanto prevenção de bugs quanto verificação de 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 por prevenção e verificação de bugs.
4.2.5. Manter-se ágil, adaptar-se a mudança. Quanto mais uma organização procura maximizar o impacto no negócio de um investimento em tecnologia, mais ela adentra novos territórios. Este novo território é inerentemente incerto e sujeito a mudança, uma vez que exploração e experimentação resultam em novas necessidades e métodos. Exigir certeza num ambiente em processo de mudança e um objetivo não realista, e leva a resultados falhos.
4.2.6. Faça da implantação um hábito. O time deve se comprometer a estar criando um produto de excelência, mesmo enquanto realiza mudanças nele. Cada mudança deve ser feita sob a convicção de que o produto deve estar pronto para ser implantado a qualquer hora. Projete o sistema para ser implantado, e pratique sua implantação num ambiente de desenvolvimento.
Desenvolvedores devem estar constantemente executando o produto, e o cliente deve estar sempre testando ou liberando as novas versões.
4.2.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 crescente para o cliente, e de um retorno de investimento também crescente. Atividades que não agregam valor de negócio devem ser minimizadas, pois são desperdício.
Iterações devem ser usadas para manter uma cadência de produtos atualizados que o cliente possa estar sempre avaliando.
Figura 1 – Esquema de iterações do MSF Ágil
