Melhoria de Processos de Software Com Métodos Ágeis e Modelo MPS

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

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

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
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
Andrs Rubinstein

Prefcio Pgina i
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 MR-
MPS-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

Prlogo Pgina ii
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-MPS-
SW.
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 bem-
sucedida. 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 iii
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 iv
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.
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.


Sumrio Pgina v
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 vi
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 vii
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 viii
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 ix
Captulo 11 - Concluses ....................................................................................................... 179
Referncias Bibliogrficas ..................................................................................................... 180


Lista de Figuras Pgina x
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 xi
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 Tabelas Pgina xii
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
Tabela 7.3: Riscos da T
2
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
Tabela 8.10: Implementao de DESENVOLVIMENTO DE REQUISITOS na T
2
.................... 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
Tabela 8.16 Resultados Esperados de VERIFICAO e Atividades Internas em T
2
.............. 134
Tabela 8.17: Resultados Esperados de VALIDAO e Atividades Internas em T
2
................. 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 xiii
Tabela 10.1: Os Problemas do Projeto Fora de Controle ......................................................... 165
Tabela 10.2: A ltima Fila da Anlise depois de Completa ...................................................... 168


Capitulo 1 Pgina 1
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
1
: 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 2
ferramentas de software. comum o caso de empresas e organizaes
2
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
referir a ela pelas siglas que seus scios usam para cham-la: T
2
, 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.
XP difcil de controlar. Acompanhando o crescimento da T
2
, 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 3
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
introduz em detalhes os primeiros passos da T
2
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
FDD. Finalmente, a quarta parte (Captulos 10 e 11) expe como a maturidade definida da T
2

permite alcanar um conhecimento profundo do funcionamento de seus processos,
caracterizando-os quantitativamente. O livro termina com um resumo da viagem da T
2
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
mtodo gil segundo seus criadores, e reconhecido como tal pela comunidade gil
3
, 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
publicados pela SOFTEX e que se encontram acessveis no website desta organizao
4
. 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
2
. 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
perfeita que acaba arruinando at mesmo a melhor reputao. a que os amigos da T
2

decidem introduzir mtodos de controle e, aconselhados corretamente, comeam a utilizar
Kanban. Ao mesmo tempo, conseguem implantar sem muito esforo extra, processos do

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

Capitulo 1 Pgina 4
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.
A adoo do MPS pela empresa T
2
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
assegurar-se de que est no caminho certo, a T
2
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
coloca em uma encruzilhada: para onde queremos levar a T
2
? 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
2
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
processos e tambm dos demais. Uma iniciativa brilhante sai de uma destas propostas e a T
2

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
modelo. No Captulo 9, introduzida a viso do risco como constante. A T
2
no define a si

Capitulo 1 Pgina 5
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
concludos, a T
2
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
momento na histria da T
2
no se aprendia sistematicamente a partir das decises j tomadas.
Para evitar que esse conhecimento se perca, a T
2
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
terceiros. A T
2
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
clientes, a T
2
acrescentou a seu arsenal o mtodo FDD, que permite planejar os sprints com
maior preciso. A T
2
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
2
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 custo-
benefcio 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.


Capitulo 2 Pgina 6
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 7
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
organizao que pretende melhorar seus processos, levando em conta o seu negcio
5
. 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 8
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
Deming em vrias ocasies
6
. 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
encontrar o material original, mas na maioria das citaes
7
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
O livro [SHEWHART, 1939] foi compilado por Deming com um prefcio de sua autoria.
7
Veja-se por exemplo http://quality.enr.state.nc.us/tools/pdca.htm

Capitulo 2 Pgina 9
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, espera-
se 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 10
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 11
lo sem ter lido todos esses detalhes
8
, com a consequente perda de vrios elementos
fundamentais, como o vnculo com os objetivos de negcio, o paralelismo na implementao
9
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
nfase nas ferramentas de Six-Sigma
10
. 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

8
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 12
melhoria onde ele ter maior benefcio. Para Arthur, a aplicao da lei de Pareto
11
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
as causas dos problemas para poder melhor-las ou difundi-las
12
. Utilizar a anlise da causa-
raiz 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
um diagrama de fluxo, sendo que h outras ferramentas possveis
13
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 13
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
14
. 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
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 14
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
necessidades
15
. 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
Manifesto
16
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
Ouvir e reagir no o mesmo que escutar e satisfazer.
16
http://www.agilemanifesto.org/

Capitulo 2 Pgina 15
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 melhorias 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 peso PDCA IDEAL FISH LS
NEGCIO 5 1 3 3 3
DETALHE 4 1 1 2 3
SISTEMA 3 2 1 1 3
MARCO 2 2 0 0 3
soma

19 22 26 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 de problemas raiz conduz aprendizagem
organizacional.
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 3 Pgina 16
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], Feature-
Driven 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
de software de modo nico, o Agile Software Development Manifesto
17
.
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
gria dos agilistas
18
um Sprint
19
, 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
http://agilemanifesto.org/
18
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 17
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
so Kanban
20,21
, Scrum
22
, XP
23
e FDD
24
. 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
que no haja estoque
25
. 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
[KNIBERG e SKARIN, 2010]
21
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 18
naquelas organizaes de baixa maturidade institucional. Como vimos, o mtodo Kanban um
dos mecanismos que suportam o TPS
26
, 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 pr-
estabelecida 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
nota, desenhados para esse uso, como mostrado na Figura 3.2
27
. 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
Toyota Production System.
27
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 19
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;
Explicitar Polticas de Processo; e Utilizar Modelos
28
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 20
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
intermedirios que so gerados ao acontecer um repasse
29
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 21
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
que suas decises no sejam revistas
30
. Na linguagem de Scrum esta pessoa conhecida
como o Dono do Produto.
Em segundo lugar, o pessoal deve ser dividido em equipes interdisciplinares pequenas, auto-
organizadas, 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 22
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
usurio CRACK
31
, 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 23
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
pequenas que repetem rapidamente seus ciclos de desenvolvimento. De fato, Kent Beck
32
, 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 24
escutando indefinidamente
33
. 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 25
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
encontrados nas referncias
34
.
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
justifica o sucesso da produtividade de sua tcnica particular de programao em duplas
35,36
.
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
Vejam code smells, http://c2.com/cgi/wiki?CodeSmell
35
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 26
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 27
Escalonamento
Quase desde o princpio de sua existncia, a engenharia de software se ocupa de dois
problemas ligados entre si: Programming in the Large e Programming in the Many
37
. O
primeiro problema o de atacar projetos grandes. O conceito de grande relativo mdia
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 28
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
Programador-Chefe
38
. 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 29
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
processo, construir a lista de funes
39
. Neste passo, a equipe reduzida aos Programadores-
Chefe. 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 30
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 31
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
acordado, o invariante resultado da execuo dos mtodos da classe
40
. Finalmente, a equipe
revisa o design resultante para garantir sua totalidade, consistncia e o que pode ser realizado
segundo o plano. Este o critrio de sada da fase
41
.
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
em CMM
42
, 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 4 Pgina 32
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
estados que oferece precisamente esse guia
43
.

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
trabalho
44
, 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.
Nvel
CMM
Porcentagem
Retrabalho
Eficcia da
Fase de
Conteno
Densidade
CRUD
por
KSLOC
Produtividade
(x Fator
Relativo)
2 23.2% 25.5% 3.20 1 x
3 14.2% 41.5% 0.90 2 x
4 9.5% 62.3% 0.22 1.9 x
5 6.8% 87.3% 0.19 2.9 x
Tabela 1: Sistema de Deciso General Dyamics
Desempenho do Projeto vs. Nivel CMM

Capitulo 4 Pgina 33
dois critrios para a boa formao de modelos de estados, descritos por Simon Kuznets
45
: 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
definio, avaliao e melhoria de processos de software
46
.

45
[KUZNETS, 1966]
46
[SOFTEX, 2012a], pgina 6

Capitulo 4 Pgina 34

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
entender a gnese
47
, 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 MR-
MPS-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 35
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 Atributos de Processo
A
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
B Gerncia de Projetos GPR (evoluo)
AP 1.1, AP 2.1, AP 2.2,
AP 3.1, AP 3.2, AP 4.1
e AP 4.2
C
Gerncia de Riscos GRI AP 1.1, AP 2.1, AP 2.2,
Desenvolvimento para Reutilizao DRU AP 3.1 e AP 3.2
Gerncia de Decises GDE
D
Verificao VER AP 1.1, AP 2.1, AP 2.2,
Validao VAL AP 3.1 e AP 3.2
Projeto e Construo do Produto PCP
Integrao do Produto ITP
Desenvolvimento de Requisitos DRE
E
Gerncia de Projetos GPR (evoluo) AP 1.1, AP 2.1, AP 2.2,
Gerncia de Reutilizao GRU AP 3.1 e AP 3.2
Gerncia de Recursos Humanos GRH
Definio do Processo Organizacional DFP
Avaliao e Melhoria do Processo Organizacional AMP
F
Medio MED AP 1.1, AP 2.1 e AP 2.2
Garantia da Qualidade GQA
Gerncia de Portflio de Projetos GPP
Gerncia de Configurao GCO
Aquisio AQU
G
Gerncia de Requisitos GRE AP 1.1 e AP 2.1
Gerncia de Projetos GPR
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 36

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 estados 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 37
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. Trata-
se 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 38
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
mudana
48
.
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 39

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
um objeto, mas um processo, um devir
49
, 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 40

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 auto-
evidncia 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 41
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
processos reais
50
.

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
mudana da organizao. Como diz Peter Senge em [SENGE, 2006]
51
, 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 42
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,
derivadas dos dois eixos sobre os quais se apoia uma organizao
52
:

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 43

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 44
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
organizao/unidade organizacional
53
; permitir a atribuio de um nvel de maturidade do MR-
MPS-SW baseando-se no resultado da avaliao; ser aplicvel a qualquer domnio na indstria
de software; ser aplicvel a organizaes e unidades organizacionais de qualquer tamanho
54
.
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 5 Pgina 45
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
2
, 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
momento em que os conhecemos, a T
2
est alcanando seus vinte meses de funcionamento
contnuo e os gmeos esto para prestar o ltimo exame para se formar.
No comeo, a T
2
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
oramento muito superficial, que enviado ao cliente e que, se for aprovado, inicia o que na T
2

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

