Processos rigorosos versus processos ágeisinf2135/docs/INF2135-Modulo09... · • Uso da abordagem ágil para a institucionalização do processo ágil – definição de objetivos

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


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


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


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


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


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


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


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”;


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



• 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;



• 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



• 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!



• 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


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;


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



• 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



• 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



• 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



• 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



acceptance criteria

green bar – frequent automatic testing

iterative planning

learning and adapting the process

excellence in egineering



• 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


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;


CMMI vs Agile – Management


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


CMMI vs Agile – Technical


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


CMMI vs Agile – Personel


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


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.


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


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.


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


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


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


XPMM


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


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


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


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


XPMM – Hard / impossible to assess

• D0. Simplicity

• D3. Create spike solutions to reduce risk

• D4. No functionality is added early

20


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


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

Documents

Processos rigorosos versus processos ágeisinf2135/docs/INF2135-Modulo09... · • Uso da abordagem ágil para a institucionalização do processo ágil – definição de objetivos