MPS - Melhoria de processo de software?

Melhoria de processo de software

     Um processo de software pode ser definido como uma sequência de passos necessários para o desenvolvimento ou manutenção de um software, com o objetivo de prover um conjunto de boas práticas técnicas e gerenciais, para a utilização de técnicas e ferramentas por pessoas que irão realizar tarefas para alcançar o objetivo determinado.

     Atualmente, todos os programas que carregam a alcunha de melhoria de processo que são criados dentro de uma organização visam o retorno do investimento (return on investment - ROI) para que mais recursos estejam disponíveis, para que a mesma continue crescendo.

     Vimos, anteriormente, os seis passos comuns a todos os programas de melhoria de processo de software executados nos modelos tradicionais. Contudo, serão mostrados aqui seis elementos que são considerados em qualquer programa de MPS executado nos moldes tradicionais.

1. Modelos organizacionais para melhoria de processo de software

     Nos modelos tradicionais, a melhoria de processo tem um caráter organizacional, ou seja, os processos da instituição são mapeados, avaliados e as melhores práticas são institucionalizadas, ou se tornarão parte do processo padrão da empresa.

       Esse processo padrão apresenta todos os processos de uma organização e critérios definidos de adaptação. Ou seja, a empresa possui algumas boas práticas internas mapeadas e, no processo, existem indicações de quando usar cada uma delas.

     Neste ponto, o mais importante é entender que todos os projetos da empresa serão executados baseados nesse processo padrão e que as lições aprendidas são incorporadas ao processo padrão da organização, o que podemos definir como aprendizado organizacional. Para ajudar uma organização a escolher a melhor forma de "aprender" sobre si mesma, existem alguns modelos organizacionais para MPS .

2. Processos padrões e avaliação dos processos

     Alguns modelos para maturidade de melhoria de processo, como o cmmi e o MPS.BR, são hoje referências no mercado para a avaliação de processos. 

     Esses modelos fornecem um conjunto de boas práticas de como o processo pode ser melhorado e fornecem também um método de avaliação que ajuda a "medir" a evolução do programa de MPS na organização.

   É entendido aqui que todo programa de melhoria de processo deve ser avaliado de forma objetiva, seguindo critérios bem definidos e não ambíguos. Não existe ainda nenhum método de avaliação que se mostre melhor para todos os casos. Normalmente, cada modelo criado é adaptado de acordo com a situação.

3. Adaptação de processos

    Abordagens de software tradicionais vêm sendo criticadas por não possuir critérios para a sua aplicabilidade ou por não se mostrarem universalmente aplicáveis.

     Este ponto retrata uma questão na melhoria de processo de software, sobre como uma organização, com um processo padrão rico em boas práticas e com uma variedade grande de projetos, pode escolher quais são as melhores práticas para maximizar o ROI de seus projetos. Este ponto do processo de MPS é conhecido como adaptação de processos. Basili e Rombach (1987) apresentaram uma das primeiras propostas para adaptar processos.

4. Implantação de processos

     A implantação do processo é uma instância da MPS nas organizações. Ela pode incluir atividades como realização de projetos pilotos, métodos e ferramentas como potenciais soluções para metas ou problemas existentes, e a avaliação dos efeitos daquela mudança no desenvolvimento de software.

    Nas abordagens tradicionais de desenvolvimento de software, é mais comum que a melhoria aborde o processo organizacional como um todo, ao invés de questões de um determinado processo em particular.

     Basicamente, uma organização pode escolher uma estratégia big-ben ou por pedaços para implantar novos processos, métodos e ferramentas. 

    Enquanto o big-ben é uma forma revolucionária que acredita que cada mudança súbita resulta em uma forma distinta de trabalho, a estratégia por pedaços é uma abordagem evolucionária que prefere um período longo de evolução dentro da organização, a partir de pequenas fases de melhoria.

5. Medição

    Você não pode controlar aquilo que não pode medir. A partir dessa premissa, é verificado que, sem atividades de medição e controle, fica extremamente difícil pensar em melhoria de processo de software. A medição possui três propósitos:

1. entender o desenvolvimento e manutenção;

2. controlar projetos;

3. melhorar processos e produtos.

     Na melhoria de processo, a medição é fundamental para a promoção da melhoria contínua. Vários mecanismos para obtenção de dados quantitativos existem hoje para auxiliar o processo de medição, sendo que os mais comuns em programas de MPS são o GQM (goal question metric) e o PSM (practical software and systems measurement).