Capitulo 5 Pgina 46
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
da T
2
, de onde o cliente pode us-lo.
No momento em que nossa equipe chamada para colaborar com eles para realizar melhorias
em seus processos, a T
2
est a ponto de concretizar um lanamento importante para dentistas.
5.2 Quem assume a responsabilidade?
Hoje um grande dia na T
2
. 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
presso de alguns membros da Sociedade para cancelar o contrato com a T
2
, 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
clientes. Por tudo isso, o Doutor Molar pede T
2
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
antes de romper com a T
2
;
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 Mariano:
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

Capitulo 5 Pgina 47
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 ganha-
ganha 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 consultor-
lder, 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. Trata-
se 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 48
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 ferramentas), 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
Oito Disciplinas
55
:
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 quarta-
feira, 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.
Nosso homem em T
2
parte para definir, seguindo o mtodo, as caractersticas desejveis do
processo:
Evitar que o problema se repita no futuro
Ser muito fcil de implementar (dois ou trs dias na T
2
)
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
necessidades da T
2
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 49
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
no universo da T
2
. 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 50
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 51
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 1 2 3 4 5 6 7
Categoria
muito
simples
simples
menos que
o normal
normal
mais que o
normal
complicado
muito
complicado
funes
derivadas
1 2 3 4 5 a 6 7 a 10 mais de 10
Dias No dia 1 a 2 2 a 4 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 52
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
56
!, 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.
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
2
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.

56
http://www.mountaingoatsoftware.com/blog/stories-epics-and-themes

Capitulo 5 Pgina 53
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 encerra-
se a sesso, e ainda resta pouco mais de uma hora para trabalhar pela manh.
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
fazem o resto. Um memorando de acordo assinado entre a T
2
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
clculo. A T
2
tem uma semana para responder com um plano e uma proposta de honorrios.
Estabelecida uma boa relao entre a T
2
e Mximo, ele chamado diretamente para que
facilite outra reunio para dar a resposta.

Capitulo 5 Pgina 54
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
do MPS com a T
2
, 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
aqui e outra ali, na tarde de sexta-feira est de novo na sala de design da T
2
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
instalaram na T
2
. 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
fechar. Mas esta a primeira proposta com desenvolvimento sob medida que a T
2
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
ID NOME IMPORTNCIA TAMANHO VALIDAO
RISCOS
ASSOCIADOS
CAPACIDADES
NECESSRIAS
1
2
3
4
5
Figura 5.6: Planilha para Definio de Histrias
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
capacidade de construir
57
.

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 55

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
Histrias <link com documento Histrias>
Identificador
Nome
Importncia
Tamanho
Validao
Riscos <link com a planilha de riscos>
Capacidades Requeridas
Calendrio de Trabalho
Sprint 1
Sprint 2
Sprint
Sprint de estabilizao
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 56
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
58
que permite
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
adequado para empresas como a T
2
o MPS.
O que o MPS? pergunta Claudio.
Mximo d uma explicao precisa sobre as vantagens do modelo MPS, matizada com
conceitos como avaliaes, evidncia direta e outros termos que hoje so novos na T
2
, 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
precisa falar na Vitalera para que a T
2
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
2
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
na T
2
:
Gerncia de Projetos (GPR) no Nvel G
GPR1 O escopo do trabalho para o projeto definido;
GPR2 As tarefas e os produtos de trabalho do projeto so dimensionados utilizando
mtodos apropriados;
GPR3 O modelo e as fases do ciclo de vida do projeto so definidos;
GPR4 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;
GPR5 O oramento e o cronograma do projeto, incluindo a definio de marcos e
pontos de controle, so estabelecidos e mantidos;

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 57
GPR6 Os riscos do projeto so identificados e o seu impacto, probabilidade de
ocorrncia e prioridade de tratamento so determinados e documentados;
GPR7 Os recursos humanos para o projeto so planejados considerando o perfil e o
conhecimento necessrios para execut-lo;
GPR8 Os recursos e o ambiente de trabalho necessrios para executar o projeto so
planejados;
GPR9 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;
GPR10 Um plano geral para a execuo do projeto estabelecido com a integrao
de planos especficos;
GPR11 A viabilidade de atingir as metas do projeto explicitamente avaliada
considerando restries e recursos disponveis. Se necessrio, ajustes so
realizados;
GPR12 O Plano do Projeto revisado com todos os interessados e o compromisso
com ele obtido e mantido;
GPR13 O escopo, as tarefas, as estimativas, o oramento e o cronograma do projeto
so monitorados em relao ao planejado;
GPR14 Os recursos materiais e humanos bem como os dados relevantes do projeto
so monitorados em relao ao planejado;
GPR15 Os riscos so monitorados em relao ao planejado;
GPR16 O envolvimento das partes interessadas no projeto planejado, monitorado
e mantido;
GPR17 Revises so realizadas em marcos do projeto e conforme estabelecido no
planejamento;
GPR18 Registros de problemas identificados e o resultado da anlise de questes
pertinentes, incluindo dependncias crticas, so estabelecidos e tratados
com as partes interessadas;
GPR19 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]
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
2
tero que
trabalhar para gerar as mudanas necessrias para que os processos estejam implementados.

Capitulo 5 Pgina 58
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 59
Gerncia de Requisitos (GRE)
GRE1 O entendimento dos requisitos obtido em conjunto com os
fornecedores de requisitos;
GRE2 Os requisitos so avaliados com base em critrios objetivos e obtido o
compromisso da equipe tcnicas com estes requisitos;
GRE3 A rastreabilidade bidirecional entre os requisitos e os produtos de trabalho
estabelecida e mantida;
GRE4 Revises em planos e produtos de trabalho do projeto so realizadas com o
objetivo de identificar e corrigir inconsistncias relacionadas aos requisitos;
GRE5 Mudanas nos requisitos so geridas durante o projeto.
Tabela 5.3 Processo GERNCIA DE REQUISITOS [SOFTEX, 2012a]
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.
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 60
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 baseiam-
se 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
enunciado aparece hoje encabeando a pgina de processos da T
2
. 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
interessado. Quando a T
2
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
modo, a T
2
atende aos resultados esperados dos Atributos de Processo.

Capitulo 5 Pgina 61
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
aos processos para melhor-los. Essas reunies recebem o nome de retrospectivas, e a T
2
as
adota sob a preparao e superviso
59
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 62

Figura 5.11: Evidncias para GPR no Nvel G
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
alinhamentos do que esperado do pessoal da T
2
.
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
2
organizando a avaliao formal do Nvel G do modelo MPS.


Capitulo 6 Pgina 63
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
competncias necessrias e delimitao de novas responsabilidades
60
.
26. T
2
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
de avaliao MPS, estes foram resolvidos prontamente pelo pessoal da T
2
e a organizao
recebeu sua placa de ao em um evento do Simpsio Brasileiro de Qualidade de Software
(SBQS) realizado anualmente. A notcia circulou rapidamente nos meios locais e a T
2
teve seus
quinze minutos de fama. Por mais breve que tenha sido essa notoriedade, os amigos da T
2
,
como o Doutor Molar, se sentiram obrigados a compartilhar o orgulho que a notcia trouxe. A
consequncia imediata foi que outros clientes se aproximaram da T
2
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
ofertados aos membros do CoProCoP e, ao mesmo tempo, que a T
2
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
2
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
2
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 64
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 65
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 Implica na contratao de servios externos
Muitas linhas de produto 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. Serem contratados os servios equivocados;
2. Serem contratados os fornecedores equivocados;
3. Serem escolhidos a partir de um subconjunto inadequado de fornecedores;
4. Serem escolhidos subjetivamente;
5. Ser feito um contrato que no atenda aos interesses das duas partes;
6. 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 66
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;
AQU2 Os critrios de seleo do fornecedor so estabelecidos e usados para avaliar
os potenciais fornecedores;
AQU3 O fornecedor selecionado com base na avaliao das propostas e dos
critrios estabelecidos;
AQU4 Um acordo que expresse claramente as expectativas, responsabilidades e
obrigaes de ambas as partes (cliente e fornecedor) estabelecido e
negociado entre elas;
AQU5 Um produto que satisfaa a necessidade expressa pelo cliente adquirido
baseado na anlise dos potenciais candidatos;
AQU6 A aquisio monitorada de forma que as condies especificadas sejam
atendidas, tais como: custo, cronograma e qualidade, gerando aes
corretivas quando necessrio;
AQU7 O produto entregue e avaliado com relao ao acordado e os resultados so
documentados;
AQU8 O produto adquirido incorporado ao projeto, caso pertinente.
Tabela 6.3: Processo AQUISIO [SOFTEX, 2012a]
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
criar uma matriz de Pugh
61
que contenha as alternativas e us-la quando for necessrio. Com
essa tarefa pendente termina a reunio.

61
Ver Captulo 2.

Capitulo 6 Pgina 67
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 ajud-
los a resolver essa questo, facilitando a reunio dos scios. Quando Mximo chega ao
escritrio da T
2
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
est interessada em desenvolver um sistema novo, na nuvem, pelo qual a experincia de T
2

bastante importante, e um fornecedor de servios a agentes de seguros que tambm quer 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
escreve: Viso para T
2
: 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 carteiras, 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 68
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 contadores
software para
drogaras
Associao
servios de sade
servios a
agentes de
seguros
esforo
1 sistema
completo
1 sistema
migrao a SaaS
1 sistema integrado
para hospitais

domnio contabilidade manejo de stocks ERP completo
sinergia boa mediana total
investimento media media enorme
alinhamento bom mediano enorme
mercado
pot.
muito amplo drogarias
hospitais, drogarias,
mdicos
????????
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 69
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: mitigao:
escolhermos as linhas de produto sem
uma viso estratgica como base
seguirmos um processo ordenado para fixar a
viso, a estratgia e as linhas de negcio
no h oramento suficiente para todas
as linhas de produto
as linhas de produto escolhidas sero
financiadas proporcionalmente sua
importncia estratgica
ningum ficar a cargo de cumprir a viso
estratgica
vincularmos, claramente, a responsabilidade por
cada linha de produto com nfase nos
resultados de negcio
com o tempo a viso estratgica ser
perdida
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
utilizarmos a viso estratgica para resolver
conflitos de recursos e dependncias crticas
certos projetos perderem valor para a
estratgia
revisar, periodicamente, a viso estratgica e
redefinir as linhas de produto, cancelando ou
continuando projetos
a organizao em seu conjunto no
visualizar as decises estratgicas
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;
GPP2 Os recursos e oramentos para cada projeto so identificados e alocados;
GPP3 A responsabilidade e autoridade pelo gerenciamento dos projetos so
estabelecidas;
GPP4 O portflio monitorado em relao aos critrios que foram utilizados para a
priorizao;
GPP5 Aes para corrigir desvios no portflio e para prevenir a repetio dos
problemas identificados so estabelecidas, implementadas e acompanhadas
at a sua concluso;
GPP6 Os conflitos sobre recursos entre projetos so tratados e resolvidos, de
acordo com os critrios utilizados para a priorizao;
GPP7 Projetos que atendem aos acordos e requisitos que levaram sua aprovao
so mantidos, e os que no atendem so redirecionados ou cancelados;

