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