Sua equipe está preparada para atender um cliente ágil?

JUGDAY * RSJUG.ORG * SUCESU-RS
Porto Alegre, RS, 24/10/2009

está
Sua equipe está preparada para
atender um cliente ágil?
Luiz Claudio Parzianello
parzianello@suryatec.com.br
http://parzianello.blogspot.com

Copyright © 2009 LUIZ C PARZIANELLO Slide 1 de 54

Quem sou eu?

CLÁ
LUIZ CLÁUDIO PARZIANELLO
http://parzianello.blogspot.com/
Assessoria e treinamento em Lean, Scrum e Extreme Programming
Palestrante em eventos nacionais e internacionais
Mestre em Engenharia Biomédica (Sistemas) pela USP
Engenheiro Eletricista (Eletrônica) pela PUCRS
+ 25 anos de experiência profissional em informática (todas as posições)
+ 11 anos atuando em Engenharia de Software
+ 6 anos de experiência com Metodologias Ágeis
Vice-Coord. do Grupo de Usuários de Métodos Ágeis da Sociedade dos
Usuários de Informática e Telecomunicações do RS (SUCESU-RS)
Atuou para organizações como Instituto do Coração (INCOR/HCFMUSP),
SCS Consulting (Citibank, EUA), BANRISUL, SICREDI, ThyssenKrupp
Elevadores, Refinaria Alberto Pasqualini (REFAP/Petrobrás), FAURGS,
FIERGS, Ministério do Planejamento (Angola), Neogrid, FUNTEC
(Argentina), Universidade Nacional de La Plata (Argentina), etc.


O Manifesto Ágil
http://agilemanifesto.org/

Estamos descobrindo melhores formas de desenvolver software
fazendo e ajudando outras pessoas a fazerem o mesmo. Ao longo
deste trabalho, passamos a valorizar:

1. Indivíduos e interações mais que processos e ferramentas
2. Software que funciona mais que documentação abrangente
3. A colaboração com o cliente mais que a negociação de contratos
4. Responder à mudança mais que seguir um plano

Ou seja, mesmo que haja valor nos itens da direita, valorizamos ainda
mais os da esquerda.
Assinado por 17 gurus da área de software
Utah (EUA), fevereiro de 2001


Prá
O Manifesto na Prática

http://pm.versionone.com/AgilePoster.html
http://pm.versionone.com/AgilePoster.html


E se o cliente fosse ágil?


Algumas regras para atender um
Cliente Ágil
Baseadas nos 12 princípios do Manifesto Ágil
http://agilemanifesto.org/principles.html


Atendendo um Cliente Ágil

Nº
Regra Nº 1

Como fornecedor, sua maior prioridade será
satisfazer minhas necessidades através da entrega
rápida e contínua de software que agregue valor para
meus interesses de negócio.

“Não tente me convencer do quanto
sua equipe é incrivelmente encantadora
... Ao invés disso, mostre-me como sua
equipe irá transformar meu negócio
em algo incrível e encantador aos olhos
dos meus clientes!”


Pensamento Enxuto

Valor é visto através dos olhos
daqueles que pagam pelo uso
e que se beneficiam com os
sistemas que desenvolvemos.

Desperdício é qualquer coisa que
deprecie os recursos no tempo,
esforço, espaço ou dinheiro sem
acrescentar valor ao cliente.


Transformaç
A Transformação

C1 C2 AS IS
E1 S1 Um projeto é um
F1 D1
A1
A2
A4 A5
transformaç
processo de transformação!
E2 A3 S2
F2 D2

M1 M2
C1 C2 TO BE
E1
S1
F1 D1
A2
Onde você pode A1 A4 A5
E2 A3 S2
reclamaç
encontrar reclamações ... F2 D2

Onde você espera M1 M2

encontrar elogios ...


Retorno de Investimento
Custo ROI

Investimento
Total

Agile

Waterfall

Time
Time
R1 R2 R3 R4 R5
Iní
Início do
Iní Final do Final da Break-
Break-even
Início do Final do Final da Break-
Break-even
Projeto Projeto Transiç
Transição
Transiç
Projeto Projeto Transição



Nº
Regra Nº 2

Como fornecedor, você deve estar preparado para
atender às mudanças de meus requisitos, durante
toda a duração do projeto.
Imediato

Próximo

Distante

Longínquo

Futuro

No Mundo da Incerteza


Me Engana que Eu Gosto!

Preciso de uma Não tenho a mínima Duvido! Você vai colocá-
estimativa de custo Não se preocupe, não la num plano e vai se
idéia! Ainda não
do seu projeto! vou considerá-la um esquecer que tivemos
levantei os requisitos
compromisso ... esta conversa. Depois,
com os usuários!
irá me despedir quando
estourar o orçamento!

