Francisco José Martins Dias Ferreira. Desenvolvimento de uma escala de agilidade para equipas de projetos TI, em ambientes ágeis

Transcrição

1 Francisco José Martins Dias Ferreira Desenvolvimento de uma escala de agilidade para equipas de projetos TI, em ambientes ágeis Projeto de Dissertação de Mestrado Mestrado em Engenharia e Gestão de Sistemas de Informação Trabalho efetuado sob a orientação do/da/de Professor Doutor Pedro Miguel Gonzalez Abreu Ribeiro Janeiro de 2018

2 DECLARAÇÃO Nome: Francisco José Martins Dias Ferreira Endereço eletrónico: Telefone: /telefone 2 (alternativo) Bilhete de Identidade/Cartão do Cidadão: Título da dissertação: Desenvolvimento de uma escala de agilidade para equipas de projetos TI, em ambientes ágeis Orientador: Professor Doutor Pedro Miguel Gonzalez Abreu Ribeiro Ano de conclusão: 2018 Mestrado em Engenharia e Gestão de Sistemas de Informação É AUTORIZADA A REPRODUÇÃO INTEGRAL DESTA DISSERTAÇÃO APENAS PARA EFEITOS DE INVESTIGAÇÃO, MEDIANTE DECLARAÇÃO ESCRITA DO INTERESSADO, QUE A TAL SE COMPROMETE. Universidade do Minho, / / Assinatura: ii

3 AGRADECIMENTOS É uma secção a escrever mais tarde que estará presente no relatório de dissertação final. iii

4

5 RESUMO As tecnologias de informação são cada vez mais um fator distintivo do sucesso das organizações. Inúmeras organizações têm equipas a desenvolver projetos de tecnologias de informação. Para desenvolver estes projetos existe um grande número de modelos e abordagens que tencionam servir de guia para este desenvolvimento. Este projeto de dissertação tem o objetivo de recolher o estado da arte circundante ao tema desta dissertação. Tem a importância de criar os alicerces necessários para a fase seguinte, que será a construção de um escala que possibilite medir a maturidade ágil das equipas de projetos de TI, que é o grande objetivo final de todo este trabalho de dissertação. Quando se elaboram projetos nesta área, deve ter-se em mente vários pressupostos e princípios, que podem ou não ser aplicados. A área da engenharia de software aborda muitas áreas de conhecimento e é preciso ter noção delas. Existem vários métodos tradicionais e ágeis que podem ser aplicados em projetos de TI, dependendo do tipo de projeto, a organização e/ou equipa devem escolher a metodologia mais indicada para o desenvolvimento do projeto. Dentro dos métodos tradicionais existem modelos de processos e modelos de maturidade, dos quais alguns são descritos neste documento. Após estes, também são descritas várias abordagens ágeis. Ora, o objetivo desta dissertação é desenvolver uma escala de agilidade para equipas de TI, em ambientes ágeis. Com agilidade a intenção é referir à maturidade ágil. Até à data, ainda não foram descobertos quaisquer estudos relacionados com maturidade ágil. Desta maneira, é necessário abordar modelos tradicionais de avaliação de maturidade, como o CMMI, ISO 15504, o TSP, o PSP e o P-CMM. Após isto, faz-se a recolha e caracterização das práticas de vários modelos ágeis. Após isto, já na fase posterior a este projeto de dissertação, será feito um estudo da evolução das equipas em ambientes ágeis. Com todas estas informações, tenciona-se conseguir então os fundamentos necessários para a criação do artefacto final desta dissertação. Este trabalho será elaborado com recurso à metodologia Design Science Research, que consiste na revisão de literatura dos conceitos mais relevantes para o tema, seguidos de uma proposta de artefacto que possa contribuir para a ciência. Este modelo pressupõe ainda que o artefacto desenvolvido seja avaliado num contexto real. Palavras- Chave: Projetos de TI, Maturidade ágil, práticas, abordagens ágeis, modelos de maturidade. v

6

7 ABSTRACT Information Technologies represents one distinctive success factor in nowadays organizations. A tremendous number of organizations have teams to develop IT projects. In order to develop this projects, there are a large number of approaches that are intended to guide this development. This dissertation project aims to collect the state of the art surrounding the theme. It is important to create the necessary foundations for the next phase, which will be the construction of a scale that makes possible to measure the agile maturity of IT project teams, and that is the great final goal of all this dissertation work. When designing projects in this area, a number of assumptions and principals should be kept in mind, although they can or not be applied. There are several traditional and agile approaches that can be applied to IT projects, depending on the type of project, the organization can choose the most appropriate methodology to the development of the project. Within the traditional methods there are process models and maturity models, some of them are described in this document. Several agile approaches are also described. The purpose of this dissertation is to develop an "agility" scale for IT teams, in agile environments. With "agility" the intention is to refer to agile maturity. No studies related to agile maturity have yet been discovered. So, it is necessary to approach traditional models of maturity evaluation, such as CMMI, ISO 15504, TSP, PSP and P-CMM. After this, the practices of several agile models are collected and characterized. After this, in the subsequent phase to this dissertation project, will be made a study of the evolution of the teams in agile environments. With all this information, it is intended to obtain the necessary foundations for the creation of the final artifact of this dissertation. This work will be elaborated using the methodology Design Science Research, which consists in the literature review of the most relevant concepts for the theme, followed by a proposal of artifact that can contribute to science. This model also assumes that the artifact developed is evaluated in a real context. Key words: IT projects, Agile maturity, practices, agile approaches, maturity models. vii

8

9 ÍNDICE Agradecimentos... iii Resumo... v Abstract... vii Lista de Figuras... xi Lista de Tabelas... xiii Lista de Abreviaturas, Siglas e Acrónimos... xv 1. Introdução Enquadramento Finalidade e Principais Objetivos da Dissertação Organização da Dissertação Revisão de Literatura Estratégia de Pesquisa Fontes de Dados e Estratégia de Pesquisa Seleção dos Artigos Extração dos Dados e Síntese Tecnologias de Informação e Sistemas de Informação Métodos Tradicionais Engenharia de Software... 9 SWEBOK... 9 Quatro Atividades Fundamentais da Engenharia de Software ISO Modelos de Processo Waterfall V-Model Rational Unified Process Modelos de Maturidade CMMI Personal Software Process (PSP) Team Software Process (TSP) ix

10 People Capability Maturity Model (P-CMM) ISO Abordagens Ágeis Manifesto Ágil Chaos Report Métodos ágeis Extreme Programming (XP) Scrum OpenUP Kanban Outros métodos existentes e conclusões gerais Caracterização do estudo Abordagem Metodológica Plano de Atividades Conclusões Bibliografia x

