Processos Ágeis para desenvolvimento de Software – Parte 04

Processos Ágeis para desenvolvimento de Software – Parte 04

4.3. Modelo de Equipe

O Modelo de Equipe do MSF tem por objetivo definir os papéis e responsabilidades das pessoas que estarão envolvidas em um projeto. Uma característica do referido modelo é que o mesmo prega a formação de uma equipe o mais horizontal possível, isto é, não com uma organização hierárquica top-down tradicional, mas um modelo para uma equipe colaborativa com responsabilidades compartilhadas. Subjacente ao modelo está o conceito de que qualquer projeto de software, para ser considerado bem sucedido, deve satisfazer a alguns objetivos chave de qualidade.

Assim, o Modelo de Equipe do MSF define cada um de seus papéis baseado na necessidade de adequação a um objetivo de qualidade conforme a tabela 1.

Para atingir tais objetivos, cada grupo de papéis, que são denominados pela metodologia de grupos de defesa de interesses, deve atuar em um conjunto de áreas funcionais com responsabilidades associadas.

Tabela 1 - Grupos de papéis do MSF e objetivos chaves de qualidade

Além dos grupos de defesa, o Modelo de Equipe também prescreve uma maneira de se adequar à escala necessária para um projeto específico. Integrantes podem representar mais de um grupo (acumulando papéis), ou um papel pode ser representado por mais de uma pessoa para atender a projetos de tamanhos pequenos e grandes, respectivamente. Existem no MSF Ágil sete grupos de defesa. Eles estão ilustrados na Figura 2, que mostra a relação entre cada grupo e os papéis associados.

Figura 2 – Grupos e papéis no MSF Ágil

4.3.1. Papeis e responsabilidades. Para uma melhor compreensão deste modelo de equipe será necessário descrever as responsabilidades de cada grupo e algumas características de seus integrantes.

4.3.1.1. Gerência de programa. O foco da gerência de programa é atender ao objetivo de concluir e entregar o projeto dentro dos prazos e custos estimados, gerando valor de negócio para o cliente. Este grupo também deve garantir que a solução certa é entregue ao tempo certo, e que todas as expectativas de todos os stakeholdes sejam entendidas, gerenciadas e atendidas durante o projeto.

Gerente de projeto: O principal objetivo do gerente de projeto é garantir a entrega de valor de negócio dentro do cronograma e orçamento acertados. O gerente de projeto é encarregado dos trabalhos de planejamento e definição de cronograma, incluindo o desenvolvimento do projeto e planos de iteração.

4.3.1.2. Arquitetura. A arquitetura defende os interesses do sistema em uma visão mais ampla. Isso inclui os serviços técnicos e não-técnicos com os quais a solução irá operar a infra-estrutura onde ela será implantada, seu lugar no negócio ou na família de produtos e seu plano de versões futuras. O grupo da arquitetura precisa garantir que a solução implantada irá atender a todas as qualidades de serviço e objetivos de negócio, e ainda ser viável em longo prazo.

Arquiteto: O arquiteto é responsável por garantir o sucesso do projeto através do projeto dos aspectos fundamentais da aplicação. Isto inclui definir a estrutura organizacional da aplicação e a estrutura física de sua implantação. Nestas tarefas, o objetivo do arquiteto é reduzir a complexidade através da divisão do sistema em partições claras e simples.

4.3.1.3. Desenvolvimento. O Desenvolvimento defende a solução técnica. Além de ser responsável pela criação primária de soluções, o desenvolvimento também é encarregado de decisões técnicas importantes, um design limpo, boas estimativas, código de qualidade e de fácil manutenção e testes unitários.

Desenvolvedor: Este papel tem como principal objetivo a implementação da aplicação conforme sua especificação e dentro do tempo estimado. Do desenvolvedor também se espera ajuda na especificação de características do projeto físico, estimativa de tempo e esforço para a finalização de cada característica, preparação do produto para a implantação e atuação como consultor de tecnologia para o restante da equipe.

4.3.1.4. Teste. Este grupo prevê, procura e reporta qualquer problema que pode diminuir a qualidade da solução aos olhos dos clientes e usuários.

Analista de testes: O principal objetivo do analista de testes é a descoberta e o relato de problemas que afetem o produto e que possam vir a prejudicar o valor de negócio deste. O analista precisa entender o contexto do projeto, e ajudar os outros a tomar decisões informadas, baseadas neste contexto. Um objetivo chave do analista de testes é a descoberta e relato de defeitos significativos no produto através da execução de testes sobre o mesmo.

4.3.1.5. Operações de release. Esse grupo garante a disponibilidade a tempo e a compatibilidade da infra-estrutura para a solução.

Gerente de release: Garante que o produto está pronto para entrar na fase de implantação e gerencia a mesma.  Para isto, cria planos e cronogramas e certifica as versões candidatas a versão final.

4.3.1.6. Experiência do usuário. Este grupo de defesa deve entender o contexto dos usuários como um todo, incluindo toda e qualquer sutileza de suas necessidades, além disso, garantir que toda a equipe está consciente da usabilidade de acordo com sua visão.

Analista de negócio: O principal objetivo deste papel é definir uma oportunidade de negócio e a aplicação que servirá a esta. O analista de negócio trabalha com os clientes e outros participantes a fim de entender suas necessidades e objetivos, e traduz estas em definições de personas (Uma persona é a descrição das capacidades necessidades, desejos, hábitos de trabalho, tarefas, e background de um conjunto particular de usuários. Uma persona é a coleção de dados que descreve características importantes sobre a interação de um grupo particular de usuários com o sistema, condensados em um papel fictício.), cenários e requisitos de qualidade de serviço que a equipe de desenvolvimento usará para construir a aplicação. Vale à pena ressaltar que o Analista de Negócios toma o lugar do Analista de Sistemas neste modelo.