Capitulo 6 Pgina 70
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]
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 71
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 72
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 compar-
las, 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 73
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
relacionados com o produto, e durao, esforo e custo da tarefa. Com isto em mente, a T
2

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
riscos associados (Tabela 6.8) a uma possvel m definio do sistema de deciso
62
que os
leva a estabelecer medidas para evit-los ou minimiz-los.
risco: mitigao:
o sistema de deciso ser defindo
arbitrariamente sem considerar a viso
estratgica
estabelecer objetivos de medio que
correspondam viso estratgica, considerando
as decises derivadas
as medidas e indicadores utilizados nos
projetos serem decididos sem considerar
as necessidades organizacionais
decidir as medidas a serem usadas nos projetos
em conjunto pela gerncia do projeto e o PMO
cada projeto ter uma verso diferente do
sistema de deciso
especificar claramente o procedimento de
medio com responsabilidades e controles
ter-se um sistema de deciso mas no se
ter dados
controlar para que os dados requeridos sejam
coletados e analisados
no ser possvel reproduzir uma deciso
baseada em dados porque os dados no
so guardados
guardar os dados e os resultados das anlises de
maneira que possam ser recuperados
nem todos os interessados entenderem o
porqu das decises
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;
MED2 Um conjunto adequado de medidas, orientado pelos objetivos de medio,
identificado e definido, priorizado, documentado, revisado e, quando
pertinente, atualizado;
MED3 Os procedimentos para a coleta e o armazenamento de medidas so
especificados;
MED4 Os procedimentos para a anlise das medidas so especificados;
MED5 Os dados requeridos so coletados e analisados;
MED6 Os dados e os resultados das anlises so armazenados;

62
A T
2
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 74
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
clientes para o sistema atual, pois o financiamento dever vir da liquidez para manter a T
2

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
com o existente da T
2
, 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 Fonte de Dados Critrio de Validade
Data Planejada de
finalizao do Programa
Planilha de construo
de programas do lder
tcnico do projeto
O Plano est aprovado e
sob controle de
configurao
Data Real de finalizao do
programa
Subversion A data de entrada gerada
automaticamente pela
ferramenta
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 Clculos utilizados
Programas Acumulados
Planejados para a Semana
Contagem do nmero de programas cuja data de
finalizao segundo o plano cai dentro da semana
em questo.
Programas Acumulados
Realizados na Semana
Contagem do nmero de programas cuja data de
finalizao segundo o Subversion ocorreu dentro da
semana em questo.
Tabela 6.10: Definio de Medidas
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
paralelas. O ambiente se energiza e a T
2
comea a preparar sua decolagem. Claudio inicia

Capitulo 6 Pgina 75
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
com os clientes. Praticamente sozinho, ele sintetiza o que a T
2
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 <data>
Especificao e
Uso do Indicador
<nome do indicador, explicar seu uso>
Amostra do
Indicador

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
0
20
40
60
80
100
120
140
160
data
1
data
2
data
3
data
4
data
5
data
6
data
7
Ttulo, com Data do Relatrio
Medida Derivada 1
Medida Derivada 2

Capitulo 6 Pgina 76

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: mitigao:
Se no sabemos onde esto
armazenados os produtos e os
resultados, perderemos tempo e
possivelmente trabalho
adotar um sistema de gesto de documentao
Se no se pode encontrar uma folha no
bosque, vai ser perdido muito tempo
identificando cada parte
adotar um sistema de classificao dos itens
armazenados
Se os documentos so atualizados sem
que os interessados saibam da
atualizao, pode haver conflitos entre
mudanas
adotar um critrio de baseline onde s se pode
modificar um documento da baseline sob regras
rigorosas de controle
Se no sabemos quem mudou o que,
nem quando mudou, pode ser difcil
reproduzir os motivos e decises em
torno de uma mudana
registrar a histria das mudanas de baseline
seguir um processo formal para mudar um
produto
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
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
63
. 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
produto em questo. Para a T
2
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
Existem outras baselines,por exemplo, baselines de cronograma e de comportamento de um processo
que veremos mais adiante.

Capitulo 6 Pgina 77
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 Dono acesso Atualizao verses
cdigo Mltiplos check out check in e merge mltiplos
baseline nico (por papel) read only write do dono nica em vigncia
comunicao Ningum read only no se aplica 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 Um Sistema de Gerncia de Configurao estabelecido e mantido;
GCO2 Os itens de configurao so identificados com base em critrios
estabelecidos;
GCO3 Os itens de configurao sujeitos a um controle formal so colocados sob
baseline;
GCO4 A situao dos itens de configurao e das baselines registrada ao longo do
tempo e disponibilizada;
GCO5 Modificaes em itens de configurao so controladas;

Capitulo 6 Pgina 78
GCO6 O armazenamento, o manuseio e a liberao de itens de configurao e
baselines so controlados;
GCO7 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]
34. Como a T
2
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
pessoas novas trabalhando na T
2
e a sala de design passou a ser a sala de uma das duas
equipes de Scrum. A um quarteiro dali, mais perto do rio, abriram uma filial da T
2
, 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
2
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
SlideShare
64
. 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
2
, 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:

64
http://www.slideshare.net/jorgeboria/qa-3-best-practices

Capitulo 6 Pgina 79
risco: mitigao:
Se no possvel compartilhar os
produtos porque possuem diferentes
formatos possvel que tenhamos
muitos erros involuntrios
verificar se os produtos esto aderentes s
regras que so poltica da organizao
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
verificar se as pessoas seguem as regras e
processos que so poltica da organizao
Se detectarmos problemas mas no os
comunicamos, eles no sero resolvidos
por si mesmos, e possvel que todos
percam o respeito aos processos
comunicar os problemas e as no
conformidades que possam ser resolvidas
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
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. revisar os riscos
2. revisar o plano
3. selecionar processos crticos
4. selecionar produtos crticos
5. planejar auditorias
6. realizar auditorias
7. 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 INSALVVEL: Corrigir imediatamente, escalar de imediato;
SEV 2
GRAVE: Consertar antes do prximo marco, escalar se no for
corrigido;
SEV 3
NEGOCIVEL : (a) Consertar antes do prximo marco ou (b)
auditar na prxima oportunidade, escalar se (a) no for
consertado;
SEV 4
SALVVEL: Fornecer dispensa, registrar no conformidade,
fechar;
SEV 5 REPREENSVEL: Advertir, fechar.
Tabela 6.16: Severidade de No conformidades em Auditorias
O procedimento realizar auditorias contm um mtodo de escalonamento que tambm
submetido ao julgamento dos scios. Dependendo da severidade, o procedimento permite
alcanar nveis da direo da T
2
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 80

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 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;
GQA2 A aderncia dos processos executados s descries de processo, padres e
procedimentos avaliada objetivamente;
GQA3 Os problemas e as no conformidades so identificados, registrados e
comunicados;
GQA4 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]
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
prticas de Scrum, colocando em bom uso o investimento da T
2
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 81
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 chamam: 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
grau de cobertura dos resultados esperados do MR-MPS-SW na T
2
. Revisam os resultados
com Mximo e, com satisfao, reafirmam que o caminho escolhido est correto (Figura 6.8).
T
2
comea a preparar sua avaliao nvel F do modelo MPS de Software (MPS-SW).
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 82

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.
K
a
n
b
a
n
B
a
c
k
l
o
g
J
o
g
o

d
e

P
l
a
n
i
f
.
V
e
l
o
c
i
d
a
d
e

H
i
s
t
r
i
c
a
T
a
x
a

d
e

"
Q
u
e
i
m
a
d
o
"
R
e
t
r
o
s
p
e
c
t
i
v
a
D
e
m
o
S
c
r
u
m

D
i
r
i
o
Gerncia de Projetos nos Nveis G e F
GPR 1 O escopo do trabalho para o projeto definido; a
GPR 2 As tarefas e os produtos de trabalho do projeto so dimensionados utilizando mtodos apropriados a a a
GPR 3 O modelo e as fases do ciclo de vida do projeto so definidos a a
GPR 4 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
a a
GPR 5 O oramento e o cronograma do projeto, incluindo a definio de marcos e pontos de controle, so
estabelecidos e mantidos
a
GPR 6 Os riscos do projeto so identificados e o seu impacto, probabilidade de ocorrncia e prioridade de
tratamento so determinados e documentados
a a
GPR 7 Os recursos humanos para o projeto so planejados considerando o perfil e o conhecimento necessrios
para execut-lo
GPR 8 Os recursos e o ambiente de trabalho necessrios para executar o projeto so planejados
GPR 9 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
GPR 10 Um plano geral para a execuo do projeto estabelecido com a integrao de planos especficos
GPR 11 A viabilidade de atingir as metas do projeto explicitamente avaliada considerando restries e recursos
disponveis. Se necessrio, ajustes so realizados
a a
GPR 12 O Plano do Projeto revisado com todos os interessados e o compromisso com ele obtido e mantido
GPR 13 O escopo, as tarefas, as estimativas, o oramento e o cronograma do projeto so monitorados em relao ao
planejado
a a a a
GPR 14 Os recursos materiais e humanos bem como os dados relevantes do projeto so monitorados em relao ao
planejado
a a a a
GPR 15 Os riscos so monitorados em relao ao planejado; a a a
GPR 16 O envolvimento das partes interessadas no projeto planejado, monitorado e mantido a a
GPR 17 Revises so realizadas em marcos do projeto e conforme estabelecido no planejamento a
GPR 18 Registros de problemas identificados e o resultado da anlise de questes pertinentes, incluindo
dependncias crticas, so estabelecidos e tratados com as partes interessadas
a
GPR 19 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

Capitulo 6 Pgina 83
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
alinhamentos do que se espera dos colaboradores da T
2
.
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
2
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
2
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.

