Considerações sobre o nível F:
No nível F, aparecem os processos considerados de apoio:GQA(Garantia da Qualidade), GCO(Gerência de Configuração), MED(Medições), GPP(Gerência de Portfólio) e opcionalmente AQU(Aquisições). Alguns desses processos, como GCO certamente tem uma parte significativa praticada nas empresas ágeis, se encontrando nelas, no mínimo, os aspectos relativos à manutenção e controle do código fonte. Outros resultados, como a formalização de itens de configuração, auditoria de baselines, etc poderão não ser observados, a menos em empresas ágeis com certificação F ou maior. Outros processos como GQA também provavelmente não serão encontrados nas empresas ágeis como preconizado pelo modelo. Aqui poderemos ter alguns ajustes de conceitos, devido aos aspectos vigentes de auto-gestão da equipe e a introdução de auditoria de alguém de fora do círculo, não envolvida no STeam. A parte de Medições(MED) poderá ter alguma aderência com o Scrum, principalmente na elaboração de estimativas, mas lacunas poderão acontecer na sistematização da coleta, análise, divulgação e tomada de decisão a respeito das métricas. A Gerência de Portfólio(GPP), deverá apresentar lacunas grandes, por ser um processo novo, até para as empresas mais estruturadas. O Processo de AQU(Aquisições) deverá ter o mesmo comportamento do GPP devido à sua opcionalidade.
Processo GQA-Garantia de Qualidade
Pontos de Atenção: Como existe ampla possibilidade desse processo ser uma novidade integral numa empresa ágil sem MPS.BR, o processo de GQA deverá ser implementado como definido pelo modelo. Assim, não deve existir diferença significativa no processo de Garantia da Qualidade (GQA) entre o Modelo MPS.BR e um a ser adotado no Scrum. Claro que estamos falando de um procedimento de aferição formal de qualidade e não uma idéia de qualidade natural, embutida nos processos ágeis, através de seus preceitos de que todos farão com correção pela força da coesão da equipe, de que as iterações , por serem curtas, implicarão menor risco de perda de qualidade, etc. Isso implicará a criação de um Plano de Qualidade a ser aplicado no release, observado nas diferentes sprints.
GQA 1. A aderência dos produtos de trabalho aos padrões, procedimentos e requisitos aplicáveis é avaliada objetivamente, antes dos produtos serem entregues e em marcos predefinidos ao longo do ciclo de vida do projeto;
Idéias sobre evidências: Relatórios de auditorias de GQA executadas, segundo plano de GQA em pontos do ciclo de vida do projeto. Por exemplo, auditoria de GQA no final do Pregame, durante os sprints do Development(presprint, sprint e postsprint) e durante o postgame . Os relatórios conterão resultados das auditorias de produtos de trabalho, realizados através de check-lists.
GQA 2. A aderência dos processos executados às descrições de processo, padrões e procedimentos é avaliada objetivamente;
Idéias sobre evidências: Relatórios de auditoria de GQA executado, segundo plano de GQA em pontos do ciclo de vida do projeto. Por exemplo, auditoria de GQA no final do Pregame, durante os sprints do Development(presprint, sprint e postsprint) e durante o postgame. Os relatórios conterão resultados de auditoria de processos, realizados através de check-lists. A mesma instância de auditoria avaliará tanto produto quanto processo.
GQA 3. Os problemas e as não-conformidades são identificados, registrados e comunicados;
Idéias sobre evidências: Os problemas detectados durante a auditoria(NC-Não conformidades), serão registrados numa ferramenta de issue-tracker, por exemplo, que deverá permitir o acompanhamento até a sua resolução. Um dos pontos que poderá ser adotado no Scrum, o que potencializará a conscientização sobre erros e, principalmente, como evitá-los, será a discussão dessas NC dentro das reuniões da equipe(daily scrum ou sprint review), por exemplo.
GQA 4. Ações corretivas para as não-conformidades são estabelecidas e acompanhadas até as suas efetivas conclusões. Quando necessário, o escalamento das ações corretivas para níveis superiores é realizado, de forma a garantir sua solução;
Idéias sobre evidências: O foco aqui é o acompanhamento da NC até a sua conclusão e a possibilidade de escalonamento, em caso de impasses na resolução. Esse ponto tem uma componente cultural relativo ao fato dos colaboradores serem " observados" por alguém de fora do “team” e auditado nos seus erros. A filosofia dos métodos ágeis, por conterem traços de comportamento mais libertos e de auto-gestão, talvez até facilite esse aspecto.
Processo GCO-Gerência de Configuração
Introdução: Não existe diferença significativa na Gerência de Configuração (GCO) entre os Modelos MPS.BR e Scrum, podendo ser adotados os mesmos conceitos da GCO tradicional. Provavelmente uma empresa ágil já terá familiaridade com ferramentas de controle de fontes, porém se atendo a operações regulares de tratamento de fontes como check-in, check-out, etc, sem maiores extensões em gerência de configuração.
GCO 1. Um Sistema de Gerência de Configuração é estabelecido e mantido;
Idéias sobre evidências: Um plano geral de Configuração, ou plano de configuração por projeto, contendo especificidades, deverá ser elaborado, contendo os principais elementos de um sistema de Gerência de Configuração: 1)Um repositório de códigos fonte, um repositório de códigos executáveis e uma ferramenta de Issue-tracker para controlar as eventuais mudanças. Além disso, outros elementos de software poderão integrar esse conjunto, como Maven, por exemplo, que ajudará na gerência do projeto, no sentido de facilitar o controle dos builds,da documentação e das dependências entre objetos.
GCO 2. Os itens de configuração são identificados com base em critérios estabelecidos;
Idéias sobre evidências: Definição de itens de configuração, colocados sob os tipos de controles: registro, versionamento e linha de base. A filosofia na escolha dos IC´s deve ser a mesma que baliza os métodos estruturados, com priorização dos elementos essenciais associados ao cliente/produto.
GCO 3. Os itens de configuração sujeitos a um controle formal são colocados sob baseline;
Idéias sobre evidências: Definição das Baselines criadas, com os seus respetivos itens de configuração. As Baselines deverão ser definidas para serem passadas em pontos(marcos) do ciclo de vida Scrum, podendo ser ao final da fase de Pré-game, ao final de cada sprint e ao final do pós-game. Eventualmente baselines tiradas em momentos de atualizações intensas e críticas poderão ser adotadas. As baselines deverão estar definidas no Release Plan, para se garantir a compatibilidade nos momentos de auditoria de GCO.
GCO 4. A situação dos itens de configuração e das baselines é registrada ao longo do tempo e disponibilizada;
Idéias sobre evidências: Processo aliado à ferramenta que permite a análise das baselines, seus itens de configuração, com as respectivas versões. Deverá permitir um -diff- entre as baselines . Isso , por vezes, é resolvido diretamente pela própria ferramenta de GCO adotada(software de controle de versão).
GCO 5. Modificações em itens de configuração são controladas;
Idéias sobre evidências: Sistema de controle de alterações, com a identificação das alterações, análise de impacto, análise sob a ótica de IC e aprovação. Os registros de Commit do SVN, por exemplo, contendo associação com os itens de backlog(Id do requisito) que estão sendo resolvidos naquela alteração são evidências. O Mantis ou equivalente como elemento de controle de alterações, descrevendo-a serve como evidência indireta. O número da “issue” registrada para a alteração deverá estar no label do SVN, CVS, etc, para definir a rastreabilidade entre a alteração efetuada no código fonte e o seu registro como issue, no ambiente de “issue-tracker”.
GCO 6. O armazenamento, o manuseio e a liberação de itens de configuração e baselines são controlados;
Idéias sobre evidências: Controle de registro de Baseline no software de controle de versão, de acordo com as definições de linhas de base do projeto(release).Liberaçãodos IC´s sob baseline para atualização e passagem de nova baseline. Os elementos derivados dessas ações são fonte de evidências.
GCO 7. Auditorias de configuração são realizadas objetivamente para assegurar que as baselines e os itens de configuração estejam íntegros, completos e consistentes;
Idéias sobre evidências: As auditorias de configuração feitas por uma auditor de configuração em cima das Base Lines passadas, com apontamento de NC que deverão ser corrigidas antes do fechamento da baseline. As auditorias deverão ter o cunho físico e funcional. A auditoria física cuida da estrutura dos diretórios, os IC corretos dentro daquela Baseline,os padrões corretos aplicados aos elementos envolvidos, etc. A auditoria funcional verifica cada IC, compara a versão correta, se o IC foi alterado, verifica o seu conteúdo abrindo o arquivo, analisando se o elemento passou pelos controles que deveria, etc.É uma espécie de garantia da garantia de qualidade.
Processo MED-Medições
Introdução: Existe alguma diferença no processo de Medições(MED), quando comparamos modelos estruturados e ágeis. Alguns tipos de indicadores são diferentes dos adotados nos processos convencionais. Por exemplo, “story point” é usado como indicador de tamanho de estórias(funcionalidades semelhante ao conceito de CSU, ou cenário de CSU). O gráfico de “burndown” , usado para acompanhamento diário da sprint é também algo bem próprio do Scrum. Os métodos para a definição de tamanho também passam por aspectos diferenciados como “poker planning”, processo mais lúdico onde a equipe estima o tamanho/esforço daquela funcionalidade através de colocações de estimativas relativas.
MED1 - Objetivos de medição são estabelecidos e mantidos a partir dos objetivos de negócio da organização e das necessidades de informação de processos técnicos e gerenciais
Idéias sobre evidências: Um plano geral de Medição, ou plano de medições por projeto, contendo especificidades, deverá ser elaborado. As medições deverão estar associadas à estratégia da empresa e contendo métricas(uma para cada processo, podendo haver métricas globalizantes, como as que ajuntam aspectos de reutilização-GRU e de engenharia-PCP). Um plano estratégico ou uma diretriz estratégica da empresa deverá ser apresentado coerente com as medições definidas.
MED2 - Um conjunto adequado de medidas, orientado pelos objetivos de medição, é identificado e definido, priorizado, documentado, revisado e, quando pertinente, atualizado;
Idéias sobre evidências: As métricas deverão ser definidas de acordo com o Scrum, podendo haver algumas medições diferentes das comumente encontradas em modelos estruturados. A diferença centra nas estimativas de tamanho, esforço e prazo, que poderão ser de outra natureza como: ideal-day, story-point, e burndown(percentagem de alcance da sprint). As medidas de processos de apoio como GQA,GCO,MED e de outros níveis como PCP,ITP,DRE,VER,VAL provavelmente serão semelhantes aos dos modelos tradicionais. As medições poderão ser feitas nas sprints, ou por projeto(release). Para cada métrica definida deverão ser mostrados: os procedimentos de coleta e armazenamento e os procedimentos de análise e de divulgação.
MED3 - Os procedimentos para a coleta e o armazenamento de medidas são especificados;
Idéias sobre evidências: Procedimentos de coleta e armazenamento, dependentes das métricas definidas, executados nos pontos definidos no Plano de Medição do projeto.
MED4 - Os procedimentos para a análise das medidas são especificados;
Idéias sobre evidências: Procedimentos de análise dependentes das métricas definidas.
MED5 - Os dados requeridos são coletados e analisados;
Idéias sobre evidências: Realização e registro das coletas, seguido das análises.
MED6 - Os dados e os resultados das análises são armazenados;
Idéias sobre evidências: Dados e resultados armazenados, com o objetivo de se criar base histórica de referência para projetos futuros.
MED7 - Os dados e os resultados das análises são comunicados aos interessados e são utilizados para apoiar decisões;
Idéias sobre evidências: Os dados e os resultados de análise poderão ser comunicados através dos elementos(mecanismos) de controle e acompanhamento do Scrum, como daily scrum(burndown), quadro do agile radiator,sprint review, retrospective meeting e final de projetos(post-game).
Processo GPP-Gerência de Portfólio
Introdução: Em Gerência de Portfólio não deve haver diferença significativa entre o GPP sugerido para empresas usando Scrum e os métodos mais estruturados. O conceito de Portfólio, quando aplicado em empresas Scrum, se identificará com os diversos desenvolvimentos de releases de produtos ou projetos em andamento naquele espaço de tempo paralelo. O PO(Product owner) ou os PO´s de cada Produto, nesse contexto, farão as vezes do Gerente de Portfólio, definindo as prioridades e alocação de recursos . Para os projetos de sistemas(empresas de projetos), a sistemática deverá ser a mesma adotada nas abordagens estruturadas, com envolvimento de PMO e GP´s. Uma figura do P.O dos P.O´s poderá surgir aqui com a implantação da Gerência de Portfólio.
GPP1 - As oportunidades de negócio, as necessidades e os investimentos são identificados, qualificados, priorizados e selecionados
Idéias sobre evidências: Definição dos road-maps de produtos, através dos PO´s envolvidos, coletando as oportunidades via os demais canais, como Departamento comercial; call center, clientes, departamento de P/D da empresa,etc.
GPP2 - Os recursos e orçamentos para cada projeto são identificados e alocados;
Idéias sobre evidências: Definição macro feita pelos PO´s dentro de cada projeto envolvido na Gerência de Portfólio. Algumas dessas informações são discutidas na fase dePreGame.
GPP3 - A responsabilidade e autoridade pelo gerenciamento dos projetos são estabelecidas;
Idéias sobre evidências: Definição macro feita pelos PO´s dentro de cada projeto envolvido na Gerência de Portfólio.Algumas dessas informações são discutidas na fase de PreGame.
GPP4 - Os conflitos sobre recursos entre projetos são tratados e resolvidos;
Idéias sobre evidências: Definição feita pelos PO´s envolvidos nos diferentes projetos do portfólio.
GPP5 - Projetos que atendem aos acordos e requisitos que levaram à sua aprovação são mantidos, e os que não atendem são redirecionados ou cancelados;
Idéias sobre evidências: Definição macro feita pelos PO´s dentro de cada projeto envolvido na Gerência de Portfólio.
Nenhum comentário:
Postar um comentário