Post on 25-Sep-2020
1
Processos ágeis
Arndt von Staa
Departamento de Informática
PUC-Rio
Março 2014
Mar 2014 2Arndt von Staa © LES/DI/PUC-Rio
Especificação
• Objetivo
– examinar Extreme Programming, SCRUM e Kanban
• Justificativa
– Extreme Programming, Scrum e Kanban abrangem praticamente todo o escopo de processos ágeis.
2
Mar 2014 3Arndt von Staa © LES/DI/PUC-Rio
The Agile Software Development Manifesto
• We are uncovering better ways of developing software by doing it and helping others do it.
• Through this work we have come to value:
– Individuals and interactions over processes and tools
– Working software over comprehensive documentation
– Customer collaboration over contract negotiation
– Responding to change over following a plan.
• That is, while there is value in the items on the right, we value the items on the left more."
Mar 2014 4Arndt von Staa © LES/DI/PUC-Rio
Valores
• Comunicação contínua entre desenvolvedores e usuários ou clientes
• Simplicidade a ser alcançada através da procura constante por soluções minimalistas
• Feedback rápido através de teste automatizado de unidades e componentes, e da integração frequente– teste estrutural elaborado pelos desenvolvedores
– teste funcional elaborado pelos (representantes) dos usuários
• Coragem de resolver problemas de forma pró-ativa– alterar arquitetura se esta for inapropriada para evolução,
teste, ou outro aspecto da qualidade
– alterar a organização do código
– evoluir as especificações
– . . .
3
Mar 2014 5Arndt von Staa © LES/DI/PUC-Rio
Apoio aos valores
• A melhor forma de troca de informação entre clientes, usuários e desenvolvedores é conversação face a face
– ênfase é em interação humana direta
– isso não impede que se documente os resultados dessa interação, entretanto não enfatiza
• Crença: as melhores especificações de requisitos, arquiteturas e projetos são geradas por equipes que se auto-organizam
– design é aquisição de conhecimento
Mar 2014 6Arndt von Staa © LES/DI/PUC-Rio
Apoio aos valores
• Simplicidade: a arte de maximizar trabalho NÃO realizado
– nunca implementar algo que se imagina que poderia vir a ser útil no futuro
• YAGNI – you aren’t going to need it
– somente implementar o que é efetivamente requerido em dado momento do desenvolvimento em curso
• princípio LEAN (processo enxuto): lazy evaluation – somente desenvolver alguma coisa quando necessário
– se adições aparecerem no futuro
• fazer as alterações quando as novas necessidades surgirem
– menos ortodoxo: como as historietas (ou o objetivo geral) são conhecidas, é permitido levar historietas futuras em consideração
• existem evoluções intrinsecamente caras
• vale a pena protelar desenvolvimento neste caso?
4
Mar 2014 7Arndt von Staa © LES/DI/PUC-Rio
Apoio aos valores
• Feedback rápido - prioridade: satisfazer o cliente ou usuário
– Priorizar a disponibilização frequente de construtos que agreguem valor ao cliente / usuário
– Frequente: de (uma?) duas semanas a dois meses
– Construto que agrega valor: implementação parcial porém útilpara o usuário do sistema total
• A funcionalidade implementada, com qualidade controlada, e disponibilizada é a medida de progresso
– não é tempo trabalhado
– não é artefato desenvolvido
– requisitos não funcionais? � qualidade controlada
Mar 2014 8Arndt von Staa © LES/DI/PUC-Rio
Apoio aos valores
• Apoiar e viabilizar a implementação de alterações de requisitos, mesmo que tardios, durante o desenvolvimento
– tolerar especificações incompletas
– tolerar especificações que evoluam no tempo
– tolerar especificações fluidas (até certo ponto)
• “somente saberei o que quero depois de ver implementado”
• Há quem diga:
– isso equivale a desenvolver sem especificação e ir corrigindo a seguir
– não é bem verdade, pois todos propõem
• historietas, casos de uso, ...
• desenvolvimento dirigido por testes ou similar
• eu proponho a mais o uso de assertivas
5
Caracterização de processos
KNIBERG, H.; SHARIN, M. Kanban and Scrum: Making the most of
both. C4Media, 2010. 122 p. Disponível (também) em:
<http://www.infoq.com/minibooks/kanban-scrum-minibook>. Acesso
em: 26 abr. 2011
Mar 2014 Arndt von Staa © LES/DI/PUC-Rio 9
número de regras formalizadas
XP – eXtreme Programming
http://www.extremeprogramming.org/index.html
Mar 2014 Arndt von Staa © LES/DI/PUC-Rio 10
6
Mar 2014 11Arndt von Staa © LES/DI/PUC-Rio
Por que “extreme”?
• Deve desenvolver extremamente rápido
• Deve extremar ao evitar a injeção e a permanência de defeitos
• Deve extremar a evolução ainda durante o desenvolvimento
– Não deve impedir ou inibir alterações nas especificações nem no código
• Deve extremar o envolvimento do usuário
• Deve extremar o envolvimento dos desenvolvedores
– todos devem poder ler e/ou alterar qualquer parte do código
• Deve extremar no respeito às pessoas e suas necessidades pessoais, sociais e psicológicas
Caristi, J.; Extreme Programming: Theory & Practices; Valparaiso University; notas de aula;
James.Caristi@valpo.edu
Mar 2014 12Arndt von Staa © LES/DI/PUC-Rio
Motivação para XP
• Reduzir riscos
• Aumentar a valia para o usuário
• Disponibilizar rápida e frequentemente alguma coisa útil
• Assegurar que exista evidência tangível de progresso
– mesmo se o projeto for cancelado no meio
7
Mar 2014 13Arndt von Staa © LES/DI/PUC-Rio
Reduzir riscos
• Risco: atrasos no desenvolvimento– como XP procura resolver
• desenvolvimento incremental através de pequenas liberações (releases, construtos) sucessivas
• cada liberação procura disponibilizar algumas das funcionalidades que, ao planejar a liberação, são de maior interesse para o usuário
• o esforço de desenvolvimento deve caber no tempo disponibilizado– o esforço é estimado pelos desenvolvedores– o prazo para disponibilizar é solicitado pelo usuário ou cliente
– a velocidade média de desenvolvimento é medida continuamente
• se a velocidade medida for incompatível com a estimada a composição da liberação deve ser replanejada
• cada liberação deve ser concluída em pouco tempo – menos de 3 meses
– consequência• possíveis atrasos na sequência de liberações terão um impacto
menor sobre o usuário / cliente• sempre será disponibilizada alguma coisa útil
Mar 2014 14Arndt von Staa © LES/DI/PUC-Rio
Reduzir riscos
• Risco: cancelamento tardio do projeto
– algumas causas para cancelamentos
• o sistema torna-se desinteressante
• o sistema torna-se inviável técnica ou financeiramente
• o projeto torna-se difícil de justificar
– como XP procura resolver
• presença de um usuário como parte da equipe – ou representante dele => proxy
• cada liberação procura disponibilizar algumas das funcionalidades que, ao planejar a liberação, são de maior interesse para o usuário
– consequência
• inutilidade e/ou inviabilidade é observada cedo
• cancelamento será baseado em observação concreta
• redução do risco de shelfware
8
Mar 2014 15Arndt von Staa © LES/DI/PUC-Rio
Reduzir riscos
• Risco: falta de manutenibilidade– possíveis causas para baixa manutenibilidade
• manutenção sucessiva tende a desestruturar o sistema, tornando-o difícil de manter
– mas sistemas utilizados sempre evoluirão
– como XP procura resolver• testes automatizados (unidade, integração, funcional)
• se for observada a possibilidade ou a necessidade de reestruturação, esta deverá ser feita (refactoring “obrigatório”)
• evitar adicionar características (funcionalidades) não explicitamente solicitadas
– consequência• a estrutura do sistema se amolda às funcionalidades
disponibilizadas em determinado momento
• testes podem ser repetidos com frequência a um custo muito baixo
• manutenção pode ser realizada com adequado (sempre?) controle da qualidade
Mar 2014 16Arndt von Staa © LES/DI/PUC-Rio
Reduzir riscos
• Risco: sistema inadequado– adequação: sistema realiza o que o usuário precisa
– possíveis causa para inadequação• sistema não resolve problemas que interessam ao usuário
– como XP procura resolver
• historietas são redigidas pelo usuário (ou representante dele)
• presença de um usuário como membro da equipe
• revisão continuada pelo usuário
• teste de aceitação realizado com frequência pelo usuário
• poucas características adicionais por liberação
• implementação das características (features) de maior valor
– consequência • especificação evolui de acordo com o aprendizado do usuário e dos
desenvolvedores
• especificação tende a ser a de maior valor agregado para o usuário
• o sistema se amolda às necessidades dos usuários
9
Mar 2014 17Arndt von Staa © LES/DI/PUC-Rio
Reduzir riscos
• Risco: características inúteis– possíveis características inúteis
• funcionalidade imaginada útil, mas que o usuário não necessita
– como XP procura resolver• historietas são redigidas pelo usuário
• novas historietas e mudanças em historietas são incorporadas ao conjunto de historietas a desenvolver
• desenvolvedores não alteram nem complementam historietas– desenvolvedores podem sugerir alterações ao usuário
– não se aceita o “deixa comigo” por parte dos programadores
• cada liberação procura disponibilizar as funcionalidades de maior interesse no momento do planejamento
– espera-se que seja pequena a probabilidade de uma característica pouco útil ser considerada de elevado interesse no futuro
– consequência • desenvolvedores não inventam características que não interessam
explicitamente ao usuário
Mar 2014 18Arndt von Staa © LES/DI/PUC-Rio
Reduzir riscos
• Risco: muitas falhas pós-entrega– como XP procura resolver
• historietas (especificações) são redigidas pelo usuário
• equipes com elevada proficiência
• desenvolvimento em pares
• reorganização obrigatória
• projeto e código simples
• testes automatizados aplicados com frequência– testes de unidade rigorosos
– bons testes automatizados de integração, funcionais, não funcionais e de aceitação
– consequência• baixa probabilidade da permanência de
– defeitos de construção
– defeitos estruturais (organização ruim)
– inadequações (não faz o que é desejado)
– defeitos funcionais (implementação incorreta)
– defeitos não funcionais (qualidade insatisfatória)
10
Parêntesis
• Causas para perdas ao desenvolver software (waste)
– trabalho realizado parcialmente
– características inúteis (adicionadas)
– retreinamento, reaprendizado
– esperas
– troca de tarefas
– defeitos
Mar 2014 19Arndt von Staa © LES/DI/PUC-Rio
Poppendiek, M.; Poppendieck, T.; Lean software development: Na agile toolkit; Addison-Wesley; 2003
Mar 2014 20Arndt von Staa © LES/DI/PUC-Rio
Reduzir riscos
• Risco: dificuldade de evoluir as especificações
– mudanças em especificações são inevitáveis!
• sempre teremos que estar preparados para elas
– como XP procura resolver
• especificação redigida pelo usuário
• desenvolvimento incremental
• cada incremento é concluído em pouco tempo
• manutenção preventiva � refactoring obrigatório
• teste automatizado usado para teste de regressão
– consequência
• poucas alterações introduzidas após incremento aceito
– a aceitação do incremento reduz a chance de propagação de defeitos para os próximos incrementos
• novos incrementos já estarão observando as alterações em incrementos anteriores
• retrabalho reduzido
11
Mar 2014 21Arndt von Staa © LES/DI/PUC-Rio
Reduzir riscos
• Risco: perdas devidas à rotação de pessoal
– como XP procura resolver• desenvolvimento em pares estabelecidos dinamicamente
• artefatos são de propriedade coletiva
• código simples, em acordo com padrões estabelecidos, bem organizado, bem projetado, e reorganizado sempre que necessário
• desenvolvedores estimam o esforço e participam do planejamento das liberações
– prazos de conclusão não são impostos � tendem a ser realistas
• dia de 8 horas (semana de 40 horas)
• equipe motivada
– consequência • não existe “dono de artefato”
• tendência ao nivelamento por cima
• elevada moral de trabalho
• não existe cronograma inviável imposto aos desenvolvedores
• sempre terá alguém que conheça o projeto ou o código a manter
Papéis envolvidos
Gerente Atua como facilitador ou coordenador. Separa decisões técnicas das do negócio. Disponibiliza os recursos necessários de forma pró-ativa.
Coach (scrum master)
Apóia, treina desenvolvedores (participantes). Promove e mantém a institucionalização do XP.
Cliente /usuário (project
owner)
Redige e prioriza historietas. Ajuda a resolver problemas. Desenvolve testes de aceitação (funcionais). Representa os diversos usuários.
Testador Apóia o cliente / usuário ao redigir os testes funcionais. Auxilia desenvolvedores a redigir testes de unidade e de integração de boa qualidade.
Observador Mantém (redige) a história do projeto (pos mortem). Mede a velocidade do desenvolvimento. Verifica a validade das estimativas, melhora a forma de estimar.
Desenvolvedor Seleciona, estima e realiza as tarefas. Desenvolve testes de unidade e integração. Reorganiza o código. Trabalha em pares.
Mar 2014 Arndt von Staa © LES/DI/PUC-Rio 22
12
Fluxo geral
Historietas
Conjecturaarquitetural
requisitos
metáfora
Planejarliberação
Experi-mentar
estimativasduvidosas
estimativasconfiáveis
plano deliberação
Iteração Teste deaceitação
Construtoaceito
aprovação
cenáriosde teste
historieta nova
velocidade defeitos
últimaversão
próximaiteração
[Wells, 2006]
Mar 2014 Arndt von Staa © LES/DI/PUC-Rio 23
Mar 2014 24Arndt von Staa © LES/DI/PUC-Rio
Práticas de planejamento
• Redigir historietas
• Planejar liberações (construto, build, release)
• Liberar com frequência construtos, realizando pequenos incrementos com relação aos anteriores
• Medir a velocidade do projeto
• Particionar o construto em iterações
• Planejar cada iteração
• Mover (fazer circular) pessoas
• Realizar reunião em pé ao início de cada dia
• Aprimorar XP quando encontrar problemas com o processo
13
Mar 2014 25Arndt von Staa © LES/DI/PUC-Rio
Práticas de projeto
• Assegurar simplicidade de projeto
• Escolher uma metáfora para o sistema
• Utilizar cartões CRC
– Classe, Responsabilidades, Colaboradores
• Realizar pequenos experimentos (spike) para reduzir riscos de estimativa
– sempre que existir incerteza quanto à forma de resolver ou de estimar o esforço de resolução
• Evitar a adição antecipada de funcionalidade
• Reorganizar (refactor) sempre que possível
– menos ortodoxo: quando necessário
Mar 2014 26Arndt von Staa © LES/DI/PUC-Rio
Práticas de codificação
• O cliente / usuário estará sempre disponível
• Redigir código em acordo com padrões estabelecidos
• Redigir primeiro os testes
– unidade, integração, componente, não funcionais, sistema
• Utilizar programação em pares para todo o código de produção
• Somente um par realiza integração a cada instante
• Integrar com frequência
– sugestão várias vezes por dia
• O código pertence a todos
• Deixar a otimização para o final
• Não utilizar ou exigir horas extras
14
Mar 2014 27Arndt von Staa © LES/DI/PUC-Rio
Práticas de teste
• Redigir testes de unidade para todas as unidade
• Redigir testes de construtos e de liberações
• Coevoluir os testes junto com a evolução do sistema
• Assegurar que todas as unidades passem o teste de unidade antes integrar ou liberar– medir cobertura de teste ao testar unidades
• Ao observar uma falha em artefato aceito– primeiro redija um teste que acuse a falha
– depois corrija o programa
– a seguir reteste tudo
• Realizar testes de aceitação com frequência e divulgar o escore do teste– medida de progresso é o número de historietas
(funcionalidades) implementadas
Mar 2014 28Arndt von Staa © LES/DI/PUC-Rio
Faltam práticas?
• Gerência de requisitos???
– assume-se que o planejamento de liberações usando as historietas pendentes resolva o problema
– não está claro como resolver alterações de historietas já implementadas
• alterações em historietas futuras não criam problemas, pois ainda não foram planejadas
– testes automatizados podem ser entendidos como especificações, mas precisam co-evoluir com as historietas
• Gerência de configuração???
– é implícita no caso de código
• é subentendido que esteja em uso um sistema de controle de versão na máquina de integração
• mas controle de versão não é gerência de configuração
– é inexistente no caso de historietas – redigidas à mão em papel
15
Mar 2014 29Arndt von Staa © LES/DI/PUC-Rio
Faltam práticas?
• Arquitetura
– não existe uma preocupação realista com relação à arquitetura
– a proposta de usar metáforas não convence
• Design
– não existe uma proposta realista com relação ao design lógico e físico
• Inicialmente a proposta era: faça isso somente se desejar, mas ao terminar o desenvolvimento descarte os documentos gerados (use um quadro branco...), o que vale é o código
– qual o limite de tamanho de sistema que se pode desenvolver com essa proposta?
Mar 2014 30Arndt von Staa © LES/DI/PUC-Rio
Faltam práticas?
• Acompanhamento de problemas???
– não é mencionado, mas aparentemente é praticado
– tampouco é mencionado como realizar a manutenção após conclusão
• Medição e análise???
– somente explicita a medição da velocidade
– a medida de progresso é o número de historietas concluídas e aceitas
• Trilha de auditoria do controle da qualidade???
• . . .
16
Detalhamento
Mar 2014 Arndt von Staa © LES/DI/PUC-Rio 31
Mar 2014 32Arndt von Staa © LES/DI/PUC-Rio
Historietas – especificações
• Historietas são especificações que focalizam uma (única?) funcionalidade
– requisitos funcionais
– requisitos não funcionais
• como são redigidas do ponto de vista do usuário podem inadvertidamente omitir aspectos relevantes
– persistência
– interface entre computadores
– modelagem dos dados
– segurança
– capacidade de crescimento – escalabilidade – capacidade de crescer junto com o crescimento da
demanda
– . . .
17
Mar 2014 33Arndt von Staa © LES/DI/PUC-Rio
Historietas
• Cada historieta é redigida pelo usuário à mão em um cartão
• Os desenvolvedores solicitam decomposição ou reescrita para historietas complexas ou não inteligíveis
• Não existe ordenação a priori de historietas
• A equipe registra as precedências intrínsecas, caso haja
• Os desenvolvedores estimam o risco e o esforço necessário para implementar a historieta
– risco técnico: baixo, médio, alto
– esforço 1, 2 ou 3 semanas “ideais”. Se mais do que 3 a historieta deve ser decomposta.
• semana ideal: 40 horas de desenvolvimento “puro”. Não contempla feriados, tarefas complementares, reuniões etc.
• O usuário acrescenta informação sobre a importância (valor, prioridade)
Mar 2014 34Arndt von Staa © LES/DI/PUC-Rio
Planejamento, aspectos gerais
• Aspectos inter-relacionados de projetos de software
– um deles sempre será função dos outros
• Abrangência (scope) – o que deve ser implementado
• responsabilidade: principalmente do cliente / usuário; comentários do desenvolvedor, ou do gerente
• Dimensão – o tamanho dos artefatos a implementar para essa abrangência
• responsabilidade: desenvolvedor
• Qualidade – requisitos não funcionais, qualidade assegurada
• responsabilidade: principalmente do cliente / usuário
• Recursos – pessoal, equipamentos, software, ...
• responsabilidade: do gerente
• Tempo – duração do projeto
• computado
18
Mar 2014 35Arndt von Staa © LES/DI/PUC-Rio
Abrangência: avaliação
• As historietas são realmente necessárias para a atual liberação?
– acrescentam valor?
– exigem pré-requisitos não disponíveis ou não previstos?
• As historietas não necessárias foram devidamente retiradas do conjunto a implementar?
• As historietas estão claras e bem escritas?
– os critérios de aceitação são conhecidos?
• Você poderá perder tempo procurando por fatos que não estão redigidos nas historietas?
• Você poderá perder tempo reescrevendo código baseado em historietas mal escritas ou incompletas?
Mar 2014 36Arndt von Staa © LES/DI/PUC-Rio
Qualidade: avaliação
• Os testes estão disponíveis antes que você necessite deles?
– disponha sempre de testes de unidade e testes de aceitação suficientemente bem elaborados
• Os testes estabelecem como você acha que as coisas deveriam ocorrer?
• Os testes executam rapidamente de modo que você possa reexecutá-los com frequência?
• Você perde tempo em reuniões para discutir como as coisas deveriam ser ou operar, ao invés de demonstrá-lo através de testes?
19
Mar 2014 37Arndt von Staa © LES/DI/PUC-Rio
Recursos: avaliação
• Você dispõe das pessoas necessárias (e adequadas) e que haviam sido prometidas?
• A adição de um testador ou consultor poderia ajudar?
• A adição de um documentador (redator técnico) poderia ajudar?
• Desenvolvedores estão desenvolvendo, ou estão participando de reuniões de especificação e planejamento?
• Os clientes/usuários estão especificando, produzindo testes de aceitação e explicando o que é desejado, ou estão dizendo como as coisas deveriam ser implementadas, ou, pior, atuando como desenvolvedores?
Mar 2014 38Arndt von Staa © LES/DI/PUC-Rio
Tempo: avaliação
• Você é obrigado a (ou quer) participar de reuniões desnecessárias?
• As reuniões são objetivas?
• As reuniões começam na hora marcada?
• Todos os que participam nas reuniões estão devidamente preparados, inclusive você?
• Historietas são apresentadas na ordem correta?
– ver mais adiante: iteração
• Testes e historietas melhores reduziriam o retrabalho inútil?
• Outras ações poderiam reduzir o retrabalho inútil?
20
Mar 2014 39Arndt von Staa © LES/DI/PUC-Rio
Planejamento
• O planejamento do desenvolvimento do sistema como um todo não está previsto
– excessiva incerteza ao iniciar
• especificações são fluidas
• alterações durante o desenvolvimento são permitidas
• desconhecimento a priori do sistema completo
• Preço fixo é inviável
– o cliente aceita embarcar em um projeto sem saber quanto custará?
– estatísticas (Boehm) envolvendo diversos projetos mostram que o desenvolvimento cuidadosamente controlado tende ao custo mínimo
– liberações frequentes demonstram o progresso real de forma insofismável
Mar 2014 40Arndt von Staa © LES/DI/PUC-Rio
Planejar liberações
• O desenvolvimento do sistema como um todo é realizado através de uma sucessão de liberações
– cada liberação (release) gera um construto e deve ocorrer em aproximadamente 3 ou menos meses
– o planejamento da liberação estabelece o conjunto de historietas a serem implementadas
– o conteúdo de cada liberação é definida pelo cliente/usuário em conjunto com os desenvolvedores
21
Mar 2014 41Arndt von Staa © LES/DI/PUC-Rio
Planejar um construto
• Planejamento (planning game)
– é realizado através da negociação entre desenvolvedores e clientes/usuários
• objetivo encontrar um equilíbrio justificável e acordado entre o que se deseja e o que se pode obter dentro das limitações de tempo, custo e demais recursos
– pode requerer
• a produção de esboços de arquiteturas
• a realização de experimentos (spikes)
– as estimativas de semanas ideais são transformadas em semanas reais através da velocidade média medida ou observada até o momento (iteração ou liberação anterior)
• uso de experiência passada (bases de estatísticas)– XP menciona a existência de um observador que mede a velocidade e
registra a história do projeto, sem dizer como
Mar 2014 42Arndt von Staa © LES/DI/PUC-Rio
Planejar um construto
• Planejar por tempo
– estabelecer um prazo aproximado
– selecionar as historietas mais relevantes ao usuário no momento do planejamento e que levem a um construto útil
– assegurar que o tempo real estimado para as historietas selecionadas caiba no prazo disponível
• Planejar por abrangência
– selecionar as historietas mais relevantes ao usuário no momento do planejamento e que levem a um construto útil
– determinar o prazo a partir da escolha de historietas
• JAMAIS
– mude estimativas para agradar a gerência ou o cliente/usuário
• prazos irrealistas são uma das principais fontes para fracassos de projetos
22
Mar 2014 43Arndt von Staa © LES/DI/PUC-Rio
Liberar com frequência
• Construtos úteis devem ser liberados com frequência em prazos de 3 semanas a 3 meses
– cada construto incremental deveria ser o menor capaz de adicionar uma funcionalidade útil
• O uso de construtos permite ao usuário avaliar a adequação do que foi desenvolvido até agora
– isso é uma forma de corrigir especificações relativamente cedo, reduzindo o retrabalho inútil
– torna-se quase que obrigatório quando as especificações forem fluidas ou estabelecem requisitos difíceis de avaliar a priori, ex.
• interfaces humano computador
• “eu saberei se é o que quero depois de poder usar”
Mar 2014 44Arndt von Staa © LES/DI/PUC-Rio
Medir a velocidade
• Velocidade mede o volume de resultados produzidos pela equipe por unidade de tempo real
• pouco contribui medir a produção por indivíduo
• a variação individual é muito grande– entre indivíduos e de um mesmo indivíduo em atividades diferentes
– Número de historietas concluídas em uma liberação considerando o tempo real para desenvolver o construto• mais precisamente total de semanas ideais estimadas nas
historietas por total de semanas de calendário
– Número de historietas concluídas em uma iteração• o número de historietas (semanas ideais) por iteração
– iterações devem ter todas mais ou menos a mesma duração
– Número de atividades concluídas pela equipe durante uma iteração• total de dias ideais estimados nas atividades desenvolvidas durante
a iteração
23
Mar 2014 45Arndt von Staa © LES/DI/PUC-Rio
Particionar o trabalho em iterações
• O trabalho de desenvolvimento de um construto deve ser particionado em iterações– iterações devem ter duração (quase) fixa
• a duração das iterações deve ser alguma coisa entre 1 e 3 semanas
• Obs. todos manuais de gerência de projetos de software dizem que atividades devem durar entre 1 e 3 semanas!
– em virtude da duração fixa não é necessário considerar o tempo real de duração de iterações ao medir a velocidade• funciona?
– iterações curtas criam menos problemas caso ocorram erros de estimativa ou alterações repentinas
– caso a velocidade das iterações mude (número semanas ideais de historietas concluídas, número de dias ideais de atividades concluídas) a liberação deve ser replanejada• isso viabiliza a inclusão / alteração de requisitos
Mar 2014 46Arndt von Staa © LES/DI/PUC-Rio
Planejar iterações
• Abrangência
– O cliente/usuário escolhe as historietas mais importantes
• obedecendo precedências caso haja
– São selecionadas também as historietas que não conseguiram passar pelos testes de aceitação em iterações anteriores
• historietas não aprovadas em iteração anterior têm seu esforço reestimado
– O total de esforço selecionado deve estar em conformidade com a velocidade
• número de semanas ideais de historietas por iteração
24
Mar 2014 47Arndt von Staa © LES/DI/PUC-Rio
Planejar iterações
• Desenvolvimento
– As historietas são particionadas em atividades de desenvolvimento
• a descrição de atividades é similar à de historietas, a linguagem no entanto é técnica ao invés de dirigida ao usuário
– Desenvolvedores candidatam-se às atividades
• pares de desenvolvedores por atividade
– Desenvolvedores estimam o tempo necessário para as atividades escolhidas,
• 1 a 3 dias ideais, se for mais de 3 particione a atividade
Mar 2014 48Arndt von Staa © LES/DI/PUC-Rio
Planejar iterações
• Desenvolvimento (cont.)
– A velocidade do projeto é utilizada para determinar o limite de capacidade de cada desenvolvedor
• o volume de trabalho (dias ideais implementados) na iteração anterior serve de estimador da capacidade
• se o total exceder a capacidade da equipe, o usuário deve remover uma historieta nova ou inconclusa segundo a prioridade dele
• se tiver sobra de capacidade, o usuário pode adicionar uma historieta
– O planejamento termina quando usuário, desenvolvedores e gerente estiverem todos de comum acordo
25
Mar 2014 49Arndt von Staa © LES/DI/PUC-Rio
Planejar iterações
• Controvérsia:
– deve-se ou não levar em consideração coisas que estão em historietas futuras para reduzir o trabalho total?
• XP ortodoxo diz que não
• XP menos radical diz que sim, caso não fazê-lo ofereça riscos. Ex. banco de dados, interpretadores, frameworks
• Observações
– caso for percebido que a velocidade não permita implementar o construto, deve-se replanejar a liberação
• eliminar historietas ainda não implementadas
• ou não concluídas caso estas tenham se mostrado muito complexas
– evite planejar adiante da iteração corrente
Mar 2014 50Arndt von Staa © LES/DI/PUC-Rio
Fazer pessoas circularem
• Assegure que os pares mudem com frequência
– pares mudam ao terminar uma atividade
• Assegure que todos tenham conhecimento de (quase) tudo
– idealmente vários desenvolvedores realizarão atividades relacionadas com uma mesma historieta
• Assegure que todos tenham conhecimento completo das ferramentas, padrões e convenções
– se necessário, use pares para fins de treinamento
26
Mar 2014 51Arndt von Staa © LES/DI/PUC-Rio
Reunião em pé
• Cada dia de trabalho inicia com uma reunião curta realizada com todos em pé em círculo,
– duração cerca de 15min
– cada membro da equipe deve responder às três perguntas a seguir:
• O que você fez desde a última reunião? – as atividades / tarefas concluídas
– as em andamento
– as que faltam fazer
• Quais problemas e obstáculos você encontrou para realizar suas tarefas desde a última reunião?
– o gerente registra os problemas e obstáculos
– depois da reunião, procura resolvê-los.
• Em que você vai trabalhar até a próxima reunião (dia útil a seguir)?
Mar 2014 52Arndt von Staa © LES/DI/PUC-Rio
Reunião em pé
• Benefícios
– espera-se que problemas do desenvolvimento sejam identificados cedo
• permite à gerência, ao usuário e aos desenvolvedores tomar uma ação corretiva ainda a tempo
– espera-se que problemas e dúvidas com o sistema encontrem alguém que se prontifique a resolve-los
– espera-se que sejam eliminadas as necessidade de outras reuniões
27
Mar 2014 53Arndt von Staa © LES/DI/PUC-Rio
Aprimorar XP
• Procure seguir as regras estabelecidas
• Mas não o faça cegamente
– se observar algum problema que requeira adaptação, implemente essa adaptação
• Processos de maneira geral devem amoldar-se ao projeto e não ao contrário
Mar 2014 54Arndt von Staa © LES/DI/PUC-Rio
Simplicidade
• Qualquer artefato deve:
– Executar corretamente todos os casos de teste
– Não possuir código duplicado
• nem cópia direta
• nem cópia ligeiramente alterada
• ao invés de cópias use uma função com parâmetros– “cut, paste and change considered harmful”
– Possuir o número mínimo de classes e funções necessárias e suficientes para implementar a funcionalidade
– A necessidade de cada classe, função e interface com o usuário deve estar relacionada com pelo menos uma das historietas do construto
28
Mar 2014 55Arndt von Staa © LES/DI/PUC-Rio
Simplicidade
• Torna necessária a reorganização (refactoring) ao terminar a atividade ou ao desenvolver outra mais tarde
• Sequência de tarefas recomendada
– dada a especificação do artefato (cartão CRC)
– implementa (parte do) teste automatizado do artefato
– implementa parte do artefato
– executa os testes e corrige até zero falhas
– repete para outra parte até que o artefato esteja completo
– aprimora o teste (aplica critérios de teste no rigor necessário para a qualidade desejada) e retesta até zero falhas
– reorganiza (refactoring) simplificando a estrutura, eliminando
duplicatas etc., sempre retestando até zero falha
Mar 2014 56Arndt von Staa © LES/DI/PUC-Rio
Uso de metáfora
• Escolha uma palavra ou frase que descreva bem as principais características do sistema– objetivos principais do sistema
– características funcionais
– características de utilizabilidade
– slogan? jingle?
• O objetivo é servir de “arquitetura”
• Esse é um dos itens mais controversos– é difícil produzir uma boa metáfora
– um sistema mais complexo dificilmente cabe em uma
– estatísticas mostram baixa institucionalização disso
Metáfora – [Aurélio Eletrônico] Figura de linguagem que consiste na transferência de uma palavra para um
âmbito semântico que não é o do objeto que ela designa, e que se fundamenta numa relação de
semelhança subentendida entre o sentido próprio e o figurado. Por metáfora, chama-se raposa a uma
pessoa astuta, ou se designa juventude por primavera da vida.
29
Mar 2014 57Arndt von Staa © LES/DI/PUC-Rio
Uso de metáfora
• Exemplo:
– Papel eletrônico para um editor
• permite escrever
• permite apagar
• permite remendar
• permite fazer rascunhos
• é clemente
• permite melhorar o aspecto
• permite copiar e colar
• permite criar esquemas (patterns) a serem copiados
Mar 2014 58Arndt von Staa © LES/DI/PUC-Rio
Utilizar cartões CRC
• Cartão CRC: similar a uma historieta
– título a classe
– à esquerda responsabilidades
• descrição da intenção
• principais funções
– à direita colaboradores
• classes / objetos com que interage
• Na realidade é similar a um “diagrama de classe” em que se visualiza uma única classe a cada vez
Beck, K.; Cunningham, W.; “A Laboratory For Teaching Object-Oriented Thinking”; ACM SIGPLAN Notices
24(10); New York, NY: Association for Computing Machinery; 1989; pags 1-6; Buscado em:
10/fevereiro/2008; URL: http://c2.com/doc/oopsla89/paper.html
30
Utilizar cartões CRC
Mar 2014 Arndt von Staa © LES/DI/PUC-Rio 59
Mar 2014 60Arndt von Staa © LES/DI/PUC-Rio
Realizar experimentos
• Sempre que não souber como resolver um problema específico deve-se realizar um pequeno experimento
– somente examinar o problema específico
– não se preocupar com outros aspectos
• Objetivo:
– aprender a resolver o problema
– aumentar a confiabilidade das estimativas
• Os experimentos não são protótipos, usualmente são descartados uma vez que se aprendeu a resolver o problema
31
Mar 2014 61Arndt von Staa © LES/DI/PUC-Rio
Evitar antecipação
• YAGNI – You are NOT gonna need it!
– O argumento é
• generalidade e funcionalidade sem demanda somente adiciona custo
• a menos que exista demanda não é possível determinar se a generalidade ou funcionalidade a mais será utilizada algum dia
– em geral não é (chute: 90% das vezes não é)
• se desenvolvido visando manutenibilidade o custo da evolução tende a ser pequeno
• crença: é mais econômico desenvolver uma versão simples e depois ampliá-la
– este é um pressuposto controverso a seguir
Mar 2014 62Arndt von Staa © LES/DI/PUC-Rio
Evitar antecipação
Conflito
• existem artefatos com custo de evolução alto– ex. base de dados povoada
– quando e como desenvolver modelos de bases de dados?
• existem artefatos cujo investimento vale a pena somente se aplicado a vários projetos ou em vários lugares de um mesmo projeto– quando, como e por quê desenvolver
• componentes genéricos?
• componentes reutilizáveis?– reuso próativo: linhas de produto (product lines)
– reuso passivo: desenvolve uma solução(quase) genérica e vê se alguém se interessa por ela
• frameworks?
• geradores de artefatos?
• ferramentas de apoio ao desenvolvimento?
32
Mar 2014 63Arndt von Staa © LES/DI/PUC-Rio
Evitar antecipação
• Em uma visão menos ortodoxa
– Valem generalizações prevendo historietas existentes ainda a serem implementadas
• desde que o custo de ampliar no futuro seja elevado
– Permite-se desenvolver ferramentas, frameworks etc. desde que o esforço do desenvolvimento seja visto como compensador para os tipos de projeto desenvolvidos na organização
existentes: ainda não desenvolvidas e não fazem parte do construto em desenvolvimento
Mar 2014 64Arndt von Staa © LES/DI/PUC-Rio
Reorganização (refactoring)
• Reorganize sempre que necessário ou possível
– ver Simplicidade
• Postura menos ortodoxa
– reorganize sempre que necessário
– lazy evaluation – elaboração preguiçosa ☺
33
Mar 2014 65Arndt von Staa © LES/DI/PUC-Rio
Reorganização (refactoring)
• Quando encontrar um design ruim corrija-o– um bom design pode ter-se tornado ruim devido
• à incorporação de novas historietas
• à manutenção sucessiva
• correria durante o desenvolvimento
• Reorganize sem mudar a funcionalidade– assegure que os casos de teste existentes rodem
• 100% no caso de teste de unidade e integração
• x% igual ou melhor ao que rodavam no teste funcional antes da refatoração
• Após reorganizar, adicione as novas funcionalidades– coevolua os casos de teste
• Conflitos decorrentes de múltiplos pares alterando um mesmo módulo podem ser resolvidos por comunicação direta
Mar 2014 66Arndt von Staa © LES/DI/PUC-Rio
Reorganização (refactoring)
• Condições para reorganização a baixo custo
– posse coletiva
• todos sabem e podem manter tudo
• isto é viável em projetos com centenas de milhares de linhas de código?
– padrões de programação
• publicados
• treinados
• obedecidos
– programação aos pares
– design simples
– teste automatizado
– integração contínua
– documentação das partes conceituais críticas (obs. adição minha)
34
Mar 2014 67Arndt von Staa © LES/DI/PUC-Rio
Usuário / cliente residente
• Usuário é alguém que efetivamente utilizará o sistema. O cliente está interessado em dispor do sistema.
– Define ou refina as especificações
• historietas
– Estabelece prioridades para as historietas
– Redige os testes de aceitação para cada uma das historietas
– Participa da negociação durante planejamento de cada liberação
– Participa da negociação do planejamento de iterações (incrementos)
Mar 2014 68Arndt von Staa © LES/DI/PUC-Rio
Cliente / usuário residente
• Problemas
– sempre podemos contar com um?
• custo
• existe alguém capaz de assumir este papel?– grande variedade de papéis em sistemas modernos
– proficiência necessária para redigir boas historietas
• no caso de software produto, quem seria o usuário?
• Variantes
– representante da variedade de usuários (proxy)
– desenvolvedor atuando como “usuário” delegado
– usuário(s) não residentes mas com compromisso de atendimento imediato
– . . .
35
Mar 2014 69Arndt von Staa © LES/DI/PUC-Rio
Padrões
• Todo código deve estar em conformidade com os padrões acordados
– Padrões estabelecem
• como representar alguma coisa
• como escolher nomes– uniformidade de terminologia
• como documentar � documentação mínima
• como organizar um artefato
• restrições de uso das linguagens de representação
• critérios de avaliação da qualidade
• esquemas de solução (padrões de projeto, design patterns)
• . . .
Mar 2014 70Arndt von Staa © LES/DI/PUC-Rio
Padrões
• Padrões devem
– contribuir para o aumento da qualidade por construção
• confiabilidade
• manutenibilidade (evolutibilidade, diagnosticabilidade)
• utilizabilidade (look and feel uniforme)
– contribuir para o aumento da produtividade
• reduzir o retrabalho inútil
– contribuir para eliminar burocracia
– contribuir para a automação de etapas do processo
– contribuir para a uniformidade dos artefatos
– facilitar a comunicação entre pessoas
• especialmente quando não presencial
– tornar artefatos impessoais
– evoluir (lentamente) no tempo
36
Mar 2014 71Arndt von Staa © LES/DI/PUC-Rio
Padrões
• Podem ser desenvolvidos por organizações de normatização,
– neste caso são normas
– ex. ANSI, DIN, ISO, ABNT
– obs. todos os CMMx não são normas, são padrões
• Podem ser desenvolvidos e publicados por uma variedade de autores
– ex. padrões de projeto
– conferências PLOP – pattern languages of programming
• Podem ser desenvolvidos em uma ou mais organizações
• Podem ser desenvolvidos para um determinado projeto
– ex. look and feel
Mar 2014 72Arndt von Staa © LES/DI/PUC-Rio
Teste automatizado
• O teste deve ser automatizado • na medida do possível �
– exemplos de frameworks:
• JUnit para Java
• CPPUnit para C++
• HTTPUnit
• JWebUnit
• . . .
– existem ferramentas para teste automatizado bastante sofisticadas
• quanto mais sofisticadas – mais caras
– mais difíceis de aprender
– nem sempre melhores �
37
Mar 2014 73Arndt von Staa © LES/DI/PUC-Rio
Teste automatizado
• Testes devem ser escritos antes do código
– testes passam a ser especificações operacionais
– são critérios de aceitação verificados mecanicamente
– podem existir problemas com gráficos e figuras
• neste caso faz-se inicialmente a verificação visual e depois a comparação com imagens importadas
• Devem ser acrescentados casos de teste sempre que se descobrir um problema que os casos de testes disponíveis não foram capazes de detectar
– antes de corrigir, adicionar casos de teste que evidenciam o problema não antes detectado
– depois de corrigir, rever os casos de teste que passaram a evidenciar problemas na realidade inexistentes
Mar 2014 74Arndt von Staa © LES/DI/PUC-Rio
Teste automatizado
• Testes de unidade devem ser redigidos pelos programadores
– devem rodar 100% correto
– devem apresentar boa cobertura
• Testes de integração de unidade redigidos pelos programadores
– devem rodar 100% correto
– devem apresentar boa cobertura – difícil assegurar isso
• Testes de aceitação devem ser redigidos pelos usuários
– devem existir casos de teste para cada item/condição contido na historieta
– pode ocorrer que programas sejam aceitos mesmo que alguns testes do usuário não passem
– próximo à data da liberação • devem estar perto dos 100%
• o usuário deve determinar quais os casos falhos toleráveis (descritos em read-me ou em issue tracker?)
38
Mar 2014 75Arndt von Staa © LES/DI/PUC-Rio
Teste automatizado
• Gere os casos de teste segundo algum método
– não use achologia
• achologia leva a testes incompletos
– testes devem descobrir e não encobrir falhas
– teste sempre os requisitos não-funcionais e os inversos
• Em geral ao iniciar o desenvolvimento dirigido por testes, os primeiros testes são simples
– à medida que o desenvolvimento evolui a qualidade do teste evolui junto
– o rigor do teste depende do risco associado ao artefato
– quanto maior o rigor, mais custoso será o teste
Mar 2014 76Arndt von Staa © LES/DI/PUC-Rio
Teste automatizado
• Podem (devem) ser utilizadas ferramentas complementares
– instrumentação (robustez , tolerância a falhas)
• controladores de cobertura
• assertivas executáveis – de maneira geral pré-condições
– programação orientada a contratos (Eiffel: contract driven
development)
– depuradores
• evite o uso de depuradores, tende a ser muito caro
• use-os somente quando tiver um problema (falha) bem definido e replicável a ser resolvido (diagnose identificar a causa)
• o uso de assertivas tende a ser muito mais eficaz e eficiente
39
Mar 2014 77Arndt von Staa © LES/DI/PUC-Rio
Teste automatizado
• Testes complementares
– teste de capacidade - verifica se o sistema é capaz de atender à demanda especificada
• usualmente faz uso de simuladores de demanda
– stress test - procura identificar o que acontece se o limite de demanda projetado é ultrapassado
• usualmente faz uso de simuladores de demanda
– teste paralelo - verifica se o sistema novo é consistente (igual?) com o sistema antigo
– teste do macaco (à prova de idiota) - verifica se o sistema resiste ao uso incorreto (uso non-sense) deliberado ou não
• geradores de dados aleatórios “quase corretos”
– . . .
Mar 2014 78Arndt von Staa © LES/DI/PUC-Rio
Programação aos pares
• Toda codificação deve ser realizada por dois programadores trabalhando em conjunto num mesmo computador
– um cria e digita
• código
• casos de teste
– outro inspeciona o que foi digitado
• erros de digitação
• não concordâncias com os padrões
• falta, excesso ou inconsistência de comentários
• uso incorreto de classes, métodos e variáveis
• estruturas de controle incorretas
• redação de casos de teste complementares
• procura por soluções reutilizáveis
• . . .
40
Mar 2014 79Arndt von Staa © LES/DI/PUC-Rio
Programação aos pares
• Os pares de programadores devem variar
– idealmente a cada módulo deve ser um par diferente
– viabiliza a posse coletiva do código
– estimula o aprendizado coletivo
• É uma forma de inspeção contínua
• Reduz um grande número de defeitos banais e vários complicados
– segundo algumas medições o custo de teste e depuração (retrabalho inútil) é bem maior do que o custo de dois programadores
Cockburn, A.; Williams, L.; “The costs and benefits of pair programming”; in: Succi, G.; Marchesi, M.; eds.;
Extreme Programming Examined; Reading, Massachusetts: Addison-Wesley; 2001; pags 223-243
Williams, L.; Kessler, R.; “Overcoming Management Resistance to Pair-Programming”; in: Williams, L.;
Kessler, R.; eds.; Pair Programming Illuminated; Reading, Massachusetts: Addison-Wesley; 2002; pags
33-44
Mar 2014 80Arndt von Staa © LES/DI/PUC-Rio
Programação aos pares
• Alguns problemas
– as pessoas que formam pares precisam ter empatia uma com a outra
• respeito e confiança mútuos
• capacidade de compartilhar raciocínio
– será que as pessoas precisam ter um nível de proficiência parecido ?
• aparentemente pode ser utilizado para treinamento “on the job”
41
Mar 2014 81Arndt von Staa © LES/DI/PUC-Rio
Integração sequencial
• Sempre que um módulo for concluído
– ele deverá ser integrado ao conjunto de módulos aceitos
• na máquina de integração
– ele deverá ser testado no contexto desse conjunto
– se passar nos testes (integração, aceitação) deve ser incorporado ao sistema de controle de versão em uso
– se não passar no teste deve ser removido da máquina de integração
• Existe uma única máquina destinada à integração
– somente contém os artefatos que tiverem sido aprovados
• A cada momento um único par poderá estar integrando
Mar 2014 82Arndt von Staa © LES/DI/PUC-Rio
Posse coletiva
• Todos devem ter conhecimento da arquitetura e do design
do sistema
• Todos devem conhecer todo o código
• Todos devem ser capazes de alterar corretamente qualquer porção de código
• Todos devem estar autorizados a alterar qualquer porção de código
• Não deve existir especialista em uma parte do sistema
42
Mar 2014 83Arndt von Staa © LES/DI/PUC-Rio
Posse coletiva
• Consequência
– o sistema é mais imune à rotação de pessoal
– existe uma tendência de nivelamento por cima
– existe uma tendência de coesão da equipe
• pode ser problema para a organização
• pode ser problema para a adição de novatos
Mar 2014 84Arndt von Staa © LES/DI/PUC-Rio
Posse coletiva
• Problemas
– sistemas grandes permitem posse coletiva?
• é possível? E se o programa tiver > 100.000 linhas de código
• quantas linhas de código redigidas por outros conseguimos ler e entender por dia?
– é conveniente a ausência de especialistas?
• SQL
• protocolos TCP/IP
• processamento distribuído
• Web-services
• Web-engineering
43
Mar 2014 85Arndt von Staa © LES/DI/PUC-Rio
Deixe a otimização para o final
• Não otimize antes de saber se é de fato necessário
– implemente a solução mais simples
• mesmo se o algoritmo não for o mais eficiente
– use estimativas de risco para determinar o grau de simplicidade
• expectativas de crescimento da demanda
– execute testes de carga para determinar os potenciais gargalos
– meça e identifique os pontos críticos
– aprimore somente os pontos críticos
• Otimização é sensível à evolução
– coisas otimizadas podem passar a ser pouco utilizadas
– o ótimo requerido depende da forma de uso, do hardware e da plataforma utilizada
– o ótimo local pode piorar o todo
Mar 2014 86Arndt von Staa © LES/DI/PUC-Rio
Semana de 40 horas
• A taxa de erros humanos aumenta à medida que as pessoas cansam
• Pessoas têm direito ao lazer, à família e à evolução profissional
• Horas extras frequentes são indicadores de
– erros de planejamento
– compromissos irrealistas
– “embromação” por parte dos gerentes
• Horas extras não pagas são diluição do salário
– isto é ético?
• Entretanto, mesmo em XP podem ocorrer ocasiões em que se requer mais do que 40 horas por semana
– mas isso é eventual e não sistemático
44
Mar 2014 87Arndt von Staa © LES/DI/PUC-Rio
Semana de 40 horas
• Se tiver demais para fazer
– procure eliminar coisas a fazer
• identifique a natureza das coisas que você faz e o volume delas
• verifique se é realmente necessário fazê-las
– procure aumentar a produtividade através
• da redução do retrabalho inútil
• da redução do perfeccionismo
• do uso de ferramentas melhores– não esqueça que a mudança de tecnologia introduz delongas
– procure passar trabalho a diante
– procure reduzir a dimensão das coisas a fazer
– negocie uma revisão do plano da liberação
Mar 2014 88Arndt von Staa © LES/DI/PUC-Rio
Atividades de teste
• Todos os módulos devem possuir um módulo de teste de unidade
• Adição minha: todos os métodos e classes críticas devem possuir assertivas invariantes, de entrada e de saída executáveis
• corretude por construção é maior
• detectabilidade de erros é maior
• diagnosticabilidade é maior
• depurabilidade é maior
• tempo médio para corrigir é bem menor
Magalhães, J.A.P.; Staa, A.v.; Lucena, C.J.P.; “Evaluating the Recovery Oriented Approach through the
Systematic Development of Real Complex Applications”; Software Practice and Experience 39(3); New
York: Wiley Periodicals; 2009; pags 315-330
45
Mar 2014 89Arndt von Staa © LES/DI/PUC-Rio
Atividades de teste
• Assegurar que todas as unidades devem passar o teste de unidade antes integrar ou liberar
• Ao encontrar uma falha em artefato aceito
– redija um teste que replique a falha e acrescente-o ao módulo (ou script) de teste
– só depois disso faça a correção
– procure identificar por que o teste não havia sido escrito e, se necessário, aprimore os padrões
Mar 2014 90Arndt von Staa © LES/DI/PUC-Rio
Atividades de teste
• Realizar testes de aceitação com freqüência e divulgar o escore do teste
– o escore do teste de aceitação é o medidor de progresso, quanto mais perto de 100% aceito estiver mais próximo da conclusão do desenvolvimento se estará
46
Mar 2014 91Arndt von Staa © LES/DI/PUC-Rio
Problemas
• XP não propõe uma especificação completa a priori
• XP não propõe uma arquitetura detalhada a priori
– XP propõe a evolução em direção a um objetivo móvel
• XP não faz questão de linguagens de representação nem de representações elaboradas
– propõe que se façam esboços a serem jogados fora
– mais recentemente já se considera documentação gráfica ser uma coisa útil
• XP não propõe documentação técnica extensa
– propõe código simples e em conformidade com padrões
– o resultado do desenvolvimento é o código fonte
• historietas concluídas, diagramas, etc. é tudo jogado fora ao final do projeto
• e a evolução como é que fica?
Mar 2014 92Arndt von Staa © LES/DI/PUC-Rio
Problemas - manutenção
Arisholm, E.; Briand, L.C.; Hove, S.E.; Labiche, Y.; “The Impact of UML Documentation on Software
Maintenance: An Experimental Evaluation”; IEEE Transactions on Software Engineering 32(6); Los
Alamitos, CA: IEEE Computer Society; 2006; pags 365-381
47
Mar 2014 93Arndt von Staa © LES/DI/PUC-Rio
Problemas
• XP assume desenvolvedores proficientes
– quantos existem no mundo?
• XP aparentemente não se ajusta a equipes grandes
– o limite parece estar em torno de 10 pessoas (7 ± 2 ? )
– existem pessoas que dizem trabalhar com 20 pessoas e até mais…
• XP não se ajusta a desenvolvimento com diferentes equipes em paralelo
– integração continuada é um obstáculo
– volatilidade de especificações é outro, pois impede
• o planejamento de grandes componentes paralelos
• estabelecimento de interfaces estáveis
Mar 2014 94Arndt von Staa © LES/DI/PUC-Rio
Problemas
• XP não se ajusta bem à evolução de sistemas legados
– dificuldade ou proibição de reorganizar o código existente é um obstáculo
– ausência de padrões é um outro
– mas é excelente quando especificações são voláteis
O sistema que terminou de ser desenvolvido hoje é um sistema legado amanhã.
48
Mar 2014 95Arndt von Staa © LES/DI/PUC-Rio
Problemas
• XP não se ajusta a ambientes hostis ao trabalho em grupo
– organização do espaço físico inadequado para a programação aos pares
– equipes com indivíduos “problemáticos”
• XP é trabalho em comunidade
• XP não se ajusta a gerentes “absolutistas”
– as decisões são realizadas pelo grupo, e não impostas pela gerência
– coordenadores (trackers) e técnicos (coaches) podem contribuir muito
– gerentes devem ser facilitadores e não comandantes
• quantos desses tem no mundo?
SCRUM resumo
Mar 2014 Arndt von Staa © LES/DI/PUC-Rio 96
49
Mar 2014 97Arndt von Staa © LES/DI/PUC-Rio
Visão macroscópica
• 3 papéis:
– Scrum Master
– Product Owner
– Scrum Team (member)
• 3 encontros:
– Sprint Planning
– Daily Scrum
– Retrospective
• 3 artefatos de controle:
– Product Backlog
– Sprint Backlog
– Burndown Chart
Mar 2014 98Arndt von Staa © LES/DI/PUC-Rio
Scrum
• fase inicial
– planejamento rápido e abrangente
– é construída uma arquitetura inicial do sistema como um todo
• fase de desenvolvimento
– iterativo
• fase de fechamento da liberação (release)
– sucessivas liberações
50
Mar 2014 99Arndt von Staa © LES/DI/PUC-Rio
Scrum
• Backlog do Produto
– lista de todo o trabalho ainda a ser feito, inclui
• requisitos
• características
• funcionalidades
• falhas encontradas
• defeitos observados
• melhorias requeridas
• mudanças de tecnologia
– é definido com base no conhecimento corrente
• evolui à medida que o produto e ambiente evoluem
– os itens no backlog do produto são priorizados
• o item de maior prioridade será trabalhado primeiro
• o item de menor prioridade será trabalhado por último
Mar 2014 100Arndt von Staa © LES/DI/PUC-Rio
Scrum
• Estimativa de Esforço
– processo iterativo no qual cada item no backlog do produto é estimado
– estimativa é feita com a participação do time de desenvolvimento
51
Mar 2014 101Arndt von Staa © LES/DI/PUC-Rio
Scrum
• Sprint (corrida de curta distância, a toda velocidade)
– iterações são desenvolvidas por sprints
– um sprint deve levar menos de 30 dias
• 2 a 3 semanas?
– é escolhida uma parte do backlog capaz de chegar a uma versão executável (liberação) do produto e que poderá ser entregue ao usuário.
• para cada sprint, são alocados alguns itens do backlog, de acordo com a prioridade definida pelo project owner (representa o cliente)
• verifica-se se poderá ser realizado dentro do tempo do sprint.
• O resultado do sprint deve ser um incremento executável e usável do produto.
• Este resultado é demonstrado ao usuário ao final do sprint na reunião de revisão do sprint.
• o backlog do sprint é estável, – nada pode ser mudado ou adicionado até que o sprint termine
Mar 2014 102Arndt von Staa © LES/DI/PUC-Rio
Scrum
• Reunião diária
– realiza-se diariamente uma reunião rápida (aproximadamente 15 minutos, stand up meeting)
– cada membro da equipe deve responder às três perguntas a seguir:
• O que você fez desde a última reunião?
– as atividades/tarefas concluídas
– as em andamento
– as que faltam fazer
• Quais problemas e obstáculos você encontrou para realizar suas tarefas desde a última reunião?
– o gerente registra os problemas e obstáculos
– depois da reunião, procura resolvê-los.
• Em que você vai trabalhar até a próxima reunião?
52
Mar 2014 103Arndt von Staa © LES/DI/PUC-Rio
Scrum
• Esse tipo de reunião permite
– a realização de um acompanhamento mais apurado
– a melhoria dos planos de curto prazo
• Provê mecanismos de correção para reagir a mudanças e fazer adaptações a cada 24 horas
• A realização dessas reuniões
– leva a uma alta visibilidade
• do andamento do projeto
• da produtividade individual
– reduz tempo perdido
• causado por obstáculos
• causado pela espera por trabalho concluído por outros
– aumenta a socialização da equipe
Mar 2014 104Arndt von Staa © LES/DI/PUC-Rio
Scrum
• Reunião de revisão ao final do Sprint (retrospectiva)
– os resultados são apresentados aos clientes e usuários
– a reunião é informal
– demonstra-se o incremento produzido
– os participantes avaliam o resultado e decidem sobre as próximas atividades
• podem ser adicionados novos itens ao backlog de produto
• podem ser alterados itens do backlog
• podem ser revisadas as estimativas de dimensão
• podem ser revisadas as prioridades
• pode ser mudada a direção do projeto
53
Mar 2014 105Arndt von Staa © LES/DI/PUC-Rio
Kanban resumo
Pinto, T.D.; Scrum e Kanban: Análise de aplicabilidade; Trabalho da Disciplina INF2135 - Processos e
Ambientes de Engenharia de Software; Departamento de Informática, PUC-Rio, 2010
Problema com Scrum: possível sobrecarga
A FAZER FAZENDO PRONTO
João
Maria
João
Maria
Douglas
DouglasMaria
Pedro
Pedro
João
Douglas
Mar 2014 Arndt von Staa © LES/DI/PUC-Rio 106
54
Mar 2014 107Arndt von Staa © LES/DI/PUC-Rio
Kanban
• Particiona o quadro em estados
– o conjunto de estados corresponde a um workflow
– estabelece um limite de tarefas em execução por estado
– o limite depende do tamanho da equipe, ex. 50% a 66% além do número de pessoas da equipe
• Restringe o número de tarefas individuais
– evita prejudicar o desempenho individual, ex. no máximo duas.
• Impõe um sistema puxado (Pull System)
– a saída de uma tarefa permite puxar a entrada de outra, respeitando o limite do estado
• Permite particionar estados
• Se um estado posterior estiver lotado, o anterior poderá ficar sem poder trabalhar. Isso obriga as pessoas a ajudarem a realizar as tarefas do estado “engarrafado”
Kanban: estado com limite de tarefas
A FAZER FAZENDO (máx. 6) PRONTO
João Maria
João
Maria
Douglas
DouglasMaria
Pedro
Pedro
Pedro
Mar 2014 Arndt von Staa © LES/DI/PUC-Rio 108
55
Mar 2014 109Arndt von Staa © LES/DI/PUC-Rio
Kanban: late binding
• Uma prática recomendada é a ligação tardia de tarefas
– espera-se até o último minuto para associar uma tarefa a a uma pessoa
– prática comum aos "processos enxutos" (lean development)
• Não impedir membros não especializados de pegar uma tarefa
– possibilita o aprendizado “on the job”
• Compatível com o sistema puxado
110
Kanban
A FAZER FAZENDO (máx. 6) PRONTO
João
Maria
Douglas
DouglasMaria
Pedro
Pedro
Nome do membroda equipe não ficaassociado previamente
Mar 2014 Arndt von Staa © LES/DI/PUC-Rio
56
Mar 2014 111Arndt von Staa © LES/DI/PUC-Rio
Kanban
• Pode-se usar mais do que 3 estados
• Permite estabelecer prioridades dentro de um sprint
A FAZER FAZENDO (6) PRONTO
João
Maria
Douglas
Douglas
Maria
PROXIMOS (2)
Pedro
Kanban: múltiplos projetos, detalhe de estado
A FAZER ESPEC. PRONTO
João
MariaDouglas
Maria
PROXIMOS
PedroDouglas
Pedro
EXEC. (4)E.P.
João
(2)
Ana LucasAna
SheilaLucas
Joana
ProjetoA
ProjetoB
ProjetoC
Ana
PedroAna
SilviaDouglas
Joana
Joana
Maria
Mar 2014 Arndt von Staa © LES/DI/PUC-Rio 112
57
Mar 2014 113Arndt von Staa © LES/DI/PUC-Rio
Kanban: alguns aspectos
• Não se está amarrado a um time-box
• Podem ser adicionadas tarefas
– comum ao realizar manutenção de software
• O desenvolvimento de um construto termina quando os seus componentes estiverem disponíveis e aceitos
– facilita a especificação de construtos satisfazendo propriedades funcionais ao invés de forçá-lo a caber em um time-box
• . . .
Mar 2014 114Arndt von Staa © LES/DI/PUC-Rio
Kanban vs. Scrum
Similarities
• Both are Lean and Agile
• Both use pull scheduling
• Both limit WIP – work in progress
• Both use transparency to drive process improvement
• Both focus on delivering releasable software early and often
• Both are based on self-organizing teams
• Both require breaking the work into pieces
– In both, release plan is continuously optimized based on empirical data (velocity / lead time)
KNIBERG, H.; SHARIN, M. Kanban and Scrum: Making the most of both. C4Media, 2010. 122 p.
Disponível (também) em: <http://www.infoq.com/minibooks/kanban-scrum-minibook>. Acesso em: 26 abr.
20110.
58
Kanban vs. Scrum
Scrum Kanban
Timeboxed iterations prescribed. Timeboxed iterations optional. Can have separate cadences for planning, release, and process improvement. Can be event-driven instead of timeboxed.
Team commits to a specific amount of work for this iteration.
Commitment optional.
Uses Velocity as default metric for planning and process improvement.
Uses Lead time as default metric for planning and process improvement.
Cross-functional teams prescribed. Cross-functional teams optional. Specialist teams allowed.
Items must be broken down so they can be completed within 1 sprint.
No particular item size is prescribed.
Burndown chart prescribed. No particular type of diagram is prescribed
Mar 2014 Arndt von Staa © LES/DI/PUC-Rio 115
Kanban vs. Scrum
Scrum Kanban
WIP limited indirectly (per sprint) WIP limited directly (per workflow state)
Estimation prescribed Estimation optional
Cannot add items to ongoing iteration. Can add new items whenever capacity is available
A sprint backlog is owned by one specific team
A kanban board may be shared by multiple teams or individuals
Prescribes 3 roles (PO/SM/Team) Doesn’t prescribe any roles
A Scrum board is reset between each sprint
A kanban board is persistent
Prescribes a prioritized product backlog Prioritization is optional
KNIBERG, H.; SHARIN, M. Kanban and Scrum: Making the most of both. C4Media, 2010. 122 p.
Disponível (também) em: <http://www.infoq.com/minibooks/kanban-scrum-minibook>. Acesso em: 26 abr.
20110.
Mar 2014 Arndt von Staa © LES/DI/PUC-Rio 116
59
Mar 2014 117Arndt von Staa © LES/DI/PUC-Rio
Bibliografia
• Anda, B.C.D.; Hansen, K.; Gullesen, I.; Thorsen, H.K.; “Experiences from Using a UML-based Development Method in a Large Safety-Critical Project”; Empirical Software Engineering 11(4); Dordrecht: Kluwer; 2006; pags 555-581
• Arisholm, E.; Briand, L.C.; Hove, S.E.; Labiche, Y.; “The Impact of UML Documentation on Software Maintenance: An Experimental Evaluation”; IEEE
Transactions on Software Engineering 32(6); Los Alamitos, CA: IEEE Computer Society; 2006; pags 365-381
• Beck, K.; Extreme Programming Explained; Addison Wesley; 2000
• Beck, K.; Fowler, M.; Planning Extreme Programming; Addison Wesley 2001
• Beedle, M. et al. SCRUM: An Extension Pattern Language for
Hyperproductive Software Development, Pattern Languages of Program Design 4, N. Harrison, B. Foote, and H. Rohnert (eds.), Addison-Wesley, Reading, Mass., 2000, pp. 637-651.
• Caristi, J.; Extreme Programming: Theory & Practices; Valparaiso University; notas de aula; James.Caristi@valpo.edu; buscado maio/2004
Mar 2014 118Arndt von Staa © LES/DI/PUC-Rio
Bibliografia
• Cockburn, A.; Agile Software Development; Addison-Wesley; 2002
• Highsmith, J.; Agile Software Development Ecosystems; Addison-Wesley; 2002
• Hunt, A. ; Thomas, D.; The Pragmatic Programmer; Addison Wesley; New York; 2001
• IEEE Software 18(6) novembro 2001, contém vários artigos sobre XP
• IEEE-Software 20(3) maio 2003
• Jeffries, R.; Anderson, A.; Hendrickson, C.; Extreme Programming Installed; Addison Wesley; 2001
• Ken Schwaber's SCRUM Web Page, http://www.controlchaos.com, November 2004.
• KNIBERG, H.; SHARIN, M. Kanban and Scrum: Making the most of both. C4Media, 2010. 122 p. Disponível (também) em: <http://www.infoq.com/minibooks/kanban-scrum-minibook>. Acesso em: 07 abr. 2010.
60
Mar 2014 119Arndt von Staa © LES/DI/PUC-Rio
Bibliografia
• Paulk, M.C.; “Extreme Programming from a CMM Perspective”; IEEE
Software 18(6) pp 19–26, 2001.
• Rising, L.; Janoff, N.; “The Scrum Software Development Process for Small Teams”. IEEE Software, 17(4), 2000, pp. 26-32.
• 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; pags 95-100
• Wake, W.C.; Extreme Programming Explored; url: http://users.vnet.net/wwake/xp/explored/XP-Explored.pdf
• Wells, D.; Extreme Programming: A Gentle Introduction; 2006; Buscado em: 06/fevereiro/2008; URL: http://www.extremeprogramming.org/index.html