Post on 19-Jun-2020
1
Processos rigorososversus processos ágeis
Arndt von Staa
Departamento de Informática
PUC-Rio
Maio 2014
Mai 2014 2Arndt von Staa © LES/DI/PUC-Rio
Pontos positivos “CMM likes”
• Certificação do processo
– confiança de clientes
– seleção de fornecedores
• Boas práticas de gerência são desejáveis
• Dispor de um processo padrão comum
– facilita a comunicação entre organizações
– facilita o desenvolvimento de ferramentas de apoio à gerência
• Se continuamente mantido e evoluído pode contribuir para
uma sensível melhoria de qualidade e produtividade
• Orr, K.; CMM Versus Agile Development: Religious Wars and Software Development; Agile Project
Management 3(7); Cutter Consortium; 2002
2
Mai 2014 3Arndt von Staa © LES/DI/PUC-Rio
Pontos negativos “CMM likes”
• Se mal institucionalizado tende ao engessamento
– dá a impressão de que produzir papel é mais importante do
que produzir resultados
• Certificação depende de quem certifica
– critérios são um tanto fluidos
– certificadores frequentemente alardeiam que ajudaram as
organizações a melhorarem
• deveriam meramente identificar conformidades e
não conformidades
Mai 2014 4Arndt von Staa © LES/DI/PUC-Rio
Pontos negativos
• Certificação visa principalmente processos e gerência
– não se preocupa explicitamente com a qualidade dos produtos
do ponto de vista do usuário
– crença (a meu ver errada) que seguir um processo bem
definido conduz inexoravelmente à qualidade
• Overhead de gerência tende a ser grande
– gerentes podem tender a ser “chefes” ao invés de “coaches”
3
Mai 2014 5Arndt von Staa © LES/DI/PUC-Rio
Pontos positivos processos ágeis
• Foco no produto final adequado ao usuário
• Desenvolvimento como atividade social
• Admitir evolução dos requisitos
• Desenvolvimento incremental
• Teste automatizado
– critérios de aceitação testáveis passam a ser especificações
através de exemplos
• Integração frequente
• Refactoring frequente
• Interação contínua explícita com o usuário
– a aprovação pelo usuário ocorre cedo e passo a passo
– reduz retrabalho inútil
• enfatiza as características (features) realmente necessárias
Mai 2014 6Arndt von Staa © LES/DI/PUC-Rio
Pontos negativos processos ágeis
• Foco excessivo em OO
• Dificuldade de criar e manter equipes (teams)
– dificuldade com o desenvolvimento como atividade social
• Um só usuário residente (XP) não captura todas as
características
• Falta de arquitetura explícita
• Falta de definição do que seja uma documentação mínima
• Requer pessoal disciplinado e competente
– existem em quantidade suficiente?
• Equipes pequenas
– dá para desenvolver sistemas grandes?
• Manutenção é mencionada raras vezes na literatura de
processos ágeis
4
Mai 2014 7Arndt von Staa © LES/DI/PUC-Rio
Reengenharia de CMM
• “Teaching elephants (CMM) to dance”
– reduzir excesso de documentação
• aprovações (assinaturas)
• qual seria o mínimo necessário?
– enfatizar colaboração
– incluir ferramentas integradas
• Huizinga, D.; Kolawa, A.; Automated Defect Prevention: Best Practices in
Software Management; Hoboken, New Jersey: John Wiley & Sons; 2007
– automatizar gerência
– enfatizar rapidez de desenvolvimento
– enfatizar controle da qualidade automatizado
• http://bradapp.blogspot.com/2006/07/agile-cmmi-and-dancing-elephants.html
Mai 2014 8Arndt von Staa © LES/DI/PUC-Rio
Reengenharia de XP
• “Getting XP to work on large outsourced projects”
– prestar mais atenção a
• especificação inicial
• arquitetura
• projeto
• documentação técnica
• ferramentas, frameworks, geradores
– prestar mais atenção à gerência
– desenvolver técnicas para particionar projetos grandes em
vários “adequadamente grandes”
– desenvolver artefatos de projeto
– desenvolver e utilizar ferramentas integradas
5
Mai 2014 9Arndt von Staa © LES/DI/PUC-Rio
Coisa a pensar
• Produtividade varia cerca de 1 para 35 entre
desenvolvedores
• Qualidade produzida varia de ?? a ??
– medida em densidade de defeitos
• Ao invés de procurar processos melhores, não seria mais
vantajoso procurar descobrir o que torna um desenvolvedor
tão melhor do que outro?
– são características inatas?
– são características que se pode ensinar / treinar?
• Desenvolvedores melhores são mais caros (salários
melhores), mas são muito mais produtivos – retrabalho
inútil, funcionalidade por unidade de tempo, defeitos
remanescentes – o que torna os projetos mais baratos
• Glass, R.L.; “A Follow-the Leader Story with a Strange Ending”;
Mai 2014 10Arndt von Staa © LES/DI/PUC-Rio
Extreme programming lessons
• Lesson: Automated tests pay off by improving developer
confidence in their code.
• Lesson: Requiring all methods to have unit tests forces
developers to create better designs.
• Lesson: Design for testability is easier if you design and
implement the tests first.
• Lesson: Make it Run, Make it Right, Make it Fast (but only if
you need to).
• McBreen, P.; Applying the Lessons of eXtreme Programming;
6
Mai 2014 11Arndt von Staa © LES/DI/PUC-Rio
Extreme programming lessons
• Lesson: Effective working together on a process requires we
all work the same way.
– “You are welcome to use your style. Just not on our project.”
• Lesson: Rather than depart from the established process,
change the process to make it workable for the team.
• Lesson: Detecting broken processes is hard if people are not
required to follow the process.
McBreen, P.; Applying the Lessons of eXtreme Programming;
Mai 2014 12Arndt von Staa © LES/DI/PUC-Rio
Extreme programming lessons
• Lesson: Nominate a coach to keep the team on process
• Lesson: If you do not want to be part of the team, don’t
work on the project.
• Lesson: Make sure the system always runs and passes all
automated tests.
• Lesson: Only check in code when all tests pass.
• Lesson: Keep the system completely integrated and
automate the tests that verify that it works.
7
Mai 2014 13Arndt von Staa © LES/DI/PUC-Rio
Extreme programming lessons
• Lesson: You can always try to sprint, but this is a long
distance race, so use an even pace.
• Lesson: Frequent, incremental delivery allows a team to
learn how to deliver software.
• Lesson: Prioritization of requirements is faster than getting
all implementation details.
• Lesson: Simple does not mean short, simple means
straightforward and easy to understand.
• Lesson: The longer you wait to Refactor, the harder the
task, so don’t delay, do it today.
– Do not create “never to be resolved” technical debts
• Lesson: Do not comment bad code, fix it!
Mai 2014 14Arndt von Staa © LES/DI/PUC-Rio
Extreme programming lessons
• Lesson: Software Development is meant to be fun, if it isn’t
the process is wrong.
• Lesson: Humans ignore future costs in favor of immediate,
short term gains.
• Lesson: Hard numbers are needed to prevent the “90%
done for 90% of the time” problem.
• Lesson: Defend against schedule pressure by making
project velocity public knowledge.
• Lesson: How does a project get to be a year late? ... One
day at a time.
8
Mai 2014 15Arndt von Staa © LES/DI/PUC-Rio
Views and beyond ���� architecture
1. Architecture serves as a means of education to introduce people to
the system.
• Those people might be new members of the team, external analysts, or
new architects.
2. Architecture serves as a primary vehicle for communication among
stakeholders.
– An architecture’s precise use as a communication vehicle depends on
which stakeholders are doing the communicating. For instance,
maintainers will use the documentation to measure the impact of a
change and to identify the areas in which to begin work. Testers and
integrators will use it to understand the desired black-box behavior of
the system’s elements and how they should fit together.
3. Architecture serves as the basis for system analysis.
– To support that analysis, the architecture documentation must contain
the information necessary for the particular type of analysis being
performed.
Clements, P.C.; et al; Documenting Software Architectures in an Agile World;
Mai 2014 16Arndt von Staa © LES/DI/PUC-Rio
Institucionalização de processos ágeis
• Características
– organização grande, mas particionada em equipes pequenas
– treinamento em processos ágeis dado a todos
– alta gerência passou a exigir uma melhoria na qualidade
• Problemas:
– resistência a mudanças
• quanto mais bem sucedido mais difícil é convencer a mudar
• tendência à institucionalização parcial, cada equipe com sua
“parcialidade”
• auto-avaliação do grau de adoção não mudou o quando geral
• desenvolvedores não se convenceram dos benefícios
– sistemas legados – grandes sistemas C++
• Packlick, J.; “The Agile Maturity Map A Goal Oriented Approach to Agile
Improvement”;
9
Mai 2014 17Arndt von Staa © LES/DI/PUC-Rio
Institucionalização de processos ágeis
• Uso da abordagem ágil para a institucionalização do
processo ágil
– definição de objetivos baseados nas práticas XP
• acabou gerando um número grande: mais de 30
– criação da lista de pendências (backlog)
• pendências são objetivos não alcançados
• Para resolver o problema do número de objetivos os
objetivos similares foram agrupados em 5 grupos
Mai 2014 18Arndt von Staa © LES/DI/PUC-Rio
Institucionalização de processos ágeis
• Grupo 1 – Critérios de aceitação [dos artefatos]
– controle da corretude funcional
– assegurar suficiente informação para os desenvolvedores
durante uma iteração
• Grupo 2 – Barra verde para testes e construtos
– automação dos testes
– construtos e testes incorretos são corrigidos imediatamente
• Grupo 3 – Planejamento iterativo
– planejamento contínuo
– progresso mantido visível a todos
– retroalimentação baseada em fatos reais e usada para decisões
10
Mai 2014 19Arndt von Staa © LES/DI/PUC-Rio
Institucionalização de processos ágeis
• Grupo 4 – Aprendizado e adaptação
– mudanças [da forma de trabalho] visando melhoria da
qualidade requer investimento em habilitação (skills) e
aquisição de conhecimento através da prática
• Grupo 5 – Excelência em engenharia
– aplicação de boas práticas, tais como refatoração, padrões de
programação
Mai 2014 20Arndt von Staa © LES/DI/PUC-Rio
Institucionalização de processos ágeis
• Foram criados 5 níveis de adoção
• Consciência
– a equipe conhece os objetivos e os seus benefícios
– está consciente da existência de práticas melhores
• Transição
– práticas visando alcançar os objetivos são desempenhadas regularmente
– a equipe demonstra compromisso em alcançar os objetivos
• Ruptura (breakthrough)
– a equipe utiliza sistematicamente práticas ágeis que satisfazem os objetivos e os
critérios de aceitação
– mesmo quando sob pressão
• Otimização
– objetivos e seu alcance são continuamente aprimorados
– existe um espírito de criatividade visando melhoria
• Difusão (mentoring)
– equipes com níveis elevados de desempenho treinam e aconselham outras
equipes
– difunde-se o conhecimento adquirido a todas as equipes
11
Mai 2014 21Arndt von Staa © LES/DI/PUC-Rio
Institucionalização de processos ágeis
acceptance criteria
green bar – frequent automatic testing
iterative planning
learning and adapting the process
excellence in egineering
Mai 2014 22Arndt von Staa © LES/DI/PUC-Rio
Institucionalização de processos ágeis
• Observações
– melhoria em cerca de 60% na produtividade
– participação mais intensiva do cliente residente
– maior satisfação por parte dos clientes
– equipes em nível mais baixo passaram a querer subir de nível
– medidas de cobertura de código durante os testes têm
aumentado
– outros projetos surgiram
• mapa da maturidade de testes
• mapa da maturidade da qualidade
12
Mai 2014 23Arndt von Staa © LES/DI/PUC-Rio
CMMI vs Agile – Application
Characteristics Agile Disciplined
Primary Goals Rapid value; responding to change Predictability, stability, high
assurance
Size Smaller teams and projects Larger teams and projects
Environment Turbulent; high change; project-
focused
Stable; low-change;
project/organization focused
Boehm, B.W.; Turner, R.; Balancing Agility and Discipline: A guide for the Perplexed;
Mai 2014 24Arndt von Staa © LES/DI/PUC-Rio
CMMI vs Agile – Management
Characteristics Agile Disciplined
Customer Relations Dedicated on-site customers;
focused on prioritized increments
As-needed customer interactions;
focused on contract provisions
Planning and Control Internalized plans; qualitative
control
Documented plans, quantitative
control
Communications Tacit interpersonal knowledge Explicit documented knowledge
13
Mai 2014 25Arndt von Staa © LES/DI/PUC-Rio
CMMI vs Agile – Technical
Characteristics Agile Disciplined
Requirements Prioritized informal stories and
test cases; undergoing
unforeseeable change
Formalized project, capability,
interface, quality, foreseeable
evolution requirements
Development Simple design; short increment;
refactoring assumed inexpensive
Extensive design; longer increments;
refactoring assumed expensive
Test Executable test cases define
requirements, testing
Documented test plans and
procedures
Mai 2014 26Arndt von Staa © LES/DI/PUC-Rio
CMMI vs Agile – Personel
Characteristics Agile Disciplined
Customers Dedicated, collocated CRACK*
performers
CRACK* performers, not always
collocated
Developers At least 30% full-time Cockburn
level 2 and 3 experts; no Level 1B
or -1 personnel (ver a seguir)
50% Cockburn Level 2 and 3s
early; 10% throughout; 30% Level
1B’s workable; no Level -1s
Culture Comfort and empowerment via
many degrees of freedom (thriving
on chaos)
Comfort and empowerment via
framework of policies and
procedures (thriving on order)
* Collaborative, Representative, Authorized, Committed, Knowledgable
14
Mai 2014 27Arndt von Staa © LES/DI/PUC-Rio
CMMI vs Agile – Cockburn personal skill levels
Level Characteristics
3 Able to revise a method (break its rules) to fit an unprecedented new situation
2 Able to tailor a method to fit a precedented new situation
1A With training, able to perform discretionary method steps (e.g., sizing stories to fit
increments, composing patterns, compound refactoring, complex COTS integration).
With experience can become Level 2.
1B With training, able to perform procedural method steps (e.g. coding a simple method,
simple refactoring, following coding standards and CM procedures, running tests).
With experience can master some Level 1A skills.
-1 May have technical skills, but unable or unwilling to collaborate or follow shared
methods.
Mai 2014 28Arndt von Staa © LES/DI/PUC-Rio
CMMI vs Agile – Critical Factors
Factor Agility Considerations Discipline Considerations
Size Well-matched to small products and
teams. Reliance on tacit knowledge
limits scalability.
Methods evolved to handle large products
and teams. Hard to tailor down to small
projects.
Criticality Untested on safety-critical products.
Potential difficultiies with simple
design and lack of documentation.
Methods evolved to handle highly critical
products. Hard to tailor down to low-
criticality products.
Dynamism Simple design and continuous
refactoring are excellent for highly
dynamic environments, but a source
of potentially expensive rework for
highly stable environments.
Detailed plans and Big Design Up Front
excellent for highly stable environment, but
a source of expensive rework for highly
dynamic environments.
15
Mai 2014 29Arndt von Staa © LES/DI/PUC-Rio
CMMI vs Agile – Critical Factors
Factor Agility Considerations Discipline Considerations
Personnel Requires continuous presence of a
critical mass of scarce Cockburn
Level 2 or 3 experts. Risky to use
non-agile Level 1B people.
Needs a critical mass of scarce Cockburn
Level 2 and 3 experts during project
definition, but can work with fewer later in
the project—unless the environment is
highly dynamic. Can usually accommodate
some Level 1B people.
Culture Thrives in a culture where people
feel comfortable and empowered by
having many degrees of freedom.
Thrives in a culture where people feel
comfortable and empowered by having their
roles defined by clear policies and
procedures.
Mai 2014 30Arndt von Staa © LES/DI/PUC-Rio
CMMI vs Agile – Dimensions Affecting Selection
Personnel
Dynamism (% Requirements-change/month)
Culture (% thriving on chaos vs. order)
Size (# of personnel)
Criticality (Loss due to impact of defects)
5030
105
1
90
70
50
30
10
3
10
30
100
300
35
30
25
20
15
Essential
Funds Discretionary
Funds Comfort
Single
Life
Many Lives
(% Level 1B) (% Level 2&3)
0
10
20
30
40
Agile
Disciplined
16
Mai 2014 31Arndt von Staa © LES/DI/PUC-Rio
CMMI vs Agile – Dimensions Affecting Selection, ex.:
Personnel
Dynamism
(% Requirements-change/month)
Culture (% thriving on chaos vs. order)
Size (# of personnel)
Criticality (Loss due to impact of defects)
5030
105
1
90
70
50
30
10
3
10
30
100
300
35
30
25
20
15
Essential Funds Discretionary
Funds Comfort
Single Life
Many Lives
(% Level 1B) (% Level 2&3)
0
10
20
30
40
Mai 2014 32Arndt von Staa © LES/DI/PUC-Rio
Disciplina ágil é possível?
• Selecionar ferramentas que todos utilizam
– mesma versão
– mesma forma de instalação
– sob controle de configuração
– requer alguém que avalia novas versões e novas ferramentas e
conduz a evolução
• Documentar como devem ser realizadas as tarefas
– um simples diagrama pode ser suficiente
– material de treinamento
– reduzir a dependência de grande volume de conhecimento
tácito
– manter uma base de conhecimento?
• Assegurar a mobilidade das pessoas através de diferentes
equipes
17
Mai 2014 33Arndt von Staa © LES/DI/PUC-Rio
XPMM
Mai 2014 34Arndt von Staa © LES/DI/PUC-Rio
XPMM - Customer Relationship Management
• P0. The planning game is used to create project plans
• P2. User stories are written
• P3. Release planning creates the schedule
• P4. Make frequent small releases
• P5. The Project Velocity is measured
• P6. The project is divided into iterations
• P7. Iteration planning starts each iteration.
• D1. Choose a system metaphor
• D3. Create spike solutions to reduce risk
• D4. No functionality is added early
• C0a. Effectively collaborating customer
– We do not require, at this level, that the customer is always
available, but we expect that the customer representative will
have enough time to write user stories, create acceptance
tests, and participate in the planning game
18
Mai 2014 35Arndt von Staa © LES/DI/PUC-Rio
XPMM – Quality assurance
• C2. Code the unit test first
• C5a. Integrate often
– At this level it could be enough to integrate once a week. By integrating
once a week instead of several times a day one has fewer versions.
Consequently, less advanced version management systems and testing
tools will do
• C7. Leave optimization till last
• T0. All code must have unit tests
• T1a. All code must go through unit tests and the score must be
published before it can be released
– This is a more liberal version of rule T1. It can happen that a story
contains a few functionalities of different importance and a functionality
of lower importance has a bug. This allows to decide whether to release
such software and solve the problem in the next release
• T2. When a bug is found tests must be created
• T3. Acceptance tests are run often and the score is published
Mai 2014 36Arndt von Staa © LES/DI/PUC-Rio
XPMM - Pair programming
• P8. Move people around
• C0b. The customer pays frequent visits to the development team
– He should visit the developers at least once a week to create and
sustain personal contacts.
• C1. Code must be written to agreed standards
• C3. All production code is pair programmed
• C4. Only one pair integrates code at a time
• C5b. Integrate offen
– At this level integrate at least once a day
• C6. Use collective code ownership
• C8b. Overtime data are collected and published
– This is a more liberal version of the rule C8
• C9. A version management system is used
• T4. Automated testing is used to support frequent integration tests
• FO. Create an open workspace for the team
19
Mai 2014 37Arndt von Staa © LES/DI/PUC-Rio
XPMM - Mature
• C0. On-site customer
– The customer representative should be available on daily basis,
not less than 2 hours per day.
• C8. No overtime
– We think that overtime at the level of 10% would be no
problem
• T1. All code must pass all unit tests before it can be
released
• ??. Customer satisfaction is achieved
Mai 2014 38Arndt von Staa © LES/DI/PUC-Rio
XPMM – Hard / impossible to assess
• D0. Simplicity
• D3. Create spike solutions to reduce risk
• D4. No functionality is added early
20
Mai 2014 39Arndt von Staa © LES/DI/PUC-Rio
Bibliografia
• Boehm, B.W.; Turner, R.; Balancing Agility and Discipline: A guide for the Perplexed;
Reading, Massachusetts: Addison-Wesley; 2004
• Clements, P.C.; James Ivers, J.; Little, R.; Nord, R.; Stafford, J.; Documenting
Software Architectures in an Agile World; Technical Note CMU/SEI-2003-TN-023;
2003
• Costa, P.; Basili, V.R.; Lindvall, M.; Dangle, K.C.; Boehm, B.W.; Shull, F.; Tesoriero,
R.; Williams, L.; Zelkowitz, M.V.; “Empirical Findings in Agile Methods”; Proceedings
of the Second XP Universe and First Agile Universe Conference on Extreme
Programming and Agile Methods - XP/Agile Universe 2002; Berlin: Springer; 2002;
pags 197-207
• Keefer, G.; XP Considered Harmful; AVOCA GmBH; 2002
• McBreen, P.; “Applying the Lessons of eXtreme Programming”; in Li, Q.; Firesmith,
D.; Riehle, R.; Meyer, B. (Eds.): TOOLS 2000: 34th International Conference on
Technology of Object-Oriented Languages and Systems; Santa Barbara, CA: IEEE
Computer Society; 2000; pags 423-430; ISBN 0-7695-0774-3
• Manzo, J.; “Odyssey and Other Code Science Success Stories”; Crosstalk The Journal
of Defense Software Engineering; URL: http://www.stsc.hill.af.mil/crosstalk/;
Washington, DC: Department of Defense; 2002; pags 19-21,30
Mai 2014 40Arndt von Staa © LES/DI/PUC-Rio
Bibliografia
• Nawrocki, J.; Walter, B.; Wojciechowski, A.; "Toward Maturity Model for extreme
Programming"; EUROMICRO 2001; IEEE Computer Society; 2001; pags 233-239
• Orr, K.; "CMM Versus Agile Development: Religious Wars and Software
Development"; Agile Project Management Advisory Service 3(7); Cutter Consortium;
2002
• Packlick, J.; “The Agile Maturity Map A Goal Oriented Approach to Agile
Improvement”; Agile 2007; Los Alamitos, CA: IEEE Computer Society; 2007; pags
266-271
• Paulk, M.C.; "Extreme Programming from a CMM Perspective"; IEEE Software 18(6);
Los Alamitos, CA: IEEE Computer Society; 2001; pags 19-26
• Pikkarainen, M.; Mtyniemi, A.; “An Approach for Using CMMI in Agile Software
Development Assessments: Experiences from Three Case Studies”; Proceedings of the
Sixth International SPICE Conference, Luxemburg, 3-5 May 2006;
• Rumpe, B.; Schroeder, A.; “Quantitative Survey on Extreme Programming Projects”;
XP2002 Third International Conference on Extreme Programming and Flexible
Processes in Software Engineering, Alghero, Italy, 2002; 2002; pags 95-100
• Staples, M.; Niazi, M.; Jeffery, R.; Abrahams, A.; Byatt, P.; Murphy, R.; “An
exploratory study of why organizations do not adopt CMMI”; The Journal of Systems
and Software 80; New York, NY: Elsevier; 2007; pags 883-895