Capitulo 6 Pgina 84
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 7 Pgina 85
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-MPS-
SW, 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
2
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
na elaborao de um modelo de competncias
65
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 86
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
de misso e funes da T
2
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 87
3. Cria Procedimentos de Teste
4. Cria Casos de Teste
5. Executa os procedimentos de teste usando os casos de teste
6. Informa os resultados de cada teste
7. Cria casos de teste crticos para assegurar a identificao do defeito
8. 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 88
corretamente como pessoal efetivo da T
2
. 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
um cargo so aquelas que so prprias dos processos da T
2
, por exemplo, um Scrum Master
deve possuir as competncias que lhe permitam fazer funcionar sua equipe, mas, alm disso,
deve fazer da maneira esperada na T
2
, 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
entendem serem indispensveis para trabalhar na T
2
, 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 89
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 Filtrar os candidatos da BD
2 Escolher entre os filtrados
3 Agendar entrevistas funcionais
4 Realizar entrevistas funcionais
5 Agendar entrevistas tcnicas
6 Realizar entrevistas tcnicas
7 Realizar oferta inicial
8 Obter aprovao
9 Realizar oferta final
10 Contratar
11 Introduzir o conhecimento da empresa
12 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 90
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
Humanos. Aqui esto seus argumentos, novamente analisados como riscos para a T
2
:
Desenvolvimento de Recursos Humanos
risco: mitigao:
se crescermos sem previso de recursos
humanos vamos ter muito atraso para
incorporar pessoal e nem sempre
poderemos responder demanda
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
dados nossos processos especficos,
provvel que o perodo de aprendizado e
ajuste s necessidades da T
2
seja muito
longo para nossos negcios.

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
avaliar se os treinamentos cumprem com seu
propsito
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
definir mtodos objetivos de medir
desempenho e utiliz-los para melhorar o
rendimento do pessoal e identificar
oportunidades de melhorias
se desperdiarmos o conhecimento
deveremos recri-lo periodicamente, a
um custo muito alto
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
2
Derivados de Polticas Pobres em Recursos Humanos
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 91
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
(Em Deus confiamos, os demais tragam dados)
66
.
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 que 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 1 2 3 4 5
Tarefa
Leigo Principiante Jnior Snior Especialista
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

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 92
Realiza a
apresentao
do mtodo de
desenvolvi-
mento da T
2

No
conhece o
material e
no
capaz de
apresent-
lo
Ajuda na
explicao
sobre o uso
dos materiais
no exerccio
Apresenta o
material com
mnimos
problemas e
conduz os
exerccios
Prepara a
apresentao,
apresenta o
material sem
problemas e
conduz os
exerccios
Prepara a
apresenta
o, apresenta
muito bem o
material e
conduz os
exerccios
Realiza
ajustes
proposta
frente ao
cliente ante
pedidos
expressos de
mudana
No sabe
como se
comportar
frente s
mudanas
no projeto
Tenta seguir
o processo de
controle de
mudanas,
mas se perde
e no
consegue
resultados
Avalia
mudanas
medindo seu
impacto em
custo e tempo
de entrega e
gerencia as
prprias
mudanas
Mantm a
integridade da
proposta sem se
confrontar com
o cliente e
assegura que as
mudanas de
impacto se
refletem no
escopo da
proposta
Coordena as
mudanas
com todos
os
interessados
e equilibra
os
interesses
coletivos
para chegar
ao ganha-
ganha
Tabela 7.4: Primeira Parte de um Modelo de Competncias

LISTA DE AVALIAO

Fase
de Apoio
Venda

Participa
da reunio
inicial

Tarefa

Anota
Faz perguntas
adequadas para
que todos
entendam melhor
a discusso
Participa e
facilita a
reunio
capaz de
sintetizar os
resultados
alcanados
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 mostra-
se 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;
GRH2 indivduos com as habilidades e competncias requeridas so identificados e
recrutados;
GRH3 As necessidades de treinamento que so responsabilidade da organizao so
identificadas;

Capitulo 7 Pgina 93
GRH4 Uma estratgia de treinamento definida, com o objetivo de atender s
necessidades de treinamento dos projetos e da organizao;
GRH5 Um plano ttico de treinamento definido, com o objetivo de implementar a
estratgia de treinamento;
GRH6 Os treinamentos identificados como responsabilidade da organizao so
conduzidos e registrados;
GRH7 A efetividade do treinamento avaliada;
GRH8 Critrios objetivos para avaliao do desempenho de grupos e indivduos so
definidos e monitorados para prover informaes sobre este desempenho e
melhor-lo;
GRH9 Uma estratgia apropriada de gerncia de conhecimento planejada, estabelecida
e mantida para compartilhar informaes na organizao;
GRH10 Uma rede de especialistas na organizao estabelecida e um mecanismo de
apoio troca de informaes entre os especialistas e os projetos implementada;
GRH11 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.
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
opes
67
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
sendo agregados queles ativos que j descrevemos, armazenados na rede interna da T
2
.
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 94
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
de processos sempre haver lugar para definir ciclos de vida em uso na T
2
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,
enquanto cuida do recm-nascido, e que tm a ver com Feature Driven Development
68
.
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
modo, e como os processos so avaliveis em relao a seu seguimento
69
, 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
passos: cada um dos cinco primeiros dias na T
2
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
baseia no Processo Padro da T
2
, 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
Ver Captulo 3
69
Ver no Captulo 6 Garantia da Qualidade

Capitulo 7 Pgina 95
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 auto-
organizada baseada em um algoritmo de redes neurais para reuso do conhecimento
desenvolvido por um dos novos programadores em seu trabalho de graduao. Desenvolvidos,
inicialmente, para o reuso de software
70
, 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
permite que uma empresa pequena como a T
2
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
Kanban com uma mini equipe dedicada
a funcionalidade nova e tem muitas
arestas inexploradas
mini espiral de Bohm dentro do sprint ou dividir o
sprint a partir de uma anlise para fazer demos mais
frequentes.
a funcionalidade totalmente central ao
funcionamento do produto (controle)
usar TDD e inspees, alm de programao por pares.
o dono do produto tem dvidas sobre a
funcionalidade que sugere
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 96
frequentes
a equipe no tem experincia usar inspees e programao por pares com o scrum
master em um dos papis
a arquitetura crucial para o
desempenho futuro do produto
usar um sprint para definir a arquitetura, maneira do
FDD, e decidir depois sobre Kanban, Scrum ou
Scrumban
Tabela 7.7: Orientao Sugerida por Perfil de Sprint
Quatro semanas depois de contar com a presena do consultor no escritrio da T
2
, volta-se a
ligar para Mximo para a reviso do processo Definio do Processo Organizacional, com
resultados perfeitos.
Definio do Processo Organizacional (DFP)
DFP1 Um conjunto definido de processos padro estabelecido e mantido, em
conjunto com a indicao da aplicabilidade de cada processo;
DFP2 Uma biblioteca de ativos de processo organizacional estabelecida e
mantida;
DFP3 Tarefas, atividades, papis e produtos de trabalho associados aos processos
padro so identificados e detalhados, juntamente com o desempenho
esperado do processo;
DFP4 As descries dos modelos de ciclo de vida a serem utilizados nos projetos da
organizao so estabelecidas e mantidas;
DFP5 Uma estratgia para adaptao do processo padro desenvolvida
considerando as necessidades dos projetos;
DFP6 O repositrio de medidas da organizao estabelecido e mantido;
DFP7 Os ambientes padro de trabalho da organizao so estabelecidos e
mantidos;
DFP8 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]
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 97
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
estratgia que lhe permite entender e documentar os objetivos estratgicos de processo da T
2
,
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
retrospectivas
71
, 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 A descrio das necessidades e os objetivos dos processos da organizao so
estabelecidos e mantidos;
AMP2 As informaes e os dados relacionados ao uso dos processos padro para
projetos especficos existem e so mantidos;
AMP3 Avaliaes dos processos padro de organizao so realizadas para
identificar seus pontos fortes, pontos fracos e oportunidades de melhoria;
AMP4 Registros das avaliaes realizadas so mantidos acessveis;
AMP5 Os objetivos de melhoria dos processos so identificados e priorizados;
AMP6 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;
AMP7 Ativos de processo organizacional so implantados na organizao;
AMP8 Os processos padro da organizao so utilizados em projetos a serem
iniciados e, se pertinente, em projetos em andamento;
AMP9 A implementao dos processos padro da organizao e o uso dos ativos de
processo organizacional nos projetos so monitorados;
AMP10 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 98
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
2
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.

Capitulo 7 Pgina 99
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
cdigo, que requer seguir normas organizacionais
72
, como a identao
73
, 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.
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 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;
GRU2 Um mecanismo de armazenamento e recuperao de ativos reutilizveis
implantado;
GRU3 Os dados de utilizao dos ativos reutilizveis so registrados;
GRU4 Os ativos reutilizveis so periodicamente mantidos, segundo os critrios
definidos, e suas modificaes so controladas ao longo do seu ciclo de vida;
GRU5 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 100
estas mudanas, mas seu esprito prtico a obriga colocar um marco firme nas necessidades
da T
2
.
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
qualidade
74
. No existe qualidade absoluta, sempre qualidade para e em um contexto. Da
mesma forma, a qualidade est relacionada s expectativas dos clientes. No modelo de Kano
75

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/

