Gestão de Projecto - Autenticação · uma decisão Intuitivos baseiam as suas decisões nas emoções ... Planificação do projecto Monitorização do projecto Gestão de Riscos

Gestão de Projecto

António Rito [email protected]

Sumário

� Caracterização� Objectivos� Problemas� Qualidades

� Factores Não-Técnicos

Gestão de Projecto 2

� Factores Não-Técnicos� Técnicas� Casos Notáveis� Exemplo � Conclusões

Objectivos

� A gestão de projecto é responsável por assegurar que o desenvolvimento de software está de acordo com os objectivos, políticas e requisitos da organizaçãoA gestão de projecto deve


� A gestão de projecto deve� Planear o projecto� Estimar o esforço� Monitorar o projecto� Gerir os riscos

Problemas

� O desenvolvimento de software apresenta, com bastante frequência, os seguintes problemas:� Os produtos são entregues com atraso relativamente aos prazos estabelecidos

� O desenvolvimento tem custos finais


� O desenvolvimento tem custos finais muito superiores às estimativas iniciais

� Os produtos entregues não satisfazem os requisitos dos utilizadores

Problema

� Estes problemas, que também acontecem nas outras engenharias, são ainda mais difíceis de gerir devido aos aspectos distintivos do software:� O produto é intangívelNão existe um processo “industrial”


� Não existe um processo “industrial” normalizado

� Não existe experiência suficiente que permita reduzir a incerteza – novos problemas, novas tecnologias, ...

Qualidades

� A boa gestão de projecto deve planear e monitorar o projecto de modo a garantir que este é levado a cabo de acordo com determinados níveis de qualidade, respeitando os prazos e o orçamento


prazos e o orçamento� Este tópico pode ser entendido como a avaliação e validação do processo de desenvolvimento

Factores Não-Técnicos

� Gestão de Equipas de Desenvolvimento� Estilos de trabalho� Papéis da equipa� Características da equipa


� Estrutura organizacional da equipa� Reuniões

Estilos de Trabalho� Os elementos da equipa têm diferentes estilos de trabalho. É da responsabilidade de todos os elementos tirarem partido das características próprias de cada elemento para aumentar a produtividade:� Extrovertidos comunicam as suas ideias de imediato


imediato� Introvertidos fazem perguntas antes de tomar uma decisão

� Intuitivos baseiam as suas decisões nas emoções

� Racionais baseiam-se mais nos factos

Estilos de TrabalhoINTUITIVO

EX

TR

OV

ER

T

INTUITIVOINTROVERTIDO:Faz perguntasReconhece sentimentos

INTUITIVOEXTROVERTIDO:Expressa opiniõesReconhece sentimentos

INT

RO

VE

RT


RACIONAL

EX

TR

OV

ER

TID

O

RACIONALINTROVERTIDO:Faz perguntasDecide logicamente

RACIONALEXTROVERTIDO:Expressa opiniõesDecide logicamente

TR

OV

ER

TID

O

Papéis da Equipa� Existem diferentes papéis na equipa que podem ser desempenhados pela mesma ou por diferentes pessoas. Estes papéis estão ligados às actividades:� Análise de requisitos� Desenho de sistema� Desenho de programa


� Desenho de programa� Implementação� Testes� Treino� Manutenção � Verificação de qualidade

Características da Equipa� Motivação no trabalho� Experiência no domínio das aplicações semelhantes

� Experiência com tecnologia, ferramentas e linguagens semelhantes


semelhantes� Capacidade de partilhar responsabilidades

� Capacidade de gestão� Capacidade de comunicação (ver figura)

Comunicação na Equipa


“Adicionar recursos humanos a um projecto atrasado ainda o atrasa mais” – Brooks´s Law

Organização do Projecto

� A escolha de uma estrutura de trabalho depende de diversos factores:� A experiência e o estilo de trabalho dos membros da equipa

� O número de pessoas na equipa


� O número de pessoas na equipa� O tipo do modelo do processo de desenvolvimento

Equipa Hierárquica

Gestor/ProgramadorChefe

SecretárioProgramador


ProgramadorProgramadorProgramador

Equipa Plana

� Não existe UM líder do grupo, existem líderes

� Existe uma identidade de equipa� Existe respeito mútuo entre os elementos da equipa


elementos da equipa� O código é partilhado em vez de pertencer a um programador

Diferentes Estruturas� Hierárquica reduz comunicação

� Muito estáveis� Repetitivos� Grande dimensão

� Plana é mais democrática e aumenta a comunicação� Aumenta a qualidade do produto e produtividade


� Aumenta a qualidade do produto e produtividade� Alto grau de indefinição� Problemas difíceis - novas técnicas e tecnologias� Projectos pequenos

� Variações são possíveis sempre que adequadas, mesmo durante o ciclo de vida do projecto

Outras Estruturas� Separar a gestão de projecto da liderança técnica pois é difícil encontrar alguém que possui ambas as características

� Subdividir a equipa em diversas equipas planas que respondem a um


equipas planas que respondem a um líder técnico o qual responde ao líder de projecto

� A anterior com participação simultânea do mesmo elemento em diversas equipas

Reuniões� As reuniões podem levar muito tempo sem obter os resultados desejados, assim deve-se assegurar que:� o objectivo seja claro� os participantes estejam preparados� os participantes não faltem ou cheguem atrasados


atrasados� a discussão não se afaste do objectivo� se evitem os argumentos, a não participação, ou o domínio da discussão

� as decisões sejam aplicadas após a reunião

Técnicas

� Planificação do projecto� Monitorização do projecto� Gestão de Riscos� Estimação do Esforço� Gestão de Configurações


� Gestão de Configurações

Plano do Projecto� Para comunicar com os clientes deve-se

fazer um plano do projecto que identifica as necessidades do cliente e indica como se espera que sejam satisfeitas.

� Plano do projecto deve conter os seguintes itens:1. Âmbito do projecto – identifica a fronteira


1. Âmbito do projecto – identifica a fronteira2. Calendarização do projecto – inclui uma

estrutura de divisão do trabalho, deliverables, etc

3. Organização da equipa – a lista das pessoas da equipa e indicação de qual vai ser o seu envolvimento

4. Descrição técnica dos sistemas propostos –hardware e software

5. Standards, técnicas e ferramentas a usar6. Plano de qualidade – indica como os testes,

inspecções e verificações vão ajudar a avaliar a qualidade

7. Plano de gestão de configurações – indica como preservar a rastreabilidade

Plano do Projecto


como preservar a rastreabilidade8. Plano de documentação – indica quais os

documentos e quem é responsável por os gerar

9. Plano de gestão de dados – indica como os dados são recolhidos, guardados e manipulados

Plano do Projecto10. Plano de gestão de recursos – indica como os

recursos vão ser usados11. Plano de testes – indica como se gera os dados

para os testes, como se testa cada módulo, como se testa a integração de módulos...

12. Plano de treino – indica como se pretende treinar os utilizadores

13. Plano de segurança – indica como os dados são


13. Plano de segurança – indica como os dados são protegidos...

14. Plano de gestão do risco – registar as decisões sobre a redução do risco

15. Plano de manutenção – indica quem tem as responsabilidades de alterar o código, alterar a documentação...

Calendarização e Deliverables� A calendarização do projecto descreve:

� o ciclo de desenvolvimento de um particular projecto enumerando as etapas do projecto e dividindo-as em actividades

� as dependências entre as actividades� a estimativa de duração de cada actividade

� É necessário definir os deliverables a


� É necessário definir os deliverables a entregar aos clientes durante o processo:� documentos� demonstrações

� Os deliverables estão por vezes associados a marcos do desenvolvimento

Divisão do Trabalho� Uma estrutura de divisão do trabalho permite representar o projecto como um conjunto de actividades discretas estando relacionadas através de:� percursor, que estabelece as condições necessárias ao início da tarefaduração, tempo necessário à execução da tarefa


� duração, tempo necessário à execução da tarefa� data término, em que a actividade deve estar terminada

� Um grafo de actividades mostra as dependências

Monitorização do Projecto

� Monitorar o projecto é uma actividade contínua que segue a execução do projecto comparando o progresso planeado com o progresso de facto


Estimar o Término� Para estimar o término anota-se o grafo de actividades com as durações das actividades

� Para descobrir o tempo mínimo para o término do projecto e quais as actividades mais críticas utiliza-se o método do caminho crítico. Este método considera para cada actividade:� tempo real estimado


� tempo disponível� tempo livre = tempo disponível - tempo real

estimado� tempo livre = tempo de início tarde – tempo de início

cedo

O caminho crítico é aquele em que o tempo livre em todos os nós é zero

Método do Caminho Crítico� Variações no caminho crítico são as que maiores consequências têm no projecto

� Ciclos no grafo, repetição de actividades devido a situações de insucesso, alteram qual é o caminho crítico pelo que as suas implicações são mais difíceis de avaliar


implicações são mais difíceis de avaliar� Gráficos de barras são usados para ilustrar a aplicação do método do caminho crítico e visualizar a afectação dos recursos pelas actividades

GanttID Task Name Duration Start Finish

1 Aula prática de EP 147,25 days Wed 12-04-00 Wed 31-05-00

10 1ª Parte do Projecto 258,38 days Wed 12-04-00 Fri 07-07-00

11 1º Conjunto de tarefas 8,13 days Wed 12-04-00 Sat 15-04-00

12 Aprender Microsoft Project 1 hr Wed 12-04-00 Wed 12-04-00

13 Iniciação ao Java 3 hrs Wed 12-04-00 Fri 14-04-00

