Metodologias ágeis
Melhoria de processo de software no desenvolvimento ágil.
De que
trata o artigo:
Este
artigo apresenta o conceito de melhoria de processo de software e sua
aplicação, utilizando abordagens de metodologias ágeis.
|
Para que serve:
O surgimento das metodologias ágeis foi de fato um importante marco na
indústria do desenvolvimento de software. Algumas definições tratam o tema como
algo revolucionário, sendo considerada uma nova disciplina de engenharia, que
modifica os valores do processo de desenvolvimento de software do mecânico
(orientado a processos e utilizando regras da ciência) para o orgânico
(dirigido por questões sobre pessoas e suas interações).
De uma forma geral, a apresentação destas metodologias trouxe mudanças
culturais em vários aspectos no desenvolvimento de software, a exemplo da
proposição de técnicas e procedimentos, até a contribuição na realização da
melhoria de processo de software (MPS).
Baseado nesse contexto de mudança cultural, uma nova forma para a
realização da melhoria de processo de software era necessária, sem que fosse
tirado o foco do "orgânico", valorizando ainda mais as pessoas e suas
competências. Nesta aula, será mostrado como é proposto o MPS nas metodologias
ágeis e sua diferença do MPS tradicional.
Para começarmos a entender um pouco mais, vamos iniciar pelo histórico
das metodologias ágeis.
Histórico
|
Para melhor entendermos o contexto do MPS em ambientes tradicionais,
devemos entender o rumo que a qualidade de software tomou a partir daquela
reunião da Otan, em 1968, na qual o termo "engenharia de software"
foi utilizado pela primeira vez por F. I. Bauer.
Naquela reunião, foi utilizado também o termo "crise do
software" para definir a situação que a indústria do software atravessava
naquele momento.
A crise foi atribuída à complexidade de desenvolver sistemas
cada vez maiores, bem como à falta de gerenciamento no processo de
desenvolvimento de software.
A partir daí, "engenheiros de software" tentaram imitar a
engenharia convencional para resolver problemas de qualidade e falhas em
sistemas de informação. Uma quantidade significativa de experiência foi obtida
através de processos de garantia da qualidade praticados na indústria de
manufatura, e essa adaptação para a indústria de software foi, em alguns casos,
um fracasso e, em outros, um sucesso, como, por exemplo, a utilização de
controle estatístico de processo (base do six sigma) para avaliação de
processos de software.
Ainda no fim da década de 1980, o controle de qualidade existente na
indústria de software era centrado no produto final e na utilização de métodos
corretivos em inspeções, no fim da linha de produção; o mesmo se mostrava pouco
efetivo para a solução de problemas gerenciais, como prazos e custos.
No início da década de 1990, o mercado substituía aquele controle de
qualidade pela garantia da qualidade com um foco centrado no processo e que
utilizava auditorias durante todo o ciclo de vida de desenvolvimento. A partir
daí, foram surgindo normas (ISO 9000-3, ISO 15504, ISO 12207), padrões (IEEE
1074, IEEE 1298) e modelos (SW-CMM, CMMI) para qualidade de software.
A partir daí, começaram a surgir os modelos para melhoria de processos
de software. A maioria é baseada no PDCA (plan-do-check-action) de Eduard
Deming. Os modelos para MPS mais utilizados foram o ideal, utilizado em
conjunto com o SW-CMM, e o modelo DMAIC, utilizado pelo six sigma.
Com o advento da garantia da qualidade, a indústria de software passou a
ser centrada em documentação, orientada a planejamento, e essa forma de
desenvolvimento de software ficou conhecida como modelo.
Nesse contexto, a melhoria do processo de software pode ser
genericamente estereotipada com as seguintes características:
I. criação de grupo responsável
pelo programa de MPS, realizando atividades de levantamento de não conformidades
e avaliação de desempenho. Na visão do modelo ideal, tem-se o software process
group engineering (sepg), e no dmaic, os green belts e black belts;
II. monitoração do processo
através de indicadores, permitindo a identificação das oportunidades de melhoria;
III. elaboração de projetos de
melhoria com base nas oportunidades identificadas em (ii);
IV. avaliação dos resultados dos
projetos de melhoria, através de critérios objetivos e previamente
estabelecidos;
V. utilização de projetos piloto
para realização dos projetos de melhoria, definidos a partir dos dados obtidos
em (iv). Desta forma, a melhoria é institucionalizada para o processo da
organização;
VI. aplicação de ações corretivas
continuamente, à medida em que uma não conformidade for encontrada;
Com a criação do manifesto ágil (www.agilemanifesto.org), em 2001, são formalizadas as metodologias
ágeis que, de certa maneira, já existiam desde o meio da década de 1990, e que
surgiram de descobertas comuns entre os participantes que, aos poucos, foram
substituindo os processos da tradicional documentação pesada e desenvolvimento
centrado no processo por abordagens mais centradas em pessoas e menos
orientadas a documentos.
Diante do quadro de ruptura em relação aos modelos tradicionais pelas
metodologias ágeis, aquela forma de MPS "tradicional" vinha de
encontro às novas ideias propostas pelo manifesto ágil, sendo esta MPS
"pesada" demais para as necessidades do desenvolvimento ágil de
software.
É muito
bom conhecer um pouco da história. Vamos continuar os nossos estudos!
|
Manifesto ágil e a "nova"
cultura
|
O termo "metodologias ágeis" foi formalizado em 17 de
fevereiro de 2001, por 17 líderes de desenvolvimento que propuseram
metodologias até então conhecidas como metodologias "leves". Este
encontro verificou pontos comuns dessas metodologias e resultou em um acordo
entre os participantes, que possuía quatro níveis.
O primeiro nível considera a necessidade da existência de métodos
construídos para responder a mudanças durante o projeto de software. O termo
"ágil" foi adotado para esses métodos, pois o termo "leve"
não era apropriado para certos projetos que teriam restrições em empregar
metodologias leves, mas, que ainda assim, poderiam precisar de agilidade.
O segundo nível do acordo foi a publicação do "manifesto
ágil", que é composto por quatro valores e que continham os valores
centrais de todas as metodologias:
1. indivíduos e iterações mais
do que processos e ferramentas;
2. software funcionando mais do
que documentação extensa;
3. colaboração do cliente mais
do que negociação de contratos;
4. responder a mudanças mais do
que seguir um plano.
Ainda que haja valor nos termos à direita, são valorizados mais os
termos à esquerda.
O terceiro nível é composto por um conjunto de doze princípios. Os
valores empregados são fornecidos com maior detalhamento, conforme segue:
1. a prioridade é cumprir as
entregas programadas e, por vezes, antecipadas. Desta forma, o cliente se
sentirá mais confiante e seguro com o produto solicitado (valor para o
cliente);
2. mudanças de requisitos são
bem-vindas, mesmo em fases tardias do desenvolvimento. Processos ágeis abraçam
mudanças para promover a vantagem competitiva do cliente;
3. entregar software funcionando
frequentemente, entre poucas semanas a poucos meses, dando preferência à escala
de tempo mais curta;
4. pessoas de software e de
negócios devem trabalhar juntas diariamente através do projeto;
5. construa projetos em torno de
indivíduos motivados, dê-lhes o ambiente e apoio que necessitem, e confie neles
para que o trabalho seja feito;
6. a forma mais eficiente e
efetiva de trazer informação para o time, e dentro do mesmo, é a comunicação
face a face.
7. software funcionando é a
primeira métrica de progresso;
8. processos ágeis promovem um
ritmo sustentável. Patrocinadores, desenvolvedores e usuários devem estar aptos
a manter o ritmo indefinidamente;
9. atenção contínua, excelência
técnica e bons projetos ajudam a agilidade.
10. simplicidade: a arte de
maximizar a quantidade de trabalho que não deve ser realizado é essencial;
11. as melhores arquiteturas,
requisitos e projetos surgem de times auto-organizados;
12. em intervalos regulares, o
time deve refletir sobre como se tornar mais efetivo, e então ajustar seu
comportamento, de acordo com a reflexão.
O quarto e último nível do acordo seriam formados com o passar do tempo.
Então, foi acordado que esse nível seria aquele no qual cada abordagem ágil
deveria definir a si mesma. Algumas destas abordagens são: extreme programming
(XP), scrum, crystal clear e lean.
Extraido a web aula da unopar 2013.
Nenhum comentário:
Postar um comentário