b. fixar o uso
76
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 (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;
GPR8 (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;
GPR20 (A partir do nvel E) Equipes envolvidas no projeto so estabelecidas e
mantidas a partir das regras e diretrizes para estruturao, formao e
atuao;
GPR21 (A partir do nvel E) Experincias relacionadas aos processos contribuem para
os ativos de processo organizacional;
GPR22 (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]
55. Na reunio mensal de anlise de portflio de projetos, so apresentados os
problemas de desempenho que continuam diminuindo a capacidade da T
2
, 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
2
se encaminha para uma avaliao do Nvel E.

76
Pouco vale ter uma diretriz se no seguida!

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
modelo de competncias da T
2
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,
conhecido como a folha de Balanced Score Card (BSC)
77
, 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
esclarecer a viso, que no caso de um exerccio to frequente como o que realizado na T
2

simplesmente a verificao de cada oportunidade
78
, so analisados os resultados, fixados
objetivos e discutidos os investimentos em diferentes categorias. A T
2
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
clientes, na T
2
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
[KAPLAN e NORTON, 1996], The Balanced Scorecard: Translating Strategy into Action.
78
A viso se expressou como Ter um crescimento sustentvel de pelo menos 15% anual com aumento
das margens proporcionais ou maior a cada ano.

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.
Comparando a densidade de defeitos produzida pelas equipes da T
2
com as mdias histricas
na literatura
79
, a direo da T
2
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

design em todos os nveis e a engenharia de testes deixam muito a desejar. A falta de
conhecimento nessas disciplinas notria.
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
especficas da T
2
; 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 enunciado 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
Tabela 8.1
81
.
risco ou problema: mitigao:
1

os clientes nos do informaes
incompletas sobre as necessidades e
requisitos do produto, gerando muito
retrabalho
seguir um processo sistemtico para a
identificao do que o cliente necessita para
obter o que quer segundo o que diz

80
Balanced Score Card
81
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.

2 a especificao de um mdulo,
componente ou sistema s vezes
incompleta, resultando em um produto
abaixo da perfeio
construir um documento que permita priorizar
os requisitos e especific-los de forma a
possibilitar sua reviso e anlise.
3 costumam ficar funes sem especificar
e os requisitos no funcionais so
frequentemente acrescentados no final
do projeto, resultando em muito
retrabalho
a especificao dos requisitos deve permitir
identificar funes, bem como os atributos de
qualidade no funcionais do produto
4 h muito impacto nos compromissos
pela quantidade de requisitos derivados
que surgem depois do jogo de
planejamento
antes de iniciar um sprint, devem ser definidos
os detalhes do conjunto de funcionalidades que
ser includo
5 a integrao contnua fracassa porque
no h uma clara definio das interfaces
parte da especificao deve ser dirigida para o
ambiente de funcionamento do produto, sejam
interfaces internas ou externas
6 as funes solicitadas so mal
interpretadas porque no h um
contexto onde situ-las, resultando em
demonstraes fracassadas
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
7 h certa pressa em passar estimativa
sem fazer uma anlise mais profunda da
funcionalidade que implementada,
resultando em oportunidades perdidas e
ineficincias
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
8 Mesmo nos casos em que so
construdos modelos do produto, estes
poucas vezes so discutidos com o dono
do produto
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
de modelos, fazendo uma breve resenha de A System Modeling Language, ASML
82
, 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

resgata que mais fcil reconhecer as caractersticas a serem implementadas em um sistema
se um modelo dele construdo, pois esse modelo funciona como objeto de fronteira
83
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 mal-
interpretado 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
de seus componentes, Java Modeling in Color
84
(JMC). Em JMC utilizada a notao de
UML
85
, 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 uso 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)

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
componentes independentes do domnio
86
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.

as ideias de Richard Denney desde sua primeira publicao em StickyMinds
87
, e acharam seu
ltimo livro
88
bastante til. Apresentam ento uma proposta alternativa: usar histrias de
usurios para se manter dentro de eXtreme Programming, elaborar com elas um diagrama de
casos de uso, identificar casos omissos usando uma matriz CRUD
89
, e desenvolver um perfil de
operaes seguindo as tcnicas do livro de Denney e, para aqueles casos que meream
90
,
desenvolver casos de uso completos seguindo os parmetros do livro de Allistair Cockburn
91
.
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
TDD
92
). 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
2
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
http://www.stickyminds.com/
88
[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.

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: mitigao: JMC XP + TST
informao incompleta sobre
necessidades e requisitos
processo sistemtico de
identificao
A M
especificaes incompletas documento onde priorizar
requisitos e especific-los
M A
funes e requisitos no
funcionais sem especificar
identificar funes, assim como
atributos de qualidade
B M
muitos requisitos derivados
depois do jogo do
planejamento
definir detalhes da poro de
funcionalidades no sprint
M M
no h clara definio das
interfaces
especificar interfaces internas e
externas
A A
no h contexto onde situar
as especificaes
construir histrias de usurio,
narrativas e/ou casos de uso
A A
passa-se estimativa sem
fazer uma anlise mais
profunda da funcionalidade
equilibrar requisitos e necessidades
do cliente contra restries da
equipe
M A
os modelos no so discutidos
com o dono do produto
validar o quanto antes os requisitos
menos comuns
A A
Tabela 8.2: Comparao entre Mtodos de Desenvolvimento pelo Benefcio

JMC XP + TST
curva de aprendizagem A B
risco de adoo A 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 se 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.


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.


Figura 8.7: Diagrama de Arquitetura

CASOS DE USO

CLASSES.............................
...
R
e
g
i
s
t
r
a
r
-
s
e

P
r
o
c
u
r
a
r

i
m
v
e
l

O
f
e
r
t
a
r

A
l
u
g
a
r

O
f
e
r
t
a
r

C
o
m
p
r
a
r

F
e
c
h
a
r

A
c
o
r
d
o

I
n
c
l
u
i
r

I
m
v
e
l

R
e
c
u
s
a
r

o
f
e
r
t
a

R
e
a
l
i
z
a
r

c
o
n
t
r
a
-
o
f
e
r
t
a

A
c
e
i
t
a
r

o
f
e
r
t
a

A
u
t
e
n
t
i
c
a
r

p
r
o
p
r
i
e
t
r
i
o

E
l
i
m
i
n
a
r

p
r
o
p
r
i
e
t
r
i
o

Cliente C U
Proprietrio C R U D
Imvel C
Acordo de Aluguel C U U C
Acordo de Compra C U U C
Oferta C C D D
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.
CASOS DE USO

CLASSES.............................
...
R
e
g
i
s
t
r
a
r
-
s
e

P
r
o
c
u
r
a
r

i
m
v
e
l

O
f
e
r
t
a
r

A
l
u
g
a
r

O
f
e
r
t
a
r

C
o
m
p
r
a
r

F
e
c
h
a
r

A
c
o
r
d
o

I
n
c
l
u
i
r

I
m
v
e
l

R
e
c
u
s
a
r

o
f
e
r
t
a

R
e
a
l
i
z
a
r

c
o
n
t
r
a
-
o
f
e
r
t
a

A
c
e
i
t
a
r

o
f
e
r
t
a

A
u
t
e
n
t
i
c
a
r

p
r
o
p
r
i
e
t
r
i
o

E
l
i
m
i
n
a
r

p
r
o
p
r
i
e
t
r
i
o

Cliente C U
Proprietrio C R U D
Imvel U C
Acordo de Aluguel C U U C

Acordo de Compra C U U C
Oferta C C D 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
Denney
93
, 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
usurios dos outros dois tipos desconhecida. Segundo Denney
94
, 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
ms. Na matriz que estamos gerando (chamada QFD
95
por Denney, dada a semelhana

93
Use Case Level of Test, op.cit., pgina 6.
94
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)

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 clientes novos
59 proprietrios novos
63,13 imveis novos
4000 buscas compra
8500 buscas aluguel
1000 oferta compra
3000 oferta aluguel
80 contraoferta compra
12 contraoferta aluguel
2 recusas
3830 acordos fechados
59 autenticaes de proprietrio
0,01 Eliminaes de proprietrio
Tabela 8.6: Estimativas de Atividade
Com essas estimativas, a matriz de QFD fica com os seguintes dados:
Q
u
a
n
t
i
d
a
d
e

CASOS DE
USO

ATORES...........
.....................
R
e
g
i
s
t
r
a
r
-
s
e

P
r
o
c
u
r
a
r

i
m
v
e
l

O
f
e
r
t
a
r

A
l
u
g
a
r

O
f
e
r
t
a
r

C
o
m
p
r
a
r

F
e
c
h
a
r

A
c
o
r
d
o

I
n
c
l
u
i
r

I
m
v
e
l

R
e
c
u
s
a
r

o
f
e
r
t
a

R
e
a
l
i
z
a
r

c
o
n
t
r
a
o
f
e
r
t
a

A
u
t
e
n
t
i
c
a
r

p
r
o
p
r
i
e
t
r
i
o

E
l
i
m
i
n
a
r

p
r
o
p
r
i
e
t
r
i
o

L
i
m
p
a
r

D
a
d
o
s

A
t
u
a
l
i
z
a
r

D
a
d
o
s

10000 Cliente 0,06 0,13 0,03 0,01 0,04
1000 Proprietrio 0,06 0,38 0,06 0 0,02
1 Administrador 59 1 110 330
execues por ms 659 1250 300 100 766 63 2 20 59 1 110 330
peso relativo 18% 34% 8% 3% 21% 2% 0% 1% 2% 0% 3% 9%
ranking 3 1 5

2

4
% de esforo 20% 38% 9%

23%

10%
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).

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
proposto por Allistair Cockburn em seu livro
96
. Frequentemente, proposta a seguinte estrutura
no design de casos de uso (Tabela 8.8):
Componentes de um Caso de Uso Definio
ID Segundo nomenclatura de configurao
NOME Descritivo do caso de uso (CDU)
REFERNCIAS CRUZADAS Outros materiais que so utilizados para entender o CDU
CRIADO POR Nome do Autor
LTIMA ATUALIZAO POR Nome do Revisor ou Atualizador
DATA DE CRIAO bvia
DATA DA LTIMA ATUALIZAO bvia
ATORES Todos os que intervm, robs inclusive

96
[COCKBURN, 2000], Writing Effective Use Cases.

DESCRIO Texto explicativo de alto nvel (opcional)
DISPARADOR Evento que dispara o CDU
PR-CONDIO Estado do sistema que permite executar o CDU
PS-CONDIO Estado do sistema que surge aps executar o CDU
FLUXO NORMAL Srie de passos que so considerados normais
FLUXOS ALTERNATIVOS Srie de passos que so considerados especiais
INCLUSES Outros CDU que so referenciados por este
FREQUNCIA DE USO De acordo com o perfil operacional
REGRAS DE NEGCIO Aquelas que se aplicam ao CDU
REQUISITOS ESPECIAIS Hardware ou ambiente de execuo ou desempenho
NOTAS E ASSUNTOS 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.
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: XP + TST
os clientes nos do informao
incompleta sobre as necessidades e
requisitos do produto, gerando muito
retrabalho
So utilizados diagramas de CDU e matriz CRUD
a especificao de um mdulo,
componente ou sistema incompleta,
resultando em um produto subtimo
As prioridades so fixadas com o DP e analisadas
mediante CDU
costumam sobrar funes sem
especificar e os requisitos no funcionais
so muito frequentemente
acrescentados ao final do projeto,
resultando em muito retrabalho
As planilhas de CDU identificam funes e
permitem acrescentar requisitos no funcionais
h muito impacto nos compromissos
pela quantidade de requisitos derivados
que surgem depois do jogo do
O jogo do planejamento passa a incluir o
detalhe dos requisitos.

