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
Gestão de Projecto 3
� 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
Gestão de Projecto 4
� 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”
Gestão de Projecto 5
� 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
Gestão de Projecto 6
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
Gestão de Projecto 7
� 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
Gestão de Projecto 8
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
Gestão de Projecto 9
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
Gestão de Projecto 10
� 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
Gestão de Projecto 11
semelhantes� Capacidade de partilhar responsabilidades
� Capacidade de gestão� Capacidade de comunicação (ver figura)
Comunicação na Equipa
Gestão de Projecto 12
“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
Gestão de Projecto 13
� O número de pessoas na equipa� O tipo do modelo do processo de desenvolvimento
Equipa Hierárquica
Gestor/ProgramadorChefe
SecretárioProgramador
Gestão de Projecto 14
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
Gestão de Projecto 15
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
Gestão de Projecto 16
� 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
Gestão de Projecto 17
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
Gestão de Projecto 18
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 Projecto 19
� 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
Gestão de Projecto 20
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
Gestão de Projecto 21
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
Gestão de Projecto 22
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
Gestão de Projecto 23
� É 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
Gestão de Projecto 24
� 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
Gestão de Projecto 25
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
Gestão de Projecto 26
� 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
Gestão de Projecto 27
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
Gestão de Projecto 28
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
23 4º Conjunto de Tarefas 8,88 days Wed 10-05-00 Sat 13-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
28 5º Conjunto de Tarefas 9,5 days Wed 17-05-00 Sat 20-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
Gestão de Projecto 29
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
Luís;Rui;Nuno;Serafim
Luís;Rui;Nuno;Serafim
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
Gestão de Projecto 30
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
Gestão de Projecto 31
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
Gestão de Projecto 32
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
Gestão de Projecto 33
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
Gestão de Projecto 34
� 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
Gestão de Projecto 35
� 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
Gestão de Projecto 36
� 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?
Gestão de Projecto 37
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
Gestão de Projecto 38
� 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
Gestão de Projecto 39
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
Gestão de Projecto 40
� 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
Gestão de Projecto 41
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
Gestão de Projecto 42
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.,
Gestão de Projecto 43
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
Gestão de Projecto 44
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
Gestão de Projecto 45
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:
Gestão de Projecto 46
� 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:
Gestão de Projecto 47
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
Gestão de Projecto 48
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
Gestão de Projecto 49
� 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� ...
Gestão de Projecto 50
� ...
� 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
Gestão de Projecto 51
� 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
Gestão de Projecto 52
� 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
Gestão de Projecto 53
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
Gestão de Projecto 54
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 Projecto 55
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
Gestão de Projecto 56
� 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
Gestão de Projecto 57
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
Gestão de Projecto 58
� 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
Gestão de Projecto 59
� 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
Gestão de Projecto 60
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...
Gestão de Projecto 61
� ...
� Integração – é o processo em que um ramo é reincorporado na sequência de código principal
Diagrama
Gestão de Projecto 62
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 é
Gestão de Projecto 63
� 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
Gestão de Projecto 64
� 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
Gestão de Projecto 65
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
Gestão de Projecto 66
� 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
Gestão de Projecto 67
� 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
Gestão de Projecto 68
� 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
Gestão de Projecto 69
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
Gestão de Projecto 70
� 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
Gestão de Projecto 71
� 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-
Gestão de Projecto 72
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
Gestão de Projecto 73
� 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
Gestão de Projecto 74
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
Gestão de Projecto 75
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
Gestão de Projecto 76
� 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
Gestão de Projecto 77
� 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
Gestão de Projecto 78
� 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
Gestão de Projecto 79
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
Gestão de Projecto 80
� 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
Gestão de Projecto 81
� 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
Gestão de Projecto 82
� 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
Gestão de Projecto 83
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
Gestão de Projecto 84
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
Gestão de Projecto 85
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?
Gestão de Projecto 86
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
Gestão de Projecto 87
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
Gestão de Projecto 88
� 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
Gestão de Projecto 89
� 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
Gestão de Projecto 90
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 é
Gestão de Projecto 91
� 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
Gestão de Projecto 92
� 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
Gestão de Projecto 93
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
Gestão de Projecto 94
� 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
Gestão de Projecto 95
� 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
Gestão de Projecto 96
� 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á
Gestão de Projecto 97
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
Gestão de Projecto 98
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
Gestão de Projecto 99
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
Gestão de Projecto 100
� 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
Gestão de Projecto 101
� 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
Gestão de Projecto 102
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
Gestão de Projecto 103
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
Gestão de Projecto 104
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
Gestão de Projecto 105
� 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
Gestão de Projecto 106
� 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
Gestão de Projecto 107
� 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:
Gestão de Projecto 108
� 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
Gestão de Projecto 109
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:
Gestão de Projecto 110
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
Gestão de Projecto 111
� 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
Gestão de Projecto 112
� 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
Gestão de Projecto 113
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
Gestão de Projecto 114
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
Gestão de Projecto 115
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
Gestão de Projecto 116
� 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
Gestão de Projecto 117
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
Gestão de Projecto 118
� 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:
Gestão de Projecto 119
� 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”
Gestão de Projecto 120
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
Gestão de Projecto 121
� 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
Gestão de Projecto 122
� 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
Gestão de Projecto 123
� 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
Gestão de Projecto 124
� 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
Gestão de Projecto 125
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
Gestão de Projecto 126
Sequência Principal
� 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
Gestão de Projecto 127
demasiado larga e densa? Como se minimiza o esforço adicional de fazer integrações?
Sequência Principal
� 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
Gestão de Projecto 128
a presença de todos os intervenientes� A dificuldade de integração aumenta com a duração entre integrações
Sequência Principal
� 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
Gestão de Projecto 129
� 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
Gestão de Projecto 130
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
Sequência Principal
� 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
Gestão de Projecto 131
� 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
� ...
Sequência Principal
� Aspectos por resolver� Como manter a sequência principal usável quando muitas pessoas estão a trabalhar nela?
Gestão de Projecto 132
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
Gestão de Projecto 133
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?
Gestão de Projecto 134
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
Gestão de Projecto 135
� 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
Gestão de Projecto 136
� 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?
Gestão de Projecto 137
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
Gestão de Projecto 138
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
Gestão de Projecto 139
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
Gestão de Projecto 140
� Pretende-se controlar quando se começa a trabalhar com as alterações que os outros entretanto fizeram
Espaço de Trabalho Privado
� 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?
Gestão de Projecto 141
progredir?
Espaço de Trabalho Privado
� 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
Gestão de Projecto 142
� Integrar o nosso código com o trabalho das outras pessoas
� A integração pode ser:� Contínua� Diferida
Espaço de Trabalho Privado
� 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
Gestão de Projecto 143
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
Gestão de Projecto 144
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
Espaço de Trabalho Privado
� 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
Gestão de Projecto 145
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
Gestão de Projecto 146
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
Gestão de Projecto 147
� 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
Gestão de Projecto 148
� 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
Gestão de Projecto 149
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
Gestão de Projecto 150
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
Gestão de Projecto 151
� 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
Gestão de Projecto 152
� 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
Construção Privada do Sistema
� Solução� Antes de confirmar o código deve-se construir o sistema usando uma construção privada similar à construção da noite
Gestão de Projecto 153
Construção Privada do Sistema
� 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
Gestão de Projecto 154
detalhes relacionado com entrega e empacotamento possam ser omitidos
� Incluir todas as dependências� Incluir todos os componentes que dependem da alteração
Construção Privada do Sistema
� Pode ser feita uma construção completa ou uma construção incremental
� Deve ser feita uma construção completa sempre que:
Gestão de Projecto 155
� 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
Construção Privada do Sistema
� 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
Gestão de Projecto 156
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
Gestão de Projecto 157
� Problema� Como garantir que a construção na sequência activa que resulta da integração dos espaços de trabalho é fiável?
Construção de Integração
� 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
Gestão de Projecto 158
partir de código já confirmado o problema já está criado
Construção de Integração
� 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
Gestão de Projecto 159
� Reproduzível� Similar à construção do produto final� Automatizado ou requerendo pouca intervenção
� Mecanismos de notificação e história
Construção de Integração
� 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:
Gestão de Projecto 160
em:� Quanto tempo demora a construir o sistema
� A frequência de alterações ao sistema
Construção de Integração
� 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
Gestão de Projecto 161
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
Gestão de Projecto 162
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
Sequência de Terceira Parte
� Problema� Qual a estratégia mais eficaz de coordenar as versões de componentes externos com versões do código do produto?
Gestão de Projecto 163
Sequência de Terceira Parte
� 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
Gestão de Projecto 164
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
Sequência de Terceira Parte
� 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
Gestão de Projecto 165
desta sequência de código
Sequência de Terceira Parte
� 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
Gestão de Projecto 166
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
Gestão de Projecto 167
submissões ao sistema de controlo de versões?
� Quanto tempo se deve esperar antes confirmar as alterações?
Confirmação de Nível Tarefa
� 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
Gestão de Projecto 168
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
Confirmação de Nível Tarefa
� 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
Gestão de Projecto 169
granularidade reduz a sobrecarga de confirmações
� Uma história detalhada de alterações permite uma recuperação selectiva
Confirmação de Nível Tarefa
� Solução� Fazer uma confirmação por cada tarefa consistente de pequena granularidade
� Cada alteração deve representar um estado consistente do sistema
Gestão de Projecto 170
Confirmação de Nível Tarefa
� 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
Gestão de Projecto 171
� 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
Confirmação de Nível Tarefa
� 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
Gestão de Projecto 172
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
Gestão de Projecto 173
� É 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?
Teste de Despistagem
� 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
Gestão de Projecto 174
pode ser muito demorado� Testes que demoram muito a executar levam a que o programador aumente o tempo entre integrações
Teste de Despistagem
� 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
Gestão de Projecto 175
automatizados
Teste de Despistagem
� 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
Gestão de Projecto 176
programadores testarem as suas alterações entre de submeterem o seu espaço de trabalho
Teste de Despistagem
� 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
Gestão de Projecto 177
sistema que é o nosso alvo� Poder ser executado pelos programadores como parte do processo de garantia de qualidade
Teste de Despistagem
� 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
Gestão de Projecto 178
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
Gestão de Projecto 179
� 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
Gestão de Projecto 180
� 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:
Gestão de Projecto 181
� 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
Gestão de Projecto 182
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?
Gestão de Projecto 183
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
Gestão de Projecto 184
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
Gestão de Projecto 185
� 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
Gestão de Projecto 186
� 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
Gestão de Projecto 187
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
Gestão de Projecto 188
regras muitos restritivas acerca de como e quando se pode confirmar
� Numa Sequência Activa as regras devem ser menos restritivas
Política da Sequência
� 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?
Gestão de Projecto 189
Política da Sequência� Cada sequência de código tem objectivos diferentes� Depuração� Entrega� Portar para outra plataforma� Nova versão
Gestão de Projecto 190
� ...
� Cada sequência tem requisitos de estabilidade diferentes
� É difícil garantir que os programadores sigam as políticas
Política da Sequência
� 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
Gestão de Projecto 191
� 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
Gestão de Projecto 192
� 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
Gestão de Projecto 193
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
Política da Sequência
� Aspectos por resolver� É necessário utilizar automatização e ter em consideração a cultura da equipa
� Usar o ANT para fazer auditorias
Gestão de Projecto 194
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
Gestão de Projecto 195
� 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
Gestão de Projecto 196
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
Gestão de Projecto 197
� 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
Gestão de Projecto 198
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
Gestão de Projecto 199
� 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
Gestão de Projecto 200
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
Gestão de Projecto 201
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
Gestão de Projecto 202
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
Gestão de Projecto 203
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
Gestão de Projecto 204
� 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
Gestão de Projecto 205
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
Gestão de Projecto 206
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
Gestão de Projecto 207
� 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
Gestão de Projecto 208
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
Gestão de Projecto 209
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
Gestão de Projecto 210
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
Gestão de Projecto 211
� 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
Gestão de Projecto 212
� 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
Gestão de Projecto 213
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
Gestão de Projecto 214
� 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
Gestão de Projecto 215
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
Gestão de Projecto 216
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
Gestão de Projecto 217
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
Gestão de Projecto 218
� 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
Gestão de Projecto 219
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
Gestão de Projecto 220
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
Gestão de Projecto 221
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.
Gestão de Projecto 222
� Stephen Berczuk e Brad Appleton. Software Configuration Management Paterns. Addison-Wesley. 2003. http://www.scmpatterns.com/
Top Related