14 Ver "Levantamento de requisitos" 4 hrs Wed 12-04-00 Sat 15-04-00

15 Procurar "use cases" na Net 8 hrs Wed 12-04-00 Fri 14-04-00

16 Levantamento dos ambientes de desenvolvimento em Java5 hrs Wed 12-04-00 Wed 12-04-00

17 2º Conjunto de Tarefas 8,13 days Wed 26-04-00 Sat 29-04-00

18 Fazer Modelo do Domínio 0,88 days Wed 26-04-00 Sat 29-04-00

19 1ª Iteração do Volere 0,56 days Wed 26-04-00 Thu 27-04-00

Hugo

Bruno

F S S M T W10 Apr '00


19 1ª Iteração do Volere 0,56 days Wed 26-04-00 Thu 27-04-00

20 3º Conjunto de Tarefas 6,25 days Wed 03-05-00 Fri 05-05-00

21 Modelo do Domínio e Modelo de Análise 0,63 days Wed 03-05-00 Fri 05-05-00

22 Continuação do Volere 0,63 days Wed 03-05-00 Thu 04-05-00


24 Modelo do Domínio e Modelo de Análise 0,63 days Wed 10-05-00 Fri 12-05-00

25 Modelação de alguns casos de utilização 0,25 days Wed 10-05-00 Wed 10-05-00

26 Continuação do Volere 0,75 days Wed 10-05-00 Fri 12-05-00

27 Fazer Protótipo com Tecnologias Java 1,25 days Wed 10-05-00 Sat 13-05-00


29 Continuação do Volere 0,5 days Wed 17-05-00 Thu 18-05-00

30 Diagramas de Colaboração e Modelo de Análise 4 days Wed 17-05-00 Sat 20-05-00

31 Finalização do Protótipo com Tecnologias Java 1,88 days Wed 17-05-00 Sat 20-05-00

GanttID

1

10

11

12

13

14

15

16

17

18

19

20

Hugo

Tiago

Rui

Paulo;Alex;Nuno;Luís;Pedro;Serafim;Hugo

Bruno

Luís;Rui;Nuno;Serafim

Pedro;Alex;Tiago;Paulo;Bruno;Hugo

T W T F S S M T W T F S S M T W T F S S M T W T F S S M T W T F S S M T W T F S S M T W T F S S M T W10 Apr '00 17 Apr '00 24 Apr '00 01 May '00 08 May '00 15 May '00 22 May '00 29 May '00


20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

Luís;Nuno;Rui;Serafim

Pedro;Alex;Tiago;Paulo;Hugo;Bruno



Paulo;Bruno;Hugo

Pedro;Alex;Tiago

Bruno;Hugo;Paulo

Serafim;Bruno;Hugo;Paulo;Nuno;Rui;Luís

Pedro;Tiago;Alex

Hugo;Bruno;Paulo

Gestão do Risco� Um risco é um acontecimento não desejado que tem consequências negativas. Os riscos distinguem-se por três aspectos:� Impacto do risco – perda associada ao acontecimento, tempo, qualidade, dinheiro, controle. Por exemplo uma alteração profunda de requisitos leva a uma perda de tempo e dinheiro se o desenho não for suficientemente


dinheiro se o desenho não for suficientemente flexível

� Probabilidade do risco – a frequência do acontecimento, pelo que a probabilidade de ocorrência do acontecimento deve ser estimada

� Controlo do risco – capacidade de controlar a ocorrência do acontecimento, o que pode ser feito para minimizar ou evitar o impacto do acontecimento

Actividades de Gestão do Risco� A gestão do risco envolve vários passos:1. Avaliar o risco1. Identificar o risco2. Analisar o risco3. Atribuir prioridades ao risco


3. Atribuir prioridades ao risco

2. Controlar o risco1. Reduzir o risco2. Plano de gestão do risco3. Resolução do risco

Actividades de Gestão do Risco� Identificar o Risco

� Se o sistema for idêntico a um sistema desenvolvido anteriormente e se existir uma lista de verificação pode-se usar essa lista para verificar se o novo projecto apresenta alguns dos riscos enumerados


enumerados� Ver os riscos associados a cada uma das actividades do processo de desenvolvimento

� Analisar os pressupostos e decisões sobre como o projecto vai ser executado, quem o vai executar e com que recursos

Actividades de Gestão do Risco� Analisar o Risco

� Saber quando, como e onde podem ocorrer os riscos

� Atribuir Prioridades ao Risco� Toma-se em consideração a probabilidade de o risco acontecer e o


probabilidade de o risco acontecer e o impacto da sua ocorrência

Actividades de Gestão do Risco� Redução do Risco

� Evitar o risco, alterando os requisitos� Transferir o risco, atribuindo o risco a outros sistemas ou fazendo um seguro

� Assumir o risco e controlar o risco com os recursos do projecto por exemplo protótipos