planejamento
a integrao contnua fracassa mais do
que o necessrio porque no h uma
clara definio das interfaces
A planilha de CDU contempla esse ponto
so mal interpretadas as funes pedidas
porque no h um contexto onde situ-
las, resultando em demonstraes
fracassadas
Os CDU cobrem este risco
h certa pressa em passar a estimativa
sem fazer uma anlise mais profunda da
funcionalidade que implementada,
resultando em oportunidades perdidas e
ineficincias
Os perfis operacionais se ocupam de estabelecer
esse equilbrio quando h presses de recursos
ainda naqueles casos em que se
constroem modelos do produto, estes
so poucas vezes discutidos com o dono
do produto
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
limitaes do cliente, tanto do
produto quanto de suas
interfaces, so identificadas;
segue-se um processo sistemtico para a
identificao do que o cliente necessita, para que
tenha o que quer segundo o que diz
DRE2 Um conjunto definido de
requisitos do cliente
especificado e priorizado a partir
de necessidades, expectativas e
limitaes identificadas;
constri-se um documento que permite priorizar os
requisitos e especific-los, de modo que sua reviso
e anlise seja possvel
DRE3 Um conjunto de requisitos
funcionais e no funcionais, do
produto e dos componentes do
produto que descrevem a soluo
do problema a ser resolvido,
definido e mantido a partir dos
requisitos do cliente;
a especificao dos requisitos deve permitir
identificar funes, assim como os atributos de
qualidade no funcionais do produto
DRE4 Os requisitos funcionais e no
funcionais de cada componente
do produto so refinados,
elaborados e designados;
antes de iniciar um sprint, devem ser definidos os
detalhes das funcionalidades que sero includas
DRE5 Interfaces internas e externas do
produto e de cada componente do
produto so definidas;
parte da especificao deve ser dirigida
expressamente ao ambiente de funcionamento do
produto, sejam interfaces internas ou externas
DRE6 Conceitos operacionais e cenrios
so desenvolvidos;
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
DRE7 Os requisitos so analisados,
usando critrios definidos, para
equilibrar as necessidades dos
interessados com as restries
existentes;
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
DRE8 Os requisitos so validados. durante o jogo do planejamento, os requisitos menos
comuns sero validados usando modelos e os casos
de uso ou histrias de usurio
Tabela 8.10: Implementao de DESENVOLVIMENTO DE REQUISITOS na T
2

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
foram introduzidos em muitos sprints anteriores. A T
2
enfrenta o problema de detect-los antes
que o cliente. Revisando as planilhas analisadas junto com os Problemas de Requisitos, que se

conglomeraram em outras quatro, a saber: Problemas de Design, Problemas de Integrao,
Problemas de Verificao e Problemas de Validao, os quatro protagonistas de nossa
histria na T
2
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.
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
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
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
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
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
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.
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
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
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
aplicar com todo rigor auditorias de
processo e produto at que seja fixada a
conduta de teste sistemtico
nem sempre a densidade que calculamos est automatizar todos os testes

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,
seguindo os conselhos de Mximo, utiliza as interpretaes de Barry Bohm em sua obra
97
.
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
2
utiliza mltiplas ferramentas. As revises
98
, sejam reviso por
pares, inspees, walkthroughs
99
, revises estruturadas ou revises contnuas
100
; 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
o propsito de detectar defeitos no produto
101
, mas tambm como ferramenta de design
102
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
2
usa atividades nas quais participa o DP
103
. 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
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.

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
maior probabilidade do que se tivessem sido corrigidos com tempo adequado
104
. 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],


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.

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

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 refaz-
lo 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
severidade. Isto bom porque, se h pessoas que se comportam com fanatismo
105
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.

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
um livro de Yourdon
106
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.

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 Revises Estruturadas Inspees
Objetivos Obter retroalimentao inicial
sobre a maneira de avanar
com o produto e corrigir
defeitos, se existirem
Mostrar que o produto tem a
qualidade esperada
Localizar todos os defeitos
possveis e corrigi-los, at
alcanar um nvel de
qualidade prefixado
Critrio de
Entrada
Identifica-se a necessidade no
calendrio do projeto ou o
autor ou outra pessoa decide
A gerncia estima que o
produto est pronto, foram
publicados os critrios de
qualidade, o autor confirma
que se pode comear
O autor solicita a inspeo e
confirma que o produto
cumpre com os critrios para
ser inspecionado
Decises As decises so tomadas pelo
autor
A equipe de inspeo informa
e recomenda, a gerncia
decide
A equipe decide sobre o
produto e aes futuras
Fechamento
das
Questes
Fora do escopo do
procedimento
A gerncia controla como
parte do projeto
O moderador controla de
acordo com os critrios da
equipe
Tamanho Duas ou mais pessoas, sem
limite
Ao menos trs e no mais de
sete
Trs pelo menos e no mais
de sete
Composio
da Equipe
Quem estiver disponvel Lderes tcnicos e colegas do
autor
Colegas do autor escolhidos
com critrios previamente
definidos
Liderana Autor Geralmente um lder tcnico
do projeto
Moderador capacitado
Preparao Opcionalmente distribudo
o material com horas de
antecipao
H uma reviso individual
prvia seguindo critrios
estabelecidos na lista de
verificao
H uma reviso individual
prvia seguindo critrios
estabelecidos na lista de
verificao e com materiais
de apoio
Apresentador Normalmente o autor Autor ou leitor designado Leitor designado ou ningum
Medidas
Registradas
Opcional, raramente feito Geralmente so registradas
como em inspees, mas no
so requeridas, depende da
empresa
Requeridas formalmente,
esforo, tempo, tipo e
nmero de questes
Relatrios O autor produz de acordo
com sua deciso
Relatrio com a lista de
defeitos, questes e aes
realizadas
Relatrio com detalhe do
detectado, investido e
realizado
Captura de
Dados
No exigida No exigida Coleta, com fins estatsticos,
de todos os dados cadastrais
e esforo, tempo, custo, etc.
Tabela 8.13: Comparao entre Revises

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
os gmeos na T
2
. 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
para seu uso em sprints. Recordando o incio da T
2
, quando se realizava o leilo de tarefas,
quando uma equipe de trabalho termina um produto que merea ser revisado, o que se define
no jogo do planejamento do Sprint, ela convoca mediante a Intranet da T
2
(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.
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

Autor
Produto

Moderador
Data de Entrada

Revisores
Hora de Comeo

Hora de Fim

Durao

Localizao
(Pgina, Linha)
Descrio da Questo
(Se o item foi levantado na reunio marque com *)
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

escolha de treinamento anual pago pela T
2
. 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).

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.

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

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


Figura 8.15 Segunda rea Fechada

Figura 8.16 Terceira rea Fechada

Figura 8.17 Quarta rea Fechada

Figura 8.18 Quinta rea Fechada


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.


Figura 8.21: Probabilidade de Cada Transio do Grafo
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
exploram a lacuna existente entre os procedimentos em uso pela T
2
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
verificados so identificados;
acordar com a equipe a estratgia de verificao, 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 uma delas) e os
ambientes de teste, quando forem aplicveis
VER2 Uma estratgia de verificao
desenvolvida e implementada,
estabelecendo o cronograma,
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,
incluindo testes e revises em
pares, so executadas;
aplicar com todo rigor auditorias de processo e
produto at que seja fixada a conduta de teste
sistemtica
VER5 Os defeitos so identificados e
registrado;
automatizar todos os testes

VER6 Os resultados de atividades de
verificao so analisados e
postos disposio das partes
interessadas.
os dados obtidos dos testes e das inspees,
walkthroughs e revises tcnicas, devem ser
analisados e discutidos na reunio mensal de
portflio
Tabela 8.16 Resultados Esperados de VERIFICAO e Atividades Internas em T
2
Resultados Esperados de VAL no MPS Atividades Internas na Tahini-Tahini
VAL1 Os produtos de trabalho a serem
validados so identificados;
acordar com o cliente e a equipe a estratgia de
validao, os produtos a serem avaliados, o
cronograma da validao, os critrios de entrada e
aceitao e os ambientes de aplicao
VAL2 Uma estratgia de validao
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
registrados;
reforar o seguimento do processo de aceitao do
usurio, aumentando a frequncia das auditorias e
ajudando a prevenir no conformidades,
assegurando que os critrios de aceitao sejam
cumpridos, baseados em documentao fidedigna
VAL6 Os resultados das atividades de
validao so analisados e postos
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

Os resultados so muito bons, o que a direo de T
2
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, pode-
se 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;

PCP2 Solues so selecionadas para o produto ou componentes do produto, com
base em cenrios definidos e em critrios identificados;
PCP3 O produto e/ou componente do produto desenhado e documentado;
PCP4 As interfaces entre os componentes do produto so desenhadas tomando
como base critrios pr-definidos;
PCP5 Uma anlise dos componentes do produto conduzida para decidir sobre sua
construo, compra ou reuso;
PCP6 Os componentes do produto so implementados e verificados de acordo com
o que foi desenhado;
PCP7 A documentao identificada, desenvolvida e posta disposio de acordo
com os padres estabelecidos;
PCP8 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
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
desenvolver critrios universais para
iniciar uma anlise de alternativas de
design baseados nos objetivos de
negcio da T
2
e do projeto
o sprint de estabilizao est tendo problemas
porque a equipe no reconhece algumas
decises de design que impactam nos testes
documentar o design, sobretudo o
porqu da seleo de componentes,
apoiado nos requisitos, sobretudo os no
funcionais
a integrao, frequentemente, fracassa na
primeira tentativa, fazendo perder um dia de
testes a cada vez
realizar uma anlise de causas para
identificar aes
tentamos reinventar a roda em vrias ocasies aplicar a anlise de reuso, ampliando
iniciativas de reuso com componentes do
mercado
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.
reforar o sentimento de YAGNI
107

utilizando s testes que foram aprovados
pela equipe no momento de aprovar o
plano de sprint
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).