6. Experiência, conhecimento e aprendizado

    O valor representado pela experiência e conhecimento não deve ser subestimado dentro de um programa de MPS e dentro de sua expectativa de melhoria contínua. Deming (1990) afirmava que perder conhecimento é mais prejudicial do que perder material. Em programas de MPS, é considerado crucial que as lições aprendidas dentro dos projetos correntes sejam testadas em outros projetos e, se o resultado for positivo, que esse conhecimento seja adicionado à base de conhecimento da organização. Isso normalmente ocorre com uma adição ao processo padrão da organização.

      Neste aspecto, podemos ressaltar o verdadeiro objetivo dos programas de MPS dentro das organizações, que é o aprendizado daquilo que funciona ou não dentro daquela organização e em que contexto este resultado pode ser reproduzido.

      MPS no desenvolvimento ágil de software

     É correto afirmar que técnicas e métodos de MPS estão limitados dentro do desenvolvimento ágil de software, mesmo tendo essa melhoria de processo de software um papel fundamental dentro de qualquer método ágil.

     Esta importância é observada em um dos princípios presentes no 3° nível do acordo que gerou o manifesto ágil. O último princípio das metodologias ágeis foi definido como: "em intervalos regulares, o time deve refletir sobre como se tornar mais efetivo e ajustar seu comportamento de acordo com esta reflexão".

    De fato, o desenvolvimento ágil de software provê uma forma "não-tradicional" para a realização da MPS, pois este considera a melhoria do processo de obtenção e compartilhamento do conhecimento entre os desenvolvedores, sendo necessário criar uma "escala" para poder pontuar a experiência desse time e maximizar o ganho dessa experiência e sua disseminação por toda a equipe. Assim, o desenvolvimento ágil de software possibilita novas formas para realização desta melhoria de processo, além daquelas apresentadas pelos modelos tradicionais.

     Para o desenvolvimento ágil de software, a melhoria de processo possui as seguintes características:

I. todo o time é responsável pela melhoria de processo;

II. as melhorias propostas são resultados da experiência do time sobre o que pode melhorar em seu próprio comportamento, sem a necessidade de 

indicadores formais ou critérios bem definidos;

III. as mudanças propostas pelo time entram em vigor a partir da próxima iteração, ou seja, já é incorporado ao processo da equipe, não precisando de projetos pilotos;

IV. a avaliação das mudanças ocorre pelo sentimento da equipe sobre o que aconteceu durante aquela iteração. Então, se a mudança "funcionou", a equipe pode manter aquela mudança;

V. as mudanças são propostas em intervalos bem definidos, sendo que os mesmos podem durar de uma a poucas iterações;

VI. o time tem autonomia para se auto-organizar e determinar como o processo será seguido e que ações realizar quando não conformidades forem encontradas.

     Avaliando os seis elementos presentes na melhoria de processo, quando tratamos do desenvolvimento ágil, temos os seguintes resultados:

1. Modelos organizacionais para melhoria de processo de software

     No desenvolvimento ágil de software, o time é a unidade responsável pela execução de um projeto. No 3° nível do acordo que gerou o manifesto ágil é, observado o seguinte princípio: "as melhores arquiteturas, requisitos e projetos surgem de times auto-organizados".

    Esse princípio esclarece que, no contexto ágil, as decisões do time são mais prioritárias do que aquelas vindas da organização. A uniformidade não é encorajada. Todos os times trabalham, logo, podemos considerar que nesse contexto não há um processo padrão definido. Porém, se pensarmos que os times da organização utilizam uma mesma abordagem, por exemplo, xp, pode-se pensar em uma forma muita parecida de trabalho.

    Boehm & Turner (2005) afirmam que existem desafios gerenciais em implantar processos ágeis, pois eles não seguem a hierarquia topdown encontradas nas organizações tradicionais, uma vez que o empowerment dado aos times tornam essa mesma estrutura autogerenciável.

  