Se você já Para saber O que você
Me dê um número ou Ok! Ele vai custar sabia quanto se estava
vou despedi-lo agora! acha de
US$ 10 milhões! É muito ia custar, por abaixo do US$ 500 mil?
caro! que me pediu previsto!
um número?



Nº
Regra Nº 3

Como fornecedor, você deve estar preparado para
entregar uma versão do produto de software em
perfeito funcionamento a cada uma ou quatro
semanas, de preferência, todos os dias.

Scrum

Mike Cohn [http://www.mountaingoatsoftware.com/scrum]

O Fluxo de Trabalho

Visão Baseada em Grandes Lotes (Waterfall)


O Fluxo de Trabalho

Fluxo Unitário de Criação

Visão Baseada em Pequenos Lotes (Just in Time)


O Fluxo de Trabalho

… ou lenta eetumultuada?
… ou lenta tumultuada?

t33
nt
rriin
Sp
Sp
2
2
nt
iint
Spr
pr
S

Você prefere uma viagem t1
t1
Você prefere uma viagem riin
rn
ápida confortável …
rrápidaeeconfortáável… ??
confortá
confort Sp
Sp



Nº
Regra Nº 4

Como fornecedor, sua equipe de desenvolvimento
deve aceitar e incentivar a colaboração diária de meus
representantes de negócio, durante todo o projeto.

será
Por que será que ainda
precisamos desta ponte?

Karl E. Wiegers
More About Software Requirements
Microsoft Press, 2006


Os Técnicos e “seus” Usuários
Té seus” Usuá



Nº
Regra Nº 5

Como fornecedor, você deve garantir a alocação de
profissionais motivados e um ambiente de trabalho
adequado para a realização de um processo criativo.

• Ambiente
• Conhecimento
• Habilidade
• Atitude



Nº
Regra Nº 6

Como fornecedor, você deve garantir a comunicação
direta de meus profissionais com sua equipe de
desenvolvimento, de preferência, de forma presencial,
mas aceitamos o uso de ferramentas de colaboração.

IMPACTO DA COMUNICAÇÃO
COMUNICAÇ
Palavras 7% Verbal
Sons 38 %
Não-Verbal
Fisiologia 55 %

Mehrabian and Ferris (1967) ¨Inference of attitutes
from nonverbal communication in two channels¨


Comunicaç
A Comunicação Humana



Nº
Regra Nº 7

Como fornecedor, sua principal medida de desempenho
e progresso será “software em funcionamento”.


No Mundo da Incerteza

Por que vários programadores que possuem:
Resposta:
Resposta:
A mesma capacitação técnica Conhecimento
As mesmas especificações de produto Conhecimento
Experiência
Experiência
O mesmo plano de desenvolvimento Inspiração
Inspiraçção
A mesma configuração dos computadores Inspiraç
Inspira
Criatividade
Criatividade
As mesmas ferramentas de desenvolvimento etc.
O mesmo ambiente de trabalho etc.
E a mesma alimentação (pizza!)

Irão produzir um código fonte diferente de seus colegas de profissão?


Qualidade Objetiva

• Cloc
• Checkstyle
• PMD
• Emma
• ...

http://xradar.sourceforge.net/


Codificaç
Padrões de Codificação

http://blogs.sun.com/geertjan/entry/checkstyle


Codificaç
Maturidade na Codificação

http://www.javapassion.com/handsonlabs/javadebugpmd/

Cobertura de Testes

http://www.mountainminds.com/products/eclemma/

Testes de Unidade

http://p.blog.csdn.net/images/p_blog_csdn_net/erylee/
http://p.blog.csdn.net/images/p_blog_csdn_net/erylee/
p.blog


Testes Funcionais

http://www.theautomatedtester.co.uk/


Integraç Contí
Integração Contínua

Pode ajudar a reduzir
as suposições feitas
sobre o produto de
software mediante sua
reconstrução sempre
que uma mudança
ocorrer no sistema de
controle de versões do
código fonte.


Integraç Contí



Nº
Regra Nº 8

Como fornecedor, você deve garantir um ritmo
sustentável de qualidade e produtividade no processo
de desenvolvimento de software.

• Duração de tarefas
• Jornadas diárias
• Compartilhamento
• Substituições
• Expectativas
• Cobranças


Métricas Ágeis

Tí
Comportamento Típico da Velocidade (Capacidade) de uma Equipe Ágil

David Starr (http://elegantcode.com/2008/01/24/on-sprint-planning-and-velocity/)


Métricas Ágeis

Iteration Burndown Chart
Iteration Burndown Chart

Product Burndown Chart
Project Burndown Chart

160
120
100
80

Iterations
Source: Danube (ScrumWorks)


Métricas Ágeis

Source: Danube (ScrumWorks)


Métricas Ágeis

Daily Burndown Chart
Daily Burndown Chart

Source: Mike Cohn User Stories Applied for Agile Software Development, 2004
Cohn,



Nº
Regra Nº 9

Como fornecedor, você deve dar atenção permanente
à excelência técnica e ao bom design de produto.

http://www.jacoozi.com/


Refactoring

http://claudiosvirgens.files.wordpress.com/


Pair Programming

At Crisp we take Pair Programming very seriously...
As professional consultants we always adapt to our
customer's corporate culture. When in Rome...

Secret CCC convent (Crisp Code
Camp) captured by paparazzi...
Historians found evidence that
pair programming has been
around for longer than we
previously thought...



Nº
Regra Nº 10

Como fornecedor, você tem a obrigação de simplificar
o que deve ser feito a fim de diminuir a quantidade de
software necessário para atender minhas necessidades.

Standish Group (Chaos Report 2002)
http://www.poppendieck.com/


Comunicaç
Comunicação x Complexidade

“É assim que eu
quero meu produto!”

“Ok! Entendi perfeitamente que
você deseja um balanço para
brincar com as crianças!”



Nº
Regra Nº 11

Como fornecedor, você deve garantir a formação de
uma equipe auto-organizada, pois é dos profissionais
que compõem essas equipes que costumam surgir as
melhores soluções técnicas e de negócio.

http://www.bestbrains.dk/



Nº
Regra Nº 12

Como fornecedor, você deve fazer com que sua equipe
reflita periodicamente à respeito de seus resultados,
investigando como ela e/ou minha empresa podem se
tornar mais eficientes e eficazes no atendimento das
necessidades.
Aprendizagem organizacional
Aprendizagem organizacional
contínua através do Kaizen!
contínua através do Kaizen!


relaç
Como ficaria nossa relação?


Cé
Uma Célula Remota
Testador (QA)
Testador (QA) Desenvolvedores
Desenvolvedores

Analista de
Analista de
Usuários-Chave
Usuários-Chave Negócios
Negócios

Fornecedor
Scrum Master
Scrum Master

Cliente
Analista
Analista
de Sistemas
de Sistemas

Cé
Uma Célula Remota

Cliente Ágil
Cliente Ágil Fornecedor
Fornecedor

• Demandas de projeto SCRUM
• Demandas de produto
Célula Remota
• Demandas de suporte

Áreas de Negócio
• Especificação de Escopo
Área de Sistemas • Protótipos Visuais
• Informações de Negócio

• Soluções
Tecnológicas
• Sistemas de Informação
• Melhorias de Software
• Informações de Suporte
• Questionamentos
• Componentes de Software
• Releases de Produto
Integração Contínua é feita no cliente, XP
com SLA’s para níveis de maturidade em
relação à qualidade do código.


O manifesto do
artesão de software


Um Novo Manifesto
“Como aspirantes a Artesãos de Software estamos elevando o nível do
desenvolvimento de software profissional praticando e ajudando os outros a
aprenderem a arte do ofício Através deste trabalho, passamos a valorizar:
ofício.

Não somente um software que funciona,
mas também um software bem acabado
acabado;
Não somente responder à mudança,
mas também agregar valor constantemente
constantemente;
Não somente indivíduos e interações,
mas também uma comunidade de profissionais
profissionais;
Não somente a colaboração com o cliente,
mas também a formação de parcerias produtivas
formaç produtivas.

Ou seja, na busca dos itens da esquerda, descobrimos que
os itens da direita são indispensáveis.”
http://manifesto.softwarecraftsmanship.org

Um Novo Manifesto

Artesão:
Artesão Pessoa que geralmente trabalha por conta
própria e utiliza técnicas que são conhecidas e
geralmente codificadas, em domínios geralmente
ligados à matéria.

Artista Aquele que cria, não somente através da
Artista:
matéria mas também da expressão física e
intelectual. Se em alguns domínios as técnicas são
conhecidas e codificadas, a inovação com que este
contribui para esse domínio é geralmente o traço
do artista.


Um Novo Manifesto

O que realmente devemos esperar de
um artesão do software?

Uma pessoa que pratique com
domínio e paixão a arte do
desenvolvimento de software;

ARTESÃO = ARTE + TESÃO


Muito obrigado!
Luiz Claudio Parzianello
parzianello@suryatec.com.br
http://parzianello.blogspot.com

http://www.slideshare.net/parzianello
http://www.scribd.com/parzianello


Sua equipe está preparada para atender um cliente ágil?

Recomendados

Recomendados

Mais conteúdo relacionado

Semelhante a Sua equipe está preparada para atender um cliente ágil?

Semelhante a Sua equipe está preparada para atender um cliente ágil? (10)

Sua equipe está preparada para atender um cliente ágil?