Introdução
Por Microsoft: https://msdn.microsoft.com/pt-br/library/hh765978.aspx
O CMMI é um modelo para entender a maturidade e a capacidade organizacional. Não é um padrão, nem é um desenvolvimento de software ou definição do processo de gerenciamento do projeto.
O modelo CMMI basicamente afirma que as novas e imaturas organizações, a princípio, desenvolverão recursos em práticas para gerenciar configurações e controle de origem, coletando informações sobre projetos e trabalho que estão empreendendo, planejando projetos, acompanhando requisitos, monitorando o progresso do projeto e tomando ações com base em comparar dados reais com um plano. Essa é a essência do nível 2 de maturidade.
Conforme as capacidades do nível 2 de maturidade se enquadram no local, a organização e suas pessoas encaminham sua atenção para outros interesses, portanto, a capacidade de definir requisitos, teste, arquitetura e design, integração e processos de definição para que eles possam ser repetidos começa a emergir. Conforme as coisas se estabilizam, uma compreensão de como a cultura e o estilo de gerenciamento afetam o desempenho surge e, esperamos, uma compreensão de que uma abordagem de pensamento do sistema é necessária para fornecer melhorias de desempenho ainda maiores. Com as coisas se tornando mais estáveis e os problemas do dia-a-dia como o planejamento e monitoramento de projeto se tornando a rotina propriamente, há um tempo para considerar o gerenciamento dos riscos e alternativas e opções a analisar antes de tomar decisões. A coordenação de vários projetos dependentes e a administração aprimorada de recursos compartilhados pode surgir. Talvez um programa de treinamento, um esquema de aprendizado professor-aluno ou formas simples de trabalho colaborativo surjam para melhorar as habilidades e aumentar o nível geral de desempenho. Se necessário, alguma auditoria interna ou função de garantia de qualidade do processo podem emergir. Tudo isto é a essência da maturidade nível 3.
Quando uma organização executa uma maturidade contínua nível 3, as coisas são executadas como relógio. A organização cumpre suas promessas e é considerada muito confiável e segura. Um alto nível de confiança emerge nas relações com clientes. Os gerentes seniores começam a fazer perguntas como “Onde devo investir para obter mais melhorias?” e “Qual equipe tem o melhor desempenho econômico?” Os gerentes começam a desenvolver idéias avançadas em capacidades e desempenho e percebe que eles podem usar a simulação e a análise estatística para melhorar a qualidade do produto, entrega ao cliente e a satisfação. As decisões de gerenciamento agora são totalmente objetivas e defensáveis com dados estatísticos. Essa é a essência de uma organização de nível 4 de maturidade. Para a maioria de diretores principais, o nível 4 de maturidade representa seu estado ideal. Tudo funciona como um relógio e eles possuem dados de desempenho comparativos e podem enviar contra promessas com um alto grau de precisão. O desempenho econômico é muito melhorado e o desempenho da organização é altamente previsível.
Os comportamentos de nível 5 de maturidade emergem geralmente muito antes de uma organização realmente alcançar o nível 5. A análise de causa raiz é geralmente vista em organizações com maturidade de nível 3. O que a torna um recurso do nível 5 é se a análise da causa raiz é feita usando dados quantitativos e é defensável estatisticamente. A emergência de um processo formalizado para a inovação de processo e implantação de melhorias também pode ocorrer antes que a organização pudesse realmente ser considerada para o nível 5 de maturidade. No nível 5, a melhoria do processo foi institucionalizada e inserida na cultura de organização. A cultura é a de sempre desafiar o status de quo e procurar melhores recursos, melhor qualidade de produto e melhor desempenho econômico.
Issue
Para o modelo MSF-CMMI da Microsoft, um Issue é um item de trabalho que tem como objetivo lhe auxiliar a rastrear problemas com Planos de Projetos, Tarefas e Atividades. Por exemplo:
– Ambiguidade nos requisitos;
– Indisponibilidade de pessoal ou outros recursos;
– Problemas com ambientes;
Em nossa abordagem, iremos usar o Issue como um Work Item com mais valor, para a identificação de incidentes já em produção (sendo bugs ou não, ligados a requisitos funcionais ou não funcionais), separando assim, do nosso processo, os reports de Bugs dentro de um projeto de desenvolvimento em andamento, de uma aplicação já disponível em produção para os clientes.
Nova Abordagem do Issue
Um Issue é um problema, geralmente encontrado em ambientes de produção, o qual faz com que a aplicação se comporte de maneira inesperada ou até impede que algumas funções do produto possam ser executadas. Issues não devem ser confundidos com bugs. O item de trabalho bug é utilizado para acompanhar problemas com o código ou testes com falhas específicas e bem mapeadas. O Issue serve para ajudar você a acompanhar todos os outros problemas com o projeto/produto.
Alicerce do Uso de Issue: O que torna problemas (Issues) diferentes do Bug é que eles representam atividades não programadas. Resolver problemas não é trabalho normal de projeto. Portanto, ele deve ser rastreado e ter atenção especial. Rastrear problemas de projeto, através dos Issues, utilizando relatórios e consultas, ajuda a gerenciar e resolver esses problemas de forma rápida e eficaz. Além disso, utilizando Issue para problemas em produção é possível separar a quantidade de problemas encontrados nos ambientes de produção dos clientes dos erros encontrados em ambiente de desenvolvimento.
O Team Foundation Server bem como os modelos de processos (por exemplo o MSF-CMMI) dá liberdade para que você adapte os Work Items e Fuxos de Trabalho à seu processo (respeitando corretamente os links de Work Itens e Workflows) e defina a melhor forma que ele deve trabalhar para você, pois os templates, Workflows e Workitens são customizáveis.
Nesse artigo iremos abordar uma maneira de gerir um problema em produção de uma versão de um aplicativo.
Vantagens de Uso de Issue
Depois que seu software está em produção, é muito importante entender os motivos que levam os usuários a entrarem em contato com o suporte, sobre um problema identificado no seu produto. Normalmente esse levantamento pode ser feito via artefatos gerados pelo ITIL, por exemplo. Inclusive gerar um plano de ação, para que essa situação não volte a ocorrer, ou quando impossibilitado de impedir que o problema ocorra, mitigar o mesmo e garantir o menor impacto na empresa e ao cliente.
Porém quando seu processo não possui o uso de um ITIL e os devidos alinhamentos, bem como, você deseja saber não pelo suporte/serviços, mas sim, pelo seu time de manutenção de produtos, você pode usar algumas ferramentas e uma dessas ferramentas é o uso de uma Issue. Sabemos que um Bug encontrado em produção gera um custo de 10 à 1000 vezes mais à empresa que criou o software, tanto de reputação, como de recursos, porém muitas vezes esses números não são palpáveis e fazem com que acabem apenas virando tópico de apresentações, geração de comoção momentânea, debates, mas sem efetividade na resolução disso.
Com uma gestão de problemas via Issue, conseguimos gerar informações reais como:
– Problema Inicial;
– O que afetou;
– Causa Raiz (Bug, Entendimento, Falta de Informações);
– Envolvidos (Tarefas, Custo Hora de Pessoas, Análises);
– Plano de Ação com datas para liberação, inclusive a “amarração” de Hotfix e Patches nesse plano;
É fácil diferenciar um Issue de um Bug, pois um Bug trata de um problema bem mais centralizado em código ou falha específica, descoberta por Casos de Testes. Ou seja, o bug corresponde às falhas identificadas durante o processo de desenvolvimento de seu produto.
Já a Issue, você poderá utilizar para problemas detectados, pós liberação de seu software, inclusive identificando, após uma análise, se realmente se tratava de um problema, entendimento.
Importante
Para que a Issue tenha efetividade, é muito importante que o demandante tenha conhecimentos acerca de como preencher uma Issue, rastreabilidade, controle, entendimento do produto em que trabalha, e que os envolvidos respeitam a seriedade da Issue, inclusive com análises periódicas e reuniões de alinhamento, caso contrário, ela se tornará mais um artefato a ser gerado no Team Foundation Server sem efetividade alguma.
Cenário
O cliente abre um solicitação que vem via Software de Gerenciamento do time de suporte e/ou serviços, informando que está com um problema para gerar um relatório. O time de suporte tentou corrigir, porém não conseguiu identificar o problema, qual o próximo passo? Como podemos solicitar apoio ao time de desenvolvimento e testes na análise desse incidente? Esse incidente é um Bug? Devo atribuir esse incidente em qual iteração do projeto do Team Foundation Server esse incidente?
Há diversas formas de você trabalhar essa situação, inclusive, irá diferenciar conforme o fluxo de trabalho da sua empresa, como por exemplo: – O time que dá suporte é o mesmo que desenvolve, testa e aplica a correção. – O time de suporte é um, e o time de desenvolvimento é outro, e tantos outros cenários que temos por aí.
Vamos imaginar que, no nosso cenário o time que dá suporte é o Time A e o que desenvolve é o Time B;
E a forma de desenvolvimento do seu time é a seguinte:
– Desenvolvimento trabalha na Current/Main ou o nome que você definiu, afinal o processo é seu 
;
– Depois de definidos os requisitos a serem atendidos, congela-se uma versão que será a versão a ser testada, validados os requisitos e sairá para produção/mercado/empresa;
– Depois o desenvolvimento continua trabalhando na Current/Main;
– Na versão de produção é descoberto um erro/bug/issue;
– O desenvolvimento abre a versão de código congelada, gera um Patch/Hotfix de correção para aplicar na versão em produção, depois de devidamente validada a correção, e leva essa correção para a Main/Current.
Simples assim!
Você pode ter diversos outros cenários ou formas de trabalho, esse exemplo é apenas para ilustrar como proceder em seu trabalho quando se recebe uma Issue.
Fluxo de Issue
Time de Suporte abre uma Issue para que haja o apoio do time de desenvolvimento na análise do problema. Essa Issue, ficará vinculada à versão do Projeto de Desenvolvimento encerrado (em produção) ou em um Projeto denominado Análises, para gerenciamento de horas, ou sem vinculo nenhum inicialmente;
Time de Desenvolvimento/Testes gera uma Tarefa de Análise e vincula à Issue, inclusive, pode ser executar um Teste Exploratório com o MTM e se confirmado, torna-se um Caso de Testes para ser vinculado no Requisito e Issue, para ser testado depois. Por enquanto, essa Tarefa de Análise não ficará vinculada a nenhum Projeto ou pode-se ter, se desejar, um Projeto Mensal denominado Análises, para gerenciamento de horas gastas e solução de Issues e assim justificar o investimento em qualidade no desenvolvimento de software;
O ideal é que todos os envolvidos abram uma tarefa e vincule à Issue para medição de custos envolvidos em horas de cada integrante.
Identificada uma falha, bug, erro de processo, etc. Deverá ser criado o plano de ação:
Em seu gerenciamento de projeto, você pode seguir a seguinte linha de “amarração dos Work Items”.
Ou seja, em versões de HOTFIX, a Issue poderá ser o ITEM inicial de demanda, sendo vinculados:
Issue: Tarefas de Análises, Tarefas de Desenvolvimento, Tarefas de Testes, e Casos de Testes para medir o custo total de uma Issue depois que foi para produção.
Quando se levará a correção para uma nova versão, você deverá vincular no Requisito, sendo que você pode iniciar de duas formas:
– A partir do Test Case criado na Issue para ficar como Regressivo, e validar se na versão Current o incidente ocorre. Se sim, abrir um BUG e corrigir o BUG através do fluxo normal.
– Analisar o código, inserir a implementação (através de uma Tarefa criada na Current) e depois executar o Caso de Teste criado na Issue para validar se está OK.
Caso de Teste (Usar mesmo criado na Issue);
Ou seja, a base de seus HOTFIXES/PATCHS serão as Issues e de suas novas versões os Requisitos (Corrigidos e Versionados);
Ficando os vinculos como:
Tarefa de Análise: Child da Issue
Tarefa de Desenvolvimento para o Hotfix: Child da Issue
Tarefa de Teste: Child da Issue
Caso de Teste: Tested by para a Issue
Iguais os vinculos de um Requirement.
Tabela para Auxiliar nas Dúvidas
Maiores Informações
qualidadeeti.wordpress.com 