ValoresDoXP

(1)

Valores do XP

Rodrigo César Lobo

Gerência de Projetos 2

Roteiro da aula

Feedback

Comunicação

Simplicidade

Coragem

Feedback (I)

Cliente Equipe

Aprende algo novo sobre o sistema Aprende ais sobre os requisitos

Aprende mais sobre a forma como foram implementados

Feedback: novas idéias

O que, quando e como deve ser feito

Requisitos Gerência de Projetos 4

Feedback (II)

Equipe Cliente

Estimativas Riscos técnicos Sugestões de design

Feedback: O que precisa ser feito

Design

Implementação

Produção vs. consumo

Romper a divisão

Cliente e equipe de desenvolvimento atuam como produtores e consumidores

Agilidade

Cliente apresenta novas idéias Equipe consome as idéias Produz alterações

Apresenta as alterações

Produção Consumo

Ágil vs. Tradicional

O processo de troca de informações

já

existia

na

abordagem

de

desenvolvimento tradicional, porém

de forma lenta

Feedback rápido e repetido várias

vezes durante todo o processo

Análise Projeto Implementação Testes Implantação

(2)

Rapidez

Quanto

mais

rápido

o

feedback

melhor o aprendizado

O cliente realimenta a equipe de

desenvolvimento no decorrer de dias

ou semanas e não em meses ou

anos

Fator psicológico Gerência de Projetos 8

Roteiro da aula

Feedback

Comunicação

Simplicidade

Coragem

Comunicação

Sempre presente e de forma intensa

Entre

os

membros

da

equipe

(desenvolvedores) e o cliente

Essencial para a troca de idéias

Crescimento do software

Atingir os objetivos desejados

Tipos de comunicação

Passar uma idéia para outra pessoa

Face-a-face Telefone E-mail

Mensagem instantânea

Qual a mais eficiente?

Influência direta na compreensão da

mensagem

Face-a-face

Fala

Tom de voz

Gestos

Expressão facial

Interpretação mais fácil

Dúvidas

são

esclarecidas

rapidamente

Perguntas e repostas rápidas

Telefone

Fala

Tom de voz

Ausência de gestos

Ausência de expressões faciais

Perde-se elementos da comunicação

Comunicação se torna mais pobre

(3)

Meio escrito (I)

Apenas elementos visuais

Maior esforço para compreensão

Não é possível esclarecer dúvidas

através do meio de comunicação

Fria e desprovida de emoção

O fator emocional é de suma importância para a comunicação humana

Meio escrito (II)

Margem para várias interpretações

diferentes

Pobre em elementos de comunicação

IMPORTANTE

Não confundir texto técnico com texto literário

Certo grau de emoção

Roteiro da aula

Feedback

Comunicação

Simplicidade

Coragem

Simplicidade

Ações de cada membro da equipe

devem ser simples e restritas

Feedback mais rápido

Simplicidade para implementação de

uma funcionalidade

Implementar apenas o que é suficiente para ser valido ou não pelo cliente

Trabalho especulativo

Proposições

para

aspectos

do

software que ainda não se tem total

certeza

Desenvolvedor geralmente tem um

dúvida para a qual ainda não tem uma resposta

Erro: Assumir uma resposta que parece

razoável e implementar a solução

Esta resposta geralmente está errada Quem sabe a “resposta correta” é o

cliente

O que fazer?

Implementar a solução mais simples

Evitar especulações

Diminui o re-trabalho

Tempo e dinheiro em ações que não se

tem certeza da necessidade

Utilizar generalizações

Com cuidado

Também pode ser um esforço inútil Esperar o momento correto

(4)

Roteiro da aula

Feedback

Comunicação

Simplicidade

Coragem

XP é um processo novo

Baseado em várias premissas que

contrariam os processos tradicionais

É necessário coragem para trabalhar com o XP

Coragem para acreditar e aplicar as

melhores práticas do XP

Coragem (I)

Desenvolver o software de forma

incremental

Ciclo de vida em Espiral

Partes implementadas são re-visitadas para acomodar novas funcionalidades ou sofrer alterações

Feedback do cliente

Coragem para alterar partes que já estavam funcionando

Coragem (II)

Manter o sistema simples

Cada funcionalidade é implementada da forma mais simples possível.

Apenas aquilo que já se conhece no

presente

Atender rapidamente à necessidade do

cliente

Feedback mais rápido

Coragem para manter o código simples e acreditar que novas funcionalidades poderão ser incorporadas.

Coragem (III)

Permitir priorizações do cliente

Aspectos de negócio tem mais peso que aspectos técnicos

Cliente prioriza

Coragem para acreditar que implementações ordenadas por valores de negócio poderão ser implementadas mesmo que não indiquem a melhor escolha do ponto de vista técnico

Coragem (IV)

Fazer os desenvolvedores trabalhar

em par

Trabalhar em par não indica aumentar os custos do projeto

Errado pensar que são dois fazendo o

trabalho de um

O que ocorre na prática é um aumento

de produtividade

Coragem para defender e adotar esta

(5)

Coragem (V)

Investir tempo em refactoring

Ao contrário do que se pensa o

refactoring não é um gasto a mais de tempo durante o desenvolvimento

Permite que alterações no código sejam realizadas rapidamente

Código de alta qualidade

Coragem para adotar esta estratégia

Coragem (VI)

Investir

tempo

em

testes

automatizados

Comumente vistos como um gasto de tempo desnecessário

Previne a ocorrência e a persistência de

erros

Não é um gasto é um investimento Coragem para adotar esta estratégia

Coragem (VII)

Estimar estórias na frente do cliente

Sempre na frente do cliente Tirar dúvidas

Estimativas mais precisas Assusta algumas equipes

Cliente pode perceber insegurança na

equipe

Comunicação aberta e honesta Coragem para expor os problemas

Coragem (VIII)

Expor o código a todos os membros

da equipe

Código é visto e manipulado por todos

os membros da equipe

Maior exposição à críticas e avaliações Coragem para expor o código

Humildade para aceitar as críticas e

aprender com os colegas

Coragem (IX)

Integrar o sistema várias vezes ao

dia

Possibilidade de surgimento de erros de

integração

Utilizar práticas que protejam contra estes

erros (testes de unidade e aceitação)

Coragem realizar as integrações e acreditar que as práticas irão minimizar a ocorrência de tais erros

Coragem (X)

Adotar um ritmo sustentável

Qualidade de software depende das

qualidade dos desenvolvedores

A qualidade dos desenvolvedores é

afetada se estes não estiverem descansados e atentos

Manter uma jornada de trabalho de 40 horas semanais mesmo durante pressões de tempo

(6)

Coragem (XI)

Abrir

mão

de

documentação

que

servem como defesa

Atritos entre clientes e equipe

Documentação como forma de proteção XP: comunicação aberta e honesta

Documentação apenas quando realmente

for necessário

Coragem para abandonar os

documentos

Coragem (XII)

Propor contratos de escopo variável

XP: acolha as mudanças

Contratos não podem ter escopo fixo Incorporar o feedback do cliente

Contratos que permitam alterações no

escopo

Coragem para adotar este novo tipo de contrato

Coragem (XIII)

Propor a adoção de um processo

novo

Contrariar o tradicional Acreditar em novas premissas

É preciso coragem para acreditar em um abordagem que parece está indo de encontro ao habitual