Maior Previsibilidade com o Visual Studio Team System 2008 White Paper Maio de 2008 Para obter as últimas informações, visite o site www.microsoft.com/teamsystem
As informações contidas neste documento representam a visão atual da Microsoft Corporation sobre os temas discutidos na data da publicação. Como a Microsoft deve responder às mudanças das condições de mercado, este documento não deve ser interpretado como um compromisso da parte da Microsoft, e a Microsoft não pode assegurar a exatidão de qualquer informação apresentada após a data da publicação. Este white paper destina-se a fins informativos apenas. A MICROSOFT NÃO FORNECE NENHUMA GARANTIA, EXPRESSA, IMPLÍCITA ou ESTATUTÁRIA, QUANTO ÀS INFORMAÇÕES NESTE DOCUMENTO. O cumprimento de todas as leis pertinentes de direitos autorais é de responsabilidade do usuário. Sem limitar os direitos sob o direito autoral, nenhuma parte deste documento pode ser reproduzida, armazenada em, ou inserida em um sistema de recuperação de dados, ou transmitido de qualquer forma ou por qualquer meio (eletrônico, mecânico, fotocópia, gravação ou outro) ou para qualquer fim, sem a permissão expressa por escrito da Microsoft Corporation. A Microsoft pode deter as patentes, as solicitações de patentes, as marcas comerciais, os direitos autorais ou outras propriedades intelectuais pertinentes ao objeto deste documento. Salvo expressamente disposto em qualquer contrato de licença escrito da Microsoft, o fornecimento deste documento não confere a você qualquer licença em relação a essas patentes, marcas comerciais, direitos autorais ou outras propriedades intelectuais. 2008 Microsoft Corporation. Todos os direitos reservados. Microsoft, Visual Studio e SharePoint são marcas registradas do grupo de empresas da Microsoft Todas as outras marcas registradas são propriedade de seus respectivos proprietários
SUMÁRIO Introdução... 1 Processo... 2 Recursos... 4 Como evitar surpresas... Error! Bookmark not defined. Estimativas... 9 Conclusão... 10 Sobre o autor... 11
INTRODUÇÃO A previsibilidade oferece vantagens em todas as áreas da empresa para o benefício de todos. As organizações raramente crescem em ambientes completamente caóticos. Isso é especialmente verdade no desenvolvimento de software. Imagine um novo desenvolvedor ser contratado para um projeto sem saber o que deve fazer, como deve fazer e sem ter a menor idéia de onde obter essas informações. A solução para esse problema costuma ser sente-se com outro desenvolvedor por algum dia para aprender. Essa situação está longe de ser a ideal. Ou que tal tentar solicitar mais recursos para um projeto? Apenas obter recursos adicionais não ajudará um projeto se você não souber onde aplicar o recurso ou as habilidades exigidas pelo recurso. Ao entender as situações atuais e desenvolver tendências, você pode planejar o futuro e evitar possíveis problemas. Evitar surpresas é o principal benefício da previsibilidade. Em diversas ocasiões, as equipes de desenvolvimento trabalham a noite toda nas semanas anteriores à entrega porque não sabem a quantidade de trabalho a ser feita. Geralmente, é necessário um esforço heróico para finalizar o software no prazo a quase sempre a qualidade é prejudicada. O Microsoft Visual Studio Team System 2008 oferece a capacidade de facilitar a colaboração entre os participantes e também evita surpresas. Ao usar o Team System como uma ferramenta de comunicação, todos ficam cientes dos problemas. O Team System ajuda a atingir o sucesso ao possibilitar processos consistentes e previsíveis. Ele ajuda a exportar tendências nos projetos de desenvolvimento, o que permite às equipes concentrar recursos e gerenciar os riscos (que poderiam não estar aparentes) de maneira ativa (e preemptiva). Sem a capacidade de voltar e ver de modo claro e fácil os detalhes do projeto, muitos problemas passam despercebidos mas isso não acontece com o Team System. A previsibilidade no processo de desenvolvimento de software leva à diminuição dos custos de desenvolvimento de software e em um retorno do investimento maior. White Paper: Obtenha Previsibilidade com o Visual Studio Team System2008 1
PROCESSO Muitas empresas ouvem a palavra processo e automaticamente adotam uma estrutura monolítica que deve ser seguida por todos. E isso fez com que muitos projetos fracassassem. Você pode achar essa visão estranha enquanto não observar que alguém no meio do processo ficou atolado em um monte de papéis quase como se o software estivesse em segundo plano. Existem documentos que explicam como fazer seu trabalho, quais são as etapas do ciclo de vida de desenvolvimento do software, a quem você deve se reportar, por quem você é responsável e que, por fim, controlam tudo o que vocês faz e o tempo que você leva para fazer aquilo. Conforme mencionamos antes, uma nova contratação é uma boa idéia. As empresas podem gastar muito tempo e dinheiro contratando pessoas e às vezes leva semanas até que essas pessoas façam algo produtivo. O Team System ajuda você a resolver esses problemas por meio do uso de modelos de processo. Um modelo de processo contém documentos relevantes para a equipe de desenvolvimento. Por padrão, um modelo de processo inclui uma lista de funções, responsabilidades, modelos de documentos, um site configurado do Microsoft SharePoint conhecido como Team Portal e relatórios padrão. Esses modelos podem ser adicionados por meio da inclusão em outros documentos, links e configurações personalizadas. Quando um desenvolvedor não sabe o que fazer, o Team Portal é o único local que pode informar tudo o que ele precisa saber. Além disso, seu processo de desenvolvimento é integrado às atividades diárias da equipe de desenvolvimento por meio do modelo de processo até ficar enraizado. Os itens de trabalho (formulários de monitoramento do projeto com informações de registro) são integrados como parte do modelo de processo e contêm as informações necessárias para que o desenvolvedor trabalhe, comunique-se e colabore com outras pessoas da equipe de desenvolvimento. Você pode personalizar os itens de trabalho para registrar as informações de que precisa para ajudar você a refinar seu próprio processo. Muitas equipes de projeto trabalham de maneiras diferentes, embora estejam na mesma empresa. As equipes podem usar um processo de desenvolvimento de software que varia entre os projetos. Com o Team System, não é necessário que todos usem o mesmo processo mas todos podem usar as mesmas ferramentas. Os membros da equipe podem personalizar cada projeto do Team System para usar apenas o que a equipe do projeto julga necessário. Isso economiza muito trabalho e treinamento desnecessários à medida que os desenvolvedores passam de um projeto para outro. O Team System inclui dois modelos de processo internos para ajudar as equipes a começar. São eles: Microsoft Solutions Framework (MSF) for CMMI Process Improvement e MSF for Agile Software Development. Os dois modelos podem ser úteis para equipes com pouca ou nenhuma experiência no processo. Para equipes mais maduras, os modelos de processo White Paper: Obtenha Previsibilidade com o Visual Studio Team System2008 2
oferecem uma plataforma para personalizar rapidamente um processo para as necessidades específicas da equipe. Explicarei esses modelos nas próximas seções. MSF for CMMI Process Improvement 4.2 O modelo CMMI/PI é certificado pelo Software Engineering Institute Capability Maturity Model (SEI-CMM) por fornecer os processos necessários para atender à classificação Nível 3 do CMMI. Basicamente, isso significa que se você usar o Microsoft Solutions Framework for CMMI Process, junto com o modelo de processo, terá um processo padrão e que se repetirá para realizar o desenvolvimento de software. MSF for Agile Software Development 4.2 O modelo ágil é um modelo leve, que tem estados e itens de trabalho simplificados em comparação com o modelo CMMI/PI. A terminologia corresponde com a usada por equipes ágeis assim como o processo adotado por essas equipes. Esse processo inclui testes de unidades, compilações freqüentes e breves iterações características de um processo ágil. O uso de um processo ágil permite à equipe reagir às mudanças de maneira mais rápida e focar primeiro na qualidade. Diferenças entre os modelos ágil e CMMI O modelo CMMI/PI oferece vários recursos que o modelo ágil não tem. Ele fornece um estado proposto, que é o estado inicial de todos os itens de trabalho novos. Também oferece alguns relatórios adicionais sobre o modelo ágil. Por fim, o modelo CMMI/PI apresenta um tipo de item de trabalho Solicitação de Alteração, que permite usar o Team System como uma ferramenta de gerenciamento de alterações. Os itens de trabalho apresentam algumas diferenças no que se refere às informações capturadas por cada modelo. Além disso, o modelo CMMI/PI usa um item de trabalho Requirements (Requisitos) em vez de um item de trabalho Scenario (Cenário) para capturar os requisitos, uma vez que o desenvolvimento ágil usa User Stories (Histórias do Usuário) em vez da documentação mais detalhada que costuma ser encontrada em um projeto formal. Com o Team System, no entanto, independentemente do modelo usado, a ferramenta funciona do mesmo jeito. White Paper: Obtenha Previsibilidade com o Visual Studio Team System2008 3
RECURSOS Você já teve dificuldades em um projeto? Talvez as coisas não estejam sendo feitas tão rapidamente quanto deveriam ou os clientes estejam insatisfeitos com o software que estão recebendo. Muitos problemas podem se materializar durante o processo de desenvolvimento de software. Você poderia resolver esses problemas contratando mais recursos. Mas que tipo de recurso? Você precisa de mais desenvolvedores ou de mais testers? Que tal mais participação de usuários ou uma máquina de compilação mais rápida? Talvez você precise de um desenvolvedor independente para auditor o código da sua equipe. Muitas equipes têm problemas de recursos e não sabem como resolvê-los. O Team System pode ajudá-lo a prever onde e quando você precisará de recursos. É aqui que os relatórios do Team System realmente têm um impacto no processo de desenvolvimento. Talvez você tenha uma situação em que seus desenvolvedores escrevam o código rapidamente, mas o Controle de Qualidade não consiga revisar o código com a mesma rapidez. Como saber isso? O Team System tem a solução basta executar o relatório Remaining Work (Trabalho Restante) para obter uma visualização instantânea da quantidade de trabalho que está em desenvolvimento no momento, o que está pronto para teste e quanto teste foi realizado (Figura 1). Figura 1. Relatório Remaining Work White Paper: Obtenha Previsibilidade com o Visual Studio Team System2008 4
Esse relatório ajuda você a determinar se precisa de mais desenvolvedores ou testers. Se o número de itens que ainda não foram concluídos não estiver diminuindo (área vermelha na Figura 1), serão necessários mais desenvolvedores do que testers. Mas se o número de itens restantes cair e o número de itens para teste subir (como na Figura 1 a área amarela), você precisará de mais testers. Esse é um exemplo simples e direto de como os relatórios do Team System podem ajudar a equipe. E se houver uma situação mais difícil? E se os requisitos não estiverem sendo concluídos com bastante rapidez para dar à equipe de desenvolvimento trabalho suficiente? Conseguir fazer com que o tempo dos usuários esteja sincronizado com o da equipe de desenvolvimento pode ser difícil nas melhores circunstâncias, mas tentar provar que eles são o gargalo é quase impossível. Ao usar uma combinação de relatórios no Team System, você pode mostrar quantos requisitos estão sendo concluídos e o número de requisitos gerais para o projeto, bem como o estágio em que eles estão. Essas métricas simples podem oferecer a prova definitiva de uma necessidade sem que as equipes tenham um trabalho intenso para coletar essas informações. White Paper: Obtenha Previsibilidade com o Visual Studio Team System2008 5
COMO EVITAR SURPRESAS O Team System oferece algumas ferramentas exclusivas e prédesenvolvidas que ajudarão as equipes a evitar muitas das surpresas típicas que historicamente destroem um projeto. Muitas equipes costumam ser pegas de surpresa pela quantidade de trabalho a ser terminado à medida que a data do lançamento se aproxima. Orçamentos são cortados, datas de lançamento são postergadas, escopo aumenta, desenvolvedores são subestimados ou outras coisas acontecem, causando problemas de última hora. Na verdade, a maioria das equipes de desenvolvimento trabalha à noite e aos finais de semana para que o software fique pronto antes do lançamento. Geralmente, a equipe entrega o projeto com a expectativa de fazer ajustes na manutenção. Em geral, as equipes não devem ser pegas de surpresa porque há indicadores que informam quando algo não dá certo. O Team System também ajuda fornecendo um ambiente de colaboração que ajuda a eliminar as barreiras para a solução eficaz de problemas. Esse tipo de abordagem de ultimo minuto para o desenvolvimento de software gera clientes insatisfeitos, desenvolvedores descontentes e software de má qualidade. Também resulta em uma das regras mas intrigantes do desenvolvimento de software 75% do dinheiro para desenvolvimento é gasto na manutenção (mantendo o negócio funcionando) versus 25% em novo desenvolvimento. Normalmente, o desejado é a situação oposta 75% em novo desenvolvimento versus 25% em manutenção. A abordagem corrigir na manutenção é um dos motivos pelos quais existe esse desequilíbrio. Outro problema comum no desenvolvimento de software é a mudança de escopo. Todos nós já passamos por isso ou vimos isso destruir um projeto. Muitas equipes podem não ter sequer notado que o aumento no escopo do projeto foi a causa dos problemas que ocorreram. E, se perceberam, não conseguiram quantificar isso. O Team System inclui um relatório Unplanned Work (Trabalho Não-planejado) que permite aos usuários ver o que é a mudança de escopo e qual é seu impacto na programação de lançamento (Figura 2). White Paper: Obtenha Previsibilidade com o Visual Studio Team System2008 6
Figura 2. Relatório Unplanned Work Com essas informações, as equipes podem discutir a questão com os usuários para minimizar ou gerenciar melhor a mudança de escopo. Entender o impacto das mudanças em uma programação de desenvolvimento é fundamental mas geralmente não há informações suficientes para resolver o problema. Mas e se você pudesse obter informações suficientes para entender um impacto sem passar dias estudando o problema porque você já tinha as métricas e teve apenas que alterar um pouco a projeção? Um caso em questão é o relatório Unplanned Work (Trabalho Não-planejado) mencionado acima. Outro caso é o relatório Remaining Work (Trabalho Restante), que você pode usar para saber quanto trabalho resta, mas que também permite ver as tendências e fazer projeções. Isso também pode ajudar você a informar a gerência sobre os impactos de suas decisões. O Team System também apresenta o relatório Quality Indicators (Indicadores de Qualidade), que fornece informações relacionadas com a qualidade do código. Os usuários não gostam de códigos lançados com muitos erros ou com outros problemas. Ao implementar o teste de unidades e coletar métricas do código, você pode fornecer informações detalhadas, como o número de bugs restantes, o número de testes que falharam (e passaram), taxas de abrangência de código e outras informações (Figura 3). White Paper: Obtenha Previsibilidade com o Visual Studio Team System2008 7
Figura 3 Relatório Quality Indicators A Figura 3 mostra uma tendência preocupante: o número de testes aprovados está diminuindo, a abrangência do código está diminuindo e a rotatividade do código está aumentando. Isso indica que os bugs corrigidos são maiores do que a equipe pensou e que está sendo gasto mais tempo para resolver os bugs. Embora isso não indique um problema, indica que algo pode estar errado. Permite a uma equipe saber que, com base nas informações que possui, há motivos para preocupação ninguém ficará surpreso quando surgir um grande problema. Este relatório ajuda a ter uma idéia do que irá acontecer até o dia do lançamento e depois dele. Você poderá decidir quanto do seu orçamento será gasto em manutenção e quanto estará disponível para novos trabalhos. Também conseguirá atender às expectativas do cliente em relação à qualidade e à finalização da aplicação na versão inicial. White Paper: Obtenha Previsibilidade com o Visual Studio Team System2008 8
ESTIMATIVAS Devido à sua natureza, os projetos de software são difíceis de estimar. Muito difíceis. E existem muitas maneiras de estimar projetos de software. Os especialistas em estimativas de software recomendam o uso de uma série de técnicas em um projeto e buscam uma convergência entre as estimativas para determinar se elas são boas. Uma das melhores técnicas para estimar os projetos de software é usar dados históricos. De acordo com Steve McConnell em seu livro Software Estimation: Demystifying the Black Art (Microsoft Press, 2006), os projetos que usam estimativas históricas tendem a não ter atrasos. É um bom motivo para usar informações históricas. Mas a maioria das empresas não mantém um bom histórico de esforços. Com o Team System, é necessário pouco esforço para gravar as informações necessárias para estimar projetos futuros com base nos resultados passados. Os itens de trabalho do Team System podem registrar informações como o número de linhas do código, o tempo levado para que ele seja concluído e outras informações úteis. Dessa maneira, as empresas podem usar seus próprios dados para estimar tarefas futuras. Usar informações históricas também inclui realidades políticas e condições específicas da empresa. Quanto mais projetos você fizer, melhor será sua capacidade de estimar. Ao extrair dados do data warehouse do Team System e analisá-los, uma empresa pode começar a melhor sua capacidade de estimar e controlar melhor os custos. White Paper: Obtenha Previsibilidade com o Visual Studio Team System2008 9
CONCLUSÃO No Team System, o processo nunca atrapalha o que os desenvolvedores realmente precisam fazer: desenvolver software. O Team System nunca atrapalha porque não é oneroso; ele inclui algumas etapas que acabam economizando tempo. E um processo simples, fácil de usar e bem seguido leva ao que todas as empresas buscam: melhoria no processo. Para melhorar o processo, é preciso ter um processo. Para saber o que precisa ser melhorado, suas equipes de desenvolvimento precisam usar o processo. O Team System ajuda a criar processos melhores com menos trabalho porque ele funciona como você. White Paper: Obtenha Previsibilidade com o Visual Studio Team System2008 10
SOBRE O AUTOR Jeff Levinson é o Lead de Prática de Gerenciamento do Ciclo de Vida da Aplicação na Northwest Cadence e é especializado no Team System e na melhoria de processos. Você pode entrar em contato com ele pelo e-mail Jeff.Levinson@nwcadence.com. Este documento foi desenvolvido em parceria com a A23 Consulting. White Paper: Obtenha Previsibilidade com o Visual Studio Team System2008 11