Modelos de maturidade adaptados a projetos ágeis

U

NIVERSIDADE DE

L

ISBOA

Faculdade de Ciˆencias

Departamento de Inform´atica

MODELOS DE MATURIDADE ADAPTADOS A

PROJETOS ´

AGEIS

Farah Maria Abdul Hamid Mussa

Trabalho orientado pela Professora Doutora Ana Paula Pereira Afonso

e pela Dra Margarida Gonc¸alves

PROJETO

MESTRADO EM ENGENHARIA INFORM ´

ATICA

Especializac¸˜ao em Sistemas de Informac¸˜ao

Agradecimentos

A realizac¸˜ao desta tese de mestrado contou com apoios fundamentais sem os quais a elaborac¸˜ao da mesma n˜ao seria poss´ıvel. Constitui uma tarefa ´ardua colocar no espac¸o limitado desta secc¸˜ao de agradecimentos palavras satisfat´orias que espelhem o meu agra-decimento a todas as pessoas que, ao longo do meu Mestrado em Engenharia Inform´atica contribu´ıram para o cumprimento dos meus objetivos e conclus˜ao de mais uma etapa na minha formac¸˜ao. Todavia deixo apenas algumas palavras que refletem o profundo e mais sincero agradecimento a cada uma das pessoas aqui mencionadas.

Ao Coordenador do Mestrado de Engenharia Inform´atica da Faculdade de Ciˆencias de Lisboa, Professor Doutor Luis Moniz, agradec¸o a oportunidade e o privil´egio que tive em frequentar este Mestrado que muito contribuiu para o enriquecimento da minha formac¸˜ao acad´emica e cient´ıfica.

`

A todos os professores do Mestrado de Engenharia Inform´atica que contribu´ıram para minha formac¸˜ao. Em particular, gostaria de expressar o meu profundo agradecimento `a Professora Doutora Ana Paula Afonso pela orientac¸˜ao e aux´ılio incondicional que con-tribu´ıu para alavancar os meus conhecimentos cient´ıficos e, sem d´uvida, estimularam o meu desejo pelo Saber e pelo Saber fazer bem.

`

A Bring, instituic¸˜ao onde esta dissertac¸˜ao foi conduzida e onde a investigadora rea-lizou o est´agio, e a todos os colaboradores desta empresa por terem providenciado um ´otimo ambiente de trabalho e pela oportunidade dada para viajar pela primeira vez em trabalho alargando os meus conhecimentos.

`

A Margarida Gonc¸alves, supervisora por parte da Instituic¸˜ao e grande exemplo pro-fissional, o meu sincero agradecimento por ter garantido a minha integracc˜ao dentro da Instituic¸˜a e pela coorientac¸˜ao nesta dissertac¸˜ao. Muito obrigada pelo profissionalismo, pela sincera amizade, pelos incentivos e pela total disponibilidade que sempre teve co-migo. O seu apoio foi determinante na elaborac¸˜ao desta dissertac¸˜ao.

clus˜oes com fundamentos te´oricos e pr´aticos de suporte acerca do tema em quest˜ao.

`

As minhas colegas de mestrado M´onica Abreu e Ana Pessoa pelos momentos de en-tusiasmo partilhados em conjunto durante as aulas e fora delas. Um obrigado especial ao Francisco do ´O, colega de curso e de est´agio pela partilha de bons momentos, ajuda e os est´ımulos nas alturas de desˆanimo durante todo o per´ıodo do mestrado.

`

As irm˜as que o destino escolheu para mim, Zulmira Abdula e Mircya Mandawa, o meu muito obrigado pelo amor e carinho nos momentos mais importantes da minha vida. Ao Shaheen Patel, `a Neuza Pedro e `a N´adia Ferrete por todas palavras de incentivo du-rante a elaborac¸˜ao da dissertac¸˜ao. Ao Pedro Ferreira e ao Francisco Oliveira, pessoas que conheci em Portugal e que tenho certeza que ficar˜ao para sempre na minha mem´oria pela vossa amizade e apoio fica aqui expresso o meu reconhecimento.

`

A toda minha Fam´ılia, em especial aos meus pais e aos meus irm˜aos, um enorme obri-gada por todo ensinamento dos valores e princ´ıpios, pois ´e grac¸as a eles que tornei-me o ser humano que sou hoje. Espero que esta etapa, que agora termino, possa, de alguma forma, retribuir e compensar todo o carinho, apoio e dedicac¸˜ao que depositaram em mim.

E acima de tudo a Allah por me amparar nos momentos dif´ıceis, providenciar forc¸a interior para superar as dificuldades e suprir todas as minhas necessidades..

Cada vez mais, surgem press˜oes de v´arias fontes para colocar produtos e servic¸os de valor no mercado em menor tempo poss´ıvel dependendo de um leque menor de recur-sos. A tecnologia impele as empresas a produzirem continuamente funcionalidades mais inovadoras, enquanto os consumidores exigem produtos ideais que funcionem e n˜ao se tornem obsoletos. Temos ainda os stakeholders que exigem que a sua equipa tenha proje-tos que possam gerar lucros rapidamente.

A metodologia ´agil vem responder a estas exigˆencias e tenta colmatar algumas de-ficiˆencias dos m´etodos cl´assicos em cascata. No entanto, para que esta metodologia traga valor acrescentado `as empresas que a adotaram no seu processo de desenvolvimento de software, ´e necess´ario compreender quais as reais necessidades de cada empresa em par-ticular. ´E preciso compreender em que realidade estas empresas se inserem, quais os seus objetivos organizacionais e de que forma est˜ao a usar a metodologia ´agil nos seus projetos.

