Este artigo aborda características da engenharia de software, algumas práticas de gestão e exemplos que você pode aplicar no Visual Studio tendo como foco principal o uso de abordagens ágeis. Assim, discutiremos os mecanismos que o Visual Studio (principalmente o Team Foundation Server) oferece para apoiar a equipe a seguir um processo Scrum definido para o projeto.
Em que situação o tema útil:
O assunto discutido neste artigo é útil para todos que estão envolvidos em atividades de desenvolvimento de software e têm interesse em conhecer como o Scrum pode ser apoiado pelo uso do Visual Studio durante o desenvolvimento do projeto.
Resumo DevMan:
Este artigo irá discutir como o Visual Studio e o Team Foundation Server apoiam o uso de práticas ágeis em projetos de software. Para isso, veremos que a Microsoft disponibiliza três modelos de processos com o TFS: Scrum, MSF para Agile Software Development e MSF for CMMI Process Improvement.
No centro de todos os processos veremos que existe a ideia de trabalho em ciclos aninhados: check-in, teste, sprint e release. Cada ciclo tem a sua própria definição de finalizado reforçado com ferramentas no TFS.
Por fim, de forma consistente com o Scrum, veremos que é importante inspecionar e adaptar não apenas o software, mas também o próprio processo. O TFS oferece um editor de modelo de processos para adaptar o processo às necessidades do projeto.
A maioria dos novos projetos de software é complexa. Mas como lidar com esta complexidade em tempos em que cada vez mais se exige qualidade e menor prazo de desenvolvimento?
Em busca de respostas para esta pergunta, este artigo aborda características da engenharia de software, algumas práticas de gestão e exemplos que você pode aplicar no Visual Studio (VS). Assim, discutiremos os mecanismos que o VS (principalmente o Team Foundation Server - TFS) oferece para apoiar a equipe a seguir um processo definido para o projeto.
O Visual Studio e o processo de desenvolvimento
O Visual Studio nos apoia a seguir um processo de desenvolvimento através de três alternativas:
1. O TFS permite a identificação de atrasos, fluxos de trabalho, status do projeto e algumas métricas de acompanhamento. Juntas, estas informações mantêm o trabalho transparente e orientam a equipe de desenvolvimento a seguir as próximas ações de forma apropriada.
2. Cada equipe de projeto controlada pelo TFS começa com um modelo de processo que define os procedimentos-padrão, relatórios, papéis e artefatos para o processo. Estes são muitas vezes alterados posteriormente no decorrer do projeto à medida que a equipe aprende e ajusta seu processo, mas seus padrões iniciais são definidos de acordo com o modelo de processo escolhido.
3. Nos clientes VS ou Eclipse, existem experiências de usuários que interagem com o servidor para garantir que as políticas sejam seguidas e que os avisos de violações de políticas definidas no processo sejam fáceis de serem entendidas.
Modelos de processos
O modelo de processo suporta o fluxo de trabalho da equipe definindo os tipos de itens de trabalho padrão, relatórios, consultas, os papéis, portal de equipe e artefatos. Os tipos de item de trabalho são o elemento mais visível dos mencionados acima uma vez que eles determinam as informações que os membros da equipe irão usar para gerenciar o backlog, selecionar o trabalho e registrar o status do projeto.
Quando um membro da equipe cria um projeto, o assistente de criação de projeto solicita que você escolha um modelo de processo como mostrado na Figura 1.
Figura 1. Assistente de criação de projeto.
A Microsoft disponibiliza três modelos de processo padrão:
· Scrum: esse modelo de processo suporta diretamente o Scrum e foi desenvolvido em colaboração com Ken Schwaber baseado no Guia Scrum. O modelo de processo Scrum define itens de trabalho para o Product Backlog, Bug, Tarefa, Impedimento, Caso de Teste e Sprint. Os relatórios disponíveis neste processo são Release Burndown, Sprint Burndown e Velocity.
· MSF for Agile Software Development: este processo também é definido tendo o Scrum como base, mas incorpora um conjunto mais amplo de artefatos que o modelo de processo Scrum. No MSF Agile, itens do backlog do produto são chamados de histórias de usuário e impedimentos são chamados de problemas.
· MSF for CMMI Process Improvement: este modelo de processo também é projetado para práticas iterativas de desenvolvimento, mas com mais formalidade do que os outros modelos. Ele foi projetado para facilitar o trabalho de uma equipe Capability Maturity Model Integration (CMMI) nível 3, tal como definido pelo Software Engineering Institute. Com isto, este modelo de processo estende o MSF Agile com um planejamento mais formal, mais documentação e produtos de trabalho e mais tempo de monitoramento. Notadamente, esse modelo de processo adiciona atividades de solicitação de mudança, acrescenta tipos de risco de item de trabalho e usa um modelo para espeficicação dos requisitos que é mais elaborado do que as histórias de usuários do MSF Agile.
Outras empresas fornecem seus modelos de processos próprios e podem ter estes certificados pela Microsoft. Por exemplo, a Sogeti lançou uma versão da sua abordagem de Gerenciamento de Teste ( ...
