Mapeamento MPSxSCRUM-Nível E-Parte VI-atualizado em 04/10/2010-16:00h
Considerações sobre os processos do nível E:
O nível E do MPS.BR é um nível bastante conceitual e distancia um pouco dos aspectos diretos de desenvolvimento, principalmente daqueles que tem o “ agilismo” correndo nas veias. Explico melhor: O nível E é o nível onde se define um ou mais processos que a empresa deverá empregar na sua culinária de sistemas. Até então, a empresa podia ter, por projetos, receitas específicas, desde que cada uma delas contemplasse os processos fundamentais(GRE,GPR), os processos de apoio(GCO,GQA,MED e GPP), além das RAP´s exigidas para aqueles níveis. Agora não. As coisas ganham um pouco mais de formalismo e exige-se que a empresa ofereça um ou mais processos padrão(variando com estilos de negócios praticados) e que esses ou esse(caso seja somente um processo padrão), tenha regras claras e objetivas de aplicação e adaptação, dependentes do tipo de sistema que se deseja desenvolver. Por exemplo, se a empresa for uma Fábrica de Software, poderá ter um processo que abrirá mão da fase inicial de DRE/GRE para se concentrar na construção e entrega. Se a empresa, ao contrário, for uma fábrica de Requisitos, o seu processo se concentrará nas fases iniciais do ciclo de vida. A esse processo adaptado, chamamos de processo definido e ao(s) processo(s)-mãe,chamamos de processo padrão. Essa espiral conceitual é algo que deverá ser bem trabalhada no mundo ágil, onde os praticantes não são muito afeito a essas elaborações semânticas e normalmente são ávidos por “ mão-na massa”, “olho no olho”, etc.
O nível E contempla dois processos seminais(AMP e DFP), que são a receita para se escrever os processos de que precisamos para a empresa. Os dois são muito conceituais e abstratos, pois resvalam nas fronteiras do meta-processo(processo para se escrever processo), mas poderão ser evidenciados pela mimetização dos conceitos ágeis, conforme veremos adiante.
Além desses, temos o GRH(Gerência de Recursos Humanos).Esse é relativamente invariante com relação ao mundo ágil, se considerarmos aquela premissa de que a empresa ágil deseja alcançá-lo. O GRH toca em pontos óbvios e necessários que qualquer empresa, seja agilista ou estruturada, deverá ter para moldar aquele que é o principal recurso de qualquer processo, independente da sua gênese: as pessoas. No GRH são elaboradas ações de recrutamento e seleção, treinamento e uma área nova, que toca na gerência de conhecimentos. As duas anteriores (recrutamento e seleção) são típicas de qualquer empresa e normalmente conduzidas por uma área paralela(RH). A parte de conhecimentos tem algumas interseções com o mundo ágil, na medida em que o conhecimento produzido pela equipe(PO,Scrum Master e Scrum Team,etc) deverá ser registrado, catalogado, pesquisado e disseminado. Uma rede de especialistas deverá ser definida e controlada. O mundo ágil, tem como premissa, repito, um certo grau de informalidade e refração à definição de protocolos e aqui deveremos ter ações preventivas para mitigar esses pontos. Deveremos trabalhar visando o aculturamento desses conceitos de “gerência” de conhecimento, via processos e ferramentas um pouco mais formais do que um “daily scrum” "despojado".
O outro processo do nível E trata de um assunto muito próximo dos agilistas: A reutilização. A Gerência de reutilização, trazida como novidade no bojo do MPS.BR, é algo novo, ainda imaturo, mesmo como processo MPS e será escrito em conjunto pelos agilistas e pelos implementadores MPS.BR nas empresas.O conceito de reutilização, nesse nível, começa com o conceito de ativos reutilizáveis, que significa,”qualquer coisa” que se deseje reutilizar, desde que traga retornos claros para a empresa. Pode ser “template”, códigos, procedimentos,etc. De novo, a reutilização, exige certas formalidades, que vão da definição do ativo e de uma base de armazenamento; de sua pertinência ou validade de ser compartilhado através de aplicação de critérios; de sua integridade(se está funcionando OK); se está pronto(intelegível e documentado) para ser reutilizado, além dos controles de seu ciclo de vida e de quem e quando faz(fez) a reutilização, ou do porquê e quando desiste de fazê-lo. E isso, como se depreende, não pode ser definido “ no bigode”, para se usar um termo do interior, quando se estabelece direitos e deveres de partes interessadas e envolvidas num compromisso. Há que se ter aqui algum formalismo definido.
Dessa forma, nestas linhas faremos um mapeamento direto do processo DFP, AMP e Extensão do GPR, com possíveis idéias sobre evidências em SCRUM.
DFP-Definição do Processo Organizacional
O processo de DFP, como explícito no nome, busca orientar no sentido do que é um Processo, seus componentes e como podemos defini-los.
DFP1 - Um conjunto definido de processos padrão é estabelecido e mantido, juntamente com a indicação da aplicabilidade de cada processo.
Idéias sobre evidências: Processo(s) padrão, definido(s) na forma ágil, com todos os ingredientes dos modelos ágeis utilizados: SCRUM,XP, etc, inclusive considerando os aspectos de Scrum distribuído.Uma empresa que pretende estabelecer projetos envolvendo diversas equipes Scrum, distribuídas por componente ou por funcionalidade, deverá definir processos para esse tipo de projeto, ou pensar em adaptações de processos que contemplem esses cenários;
DFP2 - Uma biblioteca de ativos de processo organizacional é estabelecida e mantida .
Idéias sobre evidências: Bibliotecas de ativos do(s) processo(s) padrão), definido(s) na forma ágil, com todos os ingredientes dos modelos ágeis utilizados(SCRUM,XP, etc);
DFP3 - Tarefas, atividades, papéis e produtos de trabalho associados aos processos padrão são identificados e detalhados, juntamente com o desempenho esperado do processo .
Idéias sobre evidências: Detalhamento do(s) processo(s) padrão), definido(s) na forma ágil, com todos os ingredientes modelos ágeis utilizados(SCRUM,XP, etc);
DFP4 - As descrições dos modelos de ciclo de vida a serem utilizados nos projetos da organização são estabelecidas e mantidas
Idéias sobre evidências: Detalhamento dos diferentes ciclos de vida do(s) processo(s) padrão), definido(s) na forma ágil, com todos os ingredientes dos modelos ágeis utilizados( SCRUM,XP, etc);
DFP5 - Uma estratégia para adaptação do processo padrão é desenvolvida considerando as necessidades dos projetos
Idéias sobre evidências: Documento de adaptação para o(s) processo(s) padrão), definido(s) na forma ágil, com todos os ingredientes modelos ágeis utilizados(SCRUM,XP, etc), visando a criação de processo(s) definido(s);
DFP6 - O repositório de medidas da organização é estabelecido e mantido
Idéias sobre evidências: Definição de um repositório de medidas, como evolução do processo MED(nível F) aplicado dentro do(s) processo(s) padrão), definido(s) na forma ágil, com todos os ingredientes dos modelos ágeis utilizados( SCRUM,XP,etc);
DFP7 - Os ambientes padrão de trabalho da organização são estabelecidos e mantidos
Idéias sobre evidências: Definição de ambiente de trabalho padrão da organização, elencando softwares, hardwares, por papel desempenhado dentro do(s) processo(s) padrão), definido(s) na forma ágil, com todos os ingredientes dos modelos ágeis utilizados (SCRUM,XP,etc).
Para os processos restantes do nível E,(GRH,GRU) há uma forte invariância, pelo o que permanecem somente os conceitos elaborados anteriormente. Não detalharemos, por ora, os resultados esperados desses processos.
GPR-Estendido:
O processo GPR estendido, ajusta o processo GPR(nível G) aos aspectos do processo padrão e do processo definido:
GPR4 - (A partir do nível E) O planejamento e as estimativas das atividades do projeto são feitos baseados no repositório de estimativas e no conjunto de ativos de processo organizacional
Idéias sobre evidências: O planejamento e estimativa das estórias, atividades originadas delas, ajustes de velocidades de sprints, pontos de estórias, burndown, etc, deverão ser baseado em um repositório de medidas, como evolução do processo MED(nível F) aplicado dentro do(s) processo(s) padrão), definido(s) na forma ágil, com todos os ingredientes dos modelos ágeis utilizados (SCRUM,XP,etc);
GPR18 - (A partir do Nível E) Um processo definido para o projeto é estabelecido de acordo com a estratégia para adaptação do processo da organização .
Idéias sobre evidências: No planejamento do Release(Release Planning), deverá ser estabelecido o processo definido a ser aplicado naquele momento. Um documento de adaptação deverá mostrar as eventuais alterações e suas justificativas.Aqui também deverão ser considerados os aspectos de Scrum distribuído, quando a empresa previr a possibilidade gerência integrada de várias equipes Scrum, o que deverá ser contemplado no Processo Padrão( ver DFP1).
GPR19 - (A partir do nível E) Produtos de trabalho, medidas e experiências documentadas contribuem para os ativos de processo organizacional
Idéias sobre evidências: No Retrospective Meeting, ao final da iteração, ou ao final do Release(Post-Game), deverão ser documentadas as experiências, medidas, etc que contribuirão para a melhoria do processo organizacional.
AMP-Avaliação e Melhoria de Processos
Os processos AMP e DFP podem ser vistos, em conjunto, como o processo para se definir e evoluir o processo de desenvolvimento da empresa. Assim, o processo para se desenvolver processo poderá usar os mesmos conceitos ágeis aplicados ao desenvolvimento de software.Ou seja um processo criador de processos deverá ter um ou mais releases a serem definidos com os suas sprints, e em cada sprint, poderão ser definidos a escrita de um ou mais processos. Por exemplo, um release do Processo de definição de processos (PDP) seria a revisão inicial dos processos do nível F e as suas sprints seriam as avaliações e melhorias desses processos. Poderíamos ter um outro release do PDP com a escrita dos processos de Engenharia, por exemplo e nesse teríamos a escrita de processos de DRE,PCP,ITP,VER,VAL divididas em sprints diferentes. Um outro release poderia contemplar o desenvolvimento dos processos de nível C, como GRI,GDE e DRU.Assim sucessivamente planejaríamos as escritas dos processos necessários àquele nível . Uma outra sprint poderia ser a implementação desses novos processos, caso a empresa deseje escrever tudo primeiro para implementar depois, numa espécie de cascata. Caso contrário, poderíamos ter em cada sprint de escrita, a sua implementação em estado de beta-teste, por exemplo.A escolha de quais processos serão escritos/implementado vai depender do “gap” entre o último nível certificado e o nível desejado. Muitas empresas, depois de fecharem um certo nível de maturidade, entram num certo “vale” de conforto, diminuindo o oxigênio da equipe de SEPG e provocando certas “flexibilizações” que se manifestarão quando desejarem subir de patamar.
AMP1 - A descrição das necessidades e os objetivos dos processos da organização são estabelecidos e mantidos
Idéias sobre evidências: Aqui entram as posições estratégicas e negociais da empresa definindo as necessidades de processos na organização. Seriam os insumos para se definir o formato de se escrever o processo da empresa. Poderiam ser os requisitos de alto nível do Release backlog de Processos, formado por Épicos e Temas, por exemplo.
AMP2 - As informações e os dados relacionados ao uso dos processos padrão para projetos específicos existem e são mantidos
Idéias sobre evidências: O Release Plan de cada projeto indica o processo padrão a ser usado e a seção onde aparece a adaptação do processo ao projeto indica as atividades e produtos ajustados ou customizados.Isso forma o conceito de Processo definido. Caso o Scrum esteja sendo desenvolvido em empresas mais vocacionadas para produto, haverá uma tendência de baixa incidência de adaptação, devido à uniformidade do produto e a consequente invariância do processo.
AMP3 - Avaliações dos processos padrão da organização são realizadas para identificar seus pontos fortes, pontos fracos e oportunidades de melhoria
Idéias sobre evidências: Esse resultado é relativamente invariante com relação à Scrum, pois denota as diversas avaliações pelas quais o processo padrão passou e isso é independente de ser Scrum,RUP, etc. Uma das formas de fazer isso é através de avaliações externas(DPA-Diagnóstico de pré-avaliação), ou internas(avaliações sobre o andamento da aplicação do processo padrão, nas reuniões de sprint review ou de retrospective meeting). As auditorias de QA, oriundas do nível F, também avaliam os processos e podem oferecer indicadores de pontos fortes, fracos e oportunidades de melhoria;
AMP4 - Registros das avaliações realizadas são mantidos acessíveis
Idéias sobre evidências: Esse resultado está relacionado ao anterior e valem as mesmas observações. Os diversos mecanismos aplicados na avaliação dos processos produzem diferentes formas de registros que deverão ser mantidos como evidências
AMP5 - Os objetivos de melhoria dos processos são identificados e priorizados
Idéias sobre evidências: Esse resultado pode ser entendido como um maior detalhamento dos requisitos e podem ser respondidos pela pergunta: Quais objetivos intenciono alcançar com o processo, cada melhoria sugerida, etc. O Release backlog, onde os grandes temas e épicos(macro requisitos), agora detalhados sobre a implementação do processo, estão registrados, deverão ser avaliados, através de mecanismos de priorização, com o BV(Valor de negócios) daquele processo sendo usado como elemento de priorização, por exemplo.
AMP6 – Um plano de implementação de melhorias nos processos é definido e executado, e os efeitos desta implementação são monitorados e confirmados com base nos objetivos de melhoria
Idéias sobre evidências: O plano de implementação é na essência o projeto de melhoria, aplicando o processo, como ilustrado na figura 03 abaixo. Poderíamos ter um projeto com um release e algumas sprints, como na figura mostrada. As melhorias cadastradas ou sugeridas ao SEPG ou via outras fontes são os backlogs deste projeto.
AMP7 - Ativos de processo organizacional são implantados na organização
Idéias sobre evidências: Esse resultado está relacionado ao anterior.Para cada processo ou sub-processo implementado, passarão a valer os seus produtos de trabalhos, procedimentos, templates, fórmulas, etc
AMP8 – Os processos padrão da organização são utilizados em projetos a serem iniciados e, se pertinente, em projetos em andamento
Idéias sobre evidências: Os processos padrão definidos para a organização deverão seguir os princípios de agilidade, com os ciclos de vida fortemente iterativos e incrementais. Como os projetos ágeis primam por ciclos curtos, a utilização de uma nova versão de processo e /ou de um artefato poderá ser aplicada em iterações do mesmo release, ou, se pertinente, em releases diferentes.
AMP9 - A implementação dos processos padrão da organização e o uso dos ativos de processo organizacional nos projetos são monitorados
Idéias sobre evidências: A monitoração da implementação dos processos padrão são feitas por ações de QA, medidas definidas sobre o uso do processo padrão, etc
AMP10 - Experiências relacionadas aos processos são incorporadas aos ativos de processo organizacional
Idéias sobre evidências: No Retrospective Meeting, normalmente obtem-se as lições aprendidas associadas àquele processo. Isso é feito via as perguntas
WWW-What went well? WCBI-What could be Improved?, com os devidos apontamentos de ações e responsáveis
A figura 02- mostra uma visão geral de implementação de AMP-DFP, ou seja a escrita de processos dentro do nível E. O grupo SEPG define um meta-processo que deverá ser seguido para a construção dos processos. Poderá ser um ciclo parecido com PDCA,IDEAL ou qualquer abordagem iterativo-incremental, como SCRUM, sendo esse o que adotaremos nessas linhas que mapeiam métodos ágeis com MPS. Com esse processo definido o SEPG desenvolve um Plano de Projeto de implementação(Release Plan de Processo). Esse plano conterá os objetivos de se implementar os processos, os principais passos(sprints) como revisão dos níveis anteriores, planejamento e priorização dos processos a serem escritos. A partir daí, iniciamos as diversas iterações para a construção de cada um dos conjuntos definidos. Ao final, teremos os processo(s) padrão escritos, que deverão ser usados nos projetos de software. Observem que o processo padrão poderá ser adaptado ao ser aplicado no projeto de software. Da mesma forma, o meta-processo, usado na escrita dos processos padrão da empresa poderá ser adaptado, conforme mostrado na figura 02.
A figura 03 ilustra o detalhamento dos ciclos de releases, de sprints e de daily scrum, que poderão ser usados na aplicação do método ágil para o desenvolvimento de processos MPS.BR.