Neste contexto, o trabalho far´a uma an´alise cr´ıtica do estado das empresas face `a utlizac¸˜ao de m´etodos ´ageis, com posterior avaliac¸˜ao da sua maturidade segundo o Modelo de Maturidade do Processo ´Agil. Para tal, foram recolhidos dados atrav´es de inqu´eritos, apresentado o Modelo de Maturidade escolhido e entrevistas realizadas em algumas em-presas ´ageis portuguesas. Atrav´es de uma an´alise minuciosa aos resultados pode-se con-cluir que a metodologia ´agil mais adotado pelas empresas portuguesas ´e o SCRUM e as suas variantes, e que estas se encontram num fase muito inicial de maturidade nas me-todologias ´ageis correspondendo assim ao primeiro n´ıvel de acordo com o Modelo de Maturidade do Processo ´Agil. Para al´em disso s˜ao apresentadas ainda sugest˜oes de me-lhoria de forma a alcanc¸ar n´ıveis de maturidade superiores.

Palavras-chave: qualidade de software, processo de melhoria de software, m´etodos ´ageis, modelo de maturidade ´agil, maturidade de empresas ´ageis.

Increasingly, pressures arise from several sources to place valuable products and ser-vices in the market in the shortest possible time using few resources. Technology drives companies to continuously produce more innovative features as consumers demand ideal products that work and will not become obsolete. Besides, we still have stakeholders that demand from their team to have projects that can quickly generate profit.

The agile methodology responds to these demands and tries to overcome some weak-nesses of the waterfall methodology. However, for Agile Methodology to bring added value to companies that are using it in their software development process, it is necessary to understand the real needs of each particular company. There is a need to understand the context of the company, their organizational objectives and how they are using the agile methodology in their processes.

In this context, this dissertation makes a critical analysis of the companies face to the agile methodology, with further evaluation of their maturity according to a chosen model. In order to acomplish this, data were collected through surveys, presentation of the Maturity Model chosen and interviews in some portuguese agile companies. Through a thorough analysis of the results it can be concluded that the preferred agile methodol-ogy of Portuguese companies is the SCRUM and its variants, and that these companies are still in a very early stage of maturity corresponding to the first level agreement with Maturity Model Agile Process. Furthermore this dissertation also presents suggestions for the company’s improvement in order to achieve higher levels of maturity.

Keywords: software quality, software process improvement, agile methodology, agile maturity model, maturity agile companies.

Conte ´udo

Lista de Figuras xvi

Lista de Tabelas xix

1 Introduc¸˜ao 1 1.1 Motivac¸˜ao . . . 1 1.2 Objetivos . . . 3 1.3 Contribuic¸˜oes . . . 3 1.4 Estrutura do documento . . . 4 2 Revis˜ao Bibliogr´afica 5 2.1 Metodologias ´Ageis . . . 6 2.2 Modelos de Maturidade . . . 8

2.2.1 Capability Maturity Models CMM e CMMI . . . 9

2.2.2 Modelos de Maturidade ´Ageis . . . 12

3 Modelo de Maturidade do Processo ´Agil 21 3.1 APMM N´ıvel 1 Core Agile Development . . . 22

3.1.1 SCRUM . . . 22

3.1.2 Extreme Programming XP . . . 23

3.1.3 Framework ´Agil . . . 24

3.1.4 Agile Data . . . 26

3.2 APMM N´ıvel 2 - Entrega Disciplinada ´Agil . . . 26

3.3 APMM N´ıvel 3 - Agilidade em Escala . . . 29

4 Avaliac¸˜ao de Maturidade das Empresas Portuguesas 33 4.1 Metodologia . . . 34

4.2 Recolha de dados . . . 35

4.2.1 Modelo de Ambler . . . 35

4.2.2 Inqu´erito . . . 36

4.2.3 Apresentac¸˜ao do Modelo nas Empresas . . . 42

4.2.4 Entrevistas Realizadas . . . 46

4.4.1 Processo de Adoc¸˜ao de Metodologias ´Ageis . . . 48

4.4.2 Contexto Empresarial . . . 49

4.4.3 Processo de Desenvolvimento ´Agil de Software . . . 51

4.5 An´alise de resultados e Avaliac¸˜ao de Maturidade . . . 56

5 Conclus˜ao 63

A Inqu´erito 65

B Apresentac¸˜ao `as empresas portuguesas 71

Abreviaturas 79

Bibliografia 85

´Indice 86

Lista de Figuras

1.1 Comparac¸˜ao de equipas ´ageis e n˜ao ´ageis . . . 1

1.2 Caraterizac¸˜ao dos processos de desenvolvimento de software usados . . . 2

2.1 Custo de alterac¸˜oes num projeto tradicional de software . . . 8

2.2 Componentes do Modelo CMMI . . . 11

2.3 N´ıveis de CMMI . . . 11

2.4 Modelo de Hibs . . . 15

2.5 Modelo de Patel e Ramachandran . . . 17

2.6 Process Improvement Roadmap . . . 19

3.1 Modelo de Ambler . . . 21

3.2 Ciclo do SCRUM . . . 22

3.3 Processo de Desenvolvimento de Testes . . . 25

3.4 DAD . . . 27

3.5 Processo de Entrega Disciplinada ´Agil . . . 28

4.1 Metodologia de Trabalho . . . 43

4.2 Metodologias ´Ageis vs Metodologias Tradicionais . . . 43

4.3 Modelo Te´orico . . . 44

4.4 1o N´ıvel de Maturidade do Modelo . . . 44

4.5 1o N´ıvel de Maturidade do Modelo- Continuac¸˜ao . . . 45

4.6 2o N´ıvel de Maturidade do Modelo . . . 45

4.7 2o N´ıvel de Maturidade do Modelo- Continuac¸˜ao . . . 46

4.8 3o N´ıvel de Maturidade do Modelo . . . 46

4.9 Motivos que levaram a adoc¸˜ao de metodologias ´ageis . . . 49

4.10 Contagem de empresas com formac¸˜ao ´agil . . . 49

4.11 Percentagem de empresas com avaliac¸˜ao do processo de desenvolvimento de software . . . 50

4.12 Percentagem de projetos que usam Metodologias ´Ageis . . . 51

4.13 Metodologias ´ageis adotadas em empresas portuguesas inquiridas . . . . 51

4.14 Pap´eis usados em empresas portuguesas . . . 52

4.15 Partilha de lic¸˜oes aprendidas na empresa . . . 54

4.16 Objetivos cont´ınuos do elemento da equipa . . . 55

A.3 Inqu´erito - P´agina 3 . . . 68

A.4 Inqu´erito - P´agina 4 . . . 69

A.5 Inqu´erito - P´agina 5 . . . 70

B.1 Apresentac¸˜ao - P´agina 1 . . . 71 B.2 Apresentac¸˜ao - P´agina 2 . . . 72 B.3 Apresentac¸˜ao - P´agina 3 . . . 72 B.4 Apresentac¸˜ao - P´agina 4 . . . 73 B.5 Apresentac¸˜ao - P´agina 5 . . . 73 B.6 Apresentac¸˜ao - P´agina 6 . . . 74 B.7 Apresentac¸˜ao - P´agina 7 . . . 74 B.8 Apresentac¸˜ao - P´agina 8 . . . 75 B.9 Apresentac¸˜ao - P´agina 9 . . . 75 B.10 Apresentac¸˜ao - P´agina 10 . . . 76 B.11 Apresentac¸˜ao - P´agina 11 . . . 76 xvi

Lista de Tabelas

4.1 Identificac¸˜ao do Entrevistado . . . 37

4.2 Question´ario Parte I . . . 38

4.3 Tipologia das Respostas Parte I . . . 39

4.4 Question´ario Parte II . . . 40

4.5 Tipologia das Respostas Parte II . . . 40

4.6 Question´ario Parte III . . . 41

4.7 Tipologia das Respostas Parte III . . . 41

4.8 Quest˜oes Parte IV . . . 42

4.9 Motivos que levaram a adoc¸˜ao de Metodologias ´ageis . . . 48

4.10 Divis˜ao de trabalho . . . 52

4.11 Per´ıodo M´edio de Iterac¸˜oes . . . 53 4.12 Trabalho em conjunto com arquitetos da empresa e gestores de portfolio . 54

Cap´ıtulo 1

Introduc¸˜ao

O mundo de neg´ocios tem vindo a evoluir, e com ele uma necessidade crescente de colocar no mercado produtos e servic¸os de uma forma r´apida e eficaz. ´E neste contexto que surge a metodologia ´agil.

1.1

Motivac¸˜ao

Genericamente, quando usamos os modelos tradicionais de desenvolvimento de software temos sempre um prazo bem definido para o t´ermino do projeto e procuramos recursos para que tal acontec¸a dentro do mesmo. Normalmente estes projetos s˜ao relativamente longos, e a entrega do produto s´o ´e efetuada no final do projeto. Ora isto poder´a causar problemas graves, como por exemplo, ter perdido o time-to-market do produto, e tamb´em corremos o risco de estar a entregar um produto que n˜ao corresponde `as expetativas do cliente.

Para responder a estas e outras necessidades surge a metodologia ´agil de desenvol-vimento de software que, como se pode ver na Figura 1.1, tem vindo a apresentar bons resultados no que toca ao Retorno sobre o Investimento (ROI), na qualidade do produto final, na satisfac¸˜ao dos stakeholders, na moral ou estado de esp´ırito da equipa e no tempo de entrega do produto.

Figura 1.1: Comparac¸˜ao de equipas ´ageis e n˜ao ´ageis. Adaptado de [1].

No entanto, ainda existem v´arias desvantagens frequentemente associadas `a metodo-logia de desenvolvimento ´agil de software. Provavelmente, as mais preocupantes para quem ´e respons´avel pela gest˜ao de projetos s˜ao a falta de disciplina da equipa de desen-volvimento e a falta de controle sobre a mesma. Outros mitos muito comuns s˜ao a falta de visibilidade e de previsibilidade do trabalho que est´a a ser desenvolvido. Os gestores de projeto temem perder a vis˜ao da entrega do produto. Podemos ainda referir algumas preocupac¸˜oes como a (n˜ao) produc¸˜ao de documentac¸˜ao e o comportamento da metodo-logia ´agil perante projetos de grande escala, ou seja, a escalabilidade desta metodometodo-logia ([2–4]).