2. Processos padrões e avaliação dos processos

      A avaliação do processo, bem como de todas as melhorias propostas pela equipe, não possui indicadores definidos nem critérios de aceitação formais que indiquem a aprovação ou não do mesmo. As avaliações são realizadas de forma subjetiva, de acordo com a experiência que o time obteve em experimentar aquele "novo" processo durante a iteração.

       Da mesma maneira informal com a qual a avaliação é realizada, de forma subjetiva e sem a utilização de indicadores, também é a forma com que se escolhe aquilo que deve ser alterado no processo. Não há uma maneira sistemática para decidir, ou avaliar, o que deve ser modificado, e no que está baseada a escolha, a não ser pela experiência do próprio time.

     O método de avaliação que vem sendo aceito comumente pelos times scrum é o nokia test. Outra iniciativa interessante que está se definindo como um padrão na área das metodologias ágeis é o ieee 1648 (http://standards.ieee.org/board/nes/projects/1648.pdf).

3. Adaptação de processos

     Nas metodologias ágeis, os processos são adaptados com mais frequência e de forma não sistematizada. Contudo, o desenvolvimento ágil considera que processos que são criados para serem repetidos são falhos, e consideram que cada situação exige um processo diferente, uma vez que processos repetitivos só funcionam com as mesmas pessoas, nos mesmos ambientes, com as mesmas ferramentas, para solucionar os mesmos problemas repetidas vezes.

      De fato, o desenvolvimento ágil precisa de adaptações dentro de projetos individuais dentro de uma organização, e esse processo é continuamente melhorado a partir de pequenas mudanças. Afinal, o desenvolvimento de software proposto pelas metodologias ágeis não está baseado em processos preditivos em ambientes estáveis para o desenvolvimento, e sim, baseado em um ambiente de mudanças frequentes, que ainda assim necessitam de qualidade.

4. Implantação de processos

     A maioria das implantações de processos no desenvolvimento ágil está mais voltada para a abordagem big-ben, na qual grandes mudanças podem ser sugeridas; no entanto, não há critérios para essas mudanças.

     O maior desafio nestes tipos de implantação é a falta de transparência entre os diversos níveis da organização (hierarquia) em relação ao time autogerenciável, o que pode resultar em um relacionamento fracassado entre as partes interessadas de mais alto-nível e o time.

5. Medição

      Boehm & Turner (2005) afirmam que a maioria das técnicas de medição tradicionais podem se tornar inadequadas para o apoio aos métodos ágeis. As razões mais comuns desta falha provêm da diferente forma como as estruturas analíticas de projeto (EAP) são construídas. Enquanto nos métodos tradicionais essas EAPS são um conjunto de atividades e tarefas normalmente exibidas em gráficos de GANTT, nos métodos ágeis temos a manipulação de cartões de estórias (XP) ou itens de backlog (SCRUM), que são detalhados em nível satisfatório, apenas quando são desenvolvidos.

Falando em métricas para melhoria de processos, em particular, não vemos nenhuma indicação no manifesto ágil de que esta seja uma ferramenta para o MPS. Contudo, XP indica que, sempre que for necessária uma adaptação ao processo, deve ser criado um mecanismo para avaliar o resultado dessa mudança, e SCRUM afirma que, se as coisas corretas forem medidas, é possível a realização de melhorias.

     Observando o princípio: "software funcionando é a primeira métrica de progresso", pode-se considerar que as medições são importantes ferramentas para controle da execução das atividades de engenharia do produto (gerenciamento do projeto) do que para a melhoria de processos no desenvolvimento ágil.

6. Experiência, conhecimento e aprendizado

     Este é um dos pontos mais valorizados no desenvolvimento ágil de software, especialmente para os times que desenvolvem um software específico. A ênfase dada ao aprendizado coletivo do time é observada no princípio ágil: "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".

    Beck & Andrés (2004) afirmam que, em xp, bons times não fazem apenas o seu trabalho, mas pensam sobre como realizar seu trabalho e por que realizá-lo. O time analisa o porquê de seu sucesso e sua falha, e eles não tentam esconder os seus erros, pelo contrário, eles são encorajados a mostrá-los e a aprender com eles.

     O time deve ser encorajado a aprender não só com a experiência deles, mas também com a experiência do cliente. No desenvolvimento ágil, é encorajada a comunicação face a face para que haja um entendimento melhor durante o ciclo de vida do desenvolvimento.

     Contudo, não é considerado aqui o aprendizado organizacional. Os times podem adaptar técnicas diferentes para atender a necessidades diferentes no processo de desenvolvimento, e este tipo de experiência fica implícito, uma vez que não existe um mecanismo definido para troca de experiências dentro dos times ágeis. O que normalmente é feito é: um membro de cada time é trocado de lugar e este compartilha as suas experiências com os outros times, homogeneizando o conhecimento.

      As retrospectivas são a técnica mais utilizada para a realização de MPS dentro do desenvolvimento. Esta técnica foi desenvolvida originalmente para o método crystal clear, mas foi incorporado ao scrum (sprint retrospectives meetings) e ao XP (reflexões).

      Esta técnica se resume em uma reunião que deve ocorrer sempre no final de uma iteração. Nessa reunião, o time deve opinar sobre três aspectos:

     - o que está funcionando e deve ser mantido?

     - o que está ruim e deve ser modificado?

     - o que podemos tentar fazer diferente?

Estes três tópicos são discutidos de acordo com a experiência de cada desenvolvedor, e todos dão a sua opinião sobre cada ideia surgida. Contudo, não há critérios ou indicadores para justificar/avaliar cada uma das sugestões, ficando apenas a critério do time se a mudança será incorporada ou não ao processo.

     As mudanças que forem aceitas pela equipe entram em vigor já na iteração seguinte e, na próxima reunião de retrospectivas, ela pode ser mantida, retirada ou até mesmo melhorada.

Extraido da web aula unopar 2013

Por que usar scrum?

Por que scrum?

     A indústria de desenvolvimento de software evoluiu para se tornar uma das mais importantes instituições de nosso tempo, criando produtos essenciais para o nosso dia a dia. Inúmeros exemplos podem ser citados. Neste ambiente intensamente competitivo, diferenciais devem ser criados para a sobrevivência. A capacidade de criar e de entregar mais rapidamente produtos de software que melhor satisfaçam as necessidades reais do cliente é um deles.

     Segundo PMI Brasil 2006, os problemas mais frequentes em gerenciamento de projetos levantados são:

- não cumprimento de prazos (72%)

- problemas de comunicação (71%)

- mudança de escopo (69%)

- estimativa errada de prazo (66%)

     Analisando os problemas levantados, pode-se constatar que o cerne da questão reside principalmente na comunicação - refletindo nos demais. Quando presentes, mecanismos de comunicação ineficientes são utilizados, contribuindo para a falta de compreensão e colaboração por parte dos envolvidos.

      A figura 1 promove uma comparação entre a efetividade de comunicação e a "riqueza" do canal de comunicação. Dois mecanismos são evidenciados: os que não possuem perguntas e respostas e os que possuem. Este primeiro tipo propõe pouca interação e não permite a colaboração e troca necessária para o alcance do objetivo proposto. A utilização de papel para descrever e comunicar o problema tem importante cunho "documental", além de poder ser compartilhado entre diversas pessoas.

     Por outro lado, mecanismos que promovem e facilitam a comunicação, os mecanismos interativos, são compostos por perguntas e respostas - como duas pessoas falando ao telefone ou discutindo via e-mail são notoriamente mais eficientes. E ainda torna-se mais eficiente se tivermos a presença física na mesma sala dos diversos envolvidos. Para completar, um quadro branco, auxiliando na dinâmica das discussões, pode expandir em muito as possibilidades de entender e se fazer entendido.

Figura 1. Temperatura da comunicação, segundo Alistair Cockburn.

     Comunicação "face-to-face" é uma das formas de se resolver grande parte dos problemas citados e, metodologias ágeis, como o scrum, pregam incessantemente esta prática. O manifesto ágil, criado em 2001, instituiu valores e princípios da escola que corroboram com o descrito acima. Abaixo os quatro valores principais: "nós estamos descobrindo melhores formas de se desenvolver software, fazendo software e ajudando os outros a fazê-lo."

Através deste trabalho nós viemos valorizar:

1. indivíduos e interações primeiro que processos e ferramentas.

2. software funcionando primeiro que documentação compreensiva.

3. colaboração do cliente primeiro que negociação contratual.

4. resposta a mudanças primeiro que conformidade com planejamento.

     É importante destacar que não há ruptura entre os itens da esquerda e os da direita, e sim de ênfase. A comunicação irá auxiliar em cada um dos itens da esquerda e será o grande facilitador desse processo.

     O interessante deste tipo de abordagem é que não se tem a procura por um culpado. Todos estão imbuídos na busca da melhor solução para a organização, seja o analista, desenvolvedor, gerente de projeto ou o cliente. 

     E cada um tem o seu papel claramente determinado frente ao processo de desenvolvimento. Em metodologias ágeis, uma das premissas básicas é ter o cliente sempre por perto e fazê-lo um participante ativo. É importante que ele entenda suas responsabilidades e sua grande parcela de contribuição para o sucesso do projeto.

     Algumas questões diferenciam metodologias ágeis no planejamento do projeto. Nas metodologias ágeis, o planejamento é feito continuamente, durante todo o projeto, e baseado em um goal (objetivo), no qual são definidas as tarefas necessárias para se iniciar o mesmo. Este objetivo serve como um guia para todos os envolvidos e é a meta a ser perseguida. 

     Normalmente, é um parágrafo que resume, em três ou quatro frases, o foco maior que o projeto deve ter. Seu estabelecimento visa delegar à equipe do projeto um espaço de agilidade que a permita tomar decisões rápidas ao longo do projeto, norteando-o quanto a alterações de prioridades, de requisitos, práticas ou outras quaisquer.

      Se todo o planejamento fosse feito no início do projeto, após as primeiras semanas, o longo planejamento feito poderia estar defasado, pois as mudanças ocorreriam e o forçariam a esta situação. Requisitos não devem ser intensamente esgotados no início do projeto, eles sim, são incrementados a cada iteração, experimentados pelos envolvidos, colocados a prova, avaliados e refinados.

   É importante construir o todo aos poucos, refinando os requisitos, equalizando o entendimento sobre eles e corrigindo o rumo sempre que uma mudança provoque alterações significativas.

   Planejar detalhadamente é ir contra a natureza do processo de desenvolvimento de software. As tarefas que constituem este tipo de abordagem fazem parte de um processo criativo, não linear e não palpável, fazendo com que modelos ágeis se apresentem como uma alternativa interessante. Por isso, planos menos detalhados e feitos em frequência maior mostram-se mais adequados.

    A forte presença de iterações curtas também contribui para o planejamento contínuo citado. Elas garantem ritmo a todos os envolvidos e levam ao feedback real e imediato dado pelo cliente. Como resultado, auxiliam nos possíveis ajustes - que não acontecem mais tardiamente - e ajudam na entrega de software de valor. Cada uma das iterações é composta de todas as tarefas necessárias a esta entrega: levantamento de dados, análise, projeto, implementação, testes e integração à versão anterior.

     Outro ponto interessante é a maneira pela qual o monitoramento e a medição do projeto são executados em metodologias ágeis. Cada tarefa definida é verificada quanto ao seu percentual de andamento (o mais usual) e também quanto à sua qualidade através de testes e entregas que são feitas com maior frequência. O progresso do projeto não é medido levando em consideração o plano inicial feito, como em metodologias tradicionais, ou seja, não é traçado um quadro comparativo entre o que foi planejado no início e o que foi executado até o momento. Mudanças são aceitas e algumas "linhas de bases" farão parte do projeto. Dessa forma, o atendimento ao goal definido deve ser a principal medida de progresso sendo verificado, constantemente, para garantir o máximo de retorno para o negócio.

     A identificação e o gerenciamento dos riscos em metodologias ágeis são feitos em taxas diárias (através de reuniões curtas e diárias), e, durante toda a iteração, o controle da qualidade dos trabalhos é avaliado. Esta tarefa pode ser executada através de testes, revisão por pares, inspeção contínua e acompanhamento pelo cliente, que seguem o mesmo processo. Impedimentos são levantados e devem ser resolvidos no prazo máximo de 24 horas para garantir que ações de resolução rápidas sejam executadas e para que todos conheçam os impedimentos que podem se tornar potenciais riscos para o projeto.

     Além disso, mudanças no projeto são bem aceitas, pois elas existem e irão acontecer. É por isso que o comprometimento de todos os envolvidos é tão importante em um projeto. Caso o cliente queira mudar uma solicitação ou adequar-se a uma mudança de mercado, pode-se alterar o rumo rapidamente, sem afetar todo o projeto, pois o planejamento é refeito a todo o momento. E ainda, caso uma iteração não corra conforme o esperado pelo cliente, pode-se mudar a abordagem de levantamento de dados, os recursos envolvidos, a forma de troca de informações e corrigir o rumo a tempo do final do projeto.

     Pode ser (e na maioria das vezes é) que o plano inicial não represente mais a necessidade real de nosso cliente. Ele deixa de pedir alterações, pois o contrato já foi assinado; ele não tem mais horas adicionais para pagar; o prazo está curto e ele necessita do produto e, então... ele "evita" solicitar mudanças. Pergunta: o que ele ganha? De que adianta entregar um software que o cliente não irá usar? E o quê o fornecedor do serviço ganha? Ok, entrega-se o produto, o cliente usa poucas funcionalidades, reclama das funcionalidades prioritárias que ele não recebeu e, em contrapartida, recebeu várias outras que não vai utilizar. E isso pode ser considerado um projeto de sucesso?

     O sucesso de um projeto de software utilizando metodologias ágeis não é somente medido comparando projeções iniciais de prazo, custo e escopo, e sim, através de entrega de software de valor ao cliente. Estes três pilares - prazo, custo e escopo - devem ter seus pesos definidos. É claro que todos nós desejaríamos que nossos projetos terminassem dentro do prazo previsto, com o custo dentro da margem determinada e com todo o escopo entregue. Todos nós já passamos por fases posteriores de manutenções e correções que consomem grande esforço de recursos e também trazem desgaste no relacionamento das pessoas envolvidas.

Estraido da web aula unopar 2013

O que seria Metodologias ágeis!

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.