� Verificar se o custo associado à redução do risco compensa, (risco antes redução – risco após


� Verificar se o custo associado à redução do risco compensa, (risco antes redução – risco após redução) / custo da redução

� Plano de Gestão do Risco� Registar as decisões sobre a redução do risco

� Resolução do Risco� Monitorizar o projecto de acordo com o plano

Medida e Estimação� Uma medida é uma aplicação que tem como domínio

de um conjunto de entidades e atributos do mundo real e codomínio uma representação ou modelo do mundo matemático

� Existem dois tipos de sistemas:� Sistemas de medida são usados para avaliar uma

entidade caracterizando numericamente um dos seus atributos


� Sistemas de estimação são usados para predizer acerca de um atributo de uma entidade no futuro

� Uma medida é válida se caracteriza com exactidão o atributo que mede

� Um sistema de estimação é válido se prediz com exactidão

Validar os Sistemas MeE� Para validar um sistema de medida e estimação compara-se os resultados com dados conhecidos do ambiente

� Para validar um sistema de medida é necessário demonstrar que a relação entre a medida e a qualidade se mantém� se P1 tem mais qualidade que P2


� se P1 tem mais qualidade que P2 então m(P1) > m(P2)

� m(P1,P2) = m(P1) + m(P2)

A validação assegura que as medidas foram bem definidas e são coerentes com o comportamento real

Estimação

� É necessário estimar para responder às seguintes perguntas:� Que quantidade de esforço é necessária para terminar uma actividade?

� Quanto tempo é necessário para terminar uma actividade?


terminar uma actividade?� Qual é o custo total de uma actividade?

Estimação do Esforço� Que esforço, pessoa/mês, é necessário para terminar o projecto ?� Experiência dos peritos� Métodos algorítmicos� Métodos automáticos

� A estimação deve ser feita o mais


� A estimação deve ser feita o mais cedo possível e repetidamente durante todo o projecto

� Quanto mais se avança no projecto mais correctas são as estimativas e menos necessárias

Precisão das Estimativas

INT

ER

VA

LO D

E V

AR

IAÇ

ÃO

4x

x


INT

ER

VA

LO D

E V

AR

IAÇ

ÃO

0.25xViabilidade Levantamento

RequisitosDesenho

ArquitecturaDesenhoDetalhado

DesenvolvimentoTeste

Entrega

Causas da Imprecisão� Pedidos de alteração frequente por parte dos utilizadores

� Tarefas ignoradas� Utilizadores não sabem bem quais são os requisitos

� Análise insuficiente quando se desenvolve


� Análise insuficiente quando se desenvolve uma estimativa

� Falta de coordenação entre os diversos elementos da equipa

� Falta de um método adequado para fazer a estimação

Influenciam a Estimação� Factores que influenciam a estimação

� Complexidade do sistema� Integração com sistemas existentes� Tamanho do sistema em termos de funções� Aptidão dos membros do projecto� Experiência dos membros do projecto com o

domínio da aplicação, as linguagens de programação, o hardware


programação, o hardware� Antecipação e frequência das alterações aos

requisitos de utilizador� Dimensão da equipa� Extensão das regras de programação e

documentação� Disponibilidade de ferramentas como os

geradores de aplicações

Duas Abordagens

� Top-Down – a estimação é feita a partir do nível do sistema e tendo em consideração a funcionalidade total� Subestima esforço de não-funcionalidade

� Bottom-Up – a estimação é feita, após uma decomposição do sistema


após uma decomposição do sistema em componentes, adicionando a estimação relativa ao desenvolvimento de cada componente� Subestima custos de integração

Experiência dos Peritos� Baseada na experiência� Baseada na semelhança� Pode acontecer que não sejam evidentes a diferenças entre dois projectos e mesmo que as diferenças sejam identificadas é difícil avaliar do seu impacto no custo, e.g.,


difícil avaliar do seu impacto no custo, e.g., a diferença de produtividade entre dois programadores pode ser de 10X

� Pode-se normalizar as estimativas individuais de vários peritos, pessimista, optimista e média

Métodos Algorítmicos� Existem modelos que expressam a relação entre o esforço e os factores que o influenciam

� Estes modelos são representados por equações em que o esforço é a variável dependente de um conjunto de variáveis independentes que representam os factores


independentes que representam os factores que influenciam o esforço

E = (a + bSc)m(X)a, b e c são constantes, S é a dimensão estimada do sistema, X é um vector de factores de custo e m um multiplicador de ajuste. Estes valores são calculados usando dados empíricos de projectos passados

COnstructive COst MOdel� Dá ênfase à estimação da dimensão e considera diferentes estimações para três etapas do projecto:1. Pontos de objecto – são estimados no início do projecto quando não se tem uma noção da dimensão do produto final


2. Pontos de função – são estimados em função do resultado do levantamento de requisitos

3. Linhas de código – são estimadas quando já foi desenhada a arquitectura do sistema

Pontos de Objecto

� Durante a fase inicial constróem-se protótipos para avaliar e resolver o risco associado a interfaces utilizador, interacção de sistemas, maturidade tecnológica...Contabiliza indicadores de alto nível:


� Contabiliza indicadores de alto nível:� Ecrãs� Relatórios� Componentes 3GL

Pontos de Função� Durante a segunda fase foi decidido avançar com o projecto e está-se a explorar diferentes arquitecturas da solução

� Contabiliza a dimensão em função dos requisitos:


dos requisitos:� Entradas� Saídas� Interrogações� Ficheiros� Interfaces

Linhas de Código

� Durante a terceira fase a arquitectura do sistema já está definida e sabe-se quais os seus principais módulos

� Contabiliza a dimensão de cada módulo em termos da estimativa do número de linhas de código


número de linhas de código

COCOMO 2.0

E = bScm(X)� S (Size) representa o tamanho estimado que pode ser calculado em ponto de objectos, pontos de função ou linhas de código


� S é ajustado por b, c e X. Os factores de ajuste são apresentados a seguir

Factores de Ajuste� Factores de escala

� Experiência no domínio da aplicação� Conhecimento da arquitectura� Resolução do risco� Coesão da equipa � Maturidade do processo� ...


� ...

� Factores do produto� Fiabilidade do sistema� Complexidade � Reutilização� Documentação� ...

Factores de Ajuste� Factores da plataforma

� Estabilidade do software e hardware usados no desenvolvimento

� ...

� Factores da equipa� Aptidão dos membros� Continuidade da equipa


� Continuidade da equipa� ...

� Factores do projecto� Utilização de ferramentas � Desenvolvimento distribuído � ...

Calibração do Modelo

� Os modelos devem ser calibrados para reflectir circunstâncias específicas de modo a� reduzir a complexidade e a diversidade do modelo

� reduzir a avaliação subjectiva inerente


� reduzir a avaliação subjectiva inerente aos factores de ajuste

Duração do Projecto� A duração do projecto pode ser estimada a partir da dimensão

� A duração pode também ser calculada a partir do esforço mas o número de engenheiros da equipa não tem uma influência determinante


influência determinante� Equipas maiores têm uma produtividade menor por elemento

� Os projectos podem ser mal sucedidos se não planearem uma duração suficiente

Versões de Software

� Os produtos de software podem ter diversas versões devido ao desenvolvimento incremental e iterativo ou porque se deseja ter variações de funcionalidade e de não funcionalidade


funcionalidade� As versões de software devem ser mantidas por diferentes razões� A nova versão tem erros� Existem utilizadores que continuam a usar versões antigas

Gestão de Configurações

� Tem dois objectivos distintos� Suporte à gestão� Suporte ao desenvolvimento


Gestão de Configurações� Trata os seguintes aspectos

� Identificação de configurações – com que parte do software se está a trabalhar

� Controlo de configurações – controlo da versão de um produto e das alterações a ele feitasAuditoria de componentes – registo e


� Auditoria de componentes – registo e relatório do estado dos componentes de um produto

� Revisão de produto – validação da completude de um produto e sua manutenção consistente com os restantes componentes

Gestão de Configurações� Gestão de integrações – gestão dos processos e ferramentas que a equipa usa para criar uma versão do produto

� Gestão de processo – assegurar que o processo de desenvolvimento é seguido pela equipa


pela equipa� Trabalho de grupo – controlo das interacções entre as pessoas que estão a desenvolver o software

Espaço de Trabalho

� Espaço de Trabalho – é o espaço onde o programador tem todos os artefactos que necessita para fazer o seu trabalho� Código fonte do produtoCódigo fonte de testes


� Código fonte de testes� Bibliotecas� Scripts de compilação� ...

Sequência de Código

� Sequência de Código – é a progressão, ao longo do tempo, de um conjunto de ficheiros fonte e outros artefactos que formam um componenteVersão de Artefacto – cada revisão de


� Versão de Artefacto – cada revisão de um ficheiro fonte ou de um artefacto ao longo de uma sequência de código

Configuração

� Configuração – é uma fotografia da sequência de código que contem uma versão de cada componente da sequência de código

� Versão de Sequência de Código – é uma configuração a que é dado um


uma configuração a que é dado um nome distinto através de uma etiqueta

Ramo

� Ramo – é uma sequência de código que se separa da sequência principal com um objectivo particular� Divisão de trabalho� Nova entrega do produto...


� ...

� Integração – é o processo em que um ramo é reincorporado na sequência de código principal

Diagrama


Estabilidade vs Progresso

� Qualidade é essencial e seguem-se os procedimentos, uma entrega de cada vez, reduzindo a produtividade e possivelmente deixando os programadores frustradosA rapidez de desenvolvimento é


� A rapidez de desenvolvimento é essencial e a qualidade e gestão de versões fica para depois

Princípios

� Utilizar controlo de versões � Fazer integrações periódicas –permite ter uma ideia do estado actual

� Permitir trabalho autónomo – cada


� Permitir trabalho autónomo – cada programador pode necessitar de trabalhar em pontos diferentes da sequência de código

� Utilizar ferramentas

Arquitectura

� A arquitectura influência o controlo de versões pois define� O que é o produto� As relações entre os componentes� A estrutura de directórios do código fonte


fonte

� e vice-versa ....

Organização

� A organização influência o controlo de versões pois estabelece� Distância física entre os membros da equipa

� Cultura e dinâmica da equipa� Estrutura organizacional da equipa


� Estrutura organizacional da equipa

� e vice-versa ....

Casos Notáveis� eXtreme Programming

� Kent Beck� Extreme Programming Explained� 2000

� Padrões Organizacionais para uma Equipa Produtiva� Paul Taylor


� Paul Taylor � Capable, Productive, and Satisfied: Some Organizational Patterns for Protecting Productive People

� In Harrison2000. Capítulo 27� http://jerry.cs.uiuc.edu/~plop/plop98/final_submissions/P5

4.pdf

Casos Notáveis

� Padrões de Gestão de Configurações de Software� Stephen Berczuk e Brad Appleton� Software Configuration Management Paterns

� 2003


� 2003

Metodologias Pesadas� Muito frequentemente o desenvolvimento de software é caótico e caracterizado pela frase “code and fix”

� As metodologias, e os processos que as constituem, têm surgido como


as constituem, têm surgido como forma de resolver este problema

� A crítica mais frequente às metodologias é que são muito burocráticas – por isso referidas como metodologias pesadas

Metodologias Ágeis� As metodologias ágeis são menos baseadas na documentação e mais centradas no código

� A ausência de documentação revela duas diferenças mais profundas:As metodologias ágeis são mais


� As metodologias ágeis são mais ajustáveis do que “proféticas”

� As metodologias ágeis dão mais ênfase às pessoas do que ao processo

eXtreme Programming� Os riscos mais frequentes do processo de desenvolvimento são tratados da seguinte forma:� Atrasos na calendarização – diversas pequenas versões, no máximo com uns poucos meses de duração cada


� Cancelar o projecto – pedir ao cliente para escolher a versão mais pequena que faz mais sentido do ponto de vista do negócio

eXtreme Programming� Sistema degrada-se – construir e manter um conjunto de testes que são executados cada vez que o código é alterado

� Quantidade de defeitos – testar do ponto de vista do programador, função-a-


de vista do programador, função-a-função, e do utilizador, funcionalidade-a-funcionalidade

� Satisfação do negócio – o cliente é parte integrante da equipa de desenvolvimento

eXtreme Programming� Alteração do negócio – as versões curtas permitem que existam menos alterações durante o desenvolvimento de cada versão, e o cliente é convidado a substituir funcionalidade ainda não implementada


� Falsa funcionalidade – apenas as tarefas de grande prioridade devem ser executadas

eXtreme Programming

� Mudança de staff – pedir aos programadores para aceitarem a responsabilidade por estimar e completarem o seu trabalho, e encorajar o contacto entre os elementos da equipa


elementos da equipa

Valores� Os valores definem as qualidades que a equipa de desenvolvimento deve ter em comum� Comunicação – a comunicação deve existir e ter qualidade

� Simplicidade – é melhor fazer uma solução simples hoje e ter de a alterar mais tarde do


simples hoje e ter de a alterar mais tarde do que fazer uma solução complicada que poderá nunca vir a ser usada

� Retroalimentação – a retroalimentação baseada em testes deve substituir o optimismo

� Coragem – deve haver coragem para aceitar a mudança

Princípios� A metodologia enumera um conjunto de princípios que concretizam os valores� Retroalimentação rápida – o tempo entre um estímulo e a sua resposta é crítico para a aprendizagem

� Assumir a simplicidade – o tempo que se poupa


� Assumir a simplicidade – o tempo que se poupa em 98% dos problemas que são de facto simples compensa os restantes 2%

� Alteração incremental – as alterações, de código, desenho, pessoas,... não devem ser de grande dimensão de cada vez, de modo a serem tratáveis

� ....

Actividades� Codificar – codificar é a actividade principal

� Testar – as funcionalidades que não podem ser demonstradas por testes não existem – “test infected ”

� Ouvir – ouvir os clientes é tão


� Ouvir – ouvir os clientes é tão importante como fazer perguntas

� Desenhar – refazer o desenho constantemente e de acordo com as necessidades

Práticas

� Jogo do Planeamento – determinar a amplitude da próxima versão a partir das restantes variáveis

� Versões pequenas – ciclos de desenvolvimento muito curtos


� Metáfora – uma analogia partilhada por toda a equipa e que oriente o desenvolvimento

Práticas

� Desenho simples – tão simples quanto possível e complexidade extra é retirada

� Testar – os programadores e clientes escrevem constantemente testes de unidade e de aceitação


unidade e de aceitação� Re-factorizar – programadores re-estruturam o sistema, sem alterar o seu comportamento, para retirar duplicação, simplificar, ...

Práticas

� Programação aos pares – todo o código é escrito por grupos de dois programadores numa máquina

� Partilha colectiva – qualquer programador pode alterar o código


� Integração contínua – integrar e construir o sistema diversas vezes por dia

Práticas� 40 horas por semana – nunca trabalhar mais de 40 horas por semana e não fazer trabalho extraordinário duas semanas seguidas

� Cliente no local – incluir um cliente


� Cliente no local – incluir um cliente real na equipa

� Normas de codificação – todos os programadores escrevem o código de acordo com normas para dar ênfase à comunicação

Planear eXtreme Programming

� Porquê planear?� Não se planeia para prever o futuro� Planeia-se para

� garantir que se está sempre a fazer o que existe de mais importante

� coordenar eficazmente com outras pessoas


� coordenar eficazmente com outras pessoas

� responder rapidamente a eventos inesperados

� Qualquer técnica de planeamento de software deve tentar criar visibilidade

A Ratoeira do Planeamento� Existe outra razão pela qual as pessoas planeiam: para demonstrar que estão a controlar os eventos

� Mas controlar os eventos é uma ilusão: não é possível controlar os eventos; só é possível controlar as


eventos; só é possível controlar as nossas reacções

� Se as coisas não estão a ir de acordo com o plano, o “planeador” pode ter medo de ser considerado culpado

� Os eventos acontecem. Os planos mudam

Medo� Institui-se um processo de desenvolvimento de software porque os clientes e os programadores têm medo

� Para desenvolver eficazmente temos que reconhecer esses medos

� De modo a ter sucesso, um processo de desenvolvimento tem de ser instituído


desenvolvimento tem de ser instituído entre clientes e programadores para garantir certos direitos intransmissíveis� Lista de Direitos do Cliente� Lista de Direitos do Programador

Balanceamento de Poder� A chave da gestão de projecto é o balanceamento de poder entre pessoas de negócio e programadores

� Bem feita, a gestão de um projecto de software faz com que� As pessoas de negócio tomem as decisões de

negócio


negócio� Os técnicos tomem as decisões técnicas

� As decisões de negócio no planeamento são� Qualidade� Amplitude� Custos

� As decisões técnicas no planeamento são� Tempo

Tempo e Amplitude� Para a maior parte do planeamento, assume-se que a qualidade e o custo são fixos

� Qual a melhor forma de operar com as “alavancas” do tempo e da amplitude?


amplitude?� O planeamento tem que tornar a “alavanca” do tempo visível

� Deste modo, o planeamento resume-se a decidir que histórias (casos de uso) implementar em cada iteração

Yesterday’s Weather

� Assume-se, como base do planeamento, que se fará numa dada semana o mesmo que se fez na semana anterior

� Desta forma não será frequente exagerar as nossas capacidades uma


exagerar as nossas capacidades uma vez que temos que usar esforço real

Panorama

� O processo XP está organizado em� Versões que levam entre um e seis meses

� Iterações que levam entre uma e três semanas

� Tarefas que levam alguns dias


� Tarefas que levam alguns dias

Planeamento de Versões (1/2)� O planeamento de versões associa histórias a versões

� O cliente� Define as histórias� Decide qual o valor de negócio para cada uma delas

� Decide que histórias construir nesta versão


� Decide que histórias construir nesta versão

� Os programadores� Estimam quanto tempo vai demorar cada história

� Alertam o cliente acerca dos riscos técnicos envolvidos

� Medem o progresso da equipa de modo a fornecer ao cliente um plano global

Planeamento de Versões (2/2)� O plano da versão representa apenas a visão corrente de como as coisas se vão passar – necessita de ser revisto frequentemente

� É preferível planear em avanço uma ou duas versões


ou duas versões� Evoluir a infra-estrutura à medida que se constrói a funcionalidade

� O termo velocidade é usado para representar o trabalho que uma equipa pode produzir numa iteração

Estimação� Existem três aspectos chave para uma estimação adequada� Torná-la simples� Usar o que aconteceu no passado� Aprender a partir da experiência

� Uma forma simples e eficaz de estimar uma história é


� Uma forma simples e eficaz de estimar uma história é� Olhar para uma história semelhante que já foi realizada

� Olhar para os registos para saber quanto tempo demorou

� Assumir que a nova história levará o mesmo tempo

Ordenar as Histórias� Devem-se obter estimativas assim que se começam a escrever as histórias, pois é desta forma que se descobre o nível de detalhe adequado para as histórias

� As histórias que devem ser


� As histórias que devem ser realizadas primeiro são aquelas que contêm o maior valor de negócio

� Em geral, os programadores desejam fazer as histórias de maior risco primeiro

Eventos do Planeamento de Versões� Eventos

� Mudança de prioridades das histórias� Adicionar uma história

� É necessário reconstruir o plano nas seguintes circunstâncias


seguintes circunstâncias� Quando a pilha de histórias adiadas se torna muito grande

� Se a velocidade da equipa muda

O Primeiro Plano� O primeiro plano tem duas grandes áreas de incerteza� A velocidade da equipa� O tamanho das histórias

� A iteração de funcionalidade zero� Pôr a framework de testes a funcionar


� Pôr a framework de testes a funcionar� Pôr o ambiente de desenvolvimento a funcionar

� Pôr a rede a funcionar com todas as permissões adequadas

� Configurar os scripts básicos de instalação

Planeamento de Iterações

� Durante uma iteração� Desenvolve-se nova funcionalidade� Simplifica-se o código� Adiciona-se alguma infra-estrutura� Realizam-se algumas experiências


� Recupera-se do inesperado

� Ao contrário do plano da versão, o plano da iteração está mais associado aos programadores

Reunião Planeamento Iteração� A primeira coisa que se faz numa iteração� Ler as histórias para esta iteração� Escrever no quadro todas as tarefas que necessitam de ser realizadas para cada história

� Adicionar à lista quaisquer tarefas técnicas


� Adicionar à lista quaisquer tarefas técnicas que necessitem de ser realizadas

� Os programadores submetem estimativas das tarefas de acordo com a sua velocidade individual

� Se não se conseguir atribuir todas as histórias, pergunta-se ao cliente se ele pretende adiar algumas histórias

� Se existir tempo extra, pergunta-se ao cliente se ele pretende adicionar mais histórias

Monitorizar uma Iteração

� O monitor é a pessoa responsável por monitorizar o progresso numa iteração

� Duas vezes por semana o monitor faz duas questões a cada programador por cada tarefa que lhe está


por cada tarefa que lhe está associada� Quantos dias trabalhou nesta tarefa?� Quantos dias necessita para acabar?

Reuniões Stand-up� Pequenas reuniões diárias com o objectivo de transmitir a todas as pessoas uma ideia do que as outras pessoas estão a fazer

� Todas as pessoas têm de permanecer de pé durante toda a


permanecer de pé durante toda a reunião

� Cada pessoa resume o que fez no dia anterior e o que fará nesse dia

� O objectivo da reunião é comunicar problemas e não resolvê-los

Lidar com Bugs

� Calendarizar a correcção de bugs com a construção de histórias de modo a que o cliente possa escolher entre corrigir bugs e adicionar mais funcionalidade


Mudanças na Equipa

� Os novos membros da equipa podem� Fazer pair programming com pessoas mais experientes

� Ler código e casos de teste� Falar com os clientes


� Se existirem cinco programadores e um sair, reduz-se a próxima iteração em 20 por cento

Capazes, Produtivos e Satisfeitos� Padrões organizacionais para a equipa de desenvolvimento:� equipa produtiva� equipa coesa� partilha de conhecimentos

� Espaço do problema


� Espaço do problema� Análise do domínio� Requisitos de sistema� Tecnologia de implementação� Visão do futuro do sistema

� cultura da organização

Padrões

1. Potencial Produtivo

4. Atribuição3. Equipa Centrada

no Problema2. Arranque inicialização


8. Passagem de

Testemunho9. Familiarização

5. Pulso6. Utilização dos

Deliverables

7. Espaço da

Equipamanutenção

preservação

Potencial ProdutivoAvaliar as Aptidões da Equipa e o seu Progresso

� Contexto: Uma equipa de desenvolvimento envolvida num desenvolvimento iterativo

� Problema: Observa-se uma grande actividade mas pouco progresso


actividade mas pouco progresso� Forças:

� As equipas necessitam de uma infra-estrutura de conhecimento para suportar o progresso

� O progresso não pode só ser avaliado com base nos deliverables disponíveis

� Progresso pode existir sem terem sido feitos deliverables� Saltos de progresso podem originar remoção de código ou

alterações triviais de código

Potencial Produtivo� Solução: A equipa deve ser avaliada em termos da sua maturidade e capacidade de progredir e não apenas pelos deliverablesque gera. Aprender é iterativo. O progresso da equipa é função das seguintes quantidades:� Conhecimento colectivo e grau de confiança dos

membros da equipa


membros da equipa� Grau de conforto da equipa acerca da solução� Modelos de desenho, arquitectura e documentação� As arquitecturas de software e os módulos

implementados

Deve-se olhar para o progresso nos seus diferentes aspectos e contextualizar com a etapa de desenvolvimento

Potencial Produtivo� Contexto Resultante: O atributo mais importante de uma equipa de desenvolvimento de software é o seu potencial produtivo

� Problemas Conhecidos: � Gestores de projecto podem não entender o


� Gestores de projecto podem não entender o investimento na capacidade produtiva

� Pode ser difícil obter informação sobre o progresso dos membros da equipa de software. É necessário aprender que questões se devem fazer aos membros da equipa

ArranqueAjudar uma Equipa Recém Formada a Tornar-se Produtiva

� Contexto: Os membros da equipa não conhecem o domínio do problema, a aplicação e uns aos outros

� Problema: A equipa tem que se tornar rapidamente produtiva

� Forças: � Uma equipa não produtiva tem os mesmos custos


� Uma equipa não produtiva tem os mesmos custos que uma produtiva

� Uma equipa não produtiva é instável e mais passível de ser desagregada por influências externas

� É mais difícil liderar uma equipa quando instável� Existe o perigo de os membros começarem a

construir soluções antes de entender o problema

Arranque� Solução: É necessário dividir algumas responsabilidades mas partilhar outras. Deve ser partilhado o seguinte conhecimento:� Todos na arquitectura de alto nível do sistema� Todos no contexto do negócio e contexto técnico� Programadores na linguagem e no ambiente de

desenvolvimento� Programadores no controle de versões, técnicas de


� Programadores no controle de versões, técnicas de depuração e processo de construção do software

Competência nas seguintes áreas deve ser dividida:� Peritos em modelos de negócio e arquitecturas de

software� Peritos no domínio do negócio� Peritos em ambientes de desenvolvimento� Peritos na ligação aos utilizadores

Arranque

� Contexto Resultante: � Um ambiente de confiança abertura e partilha de conhecimento

� Uma equipa com um arranque rápido

� Problemas Conhecidos:


� Se a divisão á muito estreita alguns elementos podem sentir-se excluídos da cultura intelectual da equipa

� Evitar o nascimento de estrelas que dominam todas as divisões

Equipa Centrada no ProblemaDesencadear uma Cultura de Equipa que Enfatiza o Espaço do Problema

� Contexto: Uma equipa de desenvolvimento a que foram atribuídas responsabilidades

� Problema: Converter as aptidões individuais em produtividade de equipa


individuais em produtividade de equipa� Forças:

� Equipas são constituídas por indivíduos com interesses e objectivos próprios

� Relações de trabalho entre a equipa devem poder estabelecer-se antes da equipa se tornar produtiva

� Projectos de software apresentam uma miríade de possíveis actividades muitas das quais são improdutivas, fúteis e prejudiciais

Equipa Centrada no Problema� Solução: Estimular o interesse no espaço do

problema e utilizar isso como a motivação comum que permite construir uma coesão de grupo. Desta forma cada membro obtém:� uma percepção da sua contribuição� uma partilha do vocabulário do projecto� uma base de confiança que viabiliza a comunicaçãoPara focar a equipa no espaço do problema:


Para focar a equipa no espaço do problema:� Os potenciais utilizadores visitam e educam a

equipa� Criar tarefas não técnicas que envolvam os

utilizadores e a equipa� Os membros da equipa visitam o espaço físico onde

se realiza o negócio para tomarem contacto com o contexto do negócio

� Relacionar as decisões da arquitectura e desenho com o espaço do problema

Equipa Centrada no Problema� Contexto Resultante: Os membros da equipa:� Possuem um melhor entendimento da razão das suas tarefas e orientação do trabalho

� Conseguem tomar as decisões correctas quando desenham os componentes da solução

� Conseguem uma maior comunicação


� Conseguem uma maior comunicação

� Problemas Conhecidos: Alguns problemas são muito complexos e não podem ser tratados por toda a equipa. Nesta situação a equipa deve concentrar-se sobre uma parte crítica, mas controlável, do espaço do problema

AtribuiçãoAtribuição de Tarefas aos Membros da Equipa

� Problema: Atribuir uma tarefa à pessoa errada leva à perda de tempo, maus resultados e a uma perda da energia da equipa

� Forças:� Pessoas não são inter-mutáveis � Diferentes pessoas têm diferentes capacidades� Diferentes situações do negócio obrigam a diferentes


� Diferentes situações do negócio obrigam a diferentes abordagens

� As pessoas são mais produtivas quando estão a fazer o que fazem melhor

� As pessoas nem sempre reconhecem o que é que fazem melhor

� As pessoas precisam de novos desafios

Atribuição� Solução:

� Descobrir as preferências de cada membro e atribuir as tarefas de acordo. Por exemplo alguns bugs necessitam de uma resolução rápida enquanto que a resolução de outros tem de ser mais sistemática e também mais demorada


demorada� Rodar uma tarefa por diversos membros de modo a avaliar das capacidades e preferências de cada um

� Problemas Conhecidos: A informação que se obtém acerca dos membros apenas deve ser usada para a atribuição de tarefas

PulsoGerir os Altos e Baixos da Actividade da Equipa

� Contexto: A equipa tem de desenvolver uma quantidade significativa de funcionalidade nos próximos meses

� Problema: A equipa é capaz de picos de produtividade para cumprir prazos mas é necessário gerir a altura, frequência e duração desses picos com cautela


com cautela� Forças:

� Aumentar a pressão sobre a equipa resulta num aumento de produtividade no curto prazo

� As equipas não podem manter o pico de produtividade indefinidamente

� As equipas não sujeitas a pressão não produzem na sua capacidade máxima

Pulso� Solução:

� Determinar o ciclo de produção da equipa sujeitando-a a ciclos de pressão

� Quando houver períodos longos em que a equipa não está sujeita a pressão, por exemplo devido à alteração dos objectivos do projecto, deve-se estabelecer tarefas que exijam resultados rápidos para não se quebrar o ritmo da equipa


para não se quebrar o ritmo da equipa� Contexto Resultante: É possível antecipar os picos

de trabalho e a entrega de deliverables pode ser programada para os períodos de pico.

� Problemas Conhecidos: Não funciona se os objectivos não são estáveis, se altera a equipa com frequência,...

Utilização dos DeliverablesÉ Necessário Garantir que os Deliverables são Usados

� Problema: É necessário que os deliverablessão usados por aqueles a quem se destinam

� Forças: � A equipa de desenvolvimento gosta que o seu trabalho

seja reconhecidoA equipa de desenvolvimento quer que as suas soluções


� A equipa de desenvolvimento quer que as suas soluções sejam exploradas e testadas

� Os utilizadores têm o melhor suporte da equipa de desenvolvimento quando o trabalho ainda está fresco

� Deliverables não usados desmotivam a equipa� Deliverables não usados levam a uma redução da

qualidade� Pedidos de novas funcionalidades que não são satisfeitos

em tempo aceitável desmotivam os utilizadores

Utilização dos Deliverables� Solução: Apenas se entregam deliverablesquando os utilizadores estão prontos para os utilizar. A integração entre a equipa de desenvolvimento e os utilizadores pode ser estimulada:� Encorajando o envolvimento dos utilizadores nas actividades da equipa, e.g., peritos do domínio


actividades da equipa, e.g., peritos do domínio envolvidos na revisão de requisitos

� Encorajando o envolvimento dos membros da equipa nas actividades dos utilizadores

� Contexto Resultante: Uma maior comunicação e confiança entre utilizadores e a equipa de desenvolvimento

Espaço da Equipa� Contexto: A equipa está profundamente envolvida no desenvolvimento iterativo

� Problema: O espaço de trabalho deve ser arranjado para maximizar a produtividade

� Forças:� As pessoas necessitam de pequenos intervalos� Se não forem fornecidos a equipa vai criar os seus


� Se não forem fornecidos a equipa vai criar os seus próprios espaços para intervalo

� As pessoas distraem-se quando os períodos de intervalo não coincidem

� Na falta de uma espaço para intervalo a equipa tende a juntar-se em pequenos grupos e em locais privados

� Solução: Criar um espaço físico para interacções não planeadas entre os membros

Passagem de Testemunho� Contexto: A equipa está num pico de produtividade ou próximo da uma fase crítica entrega

� Problema: Um membro crítico vai abandonar a equipa

� Forças:


� Forças:� O membro que parte tem o conhecimento mais

detalhado acerca de uma parte importante do sistema

� O substituto tem capacidade de desenvolvimento mas desconhece o domínio e a arquitectura da aplicação

� O membro que parte tem trabalho por terminar que deve ser concluído antes de partir

Passagem de Testemunho� Solução: O membro que parte deve passar o testemunho a um elemento experiente da equipa, sendo ao novo elemento atribuído novo trabalho

� Contexto Resultante: O novo elemento pode aprender e inserir-se a um ritmo que não o “mate”


não o “mate”� Problemas Conhecidos: O elemento experiente pode ficar sobrecarregado de trabalho. Nessa situação pode-se aproveitar para fazer uma re-distribuição de responsabilidades a toda a equipa

Familiarização� Contexto: Existem substituições nos membros da

equipa� Problema: Os novos membros devem ter

rapidamente uma visão dos módulos de software� Forças:

� As pessoas são animais territoriais que necessitam de um grau de posse para serem produtivos

� O novo membro tem de ficar familiarizado com o


� O novo membro tem de ficar familiarizado com o código de outro membro

� Para um módulo de software estar “vivo” tem que ser “habitado” diariamente

� Familiarização e confiança são alcançadas incrementalmente

� Muitas pessoas apenas sentem que possuem algo quando contribuem para a sua construção

Familiarização� Solução: O novo membro deve ser motivado a alterar cosmeticamente o código de módulos existentes:� Corrigir o código para ser coerente com as regras de

codificação� Adicionar código que evite situações de erro devido a

argumentos errados� Alterar nomes que são ambíguos


� Alterar nomes que são ambíguos

� Problemas Conhecidos: Não deve ser uma desculpa para fazer a limpeza do lixo. Os novos membros devem ser supervisionados para evitar alterações que não são cosméticas

Gestão de Configurações� Os padrões de gestão de configurações são úteis pois:� Consideram como as pessoas trabalham para além dos mecanismos de como se constrói o código

� Envolvem processos de construção e os artefactos resultantes


� Envolvem processos de construção e os artefactos resultantes

� Pequenas alterações na forma como se faz a gestão de configurações pode melhorar em muito o processo

� ...

Padrões� Sequência de código� Sequência principal� Sequência activa� Política da sequênciaVersões privadas

� Espaço de trabalho� Espaço de trabalho

privado� Repositório � Construção privada

do sistema� Construção de

integração


� Versões privadas� Sequência da entrega

� Sequência de preparação para entrega

� Ramo por tarefa

integração� Sequência de terceira

parte� Confirmação de nível

tarefa� Teste de despistagem� Teste de unidade� Teste de regressão

Padrões


Sequência Principal

� Contexto� Desenvolvimento de software por várias pessoas em paralelo

� A ferramenta de controlo de versões suporta ramos e integrações



� Problema� Como manter o número de sequências de código activas em número pequeno de forma a facilitar a gestão, sem a árvore de versões do projecto ficar demasiado larga e densa? Como se


demasiado larga e densa? Como se minimiza o esforço adicional de fazer integrações?


� Criar ramos é um mecanismo para isolarmos-nos de e/ou isolarmos alterações

� Integração pode ser difícil devido aos conflitos de alterações podendo exigir a presença de todos os intervenientes


a presença de todos os intervenientes� A dificuldade de integração aumenta com a duração entre integrações


� Solução� Simplificar o modelo de ramos

� Quando se está a desenvolver uma única versão do produto deve-se trabalhar numa sequência principal

� Uma sequência principal é a sequência


� Uma sequência principal é a sequência onde é feito todo o desenvolvimento, excepto em circunstâncias especiais

� Quando se pretende criar um ramo deve-se pensar na estratégia global antes de o criar

� Se houver dúvidas, escolher o modelo mais simples

Sequência Principal� A sequência principal funciona como a base de ramos e integrações resultantes – evitar modelos em escada

� A criação de ramos deve ser feita com cuidado


com cuidado� O desenvolvimento na sequência principal tem as seguintes vantagens:� Reduz integrações e sincronizações� Permite que as alterações sejam imediatamente visíveis


� Deve-se criar ramos quando:� Versões para o cliente em que já se está a fazer depuração – isolam a versão a entregar ao cliente de novas funcionalidades

� Tarefas de longa duração em que várias


� Tarefas de longa duração em que várias pessoas estão envolvidas – aplica-se quando as alterações na sequência principal são pequenas

� ...


� Aspectos por resolver� Como manter a sequência principal usável quando muitas pessoas estão a trabalhar nela?


Sequência Activa

� Contexto� O desenvolvimento de uma nova versão do produto está a ser feito numa sequência principal

� O código está a ser alterado por muitas pessoas


pessoas� As alterações podem corromper o sistema e/ou podem ocorrer conflitos entre alterações

Sequência Activa

� Problema� Como manter uma sequência de código que evolui rapidamente num estado suficientemente estável para que seja útil?


Sequência Activa� Pretende-se que a equipa trabalhe em paralelo

� Situações de impasse podem ocorrer se não forem criados pontos de sincronização

� Testes podem não ser conclusivos


� Testes podem não ser conclusivos� Uma sequência de código com erros atrasa o desenvolvimento

� Testes podem ser demorados e provocar atrasos

Sequência Activa

� Solução� Estabelecer políticas que tornem a sequência de código principal suficientemente estável para o trabalho que é necessário

� Não procurar uma sequência de


� Não procurar uma sequência de desenvolvimento activa perfeita, mas sim uma sequência principal que é usável e suficientemente activa para as necessidades

Sequência Activa

� O que é difícil é perceber quão “boa” deve ser a sequência de código:� Quem usa a sequência de código?� Qual é o ciclo de entrega?� Que mecanismos de testes temos disponíveis?


disponíveis?� Que percentagem do sistema está a evoluir?

� Qual é o preço de um ciclo em que a sequência de código fica corrompida?

Sequência Activa� Aspectos por resolver

� Uma política da sequência deve estabelecer como deve ser o processo de confirmação da sequência

� Os programadores devem usar um espaço de trabalho privado para isolar alterações e manter a sequência activa


alterações e manter a sequência activa� Uma sequência de preparação para entrega deve ser criada se se procura estabilidade

� Criar um ramo para tarefas de longa duração

Padrões de Espaço de Trabalho


Espaço de Trabalho Privado

� Contexto� Está-se a trabalhar numa sequência activa

� Pretende-se trabalhar com o código mais actualizado

� Pretende-se controlar quando se começa


� Pretende-se controlar quando se começa a trabalhar com as alterações que os outros entretanto fizeram


� Problema� Como se manter actualizado com as alterações mais recentes do código mas sem sofrer alterações não controladas do ambiente de trabalho, de forma a poder progredir?


progredir?


� O desenvolvimento no contexto de uma equipa envolve os seguintes passos:� Escrever e testar as nossas alterações ao código

� Integrar o nosso código com o trabalho


� Integrar o nosso código com o trabalho das outras pessoas

� A integração pode ser:� Contínua� Diferida


� Solução� Fazer o trabalho num espaço privado onde se pode controlar as versões do código com que se está a trabalhar

� Permite ter o controlo sobre quando e como o nosso ambiente trabalho se


como o nosso ambiente trabalho se altera

Espaço de Trabalho Privado� Um espaço de trabalho contém o seguinte:� Código que se está a editar� Componentes construídos localmente� Objectos de uma terceira parte que não se pretende construir


se pretende construir� Configuração e dados necessários para executar e testar o sistema

� Scripts de construção do sistema neste espaço de trabalho

� Informação identificando as versões de todos os componentes do sistema


� Um espaço de trabalho não deve conter o seguinte:� Scripts genéricos de construção do sistema

� Ferramentas e compiladores que são os mesmos para todas as versões do


mesmos para todas as versões do produto

Espaço de Trabalho Privado� O seguinte procedimento deve ser

seguido:1. Obter os dados mais recentes da sequência

activa2. Fazer alterações3. Fazer uma Construção Privada do Sistema4. Testar as alterações com Testes de Unidade


4. Testar as alterações com Testes de Unidade5. Actualizar o espaço de trabalho com a versão

mais recente dos componentes na sequência activa

6. Construir o sistema e executar Testes de Despistagem para garantir que não se corrompeu nada

Espaço de Trabalho Privado� Aspectos por resolver

� Uma Construção Privada do Sistema evita que se introduzam erros quando se fazem confirmações

� É necessário carregar o espaço de trabalho de um RepositórioComponentes externos devem vir de


� Componentes externos devem vir de uma Sequência de Terceira Parte

� Uma vez que o trabalho isolado está terminado é necessário integrar com o resto do sistema fazendo uma Construção de Integração

Repositório

� Contexto� Para criar um Espaço de Trabalho Privado ou para executar uma Construção de Integração é necessário obter os componentes certos

� Problema


� Problema� Como obter as versões correctas dos componentes certos num espaço de trabalho?

Repositório

� Solução� Ter um único ponto de acesso, ou repositório, para o código e outros artefactos relacionados

� Fazer com que criar um espaço de trabalho seja o mais simples e


trabalho seja o mais simples e transparente possível

Repositório

� Uma forma simples de implementar este padrão é colocar todo o código fonte, ficheiros de configuração, scripts de construção e componentes de terceiras partes no sistema de controlo de versões


controlo de versões� Aspectos por resolver

� Organizar o código de terceiras partes numa Sequência de Terceira Parte

Construção Privada do Sistema

� Contexto� As alterações feitas no Espaço de Trabalho Privado devem funcionar com o restante sistema

� Problema� Como se verifica, antes de se confirmar


� Como se verifica, antes de se confirmar as alterações, que as nossas alterações não vão corromper o sistema?

Construção Privada do Sistema� Fazer confirmação de alterações que podem corromper o sistema e fazem perder tempo

� A construção de pré confirmação pode funcionar bem mas a construção da noite falha

� A depuração feita a partir do nosso


� A depuração feita a partir do nosso ambiente de desenvolvimento dá mais pistas do que a que é feita a partir do sistema em produção

� Algumas organizações têm procedimentos de construção bem estabelecidos mas estes não escalam até aos programadores


� Solução� Antes de confirmar o código deve-se construir o sistema usando uma construção privada similar à construção da noite



� A construção privada deve ter as seguintes características:� Ser, tanto quanto possível, como a Construção de Integração e as construções do produto, embora alguns detalhes relacionado com entrega e


detalhes relacionado com entrega e empacotamento possam ser omitidos

� Incluir todas as dependências� Incluir todos os componentes que dependem da alteração


� Pode ser feita uma construção completa ou uma construção incremental

� Deve ser feita uma construção completa sempre que:


� Se estão a adicionar novos ficheiros ao sistema de controlo de versões – deve-se começar com um espaço de trabalho vazio

� Houve alterações profundas de funcionalidade central


� Aspectos por resolver� Depois de se ter verificado que se consegue construir o sistema deve ser feito um Teste de Despitagem para verificar se a funcionalidade não ficou corrompida


corrompida� Se o sistema é muito grande pode não ser eficiente construir todos os componentes que usam os nossos componentes, sendo isso deixado para a Construção de Integração

Construção de Integração

� Contexto� Os programadores trabalham separadamente nos seus espaços de trabalho

� O trabalho deve ser integrado

� Problema


� Problema� Como garantir que a construção na sequência activa que resulta da integração dos espaços de trabalho é fiável?


� Alterações em paralelo podem não ser compatíveis

� Uma construção completa e centralizada pode resolver o problema mas como vai ser feita a partir de código já confirmado o


partir de código já confirmado o problema já está criado


� Solução� Garantir que todas as alterações, e suas dependências, são construídas usando um processo de integração central. Deve ser:� Reproduzível


� Reproduzível� Similar à construção do produto final� Automatizado ou requerendo pouca intervenção

� Mecanismos de notificação e história


� Fazer a integração num espaço de trabalho que contenha os componentes a serem integrados

� Determinar a frequência das construções de integração baseado em:


em:� Quanto tempo demora a construir o sistema

� A frequência de alterações ao sistema


� Aspectos a resolver� Após a construção de integração fazer Teste de Despitagem

� Se a construção for publicada como uma base estável fazer Teste de Regressão


Sequência de Terceira Parte

� Contexto� A sequência de código está associada a um conjunto de componentes externos que fazem parte do produto

� Alguns dos produtos externos podem ter de ser adaptados


de ser adaptados� Pode ser necessário associar versões de componentes externos ao nosso produto

� Os componentes externos devem ser incluídos no espaço de trabalho


� Problema� Qual a estratégia mais eficaz de coordenar as versões de componentes externos com versões do código do produto?



� Os ciclos de versões de entrega de um vendedor são diferentes dos ciclos de versões do nosso produto

� É necessário identificar que versões do componente externo fazem parte de cada versão do nosso produto


de cada versão do nosso produto� Se forem feitas alterações ao componente externo é necessário que essas alterações sejam integradas com as versões futuras


� Solução� Criar uma sequência de código para código de terceiras partes

� Construir espaços de trabalho e procedimentos de instalação a partir desta sequência de código


desta sequência de código


� Criar ramos separados para o código da terceira parte e para as versões das adaptações a ele feitas

� Quando se obtém uma nova versão da terceira parte fazer com que ela seja a próxima versão no ramo do


seja a próxima versão no ramo do vendedor e, ulteriormente, integrar o código deste ramo com o ramo de adaptação

Confirmação de Nível Tarefa

� Contexto� Uma construção de integração é fácil de depurar se soubermos o que deve conter

� Problema� Quanto trabalho deve ser feito entre submissões ao sistema de controlo de


submissões ao sistema de controlo de versões?

� Quanto tempo se deve esperar antes confirmar as alterações?


� Codificar é uma sequência de depuração de erros, melhorias e novas funcionalidades que devem ser registadas

� Adicionar uma funcionalidade ou corrigir um erro pode levar a muitas


corrigir um erro pode levar a muitas alterações no código

� Deve ser possível recuperar para um estado anterior às alterações se elas corromperem o sistema


� Quando uma construção de integração falha deve ser possível identificar a alteração que provocou a falha� Uma história de alterações de grande granularidade reduz a sobrecarga de


granularidade reduz a sobrecarga de confirmações

� Uma história detalhada de alterações permite uma recuperação selectiva


� Solução� Fazer uma confirmação por cada tarefa consistente de pequena granularidade

� Cada alteração deve representar um estado consistente do sistema



� Exemplos de alterações consistentes:� Um relatório de problema� Alterar as invocações a um método

deprecated de forma a utilizar uma nova interface para todo o sistema

� Alterar as invocações a um método


� Alterar as invocações a um método deprecated para uma parte coerente do sistema

� Um conjunto de alterações consistentes que podem ser terminadas num dia


� Aspectos por resolver� As alterações que demoram muito tempo e são difíceis de alcançar devem ser feitas num Ramo por Tarefa

� A existência de testes de unidade, regressão e despistagem permitem


regressão e despistagem permitem motivar confirmações de pequena granularidade

Teste de Despistagem

� Contexto� A construção de integração e a construção privada do sistema são úteis para verificar aspectos de integração em tempo de construção

� É necessário verificar aspectos de tempo


� É necessário verificar aspectos de tempo de execução

� Problema� Como saber que o sistema continua a funcionar após se ter feito uma alteração?


� Podem-se escrever testes que cobrem as partes mais críticas e sujeitas a falhas do sistema, mas é difícil de desenvolver testes completos

� Correr todos os testes disponíveis pode ser muito demorado


pode ser muito demorado� Testes que demoram muito a executar levam a que o programador aumente o tempo entre integrações


� Solução� Sujeitar cada construção a um teste de despistagem que verifica que o sistema não se corrompeu de uma forma óbvia

� Os testes de despistagem devem ser automatizados


automatizados


� Os testes de despistagem não substituem testes mais exaustivos

� A execução de um teste de despistagem por construção não retira a responsabilidade dos programadores testarem as suas


programadores testarem as suas alterações entre de submeterem o seu espaço de trabalho


� Um teste de despistagem deve:� Rápido a executar� Indicar automaticamente do seu sucesso ou insucesso

� Fornecer uma cobertura abrangente do sistema que é o nosso alvo


sistema que é o nosso alvo� Poder ser executado pelos programadores como parte do processo de garantia de qualidade


� Aspectos por resolver� Um teste de despistagem deixa muitos aspectos por testar que devem ser considerados num Teste de Regressão

� Os programadores devem fazer um Teste de Unidade por cada módulo que


Teste de Unidade por cada módulo que necessitam

� Utilizar Teste de Unidade para verificar que o módulo que se está a alterar continua a funcionar de forma adequada

Teste de Unidade

� Contexto� Um teste de despistagem não é suficiente para testar uma alteração em detalhe, especialmente quando se está a trabalhar num novo módulo

� Problema


� Problema� Como testar que um módulo continua a funcionar correctamente após ter sido alterado

Teste de Unidade

� Quando um teste de despistagem falha desejamos saber que parte do sistema falhou

� Desejamos isolar os aspectos de integração das alterações locais


� Desejamos testar o contrato que cada módulo fornece localmente

Teste de Unidade

� Solução� Desenvolver e executar testes de unidade

� Os testes de unidade devem ter as seguintes características:


� São automáticos e auto avaliam-se� Têm pequena granularidade� São isolados� Testam o contrato� Simples de executar

Teste de Unidade

� Os testes de unidade devem ser executados quando:� Se está a codificar� Antes de confirmar uma alteração� Para encontrar um problema com um teste de despistagem ou de regressão


teste de despistagem ou de regressão

� Os testes de unidade devem ser suportados por ferramentas como o JUnit

Teste de Regressão

� Contexto� Para estabelecer uma entrega os testes de despistagem não são suficientes

� Problema� Como verificar que o código não fica pior conforme se vai fazendo alterações?


conforme se vai fazendo alterações?

Teste de Regressão

� Pode-se fazer testes exaustivos do sistema após cada construção mas essa actividade é demorada

� Se não se correrem os testes faz-se perder tempo aos utilizadores


Teste de Regressão� Solução

� Executar testes de regressão no sistema sempre que se quer assegurar estabilidade da sequência de código� Antes de fazer uma entrega� Antes de uma alteração arriscadaCriar os testes de regressão a partir de


� Criar os testes de regressão a partir de casos de teste para os quais o sistema falhou no passado

� São de largo espectro e testam as consequências inesperadas da integração de componentes de software

Teste de Regressão� Escrever testes de regressão a partir de:

� Problemas encontrados no passado� Problemas reportados pelos utilizadores e pelos clientes

� Testes de sistema baseados em requisitos

� Cada problema pode incluir mais do que


� Cada problema pode incluir mais do que um caso de teste

� Correr sempre os mesmos testes de regressão enriquecidos por novos casos de teste associados a novos problemas encontrados

Padrões de Sequência


Política da Sequência

� Contexto� Existem diversas sequências de código e os programadores necessitam de saber como trabalhar em cada uma delas

� Uma Sequência da Entrega deve ter regras muitos restritivas acerca de como


regras muitos restritivas acerca de como e quando se pode confirmar

� Numa Sequência Activa as regras devem ser menos restritivas


� Problema� Como é que os programadores sabem em que sequência de código confirmar o seu código, quando o fazer e que testes devem correr antes de o fazer?


Política da Sequência� Cada sequência de código tem objectivos diferentes� Depuração� Entrega� Portar para outra plataforma� Nova versão


� ...

� Cada sequência tem requisitos de estabilidade diferentes

� É difícil garantir que os programadores sigam as políticas


� Solução� Para cada sequência de código estabelecer uma política que determina quando e como os programadores podem fazer alterações

� As políticas devem ser concisas e


� As políticas devem ser concisas e auditáveis

Política da Sequência� A descrição do objectivo da sequência (3 parágrafos) pode incluir:� Tipo de trabalho – desenvolvimento, manutenção, versão, função, subsistema

� Quando e como devem os elementos ser confirmados, checked out, criados ramos ou integradosRestrições de acesso por indivíduo, papel ou


� Restrições de acesso por indivíduo, papel ou grupo

� Relações com outras sequências� Duração do trabalho e quando a sequência deve terminar

� Carga esperada de actividade e frequência de integração

Política da Sequência� Algumas políticas de sequências

� Desenvolvimento – alterações intermédias ao código devem ser confirmados e os componentes afectados devem ser construídos

� Entrega – o sistema deve ser construído e passar testes de regressão antes da confirmação; as confirmações estão limitados à depuração de erros; não são introduzidas novas


depuração de erros; não são introduzidas novas funcionalidades; após a confirmação a sequência não sofre alterações até que todo o ciclo de QA termina

� Principal – todos os componentes devem compilar e passar testes de regressão, e novas funcionalidades completamente testadas podem ser confirmadas


� Aspectos por resolver� É necessário utilizar automatização e ter em consideração a cultura da equipa

� Usar o ANT para fazer auditorias


Versões Privadas

� Contexto� É necessário avaliar rapidamente uma alteração complexa que pode corromper o sistema que está a ser desenvolvido na sequência activa

� Problema


� Problema� Como se pode experimentar uma alteração complexa, tirando ao mesmo tempo partido do sistema de controlo de versões, sem tornar as alterações públicas?

Versões Privadas� As alterações, mesmo as complexas, são melhor feitas em pequenos passos que podem ser refeitos

� O processo de alteração pode consistir em experimentar diversas alternativas


alternativas� O sistema de controlo de versões permite criar pontos de recuperação (checkpoint)

� Trabalhando só no espaço de trabalho privado não permite ter versões

Versões Privadas

� Solução� Fornecer aos programadores um mecanismo de guardar as alterações a um nível de granularidade com que eles estejam confortáveis

� Utilizar uma área local de controlo de


� Utilizar uma área local de controlo de revisões

� Apenas o código estável é confirmado no repositório do projecto

Versões Privadas

� A área local de controlo de versões pode ser um ramo

� Deve-se assegurar que os programadores que utilizam a versão privada migram as alterações para o sistema de controlo de versões


sistema de controlo de versões partilhado em intervalos razoáveis

Sequência da Entrega� Contexto

� Está-se a fazer desenvolvimento sobre uma sequência activa

� Foram entregues versões que necessitam de manutenção e pequenas melhoriasPretende-se manter a versão entregue


� Pretende-se manter a versão entregue estável

� Problema� Como fazer a manutenção de uma versão entregue sem interferir com o trabalho de desenvolvimento em curso?

Sequência da Entrega� É necessário reparar urgentemente um erro de uma versão em produção e a versão em desenvolvimento não vai estar pronta rapidamente

� Os utilizadores não querem fazer actualização para uma nova versão


actualização para uma nova versão� O esforço de manutenção da versão entregue pode ser incompatível com alguma da funcionalidade ou refactorização em curso na versão em desenvolvimento

Sequência da Entrega

� Solução� Separar a versão entregue e a nova versão em diferentes sequências de código

� Manter cada versão entregue numa sequência – sequência da entrega


sequência – sequência da entrega� Na sequência da entrega será feita a manutenção

� A sequência da entrega é um ramo da sequência principal

Sequência da Entrega

� Alterações na sequência de entrega são propagadas para a sequência activa com regularidade – sempre antes da próxima entrega

� Correcções de erros na sequência principal devem ser propagados para


principal devem ser propagados para a sequência de entrega se possível

� O código da sequência da entrega fica “morto” quando a versão deixa de ser suportada

Sequência de Preparação ...� Sequência de Preparação para Entrega

� Contexto� Está-se a terminar uma entrega e é necessário iniciar o desenvolvimento de uma nova versão


uma nova versão

� Problema� Como estabilizar o código que se está a preparar para um entrega permitindo contudo que novo trabalho continue na sequência activa

Sequência de Preparação ...

� Por vezes o processo de preparação de uma entrega pode-se prolongar devido a vários factores –configurações, instalações, erros imprevistos,...Nem toda a equipa necessita de estar


� Nem toda a equipa necessita de estar envolvida na actividade de preparar a entrega

Sequência de Preparação ...� Solução

� Criar um ramo de engenharia da entrega quando o código começa a ter a qualidade necessária para a entrega

� Terminar de preparar a entrega neste ramo enquanto que na sequência activa continua o restante desenvolvimento


continua o restante desenvolvimento� O ramo torna-se no ramo da entrega� O responsável pela sequência activa define a política sobre como e quando as alterações são propagadas da sequência de preparação para a sequência activa

Sequência de Preparação ...

� Aspectos por resolver� Se poucas pessoas estão a trabalhar na nova versão cria-se um ramo por tarefa para a nova versão


Ramo por Tarefa

� Contexto� Algumas tarefas de desenvolvimento demoram muito tempo e os seus passos intermédios geram muita instabilidade

� Problema� Como pode uma equipa fazer múltiplas


� Como pode uma equipa fazer múltiplas alterações, e de longa duração, a uma sequência de código, sem comprometer a sua consistência e integridade

Ramo por Tarefa

� Integrações frequentes são importantes para se ter estabilidade global

� Pretende-se colocar as alterações no sistema de controlo de versões para se ter rastreabilidade e recuperação


se ter rastreabilidade e recuperação� Algumas alterações desestabilizam a sequência de código

Ramo por Tarefa

� Solução� Criar um ramo separado para cada actividade que traz alterações significativas a uma sequência de código


Ramo por Tarefa

� Um ramo por tarefa é um mecanismo para isolar fisicamente actividades de risco do código base

� Deve-se integrar frequentemente as alterações da sequência activa com o ramo de forma a que a integração


ramo de forma a que a integração final do ramo com a sequência activa seja o mais suave possível

Exemplo

� Inicialização da Equipa� Partilha dos seguintes conhecimentos:

� Arquitectura� Técnicas de Programação� Ferramentas� Problema


� Problema� Negócio

� Familiarização� Foram dados exemplos de código� Programação de novos casos de uso a

partir desses exemplos

Exemplo� Projecto Parte 1

� Os alunos aprendem a arquitectura� Os alunos aprendem a tecnologia

� Projecto Parte 2� O professor é o gestor de projecto� Aprender a trabalhar em grupo� Desenvolver a comunicação entre os diferentes


� Desenvolver a comunicação entre os diferentes elementos

� Ganhar confiança

� Projecto Parte 3� Os alunos estão capazes de estimar a duração

das suas tarefas� O grupo é capaz de se gerir

Conclusões� P127 – Uma boa gestão é mais importante que uma boa tecnologia

� P130 – Entender quais as prioridades dos clientes� Os clientes podem preferir 90% da funcionalidade mais tarde se podem ter


funcionalidade mais tarde se podem ter os restantes 10% mais cedo

� P131 – As pessoas são a chave do sucesso� Bons profissionais podem ser X vezes mais produtivos que os restantes profissionais

� P134 – Confiar na equipa� P135 – Esperar excelência � P136 – Capacidade de comunicação é essencial� Comunicar, convencer, ouvir, aceitar

Conclusões


� Comunicar, convencer, ouvir, aceitar compromissos

� P138 – Pessoas são motivadas por coisas diferentes� Ambos reforços, negativos e positivos, funcionam

� P140 – Não se pode trocar tempo por pessoas� Adicionar pessoas até pode atrasar o projecto

� P142 – Pode-se optimizar o que quiser

Conclusões


quiser� Se não se indicar quais as prioridades e o que deve ser optimizado nada será optimizado

� P146 – Adaptar os métodos de estimação do esforço� Eliminar as variáveis que são invariantes no caso específico

� Adicionar variáveis que influenciam a produtividade no caso específico

Conclusões


produtividade no caso específico

� P147 – Não estabelecer prazos irrealistas� Reduzem a moral e a qualidade, geram desconfiança

Conclusões

� P150 – Obter dados sobre a produtividade� Necessários para adaptar os métodos de estimação

� P151 – Não esquecer a produtividade da equipa


da equipa� A produtividade óptima dos membros não é necessariamente a produtividade óptima da equipa

Conclusões

� P153 – Concordar com a calendarização� Todas as partes interessadas no projecto devem concordar com a calendarização e se possível participar na sua elaboração

� P155 – Regularmente reavaliar a


� P155 – Regularmente reavaliar a calendarização� Calendarizações atrasadas raramente recuperam usando etapas previamente estabelecidas

� P161 – Conhecer os 10 maiores riscos1. Falhas na equipa2. Calendarização irrealista3. Não entendimento dos requisitos4. Desenvolver uma interface de utilizador errada

Conclusões


4. Desenvolver uma interface de utilizador errada5. Tentar a solução ideal 6. Não controlar a alteração de requisitos7. Falhas na reutilização de componentes8. Falhas nas tarefas subcontratadas9. Falhas no desempenho em tempo real10.Exceder a capacidade da tecnologia actual

� P165 – Não existem aumentos miraculosos de produtividade� A indústria tem tido um aumento de produtividade de 3% a 5% por ano não obstante a adopção de novas ferramentas e novos métodos

Conclusões


ferramentas e novos métodos

� P169 – Ser optimista acerca da evolução do hardware

� P170 – Ser pessimista acerca da evolução do software

Referências

� Pfleeger01, Capítulo 3.� David95, Alguns princípios do Capítulo 7.

� eXtreme Programming. http://www.extremeprogramming.org


http://www.extremeprogramming.org

Referências

� Paul Taylor. Capable, Productive, and Satisfied: Some Organizational Patterns for Protecting Productive People. In Harrison2000. Capítulo 27. http://jerry.cs.uiuc.edu/~plop/plop98/final_submissions/P54.pdf

� Stephen Berczuk e Brad Appleton.


� Stephen Berczuk e Brad Appleton. Software Configuration Management Paterns. Addison-Wesley. 2003. http://www.scmpatterns.com/

Documents

Gestão de Projecto - Autenticação · uma decisão Intuitivos baseiam as suas decisões nas emoções ... Planificação do projecto Monitorização do projecto Gestão de Riscos