De forma a compreender melhor estes aspetos, ´e necess´ario que se entenda numa primeira fase quais os valores e princ´ıpios em que se baseia a metodologia ´agil de desen-volvimento de software. Tais valores e princ´ıpios foram enunciados no Manifesto ´Agil [5] e ser˜ao mais detalhados no Cap´ıtulo 2.

In´umeras empresas tˆem vindo a adotar esta metodologia de trabalho no seio das suas equipas de desenvolvimento de software de forma a corresponder mais eficazmente `as necessidades que o mercado imp˜oe. Como se pode observar na Figura 1.2, resultados de um inqu´erito realizado entre 13 de Fevereiro e 24 de Marc¸o de 2014 por uma empresa canadiana que demonstra a caraterizac¸˜ao dos processos de desenvolvimento de software usados na ind´ustria atual mostrou que 52% dos inquiridos j´a usa a metologia ´agil nos seus processos de trabalho nos dias de hoje Ambler [1].

Figura 1.2: Caraterizac¸˜ao dos processos de desenvolvimento de software. Adaptado de [1]

.

No entanto, para que esta metodologia traga valor acrescentado a uma empresa deve-mos garantir que a metodologia possui mecanisdeve-mos que assegurem rigor no processo de desenvolvimento de software, na consistˆencia dos entreg´aveis e que est´a alinhada com os objetivos de neg´ocio da empresa.

Cap´ıtulo 1. Introduc¸˜ao 3

A metodologia ´agil ´e um tema muito atual e que precisa de ser explorado com maior detalhe. N˜ao basta adotar a metodologia ´agil, ´e necess´ario proceder a uma an´alise pro-funda, perceber como estas empresas est˜ao a usar esta metodologia e quais as t´ecnicas que est˜ao a ser utilizadas. ´E preciso criar um ambiente favor´avel e adequado para que as empresas reflitam sobre a metodologia utilizada e confirmar que esta ´e a mais adequada `as suas necessidades de modo a identificar a melhor soluc¸˜ao para a sua empresa.

1.2

Objetivos

Este trabalho tem como objetivo fazer uma revis˜ao de literatura do trabalho relacionado nesta ´area da Engenharia Inform´atica e responder ao problema identificado e descrito na secc¸˜ao anterior.

Nesse contexto, este projeto tem como objetivo fazer uma an´alise cr´ıtica do estado de empresas face `a metodologia ´agil de uma forma integrada. Em primeiro lugar, procura-se compreender o ambiente de trabalho das equipas ´ageis, incluindo as motivac¸˜oes que levam as empresas a adotar Metodologias ´ageis em Portugal. Seguidamente, realiza-se a identificac¸˜ao das t´ecnicas e ferramentas utilizadas no desenvolvimento ´agil de software.

De acordo com as informac¸˜oes recolhidas procede-se uma avaliac¸˜ao da maturidade das empresas portuguesas segundo o Modelo de Maturidade do Processo ´Agil. Este mo-delo foi escolhido ap´os a fase de revis˜ao bibliogr´afica analisada no Cap´ıtulo 2.

Finalmente, pretende-se fazer proposta de melhorias de forma a que as empresas pos-sam alcanc¸ar n´ıveis de maturidade superiores.

1.3

Contribuic¸˜oes

As principais contribuic¸˜oes deste estudo no panorama global das Metodologias ´Ageis podem-se resumir nos seguintes pontos:

• Disponibilizar uma vis˜ao anal´ıtica da realidade das empresas ´ageis em Portugal;

• Promover a discuss˜ao dos modelos de maturidade em processos de desenvolvi-mento ´agil;

• Disseminar pr´aticas ´ageis dentro da comunidade ´agil que permitam alavancar o desempenho das equipas ´ageis em Portugal;

• Propor melhorias nos processos de desenvolvimento ´agil de forma a atingir n´ıveis mais altos de acordo com o Modelo de Maturidade em quest˜ao dentro do con-texto analisado e tendo em conta as restric¸˜oes em Portugal que derivam do concon-texto econ´omico atual.

1.4

Estrutura do documento

Este documento encontra-se organizado da seguinte forma:

• Cap´ıtulo 1 (Introduc¸˜ao), o presente cap´ıtulo, ´e um cap´ıtulo de cariz introdut´orio no qual est˜ao contemplados: a motivac¸˜ao deste trabalho, os objetivos que se pretende atingir com o desenvolvimento desta dissertac¸˜ao e as contribuic¸˜oes que este projeto faz ao panorama ´agil em Portugal.

• Cap´ıtulo 2 (Revis˜ao bibliogr´afica) apresenta o contexto onde este projeto se insere e faz uma an´alise cr´ıtica do trabalho relacionado na ´area do desenvolvimento ´agil. • Cap´ıtulo 3 (Modelo de Maturidade do Processo ´Agil) apresenta detalhadamente o

modelo escolhido para suportar a avaliac¸˜ao de maturidade das empresas ´ageis em Portugal.

• Cap´ıtulo 4 (Avaliac¸˜ao de maturidade das empresas portuguesas) contempla toda metodologia usada ao longo do estudo, o processo de recolha de dados, passando pela exposic¸˜ao dos resultados culminando com a respetiva avaliac¸˜ao de maturidade. • Cap´ıtulo 5 (Conclus˜oes) compreende as conclus˜oes finais do estudo e o trabalho

Cap´ıtulo 2

Revis˜ao Bibliogr´afica

A capacidade das organizac¸˜oes em competir, adaptar e sobreviver no mundo real est´a fortemente dependente do software que a suporta [6]. E poucos contestariam com a afirmac¸˜ao que realc¸a as aplicac¸˜oes de software como a forc¸a motriz por tr´as de gran-des operac¸˜oes modernas de neg´ocios [7].

Desta forma, podemos caraterizar a ind´ustria de software como sendo uma ind´ustria dinˆamica tanto do ponto de vista tecnol´ogico quanto do organizacional. Do ponto de vista tecnol´ogico, este dinamismo deve-se ao desenvolvimento veloz das tecnologias da informac¸˜ao e da incorporac¸˜ao cada vez maior dessas tecnologias por outros setores da atividade econˆomica. Do ponto de vista organizacional, deve-se `a necessidade constante de monitorizar o desenvolvimento tecnol´ogico, criando produtos e estabelecendo novos mercados num universo mais amplo, o que exige extrema agilidade e capacidade para localizar e se agarrar rapidamente essas oportunidades.

Neste contexto de constante evoluc¸˜ao em que o mundo se encontra, quase todas as organizac¸˜oes deparam-se com a necessidade de construc¸˜ao e entrega de produtos e servic¸os tecnicamente mais complexos e que sejam apelativos e desej´aveis para os cli-entes. Ficando a cargo destas organizac¸˜oes encontrar mecanismos sustent´aveis nos seus processos de desenvolvimento de forma a n˜ao ficar aqu´em das expetativas dos seus clien-tes.

