Capítulo 3 - Desenvolvimento Ágil de Softwaresebastiao/Ensino/UBI/2017-2018/ES... ·...

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


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.


-Plan dirigido e desenvolvimento ágil


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.


Métodos ágeis


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.


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.


Técnicas de desenvolvimento ágil


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.


O ciclo de lançamento na programação extrema


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.


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.


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


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.


A história da prescrição de medicamentos


Exemplos de tarefas para a prescrição de

medicamentos


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.


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.


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.


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.


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.


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.


Descrição do caso de teste para a verificação da

dose de medicamento


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.


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.


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.


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.



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.


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.


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.


Scrum ciclo de sprint


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.


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.


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.


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.


Scrum


Dimensionamento métodos ágeis


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.


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.


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.


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.


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.


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.


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.


Fatores ágeis e baseados em plano


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.


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.


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?


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.


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.


Fatores em grandes sistemas


Agilidade da IBM no modelo em escala


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.


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.


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.


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.


Capítulo 3 - Desenvolvimento Ágil de Softwaresebastiao/Ensino/UBI/2017-2018/ES... ·...

Documents

Transcript of Capítulo 3 - Desenvolvimento Ágil de Softwaresebastiao/Ensino/UBI/2017-2018/ES... ·...