vimos
108
para incluir entre as opes componentes que podem ser adquiridos fora da T
2
. 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
T
2
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.

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
de seleo so desenvolvidos para
atender aos requisitos definidos
de produto e componentes de
produto;
desenvolver critrios universais para iniciar uma
anlise de alternativas de design baseados nos
objetivos de negcio da T2 e do projeto
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
produto criado e documentado;
documentar o design, sobretudo o porqu da seleo
de componentes, apoiado nos requisitos, sobretudo
os no funcionais
PCP4 As interfaces entre os
componentes do produto so
criadas tomando como base
critrios predefinidos;
controlar as interfaces de todo tipo para que suas
modificaes se propaguem aos interessados
PCP5 Uma anlise dos componentes do
produto conduzida para decidir
sobre sua construo, compra ou
reuso;
aplicar a anlise de reuso, ampliando-o com
componentes do mercado
PCP6 Os componentes do produto so
implementados e verificados de
acordo com o que foi criado;
reforar o sentimento de YAGNI utilizando somente
testes que foram aprovados pela equipe no
momento de aprovar o plano de sprint
PCP7 A documentao identificada,
desenvolvida e disponibilizada de
acordo com os padres
estabelecidos;
acrescentar uma planilha de reviso da
documentao para ser utilizada para afirmao da
qualidade antes do fechamento do sprint
PCP8 A documentao mantida de
acordo com critrios definidos.
refazer a reviso da documentao no sprint de
estabilizao
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.

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)
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
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.
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
a integrao pode fracassar porque as interfaces
no so compatveis, o que pode levar a perdas
de eficcia no uso dos recursos
assegurar a compatibilidade das
interfaces mediante uma mini-inspeo
antes de subir um mdulo para ser
integrado
as mudanas nas interfaces tm efeitos
negativos nos testes de regresso, e nem
sempre so consideradas na anlise do impacto
dedicar parte do procedimento da
anlise de impacto anlise de interfaces
cedendo a presses prprias, os programadores
costumam subir cdigo defeituoso ao ambiente
de integrao
utilizar inspees breves para analisar os
produtos e auditar que os testes
unitrios foram realizados e os critrios
foram cobertos
a integrao realizada espontaneamente sem
seguir muitas pautas, salvo o que est nos
scripts da ferramenta
orientar as equipes para que gerem suas
prprias regras sempre que incluam as
normas organizacionais ou recebam
dispensa para no fazer isso
no passado, acreditamos ter aprovado uma
integrao quando na realidade no havia sido
executada ainda
os dados da integrao devem ser
cuidadosamente inseridos na ferramenta
e os resultados devem ser analisados
como parte do scrum dirio
alguns casos da base de testes de regresso
deixaram de ser teis e novos casos que
deveriam ter sido includos no foram
acrescentar descrio do papel de
engenheiro de testes o procedimento de
manuteno da base de regresso
nem sempre se desenvolveu a documentao
prevista por contrato ao mesmo tempo do
produto em si, o que frequentemente provocou
sufoco no final
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.

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.
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.


CAPTULO 9 - AMPLIANDO A CAPACIDADE DE DECISO (NVEL C do MPS-SW)
9.1 Uma Gesto Ambiciosa
At aqui a gesto da T
2
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

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
quer levar o produto da T
2
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 MR-
MPS-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


Figura 9.1: rvore de Deciso

Status Quo Nvel C SCAMPI
110

Entradas Gastos Entradas Gastos Entradas Gastos
32,1 25,3 0,8 0,032 1,6 0,069
Probabilidade 0,98 1 0,9 1 0,85 1
Expectativa 31,458 25,3 0,72 0,032 1,36 0,069
ROI 6,158 0,688 1,291
Tabela 9.1: Tabela de Pagamentos da rvore de Deciso
9.3 Viso Estratgica dos Riscos
A T
2
, 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 palavra risco, como ilustra seu abuso em
vrias tabelas que j vimos no Captulo 8
111
, Marcela define com preciso o significado e o uso
do termo dentro da T
2
. Seguindo o uso do IEEE, do MPS e do CMMI, Risco na T
2
um
problema potencial, quer dizer, algo que ainda no ocorreu. Existe risco em todas as
atividades, porque o futuro incerto. atribuda a Niels Bohr
112
a frase: Nada mais difcil de
prever que o futuro e ironias parte, nada mais certo de acordo com nosso conhecimento
cientfico. Marcela escolhe a forma mais ampla de definir um risco. Seu uso na T
2
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

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

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. Est relacionado com a
inovao e o chamaremos risco de oportunidade. A pergunta que se faz para tentar identific-
lo 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
escritrios e at os mtodos de avaliao
113
. Uma modificao na poltica de qualidade da T
2

define o escopo da aplicao da gesto de riscos com preciso.
O que Marcela prope que todos os que trabalham na T
2
, 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
analisar o risco monetrio. A cada momento, os passos definidos por Boehm
114
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 Fonte de
riscos a avaliar
Categorias
alto mdio baixo
pr-venda cliente
novo, processos fracos,
teoria X de gesto
115

novo, processos OK,
gesto moderna
conhecido, processos
OK, gesto moderna
domnio
desconhecido, baixa
tecnologia, alto
impacto em clientes do
cliente
conhecido em parte,
tecnologia moderna,
impacto mdio em
clientes do cliente
conhecido, tecnologia
avanada, impacto
administrvel no
cliente
tecnologia
inovadora, novas API,
novas ferramentas
conhecida, algumas
novas ferramentas
conhecida e compatvel
100%
concorrncia
existem bons
fornecedores com
existem bons
fornecedores com
dominamos o mercado

113
J vimos no Captulo 8 que a avaliao anual foi eliminada, substituda pela avaliao contnua.
114
BOEHM, B., 1989, Software Risk Management.
115
http://en.wikipedia.org/wiki/Theory_X_and_Theory_Y

muita experincia nossa prpria
experincia
reuso
escassa probabilidade
de reuso
algo de reuso, mas no
em certos mdulos
crticos
fundamentalmente
adaptaes a nossos
produtos
kickoff tradeoff de
sprints com
requisitos
muitas funcionalidades
para o release
planejado
possvel modular a
funcionalidade para
reduzir a durao
prefervel qualidade
no que entregue do
que muitas funes
dono do produto
no entende o
problema e est
totalmente impedido
de tomar decises
entende o problema,
mas est limitado em
sua capacidade de
deciso
operacional, resolutivo,
independente, capaz
custo do projeto
muito alto, relacionado
com a tecnologia a ser
incorporada e a curva
de aprendizagem
um pouco mais alto
que o habitual por sua
durao
habitual
sprints desenvolvimento
novo x correes
nunca h tempo para
corrigir porque o novo
sempre tem maior
prioridade
preciso se esticar um
pouco para poder
corrigir o sprint
anterior, mas
administrvel
o dono do produto
entende os problemas
e apoia que sejam
solucionados antes de
chegar estabilizao
muita
funcionalidade
h presso por incluir
sempre um pouco
mais
h presso para incluir
sempre um pouco
mais, mas h
possibilidade de
diminuir o ritmo a cada
dois sprints
pode-se descartar
alguma histria se no
se chega com a data
requisitos fracos
o dono do produto no
sabe definir com
clareza o que precisa
o dono do produto
duvida do que
necessita
o dono do produto
sabe o que necessita e
sabe explicar
estabilizao custo de
manuteno
no houve muito
tempo para corrigir e o
sprint de estabilizao
curto
ficam coisas para
corrigir, mas entram no
sprint se no surgirem
alguns defeitos
mascarados
chegamos com muito
pouco para corrigir,
possvel usar tempo
para refazer
entrega atrasada
o dono do produto
rgido a respeito da
data de entrega e no
h negociao
o dono do produto
negocia qualidade por
data de entrega
o dono do produto
prefere um produto
estvel que seja
entregue a tempo
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
deciso de um projeto o mtodo organizacional que vai ser usado. Na T
2
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

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
compatveis entre si, e tenhamos que investir muito esforo para fazer envoltrios
116
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,
monitorao e controle de riscos na T
2
. 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.

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
estratgias da T
2
(a T
2
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
tomamos a deciso apressadamente
117
, 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
situao de incompatibilidade nosso gato de Schrdinger
118
, 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 diminu-
lo? 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
efetivas, o procedimento da T
2
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.

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 Probabilidade Perda Exposio
1 0,8 90 72
2 0,8 84 67,2
3 0,8 69 55,2
4 0,8 66 52,8
5 0,6 64 38,4
6 0,5 71 35,5
7 0,5 40 20
8 0,5 32 16

9 0,3 37 11,1
10 0,3 33 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
universalmente na T
2
. 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
Guia de Gesto de Riscos da T
2
est de acordo com o MPS.
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
2
, 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
pessoas e as trajetrias das naes. Esta viso do acaso, compartilhada em outras cincias
119
,
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

119
a tese dominante no neodarwinismo, ver por exemplo, Dinosaur in a Haystack: Reflections in Natural
History, [GOULD, 1996].

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
mtodos formais
120
. O propsito de usar mtodos formais ao tomar decises que, seguindo
um padro formal, podem armazenar, comparar, analisar e reutilizar as decises baseando-se
nos resultados que produzem. A princpio, a T
2
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
e correlaes simples. A T
2
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
recorreu a um professor seu, o Dr. Zito, que recomendou vrias leituras
121
, das quais extraiu
Marcela poderosas ideias que transformou em um Guia de Aplicao de Decises da T
2
.
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
De fato, na literatura h muitas publicaes que falam ao mesmo tempo de riscos e decises formais.
121
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].

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. Definir corretamente o problema a ser resolvido.
2. Estabelecer atributos desejveis da soluo.
3. Definir mtodos de medio dos atributos selecionados.
4. Criar mtodos de avaliao das solues.
5. Gerar ou descobrir solues alternativas.
6. Aplicar a cada soluo gerada a medio dos atributos desejveis.
7. Avaliar mediante os mtodos selecionados as solues geradas.
8. 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 us-
las 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

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
da T
2
. 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 claramente, 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

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
que considerada na T
2
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 subcontrata-
se 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.


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

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
+ c
1
X
1
+ c
2
X
2
+
+ c
n
X
n
+ . Os coeficientes c
j
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 c
j
, 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
detalhes matemticos e remetemos os interessados literatura clssica
122
. O uso que se d
equao de regresso na T
2
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.
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
2
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.

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
2
, 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
financeiras internas da T
2
. 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

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
2
, 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
2
, 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]

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

novas funcionalidades desenvolvidas para fazer referncia a um modelo
de negcio comum para cada elemento de dados.
Estes requisitos so centrais para a T
2
, 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
convenientemente empacotados. No caso da T
2
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
Sistemas Operacionais modernos
124
. H definies bem documentadas
125
de tudo o que
necessrio descrever e como criar um registro de metadados
126
.
SOA menos uma arquitetura do que um paradigma para a construo e manuteno de
processos de negcios que abarcam sistemas distribudos de grande porte
127
. 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.