Uma forma de orientar estas organizac¸˜oes no processo de melhoria cont´ınua ´e identi-ficando o seu n´ıvel de maturidade em v´arias disciplinas, definir metas e implementar as medidas de melhoria. Os modelos de maturidade dos processos de desenvolvimento de software foram concebidos para servir de apoio neste processo. Os modelos servem como guias de boas pr´aticas de modo a incentivar as organizac¸˜oes que desenvolvem software a melhorar continuamente os seus processos.

Este cap´ıtulo faz uma an´alise cr´ıtica do trabalho relacionado no campo da metodo-logia de desenvolvimento ´agil e encontra-se subdivido em duas secc¸˜oes principais. Na primeira secc¸˜ao ´e feita a apresentac¸˜ao da metodologia ´agil, dos seus princ´ıpios e pr´aticas mais comuns, e na segunda sec¸˜ao s˜ao apresentados os modelos de maturidade para os processos de desenvolvimento de software. O objetivo principal deste cap´ıtulo ´e permitir a compreens˜ao do dom´ınio do problema permitindo assim o seu enquadramento numa vis˜ao do panorama ´agil.

2.1

Metodologias ´

Ageis

Segundo Larman e Basili [8], a origem das metodologias ´ageis est´a intrinsecamente li-gada `as metodologias iterativas e incrementais de desenvolvimento de software. Estes acreditam que a metodologia tradicional, Metodologia em Cascata, associada `a longas etapas de desenvolvimento de projetos ser´a colocada de lado e ser´a suplantada por ciclos iterativos de menor dimens˜ao, criando outputs pr´aticos e quantific´aveis no final de cada ciclo iterativo.

Um marco importante na hist´oria da evoluc¸˜ao da Metodologia ´Agil aconteceu no ano 2001, quando dezassete pioneiros desta metodologia se reuniram em Utah, Estados Uni-dos da Am´erica, para discutir conceitos pertinentes relativos a esta nova filosofia. Este grupo resumiu a essˆencia da filosofia no Manifesto ´Agil [5].

O Manifesto ´Agil consiste numa declarac¸˜ao de doze princ´ıpios que fundamentam o desenvolvimento ´agil de software. O Manifesto deriva de quatro valores fundamentais:

• Os indiv´ıduos e suas interac¸˜oes acima de procedimentos e ferramentas;

• O funcionamento do software acima da documentac¸˜ao abrangente;

• A colaborac¸˜ao dos clientes acima da negociac¸˜ao de contratos;

• A capacidade de resposta a mudanc¸as acima de um plano preestabelecido.

A interpretac¸˜ao destas palavras constitui um enorme desafio na adoc¸˜ao desta meto-dologia. Em relac¸˜ao `a primeira declarac¸˜ao do manifesto, os seus fundadores n˜ao tinham a intenc¸˜ao de eliminar os processos e ferramentas. O que ´e importante reter nesta frase ´e a priorizac¸˜ao de interac¸˜ao entre os indiv´ıduos [9]. Os l´ıderes em conjunto com a sua pr´opria equipa devem procurar criar e manter um ambiente de trabalho que estimula a produtividade dos elementos na equipa atrav´es do respeito e confianc¸a entre os membros da equipas. Ou seja, ´e importante considerarmos as pessoas e o trabalho em equipa como

Cap´ıtulo 2. Revis˜ao Bibliogr´afica 7

fatores importantes caso contr´ario de nada valer´a para a empresa disponibilizar os melho-res processos e ferramentas para os mesmos [10].

Sem desvalorizar a importˆancia da documentac¸˜ao na compreens˜ao da arquitetura e design do sistema e na forma de interagir com o mesmo, a apresentac¸˜ao cont´ınua de soft-ware funcional, ou seja, dispon´ıvel e utiliz´avel, ´e de mais f´acil compreens˜ao e providencia um feedback imediato dos clientes [10].

´

E extremamente importante envolver o cliente durante o processo do desenvolvimento do produto, pois s˜ao maiores as probabilidades de entregar um produto que oferece ao cliente uma maior vantagem competitiva no mercado `a data de entrega em relac¸˜ao a um contrato que ´e assinado logo no in´ıcio do ciclo de desenvolvimento [10].

Em contextos de evoluc¸˜ao constante, ´e comum em projetos de software de larga es-cala, receber in´umeros pedidos de alterac¸˜ao di´arios [11]. Assim sendo, ´e importante que as equipas de desenvolvimento saibam gerir estas mudanc¸as e incorpor´a-los no produto com o tempo dispon´ıvel sem descurar da sua qualidade.

De acordo com Cohen [12], deve-se entender o desenvolvimento ´agil de software n˜ao como uma metodologia prescritiva e rigorosa, mas como uma filosofia ou abordagem de trabalho durante o processo de desenvolvimento de software.

Dentro desta filosofia, existem v´arias metodologias que seguem esta abordagem in-cluindo, o SCRUM, Extreme Programming (XP), M´etodos de Desenvolvimento de Siste-mas Dinˆamicos (DSDM), Desenvolvimento dirigido por recurso (FDD), Unified Process Agile, entre outras [12, 13]. Todas elas procuram enderec¸ar os princ´ıpios do Manifesto

´

Agil e possuem v´arios t´opicos comuns, tais como:

• Desenvolvimento de software em pequenas iterac¸˜oes que duram entre uma a quatro semanas;

• Responsabilidade da equipa de desenvolvimento sobre todo o ciclo de desenvolvi-mento de software incluindo o planeadesenvolvi-mento, definic¸˜ao de requisitos, an´alise, desen-volvimento, codificac¸˜ao, testes unit´arios e testes de aceitac¸˜ao;

• Gest˜ao disciplinada e com responsabilidade partilhada dos projetos;

• Inspec¸˜ao e reajustes frequentes;

• Colaborac¸˜ao entre equipas multifuncionais e auto-suficientes;

Na metodologia tradicional, o custo associado `a estas alterac¸˜oes no ˆambito do produto ´e exponencial consoante se vai avanc¸ando nas etapas do projeto [14] conforme se observa Figura 2.1.

Figura 2.1: Custo de alterac¸˜oes num projeto tradicional de software. Adaptado de Cohen [12].

.

Analisando este gr´afico, a soluc¸˜ao ideal passaria por investir tempo e esforc¸o num planeamento logo no in´ıcio do projeto com todos requisitos do cliente. No entanto, tendo em conta a velocidade de mudanc¸a e a capacidade de plataformas de desenvolvimento atuais, ´e irrealista pensarmos que temos todos casos poss´ıveis cobertos at´e que o produto de software seja implantado num ambiente real do cliente [11, 12].

Todavia, tal n˜ao acontece usando as t´ecnicas ´ageis onde o risco total do projeto ´e minimizado pelo contacto mais pr´oximo do cliente e permite mudanc¸as de ˆambito muito mais r´apidas e eficazes. Idealmente, no final de cada iterac¸˜ao do ciclo temos sempre produtos funcionais e prontos para serem lanc¸ados no mercado [12].

2.2

Modelos de Maturidade

A preocupac¸˜ao de existir um referencial que aborda quais as melhores pr´aticas a cumprir no processo de desenvolvimento de software j´a ´e antiga e Watts Humphrey foi um espe-cialista muito influente nesta ´area [15]. Durante o seu mandato no Software Engineering Institute (SEI), estabeleceu o Programa de Processos de Software, liderou o desenvolvi-mento do Capability Maturity Model Software [16], e introduziu os m´etodos de Avaliac¸˜ao da Capacidade do Software e do Processo de Software. Estes, posteriormente, serviram como base para o desenvolvimento do Capability Maturity Model Integration (CMMI) [17], um quadro conceptual de boas pr´aticas de engenharia de software que tem sido ado-tado por milhares de organizac¸˜oes em todo o mundo [18].

Cap´ıtulo 2. Revis˜ao Bibliogr´afica 9

Assim sendo, o primeiro modelo de maturidade para o processo de desenvolvimento de software ´e descrito por Humphrey [19], no seu livro Managing the Software Process. Este surge a partir de uma resposta de Humphrey and Kitson [20] a um pedido do De-partamento de Defesa dos Estados Unidos da Am´erica (DoD). O DoD delegou ao SEI a tarefa de formalizar e obter um mecanismo expedito para selecionar fornecedores no ˆambito do desenvolvimento de software.

O livro de Humphrey and Kitson [20] constitui um marco importante na Engenharia de Software pois serviu de alicerce para uma metodologia at´e hoje usada nas organizac¸˜oes no processo de melhoria de desenvolvimento de software e na manutenc¸˜ao dos seus proces-sos. D´a ˆenfase aos princ´ıpios b´asicos e `as prioridades no desenvolvimento de software, estando as suas sec¸˜oes organizadas por temas standard de Engenharia de Software de forma a orientar as organizac¸˜oes.