4.3.1.7. Gerência de produto. A gerência de produto tem o dever de entender, comunicar e garantir o sucesso do ponto de vista econômico do cliente requisitando a solução.

O único papel integrante deste grupo é o Analista de Negócio, que foi descrito na subseção anterior.

4.4. Escalando para projetos pequenos.

Em projetos de pequeno porte, ou projetos de baixa complexidade, uma pessoa pode atuar em vários papéis. Quando se combina papéis, é importante preservar o equilíbrio provido pelos diferentes grupos de defesa de interesses.

4.5. Fluxos e itens de trabalho

O MSF 4.0 de maneira geral defende a concretização das metodologias através do estabelecimento de fluxos de trabalho. Estes são grupos de atividades associadas a um ou mais papéis do Modelo de Equipe, cujo objetivo é guiar a execução de tarefas específicas durante a execução do projeto. Cada fluxo de trabalho é constituído por: uma visão geral, que determina o principal objetivo a ser atingido pelo fluxo; critérios de entrada, que explicitam dependências em relação a outras atividades, assim como determinam quando o fluxo será realizado; uma seqüência de atividades a serem executadas; critérios de saída, que deixam claras as pós-condições a serem satisfeitas após o término do fluxo; um conjunto de papéis envolvidos que deixa claro quais os membros da equipe estarão envolvidos durante o fluxo, e em que nível este envolvimento se dá.

Além dos fluxos, o MSF Ágil introduziu os itens de trabalho (work items), os quais correspondem a artefatos que sofrem alterações durante o processo de desenvolvimento como resultado da evolução natural do projeto. Os sete itens de trabalho cujos modelos são fornecidos pelo MSF Ágil são: tarefa, solicitação de mudança, risco, revisão, requisito, defeito e ocorrência.

4.5.1. Tarefa. É uma indicação da necessidade de realização de trabalho por parte de algum membro da equipe (escrever um caso de teste, desenvolver código a partir de um cenário, dentre outros).

4.5.2. Solicitações de mudança. É necessária quando a modificação de qualquer item que integre um baseline do projeto e deve ser analisada pelo comitê de controle de mudança (change control board) a fim de ser rejeitada ou aprovada.

4.5.3. Risco. Documenta uma condição ou evento provável que pode ter efeitos negativos para o projeto. É parte essencial do processo de gerenciamento do projeto identificar e gerenciar os riscos inerentes ao projeto.

4.5.4. Revisão.  Documenta os resultados de uma revisão de código ou de modelo. Deve trazer os dados a respeito dos padrões utilizados pra codificar correção de nomes, relevância, complexidade algorítmica e segurança.

4.5.5. Requisito.  Captura o que o produto precisa ter para satisfazer as necessidades do cliente. Existem vários tipos de requisitos: cenários, qualidade de serviço, funcionais, operacionais e de interface. Este talvez seja o item de trabalho cuja presença é a mais importante durante o ciclo de desenvolvimento, já que é capturado nas fases iniciais e guia as atividades de análise e projeto, codificação e testes.

4.5.6. Defeito. Comunica que um problema potencial existe no produto. Sua descrição deve conter em que contexto o defeito foi encontrado, de maneira que este seja facilmente reproduzido, facilitando sua resolução.

4.5.7. Ocorrência. Documenta um evento ou situação que tem a possibilidade de bloquear o andamento do projeto. Diferem dos riscos por serem identificadas de forma espontânea em reuniões de equipe. Uma vez identificadas, são geradas tarefas que, quando completadas com sucesso, implicam a finalização da ocorrência.

5. Conclusão

O MSF Agile consiste em um conjunto de mindsets, princípios, um modelo de equipe e uma série de fluxos de trabalho. Os mindsets estão para o MSF assim como os valores estão para XP: são objetivos abstratos, que devem tentar ser seguidos, independente do projeto e representam a filosofia da metodologia.

O MSF Agile apresenta uma série de princípios, que são uma concretização dos mindsets.

Os fluxos de trabalho consistem em um conjunto detalhado de atividades e sub-atividades que devem ser realizadas pela equipe do projeto. Eles são o que mais se assemelham com as práticas de XP, mas há uma diferença conceitual grande entre eles: os fluxos de trabalho são bastante concretos, e as atividades de cada um deles são descritas com muitos detalhes, enquanto as práticas de XP são ainda um pouco abstratas e sujeitas à interpretação de quem as emprega.

Por fim o modelo de equipe define os papéis participantes da equipe. O MSF Agile possui diversas características ágeis, como iterações curtas e respostas rápidas às mudanças.

6. Referências

Manifesto for agile software development. Disponível em http://agilemanifesto.org. Acessado em 02/11/2007.

Microsoft. MSF For Agile Software Development. Disponível em: http://msdn2.microsoft.com/en-us/teamsystem/default.aspx Acessado em: 02/11/2007.

MSF for Agile Software Development Process Guidance

Extreme Programming: A gentle introduction. Disponível em: http://www.extremeprogramming.org. Acessado em: 04/11/2007

Scrum Alliance – Resources. Disponível em: http://www.scrumalliance.org/resources. Acessado em: 04/11/2007.

XP@Scrum. Disponível em:

http://controlchaos.com/about/xp.php.Acessado em: 04/11/2007

Câmara, Fábio. VSTS Rocks Team. Visual Books – 2006.