Os modelos de maturidade dos processos de desenvolvimento de software permitem a avaliac¸˜ao e classificac¸˜ao do desempenho das organizac¸˜oes que tˆem um processo ´agil de desenvolvimento de software.
Cap´ıtulo 2. Revis˜ao Bibliogr´afica 13
Segundo o estudo de Boehm e Turner [27] ´e poss´ıvel que uma organizac¸˜ao ´agil con- siga atingir n´ıveis altos de maturidade em CMMI ou Software Process Improvement and Capability Determination (SPICE). No entanto, v´arios especialistas da ´area de projetos ´ageis n˜ao acreditam que o CMMI ou o SPICE estejam adequados ao contexto da meto- dologia ´agil. Devido a esta necessidade de mapeamento de conceitos ´ageis para equipas tradicionais, nestes ´ultimos anos tˆem surgido diversos modelos que se auto-denominam modelos de maturidade ´agil que procuram enderec¸ar as necessidades e as carater´ısticas inerentes `a esta metodologia e incorpor´a-las num modelo de maturidade.
Neste contexto, Shirly Ronen-Harel sugere o modelo Agile Testing Maturity Model [28]. Neste modelo ´e usado o processo de testes para avaliar a capacidade de maturidade da equipa e da organizac¸˜ao. Existem cinco n´ıveis associados a conceitos espec´ıficos: cascata, forming, agile bonding, performing e o scaling. Essencialmente, o foco deste modelo ´e definir em termos pr´aticos uma bateria de testes a serem cumpridos para cada n´ıvel de maturidade.
Em 2010, surge tamb´em um artigo sobre um caso de estudo da British Telecom du- rante o desenvolvimento de um projeto de Benefield [29]. O Modelo de Maturidade
´
Agil proposto avalia o desempenho ´agil em sete dimens˜oes (automatizac¸˜ao de testes de regress˜ao, m´etricas de qualidade do c´odigo, automatizac¸˜ao do processo de entrega, automatizac¸˜ao de gest˜ao de configurac¸˜ao, interface de testes de integrac¸˜ao, desenvolvi- mento dirigido por testes e testes de escalabilidade de desemprenho) dentro de cinco n´ıveis de maturidade:
• N´ıvel 1: representa a emergˆencia de boas pr´aticas na comunidade de desenvolvi- mento de software;
• N´ıvel 2: representa o cont´ınuo desenvolvimento e melhoria de boas pr´aticas de software em equipas pequenas de desenvolvimento;
• N´ıvel 3: representa o cont´ınuo desenvolvimento e melhoria de boas pr´aticas de software em m´ultiplas equipas pequenas de desenvolvimento, ou seja, a n´ıvel orga- nizacional;
• N´ıvel 4: representa integrac¸˜ao cont´ınua dos recursos das v´arias equipas;
• N´ıvel 5: representa uma maturidade de desenvolvimento on-demand em que a equipa de desenvolvimento apresenta elevados n´ıveis de produtividade e ´e capaz de entender e encontrar soluc¸˜oes eficientes para dependˆencias.
Na opini˜ao da autora, a metodologia usada para estudo ´e gen´erica e foca-se demasi- ado em quest˜oes t´ecnicas. Al´em disso, a descric¸˜ao destes n´ıveis e as suas pr´aticas n˜ao s˜ao
muito detalhadas.
De seguida, encontram-se descritos trˆes modelos que se encontram mais estruturados e que enderec¸am melhor a quest˜ao central deste trabalho, em particular, identificar os modelos de maturidade ´agil, aplic´a-los a uma amostra de empresas portuguesas e tirar conclus˜oes sobre caminhos poss´ıveis para evoluc¸˜ao de maturidade de software em Portu- gal, no contexto ´agil.
Modelo de Maturidade do Processo ´Agil
No contexto da Metodologia ´Agil surge o Modelo de Maturidade do Processo ´Agil (APMM) [30] de Scott Ambler. Este modelo surge com o objetivo de fornecer uma framework que coloca as v´arias t´ecnicas e pr´aticas ´ageis em perspectiva de uma forma organizada, e que ir´a ajudar as organizac¸˜oes na melhoria dos seus processos de desenvolvimento ´ageis.
Assim sendo, este modelo encontra-se divido em trˆes n´ıveis:
• APMM N´ıvel 1 - Core Agile Development: enderec¸a apenas uma porc¸˜ao do ciclo de vida do sistema. Inclui metodologias como: Extreme Programing (XP) com t´ecnicas de refatorizac¸˜ao, Test-First design e Programac¸˜ao a Pares; Framework ´Agil com light-weight modeling e documentac¸˜ao; e Agile Data.
• APMM N´ıvel 2 - Entrega Disciplinada ´Agil: estende o primeiro n´ıvel de forma a enderec¸ar o ciclo de vida do sistema completo. Apresenta v´arias t´ecnicas: Hy- brid Processes com t´ecnicas mistas de Scrum e XP; Rational Unified Process (RUP) incluindo a avaliac¸˜ao de risco durante o ciclo de vida inteiro; Test-Driven Develop- ment (TDD) com esboc¸os iniciais de processo de neg´ocio e integrac¸˜ao cont´ınua; Unified Process combina e estende pr´aticas de SCRUM, XP, AM and RUP, Har- mony ESW (processo ´agil de software embebidos) e Dynamic System Development Method (DSDM).
• APMM N´ıvel 3 - Agilidade em Escala: enderec¸a explicitamente as complexidades que as equipas de desenvolvimento de software ´agil enfrentam no mundo empresa- rial.
Este modelo constitui uma ´otima abordagempara os objetivos deste projeto e ser´a apresentado mais detalhadamente no Cap´ıtulo 3.
Modelo de Maturidade para Processos ´Ageis
Segundo Hibbs [31], um Processo ´Agil ´e considerado maduro quando consegue estabe- lecer um equil´ıbrio eficaz entre disciplina e flexibilidade. O processo dever´a ter como
Cap´ıtulo 2. Revis˜ao Bibliogr´afica 15
foco o cumprimento de objetivos organizacionais, permitir uma resposta r´apida face `as mudanc¸as e reduzir os riscos inerentes a estas mudanc¸as.
Hibbs prop˜oe um Modelo de Maturidade para processos ´ageis (APMM) [31] em que s˜ao considerados trˆes aspectos fundamentais no campo da Engenharia de Software: o dom´ınio do problema, o desenvolvimento de tecnologia e a disciplina durante o processo de desenvolvimento do produto.
Neste modelo, Hibbs procura alcanc¸ar o equil´ıbrio entre dois tipos de competˆencias que considera como sendo cruciais para o desenvolvimento de software: as competˆencias t´ecnicas e as comportamentais como se pode ver na Figura 2.4.
Figura 2.4: Modelo de Hibbs. Adaptado de Hibbs [31].
No eixo horizontal da Figura 2.4 est˜ao representadas as competˆencias t´ecnicas da equipa de desenvolvimento. Assim sendo, de acordo com as competˆencias t´ecnicas, o processo de desenvolvimento pode ser avaliado como:
1. N˜ao ´Agil: a organizac¸˜ao n˜ao segue nenhuma premissa da metodologia ´agil e n˜ao aplica nenhuma das pr´aticas mencionadas no n´ıvel M´ınimo;
2. M´ınimo: a organizac¸˜ao segue algumas premissas da metodologia ´agil tais como: a recolha cont´ınua de requisitos, testes unit´arios, compilac¸˜ao autom´atica, ciclos itera- tivos de desenvolvimento pequenos, planeamento bem definido de atividades para iterac¸˜ao corrente, contato direto com peritos da metodologia ´agil, equipa alocada no mesmo espac¸o f´ısico e testes de aceitac¸˜ao;
3. Consolidado: a organizac¸˜ao para al´em das t´ecnicas do n´ıvel M´ınimo, inclui t´ecnicas de re-fatorizac¸˜ao, reutilizac¸˜ao sistem´atica, uso de orientac¸˜oes e normas para o pro- cesso de codificac¸˜ao, testes unit´arios independentes, testes de integrac¸˜ao e sistema e a pr´atica cont´ınua de documentac¸˜ao.
O eixo vertical do Modelo de Hibbs avalia competˆencias relacionadas com o compor- tamento da equipa. Hibbs preocupa-se aqui com a gest˜ao dos elementos da equipa e com problema da centralizac¸˜ao do conhecimento em pessoas espec´ıficas e n˜ao na equipa como um todo. Neste contexto, o processo pode ser avaliado em trˆes n´ıveis:
1. Inicial: o sucesso do projeto depende criticamente de um grupo de pessoas talen- tosas e motivadas para que o projeto decorra dentro do plano estabelecido inicial- mente o que pode tornar o processo inconsistente;
2. Organizado: dentro da organizac¸˜ao passa a existir uma gest˜ao eficiente de recursos humanos, riscos, infraestrutura, releases, suporte t´ecnico e, de expectativas para motivac¸˜ao da equipa pois esta constitui a forc¸a motriz de qualquer ser humano;
3. Disciplinado: engloba as pr´aticas do n´ıvel Organizado e passa a ter tamb´em uma avaliac¸˜ao da qualidade de produto, s˜ao realizadas a recolha e a an´alise de m´etricas do processo, existe um processo formal de fecho de projeto e de gest˜ao de conheci- mento.
Analisando este modelo podemos constatar que o mesmo n˜ao tem como objetivo a repetibilidade e a previsibilidade dos processos mas sim a visibilidade do processo e a sua capacidade de adaptac¸˜ao. Ele foca se nos elementos da equipa como pessoas tendo em conta os seus anseios e motivac¸˜oes.
´
E um modelo estruturado `a semelhanc¸a do modelo CMMI [32]. E, por ser um modelo bidimensional, permite uma vis˜ao distinta da parte t´ecnica e da gest˜ao das pessoas envol- vidas na equipa de desenvolvimento ´agil permitindo-nos analisar em separado estas duas ´areas.
Modelo de Maturidade ´agil
Em 2009, Patel e Ramachandran prop˜oem e analisam um Modelo de maturidade (AMM) [33] usando uma framework para o processo de avaliac¸˜ao e melhoria de pr´aticas da meto- dologia ´agil.
Este modelo inspira-se no CMMI e avalia o processo de desenvolvimento de software em cinco n´ıveis. Cada n´ıvel possui um conjunto de objetivos a serem alcanc¸ados com pr´aticas de diferentes metodologias ´ageis como est´a ilustrado na Figura 2.5.
No N´ıvel 1 Inicial, a organizac¸˜ao n˜ao possui um processo de desenvolvimento ´agil de software claramente definido. Como tal, o sucesso destas equipas de desenvolvimento encontra-se dependente de pessoas empenhadas e com iniciativas no seio da equipa e n˜ao
Cap´ıtulo 2. Revis˜ao Bibliogr´afica 17
Figura 2.5: Modelo de Maturidade ´Agil. Adaptado de Patel and Ramachandran [33].
desta como um todo. Os problemas t´ıpicos destas organizac¸˜oes s˜ao as incapacidades de cumprimento do calend´ario planeado, no orc¸amento acordado e nas metas de qualidade.
No N´ıvel 2 Explorado, a organizac¸˜ao passa a preocupar-se com mecanismos e pr´aticas estabelecidas durante o processo de desenvolvimento de software. As ´areas focadas neste n´ıvel s˜ao o planeamento de projetos e engenharia de requisitos. Para que sejam alcanc¸ados os objetivos neste n´ıvel s˜ao utilizadas pr´aticas para monitorizar as metas do projeto, o plano, os requisitos, os custos e a progress˜ao no desenvolvimento de funcionalidades. No entanto, ainda persistem problemas t´ıpicos a n´ıvel de comunicac¸˜ao e integrac¸˜ao de c´odigo de software.
Atrav´es de uma avaliac¸˜ao dos processos correntes ´e poss´ıvel identificar quais as fra- quezas do processo de desenvolvimento e obter uma vis˜ao global do estado do processo e a partir da´ı, poder elaborar um plano de melhoria para projetos individuais nas ´areas a melhorar;
No N´ıvel 3 Definido, a organizac¸˜ao possui mecanismos e pr´aticas estabelecidas de modo a garantir duas metas cruciais de um projeto: a satisfac¸˜ao de cliente e qualidade de software. Serve-se de v´arias t´ecnicas de programac¸˜ao tais como test driven development e programac¸˜ao a pares, regindo-se por padr˜oes de codificac¸˜ao. Neste n´ıvel de maturidade
´e crucial a preocupac¸˜ao com o cliente, o conhecimento de seus h´abitos, preferˆencias, ne- cessidades de consumo e expectativas de modo a garantir a sua fidelizac¸˜ao `a organizac¸˜ao. Ainda n˜ao existem mecanismos de avaliac¸˜ao de risco ou de pr´aticas de otimizac¸˜ao de c´odigo de software.
O objetivo aqui ´e ajudar a equipa de desenvolvimento a identificar problemas t´ecnicos e de comunicac¸˜ao entre os participantes, mantendo-se as quest˜oes organizacionais sem resoluc¸˜ao efetiva;
No N´ıvel 4- Melhorado, a organizac¸˜ao foca-se em objetivos relacionados com a ve- locidade de desenvolvimento, gest˜ao de projetos e em mecanismos de empowering das equipas de trabalho. As equipas de desenvolvimento tendem a ter mais autonomia sobre o processo. Estas procuram fazer o trabalho da forma mais simples poss´ıvel e que fun- cione. Neste n´ıvel, existe uma preocupac¸˜ao da organizac¸˜ao com o ritmo das equipas de desenvolvimento. Para efetuar esta an´alise dos processos de desenvolvimento utilizam as medic¸˜oes de desempenho do processo de desenvolvimento e da qualidade do produto final.
Os objetivos focados neste n´ıvel de maturidade est˜ao relacionados com a gest˜ao de projeto, o planeamento de trabalho, a avaliac¸˜ao de risco e no crescimento da pr´opria equipa de trabalho.
No N´ıvel 5- Maduro, a organizac¸˜ao est´a focada no processo de melhoria cont´ınua dos seus processos com base em informac¸˜oes que espelham o seu processo de desenvolvi- mento de software. Com base nestas pr´aticas, as organizac¸˜oes tomam decis˜oes pertinentes baseadas na an´alise de m´etricas quantitativas derivadas dos seus projetos.
Para al´em disto, a organizac¸˜ao preocupa-se tamb´em com a satisfac¸˜ao do cliente e do colaborador da equipa de desenvolvimento. Neste n´ıvel ´e tido em considerac¸˜ao n˜ao s´o o processo de software mas tamb´em o resultado alcanc¸ado pela equipa. Assim sendo as metas a atingir incluem o tuning do desempenho do projeto e prevenc¸˜ao de erros que pos- sam vir a ocorrer.
Ap´os a descric¸˜ao cada n´ıvel de maturidade deste modelo, ´e agora importante com- preender qual o processo a seguir para avaliar a organizac¸˜ao. Patel e Ramachandran apresentam-nos seguidamente um processo para avaliac¸˜ao de maturidade da organizac¸˜ao (Figura 2.6).
O processo descrito por Patel e Ramachandran tem por objetivo a melhoria de proces- sos. ´E um processo sequencial e consiste em: avaliac¸˜ao de adequac¸˜ao e adaptabilidade da equipa de desenvolvimento (potencialmente ´agil), avaliac¸˜ao do n´ıvel de maturidade ´ageis baseada em valores e princ´ıpios ´ageis, identificac¸˜ao de ´areas pass´ıveis de melhoria,
Cap´ıtulo 2. Revis˜ao Bibliogr´afica 19
planeamento e implementac¸˜ao das melhorias, e por fim mapeamento em pr´aticas ´ageis.
Figura 2.6: Roadmap para Melhoria de Processos. Adaptado de Patel and Ramachandran [33].
Este modelo constitui uma primeira abordagem `a quest˜ao central deste trabalho na medida que se encontra bem estruturado. No entanto peca nas descric¸˜oes de cada n´ıvel pois estas n˜ao s˜ao muito detalhadas e at´e por vezes amb´ıguas. Um ponto positivo para este modelo ´e o fato de abordar a necessidade de medidas para avaliar o desempenho. Contudo, n˜ao sugere nenhuma m´etrica para que a organizac¸˜ao possa monitorizar os seus processos.
Conclu´ıda a an´alise detalhada de trˆes modelos de maturidade, optou-se pelo Mo- delo de Maturidade do Processo ´Agil por se considerar mais adequado para o suporte da avaliac¸˜ao de maturidades das empresas ´ageis portuguesas. Este modelo ser´a apresentado em maior detalhe no Cap´ıtulo 3.
Cap´ıtulo 3
Modelo de Maturidade do Processo ´Agil
Scott Ambler ´e um engenheiro de software canadiano e consultor s´enior da Scott Am- bler+ Associates, uma organizac¸˜ao especializada em ajudar organizac¸˜oes a adotar es- trat´egias ´ageis. Autor de diversos livros sobre metodologias ´ageis tais como Disciplined Agile Delivery (DAD), Agile Scaling Model (ASM), Agile Model Driven Development (AMDD), Agile Database Techniques, the Agile UP, e Enterprise Unified Process (EUP), Ambler foca-se no treino disciplinado em metodologias ´ageis e em assessorias relaci- onadas com processo [34]. Em 2009, Scott Ambler cria o Modelo de Maturidade do Processo ´Agil tendo como objetivo ajudar as organizac¸˜oes nos seus processos de melho- ria cont´ınua Ambler [35]. O presente cap´ıtulo tem como objetivo analisar detalhadamente esse modelo, j´a que foi escolhido neste trabalho para suportar a avaliac¸˜ao de maturidade das empresas portuguesas.
O Modelo de Maturidade do Processo ´Agil (APMM) [35] define os passos para a adoc¸˜ao efetiva e personalizadas de estrat´egias ´ageis para enfrentar os desafios enfrentados por uma equipa de entrega do sistema. O APMM define trˆes n´ıveis de maturidade e cada um deles est´a assente sobre o n´ıvel imediatamente abaixo (Figura 3.1).
Figura 3.1: Modelo de Ambler.
3.1
APMM N´ıvel 1 Core Agile Development
O primeiro n´ıvel do APMM enderec¸a a etapa de construc¸˜ao do ciclo de vida do sistema. Neste n´ıvel de maturidade, o objetivo ´e construir um programa de software que funciona. Para tal, serve-se de v´arias t´ecnicas e metodologias, tais como: SCRUM, Extreme Pro- gramming, Framework ´Agil e Agile Data.