Nas pr´oximas secc¸˜oes ser˜ao descritos os modelos de maturidade CMMs e os modelos de maturidade propostos para processos de desenvolvimento ´agil de software.

2.2.1

Capability Maturity Models CMM e CMMI

Usando os princ´ıpios elicitados no livro Managing the Software Process [19], Paul cria o modelo Capability Maturity Model [16] desenhado para organizac¸˜oes de software e publica-o num livro com o t´ıtulo The Capability Maturity Model: Guidelines for Impro-ving the Software Process. Este livro constitui um guia de diagn´ostico e avaliac¸˜ao de maturidade do desenvolvimento de software numa organizac¸˜ao.

Posteriormente, surge o Capability Maturity Model Integration (CMMI) de Chrissis et al. [17]. O CMMI ´e um modelo de maturidade que visa melhorar processos de uma organizac¸˜ao e pode ser adaptado para resolver qualquer problema de desempenho, a qual-quer n´ıvel da organizac¸˜ao e em qualqual-quer setor da ind´ustria. O modelo fornece orientac¸˜oes e recomendac¸˜oes com o intuito de ajudar organizac¸˜oes no processo de diagn´ostico de pro-blemas e de melhoria do seu desempenho.

Existem trˆes modelos descritos de CMMI com diferentes p´ublicos-alvo:

• CMMI para Aquisic¸˜ao: adequado para neg´ocios cujo foco ´e iterac¸˜ao com forne-cedores para aquisic¸˜ao de produtos ou servic¸os sendo esta uma ´area cr´ıtica para desenvolver um produto ou oferecer um servic¸o;

• CMMI para Desenvolvimento: desenhado para neg´ocios cujo foco ´e desenvolver produtos e servic¸os que incluem o desenvolvimento de software;

• CMMI para Servic¸os: desenhado para organizac¸˜oes cujo foco do neg´ocio ´e criar, gerir e entregar servic¸os de qualquer tipo (relacionados ou n˜ao com o software).

O modelo relevante para os objetivos deste trabalho ´e o CMMI para Desenvolvi-mento (CMMI-DEV). O CMMI-DEV cobre todo o ciclo de desenvolviDesenvolvi-mento de um pro-duto: desde a convers˜ao dos requisitos do cliente aos da equipa de desenvolvimento, da integrac¸˜ao dos componentes do produto ao produto ou servic¸o final, da an´alise t´ecnica e trabalho de desenvolvimento a concec¸˜ao do produto ou servic¸o garantindo deste modo que o trabalho de desenvolvimento atende `as necessidades dos utilizadores finais e `as especificac¸˜oes acordadas.

O modelo CMMI-DEV ´e composto por diversos componentes: requeridos, esperados e informativos [21]. Estes encontram-se ilustrados na Figura 2.2.

• Componentes requeridos s˜ao essenciais para melhoria de processo numa determi-nada ´area;

• Componentes esperados s˜ao componentes que descrevem atividades importantes para atingir os componentes CMMI requeridos;

• Componentes informativos s˜ao aqueles usados pelos utilizadores do modo a com-preender os componentes esperados e os requeridos.

De maneira a melhor compreender o modelo CMMI, ´e importante ter o conceito de ´areas de processo bem claro. Uma ´area de processo possui um conjunto de pr´aticas (gen´ericas ou espec´ıficas) relacionadas com uma determinada ´area que ao implementa-das em conjunto, satisfaz um grupo de objetivos considerado importante para o processo de melhoria nessa mesma ´area [22].

No modelo CMMI-DEV encontram-se contempladas vinte e duas ´areas processuais organizadas por quatro categorias:

• Gest˜ao de Processo: Definic¸˜ao Organizacional de Processo (OPD), Foco Organiza-cional de Processo (OPF), Desempenho de Processo OrganizaOrganiza-cional (OPP), Gest˜ao de Processo Organizacional (OPM), Formac¸˜ao organizacional (OT);

• Gest˜ao de Projeto: Gest˜ao integrada de projeto (IPM), Monitorizac¸˜ao e Controle de projeto (PMC), Planeamento de Projeto (PP), Gest˜ao quantitativa do Projeto (QPM), Gest˜ao de Requisitos (REQM), Gest˜ao de Riscos (RSKM), Gest˜ao de for-necedores (SAM);

• Engenharia: Soluc¸˜ao t´ecnica (TS), Verificac¸˜ao (VER), Validac¸˜ao (VAL), Desen-volvimento de Requisitos (RD), Integrac¸˜ao de Produto (PI);

• Suporte: An´alise Causal e Resoluc¸˜ao (CAR), Gest˜ao de Configurac¸˜ao (CM), An´alise de decis˜ao e Resoluc¸˜ao (DAR), Medic¸˜ao e An´alise (MA), Garantia da Qualidade do Processo e do Produto (PPQA).

Cap´ıtulo 2. Revis˜ao Bibliogr´afica 11

Figura 2.2: Componentes do Capability Maturity Model Integration [17].

De acordo com a metodologia do CMMI-DEV, cada ´area de processos (com os seus respetivos processos) pode ser classificada de acordo com os seus n´ıveis de maturidade.

Existem cinco n´ıveis associados `a maturidade de processos no Modelo CMMI-DEV: inicial, gerido, definido, quantitativamente geridos e otimizado (Figura 2.3).

Figura 2.3: N´ıveis de maturidade de processos do modelo CMMI [23]. .

De realc¸ar que as ´areas de processos n˜ao constituem necessariamente processos. Os processos podem estar organizados em qualquer l´ogica ou sequˆencia que for melhor para o neg´ocio da organizac¸˜ao.

Goldenson e Gibson demonstram no seu estudo preliminar [24] que o processo de me-lhoria de processos pode resultar num aumento de desempenho e em produtos de maior qualidade. Foram avaliadas cinco medidas: custo, calend´ario, qualidade, satisfac¸˜ao do cliente e o ROI. No entanto este estudo evidencia apenas o que pode acontecer em cir-cunstˆancia ideais.

Na opini˜ao de Boehm e Turner [25], para projetos relativamente est´aveis, os pla-nos detalhados e outros mecanismos de planeamento realizados logo no in´ıcio pelas organizac¸˜oes que seguem `a risca o CMM ou CMMI aumentam efetivamente a proba-bilidade de sucesso nos projetos. No entanto, tamb´em foi constatado que quando estes projetos por alguma raz˜ao passam por alterac¸˜oes significativas, a equipa fica com maiores dificuldades para entregar o produto dentro do prazo previamente acordado.

