Especificação - PUC-Rio | Homeinf2135/docs/INF2135-Modulo06... · • princípio LEAN (processo enxuto): lazy evaluation –somente desenvolver alguma coisa quando necessário –

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


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."


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


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


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


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


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


6


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;

[email protected]


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


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


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


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


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


• 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


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


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


Poppendiek, M.; Poppendieck, T.; Lean software development: Na agile toolkit; Addison-Wesley; 2003


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


• 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


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.


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]



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


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


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


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


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


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?


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



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


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)


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


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?


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


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?


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


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


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


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


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


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”


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


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


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



• 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



• 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



• 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


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


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)?


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


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


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


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


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


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


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



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


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



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



• 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


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



• 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



• 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


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)


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


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)

• . . .


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


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


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


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


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


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


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


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”

– . . .


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



• 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



• 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


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


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


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


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


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


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


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


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


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


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


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?


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


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


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


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


49


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


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


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


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


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


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


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


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


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


54


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


55


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


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


57


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

• . . .


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


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.


59


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; [email protected]; buscado maio/2004


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


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

Documents

Especificação - PUC-Rio | Homeinf2135/docs/INF2135-Modulo06... · • princípio LEAN (processo enxuto): lazy evaluation –somente desenvolver alguma coisa quando necessário –