Figura 9.9: Ilustrao da Arquitetura SOA
9.12 Montando a Fbrica
Para o processo de reengenharia dentro da T
2
, 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
software passa a ser o arquiteto do projeto
128
. Junto com Ana e os gmeos, elaboram a
arquitetura de alto nvel, aplicando JMC
129
. Depois desse exerccio, comea a funcionar a
Fbrica de Software: dependendo do domnio, em particular do componente a converter em

124
[BORIA, 1989]
125
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.

servio, os gmeos recomendam um especialista que assume o papel de programador chefe
da equipe
130
. 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.
86. Uma empresa canadense estabelece uma aliana com a T
2
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
usados em todos os projetos da T
2
. 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.

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
e do mecanismo de governo institudo nas reunies mensais do comit de gesto da T
2
. 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
2
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.
88. Mximo conclui que a T
2
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.


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
2
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
empresa do Canad. Quase dois anos mais tarde, todos os resultados da T
2
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
T
2
. 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
2
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
estimativa de esforo e durao das tarefas foi calculada na T
2
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

de ambas modalidades. Pegaram os dados histricos para tarefas semelhantes (anlise,
construo, teste) e os carregaram na ferramenta de software de anlise estatstica
131
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 disperso
132
. Os gmeos pediram a ajuda de Cludio, para usar seus
conhecimentos de estatstica
133
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
2
, mas no a primeira vez que
faz uma exposio em pblico. Ele tambm vtima do sucesso da T
2
e frequentemente
convidado a fazer apresentaes sobre a anlise financeira aplicada anlise de portflio,
como vem fazendo na T
2
h anos. Portanto, est preparado, embora fazer uma apresentao
sobre o tema de estatsticas seja novo para ele. Sua exposio, baseada em slides ppt, intitula-
se 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.

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.

conhecidos subia de ciclo de teste em ciclo de teste. Um tpico cenrio de projeto fora de
controle
136
. 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
nenhuma concluso. Pela primeira vez em sua histria, a T
2
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 1979
137
. 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 Eureka
138
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

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
gesto se tornaram lendrias na T
2
, material de muitas histrias nascidas ao abrigo das
decises tomadas nela por aqueles que os mais jovens consideram os pais da T
2
.
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.

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 Development
140
, 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 CRACK
141
, 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: causa(s)-raiz: mitigao:
1 A capacidade de adquirir
conhecimentos por parte das
equipes foi superestimada
No foi seguido o
processo de riscos na
parte de pr-venda
Acrescentar uma auditoria de
processo atual auditoria de
produto e fazer uma reviso
por colegas do produto
2 A capacidade dos clientes de se
expressar com preciso e de
maneira integral foi
superestimada
Acrescentar aos riscos na pr-
venda o conhecimento do
negcio por parte do ponto de
contato no cliente
3 As definies iniciais no
continham regras de negcio
Os processos de negcio
estavam sofrendo
Colocar uma clusula no
contrato que torna o cliente

140
[WOOD e SILVER, 1995]
141
Ver Captulo 3.

suficientemente claras nem
completas
reengenharia ao mesmo
tempo em que se
tentava descrev-los
para construir o sistema
responsvel pelas demoras
relacionadas com requisitos
incompletos
4

Os metadados no foram
definidos de forma
centralizada e nica, cada um
criou e adaptou s suas
necessidades, maneira que
surgiam
No h uma planilha
nica, no h guias de
ajuste nem de uso
Construir a planilha padro para
metadados e os artefatos
necessrios para seu uso
produtivo na BiPro
No foi implementado
um sistema de gerncia
dos metadados e no h
revises das definies
porque os processos de
Scrum no so mais
aplicados
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
5 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 fizermos 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.

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 estabilidade 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 processos
142
, 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
direita que esquerda. Revisando na literatura de estatstica, a forma mais parecida a
2
,
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
[SHEWHART, 1939]
143
[PUTNAM e MYERS, 2003]


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 padro
144
, 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.

- 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 riscos completada com
a ltima fila como mostra a Tabela 10.2: A ltima Fila da Anlise depois de Completa

5 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
2
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 us-
lo mais extensamente. Considerando que a massa dos dados nos anos em que foram
acumulados na T
2
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
tema. assim que, temporariamente, Damin incorporado equipe da T
2
.
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

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

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
2
, 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 falta
146
. Como diria Stephen Covey, o principal se assegurar
que o principal o principal
147
. 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.

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.

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

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 porosidade
148
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.

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 pelos 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

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 pr-
determinados 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.

indicadores de causa
150
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
2
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.

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.

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
2
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
2
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
de cabea. A qualidade da T
2
aumentou o custo de entrada de seus concorrentes.
Alm disso, a T
2
pode conseguir os melhores recursos humanos no mercado porque seu mito
muito firme. Trabalhar para a T
2
um orgulho para os profissionais e considerada uma
excelente escola de negcios. Se algum recebe uma oferta da T
2
pouco provvel que a
recuse.
10.18 Inovao tecnolgica
No entanto, a T
2
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 SETI
151
, consiste na
busca constante de novas ideias e tecnologias de aplicao. Cada engenheiro da T
2
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
sobre o que leu na revista da T
2
, chamada SPI
152
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
http://www.seti.org/, SETI um projeto de busca de vida extraterrestre.
152
Software Process Improvement, Spy Glass o nome da luneta em ingls.

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 de
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 fundadores se reuniam ao
redor de uma mesa de chapa de vinil para organizar suas ideias de design e arrematar as
tarefas. A automao governa os processos, mas as ideias governam a automao. A T
2

aprendeu a reconhecer seu ncleo, mas tambm a explorar o espao em branco
153
, 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 Startup
154
.
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
projeto. Seja qual for o resultado, a T
2
acha justificado o experimento porque a organizao
aprendeu.

153
[JOHNSON, 2010], Seizing the White Space: Business Model Innovation for Growth and Renewal
154
[RIES, 2011], The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create
Radically Successful Businesses


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 seu 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.

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
2
gerou dois spin-
offs: 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.
A T
2
est preocupada com a doena do crescimento, a ancilose, e combate isso de todas as
maneiras possveis.
89. Os valores tpicos do projeto de SOA no correspondem histria dos projetos da T
2
.
90. Um projeto SOA novo entra em crise e sai do controle.
91. Jssica introduz a SPC T
2
.
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
2
.
95. Definidos os processos crticos, a T
2
se assegura de que sejam estveis e j tenham
sua baseline.
96. Para os processos crticos, Damin gera modelos estatsticos de previso para utiliz-
los 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
T
2
.
100. A inovao sistemtica d bons frutos.


CAPTULO 11 - CONCLUSES
A j no to pequena Tahini-Tahini
Nossa histria encerra aqui. Nossa amiga T
2
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
competitividade da T
2
. 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
Um dos fatores que aceleraram a maturao da T
2
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
resultado nem sempre to bem sucedido como com a T
2
, mas aqueles que no tentam
alcanar o topo no desfrutaro da vista.


Referncias Bibliogrficas Pgina 180
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/dont-
be-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/programmers-
flow-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.

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, Addison-
Wesley.
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-21-
05.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, Addison-
Wesley.
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.

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, Addison-
Wesley Professional.
KERNIGHAN B. W., e PLAUGER P. J., 1974, The Elements of Programming Style, McGraw-
Hill.
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
SM
: 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.

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-TR-
033.
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
Fundamentao para Implementao do Nvel F do MR-MPS:2011, junho 2011.
SOFTEX, 2011d, ASSOCIAO PARA PROMOO DA EXCELNCIA DO SOFTWARE

Fundamentao para Implementao do Nvel E do MR-MPS:2011, junho 2011.
SOFTEX, 2011e, ASSOCIAO PARA PROMOO DA EXCELNCIA DO SOFTWARE
Fundamentao para Implementao do Nvel D do MR-MPS:2011, junho 2011.
SOFTEX, 2011f, ASSOCIAO PARA PROMOO DA EXCELNCIA DO SOFTWARE
Fundamentao para Implementao do Nvel C do MR-MPS:2011, junho 2011.
SOFTEX, 2011g, ASSOCIAO PARA PROMOO DA EXCELNCIA DO SOFTWARE
Fundamentao para Implementao do Nvel B do MR-MPS:2011, junho 2011.
SOFTEX, 2011h, ASSOCIAO PARA PROMOO DA EXCELNCIA DO SOFTWARE
Fundamentao para Implementao do Nvel A do MR-MPS:2011, junho 2011.
SOFTEX, 2011i, ASSOCIAO PARA PROMOO DA EXCELNCIA DO SOFTWARE
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
Implementao do MR-MPS:2011 em organizaes do tipo Fbrica de Software, junho
SOFTEX, 2011k, ASSOCIAO PARA PROMOO DA EXCELNCIA DO SOFTWARE
Implementao do MR-MPS:2011 em organizaes do tipo Fbrica de Teste, junho
SOFTEX, 2011l, ASSOCIAO PARA PROMOO DA EXCELNCIA DO SOFTWARE
BRASILEIRO SOFTEX., MPS.BR Curso de Introduo ao MPS-Software (C1-MPS-
SW), setembro 2011.
SOFTEX, 2012a, ASSOCIAO PARA PROMOO DA EXCELNCIA DO SOFTWARE
BRASILEIRO SOFTEX., MPS.BR Guia Geral MPS de Software:2012, agosto 2012.
SOFTEX, 2012b, ASSOCIAO PARA PROMOO DA EXCELNCIA DO SOFTWARE
BRASILEIRO SOFTEX., MPS.BR Guia Geral MPS de Servios:2012, agosto 2012.
SOFTEX, 2012c, ASSOCIAO PARA PROMOO DA EXCELNCIA DO SOFTWARE
BRASILEIRO SOFTEX., MPS.BR Guia de Avaliao:2012, maio 2012. Disponvel
SOFTEX, 2012d, ASSOCIAO PARA PROMOO DA EXCELNCIA DO SOFTWARE
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
SOFTEX, 2012f, ASSOCIAO PARA PROMOO DA EXCELNCIA DO SOFTWARE
BRASILEIRO SOFTEX., MPS.BR Guia de Implementao Parte 13: Mapeamento

e Sistemas de Equivalncias entre o MR-MPS-SW:2012 e o MoProSoft:2005, outubro
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

Melhoria de Processos de Software Com Métodos Ágeis e Modelo MPS

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Melhoria de Processos de Software Com Métodos Ágeis e Modelo MPS

Enviado por

Direitos autorais:

Formatos disponíveis

Melhoria de Processos de Software com Mtodos geis e Modelo MPS Boria et al.

and Agile Development, Addison-Wesley.

Você também pode gostar