Te

Melhoria de Processos de Software com Mtodos geis e Modelo MPS
Boria et al.
Presidente da Repblica Dilma Vana Rousseff Ministro da Cincia, Tecnologia e Inovao Marco Antonio Raupp Secretrio de Poltica de Informtica Virglio Augusto Fernandes Almeida Coordenador Geral de Servios e Programas de Computador Rafael Henrique Rodrigues Moreira
Comit Editorial Ana Liddy Cenni de Castro Magalhes Ana Regina Cavalcanti da Rocha Christiane Gresse von Wangenheim Diva da Silva Marinho Gleison dos Santos Souza Kival Chaves Weber Marcos Vincius Amorim Ferreira Guimares Rodrigo Quites Reis Sandra Camargo Pinto Ferraz Fabbri
Boria et al.
Jorge Luis Boria Viviana Leonor Rubinstein Andrs Rubinstein
A Histria da Tahini-Tahini: Melhoria de Processos de Software com Mtodos geis e Modelo MPS
Julho 2013
Boria et al.
A Histria da Tahini-Tahini: Melhoria de Processos de Software com Mtodos geis e Modelo MPS N.9 (2013) Braslia Ministrio da Cincia, Tecnologia e Inovao Secretaria de Poltica de Informtica, 2013 201 p. ISSN 1679-1878 A Histria da Tahini-Tahini: Melhoria de Processos de Software com Mtodos geis e Modelo MPS I. Ministrio da Cincia. Tecnologia e Inovao Secretaria de Poltica de Informtica Jorge Luis Boria Viviana Leonor Rubinstein Andrs Rubinstein
Boria et al.
PREFCIO A discusso sobre a possibilidade ou no da utilizao de mtodos geis em conjunto com modelos de maturidades em processos de software frequente e atual. Alguns consideram que as exigncias dos modelos de maturidade no podem ser implementadas em organizaes com desenvolvimento gil. Outros consideram que a implementao destes modelos ir ferir a agilidade do desenvolvimento. Esta incompatibilidade discutida, portanto, por defensores do uso de mtodos geis e por defensores dos modelos de maturidade. Neste contexto se situa o livro A Histria da Tahini-Tahini: Melhoria de Processos de Software com Mtodos geis e Modelo MPS de Jorge Boria, Viviana Rubinstein e Andrs Rubinstein. O livro teve origem em uma chamada realizada em dezembro de 2011 pela Secretaria de Poltica de Informtica SEPIN, do Ministrio de Cincia, Tecnologia e Inovao MCTI, responsvel pela conduo do Programa Brasileiro de Qualidade e Produtividade em Software PBQP Software, para o Ciclo 2012 do Programa Srie de Livros do PBQP Software. Entre vrios concorrentes foi o texto selecionado para publicao. E foi, sem dvida, uma excelente escolha. Nele, os autores, a partir de sua riqussima experincia como consultores, avaliadores MPS e lead appraiser CMMI, nos mostram que no existem contradies entre modelos de maturidade, melhoria de processos e mtodos geis. Existe, pelo contrrio, um excelente caminho que pode ser trilhado com sucesso pelas organizaes at serem atingidos nveis muito altos de qualidade e maturidade nos processos de software. De acordo com os autores, o livro tem como objetivo mostrar como se inter-relacionam as tcnicas de consultoria, com os mtodos geis para atender aos resultados esperados do MRMPS-SW. Para isto utilizam quatro mtodos geis, Kanban, Scrum, XP e FDD ( Feature Driven Development), e a histria de Tahini-Tahini, uma empresa fictcia que certamente todos gostaramos que existisse. um livro tcnico, mas fascinante e de leitura muito agradvel. Por vezes nos leva a rir, tamanho o bom humor dos autores ao tratar o tema. Certamente ser um caso de sucesso, nesta excelente iniciativa do MCTI. Agradeo aos autores o convite para prefaciar um livro to interessante e com contribuies to importantes para a qualidade e a Engenharia de Software. Abril, 2013 Ana Regina Cavalcanti da Rocha Universidade Federal do Rio de Janeiro COPPE/UFRJ
Prefcio
Pgina i
Boria et al.
PRLOGO - CONSULTORIA EM MELHORIA DE PROCESSOS A Origem do Livro Este livro nasceu de um chamado realizado em dezembro de 2011 pela Secretaria de Poltica de Informtica SEPIN, do Ministrio de Cincia, Tecnologia e Inovao MCTI, responsvel pela conduo do Programa Brasileiro de Qualidade e Produtividade em Software PBQP Software, para seu Ciclo 2012 do Programa Srie de Livros de PBQP Software. Entre os temas nos quais era possvel apresentar propostas, um nos pareceu bastante til para os profissionais de engenharia de software: a Melhoria de Processos de Software com Mtodos geis e o Modelo MPS. Sobre os outros temas, de igual importncia, h muita literatura bsica e avanada. Fomos atrados pelo desafio de conciliar trs vertentes, tal a complexidade do tema. Estamos agradecidos a todos que intervieram no processo que levou seleo, edio e publicao deste livro. O Objetivo do Livro Este livro se coloca como livro de fico para profissionais. A empresa que usada como caso de sucesso no existe, nem existiu, esperamos que exista algum dia. Os personagens surgiram de amigos, conhecidos e situaes que alguma vez tenhamos vivenciado, como funcionrios, consultores ou donos de empresas de software. Seu objetivo ilustrar como se inter-relacionam as tcnicas de consultoria, capazes de facilitar o caminho quando bem feita, s vezes atuando como ensino-aprendizagem, nunca como uma ditadura; com os mtodos geis, que so muito mais que Scrum; para atender aos resultados esperados do MR-MPSSW. Este livro no um receiturio, no h nele nenhum algoritmo, nem sequer uma heurstica que permita a outros percorrerem o mesmo caminho que o dos protagonistas de nossa histria. No entanto, a proposta de utilizao que fazemos que todos possam aprender como identificar problemas e visualizar solues. Esperamos que os leitores apreciem a histria, porque ela est a para ajud-los a pensar nas situaes que ocorrem diariamente na indstria de software. Por ltimo, este livro no auto-suficiente. Ele exige que o leitor utilize as referncias bibliogrficas que apresentamos, seis pginas no total, de materiais superlativos. Se algo destacamos deste livro que a bibliografia vale a pena por si s. As Vertentes do Livro O ttulo deste livro mistura trs ideias poderosas. Fala de melhoria de processos com mtodos geis e do modelo de referncia para melhoria de processos de software MPS. Qualquer uma das trs ideias merece um livro independente, de maneira que escrever s um, e no curto prazo com que contaram os autores, implica uma escolha de contedos. Este um livro sobre as atividades que so realizadas em consultorias de melhoria de processos, embora a personagem principal que permite criar um fio condutor na histria seja uma mulher, Marcela, que trabalha como funcionria da empresa, suas atividades so as de uma consultora de primeiro nvel. Marcela encarna a herona do romance ingls do sculo XVIII que inteligente, sabe o que quer e sabe como conseguir. o exemplo de liderana deste livro, mesmo com os demais scios e companheiros de estrada sendo bons gerentes e excelentes profissionais, cada um com sua veia tcnica, Marcela que guia com o exemplo, que questiona o status quo, quem, em definitivo, leva a empresa Tahini-Tahini ao cume da qualidade. Quando escrevamos o livro era com Marcela que preferamos nos identificar, pois afinal era a personagem mais bemsucedida. As lies que devem ser aproveitadas deste livro se devem Marcela. No um livro de consultoria, estes existem e so muito bons, escritos por consultores melhores que ns. No entanto, h muitos conselhos sobre como realizar as coisas importantes, as que levam a mudanas srias, que esto contidas nas aes dos personagens. Tambm h muitssimas tcnicas que costumamos introduzir, de um modo ou de outro, em nossas consultorias. O Captulo 2 inicia o caminho mostrando variantes de mtodos de melhoria contnua, culminando com o mtodo Lean. Recomendamos leituras adicionais para poder entend-lo e aproveit-lo melhor. No um livro sobre o MPS, preferimos que o leitor aprenda sobre este robusto modelo nos seus prprios guias e nos cursos autorizados que so oferecidos. No entanto, no h nada no
Prlogo
Pgina ii
Boria et al.
livro que no tenha sido escrito com o MPS em mente. Toda a histria da Tahini-Tahini, os vaivens com as tcnicas, frequentemente apresentadas para sua discusso antes que possam ser aproveitadas, ilustram nosso ponto de vista sobre os modelos de maturidade, centrado no MPS: preciso ter a viso global do destino para que o caminho possa ser percorrido com comodidade. Tampouco um curso de mtodos geis. O leitor deve entender que, para introduzir um mtodo gil em uma organizao, preciso um consultor ou um mentor que guie a implantao dia a dia. Produzir uma organizao gil, a partir de uma que no , exige experincia e adaptao s necessidades da organizao. E embora no seja um livro sobre mudana organizacional, foi desta disciplina que tomamos emprestados muitos conceitos. De qualquer modo, a literatura de mudana organizacional muito vasta e muito rica, e lhe faramos pouca justia se tentssemos resumi-la nestas poucas pginas. O livro procura descrever as atividades de consultoria que acontecem em muitas organizaes. Os autores escolheram um mecanismo de apresentao do material que est no meio do caminho do livro tcnico e da narrativa de uma histria, o que permite que o leitor se divirta com os personagens. Esperamos que todos se entretenham com a leitura. Nota de Cautela Nenhum livro de qualidade pode deixar de citar Deming. Este super-homem da qualidade nos deixou dezenas de pensamentos e ideias para andar com maior comodidade seguindo seus passos. Neste Prlogo queremos lhe render uma pequena homenagem ao mesmo tempo em que usamos suas palavras para advertir o leitor do erro que muitas vezes cometido com o objetivo de conter gastos: O Obstculo de Deming, A esperana da sobremesa instantnea a suposio de que uma ou duas consultas com um estatstico competente colocaro a empresa no caminho da qualidade e da produtividade sobremesa instantnea. No to simples, sempre ser necessrio estudar e trabalhar. No somos estatsticos competentes, mas j vimos o mesmo sintoma em muitas empresas sendo traduzido em um convite para almoar em troca de um conselho gratuito que depois tenta-se colocar em prtica sem os conhecimentos necessrios. Os consultores no so insubstituveis, mas o conhecimento que trazem, este . Nota Sobre os Autores Um livro sempre uma criao coletiva. Tolkien falava do hmus que o autor junta para plantar suas ideias, hmus que fruto de suas leituras e experincias. As musas inspiradoras s trabalham em mentes abertas que passaram pelas experincias que enriquecem a vida, muitas vezes dolorosas. Mas, alm da herana, os autores sempre sentem obrigaes com muitas pessoas que possibilitaram o impossvel. Queremos agradecer especialmente a Ana Regina Cavalcanti da Rocha por sua confiana e amizade, a Kival Chaves Weber, Nelson Henrique Franco de Oliveira e Jos Antonio Antonioni pelo apoio e as oportunidades brindadas, e a Richard Denney pelo material emprestado.
Prlogo
Pgina iii
Boria et al.
Autores Jorge Luis Boria Master of Engineering in Computer Science pela Cornell University, Estados Unidos. Visiting Scientist do Software Engineering Institute da Carnegie-Mellon University. Senior Advisor do Modelo MPS. Avaliador Lder Experiente MPS. SCAMPI Lead Appraiser para alta maturidade. Instrutor certificado dos cursos do modelo CMMI. Foi Professor Titular das Universidades UBA, UNICEN, UNSL, USal, UB e outras na Argentina. Jorge quer agradecer especialmente a Joyce Statz pela formao que recebeu trabalhando para ela na TeraQuest Metrics. Joyce foi ao mesmo tempo amiga, formadora, orientadora e treinadora. Viviana Leonor Rubinstein Licenciada em Computao Cientfica pela UBA. Certified Project Manager, UT-SQI. Avaliador Lder Experiente MPS. SCAMPI Lead Appraiser DEV e SVC para alta maturidade. Instrutora certificada dos cursos do modelo CMMI. Foi Professora Titular nas Universidades UNS em Ushuaia, UBA, UNICEN e outras na Argentina. Viviana quer agradecer a Regina, sua me, com quem compartilhou a escrita de seu primeiro livro. Andrs Oscar Rubinstein Programador e Analista de Sistemas da Pontifcia Universidade Catlica do Rio de Janeiro. Avaliador Lder Intermedirio MPS. SCAMPI Lead Appraiser DEV e SVC. Scio da TecnoVoz S.A. Argentina. Foi professor e auxiliar docente na PUC-Rio e na Universidad de Belgrano e Colegio Nacional de Buenos Aires na Argentina. Andrs quer agradecer a Viviana e a Jorge pela confiana, a Adri e aos amigos de sempre pelo apoio, e a Male e a Nico por existirem. Finalmente, Jorge e Viviana querem agradecer a Beto e Franca por darem um novo sentido a suas vidas. E Viviana e Andrs agradecem a Jorge por sua liderana na confeco deste livro, sem a qual teria sido impossvel sua realizao.
Prlogo
Pgina iv
Boria et al.
Sumrio Prefcio ...................................................................................................................................... i Prlogo - Consultoria em Melhoria de Processos ..................................................................... ii A Origem do Livro.................................................................................................................. ii O Objetivo do Livro ............................................................................................................... ii As Vertentes do Livro ............................................................................................................ ii Nota de Cautela.................................................................................................................... iii Nota Sobre os Autores ......................................................................................................... iii Autores ..................................................................................................................................iv PARTE I Introduo Captulo 1 - Introduo ............................................................................................................. 1 1.1 O propsito do livro ........................................................................................................ 1 1.2 Definio de mtodo gil para este livro ........................................................................ 1 1.3 Se a melhoria de processos de software a resposta, qual a pergunta? .................... 1 1.4 Caso de estudo: A empresa Tahini-Tahini ....................................................................... 2 Captulo 2 - O Mtodo da Melhoria Contnua........................................................................... 6 2.1 Melhoria de processos .................................................................................................... 6 2.2 Plan-Do-Check-Act........................................................................................................... 8 2.3 O Mtodo IDEAL .............................................................................................................. 9 2.4 Focus-Improve-Sustain-Honor ...................................................................................... 11 2.5 Lean Simplified .............................................................................................................. 13 Captulo 3 - Os Mtodos geis: Kanban, Scrum, XP e FDD ..................................................... 16 3.1 O que so os mtodos geis? ........................................................................................ 16 3.2 Kanban: medindo o fluxo .............................................................................................. 17 3.3 Scrum: Organizando o sistema para um estado de equilbrio orgnico ....................... 21
Momentos da Verdade em um Scrum ........................................................................... 22
3.4 XP: Inspees, Design, Cooperao e Muitas Provas .................................................... 23

O Jogo do Planejamento ................................................................................................ 24 Pequenas Entregas ........................................................................................................ 24 Metfora ......................................................................................................................... 24 Design Simples .............................................................................................................. 24 Desenvolvimento Dirigido por Testes ............................................................................ 24 Refatorao .................................................................................................................... 25 Programao em Duplas (ou em Pares) ........................................................................ 25 Propriedade Coletiva (dos produtos pela equipe) .......................................................... 26
Sumrio
Pgina v
Boria et al.
Integrao Contnua ....................................................................................................... 26 Semana de 40 Horas (hoje chamada Passo Sustentvel) ............................................ 26 Cliente Presente ............................................................................................................. 26 Padres do Cdigo ......................................................................................................... 26 Escalonamento ............................................................................................................... 27
3.5 Feature Driven Development ........................................................................................ 27 3.6 Resumo .......................................................................................................................... 31 Captulo 4 - O Modelo de Melhoria de Processos de Software MPS-SW ............................... 32 4.1 Competir com a excelncia ........................................................................................... 32 4.2 Um caminho para a excelncia organizacional ............................................................. 33 4.3 Arquitetura do MPS....................................................................................................... 35 4.4 Os Nveis de Maturidade do MPS.................................................................................. 36 4.5 Para que a Mudana Acontea ..................................................................................... 38 4.6 Quando a mudana cultural ....................................................................................... 42 4.7 Avaliao do Estado de Maturidade ............................................................................. 44 PARTE II Primeiros Passos Captulo 5 - Uma Organizao com Problemas (Nvel G do MPS-SW) .................................... 45 5.1 A Pequena Histria de Tahini-Tahini ............................................................................. 45 5.2 Quem assume a responsabilidade? .............................................................................. 46 5.3 Mostrando a Carga de Trabalho e o Estado das Tarefas............................................... 49 5.4 Planejamento, Monitoramento e Controle do Projeto em Doses Homeopticas ........ 52 5.5 O Cliente quer Mudanas .............................................................................................. 53 5.6 Avanos na implementao do MPS-SW ...................................................................... 56 5.7 Preparando a Avaliao................................................................................................. 59 Captulo 6 - Uma Organizao em Crescimento ..................................................................... 63 6.1 Nvel F do MPS-SW ........................................................................................................ 63 6.2 Crescem os pedidos....................................................................................................... 63 6.3 Procurando Ajuda Fora da Tahini-Tahini ....................................................................... 63 6.4 O que deveramos fabricar? .......................................................................................... 67 6.5 Medindo resultados ...................................................................................................... 70 6.6 Protegendo os Ativos .................................................................................................... 76 6.7 Garantindo a Qualidade dos Processos e Produtos ...................................................... 78 6.8 A pequena fbrica de software com Scrum .................................................................. 80 Parte III Evoluo
Sumrio
Pgina vi
Boria et al.
Captulo 7 - Organizando a Organizao ................................................................................. 85 7.1 Nvel E do MR-MPS-SW ................................................................................................. 85 7.2 Uma Empresa em Franco Crescimento ......................................................................... 85 7.3 A Necessidade de Ativos de Processo ........................................................................... 93 7.4 Retrospectivas e processos ........................................................................................... 96 7.5 Diminuio de custos por reuso de componentes ........................................................ 98 7.6 Utilizando o conhecimento histrico nos projetos ....................................................... 99 Captulo 8 - Eliminando os Defeitos ...................................................................................... 102 8.1 Nvel D do MPS-SW ..................................................................................................... 102 8.2 Determinando o Problema .......................................................................................... 102 8.3 Busca da Soluo ......................................................................................................... 104 8.4 Corrigindo os Processos de Requisitos ........................................................................ 105 8.5 Perfil Operacional ........................................................................................................ 112 8.6 Detalhando Um Caso................................................................................................... 114 8.7 Detectando Defeitos nos Produtos ............................................................................. 117 8.8 Procedimentos de Verificao .................................................................................... 119 8.9 Revises ....................................................................................................................... 121 8.10 Atividades do Processo de Inspeo ......................................................................... 121
Reunio de Instruo ................................................................................................... 122 Inspeo Individual do Produto .................................................................................... 122 Reunio de Unificao ................................................................................................. 122 Deciso sobre o Produto .............................................................................................. 123 Retrabalho e Concluso ............................................................................................... 123 Informe Final................................................................................................................. 123
8.11 Fatores Crticos de Sucesso ....................................................................................... 124 8.12 Fatores de Fracasso ................................................................................................... 124 8.13 Diferenas Entre Inspees, Walkthrough e Revises Estruturadas ........................ 124 8.14 Usos geis ................................................................................................................. 126 8.15 Testes de Produto ..................................................................................................... 126 8.16 Critrios Relacionados com Testes............................................................................ 127 8.17 Cobertura .................................................................................................................. 128 8.18 Projeto e Construo................................................................................................. 134 8.19 Integrao ................................................................................................................. 137 Captulo 9 - Ampliando a Capacidade de Deciso (Nvel C do MPS-sw) ............................... 140
Sumrio
Pgina vii
Boria et al.
9.1 Uma Gesto Ambiciosa ............................................................................................... 140 9.2 Lder em Ao .............................................................................................................. 140 9.3 Viso Estratgica dos Riscos ........................................................................................ 141 9.4 Definio de um Risco ................................................................................................. 143 9.5 Captura dos Riscos ...................................................................................................... 144 9.6 Estratgias de Controle de Riscos ............................................................................... 145 9.7 Estratgia Conjunta ..................................................................................................... 146 9.8 Nota de Cautela ........................................................................................................... 147 9.9 Decises Formais ......................................................................................................... 148 9.10 A Fbrica de Componentes ....................................................................................... 153 9.11 Service Oriented Architecture (SOA) para Principiantes ........................................... 154 9.12 Montando a Fbrica .................................................................................................. 156 9.13 O nvel C do MPS ....................................................................................................... 157 Parte IV Apogeu Captulo 10 - Estabilizar para a Melhoria Contnua............................................................... 159 10.1 Nveis B e A do MPS................................................................................................... 159 10.2 Estabilidade ............................................................................................................... 159 10.3 Eliminando Aleatoriedade ......................................................................................... 161 10.4 O Cu Desaba ............................................................................................................ 161 10.5 Conteno ................................................................................................................. 164 10.6 Causas-Raiz ................................................................................................................ 164 10.7 A Previso Como Ferramenta ................................................................................... 166 10.8 Previso e Anlise...................................................................................................... 166 10.9 Correlao e Regresso ............................................................................................. 168 10.10 Identificao de processos crticos ......................................................................... 169 10.11 Processos Capazes ................................................................................................... 172 10.12 Baselines .................................................................................................................. 173 10.13 Indicadores Lderes ................................................................................................. 173 10.14 Composio do Processo Definido do Projeto ........................................................ 174 10.15 Gesto Quantitativa ................................................................................................ 174 10.16 A Melhoria Contnua Como Estratgia de Negcio ................................................. 175 10.17 Custo de Competir .................................................................................................. 175 10.18 Inovao tecnolgica............................................................................................... 175
Sumrio
Pgina viii
Boria et al.
Captulo 11 - Concluses ....................................................................................................... 179 Referncias Bibliogrficas ..................................................................................................... 180
Sumrio
Pgina ix
Boria et al.
Lista de Figuras
Figura 1.1: Relao entre ferramentas e competncia das pessoas............................................ 2 Figura 2.1: O Mtodo IDEAL (adaptado de [McFEELEY, 1996]) .................................................. 9 Figura 2.2: Viso de Melhoria de Processos do IDEAL (adaptado de [McFEELEY, 1996]) ...... 11 Figura 3.1: Painel kanban ........................................................................................................... 18 Figura 3.2: Nota do Painel kanban .............................................................................................. 19 Figura 3.3: Processo Scrum ........................................................................................................ 22 Figura 3.4: Ciclo de Desenvolvimento de XP .............................................................................. 25 Figura 3.5: Ciclo de Desenvolvimento de FDD ........................................................................... 28 Figura 3.6: rvore de Funes derivada da Arquitetura ............................................................. 30 Figura 4.1: Relao da Refatorao vs. Nvel do CMM [DIAZ e KING, 2002] ........................... 32 Figura 4.2: Organizao do MPS.BR [SOFTEX, 2011l] ............................................................. 34 Figura 4.3: Componentes do Modelo MPS [SOFTEX, 2012a] ................................................... 34 Figura 4.4: Nveis de maturidade do MR-MPS-SW [SOFTEX, 2012a] ....................................... 35 Figura 4.5: Estrutura do MPS [SOFTEX, 2011l] ......................................................................... 36 Figura 4.6: Sequencia da Resistncia Mudana (adaptado de [KUBLER-ROSS, 1997]) ....... 39 Figura 4.7: Modelo de Transio Ilusria (1) .............................................................................. 40 Figura 4.8: Modelo de Transio Ilusria (2) .............................................................................. 40 Figura 4.9: Modelo de Transio Administrada .......................................................................... 40 Figura 4.10: Modelo de Transio Sem Administrar ................................................................... 41 Figura 4.11: Passos do Comprometimento (adaptado de [CONNER 1982]) ............................. 41 Figura 4.12: Valores em Competncia (adaptado de [CAMERON e QUINN, 2011]) ................. 43 Figura 5.1: Causas da Falta de Conhecimento do Estado do Projeto ........................................ 47 Figura 5.2: Painel kanban elementar .......................................................................................... 50 Figura 5.3: Painel kanban com ciclo de vida das histrias -1- .................................................... 50 Figura 5.4: Histria no Painel kanban ......................................................................................... 51 Figura 5.5: Painel kanban com ciclo de vida das histrias -2- .................................................... 53 Figura 5.6: Planilha para Definio de Histrias ......................................................................... 54 Figura 5.7: Planilha para Definio e Anlise de Riscos ............................................................ 55 Figura 5.8: Planilha de Proposta de Projeto ............................................................................... 55 Figura 5.9: Diagrama de Raias ................................................................................................... 58 Figura 5.10: Planilha de Detalhamento de um Procedimento .................................................... 61 Figura 5.11: Evidncias para GPR no Nvel G ............................................................................ 62 Figura 6.1: Diagrama Ishikawa sobre Crescimento 1 ................................................................. 64 Figura 6.2: Diagrama Ishikawa sobre Crescimento 2 ................................................................. 64 Figura 6.3: Organograma da Tahini-Tahini ................................................................................. 70 Figura 6.4: Dados vs. Informao ............................................................................................... 71 Figura 6.5: Grfico sobre Preos Futuros do Petrleo ............................................................... 72 Figura 6.6: Processo de Auditoria da Qualidade ........................................................................ 80 Figura 6.7: A Morte do Scrum ..................................................................................................... 81 Figura 6.8: Cobertura dos Resultados Esperados com Scrum e Kanban .................................. 82 Figura 7.1: Formulrio Completo Misso e Funo para Engenheiro de Teste ......................... 87 Figura 7.2: Anlise de Opes sobre Reuso .............................................................................. 99 Figura 8.1: Estrutura Tpica de uma Folha de Resultados Equilibrados .................................. 103 Figura 8.2: Diagrama de Contexto de um Sistema ................................................................... 106 Figura 8.3: Diagrama de Classe de Acordo .............................................................................. 107 Figura 8.4: Diagrama de Classes de Acordo ............................................................................ 108 Figura 8.5: Processo de Captura de Requisitos ....................................................................... 110 Figura 8.6: Resultado dos Passos 1 e 2 ................................................................................... 110 Figura 8.7: Diagrama de Arquitetura ......................................................................................... 111 Figura 8.8: Modelo V de Desenvolvimento de Software ........................................................... 120 Figura 8.9: Zona de Caos por Postergao de Atividades de Remoo .................................. 120 Figura 8.10: Modelo em V com Revises entre Atividades de Traduo ................................. 121 Figura 8.11: Diagrama de Fluxo do Caso de Uso da Tabela 8.14 ............................................ 129 Figura 8.12: Diagrama de Fluxo de Controle com Funcionalidade Abstrada .......................... 129 Figura 8.13 Caminho Feliz ........................................................................................................ 130 Figura 8.14 Primeira rea Fechada .......................................................................................... 130 Figura 8.15 Segunda rea Fechada ......................................................................................... 131 Figura 8.16 Terceira rea Fechada .......................................................................................... 131 Figura 8.17 Quarta rea Fechada............................................................................................. 131
Lista de Figuras
Pgina x
Boria et al.
Figura 8.18 Quinta rea Fechada ............................................................................................. 131 Figura 8.19 Sexta rea Fechada .............................................................................................. 132 Figura 8.20 Todas as reas Fechadas ..................................................................................... 132 Figura 8.21: Probabilidade de Cada Transio do Grafo ......................................................... 133 Figura 9.1: rvore de Deciso ................................................................................................... 141 Figura 9.2: Planilha de Definio, Monitorao e Controle de Riscos ...................................... 144 Figura 9.3: Matriz de Riscos ...................................................................................................... 146 Figura 9.4: rvore de Objetivos................................................................................................. 150 Figura 9.5: rvore de Deciso Refinada ................................................................................... 151 Figura 9.6: Tabela de Pagamentos Correspondente rvore de Deciso Refinada ............... 151 Figura 9.7: Diagrama de Influncias com Incluso de Outros Investimentos ........................... 152 Figura 9.8: Diagrama de Tornado ............................................................................................. 153 Figura 9.9: Ilustrao da Arquitetura SOA ................................................................................ 156 Figura 10.1: Distribuies de Esforo de Tarefas Semelhantes em Duas Populaes ........... 160 Figura 10.2: Distribuio do Erro em Dois Relgios ................................................................. 161 Figura 10.3: O Mtodo das Oito Disciplinas .............................................................................. 163 Figura 10.4: Curvas da Famlia Weibull .................................................................................... 167 Figura 10.5: Zonas de SPC Sob a Distribuio Normal ............................................................ 167 Figura 10.6: Diagrama do Modelo de Kano .............................................................................. 169 Figura 10.7: Barreiras Qualidade ........................................................................................... 170 Figura 10.8: Anlise de Fatores CTQ ....................................................................................... 171 Figura 10.9: BSC Aplicado a Identificar Processos Crticos ..................................................... 171 Figura 10.10: Fatores Na Escolha de Processos Crticos ........................................................ 172 Figura 10.11: Processos Capazes e Processos Estveis ........................................................ 173 Figura 10.12: Indicadores Lderes ............................................................................................ 173 Figura 10.13: Diferentes Possibilidades de Composio do Processo .................................... 174 Figura 10.14: Definio de Adjacncias e Espao em Branco Segundo Johnson ................... 176 Figura 10.15: Construir-Medir-Aprender ................................................................................... 177 Figura 10.16: Diagrama de Pareto de Defeitos de Cdigo ....................................................... 177
Lista de Figuras
Pgina xi
Boria et al.
Lista de Tabelas
Tabela 2.1: Seleo do Mtodo de Melhoria de Processos ....................................................... 15 Tabela 5.1: Tamanhos de Tarefas .............................................................................................. 51 Tabela 5.2 Processo GERNCIA DE PROJETOS no Nvel G [SOFTEX, 2012a] ..................... 57 Tabela 5.3 Processo GERNCIA DE REQUISITOS [SOFTEX, 2012a]..................................... 59 Tabela 6.1: Pensamentos Negativos sobre a Mudana ............................................................. 64 Tabela 6.2: Preparando-nos para Crescer .................................................................................. 65 Tabela 6.3: Processo AQUISIO [SOFTEX, 2012a] ................................................................ 66 Tabela 6.4: Matriz de Pugh sobre Propostas .............................................................................. 68 Tabela 6.5: Riscos do Crescimento ............................................................................................ 69 Tabela 6.6: Processo GERNCIA DE PORTFLIO DE PROJETOS [SOFTEX, 2012a] .......... 70 Tabela 6.7: Misso e Funes .................................................................................................... 71 Tabela 6.8: Riscos Associados ................................................................................................... 73 Tabela 6.9: Processo MEDIO [SOFTEX, 2012a] ................................................................... 74 Tabela 6.10: Definio de Medidas ............................................................................................. 74 Tabela 6.11: Definio de Indicadores ........................................................................................ 76 Tabela 6.12: Riscos Derivados da Falta de Controle de Ativos .................................................. 76 Tabela 6.13: Propriedades de Cada Tipo de Item de Configurao........................................... 77 Tabela 6.14: Processo GERNCIA DE CONFIGURAO [SOFTEX, 2012a] .......................... 78 Tabela 6.15: Riscos de no Auditar ............................................................................................ 79 Tabela 6.16: Severidade de No conformidades em Auditorias ................................................. 79 Tabela 6.17: Processo GARANTIA DA QUALIDADE [SOFTEX, 2012a] ................................... 80 Tabela 7.1: Atividades de Recrutamento e Incorporao de Pessoal ........................................ 89 Tabela 7.2: Porcentagem de xito em Atividades Selecionadas por Tipo de Cargo ................. 90 2 Tabela 7.3: Riscos da T Derivados de Polticas Pobres em Recursos Humanos ..................... 90 Tabela 7.4: Primeira Parte de um Modelo de Competncias ..................................................... 92 Tabela 7.5: Lista de Avaliao Correspondente Primeira Tarefa ............................................ 92 Tabela 7.6: Processo GERNCIA DE RECURSOS HUMANOS [SOFTEX, 2012a] .................. 93 Tabela 7.7: Orientao Sugerida por Perfil de Sprint ................................................................. 96 Tabela 7.8: Processo DEFINIO DO PROCESSO ORGANIZACIONAL [SOFTEX, 2012a] ... 96 Tabela 7.9: Processo AVALIAO E MELHORIA DO PROCESSO ORGANIZACIONAL [SOFTEX, 2012a] ........................................................................................................................ 97 Tabela 7.10: Processo GERNCIA DE REUTILIZAO [SOFTEX, 2012a] ............................. 99 Tabela 7.11: Processo GERNCIA DE PROJETOS (a partir do nvel E) [SOFTEX, 2012a] ... 101 Tabela 8.1: Problemas de Requisitos ....................................................................................... 105 Tabela 8.2: Comparao entre Mtodos de Desenvolvimento pelo Benefcio ......................... 109 Tabela 8.3: Comparao entre Mtodos de Desenvolvimento pelo Risco ............................... 109 Tabela 8.4: Matriz CRUD sem Completar ................................................................................. 111 Tabela 8.5: Matriz CRUD j Completada .................................................................................. 112 Tabela 8.6: Estimativas de Atividade ........................................................................................ 113 Tabela 8.7: Perfil Operacional dos Casos de Uso .................................................................... 113 Tabela 8.8: Componentes Sugeridos dos Casos de Uso ......................................................... 115 Tabela 8.9: Lista de Controle de Mitigao de Riscos em Requisitos ...................................... 116 2 Tabela 8.10: Implementao de DESENVOLVIMENTO DE REQUISITOS na T .................... 117 Tabela 8.11: Problemas de Validao ...................................................................................... 118 Tabela 8.12: Problemas de Verificao .................................................................................... 119 Tabela 8.13: Comparao entre Revises ................................................................................ 125 Tabela 8.14: Planilha de Registro de Questes ........................................................................ 126 Tabela 8.15: Exemplo de Sequncia Principal e Alternativa de um CDU ................................ 128 2 Tabela 8.16 Resultados Esperados de VERIFICAO e Atividades Internas em T .............. 134 2 Tabela 8.17: Resultados Esperados de VALIDAO e Atividades Internas em T ................. 134 Tabela 8.18 Processo PROJETO E CONSTRUO DO PRODUTO [SOFTEX, 2012a ] ....... 135 Tabela 8.19: Problemas de Design ........................................................................................... 135 Tabela 8.20: Anlise de Opes sobre Design ......................................................................... 136 Tabela 8.21: Cobertura de Resultados Esperados de PCP ..................................................... 137 Tabela 8.22: Aes Relacionadas com Integrao, Derivadas de Retrospectivas .................. 138 Tabela 9.1: Tabela de Pagamentos da rvore de Deciso ...................................................... 141 Tabela 9.2: Estratgia de Riscos de Alto Nvel, Fontes e Categoria ........................................ 143 Tabela 9.3: Exemplo de Tabela (Parcial) de Riscos ................................................................. 147 Tabela 9.4: Definio dos Passos do PAAeTdD ....................................................................... 149
Lista de Tabelas
Pgina xii
Boria et al.
Tabela 10.1: Os Problemas do Projeto Fora de Controle ......................................................... 165 Tabela 10.2: A ltima Fila da Anlise depois de Completa ...................................................... 168
Lista de Tabelas
Pgina xiii
Boria et al.
PARTE I Introduo
CAPTULO 1 - INTRODUO 1.1 O propsito do livro Este livro dirigido a (em ordem crescente de interesse): implementadores de melhoria de processos de software que queiram conhecer melhor os mtodos geis para implant-los em organizaes da rea; gerentes de projeto interessados em conhecer melhor os mtodos geis para desenvolvimento de software, seja para adot-los ou para avaliar a sua adoo; engenheiros de software que tentam trabalhar em um projeto gil; professores de graduao em Computao; estudantes de graduao em Computao; professores de ps-graduao em Engenharia de Software; estudantes de ps graduao em Engenharia de Software.
Na medida que os mtodos geis e os modelos de maturidade tm sido considerados termos opostos nas disciplinas de desenvolvimento e manuteno de software, difcil conceber um texto que tente fazer a ponte entre os dois mundos. J foi feito, porm, com grande sucesso, no moderno clssico [BOEHM e TURNER, 2003]. O modelo de referncia para eles o CMMI, sendo fcil imaginar a passagem para o MR-MPS-SW, dada a intencional compatibilidade entre os dois modelos. 1.2 Definio de mtodo gil para este livro Este livro est focado, principalmente, em quatro mtodos geis : Kanban, Scrum, XP e FDD (Feature Driven Development). A escolha no por acaso. Esses quatro mtodos cobrem a maioria das implementaes geis realizadas no mundo. Alm disso, eles cobrem quase todas, se no todas, as necessidades de uso de mtodos geis. Cada um destes mtodos ser devidamente explicado no Captulo 3. Obviamente, isto ocorrer em ordem crescente de complexidade: primeiro o mais simples e o que tem o maior retorno em comparao ao investimento, o Kanban. Ele possui grande retorno porque, ao organizar as tarefas e detectar rapidamente os problemas, permite equipe que o utiliza aumentar o tempo disponvel para aprimorar seus processos e tentar novas melhorias. Scrum, que frequentemente o mtodo eleito desde o comeo, aqui s visto quando a empresa conseguiu se estabilizar o suficiente para ter tempo de conseguir que as atividades do Scrum possam ser seguidas com a disciplina necessria. Os outros dois mtodos se somam aos anteriores medida em que a empresa ganhe em definio de seus processos e no nmero de seus colaboradores. 1.3 Se a melhoria de processos de software a resposta, qual a pergunta? O principal inimigo de uma empresa desenvolvedora de software a baixa qualidade. At hoje, ningum desenvolveu uma proposta vlida para melhorar a qualidade que no fosse relacionada melhoria de processos, que passa a ser ento a questo principal. possvel argumentar que as pessoas e as ferramentas (de software, como CASE) so importantes em seu impulso para a melhoria da produtividade. Isto verdade, mas s quando os processos esto no lugar onde se consiga o aproveitamento das condies dos indivduos e das
1
As principais referncias de cada um dos mtodos esto indicadas quando se descreve cada um nos captulos seguintes.
Capitulo 1
Pgina 1

2
Boria et al.
ferramentas de software. comum o caso de empresas e organizaes que no aproveitam seus recursos humanos e tm licenas que no so usadas. Por isso deduzimos que, por mais importante que sejam as ferramentas e as competncias das pessoas, so os processos que, realmente, tornam possvel o aumento de produtividade. Na Figura 1.1 simbolizamos isto com cones. Na primeira equao, as pessoas capacitadas, somadas s ferramentas de software e a processos bem definidos culminam (depois do sinal de igual) em sucesso e felicidade. Na segunda equao, a falta de processos bem definidos aumenta os riscos e produz frequentes problemas nos produtos resultantes.
Figura 1.1: Relao entre ferramentas e competncia das pessoas
A disciplina induzida pelos processos a que permite aproveitar os conhecimentos e as ferramentas. Sem esta disciplina no possvel reproduzir os sucessos que podem ser alcanados pelos projetos, porque a memria organizacional perdida. 1.4 Caso de estudo: A empresa Tahini-Tahini Neste livro, acompanhamos o desenvolvimento de uma organizao que nasce de uma ideia de estudantes universitrios. A empresa criada pequena e, como uma piada entre eles, recebe o nome de Tahni-Tahni. O nome surgiu quando uma das fundadoras chegou reunio de criao um pouco atrasada e ao olhar o nmero de pessoas ao redor da mesa disse: Somos uma empresa tiny-tiny. Seus futuros scios acharam isso engraado e colocaram o nome de Tahni-Tahni, fazendo um duplo jogo de palavras. No livro, geralmente vamos nos 2 referir a ela pelas siglas que seus scios usam para cham-la: T , TT ou o Duplo T. Como toda empresa recm-nascida, criada por jovens empreendedores, no foi seguido um plano de crescimento ideal; na verdade ela cresceu aos trancos e os mares agitados que tiveram de contornar foi o que a fortaleceu. Os problemas da empresa no so incomuns, so os mais frequentes para uma organizao desse tamanho e com essa histria, em cada etapa de seu crescimento. A cada passo, os scios tiveram de tomar decises que afetaram os resultados e, a cada oportunidade, alteraram os processos que guiavam o desenvolvimento do produto. Em cada caso quiseram aprimorar a qualidade e o controle dos processos para melhorar a qualidade e o controle sobre o produto. Durante o desenvolvimento do caso de estudo utilizaremos a descrio de Kanban para o incio de um projeto de melhoria de processos; Scrum em relao s atividades de gerncia de projetos mais abrangentes; XP (Extreme Programming) para o que constitui a categoria das reas de engenharia tratadas no nvel D (Largamente Definido) do MR-MPS-SW. Quando uma empresa cresce, os mtodos anteriores comeam a apresentar limitaes. A coordenao de muitos grupos em Scrum de Scrums apresenta maiores limitaes que os mtodos tradicionais. 2 XP difcil de controlar. Acompanhando o crescimento da T , a proposta um mtodo baseado no Feature Driven Development (FDD). Em torno da questo da mudana organizacional, seguiremos o caminho do mtodo Lean, que se concentra principalmente na resoluo de problemas por meio da melhoria de processos.
2
Neste livro utilizaremos o termo organizao para nos referir a todo tipo de grupo humano organizado para a realizao de tarefas com um propsito comum, seja com ou sem fins lucrativos.
Capitulo 1
Pgina 2
Boria et al.
Neste captulo tambm descrevemos os captulos restantes. Cada captulo que faz referncia a um nvel do MR-MPS-SW explica os resultados requeridos dos processos seguindo as exigncias do modelo. O livro est dividido em quatro partes, cada uma atendendo a uma necessidade diferente. Na primeira parte (Captulos 1 a 4) esto colocadas as bases para que o leitor possa compreender os mtodos e a filosofia de trabalho que os autores propem. A segunda parte (Captulos 5 e 6) trata dos temas de baixa maturidade (Nveis G e F do MPS) e 2 introduz em detalhes os primeiros passos da T e a soluo encontrada pelos scios com base no uso de Kanban e Scrum. A terceira parte (Captulos 7 a 9) desenvolve a temtica da Maturidade Mdia, os nveis E, D, e C do Modelo MPS-SW, onde aparecem XP e mais adiante 2 FDD. Finalmente, a quarta parte (Captulos 10 e 11) expe como a maturidade definida da T permite alcanar um conhecimento profundo do funcionamento de seus processos, 2 caracterizando-os quantitativamente. O livro termina com um resumo da viagem da T desde sua criao at sua venda bilionria. No Captulo 2 explicamos nossa filosofia de melhoria de processos. Para isso, utilizamos o mtodo Lean, palavra inglesa que significa enxuto, porque o que melhor se adapta s nossas ideias. Adotando mensagens de diversas fontes, explicamos como melhor fazer o mnimo possvel para resolver um problema do que fazer grandes mudanas sem efeito aparente. Tambm aproveitamos o Captulo 2 para falar de uma viso sistmica das organizaes e da relao multicausal dos eventos. Deste modo, preparamos o leitor para entender porque uma s ao pode resolver muitos problemas e como s vezes necessrio aplicar mltiplas aes (e esperar) para obter resultados. O livro Leading Lean Software Development de [POPPENDIECK et al., 2010], nosso guia por este territrio. Tambm, onde for til, citaremos material de Thinking in Systems, A Primer do clssico de [MEADOWS, 2008]. Os dois livros revolucionam o pensamento clssico, linear, dos gerentes tradicionais, e abrem a porta a uma gerncia mais gil, mais integrada e com maiores possibilidades de sucesso. No Captulo 3 apresentamos os mtodos geis propriamente ditos. Apesar de Lean ser um 3 mtodo gil segundo seus criadores, e reconhecido como tal pela comunidade gil , seu uso exige muito conhecimento e est fora do escopo deste livro. Por outro lado, as tcnicas propostas por Kanban, Scrum, XP (Extreme Programming) e Feature Driven Development (FDD) so igualmente bem-sucedidas e muito mais fceis de adotar, sobretudo se forem feitas na ordem proposta neste livro. Esta uma introduo aos mtodos e, em nenhum momento, deve substituir a leitura dos textos clssicos sobre o tema, os quais esto listados na bibliografia e so recomendados ao leitor. O Captulo 4 est dedicado ao eixo central deste livro, o modelo de Melhoria de Processos de Software (MR-MPS-SW). Outra vez, o livro incapaz de conter todo o conhecimento necessrio para fazer um bom uso do modelo, de modo que indicamos ao leitor os guias 4 publicados pela SOFTEX e que se encontram acessveis no website desta organizao . Os guias so material indispensvel para o leitor que quer seguir nossas sugestes e implementar mtodos geis com o MPS. O que exploraremos profundamente so as grandes pinceladas que precisam ser entendidas para que o modelo faa sentido e ningum se perca nos detalhes que devem ser aplicados. Vamos tratar da evoluo da cultura existente na empresa, induzida pelo amadurecimento dos processos por meio da manifestao de mudana seguindo os nveis de maturidade do modelo, conceito em que nos deteremos neste captulo, assim como na arquitetura do modelo que permite encontrar nele as ferramentas para sua implementao. Para concluir o captulo, explicaremos o conceito de avaliao e como uma organizao pode aplic-lo a si mesma, para entender onde se encontra e que caminho lhe falta percorrer. O Captulo 5 apresenta o detalhe dos problemas iniciais da T . Utilizando exemplos que foram encontrados em sua atuao como consultores e avaliadores de processos, os autores apresentam ao leitor os problemas tpicos de uma empresa que funciona bem quando todas as coisas esto no caminho certo. Os pequenos problemas cotidianos (uma gravidez, uma regio sem recepo telefnica, um cliente apressado) podem desencadear uma tormenta 2 perfeita que acaba arruinando at mesmo a melhor reputao. a que os amigos da T decidem introduzir mtodos de controle e, aconselhados corretamente, comeam a utilizar Kanban. Ao mesmo tempo, conseguem implantar sem muito esforo extra, processos do
2
3 4
A comunidade gil se reconhece no website: http://www.agilemanifesto.org/ http://www.softex.br/mpsbr/_guias/default.asp
Capitulo 1
Pgina 3
Boria et al.
modelo MPS. Tentados pela facilidade com que implementaram os processos do Nvel G, os scios decidem realizar uma avaliao formal com um avaliador lder e passam com sucesso. 2 A adoo do MPS pela empresa T agora um fato. No Captulo 6, os autores contam como os scios, alentados pelo sucesso obtido por suas melhorias de processo, decidem aprofundar o caminho e utilizam o modelo MPS para isso. Os controles estabelecidos abrem espao para a gerncia de configurao que, de forma INICIAL, comeou a ser implementada no nvel G; para a medio que, devido formao profissional dos scios, considerada uma atividade fundamental para controlar e dirigir a empresa; e para o controle da qualidade, imposto pela realidade. A chegada de novos clientes com pedidos de projetos, que so s vezes de adaptao e s vezes de novos desenvolvimentos, faz com que os processos da gerncia de portflio de projetos sejam valiosos para entender como organizar o crescimento da demanda. Este crescimento faz com que dois caminhos sejam avaliados: crescer internamente, o que significaria ampliar o espao fsico para admitir mais desenvolvedores, com o consequente investimento fixo; ou subcontratar parte do trabalho. Para tomar a deciso, os scios se apoiam no processo de aquisio e decidem a favor da subcontratao, o que os leva a implementar este processo. Ainda assim, a pequena equipe inicial deve se dividir para atender o novo volume de trabalho, e incorporam um pequeno nmero de desenvolvedores. Para organizar os projetos, os scios decidem utilizar prticas de Scrum, que so compatveis com o MPS. Para 2 assegurar-se de que est no caminho certo, a T passa por uma nova avaliao e alcana o Nvel F. No Captulo 7 comea a terceira parte, que desenvolve os processos intermedirios do modelo MPS. medida que se expandem os negcios e novas oportunidades surgem, os scios se veem obrigados a expandir, da mesma forma, seus escritrios. Uma reunio fundamental os 2 coloca em uma encruzilhada: para onde queremos levar a T ? Finalmente, decidem criar uma viso ambiciosa: ser uma das dez melhores fbricas de software do mundo. Preparando-se para o crescimento, os scios entendem que a viso deles complementada com uma base de conhecimentos que pode ser compartilhada, usada e expandida por todos os engenheiros e demais funcionrios da empresa. Seus processos de gesto evoluem da mesma forma, para aproveitar este conhecimento de maneira sistemtica. De maneira natural surge, na base de conhecimentos, a definio dos processos organizacionais. Quando os colaboradores da T superam um nmero considerado crtico de maneira arbitrria, as reunies de processo se sistematizam e se formalizam em um projeto para sua avaliao e melhoria permanente. As constantes incorporaes foram, da mesma maneira, a organizao a tratar da identificao, captao, preparao e reteno dos recursos humanos. Em todas estas tarefas, o MPS acaba sendo fundamental e indispensvel, ao dar um marco coerente e as pautas culturais para crescer. O resultado uma organizao que aprende, com colaboradores motivados, que continuamente fazem propostas de melhoria dos seus prprios 2 processos e tambm dos demais. Uma iniciativa brilhante sai de uma destas propostas e a T incorpora prticas de reuso para melhorar ainda mais a qualidade de seus produtos e o rendimento de seu pessoal. No segundo captulo da terceira parte, o Captulo 8, apresentamos as tcnicas e prticas de Extreme Programming (XP) que no se sobrepem s anteriores j incorporadas. Uma discusso em retrospectiva leva a identificar a variao na interpretao das tcnicas de desenvolvimento nas equipes como a fonte de diferenas entre as estimativas iniciais, agora desenvolvidas a partir da histria e dos resultados reais. Discutindo na reunio do grupo de processos organizacionais vincula-se, da mesma forma, essa indefinio com um conjunto de defeitos que esto saindo repetidamente ao mercado. Uma proposta de adoo do XP recebida sem muito entusiasmo, mas de todo modo implementada, cuidando de que, ao fazer isso, sejam respeitadas as condies para continuar cumprindo com a implementao de processos de MPS. Isto leva a algumas variantes, como por exemplo que pair programming, a tcnica por meio da qual dois programadores trabalham juntos em um mesmo programa, seja implementada com um coach que registra os defeitos encontrados para permitir a realizao de suas anlises. As equipes incorporam, igualmente, software de controle e introduzem variantes aos processos para continuar avanando e permanecer dentro do marco do MPS. Confrontados com a realidade de seu crescimento e os riscos que ela traz, os scios incorporam uma viso estratgica de seu negcio e, mais uma vez, fazem isso seguindo o 2 modelo. No Captulo 9, introduzida a viso do risco como constante. A T no define a si
2
Capitulo 1
Pgina 4
Boria et al.
mesma como uma empresa que quer evitar os riscos, mas conhec-los e enfrent-los. Desse modo, capaz de se preparar melhor para afrontar o que a realidade colocar em seu caminho. Os riscos assim analisados so melhor enfrentados e a capacidade desenvolvida de melhoria de processos , nesse sentido, uma ferramenta. Por exemplo, ao invs de aproveitar de forma oportuna o reuso quando aparece uma necessidade de reusar partes j existentes nos projetos 2 concludos, a T organiza uma fbrica de componentes que podem ser articulados rapidamente para formar produtos, reduzindo ainda mais seus defeitos por elemento e aumentando a nveis muito altos sua produtividade. Cada deciso tem um custo e um benefcio, mas at este 2 momento na histria da T no se aprendia sistematicamente a partir das decises j tomadas. 2 Para evitar que esse conhecimento se perca, a T incorpora mtodos formais de deciso que incluem vrias tcnicas que aproveitam dados histricos. Logo, so usados por projetos para tomar decises sobre a velocidade, a qualidade esperada, o reuso e a subcontratao de 2 terceiros. A T j uma organizao com centenas de funcionrios e possui slida reputao de qualidade. Os contatos e indicaes obtidos por referncia de outros clientes comeam a ser internacionais. Devido a esse crescimento e ao consequente distanciamento fsico dos 2 clientes, a T acrescentou a seu arsenal o mtodo FDD, que permite planejar os sprints com 2 maior preciso. A T decide ser avaliada em relao ao Nvel C do modelo MPS, em uma avaliao conjunta com o Nvel Definido do modelo CMMI-DEV, o que consegue com incrvel sucesso. Ao ingressar na Quarta Parte do livro, encontramos a T em seu apogeu. Abre escritrios em vrios pases centrais, tem centros de desenvolvimento em todas as regies do Brasil e da Amrica Latina, e desfruta de um merecido prestgio. No entanto, os scios no descansam em seus louros. No Captulo 10, vemos como aproveitam a base de dados histrica que construram ao longo dos anos para utiliz-la a seu favor. Identificam os processos crticos que se relacionam com seus objetivos de negcio, analisam sua estabilidade relativa, constroem modelos que permitem prever resultados futuros em pontos iniciais de um projeto e ajudam a corrigir problemas. Estendem as tcnicas que empregam na tomada de decises para incluir fatores quantitativos e melhoram suas anlises de causa-raiz para que se considere o custobenefcio das possveis alternativas. A gerncia de projetos passa a ser uma cincia com aspectos de arte e no mais uma arte com aspectos de engenharia. O Captulo 11 fecha o livro com os scios discutindo a compra de duas linhas de negcios por uma mega empresa. Para que sua histria no seja um caso nico, o captulo faz a contabilidade dos fatores que permitiram seu sucesso. Revisa ento Lean, Kanban, Scrum, FDD e XP. Tambm, e fundamentalmente, o papel do MPS como a ferramenta de desenvolvimento organizacional que permitiu que realizasse este crescimento em tempo recorde e com mnimos inconvenientes.
2
Capitulo 1
Pgina 5
Boria et al.
CAPTULO 2 - O MTODO DA MELHORIA CONTNUA 2.1 Melhoria de processos Se concordamos com a literatura existente e a experincia pessoal dos autores, a melhoria de processos a ferramenta que permite s organizaes se entenderem profundamente, indo de um conhecimento intuitivo a um quantitativo, passando por etapas intermedirias que servem tanto para melhorar os resultados quanto para apoiar os passos seguintes. Uma histria serve para deixar clara a diferena entre seguir e no seguir processos que foram acordados entre todas as partes. Os processos que as partes acordaram mudam quando elas assim decidem, enquanto que no seguir processos implica a inexistncia de um padro reconhecvel pactuado entre os interessados. Em uma organizao desenvolvedora de software, Pedro, um dos melhores programadores, era um fervoroso defensor dos processos. Rapidamente convenceu seus colegas de equipe de trabalho a adotar processos na construo de diversos documentos e que, acima de tudo, definissem a sequncia de passos e o critrio de finalizao, baseado na qualidade objetiva de cada produto. Os projetos nos quais Pedro tinha participao eram bem-sucedidos com mais frequncia que todos os demais, e seus clientes elogiavam o produto gerado. Finalmente as diferenas chegaram aos ouvidos da direo e nosso jovem programador foi recebendo sucessivas promoes e, cada vez, para cargos de maior responsabilidade. No havia passado muito tempo quando finalmente foi promovido a chefe tcnico de desenvolvimento. Convocou seus at ento colegas e mostrou que sua promoo obedecia ao reconhecimento que a alta gerncia tinha do trabalho que seguia processos, por isso esperava que todos colaborassem com ele para ampliar sua utilizao e contribussem para sua melhoria. Muitas cabeas assentiram e, depois de algumas perguntas e respostas, a reunio foi concluda. S Pablo, um programador que, at a chegada de nosso heri era considerado o programador estrela, ficou para trs. Pedro, disse. Estou contente por sua nomeao, mas voc bem sabe que no sigo processos de outros e acho que tentar que os demais entendam meus processos uma perda de tempo, porque eles servem para mim e s para mim. Espero que no leve a mal, mas minha inteno continuar fazendo o que sempre fiz. No esperava outra coisa, disse Pedro. Que bom que aceite assim, fico feliz, respondeu Pablo.
Satisfeito, pegou suas anotaes e se dirigiu porta da sala. Pedro deixou que chegasse at a porta e o deteve: Bom, importante que no fracasse. Que nunca fracasse. Os que seguem processos podem ter problemas, porque os problemas nos ensinam quais partes do processo precisam de mudanas. Mas se voc no seguir processos, os fracassos no nos ensinam nada e voc ter de arcar com toda a responsabilidade. Espero que no leve a mal, mas vou continuar fazendo assim, como sempre fiz.
Os processos que apresentamos a seguir nos permitem identificar defeitos desde cedo e detectar sua origem. Em certo sentido, seguir um processo como comprar uma aplice de seguro: no queremos que nada ruim acontea, mas investimos um pouco, caso algo ocorra. O mesmo acontece com os processos: se todos ns tivssemos memria perfeita, nunca cometssemos erros e as especificaes na linguagem natural tivessem um significado nico e inaltervel, ento se relativizaria muito a necessidade de seguir processos. Ainda seriam teis para coordenar o trabalho, mas para pessoas com memria total seria suficiente fazer processos muito pequenos. A realidade bem outra: os seres humanos erram, esquecem e mal interpretam as comunicaes em linguagem natural. Como consequncia, a nica maneira de aprender como organizao capturar nossos processos para entender seu funcionamento (dados do processo) e a qualidade dos produtos que geram. Nem todos os processos so iguais. H processos administrativos que no so tratados neste livro. H processos extraorganizao que tampouco nos interessam. Os processos que queremos ressaltar e melhorar so aqueles vinculados ao desenvolvimento de software nas organizaes. Ainda assim, possvel obter mais detalhes do que colocaremos neste livro em outras fontes. Os autores se limitaro a exibir o comportamento mnimo para organizar projetos que produzam sistemas de software de boa qualidade.
Capitulo 2
Pgina 6
Boria et al.
As organizaes que entendem seus processos e tiram proveito so chamadas de maduras. Uma organizao madura persegue seus objetivos com uso desse conhecimento. Sabe o que suas equipes so capazes de alcanar e no faz promessas que no pode cumprir. As equipes usam o conhecimento para iniciar o desenvolvimento com confiana em suas foras e em sua capacidade de cumprir compromissos. As organizaes imaturas, entretanto, s vezes cumprem seus compromissos, mas nem sempre conseguem. No conhecem sua capacidade e fazem promessas que nascem de seu desejo de ganhar o cliente. O que estamos propondo neste livro um caminho para chegar excelncia, amadurecendo como organizao e usando mtodos geis, para o qual usaremos um caso de estudo e um modelo. o modelo MPS, em nosso caso, aquele que orienta a sequncia de aes no que diz respeito ao crescimento da maturidade organizacional. O modelo MPS, que explicaremos com mais detalhes no Captulo 4, um modelo de desenvolvimento organizacional por nveis, que define os processos que a organizao deve implementar e os resultados esperados dessa ao, para ir avanando de nvel em nvel. Mesmo quando todos os envolvidos tm a inteno de seguir o modelo, impossvel implementar todos os processos simultaneamente, mesmo se nos restringirmos a tomar os nveis um a um, coisa por outro lado muito saudvel, porque os hbitos construdos em um so aplicados ao que o segue. Existe a necessidade, portanto, de encontrar um mtodo que nos ajude a organizar o crescimento em termos mais concretos do que faz o MPS e que, por sua vez, se compadea das necessidades da organizao em relao a seus negcios. Como o leitor pode imaginar, no h uma maneira nica de fazer isto. Desta forma, decidimos antecipar a apresentao de um processo do MPS, no em detalhes, mas mostrando seu uso. Tomando emprestadas tcnicas do MPS em seu processo Gerncia de Decises (GDE), vamos comear definindo o problema que estamos tentando resolver. Problema: Apesar de que em um marco macro, os nveis do MPS servem para definir as pautas da melhoria contnua, em cada caso necessrio atender s necessidades da 5 organizao que pretende melhorar seus processos, levando em conta o seu negcio . O problema ento encontrar um mtodo de melhoria que brinde um bom balano entre negcio e modelo. Atributos desejveis de uma Soluo: A soluo deve fornecer um mecanismo de melhoria contnua que permita identificar cada passo sucessivo de um programa de melhoria e este deve ter detalhes suficientes para que seja possvel execut-lo sem muita ambiguidade, mas no tanto que implique um planejamento detalhado para cada seleo (DETALHE). Deve fornecer um marco terico reconhecvel que ajude a medir o impacto das decises sobre o sistema como um todo, no s a otimizao local (MARCO). Deve permitir deduzir as aes derivadas que otimizem o sistema (SISTEMA). Deve retroalimentar o mecanismo que permita introduzir melhorias a um bom ritmo, sem que interfiram com o trabalho nem com o desenvolvimento pessoal dos funcionrios (NEGCIOS). Estes atributos desejveis constituem os critrios sob os quais avaliaremos as alternativas de soluo. A ordem de sua importncia relativa mostrada na Tabela 2.1 no final deste captulo. Alternativas de Soluo: A literatura tem muitos exemplos destes mtodos. Os seguintes foram includos em nosso conjunto de solues: Plan-Do-Check-Act [SHEWHART, 1939], IDEAL [McFEELEY, 1996], Focus-Improve-Sustain-Honor [ARTHUR, 2004] e Lean Simplified [ARTHUR, 2006]. Mtodo de Avaliao: Utilizaremos uma matriz de Pugh [PUGH, 1991] para avaliar alternativas quando os atributos so mltiplos. Usada por Pugh na General Motors e descrita por ele em seu livro j citado e previamente em um artigo [PUGH, 1981], a matriz de Pugh um dos mtodos de anlise de alternativas mais difundidos entre engenheiros. Cada coluna representa uma soluo e cada linha um atributo. Cada linha tem um peso especfico que representa o valor relativo desse atributo frente aos outros. Em cada interseo linha/coluna, avalia-se a contribuio que a soluo dessa coluna faz ao critrio dessa linha. Previamente foi
5
A referncia a um negcio est entre aspas porque se trata dos motivos de existncia da organizao. Se essa organizao um hospital pblico que mede seu impacto na comunidade a partir da quantidade de curas que realiza ou do estado geral de sade da populao que atende, ento para todos os efeitos este seu negcio. No se deve entender como se s pudesse ser aplicado a organizaes com fins lucrativos.
Capitulo 2
Pgina 7
Boria et al.
estabelecido um mecanismo de avaliao que permite ajustar a objetividade a respeito da medio de cada atributo. Critrios de Avaliao por Atributo: DETALHE mensurvel como 3 (detalhe adequado), 2 (detalhe um pouco excessivo ou no suficiente), 1 (detalhe bastante excessivo, algo assim como trinta pginas para entend-lo, ou muito superficial, algo que permite muitas interpretaes) ou 0 (no tem nenhuma explicao clara associada). MARCO medido como 3 (est reconhecido no sistema que necessrio atender outras coisas), 2 (no se analisa o sistema de maneira total, mas bastante abrangente), 1 (h algumas pistas para analisar aes derivadas) ou 0 (no se apoia em nada na mudana sistmica). NEGCIOS medido como 3 (quando foca sobretudo nas necessidades do cliente como ponto de partida), 2 (h um alinhamento com o negcio, mas externo ao mtodo), 1 (pode-se alinhar ao negcio, mas o mtodo incerto e no mencionado) ou 0 (no h nenhuma relao evidente entre o mtodo e o negcio). Descreveremos agora as quatro opes, tentando fazer com que o prprio leitor possa julgar a qualificao de cada uma em relao a cada atributo. 2.2 Plan-Do-Check-Act Plan-Do-Check-Act (PDCA) foi proposto em [SHEWHART, 1939], e difundido sobretudo por 6 Deming em vrias ocasies . Deming se referia a este procedimento baseado no mtodo cientfico como o Ciclo de Shewhart. A posteridade o lembra frequentemente como o Ciclo de Deming, uma das consequncias da notoriedade deste que ainda maior do que a daquele. Depois, Deming mudou o Check (verificar) por Study (estudar) para enfatizar que o passo deve ser mais de anlise do que de inspeo. Pode-se, justificadamente, considerar Shewhart como o pai da qualidade industrial. Foi ele quem introduziu os diagramas de controle estatstico para a anlise da estabilidade de um processo a partir da medio de um atributo. Em funo de sua data de origem, difcil 7 encontrar o material original, mas na maioria das citaes o primeiro passo identificar o problema e depois analis-lo. No h uma meno explcita aos objetivos de negcio, embora seja difcil imaginar que Shewhart os tenha evitado, lendo seus outros materiais. Possivelmente o mtodo foi tirado (mais uma vez) do contexto e ao fazer isso, perdeu-se parte de seu valor sistmico. Portanto, sem julgar o mtodo em si, mas julgando seu uso habitual, podemos dizer que PDCA simples, fcil de aplicar, mas possvel que seja usado sem levar em conta o impacto no negcio. H, em vrias verses do mtodo, referncias a um processo desenvolvido por Deming para a melhoria contnua, o que daria uma melhor verso sistmica desse mtodo, assim como um possvel vnculo com os objetivos de negcio. A seguir descrevemos os passos do PDCA. PLAN (Planejar) Passo 1: Identificar o Problema. Atividades: Selecionar o problema a ser analisado; definir claramente o problema e redigir seu enunciado de forma precisa; fixar um objetivo mensurvel para o esforo de resoluo do problema; estabelecer um processo para a coordenao e conseguir a aprovao da direo. PLAN (Planejar) Passo 2: Analisar o Problema. Atividades: Identificar os processos que impactam no problema e escolher um; listar os passos do processo como so executados neste momento; construir um mapa do processo; validar o mapa do processo; identificar possveis causas do problema; juntar e analisar dados relacionados com o problema; verificar ou revisar o enunciado original do problema; identificar as causas-raiz do problema; juntar dados adicionais, se necessrio, para verificar as causas-raiz. DO (Fazer) Passo 3: Desenvolver Solues. Atividades: Estabelecer critrios para escolher uma soluo; gerar solues potenciais que ataquem as causas-raiz do problema; escolher uma soluo; conseguir aprovao e apoio para a soluo escolhida; planejar a soluo. DO (Fazer) Passo 4: Implementar a Soluo. Atividades: Implementar a soluo escolhida em um piloto ou ensaio. Se o processo PDCA estiver sendo utilizado dentro do Processo de Melhoria Contnua, passar ao Passo 6 desse processo. Se estiver sendo utilizado de forma separada, continuar com o Passo 5.
6 7
O livro [SHEWHART, 1939] foi compilado por Deming com um prefcio de sua autoria. Veja-se por exemplo http://quality.enr.state.nc.us/tools/pdca.htm
Capitulo 2
Pgina 8
Boria et al.
CHECK (Verificar) Passo 5: Avaliar os Resultados. Atividades: Juntar dados da soluo; analisar os dados. O objetivo buscado foi alcanado? Se positivo, passar ao Passo 6. Se no, voltar ao Passo 1. ACT (Agir) Passo 6: Padronizar a Soluo (e Capitalizar Novas Oportunidades). Atividades: Identificar mudanas sistmicas e necessidades de treinamento necessrias para uma implementao completa; adotar a soluo; planejar e monitorar permanentemente a soluo; continuar procurando oportunidades incrementais para refinar a soluo; procurar novas oportunidades de melhoria. O mtodo PDCA slido, mas sua idade fez com que vrios dos detalhes que seu autor defendia fossem deixados de lado em sua implementao corrente, que o que um bom avaliador julga: seu uso, acima de sua definio. Isso no impede que, para o leitor avisado, os passos do PDCA continuem tendo utilidade. De fato, como veremos no que segue, o ciclo de Shewhart continua sendo utilizado em diferentes variantes. Tampouco frequente que os usurios do PDCA o coloquem no marco adequado, simplesmente utilizado como um ciclo cuja repetio produz os resultados esperados. Devemos lembrar que para Shewhart e, como consequncia, para Deming, h um processo de melhoria contnua no qual o PDCA se encaixa. De outra maneira, perde-se parte de seu impacto. nesse processo marco que vrias das iniciativas sistmicas e o vnculo com os objetivos de negcios esto imersos, de modo que mudar esse processo como foi definido e colocar outro em seu lugar pode ter como efeito a perda desse ambiente e, como consequncia, a piora do processo de melhoria. Vejamos agora como McFeeley lida com esse problema, incorporando a seu mtodo o detalhe necessrio (de forma excessiva, segundo nosso ponto de vista). 2.3 O Mtodo IDEAL Por causa da enorme influncia que Deming e, como consequncia, Shewhart a quem ele citava constantemente tm sobre a comunidade de melhoria de processos, este mtodo e os que descreveremos mais tarde esto muito influenciados pelo PDCA. A Figura 2.1 mostra uma descrio grfica do mtodo IDEAL. Ele tem cinco fases que correspondem a etapas importantes de uma iniciativa de melhoria de processos. Como a melhoria contnua, esperase que o ciclo continue depois de alcanada a 5 fase. Mesmo que o autor do IDEAL [McFEELEY, 1996] esclarea que os limites entre fases so mais imprecisos do que os descritos na referncia, comum que as recomendaes deste no sejam seguidas e acabem sendo executadas como uma sequncia de atividades em um projeto, assim como outros desvios de alto impacto.
Figura 2.1: O Mtodo IDEAL (adaptado de [McFEELEY, 1996])
Capitulo 2
Pgina 9
Boria et al.
A primeira fase chamada, com certa lgica, de Iniciando (Initiating). Possui trs blocos, mas na descrio detalhada estes no so considerados, sendo descritas no lugar 10 tarefas, algumas detalhadas at o nvel de subtarefas. A mesma situao de desacoplamento entre a descrio textual e a grfica repetida em todas as fases. A fase Iniciando culmina quando a infraestrutura para a melhoria de processos foi construda e os objetivos de negcios foram vinculados ao programa de melhoria de processos, h um sistema de recompensas alinhado com as melhorias e um plano inicial para o projeto de melhorias, que contm o plano de comunicao dos avanos. A fase seguinte chamada de Diagnosticando (Diagnosing) e tem seis tarefas. Realmente, a fase na qual se realiza a anlise da lacuna existente entre as necessidades de processo e os processos em uso, tal como so realizados. O critrio de entrada da fase no coincide totalmente com o critrio de sada da primeira fase, por isso difcil entender como se consegue chegar sua execuo. A fase tem como critrio de finalizao que as lacunas encontradas e as recomendaes sejam entregues ao comit de gesto, com a aceitao deste, assim como a necessidade de existir um esboo do plano estratgico de ao. A terceira fase de IDEAL denomina-se Estabelecendo (Establishing), que aqui se refere ao plano e no aos processos. Apesar de ser confuso, cria uma boa sigla (IDEAL, por Initiating, Diagnosing, Establishing, Acting e Learning) que um nome mais lgico (Planejar ou Detalhar) no criaria. Nesta fase so ajustadas prioridades e formadas as equipes que levaro adiante a definio e difuso das mudanas e melhorias dos processos. O mais notvel que o mtodo recomenda que o planejamento seja realizado pelo comit de gesto, ou seja, so os gerentes que realizam a superviso estratgica do plano de melhorias, e no o grupo de processos. Este excelente conselho ignorado na prtica. A fase tem 14 atividades. O critrio de finalizao que o plano estratgico tenha sido completado e aprovado, e que a viso organizacional, o plano de negcios e o plano estratgico de melhoria de processos tenham sinergia entre si. A fase seguinte denominada Atuando (Acting). Esta fase a mais interessante, embora o modelo tenha muitos componentes teis, porque foca diretamente no negcio. quando as melhorias so identificadas, construdas, aplicadas e colocadas em prtica. Tem dez passos, dos quais destacaremos uma subtarefa do passo 2, Desenvolver Solues: Analisar e Resolver o Problema. Ela nos interessa porque de muitas formas antecipa e se parece a Lean, no qual o enfoque est orientado puramente dor e no melhoria dos processos em si. Processos so modificados porque os atuais toleram defeitos e atrasos que no devem ser tolerados, as causas so atacadas, mas focando nos sintomas. Esta fase tem como critrio de sucesso que a estratgia de realizao e o plano sejam executados plenamente, ou estejam a ponto de serem iniciados. As solues que se adotaram (ou testaram) foram documentadas corretamente, encontram-se sob o controle do grupo de processos, e est clara a forma de mant-las. A melhoria de processos comeou a ser institucionalizada na organizao. Esta fase faz referncia a muitas pequenas melhorias realizadas em paralelo, sob um nico plano estratgico e mltiplos planos tticos. No entanto, a grande maioria das implementaes de IDEAL sofre do mesmo defeito: um enorme plano ttico que nunca fica pronto e que sofre da sndrome do correio: as cartas (pedidos de novas mudanas) continuam chegando e a tarefa de planejamento nunca concluda. A fase final, ou seja, a que inicia uma nova iterao do ciclo IDEAL, denominada Aprendendo (Learning). Na realidade, uma variante da primeira fase, j que teria pouco sentido comear de novo sem levar em conta o que j se avanou. Denomina-se assim porque, frente alta gerncia, afirmado o patrocnio mediante a mostra dos avanos ocorridos pela aplicao do mtodo. Quando as organizaes cometem os erros que ressaltamos antes, o resultado que o projeto de melhorias tem pouco a mostrar. O exemplo mais comum que so definidas solues, mas no so implementadas nem em pilotos, o que justificado pela sndrome de correio: j que foram aceitos novos pedidos de mudana, o grupo de melhorias focar na definio de solues e no em sua implementao. Como consequncia, uma longa lista de mudanas lanada simultaneamente sem preparao suficiente, pela demanda de capacitao que isso acarreta, e o projeto fracassa. IDEAL no um mtodo ruim, mas muito detalhado ( descrito em um documento de 236 pginas) e isso faz com que muita gente tenha tentado implement-
Capitulo 2
Pgina 10

8
Boria et al.
lo sem ter lido todos esses detalhes , com a consequente perda de vrios elementos 9 fundamentais, como o vnculo com os objetivos de negcio, o paralelismo na implementao e a viso sistmica (multicausal, com laos de retroalimentao e atrasos entre causa e efeito visvel), que so indispensveis para se estabelecer um programa de melhoria contnua. O melhor do IDEAL sua viso de melhoria de processos (Figura 2.2) baseada nos objetivos da organizao e apoiada em alguns pilares: na visibilidade do projeto; na comunicao horizontal e vertical entre as partes; na captura, reteno e aproveitamento da experincia (lies aprendidas); e em uma rede de suporte de todo o projeto. Desse modo, os planos ttico e estratgico so sustentados para se chegar ao sucesso.
Figura 2.2: Viso de Melhoria de Processos do IDEAL (adaptado de [McFEELEY, 1996])
2.4 Focus-Improve-Sustain-Honor Focus-Improve-Sustain-Honor (FISH) de [ARTHUR, 2004] mais uma variante do PDCA, com 10 nfase nas ferramentas de Six-Sigma . O ciclo de Arthur baseia-se na medio. O uso dos dados disponveis e a busca estilo inteligncia de negcios o fundamento da anlise, ao invs dos defeitos ou da distncia a respeito de algum ideal. Isto, claro, no vai contra os preceitos do PDCA, mas influencia muito no impacto que tem cada um, porque em FISH indispensvel comear pela anlise dos dados antes de entrar no ciclo. O ciclo tem quatro fases. A primeira fase, Focus, focar, que est baseada em um fato estatisticamente demonstrvel pelas distribuies dos defeitos: uns poucos processos so responsveis pela maioria dos defeitos. Encontrar essas fbricas de defeitos possibilita focar o processo de
Se o leitor no se sente cmodo com a afirmao de que um nmero muito grande de pessoas no l os detalhes antes de implementar um modelo, os autores gostariam de remet-lo ao trabalho de Royce, Managing the Development of Large Software Systems [ROYCE, 1970], que considerado o pai do ciclo de vida em cascata por esse mesmo artigo, e que lamentavelmente est mal citado: o que Royce diz nesse trabalho que essa viso do processo de desenvolvimento infantil e cheia de problemas. 9 Os usurios de IDEAL tendem a desenvolver um projeto sequencial com muitas iniciativas que atrasam a fase de aplicao, uma das maneiras de resistir mudana. 10 Six Sigma uma estratgia de gesto criada na Motorola em 1986 e usada mundialmente (SPC and TQM in Manufacturing and Services [TENNANT, 2001]). Tenta melhorar a qualidade dos resultados dos processos identificando e eliminando as causas dos defeitos. Utiliza vrios mtodos, fundamentalmente estatsticos. O termo surgiu da anlise estatstica da ocorrncia de defeitos na manufatura. A maturidade de um processo de fabricao pode ser expresso como a quantidade de desvios-padro () que se distancia da mdia da populao total, ou pela porcentagem de peas sem defeitos que produz. Um processo seis sigma (6) um que produz 99,99966% das peas sem defeitos, que foi o objetivo fixado pela Motorola e que deu nome aos mtodos que foram juntados para alcanar este objetivo.
Capitulo 2
Pgina 11
Boria et al.
11
melhoria onde ele ter maior benefcio. Para Arthur, a aplicao da lei de Pareto prev grandes lucros. Seu raciocnio que se 80% dos defeitos so produzidos por 20% dos processos, aplicando-se novamente a regra temos que 64% (80% dos 80%) dos defeitos vem de 4% (20% do 20%) dos processos. Desse modo, focar a melhoria em um minsculo grupo de processos permite eliminar um nmero bastante grande de defeitos. Por isso necessrio focar. A segunda fase, Improve, melhorar, onde o defeito encontrado eliminado. Esta a fase onde so identificadas as causas profundas, so escolhidas as solues possveis e a implementao definida e levada adiante. O MPS (ver o Captulo 4) contm resultados esperados de processos que ajudam a entender a implementao dos passos de melhoria por identificao das causas-raiz. Utilizaremos ao longo deste livro esta capacidade de identificar 12 as causas dos problemas para poder melhor-las ou difundi-las . Utilizar a anlise da causaraiz de forma sistemtica uma das ferramentas mais poderosas da melhoria de processos, e uma das trs ferramentas intelectuais (junto com a anlise e a gesto de riscos, e a viso sistmica do processo) que mais rendimento consegue nos processos intelectuais que acompanham, ou devem acompanhar, a melhoria de processos. A terceira fase, Sustain, sustentar, onde devemos tentar consolidar e manter a melhoria, para a qual Arthur prope utilizar ferramentas de conhecimento profundo como foram introduzidas por Shewhart e difundidas por Deming. Para comear, Arthur indica desenvolver o mapa do processo, utilizando sempre ferramentas simples. Em todos os casos, Arthur se inclina pela simplicidade, dedicando tempo ao processo intelectual e utilizando a ferramenta que melhor se adapta ao menor custo de aprendizagem possvel. Por exemplo, neste caso ele sugere utilizar 13 um diagrama de fluxo, sendo que h outras ferramentas possveis que so mais poderosas e igualmente difundidas. Para poder afirmar que os resultados foram alcanados, necessrio saber se o processo est normalizado; porque, se no for assim, impossvel estabelecer comparaes. Suponhamos que o problema que uma receita culinria vem dando resultados diferentes. Ao analisar a causa profunda, percebemos que diferentes cozinheiros interpretam de forma distinta as instrues e que alguns passos esto faltando, porque o autor da receita assumiu que quem tentasse execut-la deveria ter conhecimentos culinrios em grau suficiente, o que no resultou em uma previso verdadeira. Alm disso, h um erro na receita que sugere usar um tipo de farinha que no o correto, digamos que diz farinha sem nada mais, que no contexto dos cozinheiros que tm problemas com a receita se entenda por farinha de trigo, quando quem criou a receita queria que fosse farinha de milho. A anlise da causa detectou estes defeitos e foi sugerido que mudanas na receita sejam feitas, definindo com preciso os passos para que no haja diferentes interpretaes, alm de corrigir erros e ambiguidades. Um grupo de processos sem a experincia suficiente consideraria que cumpriu com a obrigao: o processo, se executado corretamente, deveria funcionar. Jay Arthur , e os autores deste livro, no se conformam com essa definio, incompleta, da responsabilidade do grupo de processos: e se no funcionar? Lamentavelmente o resultado nesses casos que o grupo de processos joga a responsabilidade aos que, devendo executar corretamente o processo, no o fazem, sem constatar que, necessariamente, so eles e no as mudanas que levam a perpetuar o problema ou introduzir outros novos. Portanto, sustentar implica em medir e analisar os resultados. Isto obriga a entender quando, onde e o que medir. Um dos passos mais importantes na definio de processos e na mudana para a melhoria identificar os processos-chave e os atributos a medir. Esta capacidade exigida pelo MPS nos nveis mais altos de maturidade, a partir do Nvel B; mas uma das
11
Pareto foi um estatstico francs do sculo XX que se destacou no estudo da distribuio da renda. Em 1906, ele fez a famosa observao de que vinte por cento da populao possua oitenta por cento da propriedade na Itlia, posteriormente generalizada por Joseph M. Juran no princpio de Pareto (tambm conhecida como a regra do 80-20). 12 Se o evento um problema ou defeito, tentaremos localizar sua origem para elimin-lo; mas se o evento um resultado positivo no planejado, tentaremos entender o que o provocou para reproduzi-lo em outros ambientes. 13 Os diagramas SADT e IDEF0, em sua verso norma internacional, so mais detalhados e de uso difundido. Tambm os diagramas de fluxo com pistas que permitem discernir responsabilidades. Da mesma forma, seria possvel desenhar o processo seguindo tcnicas de fluxo de dados da Anlise Estruturada ou com ferramentas de UML.
Capitulo 2
Pgina 12
Boria et al.
qualidades mais valiosas de um gerente. Por exemplo, se nos preocupa que a maioria dos projetos termina depois da data prevista para sua entrega e realizamos mudanas em consequncia disso para adiantar a produo de resultados, medir os atrasos que se produzem naqueles pontos de suma importncia. Medir s o resultado final, o desvio na data de entrega, s parcialmente til porque depois que entregamos atrasado, no se pode modificar o resultado. Arthur introduz aqui ferramentas de 6 que o MPS s exige a partir no Nvel B, como j dissemos, e, portanto, complica um pouco alm do necessrio a anlise de resultados. A ltima fase do ciclo Honor, honrar. Arthur se refere aqui necessidade de respeitar e premiar os compromissos com a mudana, com a melhoria (nem toda mudana uma melhoria, mas toda melhoria uma mudana). Grande parte da mensagem sobre a melhoria de processos est contida na maneira que a organizao ressalta e recompensa os esforos de seu pessoal em relao s mudanas e s melhorias. importante destacar que nem todas as tentativas de melhoria, sobretudo nas etapas iniciais do processo de melhoria contnua, iro terminar igualmente bem-sucedidas. Algumas sero at negativas; mas indispensvel resgat-las como esforos vlidos, pois a organizao aprende com elas. 2.5 Lean Simplified O ltimo mtodo Lean Simplified [ARTHUR, 2006]. Jay Arthur desenvolveu esse mtodo como uma extenso de FISH, que vimos acima, com o propsito de tornar mais clara a aplicao deste, enfatizando a cadeia de valor que leva desde o pedido do cliente at sua satisfao pela entrega do produto. A palavra inglesa Lean significa enxuto, sem muita sobrecarga. Arthur escolhe cham-lo Simplified, simplificado, porque reduziu a exigncia estatstica de seu mtodo FISH. Chamaremos este mtodo de LS, para evitar termos em ingls. LS, como explica Jay Arthur em [ARTHUR, 2006], um mtodo para empresas de manufatura. No entanto, modificando ou deixando de lado o que no se aplica ao desenvolvimento de software, um mtodo poderoso para identificar e resolver problemas com o objetivo de realizar uma melhoria contnua. Apresentamos aqui nossa verso de LS adaptada produo de software. No corao de LS est o tema da velocidade de produo . A velocidade no pressa, fazer melhor e sem interrupes, no trabalhar os fins de semana ou at tarde noite. A velocidade produtividade posta a servio do produto. Em um mundo conectado globalmente pela Internet os clientes esperam servios quase imediatos sem perda de qualidade nem aumento de preos. O livro de [RODIN, 2010] uma viso de como a demanda por servios gratuitos entregues no momento e sem custo algum est revolucionando os negcios. Para as organizaes que fabricam software o desafio est lanado: preciso eliminar os defeitos e todas as demoras para entregar no prazo e com baixos custos. Os atrasos no so justificveis. O produto do software pode ser nico e exclusivo, mas os processos pelos quais so produzidos no so. Cada projeto composto pelas mesmas fases, que realizam as mesmas atividades. A resistncia a esse conceito notvel em empresas de baixa maturidade e, no entanto, vemos vrias vezes que a resistncia a fazer as coisas de outra maneira to arraigada quanto a necessidade de sustentar que sempre so diferentes. A nica que demora a mudar a crena de que a organizao est justificada em atuar como faz. Em cada empresa h duas fbricas, a principal, que desenha, vende, fatura e entrega o produto, cuja frmula : Velocidade com Qualidade + Lucros = Benefcio. A segunda a fbrica de consertos, que corrige todos os erros que vo sendo cometidos medida que o produto desenhado, vendido e faturado. H sempre uma fbrica de consertos visvel, que medida e controlada, mas h outra que oculta, o que faz com que os defeitos sejam corrigidos sem que
14
14
A empresa Toyota inventou o mtodo de produo enxuta ( lean production) tomando como referncia os supermercados dos EUA; onde perceberam que, quando as prateleiras dos supermercados alcanam o ponto mnimo do inventrio, so reabastecidas to rapidamente quanto os clientes tiram os produtos da gndola. Em um sistema de trao, o processo anterior deve sempre fazer o que o processo subsequente pede. Para ver que o estoque est baixo e, como consequncia, rep-lo, coloca-se um carto que marca o ponto exato. O nome em japons desse carto Kanban, palavra que hoje identifica tanto o carto quanto o sistema.
Capitulo 2
Pgina 13
Boria et al.
haja atribuio nem contabilizao. Essa fbrica tem outra frmula: Defeitos + Atrasos = Perdas. No fundo, LS se concentra na velocidade da produo. A relao entre as etapas de um processo fundamental. As etapas e atividades que no agregam valor devem ser eliminadas do processo. Por isso, a primeira atividade em LS fazer um mapa da cadeia de valor, a sequncia de atividades que vai da recepo do pedido do cliente satisfao de suas 15 necessidades . Mais uma vez, o mapa precisa ser simples, mas no tanto que acabe sendo facilmente mal interpretado. Alm disso, como se trata de um sistema de trao no qual a sada fora o processo anterior e assim sucessivamente, este mtodo atende principalmente a voz do cliente. Feito corretamente, isto gera valor para o cliente e, como consequncia, para a organizao. Foco nos Defeitos Ao tentar reduzir o atrito que atrasa os processos, a Toyota descobriu que h muitas formas de desperdcio (muda). 1. Excesso de produo (em software, incluir cdigo que no foi solicitado caso venhamos a necessitar). 2. Inventrio excessivo (em software, os processos que so gerados ao redor de funcionalidade no exigida, como testes-extra, volume de manuais, etc.). 3. Esperas (em software isso se manifesta especialmente quando preciso esperar que o pessoal ou as instalaes estejam disponveis, ou quando o cliente precisa dar uma resposta). 4. Movimentos desnecessrios do produto (em software a ubiquidade dos produtos em formato eletrnico faz disto um problema inexistente, mas se os planos so mantidos no papel ou nas lousas, isso pode chegar a ocorrer). 5. Movimentos desnecessrios de pessoal (tipicamente na instalao ou na validao, frequentemente na etapa de gerar requisitos). 6. Processamento desnecessrio ou inadequado (no muito comum, mas em certas organizaes burocrticas isso ocorre). 7. Defeitos que obrigam a reparaes e retrabalho (no h porque explicar isto em nossa profisso). Se a organizao trabalha com prazos curtos e se concentra em manter a flexibilidade, so obtidos benefcios com qualidade e satisfao do cliente. No Captulo 3 veremos como um grupo de desenvolvedores de software construiu mtodos que permitem que estes conhecimentos sejam aproveitados. O movimento que iniciaram conhecido como o Agile 16 Manifesto e marcou o desenvolvimento do software desde sua apario. LS continua com a organizao do trabalho para eliminar o desperdcio. So cinco as tarefas a realizar: Sort, ordenar; Straighten, enderear; Shine, polir; Standardize, padronizar; e Sustain, manter. Damos aqui nossa interpretao dessas tarefas em atividades de engenharia de software. Ordenar significa decidir o que til e o que no , e elimin-lo. Esta a tarefa das pessoas ou papis que identificam as melhorias do processo. Frequentemente, os pedidos de mudana de processos so originados nas equipes, e um papel em particular, chamado garantia da qualidade quem deveria detectar a necessidade de mudana e transmiti-la. Enderear colocar cada coisa em seu lugar e ter um lugar para cada coisa. Esse o papel da gesto de configurao na engenharia de software. Polir manter a rea limpa para expor defeitos e perdas. Em software isto se manifesta na aplicao de formas e padres que permitem a anlise e a inspeo por terceiros, por exemplo o uso de padres de programao que ajudam a ler um programa. Padronizar definir sistemas, processos e procedimentos que ajudem a manter as trs regras anteriores. Este novamente o papel da rea de melhoria de processos. Manter, por ltimo, conseguir que o fluxo de trabalho seja estvel e as regras sejam respeitadas. Entre a rea de melhoria de processos e o grupo de garantia da qualidade isto deveria ser realizvel. Outra das normas que regem a LS a preeminncia da demanda sobre a produo. Ao invs de produzir com antecipao ao que ser exigido, s se produz a partir do que pedido. Em
15 16
Ouvir e reagir no o mesmo que escutar e satisfazer. http://www.agilemanifesto.org/
Capitulo 2
Pgina 14
Boria et al.
nossa traduo ao mundo dos processos, isto significa que no tentaremos melhorar o que no se sente que no funciona, ou est com problema. O vocbulo ingls pull, que significa puxar, representa este pensamento, contra o vocbulo ingls push que significa empurrar. comum na disciplina de melhoria de processos que se tente empurrar m elhorias do centro para fora, ou de cima para baixo. Em nossa experincia, a resistncia assim criada exige muito esforo e no justifica o retorno sobre o investimento. Pelo contrrio, um enfoque de puxar faz com que a mudana seja vista como algo positivo j que, efetivamente, resolve um problema. Quando uma melhoria de processos percebida como uma eliminao de um obstculo produtividade, ganha-se um aliado para as futuras mudanas que, alm disso, agora conta com tempo extra para apoiar a criao e difuso de novas mudanas. LS tem mais a contribuir, mas no essencial o exposto j alcana o objetivo de fazer entender as vantagens e desvantagens do mtodo. Nossa matriz de Pugh para os quatro mtodos fica assim: atributos NEGCIO DETALHE SISTEMA MARCO soma peso 5 4 3 2 PDCA 1 1 2 2 19 IDEAL 3 1 1 0 22 FISH 3 2 1 0 26 LS 3 3 3 3 42
Tabela 2.1: Seleo do Mtodo de Melhoria de Processos
Com estes valores fica evidente que nos decidimos pelo LS. Claro, pode-se criticar esta deciso, porque os valores colocados na interseo so arbitrrios at certo ponto. Em uma deciso de maior impacto econmico, seria desejvel que a pontuao estivesse melhor detalhada para conseguir maior objetividade. Como vamos utilizar LS em nossas anlises e nossas propostas para a empresa que tomamos como caso de estudo, bom ressaltar alguns valores e crenas que se associam a LS. 1. O processo justo produzir os resultados justos. 2. Desenvolver o pessoal e os fornecedores agrega valor. 3. A resoluo contnua organizacional. de problemas raiz conduz aprendizagem
4. O fluxo de uma pea aumenta a produtividade, o lucro e a qualidade. 5. Os produtos no gostam de fazer fila esperando ateno. Os materiais, peas e produtos so impacientes. 6. O nico que agrega valor a um processo a transformao fsica ou informacional da matria-prima em algo que o cliente quer. 7. Os erros so oportunidades para a aprendizagem. 8. A resoluo de problemas 20% de ferramentas e 80% de uso da inteligncia. Nosso enfoque de melhoria de processos vai adotar muitas destas mximas aplicadas s reas de desenvolvimento de software. No vamos nos limitar a seguir o modelo MPS em sua aplicao, vamos procurar identificar e resolver os problemas que so comuns nas empresas desenvolvedoras de software.
Capitulo 2
Pgina 15
Boria et al.
CAPTULO 3 - OS MTODOS GEIS: KANBAN, SCRUM, XP E FDD 3.1 O que so os mtodos geis? No captulo anterior, apresentamos a melhoria contnua de processos e decidimos tomar como referncia a LS. As vantagens de um mtodo leve, desprovido de burocracia, que enfoca diretamente as necessidades do negcio no passaram despercebidas para os metodologistas de Engenharia de Software. J no sculo passado nasceram vrios mtodos de desenvolvimento que se apoiavam nas ideias de produo da Toyota, notavelmente o Extreme Programming [BECK, 2000], Scrum [SCHWABER, 2002], DSDM [STAPLETON, 1997], Adaptive Software Development [HIGHSMITH, 1999], Crystal [COCKBURN, 2005], FeatureDriven Development [COAD, 1999], Pragmatic Programming [HUNT, 1999] e outros. Em uma tentativa de encontrar formas comuns, dezessete destes criadores se reuniram em fevereiro de 2001 em um centro de esqui em Utah. O que surgiu foi um manifesto que marcou a engenharia 17 de software de modo nico, o Agile Software Development Manifesto . O contedo do manifesto pode ser lido online, mas consideramos que sua influncia to importante, e suas coincidncias com o mtodo da Toyota TPS so tantas, que o inclumos aqui. Manifesto para o Desenvolvimento gil de Software Estamos evidenciando maneiras melhores de desenvolver software, fazendo-o ns mesmos e ajudando outros a faz-lo. Por meio desse trabalho, passamos a valorizar: Indivduos e interao MAIS QUE processos e ferramentas Software em funcionamento MAIS QUE documentao abrangente Colaborao com o cliente MAIS QUE negociao de contratos Responder a mudanas MAIS QUE seguir um plano Ou seja, mesmo tendo valor os itens direita, valorizamos mais os itens esquerda. (assinam) Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas.
2001, the above authors this declaration may be freely copied in any form, but only in its entirety through this notice.
Embora o manifesto descreva as ideias mais bsicas, h entre os autores mais acordos que aqueles ali expostos. Muitas das coincidncias vm da mesma fonte: o foco na qualidade, com as regras da Toyota que j mencionamos no captulo anterior, na seo Foco nos Defeitos. Assim como a Toyota tem seu mtodo TPS (Toyota Production System), que uma forma de Kaizen, os mtodos geis se apoiam em perodos de produo curtos e muita colaborao dentro da equipe de projeto, apoiado na sinergia gerada pelo trabalho em equipe e na estrutura formada para alcanar as metas estabelecidas pela direo da empresa. Em grande parte, sua popularidade entre desenvolvedores deriva da independncia que as equipes sentem ao tomar suas decises em conjunto e bastante livres das redes burocrticas que so geradas nas grandes empresas, o que traz consigo resultados concretos, tanto qualitativos como quantitativos. Ao deixar que a equipe tome as decises para o prximo perodo de trabalho, chamado na 18 19 gria dos agilistas um Sprint , os mtodos geis conseguem motivar a equipe dos projetos e compromet-los com o resultado ao permitir que tomem decises de peso. Pela curta durao
17 18
http://agilemanifesto.org/ Usaremos este neologismo para designar aqueles que aderem aos mtodos geis e os praticam. 19 Os dicionrios definem Sprint como a maior velocidade alcanada por um participante em uma corrida, especialmente no final. As corridas de at 200 metros so consideradas todas Sprints, do princpio ao fim. Por analogia, cada parte de um projeto gil considerado um Sprint.
Capitulo 3
Pgina 16
Boria et al.
de um Sprint, normalmente menos de quatro semanas, as equipes podem ver seus resultados de imediato. Tambm importante a participao do cliente: junto a um representante dele, que deve estar comprometido, por sua vez, com o resultado, define-se o objetivo de cada Sprint. um dever das equipes geis definir uma parte do produto que, em si mesmo, tenha valor para a organizao do cliente. Desse modo, o produto parcial concreto e mantm a concentrao e o foco no negcio. Os mtodos geis nasceram como resposta s burocracias que ignoram as particularidades do desenvolvimento de software e, em sua ignorncia, pressionam as equipes para levar adiante projetos com compromissos irracionais assumidos de forma indevida. Ao colocar metas curtas e priorizar a participao do cliente nas decises de negcio, alm de colocar um freio concreto s mudanas arbitrrias, os mtodos geis resgatam o valor da engenharia de software frente aos embates burocrticos de certos nveis nas corporaes. Entre outras virtudes, a deciso pela equipe visvel para todos: DEVE ser visvel para todos. Em consequncia, a transparncia dos projetos geis um de seus atributos mais valiosos e mais revolucionrios. Os agilistas se consideram um movimento pr-mtodos. Os que acreditam que a agilidade contrria aos processos e s ferramentas, documentao ou aos planos, esto equivocados. O que procuram que estas entidades estejam a servio das atividades da equipe e no ao contrrio. Se o leitor acha que ser gil no planejar, no seguir processos por mais ligeiros que sejam, no ter mais ferramentas que o ambiente de desenvolvimento interativo e algumas linguagens e no documentar as decises, est totalmente equivocado. Quem pensa assim um hacker, no um agilista. Os agilistas pensam que o planejamento detalhado no pode levar mais que umas poucas horas e deve envolver a equipe, que os processos so flexveis, mas devem ter o acordo de todos aqueles que os colocam em prtica, que a documentao deve ser fcil de manter e responder a uma necessidade orgnica do projeto e deve ser feita quando essa necessidade se manifesta e no como uma condio contratual depois que o produto estiver concludo. Quanto s ferramentas, basta recordar que a integrao contnua, um dos alicerces dos mtodos geis, requer excelentes ferramentas de gesto de configurao com testes integrados, portanto claro que os agilistas trabalham em prol da eficincia e no contra ela. Os quatro mtodos geis que consideramos mais teis em diferentes etapas de uma empresa 20,21 22 23 24 so Kanban , Scrum , XP e FDD . A ordem na qual os descreveremos vai do mais simples (Kanban) ao mais complexo (FDD). Scrum e XP se apoiam em Kanban e, em particular, descreveremos XP em sua verso XBREED, que mistura os conceitos de XP com as prticas de Scrum para obter um processo mais slido e confivel. 3.2 Kanban: medindo o fluxo Quem introduziu Kanban como mtodo gil foi [ANDERSON, 2011]. O mtodo Kanban parte de uma famlia de sistemas que se denominam pull, ou de puxar, contra o enfoque tradicional de sistemas push ou de empurrar. Outra maneira de ver a diferena entre uns e outros sistemas que o sistema pull guiado pela demanda enquanto que o sistema push guiado pela produo. Em um sistema pull o processo espera que haja demanda de seu produto para iniciar a produo, tentando fazer com que ele chegue bem a tempo, de maneira 25 que no haja estoque . O estoque caracterstico dos sistemas push, j que o amortecedor que permite o desacoplamento entre processos consecutivos. O problema que o estoque consome muito capital e tem um alto custo, sendo que, alm disso, no se sabe se o produto final tem comprador ou no. Desse modo, muito trabalho e material desperdiado. O mtodo Kanban permite alcanar um ritmo de produo sustentvel e introduzir mudanas nos processos com baixssima resistncia. por isso que o usamos preferencialmente
20 21
[KNIBERG e SKARIN, 2010] Quando usamos Kanban com maiscula nos referimos ao mtodo Kanban desenvolvido por Anderson, quando usado em minscula, kanban, faz referncia a qualquer outro uso, como o sistema kanban da Toyota ou a tabela kanban que veremos mais adiante. 22 [KNIBERG, 2007] 23 [KNIBERG, 2007] 24 [PALMER e FELSING, 2002] 25 Isto tambm conhecido como sistema Just in Time ou com as siglas JIT.
Capitulo 3
Pgina 17
Boria et al.
naquelas organizaes de baixa maturidade institucional. Como vimos, o mtodo Kanban um 26 dos mecanismos que suportam o TPS , mas a adaptao para engenharia de software de 2004 e foi realizada por Anderson na Microsoft. Anderson o apresentou na conferncia Agile 2007 de Washington e, desde ento, comeou o entusiasmo pelo mtodo, j que os resultados eram muito animadores. O mtodo , em si, muito simples, mas ao us-lo de determinada maneira, traz consigo mltiplas vantagens que mostraremos ao explic-lo. Apesar de que o texto [ANDERSON, 2011] a base que permite entend-lo profundamente, para o leitor que busca uma gesto mais pragmtica aconselhamos [KNIBERG e SKARIN, 2010] que remete ao essencial da implementao, sem deixar de lado o anedtico que permite a compreenso, ou como se diz no Mxico, a aterrissagem do material. Um elemento central no mtodo o uso do painel kanban. No se deve confundir o uso do painel com a aplicao do mtodo; possvel usar o painel sem segui-lo, como de fato se faz em muitas adaptaes de Scrum e XP, porque o painel um excelente meio para comunicar o progresso de um projeto. O painel kanban simplesmente um registro do avano do projeto materializado segundo a convenincia da equipe. O mais frequente usar um painel onde se possa colar notas autoadesivas, como na Figura 3.1, dividida em colunas verticais. Cada coluna indica um estado das tarefas. As notas autoadesivas contm os nomes das tarefas. A primeira coluna da esquerda tipicamente contm o pendente, quer dizer, a lista das tarefas que devem ser feitas e que ainda no foram iniciadas. Quando um membro da equipe tem disponibilidade para comear uma delas, pega da primeira coluna a tarefa correspondente, seja por prioridade prestabelecida ou por alguma outra razo que a equipe tenha decidido, e a passa para a coluna seguinte direita. Em alguns mtodos que usam o painel kanban, o membro da equipe que faz isto coloca a data e hora do incio, seu nome e data estimada de finalizao nos cantos da 27 nota, desenhados para esse uso, como mostrado na Figura 3.2 . Quando termina de realizar sua tarefa, o membro da equipe retira a nota do lugar onde a colocou e a move para a prxima coluna direita, onde por sua vez a mesma ser tomada por outra pessoa que dar continuidade ao processo at que a tarefa chegue ao ponto onde foi combinado que ser considerada completa, ponto no qual chega coluna da extrema direita do painel.
Figura 3.1: Painel kanban
No h nenhum motivo especial para utilizar cartes autoadesivos ou as lousas em si. Podem ser utilizados papeles nos quais so presos cartes de cartolina, podem ser usadas filas horizontais ao invs de colunas ou pode ser utilizado um painel virtual dos muitos que so
26 27
Toyota Production System.
No exemplo mostrado, no canto superior esquerdo est o nome da pessoa responsvel, no superior direito, a data e hora de abertura do item, no inferior direito a estimativa de finalizao e no inferior esquerdo (vazio no exemplo) a data real de finalizao. Quando se usa esta conveno frequentemente as notas autoadesivas so copiadas e coladas umas sobre as outras para ter a histria de seu desenvolvimento.
Capitulo 3
Pgina 18
Boria et al.
oferecidos pela internet. O objetivo o mesmo: dar clareza s tarefas pendentes de resoluo e entender tanto o estado atual do projeto quanto a ocupao do pessoal.
Figura 3.2: Nota do Painel kanban
No mtodo Kanban, h um limite para o nmero de tarefas em cada coluna. O objetivo identificar claramente a capacidade do sistema e equilibrar a demanda em relao competncia da equipe. O mtodo Kanban permite compreender o tempo de circulao de cada tarefa, desde o ingresso no sistema pela esquerda, at a finalizao na coluna da direita (h algo de satisfao pessoal para cada membro da equipe em mover a tarefa para a coluna concludo que motiva a usar o kanban). Depois que se ajustou os parmetros de produo, a equipe alcana um ritmo sustentvel, quer dizer, que pode ser mantido indefinidamente, conseguindo na verdade uma certa previsibilidade que outros mtodos demoram muito para alcanar. Como essa regularidade se torna presente muito rapidamente, toda obstruo a essa regularidade rapidamente visvel, potencializando a equipe para detect-las e, em consequncia, resolv-las. O impacto que tem na regularidade os defeitos, as demoras, os gargalos e a m estimativa do tamanho e da complexidade do produto aparecem rapidamente no painel. fcil relacionar estes problemas com o custo do projeto, pois ao restringir o nmero de tarefas em cada coluna as pessoas devem atender os gargalos para ajudar a resolv-los. Desta maneira, o mtodo Kanban vincula rapidamente os problemas tcnicos do projeto ao resultado de negcio, sem precisar estabelecer complicados mecanismos de anlise. Este um resultado que no se vislumbrava ao introduzir o mtodo, mas que um dos pilares de sua adoo. Uma das vantagens do Kanban que, ao produzir com qualidade e tempo, gera-se confiana nos clientes, que recebem produtos com regularidade e com a qualidade esperada. Outra vantagem que, ao fazer com que a equipe melhore constantemente seus processos para evitar demoras, as entregas so feitas com mais frequncia e englobando maior nmero de funcionalidades. Por sua vez, esta situao faz com que a equipe se sinta mais vontade e se dedique com mais afinco a melhorar o fluxo de trabalho. Para implementar Kanban o primeiro passo identificar o fluxo de trabalho, o que se conhece como a cadeia de valor que j tnhamos visto no captulo anterior, nas discusses sobre o mtodo de melhoria de processos a ser empregado. Pela origem comum desses mtodos (as diferentes verses de qualidade total) e o fato de que o mtodo Kanban uma adaptao ao desenvolvimento de software de uma tcnica com o mesmo nome (kanban) derivada do TPS, por sua vez da mesma origem que as anteriores, as coincidncias no devem nos surpreender. Kanban usa cinco princpios para criar comportamentos nas organizaes onde aplicado: Visualizar o Fluxo de Trabalho; Limitar o Trabalho em Realizao; Medir e Administrar o Fluxo; 28 Explicitar Polticas de Processo; e Utilizar Modelos para Reconhecer Oportunidades de Melhorias. O primeiro ponto a destacar na construo de um painel kanban para o fluxo de trabalho que a coluna da direita deve corresponder ao estado de tarefa pronta. Antes que se possa
28
Os modelos a que Anderson faz referncia so mais gerais que os que apresentaremos no prximo captulo; mas, dada a abertura que sugere o texto j citado, os autores no acharam contraditrio utilizar o MPS para introduzir melhorias de processo compatveis com Kanban.
Capitulo 3
Pgina 19
Boria et al.
prosseguir com a implementao do mtodo, imprescindvel que a equipe, junto com o fornecedor de informao (mais adiante, chamaremos este papel de Dono do Produto seguindo o costume introduzido por [SCHWABER e BEEDLE, 2002]), defina os atributos necessrios de uma tarefa para que seja considerada pronta. Por exemplo, a densidade de defeitos remanescentes conhecidos, ou os estados pelos quais teve de passar (inspees, teste unitrios, etc.). A coluna da direita est assim bem identificada e seu sentido claro. A coluna da esquerda onde se colocam as tarefas pendentes. No meio, a quantidade de colunas dever ser estabelecida de acordo com o que a equipe quiser, desde que tenham significado para ela. Por exemplo, pode ser que a coluna seguinte direita de Pendentes seja Em anlise, a que segue esta seja Analisado, a seguinte Em Desenvolvimento, a seguinte Pronto para Teste, a seguinte Pronto para Integrao, e assim sucessivamente. Por outro lado, pode ser que uma equipe determine que tudo o que necessita saber est contido em trs colunas: Pendente, Em Desenvolvimento, Pronto para Entregar. As decises que assim so tomadas tm repercusses muito grandes. Por exemplo, a primeira escolha sugere que, dentro da equipe, h especialidades que vo passando a tarefa de uma outra. So abertas pelos analistas, que a passam aos desenvolvedores, que a passam aos testadores. A segunda sugere que a equipe trabalha em clulas integradas, onde todos esses papis so cumpridos dentro da clula. Um caso extremo pouco recomendvel o da clula unipessoal. Recomendamos a adoo de um painel mais complexo, com divises tcnicas do trabalho, pelo menos enquanto no se incorporarem tcnicas especiais, como programao por duplas e design dirigido por testes. O motivo que as diferentes etapas dentro do processo permitem visualizar melhor os estados intermedirios, de modo que os atrasos potenciais e os gargalos possam ser rapidamente detectados e a durao das tarefas, melhor estimadas. Alm disso, este esquema de trabalho muito flexvel e permite crescer com facilidade para outros mtodos, em particular o Feature Driven Development, que recomendamos mais adiante como um mtodo vantajoso para projetos grandes com equipes numerosas. Se estas duas caractersticas no forem suficientes, outra vantagem consiste em que os estados 29 intermedirios que so gerados ao acontecer um repasse permitem que o projeto conte com o apoio de grupos organizacionais, como Gesto da Qualidade, que podem tomar essas transferncias como referncias e intervir sem violncia na qualidade do processo. At aqui foram descritas generalidades do uso de um painel kanban. Para que seja uma aplicao do mtodo Kanban, necessrio limitar o nmero de notas em cada coluna. Se em uma coluna h tantas notas quanto indica o limite, geralmente anotado no alto de cada coluna junto a seu nome, no se pode passar uma nota a mais para essa coluna. Isto implica que, embora o passo anterior tenha sido terminado para uma tarefa, a coluna est bloqueada e no possvel avanar a nota correspondente. Claramente as pessoas que ficam ociosas notam isto, as pessoas que esto trabalhando nas atividades da coluna saturada tambm percebem isto, e a cadeia de produo fica detida. Nesta situao, detectado um gargalo, que deve ser resolvido pelos prprios membros da equipe. Ao contrrio da grande maioria dos mtodos existentes, Kanban no prescritivo. Tal caracterstica tambm seguida pelo Scrum, mas o Kanban ainda menos prescritivo do que o Scrum. A equipe escolhe, adapta e adota seus processos segundo suas necessidades. O que diferencia notavelmente o Kanban dos outros mtodos geis sua flexibilidade; mas, sobretudo, a limitao do volume de trabalho em cada etapa. esta restrio que coloca em jogo os mecanismos de adaptao e, em consequncia, os mecanismos de melhoria que, em outros mtodos, ficam a cargo de reunies especiais chamadas retrospectivas. O que nos demais mtodos uma viso do que aconteceu, no Kanban a necessidade lgica de operar sobre o que est acontecendo. Seguindo nossa opo de melhoria de processos, que definimos no captulo anterior, utilizaremos os mesmos preceitos que Anderson usa para Kanban, pois so compatveis: Foco na Qualidade, Reduo do Trabalho em Desenvolvimento, Entregas Frequentes, Equilbrio da Demanda contra a Produo, Fixao de Prioridades e Ataque s Fontes de Variao para Melhorar a Previsibilidade. A receita de Anderson no s compatvel com a de LS, que
29
Em ingls, hand-off entre um papel e o outro.
Capitulo 3
Pgina 20
Boria et al.
escolhemos anteriormente: totalmente compatvel com o MPS! No Captulo 5 expandiremos as tcnicas de Kanban utilizando o exemplo da Tahini-Tahini. 3.3 Scrum: Organizando o sistema para um estado de equilbrio orgnico Scrum no deve ser considerado um mtodo, apesar de ter regras claras que devem ser seguidas, porque deixa muitas questes abertas para resoluo da equipe do projeto. Ao descrever o Kanban dissemos que, depois dele, Scrum o enfoque gil menos prescritivo. Isto certo, mas a grande diferena entre o nmero de regras de um e outro (3 contra mais de 10) faz com que estejam prximos, mas no muito. Para implementar Scrum em uma organizao preciso antes realizar mudanas profundas. Com Kanban as mudanas originais so apenas trs: refletir o fluxo em um painel kanban, limitar o nmero de tarefas por etapa e melhorar o fluxo total fazendo as alteraes exigidas pelo processo. Kanban se adapta facilmente a qualquer processo subjacente, porque as entregas rpidas podem ser internas equipe e a participao dos envolvidos externos desejvel, mas no indispensvel. Por outro lado, em Scrum indispensvel reestruturar a organizao em vrios sentidos: primeiro preciso contar com uma pessoa que conhea o produto, ou tenha a viso do produto, e que esteja disponvel para trabalhar com a equipe durante a durao do projeto. A dedicao exigida no de tempo integral, mas esta pessoa deve permanecer acessvel para que a equipe possa tomar decises relacionadas ao negcio conjuntamente com ela. Da mesma forma, esta pessoa deve possuir autoridade suficiente para 30 que suas decises no sejam revistas . Na linguagem de Scrum esta pessoa conhecida como o Dono do Produto. Em segundo lugar, o pessoal deve ser dividido em equipes interdisciplinares pequenas, autoorganizadas, que contem com a superviso e colaborao para facilitar a resoluo de problemas por um especialista, chamado em Scrum de Scrum Master. O Scrum Master se encarrega de que os processos do Scrum sejam seguidos e de manter a relao da equipe com o meio que a rodeia. Nesse sentido, muito mais um co-pastor que cuida do gado do que um gerente que dirige as operaes. A auto-organizao da equipe fundamental no Scrum. O Scrum Master no dita o que deve ser feito, mas facilita o caminho para que possa ser feito. Desse modo, a prpria equipe que fixa as regras de colaborao e produo, e estas so flexveis e modificveis. Esta a base para que no existam filas de espera na equipe e que, quando forem abertas oportunidades de trabalhar juntos, estas sejam aproveitadas em benefcio de melhor produtividade e qualidade. Terceiro, o trabalho a realizar, os requisitos, devem ser divididos em um conjunto de entregas concretas e pequenas, no uma funcionalidade extensa, mas pequenas parcelas de trabalho que tenham sentido para o negcio e possam ser organizadas de acordo com sua prioridade, fixada em conjunto pelo usurio Dono do Produto e o Scrum Master. Objetivos so fixados, chamados de release, que estabelecem prazos de longa durao (meses) para a entrega do produto completo. Depois, o tempo de durao do projeto parcelado em pequenos marcos, chamados Sprints. Cada Sprint ter uma durao fixa, usualmente entre 1 e 4 semanas. As equipes de trabalho escolhero da lista de requisitos priorizados (Backlog), aqueles que entram no Sprint (Sprint Backlog). A equipe investe um dia de trabalho no planejamento do Sprint. H regras claras sobre como planejar e vrios mtodos que foram experimentados e adotados por muitas equipes. Fundamentalmente, a estimativa se baseia na histria de trabalho da equipe e na velocidade com que se constri em geral o produto. A equipe se rene todos os dias por um perodo curto, no mais do que quinze minutos, para revisar as tarefas do dia anterior e o plano do dia. O Scrum Master dirige e facilita esta reunio. Estas reunies so denominadas Scrum e do nome ao mtodo. O objetivo de um Sprint entregar uma parte do produto ao trmino do Sprint, o que se manifesta por uma demonstrao feita ao cliente. O fragmento de funcionalidade que se entrega ao cliente se chama sashimi, por analogia com o prato de peixe cru japons em que cada pedao um prato em si mesmo, mas tambm um componente do prato total. Cada demonstrao permite ao cliente entender melhor o produto que pediu e fazer os ajustes
30
Isto o que [BOEHM e TURNER, 2003] chamam de um usurio CRACK (collaborative, representative, authorized, committed and knowledgeable ) que traduzido colaborativo, representativo, autorizado, comprometido e com conhecimento.
Capitulo 3
Pgina 21
Boria et al.
necessrios para obter o melhor retorno do investimento no menor prazo possvel, mudando as prioridades do Backlog se isto for til.
Figura 3.3: Processo Scrum
Como h muita liberdade para realizar as tarefas durante um Sprint, possvel que tenhamos que realizar ajustes. No geral, as mudanas nos processos so introduzidas entre o trmino de um Sprint e o incio do seguinte. Para decidir sobre as mudanas, a equipe realiza reunies chamadas retrospectivas para analisar o comportamento dos processos e tentar melhor -lo.
Momentos da Verdade em um Scrum

H muitas oportunidades de errar tentando implementar o Scrum. Chamamos esses pontos crticos de momentos da verdade, por analogia com o mesmo conceito em Marketing. O primeiro sintoma de que no devemos implementar Scrum o do Dono Desconhecido. Isto aparece quando se inicia o projeto usando as ferramentas tradicionais de planejamento e no se identifica o Dono do Produto. Isto tem consequncias imediatas. Ao no ter o guia de um 31 usurio CRACK , o projeto sofrer com falta de viso do produto, falta de clareza nas prioridades, m conduo do jogo do planejamento ao iniciar os Sprints, que sero definidos com falta de objetivos claros, contribuindo para que sejam solicitadas mudanas de requisitos no meio dos Sprints. Nesse caso fica desvirtuada a validade do Scrum, motivo pelo qual inaceitvel continuar utilizando-o no projeto. preciso voltar a mtodos tradicionais, como o ciclo em cascata ou usar outros, como o Rational Unified Process. Se isto no for o desejado, preciso esperar para comear o projeto quando j houver um Dono do Produto. Se isto for impossvel, mas existir a possibilidade de gerar um ssia interno na empresa, sempre fora da equipe, esta se torna uma soluo aceitvel. NUNCA um membro da equipe pode ser o Dono do Produto, j que isto cria conflitos de interesses. Mesmo quando h um Dono do Produto, este pode sofrer de diferentes problemas: falta de viso do produto, prioridades pouco claras, ser muito inflexvel ou ter os objetivos pouco claros. Em todos os casos desejvel tentar educar o Dono do Produto para conseguir o comportamento desejado, ou se isto no for possvel, mudar de Dono do Produto. Sem um Dono do Produto CRACK, a equipe fica deriva e a qualidade do produto fica comprometida.
31
Usurio CRACK (collaborative, representative, authorized, committed and knowledgeable) que traduzido colaborativo, representativo, autorizado, comprometido e com conhecimento [BOEHM e TURNER, 2003].
Capitulo 3
Pgina 22
Boria et al.
No s o Dono do Produto que pode ser a causa do fracasso do projeto. Tambm necessrio que o Scrum Master conhea os processos e saiba como atuar em cada caso. O Scrum Master o responsvel pela escolha correta do jogo do planejamento, evitando problemas quando faltar histria equipe. Apesar de que o Dono do Produto e o Scrum Master tm participao nesse jogo, suas intervenes so limitadas. O Dono do Produto pode pedir explicaes ou explicar o que est esperando como resultado, mas no pode fixar o valor das estimativas. O Scrum Master facilita a reunio, podendo pedir precises (por exemplo, a definio de pronto), mas no deve influenciar na escolha de valores. De qualquer modo, til lembrar que a estimativa da equipe sobre tempo ideal, quer dizer, sem interrupes nem outras tarefas. O Scrum Master deve ajustar esse tempo ideal ao tempo real, multiplicando pelo fator correspondente. O Scrum Master responsvel pela adoo, desde cedo, da definio correta de quando um produto est pronto. Um Scrum Master muito flexvel pode ceder a presses do Dono do Produto, como mudanas no meio de um Sprint, que no so benficas para ningum. Um Scrum Master muito rgido pode degenerar a direo dos Scrums, tratando-os realmente como reunies de avano. O Scrum Master precisa impulsionar, da mesma forma, a melhoria de processos, por meio de retrospectivas frequentes ou quando a ocasio exigir. No comeo das atividades com Scrum, muito possvel que se escolham as duraes dos Sprints muito longas ou muito curtas. Isto no problema, pois a durao dos Sprints pode ser ajustada durante uma retrospectiva. Um problema comum entender gil como codificar e consertar. No h sequer a mnima documentao, faltam mtodos de engenharia de software na confeco de modelos ou no teste dos programas. Todas as boas prticas aprendidas so esquecidas ao adotar gil. Estes defeitos esto associados declarao que se adotou algo como Scrum, mas, ao contrrio do que ocorre no Scrum, no conhecido realmente o status de um requisito individual. Se a organizao mente para si mesma sobre o que constitui adotar Scrum, a estrutura inflexvel substituda pelo caos, perde-se o controle do projeto, as iteraes so de qualidade muito baixa e o sistema frgil frente s mudanas. Outra crtica, com fundamento, do mtodo Scrum que este no faz referncia a mtodos ou tcnicas de engenharia utilizadas no meio do Sprint. claro, isto assim pela concepo do scrum, mas continua sendo certo que devem ser adotadas ferramentas de engenharia de software que apoiem as tarefas da equipe. Uma equipe gil reconhece tticas geis, como Test Driven Development (TDD), refactoring, requisitos iterados e outras igualmente teis e as aplica. Em seguida veremos algumas destas tcnicas, de uso comum em equipes de Scrum. 3.4 XP: Inspees, Design, Cooperao e Muitas Provas Extreme Programming, normalmente conhecida como XP, um conjunto de tcnicas condensadas da engenharia de software tradicional, adaptadas para seu uso em equipes 32 pequenas que repetem rapidamente seus ciclos de desenvolvimento. De fato, Kent Beck , o pioneiro de XP, foi um dos primeiros a sugerir iteraes curtas com participao intensa do usurio durante elas. No livro citado, Beck explica sua posio extrema, dizendo que se as tcnicas da engenharia de software so boas, realiz-las todo o tempo ainda melhor. XP se apoia em cinco valores: Comunicao, Simplicidade, Retroalimentao, Coragem e Respeito. Desses cinco valores, Beck deriva cinco princpios, mais prticos e prximos produo que os valores: Retroalimentao rpida, para acelerar a aprendizagem; Busca contnua pela Simplicidade, para procurar a soluo mais simples; Mudana Incremental, para reduzir o impacto da mudana nas organizaes; Estar aberto Mudana, contrariamente a tentar control-la; e Trabalho com Qualidade, para que tanto o cliente quanto os desenvolvedores se sintam gratificados pela experincia. XP no tenta resolver todos os aspectos da engenharia de software, centrando-se fundamentalmente em quatro atividades: Codificar, Testar, Escutar e Desenhar. Diz Beck: Codifica-se porque se no codificarmos, no se fez nada. Testa-se porque se no testarmos, no se sabe se terminou a codificao. Escuta-se porque se no escutarmos, no se sabe o que codificar ou o que testar. E se desenha para poder seguir codificando, testando e
32
[BECK, 2000], Extreme Programming Explained, Addison-Wesley.
Capitulo 3
Pgina 23

33
Boria et al.
escutando indefinidamente . Beck oferece um repertrio de tcnicas que funcionam bem em equipes pequenas e foram amplamente adotadas, muitas vezes com sucesso, mas tambm s vezes criticadas. As tcnicas de Beck so: O Jogo do Planejamento; Pequenas Entregas (de produto); Metfora; Design Simples; Desenvolvimento Dirigido por Testes; Refatorao; Programao em Duplas (ou em Pares); Propriedade Coletiva (dos produtos pela equipe); Integrao Contnua; Semana de 40 Horas (hoje chamada Passo Sustentvel); Cliente Presente; e Padres de Cdigo. Como so de uso comum em muitas aplicaes de mtodos geis, entre as que adotam conscientemente ou no o XP, daremos aqui uma sntese de seu contedo, tentando explicar o suficiente para que aquelas que despertem o interesse do leitor possam ser investigadas na bibliografia oferecida. Recomendamos ao leitor [KNIBERG, 2007], Scrum and XP from the Trenches: How we do Scrum, por seu estilo prtico e abrangente.
O Jogo do Planejamento
Beck tenta equilibrar as necessidades do negcio com as necessidades (tcnicas) da equipe. Nenhuma, para ele, deve dominar a outra. Prope um dilogo onde a organizao cliente define o escopo, prioridades e a programao e composio das entregas ( releases) de cdigo. Michael Cohn, em [COHN, 2006], e Anderson em [ANDERSON, 2011], descrevem em detalhe uma variante que se chama o jogo do planejamento. Basicamente similar ao que Barry Boehm tornou popular como Wide Band Delphi em [BOEHM, 1981], quer dizer, uma estimativa feita por especialistas, neste caso, os membros da equipe, que converge a partir da discusso do primeiro resultado vendo a categoria e a mdia da estimativa. A iterao feita at que a diferena entre os extremos seja aceitvel, reduzindo-a em cada iterao mediante a justificativa de cada um sobre seu prognstico. importante que as equipes discutam com o cliente suas estimativas, mas no para que o cliente arbitrariamente fixe a durao das tarefas. A equipe tcnica tem a responsabilidade de alertar sobre as consequncias de escolher certos designs ou elementos tcnicos.
Pequenas Entregas
Todas as entregas em XP so feitas em perodos curtos, idealmente a cada duas semanas. Isto mantm o cliente interessado e comprometido, j que o feedback assim obtido aumenta o valor do produto.
Metfora
Ao invs de esperar que a arquitetura oferea coeso estrutura do produto, XP utiliza uma metfora, uma explicao de muito alto nvel do que se espera produzir. Por exemplo, ao invs de documentar em um diagrama as interfaces com os usurios e os componentes esperados, em XP se fala do comportamento como se fosse um terminal de Banco 24 Horas. Isto deveria ser suficiente para se deduzir propriedades e atributos do produto, por exemplo, que haver um administrador e diferentes tipos de clientes. Desse modo, reduzida a necessidade de refrescar a memria de cada programador quando cria o design.
Design Simples
Segundo Beck, o melhor design o que melhor se ajusta aos casos de teste, executa todos, no tem lgica duplicada, contm todos os atributos e intenes que os programadores querem do produto e faz isso com a menor quantidade de classes possvel.
Desenvolvimento Dirigido por Testes

No XP qualquer caracterstica do programa que no tenha um teste associado, no existe. Os programadores escrevem seus testes para ganhar e manter a confiana no cdigo que geram, e os clientes fazem isso pelo mesmo motivo. Ao acrescentar a quantidade de testes associados com o cdigo impossvel romp-lo ao introduzir mudanas sem que os defeitos saltem vista. De fato, o teste de regresso realizado permanentemente. No XP, o programador primeiro escreve o caso de teste da mudana que quer implementar e o executa sobre o cdigo atual, ou seja, sem modific-lo, assegurando-se de que no funcione. Desse
33
[BECK, 2000], op. cit. Captulo 9, Back to Basics, p. 49. Traduo dos autores.
Capitulo 3
Pgina 24
Boria et al.
modo verifica-se o caso de teste, que deve achar defeitos. Depois escreve o cdigo correspondente at que o caso de teste no encontre defeitos.
Figura 3.4: Ciclo de Desenvolvimento de XP
Refatorao
Este enfoque de mudanas pequenas pode ter um efeito indesejado, j que otimiza localmente o cdigo, podendo anular outras otimizaes locais e perdendo de vista a otimizao global. s vezes, necessrio realizar mudanas no design porque surgem certos padres de comportamento indesejveis. Uma das tarefas a realizar ao mudar o cdigo investigar a existncia de padres que no so considerados boa programao, como cdigo duplicado, dados que passam entre mtodos sem ser processados e outros mais que podem ser 34 encontrados nas referncias .
Programao em Duplas (ou em Pares)

A programao em duplas ou em pares, como seu nome indica, uma tcnica na qual duas ou s vezes trs pessoas trabalham juntas no desenvolvimento de um segmento do cdigo. So vrios os sites que discutem os prs e os contras da programao em duplas. Os autores se tendem a acreditar que a socializao da tarefa entre dois evita interrupes e permite aos dois programadores entrar em flow segundo tal definio em [CSIKSZENTMIHALYIS, 1991], de modo que a prpria tarefa flui (da o nome) e h prazer em lev-la adiante. desse modo que 35,36 justifica o sucesso da produtividade de sua tcnica particular de programao em duplas . Estudos realizados h muitos anos por [DE MARCO e LISTER, 1987] mostram que uma pessoa em um ambiente com baixa quantidade de interrupes at 3,8 vezes mais produtiva que outra da mesma competncia em um ambiente com as interrupes habituais. Este estudo anterior disperso dos sentidos propiciada pela internet, de modo que o ambiente normal de hoje em dia muito mais ruidoso do que era no final dos anos 80. pouco provvel que uma dupla de pessoas trabalhando juntas aceite interrupes, enquanto que uma pessoa sozinha em seu escritrio vtima do correio eletrnico , do Messenger e at do celular, em suas distintas variantes. Como se isto fosse pouco, as empresas fabricantes de telefones esto acrescentando mais inteligncia a seus produtos, e receberemos ainda mais interrupes: o voo de Dorita, a Exploradora, est saindo com atraso ou minha tia Rosinha comprou sapatos novos e publicou no Facebook, e por a vai. A programao em duplas nos
34 35
Vejam code smells, http://c2.com/cgi/wiki?CodeSmell
Os autores argumentam, alm disso, que ao trabalhar em uma equipe de duas pessoas (ou trs, se h um coach), as interrupes comuns de correios eletrnicos, conversas on-line e outras distraes que podem ser notadas nos cubculos dos programadores, desaparecem por completo. 36 http://www.codinghorror.com/blog/2006/09/the-multi-tasking-myth.html cita vrias fontes que atacam a crena de que fazer muitas coisas ao mesmo tempo serve para ganhar tempo.
Capitulo 3
Pgina 25
Boria et al.
poupa da humilhao de sucumbir a todas essas tentaes e permite que aproveitemos o flow. Uma variante importante da programao em duplas quando deixa de ser em dupla, ao ter um terceiro participante. Este costuma ser o lder tcnico, ou o programador mais respeitado pela equipe. Sua participao tem intenes formativas. Geralmente participa quando um ou os dois programadores carecem de experincia nesta tcnica. A seguir aproveitaremos para juntar estatsticas que podem ser usadas na coleta e anlise de dados de revises por duplas.
Propriedade Coletiva (dos produtos pela equipe)

Se duas pessoas podem participar do evento de programao e estas duplas podem mudar: quem o dono do produto? Obviamente, o programa pertence equipe em sua totalidade. Cada um participa da responsabilidade de melhorar o produto e ajudar a equipe a se apropriar do produto.
Integrao Contnua
Parte da possibilidade de ter propriedade coletiva do cdigo o fato de que a qualidade dele colocada prova o tempo todo, deixando em evidncia qualquer defeito quase to rapidamente quanto se incorre nele. Para comear, o design guiado pelos testes inicia um caminho baseado na qualidade como meta, e para seguir, a integrao contnua aproveita a gerao dos casos de teste para verificar cada mudana contra a base de dados de teste, assegurando que no h regresso de defeitos anteriores. Isto implica que cada novo acrscimo de cdigo integrado o mais rpido possvel ao produto em evoluo. Para concluir, a equipe apresenta com regularidade, em perodos curtos, seu produto parcial ao cliente, de modo que o feedback frequente e possvel senti-lo. frequente que se gerem regras nas equipes relacionadas com esta integrao contnua, que requer um software especializado e uma disciplina de gesto da configurao e de controle de mudanas muito bem definida.
Semana de 40 Horas (hoje chamada Passo Sustentvel)

Apesar de ter muitas regras que a diferenciam das equipes comuns, uma equipe XP suscetvel aos mesmos problemas derivados das presses do ambiente. possvel que se capitule ante um cliente loquaz e persistente, deixando a equipe com uma tarefa de maior envergadura do que pode fazer razoavelmente. A regra que no se trabalhe fora do horrio, mas se isso for necessrio, importante que se estenda por mais de uma semana. Algumas equipes levam isto a um Sprint, outras a duas semanas, mas todas tm claro que o pessoal cansado introduz muitos defeitos e estes introduzem muita desconfiana, retrabalho e interrupes.
Cliente Presente
Grande parte do sucesso de um projeto, seja gil ou no, baseia-se na participao do cliente. J vimos (nota 30 deste captulo) que um usurio colaborativo, representativo, autorizado, comprometido e com conhecimento primordial para o sucesso de um projeto. Mas se isto certo para os projetos tradicionais, indispensvel para XP, ainda mais que para Scrum. Durante o Sprint, em Scrum, o Dono do Produto est ausente e s participa convocado pela equipe. Em XP parte da equipe, convive com ela. Isto permite validar as ideias rapidamente e contar com uma voz que permita seguir caminhos alternativos quando for necessrio.
Padres do Cdigo
O ltimo ponto que tocaremos aqui sobre padres de cdigo. Se os programadores escolhem o cdigo que querem modificar, trabalham com distintos colegas vrias vezes por dia, e o cdigo deve ser lido e entendido por todos, melhor que haja um nico estilo de programao. H muitos anos que [KERNIGHAN e PLAUGER, 1974] falam do estilo de programao. Ns aconselhamos muito mais que um padro. A equipe teria de ler o livro sobre estilos de programao e adotar suas prprias regras. A maneira de introduzi-las sendo fiel programao em duplas, com ou sem o coach presente.
Capitulo 3
Pgina 26
Boria et al.
Escalonamento
Quase desde o princpio de sua existncia, a engenharia de software se ocupa de dois 37 problemas ligados entre si: Programming in the Large e Programming in the Many . O primeiro problema o de atacar projetos grandes. O conceito de grande relativo m dia que produz a organizao. Se uma organizao habitualmente gera 100.000 linhas de cdigo por ano, um incremento de 10.000 linhas para um ano um problema logstico, mas no muda radicalmente a natureza do assunto. Por outro lado, para a organizao que habitualmente gera 6.000 linhas de cdigo anuais, 10.000 linhas a mais pode ser um salto quantitativo impossvel de absorver. claro, uma parte da soluo consiste em acrescentar pessoal, o que se conhece como Programming in the Many. Como conhecido, a aprendizagem da programao um processo individual. Portanto, aprender a programar com muitos e entre muitos um exerccio disciplinar importante. No caso dos mtodos geis existem autores que se dedicaram a resolver estes problemas, notavelmente [COCKBURN, 2005] e [PALMER e FELSING, 2002], estes ltimos sobre as ideias originais de Peter Coad [COAD et al., 1999]. No caso de Cockburn, seu mtodo Crystal Clear , na realidade, uma famlia de mtodos cada vez mais complexos. As ideias de Coad, por outro lado, esto baseadas em slidos argumentos arquitetnicos; ns as usaremos porque o que foi apresentado at aqui no til para sistemas grandes e complexos, a serem desenvolvidos por equipes numerosas. Nenhum dos trs mtodos esboados neste captulo escala bem, no sentido de que, medida que necessria uma equipe de maior tamanho para poder entregar um sistema maior e complexo em prazos aceitveis pelo mercado, todos eles comeam a perder propriedades que so manifestas quando a equipe pequena. Kanban aquele que, por ter menos regras, tambm tem menores expectativas; mas ocorre que seu prprio objetivo, o de reduzir o nmero de componentes em desenvolvimento ao mesmo tempo, conspira contra seu uso em sistemas grandes e complexos. 3.5 Feature Driven Development Feature Driven Development, ou FDD, uma alternativa interessante porque combina a velocidade e flexibilidade dos mtodos geis com alta escalabilidade. Utilizando algumas tcnicas de alto impacto, extradas das boas prticas de engenharia de software, FDD consegue harmonizar o uso de modelos e planejamento com prticas geis. FDD, na verdade, consegue se colocar no meio das faces que apoiam um ou outro lado na guerra religiosa entre os agilistas e os tradicionalistas. Contado em poucas palavras, FDD consiste em desenvolver um modelo do domnio entre a equipe de desenvolvimento e os especialistas no contexto. Tirando a informao do desenvolvimento do modelo e outras atividades que poderiam ter acontecido em relao identificao de requisitos, a equipe constri uma lista de particularidades e caractersticas do produto (features) expressando-a como funes formuladas sob um padro <ao> <resultado> <objeto>. Por exemplo, Calcular o total de horas trabalhadas pelos consultores, ou Devolver o valor da hora mdia de esforo por ponto de funo. Cada uma destas funes suficientemente pequena e uma equipe pode implement-la em duas semanas de trabalho ou menos. No entanto, tampouco desejvel que sejam muito fragmentadas. desejvel que as funes s se dividam em outras menores quando se intui que em duas semanas no podero ser implementadas, de outro modo so mantidas nesse nvel de abstrao. Agora, possvel seguir o modelo para fazer um planejamento rpido e colocar para trabalhar em paralelo vrias equipes que coordenem suas interfaces utilizando um mesmo modelo, atribuindo as funes da lista. Mediante este simples procedimento se evitam muitas dores de cabea posteriores, muitas horas de refatorao e muitos defeitos entregues ao cliente. O ciclo de desenvolvimento de FDD muito formal. De todos que vimos, o que tem a definio mais parecida aos processos tpicos das organizaes grandes. Pode ser porque os autores querem uma clara definio dos passos e dos papis, pode ter sido uma exigncia do ambiente para conseguir sua adoo nas primeiras implementaes. O caso que os cinco
37
[BORIA, 1987] Ingeniera de Software, Kapelusz
Capitulo 3
Pgina 27
Boria et al.
processos que mostraremos na Figura 3.5 esto perfeitamente definidos, assim como os papis dos atores que os executam.
Figura 3.5: Ciclo de Desenvolvimento de FDD
Vamos detalhar um pouco os cinco processos. O primeiro processo comea quando se determinam os principais atores para todos os papis requeridos. FDD possui seis papis chave. O principal papel o de Gerente de Projeto. o responsvel administrativo do projeto e deve manter o sistema projeto andando. Bastante parecido com o Scrum Master, o Gerente de Projeto FDD se ocupa de que o processo seja seguido e que sua equipe possa funcionar livre de interrupes. Diferente do Scrum Master, o Gerente de Projetos FDD tem a ltima palavra em relao ao escopo, oramentos mensais e dotao do projeto. O segundo papel fundamental o de Arquiteto-Chefe. Este papel a contrapartida tcnica do Gerente. Apesar do Arquiteto ser o responsvel pelo resultado do design, suas tarefas incluem facilitar reunies que permitam aos especialistas no domnio e membros escolhidos da equipe desenhar as caractersticas do produto. No entanto, o cargo implica em ter a experincia necessria para poder tomar a deciso definitiva sobre o design arquitetnico (ou projeto da arquitetura). Se o projeto muito simples e a pessoa est capacitada, os papis de Gerente de Projeto e Arquiteto-Chefe podem ser acumulados por uma s pessoa. Se o projeto muito complexo tecnicamente e requer muita experincia no domnio ou muito tempo com o cliente, o papel de Arquiteto-Chefe pode ser dividido entre duas pessoas. Um terceiro papel exigido o de Gerente de Desenvolvimento. Pela natureza do FDD, vrias equipes desenvolvem simultaneamente, o que pode trazer conflitos sobre o uso de recursos. O Gerente de Desenvolvimento tem como principal tarefa resolver esses conflitos, utilizando critrios tcnicos e conhecimento das necessidades do cliente. Frequentemente, o papel atribudo ao Gerente de Projeto ou ao Arquiteto-Chefe. Pode-se notar que o papel exige conhecimento tcnico, conhecimento do domnio do cliente e muita capacidade de mediar, buscar o ganha-ganha, resolver conflitos, ou at evitar que eles aconteam. O quarto papel atribudo a mltiplos profissionais, um para cada equipe formada, e seu nome 38 Programador-Chefe . O Programador-Chefe uma pessoa de grandes habilidades tcnicas que passou por vrias iteraes do ciclo de vida de desenvolvimento repetidas vezes e capaz de liderar um grupo pequeno. Responde ao plano geral do Arquiteto e trabalha de forma coordenada com o Gerente de Desenvolvimento e os demais Programadores-Chefe. O quinto papel o dos que realizam o desenvolvimento cotidiano, chamados de Dono da Classe em FDD. Cada Dono da Classe um programador de mrito (no FDD no h lugar para a mediocridade) e tem como responsabilidade as atividades de desenvolvimento, teste e documentao de uma parte do produto final, seguindo padres de programao definidos e, s vezes, colaborando com o Programador-Chefe.
38
As equipes de Programador-Chefe esto descritas por [BROOKS, 1995] seguindo a implementao que fez Harlan Mills na IBM.
Capitulo 3
Pgina 28
Boria et al.
O sexto e ltimo dos papis exigidos o de Especialista no Domnio. O fato de ser o ltimo em nossa lista no o torna menos importante e, de fato, pode ser o que mais impacto causa na qualidade final do produto e no sucesso do projeto. Alm de contar com a bvia experincia no domnio, que pode estar dividida entre vrios protagonistas, necessrio que os Especialistas no Domnio tenham as outras caractersticas de CRACK que j mencionamos (ver a nota 31). Sem disponibilidade destes usurios, muito difcil que a equipe concretize um produto de sucesso. Depois que os protagonistas so determinados para todos os papis, com a possvel exceo dos Donos de Classe que no precisam participar, o processo pode comear. No primeiro processo se desenvolve um modelo global do produto a ser implementado. importante assinalar que, igual citao atribuda a Eisenhower, os planos no servem, mas o planejamento tudo, o modelo no o que importa nesta etapa. muito mais importante usar a construo do modelo para estabelecer uma relao com o cliente e investigar as reas cinzentas do conhecimento do domnio. Esta etapa importante no porque o resultado um diagrama que defina com exatido a natureza e os objetivos do produto, mas porque ilumina a equipe a respeito de quem so os especialistas no domnio, com que apoio pode contar e quais so as grandes ideias que guiam o cliente. De qualquer modo, se no h um produto, no h um critrio de finalizao, e como j dissemos, FDD tem claramente definidos cada um desses critrios para os cinco processos, ao contrrio dos mtodos anteriores, que deixam a definio do critrio de finalizao de cada elemento equipe. Para dar por concludo o primeiro processo, o Arquiteto-Chefe do projeto deve estar de acordo com o modelo resultante. O modelo deve ter sido construdo com o auxlio de todas as partes envolvidas. Isto inclui claramente a equipe de Especialistas no Domnio, mas se for possvel a participao dos Donos da Classe, estes deveriam se revezar entre as equipes para se embeber com os conhecimentos dos especialistas e resolv-los pessoalmente. O FDD tem sua prpria descrio das tarefas a serem realizadas, o que no impede que os autores recomendem muito uma leitura dos livros de [ANDRIOLE, 1993] e [WOOD e SILVER, 1995] e, sobretudo, do artigo de [ZAHNISER, 1995] em seu site de internet, para ter uma ideia clara das opes, tcnicas a empregar e resultados esperados. Depois que se chegou ao modelo que representa bem o produto, a equipe passa ao segundo 39 processo, construir a lista de funes . Neste passo, a equipe reduzida aos ProgramadoresChefe. Partindo da diviso arquitetnica inicial resultante do primeiro passo, os Programadores-Chefe, ou a equipe da lista de funes, constri a lista das caractersticas que sero implementadas. O processo iterativo. Juntam-se ao redor do design arquitetnico, para o qual j existe uma lista preliminar de tarefas designadas e estas so redistribudas em reas. Cada rea um conjunto afim de funcionalidades, possivelmente com seus prprios requisitos no funcionais (segurana, velocidade de resposta, disponibilidade, legibilidade, manutenibilidade e outros do tipo). As reas, depois de estabilizadas, voltam a se separar em atividades, onde cada uma delas um conjunto mais detalhado e reduzido da funcionalidade de uma rea. Por exemplo, no nvel mais alto, a arquitetura tem um componente com o nome Gerenciamento, debaixo da qual so listadas certas atividades: gerenciar clientes, contas, revises, consertos, etc. Ao definir reas, a gerncia global pode ser uma delas, contendo uma lista de funes relacionadas ao mesmo tempo com todas as outras reas. Teria, da mesma forma, reas para clientes, contas e ajustes, a ltima categoria sendo uma sntese das duas atividades, clientes e contas, listadas na arquitetura como separadas. Quer dizer, a criao de reas no est de modo algum limitada pela lista inicial da arquitetura, mas o resultado da experincia dos Programadores-Chefe com domnios semelhantes. Depois que as atividades foram definidas nas reas, cada passo dentro delas uma funo. Por exemplo, a atividade de gerenciar clientes na rea de gerncia pode incluir os passos: Criar Cliente, Ajustar dados do Cliente, Equilibrar dados do Cliente, Dar baixa de Cliente. O resultado deste processo uma lista derivada da arquitetura e vinculada a ela, que adota a forma de uma rvore. Percorrer a rvore a partir da raiz at o n mais profundo de um galho implica passar pelos trs nveis: Arquitetura Base, reas, Atividades e Passos (Figura 3.6). A
39
Estamos usando funes, ou caractersticas, para traduzir o original em ingls features.
Capitulo 3
Pgina 29
Boria et al.
lista ento no s contm todas as funes a serem implementadas, mas, ao ser uma rvore, permite designar requisitos no-funcionais a ns intermedirios, de modo que criada realmente uma boa descrio arquitetnica do produto. Seguindo [HOFMEISTER et al., 2000] o nvel base o nvel Conceitual, as reas constituem o Nvel Modular e as funes so a base para os dois nveis seguintes: Execuo e Cdigo.
Figura 3.6: rvore de Funes derivada da Arquitetura
O leitor interessado pode combinar as tcnicas do FDD com as sugeridas no livro Applied Software Architecture [HOFMEISTER, 1999] para obter resultados ainda melhores em aplicaes crticas. O terceiro passo do FDD a aplicao do processo de realizar o plano do projeto completo contemplando cada funo. O Gerente de Projeto, o Gerente de Desenvolvimento e os Programadores-Chefe se renem com a lista de funes diante deles e atribuem cada uma das funes aos programadores, que se convertem assim em Donos da Classe. Cada Programador pode ser dono de muitas classes, dependendo de sua experincia, da complexidade e granularidade dessas classes e do grau de conhecimento que tenha do domnio. Os Programadores-Chefe so considerados, para este efeito, programadores e, portanto, acumulam o papel de Programador-Chefe e de Donos da Classe. A atribuio de funes leva em conta muitas variveis, tais como a prioridade do cliente para a implementao de reas, a interdependncia das funes, sua complexidade e seu tamanho, a facilidade com que podem ser testadas dependendo da ordem de implementao e da disponibilidade do pessoal. O processo se repete sobre reas e vai reatribuindo tarefas medida que as prioridades que so analisadas vo sendo mudadas. Ao finalizar o passo, cada Programador-Chefe tem tarefas atribudas e um calendrio para realiz-las. Com suas tarefas na mo, cada Programador-Chefe organiza sua equipe de desenvolvimento. No quarto passo, a partir de uma viso associada a cada tarefa da lista, o Programador-Chefe procura as classes associadas a cada uma e busca identificar os programadores que vo participar. Se existirem novas classes associadas, ele as atribui. Este processo se aplica a uma ou mais tarefas a cada vez, considerando todas aquelas que valem a pena implementar em um ciclo de, no mximo, duas semanas para uma equipe. Se o domnio associado simples e bem conhecido, o Programador-Chefe pode iniciar o design do trabalho. Isto implica no desenvolvimento da documentao que permita ao Dono da Classe modificar, estender ou criar o cdigo correspondente sem interveno de especialistas no domnio. Caso contrrio, o Programador-Chefe pede ajuda aos Especialistas para realizar uma reviso do domnio correspondente ao conjunto de funes a implementar. O Especialista, ou os Especialistas, percorrem o domnio realizando uma apresentao equipe, onde so tratadas as regras do negcio, os algoritmos da aplicao e os dados necessrios para realizar as funes. Se existirem documentos associados s funes, estes so mencionados e explicados. A equipe ento os estuda para desenvolver, em primeiro lugar, o diagrama de sequncia que define a funcionalidade. Aps a definio dos itens de configurao, a equipe se dedica a refinar as classes para acomodar a funcionalidade, o que
Capitulo 3
Pgina 30
Boria et al.
permite ao Programador-Chefe publicar um modelo atualizado a ser compartilhado por toda a equipe. Usando ferramentas CASE, o Programador-Chefe atualiza o esqueleto do programa para que se ajuste ao modelo. Depois, cada Dono da Classe toma suas classes e as atualiza para refletir as mudanas no modelo e acrescenta os comentrios, o prlogo e, se foi 40 acordado, o invariante resultado da execuo dos mtodos da classe . Finalmente, a equipe revisa o design resultante para garantir sua totalidade, consistncia e o que pode ser realizado 41 segundo o plano. Este o critrio de sada da fase . O ltimo passo a fase de construo de cada pacote, que deve ter sido definido no passo anterior. Nesta fase o cdigo necessrio escrito ou modificado, feita uma inspeo do cdigo e realizado o teste de unidades, para comprovar que o produto que est sendo construdo no seja includo na baseline do cdigo com defeitos conhecidos. Ao se aprovar o produto, ele integrado seguindo os procedimentos habituais de gesto de configurao. 3.6 Resumo Este captulo cobriu quatro dos melhores mtodos geis. comum selecionar prticas de um mtodo e utiliz-las em outro. Tanto que existiu um nome prprio para a combinao de Scrum com XP, XBREED, que j no significa nada (o site na internet foi ocupado por um advogado especialista em danos por acidente). Kanban especialmente til para comear um processo de melhorias. A visibilidade que oferece e a baixssima exigncia de mudanas fazem com que o peso da responsabilidade pela qualidade fique na equipe de desenvolvimento e no em uma equipe organizacional de processos. Em nossa experincia, a melhor forma de conseguir a adoo de melhorias. Scrum aumenta as exigncias, mas sua reputao est justificada: um mtodo que acelera dramaticamente a produo de software e gera sistemas de boa qualidade. Como tambm deixa muita liberdade equipe a respeito das tcnicas de engenharia, muito frequente que seja adotado junto com o XP, RUP ou outra (assim chamada) metodologia. Todas estas prticas so bastante teis, mas se escalam relativamente mal. Como os limites ao crescimento so muito rgidos, a adoo de um mtodo mais formal, mas que tenta aproveitar os melhores conselhos dos agilistas, se faz necessria para esses projetos que, ou atacam um volume grande de cdigo ou se ocupam de manter um produto de grande porte com muita complexidade. Escolhemos FDD por nossa afinidade com a corrente de Cutter Consortium, mas igualmente poderamos ter escolhido Crystal (op cit.). FDD , para ns, autores, o formato ideal para ser usado com os modelos de maturidade inspirados 42 em CMM , tais como o MPS ou o CMMI.
40
Para ver o uso do invariante da classe em engenharia de software, ver [BORIA, 1987] ou para um tratamento mais profundo e sistemtico, [GRIES, 1987]. 41 Usamos indistintamente fase, passo e processo para nos referirmos s cinco fases do FDD. 42 [PAULK et al., 1994] seguindo a [HUMPHREY, 1989].
Capitulo 3
Pgina 31
Boria et al.
CAPTULO 4 - O MODELO DE MELHORIA DE PROCESSOS DE SOFTWARE MPS-SW 4.1 Competir com a excelncia Entre as muitas variveis que compem o sucesso de uma empresa de desenvolvimento de software, a qualidade uma das poucas que se contam dentro da classe do alcanvel. Poucas so as empresas que obtm seus lucros com produtos realmente inovadores; para a maioria, o negcio produzir melhor que a concorrncia e a um menor custo. Utilizam seu conhecimento do domnio para melhorar a satisfao de seus clientes e ampliar sua carteira, tornando cada vez mais caro o custo de transferncia para produtos dos concorrentes, retendo e ampliando sua cota de mercado. Nesse contexto, os custos de desenvolvimento so mais importantes que os preos, porque a falta de monoplio faz com que a concorrncia tente entrar no mercado, diminuindo os preos. Para uma empresa pequena ou mdia que luta para manter seu lugar no mercado, a qualidade primordial, porque os custos de desenvolvimento so mascarados pelos custos de refazer o trabalho. Em [DIAZ e KING, 2002], os autores mostram que o retrabalho supera a quinta parte do esforo total de um projeto (Figura 4.1). Colocado em termos que uma pessoa comum pode entender, o engenheiro de software joga fora uma em cada cinco coisas que faz. Se fosse uma lavanderia, uma em cada cinco peas de roupa lavada teria de voltar ao lava-roupas. As organizaes pequenas e mdias no podem suportar um custo to excessivo. Como j explicamos no Captulo 2, quando fizemos a proposta do uso de LS (Lean Simplified) como o mtodo de tratamento do problema, necessrio identificar as fontes de defeitos e remov-las. Apesar de ser possvel fazer uso do LS sem nenhum outro apoio, a procura dos defeitos ., em si, uma arte. A maioria das pessoas se sente mais cmoda seguindo um guia. A grande contribuio de Watts Humphrey [HUMPHREY, 1989] consiste na criao de um modelo de 43 estados que oferece precisamente esse guia .
Tabela 1: Sistema de Deciso General Dyamics Desempenho do Projeto vs. Nivel CMM
Nvel CMM Porcentagem Eficcia da Densidade Produtividade Retrabalho Fase de CRUD (x Fator Conteno por Relativo) KSLOC 23.2% 25.5% 3.20 1x 14.2% 9.5% 6.8% 41.5% 62.3% 87.3% 0.90 0.22 0.19 2x 1.9 x 2.9 x
2 3 4 5
Figura 4.1: Relao da Refatorao vs. Nvel do CMM [DIAZ e KING, 2002]
De fato, os modelos de estados so anteriores ao trabalho de Humphrey. Em um famoso 44 trabalho , Richard Nolan introduz um modelo de estados para a gesto de recursos computacionais. Como preldio, Nolan descreve diferentes usos dos modelos de estados, em campos to diversos como a astronomia (a formao de estrelas, galxias e sistemas solares), biologia, ecologia e, desde o sculo XIX, a economia dos pases. Em particular faz referncia a
43
Uma histria que circulava na TeraQuest, no final da ltima dcada do sculo passado, relatava que Watts Humphrey teve sua Eureka a bordo de um avio que o levava de volta a Pittsburgh depois de um seminrio no Instituto Juran. Fervoroso admirador das teorias de Deming, Juran e Crosby, Humphrey definiu como seu objetivo eliminar a dificuldade de aplicar as tcnicas da qualidade total, incluindo os grficos de comportamento de processos (cartas de controle), engenharia de software. Teve sua inspirao ao compreender a necessidade de estabelecer processos comuns, que possam ser analisados estatisticamente. Da seu modelo de estados. 44 [NOLAN, 1973]. Note-se a homenagem implcita a este artigo como fonte de inspirao no nome do livro de Humphrey op. cit.
Capitulo 4
Pgina 32
Boria et al.
45
dois critrios para a boa formao de modelos de estados, descritos por Simon Kuznets : os estados devem estar bem definidos e devem ser claramente diferentes e demonstrveis empiricamente; e a relao analtica de qualquer estado com seu predecessor ou sucessor deve estar bem definida, tornando possvel identificar os processos que fazem um objeto passar de um estado a outro. Continuando nossa rota, tentaremos demonstrar que o modelo de referncia MPS-SW um slido modelo de estados. 4.2 Um caminho para a excelncia organizacional O Modelo de Referncia para Software MPS (MR-MPS-SW) [SOFTEX, 2012a] um modelo de maturidade de processos, inspirado e compatvel com o CMMI-DEV [SEI, 2010] e aderente s normas internacionais ISO/IEC 12207 [ISO/IEC, 2008] e ISO/IEC 15504 [ISO/IEC, 2003]. Historicamente, a maioria dos enfoques sobre qualidade desenvolveu normas de boas prticas a serem aplicadas. Apesar de cumprirem uma funo importante ao difundir mtodos testados e ajudarem a focar esforos em qualidade, elas se centram em seu cumprimento e no no desenvolvimento da organizao. AS NORMAS EXIGEM CUMPRIMENTO OS MODELOS PROCURAM DESENVOLVIMENTO A vantagem de um modelo de melhoria de processos que indica um caminho desejvel para alcanar a excelncia. As normas podem ser cumpridas; mas, se so vistas como uma lista de regras a seguir, podem no ser mais do que a soma das partes. Por outro lado, um modelo, quando bem interpretado, alm de indicar as melhores prticas, tambm mostra uma possvel ordenao ao apresentar a sequncia mais lgica de implementao. Os modelos mais teis possuem formas de avaliar o grau de implementao em que se encontra uma empresa. O MR-MPS-SW no uma exceo, e esta valiosa ferramenta permite empresa interessada na melhoria de seus processos entender o que j tem implementado e o que falta, alm de sugerir os prximos passos. A desvantagem de um modelo que os caminhos de implementao so mltiplos e dependem da empresa em questo. De certo modo, a articulao de Lean Simplified com um modelo como o MPS a ferramenta ideal, j que permite identificar as mudanas mais significativas com LS e utilizar as recomendaes do modelo para realiz-las. Apesar de que as normas so muito mais fceis de interpretar e implementar, o efeito sinrgico que possuem muito escasso e difcil de encontrar, mesmo com muita experincia. A concorrente de uma empresa que procura a excelncia ela mesma. Os concorrentes que se centram no que faz o outro no podem concorrer a longo prazo com aqueles que perseguem a excelncia por meio da melhoria contnua. Em particular, tenta-se que o modelo MPS seja adequado ao perfil de empresas com diferentes tamanhos e caractersticas, pblicas e privadas, com especial ateno s micro, pequenas e mdias empresas. Tambm espera-se que o modelo MPS seja compatvel com os padres de qualidade aceitos internacionalmente e que tenha como pr-requisito o aproveitamento de toda competncia existente nas normas e modelos de melhoria de processos j disponveis. Dessa forma, tem como base os requisitos de processos definidos nos modelos de melhoria de processos e responde necessidade de implantar os princpios de engenharia de software de forma adequada ao contexto das empresas, estando em consonncia com as principais abordagens internacionais para 46 definio, avaliao e melhoria de processos de software .
45 46
[KUZNETS, 1966] [SOFTEX, 2012a], pgina 6
Capitulo 4
Pgina 33
Boria et al.
Figura 4.2: Organizao do MPS.BR [SOFTEX, 2011l]
Em particular, o MPS se ajusta nomenclatura internacional de guias. H um Guia Geral MPS de Software, MR-MPS-SW [SOFTEX, 2012a], j citado, cuja leitura indispensvel para 47 entender a gnese , os objetivos do modelo e o modelo de negcios. H um Guia Geral MPS de Servios [SOFTEX, 2012b], um Guia de Aquisio [SOFTEX, 2011a] e um Guia de Avaliao [SOFTEX, 2012c]. Voltaremos a este ltimo antes de fechar este captulo. H tambm um Guia de Implementao para cada nvel [SOFTEX 2011b; SOFTEX, 2011c; SOFTEX, 2011d; SOFTEX, 2011e; SOFTEX, 2011f; SOFTEX, 2011g; SOFTEX, 2011h;], alm de guias de implementao para Fbrica de Software [SOFTEX, 2011j], para Fbrica de Testes [SOFTEX, 2011k] e para empresas que fazem aquisio de software [SOFTEX, 2011i], mais um com orientaes para a implementao e avaliao do MR-MPS-SW em conjunto com o CMMI-DEV [SOFTEX, 2012d], outro [SOFTEX, 2012e] com uma anlise de aderncia do MRMPS-SW em relao NBR ISO/IEC 29110-4-1 [ABNT, 2012] e um outro [SOFTEX, 2012f] com o mapeamento e sistemas de equivalncias entre o MR-MPS-SW e o MoProSoft [OKTABA et al., 2005]. O modelo de negcios do MPS divide claramente os papis e responsabilidades, definindo nos extremos os clientes, usurios finais do modelo, de um lado, e do outro, o Programa MPS.BR coordenado pela SOFTEX, o organismo que dirige o modelo e as instituies habilitadas para implement-lo e avali-lo. Estes dois grupos, no excludentes, devem ser autorizados pela SOFTEX para atuar dentro dos limites do modelo.
Figura 4.3: Componentes do Modelo MPS [SOFTEX, 2012a]
47
[SOFTEX, 2012a], pgina 15, Seo 7, Base tcnica para a definio do modelo MPS
Capitulo 4
Pgina 34
Boria et al.
4.3 Arquitetura do MPS O MPS tem uma arquitetura muito simples. Por um lado, so descritos os processos que compem o modelo. Cada processo tem seu propsito e seus resultados esperados. possvel entender cada processo de forma separada, mas no reside a o valor do modelo: como modelo de estados de maturidade, o MPS organiza o desenvolvimento utilizando grupos de processos. No MPS, os nveis de maturidade so sete, do G ao A. Para alcanar um certo nvel de maturidade, a organizao deve cumprir com todos os resultados esperados dos processos definidos at (e incluindo) o nvel de maturidade em questo. Os nveis de maturidade so cumulativos, quer dizer, para alcanar o F deve-se tambm atender o G. Para alcanar o E deve-se atender o F, o que implica em atender tambm o G. Assim, para alcanar um nvel, preciso mostrar que todos os resultados de todos os processos definidos para ele foram alcanados e tambm todos os que esto abaixo. O leitor pode imaginar os nveis como bonecas russas, uma dentro da outra. Alm disso, preciso mostrar que os Atributos de Processo correspondentes ao nvel em questo tambm esto cobertos. Estes Atributos de Processo so mostrados na Figura 4.4 nas colunas da direita e so denominados AP (Atributos de Processo). Os Atributos de Processo definem a Capacidade do Processo e tambm esto descritos em termos de resultados esperados, como os processos em si. A Capacidade do Processo expressa o grau de refinamento e a institucionalizao com que o processo executado na organizao. Nvel Processos A Atributos de Processo AP 1.1, AP 2.1, AP 2.2, AP 3.1, AP 3.2, AP 4.1, AP 4.2, AP 5.1 e AP 5.2 AP 1.1, AP 2.1, AP 2.2, AP 3.1, AP 3.2, AP 4.1 e AP 4.2 AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP 3.2 AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP 3.2
Gerncia de Projetos GPR (evoluo) Gerncia de Riscos GRI Desenvolvimento para Reutilizao DRU Gerncia de Decises GDE Verificao VER Validao VAL Projeto e Construo do Produto PCP Integrao do Produto ITP Desenvolvimento de Requisitos DRE Gerncia de Projetos GPR (evoluo) Gerncia de Reutilizao GRU Gerncia de Recursos Humanos GRH Definio do Processo Organizacional DFP Avaliao e Melhoria do Processo Organizacional AMP Medio MED Garantia da Qualidade GQA Gerncia de Portflio de Projetos GPP Gerncia de Configurao GCO Aquisio AQU Gerncia de Requisitos GRE Gerncia de Projetos GPR
AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP 3.2
AP 1.1, AP 2.1 e AP 2.2
AP 1.1 e AP 2.1
Figura 4.4: Nveis de maturidade do MR-MPS-SW [SOFTEX, 2012a]
No Modelo de Referncia MPS, medida que a organizao evolui pelos nveis de maturidade, a capacidade para realizar os processos deve melhorar da mesma forma. No entanto, os benefcios em termos de desempenho no surgem do rigor com que estes so implementados, mas da cultura que gerada por sua aplicao correta e consistente. A capacidade para realizar os processos manifestada pela implementao dos Atributos de Processo (AP), que por sua vez manifestada pela implementao dos Resultados esperados dos Atributos de Processo (RAP). A Figura 4.5 descreve a arquitetura graficamente.
Capitulo 4
Pgina 35
Boria et al.
Figura 4.5: Estrutura do MPS [SOFTEX, 2011l]
Os detalhes de cada processo e os Atributos de Processo de cada nvel sero discutidos em maior detalhe nos respectivos captulos que tratam, um a um, o desenvolvimento organizacional da empresa Tahini-Tahini. Enquanto isso, focaremos na promessa que fizemos ao comear este Captulo. 4.4 Os Nveis de Maturidade do MPS Os dois critrios para a boa formao de modelos de esta dos definidos por Kuznets so que os estados devem estar bem definidos, ser claramente distintos e demonstrveis empiricamente; e que a relao analtica de qualquer estado com seu predecessor ou sucessor deve estar bem definida, tornando possvel identificar os processos que fazem com que um objeto se mova de um estado ao outro. Para ver se o MPS cumpre com a primeira condio basta revisar com detalhes a Figura 4.4. Cada um dos diferentes nveis tm perfeitamente definidos os processos que os constituem e estes processos so diferentes, mesmo quando tiverem o mesmo nome, j que esses so evolues dos homnimos anteriores e, sendo assim, so diferentes. Os nveis, alm disso, esto bem definidos, diferenciando-se pelos Atributos de Processo que devem ser implementados em cada caso. Vejamos o que caracteriza cada nvel. Imaginemos uma empresa que no tem processos bem definidos e faamos com que amadurea por meio dos nveis do MPS, comeando pelo nvel G: a empresa precisa, primeiro, ter o controle das tarefas, a partir dos requisitos, para poder cumprir seus compromissos. Ao invs de correr para implementar o que o cliente quer, a equipe faz uma pausa para planejar e entre as tarefas planejadas est o monitoramento. Surge a cultura bsica de projetos. Os benefcios do Nvel G se manifestam em um melhor foco no negcio, porque os compromissos assumidos so compreendidos e honrados. H entendimento suficiente do estado do projeto para administrar as expectativas dos clientes. H, da mesma maneira, uma maior transparncia. O estado do projeto comunicado e compartilhado. As expectativas so documentadas e explicadas. A alta gerncia trabalha com informao verdica. O outro resultado importante deste nvel a instituio de uma nova disciplina, pela qual as equipes revisam e atualizam os compromissos. Estes so respeitados e todos os esforos so feitos para que isso seja realizado com transparncia. Para passar do nvel G ao F, a organizao precisa tomar conscincia do valor de fazer as coisas de forma repetvel e deve comear a cuidar de seus ativos organizacionais. preciso comear a medir para entender e poder melhorar seu sistema de deciso. no Nvel F que comea a cultura da objetividade. Isto se manifesta em um Sistema de Medies, pelo qual se distingue entre medir e usar indicadores de gesto. O Sistema de Medies est alinhado com as necessidades de informao dos vrios nveis e fornece retroalimentao verdadeira aos que tomam decises. Alm disso, a organizao cuida de proteger de seus ativos: os produtos de trabalho so reconhecidos como ativos organizacionais e protegidos. Controlam-se as mudanas e so criadas verses dos produtos da equipe como parte integral do processo. No Nvel F , tambm, adotada uma melhor estratgia de relacionamento com os fornecedores. Os acordos so estabelecidos para beneficiar todas as partes, no s o adquirente. Comeam a integrar os fornecedores com a linha de produo, com o propsito de eliminar esperas e diminuir custos. Comea-se a entender que os funcionrios no so um custo irrecupervel, mas um ativo que pode ser utilizado de diferentes maneiras, e estas podem ser medidas e comparadas. A gerncia do portflio de projetos permite aproveitar ao mximo os recursos e esforos da organizao de forma alinhada com seus objetivos estratgicos.
Capitulo 4
Pgina 36
Boria et al.
Do F ao E: O valor do que repetvel passa a ser o valor do que pode ser compartilhado. A organizao foca no aprendizado e cria os ativos para que os projetos possam trabalhar sobre processos comuns. Nasce a cultura do aprendizado. A partir da nfase nos processos organizacionais, discute-se o que, e no quem responsvel pelos problemas e o processo melhorado para incrementar as margens do negcio. Estes processos-padro da organizao permitem compartilhar as melhores prticas em favor de melhorar a eficincia e a efetividade dos projetos. Acompanhados dos ativos de processo correspondentes, cultivam a melhoria a partir da experimentao controlada e do compartilhamento de experincias. facilitado e estimulado o ajuste dos processos s necessidades individuais dos projetos. Como isto requer novas competncias bsicas, forma-se o pessoal de maneira sistemtica para que utilizem os processos. Os atores so, ento, efetivos e eficientes. Os processos compartilhados facilitam as melhorias ao facilitar a comunicao e o compartilhamento de experincias. Tratase de uma verdadeira organizao que aprende; esta, como um todo, comea a fazer as coisas bem desde o comeo, melhorando a qualidade e eliminando retrabalhos custosos. Estas mudanas permitem, da mesma forma, uma melhor integrao. Atende-se ao ciclo de vida completo do colaborador, da definio dos cargos seleo, contratao e preparao do pessoal. So criadas equipes levando em conta a eficincia de seu funcionamento futuro. estabelecida e mantida a coordenao entre equipes. O trabalho a realizar identificado, assim como os ativos que podem ser reutilizados para incrementar o reuso e baixar os custos. Ainda antes de pensar em design detalhado, so pensadas as arquiteturas de linhas de produto. Do E ao D: A organizao passa a se centrar na engenharia de software. Culturalmente, comea a viso dos grupos de interesse e das especializaes funcionais baseadas nas experincias conjuntas dos projetos. O rendimento individual e coletivo aumenta, e com isso o sentido de posse. Diminui a rotatividade de pessoal e aumenta a produtividade. As equipes se integram ainda mais e comum o apoio ao outro em sua tarefa, mesmo esta no sendo sua especialidade (engenheiros de teste integrando equipes de inspees, engenheiros de software entrevistando o cliente). Do D ao C: A organizao se orienta pr-atividade. Comea a cultura de previso e da qualidade total. possvel comear a falar de zero defeitos e da busca da excelncia. A mentalidade de isso aqui no pode acontecer d lugar a o que vamos fazer para evitar que acontea e o que podemos fazer se acontecer de qualquer forma. Enquanto, no nvel E, so identificados ativos que merecem ser considerados para sua reutilizao, baseando-se em critrios de oportunidade e qualidade, neste nvel, dada sua caracterstica de olhar para frente, so identificadas oportunidades de gerar ativos para reutilizao. Desse modo, a organizao volta-se, cada vez mais, para uma linha de produo de software. Do C ao B: Nasce a cultura do conhecimento profundo a partir do entendimento da variao e da estabilidade. Aparece a cultura da previso, mediante conhecimento estatstico. A institucionalizao da gesto quantitativa faz com que todos pensem em como que podiam viver sem este conhecimento antes. Do B ao A: Da previso se passa competncia com a excelncia. A organizao procura otimizar cada custo, melhorar cada dia mais. importante entender o porqu desta sequncia. O que as empresas no possuem quando iniciam seu caminho de melhoria de processos a disciplina de projetos, o que realmente tm a engenharia. De nada vale a engenharia sem disciplina. por isso que Scrum to reverenciado, porque consegue prender a imaginao das pessoas que acreditam que, ao fazer Scrum, no seguem processos. De fato, sumamente disciplinado e tem claros processos, s que alguns so metaprocessos e a prpria equipe pode modific-los. Para resumir o exposto: Nvel G: Disciplina de Projetos (organizar o trabalho) Nvel F: Disciplina de Qualidade Inicial (organizar a empresa/organizao) Nvel E: Disciplina de Conhecimento Compartilhado (aprender as boas prticas e compartilh-las) Nvel D: Disciplina de Engenharia (organizar o desenvolvimento em maior nvel de detalhe) Nvel C: Disciplina de Previso (cultivar o pensamento proativo) Nvel B: Disciplina de Qualidade Total (entender os processos crticos quantitativamente e prever seu comportamento em um projeto)
Capitulo 4
Pgina 37
Boria et al.
Nvel A: Disciplina da Excelncia (procurar o panteo da disciplina). Tomando isto com uma granularidade um pouco maior, os nveis G e F estabilizam o paciente para que possa ser tratado e os nveis E, D e C montam a fbrica para que seja possvel entender os processos quantitativamente. 4.5 Para que a Mudana Acontea As organizaes que sobrevivem so aquelas que melhor se adaptam a mudanas. A melhoria de processos no a modificao dos documentos que descrevem os processos, a modificao da conduta das pessoas que devem segui-los. Isto no um tema simples, pelo contrrio, algo muito difcil de conseguir e requer profunda ateno. Dependendo do escopo e da profundidade de uma mudana, mais difcil conseguir que ela resulte em um bom resultado. Se o escopo individual, como quando h uma mudana menor em um procedimento, a difuso e implantao da mudana simples e pode ser realizada em nvel individual. Quando o escopo supe a modificao do comportamento da equipe, a mudana no trivial. A mais difcil de se conseguir a mudana da cultura. Poucas vezes isto tem como resultado uma situao de fcil adoo, sendo que, na maioria das vezes, as organizaes que tentam sem o adequado planejamento, acabam fracassando. Do ponto de vista do desenvolvimento organizacional, o amadurecimento de uma organizao pode ou no supor a mudana de sua cultura. Na realidade, no que a mudana em si seja difcil, a mudana orientada a certos objetivos que complicada. Se olharmos ao nosso redor nada permanece esttico, imutvel, tudo muda permanentemente. Mas essa mudana espontnea no equivalente melhoria. O que procuramos orientar a mudana para a melhoria do desempenho. Quando queremos que as pessoas realizem algo de maneira diferente do que esto realizando na atualidade, a mudana produz uma ruptura com o conhecido. Apesar de serem evidentes as vantagens da mudana, o familiar o presente, o agora. Mesmo quando as pessoas esto de acordo com a necessidade de mudana, no quer dizer que esto de acordo com a direo que queremos dar 48 mudana . O desconhecido causa temor ou, pelo menos, ressentimento. Esperar que todos entendam a mudana desde o incio e a adotem por suas vantagens ilusrio, a maioria ignorar ou resistir mudana. Elizabeth Kubler Ross [KUBLER-ROSS, 1997] estudou a sequncia de comportamentos que so seguidos normalmente (mas no sempre) ao enfrentar uma mudana de profundo impacto em nossas vidas.
48
A referncia bibliogrfica mais antiga sobre mudana de Maquiavel, em 1513, no seu clebre livro O Prncipe: Deve-se considerar no haver coisa mais difcil para cuidar, nem mais duvidosa a conseguir, nem mais perigosa de manejar, que tornar-se chefe e introduzir novas ordens. Isso porque o introdutor tem por inimigos todos aqueles que obtinham vantagens com as velhas instituies e encontra fracos defensores naqueles que das novas ordens se beneficiam. Esta fraqueza nasce, parte por medo dos adversrios que ainda tm as leis conformes a seus interesses, parte pela incredulidade dos homens: estes, em verdade, no creem nas inovaes se no as veem resultar de uma firme experincia. Donde decorre que a qualquer momento em que os inimigos tenham oportunidade de atacar, o fazem com calor de sectrios, enquanto os outros defendem fracamente, de forma que ao lado deles se corre srio perigo O Prncipe, Nicolau Maquiavel, Captulo VI, DOS PRINCIPADOS NOVOS QUE SE CONQUISTAM COM AS ARMAS PRPRIAS E VIRTUOSAMENTE.
Capitulo 4
Pgina 38
Boria et al.
Figura 4.6: Sequencia da Resistncia Mudana (adaptado de [KUBLER-ROSS, 1997])
A seguir evitaremos discutir mudanas culturais profundas, s quais reservamos uma seo ao final deste Captulo. Para que uma mudana planejada tenha sucesso til contar com todos os elementos de partida. preciso ter um patrocinador da mudana em uma posio que permita s pessoas alterarem suas prioridades sem violentar sua posio na organizao. Esse patrocinador de alto nvel precisa contar com o apoio, ou ganhar-lo, dos gerentes abaixo dele. A estes chamaremos de patrocinadores reforadores. preciso que aqueles que conduzam efetivamente as atividades da mudana existam. Estes so nossos agentes de mudana. s vezes, contamos com pessoas de muito prestgio que entendem e apoiam a mudana. Estes so chamados de campees da mudana e so muito importantes para acelerar a transio. Ao tratar-se a transio, fala-se muito da mudana, mas indispensvel entender que esta no 49 um objeto, mas um processo, um devir , algo que ocorre ao longo do tempo. H um estado inicial real e um estado final desejado, que deve obrigatoriamente ser diferente do atual, pois se no for assim, no h nenhuma mudana. Este estado final no pode ser acessado de imediato e sem esforo, ou no estaramos descrevendo-o aqui. um estado que requer mudanas de conduta de vrias pessoas e que leva um tempo para implementar e implantar. A passagem do estado atual ao estado final chamada de transio e o que causa todos os problemas, em geral fruto de ms interpretaes sobre o que a transio. A Figura 4.7 mostra uma viso muito simples da transio que desenhada como uma linha reta entre o estado inicial e o desejado. Supe-se, ento, que a introduo da mudana seja gradual e no oferea maiores problemas.
49
Movimento pelo qual as coisas se transformam.
Capitulo 4
Pgina 39
Boria et al.
Figura 4.7: Modelo de Transio Ilusria (1)
A realidade que no possvel conseguir a mudana dessa maneira. necessrio, pelo menos, levar em considerao a curva de aprendizagem, como mostrado na Figura 4.8.
Figura 4.8: Modelo de Transio Ilusria (2)
Esta viso est menos equivocada do que a anterior, mas continua sendo uma viso altamente otimista da realidade. Quando h uma transio importante, o novo desconhecido e deve ser aprendido. A aprendizagem segue a curva S, mas a produtividade cai durante o perodo de aprendizagem. De fato, preciso planejar uma estratgia que faa com que o perodo de transio seja o mais breve possvel e tenha tanto apoio quanto possvel para que o projeto de mudana no morra. A Figura 4.9 ilustra o verdadeiro comportamento da transio quando planejada e realizada com uma estratgia adequada.
Figura 4.9: Modelo de Transio Administrada
Se a mudana no planejada, considera-se que a adoo est assegurada pela autoevidncia de sua necessidade. O que vamos obter, provavelmente, somente um gradualismo que vai manter a produtividade em baixa durante um perodo, o que far com que a mudana
Capitulo 4
Pgina 40
Boria et al.
seja insustentvel e o resultado seja o cancelamento do projeto de melhoria e a conformidade com um novo status quo de menor produtividade, como mostra a Figura 4.10. Duas so as estratgias principais para reduzir o impacto da mudana: uma dividir a mudana em etapas to pequenas quanto forem sustentveis. A outra dar o apoio necessrio para a instalao das novas condutas s equipes que precisam realiz-las. Isto se traduz em treinamento no trabalho, sobre o trabalho, no momento que seja necessrio e com os 50 processos reais .
Figura 4.10: Modelo de Transio Sem Administrar
Durante a transio, cada pessoa precisa ser ajudada para construir seu prprio compromisso pessoal com a mudana. Conner e Patterson estudaram isto em [CONNER e PATTERSON, 1982]. Precisamos destacar que o processo individual no suficiente para conseguir a 51 mudana da organizao. Como diz Peter Senge em [SENGE, 2006] , Quando pensamos na organizao que aprende, so as equipes que aprendem. Dito de outra maneira, s quando as equipes modificam o seu comportamento que os processos se institucionalizam na organizao. A Figura 4.11 mostra os diferentes passos, limiares e estados no processo de construo de comprometimento pessoal com a mudana. Mais abaixo, elaboraremos como se combinam o compromisso individual com a aprendizagem da equipe.
Figura 4.11: Passos do Comprometimento (adaptado de [CONNER 1982])
A primeira fase a preparao para a aceitao. S quando o indivduo aceita a mudana, pode tentar, e s tentando, pode construir seu compromisso. O primeiro passo sempre o contato. Este contato precisa ser repetido e variado, por exemplo: comunicaes orais,
50
Na TeraQuest chamvamos isto pelas siglas JIT, OTJ, JET (Just in Time, On the Job, Just Enough Training) 51 When we think of a learning organization, it is the teams that learn. Peter Senge, The fifth Discipline
Capitulo 4
Pgina 41
Boria et al.
escritas, em boletins da organizao, em reunies mensais com a alta gerncia, em reunies de avano do projeto, onde for possvel, para que no possa ser ignorado. fcil ignorar uma mudana: basta pensar que no se aplica a voc. Se no h o recurso da ignorncia, o prximo passo a tomada de conscincia. Quando se percebe que a mudana inevitvel, a que se aflora a resistncia. No deveria ser um tema para a confrontao, pois a resistncia pode ser intil, mas no por isso ser ilegtima. Confrontado com a resistncia do pessoal, um agente da mudana deve ser paciente e tentar entender os motivos que a geram. Este um desses momentos nos quais bom lembrar que a percepo do fato igual ao fato para quem percebe. Em outras palavras: no importa quem tem razo, o percebido verdadeiro para quem percebe. Aceitando que no h mudana, por melhor que seja, que no tenha seu lado ruim, o agente deve escutar e negociar. Por exemplo, se a dificuldade acontece porque no h tempo para a aprendizagem dos novos processos ou ferramentas, o agente deve responder fazendo com que esse tempo aparea. Desse modo, colabora com o indivduo para que este possa cruzar o limiar da disposio, evitando cair na confuso e levando-o compreenso. A compreenso do indivduo com relao mudana no quer dizer que ele se sinta favorecido por ela. Se no continua o trabalho com a pessoa, esta cair na desconfiana. Para ajud-lo a avanar at o prximo passo, a deciso, imprescindvel aplainar o caminho, escutando suas objees e reduzindo-as com aes concretas. No h substituto para o sucesso, quando se abandona o indivduo a seus prprios meios. Neste caso, a mudana muito improvvel, de modo que necessrio continuar com o processo para influenciar o resultado. Neste passo, provvel que se comece com a primeira parte do treinamento nos novos processos, em um alto nvel para gerar o vocabulrio comum. Tomada a deciso, a pessoa est pronta para cruzar o limiar do compromisso. Estar disposto a passar instalao no o mesmo que realmente realiz-la. Este o momento em que JIT-OTJ-JET (ver nota 50) indispensvel. Um coach com profundos conhecimentos deve se unir equipe no momento exato para que a experincia de instalao seja positiva e no traumtica. Desse modo, evita-se cair no desengano e, assim, as equipes passam a ter permisso de avanar do compromisso at a adoo da mudana. Esta pode cair no desuso ou seguir at a institucionalizao, mas do ponto de vista da estratgia da mudana, a adoo o ponto de chegada. 4.6 Quando a mudana cultural At aqui consideramos as mudanas estritamente como mudanas de conduta individuais ou de comportamento de equipe. Se adotamos a definio de [CAMERON e QUINN, 2011] para falar de tipos de cultura, encontramos que so quatro dimenses, como mostra a Figura 4.12, 52 derivadas dos dois eixos sobre os quais se apoia uma organizao :
52
A afirmao de que so dois os eixos vem de um estudo de mais de 1.500 empresas que responderam com um total de mais de 50.000 dados que, analisados estatisticamente, mostraram que a cultura pode ser explicada por estes quatro quadrantes em relao aos dois eixos.
Capitulo 4
Pgina 42
Boria et al.
Figura 4.12: Valores em Competncia (adaptado de [CAMERON e QUINN, 2011])
Na direo horizontal, o eixo se move de dentro para fora, segundo a nfase que a organizao colocar, para dentro ou para fora de si. Para a esquerda, a empresa foca seus esforos para dentro, enquanto que para a direita a ateno para seu ambiente, seus clientes e fornecedores. Um enfoque para dentro serve quando h uma crena firme de que os processos internos so a maneira de se aproximar do cliente e isto d resultado. O eixo vertical mostra como se tomam as decises na organizao. A estabilidade ou flexibilidade da cultura depende se as decises dentro da organizao so tomadas no ponto mais alto possvel, neste caso representado pela parte inferior do eixo; ou se so tomadas no ponto mais baixo possvel, neste caso representado pela parte superior do grfico. As organizaes do segundo tipo tm o cuidado de dar a seus colaboradores ordens claras para garantir que a tomada de decises seja em prol do conjunto. [CAMERON e QUINN, 2011] denominaram esse eixo como o de estabilidade/flexibilidade. Os quatro quadrantes definidos assim so os tipos culturais bsicos. Toda organizao mostra at certo ponto variantes e integraes destes, mas para os efeitos da anlise importante entender os tipos puros. O Cl fruto de uma cultura onde o foco interno e as decises so delegadas s equipes. capaz de se adaptar muito rapidamente a mudanas e h muita participao coletiva. So capazes de manter a qualidade de um servio por muito tempo e melhor-la indefinidamente. difcil para o cl construir produtos muito grandes e complexos. Este o arqutipo de cultura que tenta desenvolver o movimento dos agilistas. A Hierarquia a estrutura que todos conhecemos melhor. O foco no respeito ao estabelecido e at quem est propondo resiste s mudanas. So organizaes muito estveis que podem criar produtos muito complexos e com altssima qualidade, como as fbricas de avies, transportadores espaciais ou certas instituies governamentais. Tm uma tendncia a degenerar em burocracia. O Mercado no uma referncia ao mercado externo da organizao, embora haja uma relao, mas empresa em si, que, em todos os seus nveis, opera como um mercado, realizando transaes internas e externas para satisfazer o cliente. Em um mercado no h privilgios para amigos e a competncia tudo, a o nome. As empresas financeiras costumam mostrar exemplos desta cultura. Por ltimo, uma Ad-hocracia uma cultura que favorece a diferenciao de seu pessoal. Em uma Ad-hocracia dado mais mrito s invenes e s patentes do que s ascenses e promoes.
Capitulo 4
Pgina 43
Boria et al.
Mudar de quadrante, ou mover-se significativamente na direo da mudana, muito custoso. Para fazer isso de forma consciente, necessrio um diagnstico profundo e o planejamento das atividades com ainda mais cuidado do que enunciamos no captulo anterior. conveniente contratar um consultor que tenha experincia no tema e procurar intensamente a participao de todos os envolvidos. 4.7 Avaliao do Estado de Maturidade Durante o vir-a-ser do projeto de melhoria de processos, necessrio conhecer os avanos realizados, tanto para poder julgar seu sucesso parcial como para apoiar a mudana com retroalimentao positiva. Esta tarefa difcil e ingrata. O responsvel, ou responsveis, de levar adiante o projeto de melhorias o encarregado natural de realizar esta atividade, mas a autoavaliao no um caminho fcil. Assim como se desaconselha aos mdicos sua prpria automedicao (e ainda mais aos no mdicos) e aos programadores verificar seu prprio trabalho, necessrio contar com uma viso externa, objetiva, para verificar o grau de implementao dos resultados esperados. O MPS tem um Guia [SOFTEX, 2012c] para a avaliao dos processos de uma organizao. Este guia tem como objetivo permitir a avaliao objetiva dos processos de software de uma 53 organizao/unidade organizacional ; permitir a atribuio de um nvel de maturidade do MRMPS-SW baseando-se no resultado da avaliao; ser aplicvel a qualquer domnio na indstria 54 de software; ser aplicvel a organizaes e unidades organizacionais de qualquer tamanho . O documento esclarece que est destinado fundamentalmente s instituies que realizam avaliaes ou implementaes do MPS autorizadas pela SOFTEX. Talvez, como em algumas publicidades de televiso, o pblico deveria ser avisado de que este material para uso profissional e que a autoavaliao uma m ideia. Para sustentar esta afirmao, vejamos o trabalho que a equipe de avaliao precisa realizar: examinar uma planilha, construda pela organizao que est sendo avaliada, para verificar a evidncia de implementao dos resultados esperados para cada processo e dos Atributos de Processo, segundo sejam designados pelo avaliador lder. Entre outras consideraes, o Guia no permite que scios da organizao qual pertence a unidade organizacional, parentes em algum grau dos scios da empresa ou da direo participem da equipe de avaliao. O motivo claro: os conflitos de interesse impedem de exercer a tarefa de julgar o grau de implementao dos resultados esperados. Em nossa experincia, difcil que os colaboradores da organizao sejam totalmente objetivos sem com isso pressupor m vontade da parte deles. Frequentemente, eles so mais exigentes do que os avaliadores externos. Portanto, o monitoramento e o controle de um plano de melhorias deveria incluir visitas frequentes e peridicas de uma pessoa especialista em avaliaes para garantir que no haja surpresas no momento da avaliao formal. Estas avaliaes so aconselhveis desde o primeiro momento. Conhecidas como anlise de lacunas (gap analysis), so avaliaes curtas que permitem organizao contar com uma viso objetiva de seu programa de implementao de melhorias de processos e, ao mesmo tempo, receber conselhos de uma pessoa com muito mais conhecimento e diferentes experincias.
53
A frase unidade organizacional denota a rea de uma organizao que representa o escopo da avaliao. Pode ser parte da empresa ou ela toda, uma rea particular (por exemplo, a fbrica de testes) ou um setor (novos produtos). O avaliador lder e o patrocinador da avaliao por parte da organizao so as pessoas que definem o escopo ao contratar a avaliao. 54 SOFTEX, 2012i.
Capitulo 4
Pgina 44
Boria et al.
PARTE II Primeiros Passos

CAPTULO 5 - UMA ORGANIZAO COM PROBLEMAS (NVEL G do MPS-SW) 5.1 A Pequena Histria de Tahini-Tahini A empresa Tahini-Tahini, internamente conhecida como T , como a chamaremos tambm a partir de agora, uma empresa muito pequena de uma cidade da Amrica Latina. Trabalham nela sete profissionais que se conheceram no Instituto Politcnico local. Todos os empregados so scios com maior ou menor participao e as tarefas administrativas, assim como os cargos representativos (Presidncia, Secretrias, Gerncias) so exercidos rotativamente. A empresa foi fundada com base no trabalho final de graduao de dois dos engenheiros e, fundamentalmente, oferece certos servios de folha de pagamento de salrios para empresas muito pequenas por meio da internet, na modalidade Software as a Service (SaaS). No comeo quiseram se chamar ISP, por Internet Salrios Provider, que o nome original do sistema, concebido como uma brincadeira, e que ainda usado internamente, mas como no puderam obviamente registrar a sigla, mudaram para Tahini-Tahini, que um jogo de palavras com o nome da farinha com que se fabrica a comida rabe hmus (uma pasta feita com gergelim, leo e gua) e que soa homfono ao ingls tiny (pequeno). A anedota foi inventada por uma das scias, Marcela, quando disse juntando o dedo indicador com o mdio da mo direita no smbolo universal de algo pequeno: Somos uma empresa tiny tiny. Os sete profissionais so: Alfredo e Ana, casados entre si, e que idealizaram o servio; Claudio, irmo mais velho de Ana; Mariano, amigo da infncia de Alfredo; Marcela, a amiga do casal desde o ensino mdio; e os gmeos Alberto e Armando Galarraga. Os sete se conhecem muito bem, pelo menos desde o primeiro ano da universidade de cada um. Alguns foram monitores em matrias nas quais os outros cursavam, outros foram colegas de classe. No 2 momento em que os conhecemos, a T est alcanando seus vinte meses de funcionamento contnuo e os gmeos esto para prestar o ltimo exame para se formar. No comeo, a T tinha um mercado nico, o dos negcios de roupa feminina com uma ou duas lojas no mximo. Nesse mercado continuam sendo hegemnicos, mas prevendo que possa surgir alguma concorrncia, comearam a expandir o negcio para outros ramos de empresas. Por causa das diferenas entre contratos de trabalho, cada novo ramo que acrescentam significa incorporar mudanas no sistema. At aqui, o modelo de negcios da organizao consiste em conseguir um cliente para que este pague o desenvolvimento. O cliente fica associado a um responsvel pela conta designado, em geral, na reunio semanal, normalmente aquele que atendeu a ligao ou fez o contato inicial. Esta pessoa se encarrega de elaborar os requisitos de mudanas e gera uma lista de funcionalidades que devem ser atendidas. Depois que se confirmam os requisitos com o cliente, o responsvel pela conta escolhe uma pessoa da equipe para trabalhar com ele ou ela. Juntam-se na sala de design em frente ao mapa do sistema ISP e, usando cartes autoadesivos do tipo Post-It Notes, vinculam os requisitos a diferentes mdulos. Quando se esgota a lista, revisam os mdulos para avaliar o trabalho necessrio para modific-los, a fim de ajust-los aos novos requisitos. Prepara-se um 2 oramento muito superficial, que enviado ao cliente e que, se for aprovado, inicia o que na T passa a ser um projeto. O projeto, na realidade, s tem de projeto o nome. H um responsvel nominal, mas subentende-se que, se houver problemas ou emergncias, todos estaro obrigados a atuar. O responsvel define prioridades na hora. Este processo assim: quando uma pessoa termina de implementar um requisito, anuncia ao grupo em voz alta. O responsvel pela conta, que o proprietrio da tarefa, pega o cdigo do ambiente da pessoa que o desenvolveu e o copia no arquivo prprio, onde realizar os testes do programa. Quem desenvolveu solicita ento outra tarefa. Como consequncia, as vezes, dois ou trs projetos disputam os servios de algum
2 2
Capitulo 5
Pgina 45
Boria et al.
dos membros da equipe, o que conhecido internamente como um leilo. Quem ganha o leilo vincula um ou mais requisitos pessoa que ficou livre. O ganhador do leilo escolhido pela pessoa que vai receber a tarefa. Quando o responsvel pela conta sente que o produto est desenvolvido de forma suficiente, comea a fazer testes ad-hoc. Quando no encontra falhas, libera o produto, subindo-o ao site 2 da T , de onde o cliente pode us-lo. No momento em que nossa equipe chamada para colaborar com eles para realizar melhorias 2 em seus processos, a T est a ponto de concretizar um lanamento importante para dentistas. 5.2 Quem assume a responsabilidade? Hoje um grande dia na T . Depois de assistir a uma aula no Politcnico sobre a qualidade total, os gmeos induziram todos a terem uma reunio plenria com nossa empresa de consultoria, Vitalera, devidamente autorizada pela SOFTEX como instituio implementadora do MPS (II/MPS). Nossa equipe de consultoria chega cedo reunio, como de costume, e vai se informando das novidades internas: em vinte e cinco dias deve ser concretizada a entrega do sistema ajustado para dentistas. sexta-feira e os gmeos, apesar de terem organizado a reunio, tiraram o dia de folga porque na segunda-feira tm seu ltimo exame. Ana acaba de descobrir que est grvida e ficou em casa, um pouco enjoada. No vir tarde, tem uma consulta com sua ginecologista. Alfredo est, mas ficou muito nervoso com a notcia. Marcela vai chegar tarde, avisou que vai passar na casa de Ana e ajud-la. Claudio est viajando. Por sorte, Mariano no tem problemas e est sentado em sua mesa, trabalhando. Estamos sentados na mesa da sala de design, tomando caf com Mariano e Alfredo e a ponto de comear a falar de nossa proposta, quando liga o contato com os clientes dentistas, o Doutor Molar Coroa Ponte, Presidente da Sociedade de Odontologia local. A Associao recebeu uma oferta de uma importante empresa de consultoria internacional para instalar um sistema centralizado de ERP que resolveria tambm alguns dos problemas que os associados querem resolver com o ISP para dentistas. O Doutor Molar no est muito disposto a ceder 2 presso de alguns membros da Sociedade para cancelar o contrato com a T , mas precisa de nossa ajuda para resistir aos ataques. A consultora est fazendo promessas de entrega em tempos impossveis, ignorando a necessidade de adaptao do ERP em questo, o que, alm do mais, certamente obrigar algumas mudanas importantes nas interfaces dos futuros 2 clientes. Por tudo isso, o Doutor Molar pede T que: 1. Informe o estado atual do projeto de adaptao do ISP aos problemas dos dentistas; 2. Dedique algumas horas, no meio da semana, a fazer uma demonstrao do produto no estgio atual, com o objetivo de convencer os associados a esperar o lanamento 2 antes de romper com a T ; 3. Estime que porcentagem do produto estar pronta para a demonstrao. Alfredo d garantias ao cliente, dizendo em algumas horas volto a ligar, Doutor, no se preocupe, se despede e desliga. Levanta-se e vai at a zona de trabalho. Pergunta a Marian o: Voc est com o programa de dentistas? Mariano responde que no, e que isso de exclusiva responsabilidade de Marcela e dos gmeos. Alfredo pede desculpas por interromper a reunio e liga para o celular de Marcela. Responde um aviso que diz que o celular est desligado. Com certa preocupao, liga para sua casa, onde atendido pela secretria eletrnica. Deixa uma mensagem pedindo que retornem urgente a ligao. Liga para o celular da Ana e descobre que est redirecionando para o telefone de sua casa. Comea a ficar desesperado. Este o momento onde um consultor precisa mostrar para que serve: um cliente est com problemas e sua fisionomia mostra ansiedade, um estado negativo. A ansiedade se manifesta fisicamente, fcil de perceber e nossos consultores sabem reconhecer bem. Uma fina linha de transpirao aparece no lbio superior de Alfredo que respira com maior dificuldade, suas mandbulas esto tensas, h um leve tremor em suas mos ao levantar a xcara de caf, que engole com dificuldade, fazendo rudo e pede uma aspirina para sua incipiente dor de cabea. Ansiedade, sem dvida. Nossos consultores sabem que primeiramente deve-se mudar o pensamento negativo, identificar a fonte de preocupao, eliminar o temor que provoca, criar um plano que o leve da insegurana a uma situao criativa, em que haja esperana. Tambm sabem que precisam tomar a deciso sobre o plano, porque as pessoas ansiosas tm, nesse estado, dificuldade
2
Capitulo 5
Pgina 46
Boria et al.
para decidir, pois o medo que sentem paralisante, gera pensamentos negativos sobre si mesmos. Devem ser firmes, mas ao mesmo tempo com muita empatia, enfatizando o ganhaganha porque, quem sente ansiedade, tem medo de que os outros percebam suas dificuldades, temor de perder o controle, apesar de ter conscincia de estar com dificuldades para pensar. O primeiro passo para resoluo de um problema identific-lo com clareza. Nosso consultorlder, Mximo, faz um resumo de seu entendimento do problema: h um cliente importante (o Doutor Molar) em situao crtica (a presso externa da consultora que oferece o ERP) e preciso dar uma resposta sobre o estado do projeto (as duas perguntas). Esse o detonante. O problema que no h nenhuma forma objetiva de entender o estado, porque as pessoas que esto a cargo, por uma srie de circunstncias totalmente fortuitas, no esto presentes. Alfredo concorda levemente com a anlise apresentada. Mariano concorda com mais interesse do que Alfredo. O segundo passo encontrar as causas-raiz do problema. Para garantir a participao e compromisso de Alfredo e Mariano, Mximo se levanta e vai lousa. Com um marcador divide a lousa em dois e, em um dos lados, desenha um diagrama de espinha de peixe (Figura 5.1) com quatro espinhas e coloca na cabea do peixe o nome que d ao problema: no h forma objetiva de entender o estado do projeto. As espinhas recebem seus nomes: Processo, Pessoal, Ferramentas e Capacitao. Os nomes e a quantidade de espinhas podem mudar, sendo esta escolha em parte dependente da percepo do problema ao enfrent-lo. De qualquer modo, esta uma emergncia e mais importante mostrar iniciativa do que preciso total. Agora que j conquistou a audincia, Mximo comea a perguntar aos dois scios usando outras tcnicas.
Figura 5.1: Causas da Falta de Conhecimento do Estado do Projeto
Primeiro comea com os Cinco Porqus. Falta Conhecimento do Estado das Tarefas. Por qu?, pergunta Mximo. No se trata de identificar mais sintomas, ou se a existncia do problema reconhecida. Tratase de indagar sobre a natureza das causas. pergunta Por que falta conhecimento do estado do projeto? incorreto responder com porque no sabemos responder aos clientes quando nos perguntam sobre isto. Se a resposta obtida tambm responde pergunta Como sei que falta conhecimento do estado do projeto? preciso descart-la. O que se procura a origem do problema, no outras manifestaes dele mesmo. Por isso Mximo escolheu as categorias correspondentes no diagrama. As respostas s perguntas so orientadas a esses eixos, as espinhas do peixe no diagrama. Como o pessoal da empresa um grupo de engenheiros, no mximo faltando uma matria para se formar, nem o pessoal nem a capacitao merecem grande ateno. O pequeno grupo centra-se em processos e ferramentas. A primeira resposta que os processos atuais no registram o estado. Continuam os questionamentos sobre os seguintes porqus at se detectar a causa-raiz. Pode ser que seja necessrio perguntar cinco vezes Por qu? ou pode ser que se chegue antes causa-raiz. fcil detectar uma causa-raiz porque ela geralmente oferece imediatamente uma soluo. Por exemplo, se eles respondem ao segundo porqu dizendo que
Capitulo 5
Pgina 47
Boria et al.
os processos existentes no esto preparados para identificar tarefas, responsveis, nem o estado do projeto, a soluo bvia, apesar de no ser fcil de implementar: modificar os processos para que se possa identificar as tarefas, os responsveis e o estado do projeto. Continuando com as perguntas, Mximo passa espinha das ferramentas. Tambm aqui fcil ver que as ferramentas com que se conta no do o suporte necessrio para o processo que querem implementar. Depois que uma das espinhas gera o imediato reconhecimento da soluo (por exemplo, falta um processo gera a resposta coloquemos um processo e o mesmo com as ferram entas), o exerccio suspenso e passamos discusso das solues. A aplicao dos cinco porqus no o nico caminho possvel, j que parte de nosso repertrio uma alternativa chamada as 55 Oito Disciplinas : D1: Formao de uma equipe de especialistas que em seu conjunto consigam atender todas as funes; D2: Identificao e definio completa do problema; D3: Implementao e verificao de uma ao de contingncia provisria para que o dano no se propague; D4: Identificao e verificao da causa-raiz; D5: Determinao e verificao de aes corretivas permanentes; D6: Implementao e verificao das aes corretivas permanentes; D7: Preveno da recorrncia do problema e/ou sua causa-raiz; e D8: Reconhecimento dos esforos da equipe. Como nossos consultores so eclticos, no desdenham nenhum ensinamento que seja til. Neste caso, Mximo reconhece a necessidade de aplicar D3: necessrio deter a propagao do efeito do problema, antes de comear a escrever o processo que impossibilite sua recorrncia, pois seno ser tarde demais, uma vez que j tero perdido o cliente. Mximo se coloca a trabalhar com os scios para fazer um plano de emergncia. Coordena com Alfredo. para que v buscar imediatamente sua mulher e Marcela. Mariano e Mximo se comunicam com os gmeos e decidem fazer uma reunio de investigao, assim que terminarem de festejar, tera-feira primeira hora. Mariano liga para o Doutor Molar e anuncia que na quartafeira, antes do meio-dia, ele receber uma proposta completa para chamar os interessados a participarem de uma demonstrao, proposta que incluir a proporo do sistema que ser demonstrada. Depois de suficientemente detida a hemorragia, e j identificadas claramente as causas, Mariano e Mximo definem um processo que vai solucionar a causa e evitar que se repita. 2 Nosso homem em T parte para definir, seguindo o mtodo, as caractersticas desejveis do processo: Evitar que o problema se repita no futuro 2 Ser muito fcil de implementar (dois ou trs dias na T ) Contar com suporte em software existente na empresa, ou fcil de conseguir (freeware, Open software ou semelhante) ou desenvolvido internamente (sobretudo na nuvem).
Nosso consultor considera que Mariano uma pessoa inteligente e com conhecimentos, no o subestima nem condescendente. Tampouco dita os resultados, mas quando aparece a oportunidade (um problema para o qual conhece uma resposta) faz propostas para que ele as avalie. Com a anlise inicial que realizaram com a espinha de peixe, sabe que a base de todas as propostas sempre precisa ter em seu centro um sistema que permita ingressar tarefas e indic-las, ao mesmo tempo em que vai atualizando permanentemente seu estado. O mtodo de funcionamento simples e, o que muito importante, pode ser considerado uma evoluo do que fazem hoje em dia. Quando Mariano descreve a concluso pelo qual se designam prioridades, Mximo associa com o livro de Kanban e Scrum e sugere dar uma lida, juntos, em [KNIBERG e SKARIN, 2010]. Uma rpida leitura dos materiais de Kanban faz com que tomem conjuntamente a deciso de procurar na rede ferramentas de software que se ajustem s 2 necessidades da T para colocar o painel kanban na nuvem ou em servidores locais, gratuitamente. H elementos suficientes para que Mariano se entretenha vrios dias
55
http://en.wikipedia.org/wiki/Eight_Disciplines_Problem_Solving
Capitulo 5
Pgina 48
Boria et al.
comparando-os. Revisam juntos vrios deles e, apesar de no tomarem a deciso, avanam muito no tema. Trs horas mais tarde, Mariano e nosso consultor se despedem. Receberam uma ligao tranquilizadora de Alfredo: Marcela e Ana adiantaram a visita ginecologista, onde est proibido o uso de celulares, por isso no havia resposta de nenhuma das duas. Tudo est bem 2 no universo da T . Mximo se despede dizendo a Mariano que, se quiserem continuar com um contrato permanente, as horas que trabalhou sero consideradas investimento de marketing. Mariano no d garantias, mas afirma que discutiro na reunio semanal e que a proposta contar com seu apoio. O QUE ACONTECEU AT AGORA 1. O consultor Mximo estabeleceu o contato inicial com o cliente, coincidentemente com um problema grave e facilitou sua identificao. 2. Introduziu uma primeira tcnica de anlise de causa, o diagrama de Ishikawa. 3. Utilizando a tcnica chegou, junto com os clientes, concluso de que seus processos deixavam muito espao para problemas como o detectado, a falta de controle das tarefas. 4. Apesar de ter um diagnstico concreto que j apontava para a melhoria de processos, Mximo se concentrou no problema imediato para evitar um maior, comeando por definir as caractersticas (ou atributos) desejveis da soluo. 5. Mximo sugeriu o mtodo Kanban, sem imposio, e foi escutado. 5.3 Mostrando a Carga de Trabalho e o Estado das Tarefas Na segunda-feira seguinte, nossa empresa de consultoria chamada por Alfredo, que pede para Mximo ser enviado como consultor, para que facilite a reunio semanal com a presena de todos os membros da cooperativa. O objetivo armar o painel kanban do que ainda no foi realizado at esse momento no projeto e carreg-lo no software que j baixaram no fim de semana. Alfredo afirma que os honorrios devem incluir, tambm, as quatro horas de trabalho da sexta. Ficamos gratamente surpresos, porque percebemos que os jovens empreendedores entenderam a mensagem e esto muito satisfeitos em poder contar com nossos servios. Chegada a manh de tera-feira, todos os membros da equipe esto sentados ao redor da mesa de design. Ana est um pouco plida, a gravidez ainda no foi totalmente assimilada, mas nos demais h efervescncia e energia para dar e vender. Apreciando o lugar, nosso consultor elogia a disposio da sala: h quatro lousas para serem usadas com marcadores, uma delas ainda mostra o diagrama de espinha de peixe, as outras mostram a arquitetura conceitual e a outra, a arquitetura modular do ISP. A quarta lousa eletrnica e serve para registrar decises mediante o simples apertar de um boto que transcreve o escrito na lousa a um arquivo em PDF que pode ser impresso. a que o grupo usa para registrar a memria das reunies semanais. O modelo da arquitetura modular est decorado com notas autoadesivas, representando histrias do cliente a serem implementadas. Mximo se dirige at essa lousa e chama a ateno para as notas autoadesivas, solicitando uma explicao de seu uso. Marcela responde, detalhando como se movem as notas da coluna da esquerda, agora vazia, aos diferentes mdulos, para mais adiante chegar concluso. Mximo tira uma fotografia da arquitetura com seu laptop e aproveitando o projetor, mostra audincia. Mximo indica que as notas designadas aos mdulos sero o ponto de partida. Esclarece que, apesar de ser possvel usar o software para Kanban que j instalaram, acha que o melhor fazer o exerccio moda antiga para que a percepo seja mais completa. Pega uma pilha de notas autoadesivas, entrega-as aos participantes e diz: Cada um precisa ficar com umas cinco ou seis notas. Depois que todos tm seu material, por ordem, comeando pela Ana e no sentido dos ponteiros do relgio ao redor da mesa, Mximo dita rapidamente os contedos de cada nota, pedindo que escrevam claramente e no centro do papel. Como vai projetando-os ao mesmo tempo, no se detm para esperar que sejam copiados totalmente, de modo que em poucos minutos todas as histrias do cliente, pelo menos seus nomes, esto copiadas. Ele as recolhe e coloca na lousa que havia usado na sexta. Apaga seu diagrama e desenha um painel kanban elementar, por enquanto com trs
Capitulo 5
Pgina 49
Boria et al.
colunas: Solicitadas (Pedidas), esquerda, onde esto todas as histrias. Completas, direita, que est vazia. A grande coluna do meio est vazia e sem ttulo, por enquanto (Figura 5.2).
Figura 5.2: Painel kanban elementar
Mximo solicita ento que cada um, na sua vez, diga uma tarefa derivada da implementao dessa funo. Ana comea dizendo Codificar os testes e Mximo escreve isso em uma nota autoadesiva, que em seguida gruda debaixo da original. Marcela acrescenta, quase sem pausa: Criar os testes. Isto tambm vai para a lousa. a vez de Alberto, que vem sacudindo a cabea: Investigar a histria diz e Armando acrescenta: com o cliente e dividi-la em funes e caractersticas. Todos do risada, claro. Mximo pergunta ento qual o ciclo de vida de uma histria. O resultado que ela analisada, desmembrada em funes, os testes de cada funo so construdos, ela codificada e testada. Mximo nota que as funes podem j estar claras e que nem sempre, necessariamente, acontecem anlises. Os presentes concordam. Modifica ento o painel para incluir essa informao (Figura 5.3) e tira as notas que havia acrescentado, j que as tarefas so parte do ciclo.
Figura 5.3: Painel kanban com ciclo de vida das histrias -1-
Quem o dono do produto? pergunta Mximo. Eu, diz Marcela. No o Doutor Molar? volta a perguntar Mximo. No, diz Marcela, o Doutor no conhece os detalhes das folhas de pagamentos, eu estudei a legislao vigente e sou quem sabe como se deve fazer para pagar os salrios e quais opes possui o dentista individual. Parabns! diz Mximo. Ento, o primeiro passo que entre todos, e sob sua direo, priorizemos as histrias.
Capitulo 5
Pgina 50
Boria et al.
Marcela se levanta e comea a mover as histrias que agora esto na fila mais abaixo do painel. Mximo interrompe. Conte-nos seu critrio, Marcela. Marcela comea a explicar as prioridades e os gmeos intervm quase em coro, recordando a todos a iminncia da demonstrao pedida pelo grupo de clientes. Logo todos esto de p ao redor da lousa e movendo as notas para frente e para trs. A primeira prioridade para a histria Modificar Interfaces com o Usurio pelo impacto que tem em uma demonstrao. Quando finalmente a lista se estabiliza, Mximo aprova. Perfeito, temos um Backlog do produto. Agora, vamos estimar o tamanho. Mximo escreve na lousa eletrnica uma tabela que diferencia entre tamanhos de tarefa (Tabela 5.1). Esclarece que as definies no so do que corresponde a tamanho no idioma portugus, mas que este um bom comeo. Enfatiza, igualmente, que a tabela visa que as categorias, apesar de serem atributos ordinais, tenham relao entre si, de modo que a diferena entre muito simples e simples acabe sendo comparvel com a diferena entre normal e mais que o normal. O propsito que as categorias, quando mais adiante forem substitudas por medies objetivas, possam servir de base para elas. Com esta tabela na frente de todos, pega a primeira das histrias Modificar interfaces com o Usurio. Desenha um quadrado em cada um dos cantos e com um lpis escreve tamanho no quadrado superior da esquerda (Figura 5.4) e pede que faam uma estimativa do tamanho desta histria. H um grande silncio, quebrado por Ana, que, sacudindo a cabea em negao, diz: Esta no uma histria de usurio, uma tarefa transversal a todas as histrias. Tamanho Categoria funes derivadas Dias 1 muito simples 1 2 simples 2 No dia 3 menos que o normal 3 4 normal 4 5 mais que o normal 5a6 1a2 6 complicado 7 a 10 2a4 7 muito complicado mais de 10 mais de 4
Tabela 5.1: Tamanhos de Tarefas
Com o consentimento de todos, Mximo a coloca na coluna Em Processo na metade de baixo e pega a prxima histria da fila de Solicitadas e l em voz alta.: Acrescentar um mdulo de folha de pagamento de Horas Extras.
Figura 5.4: Histria no Painel kanban
Volta a parar na frente da tabela de tamanhos e pede que se faa uma estimativa do tamanho desta histria. H uma discusso de poucos minutos, antes que os participantes concordem de que o tamanho mais que o normal. Mximo pergunta, ento, se no seria melhor dividir essa histria em partes (sub-histrias), pois so cinco ou seis funes derivadas que esto sendo pensadas. Pega um pacote de notas autoadesivas de cor diferente do que j foi usado, e repete o pedido de que sejam enunciadas as funes derivadas dessa histria. Desta vez escreve os requisitos derivados medida que Marcela, com a ajuda de todos, vai expondo: Acrescentar Opo de Carregar Horas Extras ao Mdulo de Folha de Pagamento Mensal, Acrescentar uma Frmula
Capitulo 5
Pgina 51
Boria et al.
de Clculo ao Mdulo do Funcionrio, Modificar Sequncia de Folha de Pagamento para Incluir Horas Extras, Modificar a Folha de Pagamento do Salrio Extra para Admitir Horas Extras e, claro, Modificar Interfaces com o Usurio. Agora temos um pico !, intervm os gmeos. picos, histrias, sub-histrias, temas, funes, caractersticas, casos de uso, casos de usurio, so todos nomes que damos s coisas. Vocs escolhem os que servirem. O importante que tenhamos claro que h uma raiz e que dessa raiz so derivados outros requisitos e que desses podem derivar outros mais, formando uma hierarquia. Quando os requisitos chegam a um nvel onde sabemos que podem ser implementados, derivaremos desse nvel as tarefas. Todo este conjunto uma hierarquia que nos serve para identificar as histrias e os usurios que as geram. Poderamos usar um padro que diga Como usurio X, neste caso um dentista, quero poder fazer Y, neste caso acertar as horas extras de trabalho do meu pessoal. Mas o importante que tenhamos claro o que preciso fazer e controlar isso, diz Mximo. Baseados nos dados que so obtidos, os gmeos estimam que, se comearem a trabalhar nesse momento, com a ajuda de Marcela e Ana, podem ter a demo a tempo para apresent-la na quinta-feira depois do horrio de trabalho, com as funes que no exigem novas APIs. Alfredo respira aliviado e Claudio liga para o Doutor Molar para transmitir as novidades. O QUE ACONTECEU AT AGORA 6. Mximo induziu o uso do painel kanban, sem mandar. 7. Introduziu os conceitos de sub-histria e estimativa por tamanho. 8. Houve uma clara definio da abrangncia do trabalho a realizar, obtido a partir da lista de histrias, com sua correspondente estimativa de tamanho. 9. Foi feito um desmembramento das histrias, onde seu tamanho garantia a sua utilidade. 10. Os conceitos de histria, sub-histria, desagregao e tarefa foram entendidos na prtica e foram aplicados. Foi possvel distinguir tarefa de sub-histria. 5.4 Planejamento, Monitoramento e Controle do Projeto em Doses Homeopticas A reunio continua a pedido de Mximo, por mais meia hora. Antes de deixar a T dedicada ao que tinha de fazer, Mximo quer deixar clara a definio de PRONTO para cada etapa do painel. Ento pergunta: Quando se pode afirmar que a anlise da histria est concluda? As caras dos assistentes dizem tudo: nunca tinham pensado nisso. Eles se aventuram levemente sobre algumas definies, at que Mariano acerta no ponto: a realidade que a anlise, apesar da tradio ao contrrio, no feita separadamente. parte do Design. Mximo apaga a coluna de ANLISE do painel e redistribui as demais, cada uma tem duas subcolunas: EP, que se l Em Processo, e PRONTO. As definies de pronto para Design, Cdigo, Desenvolvimento de Testes e Completas ficam assim definidas: Design: o design est PRONTO quando h um diagrama de mudana de estados que foram aprovados pelo Dono do Produto, por quem est encarregado do desenvolvimento do cdigo e por quem est encarregado do desenvolvimento dos testes. O Cdigo est PRONTO quando foi feita a reviso com um colega e realizados os testes unitrios do prprio codificador e no foram encontrados defeitos; se havia, foi demonstrado que estes foram corrigidos. O Desenvolvimento de Testes est PRONTO quando foi feita a reviso de todos os testes com um colega e foram carregados os testes unitrios na ferramenta de monitoramento dos testes automticos.
2 56
56
http://www.mountaingoatsoftware.com/blog/stories-epics-and-themes
Capitulo 5
Pgina 52
Boria et al.
A histria em si est PRONTA quando todos os testes foram feitos, foram integrados e no se encontraram defeitos nem com os novos testes nem com os testes de regresso. Tudo isto induz a uma ltima mudana do dia no painel kanban: a coluna A Testar passa a ser chamada de Integrao e Completa passa a ser chamada PRONTA. Mximo apaga todo o painel, introduz uma nova coluna esquerda chamada Em Espera, onde se colocaro as duas histrias de maior prioridade, e as colunas Design, Desenvolvimento, Integrao e Prontas. O painel visto agora como na Figura 5.5.
Figura 5.5: Painel kanban com ciclo de vida das histrias -2-
Continuando, Mximo trabalha com Marcela e os gmeos para definir o procedimento para o uso do painel nas atividades dos prximos dias. Cada vez que algum estiver livre, ele se aproximar de Marcela e escolhero, juntos, uma tarefa para realizar. Essa tarefa ser retirada da coluna Em Espera e ser colocada na coluna EP de Design. A pessoa que se encarregar da tarefa escrever seu nome no quadrado superior direito da nota correspondente. No quadrado inferior esquerdo colocar a data e a hora de comeo e no inferior direito a data e hora de trmino, quando a tarefa estiver concluda. Depois que estiver completada segundo o autor, espera-se que algum assuma a tarefa de codificar e desenhar os casos de teste. Se isso for feito pela mesma pessoa (embora seja melhor envolver algum mais, para ter mais olhos no projeto), ela revisar com Marcela e a nota passar a EP debaixo de Codificao e uma cpia a EP sob Desenvolvimento de Casos de Teste. Sempre se evitar que a pessoa que codifique desenvolva os casos de teste. Por ltimo, define-se que a integrao ser realizada pela pessoa responsvel pelo projeto, neste caso, Marcela. Todos satisfeitos encerrase a sesso, e ainda resta pouco mais de uma hora para trabalhar pela manh. O QUE ACONTECEU AT AGORA 11. Mximo mostrou que o uso do painel kanban dinmico e que pode ser modificado. 12. Ficou esclarecido o que significa uma tarefa estar PRONTA, para cada etapa do seu ciclo de vida. 13. Visualiza-se facilmente o ciclo de vida de uma histria no painel. 14. O controle do estado geral de uma histria e as tarefas associadas podem ser lidas no painel. 5.5 O Cliente quer Mudanas Na quinta-feira da mesma semana, os gmeos vo com seus tablets e laptops sala de conferncias da Sociedade de Odontlogos Profissionais em Atividade (SOPA) local. A demonstrao do produto convence quase todos, e a simpatia e juventude dos profissionais 2 fazem o resto. Um memorando de acordo assinado entre a T e a SOPA. Alguns dos menos entusiasmados pedem que se demonstre a capacidade de modificar o servio, para o qual encarregaram algumas mudanas, a maioria cosmticas, mas algumas afetam os mdulos de 2 clculo. A T tem uma semana para responder com um plano e uma proposta de honorrios. 2 Estabelecida uma boa relao entre a T e Mximo, ele chamado diretamente para que facilite outra reunio para dar a resposta.
Capitulo 5
Pgina 53
Boria et al.
Mximo preferia seguir com seus planos de implementao das prticas do MPS, mas os negcios de seus clientes sempre so prioridade para ele, como uma poltica da Vitalera. De todas as maneiras, nenhuma parte do negcio de software totalmente alheia ao MPS, de modo que sempre usar solues nascidas de suas prticas. Alm disso, nem tocou no tema 2 do MPS com a T , algo que pensa fazer mais para frente, quando chegar a ocasio para uma avaliao MPS bem-sucedida. Assim, ele organiza seu calendrio e, mudando uma reunio 2 aqui e outra ali, na tarde de sexta-feira est de novo na sala de design da T com os mesmos atores da tera-feira. Mximo repassa com os participantes os passos que levaram ao pequenssimo plano de implementao de tera-feira, mas utiliza desta vez a ferramenta de software (sprint.er) que 2 instalaram na T . A sequncia de passos a mesma: identificar o Backlog, fazer a distribuio dos componentes, organizar as histrias por prioridades, estimar o volume de trabalho, desagregar as histrias muito volumosas em pequenas histrias e tarefas derivadas, revisar e 2 fechar. Mas esta a primeira proposta com desenvolvimento sob medida que a T vai assinar; at aqui s venderam servios de um produto relativamente estvel com modificaes que no alteravam o esquema de trabalho, baseados sobretudo em correes no cdigo para eliminar defeitos ou adequaes a mudanas na legislao. por isso que a equipe no possui um padro de apresentao de planos para propostas. Mximo introduz agora a planilha para a definio de histrias que a Vitalera desenvolveu. Os assistentes sugerem pequenas mudanas e a planilha aprovada, aceita e adotada (Figura 5.6). Utilizando as facilidades de design na ferramenta sprint.er incluem os campos necessrios. Sobre a base da planilha, rearmado o Backlog, agora muito mais completo e realizada a estimativa com sprint.er. Os resultados projetam a necessidade de utilizar trs sprints de duas semanas. O primeiro implementar as mudanas mais profundas, o segundo introduzir as mudanas de interface sugeridas, e o terceiro servir de garantia de estabilidade. Sobre a base do planejado so acrescentados custos estimativa. PLANILHA DE DEFINIO DE HISTRIAS RISCOS ID NOME IMPORTNCIA TAMANHO VALIDAO ASSOCIADOS 1 2 3 4 5
Figura 5.6: Planilha para Definio de Histrias
CAPACIDADES NECESSRIAS
Para poder medir o possvel impacto de algum risco que se materialize, Mximo introduz uma planilha de definio e anlise de riscos (Figura 5.7). Toda esta documentao simples e no toma tempo extra para ser preenchida, mas joga muita luz sobre o projeto, obrigando os membros da equipe a pensar no que esto fazendo, usando outras faculdades alm de sua 57 capacidade de construir .
57
[DE BONO, 1985]. O livro faz referncia a cinco maneiras de pensar sobre um problema. Informao (Branco), Emoes (Vermelho), Discernimento (Preto), Otimista (Amarelo), Criativo (Verde). Tambm h um chapu Azul para discutir as regras do jogo em si.
Capitulo 5
Pgina 54
Boria et al.
Figura 5.7: Planilha para Definio e Anlise de Riscos
Chegado este ponto, Mximo introduz a planilha que a Vitalera usa para suas propostas de consultoria, que segue uma estrutura que contm o Backlog do produto, o plano de sprints e o painel original do primeiro sprint. Tambm so explicitados nela tempos e custos, assim como um resumo extrado da planilha de anlise de riscos e uma lista das responsabilidades mtuas (ver Figura 5.8).
Introduo Resumo Executivo da Proposta Escopo do Projeto

Mtodo de Desenvolvimento das atividades
Descrio geral Ciclo de vida de cada atividade Preparao do pessoal envolvido Identificador Nome Importncia Tamanho Validao Riscos <link com a planilha de riscos> Capacidades Requeridas Sprint 1 Sprint 2 Sprint Sprint de estabilizao
Histrias <link com documento Histrias>
Calendrio de Trabalho
Oramento econmico e financeiro
Riscos previstos Obrigaes mtuas

Comunicaes Entregas Aprovaes Pagamentos
Figura 5.8: Planilha de Proposta de Projeto
A nova estrutura, com as correspondentes conexes aos produtos vinculados (Backlog na ferramenta de software e planilha de riscos), constitui uma prova til das resolues aprovadas em equipe. Em menos de uma hora de trabalho sobre esta planilha chegam a um acordo e se dispem a mand-la ao cliente. Mximo pede duas coisas: uma que os presentes se comprometam a assinar sua concordncia com a proposta, a segunda que o cliente faa o mesmo. Os gmeos acham um pouco estranho, mas Mximo explica que os clientes que no querem assinar no querem se comprometer, sendo que o resultado que no haver acordo no momento da entrega.
Capitulo 5
Pgina 55
Boria et al.
O QUE ACONTECEU AT AGORA 15. Mximo incorporou melhorias no documento do Backlog, tornando-o mais slido e mais til. 16. Utilizando uma planilha de riscos foram analisados os possveis efeitos indesejados associados com as histrias do projeto. 17. Foi incorporada uma planilha de propostas que permite reunir em um documento dinmico o Backlog e o oramento, acrescentando as responsabilidades das partes contratuais. 18. Os compromissos mtuos de cliente e fornecedor ficam documentados, em especial o escopo do projeto, representado pelo Backlog. Sem mais nada a tratar, a reunio termina. Mximo chamado a parte por Claudio. Na sala das conversas privadas, explica que a empresa tem poucos recursos e que ele gostaria muito de contar com seu apoio como consultor, mas que no possuem oramento para isso. Talvez, apesar de tudo, esta interveno tenha sido a ltima. Mximo sorri, porque esperava que este problema surgisse. Justamente sobre isso queria que conversssemos, diz. H um programa investir em qualidade e receber recursos do estado para isso. Mximo explica o programa e os olhos de Claudio se abrem cada vez mais. De nossa experincia, apesar de ser relativamente novo no ambiente, o modelo mais 2 adequado para empresas como a T o MPS. O que o MPS? pergunta Claudio. Mximo d uma explicao precisa sobre as vantagens do modelo MPS, matizada com 2 conceitos como avaliaes, evidncia direta e outros termos que hoje so novos na T , mas que vo se converter, com a passagem do tempo, em moeda corrente. Claudio fica com a tarefa de contar o resumo do que foi conversado a todos os scios, enquanto que Mximo 2 precisa falar na Vitalera para que a T seja includa na lista de empresas que aspiram ao apoio para implementao do MPS. 5.6 Avanos na implementao do MPS-SW Algumas semanas depois, a T est preparando sua avaliao de Nvel G do MPS-SW. A primeira atividade no plano que a Vitalera preparou com eles a realizao de uma anlise de lacunas (gap analysis) que avalia como os processos esto implementados e os resultados esperados de implementao de processos do MR-MPS-SW. Para isso, til contar com a lista dos resultados esperados no Nvel G (Tabela 5.2) e compar-los com o que est implementado 2 na T : Gerncia de Projetos (GPR) no Nvel G
GPR1 GPR2
2 58
que permite
O escopo do trabalho para o projeto definido; As tarefas e os produtos de trabalho do projeto so dimensionados utilizando mtodos apropriados; O modelo e as fases do ciclo de vida do projeto so definidos; O esforo e o custo para a execuo das tarefas e dos produtos de trabalho so estimados com base em dados histricos ou referncias tcnicas; O oramento e o cronograma do projeto, incluindo a definio de marcos e pontos de controle, so estabelecidos e mantidos;
GPR3 GPR4
GPR5
58
Em vrios pases da Amrica Latina isto uma realidade (external funding). A forma que o programa adotado varia de pas para pas, por isso evitamos neste texto fazer uma referncia mais explcita. Os programas costumam pagar s empresas uma parte substancial das despesas em consultoria quando ela avaliada ou certificada sob um modelo internacional, como o MPS, CMMI ou ISO.
Capitulo 5
Pgina 56
Boria et al.
GPR6
Os riscos do projeto so identificados e o seu impacto, probabilidade de ocorrncia e prioridade de tratamento so determinados e documentados; Os recursos humanos para o projeto so planejados considerando o perfil e o conhecimento necessrios para execut-lo; Os recursos e o ambiente de trabalho necessrios para executar o projeto so planejados; Os dados relevantes do projeto so identificados e planejados quanto forma de coleta, armazenamento e distribuio. Um mecanismo estabelecido para acess-los, incluindo, se pertinente, questes de privacidade e segurana; Um plano geral para a execuo do projeto estabelecido com a integrao de planos especficos; A viabilidade de atingir as metas do projeto explicitamente avaliada considerando restries e recursos disponveis. Se necessrio, ajustes so realizados; O Plano do Projeto revisado com todos os interessados e o compromisso com ele obtido e mantido; O escopo, as tarefas, as estimativas, o oramento e o cronograma do projeto so monitorados em relao ao planejado; Os recursos materiais e humanos bem como os dados relevantes do projeto so monitorados em relao ao planejado; Os riscos so monitorados em relao ao planejado; O envolvimento das partes interessadas no projeto planejado, monitorado e mantido; Revises so realizadas em marcos do projeto e conforme estabelecido no planejamento; Registros de problemas identificados e o resultado da anlise de questes pertinentes, incluindo dependncias crticas, so estabelecidos e tratados com as partes interessadas; Aes para corrigir desvios em relao ao planejado e para prevenir a repetio dos problemas identificados so estabelecidas, implementadas e acompanhadas at a sua concluso.
Tabela 5.2 Processo GERNCIA DE PROJETOS no Nvel G [SOFTEX, 2012a]
GPR7
GPR8
GPR9
GPR10
GPR11
GPR12
GPR13
GPR14
GPR15 GPR16
GPR17
GPR18
GPR19
O Backlog permite conhecer o escopo do trabalho (GPR1) e junto com o painel define as tarefas e os produtos associados, com seus correspondentes esforos que foram estimados pelo consenso entre os participantes (GPR2). O plano dos sprints define o modelo a seguir no projeto e as fases correspondem aos sprints, da mesma forma que o painel mostra nas tarefas, o ciclo da vida de cada histria (GPR3). Na proposta est includa uma anlise de custos e o cronograma previsto (GPR2, GPR4 e GPR5). O Backlog identifica os riscos que so analisados na planilha de riscos (GPR6). No Backlog tambm so identificadas as habilidades e conhecimentos necessrios para realizar as tarefas relacionadas com cada histria e quando uma tarefa designada, considera-se isto (GPR7). A nova planilha da proposta funciona como o plano integrado, quando so includas as conexes aos documentos perifricos como os que esto armazenados na ferramenta sprint.er e a planilha de riscos (GPR10). Em cada sprint, realizada a anlise do esforo necessrio e so revisadas estimativas para garantir que as histrias sejam terminadas (GPR11). As assinaturas dos participantes no projeto, externos e internos, evidencia que os envolvidos assumem o compromisso com ele (GPR12). Das tarefas de planejamento s faltam GPR8 e GPR9. Mximo e a equipe da T tero que trabalhar para gerar as mudanas necessrias para que os processos estejam implementados.
2
Capitulo 5
Pgina 57
Boria et al.
Enquanto isso, mais produtivo voltar-se para a tarefa de garantir que as atividades de monitoramento e controle estejam sendo implementadas. A primeira ao j realizada na primeira semana do contrato foi incorporar ao repertrio de atividades o Scrum dirio. Seguindo os alinhamentos gerais j vistos no Scrum: Organizando o sistema para um estado de equilbrio orgnico do Captulo 3, Marcela passa a cumprir funes de Scrum Master e, junto com os gmeos e Ana, como equipe do sprint, se renem diariamente na sala de design para avaliar os avanos do dia anterior e o estado geral do sprint, incluindo os riscos associados. Esta reunio no exatamente um Scrum de acordo com as regras de [SCHWABER e BEEDLE, 2002], mas servem ao propsito de controlar o projeto. Continuando com a anlise de lacunas (gap analysis) entre o implementado e o que exigido pelo MPS, os componentes do modelo que o Scrum dirio contribui para evidenciar so ento GPR 13, pois nesta reunio o escopo, as tarefas, as estimativas, o oramento e o cronograma do projeto so supervisionados com relao ao planejado; GPR14, porque os recursos materiais e humanos, assim como os dados relevantes do projeto so supervisionados com relao ao planejado para o sprint; GPR15, pois so supervisionadas as tarefas relacionadas com os riscos e GPR 16 porque a participao das partes interessadas no projeto planejada, supervisionada e mantida. Depois so agregados ao processo demonstraes de produto que so realizadas com o cliente ao final de cada sprint e, desse modo, a participao de todos os interessados est completamente evidenciada. Com todos estes elementos, Mximo constri um processo que vira um diagrama de raias (um exemplo deste tipo de diagrama mostrado na Figura 5.9).
Figura 5.9: Diagrama de Raias
Ainda falta implementar vrios resultados esperados do MR-MPS-SW para o Nvel G, inclusive no se discutiu todos os processos correspondentes, j que a Gerncia de Requisitos (GRE) parte do que necessrio fazer para alcanar o Nvel, mas Mximo tem a segurana de que o que foi feito at agora evoluiu para atender, tambm, esse processo. Ele analisa ento os resultados esperados do GRE seguindo a tabela correspondente (Tabela 5.3) e comprova que a proposta, enquanto documento integrador do projeto, contm as histrias e, como est sendo assinada para mostrar sua aprovao pelos clientes, cobre desse modo o resultado esperado GRE 1; que a reviso que faz a equipe das histrias para estim-las e revisar os riscos e habilidades requeridas cobre GRE 2; que o painel kanban, como est sendo utilizado, permite rastrear as histrias por meio dos produtos do projeto, cobrindo assim GRE 3, que nas reunies dirias so introduzidas tarefas derivadas que afetam as estimativas das histrias e disparam novas anlises que determinam que GRE 4 est coberto, e que entre estas mudanas que so geradas a partir da equipe e as mudanas que possam surgir por pedido do cliente de um sprint ao seguinte, provocados ou no pela demonstrao do que foi at ento realizado, surge a prova necessria para GRE 5. O prximo passo para Mximo completar os resultados esperados com os dois que faltam em GPR e analisar e implementar os resultados esperados para os atributos de processo correspondentes, AP 1.1 e AP 2.1.
Capitulo 5
Pgina 58
Boria et al.
Gerncia de Requisitos (GRE)

GRE1
O entendimento dos requisitos fornecedores de requisitos;
obtido
em
conjunto
com
os
GRE2
Os requisitos so avaliados com base em critrios objetivos e obtido o compromisso da equipe tcnicas com estes requisitos; A rastreabilidade bidirecional entre os requisitos e os produtos de trabalho estabelecida e mantida; Revises em planos e produtos de trabalho do projeto so realizadas com o objetivo de identificar e corrigir inconsistncias relacionadas aos requisitos; Mudanas nos requisitos so geridas durante o projeto.
Tabela 5.3 Processo GERNCIA DE REQUISITOS [SOFTEX, 2012a]
GRE3
GRE4
GRE5
Em conformidade com os resultados at o momento, Mximo introduz um curto procedimento para definir a estrutura de pastas de um projeto no site de cada projeto e senta com Marcela e um dos gmeos para escrever o script que vai automatizar sua execuo. Alinhada s necessidades da organizao, a estrutura contm uma pasta para cada um dos passos do processo que a organizao segue, mais algumas pastas de comunicaes e aes a serem tomadas. Dentro de cada pasta, a equipe pode encontrar as planilhas correspondentes, a serem utilizadas no processo. Desse modo, Mximo est seguro de que os dois resultados que faltam do GPR ficaram cobertos. O QUE ACONTECEU AT AGORA 19. Mximo introduziu o Scrum dirio para avaliar os avanos dia a dia e o estado geral do sprint; foram includos os riscos associados, para com isso melhorar o controle e fornecer evidncias de vrios resultados esperados do MR-MPS-SW. 20. A organizao incorporou uma demonstrao do produto ao final de cada sprint como critrio de aceitao pelo usurio que serve para evidenciar sua participao. 21. A anlise de lacunas (gap analysis) exercida como atividade contnua mostra que os resultados esperados para GRE surgem dos processos j implementados. 22. Mximo introduziu um curto procedimento para definir a estrutura de pastas de um projeto em seus prprios sites, que evidencia a implementao de GPR 8 e GPR 9. 5.7 Preparando a Avaliao Para alcanar o nvel G do MR-MPS-SW ficaram ainda por definir as atividades que planejem e disponibilizem aos interessados os recursos e o ambiente de trabalho necessrios para executar o projeto, bem como seus dados relevantes. Para estes ltimos preciso definir como so reunidos, armazenados e distribudos. Tambm preciso definir o mecanismo para acess-los incluindo, quando for pertinente, restries de acesso. Alm disso, necessrio revisar os atributos dos processos GPR e GRE, esses que falam da capacidade da organizao para lev-los adiante. Estes so abreviados como AP e tem, por sua vez, resultados esperados que so abreviados como RAP. Em primeiro lugar, como AP 1.1. simplesmente O processo executado, com um nico resultado esperado, RAP 1, O processo consegue seus resultados definidos, o que Mximo leva em conta que os resultados definidos, tirando os j identificados, esto implementados, depois no h aes relacionadas. A coisa muda quando se trata do segundo atributo, AP 2.1 O processo gerenciado, porque os resultados esperados so nove: RAP2. Existe uma poltica organizacional estabelecida e mantida para o processo; RAP3. A execuo do processo planejada; RAP4. A execuo do processo supervisionada e so realizados os ajustes necessrios;
Capitulo 5
Pgina 59
Boria et al.
RAP5. As informaes e os recursos necessrios para a execuo do processo so identificados e colocados disposio dos interessados; RAP6. As responsabilidades e a autoridade para executar o processo so definidos, atribudos e comunicados; RAP7. As pessoas que executam o processo so competentes em termos de formao, treinamento e experincia relacionados; RAP8. A comunicao entre as partes interessadas no processo planejada e executada de modo que se assegure sua participao; RAP9. Os resultados do processo so revisados com a alta gerncia para proporcionar visibilidade sobre sua situao na organizao; RAP10. O processo planejado para o projeto executado. Mximo prope uma poltica sobre as atividades de um projeto de Nvel G que diz o seguinte: Os projetos da Tahini-Tahini se originam de requisitos do cliente e so aprovados por este, so analisados para assegurar sua viabilidade, so estimados e orados. Os custos baseiamse em estimativas de tamanho e esforo, e as etapas nas quais sero realizados so planejadas e coordenadas com os clientes. O pessoal escolhido para realizar as tarefas competente, baseado em sua capacidade objetiva. Os planos que so aprovados so utilizados como base para controlar e monitorar o projeto. Toda mudana que impacte nos compromissos internos ou externos deve contar com as mesmas aprovaes que o projeto original. Qualquer violao a esta regra ser considerada motivo de sanes e, eventualmente, suspenso dos que a violem reiteradamente. Em discusses com os gmeos, que se opunham a uma meno a sanes, Mximo conseguiu convenc-los de que uma regra sem sano mais um desejo do que uma regra, e que, alm disso, a sano era facultativa, ou seja, se a razo por trs da violao fosse embasada e justificada, no havia por que chegar sano. Este 2 enunciado aparece hoje encabeando a pgina de processos da T . Com isto, temos evidncias da implementao do RAP 2. Depois, Mximo atacou os seguintes RAPs, um a um: planejar, supervisionar a execuo e ajust-la, se for necessrio; colocar disposio daquelas pessoas e papis responsveis os recursos, dados e informaes necessrios para levar o trabalho adiante e atribuir autoridade para conduzi-lo, proporcionando-lhes capacitao quando no tiverem a competncia adequada, ou nomear quem tiver apto a executar o papel; garantir a participao das partes interessadas; revisar os processos com a alta gerncia para proporcionar visibilidade sobre sua situao na organizao e, por ltimo, executar o que foi definido.. Incorporou ainda um processo de iniciao de projetos. que descreve como deve ser completada uma proposta, obviamente baseando-se no processo que descreveu para levar adiante um projeto usando o painel virtual, mas estendendo-o para que seja coberta todas as etapas de planejamento, controle e gesto de requisitos. No mais alto nvel, descreve a sequncia do processo de maneira grfica. Para cada atividade usa a planilha de procedimento (Figura 5.10) e um diagrama de raias que desenha usando um programa grfico. Por enquanto, deixa de lado as medies de cada atividade, mas inclui o diagrama. O processo inclui todas as atividades para gerar o plano, definindo os papis e funes de cada ator e 2 interessado. Quando a T comear seu prximo projeto, o processo se executar e gerar a proposta com todas as planilhas correspondentes, assim como as atividades de Gerncia de Requisitos necessrias e as atividades de controle do projeto. O processo assim definido cobre o planejamento do planejamento, pois identifica quem so os responsveis por gerar a proposta, como se estabelece a responsabilidade e quais recursos lhe do suporte. Deste 2 modo, a T atende aos resultados esperados dos Atributos de Processo.
Capitulo 5
Pgina 60
Boria et al.
PLANILHA DE DETALHES DO PROCEDIMENTO Nome da Atividade: Propsito (O que esperamos conseguir com esta atividade?) Envolvidos (pelo menos o responsvel) Entradas exigidas Produtos de trabalho criados (sadas) Critrio de Entrada (Como sabemos quando comear esta atividade?) Critrio de Sada (Como sabemos que a atividade foi concluda satisfatoriamente?) Subatividades (3 a 6 subatividades [se existirem] para realizar esta atividade, que sero incorporadas no diagrama de raias) Medies (Como podemos medir o desempenho desta atividade?) Sequenciamento (Quais atividades sero realizadas antes e depois desta?) Figura 5.10: Planilha de Detalhamento de um Procedimento
Um dos principais impulsores da melhoria contnua em uma organizao a realizao de reunies peridicas que possibilitem aos envolvidos analisar o que foi feito e sugerir mudanas 2 aos processos para melhor-los. Essas reunies recebem o nome de retrospectivas, e a T as 59 adota sob a preparao e superviso de Mximo. O mais importante das retrospectivas que elas aconteam. Sem elas, as equipes repetem seus erros ao invs de aprender com eles. A responsabilidade do Scrum Master, portanto, que estas reunies sejam planejadas entre sprints e realizadas. possvel que uma situao crtica no meio de um Sprint motive convocar uma retrospectiva de emergncia, mas seu lugar natural entre Sprints. Deve-se reservar entre uma e trs horas da equipe com este propsito, sendo que a durao depender da participao e da quantidade de temas a serem discutidos na reunio. importante que participem todos os interessados, incluindo o Dono do Produto. O lugar da reunio no pode ser a prpria sala de trabalho, porque sumamente importante no sofrer interrupes. Mximo escolheu a sala de design porque tem as lousas que permitem trabalhar de forma cmoda e no tem telefones nem telas de computadores. No so permitidos laptops na reunio de anlise retrospectiva. Divide-se a lousa em trs colunas: O que Andou Bem, O que Precisa Melhorar e Sugestes. Primeiro so completadas as duas primeiras colunas e quando j no existirem mais propostas para nenhuma delas, so iniciadas as rodadas de sugestes. As tcnicas para isto so mltiplas e valioso conhecer tantas quanto for possvel. J mencionamos o diagrama de Ishikawa, ou de espinha de peixe, assim como os cinco porqus, e as oito disciplinas. Existem mecanismos de pensamento, como j mencionamos o dos chapus de cores de [DE BONO, 1985], que permitem exercitar o pensamento crtico. Estas e muitas outras tcnicas tm mrito e sua aplicao d excelentes resultados. O informe de Mximo para seu chefe inclui a seguinte tabela (Figura 5.13), que mostra as evidncias que temos da obteno dos resultados esperados pela implementao do processo GPR do modelo. As colunas definem a documentao existente, da esquerda para a direita: Painel kanban, Planilha de Histrias, Proposta, Script de Definio de Pastas e Recursos, Demonstrao Final de Cada Sprint, Planilha de Riscos, Informe da Retrospectiva e o Scrum Dirio. Cada uma dessas evidncias contribui para que a totalidade dos resultados esperados sejam cobertos na implementao escolhida. Da mesma forma, h outras tabelas de cobertura para GRE e RAP.
59
Escolhemos preparao e superviso para englobar o significado de coaching, que lamentavelmente no tem uma boa traduo em um nico vocbulo em portugus.
Capitulo 5
Pgina 61
Boria et al.
Figura 5.11: Evidncias para GPR no Nvel G
O QUE ACONTECEU AT AGORA 23. Mximo definiu e codirigiu vrias implementaes do procedimento de anlise retrospectiva, que fornece evidncia de GPR 17, GPR 18 e GPR 19. 24. Mximo redigiu uma poltica que a organizao aprovou para estabelecer os 2 alinhamentos do que esperado do pessoal da T . 25. Mximo desenvolveu um processo que permite evidenciar as capacidades de processo de Nvel G do MR-MPS-SW para as atividades de planejamento, por meio da proposta e gesto de requisitos, do Backlog do produto e da evoluo do painel kanban. Deixamos Mximo e a T organizando a avaliao formal do Nvel G do modelo MPS.
2
Capitulo 5
Pgina 62
Boria et al.
CAPTULO 6 - UMA ORGANIZAO EM CRESCIMENTO 6.1 Nvel F do MPS-SW Este captulo tem como objetivo discutir a implementao de prticas que so exigidas no nvel F do modelo de referncia MR-MPS-SW. No nvel F, Gerenciado, os processos so Aquisio (AQU), Gerncia de Configurao (GCO), Garantia da Qualidade (GQA), Gerncia do Portflio de Projetos (GPP) e Medio (MED). Notemos o que diz o modelo: A implementao dos processos para o nvel F pode ser feita em qualquer sequncia, visto que os processos desse nvel so de apoio gesto do projeto, fornecendo maior qualidade e controle aos produtos de trabalho. Uma vez que necessitam de processos de apoio, as organizaes podem ter a necessidade de incorporar sua equipe alguns novos perfis para realizar atividades de garantia da qualidade, gerncia de configurao, medio, gerncia do portflio de projetos e aquisio de produtos. Note, no entanto, que a existncia de um novo perfil no obriga necessariamente a contratao de novas pessoas, mas a definio de novas 60 competncias necessrias e delimitao de novas responsabilidades . O QUE ACONTECEU AT AGORA 26. T alcanou o nvel G do MPS-SW em uma avaliao oficial 6.2 Crescem os pedidos Tahini-Tahini passou a fazer parte do considervel nmero de empresas que foram avaliadas no Nvel G do MR-MPS-SW. Mesmo com alguns detalhes aqui e ali identificados pela equipe 2 de avaliao MPS, estes foram resolvidos prontamente pelo pessoal da T e a organizao recebeu sua placa de ao em um evento do Simpsio Brasileiro de Qualidade de Software 2 (SBQS) realizado anualmente. A notcia circulou rapidamente nos meios locais e a T teve seus 2 quinze minutos de fama. Por mais breve que tenha sido essa notoriedade, os amigos da T , como o Doutor Molar, se sentiram obrigados a compartilhar o orgulho que a notcia trouxe. A 2 consequncia imediata foi que outros clientes se aproximaram da T para conhecer seus servios. Uma oferta muito tentadora chegou do Conselho Profissional de Contadores Pblicos (CoProCoP) para que os tradicionais servios de folha de pagamento de salrios fossem 2 ofertados aos membros do CoProCoP e, ao mesmo tempo, que a T trabalhasse para e com eles (os membros do Conselho), estendendo esses servios a eles e a outros clientes potenciais com o conhecimento coletivo do conselho em certas aplicaes contbeis e de administrao. A oferta sumamente interessante, porque possibilitaria o aumento imediato do faturamento com clientes existentes ao oferecer as novas funcionalidades e tambm ampliaria o mercado potencial. Depois de algumas breves conversas iniciais com o CoProCoP, uma reunio plenria da T foi feita para que decises sobre o caminho a ser seguido fossem tomadas. Esta reunio crucial porque a oferta coloca uma encruzilhada real: crescer ou no crescer. Sem dvida, crescer algo que toda organizao acredita aspirar. Mais clientes, mais faturamento, melhores salrios, frias pagas, um futuro afortunado. Mas tambm implica em deixar de lado a cotidianidade dos amigos, profissionalizar a administrao, descolar-se das tarefas divertidas ou ser obrigado a faz-las de outro modo. As emoes entre os participantes da reunio oscilam entre os que esto assustados e os que esto eufricos. As vias de crescimento so pressentidas como estranhas e complicadas. Depois de duas horas de reunio, no se chega a nenhuma concluso. Ento, um dos gmeos prope que Mximo seja chamado. 6.3 Procurando Ajuda Fora da Tahini-Tahini Dois dias mais tarde, Mximo facilita a reunio plenria da T na sala de design. Desta vez, trouxe consigo seis chapus de diferentes cores: [DE BONO, 1985]. As cores so: azul, branco, vermelho, preto, amarelo e verde. Cada cor representa uma modalidade de pensamento da qual nosso crebro capaz. Uma pessoa coloca o chapu azul quando quer expressar pensamentos sobre o mtodo que segue, quer dizer, pensamentos sobre o mtodo de trabalho. O chapu branco usado para trabalhar com os dados concretos, com a
60
SOFTEX, 2012c, pgina 7
Capitulo 6
Pgina 63
Boria et al.
informao disponvel. Com o chapu vermelho so expressos os sentimentos. No preciso justific-los de forma alguma. A lgica da cautela expressa com o chapu preto, que tende a apontar os problemas, da a cor. O amarelo expressa a lgica do otimismo, do que pode acontecer e do que gostaramos que acontecesse. O verde para provocar. No h uma ordem pr-determinada de seu uso, em geral comeamos a us-los para estimular a discusso e evitar que o pensamento fique estancado na lgica do que pode andar mal. Pode-se especificar uma ordem inicial e todos usam essa cor por uma rodada, por exemplo, o chapu azul. Tambm possvel que uma pessoa pegue o chapu que corresponde ao que quer expressar antes de falar, de modo que todos saibam que essa comunicao feita a partir do ponto associado cor. Mximo coloca o chapu azul e explica os papis das cores e prope us-los em rodadas. Primeiro, todos usaro o amarelo, depois o vermelho e depois o preto. Quando chega o momento de expressar a negatividade, todos j analisaram as possibilidades e seus sentimentos a respeito das mudanas, e os compartilharam. Mximo foi registrando-os no quadro eletrnico e muda de quadro quando chegam ao preto e, ao invs de anotar os pensamentos em uma lista, faz duas colunas (Tabela 6.1): No estamos prontos para crescer Crescimento muito rpido Muitas linhas de produto Perda de controle
Tabela 6.1: Pensamentos Negativos sobre a Mudana
Mximo copiou os pensamentos negativos de todos. Alguns foram repetidos ou estavam suficientemente relacionados e puderam ser expressos em uma nica frase. Assim, todos os pensamentos foram sintetizados nas frases que escreveu. Como todos j conhecem o diagrama de Ishikawa de espinha de peixe, ele o utiliza para comear a sesso de anlise do enunciado e chegar a uma estratgia de crescimento. Desenha um esqueleto de sardinha e escreve a primeira frase na cabea do peixe (Figura 6.1):
Figura 6.1: Diagrama Ishikawa sobre Crescimento 1
As risadas do lugar a caras preocupadas. H perguntas e discusses entre os scios. Mximo deixa que continuem por uns minutos e depois interrompe: Para que serve o diagrama de Ishikawa? A pergunta retrica, mas tem seu resultado. Imediatamente, todos percebem que voltaram a colocar o chapu preto, alguns tambm o vermelho. Querendo que voltem ao exerccio de busca de solues, ele mesmo escreve a soluo (Figura 6.2).
Figura 6.2: Diagrama Ishikawa sobre Crescimento 2
H um silncio de concordncia. Mximo deixa que a ideia v crescendo nos scios e encabea sua lista com este ttulo: Preparando-nos para Crescer e apaga a primeira linha. A
Capitulo 6
Pgina 64
Boria et al.
reunio vai se animando aos poucos e onde se viam problemas agora h solues. Algumas so descartadas, por exemplo, o rpido crescimento pode ser controlado mediante a contratao de pessoal, mas o custo em esforo do pessoal atual e o investimento em facilidades so grandes. Por outro lado, possvel considerar a contratao de servios de desenvolvimento de um fornecedor estabelecido. A tabela completa ficou assim constituda (Tabela 6.2): PREPARANDO-NOS PARA CRESCER Crescimento muito rpido Muitas linhas de produto Implica na contratao de servios externos implica contar com gesto de configurao implica selecionar entre opes de investimento Perda de controle implica controle objetivo mediante decises baseadas em dados implica controlar objetivamente a aplicao de normas e polticas
Tabela 6.2: Preparando-nos para Crescer
Agora Mximo sugere que eles ataquem os riscos, um por um, comeando pela contratao de uma empresa fornecedora. Mximo produz uma lista de riscos e a projeta na parede: Contratao de Fornecedores, Riscos: 1. 2. 3. 4. 5. 6. Serem contratados os servios equivocados; Serem contratados os fornecedores equivocados; Serem escolhidos a partir de um subconjunto inadequado de fornecedores; Serem escolhidos subjetivamente; Ser feito um contrato que no atenda aos interesses das duas partes; O contrato ser encerrado sem que todos os requisitos tenham sido cumpridos.
Os scios revisam a lista com Mximo, ponto por ponto. Vo concordando, com algumas perguntas. O item 5 discutido um pouco mais que os outros. Claudio quer saber por que importante fazer um contrato que sirva s duas partes, alm das consideraes ticas. Mximo explica que se o contrato no serve ao cliente e ao fornecedor possvel que o fornecedor no possa entregar seu produto, arrastando, como consequncia, tambm o cliente em sua queda. Mximo pergunta se algum quer agregar mais algum risco e espera a resposta. Depois de um silncio suficientemente longo, continua com as mitigaes: Bem, agora podemos ver o que precisamos fazer para que estes riscos no se materializem ou, se ocorrerem, que tenham baixo impacto. Mximo no se preocupa em definir os termos de maneira formal, pois no momento apropriado far isso. Por enquanto, s precisa que colaborem com ele. Usando os diagramas de espinha de peixe de maneira muito rudimentar, j que as solues so bvias, chega-se seguinte concluso para cada um dos riscos: Para no contratar os servios equivocados, preciso planejar a aquisio, determinando o que ser adquirido e por que isso ser produzido. Para no contratar os fornecedores equivocados, preciso estabelecer claramente, antes de busc-los, quais so os atributos que devero possuir para participar da anlise de preos. Para no escolher um subconjunto inadequado de fornecedores, preciso pesquisar o mercado, com base no tipo de aquisio e nos atributos exigidos dos fornecedores. Para no escolher subjetivamente entre os candidatos, preciso construir um modelo de deciso que permita realizar a escolha baseando-se ao mximo em dados objetivos. Para no fazer um contrato que no sirva s duas partes, preciso negociar com boa disposio, procurando o ganha-ganha com coragem, maturidade, imaginao e integridade. O contrato deve permitir dirigir processos conjuntos.
Capitulo 6
Pgina 65
Boria et al.
Para que o contrato no seja encerrado sem que todos os requisitos tenham sido cumpridos, necessrio que haja um acordo claro sobre o que deve ser entregue, quando e em quais condies. Esta uma boa lista, diz Mximo. O mais interessante que estas aes podem ser implementadas cumprindo com a implementao de todos os resultados do Processo de Aquisio do MR-MPS-SW e sorri ao falar isso. Projeta ento esses resultados: Aquisio (AQU)
AQU1
As necessidades de aquisio, as metas, os critrios de aceitao do produto, os tipos e a estratgia de aquisio so definidos; Os critrios de seleo do fornecedor so estabelecidos e usados para avaliar os potenciais fornecedores; O fornecedor selecionado com base na avaliao das propostas e dos critrios estabelecidos; Um acordo que expresse claramente as expectativas, responsabilidades e obrigaes de ambas as partes (cliente e fornecedor) estabelecido e negociado entre elas; Um produto que satisfaa a necessidade expressa pelo cliente adquirido baseado na anlise dos potenciais candidatos; A aquisio monitorada de forma que as condies especificadas sejam atendidas, tais como: custo, cronograma e qualidade, gerando aes corretivas quando necessrio; O produto entregue e avaliado com relao ao acordado e os resultados so documentados; O produto adquirido incorporado ao projeto, caso pertinente.
Tabela 6.3: Processo AQUISIO [SOFTEX, 2012a]
AQU2
AQU3
AQU4
AQU5
AQU6
AQU7
AQU8
Os scios se dedicam criao de guias, critrios e processos para realizar aquisies. Rapidamente alguns critrios surgem claramente: a aquisio deve ficar claramente delimitada na arquitetura, com interfaces bem definidas; os fornecedores devem ser suficientemente experientes para poder entregar um produto de qualidade, mas no to grandes ao ponto de o acordo de negcios ser totalmente unilateral; a visibilidade dentro dos processos do fornecedor e a colaborao que estejam dispostos a prestar para isso sero objeto de anlise e ser dada importncia queles que demonstrem essa vontade. Esses e outros aspectos vo dando forma ao processo de aquisio. As primeiras dvidas e os medos se dissipam na atividade criativa. Fica a dvida, no entanto, sobre a deciso de fabricar ou comprar j que preciso considerar fatores como as caractersticas do produto que os fornecedores oferecem e como cada um se encaixa no projeto, a disponibilidade de recursos e perfis de projetos, porque preciso equilibrar o que ser feito internamente com os recursos que no sero necessrios por serem do fornecedor, mais a administrao do contrato, o custo de adquirir versus o custo do desenvolvimento interno; as datas crticas de entrega e integrao; a possibilidade de implementar uma estratgia de alianas, incluindo os requisitos de negcio de alto nvel. Tambm se propem a investigar os produtos em desenvolvimento e os que j esto no mercado, procurando entender a funcionalidade e a qualidade desses produtos, o impacto sobre a concorrncia, licenas, permisses, responsabilidades e limitaes associadas aos produtos que sero comprados, assim como a disponibilidade do produto, as questes relacionadas com a propriedade e se a deciso aumenta ou diminui os riscos. Mximo prope 61 criar uma matriz de Pugh que contenha as alternativas e us-la quando for necessrio. Com essa tarefa pendente termina a reunio.
61
Ver Captulo 2.
Capitulo 6
Pgina 66
Boria et al.
O QUE ACONTECEU AT AGORA 27. Mximo utilizou a tcnica dos chapus de cores para semear o caminho de ideias e, com o diagrama de Ishikawa, ajudou os scios a elucidar qual caminho seguir na empresa (crescer ou no crescer). 28. Mximo ajudou a revisar os riscos de contratao de fornecedores e estudar as alternativas de comprar, reutilizar ou fabricar, introduzindo a tcnica da matriz de Pugh. 6.4 O que deveramos fabricar? No dia seguinte, Mximo recebe uma ligao de Claudio. Aconteceu algo inesperado: proposta de trabalho conjunto do CoProCoP se somou outra de uma empresa que mantm e vende um sistema de gerenciamento de estoque para farmacuticos, que poderia se aproveitar bem de um sistema de folha pagamento de salrios. A pergunta , quando Mximo pode ajudlos a resolver essa questo, facilitando a reunio dos scios. Quando Mximo chega ao 2 escritrio da T j h mais duas propostas de trabalho conjunto: aos contadores e fabricantes de software para farmcias, se somaram uma ligao da associao de servios de sade, que 2 est interessada em desenvolver um sistema novo, na nuvem, pelo qual a experincia de T bastante importante, e um fornecedor de servios a agentes de seguros que tambm q uer se mudar para a nuvem de modo a integrar mais facilmente novas tecnologias (laptop, tablets, netbooks e tambm smart phones) oferta. As quatro propostas esto sendo avaliadas como fornecedores usando a matriz de Pugh que Mximo havia deixado como tarefa. Um momento, pede Mximo. No se trata de fornecedores alternativos do mesmo produto. No concorrem por um nico espao. Por que no possvel pensar em dois ou trs projetos paralelos? O silncio quase audvel. A seleo de projetos que uma organizao encara deve ser o resultado de um profundo conhecimento do mercado e da viso do rumo que levar o crescimento da organizao. A governana dos recursos da organizao, em um nvel superior ao dos projetos, essencial para o mximo aproveitamento dos patrimnios coletivos. Qualquer outra forma de definir a designao de recursos aos projetos, pode dar lugar a vinculaes inadequadas. A falta de viso um primeiro obstculo. Mximo se dirige lousa e 2 escreve: Viso para T : nos prximos dois anos nos comprometemos a, e deixa o cenrio em aberto. Claudio fala primeiro: Gostaria que fssemos uma fora decisiva no mercado de SaaS. Mximo passa a caneta para que escreva, textualmente, sua frase no quadro. Mximo se levanta, pega a caneta e corrige a frase. Agora pode-se ler: Nos prximos dois anos nos comprometemos a ser uma fora decisiva no mercado de SaaS para a Amrica Latina. Agora se levanta Marcela, pega a caneta das mos de Mximo e risca fora decisiva e em cima dela escreve uma referncia entre as cinco melhores empresas. Um dos gmeos se levanta e com o dedo apaga a palavra uma e escreve a em seu lugar. A viso diz ento: Nos prximos dois anos nos comprometemos a ser a referncia entre as cinco melhores empresas no mercado de SaaS para a Amrica Latina. O silncio agora solene e Mximo o interrompe: Se for assim, vender sistemas contbeis com folha de pagamento de salrios no suficiente. Precisamos ter uma carteira de produtos e gerenciar os projetos como um portflio de investimentos. Pode-se entender um portflio, ou carteira, segundo o [PMI, 2008], como () um conjunto de projetos, programas e outros trabalhos que se agrupam para facilitar a gesto efetiva do conjunto do trabalho para cumprir com os objetivos estratgicos especficos. Os componentes da carteira no necessariamente precisam ter alguma relao de dependncia ou estar diretamente relacionados. Alm do mais, pode-se entender que gesto da carteira refere-se gesto centralizada de uma ou mais car teiras, o que inclui a identificao, priorizao, autorizao, administrao e controle de projetos, programas e outros trabalhos relacionados, para alcanar os objetivos estratgicos especficos [PMI, 2008]. Ento, quais das propostas esto alinhadas com a viso? pergunta Mximo. Todas, menos a dos agentes de seguros, responde Marcela com segurana.
Capitulo 6
Pgina 67
Boria et al.
Mximo risca da matriz de Pugh essa oferta e apaga todos os atributos desejveis da soluo da matriz, deixando em branco a coluna da esquerda. NOOO!, gritam todos. O trabalho no tinha sido, ainda, copiado em nenhum lugar. Por sorte, Mariano tem o costume de tirar, periodicamente, fotografias do que escrito nos quadros e foi possvel recriar a informao apagada sem muito esforo. Mximo, ento, escreve os atributos da nova matriz, a de seleo de aliados. Os atributos que coloca so: esforo (exigido pelo projeto), domnio (da aplicao), sinergia (com os outros projetos), investimento (montante), alinhamento (com a viso estratgica) e mercado pot. (mercado potencial de venda do produto resultante). Preenchem a matriz e o resultado parcial o seguinte: atributo esforo domnio sinergia investimento alinhamento mercado pot. contadores 1 sistema completo contabilidade boa media bom muito amplo software para drogaras 1 sistema migrao a SaaS manejo de stocks mediana media mediano drogarias Associao servios de sade 1 sistema integrado para hospitais ERP completo total enorme enorme hospitais, drogarias, mdicos servios a agentes de seguros
????????
Tabela 6.4: Matriz de Pugh sobre Propostas
Os pontos de interrogao so escritos pelos gmeos Galarraga, que, de repente, se levantaram ao mesmo tempo e disputaram a caneta. O que aconteceria se, diz Alberto, a tecnologia que querem usar os agentes de seguros seja usada continuou Armando, e aos pacientes, as salas de primeiros socorros, os histricos clnicos terminou Armando. Os olhos de todos brilhavam de animao. Mximo foi o encarregado de jogar um balde de gua fria no conjunto: Esperem, esperem. Nada de solues ainda. Vamos tomar um caf e pensarmos juntos na estratgia. Mximo usou aqui uma ttica de facilitao que consiste em romper a reunio em pequenos grupos para que as ideias sejam cruzadas. Esta ttica uma das variantes do que se chama polinizao cruzada que adota vrias formas, mas que em sua essncia consiste em ativar a participao de todos para cruzar ideias. Algumas outras formas so mais divertidas, como O Coquetel, onde so entregues ordens e os assistentes circulam trocando ideias entre eles aos pares como em um evento social. Os resultados alcanados so apresentados a todos. Mximo tirou todo o formalismo da situao para permitir uma troca menos rgida, mas espera que a falta de ordens no derive em outros temas por causa do interesse manifestado de todos os presentes. De volta ao redor da mesa de design, cada um com seu cafezinho, Mximo pergunta: O que vamos fazer? Marcela e Claudio se entreolham. Ambos estiveram conversando nos cinco minutos do intervalo. Claudio o mais velho de todos no grupo e pede a palavra formalmente: Marcela e eu pensamos que preciso crescer, e preciso crescer rpido. A dor do crescimento vai se compensar com a magnitude da recompensa, e se perdemos agora no perdemos muito, podemos voltar a comear com o que aprendemos nesta aventura. Para crescer assim rapidamente preciso correr riscos. Em particular, preciso conseguir capital . Outra vez o silncio incmodo. Claudio olha um por um para enfatizar as ideias e continua: Para conseguir capital preciso ter um plano de negcios. Devemos considerar a expanso do nosso prprio capital humano, por exemplo, contratando mais profissionais que trabalhem sob nossas ordens. Isto vai nos levar a uma diviso tcnica do trabalho e especializao.
Capitulo 6
Pgina 68
Boria et al.
Podemos ir mudando as posies se algum no se sentir confortvel com a posio para a qual foi designado, mas no vemos outra soluo. Se pararmos, desapareceremos. Alfredo e Ana se olham. Estamos de acordo, diz Alfredo. Levante a mo quem est de acordo. Todas as mos se levantam. Mximo volta a intervir: Faamos o plano. E logo em seguida, monta uma nova planilha, que ao final de uns minutos fica assim completada (Tabela 6.5) risco: escolhermos as linhas de produto sem uma viso estratgica como base no h oramento suficiente para todas as linhas de produto ningum ficar a cargo de cumprir a viso estratgica com o tempo a viso estratgica ser perdida mitigao: seguirmos um processo ordenado para fixar a viso, a estratgia e as linhas de negcio as linhas de produto escolhidas sero financiadas proporcionalmente sua importncia estratgica vincularmos, claramente, a responsabilidade por cada linha de produto com nfase nos resultados de negcio controlarmos que a linha escolhida seja a linha seguida quando h desvios da estratgia, implementarmos aes corretivas a escassez de recursos implicar desequilbrios entre linhas certos projetos perderem valor para a estratgia a organizao em seu conjunto no visualizar as decises estratgicas utilizarmos a viso estratgica para resolver conflitos de recursos e dependncias crticas revisar, periodicamente, a viso estratgica e redefinir as linhas de produto, cancelando ou continuando projetos comunicar a viso e o estado dos projetos
Tabela 6.5: Riscos do Crescimento
Bom, diz Mximo, j estamos preparados para implementar o processo gerncia de portflio. Projeta ento a seguinte tabela (Tabela 6.6) Gerncia de Portflio de Projetos (GPP)
GPP1
As oportunidades de negcio, as necessidades e os investimentos so identificados, qualificados, priorizados e selecionados em relao aos objetivos estratgicos da organizao por meio de critrios objetivos; Os recursos e oramentos para cada projeto so identificados e alocados; A responsabilidade e autoridade pelo gerenciamento dos projetos so estabelecidas; O portflio monitorado em relao aos critrios que foram utilizados para a priorizao; Aes para corrigir desvios no portflio e para prevenir a repetio dos problemas identificados so estabelecidas, implementadas e acompanhadas at a sua concluso; Os conflitos sobre recursos entre projetos so tratados e resolvidos, de acordo com os critrios utilizados para a priorizao; Projetos que atendem aos acordos e requisitos que levaram sua aprovao so mantidos, e os que no atendem so redirecionados ou cancelados;
GPP2 GPP3
GPP4
GPP5
GPP6
GPP7
Capitulo 6
Pgina 69
Boria et al.
GPP8
A situao do portflio de projetos comunicada para as partes interessadas, com periodicidade definida ou quando o portflio for alterado.
Tabela 6.6: Processo GERNCIA DE PORTFLIO DE PROJETOS [SOFTEX, 2012a]
O QUE ACONTECEU AT AGORA 29. Para poder desenvolver mais opinies em paralelo, Mximo introduziu a tcnica de polinizao cruzada com uma oportuna interrupo na reunio. 30. Utilizando a anlise de risco como ferramenta de explorao, Mximo introduz as prticas que implementam os resultados esperados do MR-MPS-SW correspondentes gerncia de portflio de projetos (ou carteira de projetos). 6.5 Medindo resultados A primeira consequncia da deciso de crescer um novo organograma (Figura 6.3). Alfredo e Ana iro dividir a direo da empresa perante o mercado e coordenaro as atividades dos demais integrantes da empresa.
Figura 6.3: Organograma da Tahini-Tahini
Ana ser a Arquiteta-Chefe, por sua posio como docente de Arquitetura de Software, enquanto que Marcela ser o apoio administrativo e contbil, com incluso da gesto de pessoal e, alm disso, ser gerente de qualidade. Claudio ocupar o cargo de Gerente de Finanas, os gmeos dirigiro as equipes de desenvolvimento (um deles) e suporte e manuteno (o outro). Os scios desistiram de nomear quem ocupar cada cargo porque no conseguem distinguir entre os dois. Mariano, finalmente, se ocupar da ateno ao cliente. Esta funo cuida do marketing, vendas, desenvolvimento de novos produtos e da verificao e validao das verses antes de seu lanamento ao pblico. Uma reorganizao completa. Para facilitar a definio, Mximo compartilha com o grupo sua planilha de Misso e Funes (Tabela 6.7). Estabelecidas as funes e os canais orgnicos de comunicao, necessrio contar com um sistema de deciso. As decises devem ser as mais objetivas possveis. A objetividade surge da existncia de dados que apoiem a deciso. Sem o apoio de dados, a informao no existe, simplesmente uma opinio e no realmente informao. Um sistema de deciso deve se basear em um sistema de informao, e um sistema de informao deve estar sustentado por dados coletados da execuo dos processos. H dois locais onde j vimos a necessidade de coletar dados: na planilha de processos, para poder medir como esto se comportando os processos quando so executados, e nos indicadores de gesto, que ocupam uma coluna na planilha da Tabela 6.7. Falamos de dados, de informao e de deciso. Vamos explicar, agora, o que queremos dizer. Um dado simplesmente uma sequncia de smbolos, gramaticalmente bem formada, mas cuja interpretao pouco clara. O exemplo mais extremo disto uma cadeia de uns (1) e
Capitulo 6
Pgina 70
Boria et al.
zeros (0) que, codificados na memria de um computador, pode ser uma instruo, um dado numrico ou um caractere que pode ser impresso. Menos extremo que isso , por exemplo, uma clula de uma planilha de clculo que nos indica $118. Se no contexto da planilha o smbolo $ indica dlares americanos, possvel entender o contedo da clula: um dado que significa cento e dezoito dlares americanos. Mas esse um nvel sinttico, muito pouco til, no nos serve para entender muito. Necessitamos de mais contexto para subir desse nvel sinttico a um nvel semntico. Em um contexto, esse dado se converte em uma mensagem. Digamos que esse dado est em uma clula, em uma coluna sob o ttulo Preo Futuro do Barril de leo Cru em Tirkit. Agora, a combinao do valor da clula com o valor do ttulo nos d uma interpretao vlida e, possivelmente, nica da mensagem. De qualquer forma, sem um propsito para a deciso, ficamos na mensagem. Para que a mensagem tenha informao necessrio que sirva para a nossa deciso. Assim, se a deciso vender ou no vender meus valores futuros em petrleo, esta mensagem contm informao.
Tabela 6.7: Misso e Funes
Figura 6.4: Dados vs. Informao
Um bom sistema de informao se apoia tanto em dados confiveis como na construo de indicadores que permitam visualizar facilmente a deciso. Por exemplo, para a deciso que usamos como exemplo nesta seo, apresentada na Figura 6.5, uma linha paralela ao eixo X do tempo pelo ponto 105 do eixo dos Preos Futuros constitui um indicador do ponto de venda
Capitulo 6
Pgina 71
Boria et al.
segundo um critrio fixado de antemo. Quando o grfico dos preos ultrapassa o limite, a deciso automtica ou, pelo menos, pode ser automatizada. Partindo das decises que devem ser tomadas, definido quais indicadores permitem tomar a deciso com confiana. Por exemplo, uma deciso tpica de um lder de projeto se ele deve redefinir o escopo dos requisitos com os quais se comprometeu. Para poder decidir isso, necessita um indicador que aponte se, na data de entrega, o produto estar finalizado com a qualidade prevista. Um possvel indicador surge de um mtodo conhecido como valor agregado, EVM (Earned Value Management). O interessante do EVM que mais simples do que a forma como apresentado na literatura. Imaginemos que (a) so seis horas da tarde e voc est sozinho em seu escritrio, pronto para ir para casa, (b) recebe uma ligao de seu primo e melhor amigo: ele teve um acidente com seu automvel e est detido em uma cidade distante 375 quilmetros de onde voc se encontra ao receber a ligao. Se voc no chegar na delegacia em menos de quatro horas, seu primo passar a noite na priso. Se chegar antes e pagar a fiana, seu primo dormir em casa.
Figura 6.5: Grfico sobre Preos Futuros do Petrleo
Seu carro est com o tanque parcialmente cheio e voc acha que ele possui autonomia e velocidade necessrias para chegar a tempo. Voc vai ao caixa eletrnico para retirar dinheiro e em poucos minutos est a caminho. O que pode acontecer? Na verdade, pode ser que o trnsito do horrio de pico faa com que voc chegue depois da delegacia fechar e seu primo passar a noite entre baratas e outros animais. Como no quer perder tempo, pode ser que no caminho fique sem combustvel, longe de um posto e seja obrigado a caminhar perdendo um tempo valioso e possivelmente, para piorar, o carro seja roubado no acostamento. Como saber se estas coisas podem acontecer? Tem-se dois indicadores: quantos quilmetros o seu automvel percorre por hora e quanto combustvel consome, seja por quilmetro ou por hora. Claro, o primeiro indicador conhecido como velocidade e voltaremos a encontr-lo neste captulo quando falarmos com mais detalhe da estimativa. O segundo o consumo, mas diferente consider-lo por quilmetro ou por hora. Por exemplo, possvel diminuir o consumo a zero se algum detm o automvel, mas ento perde-se o objetivo de resgatar o primo da priso. Com EVM estes dois indicadores so calculados. O primeiro o desempenho no tempo e equivalente velocidade. O segundo o desempenho de custos e equivalente ao consumo. Em um automvel medimos os quilmetros percorridos, enquanto que em um projeto de software devemos medir o avano por meio do tamanho do produto ou o nmero de tarefas que so completadas. Como as tarefas no so todas idnticas e s vezes difcil comparlas, melhor tomar uma medida de tamanho (veremos uma mais adiante). Um bom indicador nos mostra, em um golpe de vista, se estamos chegando a tempo ou no. Em EVM so calculados ndices, comparando o realizado e o planejado: um valor exatamente igual a 1 interpretado como estar justo e alinhado ao planejado, enquanto que um valor maior que 1 significa que estamos adiantados em relao ao planejado e um valor menor que 1, que estamos atrasados.
Capitulo 6
Pgina 72
Boria et al.
Idealmente, para cada tarefa existe um produto que resultado de sua execuo. Definimos aqui cinco medidas bsicas [PUTNAM e MYERS, 2003] que devem estar presentes desde o primeiro momento, na definio inicial dos processos. O que vamos medir, e para qu, deve ser parte integral da definio das tarefas. Desse modo, so estabelecidas de imediato as condies para controlar os processos (uma tarefa no mais que a definio, instanciao ou execuo de um passo de um processo). Essas medies so: tamanho e nmero de defeitos 2 relacionados com o produto, e durao, esforo e custo da tarefa. Com isto em mente, a T comeou a reviso de seus processos e completou a definio de medies que tinha deixado pendente nesse nvel. O seguinte nvel o dos indicadores de gesto que exigem os novos papis. Outra vez, a sala de design v nossos velhos conhecidos reunidos. Mximo facilita a criao de uma tabela de 62 riscos associados (Tabela 6.8) a uma possvel m definio do sistema de deciso que os leva a estabelecer medidas para evit-los ou minimiz-los. risco: o sistema de deciso ser defindo arbitrariamente sem considerar a viso estratgica as medidas e indicadores utilizados nos projetos serem decididos sem considerar as necessidades organizacionais cada projeto ter uma verso diferente do sistema de deciso ter-se um sistema de deciso mas no se ter dados no ser possvel reproduzir uma deciso baseada em dados porque os dados no so guardados nem todos os interessados entenderem o porqu das decises mitigao: estabelecer objetivos de medio que correspondam viso estratgica, considerando as decises derivadas decidir as medidas a serem usadas nos projetos em conjunto pela gerncia do projeto e o PMO especificar claramente o procedimento de medio com responsabilidades e controles controlar para que os dados requeridos sejam coletados e analisados guardar os dados e os resultados das anlises de maneira que possam ser recuperados difundir os resultados e as anlises das medies obtidas
Tabela 6.8: Riscos Associados
Como acontece sempre que Mximo facilita a reunio, os resultados coincidem com os esperados pelo MR-MPS-SW: Medio (MED)
MED1
Objetivos de medio so estabelecidos e mantidos a partir dos objetivos de negcio da organizao e das necessidades de informao de processos tcnicos e gerenciais; Um conjunto adequado de medidas, orientado pelos objetivos de medio, identificado e definido, priorizado, documentado, revisado e, quando pertinente, atualizado; Os procedimentos para a coleta e o armazenamento de medidas so especificados; Os procedimentos para a anlise das medidas so especificados; Os dados requeridos so coletados e analisados; Os dados e os resultados das anlises so armazenados;
MED2
MED3
MED4 MED5 MED6
62
A T decidiu que seu sistema de apoio deciso baseado em dados, que outras empresas chamam de seu sistema de medio, seja denominado sistema de deciso. , em parte, um nome que no representa completamente a realidade; mas, por enquanto, vejamos para onde nos leva.
Capitulo 6
Pgina 73
Boria et al.
MED7
Os dados e os resultados das anlises so comunicados aos interessados e so utilizados para apoiar decises.
Tabela 6.9: Processo MEDIO [SOFTEX, 2012a]
Mximo compartilha com o grupo mais dois ativos, a planilha de definio de medidas (Tabela 6.10) e a planilha de definio de indicadores (Tabela 6.11). A situao a respeito das expanses fica ento assim definida: trabalharo com os contadores internamente. Os gmeos conduziro suas respectivas equipes para desenvolver o novo sistema e integr-lo ao existente, ao qual por sua vez daro manuteno. No buscaro novos 2 clientes para o sistema atual, pois o financiamento dever vir da liquidez para manter a T funcionando. Procuraro uma aliana com a empresa de SaaS para servios de sade. Em troca de colocar o know-how de SaaS e da arquitetura, eles esperam participao no negcio e nas patentes que possam surgir. Com a empresa que quer fundir seu software para farmcias 2 com o existente da T , realizaro um convnio pelo qual as duas partes contribuiro para a gerao do cdigo necessrio.
Nome da Medida Estado da Codificao Contar o nmero de programas com codificao e teste unitrio finalizados. utilizada durante a etapa final para compreender o trabalho que falta fazer, comparando com o estimado inicialmente. Permite planejar novas datas de entrega com alguma antecipao. Medidas Bsicas Data Planejada de finalizao do Programa Data Real de finalizao do programa Atributos Identificador nico de Programa (UPI) Nome do programador responsvel Data estimada de comeo da programao Data real de comeo da programao Data estimada de finalizao da programao Data real de finalizao da programao Medidas Derivadas Programas Acumulados Planejados para a Semana Programas Acumulados Realizados na Semana Clculos utilizados Contagem do nmero de programas cuja data de finalizao segundo o plano cai dentro da semana em questo. Fonte de Dados Planilha de construo de programas do lder tcnico do projeto Subversion Critrio de Validade O Plano est aprovado e sob controle de configurao A data de entrada gerada automaticamente pela ferramenta
Contagem do nmero de programas cuja data de finalizao segundo o Subversion ocorreu dentro da semana em questo. Tabela 6.10: Definio de Medidas
O QUE ACONTECEU AT AGORA 31. Mximo contribuiu com a definio de papis trazendo a planilha com a misso, funo e comunicao entre eles. 32. Mximo enfatizou a definio dos indicadores de gesto exigidos pelos novos papis com base nos riscos. 33. Mximo compartilhou com o grupo dois ativos: a planilha de definio de medidas e a planilha de definio de indicadores. O trabalho intenso, mas proveitoso. A nova estrutura comea a dar frutos em forma de aes 2 paralelas. O ambiente se energiza e a T comea a preparar sua decolagem. Claudio inicia
Capitulo 6
Pgina 74
Boria et al.
aes que incorporaro apoio financeiro empresa. Marcela prepara os processos com a ajuda de uma estagiria da Escola de Engenharia. Os gmeos fazem um curso de Scrum Master na Califrnia. Alfredo assina acordos e estreita laos. Mariano mantm a continuidade 2 com os clientes. Praticamente sozinho, ele sintetiza o que a T era at a semana anterior. Ana ocupa suas ltimas semanas, antes de ser me, deixando todas as decises sobre a arquitetura bem documentadas. Data de criao Especificao e Uso do Indicador Amostra do Indicador <data> <nome do indicador, explicar seu uso>
Ttulo, com Data do Relatrio

160 140 120 100 80 60 40 20 0 data data data data data data data 1 2 3 4 5 6 7
Medida Derivada 1 Medida Derivada 2
Modelo de Anlise
Descreve as aes necessrias quando o indicador mostra certos padres de comportamento. Por exemplo, se dois valores sucessivos do indicador so menores do que o valor anterior na srie, necessrio realizar uma atividade de anlise de causa-raiz e notificar a Alta Gerncia, o Comit de Controle do Produto e a rea de Gesto de Qualidade sobre a situao. Xxx
Critrio de Deciso
Identifica os pontos que disparam novas aes ou servem para determinar futuras investigaes Xxx
Medidas Utilizadas
Identifica as medidas bsicas ou derivadas que so usadas na construo do indicador Medida Derivada: xxx Medida Derivada: yyy Medida Bsica: zzz Medida Bsica: aaa
Capitulo 6
Pgina 75
Boria et al.
Construo do Indicador
Descreve os passos a seguir na construo do indicador, por exemplo: Calcule, cada ms, o ndice xxx a partir dos valores mdios de zzz e aaa. Faa o mesmo para a medida derivada yyy, que a mdia ponderada do valor hora da equipe de projetos. Crie um diagrama de barras como exemplificado acima. Pode-se utilizar a planilha amostra para gerar o grfico. Medida Derivada: xxx Medida Derivada: yyy Medida Bsica: zzz Medida Bsica: aaa
Tabela 6.11: Definio de Indicadores
6.6 Protegendo os Ativos Se os produtos que temos sero misturados com componentes ou sistemas externos, eles devem estar protegidos. Mesmo se no for um programa to extenso, os ramos de um s produto vo se expandindo medida que surgem variantes no cdigo e h diferentes verses instaladas. Os riscos de no controlar os ativos da empresa so vrios: risco: Se no sabemos onde esto armazenados os produtos e os resultados, perderemos tempo e possivelmente trabalho Se no se pode encontrar uma folha no bosque, vai ser perdido muito tempo identificando cada parte Se os documentos so atualizados sem que os interessados saibam da atualizao, pode haver conflitos entre mudanas Se no sabemos quem mudou o que, nem quando mudou, pode ser difcil reproduzir os motivos e decises em torno de uma mudana Se as pessoas no respeitarem as regras e os ativos armazenados em qualquer local e qualquer um tiver acesso e liberdade para modificar, pode-se introduzir muito retrabalho mitigao: adotar um sistema de gesto de documentao
adotar um sistema de classificao dos itens armazenados adotar um critrio de baseline onde s se pode modificar um documento da baseline sob regras rigorosas de controle registrar a histria das mudanas de baseline seguir um processo formal para mudar um produto controlar para que os produtos de trabalho sejam armazenados, possam ser lidos e liberados para uso de acordo com um processo
Tabela 6.12: Riscos Derivados da Falta de Controle de Ativos
Mximo introduz ao grupo a noo de baseline de produtos . Uma baseline um conjunto de especificaes ou produtos de trabalho que foram formalmente revistos e acordados, que servem como base para um desenvolvimento posterior e que s podem ser modificados por meio do procedimento estabelecido para controle de mudanas. O propsito de definir uma baseline manter o acordo que a produz, sem fixar uma armadilha ao redor dos produtos para que nunca mudem, mas protegendo-os de mudanas no comunicadas. Para que seja possvel gerar a baseline necessrio definir claramente as responsabilidades a respeito do 2 produto em questo. Para a T existem trs tipos de arquivos, segundo o seu contedo. Existem os de cdigo, de documentao de baseline e de comunicao. Cada um tem seu tipo e suas propriedades, que fazem com que sejam protegidos de diferentes maneiras. Certos
63
63
Existem outras baselines,por exemplo, baselines de cronograma e de comportamento de um processo que veremos mais adiante.
Capitulo 6
Pgina 76
Boria et al.
documentos, como os casos de teste, o documento de arquitetura e a especificao funcional, tm uma verso nica que mantida simplesmente com restries de acesso: um nico dono, ou pelo menos um nico papel que pode modific-los. Em outros, um nico dono indesejvel, em particular quando se trata de cdigo, onde desejvel que coexistam vrias verses. A Tabela 6.13 mostra as propriedades de cada tipo. Para armazenar cada um dos diferentes tipos, o grupo precisa tomar decises sobre o sistema que utilizar. Em princpio adotam para o cdigo o modelo de [MOREIRA, 2010] de integrao contnua. O mesmo produto freeware que estavam utilizando serve para armazenar o cdigo com as caractersticas definidas na Tabela 6.13. H vrias possibilidades para os outros dois tipos: baseline e comunicaes. Podem ser usados produtos denominados DMS ( Document Management Systems) ou solues mais simples como um disco virtual com uma estrutura de pastas que sejam definidas a partir da estrutura e tipo do projeto. Por exemplo, para um projeto que adote a estrutura de Scrum possvel que existam pastas para o Backlog do Produto, o Backlog do Sprint, as comunicaes do Dono do Produto, as medidas, o cdigo e os casos de teste. Pode ser que as pastas, por sua vez, estejam subdivididas. Cada pasta ter seu controle de leitura e escrita de acordo com os papis e as necessidades detectadas. Por exemplo, o engenheiro de testes pode escrever e apagar na pasta de casos de teste, mas o Scrum Master, no. No entanto, o Scrum Master poder ter acesso aos casos de teste para l-los, mas outras pessoas fora da equipe no podem fazer isso. TIPO cdigo baseline comunicao Dono Mltiplos nico (por papel) Ningum acesso check out read only read only Atualizao check in e merge write do dono no se aplica verses mltiplos nica em vigncia no h verses
Tabela 6.13: Propriedades de Cada Tipo de Item de Configurao
Outra questo a ser decidida so as auditorias. H auditorias fsicas que controlam que em um repositrio no haja nada a menos nem a mais do que o que deve estar ali. Deste modo, protege-se a integridade da organizao: no queremos distribuir Trojans com nosso software. Tambm existem as auditorias lgicas. Neste caso, o que se coloca em jogo a sequncia com que se chegou ao produto. Por exemplo, se para subir o cdigo fonte rea de testes, necessrio, antes, ter passado por trs etapas (digamos que primeiro se criou o caso de teste que devia mostrar um defeito, por falta de cdigo a acrescentar; depois, este cdigo foi criado e vimos que no acusava mais erros, e na terceira etapa ele foi integrado e verificado em relao ao conjunto de casos de teste de regresso, a auditoria lgica procuraria evidncias de que todos os passos foram cumpridos antes de aceitar que o cdigo em questo seja subido. Mais uma vez a responsabilidade de escrever os processos e catalog-los cai nas mos de Marcela, mas sua experincia faz com que seja fcil o que a princpio exigia muito esforo. Marcela continua usando os materiais apresentados por Mximo, definindo os produtos de cada procedimento e as medidas e indicadores pertinentes. A nomenclatura dos produtos surge das prticas habituais, o resto foi decidido entre todos. Uma estagiria ajuda a escrever e corrigir os processos. O conjunto de prticas definidas, quando for implementado, cobre os resultados esperados de Gerncia de Configurao: Gerncia de Configurao (GCO)
GCO1 GCO2
Um Sistema de Gerncia de Configurao estabelecido e mantido; Os itens de configurao so identificados com base em critrios estabelecidos; Os itens de configurao sujeitos a um controle formal so colocados sob baseline; A situao dos itens de configurao e das baselines registrada ao longo do tempo e disponibilizada; Modificaes em itens de configurao so controladas;
GCO3
GCO4
GCO5
Capitulo 6
Pgina 77
Boria et al.
GCO6
O armazenamento, o manuseio e a liberao de itens de configurao e baselines so controlados; Auditorias de configurao so realizadas objetivamente para assegurar que as baselines e os itens de configurao estejam ntegros, completos e consistentes.
Tabela 6.14: Processo GERNCIA DE CONFIGURAO [SOFTEX, 2012a]
GCO7
O QUE ACONTECEU AT AGORA 34. Como a T ir criar produtos a serem integrados com sistemas externos e usar outros produtos, em vrios subsistemas, Mximo introduziu o uso de prticas de gesto de configurao como medida para proteger os diferentes ativos. 6.7 Garantindo a Qualidade dos Processos e Produtos Passaram-se trs meses e os novos processos esto em fase de implementao. H doze 2 pessoas novas trabalhando na T e a sala de design passou a ser a sala de uma das duas 2 equipes de Scrum. A um quarteiro dali, mais perto do rio, abriram uma filial da T , com a direo geral e financeira, e o lugar que antes era ocupado pelos escritrios de Alfredo, Ana e Claudio agora um pequeno labirinto de postos de trabalho. As rodas da produo giram aceleradas. Marcela tem uma preocupao: poder julgar se o crescimento altera a qualidade dos produtos, para o qual precisa revisar o que e como produzido. Poderamos pensar que, em uma cultura que respeita a deciso de escolher os prprios processos, no necessrio que algum verifique o que vem depois, mas o conjunto da organizao que exige isso. Marcela conhece a tcnica de auditorias, mas luta contra o problema de sua falta de valor agregado. Para que, se pergunta, serve o resultado da auditoria organizao? E ao projeto auditado? Marcela v que coletar dados sobre as no conformidades com as normas e processos um bom modo de comear a entender como os processos so usados e quais normas so aplicadas, mas vacila ante o retorno que possa ter para o projeto individual. Quando Mximo explicou a escrita de processos T partiu da planilha da Figura 5.10, mas depois utilizou uma planilha de folha de clculo, uma linha para cada passo do processo. As colunas agora representam os itens da planilha: Propsito, Envolvidos, Entradas Exigidas e assim sucessivamente, inclusive com a sequncia prevista de que alguns passos sejam condicionais ou possam ser executados em paralelo com outros e no sejam todos simplesmente sequenciais. Com essa folha de clculo na mo, Marcela teve uma inspirao. Procurando entre suas pastas no computador, encontrou um webinar que baixou do 64 SlideShare . Voltou a l-lo e decidiu elaborar auditorias proativas, uma contradio em termos, mas que parece ter sido sugerida pelo webinar. Ao invs de estabelecer um programa de auditorias frequentes, Marcela se prope a participar em eventos de lanamento de etapas, como o comeo de cada sprint e as apresentaes ao dono do produto, e fazer a abertura lembrando, a todos, os passos que foram escolhidos para o processo. Nesse momento, decises podem ser modificadas, dispensas outorgadas e a atuao pode ser revista. Claro que Marcela participar em todas as retrospectivas. Como o Dono do Produto interno T , Marcela decide utiliz-lo na funo de auditor de encerramento. Alm disso, os membros da equipe recebero aleatoriamente mensagens de correio eletrnico pedindo que confirmem a execuo do processo em todos os seus passos. Desse modo, as auditorias aconteceriam sem entorpecer o desenvolvimento e s seriam sobre aqueles pontos que Marcela, como gerente de qualidade, sinta necessidade de enfatizar. Para introduzir seus processos de garantia de qualidade, Marcela rouba uma tcnica de Mximo e apresenta os riscos de no seguir seus processos:
2 2 2
64
http://www.slideshare.net/jorgeboria/qa-3-best-practices
Capitulo 6
Pgina 78
Boria et al.
risco: Se no possvel compartilhar os produtos porque possuem diferentes formatos possvel que tenhamos muitos erros involuntrios Se as pessoas no seguirem os processos que estabelecemos, no possvel assegurar que o que acontece o que se espera; alm de no aprender com os erros, provvel que faamos muitos Se detectarmos problemas mas no os comunicamos, eles no sero resolvidos por si mesmos, e possvel que todos percam o respeito aos processos Se no conseguirmos acordo sobre as aes a serem seguidas para corrigir no conformidades, ou se as aes decididas no forem controladas, possvel que as boas prticas sejam abandonadas
mitigao: verificar se os produtos esto aderentes s regras que so poltica da organizao
verificar se as pessoas seguem as regras e processos que so poltica da organizao
comunicar os problemas e as no conformidades que possam ser resolvidas
quando existirem no conformidades ou problemas, elaborar um plano de ao para que se mantenham as boas prticas ou se corrija o processo
Tabela 6.15: Riscos de no Auditar
Considerando esses riscos, os participantes da reunio aprovam o processo de auditoria apresentado por Marcela, o que inclui, para cada projeto: 1. 2. 3. 4. 5. 6. 7. revisar os riscos revisar o plano selecionar processos crticos selecionar produtos crticos planejar auditorias realizar auditorias analisar resultados
Marcela tambm definiu uma escala de severidade das no conformidades entre o realizado e as normas e padres (Tabela 6.16). SEVERIDADE
SEV 1 SEV 2
INSALVVEL: Corrigir imediatamente, escalar de imediato; GRAVE: Consertar antes do prximo marco, escalar se no for corrigido; NEGOCIVEL : (a) Consertar antes do prximo marco ou (b) auditar na prxima oportunidade, escalar se (a) no for consertado; SALVVEL: Fornecer dispensa, registrar no conformidade, fechar; REPREENSVEL: Advertir, fechar.
SEV 3
SEV 4 SEV 5
Tabela 6.16: Severidade de No conformidades em Auditorias
O procedimento realizar auditorias contm um mtodo de escal onamento que tambm submetido ao julgamento dos scios. Dependendo da severidade, o procedimento permite 2 alcanar nveis da direo da T cada vez mais altos quando uma no conformidade no tratada. O procedimento de escalonamento completado quando a no conformidade resolvida ou a pessoa que escalada decide fech-lo sem que seja necessrio trat-la. A Figura 6.6 mostra o processo desenhado por Marcela.
Capitulo 6
Pgina 79
Boria et al.
Figura 6.6: Processo de Auditoria da Qualidade
Para completar a reunio, a equipe de direo rev os resultados esperados correspondentes ao processo Garantia da Qualidade. Garantia da Qualidade (GQA)
GQA1
GQA2 GQA3 GQA4
A aderncia dos produtos de trabalho aos padres, procedimentos e requisitos aplicveis avaliada objetivamente, antes de os produtos serem entregues e em marcos predefinidos ao longo do ciclo de vida do projeto; A aderncia dos processos executados s descries de processo, padres e procedimentos avaliada objetivamente; Os problemas e as no conformidades so identificados, registrados e comunicados; Aes corretivas para as no conformidades so estabelecidas e acompanhadas at as suas efetivas concluses. Quando necessrio, o escalamento das aes corretivas para nveis superiores realizado, de forma a garantir sua soluo.
Tabela 6.17: Processo GARANTIA DA QUALIDADE [SOFTEX, 2012a]
O QUE ACONTECEU AT AGORA 35. Marcela utilizou a tcnica de identificar riscos para induzir introduo de prticas de garantia da qualidade. 6.8 A pequena fbrica de software com Scrum Os gmeos fizeram progressos enormes com o desenvolvimento de software utilizando as 2 prticas de Scrum, colocando em bom uso o investimento da T em sua formao como Scrum Master. Eles se reuniram com os programadores, engenheiros de teste e documentadores contatados por Marcela e depois de duas semanas de esforo, selecionaram duas equipes de trabalho. As equipes vo utilizar as tcnicas de Scrum, mas com o acrscimo de um sprint curto de anlise que exigir a interveno de Ana, para que a arquitetura esteja bem clara para todos. A equipe de manuteno se dedicar exclusivamente a corrigir os defeitos encontrados e a fornecer equipe de melhorias a tecnologia de desenvolvimento criando, por exemplo, um framework para scripts de testes e diversas extenses ferramenta de integrao contnua. A
Capitulo 6
Pgina 80
Boria et al.
equipe de desenvolvimento puro se encarregar de introduzir melhorias sistemticas, como novas funcionalidades e refatorao do cdigo, para o contrato com os contadores. Por causa da aceitao do painel kanban, os gmeos o mantm dentro do grupo de tcnicas que vo aplicar nos sprints. Para aumentar a visibilidade e a transparncia, as equipes utilizaro tambm um grfico de Burndown que mostre os avanos e retrocessos em um sprint. Da mesma forma, os gmeos compilaram uma lista dos componentes mais importantes do Scrum e a transformaram em um quadro que foi pendurado em cada sala. No estilo prprio deles, uma imagem muito forte que mostra claramente a mensagem. Eles a cham am: A Morte do Scrum (Figura 6.7).
Figura 6.7: A Morte do Scrum
Levando em conta as tcnicas que incorporaram, os gmeos realizam uma auto avaliao do 2 grau de cobertura dos resultados esperados do MR-MPS-SW na T . Revisam os resultados com Mximo e, com satisfao, reafirmam que o caminho escolhido est correto (Figura 6.8). 2 T comea a preparar sua avaliao nvel F do modelo MPS de Software (MPS-SW). O QUE ACONTECEU AT AGORA 36. Os gmeos implementaram o Scrum em duas equipes conservando os painis kanban para entender o estado do trabalho, acrescentando o grfico de Burndown de tarefas e o Backlog do sprint como ferramentas de controle do projeto. 37. Tahini-Tahini se prepara para a avaliao de Nvel F.
Capitulo 6
Pgina 81
Boria et al.
de Pla nif. Veloc ida de Hist rica Ta xa d e "Q ueim ado" Retr o spect iva
Ba cklo g
Ka nb an
Demo
Gerncia de Projetos nos Nveis G e F
GPR 1 GPR 2 GPR 3 GPR 4 GPR 5 GPR 6 GPR 7 GPR 8 GPR 9
GPR 10 GPR 11 GPR 12 GPR 13 GPR 14 GPR 15 GPR 16 GPR 17 GPR 18 GPR 19
O escopo do trabalho para o projeto definido; As tarefas e os produtos de trabalho do projeto so dimensionados utilizando mtodos apropriados O modelo e as fases do ciclo de vida do projeto so definidos O esforo e o custo para a execuo das tarefas e dos produtos de trabalho so estimados com base em dados histricos ou referncias tcnicas O oramento e o cronograma do projeto, incluindo a definio de marcos e pontos de controle, so estabelecidos e mantidos Os riscos do projeto so identificados e o seu impacto, probabilidade de ocorrncia e prioridade de tratamento so determinados e documentados Os recursos humanos para o projeto so planejados considerando o perfil e o conhecimento necessrios para execut-lo Os recursos e o ambiente de trabalho necessrios para executar o projeto so planejados Os dados relevantes do projeto so identificados e planejados quanto forma de coleta, armazenamento e distribuio. Um mecanismo estabelecido para acess-los, incluindo, se pertinente, questes de privacidade e segurana Um plano geral para a execuo do projeto estabelecido com a integrao de planos especficos A viabilidade de atingir as metas do projeto explicitamente avaliada considerando restries e recursos disponveis. Se necessrio, ajustes so realizados O Plano do Projeto revisado com todos os interessados e o compromisso com ele obtido e mantido O escopo, as tarefas, as estimativas, o oramento e o cronograma do projeto so monitorados em relao ao planejado Os recursos materiais e humanos bem como os dados relevantes do projeto so monitorados em relao ao planejado Os riscos so monitorados em relao ao planejado; O envolvimento das partes interessadas no projeto planejado, monitorado e mantido Revises so realizadas em marcos do projeto e conforme estabelecido no planejamento Registros de problemas identificados e o resultado da anlise de questes pertinentes, incluindo dependncias crticas, so estabelecidos e tratados com as partes interessadas Aes para corrigir desvios em relao ao planejado e para prevenir a repetio dos problemas identificados so estabelecidas, implementadas e acompanhadas at a sua concluso
a a a a a a
Jogo
a a a
a a
a a
a a a a a a
a a a a
a a
Figura 6.8: Cobertura dos Resultados Esperados com Scrum e Kanban
O QUE ACONTECEU AT AGORA DESDE O PRIMEIRO DIA 1. O consultor Mximo estabeleceu o contato inicial com o cliente, coincidentemente com um problema grave e facilitou sua identificao. 2. Introduziu uma primeira tcnica de anlise de causas, o diagrama de Ishikawa. 3. Utilizando a tcnica chegou, junto aos clientes, concluso de que seus processos deixavam muito espao a problemas como o detectado, a falta de controle das tarefas. 4. Apesar de ter um diagnstico concreto que j aponta para a melhoria de processos, Mximo se concentrou no problema imediato para evitar um problema ainda maior, comeando por definir as caractersticas (ou atributos) desejveis da soluo. 5. Mximo sugeriu o mtodo Kanban, sem imp-lo, e foi escutado. 6. Mximo induziu o uso do painel kanban, sem mandar. 7. Introduziu os conceitos de sub-histria e estimativa por tamanho. 8. H uma clara definio do escopo do trabalho a realizar, encarnado na lista de histrias, com sua correspondente estimativa de tamanho. 9. Foi feita uma desagregao das histrias, onde o tamanho destas fazia com que fossem teis. 10. Os conceitos de histria, sub-histria, desagregao e tarefa foram entendidos na prtica e aplicados. Distingue-se entre tarefa e sub-histria. 11. Mximo mostrou que o uso do painel kanban dinmico e pode ser modificado. 12. Ficou esclarecido o que significa uma tarefa estar PRONTA, para cada etapa do seu ciclo de vida. 13. Visualiza-se, facilmente, o ciclo de vida de uma histria no painel. 14. O controle do estado geral de uma histria e as tarefas associadas podem ser lidos no painel.
Capitulo 6
Pgina 82
Scr um D
i rio
Boria et al.
15. Mximo incorporou melhorias ao documento de Backlog, tornando-o mais slido e til. 16. Utilizando uma planilha de riscos, foram analisados os possveis efeitos indesejados associados com as histrias do projeto. 17. Foi incorporada uma planilha de propostas que permite reunir em um documento dinmico, o Backlog e o oramento, alm de acrescentar as responsabilidades das partes contratuais. 18. Os compromissos mtuos entre cliente e fornecedor ficam documentados, em especial, o escopo do projeto, representado no Backlog. 19. Mximo introduziu o Scrum dirio para avaliar os avanos dia a dia e o estado geral do sprint, includos os riscos associados para, com isso, melhorar o controle e proporcionar evidncias de vrios resultados esperados do MR-MPS-SW. 20. A organizao incorpora uma demonstrao do produto ao final de cada sprint como critrio de aceitao pelo usurio, que serve para evidenciar a sua participao. 21. A anlise de lacunas exercida como atividade contnua mostra que os resultados esperados para GRE surgem dos processos j implementados. 22. Mximo introduziu um curto procedimento para definir a estrutura de pastas de um projeto em seu site, o que deixa evidente a implementao de GPR 8 e GPR 9. 23. Mximo definiu e codirigiu vrias implementaes do procedimento de anlise retrospectiva, o que traz evidncias de GPR 17, GPR 18 e GPR 19. 24. Mximo redigiu uma poltica que a organizao aprovou para estabelecer os 2 alinhamentos do que se espera dos colaboradores da T . 25. Mximo desenvolveu um processo que permite evidenciar as capacidades de processo de Nvel G do MR-MPS-SW para as atividades de planejamento, por meio da proposta e gesto de requisitos, do Backlog do produto e da evoluo do painel kanban. 26. T alcanou o nvel G do MR-MPS-SW em uma avaliao oficial. 27. Mximo utilizou a tcnica dos chapus de cores para semear o caminho de ideias e, com o diagrama de Ishikawa, ajudar os scios a decidir que caminho seguir na empresa (crescer ou no crescer). 28. Mximo ajudou a rever os riscos de contratao de fornecedores e a estudar as alternativas de comprar, reutilizar ou construir, introduzindo a tcnica da matriz de Pugh. 29. Para poder desenvolver mais opinies em paralelo, Mximo introduziu a tcnica de polinizao cruzada mediante um oportuno corte na reunio. 30. Utilizando a anlise de riscos como ferramenta de explorao, Mximo introduziu as prticas que implementam os resultados esperados do MR-MPS-SW correspondentes gesto de portflio (ou carteira) de projetos. 31. Mximo contribuiu para a definio de papis apresentando a planilha com a misso, funo e comunicao entre eles. 32. Mximo enfatizou a definio dos indicadores de gesto que requerem os novos papis baseando-se nos riscos. 33. Mximo compartilhou com o grupo dois ativos: a planilha de definio de medidas e a planilha de definio de indicadores. 34. Como a T ir criar produtos a serem integrados com sistemas externos e usar outros produtos, em vrios subsistemas, Mximo introduziu o uso de prticas de gesto de configurao como medida para proteger os diferentes ativos. 35. Marcela utilizou a tcnica de identificar riscos para induzir introduo de prticas de garantia da qualidade.
2 2
Capitulo 6
Pgina 83
Boria et al.
36. Os gmeos implementaram o Scrum em duas equipes conservando os painis kanban para entender o estado do trabalho, acrescentando o grfico de Burndown de tarefas e o Backlog do sprint como ferramentas de controle do projeto. 37. Tahini-Tahini se prepara para a avaliao de Nvel F.
Capitulo 6
Pgina 84
Boria et al.
Parte III Evoluo

CAPTULO 7 - ORGANIZANDO A ORGANIZAO 7.1 Nvel E do MR-MPS-SW Este captulo tem como objetivo discutir a implementao de processos que so exigidos no nvel E do modelo de referncia MPS-SW. Para alcanar o Nvel E de maturidade necessrio conservar ou alcanar os nveis de maturidade anteriores (G e F), e implementar os processos Avaliao e Melhoria do Processo Organizacional (AMP), Definio do Processo Organizacional (DFP), Gerncia de Recursos Humanos (GRH) e Gerncia de Reutilizao (GRU). Da mesma forma, o processo de Gerncia de Projetos (GPR) sofre sua primeira evoluo, passando a ter como propsito a utilizao de um processo definido para o projeto como base da gesto, por meio de planos bem integrados. Tambm h uma evoluo quanto aos atributos de processos, j que aos atributos de processo AP 1.1, AP 2.1 e AP 2.2 so agregados AP 3.1 e AP 3.2. (Ver Captulo 4 para maiores detalhes destes atributos de processo). 7.2 Uma Empresa em Franco Crescimento Nem bem terminam as mensagens de felicitao por terem alcanado o Nvel F do MR-MPSSW, os avanos realizados so colocados prova. As tarefas de desenvolvimento se multiplicam e os ajustes ao sistema para novos e velhos clientes tambm. Alberto Galarraga exige duplicar o nmero de equipes para desenvolvimento e manuteno, para o qual utiliza a anlise de portflio que j tinha sido utilizada para decidir o crescimento. Trabalhando com Marcela, que comeou h meses um mestrado em administrao, tentam duplicar a seleo de pessoal que, embora funcionasse relativamente bem na criao das duas primeiras equipes de Scrum, ao ter sido esgotada a fonte para contratao de jovens no ltimo ano de Engenharia da Computao, gerou problemas para conseguir pessoal capacitado. Mesmo quando alguma pessoa foi selecionada e seu perfil promissor, a incorporao longa e dolorosa. J acostumados s tcnicas de Mximo, juntam-se com Marcela para analisar os problemas e identificar as suas causas-raiz. O tema da reunio o esforo que demanda incorporar novos colaboradores: 1. O perfil do colaborador solicitado no est bem definido 2. No existe um repositrio de conhecimentos que ajude a minimizar o aprendizado individual de tcnicas e mtodos 3. No h uma definio do ambiente de trabalho que permita solicitar os recursos necessrios com antecipao para que o recurso humano entre em ao de imediato 4. No h uma integrao aos processos da T que acelere a formao de equipes 5. No se leva em conta para a seleo de pessoal o tempo requerido para anlise dos candidatos Como j tradio, so listadas as medidas que sero tomadas. Claramente, neste caso, suficiente a negao dos problemas: definir bem os perfis, montar um repositrio de conhecimentos, definir o ambiente de trabalho, etc. Marcela a encarregada de realizar a busca, seleo e contratao na nova estrutura e, assim, cabe a ela a maioria das atividades que surgem da reunio. Trabalha com os gmeos 65 na elaborao de um modelo de competncias para membros da equipe, para eliminar
65
The Art and Science of Competency Models . Pinpointing Critical Success Factors in Organizations LUCIA, A.D., LEPSINGER, R., 2007
Capitulo 7
Pgina 85
Boria et al.
rapidamente a primeira parte do problema. Com base no que foi realizado, pensa em estender o modelo a todos os papis que existem dentro da organizao. Comea utilizando o formulrio 2 de misso e funes da T que uma variao da planilha que apresentamos no Captulo anterior. Como exemplo, colocamos na Figura 7.1 o formulrio completo para o cargo de Engenheiro de Testes.
Misso e Funes Nome do Cargo
Engenheiro de Teste
Nome do Cargo ao Qual se Reporta
Gerente de Teste (matricialmente), Scrum Master (tecnicamente), Equipe de Scrum (funcionalmente)

Misso (Por que existe o cargo)
A misso dos Engenheiros de Teste detectar e informar os defeitos e problemas nos produtos da empresa, para que esta possa tomar corretamente as decises de negcio sobre a qualidade dos produtos em relao a estarem prontos para serem liberados para uso. nossa poltica exceder a satisfao do cliente em nossas entregas de produto.
Fator(es) Crtico(s) de Sucesso (Os aspectos mais visveis do cargo)
1. Falhas detectadas pelo usurio (prvio a e nos primeiros seis meses depois do lanamento) 2. Satisfao dos engenheiros de software com os relatrios recebidos 3. Eficincia dos casos de teste criados (rendimento em defeitos por caso sobre total de defeitos) 4. Eficincia na execuo de casos de teste e relatrio dos resultados
Medidas de Desempenho (Como se pode medir o xito do cargo)
1. Nmero de defeitos, no previamente detectados, que foram encontrados no teste de aceitao 2. Nmero de defeitos detectados pelos usurios nos primeiros seis meses de uso que no foram previamente detectados 3. Nmero de defeitos informados no reproduzveis a partir do relatrio 4. Nmero de relatrios rejeitados pelos engenheiros de software 5. Nmero de defeitos que passam de aberto a fechado sem passos intermedirios depois do relatrio 6. Produtividade mdia dos casos de teste criados 7. Nmero total de relatrios aceitos pelos engenheiros de software 8. Nmero de casos executados por unidade de tempo 9. Nmero de defeitos informados por unidade de tempo
Funes (O que faz o ocupante do cargo para cumprir a misso)
1. Interpreta o Plano de Testes de Software 2. Rev e testa documentos de requisitos (com tcnicas como Grficos de Causa e Efeito)
Capitulo 7
Pgina 86
Boria et al.
3. 4. 5. 6. 7. 8.
Cria Procedimentos de Teste Cria Casos de Teste Executa os procedimentos de teste usando os casos de teste Informa os resultados de cada teste Cria casos de teste crticos para assegurar a identificao do defeito Executa os casos de teste sob a proteo de monitoramento de cobertura e analisa as medies resultantes 9. Escreve scripts de casos de teste para automatizar sua execuo 10. Entende as prioridades entre casos e otimiza o tempo para aumentar a produtividade
Comunicao dentro da organizao
Com os engenheiros de software, para expandir o realizado em testes executados e os respectivos relatrios Com o gerente de testes, para receber instrues acerca das tarefas a realizar e informar as atividades realizadas e situaes excepcionais Com os analistas de negcios, para desenvolver requisitos verificveis por testes e receber sugestes para o desenvolvimento de casos de teste Com os analistas de negcios, para detalhamento do que foi informado nos documentos de requisitos Com o Scrum master e a equipe do Scrum, para priorizar e classificar os defeitos encontrados (leve, srio, fatal, etc.)
Comunicao fora da organizao
Em casos particulares, com os usurios finais ou um representante deles, para planejar e realizar o teste de aceitao do usurio
Qualificao para o cargo
Trs ou mais anos em posies tcnicas relacionadas (redator tcnico, programador) ou dois anos de experincia de teste em projetos similares Experincia com integrao contnua Experincia com automatizao de testes de software Clareza de pensamento e capacidade de comunicao Boa memria visual Ateno aos detalhes Experincia em TDD desejvel Experincia em mtodos geis desejvel
Educao formal
Diploma superior ou tcnico relacionado com a profisso Certificaes profissionais MPS, MS ou semelhantes, desejveis.
Figura 7.1: Formulrio Completo Misso e Funo para Engenheiro de Teste
Esta a definio do cargo. Para construir o modelo de competncias, Marcela precisa considerar trs dimenses de cada papel: as competncias bsicas, as competncias tcnicas e as competncias especficas. As mesmas competncias bsicas so exigidas para todas as posies. Uma competncia bsica, tambm chamada de nuclear ou elementar, definida como um conhecimento, habilidade ou comportamento essencial para que algum possa atuar
Capitulo 7
Pgina 87

2
Boria et al.
corretamente como pessoal efetivo da T . As competncias bsicas so aplicadas geralmente a todos os cargos da mesma maneira. Uma competncia tcnica uma habilidade particular relacionada, especificamente, com o papel em questo, por exemplo, o engenheiro de testes precisa ser capaz de realizar o design de um caso de testes. As competncias especficas de 2 um cargo so aquelas que so prprias dos processos da T , por exemplo, um Scrum Master deve possuir as competncias que lhe permitam fazer funcionar sua equipe, mas, alm disso, 2 deve fazer da maneira esperada na T , quer dizer seguindo suas polticas, processos e procedimentos. Tipicamente, as competncias bsicas e as tcnicas so utilizadas no processo de seleo, embora s vezes os colaboradores possam ter acesso capacitao para adquirir ou aumentar suas competncias tcnicas, e existem programas de sensibilizao a respeito das competncias bsicas. Em seguida apresentada uma lista das competncias bsicas que Marcela e os gmeos 2 entendem serem indispensveis para trabalhar na T , com a descrio do comportamento esperado em cada uma: tica e Integridade: Comporta-se sempre com honradez e admite os erros quando so assinalados, no assume ideias alheias como prprias; Servio ao Cliente: Cumpre com os objetivos do projeto a respeito dos nveis de servio ao cliente, esforando-se constantemente para alcan-los e at super-los; Comunicao: Comunica-se com eficincia de forma verbal e escrita; Resoluo de problemas: Desenvolve estratgias eficazes ajustadas s necessidades do negcio e resolve problemas; Flexibilidade: Demonstra flexibilidade nos papis em que atua e gerencia suas mudanas de maneira que tenham como resultado um desempenho produtivo; Tecnologia: Utiliza equipamentos e tecnologia de maneira segura, eficiente e eficaz; Segurana: Cumpre com as normas de segurana, observa as prticas de trabalho seguras e proporciona informao sobre questes de segurana; Autogesto: Maximiza o prprio tempo e aproveita seu talento para alcanar os objetivos da organizao; Crescimento: Procura oportunidades para inovar e melhorar continuamente; Adaptao: Desenvolve enfoques eficazes para a gesto de si mesmo na mudana organizacional; Trabalho em equipe: Trabalha de forma eficiente com a equipe de trabalho e tambm com aqueles que esto fora da linha formal de autoridade para conseguir os objetivos organizacionais; Prudncia: Utiliza os recursos baseando-se sensatamente nas prioridades da organizao. Alm disso, o modelo que desenvolvem contm as competncias tcnicas para cada um dos cargos. Ainda no desenvolveram um modelo completo, que dever conter um mecanismo de avaliao do grau de adequao do pessoal ao modelo, assim como as competncias especficas, cujos detalhes surgiro dos processos que devem seguir os papis. Por enquanto, Marcela se conforma com uma descrio do que procura em cada atividade que faz parte da cadeia de valor que atendida pelo cargo, o que constitui contedo suficiente para suas buscas tcnicas. Por exemplo, para o cargo de Engenheiro de Testes, no processo de Design da Estratgia de Testes, o propsito encontrar a melhor estratgia possvel para a produtividade dos testes. Um Engenheiro de Testes deve ser capaz de interpretar o Plano de Testes de Software e escolher uma estratgia para os testes, baseada nos objetivos de negcios e nos riscos. Quando participa da Anlise de Requisitos, espera -se que seja capaz de encontrar uma alta porcentagem de no conformidades e incompletudes, o que consegue ao revisar e testar
Capitulo 7
Pgina 88
Boria et al.
documentos de requisitos, com tcnicas como Grficos de Causa e Efeito. Utiliza estas tcnicas de gerao sistemtica de testes para identificar requisitos omissos ou divergentes. Estes so os elementos tcnicos que serviro para a seleo, as entrevistas e os exames de aptido dos candidatos. Armada com estas definies, Marcela comea a procurar pessoal para ocupar oito cargos de engenheiro de software e cinco de engenheiros de testes, destes ltimos pelo menos um deles dever ter experincia em documentao de software. Buscando no mercado, as etapas de divulgao da oportunidade, os filtros iniciais das respostas, das comunicaes, das entrevistas, da preparao de ofertas e da contratao tiveram como resultado uma demora de vrias semanas. Marcela volta a reunir os scios, para propor uma atitude pr-ativa na busca. Usando os nmeros de suas buscas e dados do estudo de busca de pessoal que a auxilia, adverte sobre as demoras que se apresentam na contratao e do risco de no contarem com o pessoal necessrio no comeo de um projeto, o que impedir atingirem os objetivos e cumprirem com os compromissos com os clientes. Prope uma atividade de mitigao que consiste em gerar uma base de dados dos candidatos. Seu mecanismo ser o seguinte: uma vez por ms os scios se reuniro para rever o portflio de projetos e fazer ajustes no plano estratgico. Nessa reunio sero estabelecidos os potenciais cargos a cobrir. Com esse fundamento, Marcela estabelecer um plano ttico de contrataes. Marcela apresenta a tabela (Tabela 7.1) com as atividades do processo de recrutamento e incorporao de pessoal. Alm disso, como dados de ajuste, Marcela tem duas tabelas, uma para desenvolvedores e outra para pessoal de testes, que medem a porcentagem de respostas positivas a um evento (por exemplo, quantas buscas de currculo em uma base de dados de pessoal do resultados positivos para cada tipo de cargo) e o tempo de demora de cada atividade. Como exemplo, Marcela apresenta uma tabela com as respostas positivas porcentuais em cada evento significativo, para cada uma de muitas posies relacionadas com o desenvolvimento, que conseguiu na agncia que a ajuda em suas buscas (Tabela 7.2). Desse modo, pode calcular quantas instncias de cada atividade precisa realizar em cada caso e com que antecipao. Vendo os dados da tabela para o pessoal de testes pode-se deduzir que preciso realizar seis ofertas (5,6 para ser preciso) para obter cinco aceitaes, o que exige que sejam feitas 5,7 entrevistas tcnicas, 6,4 entrevistas funcionais, que sejam enviados a 12,9 candidatos selecionados entre 143,2 currculos da base de dados. Se as oportunidades no se concretizam, a busca pode ser igualmente til se surgirem outras novas necessidades ou se simplesmente se esfria at que aparea algo. O preo que se paga menor do que o de adiamentos. Atividade 1 2 3 4 5 6 7 8 9 10 11 12 Filtrar os candidatos da BD Escolher entre os filtrados Agendar entrevistas funcionais Realizar entrevistas funcionais Agendar entrevistas tcnicas Realizar entrevistas tcnicas Realizar oferta inicial Obter aprovao Realizar oferta final Contratar Introduzir o conhecimento da empresa Capacitar no papel
Tabela 7.1: Atividades de Recrutamento e Incorporao de Pessoal
Deste modo, Marcela tem um processo de incorporao de pessoal e um sistema de medio que permitem antecipar o tempo e o esforo do recrutamento. Isto permite atender as previses para a seleo, agora falta eliminar os riscos no processo de incorporao, que se sintetizam no atraso dos projetos porque demora muito para levar o pessoal incorporado a um
Capitulo 7
Pgina 89
Boria et al.
nvel de rendimento aceitvel dado o excesso de treinamento exigido para incorporar os novos colaboradores s equipes.
Tabela 7.2: Porcentagem de xito em Atividades Selecionadas por Tipo de Cargo
Em primeiro lugar, Marcela prope reforar a estrutura e o papel de sua Gerncia de Recursos 2 Humanos. Aqui esto seus argumentos, novamente analisados como riscos para a T : Desenvolvimento de Recursos Humanos risco: se crescermos sem previso de recursos humanos vamos ter muito atraso para incorporar pessoal e nem sempre poderemos responder demanda dados nossos processos especficos, provvel que o perodo de aprendizado e 2 ajuste s necessidades da T seja muito longo para nossos negcios. mitigao: estudar as necessidades estratgicas da organizao e prever as necessidades de recursos, antecipando-nos a elas identificar os candidatos a ocupar postos e desenvolver relaes para recrut-los identificar as necessidades estratgicas de capacitao de pessoal gerar um plano de longo prazo para atender as necessidades de capacitao implementar as partes principais do plano no curto e mdio prazos possuir registros claros dos treinamentos realizados provvel que haja treinamentos que no tenham o valor esperado e que o investimento seja perdido se quisermos ser proativos na melhoria de desempenho, devemos entender como avali-lo e melhor-lo constantemente ou corremos o risco de investir no que no tem retorno se desperdiarmos o conhecimento deveremos recri-lo periodicamente, a um custo muito alto avaliar se os treinamentos cumprem com seu propsito definir mtodos objetivos de medir desempenho e utiliz-los para melhorar o rendimento do pessoal e identificar oportunidades de melhorias ter uma estratgia para gerar, captar, difundir e aproveitar o conhecimento formar grupos de interesse em cada disciplina e apoi-los estabelecer meios de difundir e compartilhar conhecimento e habilidades entre pares
Tabela 7.3: Riscos da T Derivados de Polticas Pobres em Recursos Humanos
2
Felizmente vrias atividades j esto sendo realizadas. Por exemplo, o mtodo adotado para rever o portflio de projetos, agora, inclui estudar as necessidades estratgicas da organizao e prever as necessidades de recursos, o que Marcela prope aprofundar ainda mais utilizando as ferramentas de um modelo de competncias. Da mesma forma, o modelo de competncias,
Capitulo 7
Pgina 90
Boria et al.
junto com o processo de recrutamento, vai ajudar na identificao dos candidatos a ocupar postos e desenvolver relaes para recrut-los. Marcela se prope a contratar um profissional da rea de recursos humanos que tenha conhecimentos de modelos de competncias e design instrucional, uma combinao no frequente, mas tampouco extravagante. Juntando isto com a anlise mensal do portflio, possvel identificar as necessidades estratgicas de capacitao de pessoal e, desse modo, gerar um plano de longo prazo para atender s necessidades de capacitao e implementar as partes principais do plano no curto e mdio prazo, como plano ttico. Certamente, ser preciso estabelecer registros explcitos dos treinamentos realizados e avaliar se eles atendem a seus objetivos. Nesse sentido, o modelo de competncias adotado permite, ou dever permitir, a definio de mtodos objetivos para medir o desempenho e utiliz-los para melhorar o rendimento do pessoal e identificar oportunidades de melhorias. Medir esse desempenho, antes e depois do treinamento realizado, permite relacionar a melhoria de desempenho capacitao. Como Marcela tem em mente um modelo de pessoal que chega aos custos individuais (o custo derivado do salrio incluindo encargos sociais e os custos de manter o cargo em funcionamento, como eletricidade, licenas de software e hardware, amortizao dos metros quadrados ocupados, etc.) e desempenho individual (a receita que pode ser relacionada ao desempenho da pessoa no cargo), possvel atribuir um valor monetrio diferena de produtividade, que pode ser medido com relao ao custo da capacitao. possvel, da mesma forma, fazer anlises do perodo de reembolso, o valor da capacitao e outras anlises financeiras. A ponto de receber o ttulo de Mestre em Administrao, Marcela confia que as anlises financeiras aplicadas a todo tipo de investimentos rendero benefcios na hora de tomar decises. Apesar de que isto possa parecer uma forma de matar mosquitos com canhes, uma pauta cultural necessria para tomar decises baseadas em dados e no em sensaes. Nas palavras de D. Edwards Deming, In God we trust, all the others bring data 66 (Em Deus confiamos, os demais tragam dados) . Para mostrar que um modelo de competncias possvel, Marcela oferece um exemplo parcialmente completo para o cargo de gerente de contas, que foi enviado por Mximo. Na verso utilizada, cada passo crtico do processo de vendas de um projeto novo listado na primeira coluna. Depois h cinco colunas representando o grau de competncia do gerente de contas, do leigo ao especialista. Debaixo de cada grau h uma descrio do q ue se entende por esse grau (Tabela 7.4). Da mesma forma, a Tabela 7.5 mostra a lista de avaliao correspondente primeira tarefa. Desse modo, possvel relacionar o rendimento com os indivduos e medir o resultado da capacitao como a diferena de produtividade antes e depois do evento.
COMPETNCIA POR NVEIS DE UM GERENTE DE CONTAS COMPETNCA Fase Tarefa Apoio Venda Participa da reunio inicial No tem ideia sobre o que se espera dele ou dela Faz anotaes e perguntas relacionadas Faz anotaes, perguntas relacionadas e esclarecimentos Faz anotaes, perguntas relacionadas e esclarecimentos bem como participa nas discusses Conduz e facilita a atividade 1 Leigo 2 Principiante 3 Jnior 4 Snior 5 Especialista
66
Na verdade, no h confirmao de que tenha sido Deming que disse isto, mas parte do mito que o acompanha. Ver http://en.wikipedia.org/wiki/W._Edwards_Deming
Capitulo 7
Pgina 91
Boria et al.
Realiza a apresentao do mtodo de desenvolvi2 mento da T
No conhece o material e no capaz de apresentlo No sabe como se comportar frente s mudanas no projeto
Ajuda na explicao sobre o uso dos materiais no exerccio
Apresenta o material com mnimos problemas e conduz os exerccios Avalia mudanas medindo seu impacto em custo e tempo de entrega e gerencia as prprias mudanas
Prepara a apresentao, apresenta o material sem problemas e conduz os exerccios Mantm a integridade da proposta sem se confrontar com o cliente e assegura que as mudanas de impacto se refletem no escopo da proposta
Prepara a apresenta o, apresenta muito bem o material e conduz os exerccios Coordena as mudanas com todos os interessados e equilibra os interesses coletivos para chegar ao ganhaganha
Realiza ajustes proposta frente ao cliente ante pedidos expressos de mudana
Tenta seguir o processo de controle de mudanas, mas se perde e no consegue resultados
Tabela 7.4: Primeira Parte de um Modelo de Competncias
LISTA DE AVALIAO
Fase de Apoio Venda Tarefa

Anota Faz perguntas adequadas para que todos entendam melhor a discusso Participa e facilita a reunio capaz de sintetizar os resultados alcanados
Participa da reunio inicial
Quase Nunca (0% - 10%) Muito Pouco (1% - 33%) Com frequncia (34% - 66%) Quase Sempre (67% - 95%) Sistematicamente (96% - 100%) Tabela 7.5: Lista de Avaliao Correspondente Primeira Tarefa
Marcela implementa as aes e liga para Mximo para revisar sua pertinncia. Mximo mostrase satisfeito com os progressos conseguidos e sugere que as prticas sejam avaliadas em comparao com os resultados do modelo MR-MPS-SW, desta vez com o processo Gerncia de Recursos Humanos: Gerncia de Recursos Humanos (GRH)
GRH1 As necessidades estratgicas da organizao e dos projetos so revistas para identificar recursos, conhecimentos e habilidades requeridos e, de acordo com a necessidade, planejar como desenvolv-los ou contrat-los; indivduos com as habilidades e competncias requeridas so identificados e recrutados; As necessidades de treinamento que so responsabilidade da organizao so identificadas;
GRH2 GRH3
Capitulo 7
Pgina 92
Boria et al.
GRH4 GRH5 GRH6 GRH7 GRH8
GRH9 GRH10 GRH11
Uma estratgia de treinamento definida, com o objetivo de atender s necessidades de treinamento dos projetos e da organizao; Um plano ttico de treinamento definido, com o objetivo de implementar a estratgia de treinamento; Os treinamentos identificados como responsabilidade da organizao so conduzidos e registrados; A efetividade do treinamento avaliada; Critrios objetivos para avaliao do desempenho de grupos e indivduos so definidos e monitorados para prover informaes sobre este desempenho e melhor-lo; Uma estratgia apropriada de gerncia de conhecimento planejada, estabelecida e mantida para compartilhar informaes na organizao; Uma rede de especialistas na organizao estabelecida e um mecanismo de apoio troca de informaes entre os especialistas e os projetos implementada; O conhecimento disponibilizado e compartilhado na organizao. Tabela 7.6: Processo GERNCIA DE RECURSOS HUMANOS [SOFTEX, 2012a]
Mximo est contente, seus afilhados esto ficando melhores do que o professor. O QUE ACONTECEU AT AGORA 38. Tahini-Tahini chega ao nvel F do modelo MPS-SW. 39. Marcela e os gmeos analisam as causas-raiz das dificuldades para contratar pessoal idneo e faz-los render no curto prazo. 40. Marcela e os gmeos comeam a construo de um modelo de competncias para Tahini-Tahini. 41. Marcela prope um mecanismo de seleo proativo para a contratao de pessoal. 42. Mximo revisa e aprova a implementao escolhida para o processo Gerncia de Recursos Humanos. 7.3 A Necessidade de Ativos de Processo Ao fazer a anlise das necessidades de capacitao, frequente descobrir que esto faltando alguns dos recursos necessrios para ajudar o pessoal na realizao de suas tarefas: planos, ferramentas de software, diretrizes de apoio, formulrios tipo, padres de trabalho, evidncia histrica e numrica do desempenho dos processos, materiais de treinamento e de apoio aos usurios dos prprios produtos, entre outros. Todos estes auxiliam nas decises e facilitam a realizao das tarefas cotidianas. Sua ausncia representa um mal investimento, pois o conhecimento no capturado deve ser reproduzido, com os consequentes riscos, ou compartilhado pelos que j possuem, com as consequentes demoras. A capacitao centralizada s uma parte da soluo: a organizao que aprende, faz isso constantemente, por desgnio de sua estrutura. preciso criar uma estratgia para gerar, captar, difundir e aproveitar o conhecimento em cada um dos papis e funes da organizao, uma corrente de grupos de interesse em cada disciplina e apoi-la com mltiplos meios de difuso e compartilhar conhecimento e habilidades entre pares, como blogs internos, fruns internos, webs para armazenar conhecimento, reforo das atitudes de compartilhar com os que sabem menos, etc. Marcela escolhe uma ferramenta de gesto de conhecimento entre vrias 67 opes e, com a ajuda de Armando, a implementam na organizao. De imediato, produzida uma corrente de interesse que comea a gerar artefatos que, pouco a pouco, vo 2 sendo agregados queles ativos que j descrevemos, armazenados na rede interna da T . Com o crescimento organizacional, uma empresa que alcanou isto por estar relativamente bem organizada, pode descobrir que, na realidade, essa evoluo a fez retroceder, empurrada pelo influxo de pessoal novo e a multiplicao do nmero de projetos, at parar em um mundo de processos caticos. A soluo simples, mas demanda organizao para que possa ser aplicada e ter pacincia para que, com o tempo, d seus frutos: trata-se de definir processos organizacionais adaptveis, adotveis e com ativos fceis de usar, mesmo quando os
67
http://bsix12.com/knowledge-sharing-tools/ um bom ponto para comear a busca.
Capitulo 7
Pgina 93
Boria et al.
processos devem ser detalhados para que sua utilizao (ou a falta dela) possa ser facilmente avaliada em cada projeto individual, segundo suas caractersticas. Um processo muito flexvel no um processo avalivel. J vimos no Captulo 5 quais atributos descrevem um processo, com a planilha que introduziu Mximo. Sem trocar essa estrutura, o que se pede que os passos para a sua execuo sejam muito concretos e que seja possvel avaliar o seu seguimento ou no. Marcela comea a construir uma arquitetura para organizar os ativos que vo sendo gerados, assim como a construir aqueles que no s lhe deem estrutura aos que surgem espontaneamente das equipes de projetos, mas sobretudo incorporando outros que inspirem a continuar crescendo. Por exemplo, ela est segura de que Kanban e Scrum no sero as nicas fontes de inspirao para a gesto de projetos, por isso decide que em sua biblioteca 2 de processos sempre haver lugar para definir ciclos de vida em uso na T e torn-los adaptveis aos processos. Em especial, est pensando em algumas ideias que discute com Ana, que continua trabalhando de sua casa, desde as ltimas semanas de sua gravidez, 68 enquanto cuida do recm-nascido, e que tm a ver com Feature Driven Development . Por causa da sua experincia com o recrutamento de novos colaboradores e os objetivos fixados para controlar o desempenho, sobretudo como medida da efetividade dos treinamentos, Marcela est segura da utilidade de manter um repositrio de dados de desempenho dos processos. A planilha de definio de processos j incorpora medidas, mas Marcela vai acrescentando indicadores de desempenho, individuais e por equipes, que servem para tomar decises no momento de fazer ofertas de trabalho com conhecimento da capacidade para realiz-lo. Para evitar que as medies no tenham nenhum sentido, Marcela prope que somente sob excees justificadas e aprovadas pela direo (da qual parte) podem ser utilizados procedimentos que no tenham sido sancionados previamente. Desse 69 modo, e como os processos so avaliveis em relao a seu seguimento , os resultados podem ser comparados. Se os caminhos para executar os processos fossem individuais, a comparao de resultados no seria possvel. A aprovao de um processo, segundo pensa Marcela, efetivada pela publicao na Biblioteca de Ativos de Processos, BiPro como chamada, na intranet. Como parte das medidas para acelerar o rendimento do pessoal recentemente incorporado, Marcela detectou que necessrio definir padres dos ambientes de trabalho, pois a compra de novos equipamentos e licenas no um assunto to imediato quanto gostaria. Para poder conseguir bons preos no mercado necessrio contar com certa antecipao para a compra. Por outro lado, a experincia mostra que a incorporao de pessoal com experincia em outros tipos de projetos geis difcil, por isso, receber um padro de capacitao bastante til. Marcela opta por um mecanismo que faz a incorporao menos traumtica: cada novo colaborador, de agora em diante, contar com o apoio de outro, j experiente, que o ajudar em seus primeiros 2 passos: cada um dos cinco primeiros dias na T esto pautados na Diretriz de Incorporaes, a apresentao direo, o percurso das instalaes, o uso da BiPro, os cursos online e o ambiente de trabalho. A BiPro contm muitos elementos. Marcela foi acumulando experincias prprias e alheias, filtrando os melhores ativos da ferramenta de gesto de conhecimento e a lista do contedo longa: em princpio contm o Plano Organizacional de Melhoria de Processos, que discutiremos em detalhe na seo a seguir. Este plano permite a qualquer um que esteja interessado em conhecer as necessidades de melhorias de processos que foram reconhecidas pela organizao e como esta se prope a atende-las, identificando as estratgias, enfoques e aes para realizar melhorias de processos. No nvel mais alto, h uma descrio da arquitetura dos processos organizacionais, que se 2 baseia no Processo Padro da T , com sua Diretriz de Adaptao para seu uso nos projetos. Marcela j incorporou algumas Polticas Organizacionais, para comunicar os princpios que guiam a organizao, e Descries Organizacionais de Ciclos de Vida, que permitem guiar a determinao das principais fases de um projeto ou produto sobre as quais possvel determinar o escopo do planejamento.
68 69
Ver Captulo 3 Ver no Captulo 6 Garantia da Qualidade
Capitulo 7
Pgina 94
Boria et al.
Tambm h um Exemplo do Plano de Projeto, que ilustra o nvel adequado das estimativas, definio de papis e outros atributos crticos relacionados ao planejamento de um projeto, e Definies Operacionais de Medidas para fornecer descries precisas e inequvocas dos atributos das entidades que podem ser teis medir em um processo. Para auxiliar na padronizao dos processos, h planilhas e diretrizes de uso, como as Planilhas para Procedimentos e Critrios de Testes de Validao e Verificao, e Normas de Desenvolvimento de Produto. Em geral, h claras definies das expectativas da organizao para processos, ferramentas, tcnicas e mtodos a serem usados no ambiente de desenvolvimento. H tambm outras diretrizes particulares, como as Diretrizes de Anlise de Deciso para guiar a seleo de temas que devem ser submetidos a avaliaes formais. Ilustrar vrios atributos que deveriam ser considerados na avaliao do design de componentes de produto. Existem, da mesma forma, materiais para ajudar na seleo e uso de tcnicas e ferramentas, como os Exemplos de Tcnicas de Levantamento de Requisitos para fornecer apoio com exemplos de tcnicas para a coleta de necessidades, expectativas, restries e interfaces dos interessados, o mesmo com a planilha para especificaes de requisitos que ajuda a comunicar efetivamente os compromissos e produtos do projeto a todos os interessados mais relevantes. H outros, mas, como exemplo, estes so suficientes. O critrio que se til para algum, pode ser guardado para ser acessado e o conhecimento, reusado. Cada elemento tem seu guia de uso e os critrios associados para sua escolha diante de vrias alternativas. Como algo to diverso e amplo difcil de utilizar, uma parte corresponde aos ativos recomendados necessrios para o uso cotidiano, mas a BiPro tem capacidades de wiki autoorganizada baseada em um algoritmo de redes neurais para reuso do conhecimento desenvolvido por um dos novos programadores em seu trabalho de graduao. Desenvolvidos, 70 inicialmente, para o reuso de software , os wikis semnticos, como so chamados, simplificam o armazenamento da informao ao utilizar algoritmos que relacionam os contedos de maneira automtica, incrementando a sua usabilidade. Um problema conhecido dos wikis que, no incio, quando h pouco contedo, a usabilidade muito alta. Ao aumentar o contedo, a usabilidade diminui rapidamente. Por isso, o uso de auto-organizao diminui o esforo e 2 permite que uma empresa pequena como a T possa armazenar, com facilidade, o aprendizado gerado a partir da ferramenta de gesto do conhecimento. Marcela mantm um indicador de uso dos elementos da BiPro. Pelas ferramentas de apoio escolhidas, sempre mais fcil acessar o documento ou conhecimento na biblioteca do que guardar cpias em pastas locais e acess-las quando forem usadas. Isto faz com que as estatsticas de uso sejam representativas da realidade. Utilizando estes dados, Marcela vai entendendo que h perfis de projetos, embora s vezes haja perfis de sprints. Decidida a entender, armam com Ana um grupo de trabalho que inclui Mariano e os gmeos, e comeam um trabalho de detetive, juntando dados dos atributos dos sprints e correlacionando estes dados com o uso de certos elementos na prtica. Analisando estes dados, chegam s seguintes concluses, que publicam na BiPro para sua difuso e uso.
Orientao Sugerida por Perfil de Sprint condio escolha sugerida
o tamanho da funcionalidade excede a capacidade do sprint a funcionalidade nova e tem muitas arestas inexploradas a funcionalidade totalmente central ao funcionamento do produto (controle) o dono do produto tem dvidas sobre a funcionalidade que sugere
Kanban com uma mini equipe dedicada mini espiral de Bohm dentro do sprint ou dividir o sprint a partir de uma anlise para fazer demos mais frequentes. usar TDD e inspees, alm de programao por pares. ampliar o jogo do planejamento at incluir um esboo de modelo dinmico usando tcnicas de UML e FDD diminuir a durao do sprint para fazer demos mais
70
DECKER, B., et al, 2005.
Capitulo 7
Pgina 95
Boria et al.
frequentes a equipe no tem experincia a arquitetura crucial para o desempenho futuro do produto usar inspees e programao por pares com o scrum master em um dos papis usar um sprint para definir a arquitetura, maneira do FDD, e decidir depois sobre Kanban, Scrum ou Scrumban
2
Tabela 7.7: Orientao Sugerida por Perfil de Sprint
Quatro semanas depois de contar com a presena do consultor no escritrio da T , volta-se a ligar para Mximo para a reviso do processo Definio do Processo Organizacional, com resultados perfeitos. Definio do Processo Organizacional (DFP)
DFP1 DFP2 DFP3
DFP4 DFP5 DFP6 DFP7 DFP8
Um conjunto definido de processos padro estabelecido e mantido, em conjunto com a indicao da aplicabilidade de cada processo; Uma biblioteca de ativos de processo organizacional estabelecida e mantida; Tarefas, atividades, papis e produtos de trabalho associados aos processos padro so identificados e detalhados, juntamente com o desempenho esperado do processo; As descries dos modelos de ciclo de vida a serem utilizados nos projetos da organizao so estabelecidas e mantidas; Uma estratgia para adaptao do processo padro desenvolvida considerando as necessidades dos projetos; O repositrio de medidas da organizao estabelecido e mantido; Os ambientes padro de trabalho da organizao so estabelecidos e mantidos; Regras e diretrizes para a estruturao, formao e atuao de equipes so estabelecidas e mantidas.
Tabela 7.8: Processo DEFINIO DO PROCESSO ORGANIZACIONAL [SOFTEX, 2012a]
O QUE ACONTECEU AT AGORA 43. Marcela incorpora uma ferramenta para compartilhar conhecimento entre os membros da Tahini-Tahini. 44. Marcela define uma arquitetura para organizar os ativos de processo. 45. Marcela define indicadores a partir de uma base de dados de desempenho dos processos que permitem melhorar o conhecimento da capacidade individual e das equipes. 46. Marcela define padres dos ambientes de trabalho. 47. Marcela define um processo e ativos para a incorporao de pessoal novo s equipes. 48. Marcela conecta a ferramenta de gesto do conhecimento biblioteca de ativos de processo, utilizando um algoritmo que permite auto-organizar os contedos. 49. Um workshop interno identifica correlaes entre usos de ativos da biblioteca e atributos dos projetos e produtos a construir e gera uma diretriz de uso. 50. Mximo revisa os processos e ativos de Definio do Processo Organizacional e os aprova. 7.4 Retrospectivas e processos Assim como o crescimento do pessoal e a multiplicao dos projetos pode, como j foi dito, acabar em um mundo de processos caticos, a acelerao da mudana pode levar a confundir mudanas de processos com melhoria de processos, perdendo tempo e dinheiro. Marcela tem
Capitulo 7
Pgina 96
Boria et al.
um esprito prtico com formao contbil e de sistemas, uma combinao que a faz ser muito esperta. Para evitar que os esforos na rea de processos sejam dispersos adotou uma 2 estratgia que lhe permite entender e documentar os objetivos estratgicos de processo da T , o que acontece durante as reunies mensais de reviso do portflio. A reviso permanente desses objetivos feita a partir do sistema de medio da capacidade dos processos que Marcela coloca em prtica. Com estes dados, Marcela mantm seu plano de melhoria baseado na medio da capacidade e dos objetivos estratgicos de negcio. O plano parte de atividades que realizam os projetos, em particular as autoavaliaes que so realizadas ao final de cada sprint, chamadas 71 retrospectivas , onde so discutidas tanto novas necessidades quanto as melhorias j realizadas, para selecionar e adotar melhorias aprovadas e que sero difundidas e implantadas nos outros projetos. Este mais um dos planos de projeto e seu avano discutido nas reunies mensais, pois os planos de projeto tm os mesmos atributos e a mesma necessidade de monitoramento e controle. A diferena com os projetos de desenvolvimento que, para cada iniciativa, escolhido o grupo de especialistas que ir participar na confeco dos ativos, sejam estes processos, procedimentos ou diretrizes, ou todos os anteriores, e definida a sua dedicao, geralmente de tempo parcial. Marcela conduz estes grupos, no mximo dois por ms, seguindo seu prprio painel kanban e com reunies semanais. Uma boa prtica que foi adotada a de fazer com que todos os especialistas trabalhem ao mesmo tempo no mesmo dia da semana, para obter resultados mais rpidos e assegurar sua participao. A designao por mltiplos de 10% de dedicao semanal, de modo que se considerarmos a semana de quarenta horas, cada mltiplo de meio dia (um turno). Desse modo, possvel controlar os compromissos com o projeto. A inclinao de Marcela pelos nmeros a leva a ser sistemtica ao medir os resultados obtidos comparando com os resultados esperados do plano de melhorias, que documenta em cada caso e apresenta nas reunies mensais de reviso do portflio. O planejamento estrito no impede que incorpore melhorias oportunas quando existam, como as ideias que Ana traz de suas aulas. Marcela revisa por sua conta os resultados do processo Avaliao e Melhoria do Processo Organizacional e, satisfeita com os resultados, envia um relatrio Gerncia Geral recomendando comear os preparativos para uma avaliao de nvel E do MR-MPS-SW. Avaliao e Melhoria do Processo Organizacional (AMP)
AMP1 AMP2 AMP3 AMP4 AMP5 AMP6
AMP7 AMP8 AMP9 AMP10
A descrio das necessidades e os objetivos dos processos da organizao so estabelecidos e mantidos; As informaes e os dados relacionados ao uso dos processos padro para projetos especficos existem e so mantidos; Avaliaes dos processos padro de organizao so realizadas para identificar seus pontos fortes, pontos fracos e oportunidades de melhoria; Registros das avaliaes realizadas so mantidos acessveis; Os objetivos de melhoria dos processos so identificados e priorizados; Um plano de implementao de melhorias nos processos definido e executado, e os efeitos desta implementao so monitorados e confirmados com base nos objetivos de melhoria; Ativos de processo organizacional so implantados na organizao; Os processos padro da organizao so utilizados em projetos a serem iniciados e, se pertinente, em projetos em andamento; A implementao dos processos padro da organizao e o uso dos ativos de processo organizacional nos projetos so monitorados; Experincias relacionadas aos processos so incorporados aos ativos de processo organizacional.
Tabela 7.9: Processo AVALIAO E MELHORIA DO PROCESSO ORGANIZACIONAL [SOFTEX, 2012a]

71
Ver Captulo 3
Capitulo 7
Pgina 97
Boria et al.
O QUE ACONTECEU AT AGORA 51. Marcela define um plano de melhoria contnua de processos baseado nos objetivos organizacionais de negcios e na capacidade real dos processos. 52. Marcela revisa por sua conta os resultados do processo Avaliao e Melhoria de Processos Organizacionais 7.5 Diminuio de custos por reuso de componentes Mas antes de alcanar o nvel E, a T deve atender alguns outros processos. Apesar dos esforos de contratao de pessoal, organizao e difuso de conhecimento e processos que aceleram as atividades, as equipes ficam aqum da produtividade exigida. Ana, j reincorporada parcialmente (participa de todas as reunies de direo e quando convidada a revisar artefatos em conjunto com a equipe) mostra que, como j est sendo usado o algoritmo que um de seus alunos aplicou no trabalho de graduao para a auto-organizao do conhecimento nos wikis, este mesmo algoritmo poderia ser usado para encontrar os componentes teis na biblioteca dos projetos. O que ela sugere implementar uma estratgia de reuso que contemple critrios claros para a seleo dos componentes, com mecanismos de armazenamento e uso dos ativos, alm de procedimentos para que sejam atualizados permanentemente com usurios claramente identificados do sistema, para comunic-los sobre mudanas e melhorias. Os procedimentos precisam atender tanto os aspectos tcnicos quanto os administrativos. Entende-se como artefato ativo reutilizvel qualquer software que seja preparado, quer dizer, que seja empacotado expressamente para ser reutilizado pelos processos da organizao. Isto sugere que existam alguns critrios especiais para sua construo e teste. A primeira considerao o ajuste arquitetnico. Os componentes se agrupam por tecnologia e interfaces, e sua verso atualizada constantemente. As APIs so publicadas em um relatrio, que indexado para ser utilizado mais adiante. Isto evita que seja necessrio fazer um processo manual de busca, porque os filtros so automticos, o que coloca disposio da equipe um conjunto de oportunidades para explorar justo quando esto buscando alternativas para integrar seu plano do sprint. Outros critrios fundamentais so: o custo versus o benefcio de reutilizar; a adequao ao plano e ao design do produto; se ou no um produto herdado; e outros critrios que podem ser dependentes do projeto em si. Como os projetos so geis, a equipe que decide os critrios. Decide-se que os projetos incorporem a seu procedimento de planejamento, no momento de estabelecer o Backlog do sprint, uma anlise de opes que siga os passos do processo de reuso. Brevemente, os passos so os seguintes: 1. Identificao de objetivos, isto , os motivos pelos quais se busca reutilizar componentes. Alguns exemplos so diminuir prazos sem perda de qualidade, permitir manter a durao do sprint desenvolvendo mais pontos de usurio, diminuir custos, etc. 2. Escolha de atributos desejveis, onde a equipe discute se vale a pena, ou no, seguir o processo de reuso, a partir dos requisitos, do design a adotar ou pr-existente, da histria com reuso da equipe, do volume de trabalho no sprint, e/ou qualquer outro adequado ao projeto. 3. Identificao de candidatos, que se realiza automaticamente usando o algoritmo neural baseado nos atributos escolhidos. 4. Avaliao de candidatos, realizada por testes ad-hoc, que so projetados de acordo com os atributos escolhidos e a histria do componente. 5. Anlise de opes, realizada seguindo um mtodo pr-estabelecido que utiliza uma matriz de Pugh como a que se viu no Captulo 4. Uma das opes sempre no reutilizar um componente. 6. Seleo de alternativas, tambm seguindo o mtodo anterior. 7. Adoo de componentes, quando aplicado, realizado o ajuste do componente, de acordo com as necessidades da equipe. Pode ser que, chegando neste ponto, o resultado da avaliao d alternativas com resultado negativo e se decida no usar nenhum componente.
2
Capitulo 7
Pgina 98
Boria et al.
8. Avaliao do resultado, na qual compara-se o resultado com os objetivos identificados no primeiro passo para continuar montando a histria do componente e acrescentando os conhecimentos adquiridos.
Figura 7.2: Anlise de Opes sobre Reuso
Da mesma forma, para que um componente possa integrar a biblioteca de ativos de reuso, preciso que, primeiro, seja proposto como tal pelos seus autores, antes mesmo de constru-lo, porque o desenvolvimento de um componente para reuso diferente do desenvolvimento normal de cdigo. Os critrios exigem que se acrescente uma documentao especial para guiar o reuso para que, no futuro, seja possvel selecionar o componente a partir de caractersticas predefinidas, assegurando: que os testes sejam exaustivos e o critrio de aceitao seja zero-defeitos; que o design e a arquitetura, ou arquiteturas com as quais o componente interage normalmente tambm formem parte dessa documentao; e que esta seja inspecionada formalmente. Alm disso, h um critrio especial para a anlise esttica do 72 73 cdigo, que requer seguir normas organizacionais , como a identao , os comentrios, os nomes de variveis e a documentao de mudanas no cdigo. A biblioteca de componentes para reuso tem seu prprio mecanismo de gerncia de configurao e sua prpria rastreabilidade entre ativos, que simplesmente um subconjunto com restries maiores do que as usuais do sistema de gerncia de configurao organizacional para baselines. Os usurios deste subsistema recebem os relatrios sobre os ativos gerenciados desta forma. O QUE ACONTECEU AT AGORA 53. Ana sugere introduzir reuso de componentes para aumentar a capacidade das equipes. 54. definido e realizado um processo de criao, adoo e manuteno de componentes de reuso com um procedimento para decidir quando deve ser reutilizado um componente e se estende a diretriz de ajuste do processo para que contenha este critrio.
Gerncia de Reutilizao (GRU)

GRU1
GRU2 GRU3 GRU4 GRU5
Uma estratgia de gerenciamento de ativos documentada, contemplando a definio de ativo reutilizvel, alm dos critrios para aceitao, certificao, classificao, descontinuidade e avaliao de ativos reutilizveis; Um mecanismo de armazenamento e recuperao de ativos reutilizveis implantado; Os dados de utilizao dos ativos reutilizveis so registrados; Os ativos reutilizveis so periodicamente mantidos, segundo os critrios definidos, e suas modificaes so controladas ao longo do seu ciclo de vida; Os usurios de ativos reutilizveis so notificados sobre problemas detectados, modificaes realizadas, novas verses disponibilizadas e descontinuidade de ativos.
Tabela 7.10: Processo GERNCIA DE REUTILIZAO [SOFTEX, 2012a]
7.6 Utilizando o conhecimento histrico nos projetos A partir do nvel E, alguns resultados esperados dos processos evoluem e novos resultados so incorporados. A gerncia de projetos deve, agora, ser realizada a partir de um processo especialmente definido para o projeto e selecionado com base em ativos da organizao. Este processo deve contemplar todos os elementos constitutivos do projeto, desde a construo de planos integrados at o seu encerramento. Marcela tem conscincia das vantagens que trazem
72
Nos mtodos geis, as equipes escolhem as normas que utilizaro, mas ao incluir um componente na biblioteca de componentes para reuso, necessrio seguir normas da organizao. 73 Algo conseguido facilmente com ferramentas de Pretty Printing.
Capitulo 7
Pgina 99
Boria et al.
estas mudanas, mas seu esprito prtico a obriga colocar um marco firme nas necessidades 2 da T . Algumas diferenas entre a maneira de interpretar e, portanto, de executar certos procedimentos fazem com que Marcela precise reforar firmemente sua mensagem de uniformidade na execuo. Seu argumento que sem uniformidade no h clareza na interpretao dos resultados e a capacidade real no pode ser conhecida. Da mesma forma, sustenta que a qualidade vem da previsibilidade. Sua tese baseia-se em que qualidade no nem subjetiva, nem objetiva, um atributo da relao entre um objeto e o sujeito que avalia a 74 qualidade . No existe qualidade absoluta, sempre qualidade para e em um contexto. Da 75 mesma forma, a qualidade est relacionada s expectativas dos clientes. No modelo de Kano possvel ver que h trs tipos de requisitos, que sero descritos a seguir. O primeiro deles, os requisitos Indispensveis, tambm so chamados de bsicos, porque se no forem satisfeitos, o cliente estar sumamente insatisfeito, como por exemplo, na compra de uma bicicleta que, ao ser entregue, teve suas rodas retiradas porque elas so compradas separadamente. H uma expectativa de que as bicicletas sejam vendidas com suas rodas. Mas, como o cliente percebe que so indispensveis, fornec-las no aumenta a sua satisfao. O segundo tipo, os requisitos Lineares, so os mais visveis, os mais comuns. A satisfao do cliente proporcional ao grau de sua satisfao, ou seja, quanto mais se atenda a estes requisitos, maior a satisfao do cliente e vice-versa. Por exemplo, a capacidade do porta-malas de um automvel, ou a quantidade de quilmetros que podem ser feitos sem precisar reabastecer. Com frequncia, os clientes exigem explicitamente estes requisitos. H um terceiro tipo, chamado por Kano de requisitos Atrativos, tambm chamados deleites. So aqueles que o cliente nem espera nem requer explicitamente (surpresas positivas). Atende-los leva a satisfaes excepcionais, mas se no so atendidos no h sentimento de insatisfao. Um exemplo pode ser uma cadeirinha para transportar crianas ou uma roda extra ao comprar uma bicicleta. O que se pode concluir a partir do modelo de Kano que o que se define por qualidade a percepo que o cliente tem do produto, no os atributos em si. H atributos esperados, claro, que marcam o mnimo, mas alm destes, o contexto que define se h qualidade suficiente ou no. A consistncia nas entregas uma qualidade evidente do software para o cliente. Tanto o tempo, quanto as interfaces ou a densidade de defeitos precisa ser do nvel esperado ou o cliente ficar insatisfeito. Esse o argumento de Marcela a favor da normalizao e da consistncia. Portanto, em uma reunio mensal de anlise do portflio de projetos, Marcela levanta a solicitao de discutir vrios temas relacionados. Os gmeos contribuem apontando que as equipes no aprendem de sua experincia e continua existindo muita diferena entre o tempo ideal e o real, o que traz no conformidades em cada sprint que acabam sendo significativas para o cliente. Por outro lado, apesar de existir uma norma sobre os recursos a serem utilizados pelos funcionrios, nem sempre ela seguida. Marcela intervm para afirmar que vai contratar uma pessoa para ajud-la na garantia da qualidade, de maneira permanente, e que, a partir de agora, o processo do projeto deve ser definido como parte do plano antes do projeto ser iniciado. Ana pede que sejam expressos no processo, com toda clareza, a estrutura de decises, porque viu, em suas visitas espontneas s equipes de projetos, que as responsabilidades sobre as decises podem levar a demoras se no so expressas corretamente com antecedncia. Os gmeos voltam a intervir, desta vez para criticar que as retrospectivas no so guardadas com fidelidade: as lies aprendidas so somente lies registradas que no se traduzem em experincia para os projetos porque no se usa a estrutura de palavras-chave que permite classific-las para seu uso posterior. Quando termina a reunio, Marcela, que a encarregada das minutas da reunio, sai com a lista de aes pendentes. a. utilizar o histrico dos sprints no jogo do planejamento para ter uma melhor aproximao ao esforo real
74
[PIRSIG, 1974], Zen e a arte da Manuteno de Motocicletas. Pode-se dizer que um dos ensaios mais importantes e profundos, j escritos, sobre a natureza e o significado de qualidade e, definitivamente, um calmante necessrio para as consequncias de um mundo moderno, patologicamente obcecado com a quantidade. 75 http://kanomodel.com/
Capitulo 7
Pgina 100

76
Boria et al.
b. fixar o uso do padro de recursos necessrios, nos planos do projeto, para poder comear sua proviso antecipadamente (escritrio, PC, SW, etc.) c. estabelecer normas de comportamento das equipes e fazer com que sejam respeitadas, com as variaes necessrias
d. dar s lies aprendidas e experincias o lugar importante que merecem e armazenar de forma adequada os resultados para aproveit-los em futuros projetos e. estabelecer processos padro e mecanismos de escolha entre eles, com critrios para escolher e adaptar. Marcela sorri. Muitas das aes j foram incorporadas em sua biblioteca, mas agora conta com o mandato necessrio para que sejam cumpridas. Confia que logo ser materializado o progresso alcanado em uma avaliao formal de Nvel E. Gerncia de Projetos (GPR)
GPR4
GPR8
GPR20
GPR21 GPR22
(A partir do nvel E) O planejamento e as estimativas das tarefas do projeto so feitos baseados no repositrio de estimativas e no conjunto de ativos de processo organizacional; (A partir do nvel E) Os recursos e o ambiente de trabalho necessrios para executar os projetos so planejados a partir dos ambientes padro de trabalho da organizao; (A partir do nvel E) Equipes envolvidas no projeto so estabelecidas e mantidas a partir das regras e diretrizes para estruturao, formao e atuao; (A partir do nvel E) Experincias relacionadas aos processos contribuem para os ativos de processo organizacional; (A partir do nvel E) Um processo definido para o projeto estabelecido de acordo com a estratgia para adaptao do processo da organizao.
Tabela 7.11: Processo GERNCIA DE PROJETOS (a partir do nvel E) [SOFTEX, 2012a]
O QUE ACONTECEU AT AGORA 55. Na reunio mensal de anlise de portflio de projetos, so apresentados os 2 problemas de desempenho que continuam diminuindo a capacidade da T , como pessoal sem suficiente competncia, equipes que no aproveitam a histria ou experincias anteriores, indefinio de papis nas equipes, etc. 56. Marcela fica encarregada de transformar a lista de aes em realidade, parcialmente implementadas na BiPro, mas ainda no realizadas nos projetos. 57. A T se encaminha para uma avaliao do Nvel E.
2
76
Pouco vale ter uma diretriz se no seguida!
Capitulo 7
Pgina 101
Boria et al.
CAPTULO 8 - ELIMINANDO OS DEFEITOS 8.1 Nvel D do MPS-SW Mesmo antes da publicao do resultado da avaliao do Nvel E, Marcela est agindo para fazer com que os resultados sejam os mais firmes possveis, segundo seu plano. Depois de vrias entrevistas de trabalho com potenciais colaboradores, Marcela encontra uma pessoa que possui as condies que est buscando: um passado com experincia administrativa e contbil, uma licenciatura em Psicologia Aplicada Empresa e um Diploma em Design Instrucional. Jssica, este seu nome, ter como responsabilidade completar e melhorar o 2 modelo de competncias da T e aperfeioar a base de conhecimentos e seu uso pelos colaboradores da empresa. Jssica consegue se integrar perfeitamente com a equipe de direo, sendo, como eles, jovem, entusiasmada e com muito boa formao. No demora muito para que seja convidada a fazer parte das reunies mensais da direo. 8.2 Determinando o Problema O primeiro assunto do dia nessas reunies, desde que a BiPro e a base de dados esto sendo usadas na empresa, rever os nmeros. Mariano prepara um relatrio sobre os dados de satisfao dos clientes e a correlao com componentes do produto. Isto colocado como um indicador de tendncia com os dados que so refletidos como sries temporais no grfico: Densidade de Defeitos Identificados pelo Cliente por Componente, que uma quantidade que muda ms a ms, ao se modificar o tamanho do componente e os defeitos identificados; e Porcentagem de Defeitos Identificados pelo Cliente relacionados com o componente. O primeiro indica a quantidade de defeitos introduzidos e no detectados antes de liberar o produto para o cliente e o segundo, qual dos componentes o maior responsvel pelos defeitos. A derivada da primeira srie o indicador de melhoria ou de piora, enquanto que o histograma indica onde buscar os problemas. J a srie temporal do mdulo com pior desempenho indica a magnitude. Desse modo, possvel criar a estratgia para identificar aqueles defeitos que valem a pena analisar na reunio. Se a variao desde o ms anterior muito grande, Marcela se responsabiliza pela realizao de uma anlise mais profunda da causa-raiz com participao dos especialistas no tema. Se o componente responsvel tiver muitos defeitos, possvel prever que ser refeito. A partir da anlise dos defeitos encontrados pelo cliente e do grau de satisfao correspondente, feita a iterao sobre um processo que Jssica introduziu ao grupo, 77 conhecido como a folha de Balanced Score Card (BSC) , de uso comum em empresas de porte mdio e grande. utilizada para assegurar que a organizao entenda sua misso, alinhar seus objetivos com a misso e canalizar adequadamente os recursos e as energias para atingir seus objetivos. O mtodo consiste em identificar primeiro a viso de negcios, o para onde queremos ir, para poder encontrar significados nas atividades. Depois de 2 esclarecer a viso, que no caso de um exerccio to frequente como o que realizado na T 78 simplesmente a verificao de cada oportunidade , so analisados os resultados, fixados 2 objetivos e discutidos os investimentos em diferentes categorias. A T adotou como eixos de sua anlise as categorias clssicas: Resultados Financeiros, Satisfao do Cliente, Processos Internos e Conhecimento e Crescimento do Pessoal. A Figura 8.1 resume os passos de sua construo. Para cada uma das categorias listadas so escolhidos temas que esto alinhados com a viso de negcios da empresa. Por exemplo, para que os resultados financeiros estejam alinhados com a viso de crescimento h, pelo menos, quatro coisas que podem ser feitas: aumentar as vendas com os clientes atuais, (1) vendendo-lhes novos produtos ou (2) estendendo as prestaes, (3) aumentando o portflio de clientes ou (4) subindo os preos. Por outro lado, para analisar como estas metas financeiras so traduzidas em metas com os 2 clientes, na T so usados trs temas para (1) expandir (que eles comprem mais licenas), (2) aprofundar (que nos solicitem novas prestaes) ou (3) redefinir relaes com os clientes (que
77 78
[KAPLAN e NORTON, 1996], The Balanced Scorecard: Translating Strategy into Action. A viso se expressou como Ter um crescimento sustentvel de pelo men os 15% anual com aumento das margens proporcionais ou maior a cada ano.
Capitulo 8
Pgina 102
Boria et al.
forneam melhores referncias da empresa e estas se transformem em vias de vendas). Em todo caso, trata-se sempre de aumentar a satisfao dos clientes com os produtos.
Figura 8.1: Estrutura Tpica de uma Folha de Resultados Equilibrados
evidente que se os objetivos de gesto com o cliente so cumpridos, eles tm um impacto claro nas metas financeiras, mas a anlise no termina a. A pergunta que se segue : O que precisamos fazer para que estas metas de bom relacionamento com os clientes possam ser alcanadas, do ponto de vista de modificar o que j estamos fazendo? Claramente, os processos que utilizamos impactam na nossa capacidade. As duas variveis que mais impactam nos clientes so o prazo de entrega e o nmero de defeitos que entregamos. necessrio diminuir ambos para aumentar significativamente a satisfao, a percepo do cliente. Se ao realizar aes relacionadas a estes objetivos, podemos alcan-los diminuindo tambm os custos, melhor, porque ainda se as vendas no sobem muito, ao baixar os custos, aumentam as margens. A anlise fica completa com o diagnstico do aprendizado necessrio para que os processos permitam reduzir prazos e defeitos para que os clientes tenham uma maior satisfao e para que os resultados financeiros melhorem. Como todo processo, isso requer que se ajuste de maneira constante o conjunto, porque o aprendizado, por exemplo, pode ser muito caro ou muito longo para que os resultados possam ser traduzidos em objetivos que tenham um prazo razovel. Os dados coletados permitem, tambm, realizar uma anlise objetiva dos resultados. 2 Comparando a densidade de defeitos produzida pelas equipes da T com as mdias histricas 79 2 na literatura , a direo da T est preocupada com os resultados: quer diminuir o nmero de defeitos. Um dos problemas detectados pelas retrospectivas que, apesar da BiPro, h pouca preparao tcnica. A BiPro ajuda muito quando a tarefa de gesto ou de apoio, mas as tcnicas de engenharia de software, apesar de que os engenheiros comearam a se agrupar em disciplinas, ainda so primitivas. A programao no o problema, porque a Escola de Engenharia (como tantas outras boas universidades) se encarrega muito bem de formar bons programadores, mas as disciplinas correlacionadas, como a definio e anlise de requisitos, o
79
Capers Jones, [JONES, 1986], Programming Productivity
Capitulo 8
Pgina 103
Boria et al.
design em todos os nveis e a engenharia de testes deixam muito a desejar. A falta de conhecimento nessas disciplinas notria. O QUE ACONTECEU AT AGORA 58. Jssica incorporada equipe de Marcela e introduz o BSC
80
nas reunies mensais.
59. Em uma anlise equilibrada dos defeitos, detecta-se grande densidade de defeitos no produto, o que um obstculo para o alcance dos objetivos financeiros. 60. O uso do material gerado nas retrospectivas das equipes permite identificar uma srie de problemas relacionados. 8.3 Busca da Soluo A soluo poderia ser definir um mtodo prprio e adaptado s necessidades de negcios 2 especficas da T ; mas, tanto Ana quanto Marcela so partidrias de uma resposta que lhes permita crescer em nmero de funcionrios selecionando pessoal j pr-capacitado na parte tcnica. Portanto, essa soluo descartada. Consultados, os gmeos sem nem pensar sugerem a capacitao integral em XP: programao entre pares, desenvolvimento dirigido por testes (Test driven development ou TDD), design incremental, integrao contnua, propriedade coletiva do cdigo, conhecimento compartilhado, padres de codificao, passo sustentvel e trabalho energizado, alm das prticas comuns a Scrum, como os sprint e o jogo do planejamento. Vocs podem imagin-los falando ao mesmo tempo e terminando as frases um do outro. Nessas partes onde diferem Scrum e XP, como a participao do usurio na equipe, obrigada nesta ltima e descartada em Scrum, os gmeos preferem manter as tcnicas do primeiro. Para Ana, XP uma possibilidade, mas no a nica. Prope identificar outros mtodos e compar-los, seguindo o esquema de anlise que j utilizado normalmente na empresa. Mesmo quando, a princpio, est de acordo, a esta altura de sua trajetria, parece necessrio para Marcela entender o que anda mal e o que quer corrigir antes de comear a decidir. Para isso conta com uma fonte inestimvel de experincias: a base de conhecimento construda a partir das reunies de retrospectiva. Da surgem mltiplos temas que parecem s equipes problemas ou riscos dos projetos, relacionados com suas tarefas tcnicas. Marcela convence os quatro a realizar uma anlise desses temas. Entre ela, Ana e os gmeos vo lendo os problemas detectados e copiando-os em uma folha autoadesiva. Se eles encontram dois problemas com enunciados muito parecidos colam um sobre o outro. Quando todos os problemas foram reunidos na lousa, os participantes tentam agrup-los em tipos de semelhana. Por exemplo, o enunci ado a falta de cobertura na definio de critrios nos levou a tomar decises equivocadas sobre a qualidade do produto demonstrada pela densidade de defeitos em testes agrupado com nem sempre a densidade de defeitos que calculamos est baseada em dados confiveis e ao fazer isso coloca ambos sob o ttulo Problemas em Testes. Ao finalizar ficaram cinco tipos. O primeiro intitulado Problemas de Requisitos e so listados os problemas com a mitigao ou soluo direita na 81 Tabela 8.1 . risco ou problema: 1 os clientes nos do informaes incompletas sobre as necessidades e requisitos do produto, gerando muito retrabalho mitigao: seguir um processo sistemtico para a identificao do que o cliente necessita para obter o que quer segundo o que diz
80 81
Balanced Score Card As outras quatro so denominadas Problemas de Design, Problemas de Integrao, Problemas de Verificao e Problemas de Validao. No contexto do modelo MPS-SW, a diferena entre verificao e validao clara: a verificao relativa aos requisitos, verifica-se' quando se compara um produto, final ou intermedirio, com os requisitos dos quais deriva, levando em conta sua completude em relao a eles e sua consistncia intrnseca.
Capitulo 8
Pgina 104
Boria et al.
a especificao de um mdulo, componente ou sistema s vezes incompleta, resultando em um produto abaixo da perfeio costumam ficar funes sem especificar e os requisitos no funcionais so frequentemente acrescentados no final do projeto, resultando em muito retrabalho h muito impacto nos compromissos pela quantidade de requisitos derivados que surgem depois do jogo de planejamento a integrao contnua fracassa porque no h uma clara definio das interfaces as funes solicitadas so mal interpretadas porque no h um contexto onde situ-las, resultando em demonstraes fracassadas h certa pressa em passar estimativa sem fazer uma anlise mais profunda da funcionalidade que implementada, resultando em oportunidades perdidas e ineficincias Mesmo nos casos em que so construdos modelos do produto, estes poucas vezes so discutidos com o dono do produto
construir um documento que permita priorizar os requisitos e especific-los de forma a possibilitar sua reviso e anlise. a especificao dos requisitos deve permitir identificar funes, bem como os atributos de qualidade no funcionais do produto
antes de iniciar um sprint, devem ser definidos os detalhes do conjunto de funcionalidades que ser includo parte da especificao deve ser dirigida para o ambiente de funcionamento do produto, sejam interfaces internas ou externas como parte do mecanismo de entendimento dos requisitos, necessrio construir histrias de usurio, narrativas e/ou casos de uso que expliquem o uso esperado do produto a seleo de processos em um sprint deve estar baseada na anlise de requisitos e necessidades do cliente equilibradas com as restries de capacidade da equipe durante o jogo de planejamento, os requisitos menos comuns devem ser validados usando modelos e os casos de uso ou histrias de usurio
Tabela 8.1: Problemas de Requisitos
Este o ponto de partida da futura tabela de deciso. A coluna da direita, mitigao:, d a definio de atributos desejveis da soluo. Quando se compara com as prticas de eXtreme Programming fica claro que no h uma correspondncia, salvo com a presena de tempo completo do usurio no meio da equipe, que poderia ajudar, mas que tambm poderia tornar as coisas mais difceis: Um usurio que disponha de 8 horas dirias para trabalhar no desenvolvimento de software possivelmente no tem muito poder de deciso na empresa que representa, tornando mais complexa a elaborao dos requisitos. Os gmeos ficam um pouco frustrados, mas as reunies de retrospectiva no mentem; tal a densidade dos problemas derivados da m elaborao de requisitos que finalmente os dois se resignam a expandir o horizonte das prticas aplicveis pelas equipes de desenvolvimento (sobretudo) e manuteno. Sem renunciar a XP, necessrio utilizar tcnicas que tenham foco na primeira parte do processo de construo do produto, a captura e elaborao das especificaes tcnicas. 8.4 Corrigindo os Processos de Requisitos Como resposta, Marcela e Ana sugerem voltar a ferramentas que sempre so teis quando se trata de analisar requisitos, ferramentas conhecidas como mtodos de criao de modelos. Os gmeos no querem acreditar no que esto ouvindo, mas prestam ateno mesmo assim. Em seu mundo, modelar no tarefa de programadores! Marcela explica as bases da construo 82 de modelos, fazendo uma breve resenha de A System Modeling Language, ASML , que depois ficou conhecido como Yourdon Software Development Methodology (YSDM). Marcela
82
[WARD e MELLOR, 1986], Structured Development for Real-Time Systems, Volume I: Introduction and Tools
Capitulo 8
Pgina 105
Boria et al.
resgata que mais fcil reconhecer as caractersticas a serem implementadas em um sistema 83 se um modelo dele construdo, pois esse modelo funciona como objeto de fronteira entre o cliente e o engenheiro de software. O modelo, ento, passvel de anlise, tanto pelos usurios quanto pelos tcnicos. Uma simples narrativa ou caso de uso pode ser malinterpretado sem que as diferenas sejam detectadas, porque a linguagem natural muito ambgua. Um Diagrama de Contexto (ver Figura 8.2), por outro lado, no. possvel fazer um diagrama muito simples que descreva os atores envolvidos no ambiente do sistema e os estmulos (fluxos de entrada) aos que o sistema precisa dar uma resposta automtica (fluxos de sada). Esta simples estrutura tem a excelente propriedade de poder ser executada com usurios para detectar diferenas de opinio. Como exemplo, Marcela realiza em poucos traos o diagrama da Figura 8.2 e o narra, mostrando como o sistema interage com clientes, proprietrios e administrador em um sistema de administrao de imveis para alugar ou vender. O Proprietrio se registra com seus dados cadastrais e registra seus imveis. O sistema comunica cada solicitao de registro (pede autorizao para registrar um imvel) ao Administrador, que rev e autoriza ou no esse imvel. Um Cliente se registra interativamente e procura um imvel no sistema. O sistema recebe as ofertas do Cliente e assim sucessivamente. Os gmeos no esto convencidos, j no existe no mercado quem trabalhe com ASML ou anlise estruturada.
Figura 8.2: Diagrama de Contexto de um Sistema
As mulheres lembram que ASML o antecessor direto da UML e que UML ensinado nas Universidades. Ana toma, ento, a liderana da reunio e comea a explicar sua experincia nas disciplinas de Arquitetura e Design com o que se conhece como FDD, mas enfatizando um 84 de seus componentes, Java Modeling in Color (JMC). Em JMC utilizada a notao de 85 UML , uma norma de expresso de modelos que evoluiu das velhas linguagens e que continua sendo apoiada por ferramentas e bibliografia, na qual, em JMC, so aplicados abundantemente os padres, que os autores denominaram arqutipos, que no devem ser confundidos com os esteretipos de UML. Em JMC, as classes de UML so pintadas de diferentes cores para expressar mais claramente sua funo. As rosas so chamadas <<intervalo ou evento>> e representam eventos ou atividades para as quais temos que realizar um acompanhamento por razes de negcios ou jurdicas no sistema a ser desenvolvido. Se tomarmos como um caso ilustrativo uma empresa de bens imobilirios, exemplos de classes de cor rosa so Venda e Aluguel. Sempre as classes rosa so as mais importantes, porque se no houvessem transies e
83
Um objeto de fronteira definido como uma entidade que tem us o plstico, que varia de uma comunidade a outra. Desse modo sua interpretao permite detectar discrepncias entre as comunidades. 84 [COAD et al., 1999], Java Modeling In Color With UML: Enterprise Components and Process . Atualmente o nome foi modificado para Visual Paradigm, abreviado VP UML. 85 [FOWLER, 2003], UML Distilled: A Brief Guide to the Standard Object Modeling Language (3rd Edition)
Capitulo 8
Pgina 106
Boria et al.
eventos, no haveria necessidade de histria, desta forma no haveria necessidade de sistemas de informao.
Figura 8.3: Diagrama de Classe de Acordo
Uma classe pintada de cor verde uma <<entidade>> e so classificadas, alm disso, em <<grupo>> (geralmente uma pessoa ou organizao), <<lugar>> (o lugar onde o evento ou atividade produzida), e <<coisa>> (os objetos do mundo real que participam no evento ou atividade). Exemplos para o nosso caso so Pessoa (que pode ser mais de um) e Imvel. As classes amarelas denotam <<papis>> e representam uma forma de participar em um evento ou atividade por uma classe de entidade verde. Exemplos de classes amarelas so Comprador, Vendedor e AgenteDeVendas. O quarto arqutipo o azul, denominado <<descrio-como-entrada-de-catlogo>> (Descrio, para abreviar), e representa a diferena entre algo como um departamento em um edifcio de vrios andares e a descrio do tipo de apartamento no catlogo de vendas. A descrio a classe azul, que contm uma srie de valores e intervalos de valores que podem ser tomados para todos os apartamentos desse tipo; cada apartamento individual fsico est representado por uma classe verde <<entidade>>. Nestas classes no importa tanto a preciso com a qual se pode instanciar porque seu papel permitir identificar classes faltantes e ajudar a realizar a anlise dinmica do modelo. As classes que pertencem a uma determinada classe arqutipo tm mais ou menos o mesmo tipo de atributos e operaes, mas no precisam ser iguais. Estas classes particulares de arqutipos tambm tendem a interagir com as classes de outros arqutipos em formas geralmente previsveis. Estes padres de caractersticas e comportamento podem nos ajudar a construir rapidamente modelos de objetos que se tornam muito slidos e so facilmente extensveis, ao identificar rapidamente atributos e operaes que de outro modo poderiam ser perdidos, e nos dar maior confiana na estrutura de nosso cdigo. Notavelmente, um modelo dinmico, tal como um diagrama de transio de estados, pode ser deduzido da estrutura. Por exemplo, se pegarmos um Acordo de Aluguel, este comearia com uma busca de seu identificador nico para acessar o Cliente e, por meio dele, os dados de seu domiclio legal. Esta sequncia se repete se o objeto da busca um Livro emprestado a um Leitor em uma biblioteca, para averiguar onde este mora. Esta caracterstica dos modelos UML coloridos fazem com que a pesquisa seja muito mais sistemtica e que at uma pessoa sem conhecimento do domnio seja capaz de conduzir entrevistas produtivas com usurios. Os arqutipos se combinam entre si de maneira natural, que os autores de JMC chamam 86 componentes independentes do domnio A Figura 8.4 mostra um componente deste tipo. Como j dissemos, a caracterstica destes componentes independentes que tm uma dinmica implcita. Esta dinmica implcita pode ser traduzida de modo semiautomtico em um diagrama de transio de estados que mostra explicitamente as conexes dinmicas entre as classes para o caso em que, por exemplo, quisssemos contabilizar transaes de um cliente. A vantagem de contar com uma arquitetura pr-fabricada evidente para Ana e Marcela, somando a isto o fato de que muitas ferramentas apoiam o design de diagramas UML, e que as universidades preparam pessoal com este conhecimento; no precisam de mais argumentos. Os gmeos no esto totalmente convencidos e pedem tempo para ler mais sobre o tema. Sugerem que, enquanto isso, um mtodo sistemtico de design dos testes que inclua a descrio de casos de uso seria suficiente para mitigar muitos dos riscos. Estiveram seguindo
86
Domain Neutral Components, traduo dos autores.
Capitulo 8
Pgina 107

87
Boria et al.
as ideias de Richard Denney desde sua primeira publicao em StickyMinds , e acharam seu 88 ltimo livro bastante til. Apresentam ento uma proposta alternativa: usar histrias de usurios para se manter dentro de eXtreme Programming, elaborar com elas um diagrama de 89 casos de uso, identificar casos omissos usando uma matriz CRUD , e desenvolver um perfil de 90 operaes seguindo as tcnicas do livro de Denney e, para aqueles casos que meream , 91 desenvolver casos de uso completos seguindo os parmetros do livro de Allistair Cockburn . Podero, assim, certificar-se de que todas as entidades necessrias esto sendo consideradas nos requisitos. Para assegurar que a transio a partir dos requisitos ao cdigo se realize com fluidez, podem utilizar o Desenvolvimento Baseado em Testes (Test Driven Development ou 92 TDD ). Desse modo, opinam, solucionaro a maioria dos problemas sem modificar muito o tratamento atual dos requisitos.
Figura 8.4: Diagrama de Classes de Acordo
Como T uma organizao que amadureceu muito, as opinies no se discutem a no ser que sejam submetidas anlise e comparaes. Os quatro montam uma matriz de Pugh que cruza os problemas com as solues. Na interseo de cada fila (problemas) e cada coluna (solues) coloca-se uma letra que indica a contribuio da coluna para essa soluo. Por enquanto basta categoriz-las como A (alto), M (mdio) ou B (baixo). Se no h nenhum impacto da soluo no problema, deixa-se a clula em branco. As duas solues so colocadas nas colunas: Modelado em Cor com UML e XP ampliado com melhor design de testes. A Tabela 8.2, Comparao entre Mtodos de Desenvolvimento pelo Risco, mostra os resultados como so entendidos pela equipe de anlise. Da matriz fica claro
87 88
http://www.stickyminds.com/ [DENNEY, 2012], Use Cases Levels of Test. A Four-Step Strategy for Budgeting Time and Innovation in Software Test Design. 89 CRUD a sequncia de iniciais das palavras inglesas CREATE, READ, UPDATE, DELETE. Estas atividades surgem do uso tpico de um sistema de informao e a falta de uma dessas funes sugere uma especificao incompleta, sendo mais frequente a falta das eliminaes de registros que j no so necessrios. 90 Seguindo Denney, os casos que tenham maior frequncia de uso so desenvolvidos primeiro. 91 [COCKBURN, 2000], Writing Effective Use Cases. 92 Fundamental em XP, o TDD baseia-se em um ciclo curto de repeties: primeiro o desenvolvedor escreve um caso de teste automatizado que define uma melhoria desejada ou novas funcionalidades. O cdigo sem modificar precisa fazer com que esse teste fracasse, a no ser que o rechace. O novo cdigo que produzido pode ento ser validado por verificao por meio de um novo teste. Se for necessrio reacomodar o cdigo para que se cumpra com normas de legibilidade ou semelhantes, ele ser redesenhado usando Refatorao e Smells.
Capitulo 8
Pgina 108
Boria et al.
que os dois enfoques so bastante poderosos, mas nenhum completo. H elementos de processo a acrescentar em todos os casos e pouca a vantagem de um mtodo sobre o outro. Por causa da paridade, a equipe decide incorporar mais uma anlise, desta vez baseando-se na curva de aprendizagem e no risco da adoo. risco: informao incompleta sobre necessidades e requisitos especificaes incompletas funes e requisitos no funcionais sem especificar muitos requisitos derivados depois do jogo do planejamento no h clara definio das interfaces no h contexto onde situar as especificaes passa-se estimativa sem fazer uma anlise mais profunda da funcionalidade os modelos no so discutidos com o dono do produto mitigao: processo sistemtico de identificao documento onde priorizar requisitos e especific-los identificar funes, assim como atributos de qualidade definir detalhes da poro de funcionalidades no sprint especificar interfaces internas e externas construir histrias de usurio, narrativas e/ou casos de uso equilibrar requisitos e necessidades do cliente contra restries da equipe validar o quanto antes os requisitos menos comuns JMC A M B M XP + TST M A M M
A A M
A A A
Tabela 8.2: Comparao entre Mtodos de Desenvolvimento pelo Benefcio
JMC
XP + TST
curva de aprendizagem risco de adoo
A A
B B
Tabela 8.3: Comparao entre Mtodos de Desenvolvimento pelo Risco
Apesar de ser um pouco melhor usar UML com as extenses de modelamento em cor, muito mais simples continuar como at agora, com o agregado dos casos de uso e as tcnicas propostas por Denney. Vencidas pelas provas, Ana e Marcela comeam a trabalhar com os gmeos na melhoria, resumindo as tcnicas em um processo (ver Figura 8.5). Alguns procedimentos do processo anterior so expandidos para que possam ser executados de maneira similar em todos os casos. Por exemplo, para definir histrias de usurio so agregados passos que aprofundam a funcionalidade no jogo do planejamento, em particular durante a discusso com o Dono do Produto. O Dono do Produto participa ativamente na criao destas histrias. Uma histria de usurio uma ou mais frases na linguagem comum do usurio final, que capta o que faz ou precisa fazer como parte de sua funo. Captura quem, o qu e por qu de um requisito, de uma forma simples e concisa, muitas vezes limitada em detalhes que podem ser manuscritos em um guardanapo de papel. Por exemplo, Um cliente s e registra no sistema para buscar imveis para alugar ou comprar. As histrias de usurio so a principal forma de influenciar a funcionalidade do sistema a ser desenvolvido. Podem tambm ser escritas pelos mesmos engenheiros de desenvolvimento para expressar requisitos no funcionais (segurana, qualidade, desempenho, etc.) ou requisitos derivados, por exemplo aqueles que se omitiram na definio do backlog do sprint porque foram assumidos como bvios (uma verificao de saldos em uma conta, a existncia do cliente em um repositrio, etc.) As histrias de usurio so traduzidas em casos de uso como diagrama de casos de uso.
Capitulo 8
Pgina 109
Boria et al.
Figura 8.5: Processo de Captura de Requisitos
Figura 8.6: Resultado dos Passos 1 e 2
Segundo o novo processo, o prximo passo gerar o diagrama de casos de uso com os atores, como ilustra a Figura 8.7. Segundo Denney devemos nos assegurar, agora, que no existam mais casos de uso que estejam faltando. So listados primeiro os casos de uso: Registrar-se; Procurar imvel; Ofertar Aluguel; Ofertar Compra; Fechar Acordo; Incluir Imvel; Recusar oferta; Realizar contra-oferta; Aceitar oferta; Autenticar proprietrio; Eliminar proprietrio. Depois so listadas as classes que surgem dos casos de uso e estas so analisadas para verificar se as quatro funes CRUD esto definidas para cada uma delas. Para continuar com o exemplo proposto, considerando o primeiro caso de uso, Registrar-se, sendo que tanto o ator Cliente quanto o Proprietrio utilizam esse caso de uso, razovel supor que teremos classes para cada um. So includos na lista de Classes. Na ordem dos casos de uso, segue Procurar Imvel; Imvel vai para a lista. Assim tem-se a seguinte lista de classes: A: Cliente; B: Proprietrio; C: Imvel; D: Acordo de Aluguel; E: Acordo de Compra; F: Oferta: Nossa matriz agora tem Atores na primeira coluna e casos de uso em cada uma das seguintes. O resultado a Tabela 8.4.
Capitulo 8
Pgina 110
Boria et al.
Figura 8.7: Diagrama de Arquitetura
Autenticar proprietrio U Autenticar proprietrio U
Realizar contra-oferta
CLASSES............................. ...
Cliente Proprietrio Imvel Acordo de Aluguel Acordo de Compra Oferta
C C R
U D
C C C C C D U U D U U C C
Tabela 8.4: Matriz CRUD sem Completar
A matriz completada colocando na interseo de cada interseo linha e coluna um C, R, U ou D segundo o caso de uso da coluna crie, leia, atualize ou elimine um objeto da classe da fila. A matriz assim completada vista na Tabela 8.5.
Realizar contra-oferta Eliminar proprietrio D Ofertar Comprar Procurar imvel
CLASSES............................. ...
Cliente Proprietrio Imvel Acordo de Aluguel
C C R U C
C U U C
Capitulo 8
Aceitar oferta
Incluir Imvel
Registrar-se
CASOS DE USO
Recusar oferta
Fechar Acordo
Ofertar Alugar
Aceitar oferta
Incluir Imvel
Registrar-se
CASOS DE USO
Pgina 111
Eliminar proprietrio
Ofertar Comprar
Procurar imvel
Recusar oferta
Fechar Acordo
Ofertar Alugar
Boria et al.
Acordo de Compra Oferta C C
C D
U D
Tabela 8.5: Matriz CRUD j Completada
Todas as classes tm pelo menos um caso de uso que cria objetos de sua classe. Os casos de uso Aceitar Oferta e Fechar acordo so vistos estranhamente iguais. Talvez se trate de um requisito redundante, e ser preciso separ-lo de forma detalhada com o Dono do Produto. A grande quantidade de espaos em branco sugere que devemos analisar, mais profundamente, com o Dono do Produto, as regras do negcio. Por exemplo, analisar se a criao de um acordo atualiza os objetos que se relacionam com ele, o cliente e o proprietrio, alm do imvel. Parece lgico que seja assim e deveramos confirm-lo. Isto nos leva a pensar que o objeto Oferta cria relaes similares, ainda no marcadas na matriz. Por outro lado, no h casos de uso que atualizem ou eliminem objetos da classe Cliente, de modo que depois de criado, o objeto persistente e totalmente inerte. Objetos com essas caractersticas so pouco teis em geral. Depois, em um caso real, perguntaramos se existem regras de negcio que nos dizem o que fazer com um Cliente, como se atualiza sua informao e como, se for o caso, ele pode ser excludo no sistema. Da mesma forma, falta informao sobre imveis e acordos, que parecem ser modificados uma nica vez. Certamente, os acordos se renovam ou vencem, os imveis podem sair do sistema. Inclusive nos perguntamos se, ao excluir um Proprietrio, no corresponderia excluir nos objetos relacionados com ele ou ela. Nosso conhecimento do sistema, que parecia to completo quando olhvamos a Figura 8.7, agora parece muito resumido. Com um mtodo simples, mas exaustivo, podemos assegurar que identificamos casos de uso que faltam ou so redundantes e regras de negcio incompletas. 8.5 Perfil Operacional Descreveremos agora o passo seguinte, construir o primeiro nvel do perfil operacional, que refinaremos depois para cada caso de uso. O propsito desta atividade evitar detalhar casos de uso que so pouco frequentes e que, portanto, implicam pouco risco. Nas palavras de 93 Denney , melhor ter uma estratgia para utilizar o tempo sabiamente, e saber quais tcnicas funcionam melhor (ou no) em diferentes problemas. Para simplificar, vamos supor que j consultamos com o cliente as regras de negcio e este nos disse que, por enquanto, s quer incluir mais dois casos de uso, Limpar Dados, que levar em conta eliminaes de objetos que caducaram, e Atualizar Dados, que usaro Cliente e Proprietrio para renovar suas identificaes. Para construir nosso perfil de uso, devemos entender a frequncia de uso de cada caso de uso para cada um dos atores. Obviamente, no caso de um produto existente, investigaremos o comportamento atual e o ajustaremos aos desejos ou necessidades futuras do cliente. Se o sistema novo, deveremos utilizar a viso do Dono do Produto para conseguir os dados. Nossa matriz tem agora Atores na primeira coluna e casos de uso em cada uma das seguintes, mas foi acrescentada uma coluna que identifica a quantidade de atores esperados de cada um dos tipos. Por exemplo, existe s um Administrador, mas se o sistema novo, a quantidade de 94 usurios dos outros dois tipos desconhecida. Segundo Denney , a preciso pode ser desprezada neste momento, basta conhecer a ordem de magnitude relativa. importante reconhecer que ordens de magnitude so suficientes para identificar perfis de uso. Em nosso caso, diremos que h mil Proprietrios para cada administrador e dez Clientes para cada Proprietrio no sistema. Agora preciso quantificar o uso dos casos de uso pelos atores. Primeiro escolhemos (nfase em escolher) um intervalo de tempo conveniente. Pode ser um segundo, um minuto ou um ano. O importante que sirva para estimar nmeros razoveis. Em nosso caso, digamos que se conta com estimativas mensais para cada ator, de modo que o intervalo escolhido seja o 95 ms. Na matriz que estamos gerando (chamada QFD por Denney, dada a semelhana
93 94
Use Case Level of Test, op.cit., pgina 6. Use Case Level of Test, op.cit., pginas 40 e 41. 95 Desdobramento da funo qualidade (QFD Quality Function Deployment) um mtodo de gesto de qualidade baseado em transformar as demandas do usurio na qualidade do design, implementar as (a nota continua na prxima pgina)
Capitulo 8
Pgina 112
Boria et al.
existente entre sua matriz de quantificao de perfil com a usada pelo mtodo desse nome) coloca-se em cada clula a estimativa de frequncia de uso mensal do caso de uso (coluna) pelo Ator (linha). Este nmero um nmero real positivo que omitido quando a frequncia exatamente 0. Por exemplo, foi estimado em um estudo de mercado realizado pela empresa cliente, que sero includos 59 Proprietrios por ms que no total (novos e j registrados) incluiro uma mdia de 0,27 propriedades cada um por ms, levando em conta publicaes de avisos de aluguel na rede e outros meios (avisos classificados dos jornais). Seguindo com as estimativas de modo parecido ao modelo de tomar como referncia ordens de magnitude, o resultado o da Tabela 8.6; Estimativas de Atividade.
por ms 600 59 63,13 4000 8500 1000 3000 80 12 2 3830 59 0,01 clientes novos proprietrios novos imveis novos buscas compra buscas aluguel oferta compra oferta aluguel contraoferta compra contraoferta aluguel recusas acordos fechados autenticaes de proprietrio Eliminaes de proprietrio
Tabela 8.6: Estimativas de Atividade
Com essas estimativas, a matriz de QFD fica com os seguintes dados:

Autenticar proprietrio Realizar contraoferta Ofertar Comprar Procurar imvel Atualizar Dados
330 330 9% 4 10%
Recusar oferta
Fechar Acordo
Ofertar Alugar
ATORES........... ..................... Cliente Proprietrio Administrador execues por ms peso relativo ranking % de esforo
10000 1000 1
0,06 0,06
0,13
0,03
0,01
0,04 0,38 0,06 0 0,02 59 1 1 0% 110 110 3%
659 18% 3 20%
1250 34% 1 38%
300 8% 5 9%
100 3%
766 21% 2 23%
63 2%
2 0%
20 1%
59 2%
Tabela 8.7: Perfil Operacional dos Casos de Uso
Os valores de cada clula surgem da diviso dos dados correspondentes a cada caso de uso pela multiplicidade correspondente do ator que o executa. Por exemplo, se h cem ofertas de
funes que aportem mais qualidade, e implementar mtodos para alcanar qualidade do design em subsistemas e componentes e, em ltima instncia, aos elementos especficos do processo de fabricao. http://en.wikipedia.org/wiki/Quality_function_deployment (N.A.: a redao desta pgina indica sua origem em alguma traduo automtica, o que deixa com um baixo valor esttico, mas ainda legvel).
Capitulo 8
Limpar Dados
Incluir Imvel
Registrar-se
Quantidade
CASOS DE USO
Eliminar proprietrio
Pgina 113
Boria et al.
compra por ms e so dez mil atores, cada um deles executa 0,01 vezes o caso de uso correspondente. As execues por ms resultam da soma dos produtos desse nmero por esta multiplicidade. Por exemplo, se h 0,06 execues de Registrar-se por parte de Clientes e 0,059 execues do mesmo caso por parte de Proprietrios, o produto de 0,06 x 10000 somado ao produto de 0,059 por 1000 d 659. Somando todas as execues, o resultado 3660 que, usado como divisor dos nmeros anteriores, d a porcentagem que corresponde a cada um. Assim, 1250 dividido por 3660 d aproximadamente 34%, que o caso de uso de mais alto ranking. Descartando os casos de uso de baixa frequncia, pode-se recalcular o peso relativo entre os restantes. Esse novo peso serve para usar de proporo para multiplic-lo pelo esforo esperado e conseguir calcular a dedicao a cada caso de uso. Dados os nmeros assim calculados, faz sentido investir nos casos de uso que ocupam os primeiros 4 lugares porque, em conjunto, representam 82% do uso do sistema. Os 5 primeiros somam 90%, enquanto que os 3 primeiros somam 73%. Para quem fizer a escolha, o mtodo claro: so eleitos para serem detalhados os casos de uso que mais peso tm em termos de utilizao pelos usurios. A exceo ou excees podem vir do risco que colocam alguns casos de uso em particular, por exemplo, pode ser que o caso de uso Autenticar Proprietrio seja muito importante em termos de negcio, de modo que, apesar de seu relativo baixo peso, seja considerado para ser detalhado de todos os modos. 8.6 Detalhando Um Caso Cada caso de uso deve descrever como se utiliza o sistema em um aspecto nico do negcio, quer dizer, descreve, a partir do ponto de vista do usurio, o comportamento do sistema quando este ajuda um usurio a alcanar um objetivo de negcio com ele. Para a maioria de projetos de software, isto significa que talvez seja necessrio especificar centenas de casos de uso para definir completamente o novo sistema. Os projetos geis, com sua definio de sashimi para cada sprint, no precisam de tantos. Se, alm disso, so selecionados, como vimos na seo anterior, aqueles que so mais representativos, o resultado manipulvel pela equipe em poucas horas. Um caso de uso contm uma descrio textual de todas as maneiras que se espera que os atores interajam com o sistema. Os casos de uso no descrevem funcionalidades internas do sistema, nem expem como sero implementadas. Por outro lado, mostram os passos da interao do sistema com o ator. Para ser til, um caso de uso deve descrever uma nica tarefa do negcio que sirva a um objetivo de negcio, porque, se h muitos objetivos, o resultado um produto muito complexo. importante ter um nvel de detalhe apropriado, nem muito detalhado nem muito simples, e ser bastante simples a ponto de que um desenvolvedor o elabore em um perodo curto. Para evitar escrever longos casos de uso, h objetivos e subobjetivos, de modo que um caso de uso estende outro caso de uso; ou um caso de uso pode chamar outro caso de uso. O detalhamento de cada caso selecionado implica seguir certas convenes para evitar ter um conjunto de casos de uso dspares em tamanho e extenso e, consequentemente, incomparveis. Neste caso, Marcela d preferncia ao formato 96 proposto por Allistair Cockburn em seu livro . Frequentemente, proposta a seguinte estrutura no design de casos de uso (Tabela 8.8): Componentes de um Caso de Uso
ID NOME REFERNCIAS CRUZADAS CRIADO POR LTIMA ATUALIZAO POR DATA DE CRIAO DATA DA LTIMA ATUALIZAO ATORES
Definio
Segundo nomenclatura de configurao Descritivo do caso de uso (CDU) Outros materiais que so utilizados para entender o CDU Nome do Autor Nome do Revisor ou Atualizador bvia bvia Todos os que intervm, robs inclusive
96
[COCKBURN, 2000], Writing Effective Use Cases.
Capitulo 8
Pgina 114
Boria et al.
DESCRIO DISPARADOR PR-CONDIO PS-CONDIO FLUXO NORMAL FLUXOS ALTERNATIVOS INCLUSES FREQUNCIA DE USO REGRAS DE NEGCIO REQUISITOS ESPECIAIS NOTAS E ASSUNTOS
Texto explicativo de alto nvel (opcional) Evento que dispara o CDU Estado do sistema que permite executar o CDU Estado do sistema que surge aps executar o CDU Srie de passos que so considerados normais Srie de passos que so considerados especiais Outros CDU que so referenciados por este De acordo com o perfil operacional Aquelas que se aplicam ao CDU Hardware ou ambiente de execuo ou desempenho Comentrios para revisores ou futuros usurios Tabela 8.8: Componentes Sugeridos dos Casos de Uso
A planilha anterior uma entre muitas variaes. Para ver um exemplo dos campos de Fluxo ver Tabela 8.15 mais abaixo. Possivelmente um caso de uso complexo possa requerer todos esses campos e alguns mais. s vezes so separados os fluxos alternativos em duas categorias, uma delas dedicada ao tratamento de excees, como quando uma condio intermediria no cumprida. o caso do fluxo que atende ao usurio que esqueceu sua senha no CDU de Entrada. Outras vezes, estes casos so derivados de Casos de Uso especialmente criados e includos. A deciso de qual planilha usar depende exclusivamente das necessidades de cada situao, basta que os campos sejam utilizados uniformemente para que possam ser revisados. O QUE ACONTECEU AT AGORA 61. Marcela, Ana e os gmeos analisam os problemas e os agrupam para procurar solues. 62. Fazendo uma anlise de causas profundas decide-se incorporar mtodos e tcnicas para o desenvolvimento dos requisitos no Sprint. 63. Comparando mtodos por seu impacto e custo de implementao, decide-se utilizar uma mistura de XP-TDD com tcnicas de desenvolvimento de casos de teste propostas por Denney. Neste ponto, o processo de captura de requisitos j tem todos seus componentes descritos. Os gmeos colocam em prtica nas quatro equipes que dirigem, e ao final de quatro sprints, controlando os riscos detectados, pode-se apreciar que todos eles foram considerados. risco: os clientes nos do informao incompleta sobre as necessidades e requisitos do produto, gerando muito retrabalho a especificao de um mdulo, componente ou sistema incompleta, resultando em um produto subtimo costumam sobrar funes sem especificar e os requisitos no funcionais so muito frequentemente acrescentados ao final do projeto, resultando em muito retrabalho h muito impacto nos compromissos pela quantidade de requisitos derivados que surgem depois do jogo do XP + TST So utilizados diagramas de CDU e matriz CRUD
As prioridades so fixadas com o DP e analisadas mediante CDU As planilhas de CDU identificam funes e permitem acrescentar requisitos no funcionais
O jogo do planejamento passa a incluir o detalhe dos requisitos.
Capitulo 8
Pgina 115
Boria et al.
planejamento a integrao contnua fracassa mais do que o necessrio porque no h uma clara definio das interfaces so mal interpretadas as funes pedidas porque no h um contexto onde situlas, resultando em demonstraes fracassadas h certa pressa em passar a estimativa sem fazer uma anlise mais profunda da funcionalidade que implementada, resultando em oportunidades perdidas e ineficincias ainda naqueles casos em que se constroem modelos do produto, estes so poucas vezes discutidos com o dono do produto A planilha de CDU contempla esse ponto
Os CDU cobrem este risco
Os perfis operacionais se ocupam de estabelecer esse equilbrio quando h presses de recursos
O jogo do planejamento passa a incluir o detalhe dos requisitos e sua reviso
Tabela 8.9: Lista de Controle de Mitigao de Riscos em Requisitos
Marcela incorporou, aos passos de aprovao do procedimento, a criao de um mapa dos resultados esperados do MR-MPS-SW que a mudana traz. Isto realizado sem exigncia de completar necessariamente todos os resultados, mas para entender melhor a lacuna entre o que j foi implementado e o que resta para cumprir com o requisitos de uma avaliao. O resultado detalhado na Tabela 8.10. Resultados Esperados do DRE no MPS Evidncia de implementao na Tahini-Tahini
DRE1 As necessidades, expectativas e segue-se um processo sistemtico para a limitaes do cliente, tanto do identificao do que o cliente necessita, para que produto quanto de suas tenha o que quer segundo o que diz interfaces, so identificadas; DRE2 Um conjunto definido de constri-se um documento que permite priorizar os requisitos do cliente requisitos e especific-los, de modo que sua reviso especificado e priorizado a partir e anlise seja possvel de necessidades, expectativas e limitaes identificadas; DRE3 Um conjunto de requisitos a especificao dos requisitos deve permitir funcionais e no funcionais, do identificar funes, assim como os atributos de produto e dos componentes do qualidade no funcionais do produto produto que descrevem a soluo do problema a ser resolvido, definido e mantido a partir dos requisitos do cliente; DRE4 Os requisitos funcionais e no antes de iniciar um sprint, devem ser definidos os funcionais de cada componente detalhes das funcionalidades que sero includas do produto so refinados, elaborados e designados; DRE5 Interfaces internas e externas do parte da especificao deve ser dirigida produto e de cada componente do expressamente ao ambiente de funcionamento do produto, sejam interfaces internas ou externas produto so definidas; DRE6 Conceitos operacionais e cenrios como parte do mecanismo de entendimento dos requisitos, necessrio construir histrias de so desenvolvidos;
Capitulo 8
Pgina 116
Boria et al.
usurio, narrativas e/ou casos de uso que expliquem o uso esperado do produto
DRE7 Os requisitos so analisados, usando critrios definidos, para equilibrar as necessidades dos interessados com as restries existentes; DRE8 Os requisitos so validados.
a seleo de processos em um sprint baseia-se na anlise de requisitos e necessidades do cliente, equilibradas com as restries de capacidade da equipe
durante o jogo do planejamento, os requisitos menos comuns sero validados usando modelos e os casos de uso ou histrias de usurio
2
Tabela 8.10: Implementao de DESENVOLVIMENTO DE REQUISITOS na T
O QUE ACONTECEU AT AGORA 64. Dirigindo os procedimentos em quatro sprints, verifica-se que foram controlados todos os riscos detectados 65. Marcela constata que os resultados esperados para DRE foram cobertos com a implementao dos novos procedimentos 8.7 Detectando Defeitos nos Produtos Os riscos controlados pelas mudanas realizadas no processo de requisitos deveriam diminuir a densidade de defeitos. Na reunio posterior aos quatro meses de acompanhamento em projetos pilotos, os nmeros so mistos. Apesar de terem sido eliminados os problemas que so introduzidos em um sprint que chega ao usurio, os problemas legados de sprints anteriores reestruturao do processo comearam a surgir com fora e so o foco da ateno neste momento. Este fenmeno frequente e uma das causas mais habituais de frustrao com a melhoria de processos. Resolver um problema faz com que seja evidente a existncia de outro que antes era escondido pela existncia do primeiro problema. O fenmeno, conhecido pelos designers de sistemas operacionais, denomina-se problema de engarrafamento, porque ilustrado com esta conhecida molstia do trnsito. A histria assim: suponhamos que um ponto de um caminho produz engarrafamentos dirios a um custo anual ao pblico de cem mil horas de espera, somadas todas as partes envolvidas. Com relao aos cofres pblicos calcula-se que uma hora de espera tem um custo social de cerca de 100 reais. Assim, o ponto em questo custa sociedade dez milhes de reais anuais. O Estado inicia planos para eliminar o problema que custam vinte milhes de reais e, depois de concludos, espera-se que o que foi gasto seja recuperado em dois anos. Depois que as obras foram entregues, o engarrafamento no acontece mais nesse ponto, mas em uma parte um pouco mais abaixo na mesma estrada surge um novo engarrafamento, que antes no era detectado porque o trnsito no chegava a esse segundo ponto na densidade suficiente para criar um engarrafamento. As horas perdidas so agora quase as mesmas, mas em outro ponto. Este desmascaramento ocorre na melhoria de processos tambm. Podemos considerar um projeto como uma srie de estaes unidas por traados pr-definidos (os processos) que levam os produtos de uma a outra. Em cada estao o produto transformado (de necessidade do cliente em caso de uso, de caso de uso em cdigo, de caso de uso em caso de teste, de cdigo no testado em cdigo testado, e assim por diante). Se o que oferta o servio est ocupado, o produto espera para ser liberado. Isto produz filas. Acelerar o servio em uma estao, neste caso a deteco de defeitos, faz com que outra estao mais adiante tenha agora uma fila de espera. Vimos o tratamento que ocorre em Kanban sobre este tema no Captulo 3, focado em liberar o servio da melhor maneira possvel e o quanto antes. Nesta seo nos limitaremos a mostrar as atividades que so necessrias para melhorar o servio que segue. Neste caso o problema que se eliminou a introduo de problemas derivados de requisitos incompletos, ambguos ou inconsistentes, mas o usurio continua encontrando defeitos porque o produto continua mostrando defeitos que no foram detectados em seu momento e que 2 foram introduzidos em muitos sprints anteriores. A T enfrenta o problema de detect-los antes que o cliente. Revisando as planilhas analisadas junto com os Problemas de Requisitos, que se
Capitulo 8
Pgina 117
Boria et al.
conglomeraram em outras quatro, a saber: Problemas de Design, Problemas de Integrao, Problemas de Verificao e Problemas de Validao, os quatro protagonistas de nossa 2 histria na T concluem que h motivos para continuar modificando o que fazem. Primeiro consideram os problemas de Validao, porque no sentido mais estrito afetam o cliente. Das notas que se tomaram na anlise resgatam a Tabela 8.12. risco ou problema: em algumas ocasies preparamos validaes com o cliente que no cumpriam as expectativas do que eles queriam ver, por exemplo omitimos documentao, perdendo credibilidade e tempo em algumas ocasies preparamos validaes que seguiam uma ordem incorreta e confundiam o cliente, fazendo com que tivssemos que refazer a apresentao frequentemente os clientes no compartilham nossos critrios de qualidade, sobretudo quando os requisitos foram disputados vrias vezes em algumas ocasies o produto roda em nosso ambiente, mas no no ambiente do cliente para resolver o problema com o cliente, fizemos correes durante o desenvolvimento que no ficaram registradas e tiraram de sincronizao a baseline resolvemos de mais e de menos em muitas ocasies, desperdiando esforo ou perdendo qualidade em algumas ocasies liberamos cdigo sem o suficiente respaldo
Tabela 8.11: Problemas de Validao
mitigao: decidir com o cliente e a equipe a estratgia de validao, os produtos a avaliar, o cronograma de validao, os critrios de entrada e de aceitao e os ambientes de aplicao
reforar o seguimento do processo de aceitao do usurio, aumentando a frequncia das auditorias e ajudando a prevenir no conformidades, visando assegurar que os critrios de aceitao sejam cumpridos, baseados em documentao fidedigna
Comparando as aes de mitigao desta tabela com as da Tabela 8.12, Problemas de Verificao, Marcela encontra semelhanas que sugerem que a melhoria do processo de engenharia de testes pode atender tanto Validao quanto Verificao. risco ou problema: apesar do plano de testes ser geral, a inspeo seletiva e nem sempre escolhemos bem os produtos ou partes deles que devem ser inspecionados, ou ento escolhemos mtodos mais fracos do que deveramos nem sempre planejamos com antecipao suficiente as atividades de teste ou verificao e perdemos participantes importantes a falta de cobertura na definio de critrios nos levou a tomar decises equivocadas sobre a qualidade do produto demonstrada pela densidade de defeitos quando o sprint est por terminar, cortou-se caminho omitindo testes importantes, como o de estresse nem sempre a densidade que calculamos est aplicar com todo rigor auditorias de processo e produto at que seja fixada a conduta de teste sistemtico automatizar todos os testes mitigao: decidir com a equipe a estratgia de verificao, incluindo: os produtos a avaliar e com quais mtodos; o cronograma das diferentes avaliaes; os critrios de entrada, descontinuidade e aceitao (garantindo que a cobertura mnima seja um deles); e os ambientes de teste, quando aplicvel
Capitulo 8
Pgina 118
Boria et al.
baseada em dados confiveis deveramos poder justificar perante a equipe o retorno do investimento de verificar usando inspees os dados obtidos dos testes e das inspees, walkthroughs e revises tcnicas, devem ser analisados e discutidos na reunio mensal de portflio de projetos
Tabela 8.12: Problemas de Verificao
Desde o comeo, Marcela deixou clara a diferena entre Validao e Verificao. Apesar de que h escolas opostas no que diz respeito ao significado destes dois termos, Marcela, 97 seguindo os conselhos de Mximo, utiliza as interpretaes de Barry Bohm em sua obra . Para eles, ento, verificar comparar se o que realizado cumpre com o especificado, enquanto que validar garantir que o produto satisfaz as necessidades do cliente. Para verificar seus produtos, a T utiliza mltiplas ferramentas. As revises , sejam reviso por 99 100 pares, inspees, walkthroughs , revises estruturadas ou revises contnuas ; so usadas para constatar que o produto sob reviso tem a qualidade esperada e consistente, no s em si mesmo, mas com os produtos que o antecedem, fundamentalmente com os requisitos do sistema. Os testes de programa so utilizados para provocar quedas ou falhas do sistema com 101 102 o propsito de detectar defeitos no produto , mas tambm como ferramenta de design e guia para a construo do programa, como j vimos no Captulo 3. Desenvolveremos tanto as revises em geral quanto mtodos e tcnicas de teste de programas. Para validar seus produtos, a T usa atividades nas quais participa o DP . Ao planejar o Sprint, a equipe cria o modelo que representa a funcionalidade desejada e o executa na frente do DP. Isto permite validar a viso da equipe, no que ela traduziu o que entendeu um objeto de fronteira que o DP pde interpretar por sua vez, achando ento diferenas ou at esclarecendo sua prpria viso. Ao finalizar o Sprint, a equipe apresenta uma demonstrao do produto ao DP, para constatar que a viso compartilhada se materializou corretamente. Estas duas atividades so efetivamente atividades de validao, voltadas para avaliar a eficincia do produto para o cliente. 8.8 Procedimentos de Verificao J cobrimos no Captulo 3 a reviso contnua, como programao por pares ou em dupla. Aqui desenvolveremos em detalhe os procedimentos de reviso clssicos: walkthroughs, reviso formal estruturada e inspeo. As revises so uma parte fundamental de toda atividade de criao de um produto. Em particular, na engenharia de software so indispensveis porque, se adiamos o teste do produto at o ltimo momento, colocamos em perigo a totalidade do projeto. Vamos argumentar este ltimo comeando por uma definio que foi evoluindo na dcada de 60 do sculo passado, pela qual o processo de construo de um artefato de software pode ser visto como a traduo de um contedo semntico de uma sintaxe para outra, com preservao da semntica e o possvel acrscimo de detalhes em cada passo. Por exemplo, o documento de especificao com casos de uso pode ser visto como um refinamento do documento de histrias de usurio, com uma nova sintaxe (a do caso de uso), mas preservando o significado (a semntica) do documento anterior. Da mesma forma, o caso de teste pode ser visto como
97
98
103
De maneira muito geral, pode-se dizer que a verificao se ocupa de constatar se o produto est sendo desenvolvido corretamente, enquanto que a validao procura assegurar que se est desenvolvendo o produto correto, quer dizer, aquele produto que o cliente necessita [BOEHM, 1981]. 98 Veja para maior detalhe [FREEDMAN e WEINBERG, 1990]. 99 N. dos A. Traduzimos walkthroughs como percursos, mantendo a consistncia histrica com [BORIA, 1987]. 100 Seguindo a [BECK, 2000] consideramos a programao a dois uma forma extrema de reviso contnua. 101 Testar o programa para assegurar que funcione um erro de enfoque que diminui a eficincia do teste. 102 Test Driven Design em [BECK, 2000]
103
Dono do Produto, Captulo 3.
Capitulo 8
Pgina 119
Boria et al.
um refinamento do caso de uso com outras regras sintticas, e o cdigo gerado como uma nova iterao desse processo de traduzir e refinar com outra sintaxe. Isto visualizado na parte esquerda da Figura 8.8, sob o ttulo Atividades de Traduo.
Figura 8.8: Modelo V de Desenvolvimento de Software
O ramo direito do modelo em V define a correspondncia entre as atividades de traduo e as atividades de deteco de defeitos por elas introduzidos. A hiptese que cada traduo introduz rudo no sentido que esse termo tem em teoria de informao, quer dizer, um elemento que dificulta a recepo da mensagem. Cada atividade, ento, introduz defeitos. Se esperarmos at o cdigo ser escrito para remover defeitos, o resultado catico. Certamente o projeto tem poucas reservas de tempo e esforo ao chegar a esse ponto, como bem conhecido pelos engenheiros de teste que, consistentemente, veem seu calendrio deslizar para o futuro porque o desenvolvimento ainda no alcanou o ponto onde o produto pode ser entregue a eles. Nessas circunstncias, a deteco de defeitos no diferente em primeira instncia, mas a falta de tempo conspira contra a resoluo: as modificaes so feitas rapidamente e sem pensar muito. O resultado que a correo introduz novos defeitos, com 104 maior probabilidade do que se tivessem sido corrigidos com tempo adequado . Se a deteco de todos os defeitos introduzidos postergada, pode-se esperar que o resultado seja uma zona de grande atrito entre os envolvidos at o final do esforo, como mostra a Figura 8.9.
Figura 8.9: Zona de Caos por Postergao de Atividades de Remoo
Se, em contraste com este enfoque, feito um esforo para detectar e eliminar defeitos assim que tiverem sido introduzidos, como mostra a Figura 8.10, onde foram acrescentadas atividades de deteco mais cedo (revises indicadas pela letra R em um crculo, onde a flecha CRUCIAL mostra as duas mais importantes), o resultado um menor esforo de retrabalho, realizado no momento correto.
104
[MYERS, 1979],
Capitulo 8
Pgina 120
Boria et al.
Figura 8.10: Modelo em V com Revises entre Atividades de Traduo
8.9 Revises Os trs mtodos de reviso que so aconselhados, alm da programao em pares, so a inspeo, que detalharemos a seguir, a reviso formal estruturada e o walkthrough. Os produtos que se aconselha revisar so os que esto associados a requisitos, como casos de uso ou documentos de especificao, e o prprio cdigo. Sempre conveniente identificar os componentes mais arriscados para cobri-los antes de ficarmos sem tempo. Vamos comear ento pelas inspees, para depois, por diferena, definir os outros dois mtodos. O que se ganha ao fazer inspees? Qualidade, porque ao inspecionar produtos so detectados e eliminados defeitos, mas tambm comunicao, porque escolhendo convenientemente os participantes, consegue-se comunicar contedos com preciso, assim como melhorar o conhecimento dos mais novos. Ao inspecionar materiais gerados por especialistas, os mais novos aprendem com eles melhores prticas. Uma inspeo um processo muito formal que identifica um produto, escolhe uma equipe de inspetores, escolhe as ferramentas de inspeo, detecta os defeitos no produto e garante a qualidade resultante. Uma equipe de inspeo formada com papis bem definidos. Deve haver um Moderador que conduza o processo e capacite, se for necessrio, os inspetores. O autor dos materiais a serem inspecionados participa sem voz, escutando o que os Revisores opinam, tambm chamados de inspetores. Um deles, ou o Moderador, atua como Escrivo, tomando nota do que foi feito. O Moderador algum com habilidades de facilitador e que recebeu treinamento para dirigir inspees. A equipe pequena, no mais do que sete pessoas no total, contando o Moderador, o Autor, e dois a cinco Inspetores. Os inspetores so escolhidos de modo a conseguir o mximo benefcio da inspeo, por exemplo, conhecem ou so os autores do produto anterior ou sero os autores do produto que se segue. Individualmente so representantes de categorias importantes dentro da organizao, como arquitetos ou testadores. O que deve ser assegurado que compreendam o produto e o processo, e so especialistas ou vo receber treinamento. Possivelmente algum de Garantia da Qualidade participe com funes especiais, mas tambm til que a Garantia da Qualidade tenha feito uma auditoria do produto antes da inspeo. 8.10 Atividades do Processo de Inspeo O processo de inspeo ativado quando o autor do produto avisa que ele est completo. O encarregado que recebe este aviso consegue a participao de um Moderador entre o conjunto de Moderadores treinados da empresa. Este se comunica com o Autor e comeam a primeira atividade de preparao, que consiste na Seleo do Material. Nela, o Autor com o Moderador decidem, juntos, quais partes do produto sero inspecionadas. Como critrio de seleo, as partes a inspecionar devem estar completas, no devem ser to extensas que incorram em grandes esforos dos inspetores, mas devem ser crticas para que valha a pena avali-las. Ento, o Autor e o Moderador escolhem e preparam materiais acerca do produto (lucro, apresentao, etc.) e as listas de verificao e guias a serem aplicadas ou padres que ajudem a entender o material, assim como produtos referenciados que servem de apoio.
Capitulo 8
Pgina 121
Boria et al.
A logstica preparada tambm entre o Moderador e o Autor. Ambos escolhem a equipe, designam papis distintos (pelo menos o escrivo) e o moderador fixa as duraes para reviso do material, que deve ser no mximo umas 2 horas de esforo; pode ser que em 2 dias de durao; para a reunio de instruo (uns 30 minutos); para a reunio de unificao de defeitos (no mais que 2 horas) e comunica as decises equipe. So consideradas as respostas ao pedido de participao e, depois de estabilizada a equipe e o calendrio de atividades, procede-se Reunio de Instruo.
Reunio de Instruo
Na reunio de instruo, o Moderador instrui a equipe de inspetores sobre o que buscar e por que importante, inclusive o que acontece se passar um defeito (impacto no projeto, impacto no cliente). O Moderador instrui os participantes nos processos a seguir e, se so novos em relao ao processo, so formados parte. A Reunio tambm serve para distribuir os materiais a revisar e as referncias, discutir os papis que cada inspetor vai ter, ou seja, se escolhe-se fazer com que cada um desempenhe um papel (por ex., cliente, usurio final, designer, engenheiro de testes, garantia de qualidade). Nesse caso, cada papel pode ter sua prpria lista de itens de verificao. O autor fornece informaes sobre o produto, como resumo do material a inspecionar, responde perguntas, esclarece significados e relaciona entre si os produtos. Tudo isto realizado em, no mximo, 30 minutos. Os materiais distribudos so cuidadosamente preparados. O produto ter as linhas numeradas ou identificadas de forma clara, e se no for todo o produto, destaca-se o que preciso revisar. Entrega-se tambm a planilha usada para preparar o produto, assim como os padres e referncias, os materiais relacionados e as listas de itens de inspeo que serviro para identificar os defeitos. Para junt-los, entrega-se uma planilha de registro de defeitos.
Inspeo Individual do Produto

Cada inspetor revisa os materiais por sua conta e tenta encontrar TODOS os defeitos. Para isso utiliza os guias, planilhas e as listas de itens e se coloca na perspectiva de seu papel. Registra uma a uma as observaes encontradas na planilha de registro de defeitos, onde marca a localizao do problema, o tipo de item (pergunta, defeito, ambiguidade), e a severidade do defeito. Quando completa todos os itens que encontrou, registra o tempo e o esforo na planilha e realiza um resumo dos problemas. Se, no prazo de duas horas, no alcanou o final do produto a revisar, pode estender o tempo de inspeo pessoal, mas no alm de meia hora. Em qualquer caso, quando termina o prazo sem ter conseguido terminar a tarefa, marca at onde inspecionou e d por concluda a inspeo pessoal. Se o produto no est pronto para ser revisado pela sua baixa qualidade, ou se existe algum outro motivo para que no seja feita a reunio de unificao, caso o produto seja redundante ou esteja desatualizado, informa-se ao Moderador. Se segue o processo normal, cada Inspetor envia a planilha preenchida ao Moderador para que este a unifique dentro da que apresentar na Reunio de Unificao.
Reunio de Unificao
As diferentes questes encontradas individualmente so unificadas em uma reunio especial, cujo objetivo incrementar a qualidade do produto. A sinergia obtida da discusso incrementa em 20% o nmero de questes documentadas na sesso. o Moderador que conduz esta reunio. O Moderador a prepara verificando que todos enviaram suas planilhas preenchidas. Se algum no fez isso, a reunio adiada, o que um grave problema porque o projeto demora. Seria possvel fazer sem o Inspetor atrasado, mas o precedente que seria colocado faria com que a inspeo perdesse a prioridade que deve ter. Na reunio, o Moderador lembra a todos o objetivo da reunio, que consiste em assumir a responsabilidade conjunta pelos defeitos do produto, no a caa s bruxas dos autores. A equipe de inspeo empregou valiosos recursos na anlise do produto para que este saia como um resultado coletivo, com a melhor qualidade possvel. Para reforar a conscincia do trabalho em comum, o Moderador apresenta as estatsticas dos inspetores, tempo, esforo e quantidade de questes levantadas. Depois, ajudado por um projetor, vai percorrendo um a um os defeitos em sua planilha unificada. Ordenou-os por localizao, de modo a ir do geral ao particular e do princpio ao fim. De cada questo d a descrio, tipo e severidade. Depois de lida uma questo faz uma pausa para permitir comentrios dos participantes. Os inspetores podem fazer perguntas entre si, por exemplo, se tal ou qual questo est relacionada com
Capitulo 8
Pgina 122
Boria et al.
outra, ou se realmente to severo quanto foi dito. Podem fazer perguntas ao autor sobre suas decises, mas estas no so julgadas. Se surgem novos problemas, estes so registrados no momento, com toda a equipe, menos o Autor, concordando na redao da questo levantada. Estes podem ser problemas em outros produtos (melhorias da planilha, por exemplo, ou questes no detectadas previamente em outros documentos que foram oferecidos como apoio) inclusive outras questes levantadas na sesso. aceito que a equipe faa comentrios, oferea sugestes e alternativas, que sejam feitas perguntas que sirvam para esclarecer e propostas de solues, mas no so discutidas, s registradas. O Autor responde perguntas se forem dirigidas a ele, mas pode tambm perguntar em cima das questes levantadas, sem defender sua posio, para que sejam esclarecidas. A discusso limitada para que a sesso no dure mais de uma hora. Geralmente, o Moderador tenta concluir em noventa minutos para que seja vivel que a reunio termine antes das duas horas. Se so completadas as duas horas, a inspeo cancelada, o que d um estmulo muito grande para que a equipe tente encerrar. Na Reunio de Unificao no se discutem nem se resolvem as questes, que so apenas anotadas. Talvez se esclarea o tipo ou a severidade, que pode mudar se quem levantou a questo concordar. Como j dissemos, pode-se pedir esclarecimento sobre por que isso considerado uma questo ou um defeito.
Deciso sobre o Produto

Quando j no h mais questes, a equipe decide sobre o produto. Isto significa que escolhe entre opes de: aceit-lo completamente, no h retrabalho indicado; ou h retrabalho, mas basta que seja verificado pelo moderador; ou h retrabalho, mas necessria outra inspeo por esta ou outra equipe; ou no h retrabalho, o produto recusado porque preciso refazlo inteiramente. Nos casos em que a deciso no seja definitiva (aprovar ou recusar) a equipe precisa fixar critrios de aprovao para o Autor, que o Moderador garantir. O Moderador facilita esta discusso de fechamento e a conduz. O resultado completo enviado com a deciso e as questes levantadas a todos os participantes, principalmente ao Autor.
Retrabalho e Concluso
Para cada questo levantada, o Autor se rene com o Moderador para definir se a corrige, caso seja um defeito, ou a documenta e arquiva, se for uma melhoria pedida para esse ou outro produto e ainda no est disposto a realiz-la. Em todos os casos, anota sua deciso na planilha da inspeo que recebeu do Moderador. Se o Moderador o autoriza, pode mudar a 105 severidade. Isto bom porque, se h pessoas que se comportam com fanatismo na reunio, possvel parar de discutir em um ponto e avanar. Se necessrio completa-se, ento, o trabalho, e o moderador verifica a completude do trabalho realizado, quer dizer, se foram corrigidos os defeitos severos, se o critrio de aprovao fixado pelos inspetores foi alcanado ou superado. Podem ento ocorrer algumas das seguintes alternativas: que o Moderador revise ou aprove o retrabalho, porque a disposio escolhida pela equipe permite; que a equipe revise partes selecionadas do produto, guiada por sugestes do Moderador, seja trabalhando individualmente (que a opo preferida) ou em uma nova reunio. Tambm pode ocorrer que todo o produto seja reinspecionado quando os problemas forem substanciais e o produto for crtico para o projeto.
Informe Final
A inspeo completada com um Informe de Fechamento ou Informe Final de Inspeo. O Autor atualiza os itens da planilha de inspees, deixando claro o status de cada item (pois algumas questes podem ter ficado sem resolver), a classificao final de severidade e tipo para cada item (pois podem ter mudado com anuncia do Moderador), e envia a planilha atualizada ao Moderador. O Moderador ou o Autor se colocam de acordo para ver quem que envia pedidos de mudana aos autores dos documentos de apoio relacionados com itens levantados na planilha. o Moderador quem responsvel por emitir o informe final, que descreve a disposio final do produto de trabalho e inclui as estatsticas finais: severidade por tipo, esforo, etc. Estes nmeros so consolidados e analisados especialmente para medir a efetividade e eficcia das inspees.
105
Um fantico uma pessoa que no est disposta a mudar de opinio nem mudar de tema . Winston Churchill.
Capitulo 8
Pgina 123
Boria et al.
8.11 Fatores Crticos de Sucesso O fato de que uma reviso seja denominada uma Inspeo no a transforma em uma atividade efetiva. necessrio planej-la bem e levar em conta os fatores de sucesso. Ao planejar uma inspeo, escolha os participantes com cuidado, seguindo as pautas anotadas (ao final da seo Revises, na pgina 121). Sempre til contar com um engenheiro de testes, porque possvel trein-lo para encontrar problemas. Incluir pessoal novato permite mostrar a eles boas prticas. Assegure-se que a quantidade de material a inspecionar limitada, para que tudo possa ser revisado. O Moderador deve exigir que os projetos forneam tempo suficiente de preparao aos Inspetores para a reviso inicial. A durao da reunio de unificao deve se restringir a duas horas, em uma organizao com problemas de disciplina as inspees comearam a ser usadas para outro tipo de reunies porque eram as nicas reunies que os engenheiros respeitavam, convertendo-as em maratonas de decises at que deixaram de assistir a todas elas. Por ltimo, monitore e controle o processo. O que no se controla, se dispersa. 8.12 Fatores de Fracasso As pautas para que uma inspeo seja bem-sucedida no acabam aqui. H certas decises que matam a inspeo. Se a alta gerncia participar da reunio muito provvel que no se levantem questes para no ferir a reputao do Autor. Se toneladas de material so revisadas, as questes levantadas no sero significativas e as inspees perdero fora rapidamente. Se a reunio de unificao se transforma em uma reunio de soluo, degenerar rapidamente em um concurso de opinies, deixe que o Autor seja o responsvel por escolher as correes. A inspeo no uma proposta de design por comit, mas de qualidade por apoio da equipe. Se a reunio de unificao dura para sempre, as pessoas comearo a colocar objees e desculpas para no participar. Se durante a reunio, o Moderador aceita comentrios personalizados ou carregados de emoo (Isto uma porcaria de produto ou Quem escrever assim no pode trabalhar comigo) as brigas sero moeda corrente e o propsito da inspeo, que a que um grupo ajude uma pessoa a melhorar seu produto para bem de todos, perde-se de forma total. 8.13 Diferenas Entre Inspees, Walkthrough e Revises Estruturadas Utilizando as inspees como gnero, revisaremos os outros dois tipos mostrando somente as diferenas. Seguimos aqui o material de trs livros que coincidem no essencial a respeito destes trs tipos: [FREEDMAN, 1990], [GILB, 1994] e [EBENAU, 1994]. Primeiro comearemos com a mais fraca das trs, em termos de capacidade de encontrar defeitos, o walkthrough. H 106 um livro de Yourdon que descreve com detalhe o processo de walkthrough, mas que em nossa opinio descreve uma reviso estruturada, de modo que se estivermos interessados nesta ltima, essa uma boa referncia. Ao contrrio da inspeo, o walkthrough no exige um moderador. O prprio Autor organiza e facilita. A equipe no est limitada a um nmero mximo e no precisa ser convocada com antecipao alguma. O Autor pode reunir um grupo que dispe de tempo e pedir que se apresentem para uma reunio em minutos ou horas. A durao da reunio tambm flexvel, e os papis so designados, se for o caso, no momento de comear a reunio. Se a inspeo uma tarefa premeditada, o walkthrough uma atividade apenas formal. O propsito obter retroalimentao rpida de um grupo de pessoas para melhorar a qualidade de um produto no momento. As anotaes, captura de dados e resoluo ficam a cargo do autor. possvel que no fiquem rastros desta atividade e que se considere que a falta de histria no um problema. Entre os dois tipos se encontra a reviso estruturada que, como j dissemos, est bem documentada na literatura. Nossa descrio coincide com a realizada no livro de Gilb j citado e em muitas partes com o livro de Yourdon, tambm citado. Na reviso estruturada, quem convoca o encarregado do projeto, ou seja, o lder tcnico, lder de projeto ou gerente de projeto. O propsito conhecer o estado de um produto. O encarregado designa o facilitador e este pode escolher se o autor participa na logstica da atividade. Quer dizer, pode no lev-lo em conta para as decises de composio da equipe e outras decises. O facilitador cumpre um papel mais direto que o Moderador na inspeo
106
YOURDON, Edward, 1989, Structured Walkthroughs. Prentice-Hall.
Capitulo 8
Pgina 124
Boria et al.
porque, apesar de seu nome, ele toma mais decises que o Moderador. Em geral, segue-se o procedimento descrito para a inspeo, exceto porque a reunio de instruo opcional, sendo substituda frequentemente por uma comunicao eletrnica para os participantes. As listas de verificao so semelhantes, mas menos frequente que sejam diferentes para os distintos participantes segundo seus papis, que tampouco so designados com a mesma frequncia do que nas inspees. Muda tambm a capacidade da equipe de decidir sobre o produto. Ao invs de escolher a disposio, a equipe recomenda ao encarregado do projeto um caminho a seguir, que este no est obrigado a considerar. Uma das aplicaes mais interessantes seu uso combinado em projetos de certo risco. Para mais informao ver [BORIA, 2010]. Resumindo as diferenas em uma tabela, so as seguintes: Walkthrough Objetivos
Obter retroalimentao inicial sobre a maneira de avanar com o produto e corrigir defeitos, se existirem Identifica-se a necessidade no calendrio do projeto ou o autor ou outra pessoa decide
Revises Estruturadas
Mostrar que o produto tem a qualidade esperada
Inspees
Localizar todos os defeitos possveis e corrigi-los, at alcanar um nvel de qualidade prefixado O autor solicita a inspeo e confirma que o produto cumpre com os critrios para ser inspecionado A equipe decide sobre o produto e aes futuras O moderador controla de acordo com os critrios da equipe Trs pelo menos e no mais de sete Colegas do autor escolhidos com critrios previamente definidos Moderador capacitado H uma reviso individual prvia seguindo critrios estabelecidos na lista de verificao e com materiais de apoio Leitor designado ou ningum Requeridas formalmente, esforo, tempo, tipo e nmero de questes Relatrio com detalhe do detectado, investido e realizado Coleta, com fins estatsticos, de todos os dados cadastrais e esforo, tempo, custo, etc.
Critrio de Entrada
A gerncia estima que o produto est pronto, foram publicados os critrios de qualidade, o autor confirma que se pode comear A equipe de inspeo informa e recomenda, a gerncia decide A gerncia controla como parte do projeto Ao menos trs e no mais de sete Lderes tcnicos e colegas do autor Geralmente um lder tcnico do projeto H uma reviso individual prvia seguindo critrios estabelecidos na lista de verificao Autor ou leitor designado Geralmente so registradas como em inspees, mas no so requeridas, depende da empresa Relatrio com a lista de defeitos, questes e aes realizadas No exigida
Decises
As decises so tomadas pelo autor Fora do escopo do procedimento Duas ou mais pessoas, sem limite Quem estiver disponvel
Fechamento das Questes Tamanho Composio da Equipe Liderana Preparao
Autor Opcionalmente distribudo o material com horas de antecipao
Apresentador Medidas Registradas
Normalmente o autor Opcional, raramente feito
Relatrios
O autor produz de acordo com sua deciso No exigida
Captura de Dados
Tabela 8.13: Comparao entre Revises
Capitulo 8
Pgina 125
Boria et al.
8.14 Usos geis As revises, assim descritas, parecem mais adequadas em um projeto longo do que para serem teis em um ambiente gil. No entanto, vejamos como foram adaptadas por Marcela e 2 os gmeos na T . Em primeiro lugar, a reviso escolhida pelos gmeos reviso contnua, chamada na literatura de programao em pares, qual se podem juntar os dados que mudaram no processo: quando o mdulo crtico o programador com mais experincia atua de coach e captura dados em uma planilha adaptada usada habitualmente em inspees (ver Tabela 8.14). Com esses dados possvel iniciar uma anlise estatstica dos defeitos detectados. Da mesma forma, Marcela e Jssica adaptaram o mtodo de revises estruturadas 2 para seu uso em sprints. Recordando o incio da T , quando se realizava o leilo de tarefas, quando uma equipe de trabalho termina um produto que merea ser revisado, o que se define 2 no jogo do planejamento do Sprint, ela convoca mediante a Intranet da T (chamada festivamente ITT) as outras equipes para uma reviso. Cada equipe tem a obrigao moral de liberar um de seus membros, nas duas horas que se seguem ao chamado, que possa rever o material. No fim do dia, os revisores se renem com os autores para apresentarem suas questes. O Scrum Master da equipe que solicitou a reviso o Moderador e tem as mesmas responsabilidades em relao ao relatrio do que se fosse uma inspeo. Desse modo, as revises so geis e produzem resultados. Os dados das revises so armazenados em um repositrio central para serem analisados na reunio mensal. O QUE ACONTECEU AT AGORA 66. Os problemas introduzidos em um sprint foram eliminados, mas os problemas legados escalaram. 67. Marcela verifica que uma melhoria do processo de engenharia de testes pode atender tanto Validao quanto Verificao. 68. Marcela, Jssica e os gmeos adaptaram o processo de revises estruturadas a seus sprints e modificaram o procedimento de programao em pares para que produza evidncia de reviso contnua.
Questes Levantadas Pela Inspeo

Projeto Produto Data de Entrada Hora de Comeo Hora de Fim Durao Localizao (Pgina, Linha) Descrio da Questo (Se o item foi levantado na reunio marque com *) Autor Moderador Revisores
Tipo
Severidade
Comentrios da Correo
Tabela 8.14: Planilha de Registro de Questes
8.15 Testes de Produto Para continuar com a melhoria da percepo da qualidade do produto pelo cliente, os gmeos lideram uma equipe de especialistas em testes. Jssica incorporou entre as melhorias ao sistema de compensaes a avaliao contnua, que consiste em descartar a avaliao anual de desempenho e, em troca, realizar avaliaes do resultado de cada tarefa, inspirada pelo material de [CULBERT, 2010]. Como parte do sistema de recompensas, os mais destacados por seu desempenho recebem um diploma honorrio de Campees e um curso de sua
Capitulo 8
Pgina 126

2
Boria et al.
escolha de treinamento anual pago pela T . Como consequncia, Evelina Kahn acabou a Campe de Testes e como recompensa escolheu um curso de engenharia de processos e tcnicas de testes, e voltou de l disposta a aplicar o que aprendeu. Como a oficina est inspirada no livro de Denney, citado acima, a compatibilidade entre o que procuram os gmeos e o que Evelina quer aplicar total. Revisando as aes para as questes de validao e verificao, Marcela j se ocupou de reforar o seguimento do processo de testes, tanto para a aceitao do usurio quanto para os testes que o precedem, aumentando a frequncia das auditorias e ajudando a prevenir no conformidades, de modo que este ponto considerado fechado. D ento a maior prioridade necessidade de definir com o cliente e a equipe as estratgias de teste, os produtos a serem avaliados, o cronograma dos testes, os critrios de entrada e de aceitao e os ambientes de aplicao. 8.16 Critrios Relacionados com Testes Entende-se por critrio, segundo o dicionrio Aurlio, princpio que se toma como referncia e que permite distinguir o verdadeiro do falso. Em segunda acepo um critrio ponderao, medida, equilbrio, discernimento. Em ambos, o significado considera o critrio como um elemento de juzo que permite conhecer a verdade. Quando trabalhamos em um ambiente de software, importante responder pergunta:.como saberemos que o produto est pronto para passar prxima fase ou ser liberado ao usurio? Questes deste tipo so denominadas de Critrios de Aceitao. Para cada tipo de teste, define-se: 1. O conjunto de casos de teste que deve ser usado 2. Os dados que devem ser utilizados cada vez que forem executados os casos de teste 3. Os ambientes nos quais devem ser executados os testes 4. Os testes de regresso includos neste tipo de testes 5. O nmero de defeitos tolerados por categoria de severidade 6. O mnimo de funcionalidades cobertas pelos testes (cobertura) 7. Objetivos de desempenho dos testes a serem alcanados ( performance) 8. Objetivos especficos de volume (se aplicveis) 9. Objetivos de confiabilidade (se aplicveis) 10. Objetivos de usabilidade (se aplicveis) Outros dois critrios teis servem para responder pergunta: como sabemos que o produto est pronto para ser testado? Saber isto importante porque, se comeamos o teste com um produto imaturo, os defeitos se acumularo sem benefcio, pois ser preciso realizar muitas modificaes. Depois importante definir e confirmar que o critrio de entrada para a fase de testes correspondente ser cumprido. Para cada tipo de teste, define-se: Qual o estado que precisa ter o produto para ingressar na fase (geralmente o critrio de aceitao do produto na fase anterior, quer dizer, precisa ter sido provado em tal ambiente com tais casos que deram tal cobertura e com os resultados de no mais do que tantos defeitos segundo a severidade). Garantir que o critrio de entrada seja cumprido implica em um bom investimento de recursos. Isto especialmente importante nas primeiras etapas de teste, porque a onde so produzidos os maiores atrasos, quando os desenvolvedores entregam apressadamente produtos ainda sem terminar. O seguinte critrio a incluir o que responde pergunta: quando preciso deixar de testar um produto porque tem muitos defeitos? Deixa-se de testar o produto e o devolvemos fase de desenvolvimento para corrigi-lo quando no faz sentido continuar investindo recursos para testar cdigo que fatalmente ir mudar de forma significativa. bastante comum conectar este critrio com o de aceitao que diz respeito quantidade de defeitos por severidade. Claramente continua-se testando o produto enquanto o critrio de aceitao relacionado com a densidade de defeitos (o 5 em nossa lista) continuar sendo cumprido e o critrio de cobertura ainda no (o 6 em nossa lista).
Capitulo 8
Pgina 127
Boria et al.
8.17 Cobertura A cobertura fornecida pelos testes um aspecto sumamente importante na definio de critrios. Podemos ser mais especficos do que simplesmente falar da funcionalidade coberta. Nesse caso, o que se expressa como cobertura a porcentagem dos casos de uso que os casos de teste cobrem. Mas se lembrarmos a redao de um caso de uso (Tabela 8.8) possvel que existam fluxos alternativos. Por exemplo, vejamos o primeiro de todos os CDU, Registrar-se como Usurio do Sistema. FLUXO NORMAL
1. O sistema espera um usurio novo mostrando a tela de entrada 2. Um usurio escolhe entrar no sistema 3. O sistema apresenta a tela de opes para usurios registrados ou novos 4. O usurio escolhe a opo para usurios novos 5. O sistema apresenta a tela de registro de dados 6. O usurio introduz seus dados pessoais e confirma apertando ENTER 7. O sistema armazena os dados do novo usurio em sua base de dados e passa ao CDU de Entrar
FLUXOS ALTERNATIVOS
7a. O sistema encontra um usurio com a mesma identidade (nome, tipo e nmero de documento), mas outros dados de cadastro (endereo e bancos) 7b. O sistema consulta o usurio sobre os dados existentes, solicitando permisso para atualiz-los com os dados recm-ingressados 7c. O usurio autoriza o sistema a realizar a atualizao 7d. O sistema atualiza os dados em sua base de dados e passa ao CDU de Entrar
Tabela 8.15: Exemplo de Sequncia Principal e Alternativa de um CDU
claro que um caso de teste que siga a sequncia feliz (o usurio totalmente novo) no cobre toda a funcionalidade do caso de uso, j que h pelo menos um fluxo alternativo quando o usurio se registrou anteriormente e em consequncia uma regra de negcio (atualizar os dados de cadastro) que no testada. Portanto, importante definir o que se quer dizer com cobertura dos casos de teste. Obviamente, no nvel mais alto, espera-se que haja pelo menos um caso de teste para cada caso de uso. Pode-se requerer que a cobertura de casos de uso seja 100% na maioria dos casos, mas nem sempre assim, se o perfil operacional nos diz que alguns dos CDU so de muito baixa importncia. Se alguns casos de uso so importantes, devemos saber quais coberturas das diferentes alternativas e excees, de cada um, estamos cobrindo com nossos casos de teste. Na realidade, a literatura clssica de design de casos de teste associa cobertura dos casos de teste com os mtodos de caixa de cristal, ou caixa branca como eram chamados no princpio. Os mtodos de design de testes so classificados em dois grandes tipos: o design de casos de teste omitindo o cdigo que foi ou ser construdo, chamados caixa preta por sua semelhana com mtodos de design de testes que ignoram o design dos componentes a testar, e caixa de cristal, ou caixa branca originalmente (at que algum levou em considerao que o problema distinguir entre opacidade e transparncia, e no entre cores de caixas igualmente opacas). Os mtodos de caixa de cristal so associados facilmente cobertura, porque as categorias de cobertura so: sentenas (porcentagem de linhas de cdigo exercitadas durante a execuo do conjunto de dados de teste), condies (porcentagem das condies testadas em ambos os sentidos, quer dizer Falso/Verdadeiro, exercitadas durante a execuo do conjunto de dados de teste), e caminhos (porcentagem de todos os caminhos possveis exercitados durante a execuo do conjunto dos dados de teste). As categorias so crescentes, nas quais a cobertura de caminhos implica na cobertura de condies, que por sua vez implica na cobertura de sentenas. No posso atender todas as condies sem atender todas as sentenas A NO SER QUE HAJA CDIGO INALCANVEL, quer dizer, cdigo que no pode ser executado em condies normais de uso. o caso de pores de cdigo que se separaram do conjunto colocando um salto (GOTO) primeira sentena que vem depois da poro na sentena anterior qual ele comea ou que esto condicionados por uma condio inalcanvel.
Capitulo 8
Pgina 128
Boria et al.
Voltemos, agora, a Denney e seu livro Use Case Levels of Test. Ns o abandonamos com a construo do Perfil Operacional do sistema e a construo daqueles casos de uso que se justificavam. Agora j podemos elaborar sobre estes casos de uso que valem a pena, para analisar quais passos preciso atender. Do perfil operacional j no podemos tirar mais nada, a no ser que refinemos os passos que so percorridos dentro de cada caso de uso e analisemos sua frequncia relativa. isso precisamente o que nos prope Denney, convertendo primeiro o caso de uso em um diagrama de fluxo de controle. A tentativa de construo do diagrama permite ver que h caminhos sem definir no caso de uso. Por exemplo, O que acontece se o usurio no d permisso para atualizar seus dados? No diagrama tomamos a deciso de finalizar sem atualizar.
Figura 8.11: Diagrama de Fluxo do Caso de Uso da Tabela 8.14
Um diagrama de fluxo de controle requer ter um nico ponto de entrada e um nico ponto de sada. Estes nos permitem fechar regies no diagrama, marcadas como 1, 2 e 3, de baixo para cima. Isto importante porque nos permite conhecer o nmero de casos de teste que necessitaremos gerar. Comecemos por fazer abstrao do que acontece em um n para poder mostrar, progressivamente, o mtodo de construo de casos de teste mais a cobertura medida que acrescentamos casos ao conjunto. Tomando novamente emprestado de Denney usaremos seu exemplo da Figura 8.12.
Figura 8.12: Diagrama de Fluxo de Controle com Funcionalidade Abstrada
Dependendo se for um caso de uso de alta frequncia, os caminhos que valem a pena atender com casos de teste sero diferentes. Imaginemos o pior caso, no qual a cobertura de todos os casos de uso for parte dos critrios de aceitao de uma fase de testes, mas o caso de uso
Capitulo 8
Pgina 129
Boria et al.
assim representado tem baixa frequncia de utilizao. Ento tentaremos fazer o menos possvel para cumprir com o critrio, mas sem usar recursos demais. Quando preciso escolher um nico caso de teste para um caso de uso, geralmente, cria-se sobre a base de que o uso mais frequente deve ser no caso em que todas as condies acontecem de forma perfeita. por isso que este caso denominado o caminho feliz, porque no ocorrem excees. Ainda para o caminho feliz, poderamos ter uma mesma sequncia de testes com diferentes dados, mas falaremos disto mais adiante. Um caso de teste que percorra os ns 1, 2, 3, 4, 5 e 6 da Figura 8.12 exercita o caminho feliz. Se dentro de cada n no h caminhos alternativos, a execuo de um n implica a execuo de todas as sentenas que formam parte desse n no cdigo, por isso a cobertura de ns no diagrama de fluxo de controle equivalente cobertura de sentenas e no cdigo. Para conseguir cobertura de sentenas, precisamos de dois casos de teste. Um pode se aproveitar da existncia de dois ciclos (entre 5 e 4 e entre 5a e 4) para que o caso de teste que percorre 1, 2, 2a, 3, 3a, 4, 5, 4, 5a e 6 d cobertura aos ramos da direita do diagrama e depois com 1, 1a e 1b atender o ramo da esquerda. Mas a cobertura de sentenas no garante que os testes sejam definitivos. Para ter a maior cobertura possvel, a de caminhos, podemos partir do diagrama de fluxo de controle e sistematicamente produzir todos os caminhos. Comecemos com o primeiro caminho, o Caminho Feliz, que como j vimos 1, 2, 3, 4, 5 e 6 (Figura 8.13) e indo do ltimo n para cima vamos escolher um passo que no tenhamos explorado. Como j passamos pelo 5, a nica opo o 5a com seus dois passos, de 4 at ele e dele at o 6. Isto delimita a primeira zona do diagrama, a zona 1 (Figura 8.14). Repetindo o algoritmo chegamos ao n 4, e agora escolhemos qualquer arco de entrada. Damos preferncia aos que so numericamente posteriores, depois escolhemos o n 5 e o arco que vai do 5 ao 4 (Figura 8.15). Fica delimitada a segunda zona, a 2. Repetindo o processo aparecem sucessivamente todas as zonas at a 7. So necessrios 8 casos de teste para atender todos os caminhos.
Figura 8.13 Caminho Feliz
Figura 8.14 Primeira rea Fechada
Capitulo 8
Pgina 130
Boria et al.
Figura 8.15 Segunda rea Fechada
Figura 8.16 Terceira rea Fechada
Figura 8.17 Quarta rea Fechada
Figura 8.18 Quinta rea Fechada
Capitulo 8
Pgina 131
Boria et al.
Figura 8.19 Sexta rea Fechada
Figura 8.20 Todas as reas Fechadas
S resta definir como se selecionam os caminhos que valem a pena serem detalhados com casos de teste. O mtodo de Denney sugere Adivinhar! , mas no sem fundamentos. Baseando-se na conhecida distribuio dos bens do matemtico italiano Pareto, Denney prope atribuir uma probabilidade de 80% ao passo mais provvel e 20% ao outro, se so dois. Por exemplo, na Figura 8.13 o passo de sada (1, 2) teria 80% de probabilidade e o (1, 1a) teria 20%. Cada passo do caminho feliz tem 80% e as alternativas 20%. Quando h s um caminho de sada este tem um peso probabilstico de 100%, obviamente. Desta maneira as probabilidades so designadas a cada passo. Desprende-se ento que a frequncia de uso de um caminho o produto de todos os passos desse caminho. O caminho feliz tem frequncia (0,8 x 0,8 x 0,8 x 0,8 x 0,8) = 0,32768. O caminho 1 -> 1a -> 1b tem frequncia 0,16. (Figura 8.21). Marcela e as equipes tcnicas investigam a possibilidade de utilizar critrios de cobertura fortes para garantir que os testes deem uma alta segurana de que os defeitos remanescentes so muito poucos e dentro do objetivo de processo estabelecido pelo comit de gesto. Finalmente, decide-se que os critrios sero estabelecidos pelo dono do produto em conjunto com a equipe durante o jogo do planejamento, como parte da atividade de estabelecer os requisitos no funcionais do sprint. Mas quando um caminho dentro de um caso de uso utilizado com alta frequncia tiver risco alto, o caso de teste correspondente deve ser includo entre os casos a criar e implementar para o teste de integrao contnua do sprint. Como parte do design, concorda-se em seguir os passos descritos por Denney. Para o sprint de estabilizao sero fixados critrios especiais relacionados aos objetivos de negcio da empresa a respeito do produto em questo.
Capitulo 8
Pgina 132
Boria et al.
Figura 8.21: Probabilidade de Cada Transio do Grafo
O QUE ACONTECEU AT AGORA 69. Jssica incorporou entre as melhorias ao sistema de compensaes a avaliao contnua. 70. Os gmeos encabeam um grupo de especialistas para modificar e melhorar as tcnicas de testes de produto. 71. Evelina terminou Campe de testes e volta de um curso de engenharia de testes disposta a aplicar o que aprendeu recentemente. 72. So adotadas as tcnicas de design de casos de teste guiadas por riscos e frequncia de uso. 73. Os critrios de cobertura, com diferente nfases, so usados na fixao de objetivos para cada sprint. 74. O Sprint final de estabilizao receber seus prprios critrios de cobertura. Como ltimo passo na melhoria de processos da engenharia de testes, Marcela e Jssica 2 exploram a lacuna existente entre os procedimentos em uso pela T e os resultados esperados do MR-MPS-SW para os processos de Verificao e Validao. Resultados Esperados de VER no MPS Atividades Internas na Tahini-Tahini
VER1 Os produtos de trabalho a serem acordar com a equipe a estratgia de verificao, os produtos a avaliar e com quais mtodos, o verificados so identificados; VER2 Uma estratgia de verificao entrada, descontinuidade e aceitao (garantindo desenvolvida e implementada, que a cobertura mnima seja uma delas) e os estabelecendo o cronograma, ambientes de teste, quando forem aplicveis revisores envolvidos, mtodos para verificao e qualquer material a ser utilizado na verificao; VER3 Critrios e procedimentos para verificao dos produtos de trabalho a serem verificados so identificados e um ambiente para verificao estabelecido; VER4 Atividades de verificao, aplicar com todo rigor auditorias de processo e incluindo testes e revises em produto at que seja fixada a conduta de teste sistemtica pares, so executadas; VER5 Os defeitos so identificados e automatizar todos os testes registrado;
cronograma das diferentes avaliaes, os critrios de
Capitulo 8
Pgina 133
Boria et al.
VER6 Os resultados de atividades de verificao so analisados e postos disposio das partes interessadas.
Resultados Esperados de VAL no MPS
os dados obtidos dos testes e das inspees, walkthroughs e revises tcnicas, devem ser analisados e discutidos na reunio mensal de portflio
2
Tabela 8.16 Resultados Esperados de VERIFICAO e Atividades Internas em T
Atividades Internas na Tahini-Tahini
VAL1 Os produtos de trabalho a serem acordar com o cliente e a equipe a estratgia de validao, os produtos a serem avaliados, o validados so identificados; VAL2 Uma estratgia de validao aceitao e os ambientes de aplicao desenvolvida e implementada, estabelecendo um cronograma, participantes envolvidos, mtodos para validao e qualquer material a ser utilizado na validao; VAL3 Critrios e procedimentos para a validao dos produtos de trabalho a serem validados so identificados e um ambiente para validao estabelecido; VAL4 As atividades de validao so executadas para garantir que o produto esteja pronto para seu uso no ambiente operacional previsto; VAL5 Os problemas so identificados e reforar o seguimento do processo de aceitao do usurio, aumentando a frequncia das auditorias e registrados; VAL6 Os resultados das atividades de assegurando que os critrios de aceitao sejam validao so analisados e postos cumpridos, baseados em documentao fidedigna disposio das partes interessadas; VAL7 As evidncias de que os produtos de software desenvolvidos esto prontos para seu uso previsto so fornecidas.
Tabela 8.17: Resultados Esperados de VALIDAO e Atividades Internas em T
2
2
cronograma da validao, os critrios de entrada e
ajudando a prevenir no conformidades,
Os resultados so muito bons, o que a direo de T recebe com muita alegria. A pergunta que se fazem se vale a pena fazer uma avaliao para o Nvel D ou esperar at ter o C implementado. Marcela lembra que ainda no revisaram todos os processos do nvel D, falta ocupar-se de Integrao do Produto ITP e de Projeto e Construo do Produto PCP. 8.18 Projeto e Construo Seguindo a linha de atuao que surgiu dos requisitos, a construo de casos de teste, podese ir at ITP considerando que a integrao tem um forte componente de testes, ou at PCP, porque a equipe escolheu Test Driven Design como tcnica de design. Este ltimo os guia at revisar a lacuna com PCP. Os resultados de PCP esto listados na : Projeto e Construo do Produto (PCP)
PCP1
Alternativas de soluo e critrios de seleo so desenvolvidos para atender aos requisitos definidos de produto e componentes de produto;
Capitulo 8
Pgina 134
Boria et al.
PCP2 PCP3 PCP4 PCP5 PCP6 PCP7 PCP8
Solues so selecionadas para o produto ou componentes do produto, com base em cenrios definidos e em critrios identificados; O produto e/ou componente do produto desenhado e documentado; As interfaces entre os componentes do produto so desenhadas tomando como base critrios pr-definidos; Uma anlise dos componentes do produto conduzida para decidir sobre sua construo, compra ou reuso; Os componentes do produto so implementados e verificados de acordo com o que foi desenhado; A documentao identificada, desenvolvida e posta disposio de acordo com os padres estabelecidos; A documentao mantida de acordo com critrios definidos.
Tabela 8.18 Processo PROJETO E CONSTRUO DO PRODUTO [SOFTEX, 2012a ]
Revisando os materiais derivados das reunies de retrospectiva so analisados os problemas que se vinculam ao design e construo dos produtos. Reflete-se esta anlise na Tabela 8.19.
Design (Projeto) e Construo do Produto PCP
risco ou problema: nos dedicamos a explorar a primeira opo de design e se no h razo para descart-la, a implementamos sem considerar os objetivos do design e buscar alternativas melhores, arriscando sub-otimiz-lo o sprint de estabilizao est tendo problemas porque a equipe no reconhece algumas decises de design que impactam nos testes a integrao, frequentemente, fracassa na primeira tentativa, fazendo perder um dia de testes a cada vez tentamos reinventar a roda em vrias ocasies
mitigao: desenvolver critrios universais para iniciar uma anlise de alternativas de design baseados nos objetivos de 2 negcio da T e do projeto documentar o design, sobretudo o porqu da seleo de componentes, apoiado nos requisitos, sobretudo os no funcionais realizar uma anlise de causas para identificar aes aplicar a anlise de reuso, ampliando iniciativas de reuso com componentes do mercado reforar o sentimento de YAGNI utilizando s testes que foram aprovados pela equipe no momento de aprovar o plano de sprint
107
em algumas ocasies, a equipe se desviou significativamente das decises de design, em favor de melhorias hipotticas, aumentando a probabilidade de precisar refazer os casos de teste no ltimo momento. em casos particulares entregou-se a documentao incompleta ou em formato diferente do decidido
acrescentar uma planilha de reviso de documentao para ser utilizada para afirmao da qualidade antes do fechamento do sprint refazer a reviso da documentao no sprint de estabilizao
Tabela 8.19: Problemas de Design
Comparando as solues com os resultados esperados do processo, Marcela e Ana vislumbram grandes oportunidades de resolver o problema detectado em cada caso e, ao mesmo tempo, fazer uma implementao que alcance esses resultados esperados. Algumas aes so muito fceis de implementar, por exemplo, ampliar a anlise de reuso que j
107
You Ain't Gonna Need It (Voc no vai precisar).
Capitulo 8
Pgina 135

108
Boria et al.
2
vimos para incluir entre as opes componentes que podem ser adquiridos fora da T . Isto d frutos de imediato porque Mariano mantm um caderno de tecnologia no mesmo wiki em que so guardadas as informaes de componentes reutilizveis. O motivo pelo qual faz isso porque quer ter muito claro quais so os produtos que competem com as linhas de produto da 2 T e orient-la para as necessidades do mercado. Desse modo, as equipes no precisam mudar nem uma linha de seus processos, pois uma pequena mudana no mtodo de busca na wiki d o resultado esperado. Mas a investigao sobre reuso trouxe um presente inesperado: pode-se adaptar o mtodo de anlise de decises para reuso, para que seja um mtodo de anlise para design em geral, de modo que, ao comear o design, j se esteja pensando em alternativas. Desse modo, ataca-se a raiz do problema de design, o primeiro dos pontos. Modificada a anlise que deve ocorrer no jogo do planejamento, fica assim: 1. Enunciado de objetivos, quer dizer, para que se realiza o design do produto do sprint. Alguns exemplos so encurtar prazos sem perda de qualidade, permitir manter a durao do sprint desenvolvendo mais pontos de usurio, diminuir custos, etc. 2. Escolha de atributos desejveis, onde a equipe discute, a partir dos requisitos, quais atributos deve ter o design, por exemplo, deve ser integrvel facilmente, compatvel com o design atual, fcil de testar, executar muito rpido, etc. 3. Identificao de solues candidatas, que realizado automaticamente usando o algoritmo neural baseado nos atributos escolhidos para componentes existentes ou no mercado. No caso de no existir ou de considerar a equipe necessria, so descritos ao menos trs solues alternativas enfatizando o impacto do risco na identificao. 4. Avaliao de candidatos, que realizado por testes ad-hoc, que so criados em relao aos atributos escolhidos, e a histria do componente, quando existente, ou por mtodos menos formais, quando se trata de solues originais. 5. Anlise de opes, realizado seguindo um mtodo pr-estabelecido que utiliza uma matriz de Pugh como a que j foi visto no Captulo 4. Uma das opes nunca utilizar um componente reutilizvel. 6. Seleo de alternativas, realizado tambm seguindo o mtodo anterior. 7. Adoo ou Design de componente, que realiza o ajuste do componente, de acordo com as necessidades da equipe, se aplicvel. Pode ser que, ao chegar a este ponto, o resultado da avaliao de alternativas seja totalmente negativo e seja preciso revisar novamente o design. 8. Avaliao do resultado, que compara os resultados obtidos com os objetivos enunciados no primeiro passo para: continuar montando a histria do componente e acrescentar os conhecimentos adquiridos, quando se trata de reuso, ou capturar o aprendido na wiki, quando se trata de um design novo. Se aplicvel, registrar o componente como til para reuso.
Tabela 8.20: Anlise de Opes sobre Design
Deste modo, estende-se a aplicao de reuso a componentes ainda no construdos ou j existentes no mercado. Realizada uma anlise de causas sobre os problemas do fracasso da integrao contnua na primeira tentativa, determina-se que o problema que houve mudanas nas API sem que todos os interessados tivessem sido comunicados. A soluo que as APIs fiquem sob controle do Scrum Master depois de aprovadas e que todas as mudanas sejam comunicadas. O uso de ferramentas de controle de configurao faz com que esta pequena mudana seja fcil de implementar. Apesar de tudo, os primeiros Sprints utilizando a mudana ainda mostram traos desse problema, por isso o grupo de Qualidade, que agora depende de Jssica, volta a realizar auditorias iniciais para garantir que as APIs e as interfaces de usurio estejam sob controle de mudana e designadas ao Scrum Master. Apesar de isto violar de certo modo os
108
Captulo 7, Figura 7.2: Anlise de Opes sobre Reuso, pgina 99.
Capitulo 8
Pgina 136
Boria et al.
princpios geis, a proposta bem recebida pelas equipes: poucas coisas so mais sentidas do que chegar pela manh a um escritrio vazio e descobrir que os resultados da noite anterior so nulos. J no tema das auditorias de qualidade, incorpora-se a sugesto das retrospectivas de acrescentar um item de controle que permita conhecer o estado da documentao decidida com o usurio em cada caso. Todas as auditorias pr-demo as incluem, assim como as de entrada e sada ao Sprint de estabilizao. Voltando ao tema de design de testes, como os testes se desenvolvem de modo sistemtico agora, torna-se mais desejvel utiliz-los como elemento de design. As equipes ratificam sua poltica de usar os testes criados por engenheiros de teste para desenvolver o produto. Neste ponto, Marcela considera que os itens principais surgidos das retrospectivas que se relacionam com o Design foram cobertos. Para verificar isso, constri a Tabela 8.21. Resultados Esperados de PCP no MPS Cobertura na Tahini-Tahini
PCP1 Alternativas de soluo e critrios desenvolver critrios universais para iniciar uma de seleo so desenvolvidos para anlise de alternativas de design baseados nos atender aos requisitos definidos objetivos de negcio da T2 e do projeto de produto e componentes de produto; PCP2 Solues so selecionadas para o produto ou componentes de produto, com base em cenrios definidos e em critrios identificados; PCP3 O produto e/ou componente do documentar o design, sobretudo o porqu da seleo produto criado e documentado; de componentes, apoiado nos requisitos, sobretudo
os no funcionais
PCP4 As interfaces entre os controlar as interfaces de todo tipo para que suas componentes do produto so modificaes se propaguem aos interessados criadas tomando como base critrios predefinidos; PCP5 Uma anlise dos componentes do aplicar a anlise de reuso, ampliando-o com produto conduzida para decidir componentes do mercado sobre sua construo, compra ou reuso; PCP6 Os componentes do produto so reforar o sentimento de YAGNI utilizando somente implementados e verificados de testes que foram aprovados pela equipe no momento de aprovar o plano de sprint acordo com o que foi criado; PCP7 A documentao identificada, acrescentar uma planilha de reviso da desenvolvida e disponibilizada de documentao para ser utilizada para afirmao da acordo com os padres qualidade antes do fechamento do sprint estabelecidos; PCP8 A documentao mantida de refazer a reviso da documentao no sprint de estabilizao acordo com critrios definidos.
Tabela 8.21: Cobertura de Resultados Esperados de PCP
8.19 Integrao As retrospectivas tambm deixaram lies sobre os procedimentos de integrao. Nelas foram detectados vrios problemas relacionados, e da mesma forma, foram propostas solues. Algumas destas solues propostas esto vinculadas a procedimentos j implementados para engenharia de testes, de maneira que acabam sendo muito fceis de implementar.
Capitulo 8
Pgina 137
Boria et al.
risco ou problema: a integrao contnua est sendo usada muito limitadamente, sem considerar os componentes j desenvolvidos, o que pode trazer consequncias no sprint de estabilizao (e j trouxe em alguns casos) quando o produto comea a estabilizar-se e a crescer, o ambiente de desenvolvimento muito lento e a integrao cria obstculos ao desenvolvimento, resultando em horas perdidas. a integrao pode fracassar porque as interfaces no so compatveis, o que pode levar a perdas de eficcia no uso dos recursos as mudanas nas interfaces tm efeitos negativos nos testes de regresso, e nem sempre so consideradas na anlise do impacto cedendo a presses prprias, os programadores costumam subir cdigo defeituoso ao ambiente de integrao a integrao realizada espontaneamente sem seguir muitas pautas, salvo o que est nos scripts da ferramenta no passado, acreditamos ter aprovado uma integrao quando na realidade no havia sido executada ainda alguns casos da base de testes de regresso deixaram de ser teis e novos casos que deveriam ter sido includos no foram nem sempre se desenvolveu a documentao prevista por contrato ao mesmo tempo do produto em si, o que frequentemente provocou sufoco no final
mitigao: ampliar o uso da integrao contnua para conseguir que os testes de regresso ocorram com certa frequncia, visando minimizar o esforo de estabilizao no sprint final garantir que os ambientes de integrao definidos para os projetos estejam de acordo com suas necessidades, a partir de uma definio bsica padro e critrios de ajuste assegurar a compatibilidade das interfaces mediante uma mini-inspeo antes de subir um mdulo para ser integrado dedicar parte do procedimento da anlise de impacto anlise de interfaces utilizar inspees breves para analisar os produtos e auditar que os testes unitrios foram realizados e os critrios foram cobertos orientar as equipes para que gerem suas prprias regras sempre que incluam as normas organizacionais ou recebam dispensa para no fazer isso os dados da integrao devem ser cuidadosamente inseridos na ferramenta e os resultados devem ser analisados como parte do scrum dirio acrescentar descrio do papel de engenheiro de testes o procedimento de manuteno da base de regresso orientar os scrum masters para que revisem o backlog e questionem a falta de tarefas relacionadas com a documentao contratualmente obrigatria, quando for pertinente
Tabela 8.22: Aes Relacionadas com Integrao, Derivadas de Retrospectivas
Como parte do procedimento habitual de integrao contnua, foi acrescentada a execuo de testes de regresso todas as sextas-feiras ao sair para o fim de semana, a fim de minimizar o esforo de estabilizao no sprint final. Ao contar com ambientes de teste bem definidos para os projetos de acordo com suas necessidades, incorporou-se naturalmente o ambiente de integrao, a partir de uma definio bsica padro e critrios de ajuste que integram a BiPro. Quando se sobe um programa baseline para sua integrao contnua, o colega que realizou os testes correspondentes deve assegurar a compatibilidade das interfaces mediante uma miniauditoria antes de subi-lo. No jogo do planejamento, dedica-se agora parte do tempo anlise de interfaces. So realizadas miniauditorias de configurao e processos para assegurar que foram realizados os testes unitrios e foram cobertos os critrios de aprovao dos mdulos antes que possam ser integrados.
Capitulo 8
Pgina 138
Boria et al.
As equipes adaptam as normas organizacionais para realizar procedimentos de integrao ou recebem dispensa para no precisar realiz-los sob justificativa bem documentada. Os dados da integrao surgem da ferramenta e os resultados so analisados primeira hora, como parte do scrum dirio. O papel de engenheiro de testes tem agora documentada sua responsabilidade pelo procedimento de manuteno da base de testes de regresso. tarefa dos Scrum Master revisar diariamente o backlog e questionar a possvel falta de tarefas relacionadas com a documentao obrigatria quando for pertinente pelo acordo com o cliente. Com todas estas melhorias, o Comit de Gesto espera obter benefcios significativos, manifestados nos objetivos de negcio. O QUE ACONTECEU AT AGORA 75. As mudanas introduzidas permitem supor que os resultados esperados de VER e VAL esto cobertos. 76. A direo est em dvida se deve esperar para implementar o Nvel C ou realizar antes uma avaliao do Nvel D. 77. Os resultados esperados de PCP e ITP so revisados, junto com aes resultantes de retrospectivas, e so tambm implementados aproveitando mudanas anteriores.
Capitulo 8
Pgina 139
Boria et al.
CAPTULO 9 - AMPLIANDO A CAPACIDADE DE DECISO (NVEL C do MPS-SW) 9.1 Uma Gesto Ambiciosa At aqui a gesto da T foi, nos dois anos e um ms que a acompanhamos, um processo slido, baseado em decises estruturadas e com um profundo sentido das opes possveis e os riscos que implicavam. O sucesso obtido com a implementao dos ajustes engenharia, realizados com nfase nos resultados esperados dos processos de Nvel D do modelo MPS, convenceram Marcela que a fonte onde bebem boa, e essa a mensagem que ela transmite direo. Na reunio mensal de dezembro, a mais importante do ano porque coincide com o fechamento do exerccio anual, Marcela faz seu anncio oficial: a j no mais to pequena Tahini-Tahini vai realizar uma avaliao conjunta do Nvel C do MPS-SW e do Nvel 3 (Definido) do CMMI-DEV no ano que vem. Ana, que j sabia do projeto, apoia animada. Alfredo olha para uma e para outra sem saber o que dizer. Os gmeos perguntam se os trs novos projetos que esto realizando, assim como as extenses aos sistemas de farmcia e hospital que esto sendo produzidas a cada semestre, podero receber o apoio dos recursos que necessitam ou se a demanda pelas avaliaes vai dificultar o sucesso deles. Marcela se dirige a Mariano, interrogando-o com o olhar. No h dvida, diz Mariano, as vantagens de entrar no mercado internacional com produtos inovadores como os nossos incomparvel. Podemos atrasar projetos e pagar as consequncias com juros se formos avaliados no Nvel 3 e isso nos trouxer s um cliente do Hemisfrio Norte. Mas isso no tem por que ser assim, diz Jssica, porque podemos alcanar esse cobiado prmio sem pararmos os projetos nem um segundo. At chegar o momento da avaliao, precisamos somente de fundos para dois recursos, um funcionrio em tempo integral e o outro, Mximo, para nos conduzir nas decises mais importantes . 9.2 Lder em Ao "Managers are people who do things right and leaders are people who do the right thing"
109 2
Marcela apresenta um quadro comparativo dos lucros ao usarem uma ferramenta nova (mais uma) que Jssica introduziu, a rvore de Deciso. Um dos caminhos da rvore representa o status quo, com os investimentos normais e os lucros esperados. Outro dos ramos mostra os investimentos a serem realizados para alcanar o nvel C e os benefcios esperados. Estes so derivados de um exerccio que realizaram Ana, Mariano e Cludio, analisando a expanso de mercado possvel com base nas melhorias de qualidade, assim como os benefcios internos imediatos vindos da diminuio dos custos. Um terceiro ramo mostra os custos e benefcios de alcanar tanto o nvel C do MPS quanto o nvel Definido do CMMI. Nesse ramo tambm se acrescenta a expanso do mercado do hemisfrio norte. Mariano intervm para colocar que j iniciaram contato com uma importante farmacutica que 2 quer levar o produto da T ao mercado do Canad. Obter o Nvel de Maturidade 3, segundo Mariano, terminaria de convenc-los e fecharia o negcio. A votao unnime a favor da avaliao conjunta. A Tabela 9.1 mostra os clculos realizados pela rvore da Figura 9.1. Marcela elabora mais sobre os trs aspectos que so muito importantes para o nvel C do MRMPS-SW: Formalizar a gesto de riscos, a gesto das decises e desenvolver mtodos para que o reuso seja sistemtico. Os trs pontos, afirma Marcela, j esto em nossos processos. s uma questo de detalhar ainda mais, coloc-los no papel e documentar seu uso de maneira mais explcita. Os gmeos ficam contra o expresso usada por Marcela: Alberto a acusa de ser ecologicamente incorreta por falar em papel. Armando explica que em um mundo sem rvores, o oxignio passa a ser um bem dos muito ricos. O ambiente fica mais tranquilo e a reunio termina com um brinde: os Galarraga fazem aniversrio e trouxeram para a mesa de trabalho Champagne Mumm Cordon Rouge, que acaba em poucos minutos.
109
[BENNIS, 1997], Learning to Lead
Capitulo 9
Pgina 140
Boria et al.
Figura 9.1: rvore de Deciso
Status Quo Entradas 32,1 Probabilidade Expectativa ROI 0,98 31,458 6,158 Gastos 25,3 1 25,3
Nvel C Entradas 0,8 0,9 0,72 0,688 Gastos 0,032 1 0,032
SCAMPI Entradas 1,6 0,85 1,36 1,291
110
Gastos 0,069 1 0,069
Tabela 9.1: Tabela de Pagamentos da rvore de Deciso
9.3 Viso Estratgica dos Riscos A T , h mais de um ano, comeou a aproveitar os conhecimentos adquiridos pelo pessoal, criando ativos em seus arquivos. A biblioteca de processos continuamente atualizada e melhorada. Os engenheiros, que j passam de cento e vinte, formam naturalmente grupos de interesse em cada uma das disciplinas. As anomalias na entrega dos produtos e os atrasos nos projetos esto comeando a serem vistos como excees e no como regra. Quando aparecem problemas, eles so rapidamente identificados e resolvidos. Os engenheiros esto alertas, detectando os padres que permitem se anteciparem aos problemas e introduziram um mtodo simples para capturar estes padres em uma tabela. Sobre essa base, Marcela elabora um procedimento de riscos que compatvel com o atual e cobre os resultados esperados do processo Gerncia de Riscos do MPS-SW. Consciente dos desvios e excessos no uso da pala vra risco, como ilustra seu abuso em 111 vrias tabelas que j vimos no Captulo 8 , Marcela define com preciso o significado e o uso 2 2 do termo dentro da T . Seguindo o uso do IEEE, do MPS e do CMMI, Risco na T um problema potencial, quer dizer, algo que ainda no ocorreu. Existe risco em todas as 112 atividades, porque o futuro incerto. atribuda a Niels Bohr a frase: Nada mais difcil de prever que o futuro e ironias parte, nada mais certo de acordo com nosso conhecimento 2 cientfico. Marcela escolhe a forma mais ampla de definir um risco. Seu uso na T parte da definio de problema. Habitualmente, reconhecemos um problema como uma situao incmoda, chata, um obstculo em nossa vida ou no processo de negcios. , definitivamente, algo ruim. Se olharmos o problema como um problema intelectual, algo que nos desafia a
2
110
SCAMPI a sigla de Standard CMMI Appraisal Method for Process Improvement, o mtodo padro e oficial de avaliar a maturidade de processos em relao ao modelo CMMI. 111 Nas tabelas derivadas das retrospectivas, a primeira coluna intitulada riscos, apesar de que so problemas j detectados ou incidentes. A segunda se intitula mitigao embora na realidade seja um plano de ao para resolver o problema. 112 http://www.aps.org/policy/reports/popa-reports/energy/modeling.cfm
Capitulo 9
Pgina 141
Boria et al.
encontrar uma melhoria mesmo quando a situao no to ruim, teremos uma melhor definio de problema. Para classific-lo de algum modo que ajude a esclarecer, podemos falar de: problemas de desempenho quando a situao atual pior do que a esperada; problemas de melhoria quando a situao atual no to boa quanto desejamos; e problemas de manuteno quando a situao atual deve ser mantida. Nesse caso, h riscos de trs tipos, o primeiro dos tipos coincide com a definio habitual: Algo ruim que pode acontecer. A pergunta que feita por aquele que tenta identific-los o que pode nos impedir de obter o resultado esperado? O segundo tipo o risco de perder uma oportunidade. E st relacionado com a inovao e o chamaremos risco de oportunidade. A pergunta que se faz para tentar identificlo o que estamos deixando de considerar que pode nos dar uma vantagem competitiva? Est claro que esta segunda pergunta ser muito menos frequente do que a primeira, mas de qualquer modo, Marcela prope estender o escopo a todos os aspectos do negcio, por exemplo as contrataes, os fornecedores, os salrios, a tecnologia, a localizao dos 113 2 escritrios e at os mtodos de avaliao . Uma modificao na poltica de qualidade da T define o escopo da aplicao da gesto de riscos com preciso. O que Marcela prope que todos os que trabalham na T , de Alfredo ao engenheiro mais recentemente incorporado, vejam seu trabalho como uma srie infinita de tomada de decises, cada uma delas com suas consequncias. Ao colocar opes para essas decises, a pessoa precisa perguntar-se, ou perguntar, no caso daqueles que possuem capacidades de direo: qual o risco? Marcela pensa em uma organizao consciente de seus riscos, no em uma que evita os riscos em todos os casos. Ser consciente de um risco compreender o impacto que ele traz caso se materialize, quer dizer, deixar de ser um risco para se converter em um problema. A probabilidade de que um risco se materialize importante para fazer uma avaliao de como atuar a respeito. Por exemplo, no se pode descartar que, antes de finalizar o ano, um meteorito destrua a cidade em que moramos e trabalharmos, com as bvias nefastas consequncias para os indivduos que moram nela e nossos clientes, mesmo aqueles que vivem em outros pases. Mas o evento tem baixssima probabilidade de ocorrer, por isso preferimos ignor-lo. Esta uma das possveis respostas frente a um risco: assumi-lo e continuar com o plano. H dois motivos pelos quais se assume um risco: ou a probabilidade to baixa que qualquer investimento em mitig-lo ou planejar contingncias muito caro, ou estes gastos so to altos que no justificam sua realizao, porque o remdio pior do que a doena. Se um risco muito grande, talvez no haja mitigao possvel, mas isso coloca em questo se vale a pena continuar com o projeto. Marcela define o processo de gesto de riscos desde o primeiro contato de vendas. Parte do processo de Mariano deve ser analisar os riscos antes de apresentar uma proposta. Cludio colaborar na anlise financeira, valor presente, perodo de amortizao e outras maneiras de 114 analisar o risco monetrio. A cada momento, os passos definidos por Boehm so seguidos: H duas etapas, a da avaliao e a do controle dos riscos. Na etapa de avaliao so distinguidas as seguintes atividades: Identificao, Anlise e Priorizao. Na de controle, as atividades so: Planejamento, Resoluo e Monitorao. Nos detalhes de cada atividade, Marcela tomou a liberdade de adapt-las s necessidades da empresa. Fase pr-venda Fonte de riscos a avaliar cliente domnio Categorias alto
novo, processos fracos, 115 teoria X de gesto desconhecido, baixa tecnologia, alto impacto em clientes do cliente inovadora, novas API, novas ferramentas existem bons fornecedores com
2
mdio
novo, processos OK, gesto moderna conhecido em parte, tecnologia moderna, impacto mdio em clientes do cliente conhecida, algumas novas ferramentas existem bons fornecedores com
baixo
conhecido, processos OK, gesto moderna conhecido, tecnologia avanada, impacto administrvel no cliente conhecida e compatvel 100% dominamos o mercado
tecnologia concorrncia
113 114 115
J vimos no Captulo 8 que a avaliao anual foi eliminada, substituda pela avaliao contnua. BOEHM, B., 1989, Software Risk Management. http://en.wikipedia.org/wiki/Theory_X_and_Theory_Y
Capitulo 9
Pgina 142
Boria et al.
muita experincia
nossa prpria experincia algo de reuso, mas no em certos mdulos crticos possvel modular a funcionalidade para reduzir a durao entende o problema, mas est limitado em sua capacidade de deciso um pouco mais alto que o habitual por sua durao preciso se esticar um pouco para poder corrigir o sprint anterior, mas administrvel h presso para incluir sempre um pouco mais, mas h possibilidade de diminuir o ritmo a cada dois sprints o dono do produto duvida do que necessita ficam coisas para corrigir, mas entram no sprint se no surgirem alguns defeitos mascarados o dono do produto negocia qualidade por data de entrega fundamentalmente adaptaes a nossos produtos prefervel qualidade no que entregue do que muitas funes operacional, resolutivo, independente, capaz
reuso kickoff tradeoff de sprints com requisitos dono do produto
escassa probabilidade de reuso muitas funcionalidades para o release planejado no entende o problema e est totalmente impedido de tomar decises muito alto, relacionado com a tecnologia a ser incorporada e a curva de aprendizagem nunca h tempo para corrigir porque o novo sempre tem maior prioridade h presso por incluir sempre um pouco mais
custo do projeto
habitual
sprints
desenvolvimento novo x correes
o dono do produto entende os problemas e apoia que sejam solucionados antes de chegar estabilizao pode-se descartar alguma histria se no se chega com a data
muita funcionalidade
requisitos fracos estabilizao custo de manuteno
o dono do produto no sabe definir com clareza o que precisa no houve muito tempo para corrigir e o sprint de estabilizao curto o dono do produto rgido a respeito da data de entrega e no h negociao
o dono do produto sabe o que necessita e sabe explicar chegamos com muito pouco para corrigir, possvel usar tempo para refazer o dono do produto prefere um produto estvel que seja entregue a tempo
entrega atrasada
Tabela 9.2: Estratgia de Riscos de Alto Nvel, Fontes e Categoria
A estratgia refinada depois da pr-venda. A aquisio de conhecimento acerca dos riscos abarca as fontes, categorias e as medidas associadas a sua eliminao, mitigao, transferncia, diminuio ou tratamento da contingncia. J existem certas mitigaes que foram detectadas e formam parte do conhecimento armazenado. Por exemplo, a primeira 2 deciso de um projeto o mtodo organizacional que vai ser usado. Na T os ciclos de vida autorizados esto associados ao tipo de projeto, para mitigar os riscos: Kanban para projetos muito simples com tarefas tcnicas difceis de separar em sashimi e que duram algo mais do que o habitual, Scrum para a maior parte dos projetos e FDD para aqueles projetos onde o volume de trabalho to grande que uma pirmide de Scrums faria com que, de fato, estivessem trabalhando em uma cascata simples. De fato, FDD no foi utilizado ainda; a organizao no quer correr o risco de introduzi-lo quando o cliente no suficientemente compreensivo. 9.4 Definio de um Risco Detectar o risco no equivalente a defini-lo corretamente. Para poder fazer a gesto do risco mais efetiva e eficiente importante dedicar tempo redao da definio do risco. Deve-se indicar claramente a situao atual, presente ou potencial que dispara o risco. Esta formulao diferencia entre J que e Pode ser que. Por exemplo, J que nossa nica especialista em sistemas de bases de dados persistentes ficou grvida do primeiro tipo, a situao j est presente. O segundo caso em si mesmo provvel, por exemplo, Pode ser que os componentes A e B, por terem sido comprados de fabricantes diferentes, no sejam compatveis entre si. Neste caso no se sabe com certeza se isso real, mas existe a
Capitulo 9
Pgina 143
Boria et al.
suspeita de que pode ser. A segunda parte do enunciado do risco deve apontar as consequncias. Nos casos em que nosso enunciado do risco comea com j que , o resto da definio deve deixar claro que h uma probabilidade de que a consequncia se materialize sem termos certeza. Por exemplo, o enunciado J que nossa nica especialista em sistemas de bases de dados persistentes ficou grvida, seguramente no poderemos terminar no prazo no um risco, um problema manifestado. Alm do mais, est descrito de tal maneira que no possvel analisar as condies resultantes na perda (no terminar no prazo). Por outro lado, J que nossa nica especialista em sistemas de bases de dados persistentes ficou grvida provvel que tenha que parar de ir empresa durante os meses finais, por isso possvel que nosso sprint se ressinta de estabilizao ao no poder contar com ela 24x7 est redigido em termos de risco e nos d claras indicaes de por onde atac-lo. possvel montar um ambiente de tal maneira que ela possa participar no sprint de sua casa, ou treinar mais pessoas para que ela possa dirigi-los remotamente com pouca interao, ou conseguir algum que possa substitu-la para esse sprint. Como se pode ver, importante redigir o enunciado do risco de maneira que seja claro qual a fonte do problema, no a gravidez nem a ausncia, mas a falta de experincia no momento do sprint da estabilizao. A definio em termos de pode ser que semelhante, seguindo o exemplo, Pode ser que os componentes A e B, por terem sido comprados de fabricantes diferentes, no sejam 116 compatveis entre si, e tenhamos que investir muito esforo para fazer envoltrios que montem API compatveis entre eles. Perceba que o enunciado Dado que os componentes A e B, por terem sido comprados de fabricantes diferentes, no so compatveis entre si, devemos investir muito esforo para fazer envoltrios que montem API compatveis entre eles no faz meno probabilidade, um problema que j existe e at anuncia o plano de ao a seguir. 9.5 Captura dos Riscos Marcela adaptou uma planilha para que sirva na captura e gesto de riscos.
Figura 9.2: Planilha de Definio, Monitorao e Controle de Riscos
Ao explicar a planilha ficar claro o procedimento de definio, anlise, priorizao, 2 monitorao e controle de riscos na T . A planilha comea com uma lista de dados correspondentes ao projeto em questo. As colunas da esquerda para a direita contm: o ndice do risco, um nmero natural; o enunciado do risco, dividido em Condio e Consequncia; a probabilidade de que o risco se materialize, quer dizer, que se transforme em um problema, calculada arbitrariamente como um nmero real entre zero e um (nem zero, porque ento no seria necessrio controlar esse risco por ser impossvel que afete o projeto, nem um, porque ento j um problema); a perda estimada para o projeto caso o risco se materialize, medida em uma escala de um a cem; a exposio que traz o risco, definida como o
116
Na Tecnologia da Informao, um envoltrio (wrapping) so os dados que precedem ou marcam os principais dados de um programa, ou um programa que coloca em marcha outro programa para que possa executar corretamente. Em particular, em programao, um envoltrio um programa ou script que estabelece as bases e torna possvel o funcionamento de outro programa mais importante.
Capitulo 9
Pgina 144
Boria et al.
produto entre probabilidade e perda, e que o valor usado para priorizar o risco entre os demais (uma maior exposio implica em maior prioridade); a ordem de prioridade que ocupa esse risco nesta anlise, onde 1 o de maior prioridade e 10 o de menor; a mesma informao a respeito da ltima vez que se realizou o exerccio de controle de riscos; o nmero de vezes que o risco est na lista, o que indicativo de sua maturidade ou no; a ao, seja eliminao, mitigao, transferncia, diminuio ou tratamento da contingncia que ser tomada, incluindo, quando um plano de contingncia, um disparador para iniciar a contingncia; e quem vai levar adiante as aes e quando vai informar seu resultado. 9.6 Estratgias de Controle de Riscos Em toda estratgia, o que conta a sequncia dos esforos. A primeira parte de uma anlise estratgica consiste em identificar os riscos e prioriz-los. Depois de conhecido o inimigo, agora preciso estimar os esforos que vamos dedicar a combat-lo. Cada atividade tem seu custo e este custo no pode ser tal que o projeto se ressinta por eles. Em primeiro lugar, as 2 2 estratgias da T (a T tem em seus guias de controle de riscos duas estratgias para serem aplicadas nos projetos) comeam por analisar se possvel ou desejvel a eliminao do risco. Dado o exemplo da seo anterior, Pode ser que os componentes A e B, por terem sido comprados de fabricantes diferentes, no sejam compatveis entre si e devemos investir muito esforo em criar envoltrios que montem API compatveis entre eles deveramos ver se podemos eliminar esse risco. Uma alternativa sugerida que construamos os componentes internamente. Isso modifica o projeto, os custos e a estrutura da equipe, trazendo seus prprios riscos. Outra que desistamos do projeto. Uma terceira buscarmos obter mais informao. Se fizssemos um pequeno ensaio em um ambiente especialmente criado para isso e vssemos se A e B so realmente incompatveis, poderamos tomar melhores decises e eliminar o risco de nossa lista. Caso seja impossvel elimin-lo, o prximo passo tentar transferi-lo. Caso seja o cliente quem exige o uso dos componentes, ou se quem tem parmetros rgidos sobre a data de entrega ou o custo, deveramos ser capazes de ir at ele e explicar o risco, pedindo uma clusula de risco que cubra o trabalho extra de construir os envoltrios para gerar a compatibilidade entre eles, clusula que entra em vigor se o risco se materializar. Se formos ns mesmos que 117 tomamos a deciso apressadamente , ento abusivo que tentemos fazer isto. No entanto, possvel que as vantagens de usar A e B sejam to grandes que possamos negociar algum compromisso. Por exemplo, pode ser que se, ao invs de B usarmos C, o resultado seja uma perda menor de desempenho, mas um lucro muito grande em compatibilidade. Deste modo, transfere-se o risco de incompatibilidade a um risco de desempenho. Quando no se pode eliminar ou transferir o risco, o procedimento pede que se tente mitig-lo. A mitigao bem-sucedida desde que reduza a exposio que o risco causa ao projeto. Isto pode ser realizado de duas maneiras: ou reduzida a probabilidade de que o risco se materialize ou reduzida a perda que o risco provoca. Seguindo com nosso exemplo, j que a 118 situao de incompatibilidade nosso gato de Schrdinger , j que a incompatibilidade existe ou no, s que no sabemos, impossvel mitigar a probabilidade de que sejam incompatveis. Nossa nica esperana mitigar o impacto, a perda. A perda que expressamos como o esforo investido para construir artificialmente essa compatibilidade. possvel diminulo? Deixemos este exerccio da imaginao a cargo do leitor, porque no nos ocorre como. Por ltimo, se todos os demais fracassam ou se suspeitamos que as aes podem no ser 2 efetivas, o procedimento da T chama o tratamento da contingncia. Entende-se por isto que se planeja tomar aes que atuam contra o risco como problema. No caso do exemplo anterior, a contingncia que sejam efetivamente incompatveis. Nesse caso ser preciso construir os envoltrios para que se comuniquem por meio deles. Quanto que podemos esperar antes de
117
Tarefa para Marcela: modificar o mtodo de deciso de aquisies para incluir na lista de verificao a compatibilidade entre componentes quando mais de um comprado. 118 Gato de Schrdinger: um experimento imaginrio concebido em 1935 pelo fsico Erwin Schrdinger para expor uma das consequncias menos intuitivas da mecnica quntica. Um gato, junto com um matraz (recipiente de vidro) que contm um veneno e uma fonte radiativa, so colocados em uma caixa fechada. Se um contador Geiger detecta a radiao, o frasco se rompe, liberando o veneno que mata o gato. A interpretao da mecnica quntica da Escola de Copenhague implica que, depois de um tempo, o gato est ao mesmo tempo vivo e morto.
Capitulo 9
Pgina 145
Boria et al.
incorrer nesse gasto-extra? Como nosso enunciado pode ser que, isso indica que no estamos seguros da incompatibilidade, s temerosos de que ocorra. Comear a trabalhar nos envoltrios antes de estarmos seguros uma perda de esforo. escolhido um evento ou uma data como disparador desse esforo e possivelmente ser revisto o plano de sprints para contempl-lo. 9.7 Estratgia Conjunta O guia de controle de riscos contempla o procedimento de tratamento a cada risco, mas a vida no to simples. Como organizar os esforos se os riscos que preciso atender so mltiplos? Marcela identificou dois mtodos, um simples e fcil de aplicar, a matriz de riscos (Figura 9.3), e outro mais sofisticado, que se chama o espectro de riscos. Vejamos primeiro o mais simples.
Figura 9.3: Matriz de Riscos
Os riscos esto localizados na matriz da Figura 9.3, construda como se v sobre dois eixos, a perda na vertical e a probabilidade de ocorrncia no horizontal. Foram escolhidos cinco intervalos em cada eixo, embora pudesse ter sido outro nmero. A estratgia conjunta consiste em adaptar as atividades ao grau de risco que possui cada um. Desse modo no se investe tempo em tentar eliminar defeitos que tm pouco impacto. As atividades relacionadas com os intervalos de cores diferentes so listadas direita do desenho. O outro mtodo o do espectro de riscos. O guia de controle de riscos o prope para projetos que tenham muitos riscos, mas cuja importncia estratgica faz com que valha a pena lev-los adiante de todos os modos. Nesse caso, designada uma quantidade de dinheiro no oramento ou de esforo para o tratamento dos riscos, e se avalia qual a melhor forma de investi-lo. Costuma ocorrer que a distribuio da exposio siga um padro parecido com o espectro luminoso, no sendo distribudo uniformemente; mas h segmentos com um nmero maior deles do que outras de igual tamanho. Simplesmente dividir o oramento de modo que atribua mais ao primeiro risco, menos ao segundo e assim sucessivamente, no cumpre com o objetivo de usar o esforo da melhor maneira possvel. Vejamos um exemplo: ID 1 2 3 4 5 6 7 8 Probabilidade Perda Exposio 0,8 0,8 0,8 0,8 0,6 0,5 0,5 0,5 90 84 69 66 64 71 40 32 72 67,2 55,2 52,8 38,4 35,5 20 16
Capitulo 9
Pgina 146
Boria et al.
9 10
0,3 0,3
37 33
11,1 9,9
Tabela 9.3: Exemplo de Tabela (Parcial) de Riscos
Os dois primeiros riscos esto muito prximos entre si. Como os nmeros foram estimados para a perda e a probabilidade em cada caso, sem contar com um raciocnio muito slido por trs, difcil assegurar que o risco 1 maior em exposio que o 2. Uma tcnica que pode ser aplicada a anlise de sensibilidade, que veremos depois, para entender melhor as variveis em jogo. A melhor estratgia consider-los da mesma categoria e trat-los como iguais. O mesmo acontece com os dois seguintes. Isto sugere que possvel dividir o oramento para tratamento de riscos entre as duas primeiras categorias e simplesmente monitorar as restantes. A proporo em que os recursos so repartidos fica a critrio de cada equipe. Marcela introduz os gmeos aos pontos difceis do MPS e recruta sua ajuda para estabelecer a lacuna com a Gesto de Riscos. Os gmeos concordam com ela de que o escopo da gerncia de riscos est bem estabelecido na poltica de qualidade e que pode ser aplicada 2 universalmente na T . Colocam GRI 1 ao lado dos resultados alcanados. O Guia de Riscos descreve as fontes e categorias dos riscos, assim como os parmetros para analis-los, prioriz-los e controlar o esforo que realizado (GRI 2). As estratgias completam algumas destas coisas com ainda maior detalhe (GRI 3). Cada projeto que usou este mtodo e a documentao conforme discutida nas reunies mensais do comit de gesto estratgica (GRI 4, GRI 5, GRI 6). revisada a cada semana, a cada quinzena ou a cada ms, segundo dita a estratgia fixada, utilizando a planilha para esse fim (GRI 7 e GRI 8). As aes correspondentes, sejam de eliminao, mitigao, transferncia ou contingncia, so documentadas e monitoradas para assegurar sua efetividade (GRI 9). Marcela est satisfeita, o 2 Guia de Gesto de Riscos da T est de acordo com o MPS. O QUE ACONTECEU AT AGORA 78. Depois de um perodo de seis meses de estabilidade, Marcela anuncia os planos para passar ao Nvel C em uma avaliao conjunta. 79. Jssica introduz uma nova ferramenta de decises, a rvore de deciso. 80. Baseando-se nas apresentaes de Marcela e nos resultados da rvore da deciso, o Comit de Gesto aprova de maneira unnime o investimento para alcanar o Nvel C do MPS-SW em uma avaliao conjunta com um SCAMPI de Nvel Definido (3). 81. A primeira implementao do Nvel C a do processo gerncia de riscos, que construdo e implantado em tempo recorde. 82. Depois de divulgado o uso do Guia de Gesto de Riscos da T , Marcela e os gmeos constatam que cobre todos os resultados esperados de GRI no MPS. 9.8 Nota de Cautela O especialista em risco, economista e financista, Nassim Nicholas Taleb dedicou sua vida a analisar questes relacionadas com o acaso e a probabilidade. Seus dois ltimos livros, [TALEB, 2010] e [TALEB, 2012] exploram o imprevisto. Sua tese que a normalidade das coisas no importante, que o que realmente modela o mundo o acaso, os grandes acontecimentos imprevisveis, que ele chama cisnes negros. Seus livros esto cheios de exemplos, incluindo a peste negra e a ocupao da Amrica pelos europeus no sculo XVI, de acontecimentos que pareciam impossveis gerao que os vivia e que mudaram as vidas das 119 pessoas e as trajetrias das naes. Esta viso do acaso, compartilhada em outras cincias , fora as organizaes a repensar sua estrutura e a administrao do risco. J que um cisne negro no pode ser previsto, imprescindvel organizar-se para que a sua chegada no seja destrutiva no curto, mdio e longo prazo. No curto prazo, as empresas e organizaes deveriam criar planos de contingncia alinhados com sua sobrevivncia ante desastres, ao estilo de [TOIGO, 2002]. No mdio prazo, as empresas e organizaes precisam ter a
2
119
a tese dominante no neodarwinismo, ver por exemplo, Dinosaur in a Haystack: Reflections in Natural History, [GOULD, 1996].
Capitulo 9
Pgina 147
Boria et al.
flexibilidade e a adaptabilidade para no s tolerar as novas circunstncias, mas aproveit-las. No longo prazo, as empresas e as organizaes devem saber que se ficarem paralisadas, o prximo cisne negro poder destru-las e, por isso, devem se segmentar, dividir e multiplicar sem endurecer seus canais de informao. 9.9 Decises Formais Do mesmo modo que os riscos so analisados seguindo procedimentos bem definidos para agregar valor, recolhendo novos riscos e as solues correspondentes que devem ser consideradas, h decises especiais que so tomadas, quando necessrio, com base em 120 mtodos formais . O propsito de usar mtodos formais ao tomar decises que, seguindo um padro formal, podem armazenar, comparar, analisar e reutilizar as decises baseando-se 2 nos resultados que produzem. A princpio, a T tinha s mtodos muito bsicos, baseados em matrizes de Pugh com pesos entre alternativas, mas a importncia das decises tornou clara a necessidade de ferramentas mais potentes, incluindo rvores de deciso, simulaes, modelos 2 e correlaes simples. A T comeou, corretamente, o avano no caminho da alta maturidade em seus processos estratgicos. Vejamos como foi feito. Novamente Marcela com sua bagagem do Mestrado em Administrao 121 recorreu a um professor seu, o Dr. Zito, que recomendou vrias leituras , das quais extraiu 2 Marcela poderosas ideias que transformou em um Guia de Aplicao de Decises da T . O Guia parte do material usado na integrao de novo pessoal. A justificativa reside em que, em todo projeto de software, frequentemente a equipe se enfrenta com a necessidade de tomar uma deciso. Em quase todas essas ocasies, as alternativas so claras e as variveis que as diferenciam so visivelmente observveis e fceis de comparar. Selecionar entre as alternativas acaba sendo simples e justificar a deciso tampouco implica um custo extra para a equipe: as caractersticas da soluo so bvias, a gerao de alternativas simples e a deciso uma consequncia lgica de aplicar bem os passos anteriores. Nesses casos, a aplicao documentada de um processo formal desnecessria. Mas em algumas ocasies, a deciso significa um risco muito alto para o projeto e acaba sendo pouco aconselhvel tom-la de maneira informal. As decises difceis no mudaro por serem tomadas formalmente, mas se o procedimento formal executado passo a passo, a organizao em seu conjunto consegue aprender de seus erros quando estes so cometidos. De outra maneira, as mesmas decises podem ser tomadas vrias vezes em diferentes projetos sem que haja necessariamente ocorrido uma aprendizagem de um para outro. O Guia formaliza o processo de tomada de decises para garantir que sejam geradas e capturadas todas as informaes necessrias, de modo que, se a deciso for acertada, pode ser repetida e se no for, que possa ser analisado o que foi decidido para melhorar essa deciso em futuros projetos. O Procedimento de Anlise de Alternativas e Tomada de Decises (PAAeTdD) permite organizao tomar decises de maneira consistente. Em particular, o PAAeTdD ajuda os participantes a tomarem decises difceis, aquelas que implicam riscos a bens ou pessoas. O PAAeTdD um procedimento sistemtico que descreve passo a passo as atividades a serem realizadas para poder formalizar a gerao, documentao, avaliao e seleo de alternativas entre o espao de solues de um problema. Consiste em identificar claramente o problema a resolver, estabelecer objetivos da soluo (seus atributos), gerar (identificar) alternativas, descompor o problema e model-lo, medir as alternativas contra o mtodo de avaliao e selecionar a melhor entre elas. O Procedimento de Anlise de Alternativas e Tomada de Decises (PAAeTdD) no foi construdo com o propsito de ser aplicado a todas as decises que so tomadas em uma equipe. A lista que segue pretende ser um guia da aplicao do procedimento, no necessariamente exaustiva. O PAAeTdD pode ser utilizado em mltiplas ocasies, conforme seja til, a critrio da equipe ou da gerncia da organizao. Para a aplicao do PAAeTdD, o Guia estabelece parmetros claros: deve ser utilizado quando a equipe enfrenta decises que tm uma ou mais das seguintes caractersticas: (a) A deciso est relacionada com um tpico que considerado de alto risco e que est sendo monitorado formalmente, ou (b) A deciso afeta o plano de trabalho de modo que impacta em mais de 5%
120 121
De fato, na literatura h muitas publicaes que falam ao mesmo tempo de riscos e decises formais. Em particular, o Dr. Zito recomendou o livro de CLEMEN, 1997, mas Marcela tambm achou til um livro muito mais simples, Decision Analysis in Projects. Learn to Make Faster, More Confident Decisions , de [SCHUYLER, 1996].
Capitulo 9
Pgina 148
Boria et al.
da baseline do produto, ou (c) A deciso afeta o plano de trabalho de modo que impacta em mais de 5% do oramento, ou (d) A deciso afeta o plano de trabalho de modo que impacta em mais de 5% a data de entrega do produto, ou (e) A deciso afeta o plano de trabalho de modo que impacta em mais de 5% na qualidade final do produto, ou (f) O cliente requer que a tomada de decises fique integralmente documentada para a deciso em questo, ou (g) O impacto estimado da deciso supera em mais de 100% o custo esperado de aplicar o procedimento PAAeTdD. O PAAeTdD contm os seguintes passos: 1. 2. 3. 4. 5. 6. 7. 8. Definir corretamente o problema a ser resolvido. Estabelecer atributos desejveis da soluo. Definir mtodos de medio dos atributos selecionados. Criar mtodos de avaliao das solues. Gerar ou descobrir solues alternativas. Aplicar a cada soluo gerada a medio dos atributos desejveis. Avaliar mediante os mtodos selecionados as solues geradas. Selecionar a melhor alternativa.
Tabela 9.4: Definio dos Passos do PAAeTdD
Desenvolveremos cada um dos passos com um pouco mais de detalhe. Comeamos pelo passo 1, Definio do Problema. O propsito deste passo estabelecer o enfoque do problema e assegurar que se pretende resolver o problema correto. Busca-se alinhar o enfoque com os objetivos de negcio da organizao e identificar as causas principais do problema, para uslas como entrada ao passo da seleo de solues alternativas. As tarefas envolvidas so Fixar os objetivos de Resoluo do Problema; Identificar e listar diferentes pontos de vista sobre o que constitui o problema; Reduzir por agrupamento o nmero de temas a uma quantidade administrvel; Organizar os temas em ordem de importncia para o objetivo do projeto; Realizar uma anlise das causas profundas dos possveis problemas; Listar cada uma das causas profundas consideradas e reduzi-las por agrupamento; Dividir as causas em trs grandes categorias: imediatas, prximas, a considerar alguma vez. Os passos exigem que os participantes estejam capacitados para realizar brainstorms, agrupamento de temas e o uso de ferramentas como o diagrama de causa-efeito, hierarquia de objetivos, diagrama de Ishikawa ou diagrama de espinha de peixe. Tambm devem ser suficientemente responsveis para poder realizar uma triagem dos problemas. O passo 2, Atributos da Soluo tem como propsito estabelecer os objetivos que precisam ser cumpridos por uma soluo, quer dizer, definir os atributos de uma soluo aceitvel em termos dos objetivos. A nica tarefa identificar os atributos de uma boa soluo. O passo 3, Mtodos de Medio tem como propsito fixar medidas objetivas dos atributos que devem pertencer soluo escolhida. As tarefas envolvidas so as seguintes: Definir o indicador adequado para o atributo em questo, Descrever os critrios de anlise envolvidos no modelo de medio, Listar as medidas derivadas das medidas bsicas e as funes de composio requeridas, Listar as medidas bsicas e seu mtodo de medio, e Definir claramente as unidades de cada medida em cada nvel. O passo 4, Mtodos de Avaliao tem como propsito descrever o(s) mtodo(s) que permitam discriminar entre solues alternativas. As tarefas envolvidas so as seguintes: Hierarquizar e dar pesos relativos aos diferentes atributos das solues, Ponderar possveis relaes entre atributos considerados independentes, e Definir funes que ponderem os resultados obtidos por meio dos indicadores para que as solues possam ser comparadas. Em princpio, os atributos escolhidos para representar uma boa soluo so independentes uns dos outros. As diferentes solues exigem que seja realizada uma anlise dos pesos relativos entre os atributos para poder ponder-los, porque se no for assim os resultados, ao se encontrarem em um espao multidimensional, acabam sendo no comparveis. Este mecanismo conhecido como trade-off analysis. O passo 5, Solues Alternativas tem como propsito definir um conjunto de solues que possam resolver o problema. As tarefas envolvidas so as seguintes: Revisar a lista de causas profundas de realizao imediata, Gerar um ranking por prioridade de causa, e Sugerir solues alternativas a cada causa de problemas detectada. Apesar de esta atividade poder ser realizada de maneira imediata depois da identificao do problema, aconselhvel postergar sua realizao at que haja um conhecimento mais profundo da natureza da soluo, coisa que as atividades listadas antes podem fornecer. Por outro lado, possvel que durante a realizao da atividade 1. Definio do Problema seja natural a identificao de possveis
Capitulo 9
Pgina 149
Boria et al.
solues como resultado da tarefa Identificar causas profundas. Cada equipe e cada circunstncia devem indicar qual das duas opes a correta para a ocasio. O passo 6, Medies das Alternativas tem como propsito obter indicadores para cada soluo alternativa definida a partir da medio dos atributos predefinidos para poder avali-las. H s uma tarefa envolvida: Aplicar as medidas definidas em 3 (Mtodos de Medio) s alternativas identificadas em 5. (Solues Alternativas). O passo 7, Avaliao das Alternativas tem como propsito gerar a tabela final de resultados para poder selecionar a soluo a ser adotada. As tarefas envolvidas so: Calcular o valor de cada uma das alternativas utilizando os valores obtidos na medio dos atributos e a funo de avaliao antes definida, Ordenar as solues em ordem descendente e apresent-las em forma de tabela, Revisar os resultados e corrigir as ferramentas quando a ordem obtida contradiz o sentido comum. Chegando a este ponto, bom revisar o realizado ao longo de todo o processo, julgando-o a partir da tabela gerada. Se os resultados contradizem o sentido comum, bom se perguntar se este que deve ser modificado, ou se foram introduzidos erros de conceito nas funes definidas para medir e combinar medidas na construo do valor da soluo individual. O passo 8, Seleo da Melhor Alternativa tem como propsito o que diz o ttulo, obviamente. As tarefas envolvidas so: Revisar e explicar os resultados da tabela final, Identificar e expor prs e contras da melhor alternativa, Definir com preciso o impacto da alternativa em termos de planos e tarefas, e Obter consenso em adotar a soluo de melhor valor para a organizao. Um trao da maturidade organizacional a implementao inteligente de solues escolhidas por meio de mtodos objetivos. Neste ponto, a soluo deve ser implementada com detalhe para que a direo tome a deciso de maneira consciente e responsvel. Marcela se prope a acrescentar, alm disso, os mtodos ao repertrio de tomada de decises 2 da T . Primeiro, redige instrues para construir uma hierarquia de objetivos. Dado o problema que preciso identificar, procura-se o efeito que se tenta conseguir. Por exemplo, temos que decidir entre dois fornecedores de um produto. Qual o objetivo? Talvez haja muitos, de modo que entender qual o mais importante crucial para a deciso. Digamos que a equipe se divide entre os que acreditam que entregar a tempo o objetivo e aqueles que acreditam que entregar com qualidade o objetivo, e que a escolha surge clarament e, independente de quem escolha. Isso pode paralisar a deciso de forma completa, de modo que necessrio encontrar um objetivo de ordem maior que os contenha. Neste caso, poderia ser entregar a tempo e com qualidade, o que no ajuda muito; melhor seria entregar sempre no prazo. Este ltimo objetivo melhor porque nos leva a analisar o impacto, em projetos futuros, de entregar com baixa qualidade este produto (Figura 9.4). Quantos recursos estaro ausentes para realizar emendas no produto que entregamos com defeitos conhecidos? Isto leva rapidamente a outra ferramenta de pensamento, a rvore da deciso. Quando as decises esto conectadas, a matriz de Pugh no captura isso de maneira direta. necessria uma nova ferramenta, que j vimos no comeo deste captulo, na Figura 9.1, introduzida por Jssica para analisar a deciso de partir ou no para a avaliao de Nvel C e de faz-la, ou no, conjuntamente.
Figura 9.4: rvore de Objetivos
Capitulo 9
Pgina 150
Boria et al.
Quando aparece a probabilidade na anlise, e este o caso com frequncia na tomada de decises, pois o problema est inserido em um ambiente de relativa incerteza, a ferramenta 2 que considerada na T a rvore de deciso. A rvore nasce de um n-raiz do qual saem as primeiras decises, porque a rvore pode ser usada para tomar decises combinadas, sejam estas independentes ou no uma das outras. Por exemplo, pode-se usar para decidir entre fornecedores de um produto semelhante e, ao mesmo tempo, decidir se a manuteno deve ser contratada ou no (as decises so independentes) ou pode ser usada para decidir entre dois produtos, um com adaptaes e outro sem elas, e decidir conjuntamente se subcontratase a adaptao (as decises no so independentes, um dos ramos ficar vazio porque a deciso de adaptao s se aplica em um caso). Esta versatilidade para se adaptar a decises complexas o trao mais destacado da rvore da deciso. Tampouco h restries muito grandes sobre sua sintaxe, o importante que as ideias sejam expressas claramente. A tabela de pagamentos (Tabela 9.1) que acompanha a rvore de deciso exemplifica mais claramente a obteno de resultados. Para completar o exemplo, vejamos como se pode refinar a rvore para uma anlise de diferentes possibilidades no caso de se optar pelo Nvel C do MPS-SW (Figura 9.5), pensando que os benefcios podem ser diferentes com diferentes (ou as mesmas) probabilidades. Isto fcil de expressar em uma rvore de deciso.
Figura 9.5: rvore de Deciso Refinada
A tabela de pagamentos correspondente, com comentrios, mostrada na Figura 9.6.
Figura 9.6: Tabela de Pagamentos Correspondente rvore de Deciso Refinada
Marcela acrescenta outra tcnica ao repertrio, o diagrama de dependncias ou diagrama de influncias. Um diagrama de influncia uma representao visual simples em forma de grfico de um problema de deciso. Oferece uma maneira intuitiva de identificar e representar elementos essenciais de um problema deste tipo, incluindo objetivos, decises, elementos de incerteza ligados a probabilidade e s relaes entre eles. No grfico podemos diferenciar ns e arcos. Os arcos so dirigidos e representam relaes entre os ns. Os ns representam decises (ns quadrangulares, chamados ns de deciso), variveis aleatrias (ns ovais, chamados ns estocsticos) cujo valor conhecido s em probabilidade e tambm utilidades (ns em forma romboide, chamados ns de valor). Por exemplo, ampliando o diagrama de hierarquia de objetivos com decises de investimento em marketing podemos obter um diagrama de domnio como o que mostrado na Figura 9.7.
Capitulo 9
Pgina 151
Boria et al.
Figura 9.7: Diagrama de Influncias com Incluso de Outros Investimentos
No diagrama da Figura 9.7 assumimos que o tamanho do mercado uma varivel aleatria que no pode ser influenciada pelas decises que so tomadas. Isto poderia ser revisado, se o investimento em marketing pudesse alterar isto, por exemplo, incluindo clientes de outros pases. Tambm poderiam existir outras decises que influenciassem nessa varivel. De qualquer modo, naquelas variveis onde opera o acaso, manteremos ns estocsticos no diagrama embora sejam dependentes, como o caso de custos. Tambm possvel notar que a qualidade do produto influencia na cota do mercado e nos custos. O n nmero de licenas vendidas redundante, porque se desprende seu valor de cota de mercado e tamanho de mercado, mas o propsito de um diagrama de influncias mostrar as relaes, pelo que sua incluso no vulnera os objetivos. O diagrama de influncias uma ferramenta para a discusso de ideias, no um objetivo em si mesmo. Depois que se entendem as relaes entre as variveis so utilizadas outras tcnicas como apoio deciso. Um dos problemas de estimativas a insegurana sobre os valores estimados. Sua variao importante em funo de compreender o impacto de uma deciso. Suponhamos que o tamanho do mercado de vrios milhes de licenas possveis. Para fixar um nmero, digamos que se trata de 10.000.000 de licenas. Agora, se cada licena representa uma entrada de 1.000 dlares anuais, estamos falando de um mercado de 10.000.000.000 de dlares. Uma variao de um ponto na cota de mercado representa ento 100.000.000 de dlares. Parece razovel ento que sejam utilizados os meios mais potentes para as estimativas caso se trate de uma cota de 1% ou de 0,002%, sobretudo se a qualidade do produto tiver uma influncia decisiva neste valor. Este tipo de anlise, o de entender at que ponto a incerteza associada a seus parmetros numricos poderia fazer variar a utilidade esperada afetando as decises, ou em outras palavras, onde preciso investir em conhecimento para diminuir a incerteza, denomina-se anlise de sensibilidade e a ferramenta mais comum para realiz-la o diagrama de tornado. Estes diagramas mostram graficamente as mudanas que so produzidas na utilidade esperada quando varia uma quantidade ou valor especfico. Se vamos mudando uma a uma as variveis, mantendo as demais em seu valor original, obteremos uma classe de utilidades esperadas para cada uma delas. Estas classes so representadas como barras em um grfico. Estas barras so ordenadas de cima para baixo e da mais menos longa, de modo que o grfico fique parecido a um tornado. Os mais longos indicam que a mudana dos valores da varivel que representam implica uma maior mudana na utilidade esperada, o que o mesmo que dizer que a importncia de uma varivel ao alcanar um resultado maior quanto maior for a barra correspondente no diagrama de tornado. Geralmente, variam os valores entre dois extremos, o mnimo provvel e o mximo provvel, de modo que a incerteza refletida pode se refletir no impacto sobre o objetivo. Para as variveis que no mostram sensibilidade, investir em melhorar o conhecimento de sua incerteza no til, assim como melhorar seu valor em funo disso tampouco . O diagrama da Figura 9.8 foi construdo sem nenhuma base de frmulas, somente para ilustrar a forma que tm os diagramas de tornado. Se as frmulas que produziram esse diagrama existissem, do diagrama pode-se ler que o tamanho do mercado a varivel que mais influencia no objetivo de margens. Investir para ter melhor conhecimento desse tamanho sensato. Pelo contrrio, nosso objetivo de aumentar as margens parece ser inelstico relativamente ao oramento de Marketing. Seria melhor transferir esse oramento para
Capitulo 9
Pgina 152
Boria et al.
melhorar a qualidade do produto, que est sob nosso controle, para aumentar assim as margens.
Figura 9.8: Diagrama de Tornado
Para construir o diagrama de tornado, uma ferramenta til conhecer a dependncia estatstica entre as variveis. Este conhecimento se expressa em uma equao chamada de regresso que modela a relao entre uma varivel chamada dependente, em nosso caso Margens, e um conjunto de variveis independentes que influenciam no comportamento da varivel dependente. Este modelo assume a forma de uma equao Y = c 0 + c1 X1 + c2 X2 + + cn Xn + . Os coeficientes cj so os que determinam a variabilidade correspondente no diagrama de tornado. Um coeficiente muito grande em comparao aos demais permite supor que o impacto da variao da varivel independente correspondente maior que a dos demais. Isto, claro, est limitado a que tal variao seja possvel. O coeficiente c 0 o que estabelece a ordenada origem, quer dizer, o valor de Y quando todos os valores independentes so nulos. O coeficiente um artifcio, chama-se termo aleatrio e s existe para que se cumpra a igualdade. Se esse valor conhecido, ento se pode conhecer o ajuste da equao. O problema da regresso consiste em escolher uns valores determinados para os parmetros desconhecidos cj, de modo que a equao fique completamente especificada. Para isso necessrio um conjunto de observaes. Em uma observao qualquer i-sima (i=1, n) registrado o comportamento simultneo da varivel dependente e as variveis explicativas (as perturbaes aleatrias supostamente no so observveis). Mediante o uso de tcnicas estatsticas so obtidos tais coeficientes. Dada a existncia de mltiplas ferramentas de clculo de tais coeficientes (comeando pela Excel) e a natureza deste livro dispensaremos o leitor dos 122 detalhes matemticos e remetemos os interessados literatura clssica . O uso que se d 2 equao de regresso na T o de poder calcular os valores dependentes para uma rvore de deciso, mas veremos que deste modesto incio surge uma aplicao muito madura, no captulo seguinte. O QUE ACONTECEU AT AGORA 83. Marcela segue conselhos de seu professor e implementa um Guia de decises que cumpre claramente com os resultados do MPS para o processo GDE. 84. feito um piloto do processo para tomada de decises que aprovado para sua difuso. 85. Marcela acrescenta um Guia de Mtodos para que as decises no se limitem somente a matrizes de Pugh. 9.10 A Fbrica de Componentes Mariano chega muito excitado ao escritrio da T em uma tera-feira pela manh. Acaba de descer do avio que o trouxe de Toronto e convoca uma reunio urgente do comit de gesto. Sentado na sala de reunies espera que cheguem os demais. Um a um vo se cumprimentando, servem-se do primeiro cafezinho do dia e perguntam o motivo de tanta urgncia a Mariano, que sorri enigmaticamente e desvia a conversa para outros tpicos, como
122
[SPIEGEL, 2011] nosso livro de cabeceira para Estatstica Elementar.
Capitulo 9
Pgina 153
Boria et al.
a turbulncia que sempre acontece sobre o equador nos voos, ou a baixa temperatura que virou costume no interior dos avies. Por ltimo chegam Ana e Alfredo, que tiveram de passar antes pela creche. Mariano se levanta, respira fundo e comea sem poupar detalhes: Colegas da T , bem-vindos grande empresa. Ontem assinamos com a TransKND um acordo de entendimento para que financiem a reengenharia de nosso produto central para hospitais e farmcias. Seu financiamento cobre a criao de uma arquitetura de linha de produto orientada a servios, SOA. O investimento lhes d direitos de comercializao exclusivos em mercados internacionais, mas no d nenhum privilgio tcnico nem participao alguma em decises 2 financeiras internas da T . Neste momento o Board da TransKND est reunido em Toronto para ratificar ou recusar o acordo, do mesmo modo que ns estamos fazendo aqui. Revisemos o acordo. Em seguida, distribui cpias a cada um, com as partes importantes previamente marcadas. O Comit discute durante vrias horas; mas, ao finalizar a discusso, o acordo aprovado e encomendado a Mariano e Cludio a assinatura do contrato. Ana tambm vai participar na parte tcnica. Alcanado o resultado, Mariano liga para sua contraparte na TransKND e os empresrios se cumprimentam, chegaram ao mesmo resultado positivo no hemisfrio norte, h uma aliana. A reunio se dissolve antes que os gmeos tenham tempo de ir buscar mais Mumm. Assim que saem no corredor, Ana gruda em Marcela e solicita sua ajuda. As duas, com apoio dos demais, devem dar forma ao processo que ser utilizado para a reengenharia e sucessivamente, para que todos os projetos aproveitem a SOA. 9.11 Service Oriented Architecture (SOA) para Principiantes
123 2
SOA um conceito que aplicado na construo de sistemas distribudos de grande porte. Para compreender SOA fundamental entender as propriedades deste tipo de sistemas. Isto significa que preciso poder integrar cdigo legado, porque ningum pode parar as mquinas e voltar atrs na histria quando os sistemas j produziram milhes de linhas de cdigo. Assim, um projeto de SOA mais parecido com um projeto de reengenharia do que com um projeto de desenvolvimento. Envolve mudar a estrutura de um sistema, mas sem reescrev-lo. preciso desacoplar e envolver os servios que j esto sendo fornecidos para transform-los em um formato que permita construir facilmente a partir das partes resultantes. Os servios so unidades de funcionalidade no associadas, fracamente acopladas, que no tm chamadas entre si. Cada servio se refere a uma ao, como preencher um formulrio online para uma conta, ou ver um extrato de conta online, ou a solicitao de uma reserva online ou comprar passagens de avio. Os desenvolvedores que utilizam SOA associam objetos individuais (servios) de SOA mediante o uso da instrumentao. No processo de instrumentao da funcionalidade, o desenvolvedor de software associa servios em uma disposio no hierrquica a uma ferramenta de software que contm uma lista completa de todos os servios disponveis, suas caractersticas, assim como os meios para construir uma aplicao que utilize estas fontes. necessrio ento que haja um sistema de comunicao heterogneo para que se possa compatibilizar arquiteturas de dcadas anteriores com os ltimos avanos tecnolgicos. Vejamos o produto estrela da T , o sistema que vincula o estado de cada paciente com seu histrico clnico, a medicao e a farmcia do hospital, assim como suas farmcias fornecedoras. J tem trs anos de desenvolvimento e cresceu mais de um milho e meio de linhas de cdigo. H muitas regras de negcio embutidas que no podem ser jogadas fora ou recodificadas em novas linguagens e provadas em novos ambientes. imprescindvel preserv-las. Isto sugere que faamos as menores mudanas possveis. Mas agora imaginemos o novo grande produto da T , o sistema hospitalar, hoje pendurado na nuvem, mas conectando enfermeiros, mdicos, pacientes, familiares dos pacientes, sistemas de ambulncia e todos os outros integrantes da grande famlia da indstria da sade. preciso desacoplar o cdigo das interfaces e gerar um protocolo para que os telefones, os Blackberry, os tablets, os laptops, e toda outra futura inveno que usem correntes de bits possam aproveitar essas regras de negcio e aumentar a capacidade e velocidade da deciso dos
123
[JOSUTTIS, 2009]
Capitulo 9
Pgina 154
Boria et al.
interessados. Em lugar de chamar os servios entre si, por mtodos ou rotinas de seu cdigo fonte, utilizam protocolos definidos que descrevem como os servios so transmitidos e analisam mensagens mediante metadados de descrio. Atrs disto e para permitir que funcione, necessrio que estes metadados tenham detalhe suficiente para descrever no somente as caractersticas destes servios, mas tambm os dados que os impulsionam a funcionar. Os programadores fizeram uso extensivo de XML em SOA para estruturar os dados descritos em um envoltrio quase exaustivo da descrio do contedo. Analogamente, a linguagem de descrio de servios Web (WSDL) no geral descreve os servios em si, enquanto que no protocolo SOAP so descritos os protocolos de comunicao. Se estas linguagens de descrio so as melhores possveis para o trabalho, e se sero convertidas ou continuaro sendo as favoritas no futuro, estas so perguntas abertas. A partir de 2008, a SOA depende dos dados e servios que so descritos por metadados que devem cumprir com os dois critrios seguintes: 1. Os metadados devem vir de tal forma que os sistemas de software possam utiliz-los para que se configurem dinamicamente, mediante a descoberta e a incorporao de servios definidos, mantendo coerncia e integridade. Por exemplo, os metadados podem ser utilizados por outras aplicaes, como um catlogo, para realizar a deteco automtica dos servios sem necessidade de modificar o contrato funcional de um servio. 2. Os metadados devem vir em uma forma que os designers de sistemas possam compreender e trabalhar com um gasto razovel de custo e esforo. SOA tem como objetivo permitir aos usurios encadear peas, bastante grandes de funcionalidade para formar aplicaes ad hoc, que so construdas quase por completo a partir dos servios de software existentes. Quanto maior for o bloco, menor a quantidade de pontos de interface necessrios para implementar qualquer conjunto dado de funcionalidade. No entanto, se os pedaos de funcionalidade so muito grandes, podem no ser suficientemente granulares a ponto de poderem ser reutilizados facilmente. Cada interface leva consigo uma certa quantidade de grava-me de processo, pelo que a granularidade dos servios uma considerao de rendimento, tanto para o servio quanto para seus futuros usos. Se for muito pequeno sobrecarrega as interfaces, se for muito grande reduz o reuso. Esta caracterstica faz com que seja muito rentvel o uso de SOA em domnios especficos, ao invs de domnios muito gerais. Os servios SOA esto menos acoplados que as funes de biblioteca conectadas para formar um executvel. Os servios SOA tambm so executados em wrappers seguros (como Java ou .NET) e em outras linguagens de programao que administram a designao de memria e recuperao, permitem enlace ad hoc e tardio, e proporcionam um certo grau indeterminado de tipo de dados (data typing). SOA, como arquitetura, baseia-se na orientao a servios como princpio fundamental de design. Se um servio apresenta uma interface simples que abstrai a complexidade subjacente, os usurios podem acessar os servios independentes sem saber como foi implementado o Santo Graal do reuso. A grande promessa da SOA que o custo marginal da criao da ensima aplicao baixo, j que todo o software necessrio j existe porque foi criado para satisfazer os requisitos de outras aplicaes anteriores. Idealmente, s preciso instrumentao para produzir uma nova aplicao. A fim de utilizar eficientemente um SOA, a arquitetura deve cumprir os seguintes requisitos: Deve existir interoperabilidade entre os diferentes sistemas e linguagens de programao que proporcionam a base para a integrao entre aplicaes em diferentes plataformas por meio de um protocolo de comunicao. Um exemplo de tal comunicao o conceito de mensagens. O uso de mensagens por meio de canais definidos diminui a complexidade da aplicao final, permitindo deste modo ao programador da aplicao concentrar-se na funcionalidade em lugar das complexidades de um protocolo de comunicao. O desejo de criar uma federao de recursos. Estabelecer e manter o fluxo de dados em um sistema de base de dados distribuda. Isto permite
Capitulo 9
Pgina 155
Boria et al.
novas funcionalidades desenvolvidas para fazer referncia a um modelo de negcio comum para cada elemento de dados. Estes requisitos so centrais para a T , pois so essenciais viso de interoperabilidade e independncia da configurao hardware e software do cliente. O primeiro passo construir a arquitetura de referncia SOA, que fornece um plano de design de servios de uma implementao atravs de uma organizao. Um dos aspectos relevantes em SOA definir a Arquitetura de Referncia para a Empresa, porque permite ter um marco de referncia onde localizar os futuros desenvolvimentos ou ainda aqueles componentes de servios 2 convenientemente empacotados. No caso da T esta arquitetura de referncia deve ser documentada, ampliada e refinada, mas o conhecimento do domnio permite visualizar que esse processo no ser doloroso nem longo. A Arquitetura de Referncia SOA modela os diferentes componentes de uma soluo SOA, principalmente Processos de Negcios e Servios. Alm disso, mostra como interagem estes componentes com os usurios de negcio e com os sistemas existentes na Empresa (sistemas legados). Geralmente orientada a camadas pela independncia que este modelo arquitetnico fornece e o pouqussimo acoplamento que produz, h grandes semelhanas com o design de 124 125 Sistemas Operacionais modernos . H definies bem documentadas de tudo o que 126 necessrio descrever e como criar um registro de metadados . SOA menos uma arquitetura do que um paradigma para a construo e manuteno de 127 processos de negcios que abarcam sistemas distribudos de grande porte . Um componente essencial de uma arquitetura SOA o bus. O bus o grande unificador, permite eliminar a necessidade de conhecer detalhes de interfaces entre servios. Em troca, exige a existncia de um registro dos metadados que cada um espera receber e a capacidade de cada um de interpretar metadados. Isto pode levar a um grande caos, por isso todos os autores recomendam incorporar um nvel de superviso e guia para governar o registro e a instrumentao.
2
Figura 9.9: Ilustrao da Arquitetura SOA
9.12 Montando a Fbrica Para o processo de reengenharia dentro da T , Ana prope contratar um ajudante que j trabalha com ela na universidade e que cumpre com as condies e tem as competncias necessrias. Passadas as entrevistas e as verificaes de antecedentes, o novo engenheiro de 128 software passa a ser o arquiteto do projeto . Junto com Ana e os gmeos, elaboram a 129 arquitetura de alto nvel, aplicando JMC . Depois desse exerccio, comea a funcionar a Fbrica de Software: dependendo do domnio, em particular do componente a converter em
124 125
[BORIA, 1989] http://www.soa.com/solutions/metadata_federation/ 126 Uma busca no Google devolve mais de um milho de sites 127 [JOSUTTIS, 2009]. SOA in Practice: The Art of Distributed System Design. 128 Uma dessas coisas que s acontecem com softwares! 129 Ver captulo 8, Java Modeling in Color.
Capitulo 9
Pgina 156
Boria et al.
servio, os gmeos recomendam um especialista que assume o papel de programador chefe 130 da equipe . Ser ele que se encarregar dos detalhes do envoltrio e da definio de metadados para o registro. Para a escrita do envoltrio, montar sua equipe e a liderar. Resumindo, uma aplicao clssica de FDD e SOA. O QUE ACONTECEU AT AGORA 86. Uma empresa canadense estabelece uma aliana com a T para refazer a arquitetura do produto de sade passando-a para SOA. 87. Marcela e Ana definem um processo para fabricar os servios a partir do cdigo existente, aplicando FDD. 9.13 O nvel C do MPS Revisando com Mximo o que aconteceu, mais uma vez chamado para realizar uma anlise de lacunas, a nfase recai sobre duas coisas: O processo de Desenvolvimento para o Reuso e os resultados de atributos de processo, que marcam o grau de institucionalizao dos processos. Por causa do novo acordo com a empresa do Canad, o resultado DRU 1: Os domnios de aplicao nos quais sero investigadas as oportunidades de reuso de ativos ou nos quais se pretende praticar reuso so identificados, detectando os potenciais de reuso respectivos , est claramente coberto. O segundo resultado, DRU 2: A capacidade de reuso sistemtica da organizao avaliada e as aes corretivas so tomadas, caso sejam necessrias , fica evidenciado com a incorporao de um arquiteto para SOA e a instalao do projeto baseado em FDD. O terceiro resultado, DRU 3: Um programa de reuso, cobrindo propsitos, escopo, metas e objetivos, planejado a fim de atender s necessidades de reuso de domnios , algo tambm evidenciado por este projeto. O quarto resultado, DRU 4, O programa de reuso implantado, monitorado e avaliado decanta dos mesmos preceitos de governana que so 2 usados em todos os projetos da T . DRU 5 diz: As propostas de reuso so avaliadas de forma a garantir que o resultado do reuso seja apropriado para a aplicao objetivo , aplicada no mecanismo de avaliao de cada sprint do projeto SOA, enquanto que a DRU 6, Formas de representao para modelos de domnio e arquiteturas de domnio so selecionadas , fica evidenciada pelo registro e a arquitetura de negcios que constituem o nvel mais alto de especificao do projeto, realizado por Ana e os gmeos. DRU 7, Um modelo de domnio desenvolvido e seus limites e relaes com outros domnios so estabelecidos e mantidos , est contemplado no registro de metadados, j que o resultado elaborado deste modo: Este modelo deve ser capaz de capturar caractersticas, capacidades, conceitos e funes comuns, variantes, opcionais e obrigatrias. Tambm a escolha de SOA permite facilmente evidenciar o DRU 8: Uma arquitetura de domnio descrevendo uma famlia de aplicaes para o domnio desenvolvida e mantida por todo seu ciclo de vida. Por ltimo, DRU 9, que pede que Os ativos de domnio sejam especificados; adquiridos ou desenvolvidos, e mantidos por todo seu ciclo de vida, parte do prprio contrato com a TransKND e o corao do novo projeto. Assim, o processo DRU do nvel C do MPS-SW no constitui um problema. Em relao aos resultados dos atributos de processo, o RAP, a reviso alcana aqueles aplicados at o Nvel C e no foram substitudos por outros no processo de amadurecimento. Estes so: RAP 1, o mais bsico, que faz referncia ao Grau em que o processo alcana seus resultados definidos, este o motivo para que se realize a reviso dos resultados dos processos, de modo que no uma preocupao para Marcela e sua equipe. Tampouco surgem muitas dvidas sobre os seguintes resultados esperados: RAP 2. Existe uma poltica organizacional estabelecida e mantida para o processo ; RAP 3. A execuo do processo planejada; RAP 4. As medies so planejadas e coletadas para monitorar a execuo do processo e os ajustes so realizados; RAP 5. As informaes e os recursos necessrios para a execuo do processo so identificados e postos disposio dos interessados ; RAP 6. Os papis necessrios, as responsabilidades e a autoridade para a execuo do processo definido so designados e comunicados; RAP 7. As pessoas que executam o processo so competentes em termos de formao, treinamento e experincia ; RAP 8. A comunicao entre as partes interessadas no processo planejada e executada de forma a garantir seu envolvimento; RAP 9. Os mtodos adequados para monitorar a eficcia e adequao do
130
Ver captulo 3, Feature Driven Development.
Capitulo 9
Pgina 157
Boria et al.
processo so determinados e os resultados do processo so revistos com a gerncia de alto nvel para dar visibilidade sobre sua situao na organizao . Todas estas formam parte do planejamento normal de projetos, programas e sprints, ou da estrutura de controle de qualidade 2 e do mecanismo de governo institudo nas reunies mensais do comit de gesto da T . O mesmo acontece com RAP 10, A aderncia dos processos executados a suas descries de processo, padres e procedimentos avaliada objetivamente e so tratadas as no conformidades. A implementao da boa gerncia de configurao na qual insistiram todos, em particular os gmeos, produz as evidncias necessrias para RAP 11, Os requisitos dos produtos de trabalho do processo so identificados; RAP 12, Os requisitos para documentao e controle dos produtos de trabalho so estabelecidos; RAP 13, Os produtos de trabalho so colocados em nveis apropriados de controle; e RAP 14, Os produtos de trabalho so avaliados objetivamente em relao aos padres, procedimentos e requisitos aplicveis e so tratadas as no conformidades. Mximo teve de comparar planos e processos para descobrir que, efetivamente, o que dito o que planejado, e o que planejado o que feito. Mas isto serviu para ver da mesma forma a evidncia de RAP 15, Um processo padro descrito, incluindo diretrizes para sua adaptao; RAP 16, A sequncia e interao do processo padro com outros processos so determinadas; RAP 17, Os papeis e competncias exigidos para executar o processo so identificados como parte do processo padro; e finalmente de RAP 18, A infraestrutura e o ambiente de trabalho exigidos para executar o processo so identificados como parte do processo padro. Tudo isto Mximo encontra na BiPro quando compara os planos dos projetos com os processos que lhes do origem. Nessa anlise, Mximo apoia-se no processo definido que cada projeto adota, seguindo os guias de adaptao, o que lhe permite observar evidncia de RAP 19, Um processo definido implementado baseado nos guias para seleo e/ou adaptao do processo padro ; RAP 20, A infraestrutura e o ambiente de trabalho exigidos para executar o processo definido so colocados disposio, geridos e mantidos ; e finalmente RAP 21, Os dados apropriados so coletados e analisados, constituindo uma base para a compreenso do comportamento do processo, para demonstrar a adequao e a eficcia do processo, e avaliar onde podem ser realizadas melhorias contnuas do processo. Mximo conclui que a T est preparada para a avaliao do Nvel C e, em consequncia, pela fora do modelo MPS, para realiz-la conjuntamente com um SCAMPI de Nvel 3, Definido, do CMMI-DEV. O QUE ACONTECEU AT AGORA 88. Mximo conclui que a T est preparada para a avaliao de Nvel C e, em consequncia, dada a fora do modelo MR-MPS-SW, para realiz-la conjuntamente com um SCAMPI de Nvel 3 do CMMI-DEV.
2 2
Capitulo 9
Pgina 158
Boria et al.
Parte IV Apogeu
CAPTULO 10 - ESTABILIZAR PARA A MELHORIA CONTNUA No a espcie mais forte a que sobrevive, nem a mais inteligente, mas sim aquela que melhor se adapta s mudanas Charles M. Darwin 10.1 Nveis B e A do MPS J se foram vinte meses desde que visitamos nossos amigos da T e j passou muita gua sob a ponte. Quando ns os deixamos, eles estavam preparando a avaliao conjunta do nvel C do MR-MPS-SW com o nvel 3 (Definido) do CMMI-DEV, avaliao que se realizou sem sobressaltos e com sucesso poucos meses depois. O desenvolvimento da Fbrica de Software baseado em arquitetura SOA era incipiente e o crescimento se acentuava no acordo com a 2 empresa do Canad. Quase dois anos mais tarde, todos os resultados da T se acentuaram positivamente. A empresa tem trs linhas de produtos, conhecida pelo primeiro ERP seguro na nuvem, tem aes na Bolsa e suas marcas so reconhecidas. Chegar cidade, vindo do aeroporto, percorrer um outdoor atrs do outro lembrando ao viajante que est na cidade da 2 T . Os fundadores so conhecidos nos programas de televiso locais e convidados frequentemente para seminrios e palestras. Ainda so jovens, alguns mudaram de estado civil, Adolfo e Ana j tm trs filhas, os gmeos continuam sendo mais conhecidos nos bares que em sua casa paterna, Mariano se casou, Cludio vive com a namorada. Marcela adotou um enorme cachorro, cruzamento de Mastim com So Bernardo, que ocupa seus dias mais que seu namorado. A vida boa. 10.2 Estabilidade Em todos os aspectos de nossas vidas, a estabilidade nos oferece uma sensao de tranquilidade. Quando os acontecimentos so estveis e as surpresas so mnimas, sentimos que estamos seguros. At em esportes radicais, os seres humanos querem controle sobre o que ocorre. Os filmes de aventura nos tiram da zona de conforto e aceleram nossa adrenalina porque nos apresentam um panorama onde o futuro incerto, no possvel fazer previses e, em consequncia, mesmos os melhores planos acabam mal. Nossos amigos da T deduziram o mesmo de uma experincia particular nas primeiras tentativas de planejar seus sprints para o projeto SOA. Durante a adoo do nvel E do MPS, a 2 estimativa de esforo e durao das tarefas foi calculada na T a partir do tamanho dos produtos a serem desenvolvidos. No Scrum, no princpio, o tamanho foi calculado na forma de pontos de histria. A partir do nvel D, foram utilizados pontos de casos de uso, dada a introduo destes como parte da definio de escopo do projeto. No Kanban so usadas diferentes medidas de tamanho. No entanto, como o uso do Kanban pouco frequente, voltado, a princpio, para controlar certas tarefas de durao mdia, no h um mtodo to rigoroso. A partir da estimativa de tamanho, assume-se como valor inicial do esforo o valor resultante da equao de regresso para tarefas desse tipo, tomando por base os valores histricos da base de dados de processos. Conscientes de que estes eram processos e procedimentos novos, os gmeos comearam a gerar os dados para que a equao pudesse ser usada com o mesmo efeito. Durante trs meses, as estimativas foram feitas com base apenas na experincia e os parmetros utilizados na equao de regresso foram ajustados at que estivessem adaptados aos coeficientes derivados dos pontos de histria. Mesmo assim, os gmeos se surpreenderam com a grande disparidade que comearam a observar entre os sprints da fbrica. As previses erravam por vrios dias, at por semanas em algumas ocasies. Armados com as ferramentas de anlise, comearam a trabalhar. Por que um processo, o de estimativa, que tinha sido suficientemente bom at agora, j no servia com a mesma capacidade? Obviamente que o primeiro questionamento foi a novidade do domnio e a consequncia imediata foi comparar os dados
2 2
Capitulo 10
Pgina 159
Boria et al.
de ambas modalidades. Pegaram os dados histricos para tarefas semelhantes (anlise, construo, teste) e os carregaram na ferramenta de software de anlise estatstica131 em uso e com sua ajuda produziram curvas normais para ambas as populaes. Esperavam que os valores mdios fossem diferentes, mas acreditavam que no resto as distribuies no seriam muito diferentes. As duas distribuies terminaram muito diferentes. O valor mdio era, como esperado, muito maior para a nova populao ( direita nos grficos da Figura 10.1), mas a maior diferena era constituda pela disperso132. Os gmeos pediram a ajuda de Cludio, para usar seus conhecimentos de estatstica133 recentemente adquiridos. Cludio mostra-se um pouco surpreso pela pergunta dos gmeos que querem saber por que as estimativas so to imprecisas no novo projeto quando eram to precisas nos anteriores. D uma resposta muito sucinta a eles, que parece to boa que os gmeos o convidam a realizar uma breve exposio para os lderes tcnicos que produzem as estimativas.
Figura 10.1: Distribuies de Esforo de Tarefas Semelhantes em Duas Populaes
Cludio se dirige pela primeira vez a um auditrio dentro da T , mas no a primeira vez que 2 faz uma exposio em pblico. Ele tambm vtima do sucesso da T e frequentemente convidado a fazer apresentaes sobre a anlise financeira aplicada anlise de portflio, 2 como vem fazendo na T h anos. Portanto, est preparado, embora fazer uma apresentao sobre o tema de estatsticas seja novo para ele. Sua exposio, baseada em slides ppt, intitulase Estimativa e Disperso. Seu argumento central que a preciso da estimativa no um problema do mtodo de estimativa, mas do comportamento do processo estimado. Para ilustrar isto, ele escolhe o seguinte exemplo: Vamos supor que estamos tentando estimar o erro de um relgio, no qual observamos a hora que ele marca e a comparamos com a hora real, medida por um instrumento confivel, como um computador, a cada vinte minutos. No final de um dia, 24 horas, teremos 72 observaes. Agora, imaginemos que observamos um cronmetro. Nesse caso, os desvios estaro, possivelmente, abaixo do limite de tolerncia de nossas medies, quer dizer, se comparamos as medies em segundos, possvel que a diferena entre o computador e o cronmetro seja menor do que um segundo. Mesmo se fosse perto de um segundo, a disperso dos dados mnima. Por outro lado, se observamos um relgio de parede que ficou sem bateria, ele sempre marca a mesma hora. Como o relgio s marca 12 horas, cada medio que fazemos do erro aumenta em vinte minutos at alcanar ou passar das 6 horas, ento diminui de vinte em vinte minutos. Se pegamos os erros com seu sinal, eles se compensam entre si, de maneira que o valor mdio de ambos os relgios zero, talvez se algum valor mdio no zero, provavelmente o calculado com o uso do cronmetro. Claro que tomamos os desvios
131 H muitas ferramentas de software para anlise estatstica, incluindo algumas de cdigo aberto e extenses para Excel. Muito difundido o Mini Tab. Para as simulaes de Monte Carlo, Crystal Ball. Para uma lista, ver http://alternativeto.net/software/minitab/. 132 As medidas de disperso, tambm chamadas medidas de variabilidade, mostram a variabilidade de uma distribuio, indicando por meio de um nmero, se as diferentes pontuaes de uma varivel esto muito distantes da mediana mdia. Quanto maior for esse valor, maior ser a variabilidade, quanto menor for, mais homognea ser mediana mdia. Assim se sabe se todos os casos so parecidos ou variam muito entre eles. http://en.wikipedia.org/wiki/Statistical_dispersion 133 Cludio iniciou cursos de doutorado em anlise financeira para empresas. De passagem, especializou-se em Auditoria.
Capitulo 10
Pgina 160
Boria et al.
em seu valor absoluto; mas, de todo modo, isto indicativo de que o valor mdio no o melhor modo de calcular estimativas, porque h uma grande parte da informao que reside na disperso e que o valor mdio no captura. Se usamos a mdia do erro para ajustar nossa estimativa, o relgio da parede nos trar surpresas: cada observao est muito distante da realidade, no entanto, a mdia compensa. O mtodo o mesmo, o erro, totalmente diferente. Depois, o erro no vem do mtodo, mas da distribuio subjacente da varivel que mede o comportamento do processo. Se no gostamos de nossas estimativas, intil punir quem est fazendo as estimativas, preciso melhorar a estabilidade do que tentamos estimar.
Figura 10.2: Distribuio do Erro em Dois Relgios
10.3 Eliminando Aleatoriedade O resultado que os processos de SOA no so estveis. Procurando a causa-raiz, so encontradas vrias candidatas: os procedimentos no esto definidos com suficiente preciso, h diferentes interpretaes de como devem ser executados; dentro deste mesmo tema, diferentes execues tm diferentes graus de aderncia ao processo (fidelidade); os ajustes que o guia permite foram mal feitos e isto passou despercebido pela qualidade; pelo fato de ser um processo novo, as medies esto mal automatizadas e a granularidade maior que nos casos de Scrum, onde as tarefas esto claramente separadas e a coleta de dados lmpida. O primeiro passo para controlar o problema esclarecer o processo inicial de definio do sprint, que antes era bem descrito pelo jogo do planejamento, mas como este no aplicado em SOA, substitudo por um procedimento centrado na estimativa individual do tamanho, realizada pelo programador-chefe. Esta estimativa no revisada e parte da fonte do erro. Marcela se encarrega de tornar o procedimento de contagem preciso, construindo um mtodo semelhante aos pontos de caso de uso que j utilizam, mas baseado na densidade e extenso dos metadados que requer o servio ou o componente em questo. Colocados em prtica, os resultados so promissores, a disperso diminui significativamente em poucas aplicaes, mas decidem continuar com o experimento at que as ferramentas estatsticas mostrem que o resultado significativo a 10%134. Isto no os detm na melhoria contnua, j que Marcela acrescenta auditorias e revises que na pressa para comear o projeto SOA foram deixadas de lado. Que isto seja uma lio: at as melhores intenes costumam dar oportunidade ao otimismo e o resultado pode ser pior do que o esperado. Nada substitui a vigilncia contnua. De passagem, as anlises estatsticas s conduzem a ideias e novas perguntas no a solues. Para solucionar os problemas detectados preciso analisar as causas e possivelmente criar novas medies para investig-las claramente. 10.4 O Cu Desaba Os resultados permitem que novamente a gerncia confie nas estimativas e a estabilidade resultante induz a uma feliz sensao de estar no controle. At que um acontecimento incomum sacode todo mundo. Jssica se lembra de suas leituras de Taleb 135 e os cisnes negros. Um projeto novo de SOA andava normalmente, quer dizer, de acordo com as expectativas, at que no Sprint de estabilizao o cu desabou: os defeitos no s estavam fora de toda previso, mas cada correo acrescentava novos. A conta de defeitos abertos
134
Nos testes estatsticos, considerado um resultado estatisticamente significativo se for to extremo que tal resultado esperado que surja por casualidade s em raras circunstncias. A porcentagem expressa quo raro ele : 10% significa que uma em cada nove vezes o resultado fruto da escolha feita a partir da amostragem, 1% indica que uma em cada cem vezes o caso. Ver [SPIEGEL, 2011]. 135 [TALEB, 2010] e [TALEB, 2011], op. cit., ver Captulo 9.
Capitulo 10
Pgina 161
Boria et al.
conhecidos subia de ciclo de teste em ciclo de teste. Um tpico cenrio de projeto fora de controle136. Ao invs de diminuir, os defeitos aumentam a cada tentativa de eliminar um deles. O comit de gesto aperta o boto de emergncia e interrompe a linha de produo. Em uma reunio dos programadores-chefe, realizada uma anlise das causas-raiz que no chega a 2 nenhuma concluso. Pela primeira vez em sua histria, a T est perplexa e sem resposta. Marcela recorre, como sempre, literatura existente e aos seus bons contatos acadmicos. O Dr. Zito, que fez consultoria para empresas internacionais de software em encarnaes anteriores de sua profisso, sorri beatificamente ao escutar sua narrativa, como se espera dos professores titulares que j sabem o que devem responder. Marcela, diz ele, estamos falando do problema de complexidade das interfaces. tpico que o acoplamento baixo produza, em um sistema suficientemente grande, um caos de interpretao. A parte do software de vocs que interpreta os metadados tornou-se mais voltil e complexa que os benefcios que obtm do baixo acoplamento. O problema j era conhecido na poca da anlise estruturada, Constantine j falava disto, em 1979137. A pergunta-chave : Quanto um mdulo deve conhecer do outro para entend-lo e se comunicar com ele? Quanto mais devemos saber do mdulo B para entender do mdulo A, mais acoplados esto A e B. O fato de termos que saber algo sobre o outro mdulo, j uma prova a priori de que h certo grau de interconexo, inclusive se a forma de interconexo no conhecida. Isto levado ao extremo no caso de SOA. Infelizmente, chega um ponto onde no ter que saber nada de nada implica poder aprender de tudo no momento de se conectar. Essa a complexidade que esto enfrentando agora. Mas, diz Marcela, por que funcionou antes e agora no?. O que est diferente neste projeto em relao aos anteriores?, perguntou o Doutor. um projeto feito a partir do zero em um domnio que no conhecemos muito bem, responde Marcela. A est, diz o Doutor. A resposta essa. SOA no a ferramenta para isso, esto abusando do modelo. Marcela agradece e vai embora pensando no que acaba de aprender. Sua perplexidade diminuiu, mas no desapareceu. Por que uma ferramenta to til em alguns casos to ruim em outros? E, sobretudo; Como se conserta isto agora? Claro que, por outro lado tambm, seu vis de melhoria contnua a inquieta: isso poderia ter sido prevenido? O comit de gesto est reunido na reunio de emergncia. Marcela expe o caso como viu com o Doutor Zito. Na ida da faculdade ao escritrio teve uma Eureka138 e a transmite ao comit. Ela utiliza um mtodo de Ford que conhecido como as oito disciplinas 139, pelo qual definido corretamente o problema da mesma forma que no caso da anlise de causas-raiz, mas acrescentado um elemento importante: a conteno do problema antes de se preocupar em solucionar as causas-raiz. Com isto em mente, Marcela faz sua apresentao: o problema a necessidade de atender todos os metadados possveis em um domnio novo, onde no h experincia necessria para entender o que o crtico e o que o acessrio. Desse modo, os envoltrios ( wrappers) terminam sendo extremamente complexos, quase programas de Inteligncia Artificial. Isto
136
[GLASS, 1997]: Um projeto de software classificado como fora de controle quando excede em mais de 30% suas estimativas. No caso que citamos, o indicador de gesto que aponta para isto o crescimento permanente dos defeitos conhecidos e abertos em cada ciclo de teste. 137 [YOURDON e CONSTANTINE, 1979]. Muitos atribuem grande parte do material a Constantine, da a citao do Doutor pela metade. 138 Eureka! ou Heureka em grego Encontrei!, uma famosa exclamao atribuda ao matemtico grego Arquimedes, que segundo a lenda pronunciou esta palavra depois de descobrir que o peso de um corpo, dividido pelo seu peso aparente ao ser submerso em gua, uma propriedade que hoje conhecemos com o nome de densidade. Isto permitiu que ele descobrisse se a coroa do Rei era feita de ouro puro. Esta descoberta teria sido feita enquanto ele se encontrava submerso na banheira. Tal foi sua alegria que saiu pelas ruas de Siracusa nu e gritando Eureka!. Marcela teve sua Eureka no carro e vestida, por sorte. 139 http://en.wikipedia.org/wiki/Eight_Disciplines_Problem_Solving
Capitulo 10
Pgina 162
Boria et al.
ocorre porque no h um cdigo herdado que se possa abstrair, mas desenvolvido medida que se define o servio.
Figura 10.3: O Mtodo das Oito Disciplinas
Marcela agora chama um grupo de programadores-chefe que j tinha selecionado e comunicado a necessidade de estarem preparados para esta reunio, a qual chama de uma retrospectiva acelerada. Entram na sala e Ana, que j foi avisada por Marcela sobre o direcionamento que quer dar reunio, assume o comando e conduz a discusso sobre os ajustes arquiteturais que devero ser efetuados para contar com um produto dentro de prazos razoveis. Os programadores se sentem muito incomodados, j que as reunies do comit de 2 gesto se tornaram lendrias na T , material de muitas histrias nascidas ao abrigo das 2 decises tomadas nela por aqueles que os mais jovens consideram os pais da T . Timidamente eles expem suas queixas, quase todas justificadas: A direo superestimou a capacidade de adquirir conhecimentos por parte das equipes, assim como a capacidade dos clientes de se expressar com preciso e de uma maneira integral. Os mtodos de Denney no serviram porque as definies iniciais no continham regras de negcio suficientemente claras nem completas. Os metadados no foram definidos de forma centralizada e nica, cada um criou e adaptou s suas necessidades, maneira que surgiam. O atraso no sprint de arquitetura foi tomado como um bom sintoma, como se o tempo investido na anlise fosse se pagar somente no futuro, quando na realidade foi interrompido abruptamente porque todos sentiram que continuar era melhor que esperar para entender bem o problema do usurio. O ambiente cada vez mais sombrio dentro da sala. S os programadores-chefe falam, na verdade, sussurram, suas sensaes. Em um ponto Alberto Galarraga tenta refutar alguns comentrios, mas Ana o interrompe. Armando, ela diz, confundindo-o com seu irmo, no h nada a refutar, a percepo a realidade neste caso. No importa se pensamos que foi de outra maneira, para poder consertar este desastre necessitamos nos colocar na viso dos que devem resolv-lo. A armadilha de Deming: ficamos to pendentes dos recursos que nos esquecemos dos objetivos, acrescenta Alfredo, que ficou pensando no problema. Os programadores-chefe se sentem respaldados, mas o medo no desaparece. Marcela pede, quase implora, que sejam propostas solues para o problema atual. Um dos mais jovens, que foi aluno de Ana, sugere comear de novo, mas com mtodos diferentes e diminuir o tempo reusando o cdigo j escrito. Tratar em parte o cdigo como um legado, mas comear com um modelo mais preciso do negcio do cliente. Outro soma sua voz, dizendo que est de acordo, mas que precisam deixar o SOA de lado, acabar com os metadados por enquanto. As outras vozes se incorporam para pedir que os requisitos sejam refeitos. Alfredo refuta: No h tempo para refaz-los, o mximo que dispomos de seis semanas, estourando dois meses, e, mesmo assim, fazendo concesses ao cliente.
Capitulo 10
Pgina 163
Boria et al.
No completamente certo que no haja tempo, retruca Mariano, normalmente calado nas reunies tcnicas. Podemos aplicar JAD e salvar isto no prazo. 10.5 Conteno Agora a vez de Mariano expor sua ideia. Sucintamente, descreve JAD para os no iniciados. Ao escut-lo, Marcela lembra-se que Mariano era um entusiasta do mtodo j nos anos em que os dois estudavam juntos no Poli. JAD a abreviao usada para Joint Application Development140, um mtodo integral de construo de software baseado fortemente na participao de todos os interessados na construo do modelo do sistema antes de escrever o cdigo. De certo modo, um dos precursores do mtodo gil, porque a equipe autnoma e escolhe seus processos at certo ponto e os perodos esto prefixados. O mtodo baseia-se em uma investigao inicial, em essncia, a coleta dos requisitos, para construir um modelo do sistema em questo. Esta etapa, segundo opina Mariano, pode ser realizada sem interveno do cliente porque as equipes j tm o conhecimento necessrio. A segunda fase constitui a identificao de uma equipe e sua convocao para revisar e atualizar o modelo. Nesta etapa, h dois resultados crticos: a escolha dos participantes e o respaldo da alta gerncia. Os participantes devem ser usurios CRACK141, quer dizer, devem ser pessoas reconhecidas no ambiente do cliente, contar com capacidade de deciso, contar com conhecimento de domnio e colocar-se disposio da equipe. O patrocnio da alta gerncia necessrio por duas questes: a convocao reunio deve vir da alta gerncia, de outro modo pouco provvel que os usurios CRACK atendam; e a outra razo que, ao fazer a convocao, o patrocinador deve garantir o comprometimento de todos com o resultado. Ningum pode dizer isto no o que eu queria, mas para terminar a discusso preferi aceit-lo. O compromisso com o resultado obriga todos tanto a participar quanto a negociar, j que o projeto tem durao fixa. A terceira fase a junta de anlise em si, onde o modelo proposto, analisado e melhorado. As objees que so levantadas na reunio so incorporadas ao modelo durante a noite e apresentadas de novo no dia seguinte. Isto aliado presena de pessoas com conhecimento e poder de deciso geram uma dinmica muito rpida, e entre trs e cinco dias possvel atender o que habitualmente leva de dois a trs meses. Ficaro alguns pontos abertos, mas os responsveis por fech-los tero um prazo inadivel para fazer isso. Enquanto se fecham as ltimas aes, o cdigo escrito, provado e demonstrado. Os programadores-chefe aprovam a estratgia e Mariano se compromete a convencer o cliente se o comit respald-los. Os gmeos continuam com dvidas, mas no tm uma opo melhor. Mariano fica encarregado de falar com o cliente e facilitar as futuras atividades de JAD. 10.6 Causas-Raiz At certo ponto a reunio atacou as causas-raiz, mas ainda no de forma sistemtica. Marcela utiliza dados do fracasso para mostrar os resultados e iniciar uma discusso de anlise. Jssica, que est secretariando a reunio e recolheu os comentrios dos programadores chefe, prope fazer a anlise a partir deles. risco ou problema: 1 A capacidade de adquirir conhecimentos por parte das equipes foi superestimada A capacidade dos clientes de se expressar com preciso e de maneira integral foi superestimada As definies iniciais no continham regras de negcio Os processos de negcio estavam sofrendo causa(s)-raiz: No foi seguido o processo de riscos na parte de pr-venda mitigao: Acrescentar uma auditoria de processo atual auditoria de produto e fazer uma reviso por colegas do produto Acrescentar aos riscos na prvenda o conhecimento do negcio por parte do ponto de contato no cliente Colocar uma clusula no contrato que torna o cliente
140 141
[WOOD e SILVER, 1995] Ver Captulo 3.
Capitulo 10
Pgina 164
Boria et al.
suficientemente claras nem completas
reengenharia ao mesmo tempo em que se tentava descrev-los para construir o sistema No h uma planilha nica, no h guias de ajuste nem de uso No foi implementado um sistema de gerncia dos metadados e no h revises das definies porque os processos de Scrum no so mais aplicados
responsvel pelas demoras relacionadas com requisitos incompletos Construir a planilha padro para metadados e os artefatos necessrios para seu uso produtivo na BiPro Implementar um sistema para gerncia dos metadados, incluir as definies de metadados entre os artefatos e documentos sujeitos a reviso por inspeo e criar a lista de itens de controle para poder realiz-las objetivamente
Os metadados no foram definidos de forma centralizada e nica, cada um criou e adaptou s suas necessidades, maneira que surgiam
O atraso no sprint da arquitetura foi visto como um bom sintoma, como se o tempo investido na anlise fosse se pagar somente no futuro quando, na realidade foi interrompido abruptamente porque se sentiu que continuar era melhor que esperar para entender bem o problema do usurio
Tabela 10.1: Os Problemas do Projeto Fora de Controle
A reunio avana rapidamente enquanto so tratados os primeiros quatro pontos, mas chega a um impasse quando o quinto confrontado. H silncios longos que so preenchidos por tosses e sugestes inconclusas, um Vamos ver, se f izermos que diludo sem terminar, ou um E se colocssemos, por outro lado que tampouco prospera. Jssica finalmente decide intervir. Isto acontece conosco porque somos bons fazendo autpsias, mas no sabemos fazer diagnsticos antecipados, diz, decidida. Como, como, como?, pergunta Alfredo com uma curiosidade sincera. Sim, somos mdicos legistas, trabalhamos com cadveres, mas no somos clnicos. No sabemos medir a glicose no sangue, os triglicerdeos, a quantidade de glbulos vermelhos, de leuccitos, de clcio. No sabemos e o que pior, se tivssemos os nmeros no saberamos interpret-los, insiste Jssica, que gosta de falar com parbolas e hiprboles. Ana comea a entender: No somos clnicos, no fazemos preveno, no fazemos anlise, no medimos isso? , pergunta Ana. Mas ns medimos, diz Alberto. E tambm fazemos anlise, diz Armando. Mas fazemos tudo isso quando o fato j ocorreu, fazemos post mortem, autpsia, rigor mortis e j no h mais nada a fazer, exagera mais uma vez Jssica, que tem certa afinidade com o dramaturgo dos pases blticos, Henrik Ibsen. A discusso se anima, todos parecem querer falar ao mesmo tempo, em parte fascinados pelo que acham ser certo, em parte rejeitando as ideias porque no so descritivas da realidade.
Capitulo 10
Pgina 165
Boria et al.
10.7 A Previso Como Ferramenta O que Jssica quis dizer em sua forma to peculiar que, apesar de serem feitas previses, estas no so categorizadas. Quer dizer, escolhido um ponto central e projetado para saber quantos defeitos vamos encontrar, qual o nmero de vezes que temos de executar cada caso de teste ou quando vamos entregar com a qualidade prevista, mas todas estas estimativas esto imbudas de erro e no se insere este erro no clculo. Lembrando a equao de regresso, devemos considerar o , porque se este valor for muito grande, no poderemos confiar na estimativa. De certo modo, a mesma discusso sobre a estabilidade transposta s equaes de regresso. Se os processos so estveis, deveria ser possvel estabelecer a correlao entre os valores das variveis independentes e os valores dependentes, com ajuste aleatoriedade que elas tm, quer dizer, prever o valor mdio dentro de um intervalo de confiana. Dessa maneira, poderamos afirmar coisas como dizer que o projeto est dentro dos limites esperados, ao invs de colocar valores arbitrrios de 15% acima e abaixo do valor mdio. Em termos das teorias de qualidade, o que no estamos fazendo escutar a voz do processo. Os processos tm comportamentos derivados do grau de estabilidad e que tm na empresa. Quanto menor for a disperso, maior a estabilidade. 10.8 Previso e Anlise Ns humanos baseamos nosso conhecimento em uma lei: Como foi ontem ser hoje. A repetitividade de um fenmeno o parmetro pelo qual medimos sua qualidade cientfica. As leis cientficas estabelecem as relaes entre eventos e objetos, medem os resultados que so enunciados como equaes matemticas. Kepler e as rbitas planetrias, ou Galileu e o plano inclinado, primeiro observaram os fenmenos e depois postularam relaes matemticas para explic-los. Do mesmo modo e baseados nos mesmos princpios, pensamos que se nossa fbrica se comportou de uma maneira ontem, e no houve mudanas, ela dever se comportar de forma semelhante hoje. O que aprendemos ontem serve hoje porque a realidade bastante parecida hoje, e podemos aproveitar esse conhecimento. Em termos dos processos, os dados que foram sendo obtidos sobre suas caractersticas podem ser utilizadas para comparar o passado com o presente. Enquanto no aparecerem cisnes negros, esperamos que os valores obtidos no passado sejam representativos do que est por ocorrer. Ao invs de ter presente a caracterstica e os valores mdios (mediana ou mdia) mais instrutivo conhecer a distribuio dos valores histricos. O ponto de Jssica que, se investirmos no conhecimento da distribuio de uma varivel aleatria relacionada com nossos projetos, podemos aplicar controle estatstico de processos142, abreviado SPC por suas iniciais em ingls (CEP em portugus). Vamos pegar uma das variveis associadas a determinada tarefa e observar seu comportamento. Para fixar ideias, tomamos o esforo que representa a construo de casos de teste por unidade do tamanho do caso de uso nos quais se baseiam. Derivando o histograma, vemos que toma uma forma parecida a uma distribuio normal, talvez um pouco mais voltada 2 direita que esquerda. Revisando na literatura de estatstica, a forma mais parecida a , uma distribuio derivada da curva normal de Gauss. Seguindo nossa busca, vemos que h uma famlia completa de curvas semelhantes, a famlia Weibull (ver Fig. 10.4), e que Putnam 143 utilizou em suas pesquisas sobre os processos de software.
142 143
[SHEWHART, 1939] [PUTNAM e MYERS, 2003]
Capitulo 10
Pgina 166
Boria et al.
Figura 10.4: Curvas da Famlia Weibull
Aplicar SPC teria sido til no projeto fora de controle, porque nos teria mostrado que a durao de certas atividades estava fora de seus limites normais. Isto implica que conhecemos quais so esses limites. Digamos que entramos em um clube de bridge e nos aproximamos de uma mesa onde h dois casais jogando. Observando as cartas, vemos que cada um tem na mo treze cartas do mesmo naipe, o que obviamente desperta nossas suspeitas. No nosso conhecimento da distribuio que se produz ao embaralhar e distribuir as cartas de um baralho, a probabilidade de que ocorra essa exata distribuio exatamente igual de todas as outras mos, mas to particular que nos surpreende v-la. Como isto tem um impacto muito alto no resultado do jogo, suspeitamos que este fato no seja normal. Quer dizer, normal e anormal so julgados em termos estatsticos. Se sobre o sino de Gauss, que a representao da curva normal, desenhamos zonas correspondentes distncia da mdia a um, dois e trs desvios padro144, e chamamos essas zonas de A, B e C, como na Figura 10.5, veremos que os dois extremos assinalados com setas tm muito baixa probabilidade de ser parte de uma amostra pequena da varivel, j que a cada cem vezes que observamos a varivel podemos encontrar um valor nessas zonas (de fato, a probabilidade de que isso ocorra naturalmente inferior a 0,3%). Portanto, se as coisas so normais, no esperaramos que isso ocorresse. Ao contrrio, se vemos um valor fora das zonas A, B ou C, suspeitamos que algo anormal est ocorrendo, que o processo est nos dizendo algo. por isto que a mxima precisamos escutar a voz do processo.
Figura 10.5: Zonas de SPC Sob a Distribuio Normal
Se isto tivesse sido feito nas primeiras etapas do projeto fora de controle, teriam sido detectadas as anomalias e medidas paliativas ou corretivas poderiam ter sido tomadas. As zonas A, B e C servem, alm disso, para outros usos. Dada a caracterstica aleatria das variveis, os valores obtidos do mesmo processo no so sempre idnticos. A variao que consideramos aceitvel rotulada de normal e ignoramos o rudo que produz. Shewhart percebeu que o processo s vezes grita (quando os 3 desvios padro so ultrapassados) e s vezes sussurra. As regras complementares do ponto alm da zona de controle so mltiplas e foram modificadas desde que Shewhart as gerou para a Western Electric. So as seguintes:
144
Medida da disperso de uma varivel ao redor da mdia de sua distribuio.
Capitulo 10
Pgina 167
Boria et al.
- 2 de 3 pontos consecutivos na zona A, que similar ao caso anterior, j que a probabilidade de que isto acontea inferior a 0,0625%. - 6 pontos consecutivos em linha ascendente ou descendente, j que isto tambm tem uma pequena probabilidade (probabilidade das rajadas) considerado que o sistema segue uma tendncia no aleatria. - 9 pontos consecutivos de um lado da linha central (seja por cima ou por baixo dela). Este caso costuma indicar um deslocamento da mdia, geralmente devido a uma mudana significativa no sistema. Pode ser uma boa notcia, por exemplo que aumentou a produtividade, mas, de todo modo, preciso explic-lo. - 14 pontos consecutivos alternando acima ou abaixo, o que pode indicar um fenmeno cclico ou sries temporais, ou que estamos na presena de duas populaes. - 15 pontos consecutivos na zona B ou C: isto implica na melhoria da preciso e um desvio padro associado menor. De novo, em geral, uma boa notcia. - 4 de 5 pontos consecutivos na zona B ou alm. - 8 pontos consecutivos acima e abaixo da zona C indica que temos duas populaes diferentes. Definitivamente, prestar ateno ao comportamento do processo permite tomar decises antecipadas, ao poder separar o rudo da mensagem. A tabela de ris cos completada com a ltima fila como mostra a Tabela 10.2: A ltima Fila da Anlise depois de Completa
O atraso no sprint da arquitetura foi visto como um bom sintoma, como se o tempo investido na anlise fosse se pagar somente no futuro quando, na realidade foi interrompido abruptamente porque se sentiu que continuar era melhor que esperar para entender bem o problema do usurio
No h um conhecimento profundo do comportamento dos processos e, em consequncia, a superstio se impe sobre a realidade
Aplicar SPC aos processos crticos
Tabela 10.2: A ltima Fila da Anlise depois de Completa
10.9 Correlao e Regresso Se a T tivesse utilizado SPC, poderia ter detectado as anomalias no comeo do projeto. Esse uso j justifica a anlise, mas depois que possumos esse conhecimento tentador poder uslo mais extensamente. Considerando que a massa dos dados nos anos em que foram 2 acumulados na T muito interessante, Jssica prope que sejam identificadas e analisadas as tendncias. Cludio se familiarizou com as tcnicas de inteligncia de negcios 145 e prope contratar um doutorando com quem compartilha alguns cursos e sabe que especialista no 2 tema. assim que, temporariamente, Damin incorporado equipe da T . Damin segmenta os dados em populaes diferentes e produz uma anlise detalhada de cada uma. Monta o que se chama hipercubos de dados , que vai submeter a mtodos estatsticos. A ideia que uma base de dados relacional em 5 forma normal muito lenta para realizar as milhares de operaes SELECT que demanda a anlise, por isso h um processo de extrao que separa os dados e monta uma super tabela, o cubo em questo. Sobre esse cubo, faz diversas operaes: limpa os dados, analisa correlaes e fatores mediante anlise da variao e anlise fatorial; e constri equaes de regresso que vinculam os valores de seus cubos. O resultado desses esforos um conjunto de modelos que predizem o
2
145
Denomina-se inteligncia empresarial, inteligncia de negcios ou BI (do ingls business intelligence) o conjunto de estratgias e ferramentas focadas na administrao e criao de conhecimento mediante a anlise de dados existentes em uma organizao ou empresa. http://pt.wikipedia.org/wiki/Inteligncia_empresarial
Capitulo 10
Pgina 168
Boria et al.
comportamento de variveis do projeto a partir de certos dados, que so obtidos em etapas iniciais. 10.10 Identificao de processos crticos Por causa da grande massa de dados que possui a T , possvel tirar concluses sobre eles usando data mining, como fez Damin; mas, nos casos em que esses dados no existam ou sejam insuficientes, a construo trabalhosa de dezenas de medies pouco operacional. Mesmo quando os dados existem, possvel que haja um excesso de informao, que pode ser to paralisante quanto sua falta146. Como diria Stephen Covey, o principal se assegurar que o principal o principal147. Mas, como? Se lembrarmos do modelo de Kano (Figura 10.6) que vimos no Captulo 7, a satisfao do cliente o principal objetivo da empresa. Em primeiro lugar, deveramos assegurar que no h requisitos obrigatrios que no tenham sido cobertos. Isto significa que devemos fazer um esforo grande para conhecer as necessidades de nosso cliente, alm das que so verbalizadas nos requisitos, como j vimos no Captulo 8 ao discutir os resultados de DRE. necessrio saber que o que o cliente pede, o que quer e o que necessita no so a mesma coisa. Faa uma lista ento com as necessidades de seu cliente, identifique quando tiver satisfeito suas expectativas e onde ainda no, mas no tente medir sucessos e fracassos, mantenha seu foco nas expectativas e use o modelo de Kano para classificar os requisitos. Este conhecimento deveria nos permitir identificar os eventos crticos. Um evento crtico um instante no qual o usurio de um produto ou servio forma uma opinio sobre a qualidade ou o seu valor. Por exemplo, um viajante atrado pela publicidade no caminho escolhe um restaurante de fast food para comer, mas, ao se aproximar, o cliente passa por vrios eventos crticos. Para comear, se o restaurante est do mesmo lado de seu caminho ou se precisa deixar a rodovia e cruzar para entrar no estabelecimento (do ponto de vista egocntrico do condutor isso um evento externo); de imediato, a acessibilidade do estacionamento; sua limpeza, j que um indicador do que pode encontrar dentro do restaurante; sua percepo da segurana do estacionamento, j que vai deixar o carro com objetos de valor, no vai descer com a bagagem; a disponibilidade de lugares no estacionamento, j que esperar na estrada no agradvel. Tudo isto considerado pelo cliente sem fazer uma anlise de decises formal.
2
Figura 10.6: Diagrama do Modelo de Kano
Em produtos e servios de software, o equivalente a estes eventos crticos podem ser diferentes de cliente para cliente. Mas preciso considerar: (a) os defeitos, como as diferenas com os requisitos, em sua severidade e nmero; (b) a adequao e convenincia de uso do
146
http://www.thedailybeast.com/newsweek/2011/02/27/i-can-t-think.html na Newsweek faz referncia a investigaes a respeito disso conduzidas por Angelika Dimoka, diretora do Centre for Neuronal Decision Making da Universidade de Temple (Pensilvnia) 147 [COVEY, 1996], First Things First.
Capitulo 10
Pgina 169
Boria et al.
sistema s necessidades; (c) sua facilidade de uso, o complicado ou no da aprendizagem; (d) o tempo que demora at sua entrega efetiva e com qualidade, talvez no s o tempo acumulado das demoras, mas tambm a quantidade de vezes que foi prometida a entrega e no foi cumprida; (e) a facilidade de instalao (transio da antiga verso ou do produto anterior); (f) o volume de mudana nos processos; (g) a migrao de dados; (h) os custos nicos, por exemplo, de uma licena (COTS - Commercial-Off-The-Shelf Software), ou os custos de desenvolvimento em contratos de tempo e materiais, ou de ajustes em MOTS (Modifiable Off-The-Shelf Software), tambm com consideraes especficas; (i) o suporte, como o pessoal dedicado e a curva de aprendizagem de sua prpria equipe, se o suporte transferido ao cliente; todos essas consideraes podem afetar a percepo de qualidade do cliente. Isto constitui o que se denomina CTCs (Critical to Customer). O prximo passo identificar caractersticas mensurveis de um produto, servio ou processo que so chave, de modo que os limites de especificao ou padres de desempenho devam ser cumpridos para obter a satisfao do cliente, que na literatura denominada CTQs ( Critical to Quality). Para transformar as necessidades e desejos do cliente em requisitos mensurveis que possam ser implementados e controlados na empresa, necessitamos de uma ferramenta, e essa a rvore CTQ. Para construir a rvore seguimos os seguintes passos: Escutar a voz do cliente (VOC); Identificar Defeitos em Produtos e Servios; Definir as Unidades de Produtos e Servios; e Detalhar as Oportunidades para Produtos e Servios. Por exemplo, vamos pegar um incidente registrado em nossa base de dados: Cada vez que peo uma mudana no produto, tenho que esperar seis semanas para que me respondam. O incidente passa a ser um evento crtico e queremos resolv-lo. Devemos primeiro identificar a varivel CTQ, neste caso, o tempo de resposta a pedidos de mudana. A medio que devemos usar ou criar o tempo de resposta a um pedido de mudana, medido em dias desde que aparece em nossa base de pedidos de mudana at que o usurio receba a resposta, no antes. Falando com clientes, descobrimos que parece razovel a eles um tempo de resposta que no exceda trs dias teis. Agora dispomos de um sinal para medir quando um pedido de mudana tem um tempo de resposta que excede os trs dias. Neste ponto devemos identificar o que leva os processos a demorar mais de trs dias. A Figura 10.7 mostra um grfico que exemplifica nossa anlise.
Figura 10.7: Barreiras Qualidade
A partir de uma necessidade genrica expressa pelo cliente, identificamos os processos que esto sendo uma barreira para a satisfao do cliente e dos processos CTQs relacionados que, especificamente, precisam ser melhorados para os obstculos serem eliminados. Um exemplo, de novo com uma cadeia de restaurantes, poderia ser que esta vem recebendo queixas do mau atendimento de seus funcionrios em vrios locais. Uma anlise dos incidentes indica que os clientes (VOC) se queixam de ter de esperar at que sejam atendidos ao entrar no estabelecimento, e so ignorados por muito tempo; tambm precisam esperar muito tempo at que uma mesa fique limpa quando no h mesas vazias ao chegar; e que os atendentes no so amveis, nem profissionais, mas muito distantes. A anlise poderia dar o seguinte resultado (Figura 10.8). Os retngulos representam processos, os objetos ovais, objetivos de negcio traduzidos a objetivos de processos, e as setas, mudanas sugeridas. Notem que Tratamento Amvel Segundo Processo foi traduzido em uma srie de objetivos que no cobrem as necessidades do cliente. Isto tpico de uma incapacidade para traduzir em objetivos mensurveis certos comportamentos. J recomendamos o livro de Mager em captulos anteriores e voltamos a
Capitulo 10
Pgina 170
Boria et al.
fazer isso aqui. Esto faltando dois objetivos observveis: olhar nos olhos do cliente quando se dirigir a ele e sorrir ao falar. Estes dois objetivos so mensurveis j que so observveis e uma lista de verificao consegue fazer essa avaliao.
Figura 10.8: Anlise de Fatores CTQ
Este processo equivalente ao que introduziu Jssica no comit de gesto em uma de suas primeiras intervenes, o BSC (Balanced Score Card). Os passos so semelhantes, so identificados objetivos de negcio e so traduzidos a objetivos derivados at que seja obtida uma clara associao com processos. Por exemplo, partindo de reter os clientes de nosso portflio, possvel traduzir este objetivo em vrios objetivos derivados de melhorar a interface com o usurio, diminuir o nmero de defeitos entregues, acelerar o processamento de certos dados, melhorar o tempo de descarga e instalao, etc.
Figura 10.9: BSC Aplicado a Identificar Processos Crticos
Estes objetivos podem estar associados facilmente com processos, possivelmente mais de um, e, para cada um deles, podemos, por sua vez, identificar objetivos. Por exemplo, poderamos associar a quantidade de defeitos entregues com o processo de inspees, e colocar um objetivo de eliminar, ou diminuir significativamente a porosidade148 das inspees. Isto levaria explorao de vrias alternativas para detectar mais defeitos em cada inspeo, seja para
148
A porosidade de um processo de software a porcentagem de defeitos que se deixa escapar sobre o total que deveria ter sido encontrado. Obviamente, a porosidade no pode ser calculada in processu, necessrio contar com dados dos defeitos que escaparam e acabaram sendo encontrados em processos posteriores. Os defeitos latentes so os que nunca so encontrados.
Capitulo 10
Pgina 171
Boria et al.
melhorar as listas de verificao, treinar melhor o pessoal ou envolver pessoal com mais experincia. Conhecida a distribuio dos valores associados ao processo, como a densidade de defeitos encontrados, podem ser fixados objetivos que expressem as melhorias como modificaes aos parmetros da distribuio, como diminuir o valor mdio, ou diminuir o valor do desvio padro, o que significa um aumento na preciso da estimativa. Por ltimo, uma tcnica para identificar processos crticos construir modelos de regresso com as variveis conhecidas e analisar a sensibilidade do modelo usando diagramas de tornado. Aqueles que demonstram maior sensibilidade so crticos e devem ser melhor controlados. 10.11 Processos Capazes Depois de estabelecido o objetivo a alcanar, til perguntarmos se podemos modificar o processo para que este seja alcanado. Dado nosso conhecimento da variao, j no podemos enunciar objetivos em termos de um s nmero: devemos especificar os limites que consideramos como definidores da zona desejvel para os valores da varivel. Por exemplo, podemos definir um objetivo como a densidade de defeitos detectada pel os testes de sistema deve ser de 0,1 defeito por ponto de funo (PF), mais ou menos 0,001 defeito PF. Claro, os nmeros escolhidos so arbitrrios e sumamente ambiciosos, mas de nada vale fixar objetivos que no sejam assim. Por exemplo, um objetivo de 10 defeitos por PF mais ou menos 7 defeitos por PF to pouco ambicioso que o efeito pode ser que as equipes diminuam sua capacidade. Definimos um processo como estvel se a variao aceitvel para os propsitos do negcio. Claro, somos conscientes de que esta no uma definio operacional e que muito subjetiva para ser til. No entanto, como todos os processos mostram variao, qualquer definio que fixe valores arbitrria e o nico juzo que podemos propor o da adequao. Visto da perspectiva do SPC, um processo estvel aquele observado dentro dos limites de controle. Um conceito afim, o do processo capaz, est vinculado s necessidades do negcio impostas pelo cliente. Dados os objetivos fixados a partir das necessidades do cliente, estabelecemos outros limites ao processo, no de controle, mas de especificao. J falamos da voz do processo, estes limites agora esto associados voz do cliente. Na realidade, h uma grande quantidade de vias para identificar os processos crticos. A Figura 10.10 ilustra alguns deles.
Figura 10.10: Fatores Na Escolha de Processos Crticos
No so s as necessidades dos clientes que so importantes, h outras variveis, como custos e utilizao de recursos que podem determinar processos crticos. Desta forma recomendvel no ignorar a qualidade sob pena da empresa no sobreviver no mercado. O processo que melhor se adapta s necessidades do negcio e do cliente aquele que capaz e estvel. De fato, podemos colocar em dvida que um processo no estvel seja capaz porque seria impossvel demonstrar. A Figura 10.11 mostra a relao entre ambas as caractersticas. Na figura, UCL significa Limite de Controle Superior, do ingls Upper Control Limit; LCL o Limite de Controle Inferior, por Lower Control Limit; USL o Limite de Especificao Superior; e LSL o Limite de Especificao Inferior. Na metade direita, mostrado um processo capaz e estvel, porque os limites de controle esto compreendidos pelos limites
Capitulo 10
Pgina 172
Boria et al.
de especificao, enquanto que a metade esquerda mostra um processo estvel, mas no capaz. Se os requisitos do cliente no podem ser modificados, no resta alternativa a no ser modificar o processo para que seus limites de controle sejam reduzidos.
Figura 10.11: Processos Capazes e Processos Estveis
10.12 Baselines Os processos crticos devem ser controlados mais de perto que os outros. Se nos primeiros nveis do MPS suficiente verificar o progresso de maneira global e em pontos prdeterminados do projeto, como os marcos de mudana de fase, e nos nveis G e superiores indispensvel verificar o avano por tarefa, nos nveis B e A o controle recai no SPC. Para isso, necessrio contar com os dados necessrios para entender os limites de controle naturais dos processos, em particular os crticos. Chamamos essa caracterizao de baseline de desempenho e a pedra fundamental da alta maturidade. Cada ponto ingressado no diagrama de controle de SPC permite tirar concluses sobre o comportamento do processo. Por isso, Damin segmentou os dados em populaes diferentes, estratificou-os quando diferentes classes mostravam diferentes comportamentos, depurou-os para eliminar os dados mal coletados ou que respondiam a situaes excepcionais e construiu a baseline de desempenho de tudo o que serve para a gesto quantitativa dos processos crticos. 10.13 Indicadores Lderes Por causa da relao entre os processos iniciais que so explorados com diferentes meios, Damin descobriu que vrios processos servem de alerta inicial para saber se um projeto est orientado para cumprir seus objetivos. A noo de um indicador que permite antecipar resultados de um processo posterior fundamental para a gesto quantitativa de um projeto. Digamos que decidimos que, para aumentar nossa participao no mercado, devemos reduzir os defeitos que chegam ao cliente e que, para isto, preciso aumentar o esforo em inspees e conseguir melhores inspetores e maior nmero. Com isso, pensamos que podemos diminuir a porcentagem de defeitos filtrados e, desse modo, diminuir os defeitos no cliente.
Figura 10.12: Indicadores Lderes
Os modelos de regresso que Damin construiu a partir dos dados so os que nos permitem estabelecer estas hipteses. Um indicador sempre um indicador de resultado 149: mede o que aconteceu, nenhum pode medir o que vai acontecer. Mas alguns indicadores podem ser
149
Tambm chamados indicadores de efeito, e em ingls, lag indicators ou outcome measures.
Capitulo 10
Pgina 173
Boria et al.
indicadores de causa150 porque seus valores servem para prever o resultado das aes que se encontram mais adiante no fluxo do processo. Justamente esses modelos de regresso permitem estabelecer intervalos dentro dos quais se encontrar uma varivel futura a partir do conhecimento do valor atual de um indicador de desempenho. Isto nos permite corrigir o rumo se for necessrio. Por exemplo, Damin encontrou em seus dados uma relao que modela a durao da construo de um requisito como previsor da durao do perodo de testes. Com esse modelo teria sido possvel prever nos primeiros momentos que o projeto estaria fora de controle. 10.14 Composio do Processo Definido do Projeto Enquanto a T usava qualitativamente suas ferramentas da BiPro, os guias de ajuste cumpriam bem o propsito de adaptar o processo padro s necessidades de um projeto em particular. Mas a introduo das ferramentas quantitativas, as baselines e os modelos, tornam necessrio que seja revisado o processo de seleo dos componentes. O que antes era qualitativo agora deve ser selecionado com ateno aos objetivos da empresa. Os objetivos fixados na reunio mensal so traduzidos um a um para cada sprint, e Damin, a partir de seus modelos e das baselines do desempenho que so aplicadas, roda simulaes que permitem oferecer s equipes as alternativas possveis, uma ou mais de uma, para alcanar os objetivos. Isto implica que no h uma estratgia dominante, quer dizer que no h uma nica forma de fazer as coisas.
2
Figura 10.13: Diferentes Possibilidades de Composio do Processo
Vamos imaginar que h trs diferentes mtodos para capturar requisitos, as Entrevistas Individuais, JAD e RAD, e que cada um tem sua baseline de desempenho em termos de requisito individual, com sua distribuio para custo, durao e qualidade. O mesmo ocorre com os dois mtodos de Design, os quatro de Codificao e os trs de Testing. Dependendo do que estivermos procurando otimizar, o caminho a seguir ser diferente, por exemplo JAD o que melhor qualidade tem, mas mais caro que RAD ou as Entrevistas. Damin tem ento de onde tirar dados para rodar suas simulaes de Montecarlo e gerar resultados alternativos que permitam equipe interessada fazer a escolha que melhor se adqua a suas necessidades. Se no houvesse nenhuma alternativa que permitisse alcanar os objetivos adequadamente, o comit seria convocado para revis-los ou para dar uma dispensa equipe, ou para tentar, de qualquer modo, alcan-los com um processo que no tem uma alta probabilidade de fazer isso. Neste ltimo caso, so acrescentados aos riscos os processos que tm mais impacto no resultado e so procuradas alternativas que permitam mitigar esses riscos. 10.15 Gesto Quantitativa Equipados com um processo que dever funcionar na maioria dos casos, as equipes simplesmente precisam executar as tarefas, medir os resultados e control-los mediante SPC para que a gesto seja levada adiante. No h mais necessidade de nada e o projeto controlado sozinho enquanto os dados no mostrarem anomalias. Se h decises a serem tomadas frente a mudanas de qualquer porte, o Scrum Master ou o programador-chefe pode reusar o modelo, com ou sem a ajuda de Damin, para estimar o efeito de suas decises. Isto
150
Tambm chamados indicadores indutores, e em ingls, lead indicators ou performance drivers.
Capitulo 10
Pgina 174
Boria et al.
assim porque os modelos possuem variveis que esto sob controle dos que tomam as decises, por exemplo a experincia mdia dos participantes em certas tarefas, a quantidade de inspees que so introduzidas no processo, as estratgias de teste e outras que, ao poderem ser modificadas, permitem fazer ajustes no projeto durante sua execuo por meio de modificaes no processo. 10.16 A Melhoria Contnua Como Estratgia de Negcio Para a T o objetivo ser cada vez melhor. No s ser a melhor de todas as empresas em seu ramo, mas melhor que ela mesma, ontem. Desde seu humilde incio, a empresa no fez mais que melhorar. A qualidade que seus produtos mostram e sua busca incessante pela superao resulta em um diferencial competitivo que usado para ganhar e reter clientes. Cada passo em seu caminho para a excelncia difundido pelos canais tradicionais e os prmios obtidos ajudam continuamente conquista de mercado. O conhecimento profundo que adquiriu de seu funcionamento no s permite prever os resultados com maior preciso que seus concorrentes, mas tambm permite escolher os clientes. Aqueles que no oferecem segurana nas margens so passados graciosamente aos perseguidores de cota de mercado, como Cludio os chama. Este conhecimento e sua versatilidade com os mtodos geis so o fruto direto de decises estratgicas que permitem desenhar novas linhas de produto com alta probabilidade de sucesso. Os riscos de territrios desconhecidos e domnios sem dono so conhecidos e eles aprenderam a naveg-los. Suas anlises de portflio passaram a ser verdadeiras anlises financeiras com profuso de dados de mercado, probabilidades e simulaes. 10.17 Custo de Competir Ainda mais importante para a T que seus concorrentes tm srios problemas para poder entrar nos mercados que ela atua. Seus mtodos geis e sua perfeita posio no mercado faz com que arrisquem margens com frequncia, com as consequentes perdas ocasionais e dores 2 de cabea. A qualidade da T aumentou o custo de entrada de seus concorrentes. Alm disso, a T pode conseguir os melhores recursos humanos no mercado porque seu mito 2 muito firme. Trabalhar para a T um orgulho para os profissionais e considerada uma 2 excelente escola de negcios. Se algum recebe uma oferta da T pouco provvel que a recuse. 10.18 Inovao tecnolgica No entanto, a T tem claro que no se pode dormir sobre a fama. Como parte de seu programa de introduo empresa, os ingressantes recebem instruo no projeto de Escuta Tecnolgica. Esse projeto, filho de Mariano e Alfredo, que o comparam ao SETI151, consiste na 2 busca constante de novas ideias e tecnologias de aplicao. Cada engenheiro da T escolhe uma publicao acadmica, cientfica ou de divulgao, como Scientific American, CACM, IEEE Computer, IEEE Software ou Discover, e a empresa paga sua assinatura e os custos de associao, se for o caso. Em troca, o engenheiro precisa contribuir com pelo menos uma nota 2 sobre o que leu na revista da T , chamada SPI152 Glass. No comeo do programa, quando os engenheiros eram contados por unidades, publicava-se tudo que era enviado. Hoje, com os nmeros aproximando-se dos mil nas trs sedes, h um comit de seleo de materiais, que uma tarefa de tempo integral. Vrias ideias germinaram a partir da leitura dos materiais. Uma maneira inovadora de captar requisitos mediantes prottipos em papel passou de inquietude a proposta de melhoria a ser testada em um projeto e completou seu ciclo quando foi adotada como uma tcnica na BiPro. A incorporao destas mudanas aos processos sofreu transformaes tambm. Antes, os pedidos e sugestes de mudana eram tratados em reunies para colocar prioridades e serem aprovados, postergados, rechaados ou dar um tratamento piloto. Hoje os dados e modelos estatsticos governam as decises. O comit de gesto j no pergunta Como vai o projeto? ou Como podemos aproveitar isso?, mas muito mais preciso: Qual a probabilidade de que este projeto cumpra com seus compromissos? e espera uma resposta numrica com um grfico que o acompanhe. Para o caso dos processos, o que se pergunta Como so
151 152
http://www.seti.org/, SETI um projeto de busca de vida extraterrestre. Software Process Improvement, Spy Glass o nome da luneta em ingls.
Capitulo 10
Pgina 175
Boria et al.
modificadas nossas margens no futuro, adotando essa mudana? e Qual o valor presente desse investimento? Marcela no apresenta nada ao comit que no esteja acompanhado d e um plano piloto e dos dados financeiros que preparou com Cludio sobre as simulaes que Damin rodou. Quando se justifica, apresenta uma rvore de decises. Desse modo, foram incorporadas mudanas a muitos processos, inclusive alguns que vm da noite dos tempos, como os gmeos chamam os dias nos quais os fu ndadores se reuniam ao redor de uma mesa de chapa de vinil para organizar suas ideias de design e arrematar as 2 tarefas. A automao governa os processos, mas as ideias governam a automao. A T aprendeu a reconhecer seu ncleo, mas tambm a explorar o espao em branco153, aquelas oportunidades que no se encaixam com seus modelos de negcios ou com seus clientes habituais. Johnson define o espao em branco como: a gama de possveis atividades que no estejam definidas ou dirigidas pelo modelo de negcios da empresa atual, quer dizer, as oportunidades fora de seu ncleo e alm de suas adjacncias que requerem um modelo de negcios diferente de explorao.
Figura 10.14: Definio de Adjacncias e Espao em Branco Segundo Johnson
Algumas das propostas apresentadas ao comit so atendidas de uma maneira muito particular: cria-se um grupo de estudos que recebe oramento do mesmo modo que um projeto, mas que no tem as mesmas obrigaes. Por exemplo, no segue um ciclo de vida normal, utilizando em troca um que Jssica adaptou do livro de Eric Ries, The Lean Startup154. Ries chama seu ciclo de retroalimentao Construir-Medir-Aprender (Ver Figura 10.15). O objetivo acelerar a aprendizagem passando to rpido quanto for possvel por todos os passos do ciclo. Ao invs de construir um prottipo completo, o que se conhece como um teste de conceito, construda uma maquete incompleta que submetida de imediato ao teste de uso pelo cliente. Isto deve ser medido com base em critrios que foram fixados de antemo, como o caso no design de novas funes em software. As reaes dos usurios sugerem mudanas, ajustes, continuar pelo caminho e ampli-lo ou simplesmente suspender o 2 projeto. Seja qual for o resultado, a T acha justificado o experimento porque a organizao aprendeu.
153 154
[JOHNSON, 2010], Seizing the White Space: Business Model Innovation for Growth and Renewal [RIES, 2011], The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses
Capitulo 10
Pgina 176
Boria et al.
Figura 10.15: Construir-Medir-Aprender
s vezes, os usurios fazem comentrios que identificam defeitos grosseiros, mas no exatamente como resolv-los. Para isso, so aplicadas as mesmas tcnicas de anlise de causa que usam os projetos de software e o grupo de qualidade de Marcela para identificar problemas, oportunidades e solues, mas sem contar, como os anteriores, com a vantagem dos dados estatsticos. J vimos vrias tcnicas de uso comum, comeando na noite dos tempos com o diagrama de espinha de peixe e o mtodo das oito disciplinas. Em duas oportunidades mencionamos a Lei de Pareto 155, mas no mostramos uma aplicao particular que feita na anlise de causas-raiz. Quando um acontecimento merece, por exemplo um cisne negro, a anlise de causa segue o mtodo habitual de analisar as causas -raiz com especialistas, identificar solues, estimar s eu impacto, vend-las direo, implement-las e medir o resultado. Mas em duas ocasies no ano, o grupo de Marcela analisa as melhorias a implementar no semestre. As fontes de iniciativas so os grupos de estudo, as sugestes por meio do SPI Glass e as mudanas nos objetivos de negcios. Estes ltimos sugerem melhorias em termos de margens a alcanar, para o qual um dos pontos de partida so os defeitos registrados. Marcela e seu grupo classificam os defeitos e analisam seu impacto no retrabalho. Aqueles que exigem mais esforo so candidatos a seguir o processo de anlise de causa. A Figura 10.16 mostra um diagrama usado nesta anlise.
Figura 10.16: Diagrama de Pareto de Defeitos de Cdigo
Os defeitos de cada categoria so contabilizados somando o esforo de correo individual em dias de trabalho. Sada Incorreta acumula 53 dias, que representa 52,5% do total do esforo investido em correes. Entre esta categoria e a que segue em importncia acumulam 81,2% do total, um exemplo da lei do 80-20. fcil tirar concluses a partir do diagrama. Por exemplo, se consegussemos diminuir pela metade o nmero de defeitos da primeira categoria,
155
Captulos 2, na discusso de Lean, e 8, aplicando a anlise de perfil operativo.
Capitulo 10
Pgina 177
Boria et al.
reduziramos em mdia 26,5 dias de esforo de correo. Isto traduzvel em dinheiro disponvel de modo imediato, pelo que se pode rapidamente ter uma ideia do volume que pode ser investido para eliminar os defeitos desse tipo. Os erros de direcionamento no tm esse mesmo peso, e, portanto, saem da anlise. Este mtodo de experimentar novas ideias deu frutos muito interessantes. A T gerou dois spinoffs: Uma linha de produto novo j uma empresa prpria, fabricando ambientes de desenvolvimento para aplicativos de telefonia inteligente; a segunda oferece uma srie de servios na nuvem para aplicativos de seguros com banda larga para fazer uso da imagem em sinistros, economizando milhares de horas de inspeo por ms. Um dos aplicativos desenvolvidos pela fbrica de apps uma viso 3D de um objeto a partir de um filme de 360. As empresas tm sinergia Mais interessante, no entanto, o uso que deram a projetos que se aventuraram no espao em branco. Em alguns casos, venderam as patentes, em outros iniciaram novas sociedades ou financiaram aqueles que fizeram o estudo, em troca de uma participao na nova empresa. 2 A T est preocupada com a doena do crescimento, a ancilose, e combate isso de todas as maneiras possveis. O QUE ACONTECEU AT AGORA 89. Os valores tpicos do projeto de SOA no correspondem histria dos projetos da T . 90. Um projeto SOA novo entra em crise e sai do controle. 91. Jssica introduz a SPC T . 92. Damin entra na equipe para realizar anlise de dados com ferramentas de inteligncia de negcios. 93. Damin segmenta os dados em populaes diferentes e produz a baseline de desempenho de cada uma. 94. Com a ajuda de diversas tcnicas so identificados os processos crticos para T . 95. Definidos os processos crticos, a T se assegura de que sejam estveis e j tenham sua baseline. 96. Para os processos crticos, Damin gera modelos estatsticos de previso para utilizlos na anlise de objetivos. 97. O sistema de medio estendido para incluir indicadores lderes e intervalos de confiana. 98. A composio do processo definido do projeto passa a ser quantitativa, baseada em simulaes Monte Carlo de seu desempenho. 99. A busca constante da excelncia aumenta o custo de entrada para a concorrncia da 2 T. 100. A inovao sistemtica d bons frutos.
2 2 2 2 2
Capitulo 10
Pgina 178
Boria et al.
CAPTULO 11 - CONCLUSES
A j no to pequena Tahini-Tahini
2
Nossa histria encerra aqui. Nossa amiga T est considerando uma oferta astronmica de compra de duas de suas linhas de negcios, feita por uma dessas empresas gigantescas dos EUA. Os gerentes, ainda bem jovens, avaliam ideias sobre aposentar-se em ilhas do Pacfico Sul ou Fernando de Noronha. Considerando o caminho percorrido, merecem. Mas, por enquanto, preciso resumir sua histria para que outros possam aproveitar.
Lean como mtodo de identificao da rea de melhoria
O uso de um mtodo de identificao de oportunidades baseada na diminuio de falhas e o shortening dos prazos de entrega fizeram a empresa focar em negcios antes dos processos. Se bem que, enquanto melhoravam os processos, o objetivo sempre foi a melhoria da 2 competitividade da T . O preo nunca foi to alto a ponto que os resultados no se justificassem. Em suma, o resultado uma empresa de qualidade mundial que justifica sua proeminncia nos fatos.
Mtodos geis como ferramenta de melhoria

2
Um dos fatores que aceleraram a maturao da T como empresa, foi a escolha, no incio de sua vida, de mtodos geis. A iterao contnua acrescentou o conhecimento dos processos e sua execuo. Com muitos dados nas mos, as decises foram mais simples e muito mais bem sucedidas. Ainda quando a crescente complexidade dos sistemas a serem desenvolvidos eliminaram o uso de Scrum e Kanban, a empresa continua sua adeso aos mtodos geis, escolhendo FDD para atacar os novos desafios.
O MR-MPS-SW como marco do crescimento organizacional
Uns dos aspetos mais fascinantes do MR-MPS-SW sua funcionalidade como ferramenta de desenvolvimento organizacional. Em patamares muito acessveis, desenha um caminho de crescimento que vai desde a desordem inicial excelncia global. Desde os primeiros passos, onde a reao frequente e os erros so muitos, at que a qualidade impere e os clientes esto totalmente satisfeitos, o MR-MPS-SW acompanha as organizaes que o adotam. O 2 resultado nem sempre to bem sucedido como com a T , mas aqueles que no tentam alcanar o topo no desfrutaro da vista.
Capitulo 11
Pgina 179
Boria et al.
REFERNCIAS BIBLIOGRFICAS ABNT, 2012, ASSOCIAO BRASILEIRA DE NORMAS TCNICAS. NBR ISO/IEC 29110-4-1: Engenharia de Software - Perfis de ciclo de vida para microorganizaes (VSEs) Parte 4-1: Especificaes de perfil: Grupo Perfil Genrico, Rio de Janeiro: 2012. AMBLER, S. W., 2002, Agile Modeling: Effective Practices for Extreme Programming and the Unified Process, John Wiley and Sons. ANDERSON, D. J., 2011, Kanban. Successful Evolutionary Change for Your Technology Business. Blue Hole Press. ANDRIOLE, S., 1993, Rapid Application Prototyping: The Storyboard Approach to User Requirements Analysis, QED Technical Publishing Group. ARTHUR, J., 2004, The Small Business Guerrilla Guide to Six Sigma, LifeStar Publishing. ARTHUR, J., 2006, Lean Simplified. The Power Laws of Speed, LifeStar Publishing. ATWOOD J., 2006, The Multitasking Myth, Coding Horror. Disponvel em: http://www.codinghorror.com/blog/2006/09/the-multi-tasking-myth.html. BECK, K., 2000, Extreme Programming Explained, Addison-Wesley. BOEHM, B., 1981, Software Engineering Economics, Prentice Hall. BOEHM, B., 1989, Software Risk Management, IEEE Computer Society Press. BOEHM, B. e TURNER, R., 2003, Balancing Agility and Discipline: A Guide for the perplexed, Addison-Wesley. BENNIS, W., 1997, Learning to Lead: A Workbook on Becoming a Leader, Addison Wesley. BORIA, J., 1987, Ingeniera de Software, Kapelusz (II EBAI). BORIA, J., 1989 Construccin de Sistemas Operativos, Kapeluz (IV EBAI). BORIA, J., 2010, Dont Be On Time. Disponvel em: http://www.slideshare.net/jorgeboria/dontbe-on-time. BROOKS, F. P., 1995, The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition), Addison-Wesley. BROWN, A., 2010. Disponvel em: http://www.aaronmbrown.net/blog/2010/07/programmersflow-and-productivity/ CAMERON, K., QUINN, R., 2011, Diagnosing and Changing Organizational Culture: Based on the Competing Values Framework, Jossey-Bass. CARL III, W. J., Unpublished paper, Flow - A Theory of Optimal Experience: History and Critical Evaluation. CHRISSIS, M. B.; KONRAD M. e SHRUM S., CMMI for Development: Guidelines for Process Integration and Product Improvement, Addison-Wesley, 3ra edio. CLEMEN, R., 1997, Making Hard Decisions: An Introduction to Decision Analysis , Duxbury. COAD, P., DE LUCA, J., LEFEVRE E., 1999, Java Modeling In Color With UML: Enterprise Components and Process, Prentice-Hall. COCKBURN, A., 2000, Writing Effective Use Cases, Addison-Wesley Professional. COCKBURN, A., 2005, Crystal Clear: A Human-Powered Methodology for Small Teams, Addison-Wesley. COHN, M., 2006, Agile Estimation and Planning, Prentice-Hall. COVEY, S., 1996, First Things First, Free Press. CONNER, D., PATTERSON, R., 1982, Building Commitment to Organizational Change, Training and Development Journal, v36 n4 p18-26,28-30 Apr 1982. CULBERT, S., 2010, Get Rid of the Performance Review!: How Companies Can Stop Intimidating, Start Managing--and Focus on What Really Matters, Business Plus.
Referncias Bibliogrficas
Pgina 180
Boria et al.
CRISPIN, L. e GREGORY, J., 2009, Agile Testing. A Practical Guide for Testers and Agile Teams, Addison-Wesley. CSIKSZENTMIHALYIS M., 1991, Flow: The psychology of optimal experience, Harper & Row. DECKER, B., RAS, E., RECH, E., KLEIN, B., HOECHT, C., 2005, Self-organized Reuse of Software Engineering Knowledge Supported by Semantic Wikis, Proceedings of the Workshop on Semantic Web Enabled Software Engineering. DE BONO, E., 1985, Six Thinking Hats, Little Brown and Company. DE MARCO, T. e LISTER, T., 1987, Peopleware: Productive Projects and Teams, Dorset House. DEMING, E. D., 2010, Out of the Crisis, The MIT Press. DENNEY, R., 2007, Succeeding with Use Cases. Working Smart to Deliver Quality , AddisonWesley. DENNEY, R., 2012, Use Cases Levels of Test. A Four-Step Strategy for Budgeting Time and Innovation in Software Test Design, CreateSpace Independent Publishing Platform. DIAZ, M., e KING, J., 2002, How CMM Impacts Quality, Productivity, Rework, and the Bottom Line, Crosstalk, March 2002. Disponvel em: http://www.crosstalkonline.org/storage/issue- archives/2002/200203/200203-Diaz.pdf EBENAU, R. e STRAUSS S., 1994, Software Inspection Process, McGraw-Hill. FLORAC, W. A. e CARLETON, A. D., 1999, Measuring the Software Process, Addison-Wesley. FOWLER, M., 2003, UML Distilled: A Brief Guide to the Standard Object Modeling Language (3rd Edition), Addison-Wesley. FREEDMAN, D. P. AND WEINBERG G., 1990, Handbook of Walkthroughs, Inspections, and Technical Reviews. Dorset House, FRIED, J., 2005, An Analysis of the Correlation between System Engineering Defect Phase Containment and System Engineering Hours at General Dynamics C4 Systems . Disponvel em: http://www.acims.arizona.edu/PUBLICATIONS/PDF/JenniferFriedMCSproject%205-2105.pdf. GAUSE, D. and WEINBERG G., 1989, Exploring Requirements: Quality Before Design . Dorset House. GILB T. e GRAHAM D., 1994, Software Inspection, Addison-Wesley Professional. GLASS R., 1997, Software Runaways: Monumental Software Disasters, Prentice Hall. GOULD S., 1996, Dinosaur in a Haystack: Reflections in Natural History , Three River Press. GRIES, D., 1987, The Science of Programming, Springer. HALL, E., 1998, Managing Risk: Methods for Software Systems Development, Addison-Wesley Professional. HIGHSMITH, J., 1999, Adaptive Software Development: A Collaborative Approach to Managing Complex Systems, Dorset House. HIGHSMITH, J., 2001, Agile Alliances Agile Manifesto, History and Contents. Disponvel em: http://agilemanifesto.org/ HIGHSMITH, J., 2004, Agile Project Management. Creating Innovative Products, AddisonWesley. HOFMEISTER, C., NORD, R., e SONI, D., 2000, Applied Software Architecture, Addison Wesley. HUMPHREY, W., 1989, Managing the Software Process, Addison Wesley. HUNT, A. e THOMAS, D., 1999, The Pragmatic Programmer: From Journeyman to Master , Addison Wesley Professional.
Pgina 181
Boria et al.
ISO/IEC, 2003, ISO/IEC 15504 Software Engineering Process Assessment, The International Organization for Standardization and The International Electrotechnical Commision. ISO/IEC, 2008, ISO/IEC 12207 System and Software Engineering Software Life Cycle Process, The International Organization for Standardization and The International Electrotechnical Commision. JOHNSON, M., 2010, Seizing the White Space: Business Model Innovation for Growth and Renewal, Perseus Books Group. JONES, C., 1996 Applied Software Measurement, McGraw-Hill. JONES, C., 1994, Assessment and Control of Software Risks, Prentice-Hall. JONES, C., 1986, Programming Productivity, McGraw-Hill. JOSUTTIS, N.,2009, SOA in Practice: The Art of Distributed System Design, OReilly Media. KAPLAN, R., e NORTON, D., 1996, The Balanced Scorecard: Translating Strategy into Action, Harvard Business Review Press. KAN. S., 2002, Metrics and Models in Software Quality Engineering, 2nd Edition, AddisonWesley Professional. KERNIGHAN B. W., e PLAUGER P. J., 1974, The Elements of Programming Style, McGrawHill. KNIBERG, H., 2007, Scrum and XP from the Trenches. How we do Scrum, C4Media, Publisher of InfoQ.com. KNIBERG, H. e SKARIN, M., 2010, Kanban and Scrum - making the most of both, C4Media, Publisher of InfoQ.com. KUBLER-ROSS, E., 1997, On Death and Dying. Scribner. KUZNETS, S., 1966, Economic Growth and Structure. Selected Essays, Heinemann. LADAS, C., 2008, Scrumban and And Other Essays on Kanban Systems for Lean Software Development, Modus Cooperandi Press. LEFFINGWELL, D., 2007, Scaling Software Agility. Best Practices for Large Enterprises , Addison-Wesley. LUCIA, A.D., LEPSINGER, R., 2007, The Art and Science of Competency Models. Pinpointing Critical Success Factors in Organizations, Jossey-Bass Pfeiffer. McFEELEY, B., 1996, IDEAL : A Users Guide for Software Process Improvement. Software Engineering Institute Handbook CMU/SEI-96-HB-001. McMAHON, P., 2011, Integrating CMMI and Agile Development, Addison-Wesley. McGARRY,J.; CARD, D.; JONES, C.; LAYMAN, B.; CLARK, E.; DEAN, J. e HALL, F, 2002, Practical Software Measurement: Objective Information for Decision Makers, Addison Wesley. MEADOWS, D., 2008, Thinking in Systems, A Primer, Chelsea Green Publishing. MIRANDA, E., 2003, Running the Successful Hi-Tech Project Office, Artech House Publishers. MONDEN, Y., 2011, Toyota Production System: An Integrated Approach to Just-In-Time, 4th Edition, Productivity Press. MOREIRA, M., 2010, Adapting Configuration Management for Agile Teams. Balancing Sustainability and Speed, Wiley. MYERS, G., 1979, The Art of Software Testing, Wiley. NOLAN, R., 1973, Managing the Computer Resource: A Stage Hypothesis. CACM, Vol 16, No 7, July 1973, republished in Managing The Data Resource Function, same author, West.
SM
Pgina 182
Boria et al.
OKTABA, H. et al., 2005, Modelo de Procesos para la Industria del Software MoProSoft, versin 1.3. PALMER, S. R. e FELSING, J. M., 2002, A Practical Guide to Feature-Driven Development, Prentice Hall. PAULK, M., WEBER, C., E CURTIS, B., 1994, The Capability Maturity Model: Guidelines for Improving the Software Process, Addison Wesley. PIRSIG, R.M., 1974, Zen and the Art of Motorcycle Maintenance, An inquiry into Values , William Morrow and Co. PMI, 2008, Project Management Institute. The Standard for Portfolio Management . Syba: PMI Publishing Division. POPPENDIECK, M. e POPPENDIECK, T., 2010, Leading Lean Software Development. Results Are Not the Point, The Addison Wesley Signature Series. PUGH, S., 1991, Total Design: Integrated Methods for Successful Product Engineering . Addison-Wesley. PUGH, S. 1981, Concept selection: a method that works. In: Hubka, V. (ed.), Review of design methodology. Proceedings international conference on engineering design, March 1981, Rome. Zrich: Heurista. PUTNAM, L. H. e MYERS, W., 2003, Five Core Metrics: The Intelligence Behind Successful Software Management, Dorset House Publishing Company. RODIN, R. e HARTMAN, C., 2000, Free, Perfect and Now: Connecting to the Three Insatiable Customer Demands, A CEOs true Story, Free Press. RIES, E., 2011, The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses, Random House. ROYCE, W., 1970, Managing the Development of Large Software Systems, Proceedings of IEEE WESCON 26 (August): 19 SCHWABER, K. e BEEDLE, M., 2002, Agile Software Development with Scrum, Prentice Hall. SCHWABER, K., 2004, Agile Project Management with Scrum, Microsoft Press. SCHUYLER, J., 1996, Decision Analysis in Projects. Learn to Make Faster, More Confident Decisions, Project Management Institute. SEI, 2010, Capability Maturity Model Integration (CMMI) for Development, version 1.3 , Carnegie Mellon University, Software Engineering Institute, Technical Report CMU/SEI-2010-TR033. SENGE P. M., 2006, The Fifth Discipline: The Art & Practice of The Learning Organization , Crown Business. SHEWHART, W., 1939, Statistical Method from the Viewpoint of Quality Control, Dover Books on Mathematics. SOFTEX, 2011a, ASSOCIAO PARA PROMOO DA EXCELNCIA DO SOFTWARE BRASILEIRO SOFTEX, MPS.BR Guia de Aquisio:2011, junho 2011. Disponvel em: http://www.softex.br. SOFTEX, 2011b, ASSOCIAO PARA PROMOO DA EXCELNCIA DO SOFTWARE BRASILEIRO SOFTEX., MPS.BR Guia de Implementao Parte 1: Fundamentao para Implementao do Nvel G do MR-MPS:2011, junho 2011. Disponvel em: http://www.softex.br. SOFTEX, 2011c, ASSOCIAO PARA PROMOO DA EXCELNCIA DO SOFTWARE BRASILEIRO SOFTEX., MPS.BR Guia de Implementao Parte 2: Fundamentao para Implementao do Nvel F do MR-MPS:2011, junho 2011. Disponvel em: http://www.softex.br. SOFTEX, 2011d, ASSOCIAO PARA PROMOO DA EXCELNCIA DO SOFTWARE BRASILEIRO SOFTEX., MPS.BR Guia de Implementao Parte 3:
Pgina 183
Boria et al.
Fundamentao para Implementao do Nvel E do MR-MPS:2011, junho 2011. Disponvel em: http://www.softex.br. SOFTEX, 2011e, ASSOCIAO PARA PROMOO DA EXCELNCIA DO SOFTWARE BRASILEIRO SOFTEX., MPS.BR Guia de Implementao Parte 4: Fundamentao para Implementao do Nvel D do MR-MPS:2011, junho 2011. Disponvel em: http://www.softex.br. SOFTEX, 2011f, ASSOCIAO PARA PROMOO DA EXCELNCIA DO SOFTWARE BRASILEIRO SOFTEX., MPS.BR Guia de Implementao Parte 5: Fundamentao para Implementao do Nvel C do MR-MPS:2011, junho 2011. Disponvel em: http://www.softex.br. SOFTEX, 2011g, ASSOCIAO PARA PROMOO DA EXCELNCIA DO SOFTWARE BRASILEIRO SOFTEX., MPS.BR Guia de Implementao Parte 6: Fundamentao para Implementao do Nvel B do MR-MPS:2011, junho 2011. Disponvel em: http://www.softex.br. SOFTEX, 2011h, ASSOCIAO PARA PROMOO DA EXCELNCIA DO SOFTWARE BRASILEIRO SOFTEX., MPS.BR Guia de Implementao Parte 7: Fundamentao para Implementao do Nvel A do MR-MPS:2011, junho 2011. Disponvel em: http://www.softex.br. SOFTEX, 2011i, ASSOCIAO PARA PROMOO DA EXCELNCIA DO SOFTWARE BRASILEIRO SOFTEX., MPS.BR Guia de Implementao Parte 8: Implementao do MR-MPS:2011 em organizaes que adquirem software, junho 2011. Disponvel em: http://www.softex.br. SOFTEX, 2011j, ASSOCIAO PARA PROMOO DA EXCELNCIA DO SOFTWARE BRASILEIRO SOFTEX., MPS.BR Guia de Implementao Parte 9: Implementao do MR-MPS:2011 em organizaes do tipo Fbrica de Software, junho 2011. Disponvel em: http://www.softex.br. SOFTEX, 2011k, ASSOCIAO PARA PROMOO DA EXCELNCIA DO SOFTWARE BRASILEIRO SOFTEX., MPS.BR Guia de Implementao Parte 10: Implementao do MR-MPS:2011 em organizaes do tipo Fbrica de Teste, junho 2011. Disponvel em: http://www.softex.br. SOFTEX, 2011l, ASSOCIAO PARA PROMOO DA EXCELNCIA DO SOFTWARE BRASILEIRO SOFTEX., MPS.BR Curso de Introduo ao MPS-Software (C1-MPSSW), setembro 2011. SOFTEX, 2012a, ASSOCIAO PARA PROMOO DA EXCELNCIA DO SOFTWARE BRASILEIRO SOFTEX., MPS.BR Guia Geral MPS de Software:2012, agosto 2012. Disponvel em: http://www.softex.br. SOFTEX, 2012b, ASSOCIAO PARA PROMOO DA EXCELNCIA DO SOFTWARE BRASILEIRO SOFTEX., MPS.BR Guia Geral MPS de Servios:2012, agosto 2012. Disponvel em: http://www.softex.br. SOFTEX, 2012c, ASSOCIAO PARA PROMOO DA EXCELNCIA DO SOFTWARE BRASILEIRO SOFTEX., MPS.BR Guia de Avaliao:2012, maio 2012. Disponvel em: http://www.softex.br. SOFTEX, 2012d, ASSOCIAO PARA PROMOO DA EXCELNCIA DO SOFTWARE BRASILEIRO SOFTEX., MPS.BR Guia de Implementao Parte 11: Implementao e Avaliao do MR-MPS-SW:2012 em Conjunto com o CMMI-DEV v1.3, agosto 2012. Disponvel em: http://www.softex.br. SOFTEX, 2012e, ASSOCIAO PARA PROMOO DA EXCELNCIA DO SOFTWARE BRASILEIRO SOFTEX., MPS.BR Guia de Implementao Parte 12: Anlise da Aderncia do MRMPS-SW:2012 em relao NBR ISO/IEC 29110-4-1:2012 Engenharia de Software - Perfis de ciclo de vida para microorganizaes (VSEs) Parte 4-1: Especificaes de perfil: Grupo Perfil Genrico, setembro 2012. Disponvel em: http://www.softex.br. SOFTEX, 2012f, ASSOCIAO PARA PROMOO DA EXCELNCIA DO SOFTWARE BRASILEIRO SOFTEX., MPS.BR Guia de Implementao Parte 13: Mapeamento
Pgina 184
Boria et al.
e Sistemas de Equivalncias entre o MR-MPS-SW:2012 e o MoProSoft:2005, outubro 2012. Disponvel em: http://www.softex.br. SOLINGEN, R.; BERGHOUT, E., 1999, The Goal/Question/Metric Method: a Practical Guide for Quality Improvement of Software Development, McGraw-Hill. SPIEGEL, M. e STEPHENS, L., 2011, Schaums Outline of Statistics, Fourth Edition (Schaum's Outline Series) Mc Graw Hill. STAPLETON, J. e CONSTABLE, P., 1997, DSDM: Dynamic Systems Development Method: The Method in Practice, Addison-Wesley Professional. TALEB, N., 2012, Antifragile: Things That Gain from Disorder, Random House. TALEB, N., 2010, The Black Swan: Second Edition: The Impact of the Highly Improbable: With a new section: On Robustness and Fragility, Random House Trade Paperbacks. TENNANT, G., 2001, Six Sigma: SPC and TQM in Manufacturing and Services, Gower. TOIGO, J., 2002, Disaster Recovery Planning: Preparing for the Unthinkable (3rd Edition), Prentice Hall. UNKNOWN AUTHOR. Disponvel em: http://c2.com/cgi/wiki?CodeSmell. WARD, P., e MELLOR, S., 1986, Structured Development for Real-Time Systems, Volume I: Introduction and Tools, Prentice-Hall. WARD, P., e MELLOR, S., 1986, Structured Development for Real-Time Systems, Volume II: Essential Modeling Techniques, Prentice-Hall. WARD, P., e MELLOR, S., 1986, Structured Development for Real-Time Systems, Volume III: Implementation Modeling Techniques, Prentice-Hall. WHEELER, D., 2000, Understanding Variation. The Key to Managing Chaos , SPC Press. WEINBERG, G., 1992, Quality Software Management, vol. 1 Systems Thinking. Dorset. WEINBERG, G., 1993, Quality Software Management, vol. 2 First-Order Measurement. Dorset. WEINBERG, G., 1994, Quality Software Management, vol. 3 Congruent Action. Dorset. WEINBERG, G., 1997, Quality Software Management, vol. 4 Anticipating Change. Dorset. WOOD, S. e SILVER, D., 1995, Joint Application Development, Wiley. YOURDON, E., 1989, Structured Walkthroughs, Prentice-Hall. YOURDON, E., e CONSTANTINE, L. 1979, Structured Design: Fundamentals of a Discipline of Computer Program and System Design, Prentice-Hall. ZAHNISER, R., 1995, System Storyboarding Techniques, American Programmer, Sep 1993. Disponvel em: http://www.belizenorth.com/articles/SST.htm
Pgina 185

Te

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Te

Uploaded by

Copyright:

Available Formats

Melhoria de Processos de Software com Mtodos geis e Modelo MPS

Melhoria de Processos de Software com Mtodos geis e Modelo MPS

Jorge Luis Boria Viviana Leonor Rubinstein Andrs Rubinstein

Melhoria de Processos de Software com Mtodos geis e Modelo MPS

Melhoria de Processos de Software com Mtodos geis e Modelo MPS

Melhoria de Processos de Software com Mtodos geis e Modelo MPS

Melhoria de Processos de Software com Mtodos geis e Modelo MPS

Melhoria de Processos de Software com Mtodos geis e Modelo MPS

Melhoria de Processos de Software com Mtodos geis e Modelo MPS

3.4 XP: Inspees, Design, Cooperao e Muitas Provas .................................................... 23

Melhoria de Processos de Software com Mtodos geis e Modelo MPS

Melhoria de Processos de Software com Mtodos geis e Modelo MPS

Melhoria de Processos de Software com Mtodos geis e Modelo MPS

Melhoria de Processos de Software com Mtodos geis e Modelo MPS

Captulo 11 - Concluses ....................................................................................................... 179 Referncias Bibliogrficas ..................................................................................................... 180

Melhoria de Processos de Software com Mtodos geis e Modelo MPS

Melhoria de Processos de Software com Mtodos geis e Modelo MPS

Melhoria de Processos de Software com Mtodos geis e Modelo MPS

Melhoria de Processos de Software com Mtodos geis e Modelo MPS

Melhoria de Processos de Software com Mtodos geis e Modelo MPS

Melhoria de Processos de Software com Mtodos geis e Modelo MPS

Figura 1.1: Relao entre ferramentas e competncia das pessoas

Melhoria de Processos de Software com Mtodos geis e Modelo MPS

A comunidade gil se reconhece no website: http://www.agilemanifesto.org/ http://www.softex.br/mpsbr/_guias/default.asp

Melhoria de Processos de Software com Mtodos geis e Modelo MPS

Melhoria de Processos de Software com Mtodos geis e Modelo MPS

Melhoria de Processos de Software com Mtodos geis e Modelo MPS

Melhoria de Processos de Software com Mtodos geis e Modelo MPS

Melhoria de Processos de Software com Mtodos geis e Modelo MPS

Melhoria de Processos de Software com Mtodos geis e Modelo MPS

Figura 2.1: O Mtodo IDEAL (adaptado de [McFEELEY, 1996])

Melhoria de Processos de Software com Mtodos geis e Modelo MPS

Melhoria de Processos de Software com Mtodos geis e Modelo MPS

Figura 2.2: Viso de Melhoria de Processos do IDEAL (adaptado de [McFEELEY, 1996])

Melhoria de Processos de Software com Mtodos geis e Modelo MPS

Melhoria de Processos de Software com Mtodos geis e Modelo MPS

Melhoria de Processos de Software com Mtodos geis e Modelo MPS

Ouvir e reagir no o mesmo que escutar e satisfazer. http://www.agilemanifesto.org/

Melhoria de Processos de Software com Mtodos geis e Modelo MPS

Tabela 2.1: Seleo do Mtodo de Melhoria de Processos

Melhoria de Processos de Software com Mtodos geis e Modelo MPS

Melhoria de Processos de Software com Mtodos geis e Modelo MPS

Melhoria de Processos de Software com Mtodos geis e Modelo MPS

Figura 3.1: Painel kanban

Toyota Production System.

Melhoria de Processos de Software com Mtodos geis e Modelo MPS

Figura 3.2: Nota do Painel kanban

Melhoria de Processos de Software com Mtodos geis e Modelo MPS

Em ingls, hand-off entre um papel e o outro.

Melhoria de Processos de Software com Mtodos geis e Modelo MPS

Melhoria de Processos de Software com Mtodos geis e Modelo MPS

Figura 3.3: Processo Scrum

Momentos da Verdade em um Scrum

Melhoria de Processos de Software com Mtodos geis e Modelo MPS

[BECK, 2000], Extreme Programming Explained, Addison-Wesley.

Melhoria de Processos de Software com Mtodos geis e Modelo MPS

Desenvolvimento Dirigido por Testes

Melhoria de Processos de Software com Mtodos geis e Modelo MPS

Figura 3.4: Ciclo de Desenvolvimento de XP

Programao em Duplas (ou em Pares)

Vejam code smells, http://c2.com/cgi/wiki?CodeSmell

Melhoria de Processos de Software com Mtodos geis e Modelo MPS

Propriedade Coletiva (dos produtos pela equipe)