Upload
dinhtu
View
214
Download
0
Embed Size (px)
Citation preview
Capítulo 3 - Desenvolvimento Ágil de Software
12017/2018 Capítulo 3 Desenvolvimento Agile de Software
Assuntos abordados
Métodos ágeis
Técnicas de desenvolvimento ágil
Gestão ágil de projetos
Dimensionamento de métodos ágeis
Capítulo 3 Desenvolvimento Agile de Software 22017/2018
Desenvolvimento de software rápido
O desenvolvimento rápido e consequentemente a entrega rápida, são
agora frequentemente o requisito mais importante para sistemas de
software
As empresas operam muito rapidamente, os requisitos estão em
constante mudança, praticamente é impossível produzir um conjunto de
requisitos de software estáveis.
Software tem que evoluir rapidamente para refletir mudanças nas
necessidades de negócios.
O desenvolvimento seguindo o modelo plano é essencial para alguns
tipos de sistema, mas não atende a essas necessidades de negócios.
Métodos ágeis de desenvolvimento surgiu no final de 1990, cujo
objetivo era reduzir radicalmente o tempo de entrega para sistemas
de software
32017/2018 Capítulo 3 Desenvolvimento Agile de Software
Desenvolvimento ágil
As tarefas de especificação, design e implementação
são intercaladas.
O sistema é desenvolvido como uma série de versões
ou com incrementos.
Entrega frequente de novas versões para avaliação
Suporte para ferramentas extensas (por exemplo,
ferramentas de testes automatizados) utilizada para
suportar o desenvolvimento.
Documentação mínima - foco no código.
42017/2018 Capítulo 3 Desenvolvimento Agile de Software
Desenvolvimento plano e desenvolvimento ágil
Desenvolvimento plano
Iteração ocorre dentro das atividades.
Desenvolvimento ágil
Especificação, projeto, implementação e testes estão
intercaladas e as saídas do processo de desenvolvimento são
decididos através de uma negociação durante o processo de
desenvolvimento de software.
62017/2018 Capítulo 3 Desenvolvimento Agile de Software
Métodos ágeis
A insatisfação com os custos gerais envolvidos no design de
software nos anos 1980 e 1990 levaram à criação de métodos
ágeis. Estes métodos:
Foco no código em vez do design
São baseados numa abordagem iterativa para desenvolvimento
software
São destinados para entregar rapidamente software functional e evoluir
este rapidamente para atender às necessidades de mudança.
O objectivo dos métodos ágeis é reduzir os custos no processo de
software (por exemplo, por documentação limitante) e de ser capaz
de responder rapidamente as mudanças nos requisitos sem
retrabalho excessivo.
82017/2018 Capítulo 3 Desenvolvimento Agile de Software
Os princípios dos métodos ágeis
Capítulo 3 Desenvolvimento Agile de Software
10
Princípio Descrição
Envolvimento do
Cliente
Os clientes devem estar intimamente envolvidos em todo o
processo de desenvolvimento. O Seu papel é fornecer e
priorizar novos requisitos do sistema e avaliar as iterações do
sistema.
Entrega incremental O software é desenvolvido em incrementos com o cliente a
especificar os requisitos para serem incluídos em cada
incremento.
As pessoas não
processos
As habilidades da equia de desenvolvimento deve ser
reconhecido e explorado. Os membros da equipa devem ter
autonomia para desenvolver suas próprias formas de trabalhar
sem processos prescritivos.
Aceitar a mudança Alterar os requisitos do sistema obdecendo às mudanças e
assim projetar o sistema para implementar essas mudanças.
Manter a simplicidade Foco na simplicidade, tanto no software que está a ser
desenvolvido como no processo de desenvolvimento. Sempre
que possível, trabalhar ativamente para eliminar a complexidade
do sistema.2017/2018
Aplicabilidade do método ágil
Desenvolvimento de produtos, onde uma empresa de
software está a desenvolver um produto de pequeno ou
médio porte para venda.
Praticamente todos os produtos de software e aplicativos são
agora desenvolvido utilizando uma abordagem ágil
Desenvolvimento de sistemas personalizados dentro de
uma organização, onde há um claro compromisso do
cliente para se envolver no processo de
desenvolvimento e onde existem algumas regras e
regulamentos externos que afetam o software.
112017/2018 Capítulo 3 Desenvolvimento Agile de Software
Programação extrema
Um método ágil muito influente, desenvolvido na décadade 1990, que introduziu uma série de técnicas dedesenvolvimento ágil.
Extreme Programming (XP) tem uma abordagem'extrema' para o desenvolvimento iterativo.
Novas versões podem ser construídas várias vezes por dia;
Incrementos são entregues aos clientes a cada 2 semanas;
Todos os testes devem ser executados para cada construção ea construção só é aceite se os testes forem executados comêxito.
132017/2018 Capítulo 3 Desenvolvimento Agile de Software
O ciclo de lançamento na programação extrema
142017/2018 Capítulo 3 Desenvolvimento Agile de Software
Práticas de programação extremas
15
Princípio ou prática Descrição
Planeamento
incremental
Cada incremento é alvo de um planeamento individual.
Lançamentos pequenos Um conjunto útil mínimo de funcionalidades que fornece o valor
do negócio é desenvolvido em primeiro lugar. Versões do
sistema são frequentes e incrementalmente adicionam-se
funcionalidade.
Design simples Design é realizado para atender às exigências atuais e nada
mais.
Testar o
desenvolvimento
Uma estrutura de teste de unidade automatizado é usado para
escrever testes para uma nova funcionalidade antes que a
funcionalidade seja implementada.
Refatoração Todos os desenvolvedores são esperados para refactoro código
continuamente o mais rapidamente possível melhorias de
código são encontradas. Isso mantém o código simples e de
fácil manutenção.
2017/2018 Capítulo 3 Desenvolvimento Agile de Software
Práticas de programação extremas
Capítulo 3 Desenvolvimento Agile de Software
16
Programação em pares Os programadores trabalham em equipa, verificando o trabalho
uns dos outros e proporcionando o apoio.
Propriedade coletiva A equipa de programadores trabalha em todas as áreas do
sistema, há algumas especificações de especialização a
desenvolver e todos os programadores assumem a
responsabilidade por todo o código.
Integração contínua Assim que uma tarefa estiver concluída, ela é integrada no
sistema. Depois dessa integração, todos os testes de unidade
no sistema deve ser feitos.
Ritmo sustentável Grandes quantidades de horas extras não são considerados
aceitáveis, isso origina a redução da qualidade do código e da
produtividade a médio prazo.
On-site do cliente Um representante do utilizador final do sistema (o cliente) deve
estar disponível a tempo inteiro para o uso da equipa de
desenvolvimento. Em um processo de programação extrema, o
cliente é um membro da equipa de desenvolvimento e é
responsável por trazer os requisitos de sistema para a equipa
de implementação.2017/2018
Programação extrema e princípios ágeis
Desenvolvimento incremental é suportado através de
pequenas e frequentes versões do sistema.
O envolvimento do cliente significa o envolvimento do
cliente em tempo integral com a equipa.
As mudanças são suportadas de lançamentos regulares
de versões do sistema.
Manter a simplicidade através de refactoring constante
de código.
172017/2018 Capítulo 3 Desenvolvimento Agile de Software
Práticas influentes na programação extrema
Programação extrema tem um foco técnico e não é fácil
de integrar com a prática de gestão na maioria das
organizações.
Consequentemente, enquanto o desenvolvimento ágil
utiliza práticas da programação extrema, o método como
originalmente definido não é amplamente utilizado.
Práticas chaves
Uso do conhecimento dos utilizadores para a especificação
Refatoração
Testar sempre os desenvolvimentos
Programação em equipa
182017/2018 Capítulo 3 Desenvolvimento Agile de Software
Uso dos utilizadores para requisitos
Na programação estrema, o cliente ou utilizador são parte da
equipa, e são responsáveis pela tomada de decisões sobre
requisitos.
Os requisitos do utilizador são expressos como narrativas dos
utilizadores ou cenários/situações.
Estes são documentados e a equipa de desenvolvimento
dividi-os em tarefas de execução. Essas tarefas são a base
de estimativas de custos e do cronograma.
O cliente escolhe os requisitos para inclusão na próxima
versão, com base nas suas prioridades e nas estimativas do
cronograma.
192017/2018 Capítulo 3 Desenvolvimento Agile de Software
Exemplos de tarefas para a prescrição de
medicamentos
212017/2018 Capítulo 3 Desenvolvimento Agile de Software
Refatoração
Em engenharia de software é natural projetar umamudança. Assim, vale a pena gastar tempo e esforçoantecipando mudanças, assim reduz-se os custos maistarde no ciclo de vida.
Contudo, programação extrema sustenta que isso éimpraticável, porque as alterações não podem serantecipados de forma confiável.
Em vez disso, propõe a melhoria constante do código(refactoring) para fazer alterações mais facilmentequando estas têm de ser implementadas.
222017/2018 Capítulo 3 Desenvolvimento Agile de Software
Refatoração
A equipa de programação procura possíveis melhorias e
fazer essas melhorias no software, mesmo onde não há
necessidade imediata das mesmas.
Isso melhora a compreensibilidade do software e assim
reduz a necessidade de documentação.
Mudanças são mais fáceis de fazer, porque o código é
bem estruturado e claro.
No entanto, algumas mudanças requerem nova
arquitetura e isso é muito mais caro.
232017/2018 Capítulo 3 Desenvolvimento Agile de Software
Exemplos de refazer trabalho
Reorganização de uma hierarquia de classes para
remover código duplicado.
Arrumar e renomear atributos e métodos para torná-los
mais fáceis de entender.
A substituição de código embutido com chamadas para
métodos que foram incluídos numa biblioteca de
programas.
242017/2018 Capítulo 3 Desenvolvimento Agile de Software
Testar o desenvolvimento
O teste é central para a programação extrema, esta
desenvolveu uma abordagem onde o programa é
testado depois de cada alteração foi feita.
Características dos testes em programação extrema:
Testar o desenvolvimento primeiro.
Teste incremental dos desenvolvimento de cenários.
O envolvimento do utilizador no desenvolvimento de testes e
validação.
Série de testes automatizados são usados para executar todos
os testes de componentes cada vez que uma nova versão é
construída.
252017/2018 Capítulo 3 Desenvolvimento Agile de Software
Desenvolvimento do plano de testes
Escrever testes antes do código esclarece as exigênciasa serem implementadas.
Os testes são programados para que possam serexecutadas automaticamente. O teste inclui umaverificação que tenha executado corretamente.
Geralmente baseia-se num framework de testes, tais como jUnit.
Todos os testes anteriores e novos são executadosautomaticamente quando uma nova funcionalidade éadicionada, verifica-se assim que a nova funcionalidadenão introduziu erros.
262017/2018 Capítulo 3 Desenvolvimento Agile de Software
O envolvimento do cliente
O papel do cliente no processo de teste é ajudar a desenvolver
testes de aceitação para os requisitos que estão a ser
implementados no próximo lançamento do sistema.
O cliente faz parte da equipa e escreve testes a par com o
progresso do desenvolvimento. Todo o código novo é validado para
garantir que este é o que o cliente precisa.
No entanto, as pessoas que adotam o papel de cliente têm pouco
tempo disponível e, portanto, não pode trabalhar em tempo integral
com a equipa de desenvolvimento. Eles podem sentir que fornecer
os requisitos é o suficiente para a sua contribuição e assim podem
estar relutantes em se envolver no processo de teste.
272017/2018 Capítulo 3 Desenvolvimento Agile de Software
Descrição do caso de teste para a verificação da
dose de medicamento
282017/2018 Capítulo 3 Desenvolvimento Agile de Software
Automação de testes
Automação de testes significa que os testes são escritos como
componentes executáveis antes que a tarefa seja implementada
Estes componentes de teste deverão ser stand-alone, deve simular a
apresentação de entrada a ser testado e deve verificar se o resultado
corresponde a especificação de saída. Uma estrutura de teste
automatizado (por exemplo o jUnit) é um sistema que faz com que seja
fácil de escrever testes executáveis e apresentar um conjunto de testes
para execução.
Dado que a experimentação é automatizado, não é sempre um
conjunto de testes que podem ser rapidamente e facilmente
executado
Sempre que qualquer funcionalidade é adicionada ao sistema, os testes
podem ser executados e os problemas que o novo código introduziu
podem ser capturados imediatamente.
292017/2018 Capítulo 3 Desenvolvimento Agile de Software
Problemas com os testes no desenvolvimento
Programadores preferem a programação aos testes e às
vezes não planeiam bem os testes. Por exemplo, podem
escrever testes incompletos que não verificam para todas as
exceções possíveis que possam ocorrer.
Alguns testes podem ser muito difícil de escrever de forma
incremental. Por exemplo, uma interface de utilizador
complexa, muitas vezes é difícil escrever testes de unidade
para o código que implementa a 'lógica de exibição' e fluxo de
trabalho entre as telas.
É difícil julgar a completude de um conjunto de testes.
Embora possa ter um monte de testes do sistema, o seu
conjunto de teste pode não fornecer uma cobertura completa.
302017/2018 Capítulo 3 Desenvolvimento Agile de Software
A programação em pares
A programação em equipa envolve programadores quetrabalham juntos, desenvolvem código juntos.
Isso ajuda a desenvolver código comum e a que toda aequipa o conheça.
Serve como um processo de avaliação informal comocada linha de código é olhado por mais do que umapessoa.
Estimula a refatoração, onde toda a equipe podebeneficiar com a melhora do código do sistema.
312017/2018 Capítulo 3 Desenvolvimento Agile de Software
A programação em pares
Na programação em pares, em alguns casos os programadores
sentam-se juntos no mesmo computador para desenvolver o
software.
Pares são criados dinamicamente para que todos os membros da
equipa trabalhem uns com os outros durante o processo de
desenvolvimento.
A partilha de conhecimentos que acontece durante a programação
em pares é muito importante, pois reduz os riscos globais para um
projeto quando algum membro da equipa sair.
A programação em pares não é necessariamente ineficaz e há
alguma evidência que sugere que um par a trabalhar em conjunto é
mais eficiente do que 2 programadores trabalhar separadamente.
322017/2018 Capítulo 3 Desenvolvimento Agile de Software
Gestão ágil de projetos
A principal responsabilidade dos gestores de projeto de
software é gerir o projeto para que o software seja
entregue no prazo e dentro do orçamento.
A abordagem padrão para gerir projetos é orientada
para o plano. Gestores elaboram um plano para o
projeto mostrando o que deve ser entregue, quando
deve ser entregue e quem irá trabalhar no
desenvolvimento do projeto.
Gestão ágil de projetos requer uma abordagem
diferente, que é adaptada para o desenvolvimento
incremental e às práticas utilizadas em métodos ágeis.
342017/2018 Capítulo 3 Desenvolvimento Agile de Software
Scrum
Scrum é um método ágil que se concentra na gestão do
desenvolvimento iterativo ao invés de práticas ágeis
específicas.
Existem três fases no scrum.
A fase inicial é uma fase de esboço do planeamento onde se
estabelecem os objetivos gerais para o projeto e se projeta a
arquitetura do software.
Isto é seguido por uma série de ciclos de sprints, onde cada
ciclo desenvolve um incremento do sistema.
A fase de encerramento do projeto, alem da entrega total do
software, envolve toda e completa documentação necessária,
formação.
352017/2018 Capítulo 3 Desenvolvimento Agile de Software
Terminologia scrum
Termo Scrum Definição
Equipe de
desenvolvimento
Um grupo de auto organizado de programadores de software, onde não
devem ser mais do que 7 pessoas. Eles são responsáveis pelo
desenvolvimento do software e outros documentos essenciais do projeto.
Incremento do produto
potencialmente
utilizável
O incremento de software que é entregue a partir de um sprint. A idéia é que
este deve ser 'potencialmente utilizável', que significa que ele está em um
estado acabado e não necessita de nenhum trabalho adicional, tais como
testes, é necessário incorporá-lo no produto final. Na prática, isso nem
sempre é possível.
Product backlog Esta é uma lista de itens 'fazer' que a equipe Scrum deve enfrentar. Eles
podem ser definições de recurso para o software, requisitos de software, ou
descrições de tarefas suplementares que são necessárias, tais como a
definição de arquitetura ou a documentação do utilizador.
Product Owner Um indivíduo (ou possivelmente um pequeno grupo), cujo trabalho é
identificar características ou requisitos do produto, priorizar estes para o
desenvolvimento e rever continuamente a lista de tarefas do produto para
garantir que o projeto continua a atender as necessidades críticas de
negócios. O Product Owner pode ser um cliente, mas também pode ser um
gestor de produto numa empresa de software ou outro representante das
partes interessadas.362017/2018 Capítulo 3 Desenvolvimento Agile de Software
Terminologia scrum
Termo Scrum DefiniçãoScrum A reunião diária da equipa, onde se analisa os progressos e prioriza
trabalho a ser feito naquele dia. Idealmente, esta deve ser uma breve
reunião que inclui toda a equipa.
Scrum Master O Scrum Master é responsável por assegurar que o processo Scrum é
seguido e orienta a equipa. Ele é responsável pela ligação com o resto
da empresa e para garantir que a equipa Scrum não é desviada por
interferência externa.
Sprint A iteração de desenvolvimento. Sprints são geralmente 2-4 semanas de
duração.
Velocidade Uma estimativa de esforço da equipa num único sprint. Compreender a
velocidade da equipa ajuda a estimar o que pode ser realizado num
sprint e fornece uma base para medir e melhorar o desempenho.
372017/2018 Capítulo 3 Desenvolvimento Agile de Software
O ciclo de sprint Scrum
Sprint são de comprimento fixo, normalmente 2-4
semanas.
O ponto de partida para o planeamento é a lista de
tarefas, que é a lista de trabalho a ser feito no projeto.
A fase de seleção envolve toda a equipa de projeto que
trabalham com o cliente para selecionar os recursos e
funcionalidades da lista de tarefas a serem
desenvolvidas durante o sprint.
392017/2018 Capítulo 3 Desenvolvimento Agile de Software
O ciclo de Sprint
Uma vez que estes são acordados, a equipe se
organizar para desenvolver o software.
Durante esta fase, a equipa está isolada do cliente e da
organização, com todas as comunicações canalizadas
através do chamado 'Scrum master'.
O papel do mestre de Scrum é proteger a equipa de
desenvolvimento de distrações externas.
No final do sprint, o trabalho feito é revisto e
apresentado às partes interessadas. O próximo ciclo de
Sprint começa.
402017/2018 Capítulo 3 Desenvolvimento Agile de Software
Trabalho em equipa no Scrum
O 'mestre Scrum' é um facilitador, que organiza reuniões
diárias, controla o trabalho a ser feito, registra decisões,
mede o progresso contra o atraso e comunica com o
clientes e outros gestores fora da equipe.
Toda a equipa participa das reuniões diárias curtas
(scrums), onde todos os membros da equipa partilham
informações, descrevem o seu progresso desde a última
reunião, problemas que surgiram e o que está previsto
para o dia seguinte.
Isto significa que todos na equipa sabem o que está a acontecer
no projeto e, se surgirem problemas, podem re-planear trabalho
de curto prazo para lidar com esses problemas.
412017/2018 Capítulo 3 Desenvolvimento Agile de Software
Benefícios de Scrum
O produto é dividido em um conjunto de pedaços geráveis e
compreensíveis.
Requisitos instáveis não têm progressão, rapidamente são
detetáveis.
Toda a equipa tem visibilidade de tudo e, consequentemente, a
comunicação da equipa é melhorada.
Os clientes recebem o incremento e ficam em condições de darem
feedback sobre como o produto funciona.
A confiança entre clientes e programadores é estabelecida e uma
cultura positiva é criada em que todo mundo espera que o projeto
tenha sucesso.
422017/2018 Capítulo 3 Desenvolvimento Agile de Software
Dimensionamento de métodos ágeis
Métodos ágeis têm-se revelado bem sucedidos para
pequenos e médios projetos feitos sob medida que
podem ser desenvolvidas por uma equipa pequena.
Às vezes é argumentado que o sucesso destes métodos
vem por causa das comunicações melhoradas que é
possível quando todos trabalham juntos.
Intensificação dos métodos ágeis envolve mudar estes
para lidar com projetos maiores, mais longos, onde há
várias equipes de desenvolvimento, talvez a trabalhar
em locais diferentes.
452017/2018 Capítulo 3 Desenvolvimento Agile de Software
Problemas práticos com métodos ágeis
A informalidade de desenvolvimento ágil é incompatível
com a abordagem legal para a definição do contrato que
é comumente usado em grandes empresas.
Métodos ágeis são mais adequados para o
desenvolvimento de novos software, em vez de
manutenção de software. No entanto, a maioria dos
custos de software em grandes empresas vêm de
manutenção dos seus sistemas de software existentes.
Métodos ágeis métodos são projetados para pequenas
equipas, ainda que atualmente o desenvolvimento de
software envolva equipas distribuídas por todo o mundo.
472017/2018 Capítulo 3 Desenvolvimento Agile de Software
Questões contratuais
A maioria dos contratos de software para sistemas
personalizados são baseados em torno de uma
especificação que define o que deve ser implementado
pelo programador do sistema para o cliente sistema.
No entanto, isso exclui especificação intercalar e
desenvolvimento como é a norma no desenvolvimento
ágil.
Um contrato que paga por tempo de desenvolvimento
em vez da funcionalidade necessária.
No entanto, isso é visto como um risco elevado por muitos
departamentos jurídicos porque o que tem de ser entregue não
é garantido.
482017/2018 Capítulo 3 Desenvolvimento Agile de Software
Métodos ágeis e manutenção de software
A maioria das organizações gastam mais em manutenção de
software existente do que no novo desenvolvimento de software.
Então, se os métodos ágeis são para ser bem sucedidos, eles têm
de apoiar a manutenção, bem como o desenvolvimento original.
Duas questões-chave:
sistemas que são desenvolvidos usando uma abordagem sustentável
ágil, é dada a ênfase no processo de desenvolvimento de minimizar
documentação formal?
Podem os métodos ágeis serm utilizados de forma eficaz para a
evolução de um sistema em resposta a solicitações de mudança do
cliente?
Podem surgir problemas se a equipa de desenvolvimento original
não pode ser mantida.
492017/2018 Capítulo 3 Desenvolvimento Agile de Software
Manutenção ágil
Os principais problemas são:
Falta de documentação do produto
Manter os clientes envolvidos no processo de desenvolvimento
Manter a continuidade da equipa de desenvolvimento
O desenvolvimento ágil conta com a equipa de
desenvolvimento para saber e compreender o que tem
que ser feito.
Para os sistemas de longa vida, este é um problema
real, como os programadores originais não continuam
no projeto.
502017/2018 Capítulo 3 Desenvolvimento Agile de Software
Métodos ágeis e planeados
A maioria dos projetos incluem elementos de processos baseados em
modelos planos e ágeis. Decidir sobre o equilíbrio depende:
É importante ter uma especificação muito detalhada e design antes de
passar para a implementação? Se assim for, provavelmente precisará
usar uma abordagem orientada para o plano.
É uma estratégia de entrega incremental, onde entregar o software ao
clientes e obter feedback rápido a partir deles é realista? Se assim for,
considerar o uso de métodos ágeis.
Quão grande é o sistema que está a ser desenvolvido? Métodos ágeis
são mais eficazes quando o sistema pode ser desenvolvido com uma
equipa pequena que pode se comunicar informalmente. Isto pode não ser
possível para sistemas de grande porte que exigem equipas de
desenvolvimento maiores, assim uma abordagem baseada em plano
deve ser usada.
512017/2018 Capítulo 3 Desenvolvimento Agile de Software
Princípios ágeis e prática organizacional
Princípio PráticaO envolvimento do cliente Isso depende de ter um cliente que está disposto e capaz de
passar tempo com a equipa de desenvolvimento e que podem
representar todos os stakeholders do sistema. Muitas vezes, os
representantes dos clientes têm outras obrigações ao mesmo
tempo e não podem desempenhar um papel integral no
desenvolvimento de software.
Aceite a mudança Periorizar as mudanças pode ser extremamente difícil,
especialmente em sistemas para os quais há muitas partes
interessadas. Tipicamente, cada uma das partes interessadas
transmite diferentes prioridades para diferentes alterações.
Entrega incremental Iterações rápidas e planeamento a curto prazo para o
desenvolvimento nem sempre se encaixa com os ciclos de
planeamento a longo dos negócios e do marketing. Os gestores
de marketing podem precisar de saber vários meses de
antecedência qual o produto que apresenta para preparar uma
campanha de marketing eficaz.
Manter a simplicidade Sob pressão dos prazos de entrega, os membros da equipa
podem não ter tempo para realizar simplificações no Sistema.
522017/2018 Capítulo 3 Desenvolvimento Agile de Software
Problemas do sistema
Quão grande é o sistema que está a ser desenvolvido?
Métodos ágeis são mais eficazes numa equipa pequena que pode
comunicar informalmente.
Que tipo de sistema está a ser desenvolvido?
Sistemas que requerem muita análise antes da implementação,
necessitam de um design bastante detalhado para realizar esta análise.
Qual é a vida útil do sistema esperado?
Sistemas de longa vida exigem documentação para comunicar a
intenções dos programadores para a equipe de suporte.
É o sistema sujeito a regulação externa?
Se um sistema é regulado, provavelmente será necessário para produzir
documentação detalhada como parte do plano de segurança do sistema.
552017/2018 Capítulo 3 Desenvolvimento Agile de Software
Pessoas e equipas
Como bom são os designers e programadores na
equipa de desenvolvimento?
Por vezes argumenta-se que os métodos ágeis exigem níveis
mais elevados do que as abordagens baseadas plano em que
os programadores simplesmente traduzem um projeto detalhado
em código.
Como a equipa de desenvolvimento se organizada?
Documentação do projeto é necessária se a equipa está
distribuída.
562017/2018 Capítulo 3 Desenvolvimento Agile de Software
Questões organizacionais
Organizações tradicionais de engenharia têm uma
cultura de desenvolvimento baseado no plano, pois esta
é a norma em engenharia.
É prática padrão organizacional desenvolver uma
especificação detalhada do sistema?
Representantes do cliente vão estar disponíveis para
fornecer feedback de incrementos do sistema?
Desenvolvimento ágil informal pode caber na cultura
organizacional da documentação detalhada?
572017/2018 Capítulo 3 Desenvolvimento Agile de Software
Métodos ágeis para grandes sistemas
Grandes sistemas são geralmente coleções de sistemas
separados que comunicam, onde equipas diferentes
desenvolvem sistemas diferentes. Frequentemente, essas
equipas trabalham em lugares diferentes, por vezes, em
diferentes fusos horários.
Grandes sistemas incluem e interagem com um número de
sistemas existentes. Muitos dos requisitos do sistema estão
preocupados com essa interação e assim realmente não se
prestam a flexibilidade e desenvolvimento incremental.
Onde vários sistemas são integrados para criar um sistema,
uma fração significativa do desenvolvimento está preocupado
com a configuração do sistema, em vez de desenvolvimento
de código original.
582017/2018 Capítulo 3 Desenvolvimento Agile de Software
Desenvolvimento em grandes sistemas
Grandes sistemas e os seus processos de desenvolvimento
são muitas vezes limitados por regras externas e
regulamentos que limitam a maneira que eles podem ser
desenvolvidos.
Grandes sistemas têm uma longa aquisição e duração
desenvolvimento. É difícil manter equipas coerentes que
sabem sobre o sistema durante esse período como,
inevitavelmente, as pessoas passarem para outros trabalhos
e projetos.
Sistemas grandes geralmente têm um conjunto diversificado
de stakeholders. É praticamente impossível envolver todas
estas diferentes partes interessadas no processo de
desenvolvimento.
592017/2018 Capítulo 3 Desenvolvimento Agile de Software
Ampliando a grandes sistemas
Uma abordagem completamente incremental para
engenharia de requisitos é impossível.
Não pode haver um dono único do produto ou representante
do cliente.
Para o desenvolvimento de sistemas de grande porte, não é
possível focar apenas no código do sistema.
Mecanismos de comunicação entre as equipes têm que ser
concebidos e utilizados.
A integração contínua é praticamente impossível. No entanto,
é essencial para manter o sistema em frequente alteração e
lançar regularmente novas versões do sistema.
622017/2018 Capítulo 3 Desenvolvimento Agile de Software
Métodos ágeis nas organizações
Os gestores de projeto que não têm experiência em métodos ágeis
podem estar relutantes em aceitar o risco de uma nova abordagem.
As grandes organizações têm muitas vezes procedimentos de
qualidade e padrões que são seguidos em todos os projetos, devido
à sua natureza burocrática, estes são suscetíveis de ser incompatível
com métodos ágeis.
Métodos ágeis parecem funcionar melhor quando os membros da
equipe têm um nível relativamente alto de habilidade.
Pode haver resistência cultural aos métodos ágeis, especialmente
nas organizações que têm uma longa história de uso de processos
de engenharia de sistemas convencionais.
642017/2018 Capítulo 3 Desenvolvimento Agile de Software
Pontos chave
Métodos ágeis são métodos incrementais de desenvolvimento que
se concentram no desenvolvimento de software rápido,
lançamentos freqüentes do software, reduzindo despesas gerais de
processo, minimizando documentação e produzir código de alta
qualidade.
Práticas ágeis de desenvolvimento incluem
Requesitos dos utilizadores para a especificação do sistema
Lançamentos freqüentes do software,
Melhoria contínua do software
Testar o desenvolvimento
Participação do cliente na equipa de desenvolvimento.
652017/2018 Capítulo 3 Desenvolvimento Agile de Software
Pontos chave
Scrum é um método ágil que oferece uma estrutura de
gestão de projeto.
É centrado em volta de um conjunto de sprints, que são
fixadosem períodos de tempo quando um incremento sistema é
desenvolvido.
Muitos métodos de desenvolvimento práticos são uma
mistura de desenvolvimento baseado em plano e ágil.
Dimensionamento métodos ágeis para grandes sistemas
é difícil.
662017/2018 Capítulo 3 Desenvolvimento Agile de Software