Segundo Glazer et al. [26], usar CMMI como um padr˜ao ´e um desvio total das intenc¸˜oes dos criadores do modelo. Este acredita que o CMMI deve servir como incentivo `as organizac¸˜oes para experimentarem e utilizarem diferentes abordagens, modelos, estru-turas e pr´aticas conforme o caso, as necessidades e prioridades da organizac¸˜ao. Para tal, sugere que este deve apenas ser usado como uma ferramenta de aprendizagem e de comunicac¸˜ao, isto ´e, como um recurso para organizar pensamentos. Por´em a exigˆencia de crit´erios objetivos de diferenciac¸˜ao faz com que as organizac¸˜oes definam padr˜oes e se avaliem de acordo com o referencial CMMI.

No entanto, h´a que salientar que este modelo constitui um modelo ´unico para o pro-cesso de melhoria em termos corporativos, integrando diversos modelos e disciplinas. Como um bom modelo de boas pr´aticas, cabe `a organizac¸˜ao identificar a pr´atica que me-lhor se adapta ao seu neg´ocio e provar que d´a resposta `as ´areas processuais do CMMI. Da´ı que um processo de desenvolvimento em cascata, ou um processo de desenvolvimento SCRUM podem ter o mesmo n´ıvel de CMMI para o mesmo ˆambito. ´E um dos aspetos mais interessantes nos modelos de maturidade, ou seja a sua abrangˆencia. Quando o foco ´e a melhoria interna, por vezes queremos focar no modelo de maturidade a usar. Da´ı que esta tese versa sobre modelos de maturidade ´ageis que est˜ao mais perto de ajudar a me-lhoria cont´ınua das organizac¸˜oes que desenvolvem software de acordo com os princ´ıpios ´ageis.

2.2.2

Modelos de Maturidade ´

Ageis

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.

3.1.1

SCRUM

De acordo com Schwaber e Sutherland, o SCRUM ´e uma framework para desenvolver e manter produtos complexos [36]. Esta metodologia pretende alcanc¸ar uma lideranc¸a efetiva no projeto e na gest˜ao de requisitos eficaz e eficiente [37]. Para tal, o desenvolvi-mento de software encontra-se dividido em per´ıodos de tempo fixos - Iterac¸˜oes- pequenas de forma que sejam entregues funcionalidades de valor ao cliente mais cedo providenci-ando deste modo mais oportunidades para mudar e alinhar o produto com as expetativas do cliente [37].

O SCRUM ´e composto por v´arios elementos: equipas SCRUM, eventos e artefatos. Estes elementos relacionam-se entre si atrav´es de regras de forma a melhorar significati-vamente a produtividade da organizac¸˜ao [36]. Este metodologia encontra-se ilustrada na Figura 3.2.

Figura 3.2: Metodologia SCRUM. Adaptado de Opus [38].

As Equipas SCRUM s˜ao constitu´ıdas por um Product Owner, pela equipa de desen-volvimento e pelo Scrum Master. O Product Owner ´e respons´avel pela vis˜ao e maximizac¸˜ao do valor do produto e da sua equipa SCRUM. Este ´e o ´unico respons´avel por gerir o Pro-duct Backlog. As decis˜oes sobre o ProPro-duct Backlog poder˜ao ser tomadas coletivamente, no entanto, em ´ultimo caso o Product Owner ´e que possui a responsabilidade e autoridade sobre o Product Backlog e de todos os elementos que o integram.

Cap´ıtulo 3. Modelo de Maturidade do Processo ´Agil 23

A equipa de desenvolvimento ´e constitu´ıda por profissionais cujo trabalho ´e entre-gar, no fim de cada iterac¸˜ao (doravante sprint), vers˜oes funcionais do produto. Esta n˜ao cont´em sub-equipas dedicadas a dom´ınios espec´ıficos, tais como testes ou an´alise de neg´ocio.

O Scrum Master ´e respons´avel por garantir que o SCRUM ´e compreendido e divul-gado dentro da equipa. Em conjunto com o Product Owner, o SCRUM Master deve auxiliar na gest˜ao do Product Backlog, comunicar claramente a vis˜ao, objetivo e elemen-tos do Product Backlog `a equipa, e trein´a-la na criac¸˜ao destes elemenelemen-tos.

Os Eventos SCRUM prescritos tem por objetivo criar uma regularidade e minimizar a realizac¸˜ao de reuni˜oes adicionais. Podemos identificar v´arios eventos: sprint, Reuni˜ao de Planeamento de sprint, Reuni˜ao di´aria do sprint (Daily SCRUM), Revis˜ao do Sprint e a Retrospetiva do sprint [36].

