Métodos Ágeis de desenvolvimento de software

Prévia do material em texto

Métodos Ágeis de desenvolvimento de
software.
A princípio os métodos ágeis, eles são formatos onde trabalho um formato diferente de
abordagem tradicional de desenvolvimento e a partir disso, conseguimos trabalhar algumas
características pessoais dentro dos métodos ágeis.
Para que tenhamos esse tipo de metodologias ágeis, trabalhando dentro do nosso formato
desenvolvimento de software, dentro dessas necessidades surgiu o manifesto ágil.
Manifesto ágil
Um manifesto onde alguns grupos de pessoas com muita experiência em qualidade de
software, fizeram um manifesto, ou seja, fizeram alguns tratados onde eles declaram o
formato que pode ser uma empresa de desenvolvimento de software, com formato ágil e
eles deixaram esse manifesto, ou seja, linhas de instruções de como ter uma empresa ágil
no formato de desenvolvimento de software (www.manifestoagil.com.br).
Extreme Program ou XP
O XP ou programação extrema, tem por objetivo aplicar aos responsáveis pelo
desenvolvimento:
● Valores
● Princípios
● Processos
● Práticas ao extremo, para que haja qualidade de software.
O XP ela visa uma abordagem, uma prática do desenvolvedor de qualidade de software,
mais em termos de perfil de trabalhador, então a princípio ele agrega valores que são,
comunicação, a simplicidade, feedback, coragem e respeito, como valores para se trabalhar
dentro de um ambiente ágil e os princípios básicos, ou seja os pilares e que se desenvolve,
um projeto ou uma cultura ágil dentro de uma empresa.
● Feedback rápido
● Presumir simplicidade
● Mudanças incrementais
● Abraçar as mudanças
● Trabalho de alta qualidade
A partir desses princípios começa-se a trabalhar os seus processos;
http://www.manifestoagil.com.br
● Design
● Codificação
● Testes
Embora tenha vários autores que definem algumas práticas do XP, usaremos abordagem do
material, a abordagem de Teles em 2004, onde ele define planejamento como uma prática
do XP, pequenas versões, ou seja, sempre que é feito um conjunto de funcionalidades é
liberado uma nova versão do sistema.
A metáfora, que é entender a realidade do cliente e utilizar os termos de comunicação de
negócio, é importante para a sintonia entre as partes, evitando que a equipe técnica utilize
conceitos e palavras fora da área, projeto simples.
● Simplicidade no software, um time coeso, um time que se comunica com frequência.
● Testes de aceitação, nesse aspecto o teste é feito pelo cliente.
● Ritmo Sustentável, onde o ritmo de trabalho normal em um projeto bem planejado,
costuma ser de 40 horas por semana, 8 horas por dia, evitando hora extra, se o
projeto necessitar de horas extras, por mais de duas semanas é porque tem um
problema mais grave que precisa ser corrigido, nesse aspecto temos uma métrica ,
onde precisamos trabalhar esses aspectos de hora.
● Reunião em Pé, que é no máximo 10 minutos, que também chamado reunião de
elevador ou conversa de elevador.
● Posse coletiva, o código pode ser alterado, várias pessoas podem utilizar o mesmo
código fonte, desenvolvido por qualquer programador e pode fazer essas alterações,
isso consegue-se a partir do momento que o código trabalhado por profissionais, ele
utilize padrões; utilize design patterns.
● Desenvolvimento orientado a testes, onde nesse formato, geralmente nos testes,
nós temos uma abordagem; trabalhamos o código em si e depois testamos e nesse
nós iremos na contramão, trabalhando XP já temos os testes e devemos programar
em cima dos testes, por exemplo, se tivermos um teste que precisamos saber um
valor de determinado campo ou variável caixa de texto, que ele só pode receber
entre 1 e 10, já iremos fazer o programa a partir do teste para que ele receba entre 1
e 10. Então primeiro tem o teste e a partir do teste desenvolvo o programa.
● Refatoração que é uma boa prática de código, onde nós temos o processo de
melhoria contínua do código, por exemplo criamos um código muito grande e
distribuímos esse código em funções, ou seja, observo nesse código o que ele se
repete, a partir das repetições deste código, conseguimos extrair uma função por
exemplo que eu posso somente chamá-la, então vamos supor que tenhamos 100
linhas, dessa 100 linhas 5 são repetidas exatamente iguais, ao invés de colocarmos
5 linhas, simplesmente criamos uma função que tenha essa linha e chamo ela 5
vezes, então fazemos com que o software fique mais limpo, que o software fique
melhor processado no computador e refatorado.
● Integração contínua, sempre que uma funcionalidade é criada ou alterada, uma nova
versão é imediatamente incorporada e disponibilizada para usuários.
Uma das práticas do XP, é trazer o cliente para o ambiente de desenvolvimento, ou seja ele
ficar em local ou on side.
Diferente dos outros formatos ou dos outros modelos que nós estávamos falando, no XP
temos a necessidade de trazer o meu cliente para perto, então para ser um método ágil, ele
trabalha muito com a meta da entrega, com uma pessoa para tirar as dúvidas, entender
melhor qual é a necessidade dos cliente, mas existem também alguns clientes que não tem
essa possibilidade.
Formato de ambiente de trabalho, anteriormente só estávamos falando de desenvolvimento
de software, agora estamos falando de pessoas, características, formas de se trabalhar,
horas de trabalho, o que é uma entrega rápida ou não. Dentro desse formato nós temos as
regras e a metodologia XP é uma das mais importantes dentro do mundo ágil, por isso é
importante conhecê-las.
Engenharia de requisitos.
Para Pressman, a análise de requisitos resultam na especificação das características
operacionais do software, podemos compreender melhor engenharia de requisitos a partir
de três importantes conceitos:
● Requisitos funcionais: visam trabalhar com aspectos físicos e lógicos da implantação
de sistema, que busca projetar para estrutura do cliente o sistema ou prover uma
nova estrutura, busca responder as perguntas; Qual plataforma irá ser executada?
Qual o sistema operacional? Qual o tipo de rede? Qual o idioma? Rede elétrica?
Cloud ou local? Qual tipo de banco?
● Requisitos não funcionais; Para Sommerville os requisitos não funcionais são as
restrições aos serviços ou funções oferecidas pelo sistema, inclui restrição de time,
restrição de processo de desenvolvimento e restrições impostas pelas normas,
características em relação a entrada de dados
● Regras de negócio; que são todas as regras específicas de uma empresa ou ramo
de atividade, que podem ou não serem incorporados em um sistema de informação.