11 LISTA DE FIGURAS Figura 1- Tópicos para a área de conhecimento Engineering Process (retirado de (IEEE, 2014)) Figura 2- Passos para o desenvolvimento de um programa (retirado de Royce (1970)) Figura 3- Diagrama representativo do V-Model (retirado de 14 Figura 4-Framework do RUP (retirado de 16 Figura 5- Os 5 níveiws de maturidade do P-CMM (Retirado de (Curtis, et al., 2009)) Figura 6- Comparação da Chaos Resolution entre Agile e Waterfall (retirado de 29 Figura 7-Ciclo de Vida do Processo em XP (retirado de Abrahamson, et al.,(2002)) Figura 8 - Fluxo de trabalho do OpenUP (Retirado de 44 Figura 9-Delivery Process do OpenUp (Retirado de Balduino (2007) Figura 10-Práticas do OpenUP (Adaptado de 47 Figura 11- Fases Constituintes da metodologia DSR Figura 12- Diagrama de Gantt xi

12

13 LISTA DE TABELAS Tabela 2- Organização dos Processos por Níveis de Maturidade (adaptado de SEI (2010)) Tabela 3- Descrição das fases do ciclo de vida do XP (adaptado de Beck (1999;2000) e Abrahamson, et al.,(2002)) Tabela 4- Descrição dos papéis e responsabilidades do XP (adaptado de Beck (2000)) Tabela 5- Práticas do XP (Adaptado de Beck (1999,2000), Abrahamsson, et al.,(2002), Sommerville (2015a)) Tabela 6-Ciclo do Scrum (Retirado de Sutherland e schwaber, (2011)) Tabela 7- Mapeamento entre as iterações e respetivas atividades com os bojetivos de cada fase (Adaptado de Balduino (2007) e de 44 Tabela 8-Papéis e respetivas responsabilidades da equipa em OpenUP (Adaptado de Balduino (2007) e 45 Tabela 9- Mapeamento entre os princípios do Agile Manifesto e dos principios do OpenUP (Adaptado de Balduino (2007) e 46 Tabela 10- Sumáio das práticas do Kanban e respetivas descrições (Adaptado de Anderson & Carmichael, 2016)) xiii

14

15 LISTA DE ABREVIATURAS, SIGLAS E ACRÓNIMOS CMMI CMMI-DEV CMM SCAMPI SPICE ISO PMBOK TI SI SWEBOK RUP P-CMM UML TSP PSP DSR Capability Maturity Model Integration CMMI for development Capability Maturity Model Standard CMMI Appraisal Method for Process Improvement Software Process Improvement and Capability Determination International Organization of Standardization Project Management Body of Knowledge Tecnologias de Informação Sistemas de Informação Software Engineering Body of Knowledge Rational Unified Process People Capability Maturity Model Unified Modeling Language Team software process People software Process Design Science Research xv

16

17 1. INTRODUÇÃO 1.1 Enquadramento Hoje em dia, no mundo atual, em que cada vez vivemos mais inundados de informação, os sistemas de informação que são bem implementados representam uma grande arma para as empresas, caso sejam utilizadas todas as suas capacidades. Têm grande importância pois processam os dados da organização para gerar informação que é útil para gerir as suas operações. Cada vez mais os clientes e utilizadores finais de projetos de tecnologias de informação requerem mais qualidade e funcionalidades, com menos tempo, custos e recursos, desta maneira surge a necessidade de utilizar certos mecanismos ou metodologias que permitam às empresas gerir as suas atividades de desenvolvimento para atingir os seus objetivos de negócio (SEI, 2010). A engenharia de software segue esta tendência, tendo atualmente uma fraca reputação no que diz respeito a falhas de prazos, custos e muitas das vezes ao nível da qualidade do produto final que foi solicitado pelo cliente. Uma maneira de contornar este problema é utilizando metodologias de desenvolvimento já bem enraizadas no mercado. Estas metodologias servem para ajudar a organizar o trabalho de desenvolvimento de software. Existem as metodologias tradicionais e as metodologias ágeis, que apresentam algumas diferenças, mas podendo uma ou outra ser mais eficiente em diferentes tipos de projetos, portanto não é possível saber qual a melhor entre as duas, sem saber o tipo do projeto que certa equipa vai desenvolver. Existem até autores que falam na integração entre a metodologia apresentada pelo CMMi e da Ágil. Durante muitos anos as metodologias tradicionais eram mais conhecidas, apesar de existirem também metodologias chamadas de lean methodologys, mas a partir do Agile Manifesto (2001) o termo ágil ganhou popularidade e definindo alguns valores e princípios alternativos (Beck et al., 2001). Existem vários métodos para o desenvolvimento ágil de software, e uma parte deste projeto de dissertação vai ser o estudo desses métodos e modelos ágeis, após o estudo de modelos tradicionais, como modelos de maturidade e modelos de processo, mas com foco na maturidade, para analisar a evolução típica em equipas que trabalham em ambientes ágeis. Esta evolução poderá ser estudada através de artigos que se consigam recolher. Mas também se pretende que exista o contacto com empresas reais que aplicam metodologias ágeis e, através de entrevistas nessas empresas tentar perceber o sucesso que têm vindo a obter, as práticas que aplicam, as abordagens que utilizam, entre 1

18 outros aspetos que na altura possam ser relevantes para servir de input ao desenvolvimento do artefacto final. O objetivo será a conseguir elaborar uma proposta de escala de agilidade, com os diversos níveis de evolução. Os métodos tradicionais são pouco flexíveis o que contrasta com os ágeis que providenciam um conjunto de práticas que permite adaptações rápidas a pedidos do cliente e que vão de encontro às necessidades que o moderno desenvolvimento de produtos apresenta (Papadopoulos, 2014). Podem ainda escolher entre utilizar as duas dependendo do tipo de projeto que têm em mãos ou tentam integrar ambas a metodologias (Glazer et al., 2008). Serão pesquisados estudos com algumas informações relativas à aplicação de metodologias Ágeis, ou de métodos como o SCRUM, o XP, Kanban, OpenUP, por exemplo. Um dos exemplos é a utilização de técnicas ágeis para a evolução da plataforma de Inteligência da Força Aérea dos Estados Unidos, desta forma apresentam um trabalho incremental, abordagens iterativas para conseguir entregas de grande capacidade mais frequentemente e de uma maneira mais gerida (Levinson, 2016). Outro exemplo relevante de literatura entre muitos outros, será por exemplo o artigo publicado por Bradley de Souza em 2015, que diz que a Agilidade vem acompanhada da maturidade e explica que a abordagem Ágil é ideal para projetos pequenos em organizações pequenas, mas quando é requerida uma escala maior, o modelo precisa de ser ajustado para ser efetivo (Souza, 2015). Em suma, a partir de um problema, que é o de medir a maturidade ágil das equipas de desenvolvimento de Tecnologias de Informação, este trabalho visa desenvolver um artefacto, sendo neste caso uma escala capaz de apresentar resposta ao problema referido previamente. Irão ser cobertos vários modelos tradicionais e ágeis para ser possível, posteriormente, fazer a comparação entre eles e definir quais as melhores práticas que devem ser incorporadas para tentar medir a maturidade ágil de equipas de desenvolvimento de projetos TI. Isto será complementado com o estudo da evolução de equipas ágeis, como por exemplo se usam métodos ágeis para todos os tipos de projetos, se antes usavam métodos tradicionais e fizeram a mudança para ágeis, se tentam incorporar os dois, possíveis aspetos positivos e/ou negativos com a adoção de algum dos métodos face a diferentes tipos de projeto e possível perceção das áreas que algumas empresas cobrem com mais ou menos frequência tendo em vista o sucesso. Para assim se tentar medir através de várias comparações e perceções, a maturidade ágil, construindo posteriormente uma escala que possa medir a agilidade das equipas de desenvolvimento de projetos de TI. Visa-se chegar a este artefacto com o estudo de diversa literatura como contida neste documento, através do estudo dos modelos tradicionais de avaliação de maturidade, após isto o estudo de modelos 2

19 ágeis e das principais práticas, da evolução das equipas em ambientes ágeis e da definição do conceito de Zero process para assim ter ferramentas necessárias que permitam elaborar uma ferramenta que neste caso vai conseguir escalar a agilidade das equipas. Esta será uma versão preliminar que vai ter uma aplicação prática e a recolha de opinião de especialistas para assim conseguir elaborar uma nova escala com base nos trabalhos de validação já referidos. 1.2 Finalidade e Principais Objetivos da Dissertação Esta dissertação tem a finalidade de desenvolver uma escala de agilidade para equipas de projetos TI, em ambientes ágeis, para assim ser possível medir a sua maturidade. Desta forma, é necessário o estudo de modelos tradicionais e ágeis existentes e também de entidades que fizeram a transição da utilização de modelos tradicionais para ágeis. De seguida apresentam-se os principais objetivos propostos: Estudar modelos tradicionais de avaliação de maturidade (CMMI, ISO 15504); Caracterizar práticas ágeis dos modelos principais; Definir o conceito de zero process ; Definir uma escala para medir a maturidade ágil das equipas de desenvolvimento TIs; Validar o modelo com casos práticos e opinião de especialistas 1.3 Organização da Dissertação O primeiro capítulo desta dissertação contém a Introdução, onde está o enquadramento do trabalho, onde é descrita a finalidade e quais os objetivos principais. Por fim apresenta a estrutura e organização do documento de uma forma simples. O segundo capítulo, Revisão de Literatura, é onde é feito o estudo de vários conceitos, métodos, abordagens importantes relacionados com o tema, tais como a engenharia de software, modelos de processo, modelos de maturidade e abordagens ágeis, para que se consiga obter todos os alicerces necessários para avançar à próxima fase desta dissertação, que consiste em começar a construir o artefacto. O terceiro capítulo, caracterização do estudo, contem a abordagem metodológica, onde se refere a forma como se vai realizar este trabalho de investigação e também o planeamento das tarefas que fazem parte desta dissertação. 3

20 O quarto e último capítulo apresenta as conclusões e uma pequena síntese do trabalho que foi realizado até à data. 4

21 2. REVISÃO DE LITERATURA 2.1 Estratégia de Pesquisa Fontes de Dados e Estratégia de Pesquisa Para a elaboração deste tópico, cujo objetivo é trabalhar e estudar o estado da arte, para realizar uma revisão de literatura, inicialmente foram feitas algumas pesquisas para se verificar se existiam estudos que cobrissem o tema desta dissertação, através de motores de busca como o Google Scholar, a IEE Eletronic Xplore Digital Library e o presente no website da Carnegie Mellon University (CMU). Não foram encontrados artigos que cobrissem totalmente o tema, ou seja, que o assunto fosse escalas de maturidade ágil. Então, o passo seguinte foi começar por investigar várias abordagens tradicionais e ágeis, ao mesmo tempo que se pesquisava se existiam propostas de maturidade para alguma destas. A solução pensada foi então pesquisar por vários métodos tradicionais e ágeis e fazer um estudo sobre estes e as práticas que os constituem. Algumas das abordagens não têm práticas explícitas, mas podem ser importantes devido ao processo que têm associados e podem ser úteis na conceção do artefacto desta dissertação, da escala de maturidade ágil. Assim, ao pesquisar por artigos de assuntos mais específicos e restritos, foram encontrados artigos com elevada relevância e muitos deles publicados em conferências (como a Agile conference, por exemplo), revistas ou jornais científicos com boa reputação na área, como por exemplo o International Journal of Information Technology and Business Management, The Journal of Systems and Software, Information and Software Technology, Journal of Software Maintenance and Evolution: Research and Practice, entre outros. Para além disto, foi feita a pesquisa de vários livros, que continham informações bastante interessantes publicados por Ian Sommerville e Roger S. Pressman, alguns com excertos disponíveis no Google Books, outros por autores pertencentes à Agile Alliance, como Kent Beck, Alistair Cockburn, Mike Beedle, Ken Schwaber, Jeff Sutherland, assim como de documentos publicados por entidades como o Software Engineering Institute, pelo Projeto Eclipse, pelo Project Management Institute (PMI), pela IBM e pela IEEE Computer Society, por exemplo. Apesar de toda a documentação importante encontrada acima, foram ainda utilizados outros motores de busca para o acesso a mais informação que foi estudada e alguma dela utilizada já neste projeto de dissertação. Os outros motores de busca que foram utilizados para obter mais documentação 5

22 das suas bases de dados e assim ter uma boa base de pesquisa, quer para o estado da arte incluído no projeto de dissertação, quer para o arranque da fase seguinte, foram por exemplo: o ScienceDirect, o ResearchGate, o Scopus, o RepositoriUM, o WebofScience e o Springer. Assim, com esta documentação retirada de fontes concretas e com foco na área, acredita-se que também as informações conseguidas para esta revisão de literatura possuem grande relevância no ambiente que envolve o tema. Várias expressões simples e compostas foram utilizadas para esta pesquisa, a lista que se segue, contém apenas as mais relevantes de uma infinidade de combinações de palavras e conceitos utilizados: Software Engineering e SWEBOK ; Maturity Models e Modelos de Maturidade ; Process Models e Modelos de Processo ; Information Systems e Sistemas de Informação ; Information Technology e Tecnologias de Informação ; CMMI ; ISO e ISO ; Waterfall Model ; V-Model ; RUP ; Method Composer ; TSP, PSP e P-CMM ; Agile Manifesto Agile Methods Extreme Programming, Scrum, Kanban e OpenUP ; Best practices agile e Agile maturity levels ; Chaos Report ; Agile Scale e Escala ágil ; Agile proposals, CMU Agile e PMI Agile. 6

23 2.1.2 Seleção dos Artigos A seleção de artigos foi elaborada através do título destes, pois muitas das vezes o título fornecia informação clara quanto ao seu conteúdo, outros foram escolhidos através de palavras-chave destacadas que apareciam no excerto de texto por baixo do hyperlink quando é efetuada a pesquisa. Outra forma foi ler o resumo do artigo, ou fazer uma leitura cruzada e perceber se este era realmente relevante e passível de ser estudado com maior atenção através da compreensão do conteúdo do mesmo. Além disto, foram selecionados artigos que por vezes nem ao ler o resumo nem a introdução, davam a perceber se este continha alguma informação sobre o assunto desejado, por isso era preciso mais um bocado de esforço de leitura para se conseguir perceber se o artigo poderia servir o objetivo da solução ou não. Foram selecionados artigos que: Abordassem e definissem metodologias tradicionais e/ou ágeis; Abordassem as melhores práticas de determinada metodologia; Abordassem níveis de maturidade, tanto para metodologias ágeis como tradicionais; Abordassem o tema da engenharia de software; Definissem o que se entende por SI e TI; Abordassem o estudo de práticas comuns a vários métodos, principalmente se um deles incluísse níveis de maturidade na sua abordagem. Apesar de selecionados, alguns não foram referidos nesta revisão de literatura, mas vão servir de arranque para a próxima fase desta dissertação Extração dos Dados e Síntese Este tópico tem o objetivo de apresentar uma matriz de conceitos elaborada para se conseguir uma melhor compreensão das afirmações e escolhas para cada tópico deste trabalho, nesta são identificados os artigos abordados e faz-se o cruzamento com os conceitos que se relacionam. Posto isto, documento ainda não vai conter esta matriz, a estrutura desta já foi pensada, mas vai ser apenas inserida no documento final da dissertação, quando as referências tiverem todas acertadas. Apesar disto, os conceitos com que as referências irão cruzar podem ficar já aqui enumerados e, são os seguintes: Sistemas de Informação, Tecnologias de Informação, Modelos de Processo, Modelos de Maturidade e Abordagens ágeis. 7

24 2.2 Tecnologias de Informação e Sistemas de Informação Tecnologias de Informação (TI) e Sistemas de Informação (SI), são termos bastantes comuns no dia a dia das pessoas pertencentes a este universo, apesar disto, não existe um consenso universal para estes conceitos e vários autores influentes na área apresentam as suas próprias descrições do que serão então os Sistemas de Informação, como por exemplo Alter (1992) e Buckingham (1987) (Amaral, 1994; Carvalho, 2000; Laribee, 1991). Um SI é uma entidade que recolhe, guarda, processa e dissemina informação relevante para uma organização, com o objetivo de a tornar útil e acessível para quem a deseja e possa utilizar (Buckingham et al. 1987; Varajão, 2002) Outra definição de Sistemas de informação, disponibilizada por Oliveira e Amaral (1999), é que estes estes são vistos como a junção da gestão de recursos humanos e materiais que executam atividades para adquirir, armazenar, processar e difundir informação, que podem ter ou não o envolvimento de computadores. Uma outra possível descrição de SI é feita por Renkema e Berghout (1997) e referem que um SI pode ser descrito como a integração de todos os componentes que fornecem informação necessária, sendo eles: as pessoas, os procedimentos, o software, o hardware e os dados processados pelo sistema. Os Sistemas de Informação são suportados pelas Tecnologias de Informação. Para definir a maneira como as Tecnologias de Informação suportam os Sistemas de Informação, Amaral (1994) propõe a atividade de Planeamento de Sistemas de Informação (PSI) e, os resultados desta atividade com foco nas TI são: a identificação das grandes opções tecnológicas (configurações, equipamentos, suportes lógicos, suportes metodológicos, ). Amaral (1994) defende que segundo McNurlin e Sprague Jr. (1989), o SI deve assumir como missão própria a melhoria do desempenho das pessoas no que diz respeito aos processos da organização, através da utilização da informação e das TI. Alter (1992), numa perspetiva tecnológica, dá a entender que as TI são o conjunto de equipamentos e suportes lógicos (hardware e software), que permitem executar tarefas de aquisição, transmissão, armazenamento, recuperação e exposição de dados (Alter, 1992; Amaral, 1994). Hoje, a importância das TI e dos SI nas organizações, é uma realidade bem conhecida (Earl, 1989; Eason 1988; Amaral, 1994). Sá Soares (1998) vai ao encontro disto ao referir que a aposta nos SI e a adoção de TI por parte das organizações contribui para que se consigam superar os desafios mais atuais. A escala de agilidade é direcionada às equipas de projetos TI e como tal importa ter a noção do conceito de projeto. Segundo o PMI (2013), um projeto representa um esforço temporário, com datas de início e fim bem definidas, assim como os recursos presentes (humanos, materiais, monetários, ) 8

25 para utilização e, através de um conjunto de operações específicas, criar um novo produto, serviço ou resultado. O PMI propõe ainda as seguintes fases para o ciclo de vida de um projeto: Iniciação, Planeamento, Execução e Conclusão. Segundo Fernandes e Abreu (2014), nas últimas décadas têm surgido uma série de referenciais que abordam as melhores práticas de TI. Segundo Mahmood (2006) os referências que se aplicam nos projetos, neste caso de TI, fornecem um conjunto de boas práticas, normas, modelos de maturidade, que auxiliam o desenvolvimento do projeto. Alguns destes referenciais são: o CMMI-DEV, P-CMM, RUP, SCRUM, entre outros, que no âmbito deste projeto vão servir de base para o estudo e desenvolvimento deste projeto, pois será necessário conhecimento de um leque alargado de referenciais e investigação de casos de empresas que apliquem abordagens ágeis para conseguir criar um método ou agrupar as melhores práticas por níveis de maturidade, com a finalidade de medir a agilidade das equipas de projetos TI. 2.3 Métodos Tradicionais Engenharia de Software SWEBOK O SWEBOK é um guia que apresenta um corpo de conhecimento que tenta definir uma profissão, neste caso a de engenharia de software e defende que todas as profissões são baseadas num corpo de conhecimento, apesar de algumas não o terem definido de maneira concisa (IEEE,2014). A última versão do SWEBok (v3.0) apresenta 15 áreas de conhecimento para a prática da engenharia de software, sendo elas: Software Requirements, Software Design, Software Construction, Software Testing, Software Maintenance, Software Configuration Management, Software Engineering Management, Software Engineering Process, Software Quality, Software Engineering Models and Methods, Software Engineering Professional Practice, Software Engineering Economics, Computing Foundations, Mathematical Foundations e Engineering Foundations (IEEE, 2014). Numa primeira visão sobre estas áreas e após uma breve compreensão de cada uma, importa rever a área Software Engineering Process com maior atenção. Um processo é um conjunto de atividades relacionadas entre si que transformam um ou mais inputs em outputs, através do consumo de recursos. Mais detalhadamente, um processo, designa uma sequência de atividades, geralmente agrupadas em fases, que são executadas de forma sistemática e uniformizada por intervenientes com 9

26 responsabilidades bem definidas e que, a partir de um conjunto de inputs, produzem um conjunto de outputs, através do consumo de recursos (Pressman, 2009). Esta área de conhecimento preocupa-se com as atividades relacionadas com o desenvolvimento, manutenção e operação de software feitas pelos engenheiros de software. Um processo de software possibilita facilitar a compreensão, comunicação e coordenação humana. Esta área de conhecimento embaraça a definição de processo de software, o ciclo de vida do software, a avaliação e melhoria do(s) processo(s) de software, a medição do softwar e ferramentas de processo da engenharia de software, como se pode ver na figura que se segue (Fairley, Bourque, & Keppler, 2014). Figura 1- Tópicos para a área de conhecimento Engineering Process (retirado de (IEEE, 2014)) Segundo o Swebok v3.0 (2014), o tópico Software Process Definition embaraça a definição de processo de software, a gestão de processos de software e a infraestrutura dos processos de software. Os modelos de ciclos de vida (BKCASE, 2017) de software servem de definição das fases que ocorrem durante o desenvolvimento de software, definir as suas atividades e combiná-las com o processo de software, para que sejam devidamente detalhadas e ordenadas. A avaliação dos processos de software é geralmente feita através da utilização de modelos e de métodos, como o ITIL e o CMMI são exemplos de modelos enquanto que os métodos fornecem informação quantitativa que caracteriza o nível de 10

27 capacidade do processo. A medição dos processos e do software deve ser feita com recurso às forças e fraquezas ou mesmo pelo impacto que produz no resultado final, antes do processo corrente ser modificado ou ser implementado um novo. As ferramentas de processo da engenharia de software são utilizadas para auxiliarem as atividades da engenharia de software e suportam muitas notações para definir, implementar e gerir processos de software e ciclos de vida. Estas ferramentas podem também ser baseadas em computador, Computer-Assisted Software Engineering (CASE), que reforçamo uso de processos integrados, suportam a execução da definição dos processos e disponibilizam guias para o ser humano desenvolver processos bem definidos. O SWEBOK tenta com estas áreas identificar o que constitui o núcleo da engenharia de software, mas defende que para além disto, os engenheiros de software devem ainda ter conhecimento noutras áreas, que por exemplo podem ser definidas ou sob a responsabilidade da organização ou iniciativa em que estão envolvidos. Quatro Atividades Fundamentais da Engenharia de Software Sommerville (2015a), enuncia que existem muitos processos de software diferentes, mas todos devem incluir as quatro seguintes atividades fundamentais à engenharia de software: Software Specification- é a atividade onde os clientes e os engenheiros de software definem o software a ser implementado, assim como os seus requisitos e restrições na sua operação; Software Design and Implementation- é uma atividade também chamada de Software Development e é onde se faz o design do software e a sua programação; Software Validation- é a atividade onde o software é testado e avaliado para assegurar que é o que o cliente quer; Software Evolution- é a atividade onde o software é modificado e reflete os requisitos das mudanças do cliente e do mercado. ISO A ISO/IEC (2008) é uma norma internacional sobre a engenharia de software que define os processos de engenharia de software, atividades e tarefas associadas com o ciclo de vida dos processos de software desde a sua conceção até à sua retirada. O objetivo desta norma é ser a norma que define todas as tarefas necessárias para o desenvolvimento e manutenção de software. Em acréscimo, as atividades que esta norma apresenta, são transversais a todos os modelos de processo. 11

28 Estabelece que cada processo tem um conjunto de resultados associados e engloba 23 processos, 95 atividades, 325 tarefas e 224 resultados. O conjunto de processos, atividades e tarefas pode ser adaptado de acordo com o projeto. A ISO classifica os processos em três tipos: básico, de suporte e organizacional. Os processos organizacionais e de suporte devem existir independentemente da organização e do projeto que esta a ser executado. Já os processos básicos, devem ser instanciados de acordo com a situação. Após este estudo e recolha de informação sobre a profissão de engenharia de sofware, das tarefas transversais a todos os modelos de processo (ISO/IEC/IEEE, 2008). Existem outros métodos tradicionais que suportam o desenvolvimento de software que importam ter em atenção relevante para a elaboração de uma possível primeira iteração do objetivo desta dissertação. No âmbito desta recolha do estado da arte (da parte tradicional) irão ser estudados, nas secções seguintes, os modelos de processo tradicionais como o modelo Waterfall, o V-model e o RUP. Após isto pretende-se que seja recolhida informação sobre os modelos de maturidade como o CMMI e o P-CMM, passando por estudar também o TSP e o PSP, que é a origem do PCMM Modelos de Processo Waterfall Bell e Thayer (1976), no seu paper, explicam que Royce (1970) introduziu o conceito de waterfall para atividades de desenvolvimento. As fases do modelo original de Royce (1970) estão representadas na figura 2. Nesta abordagem, o desenvolvimento de software é feito de uma maneira sequencial, como demostra a figura atrás referida. Assim, o modelo Waterfall aborda e propõe uma sequência temporal do trabalho (Pressman, 2009), ou seja, é um modelo de desenvolvimento sequencial, onde o desenvolvimento do projeto pressupõe que cada passo é cuidadosamente executado na perfeição e não se volta atrás. Por isso, é visto como uma cascata que segue constantemente para baixo através das fases: Requirements Analysis (do sistema e do software), Design (conceção do programa), Implementation (codificação), Verification (testes), Maintenance, como é demonstrado na figura que se segue (Balaji,2012). 12

29 Figura 2- Passos para o desenvolvimento de um programa (retirado de Royce (1970)) Neste modelo, os outputs de cada uma das fases anteriores serve de input para a fase seguinte e a passagem de uma fase para a seguinte faz-se de forma sequencial. Por exemplo, neste caso, só quando a análise de requisitos estiver concluída, ou seja, quando todos os requisitos tiverem sido cumpridos, revistos e aprovados, é que a equipa de TI pode prosseguir para a fase de design, não é possível avançar para a fase seguinte se a anterior não estiver devidamente concluída e como tal, não pode haver sobreposição de fases (Balaji, 2012). Os defeitos são encontrados muito tarde no ciclo de vida do desenvolvimento do software, porque a equipa de testes não é envolvida desde o início do projeto, é apenas envolvida na fase de testes, retardando assim a altura em que os defeitos e falhas são encontradas (Balaji, 2012). Apesar disto, para a utilização deste modelo, os requisitos fornecidos pelo cliente devem ser claros e bem definidos antes de começar a fase seguinte do ciclo de vida, pois no modelo Waterfall, por exemplo, a fase de requisitos deve ficar congelada antes de se poder começar a fase seguinte (design), Consequentemente, futuras mudanças de requisitos não podem ser consideradas. 13

30 V-Model O V-Model é uma versão modificada do modelo em cascata (Waterfall) e, na sua estrutura, para além do eixo linear semelhante ao do Waterfall, tem um eixo que volta para cima depois da fase de desenvolvimento de código (Balaji, 2012). É um modelo que depende da verificação das fases anteriores antes de poder prosseguir, ou seja, o produto de cada uma das fases precisa de ser verificado e aprovado antes de se poder avançar para a fase seguinte. A figura 3 ilustra esta situação. Figura 3- Diagrama representativo do V-Model (retirado de Neste modelo, se o cliente precisar de mudar algum requisito é possível fazer a atualização dos respetivos requisitos, mas toda a documentação previamente preparada das fases de requisitos e das subsequentes têm de ser atualizados (Balaji, 2012). Rational Unified Process O Rational Unified Process (RUP) é um processo de engenharia de softwar e fornece uma abordagem que permite atribuir tarefas e responsabilidades dentro de uma organização de desenvolvimento, com o objetivo de assegurar a produção de software de alta qualidade que vai de encontro às necessidades dos utilizadores dentro de prazos e orçamentos estipulados (Kruchten,2003; ANWAR, 2014). 14

31 Este processo melhora a produtividade das equipas através do fornecimento de um fácil acesso a uma base de conhecimento com várias orientações (guidelines), templates (modelos) e ferramentas para atividades de desenvolvimento. Além disto, descreve as seis melhores práticas no desenvolvimento de software, que se comprovam serem melhores práticas porque são comummente utilizadas na indústria por organizações bem sucedidas (Rational Software White Paper, 2004) sendo elas: Develop Software Iteratively, Manage Requirements, Use Component-based Architectures, Visually model software, Verify software quality, Control Changes to Software. A descrição de cada uma destas práticas é feita segundo Sommerville (2013): Develop Software Iteratively- devem ser planeados incrementos do sistema baseados nas prioridades do cliente e desenvolver as funcionalidades com maior prioridade no processo de desenvolvimento; Manage Requirements- os requisitos do cliente devem estar devidamente explícitos e deve-se seguir as mudanças que possam ser feitas a esses requisitos e o impacto que estas podem causar ao sistema antes de as aceitar; Use Component-based Architectures- estruturar a arquitetura do sistema em componentes Visually model software- Usar gráficos de modelos UML para representar vistas estáticas e dinâmicas do software; Verify software quality- Assegurar que o software vai de encontro às normas de qualidade da organização; Control Changes to Software- Gerir as mudanças do software utilizando sistemas de gestão de mudança, procedimentos de gestão de manutenção e ferramentas. A figura 4 representa as fases constituintes da abordagem do RUP, que são a Inception, Elaboration, Construction, Transition. De seguida apresenta-se uma breve descrição destas fases segundo Anwar (2014): Inception- prepara o lançamento do projeto. O projeto tem de ser validado para poder ser aplicado um orçamento. Normalmente é produzido um business case, com todos os detalhes necessários ao lançamento; Elaboration- esta fase foca em perceber os maiores riscos técnicos do projeto. Nesta fase elabora-se um sistema básico (a arquitetura do sistema) que poderá responder à maioria das questões técnicas; 15

32 Construction- tem o foco em desenvolver um sistema operacional através da utilização da arquitetura criada na fase anterior. O foco maior é no desenvolvimento de componentes e funcionalidades; Transition- foca na transição do sistema do estado de desenvolvimento para o estado de produção. O sistema deve cumprir os requisitos e preencher as necessidades dos utilizadores. Figura 4-Framework do RUP (retirado de Modelos de Maturidade Segundo Sommerville (2015a) De hoje em dia, existe cada vez uma demanda maior por parte da indústria de software melhor e mais barato, que tem de ser entregue em tempos cada vez menores. A noção de maturidade do processo foi introduzida no final da década de 80 quando o Software Engineering Institute (SEI) propôs o seu modelo de capacidade e maturidade dos processos. Após a análise dos modelos de processo tradicionais da secção anterior, importa analisar modelos de maturidade, pois estão diretamente relacionados com o tema desta dissertação. Neste caso como já referido acima, vai ser retirado o essencial dos seguintes modelos de maturidade: CMMI e P-CMM. Para além destes também se espera uma recolha de informação sobre o TSP e o PSP, pois são modelos que ajudam a atingir certos níveis de maturidade. Espera-se que com as seguintes secções fiquem claros os aspetos mais importantes e que possam ser relevantes para o objetivo desta dissertação. 16

33 CMMI Nos métodos tradicionais, um dos grandes referenciais é o CMMI. O CMMI é uma representação simplificada do mundo e incorpora as melhores práticas para organizações de desenvolvimento de produtos e serviços. Desta maneira as melhores práticas presentes no modelo CMMI focam nas atividades para o desenvolvimento de produtos e serviços de qualidade que vão de encontro às necessidades dos clientes e utilizadores finais. Este documento está organizado em três partes principais. A primeira fornece informação genérica sobre o modelo, a segunda contém os objetivos e práticas genéricas e as áreas de processo que o utilizador do modelo deve ter atenção, a terceira inclui apêndices e o glossário necessário à compreensão do modelo (SEI, 2010). As organizações, cada vez mais precisam de entregar os seus produtos e serviços que são gradualmente mais complexos de uma maneira melhor, mais rápida e de menor custo (SEI,2010; Sommerville, 2015a). Como de hoje em dia, as organizações para desenvolverem um produto ou serviço complexo não desenvolvem todos os componentes dentro da empresa, é comum que alguns sejam adquiridos e finalmente integrados com os construídos dentro da empresa, ou não, para obter o produto ou serviço final. Assim sendo, as organizações necessitam de conseguir gerir e controlar todo este desenvolvimento complexo e processo de manutenção. Para as organizações conseguirem melhorar a maneira de fazerem os seus negócios existem no mercado, modelos de maturidade, normas, metodologias e guias. Contudo, muitas das abordagens focam em partes específicas do negócio e não tomam uma abordagem sistémica aos problemas que muitas organizações enfrentam. O CMMI pode ser visto como uma coleção das melhores práticas relacionadas com a melhoria dos processos nas organizações (SEI, 2010) e tem o objetivo fundametal que é avaliar a maturidade dos processos da organização (Fernandes e Abreu, 2014; Jalote, 2002). A framework presente no CMMI, é usada para gerar vários modelos e materiais de treino e avaliação. Os modelos são categorizados por representações e pelos tipos de processos O CMMI apresenta dois tipos de implementação que as organizações que aplicam este modelo fazem: implementação por etapas (muitas vezes chamada de faseada) ou implementação contínua. Para este trabalho, importa focar na implementação por etapas por ser o tipo de implementação que divide as vinte e duas áreas de processo presentes no CMMI em níveis de maturidade. Existem 5 níveis de maturidade diferentes na implementação por etapas do CMMI e para alcançar estes níveis, cada um tem um determinado conjunto de áreas de processo que devem ser 17

34 atingidas. Cada um destes níveis vai ser descrito conforme a literatura de SEI (2010) e (Sommerville,2015a). O nível 1 é o nível inicial (denominado de Initial) e qualquer organização possui este nível 1 de maturidade, é um nível que refere a processos imprevisíveis, controlados de forma pobre e pouco reativos (ou seja, não são proativos). O nível 2 de maturidade tem a designação de Managed, neste nível, os processos estão caracterizados para projetos, tomam alguns inputs e geram alguns outputs, mas continuam a não ser proativos, são reativos, quando algumas circunstâncias ocorrem, têm algumas soluções e respondem de acordo. Cada projeto tem um conjunto de padrões, que estão implementados apenas ao nível do projeto e as organizações que se encontram neste nível limitam-se a seguir estes padrões em todos os projetos. No nível 3 a designação para este nível de maturidade é Defined, todos os padrões que certo projeto segue, é ao nível da organização e os processos estão descritos para a organização e deixam de ser reativos e passam a ser proativos. O nível 4, Quantitatively Managed, fala sobre números, sobre dados e estatísticas. Por exemplo, a empresa tem de ter um certo lucro ou uma certa receita e por isso os seus processos são geridos e controlados quantitativamente. Finalmente, ao chegar ao nível 5, denominado de Optimizing. aqui os números que se trataram no nível 4 precisam de ser otimizados, ou seja focar nos resultados e nos dados utilizados no nível 4 e de alguma maneira otimizá-los e por isso as organizações que se encontram neste nível, focam na melhoria continua dos processos (SEI, 2010; Sommerville,2015a). A Tabela 2, agrupa as 22 áreas processos presentes no CMMI pelos respetivos níveis de maturidade. Nome da área de processo processo Nível de Tipo Abreviação maturidade Configuration Management Suporte CM 2 Measurement and Analysis Suporte MA 2 Project Monitoring and Control Gestão de projetos PMC 2 Project Planning Gestão de projetos PP 2 Process and Product Quality Assurance Suporte PPQA 2 Requirements Management Gestão de projeto REQM 2 Supplier Agreement Management Gestão de Projeto SAM 2 18

35 Decision Analysis and Resolution Suporte DAR 3 Integrated Project Management Gestão de projeto IPM 3 Organizational Process Definition Gestão de processo OPD 3 Organizational Process Focus Gestão de processo OPF 3 Organizational Training Gestão de processo OT 3 Product Integration Engenharia PI 3 Requirements Development Engenharia RD 3 Risk Management Gestão de projeto RSKM 3 Technical Solution Engenharia TS 3 Validation Engenharia VAL 3 Verification Engenharia VER 3 Organizational Process Performance Gestão de processo OPP 4 Quantitative Project Management Gestão de projeto QPM 4 Causal Analysis and Resolution Suporte CAR 5 Organizational Performance Management Gestão de processo OPM 5 Tabela 1- Organização dos Processos por Níveis de Maturidade (adaptado de SEI (2010)) Utilizando este modelo de Maturidade, para se progredir de nível de maturidade, ou seja, para passar ao nível seguinte, a organização deve ter incorporados todos os processos do nível de maturidade anterior (SEI,2010). Em seguida será resumida, brevemente, cada uma das 22 áreas de processo, para posteriormente, na fase de dissertação (pós projeto de dissertação) ser possível fazer mentalmente comparações com outros modelos ou outras práticas caso seja necessário, para se perceber as bases dos níveis de maturidade tradicionais propostos. E, se possível, através de relacionamentos e/ou práticas parecidas começar a elaborar o escalonamento proposto pelo tema desta dissertação. De acordo com o CMMI-DEV 1.3 (SEI, 2010) as áreas de processo são as seguintes: CAUSAL ANALYSIS AND RESOLUTION (CAR)- Esta área de processo serve para identificar as causas de resultados selecionados e planear medidas corretivas e preventivas para melhorar o desempenho dos processos. Desta maneira é possível melhora a qualidade e produtividade da organização. CONFIGURATION MANAGEMENT (CM)- A CM ajuda a estabelecer e a manter a integridade dos artefactos, através da utilização configuration identification, configuration control, configuration status accounting, and configuration audits. 19

36 Decision Analysis and Resolution (DAR) - Ajuda a escolher a melhor alternativa através análise de decisões possíveis e da utilização de um processo de avaliação formal que avalie as alternativas indentificadas em contraste com as estabelecidas. INTEGRATED PROJECT MANAGEMENT (IPM)- Esta área de processo ajuda a estabelecer, gerir o projeto e o envolvimento de stakeholders relevantes e leva a criação de um processo padrão para o desenvolvimento de processos do projeto definidos. MEASUREMENT AND ANALYSIS (MA)- Esta área tem o propósito de desenvolver e sustentar a capacidade de fazer medições em projetos ao nível da organização. Isto pode ser usado para ajudar na tomada de decisão por parte da gestão de topo. ORGANIZATION PROCESS DEFINITION (OPD)- Esta área de processo de estabelecer e fazer a manutenção gradual necessária de um conjunto de processos ativos na organização, de padrões de ambiente de trabalho, regras e orientações para equipas. ORGANIZATION PROCESS FOCUS (OPF)- Esta área ajuda no planeamento, implementação e implantação de melhorias de processos organizacionais. Tem como base a compreensão dos pontos fortes e fracos atuais dos processos da organização. ORGANIZATIONAL PERFORMANCE MANAGEMENT (OPM)- Tal como o nome sugere, esta área foca na gestão proativa do desempenho da organização na medida em que vai de encontro aos objetivos do negócio. ORGANIZATIONAL PROCESS PERFORMANCE (OPP)- Esta área fornece ajuda às atividades de melhoria de processos, na medida em que se estabelece e mantem uma compreensão quantitativa do desempenho de um conjunto de processos padrão da organização que dão o suporte necessário para alcançar objetivos de qualidade e de desempenho de processos, fornecer dados sobre o desempenho de processos e modelos que possibilitem a gestão quantitativa dos projetos da organização. ORGANIZATIONAL TRAINING (OT)- O propósito desta área está associado ao desenvolvimento dos skills e conhecimento das pessoas da organização para poderem desempenhar as suas tarefas de maneira eficaz e eficiente. PRODUCT INTEGRATION (PI)- Esta área de processo tem a função de conseguir reunir os componentes do produto no produto final e, ainda, garantir que o produto depois da integração se comporta como esperado e a sua entrega. PROJECT MONITORING AND CONTROL (PMC)- Esta área de processo serve para se garantir um conhecimento do progresso do projeto e consequentemente ser possível a 20

37 aplicação de medidas corretivas adequadas caso o desempenho do projeto se desvie significativamente do plano. PROJECT PLANNING (PP)- O propósito desta área de processo é estabelecer e fazer a manutenção gradual dos planos que definem as atividades do projeto. Para isto, esta área deve consistir nas melhores práticas de planeamento de projeto para ajudar a concretizar um planeamento de projeto eficaz. Fazem parte desta área itens como estimações, o preparação do plano de projeto que inclui o planeamento dos recursos, a calendarização, o plano de riscos e contingências, etc PROCESS AND PRODUCT QUALITY ASSURANCE (PPQA)- Esta área suporta a gestão da qualidade dos processos e produtos através da utilização de atividades de garantia de qualidade. Desta maneira, promove-se a entrega de produtos de alta qualidade, pois todos o staff e gestores do projeto têm feedback e uma vista apropriada, a todos os níveis, dos processos e produtos a serem desenvolvidos durante o tempo de vida do projeto. QUANTITATIVE PROJECT MANAGEMENT (QPM)- A área QPM tem o propósito de gerir e controlar quantitativamente o projeto de forma a alcançar os objetivos de desempenho de processos e qualidade estabelecida. REQUIREMENTS DEVELOPMENT (RD)- O propósito desta área de processo é fazer a coleta de requisitos, analisá-los e depois detalhá-los em diferentes tipos de requisitos, tais como: requisitos do utilizador, do cliente, do produto e das componentes do produto. REQUIREMENTS MANAGEMENT (REQM)- Esta área ajuda na gestão dos requisitos dos produtos do projeto e das componentes do projeto. E, assegura que estes requisitos estejam alinhados com o trabalho que é desenvolvido nos artefactos do projeto e com os planos de projeto. RISK MANAGEMENT (RSKM)- O propósito desta área é identificar possíveis problemas antes que ocorram para que se possam planear atividades de tratamento de risco (medidas atenuantes/corretivas/de prevenção/planear a sua mitigação) e executá-las conforme necessário durante toda a vida do projeto ou produto para mitigar impactos adversos à concretização dos objetivos. SUPPLIER AGREEMENT MANAGEMENT (SAM)- A presente área ajuda na gestão da aquisição de produtos e serviços de fornecedores. 21

38 TECHNICAL SOLUTION (TS)- O propósito desta área é ajudar na seleção, projeção e implementação de soluções para os requisitos do projeto. VALIDATION (VAL)- Esta área de processo tem o propósito de demonstrar que o produto ou componente do produto funciona como desejado quando alocada no ambiente pretendido. VERIFICATION (VER)- O propósito desta área é assegurar que certos artefactos selecionados vão de encontro aos seus requisitos específicos, verificando-os. Personal Software Process (PSP) Todos os desenvolvedores de software utilizam algum processo para o contruir. O Personal Software Process enfatiza a medição pessoal de ambos o trabalho dos artefactos do produto a ser realizado e a qualidade que resulta deste produto de trabalho. Este modelo define 5 atividades que cada pessoa deve ter presente, de modo a torna-la ciente e responsável quanto ao plano de projeto e dar-lhe a habilidade de controlar a qualidade de todos os produtos de trabalho de software que são desenvolvidos (Pressman, 2009). O modelo PSP define cinco atividades, que são as seguintes: Planning, High-level design, High-level design review, Development, Postmortem e, vão ser descritas brevemente segundo Pressman (2009): Planning- Esta atividade define os requisitos. Todas as métricas são redigidas e guardadas. Após isto, as atividade de desenvolvimento são identificadas e o calendário do projeto é criado. High-level design- Especificações para cada componente a ser desenvolvida e é criado o design do componente. São construídos protótipos quando existe incerteza. Todos os problemas são seguidos e escritos em relatórios de forma a gravar os acontecimentos. High-level design review- Verificação formal dos métodos para possibilitar descobrir erros no design. Development- O design ao nível da componente é refinado e revisto. É gerado código, revisto, compilado e tewstado. Postmortem- A eficácia do projeto é determinada através do uso das medidas e métricas coletadas, que devem fornecer guias para a modificação do processo tendo em vista a melhoria da eficácia. 22

39 Quando o PSP é devidamente introduzido aos engenheiros de software (Humphrey, 1997), resulta numa melhoria da produtividade e qualidade na execução das tarefas e trabalhos relacionados com a engenharia de software (Ferguson, 1997). Team Software Process (TSP) Muitos projetos de software são tidos por uma equipa de praticantes da profissão de engenharia de software, por isto, Watts Humphrey extendeu o que se pôde aprender com a introdução do PSP e propôs um Team Software Process (TSP). O objetivo do TSP é construir equipas de projeto que se auto direcionam e se organizam de maneira a produzir software de alta qualidade (Humphrey, 2000). Segundo Pressman (2009), uma equipa que se auto direciona compreende os objetivos e metas globais, define papeis e responsabilidades para cada elemento da equipa, rastreia quantitativamente dados do projeto, sobre a produtividade e qualidade, identifica um processo de equipa que é apropriado para o projeto e a estratégia para a implementação do projeto, define normas aplicáveis ao trabalho da equipa de engenharia de software, avalia continuamente o risco e reage conforme, segue, gere e reports (cria relatórios) do estado do projeto. As atividades que o modelo TSP define são as seguintes: project launch, high-level desing, implementation, integration and test e postmortem. Estas atividades possibilitam que a equipa planeie, faça o design e costrua o software de uma maneira disciplinada e ao mesmo tempo meça quantitativamente o processo e o produto. A atividade postmortem serve para preparar uma etapa que visa a melhoria de processos. O TSP reconhece que as melhores equipas de software são auto-direcionadas. Os seus membros definem objetivos para o projeto, adaptam o processo conforme as necessidades, controlam a calendarização do projeto e através da medição e análise de métricas coletadas, trabalham continuamente para melhorar a abordagem da equipa à engenharia de software (Pressman, 2009). People Capability Maturity Model (P-CMM) O People Capability Maturity Model (P-CMM) fornece um mapeamento para a transformação da organização através da melhoria das práticas dos seus trabalhadores. Assim como o CMMI, o P-CM também consiste em cinco níveis de maturidade, perante os quais as práticas dos trabalhadores da organização evoluem (Curtis, Hefley, & Miller, 2009) e a imagem ilustra esta situação. 23

40 Figura 5- Os 5 níveiws de maturidade do P-CMM (Retirado de (Curtis, et al., 2009)) O P-CMM teve o PSP na sua origem e o SEI, desenvolveu o P-CMM pelo facto do fator das pessoas ser deveras importante, ao mesmo tempo que reconhece que toda a organização precisa de melhorar continuamente a sua habilidade de atrair, desenvolver, motivar, organizar e reter a sua força de trabalho necessária para cumprir os objetivos estratégicos do negócio (Curtis, et al., 2009; Pressman, 2009). Esta ferramenta reforça a necessidade de reconhecer a importância das pessoas como indivíduos e de desenvolver as suas capacidades. O P-CM pode levar a melhorias significantes na capacidade das organizações produzirem software de alta qualidade (Sommerville, 2015b). Os objetivos estratégicos do P-CMM (Sommerville, 2015b) são: Melhorar a capacidade das organizações que desenvolvem software, através do aumento da sua força de trabalho; Assegurar que a capacidade de desenvolvimento é um atributo da organização e não de apenas alguns indivíduos; Alinhar a motivação dos indivíduos com a da organização; Reter pessoas que sejam valiosas (que tenham conhecimento crítico e habilidades) na organização. ISO A revisão desta norma vai ser feita através dos artigos de Pino, Baldassarre, Piattini, & Visaggio (2009), Maheshkumar & Sukhbaatar, 2010 e, do livro de Loon(2007) que incluem várias informações sobre a ISO/IEC e permite chegar às conclusões apresentadas nos próximos parágrafos. 24

41 A norma ISO/IEC 15504, também conhecida como SPICE, é uma framework para a avaliação de processos. Com isto, é possível fazer uma revisão dos processos de software da organização, pois é feita de maneira disciplinada uma análise dos processos de uma organização tendo em conta um conjunto de critérios para se determinar a capacidade destes processos cumprirem com os objetivos de qualidade, custo e calendarização. Assim, é de grande ajuda às melhorias da organização, já que permite encontrar problemas críticos e estabelecer prioridades nas melhorias, isto leva à elaboração de um plano de melhoria. Refere-se ainda que para se começar a fazer melhorias, é necessário saber o estado atual dos processos de software da organização, os objetivos futuros e ainda se os objetivos foram atingidos quando as atividades do plano de melhoria acabam. A framework de avaliação SPICE, contém duas dimensões, a dimensão do Processo e a dimensão da capacidade. Assim, cada processo recebe um certo nível de capacidade. A escala de medida da capacidade do processo é definida desde o nível Incomplete Process, que é o nível que representa menos capacidade e significa que o seu desempenho não é capaz de preencher todos os objetivos, até ao nível Optimising Process, que por sua vez é o nível com mais capacidade e significa que o seu desempenho é capaz de ir ao encontro dos objetivos e também sustentar a melhoria contínua do processo. Os níveis intermédios são: Performed, Managed, Established, Predictable. 2.4 Abordagens Ágeis Esta secção serve para recolher informação do estado da arte sobre métodos ágeis, pois são os que estão diretamente relacionados com o tema desta dissertação. Apesar disto, os métodos tradicionais não podem ser negligenciados, pois ambos poderão ser necessários para o desenvolvimento da escala de maturidade ágil. Correntemente não existe nenhuma maneira formulada de medir a maturidade ágil de equipas TI. Portanto, é importante perceber os conceitos através do estado da arte relacionada com o tema para na fase de dissertação ser possível tentar avançar com uma primeira iteração de uma possível escala de maturidade ágil. Apesar de todos os métodos tradicionais descritos acima, existe muita burocracia e sobrecarga por parte destes métodos formais de melhoria de processos para pequenas empresas (Sommerville, 2015a). 25

42 Na década de 90 e mesmo antes já se falava de métodos leves que evoluíram através da reação aos métodos mais pesados ou tradicionais, que foi quando várias metodologias até à data chamadas leves começaram a aparecer, como por exemplo o Scrum, o Extreme Programming, o Crytal Clear, entre outros. Só a partir do Manifesto Ágil é que métodos como os enumerados começaram a utilizar o termo ágil para serem referidos Manifesto Ágil A filosofia por trás dos métodos ágeis foi refletida no manifesto ágil em Fevereiro de 2001 e assinado por todos os 17 participantes, que se nomearam de The Agile Alliance, os quais são intervenientes e representantes de com métodos de desenvolvimento ágil (como é o exemplo de representantes dos métodos XP, SCRUM, DSDM (Dynamic Systems Development Method), Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming) e também simpatizantes com a necessidade da existência de uma alternativa para métodos mais pesados como os tradicionais (Kent et al., 2001). Desta reunião emergiu então o Manifesto for Agile Software Development (Manifesto para o Desenvolvimento Ágil de Software), assinado por todos os participantes como referido acima, que também por serem representantes de diferentes métodos, por vezes competem entre si. Todos em acordo, como The Agile Alliance, criada na reunião, definiram um conjunto de valores e princípios do desenvolvimento ágil de software. Então, o Manifesto for Agile Software Development, cita: Ao desenvolver e ao ajudar outros a desenvolver software, temos vindo a descobrir melhores formas de o fazer. Através deste processo começámos a valorizar: Indivíduos e interações mais do que processos e ferramentas; Software funcional mais do que documentação compreensiva; Colaboração com o cliente mais do que negociações contratuais; Responder à mudança mais do que seguir um plano. Ou seja, apesar de reconhecermos valor nos itens à direita, valorizamos mais os itens à esquerda (Kent, et al., 2001). Para além destes quatro valores, constataram-se ainda doze princípios que estão por trás do Manifesto Agil (Kent et al., 2001) e, que por exemplo autores como Pressman (2009) e Cockburn (2002) incluem-nos nos seus livros, sendo eles: 26

43 A nossa maior prioridade é, desde as primeiras etapas do projeto, satisfazer o cliente através da entrega rápida e contínua de software com valor. Aceitar alterações de requisitos, mesmo numa fase tardia do ciclo de desenvolvimento. Os processos ágeis potenciam a mudança em benefício da vantagem competitiva do cliente. Fornecer frequentemente software funcional. Os períodos de entrega devem ser de poucas semanas a poucos meses, dando preferência a períodos mais curtos. O cliente e a equipa de desenvolvimento devem trabalhar juntos, diariamente, durante o decorrer do projeto. Desenvolver projetos com base em indivíduos motivados, dando-lhes o ambiente e o apoio que necessitam, confiando que irão cumprir os objetivos. O método mais eficiente e eficaz de passar informação para dentro e dentro de uma equipa de desenvolvimento é através de conversa pessoal e direta. A principal medida de progresso é a entrega de software funcional. Os processos ágeis promovem o desenvolvimento sustentável. Os sponsors, a equipa e os utilizadores deverão ser capazes de manter, indefinidamente um ritmo constante. A atenção permanente à excelência técnica e um bom design da solução aumentam a agilidade. Simplicidade- a arte de maximizar a quantidade de trabalho que não é feito- é essencial. As melhores arquiteturas, requisitos e desenhos surgem de equipas autoorganizadas. A equipa reflete regularmente sobre o modo de se tornar mais eficaz, fazendo os ajustes e adaptações necessárias. Sommerville (2015a), com base na filosofia por trás do manifesto ágil e valores apresentados pelos seus autores, apresenta uma visão sobre um conjunto de princípios comuns a vários métodos ágeis e respetiva descrição. Este autor acrescenta que todos os métodos ágeis sugerem que o desenvolvimento e entrega de software deve ser feito de maneira incremental. E, estes métodos são baseados em diferentes processos ágeis mas partilham um conjunto de princípios, sendo eles 27

44 Envolvimento com o cliente, Adotar a mudança, Entregas incrementais, Manter a simplicidade, Pessoas, não processos. O princípio Envolvimento com o cliente avoga que os clientes devem ser envolvidos ao longo do processo de desenvolvimento e o seu papel é fornecer, priorizar novos requisitos do sistema e avaliar iterações do sistema. Adotar a mudança significa esperar e aceitar que os requisitos do sistema mudem e como tal desenhar o sistema para alojar estas mudanças. O princípio Entregas Incrementais provém do facto que nos métodos ágeis, o software é desenvolvido através de incrementos, com o cliente a especificar os requisitos a serem incluídos em cada incremento. No princípio Manter a simplicidade descreve que deve existir o foco na simplicidade tanto no software a ser desenvolvido como no processo de desenvolvimento, seja onde for possível, deve-se trabalhar ativamente para que se possa eliminar o máximo de complexidade possível do sistema. Pessoas, não processos é um princípio que refere que as habilidades da equipa de desenvolvimento devem ser reconhecidas e exploradas. Os elementos da equipa devem ser deixados para desenvolver as suas próprias maneiras de trabalhar sem processos prescritos (Sommerville, 2015a) Chaos Report O Standish Group (2015) elaborou um relatório sobre o estado da indústria de desenvolvimento de software, no qual abrangem projetos de todo o mundo, feitos numa vasta variedade de indústrias, desde pequenas melhorias a implementações de reengenharia em sistemas muito complexos (Hastie & Wojewoda, 2015). Uma das grandes diferenças do relatório do ano de 2015 para os anos anteriores, foi que o Standish Group redefiniu a sua definição de sucesso, como relata Jennifer na entrevista presente no artigo de Hastie & Wojewoda (2015). Para o Standish Group, antes um projeto de sucesso era dentro do tempo, do orçamento e do âmbito, mas em 2015, este último mudou para com resultados satisfatórios. Neste relatório podemos ver que em 2015, comparativamente aos 4 anos que lhe precedem, o sucesso geral dos projetos aumentou, a percentagem dos projetos desafiadores e que falharam diminiu (Hastie & Wojewoda, 2015). É ainda referido neste relatório que a tendência dos projetos mais pequenos terem uma maior probabilidade de sucesso continuou como no relatório do ano anterior. Sommerville (2015a), no seu livro também acaba por confirmar este facto, ao referir que os métodos ágeis têm tido mais sucesso para dois tipos de desenvolvimento de sistemas: quando o a organização desenvolve um produto de tamanho médio ou pequeno para venda e quando existe um compromisso do cliente com o processo de 28

45 desenvolvimento, onde há poucas regulamentações e stakeholders externos que possam afetar o software, sendo desta maneira mais fácil de alcançar resultados satisfatórios. Com a inserção de métodos ágeis de desenvolvimento nos últimos anos, neste estudo é possível comparar os resultados dos projetos entre os que utilizam uma metodologia ágil e projetos tradicionais, como uma metodologia em waterfall, tendo ainda como outro fator de análise, o tamanho do projeto. Como se pode ver na figura 6 presente neste estudo, em todos os tamanhos dos projetos, as abordagens ágeis apresentam resultados que incluem uma maior probabilidade dos projetos serem bem sucedidos e menor probabilidade de falhas completas (Hastie & Wojewoda, 2015). Figura 6- Comparação da Chaos Resolution entre Agile e Waterfall (retirado de Métodos ágeis As ideias subjacentes aos métodos ágeis foram desenvolvidas por volta do mesmo tempo por um número diferente de pessoas na década de 1990 (Sommerville,2015a) e, como já referido no início da secção 2.4, antes do Agile Manifesto, alguns dos métodos que aqui vão ser revistos ( como os que já existiam antes de 2001), eram chamados de métodos lean, que era o termo utilizado na indústria antes do termo ágil ganhar popularidade. Cohn (2006), na sua obra e, a partir da compreensão dos quatro valores principais citados no Manifesto Ágil, propõe que se pode virar a atenção para o que uma equipa ágil parece na prática. Os 29

46 quatro valores ao serem tidos em conta coletivamente, levam a processos de desenvolvimento de software que são altamente iterativos e incrementais e, que levam à entrega de código e software testado no final de cada iteração. Então, Cohn (2006) propõe que as maneiras principais em que as equipas ágeis trabalham são: Trabalhar como uma equipa; Trabalhar em pequenas iterações; Entregar algo em cada iteração; Focar nas prioridades do negócio; Inspecionar (perceber o que correu bem e o que correu mal) e adaptar; Nesta secção é feita uma revisão descritiva e sucinta de vários abordagens para o desenvolvimento ágil: Extreme Programming (XP), Scrum, Kanban e OpenUP com o objetivo de recolher informação sobre ambos os métodos, assim como as melhores práticas propostas por estes, que serão úteis para a formulação de uma primeira iteração da escala de maturidade ágil a ser proposta com esta dissertação. Os métodos Extreme Programming (XP) e o Scrum são dois métodos ágeis bastante conhecidos. Muitas vezes, na prática, os métodos de gestão de projeto presentes no Scrum são combinados com as técnicas mais práticas do XP, desta maneira as duas técnicas podem funcionar como complemento uma da outra (Stellman & Greene, 2014). Extreme Programming (XP) Em 1999, Beck documentou a ideia do XP num livro chamado Extreme programming Explained, este autor é um dos participantes de Agile Alliance e também foi um dos participantes do Agile Manifesto. Em 2004 publicou a segunda versão do livro, com melhorias de cinco anos de experiência de trabalho com o XP, incluindo feedback positivo e negativo. O XP evoluiu de problemas causados devido aos longos ciclos de desenvolvimento dos modelos de desenvolvimento tradicionais (Beck,1999) e surgiu primeiramente com práticas que foram vistas como eficazes nos processos de desenvolvimento de software durante as décadas anteriores (Beck, 2000). É uma coleção de ideias e práticas retiradas de metodologias já existentes (Beck, 1999). Beck (2000) explica que o termo extreme resulta de levar os princípios e práticas do senso comum a um nível extremo e que apesar das práticas individuais presentes no XP não terem sido criadas por ele e não serem novas, foram coletadas e alinhadas de maneira a poderem ser integradas entre si e formar uma metodologia para o desenvolvimento de software. 30

47 O XP tem o objetivo de possibilitar o desenvolvimento de software com sucesso mesmo com requisitos vagos ou em constante mudança em pequenas e médias equipas. Em XP, os requisitos são chamados de user stories, que são implementados diretamente como uma série de tarefas. Os programadores trabalham em pares, desenvolvem os testes para cada tarefa antes de escreverem o código e todos os testes devem ser executados com sucesso quando o código é integrado no sistema (Sommerville, 2015a). Os principais valores do XP são a comunicação e feedback, simplicidade e coragem. A comunicação frequente e cara a cara com o consumidor e também com os desenvolvedores do projeto, que é vital para o sucesso do projeto em XP. O lançamento frequente de código funcional e consequente receção de feedback por parte do cliente também representa uma parte crítica. Este método defende que é mais rápido e mais eficiente desenvolver uma solução simples para as necessidades correntes do software do que gastar demasiado tempo a desenhar uma solução flexível e reutilizável. Os programadores em XP precisam de acreditar que com os valores e práticas presentes neste, serão responsáveis por produzir código de alta qualidade para o software (Turk, et al., 2005). Processo O ciclo de vida do XP consiste nas seguintes fases: Exploração, Planeamento, Iterações a serem entregues, Produção, Manutenção e Morte (Beck,2000). A figura 7 esquematiza o ciclo de vida do processo em XP. Figura 7-Ciclo de Vida do Processo em XP (retirado de Abrahamson, et al.,(2002)) 31

48 A tabela seguinte descreve de forma sucinta as fases do ciclo de vida conforme a descrição de Beck (2000) no capítulo 21. Fase Exploração Planeamento Iterações a serem entregues Produção Manutenção Morte Descrição Os clientes escrevem as user stories que desejam ver incluídas na primeira entrega. Cada story acrescenta uma funcionalidade a ser adicionada ao sistema. Enquanto isto, a equipa do projeto estuda as limitações, familiarizase, testa a tecnologia a utilizar e explora diferentes possibilidades de arquitetura para o sistema através do desenvolvimento de um protótipo do sistema. Define a prioridade de cada story e o acordo do conteúdo entre os programadores e o cliente que a primeira entrega deve ter, ou seja, quando um pequeno conjunto de stories estará completo. Para acordarem a calendarização das entregas, os programadores, fazem uma estimativa baseada no esforço que cada story requere Inclui varias iterações do sistema antes da primeira entrega. A calendarização da fase de planeamento é dividida pelo número de iterações (cada uma destas leva de uma a quatro semanas a ser implementada). O cliente é quem decide as stories que vão ser selecionadas para cada iteração e no final de cada uma cria os testes funcionais a serem executados. No final da última iteração o sistema está pronto para produção. Requer a execução de mais testes e a avaliação do desempenho do sistema antes de ser entregue ao cliente. Nesta fase, novas mudanças podem ser requeridas e a decisão de serem incluídas na versão atual ou numa futura, tem de ser tomada. Conta também com feedback por parte do cliente. As novas ideias e sugestões são documentadas para serem implementadas durante a fase de manutenção. Esta fase lida com a necessidade de manter o sistema da primeira entrega funcional enquanto que, ao mesmo tempo, se produzem novas funcionalidades. Importa notar que a equipa deve estar preparada para interromper o desenvolvimento caso ocorra algum problema na produção. Nesta fase também é aplicado esforço em tarefas que dizem respeito ao suporte ao cliente. Por estes factos, a velocidade de desenvolvimento pode diminuir depois do sistema estar em produção. A aproximação desta fase dá-se quando o cliente não tem mais stories para serem implementadas, mas isto requer que o sistema satisfaça as necessidades do cliente. É o momento no qual se escreve a documentação necessária sobre o sistema, quando não existem mais mudanças na arquitetura, design, código do sistema. Apesar disto, pode ainda haver outro meio de chegar a esta fase, que é quando o sistema não entrega os resultados desejados, quando se torna muito dispendioso ou quando existe a inabilidade do sistema acomodar stories futuras. Tabela 2- Descrição das fases do ciclo de vida do XP (adaptado de Beck (1999;2000) e Abrahamson, et al.,(2002)) 32

49 Papéis e responsabilidades No XP existem papéis diferentes para os vários integrantes da equipa do projeto que variam conforme as tarefas que cada um tem como responsabilidade. A tabela seguinte apresenta segundo o capítulo 22 de Beck (2000), os vários papéis e responsabilidades correspondentes. Papel Programador Cliente Tester Tracker Coach Consultor Big Boss ou Gestor Responsabilidades Escrever testes e manter o código o mais simples possível. Comunicar e existir coordenação com outros programadores e membros da equipa, pois um dos factores de sucesso do XP é conseguir com que exista esta comunicação e coordenação entre todos os integrantes do projeto. Escrever as stories e os testes funcionais. Decidir quando um cada requisite é satisfeito. Definir a prioridade dos requisitos para a implementação. Ajudar o cliente a escrever testes funcionais. Executar regularmente estes testes, transmitir os seus resultados e ter a preocupação da manutenção das ferramentas de teste. Seguir as estimativas feitas pela equipa e dar feedback sobre o quão precisa foi a sua estimativa, com o objetivo de melhorar estimativas futuras. Traçar o progresso feito para cada iteração e avaliar se os objetivos são tangíveis conforme os recursos disponíveis e restrições de tempo ou se alguma mudança será necessária ao processo. Ser responsável pelo processo como um todo. Notar quando existem desvios do que deve ser feito (do processo da equipa) e fazer com que a equipa tenha atenção a este aspeto, ou seja, servir de guia para os membros da equipa seguirem o processo. Membro externo à equipa que deve possuir o conhecimento técnico específico necessário. Estar atento ao que a equipa faz de uma maneira neutra. Guiar a equipa para perceberem o problema que necessitam de resolver de maneira clara. Providenciar testes específicos para mostrar exatamente quando o problema foi resolvido. Estar disponível para ensinar como resolver os seus problemas aos membros que necessitarem. Tomar as decisões. Comunicar com a equipa para determinar a situação corrente e distinguir quaisquer dificuldades ou deficiências no processo. Tabela 3- Descrição dos papéis e responsabilidades do XP (adaptado de Beck (2000)) Melhores práticas Práticas são atividades concretas e artefactos que um método define como base a serem utilizadas no processo (Abrahamsson, et al., 2002) e são as descrições das maneiras de atingir um objetivo (Sommerville, 2009). Pequenas iterações e entregas com a obtenção de feedback rápido, a participação do cliente, a comunicação e coordenação, a integração contínua e testes sucessivos, a posse coletiva do código, a documentação limitada e a programação a pares são algumas das principais caraterísticas do XP. (1999,2000). As práticas presentes no XP são apresentadas na tabela 5 que está de acordo com Beck 33

50 Prática Planning game Small releases Metaphor Simple design Tests Refactoring Pair Programming Continuous Integration Collective ownership Descrição Deve existir uma interação próxima entre o cliente e os programadores. Os programadores estimam o esforço necessário para implementar as user stories e com base nestas estimativas, o cliente decide sobre o âmbito e o tempo das iterações. Os programadores implementam apenas a funcionalidade exigida nas stories da iteração presente. O sistema é colocado em produção em alguns meses, mesmo antes de resolver o problema todo. Novas versões são feitas até diariamente e no máximo mensalmente A forma do sistema é definida por uma metaphor ou conjunto de metaphors partilhadas entre o cliente e os programadores. Esta storie partilhada guia todo o desenvolvimento ao descrever como o sistema funciona. Enfatiza que o design da solução seja o mais simples possível, que seja implementável no momento. Complexidade desnecessária e código extra são imediatamente removidos. O desenvolvimento do software provém dos testes escritos pelos programadores (test driven). Os testes são implementados antes do código e são executados continuamente. O cliente escreve os testes funcionais para as stories de uma iteração. Re-estruturar o sistema com a remoção de duplicações, melhorar a comunicação, simplificar e adicionar flexibilidade. Todos os programadores são responsáveis por corrigir e melhorar o código o mais cedo possível cada vez que uma possível melhoria é encontrada. Toda a produção de código é feita por duas pessoas em apenas um computador. Cada novo pedaço de código é integrado no código de base logo que esteja pronto, por isto, o sistema é integrado a partir do zero várias vezes por dia e todos os testes são feitos a cada mudança feita no código e devem apresentar resultados positivos para ser aceite ou então, as mudanças são descartadas. Todos os programadores devem melhorar o código em qualquer parte do sistema, a qualquer momento, sempre que virem oportunidade para tal. 34

51 On-site customer 40-hour-weeks Open Workspace Just rules O cliente deve estar presente e disponível a tempo inteiro para a equipa de desenvolvimento Máximo de 40 horas de trabalho semanais. Não são permitidas mais que duas semanas seguidas a ultrapassar este tempo e se tal acontecer, é tratado como um problema a ser resolvido. A equipa trabalha numa sala ampla com pequenas cabines à volta da periferia. Os pair programmers trabalham nos computadores alocados ao centro. Uma equipa Extreme tem as suas próprias regras, que podem ser modificadas a qualquer altura caso haja um consenso e o impacto desta mudança deve ser avaliado. Tabela 4- Práticas do XP (Adaptado de Beck (1999,2000), Abrahamsson, et al.,(2002), Sommerville (2015a)) Segundo Cockburn (2002), duas peculiaridades que devem ser ajustadas por serem controversas: a ausência de documentação e a restrição a equipas pequenas. Muitas vezes os sponsors querem a entrega de alguma documentação para além do sistema a ser desenvolvido. Para além disto, se várias pessoas abandonarem o projeto sucessivamente, num curto espaço de tempo, os novos integrantes do projeto não vão ter tempo de absorver todos os detalhes do projeto adequadamente e, isto também se deve à inexistência de documentação. Sendo que a única documentação existente são as user stories, que apenas contêm as funcionalidades requeridas. Scrum O Scrum é uma abordagem criada por Ken Schwaber e Jeff Sutherland ao longo dos anos 90 e finalmente formalizada em 1995 e deriva do trabalho presente no artigo de Takeuchi e Nonaka (1986). Para além disto também foram Takeuchi e Nonaka que deram o nome Scrum a esta abordagem (Sutherland, 2007). O Scrum é uma framework com a qual as pessoas podem resolver problemas complexos, ao mesmo tempo que conseguem entregar produtos do mais alto valor possível de maneira produtiva e creativa. O Scrum é uma framework de processo utilizada para gerir projetos sobre produtos complexos. Apesar de ser uma framework de processo, não é um processo, técnica, ou mesmo um método definitivo. É uma estrutura (framework) na qual se podem empregar várias técnicas e processos (Schwaber & Sutherland, 2017). O Scrum baseia-se num processo empírico, iterativo e incremental. Ao ser uma metodologia que se baseia num processo empírico tem em conta que o conhecimento vem da experiência e as decisões 35

52 são feitas baseadas no que é conhecido. Assim, os três pilares que suportam uma implementação de um processo de controlo empírico e por consequência, do Scrum são: transparência, inspeção e adaptação (Schwaber & Sutherland, 2017). O Scrum é uma abordagem especialmente popular em em organizações que decidiram mudar de abordagens tradicionais para uma metodologia ágil (Ashmore & Runyan, 2014). Assim, é um bom ponto de partida para organizações que querem fazer a transição para o ágil, devido à sua simplicidade na comunicação (Stellman & Greene, 2014), mas apesar de ser simples de compreender, é difícil de dominar (Schwaber & Sutherland, 2017). A abordagem que o Scrum apresenta para gerir projetos ágeis, provou a sua aptidão ao gerar excelentes resultados. O Scrum lida com um projeto em iterações, ou seja, em curtos períodos de tempo para atingir partes de um objetivo e então voltar a visitar os objetivos numa reunião. Uma iteração é normalmente feita durante 30 dias e fornece a capacidade e flexibilidade de uma equipa fazer a sua própria gestão, pois têm o foco em objetivos para trabalharem que são principalmente a prioridade dos objetivos de negócio do cliente (Schwaber, 2004). Assim, o foco principal do Scrum é fornecer uma forma de trabalho para que os elementos das equipas de projetos que utilizem esta abordagem possam produzir software que oferece valor, de forma flexível num ambiente em constante mudança (Lopes, 2014). A framework apresentada pelo Scrum consiste nos papéis, eventos, artefactos e regras associados à equipa Scrum (Scrum team). Cada componente da framework tem um propósito específico e é essencial para que esta abordagem obtenha sucesso na sua utilização (Schwaber & Sutherland, 2017). Papéis e Responsabilidades Segundo a Scrum Guide que foi desenvolvida, atualizada e sustentada por mais de vinte anos pelos autores do Scrum, Jeff Sutherland e Ken Schwaber (2017), no Scrum existem três papéis, sendo eles o Product Owner, a equipa de desenvolvimento e um Scrum Master. Para além destes papéis que dizem respeito à Scrum Team (Schwaber & Sutherland, 2017), existem outros que fazem parte do ambiente desta abordagem e são referidos por estes dois autores do Scrum noutros papers e por exemplo por Abrahamsson (2002). Estes papéis são: o cliente, o utilizador e a própria gestão. Apesar disto, neste tópico e para este trabalho de dissertação, irão apenas ser abordados os papéis referentes à equipa, neste caso a Scrum Team. 36

53 As Scrum Teams são capazes de se auto organizarem e são multifuncionais. Equipas auto organizadas são capazes de escolher a melhor maneira de conseguir fazer o seu trabalho, em vez de estarem a ser direcionadas por alguém de fora da equipa. Multifuncionais porque têm as competências necessárias para cumprir o trabalho que têm a fazer sem depender de outros que não façam parte da equipa. O modelo de equipa concebido pelo Scrum é feito de maneira a otimizar a flexibilidade, criatividade e produtividade das esquipas. Como já foi referido, as Scrum teams entregam os produtos de forma iterativa e incremental, de maneira a maximizar o feedback e as entregas incrementais de um produto acabado asseguram que uma versão funcional do artefacto está sempre disponível (Schwaber & Sutherland, 2017). Então, os papéis presentes no Scrum são descritos em seguida de maneira sucinta: Product Owner: é o dono do produto (Lopes, 2014), uma pessoa responsável por maximizar o valor do produto que resulta do trabalho da equipa de desenvolvimento. Toma as decisões do produto/projeto e as suas decisões são visíveis através do conteúdo e da ordem dos itens do Backlog do produto e é o responsável por este artefacto. Esta pessoa pode fazer este trabalho ou dar a alguém da equipa de desenvolvimento para o fazer, mas apesar disto, continua a ser o responsável. A última palavra no planeamento do Incremento/Sprint ou da prioridade dos itens do Backlog do produto é sempre dele. Por isto, ninguém pode forçar a equipa de desenvolvimento a trabalhar a partir de um conjunto diferente de requisitos. Assim, o Product Owner ao ser a única pessoa responsável pela gestão do Backlog do produto. Gerir este artefacto deve incluir a expressão clara os itens presentes neste, a ordenação dos itens de maneira a atingir os objetivos, otimização do trabalho que a equipa de desenvolvimento desempenha, assegurar que o Backlog do produto é visível, transparente e claro para todos, mostrar no que a equipa deve trabalhar de seguida e assegurar que esta percebe os itens do Backlog (Schwaber & Sutherland, 2017). Equipa de desenvolvimento: é constituída pelos profissionais que elaboram uma versão funcional que possibilita um potencial incremento do produto acabado ao fim de cada Sprint. As equipas são auto organizam-se (ninguém lhes diz como tornar o Backlog do produto em incrementos com potenciais funcionalidades para entrega) e devem ser estáveis e dedicadas a 100% ao projeto, com um alto nível de autonomia, que apesar 37

54 de terem poder de decisão também têm de ter mais responsabilidade. As equipas são multifuncionais e multidisciplinares, com todas as habilidades necessárias para criar um incremento do produto. Não existe outros nomes ou diferença de papéis para os membros das equipas de desenvolvimento, independentemente do tipo de trabalho que qualquer pessoa esteja a desenvolver, são todos chamados de developer (Schwaber & Sutherland, 2017). É a equipa de desenvolvimento que desenvolve as funcionalidades do produto e como um todo, são responsáveis pelo sucesso de cada iteração (Lopes,2014). Segundo Sutherland e Schwaber (2017) o número ideal de membros da equipa de desenvolvimento deve estar entre os três e os nove elementos, mas idealmente entre cinco e nove. Scrum Master: é o líder da equipa (facilitador) e é responsável por transmitir os valores do Scrum, tal é possível ao ajudar todos os elementos da equipa a compreender a teoria do Scrum, as práticas, regras e valores. Garante que o processo é seguido e orienta e distribui as tarefas pela equipa. É responsável pela gestão da equipa, incluindo cumprimento de tarefas, objetivos, datas, bom funcionamento/ambiente do grupo e ainda por resolver impedimentos que possam surgir e fazer mudanças no processo para a equipa continuar a trabalhar o mais produtivamente possível. O Scrum Master serve o Product Owner, a equipa de desenvolvimento e ainda a organização (Schwaber & Sutherland, 2017). Eventos do Scrum Todos os eventos prescritos do Scrum são utilizados para criar regularidade e para minimizar a necessidade de reuniões que não estejam definidas, para além disto, todos os eventos têm um tempo limite. Cada evento do Scrum representa uma oportunidade formal de inspecionar ou adaptar algo, pois foram concebidos especialmente para possibilitar a transparência e a inspeção. A não inclusão de algum destes eventos do Scrum resulta numa redução da transparência e na perda de uma oportunidade de fazer inspeções e adaptar algo (Schwaber & Sutherland, 2017). Em seguida são explicados cada um dos eventos do Scrum de forma descritiva e sucinta: O Sprint: representa uma iteração do desenvolvimento do produto (Sommervile 2015a), é o coração do Scrum, onde a equipa se organiza de modo a produzir um incremento 38

55 executável e funcional do produto que duração ronda os 30 dias ou menos. Quando um Sprint é concluído, dá-se imediatamente o início de outro. Um Sprint contém e consiste no Sprint Planning, Daily Scrums, trabalho de desenvolvimento, Sprint Review e na Retrospetiva do Sprint (Schwaber & Sutherland, 2017).É o procedimento de adaptação às variáveis em mudança do ambiente (requisitos, tempo, recursos, conhecimento, tecnologia) (Abrahamsson, et al., 2002). Cada Sprint pode ser considerado como um pequeno projeto com no máximo um mês de duração, porque tal como os projetos, os Sprints são utilizados para conseguir/cumprir algo e têm um objetivo sobre o que se precisa de construir, um respetivo design e um plano flexível que vai guiar a sua construção, o trabalho e os resultados do incremento. Um Sprint pode vir a ser cancelado se o seu objetivo se tornar obsoleto, mas devido à pequena duração de cada Sprint, o seu cancelamento não costuma ocorrer (Schwaber & Sutherland, 2017). Sprint Planning: o trabalho a ser feito no Sprint é planeado no Sprint Planning. Toda a Scrum Team colabora na criação deste plano. Cada Sprint Planning demora no máximo oito horas para cada Sprint de um mês e é realizada através de uma reunião. O Scrum Master assegura que o evento acontece e que os participantes compreendem o seu propósito. Este evento responde ainda às duas seguintes perguntas: What can be delivered in the Increment resulting from the upcoming Sprint? e How will the work needed to deliver the Increment be achieved? (Schwaber & Sutherland, 2017). Para responder à primeira pergunta a equipa de desenvolvimento tenta prever a funcionalidade que vai ser desenvolvida durante o Sprint. O Product Owner leva para esta reunião a Backlog devidamente priorizada e explica o objetivo a ser alcançado pelo Sprint, através da clarificação dos itens do Backlog do produto que, se completos/cumpridos, fazem com que o objetivo se concretize. A segunda pergunta, depende da primeira, depois de se ter o objetivo do Sprint definido e selecionados os itens do Backlog do produto para a Sprint daquele mês, a equipa de desenvolvimento decide como vai construir estas funcionalidades num incremento acabado do produto. Os itens do Backlog do produto selecionados para a corrente Sprint, mais o plano, são denominados de Sprint Backlog (Schwaber & Sutherland, 2017). Daily Scrum: é uma reunião diária a horas fixas (para diminuir a complexidade) que dura no máximo quinze minutos e é onde a equipa de desenvolvimento planeia o trabalho para o dia seguinte. Serve também para otimizar a colaboração entre a equipa e o 39

56 desempenho, ao inspecionar o trabalho feito desde a última Daily Scrum e ao tentar prever o trabalho do próximo Sprint. Nesta reunião, cada membro deve dizer o que fez no dia anterior, o que tem para fazer hoje e se existe algum impedimento que o possa estar a impedir de concretizar os objetivos (Schwaber & Sutherland, 2017). Sprint Review: é uma reunião com a duração máxima que ronda as quatro horas, que acontece no final de cada Sprint para se poder inspecionar o incremento elaborado e adaptar o Backlog do produto, caso necessário, baseado na discussão da equipa de desenvolvimento com os stakeholders sobre o que correu bem durante a Sprint, os problemas encontrados e os que foram resolvidos. A equipa de desenvolvimento mostra o trabalho realizado e responde a perguntas sobre o incremento. O Product Owner projeta datas para a conclusão do projeto baseadas no progresso até à data. Posto isto, todos colaboram para decidir o que fazer a seguir, de modo a que a Sprint Review forneça inputs valiosos para a Sprint Planning que se segue (Schwaber & Sutherland, 2017). Sprint Retrospective: é uma reunião que representa uma oportunidade para a Scrum Team de fazer uma inspeção sobre ela própria e criar um plano de melhorias para ser aplicado na próxima Sprint. O seu propósito é inspecionar como a última Sprint correu no que diz respeito às pessoas, relações entre elas, ao processo e às ferramentas, identificar e ordenar os principais itens que correram bem e potenciais melhorias. Por fim, criar um plano para implementar melhorais na forma como a Scrum Team faz o seu trabalho (Schwaber & Sutherland, 2017). Artefactos do Scrum Os artefactos definidos pelo Scrum são especialmente concebidos para maximizar a transparência da informação principal para que todos tenham a mesma compreensão do artefacto (Schwaber & Sutherland, 2017). Os artefactos podem ser utilizados para guiar a maneira de pensar, avaliar competências e criar algo passível de ser alvo de uma auditoria. Os artefactos consistem de documentos, modelos, programas, casos de teste e outros deliverables criados antes da implementação do sistema (Sutherland e Schwaber, 2011). 40

57 User stories: representam um objetivo a ser alcançado, ou seja, representam uma funcionalidade, estas funcionalidades descritas nas User stories trazem valor quer para o utilizador ou comprador do sistema ou software (Cohn, 2004). Por vezes quando chega a altura de determinada story ser implementada, precisa de ser dividida em várias, em partes mais pequenas. Isto acontece quando é uma story muito grande para se conseguir alocar numa única iteração, ou mesmo pode acontecer de algumas vezes ser maior do que a iteração inteira. E, como tal uma sotry nesta situação precisa de ser dividida (Cohn, 2006). Backlog do produto: é uma lista ordenada em termos de valor para o negócio de tudo que é necessário estar no presente no produto, inclui as funcionalidades descritas nas user stories, funções, requisitos, melhorias e ajustes que constituem as mudanças a ser feitas no produto (Schwaber & Sutherland, 2017; Sommerville 2015a). O Product Owner é o responsável pelo Backlog do produto, incluindo pelo seu conteúdo, disponibilidade e ordenação. É um artefacto que nunca está completo, mas sim sempre em constante evolução, é dinâmico, evolui à medida que o produto e respetivo ambiente evoluem, muda constantemente com o objetivo de identificar o que o produto precisa para ser apropriado, competitivo e útil (Schwaber & Sutherland, 2017). Sprint Backlog: é o ponto de partida para cada Sprint. É uma lista do conjunto dos itens selecionados do Backlog do produto selecionados para serem implementados no próximo Sprint. Os itens são selecionados pela Scrum Team juntamente com o Scrum Master e o Produtc Owner na Sprint Backlog Meeting. Contrasta com o Backlog do produto, pois é estável até ao próprio Sprint estar completo. Quando todos os itens do Sprint Backlog estão completos, uma nova iteração do sistema é entregue (Abrahamsson, 2002; Schwaber & Beedle, 2001). Para além disto, é ainda um plano para a entrega do incremento do produto e da realização do objetivo do Sprint, pois torna visível todo o trabalho que a equipa de desenvolvimento identificou como necessário para ir ao encontro dos objetivos do Sprint. Sendo assim, funciona como uma visualização total, em tempo real do trabalho que a equipa de desenvolvimento planeou cumprir durante o Sprint (Schwaber & Sutherland, 2017). Existe um outro artefacto associado ao Sprint Backlog que são as Sprint Burndown Charts. Este artefacto consiste num gráfico que serve como indicador de 41

58 progresso do Sprint e permite à equipa ver a evolução e, para caso seja necessário, tomar medidas. Este artefacto é visualizado pela equipa nas Daily Scrum (Lopes, 2014). Incremento: o incremento é a soma de todos os itens do Product Backlog desenvolvidos durante a Sprint e é o artefacto que representa o valor dos incrementos dos Sprints anteriores. No final de cada Sprint, um incremento deve estar acabado, o que significa que se deve encontrar numa condição em que é útil e vai de encontro à definição que a Scrum Team tem de acabado (Schwaber & Sutherland, 2017). Ciclo do Scrum Os projetos que utilizam a abordagem do Scrum são divididos em ciclos, pois o Scrum é uma framework iterativa e incremental para o desenvolvimento de projetos. Esta abordagem estrutura o desenvolvimento em ciclos chamados Sprints. Cada uma destas iterações não demora mais que um mês e, a seguir a uma, logo outra toma lugar, sem parar. No início de cada Sprint, a equipa seleciona os itens de uma lista ordenada (Backlog do Produto) e passa a ter o Sprint Backlog. A equipa compromete-se a concluir o desenvolvimento dos itens até ao final do Sprint. Durante o Sprint, os itens não mudam e todos os dias a equipa reúne (Daily Scrum) para inspecionar o seu progresso e, caso necessário, ajustar os próximos passos necessários para completar o trabalho que falta. No fim do Sprint, a equipa revê-o com os stakeholders (Sprint Review) e demonstra o que foi construído, aqui é obtido feedback que pode ser introduzido no próximo Sprint. O Scrum dá ênfase ao produto acabado no fim de cada Sprint, ou seja, que o incremento do produto está pronto para ser entregue de dar pequenos paços no desenvolvimento, fazendo inspeções do produto que resultou do Sprint e da eficácia das práticas correntes, após isto enfatiza a adaptação aos objetivos do produto e das práticas do processo (Sutherland e schwaber, 2011). A figura abaixo representa sumariamente o ciclo do Scrum, incluindo os principais papéis, artefactos e eventos. 42

59 Tabela 5-Ciclo do Scrum (Retirado de Sutherland e schwaber, (2011)) OpenUP O OpenUP é um método de desenvolvimento de software baseado no RUP mas com uma estrutura simplificada. Segundo Balduino (2007) contem apenas o conteúdo fundamental para o desenvolvimento de software e portanto, não providencia guias em vários tópicos com que alguns projetos podem ter de lidar. Contudo, é completo no sentido em que pode ser manifestado como um processo inteiro para construir um sistema. Para cobrir necessidades de vários tópicos que não aborda, o OpenUp é extensível para ser usado como base ao qual mais conteúdo do processo pode ser adicionado ou integrado conforme o necessário. O OpenUP é um processo ágil que aplica abordagens iterativas e incrementais num ciclo de vida estruturado. Processo A estrutura do ciclo de vida do projeto no método OpenUP apresenta quatro fases, sendo elas: Inception, Elaboration, Contruction, Transition. (Balduino, 2007). A imagem seguinte representa o fluxo de trabalho estruturante deste ciclo de vida definido que suporta os princípios do OpenUP. 43

60 Figura 8 - Fluxo de trabalho do OpenUP (Retirado de A tabela 7 faz o mapeamento entre as iterações de cada fase e respetivas atividades que lhe dizem respeito, com os objetivos de cada fase, de modo a conseguirmos entender no que consiste cada fase que integra o processo de desenvolvimento em OpenUP. Nota-se também que, como este método é baseado no RUP, aplica fases do Unified Process, as quais já foram referidas acima. Padrões das iterações Inception Phase Iteration Iniciar o Projeto Planear e Gerir a Iteração Identificar e Aperfeiçoar os Requisitos Acordo sobre a Abordagem Técnica Elaboration Phase Iteration Planear e gerir Iteração Identificar e Aperfeiçoar os Requisitos Definir a Arquitetura Desenvolver o Incremento da Solução Testar a Solução Tarefas Contínuas Construction Phase Iteration Planear e gerir Iteração Identificar e Aperfeiçoar os Requisitos Desenvolver o Incremento da Solução Testar a Solução Tarefas Contínuas Transmition Phase Iteration Planear e gerir Iteração Desenvolver o Incremento da Solução Testar a Solução Tarefas Contínuas Objetivos da fase Compreender o que se tem de construir Identificar as funcionalidades-chave do sistema Determinar pelo menos uma solução possível Compreender o custo, calendarização e riscos associados ao projeto Obter uma compreensão aprofundada dos requisitos Elaborar o design, a implementação, a validação e linhas base da arquitetura Mitigar os riscos, produzir um calendário preciso e estimar os custos De maneira iterativa, desenvolver um produto completo que está pronto para a transição para a comunidade de utilizadores Minimzar o custo de desenvolvimento e obter um grau de paralelismo Concretizar um Beta test para validar se as expetativas dos utilizadores são cumpridas Alcançar a concordância dos stakeholders sobre o desenvolvimento estar completo Tabela 6- Mapeamento entre as iterações e respetivas atividades com os bojetivos de cada fase (Adaptado de Balduino (2007) e de Quando se elabora os diversos padrões dos templates das iterações (que ocorrem quantas vezes for necessário), temos um delivery process que é uma abordagem completa e integrada para desenvolver um tipo especifico de projeto (figura abaixo). Um delivery process descreve o ciclo de vida do projeto e é utilizado como referência para projetos similares (Banduino, 2007). 44

61 Figura 9-Delivery Process do OpenUp (Retirado de Balduino (2007) O OpenUP apresenta assim um delivery process para o desenvolvimento iterativo através de quatro fases. Os padrões dos templates das iterações são aplicados quantas vezes forem necessários e depende de quantas iterações a equipa decidir elaborar em cada fase. E, projetos com necessidades diferentes podem instanciar os pradrões dos templates das iterações de maneira diferente. Papéis e Responsabilidades No OpenUP existem papéis diferentes que representam as habilidades requeridas dos vários integrantes da equipa do projeto. A tabela seguinte apresenta os vários papéis e respetivas responsabilidades. Papel Analista Qualquer papel Arquiteto Desenvolvedor Gestor de Projeto Stakeholder Tester Responsabilidade Representar os interesses e preocupações do cliente e utilizadores finais através da informação fornecida pelos stakeholders para se compreender o problema a ser resolvido e ao mesmo tempo capturar e selecionar prioridades para os requisitos Ser capaz de desempenhar tarefas gerais Projetar a arquitetura de software, que inclui fazer as principais decisões técnicas que limitam o design geral e implementação do projeto Desenvolver uma parte do sistema, incluindo desenhá-la de maneira que vá ao encontro da arquitetura e depois implementar, fazer testes e integrar os componentes que são parte da solução Liderar o planeamento do projeto em colaboração com os stakeholders e a equipa, coordenar interações com os stakeholders e fazer com que a equipa do projeto continue motivada e focada em ir ao dos objetivos do projeto Representa os grupos de interesse cujas necessidades devem ser satisfeitas pelo projeto. É um papel que pode ser representado por qualquer pessoa que é ou potencialmente vai ser, afetada pelo resultado do projeto Fazer as atividades fundamentais de testes, como a identificação, definição, implementação e gerir os testes necessários. Fazer ainda o registo dos resultados dos testes e analisar os resultados. Tabela 7-Papéis e respetivas responsabilidades da equipa em OpenUP (Adaptado de Balduino (2007) e 45