Por ´ultimo, temos Artefatos de SCRUM que espelham o trabalho realizado pela equipa SCRUM. Estes foram concebidos para maximizar a transparˆencia e providenciar oportunidades para a inspec¸˜ao e adaptac¸˜ao. S˜ao eles o Product Backlog (lista ordenada de caracter´ısticas, func¸˜oes, requisitos que o produto deve conter que evolui `a medida que o produto e o ambiente em que ele ser´a usado evoluem), o Sprint Backlog (itens do Product Backlogque foram selecionados para o Sprint) e os Incrementos (uma vers˜ao do produto funcional no final de um Sprint).

3.1.2

Extreme Programming XP

Kent Beck, pai do Extreme Programming, no seu livro intitulado Extreme Programming explained: embrace changedefine o Extreme Programming como uma metodologia leve dirigida a pequenas a m´edias equipas de desenvolvimento de software que se deparam com requisitos vagos ou em constantes mudanc¸as [14, 39].

Ambler define Extreme Programming como um conjunto de pr´aticas para construc¸˜ao de software. Este ir´a incluir t´ecnicas tais como: Programac¸˜ao a pares, Refatorizac¸˜ao, Test First Design, Integrac¸˜ao cont´ınua e o conceito de Equipa e Propriedade Conjunta [30].

A t´ecnica de Refatorizac¸˜ao consiste na restruturac¸˜ao do design do c´odigo do sistema sem mudar o seu comportamento. Ou seja, o c´odigo continua a fazer a mesma coisa, o que muda ´e como o faz. Esta t´ecnica constitui uma oportunidade para a equipa de desen-volvimento para restruturar o sistema de modo a simplific´a-lo, adicionar flexibilidade e melhorar o desempenho do mesmo [14, 39].

Para o processo de escrita do c´odigo, a equipa de desenvolvimento usa a t´ecnica do Test-first design. Aqui, os programadores escrevem testes unit´arios que devem ser co-bertos a 100%. Finalizada esta fase, o Product Manager especifica os testes funcionais para confirmar que o requisito foi alcanc¸ado [39].

A t´ecnica de Programac¸˜ao a pares requer que todo o c´odigo produzido seja escrito por dois programadores e uma m´aquina [14]. Cada elemento do par possui responsabi-lidades distintas. Um deles, o chamado condutor possui a m´aquina a seu dispˆor e tem a responsabilidade de produzir o c´odigo. Enquanto que, o outro, denominado navegador, tem a func¸˜ao de pensar no que o condutor esta a codificar, e de que forma este pedac¸o de c´odigo ir´a afetar o design global do software em produc¸˜ao, assumindo desta forma uma posic¸˜ao mais estrat´egica [14, 39].

Um problema recorrente das empresas que produzem software tem a ver com atrasos desde o momento que a equipa de desenvolvimento diz que j´a est´a pronto at´e o momento que este se pode entregar ao cliente. A Integrac¸˜ao cont´ınua constitui uma ´otima aborda-gem para este problema pois garante que o c´odigo de todos programadores estejam inte-grados e constr´oi uma infra-estrutura de lanc¸amento juntamente com o resto da aplicac¸˜ao. O ideal seria entregar todos componentes do software funcionais e prontos-a-usar exceto as ´ultimas horas de trabalho a qualquer momento [14, 39].

Outro conceito inovador introduzido para esta metodologia ´e o de Equipa e Proprie-dade conjunta, na qual todas as pessoas envolvidas no desenvolvimento do produto s˜ao respons´aveis pela qualidade do c´odigo produzido. Qualquer pessoa pode alterar qualquer linha de c´odigo, corrigir erros de software e melhorar o design do sistema em produc¸˜ao [39].

3.1.3

Framework ´

Agil

A Framework ´Agil consiste num conjunto de pr´aticas de modelac¸˜ao leve incluindo colocac¸˜ao dos requisitos em diversas perspetivas, especificac¸˜oes execut´aveis, participac¸˜ao ativa das partes interessadas, e a manutenc¸˜ao de requisitos priorizados que v˜ao de encon-tro com o c´odigo produzido pelas equipas de desenvolvimento.

No in´ıcio de qualquer projeto, na fase de an´alise deveremos prestar atenc¸˜ao a algumas vari´aveis importantes: o ˆambito do projeto, o calend´ario e o orc¸amento deste. A partir desta an´alise, cria-se uma pilha inicial de requisitos. De forma, a colocar os requisitos em diferentes perspectivas s˜ao criadas v´arias estruturas. Inicialmente, para cada um deles cria-se um caso de uso de alto n´ıvel. Ap´os esta fase passa-se para os Modelos de

Cap´ıtulo 3. Modelo de Maturidade do Processo ´Agil 25

Dom´ınio onde s˜ao capturadas as entidade de neg´ocio principais e as relac¸˜oes entre eles e por fim as interfaces com o utilizador [40].

Os testes passam a ser especificac¸˜oes detalhadas. Primeiro escreve-se o c´odigo de teste e s´o depois o c´odigo funcional [41]. O processo pode ser observado na Figura 3.3.

Figura 3.3: Test-First Development. Adaptado de Ambler [41].

Podemos descrever a t´ecnica Test Driven Development como um agregado da t´ecnica de Test-First Development e do uso da refatorizac¸˜ao [41].

A participac¸˜ao ativa das partes interessadas constitui uma oportunidade ´unica de envolver pessoas com autoridade e habilidade para providenciar informac¸˜ao pertinente em relac¸˜ao ao sistema a em produc¸˜ao. ´E importante usar sabiamente este espac¸o de modo a garantir que os mesmos tomem decis˜oes pertinentes e pontuais em relac¸˜ao aos requisitos e `a priorizac¸˜ao destes.

3.1.4

Agile Data

Agile Data consiste num conjunto de pr´aticas para o desenvolvimento de base de dados, incluindo Framework ´Agil de dados, testes, refatorizac¸˜ao, e integrac¸˜ao cont´ınua de base de dados.

A t´ecnica de Refatorizac¸˜ao de base de dados consiste na mudanc¸a de um esquema de base de dados com objetivo de melhorar o seu design, mantendo a sua semˆantica a n´ıvel comportamental e informativo. Preservar a semˆantica a n´ıvel informativo ir´a impli-car que quando mudamos os valores dos dados armazenados numa coluna os clientes, a informac¸˜ao n˜ao deve ser afetada pela melhoria. Usando o mesmo racioc´ıneo, em relac¸˜ao `a semˆantica comportamental o objetivo ´e manter a funcionalidade de caixa preta ou seja qualquer c´odigo fonte que funciona com os novos aspectos de mudanc¸as no seu esquema de base de dados deve ser reformulado para realizar a mesma funcionalidade que fazia antes da mudanc¸a [42].

O processo de Testes das Bases de Dados Relacionais constitui um t´opico importante no desenvolvimento de software pois os dados constituem um recurso crucial de qualquer organizac¸˜ao e os testes podem providenciar um feedback concreto para identificar defei-tos no sistema.

3.2

APMM N´ıvel 2 - Entrega Disciplinada ´

Agil

O segundo n´ıvel de maturidade proposto por Ambler [30] estende o primeiro n´ıvel e passa a enderec¸ar todo ciclo de vida do sistema de software. De forma a cumprir os objetivos deste n´ıvel, deve-se ter em considerac¸˜ao o processo de testes, o de medic¸˜ao, o de melhoria cont´ınua do processo de desenvolvimento de software e ainda os mecanismos efetivos na gest˜ao.

A estrutura de decis˜ao da Entrega Disciplinada ´Agil (DAD) tem v´arios aspetos in-teressantes. Esta abordagem coloca as pessoas como um fator importante no processo de entrega de software, sugerindo pap´eis espec´ıficos para cada fase de desenvolvimento. Constitui uma abordagem h´ıbrida ´agil orientada `a aprendizagem para a soluc¸˜ao de entrega de software.

No que diz respeito ao Risco, este n´ıvel de maturidade pressup˜oe um risk-value deli-very lifecycle, isto ´e, promove a realizac¸˜ao das tarefas mais arriscadas logo ao in´ıcio do projeto a fim de elimin´a-los logo no in´ıcio, aumentando desta forma a probabilidade de sucesso no projeto.

Cap´ıtulo 3. Modelo de Maturidade do Processo ´Agil 27

A Entrega Disciplinada ´Agil apresenta v´arias carater´ısticas ´unicas: ´e orientada a ob-jetivos, ´e enterprise-aware (olha para a empresa como um todo) e ´e escal´avel.

Esta constitui uma abordagem h´ıbrida que engloba estrat´egias de diferentes metodo-logias ´ageis, como mostra a Figura 3.4.

Figura 3.4: Entrega ´Agil de Software [43].

O objetivo do DAD ´e o de mostrar como us´a-las em conjunto para melhor produtivi-dade da organizac¸˜ao [43]. Entre as metodologias acima referidas na Figura 3.4, Ambler [30] d´a ˆenfase `as seguintes metodologias:

• Processos H´ıbridos: agregado da framework de processos do SCRUM e as ideias do XP;

• Rational Unified Process (RUP): ´e um processo abrangente para entrega software. Pr´aticas do RUP incluem o conceito de equipa, Desenvolvimento dirigido por testes (TDD), esboc¸o de processo de neg´ocio e integrac¸˜ao continua;

• Open Unified Process (OpenUP): combina e estende pr´aticas de SCRUM, XP, Modelagem ´Agil e RUP direccionadas `a equipas ´ageis de desenvolvimento de pro-duto alocadas no mesmo espac¸o f´ısico . Pr´aticas de OpenUP incluem conceito de equipa, reuni˜oes di´arias, prioritizac¸˜ao de itens de trabalho, ciclo de vida orientado para o risco, TDD, participac¸˜ao ativa das partes interessadas e integrac¸˜ao cont´ınua;

• Harmony Embedded Software: processo ´agil de software para sistemas embebi-dos;

• Dynamic System Development Method (DSDM) : processo de entrega baseado em Rapid Application Development (RAD) que ´e muitas vezes usado no desenvol-vimento de interface de utilizador da aplicac¸˜ao intensiva. Inclui pr´aticas de

prototi-pagem, testes durante todo ciclo de vida e alterac¸˜oes revers´ıveis.

Tal como referido inicialmente, o DAD enderec¸a todo ciclo de vida do software. Po-demos dividir este ciclo em trˆes fases: concec¸˜ao, construc¸˜ao e transic¸˜ao sendo que o objetivo ´e produzir continuamente uma vers˜ao potencialmente mais funcional. Pode-se observar o processo na Figura 3.5.

Figura 3.5: Processo de Entrega Disciplinada ´Agil. Adaptado de Ambler [43].

A cada uma das trˆes fases est˜ao associados objetivos espec´ıficos ´a cada uma delas: objetivos durante a concec¸˜ao, a construc¸˜ao e transic¸˜ao. E para al´em destes temos objeti-vos cont´ınuos independente da fase em curso.

O prop´osito da fase de concec¸˜ao, ´e o de garantir que est˜ao reunidas todas as condic¸˜oes para se iniciar um processo de desenvolvimento de software. Assim sendo, os objetivos desta fase passam por: formac¸˜ao da equipa inicial, desenvolvimento de uma vis˜ao comum, alinhamento com a estrat´egia da organizac¸˜ao, explorac¸˜ao detalhada do ˆambito inicial, identificac¸˜ao da estrat´egia t´ecnica inicial, desenvolvimento de plano inicial de entregas, garantia de recursos monet´arios, desenvolvimento de ambiente de trabalho e identificac¸˜ao de riscos.

Ap´os esta fase, passamos para a fase de construc¸˜ao em que o prop´osito ´e produzir uma soluc¸˜ao potencial de modo iterativo e incremental. Os objetivos espec´ıficos desta fase s˜ao: produc¸˜ao de uma soluc¸˜ao potencialmente utiliz´avel, comerci´avel e desej´avel; enderec¸ar `as constantes mudanc¸as de necessidades das partes interessadas; constante aproximac¸˜ao de uma soluc¸˜ao que possa ser entregue ao cliente; constante melhoria de qualidade e a confirmac¸˜ao que a estrat´egia arquitetural inicial funciona.

Cap´ıtulo 3. Modelo de Maturidade do Processo ´Agil 29

A ´ultima fase, a fase da transic¸˜ao, tem como principal finalidade colocar a soluc¸˜ao em produc¸˜ao para estar dispon´ıvel no mercado. Os dois objetivos para esta fase s˜ao: ga-rantir que a soluc¸˜ao est´a pronta para ser implantada e ser aceite no cliente e a respetiva implantac¸˜ao do software no cliente.

N˜ao menos importante, temos objetivos cont´ınuos durante todo o processo: cresci-mento pessoal e professional de cada elecresci-mento da equipa, cumpricresci-mento dos objetivos de equipa, enderec¸amento aos riscos, promoc¸˜ao da utilizac¸˜ao de recursos e infraestruturas organizacionais, coordenac¸˜ao de atividades, melhoria cont´ınua do ambiente de trabalho e da forma de trabalhar em equipa.

Apesar de possuir objetivos bem delineados e expl´ıcitos, o DAD n˜ao ´e prescritivo. Tomando como exemplo a gest˜ao de requisitos, o SCRUM prescreve o uso de Product Backlog para gest˜ao dos mesmos. Enquanto que o DAD avalia esta quest˜ao colocando na mesa os seus aspetos importantes sem comprometer-se com uma determinada t´ecnica. Durante a construc¸˜ao existe o objetivo de enderec¸ar as constantes mudanc¸as de necessi-dades das partes interessadas e para isso existem v´areas ´areas a analisar: a estrat´egia de gest˜ao do item de trabalho e a estrat´egia para prioritizac¸˜ao dos mesmos, a monitorizac¸˜ao da aceitac¸˜ao das partes interessadas, o modo de iterac¸˜ao das partes interessadas com a equipa e a elicitac¸˜ao de m´etodos.

3.3

APMM N´ıvel 3 - Agilidade em Escala

O N´ıvel 3 do Modelo de Ambler [30] enderec¸a explicitamente as complexidades que as equipas de desenvolvimento ´agil de software enfrentam no mundo real. Aqui, a metodo-logia ´Agil tem de adaptar-se a diferentes tipos de neg´ocios, organizac¸˜ao e complexidades t´ecnicas atuais.

Os fatores de escala a ter-se em conta incluem: o tamanho da equipa, a distribuic¸˜ao f´ısica, distribuic¸˜ao organizacional, a conformidade, o contexto cultural ou organizacional, a complexidade do sistema e as disciplinas corporativas [30].

O tamanho de equipa pode variar desde duas at´e vinte e cinco, cem pessoas depen-dendo da dimens˜ao do projeto em quest˜ao. Este tamanho da equipa vai influenciar as for-mas de coordenar pois, quanto maior for o seu tamanho maior a complexidade. Quando temos equipas grandes, a soluc¸˜ao passa por subdividir em pequenas equipas, todavia a mensagem chegar´a sempre mais r´apido e sem deturpac¸˜oes se estivermos a lidar com uma equipa pequena.

Sobre a distribuic¸˜ao f´ısica, as equipas ´ageis podem encontrar-se localizadas na mesma sala, edif´ıcio ou em diferentes locais ou mesmo pa´ıses. Muitas pessoas, equivocadas, acreditam que as pessoas que trabalham em metodologias ´ageis devem estar no mesmo lo-cal [44]. Existem enormes benef´ıcios associados a uma maior distribuic¸˜ao geogr´afica, tais como: acesso a uma maior grupo de pessoas qualificadas, menores custos de produc¸˜ao, maior time-to-market (admitindo que h´a sempre algu´em a trabalhar durante as vinte e quatro horas do dia). Todavia existem sempre riscos associados ao fato das equipas tra-balharem distantes uma das outras, tais como: comunicac¸˜ao (como por exemplo, a n˜ao visiualizac¸˜ao da linguagem corporal), dificuldade com os fusos hor´arios, diferenc¸as cul-turais, entre outros.

O fator da distribuic¸˜ao organizacional entra em campo quando envolvemos pessoas de diferentes organizac¸˜oes no projeto. ´E mais f´acil quando temos todos os elementos da equipa da mesma organizac¸˜ao pois todos tem os mesmos deveres e est˜ao sujeitos `as mes-mas regras. Isto n˜ao acontece quando temos recursos subcontratados.

Existem dois tipos de conformidade que a empresa pode estar sujeita. A empresa pode decidir por vantagem competitiva do mercado por exemplo, decidir seguir as nor-mas CMMI ou ISO. A segunda forma ´e a conformidade regulamentar (financeiras, de privacidade, etc). Em ambos casos, do ponto de vista processual estas ir˜ao implicar mais documentac¸˜ao e mais revis˜oes.

O contexto cultural e contextual da organizac¸˜ao que envolve as equipas do projeto ir˜ao influenciar diretamente o seu crescimento.

A complexidade do pr´oprio sistema, seja a n´ıvel t´ecnico ou de dom´ınio, a ser cons-tru´ıdo tamb´em influencia a estrat´egia de produzir em larga escala. Por exemplo, a n´ıvel de dom´ınio, a construc¸˜ao de um website ser´a mais f´acil em relac¸˜ao `a um sistema dentro da ind´ustria aeron´autica. Neste ´ultimo caso deveremos ter mais investimento inicial na fase de modelac¸˜ao e planeamento. A n´ıvel t´ecnico, as medidas a tomar em caso de aplicac¸˜oes que dever˜ao suportar mais plataformas tecnol´ogicas ou lidar com base de dados antigas s˜ao diferentes em relac¸˜aos `as aplicac¸˜oes mais simples.

Os regulamentos e disciplinas corporativas como a reutilizac¸˜ao estrat´egica, a arqui-tetura corporativa, e gest˜ao de portfolio v˜ao conduzir a diferentes tomadas de decis˜oes.

Cada fator traz consigo uma enorme complexidade ao projeto, e cada equipa ´agil ter´a de lidar com diferentes combinac¸˜oes. Assim vai precisar de um processo, a estrutura da