Abordagens AGILE na gestão de projectos

Tamanho: px
Começar a partir da página:

Download "Abordagens AGILE na gestão de projectos"

Transcrição

1 Abordagens AGILE na gestão de projectos João Carlos Loureiro Mendes Ferreira Dissertação para obtenção do Grau de Mestre em Engenharia Electrotécnica e de Computadores Júri Presidente: Orientador: Coorientador: Vogal: Vogal: Prof. Nuno Cavaco Gomes Horta Prof. José Manuel Costa Dias de Figueiredo Prof. Luís Manuel de Jesus Sousa Correia Prof. João Carlos da Cruz Lourenço Prof. Alberto Manuel Rodrigues da Silva Outubro 2013

2

3 Agradecimentos Ao Professor José Figueiredo, por toda a disponibilidade, apoio e motivação que me deu ao longo deste trabalho. Ao Professor Luís Correia, pela ajuda ao longo do trabalho e pela sua disponibilidade. Aos meus Pais pelo apoio incondicional e motivação ao longo de todo o meu percurso académico e por me terem proporcionado as condições ideais para que pudesse ter sucesso. À minha namorada Joana, pela ajuda, apoio, paciência e motivação prestada ao longo destes últimos anos. Sem ela este trabalho não teria sido possível. Ao Pedro Girão por ter facultado os dados referentes ao estudo de caso apresentado nesta dissertação, assim como pela sua disponibilidade para esclarecer todas as dúvidas por mim apresentadas. Agradeço também aos meus amigos por todo o apoio e motivação. Um agradecimento particular ao José Sousa, Miguel Capelo, Francisco Sarmento e Filipe Martins. Agradeço ainda aos meus colegas da TMN pelo apoio e motivação prestado ao longo dos últimos tempos e por terem permitido que conseguisse conciliar o trabalho com a conclusão desta dissertação. i

4 ii

5 Resumo Com a necessidade de aumentar a eficiência da gestão dos projectos, acompanhada pelo aumento da complexidade dos mesmos, surge a necessidade de desenvolver metodologias de gestão de projectos que possam ser adaptáveis às especificidades dos projectos. Com estes factores em vista surgiram as metodologias ágeis. As metodologias ágeis apresentam inúmeras vantagens face às metodologias clássicas utilizadas para gestão de projectos. Estas metodologias são, por norma, aplicadas a projectos de desenvolvimento de software. No entanto, as suas características tornam desejável a sua aplicação a outro tipo projectos, incluindo projectos de Engenharia Electrotécnica. Assim, o objectivo do estudo conduzido nesta dissertação foi a verificação da aplicabilidade de metodologias ágeis a projectos de Engenharia Electrotécnica. Para tal, foi estudada a aplicabilidade destas metodologias a vários campos da Engenharia. Primeiramente foi analisado um caso na área de Engenharia Informática, na qual estas metodologias são usualmente aplicadas. Foi também analisado um caso na área de Engenharia Civil de forma a avaliar a aplicação destas metodologias a projectos com constrangimentos mais rígidos. Por fim, com base nas boas práticas identificadas em ambos os casos, foi avaliada a possibilidade de aplicação das metodologias ágeis a projectos de Engenharia Electrotécnica. Verificou-se que as boas práticas decorrentes da aplicação de metodologias ágeis a projectos de Engenharia Informática e de Engenharia Civil podem ser facilmente extrapoladas para a área de Engenharia Electrotécnica, sendo que as mesmas podem ser adaptadas às necessidades e características especificas dos projectos. Palavras-Chave: Metodologias Ágeis, Gestão de Projectos, Outsystems, LEAN, Boas Práticas, Engenharia Electrotécnica iii

6 iv

7 Abstract With the need to increase the efficiency of project management, followed by the increased of their complexity, comes the need to develop methodologies for project management that can be adapted to the specificities of the projects. With these factors in mind agile methodologies have emerged. Agile methodologies have numerous advantages over the classical methods used in Project Management. These methodologies are usually applied to software development projects. However, their characteristics make them appropriate to be applied to projects in other areas, including Electrical Engineering projects. The aim of the study conducted in this thesis was to verify the applicability of agile methodologies to projects in Electrical Engineering. To this end, the applicability of these methodologies to various fields of engineering was studied. We first analyzed a case study in the area of Computer Engineering, an area in which these methodologies are most commonly applied. It was also analyzed a case study in the area of Civil Engineering to assess the application of these methodologies to projects with more rigid constraints. Finally, based on best practices identified in each case study, we evaluated the possibility of application of agile methodologies in Electrical Engineering projects. It was found that good practices arising from the application of agile methodologies to Computer and Civil Engineering projects can be easily extrapolated to the area of Electrical Engineering, and also that those good practices could be adapted to the needs and specifications of the projects. Keywords: Agile methodologies, Project Management, Outsystems, LEAN, Good Practices, Electrical Engineering v

8 vi

9 Índice Índice de Figuras... ix Índice de Tabelas... x Índice de Abreviaturas... xi 1. Introdução Enquadramento Estado da Arte Contexto Histórico Manifesto Ágil Metodologias Ágeis Scrum Papéis do Scrum Processo Scrum Extreme Programming (XP) Papéis do XP Processo XP Outsystems Conceitos Equipa de projecto Equipa do cliente Equipa de desenvolvimento Outras Metodologias Ágeis Adaptive Software Development (ASD) Crystal Organização da Dissertação Gestão Ágil de Desenvolvimento de Software vii

10 2.1. Estudo de Caso de Aplicação da Ferramenta Outsystems Descrição do Estudo de Caso Estudo de Caso Sizing Timebox Sprints Sprint planning Team leveling Who does what Considerações Finais do Caso em Estudo Gestão Ágil de Projectos de Construção Civil LEAN Thinking Origem, Princípios e Benefícios Desperdício Lean Construction Construção Convencional vs Lean Construction Estudo de Casos Modelo Proposto Descrição do modelo proposto Implementação do modelo, resultados e análise Considerações Finais Conclusões e Perspectivas Futuras Conclusões Perspectivas Futuras Bibliografia Anexo A viii

11 Índice de Figuras Figura Funcionamento geral das metodologias ágeis Figura Funcionamento geral das metodologias clássicas Figura Processo Scrum (Schwaber, 2004) Figura Processo XP (Silva e Videira, 2008) Figura Processo ASD (adaptado de (Abrahamsson et al., 2002)) Figura Relação entre a criticidade e o tamanho das equipas em projectos Crystal (Abrahamsson et al., 2002). 16 Figura Exemplo de sizing Figura Listagem dos sprints Figura Sprint Planning do projecto Figura Team Leveling Figura Who does What Figura Principais benefícios associados à Lean Thinking (adaptado de (Venâncio, 2010)) Figura 3.2 Principais benefícios associados à redução de desperdício Figura Esquema do modelo proposto (Gonçalves, 2009) Figura Esquema top-down referente à montagem de caixilharia (Gonçalves, 2009) Figura 5.2 Exemplo de esquema SIPOC simplificado (Gonçalves, 2009) Figura Exemplo de actividades de um mapa de estado actual (Gonçalves, 2009) Figura Exemplo de actividades de um mapa de estado futuro (Gonçalves, 2009) ix

12 Índice de Tabelas Tabela Comparação entre a Lean Construction e a gestão de projectos convencional [(Abdelhamid e Salem, 2005) através de (Peneirol, 2007)] Tabela 4.1 Aplicabilidade à Engª Electrotécnica das boas práticas identificadas x

13 Índice de Abreviaturas AM ASD DM DSDM EM FDD ISD IT/TI JIT LTE PMBOK PPC SIPOC SWOT TPS VBM VE XP Agile Modeling Adoptive Software Development Delivery Manager Dynamic Systems Development Method Engagement Management Feature-driven Development Internet-speed Development Information Technologies/Tecnologias de Informação Just In Time Long Term Evolution Project Management Body of Knowledge Percentagem de Plano Concluído Suppliers, Inputs, Process, Outputs, Costumer Strenghts, Weaknesses, Opportunities and Treats Toyota Production System Value-based Management Value Engineering Extreme Programming xi

14 xii

15 1. Introdução 1.1. Enquadramento Ao longo dos últimos anos as metodologias ágeis têm vindo a ser desenvolvidas largamente e são actualmente aplicadas a inúmeros projectos. As metodologias ágeis apresentam inúmeras vantagens face às metodologias clássicas utilizadas na Gestão de Projectos e a sua aplicação a projectos de diversas áreas é, portanto, de grande interesse. Por norma, este tipo de metodologias é aplicado a projectos de desenvolvimento de software que, pela sua natureza se adequam perfeitamente aos princípios introduzidos pelas metodologias ágeis. No entanto, projectos de outras áreas como Engenharia Civil, menos flexíveis e com mais constrangimentos físicos, têm vindo a utilizar estas metodologias. Ainda assim, não há qualquer registo de que metodologias ágeis tenham sido aplicadas a projectos na área da Engenharia Electrotécnica. Assim considerámos importante avaliar a aplicabilidade de metodologias ágeis a projectos de Engenharia Electrótécnica, tendo sido, para isso, estudados projectos em que esta metodologia foi aplicada. Assim, a questão de investigação é avaliar essa aplicabilidade e identificar boas práticas que decorram da aplicação de metodologias ágeis aos projectos em estudo, verificando se as mesmas podem ser extrapoladas para projectos de Engenharia Electrotécnica Estado da Arte Contexto Histórico A evolução sustentada da Gestão de Projectos como disciplina autónoma começa nos anos cinquenta do século vinte. Em meados da década de 1990 começaram a surgir algumas alternativas aos standard (PMBOK), nomeadamente a abordagem Critical Chain e Agile. As abordagens standard continuam a imperar mas, embora significativas em termos de eficácia e de eficiência, reconhece-se que enfermam de uma certa rigidez que as não torna adequadas para determinado tipo de projectos. A falta de adaptabilidade às mudanças ao longo do projecto e a excessiva burocracia inerente a este tipo de metodologias veio facilitar o desenvolvimento de novas metodologias, inicialmente descritas como métodos leves. No ano 2001, um grupo de programadores reuniu-se em Snowbird, uma estância turística nos Estados Unidos da América, para definir, subscrever e descrever os fundamentos principais de uma nova metodologia para a gestão de projectos de software. Surge então, pela primeira vez, o nome de metodologia ágil. Decorrente deste encontro 1

16 foi elaborado o manifesto ágil, documento que contém os princípios e práticas mais relevantes da metodologia. Algum tempo depois surgiu a Agile Alliance, uma organização sem fins lucrativos que pretende promover as metodologias ágeis e aplicação dos princípios do manifesto ágil Manifesto Ágil O manifesto ágil, elaborado em 2001 como referido anteriormente, descreve um conjunto de 12 princípios fundamentais que formam a base para o desenvolvimento de projectos segundo as metodologias ágeis. Esses princípios são os seguintes (Agile Alliance, 2013): Dar máxima prioridade à satisfação do cliente. A entrega do produto deve ser antecipada o mais possível e efectuada progressivamente; Estar sempre aberto à introdução de alterações dos requisitos do projecto, mesmo que tardiamente na execução do mesmo (no caso de projectos que envolvam software). Os processos ágeis devem sempre que possível tirar partido das alterações de modo a dar uma vantagem competitiva aos seus clientes. Esta condição aplica-se por se tratar de um desenvolvimento de intangíveis (software), sendo impossível de aplicar na íntegra em outros ramos da engenharia; Efectuar entregas de produtos funcionais frequentemente. As entregas devem ser semanais ou mensais. Quanto menor o tempo entre as entregas melhor; Incentivar os gestores e programadores a trabalhar diariamente em conjunto de modo a existir um consenso entre o realizado, o a realizar e o como realizar; Criar um ambiente favorável e oferecer todos os recursos necessários para o desenvolvimento do projecto. Contractar funcionários motivados e confiar neles de modo a poderem realizar o seu trabalho; O modo mais eficaz de reunir toda a informação da equipa de desenvolvimento é através de conversas directas. Embora isso não seja sempre possível, deve realizar-se este tipo de reuniões, sempre que para tal haja disponibilidade; Produtos a funcionar bem são o principal meio para medir o progresso do projecto; O desenvolvimento sustentado e constante do projecto deve ser promovido. Os patrocinadores, programadores e utilizadores devem manter um progresso constante; A excelência técnica e de design deve ser uma das características dos projectos ágeis; Simplicidade, sem descuidar a qualidade é prioritária nestes projectos; Construir equipas organizadas de modo a entregar o melhor produto possível em termos de arquitectura, requisitos e design; Efectuar regularmente reuniões para reflectir sobre modos de melhorar o funcionamento do projecto. 2

17 Embora muitas vezes não seja possível cumprir todos os princípios enunciados, os métodos ágeis devem reger-se ao máximo por estes princípios. À primeira vista pode parecer que o manifesto ágil vem cortar com as ferramentas tradicionais para o desenvolvimento dos projectos. Todavia este apenas vem colocar uma escala de prioridades. Nos projectos ágeis é dada prioridade à flexibilidade e à colaboração entre as partes envolvidas ao invés de dar prioridade à rigidez de processos como acontece nas metodologias clássicas Metodologias Ágeis Com a adopção crescente dos princípios ágeis surgiram vários processos para o desenvolvimento de projectos. Embora possam ser utilizados em outras áreas, os processos ágeis mais comuns são maioritariamente aplicados ao desenvolvimento de software. Os processos ágeis mais utilizados actualmente são o Scrum e o Extreme Programming (XP), embora existam outros como o Adaptive Software Development (ASD), Agile Modeling (AM), Crystal Family, Dynamic Systems Development Method (DSDM), Feature-driven Development (FDD), Internet-Speed Development (ISD) (Abrahamsson et al., 2003). As metodologias ágeis introduzem alterações significativas relativamente às metodologias clássicas, das quais provavelmente a mais importante o funcionamento iterativo. O conceito das iterações é dividir o trabalho a efectuar por diversas etapas, fazendo a entrega ao cliente no final de cada etapa. Na maioria dos casos a duração das iterações é definida logo no início do projecto e só deve ser alterada em caso extremo. A duração máxima de uma iteração é tipicamente um mês. Este é, como referido anteriormente, um princípio central das metodologias ágeis. Além da vantagem proveniente do funcionamento iterativo - a entrega progressiva do produto ao invés da entrega apenas no final - estas metodologias permitem um melhor acompanhamento do progresso do projecto, permitindo ao gestor de projectos saber se o projecto está adiantado ou atrasado relativamente à previsão efectuada. As reuniões regulares entre as pessoas envolvidas no projecto permitem um melhor controlo do progresso do projecto, assim como uma gestão mais eficiente de todos os recursos envolvidos no mesmo, sejam eles recursos humanos ou de outro tipo. 3

18 E n t r e g a E n t r e g a D D D D F e e e e i m m m m m Análise Desenv. o 1 Desenv. o 2 Desenv. o 3 Desenv. o Suporte 1ª Iteração 2ª Iteração 3ª Iteração 4ª Iteração E n t r e g a Figura Funcionamento geral das metodologias ágeis. Análise Desenvolvimento D F e i m m o Suporte Figura Funcionamento geral das metodologias clássicas. Como se pode verificar pela Figura 1.1 e Figura 1.2 existe uma diferença acentuada entre as duas abordagens. Nos projectos segundo metodologias ágeis, representados na Figura 1.1, observa-se que existe um período de tempo reduzido para a análise do projecto, sendo esse trabalho feito progressivamente ao longo do projecto. Por outro lado, nos projectos segundo metodologias clássicas, representados na Figura 1.2, a análise é efectuada exaustivamente no início, sendo que o projecto só começa quando todos os requisitos se encontram discriminados e são aceites por todas as partes envolvidas. No caso das metodologias ágeis, no início só se efectua uma análise mais superficial pois os requisitos estão abertos a alterações constantes, sendo, portanto, mais aconselhável ir procedendo a análises progressivas ao longo do projecto. Outra diferença significativa entre as figuras é a diferença na abordagem ao projecto. Como já referido anteriormente, as metodologias ágeis funcionam à base de iterações ao invés das metodologias clássicas que optam por fazer o desenvolvimento todo e só no fim entregar o produto, completamente acabado, ao cliente. Deve ser realçada a diferenciação que é necessária efectuar do âmbito do projecto. Ou seja, caso o objectivo do projecto seja entregar o produto totalmente concluído ao cliente, e o facto de se efectuarem entregas progressivas não traga qualquer valor acrescentado ao projecto deve-se optar por metodologias tradicionais. O risco associado à aplicação dessas mesmas metodologias é inferior, visto que são as metodologias aplicadas na maioria dos casos actualmente e os intervenientes no projecto, em teoria, devem ter um conhecimento superior dessas metodologias. Por outro lado, no caso de um projecto ser desenvolvido através de metodologias clássicas e o mesmo for descontinuado, não existe qualquer retorno para ambas as partes. Nestes casos, se o projecto for desenvolvido 4

19 através de metodologias ágeis, existe sempre a possibilidade de aproveitar aquilo que já tenha sido desenvolvido, logo o prejuízo é menor (esta situação só ocorre nos casos em que tal é possível, podendo variar de projecto para projecto). A grande mais-valia das metodologias ágeis centra-se na versatilidade e na facilidade de mudança inerente às metodologias. No caso das metodologias tradicionais, o risco do projecto está todo do lado do fornecedor da solução, pelo contrário, no caso das metodologias ágeis, ao existir uma maior proximidade com o cliente e uma maior partilha da decisão, o risco é repartido. Outro factor a ter em conta é o facto de no caso de o projecto ser desenvolvido recorrendo a metodologias ágeis, os riscos associados ao não cumprimento de prazos ou de o resultado final não ser aquilo que era pretendido é muito menor, visto que, como referido anteriormente, existe um acompanhamento muito mais próximo por parte do cliente. O projecto pode ser alterado consoante as necessidades do cliente e isso, dependendo do âmbito do projecto, pode ser uma enorme mais-valia Scrum O Scrum surgiu em 1995, quando Ken Schwaber o definiu e ajudou a implementar em projectos de desenvolvimento de software a nível mundial. Hoje em dia o Scrum assume um papel preponderante no âmbito das metodologias ágeis para desenvolvimento de software, embora em teoria possa ser utilizado em qualquer projecto onde exista um grupo de pessoas a trabalhar para um fim comum (Pries e Quigley, 2011) Papéis do Scrum Em termos de recursos humanos os projectos que utilizam metodologia Scrum estão organizados segundo uma hierarquia definida da seguinte forma: Scrum Master: responsável por manter os processos e organizar e gerir a equipa de desenvolvimento; Product Owner: representa os Stakeholders e é responsável pela elaboração dos requisitos do projecto e pela verificação da sua implementação; Equipa: responsável pela elaboração do projecto. A equipa habitualmente tem cerca de 7 elementos, podendo este número variar consoante o projecto. 5

20 Processo Scrum A Figura 1.3 representa os processos para a elaboração de um projecto seguindo o Scrum. Passa-se a uma breve descrição de cada um desses processos. O Product Backlog é o processo inicial em que o Product Owner enumera os requisitos do projecto com base nas necessidades do cliente. A lista de requisitos é elaborada e priorizada pelo Product Owner, sendo essa a sua principal função. Esta lista será fundamental ao longo de todo o projecto pois é com base nela que os Sprints serão organizados. O Product Backlog é dinâmico, sendo esta uma das grandes vantagens da gestão de projectos segundo metodologias ágeis. Ao contrário da gestão de projectos segundo metodologias clássicas, nos projectos Scrum os requisitos do projecto podem ser alterados ao longo do projecto segundo as necessidades do cliente. Convém salientar que estas constantes alterações só são possíveis em projectos de desenvolvimento de software. No início de cada Sprint é efectuada uma reunião entre todas as partes envolvidas no projecto na qual são escolhidos os itens a desenvolver no Sprint, esta reunião é a Sprint Planning Meeting e tem uma duração máxima de 8 horas. A primeira parte da reunião, com uma duração de 4 horas, consiste numa reunião entre a equipa e o Product Owner em que são escolhidos os itens a realizar no Sprint de modo a que resulte algo que possa ser entregue ao cliente no fim do Sprint. Na segunda parte da Sprint Planning Meeting a equipa planeia o Sprint. Como os elementos da equipa são responsáveis pelo seu trabalho, este planeamento é fundamental para que todos os itens que a equipa se comprometeu a entregar no fim do Sprint sejam efectivamente entregues. A experiência das partes envolvidas no projecto é fundamental neste processo, dado ser necessária uma perfeita gestão do tempo e uma previsão correcta para a duração dos itens a realizar. O resultado final desta reunião que precede o Sprint é o Sprint Backlog, que lista os requisitos do projecto a realizar no Sprint que será iniciado. Cada Sprint corresponde a uma iteração de 30 dias consecutivos, sendo que, no final do Sprint, algo funcional tem de ser entregue ao cliente. Diariamente, no início do dia, é realizada uma reunião de aproximadamente 15 minutos entre a equipa, denominada Daily Scrum, na qual se verifica o trabalho realizado no dia anterior e é planeado o trabalho a realizar nesse dia, analisando os possíveis entraves ao progresso normal do projecto. O objectivo fundamental desta reunião diária é analisar o progresso do projecto, evitando atrasos, assim como estabelecer laços de camaradagem e comportamento colaborativo entre os elementos da equipa. No fim do Sprint é efectuada outra reunião, a Sprint Review Meeting, em que a equipa apresenta os resultados do Sprint ao Product Owner e a outros Stakeholders. Esta reunião informal tem como objectivo analisar o Sprint anterior e começar a planear o Sprint seguinte. O Scrum Master e a equipa reúnem-se uma vez mais, na Sprint Retrospective Meeting onde a equipa é incentivada a analisar o Sprint concluído e tentar melhorar aquilo que for possível, de modo a que o Sprint seguinte corra melhor (Schwaber, 2004; Francisco, 2008). 6

21 Figura Processo Scrum (Schwaber, 2004) Extreme Programming (XP) O XP foi criado por Kent Beck durante a década de 1990 durante o seu trabalho na empresa Chrysler. Embora o XP seja relativamente recente, as suas ideias são comuns em vários projectos há muitos anos. A ideia geral do XP é levar as boas práticas a níveis extremos. Em 1999, Kent Beck publicou o livro Extreme Programming Explained em que descreve o funcionamento do XP (Beck, 1999). No final da década de 1990 e início da década de 2000, o XP teve alguma divulgação, tendo sido utilizado em projectos com âmbitos bastante diferentes daqueles para os quais a metodologia tinha sido idealizada. Tal como o Scrum, também no caso do XP, os projectos de desenvolvimento de software são o alvo preferencial para a aplicação desta metodologia, embora em teoria, com algumas alterações dependentes dos casos, seja possível utilizá-la em projectos noutras áreas (Beck, 1999). 7

22 Papéis do XP Tal como no Scrum, também no caso do XP existem papéis bem definidos para os intervenientes nos projectos. No caso do XP o número de papéis é bastante superior ao existente na metodologia estudada anteriormente (Scrum). Os principais papéis identificados nos projectos em XP são os seguintes: Programador, Cliente, Testador, Gestor, Monitorizador, Treinador e Consultor. Quando os projectos são pequenos um individuo pode ter mais do que um papel no projecto. O Programador tem o papel central no projecto. A sua principal função, como o próprio nome indica, é desenvolver o código. Todavia, no XP o papel do programador é mais importante uma vez que o sucesso ou insucesso do projecto está frequentemente correlacionado com a capacidade do programador ouvir as sugestões do cliente e adaptar-se a elas, ou sugerir alternativas melhor adaptadas ao que o cliente quer. O Cliente tem no XP um papel bastante relevante. Ao contrário do que acontece noutras metodologias (i.e. Scrum), no XP o Cliente tem que estar dedicado a tempo inteiro ao projecto. Um dos papéis do Cliente é elaborar e priorizar os requisitos que o sistema deve satisfazer. Outra responsabilidade do Cliente é tomar as decisões relevantes para o projecto ao longo da realização do mesmo (i.e. tecnologia a utilizar, requisitos a implementar na próxima release ou, caso seja adequado, excluir determinado requisito). No fim do projecto o Cliente tem a função de validar o trabalho efectuado. O Testador, como o próprio nome indica, tem a função de efectuar testes de modo a auxiliar o Cliente na validação do trabalho efectuado, verificando a boa implementação dos requisitos planeados para uma determinada release. O Gestor não tem no XP um papel tão central como em outras metodologias ágeis. Algumas das responsabilidades normalmente associadas ao Gestor do projecto são, no caso do XP, atribuídas ao Cliente ou ao Programador. A principal função do Gestor é gerir as pessoas e auxiliar na resolução dos problemas que vão surgindo. O Gestor é igualmente responsável pela constituição e gestão da equipa e serve de interface entre a equipa envolvida no projecto e todos os interessados. O Monitorizador e o consultor têm um papel mais esporádico no XP. O Monitorizador é apenas necessário para fazer o planeamento das releases. Normalmente, o Monitorizador tem bastante experiência na área e utiliza os seus conhecimentos de projectos passados para fazer uma estimativa correcta para a duração da release, auxiliando deste modo o Programador. O Consultor tem igualmente um papel auxiliar no XP. A sua participação ocorre quando surge um problema que foge à área de conhecimento da equipa. A sua participação no projecto deve ser bem definida e, caso seja possível, deve ser acompanhada por alguém interveniente no projecto de modo a transmitir o máximo de informação possível. 8

23 Por último deve ser realçado o papel do Treinador. O Treinador tem um papel bastante importante no XP: a sua função é aplicar o XP de forma correcta e integral ao longo do projecto. A sua experiência e conhecimento profundo do projecto são aspectos fundamentais para o seu trabalho de auxílio aos programadores quando se deparam com situações de difícil resolução. Embora a sua função seja auxiliar a equipa, é desaconselhado que a sua contribuição seja feita de forma directa, sendo mais indicado que, sempre que possível, tente indicar abordagens para a resolução ao invés de fornecer directamente a solução para o problema (Silva e Videira, 2008) Processo XP O XP, tal como o Scrum, propõe uma abordagem iterativa em que é possível efectuar constantes alterações à medida que o projecto é desenvolvido. Um dos objectivos principais é reduzir drasticamente os custos de alteração de requisitos. Os principais artefactos por trás da metodologia XP são os seguintes: Histórias de utilização, Tarefas, Plano da Release, Plano da Iteração, Código, Testes Unitários e Testes Funcionais. Na Figura 1.4 estão representados os principais conceitos do XP e a relação entre si. Figura Processo XP (Silva e Videira, 2008). As histórias de utilização são escritas pelo cliente de forma simples e fácil de entender pela equipa e representam os itens a realizar ao longo do projecto. Têm um carácter ontológico na medida em que contribuem para uma apropriação partilhada do carácter do projecto. As histórias devem ser divididas pelo cliente de acordo com a sua 9

24 importância para o projecto e pelos programadores de acordo com a estimativa de tempo e risco. A duração de cada história não deve ultrapassar as 2 semanas. Caso isso aconteça, a história de utilização deve ser dividida. As tarefas são descrições do trabalho a realizar de modo a implementar uma determinada história. A duração de cada tarefa pode variar entre 1 e 4 dias e cada história pode dar origem a várias tarefas. No plano da release são apresentadas as histórias de utilização com a respectiva atribuição de esforço e prioridade do ponto de vista do Cliente. A duração de cada release pode variar entre 1 e 4 meses. Em cada iteração a equipa compromete-se a realizar um conjunto de histórias de utilização a que se dá o nome de Plano da Iteração. Tipicamente cada iteração tem uma duração que pode variar entre 1 e 4 semanas. O Código, apesar de ser um termo genérico, no caso do XP, representa não só o código-fonte escrito pelos Programadores como modelos que podem, posteriormente, vir a gerar códigos-fonte. Os testes unitários e os testes funcionais são testes efectuados pelos Programadores e pelos Clientes, respectivamente. Enquanto os testes unitários são efectuados automaticamente com vista a validar partes do código fonte, os testes funcionais são efectuados manualmente pelo Cliente e do seu sucesso depende o sucesso do próprio projecto Outsystems A Metodologia Outsystems segue os princípios das metodologias ágeis já analisadas anteriormente. Um dos principais princípios sobre o qual assenta esta metodologia é o facto de as funcionalidades de uma dada solução terem de ser demonstradas, avaliadas e poderem ser redefinidas à medida que o projecto avança. A fase de análise de requisitos é bastante mais reduzida do que nas metodologias convencionais e o desenvolvimento é efetuado em pequenos ciclos, ao fim dos quais é efetuada uma demonstração aos clientes e utilizadores. Durante a apresentação é efectuada a avaliação pelos utilizadores, do projecto desenvolvido até ao momento e a equipa de desenvolvimento recolhe feedback. Esse feedback é fundamental para que se obtenha uma ideia do valor para o negócio das funcionalidades apresentadas. O facto de este método ser iterativo e apresentar diversas demonstrações ao longo do ciclo do projecto faz com que o resultado final do mesmo seja muito mais próximo das reais necessidades do cliente. Este método iterativo e com diversas demonstrações ao longo do ciclo do projecto faz com o resultado final do mesmo seja muito mais próximo das reais necessidades do cliente. 10

25 Conceitos Para o planeamento e execução de um projecto baseado na metodologia Outsystems existem quatro conceitos fundamentais: Project Backlog: lista de tarefas/requisitos a desenvolver durante o projecto. A lista de tarefas/requisitos é dinâmica e a mesma encontra-se ordenada por grau de prioridade. Em cada iteração, a prioridade pode ser revista em função das necessidades do negócio (tempo, recursos, etc.). Budget: esforço previsto para o projecto, expresso em homem/dia. Um conceito fundamental inerente à metodologia outsystems é o budget. O budget mantém-se constante ao longo do projecto. É fundamental que o custo total da solução seja aquele que foi inicialmente planeado. Sprint: ciclo de tempo limitado (tipicamente 2 a 4 semanas) para a realização de análise, desenvolvimento e teste de uma versão de demonstração incremental da solução. Timebox: período de tempo definido para a duração do projecto, de acordo com o budget homem/dia. Este período é fixo e não pode ser alterado Equipa de projecto De acordo com a metodologia, para o levantamento e análise de requisitos, o acompanhamento do projecto e os testes requerem a participação de elementos do cliente. Resume-se de seguida as responsabilidades dos vários participantes no projecto, tanto dos Intervenientes do Cliente como da Equipa de Desenvolvimento Equipa do cliente Business Sponsor Tipicamente o director / responsável pelo departamento de negócio que solicita a solução e que deverá fazer parte do steering committee 1. Compete-lhe: Delegar poderes e responsabilidades nos seus representantes que participam no projecto, garantindo a disponibilidade desses elementos; 1 Comité decisor 11

26 Sempre que necessário, participar nas reuniões do steering committee e tomar decisões atempadamente de forma a garantir o bom desenrolar do projecto; Business Manager Responsável por parte do cliente pela solução a desenvolver. Compete-lhe: Conduzir a análise de negócio e esclarecer dúvidas relacionados com requisitos negócio; Garantir a participação dos restantes elementos do cliente (utilizadores de negócio, técnicos etc.) identificados como chave nas diferentes fases do projecto; Executar todas as diligências para que as tarefas complementares da responsabilidade dos restantes elementos do cliente sejam executadas a tempo e com a qualidade esperada; Definir e priorizar o âmbito (backlog) do projecto em conjunto com o Engagement Manager da OutSystems inclui a distinção entre defeitos e novas funcionalidades durante a manutenção da solução; Coordenar a comunicação interna entre grupos distintos com a finalidade de oferecer uma interface consistente à equipa de desenvolvimento; Garantir todas as condições iniciais de trabalho para a equipa de desenvolvimento implementar o projecto; Assegurar a disponibilidade dos elementos necessários à realização de todos os testes de aceitação. IT Manager responsável pela infraestrutura de TI 2 necessária ao projecto. Compete-lhe: Garantir o suporte das Infraestruturas necessárias, incluindo ambientes de desenvolvimento, pré- -produção e produção; Garantir o acesso a qualquer sistema do cliente com o qual a equipa de desenvolvimento necessite de integrar para o desenvolvimento da solução; Colaborar com a equipa de desenvolvimento no esclarecimento de dúvidas técnicas. Business User este elemento tem experiência de negócio e vai utilizar a solução diariamente. Compete-lhe: Apoiar durante a análise de negócio e esclarecer dúvidas relacionadas com requisitos negócio; Participar e dar feedback nas sessões de demonstração; Executar testes funcionais para aceitação da solução. Maintenance Responsável pela operação, manutenção e pós-produção da solução. Compete-lhe: Recolher toda a informação e conhecimento necessário à operação e manutenção da solução pósprodução; 2 Tecnologias de Informação 12

27 Trabalhar em conjunto com a equipa de desenvolvimento durante a fase de afinação da solução para preparar a fase de manutenção Equipa de desenvolvimento Engagement Manager (EM) Faz a gestão de cliente e colabora com o Business Manager na análise de negócio e definição do backlog de projecto. Compete-lhe: Analisar o negócio; Assegurar o relacionamento da equipa técnica e de negócio do cliente; Garantir o relacionamento com os clientes internos do projecto e agendar demonstrações e recolha de feedback; Organizar a equipa de desenvolvimento; Gerir o planeamento do projecto; Controlar e gerir o projecto; Reportar regularmente a evolução do projecto aos directores de projecto. Delivery Manager (DM) - Responsável pelo desenvolvimento do projecto. Compete-lhe: Definir a arquitectura técnica da solução, com o apoio do Engagement Manager e do IT Manager; Gerir a equipa de desenvolvimento; Developer Elemento da equipa de desenvolvimento. Compete-lhe: Executar as tarefas de desenvolvimento atribuídas pelo Delivery Manager; Realizar de testes unitários para cada funcionalidade implementada. O Engagement Manager da equipa de desenvolvimento irá apresentar regularmente um Relatório de Progresso. Esta apresentação será realizada através de uma reunião recorrente para este fim onde participam pelo menos o Engagement Manager e o Business Manager. Posteriormente nesta dissertação será apresentado um estudo de caso onde será aplicada a metodologia Outsystems. 13

28 Outras Metodologias Ágeis Embora o Scrum e o Extreme Programming sejam as metodologias ágeis com maior relevância hoje em dia, existem outras que também merecem ser destacadas tais como o Adaptive Software Development (ASD) ou a família de processos Crystal. Uma breve descrição destas duas metodologias será apresentada de seguida Adaptive Software Development (ASD) O ASD foi criado por James A. Highsmith e publicado em Adaptive software development: a collaborative approach to managing complex systems (Highsmith, 2000). Muitos dos princípios do ASD derivaram de outros modelos iterativos desenvolvidos por James Highsmith, sendo o RADical Software Development provavelmente o modelo mais relevante. O ASD baseia o seu processo em três fases distintas: Colaborar, Especular e Aprender. Estas três fases formam um círculo, que as relaciona entre si. Esta relação pode ser observada na Figura 1.5. Colaborar Especular Aprender Figura Processo ASD (adaptado de (Abrahamsson et al., 2002)). A fase de especulação corresponde à fase de planeamento nas outras metodologias. Nesta fase é efectuado um estudo do projecto e é feito o seu planeamento. Ao dar ênfase a este processo pretende-se evitar a incerteza que pode determinar o falhanço do projecto. A denominação escolhida pretende realçar o carácter criativo da actividade, no sentido de poder vir a construir soluções novas. Por outro lado a fase de colaboração vem realçar o papel do trabalho em equipa em qualquer projecto segundo a metodologia ASD. Como o ASD valoriza a possibilidade de alterar o projecto as vezes que forem necessárias, o trabalho em equipa é uma característica que se torna ainda mais importante nestes projectos. 14

29 Por fim a fase de aprendizagem é igualmente fundamental para o sucesso do projecto. Aprender a reagir aos problemas e às alterações é outro factor muito importante para assegurar o sucesso dos projectos. Uma característica importante no ASD é ser orientado para o resultado e para a qualidade do mesmo ao invés de sobrevalorizar as tarefas e o modo como o resultado foi obtido. Ao valorizar a adaptabilidade dos projectos, que podem ser sujeitos a constantes mudanças, aumentam os riscos de insucesso, daí a importância atribuída aos processos referidos anteriormente. Os papéis no ASD não são completamente definidos em Adaptive software development: a collaborative approach to managing complex systems (Highsmith, 2000), todavia é possível distinguir o Executive Sponsor que é responsável pelo desenvolvimento do produto. Outros papéis referidos são os do Facilitator, Scribe, Project Manager e Representantes dos Clientes (Abrahamsson et al., 2002). Um dos grandes entraves ao desenvolvimento e aplicação do ASD, principalmente em projectos grandes e de desenvolvimento estável, é a sua natureza demasiado colaborativa e pouco prescritiva. Existem poucos registos de aplicação do ASD, estando, provavelmente, o seu desenvolvimento estagnado (Abrahamsson et al., 2003;Videira e Silva, 2008) Crystal Crystal é uma família de processos, criada por Alistair Cockburn e descrita em Agile Software Development (Cockburn, 2002)onde pretende, recorrendo à sua experiência profissional, relacionar os processos de modo a suportar a variabilidade dos projectos. O tamanho da equipa e o nível de criticidade do projecto são os factores a ter em conta ao escolher a variante da família Crystal a aplicar. Cada uma dessas variáveis é representada por uma cor consoante o número de pessoas envolvidas no projecto e a dificuldade do mesmo. 15

30 Figura Relação entre a criticidade e o tamanho das equipas em projectos Crystal (Abrahamsson et al., 2002). A Figura 1.6 representa a relação entre o tamanho do projecto e a criticidade do mesmo. De notar que as letras representam o nível de criticidade (Comfort, Discretionary Money, Essential Money, Life) enquanto que os números representam o número de pessoas envolvidas no projecto. Os projectos Crystal são altamente centrados nas pessoas. Para Alistair Cockburn (2002) uma das razões para o insucesso de outras metodologias, como o XP, é a dificuldade que as pessoas têm em seguir um processo disciplinado pelo que propõe no Crystal o mínimo de disciplina possível. Existem algumas regras fundamentais em todas as metodologias da família Crystal. Uma delas é de que todos os projectos utilizam círculos incrementais com duração típica entre 1 e 3 meses. Outra das características do Crystal é permitir a utilização de processos de outras metodologias, tais como o Scrum e o XP, desde que estes sejam vantajosos para o projecto (Cockburn, 2002). Os papéis no Crystal são dependentes da metodologia em uso. No caso do Crystal Clear (projectos relativamente pequenos com equipas até 6 elementos), os papéis principais são: Sponsor, Senior, Senior Designer Programmer, Designer-Programmer e User. Tratando-se de projectos Crystal Orange (projectos com 10 a 40 elementos e com duração entre 1 e 4 anos) os papéis já são diferentes. O número de elementos mais elevado impõe a divisão em várias equipas, entre elas as equipas de System Planning, Project Mentoring, Architecture, Technology, Functions e External Tests. Dentro das equipas os elementos são divididos segundo o papel que têm que desempenhar dentro da mesma. A melhoria do processo é umas das principais preocupações do Crystal, daí que seja recomendado que no fim de cada iteração e no fim do projecto seja realizada uma reunião de revisão de forma a apurar o que correu bem e mal (Silva e Videira, 2008; Cockburn, 2002; Cohen et al., 2004). Informações adicionais sobre o Crystal podem ser consultadas em (Cockburn, 2002; Cohen et al., 2004). 16

31 1.3. Organização da Dissertação A dissertação é composta por quatro capítulos: o o o o Capítulo 1 Introdução, onde se faz o enquadramento do âmbito da dissertação, a organização da mesma e onde se apresenta o estado da arte relativamente à temática em estudo nesta dissertação. Capítulo 2 Gestão Ágil de Desenvolvimento de Software, no qual se analisa um estudo de caso na área de Engenharia Informática aplicando a metodologia Outsystems. Capítulo 3 Gestão Ágil de Projectos de Construção Civil. Neste Capítulo exploram-se os conceitos e princípios do LEAN Thinking e analisa-se um estudo de caso na área de Engenharia Civil. Capítulo 4 Conclusões e Perspectivas Futuras, no qual se apresentam as conclusões retiradas da análise feita aos dois estudos de caso e se tecem considerações acerca de trabalhos futuros. 17

32 18

33 2. Gestão Ágil de Desenvolvimento de Software 2.1. Estudo de Caso de Aplicação da Ferramenta Outsystems Neste capítulo será descrito de forma resumida um estudo de caso real no qual foi aplicada a metodologia Outsystems. Por motivos de confidencialidade e, uma vez que não trariam valor acrescentado ao estudo efetuado, foram omitidos alguns dados referentes ao projecto Descrição do Estudo de Caso O estudo de caso baseia-se num projecto implementado em Julho de 2011 pela empresa Do it Lean, cujo objectivo era o desenvolvimento de uma aplicação informática que melhorasse e acelerasse a transmissão de informação entre as várias entidades envolvidas na gestão e controlo do tráfego aéreo. As entidades envolvidas no projecto em questão são uma companhia aérea, uma empresa de prestação de serviços de handling 3 e a empresa responsável pela gestão das infraestruturas aeroportuárias. Cada voo tem um formulário associado que contem diversas informações acerca do voo, tais como a origem e o destino do voo, a lista de passageiros, entre outras. Os formulários, em papel, eram preenchidos manualmente pelos funcionários da empresa de handling. A aplicação informática desenvolvida permite gerar formulários electrónicos automáticos previamente preenchidos pela companhia aérea com toda a informação relativa ao voo. Na pista, os funcionários da empresa de handling têm computadores nos quais podem aceder aos formulários electrónicos, tendo apenas de verificar a informação previamente preenchida e, caso necessário, completar o formulário com informação adicional. Por fim, a informação compilada nos formulários é transmitida à empresa responsável pela gestão das infraestruturas aeroportuárias. De notar que tipicamente cerca de 90% dos formulários vêm correctamente preenchidos, não sendo necessário efectuar qualquer preenchimento adicional. O preenchimento adicional dos restantes formulários deve-se à ocorrência de anomalias como por exemplo bagagem em falta ou passageiros que perdem o avião ou falham a escala. Diariamente são preenchidos 500 formulários em média. 3 Handling designação inglesa que abrange todos os serviços prestados em terra para apoio às aeronaves, passageiros, bagagem, carga e correio. 19

34 Estudo de Caso Para efectuar a gestão do projecto de desenvolvimento da aplicação apresentada anteriormente, foi utilizado o portal online disponibilizado pela empresa Outsystems Outsystems Network. De seguida serão apresentadas todas as etapas referentes à gestão do projecto assim como a respectiva aplicação na Outsystems Network Sizing De modo a definir uma previsão para a duração do projecto e posteriormente apresentar uma proposta ao cliente, foi efectuado o sizing do projecto. Assim, foram analisados os requisitos do projecto e o tempo estimado de implementação de cada uma das funcionalidades foi previsto de acordo com os padrões mais utilizados na metodologia Outsystems. Mediante a estimativa temporal obtida e o número de recursos disponíveis, consegue-se determinar aproximadamente a duração total do projecto. O sizing é uma parte vital do ciclo de vida do projecto, visto que, caso o sizing seja mal efectuado pode comprometer o projecto. Este deve ser elaborado por um gestor experiente, que tenha bastante sensibilidade para o negócio e para todas as etapas constantes no referido projecto. Na Figura 2.1 apresenta-se parte do sizing do projecto descrito anteriormente assim como resultado do mesmo. 20

35 Figura Exemplo de sizing. Como se pode ver na figura anterior, com a aplicação Outsystems é possível listar todos os requisitos constantes no projecto, fazendo uma estimativa de duração de cada um. O resultado final do sizing é o esforço do projecto (apresentados no canto superior da Figura 2.1, duration). A duração estimada para o projecto, obtida no sizing, irá dar origem à proposta a efectuar ao cliente, tanto em termos de duração do projecto como de custo do mesmo. Caso o sizing tenha sido mal efectuado, o resultado final em termos de custos ou duração do projecto pode ser bastante diferente daquilo que efectivamente acontecerá o que originará graves prejuízos para ambas as partes. A estimativa de duração temporal do projecto na Outsystems Network é baseada em padrões previamente estabelecidos. O gestor de projecto, quando está a elaborar a proposta e a listar os diversos requisitos, estabelece qual o padrão existente que mais se aproxima daquilo que efectivamente será desenvolvido. Por exemplo, analisando a Figura 2.1, no caso do requisito CRUD Perguntas foi definido que este requisito é similar a dois padrões: Web Edit e Business Rule. Desta definição resulta a duração da implementação deste item. Cada requisito tem uma breve descrição, que no caso apresentado foi omitida por razões de confidencialidade. 21

36 Timebox Por timebox entende-se o período de execução do projecto. Na timebox é definida a data de início e de fim do projecto, que é fixa e não deve ser alterada em nenhuma circunstância. Caso as datas não sejam respeitadas ou seja necessário mais tempo para execução do projecto, pode ser negociado um novo projecto para melhorias, porém isso trará custos acrescidos para o cliente. Mais uma vez deve ser realçada a importância de um bom planeamento para a perfeita execução da metodologia ágil aplicada. Uma vantagem inerente às metodologias ágeis é a versatilidade dos projectos assim como dos requisitos dos mesmos. Caso o cliente pretenda alterar algum requisito do projecto durante o desenvolvimento do mesmo, isso é possível. No entanto as datas de início e fim do projecto e dos sprints permanecem inalteradas Sprints Dado que esta metodologia é baseada na metodologia Scrum, o desenvolvimento do projecto é efectuado à base de sprints. O conceito de sprint já foi apresentado e descrito anteriormente aquando da apresentação das metodologias ágeis, sendo que o conceito por trás das metodologias ágeis é efectuar o desenvolvimento dos projectos de forma iterativa, sendo que no final de cada sprint é apresentado/entregue algo ao cliente. Conforme apresentado na Figura 2.2, para o desenvolvimento do projecto foram planeados dois sprints e posteriormente, para implementação da solução desenvolvida foi planeada mais uma iteração. 22

37 Figura Listagem dos sprints. Na opção de listagem de sprints é possível verificar o estado de cada sprint em termos de duração. É possível verificar se o projecto está a decorrer dentro dos prazos previsto e caso isso não esteja a acontecer, tentar rectificar Sprint planning Após a definição do número de sprints a efectuar, distribuem-se os diversos requisitos pelos sprints. Visto que, quando se efectuou o sizing, já foi definida uma duração para cada requisito, após o sprint planning é possível saber a ordem de implementação das funcionalidades, assim como a duração dos sprints. Nesta altura a análise de dependência de funcionalidades é fundamental, visto que é nesta fase que é definida a ordem de implementação das diversas funcionalidades. O sprint planning referente ao projecto em estudo é apresentado na Figura

38 Figura Sprint Planning do projecto. Como se consegue observar na figura acima, o sprint planning permite verificar a duração prevista para cada sprint e se, ao longo do ciclo do projecto, as durações e os respectivos prazos estão a ser respeitados. Consegue-se observar que no caso em estudo, o primeiro sprint se iniciou antes do tempo previsto e acabou no limite previsto. Relativamente ao segundo sprint, o início ocorreu ligeiramente após a data prevista porém a sua conclusão ocorreu antes da data prevista. O sprint relativo à implementação da solução sofreu um desvio bastante acentuado, que pode facilmente ser observado graficamente na Figura 2.3. No caso em estudo, este desvio bastante acentuado deveu-se à resolução de bugs da aplicação e suporte adicional ao cliente. Estes requisitos adicionais, que levaram ao prolongamento do projecto foram solicitados pelo cliente e, portanto, foram negociados separadamente Team leveling Para realizar cada um dos workitems são necessários recursos. A ferramenta Team Leveling permite distribuir os diversos recursos pelos sprints pois, consoante os requisitos a implementar, é necessário aplicar o recurso necessário para a implementação dos mesmos. 24

39 O Team Leveling referente ao projecto em estudo é apresentado na Figura 2.4. Figura Team Leveling. Na figura Figura 2.4 podem ser observadas as funções de cada recurso. A descrição da função de cada recurso foi apresentada no capítulo anterior. Um dado recurso pode estar integrado no projecto com diversos papéis, sendo que durante o dia são alocadas horas a esse recurso consoante o papel que o mesmo tem que desempenhar. Pode ser facilmente observado que os developers são os recursos que estão mais horas alocados ao projecto. Esta é uma situação previsível visto que são os recursos que desenvolvem o software. Existem igualmente recursos que não têm horas alocadas ao projecto, essa situação ocorre principalmente por dois motivos: ou o recurso foi alocado ao projecto para o caso de ser necessário cumprir algum prazo, ou para o caso de se tratar de um utilizador do cliente este poder observar o projecto e como o mesmo se está a desenrolar. Esta abertura e transparência da ferramenta Outsystems é uma grande mais-valia para a mesma. Após ter uma estimativa das horas a efectuar por cada recurso, é mais fácil efectuar uma estimativa do custo do projecto. Habitualmente, para efectuar a proposta ao cliente, o gestor do projecto atribui um certo custo ao recurso, onde já está incluída a margem da empresa, e com base nas horas de trabalho previstas obtém o custo total do projecto. O Team Leveling é uma ferramenta fundamental para a gestão de projectos baseado na metodologia Outsystems pois a mesma permite efectuar a correspondência directa entre os recursos e os sprints, controlando assim a duração/custo do projecto. 25

40 Who does what 4 Após a definição dos recursos alocados a cada sprint, é necessário definir o que cada um desses mesmos recursos vai efectuar. Para tal existe uma ferramenta que permite alocar a cada work item (previamente definido) o recurso que o iá efectuar. Essa mesma correspondência entre work item e recurso pode ser observada na Figura 2.5. Figura Who does What. Nesta ferramenta é possível determinar qual o recurso que vai efectuar e implementar cada work item. Após a conclusão de cada work item, o recurso indica quantas horas despendeu a implementar o mesmo, introduzindo esse valor na penúltima coluna (Actual). Esta etapa do projecto é muito importante, visto que é através dela que se consegue controlar o desenrolar do projecto assim como gerir os diversos recursos do projecto. Esta é a última etapa da gestão do projecto, sendo que se trata de uma ferramenta utilizada diariamente pelos intervenientes no projecto. 4 Who Does What Expressão em inglês para Quem faz o quê. 26

41 Considerações Finais do Caso em Estudo A gestão de um projecto segundo esta metodologia e usando a aplicação Outsystems permite que o processo seja mais fácil e mais célere, uma vez que os recursos envolvidos, por estarem ligados à Internet, têm acesso à informação em tempo real. Eventuais erros provenientes de uma comunicação deficiente são significativamente reduzidos, bem como os custos associados a todo o processo. Em seguida, sumarizamos as principais mais-valias para as empresas intervenientes no projecto devido ao desenvolvimento da aplicação descrita neste caso: Os erros provenientes do preenchimento manual foram virtualmente eliminados; Foi reduzida a intervenção humana no processo em 95%; Foi introduzida a possibilidade de actualizações e correcções de forma imediata; Os resultados obtidos neste caso, recorrendo à metodologia Outsystems, reflectem na perfeição os objectivos das metodologias ágeis. 27

42 28

43 3. Gestão Ágil de Projectos de Construção Civil Os princípios fundamentais das metodologias ágeis não são aplicáveis exclusivamente a projectos de desenvolvimento de software ou de desenvolvimento de produtos. De facto estas metodologias podem ser aplicadas em mais domínios, por exemplo na indústria da construção civil. Com o agravamento substancial das condições de investimento no sector da construção civil nos últimos anos foi necessário encontrar alternativas aos processos até então utilizados de modo a melhorar a sua performance. Embora à primeira vista a aplicabilidade das metodologias ágeis na construção civil seja algo limitada, estudos recentes provam que em certos contextos, as metodologias ágeis, se bem aplicadas, podem ser um factor determinante para o sucesso de um projecto, qualquer que seja o sector. O sector da construção civil está mergulhado numa profunda recessão, com um total de desempregados de aproximadamente 293 mil pessoas, segundo dados do Instituto Nacional de Estatística (INE) referentes ao 2º Trimestre de 2013, o que corresponde a um aumento de 8,4% face ao período homólogo do ano anterior (Estatística, 2013). Estes dados reflectem obviamente o decréscimo na procura de imóveis face à crise económica mundial. Porém, reflectem também um conjunto de más decisões efectuadas pelos responsáveis das empresas e dos projectos. Com a crise económica crescente, a concorrência entre as várias empresas do sector aumentou significativamente, o que resulta numa redução significativa das margens de lucro e das margens de erro. Posto isto, a eficiência dos processos é fulcral para o sucesso de qualquer projecto de construção civil e é nesse campo que as metodologias ágeis podem desempenhar um papel fundamental. Na indústria da construção civil existem problemas que actualmente são encarados como inevitáveis, porém, estudos recentes comprovam que os mesmos podem ser evitados se o projeto for devidamente planeado. O desperdício de materiais e recursos, o atraso na conclusão das obras e o desvio de custos podem ser evitados com o recurso a técnicas de gestão de projectos mais eficientes. Essas metodologias encontram-se ainda pouco divulgadas e são, neste momento, ainda pouco utilizadas. Todavia, a aplicação de metodologias ágeis permite que as empresas tentem rentabilizar os recursos ao máximo e controlem melhor as perdas no processo (Neves, 2010). 29

44 3.1. LEAN Thinking Origem, Princípios e Benefícios A origem da filosofia Lean remonta à década de 1940 no Japão, com o Toyota Production System (TPS). Este sistema implementado pela construtora de automóveis Toyota tinha como principal objetivo melhorar o rendimento da sua produção e assentava nos seguintes princípios: Fornecer valor ao cliente final; Promover um fluxo contínuo; Melhorar constantemente o desempenho; Minimizar desperdícios. A eliminação dos desperdícios na cadeia de produção é um dos pilares onde assenta o TPS. Para isso, Taiichi Ohno, um dos fundadores do TPS, definiu que o sucesso do TPS dependia de dois pilares fundamentais: Sustentabilidade, através da teoria Just in Time (JIT) e a automação através da teoria Jidoka (Womack e Jones, 2003). Sustentabilidade: Just in time (JIT) é uma técnica de gestão implementada no TPS, onde o fornecedor produz exactamente aquilo que o cliente necessita, ou seja, só é produzido o produto correcto na quantidade exacta e no momento certo. Com esta técnica pretende-se reduzir o desperdício inerente à produção em larga escala, que muitas vezes acarreta excesso de stock se o planeamento não for bem efectuado. O sucesso do JIT está obviamente dependente da eficiência da mão-de-obra e dos fornecedores, caso estes sejam pouco eficiente, o sucesso do JIT fica comprometido. Automação: Outra teoria por trás do TPS é a Jidoka, ou automação. Com esta técnica pretende-se transferir alguns processos habitualmente efectuados por humanos para máquinas. Com esta transferência pretende-se que os erros sejam detectados automaticamente pela máquina evitando que o mesmo se propague. Esta técnica permite igualmente que um funcionário possa controlar várias máquinas o que reduz significativamente o custo associado à operação. Estas técnicas tinham como principal objectivo a redução do desperdício inerente à actividade onde as mesmas fossem implementadas (no caso, industria automóvel). Nos anos subsequentes à introdução do TPS surgiram várias dúvidas sobre a sua aplicabilidade noutros contextos ou mesmos noutros países. Vários autores questionaram sobre a aplicabilidade do TPS e das metodologias Lean em outros ambientes e em outras culturas diferentes da Japonesa. Estaria o sucesso do TPS relacionado com a cultura Japonesa ou com o ramo de actividade onde estava a ser aplicado? James Womack tenta responder a essas questões em duas publicações. Em 1991 escreveu o livro The Machine That Changed The World onde introduz o termo Lean Production. Segundo Womack esta filosofia poderia ser 30

45 aplicada a qualquer empresa em qualquer zona geográfica porém o seu sucesso seria superior se fosse aplicado a toda a estrutura da empresa e não apenas à cadeia de produção (Womack et al., 1991). Em 2003, James Womack comparou o desempenho da indústria automóvel Japonesa à indústria alemã (Womack e Jones, 2003) tendo chegado a conclusões muito interessantes: a Toyota conseguia obter melhores resultados que se reflectiam em maior produtividade, menor desperdício e melhor qualidade do produto final utilizando menos recursos do que as empresas alemãs. Apesar de o TPS não ser uma teoria mas sim um conjunto de práticas que permitiam agilizar o processo de produção e melhorar o resultado obtido, foi com base no TPS que James Womack e Daniel Jones desenvolveram os princípios do Lean Thinking e os apresentaram no livro: Lean Thinking: Banish the Waste and Create Wealth in Your Corporation, publicado em 2003 (Womack e Jones, 2003). O Lean Thinking tem como base os seguintes princípios (Womack e Jones, 2003; Nunes, 2010): Especificar o valor No início do processo deve ser definido o valor do produto do ponto de vista do cliente final. A especificação do valor depende da expectativa do cliente para o produto ou serviço a desenvolver. Identificar a cadeia de valor Devem ser identificadas todas as actividades necessárias para desenvolver o produto desde a sua concepção ao lançamento, evitando assim actividades desnecessárias e controlando melhor os timings do processo. Criar fluxo contínuo o processo de produção deve ser continuo evitando interrupções entre as actividades. Devem ser reduzidas as actividades que não acrescentem valor e o foco deve estar no produto e não nas pessoas ou equipamentos. Deixar o cliente puxar o produto o produto só deve ser produzido depois de ter sido encomendado pelo cliente, evitando assim a acumulação de stock desnecessário. Com esta medida pretende-se reduzir o tempo compreendido entre a concepção do produto e a entrega do mesmo ao cliente. Procurar a perfeição este é o princípio fundamental da filosofia Lean. Com a aplicação dos princípios supracitados ficam expostos os desperdícios na cadeia de produção e eliminando-os consegue-se aumentar a eficiência do processo e aproximar o mesmo da perfeição. 31

46 Na Figura 3.1 apresentam-se os principais benefícios resultantes da aplicação da filosofia Lean Thinking. Conhecimento compreensão mais adequada do processo Financieiro diminuição dos custos associados ao processo de produção Principais Benefícios Recursos funcionários com mais formação e mais responsáveis Clientes melhor compreensão das necessidades dos clientes e melhor produto final Qualidade processos com menos erros e mais eficazes Figura Principais benefícios associados à Lean Thinking (adaptado de (Venâncio, 2010)) Desperdício O desperdício é um dos principais pontos onde se foca o TPS. Entende-se como desperdício qualquer actividade que não traga valor acrescentado ao produto e que o torna mais dispendioso. O TPS identifica três tipos de desperdício: muda, mura e muri. Com a redução de desperdícios pretende-se que o cliente obtenha o produto pelo valor mais justo possível, sendo que para isso é necessário reduzir ao máximo os custos associados a processos desnecessários eliminando-os do ciclo de produção. 32

47 Segundo Taiichi Ohno existem sete formas de desperdício que representam 95% em ambiente non-lean (Nunes, 2010; Ohno, 1988). Excesso de produção: consiste em quantidades produzidas em excesso ou produção antecipada de produtos, ou seja, produção efectuada antes de a mesma ser necessária. Com a redução destes dois tipos de excesso de produção pretende-se reduzir significativamente os níveis de stock e evitar a alocação de recursos e matérias-primas a produções que não são necessárias naquele momento. De modo a evitar excesso de produção deve-se recorrer à técnica Just in Time e produzir apenas o produto necessário no momento exacto e utilizando os recursos necessários. Espera: este tipo de desperdício ocorre sempre que o processo de produção é interrompido devido ao atraso de uma ou mais actividades. Este atraso pode estar relacionado com material, ferramentas, informação, etc. Para tentar minimizar o tempo de espera pode-se reduzir a burocracia e unir processos de modo a criar um fluxo contínuo. Transporte: o transporte de material e recursos é um desperdício inevitável no processo de produção, porém o mesmo pode ser minimizado através da reorganização geográfica do processo de modo a criar um fluxo contínuo. Processamento inapropriado: operações extraordinárias, refazer trabalho previamente efectuado, reparar ou retocar trabalho podem ser processos que levam a desperdícios evitáveis na cadeia de produção. A utilização de máquinas demasiado potentes que posteriormente terão de ser rentabilizadas produzindo produto em excesso e originando stock desnecessário é outro desperdício associado ao processamento inapropriado que pode igualmente ser evitado. Para evitar estes desperdícios deve-se identificar correctamente a cadeia de valor no processo de produção e adaptar a produção à mesma. Excesso de inventário: só deve ser produzido o produto que foi efectivamente encomendado pelo cliente. O armazenamento de matéria-prima e de produto final acarreta custos bastante elevados e empata capital que poderia ser utilizado para outros fins mais indicados. Para evitar estes desperdícios deve-se aplicar a técnica Just in Time. Excesso de movimentos: movimentações excessivas de funcionários, matérias-primas, produtos e informação podem atrasar significativamente o processo de produção e entrega do produto ao cliente e originar desperdícios. Posto isto, assim como o desperdício associado ao transporte, também este 33

48 desperdício pode ser evitado, ou pelo menos minimizado, recorrendo a um fluxo contínuo e a uma melhor distribuição geográfica dos recursos. Defeitos: a necessidade de refazer trabalho devido a defeitos no processo de fabrico é outro ponto que pode originar desperdícios que podem ser facilmente evitáveis recorrendo a mecanismos de detecção e alerta de erros. A constante melhoria dos processos e a formação das equipas também reduzem drasticamente os desperdícios associados a defeitos Lean Construction A indústria da construção civil apresenta um enorme potencial para a aplicação de metodologias ágeis, é nesse contexto que surge a Lean Construction. Com base na teoria apresentada por Womack e Jones (Womack e Jones, 2003), a Lean Construction tem como objectivo trazer o Lean Thinking para a indústria da construção civil, possibilitando que esta beneficie de todas as mais-valias e boas práticas inerentes ao Lean Thinking. O principal objectivo da Lean Construction é aumentar significativamente a produtividade de uma indústria pouco eficaz e que, utilizando as teorias do Lean Thinking, pode melhorar consideravelmente o seu rendimento. A introdução das teorias Lean Thinking na indústria da construção civil, tem lugar em 1992, e foi liderada Lauri Koskela (Koskela, 1992). Lauri Koskela levantou questões relativas à aplicação dos fluxos contínuos ou de ser o cliente a puxar pelo produto no âmbito dos projetos de construção civil, entendendo que o potencial de sucesso destas teorias neste tipo de projetos seria bastante elevado se devidamente aplicados. A Lean Construction surgiu não só como uma aplicação directa das teorias Lean, mas procurou ir além disso tentando incorporar outras vertentes tais como a complexidade, a gestão por conversação e a aprendizagem contínua ao longo da vida. Os projectos de construção civil têm características particulares que não podem ser negligenciadas quando se estuda a aplicabilidade de uma teoria de gestão de projetos. Essas particularidades são as seguintes (Koskela, 1992 através de Peneirol, 2007): Natureza única do projecto produto único: cada projeto é original e dimensionado singularmente; Produção afecta a determinado local: o projecto tem que se adaptar à localização onde o mesmo será aplicado; 34

49 Multi-organização de diferentes especialidades e de caracter temporário: a diversidade de especialidades e com muitas funções temporárias traz ao projecto uma variável que o torna mais difícil de gerir. Embora estas características não sejam exclusivas da indústria da construção civil é nesse campo que a comunhão de todas elas se torna mais relevante, em especial a natureza específica do projecto e local onde o mesmo será implementado (Ballard e Howell, 1998). As particularidades da indústria da construção civil têm também uma relação entre si que podem contribuir para o aumento do desperdício e para a perda de valor do produto, embora a sua quantificação seja muito difícil de apurar (Koskela, 2000). As relações entre as particularidades da indústria da construção foram exploradas por Vrijhoef e Koskela em 2005, sendo que as mesmas devem ser minimizadas de modo a tirar o máximo rendimento dos projectos. Para tentar reduzir ao máximo as implicações inerentes às particularidades da indústria da construção tem que existir investimento e um esforço suplementar. Posto isto, é necessário efectuar um balanço da relação custo/benefício de modo a decidir se compensa o esforço extraordinário aplicado (Vrijhoef e Koskela, 2005). Relativamente à Lean Construction esta apresenta as seguintes características (Chitla, 2002): Conjunto claro e definido de objectivos para o processo de fornecimento, com bom entendimento das necessidades e requisitos dos clientes; Equipas de desenho a trabalhar de forma concorrencial de modo a acrescentar mais valor ao projecto; Estruturar devidamente o trabalho de modo a reduzir o desperdício ao longo do ciclo do projecto. Um melhor planeamento melhora significativamente o resultado do projecto. O objectivo primordial da Lean Construction é reduzir significativamente o desperdício que não acrescenta valor ao projecto. 35

50 Na figura Figura 3.2 apresentam-se os benefícios potencialmente obtidos com a redução desse mesmo desperdício. Reduzir o desperdício Organizar a interdependência Melhorar a fiabilidade Reduzir a incerteza Integrar a gestão da produção Figura 3.2 Principais benefícios associados à redução de desperdício. Assim como no Lean Thinking, em 2002 foram enumerados os 11 princípios que se poderiam aplicar à Lean Construction. São eles (Koskela e Howell, 2002 através de Peneirol, 2007): 1. Reduzir ao máximo a quantidade de actividades que não acrescentam valor (desperdício); 2. Aumentar o valor final através da análise sistemática dos requisitos do cliente o cumprimento dos requisitos impostos pelo cliente é um ponto fulcral em qualquer projecto, sendo, no entanto, necessário que os mesmos sejam claros e estejam devidamente identificados; 3. Reduzir a variabilidade, uniformizando ao máximo o produto de modo a reduzir o número de actividades que não acrescentam valor ao produto; 4. Reduzir tempos de ciclo deve-se evitar ao máximo a descentralização na hierarquia organizacional; 5. Reduzir ao máximo o número de passos, partes e ligações; 6. Aumentar a flexibilidade do resultado final, através da modularização dos produtos e da redução da dificuldade de redefinição consegue-se aumentar a flexibilidade do resultado final; 7. Incrementar a transparência do processo ao tornar o processo de construção mais transparente torna-o mais facilmente observável e com isso é mais fácil detectar melhorias no mesmo; 8. Focar o controlo de todo o processo, optimizando o controlo de todo o processo e tendo equipas autónomas com permissão de controlo do processo torna-se mais fácil controlar o processo e atingir as metas estabelecidas; 9. Melhorar continuamente o processo, tentando com isso reduzir o desperdício e desenvolver actividades que tragam valor acrescentado ao processo; 36

51 10. Balancear as melhorias de fluxo com as melhorias no processo de conversão ao ter um melhor fluxo não existe a necessidade de um investimento tão avultado assim como torna mais fácil a implementação de tecnologias de conversão; 11. Benchmark - fazer uma análise SWOT 5 ao processo permite identificar pontos de melhoria e tentar explorar os pontos fortes do mesmo. Conhecer os líderes da indústria e as suas práticas pode igualmente trazer grandes benefícios. Para Lauri Koskela, aplicar o Lean Thinking à indústria da construção civil não implica a transformação da mesma numa indústria similar à da manufactura, mas a correcta aplicação de alguns dos princípios pode trazer enormes mais-valias à indústria da construção civil Construção Convencional vs Lean Construction Com o aumento da dimensão e da complexidade dos projectos, as técnicas utilizadas para gerir os mesmos deixaram de ser tão eficazes. Posto isto, segundo Ballard e Howell existe uma crescente necessidade de controlar a gestão dos processos e não apenas do resultado destes (Ballard e Howell, 1996). Se os processos para a execução de um projecto não estiverem controlados é muito difícil fazer uma verdadeira e fiável medição dos resultados do projecto. Segundo o modelo clássico de gestão de projectos, os objectivos são fixados e os meios para os atingir só são alterados quando existe uma falha no processo que necessita ser recuperada, ou uma solicitação nesse sentido do cliente. Uma lacuna importante no modelo clássico de gestão de projectos é a falta de informação relativa às causas que levaram aos atrasos no cumprimento dos objectivos previamente definidos. A gestão de projectos aplicada actualmente apresenta insuficiências, que se poderão explicar por algumas das seguintes razões (Koskela, 2000): Desconsideração pela incerteza inerente a qualquer projecto; A relação entre as actividades é constantemente considerada simples quando pode ser bastante complexa; Rigidez na consideração do limite das actividades. Muitas vezes o limite é considerado como fixo, quando tal pode não ser verdade; 5 Análise SWOT - Análise das Forças (Strenghts), Fraquezas (Weaknesses), Oportunidades (Oportunities) e Ameaças (Threats). 37

52 Concentração nas actividades individuais, descartando o impacto que cada actividade tem nas restantes actividades. Muitas vezes a melhoria numa actividade pode significar a pioria de outras ou do processo como um todo. A gestão de produção está excluída da gestão de projecto. Segundo a abordagem Lean, é fundamental que uma actividade só seja iniciada caso tudo o que é indispensável para a conclusão da mesma esteja assegurado. Deve-se valorizar uma gestão pró- -activa ao invés de uma gestão reactiva. Actualmente na indústria da construção civil utiliza-se maioritariamente a perspectiva individual da gestão das actividades. Cada actividade é encarada de forma independente das restantes. Esta perspectiva acarreta elevados riscos para o projecto em termos de cumprimento de prazos, pois como referido anteriormente, desprezam-se as relações de interligação entre as actividades que podem provocar atrasos significativos. O fluxo de trabalho contínuo e a tentativa de prever factores que possam levar a atrasos no projecto são pontoschave na filosofia Lean que devem estar sempre presentes. A redução da incerteza no projecto leva a um aumento exponencial da eficiência do mesmo (Koskela, 2000). Na Tabela 3.1 apresentam-se os níveis nos quais podem existir mudanças da gestão convencional para a gestão baseada na filosofia Lean [(Abdelhamid e Salem, 2005) através de (Peneirol, 2007)]. Tabela Comparação entre a Lean Construction e a gestão de projectos convencional [(Abdelhamid e Salem, 2005) através de (Peneirol, 2007)] Gestão Convencional da Construção Sabe-se como TRANSFORMAR materiais em estruturas fixas. É expectável acontecerem mudanças de definições e erros de desenho durante a construção, que serão resolvidos e novamente preparados pela equipa de construção. O gestor é o ÚNICO responsável pelo planeamento. Assume-se que reduzindo o custo de uma peça ir-se-á reduzir o custo de todo o projecto o todo é a soma das partes. Gere-se o processo utilizando os elementos que referem a evolução de custos os quais estão na base dos pagamentos. É-se guiado pelo paradigma de retornos em termos de prazo/custo/qualidade. Lean Construction Sabe-se (também) como TRANSFORMAR materiais em estruturas fixas. Desenha-se produto e processo de construção em conjunto para evitar erros/omissões de desenho e dimensionamento que levantam questões de possibilidade de execução. Tanto os gestores como os encarregados e trabalhadores são responsáveis pelo planeamento. Os gestores são os primeiros responsáveis e os encarregados e trabalhadores são os últimos. Trata-se todo o projecto como um sistema e faz-se uso do Target Costing para alcançar as reduções do custo de projecto o todo é mais que a soma das suas partes. Utiliza-se os elementos de evolução de custos como um input para o planeamento e controlo das operações no estaleiro. Desafia-se o paradigma de retorno em termos de tempo/custo/qualidade ao remover as fontes de desperdício nos processos de desenho/produção de forma a promover um melhor e mais fiável Ffluxo de 38

53 trabalho. Não se planeia ou controla as operações de produção em estaleiro a não ser que se verifique desvios de custo e de prazo espera-se até que os problemas aconteçam para se reagir no sentido de voltar a ter o projecto no rumo definido. Considera-se fornecer valor ao cliente quando se maximiza a performance em relação ao custo perspectiva Value Engineering (VE). Planeia-se e controla-se as operações de produção em estaleiro de forma a evitar que os indicadores de evolução do projecto se desviem dos prazos e custos definidos. Considera-se fornecer valor ao cliente quando o valor do produto é aumentado (a infra-estrutura efectivamente corresponde às necessidades do cliente) através da gestão do processo de valor da construção perspectiva Value-based Management (VBM) Estudo de Casos De modo a tentar determinar as vantagens da aplicação dos ideais da filosofia Lean face às metodologias aplicadas actualmente na indústria da construção civil, apresentam-se neste capítulo alguns exemplos de obras sob as quais foi efetuado um acompanhamento, análise e recolha de dados (Gonçalves, 2009). Esses exemplos de obras serviram de base de trabalho e análise. Os estudos de caso apresentados neste capítulo foram estudados na dissertação de mestrado de Wilma Karina Fernandes Gonçalves (Gonçalves, 2009). Os casos seguidamente apresentados resultam de uma investigação em parceria com uma empresa do sector da construção civil em Portugal, mais precisamente, da avaliação de seis obras adjudicadas à empresa em questão. As obras em análise apresentam diferentes níveis de subcontratação, prazos de execução e volumes de negócio. Novo Pier Norte Construção de salas de embarque e remodelação da plataforma ECO, inserida no Plano de Desenvolvimento do Aeroporto de Lisboa. Igreja Boa Nova Estoril Construção de igreja, centro paroquial, auditório, estacionamento subterrâneo e centro comunitário. Sana Torres Vasco da Gama Royal Hotel Execução da parte estrutural do edifício dividida em fundações e estrutura em elevação. Parque temático Kidzania Construção do parque temático Kidzania no interior de um centro comercial na Amadora. Condomínio Jardim de São Lourenço Execução dos acabamentos do Condomínio Jardim de São Lourenço. Edifício PT Afonso Costa Reabilitação do edifício da PT na Avenida Afonso Costa. 39

54 As obras acima descritas foram analisadas sob cinco aspectos essenciais: Planeamento e Estratégia, Organização de Obra, Sistema de Produção de Gestão de Materiais, Comunicação e Envolvimento dos Colaboradores e Gestão da Construção. A recolha de dados foi feita através de observação directa em estaleiro, realização de inquéritos e análise documental. O propósito da observação directa em estaleiro foi a compreensão dos procedimentos e práticas correntes na obra. Foram observadas a organização do estaleiro, a zona de armazenamento de materiais, o espaço social, a interacção entre os intervenientes da direcção da obra e a organização das frentes de trabalho. Os inquéritos aos intervenientes na direcção de obra tiveram por objetivo apurar a opinião dos mesmos quanto ao sistema de gestão em vigor. Por último, a análise documental, em particular do projecto, planeamento, documentos de controlo de performance e procedimentos da empresa, serviu como base para a caracterização da obra, tendo também sido fundamental para corroborar as informações resultantes da observação directa dos inquéritos efectuados. Após a análise cuidada dos dados recolhidos foram identificados alguns aspectos importantes acerca do funcionamento das obras em questão, bem como de constrangimentos ao funcionamento do processo que constituem potenciais pontos de melhoria. Em todas as obras é efetuado um planeamento inicial, sendo este revisto e ajustado sempre que necessário. A calendarização é feita recorrendo à construção de uma Work Breakdown Structure onde as atividades são apresentadas por especialidades de construção. O planeamento dos trabalhos a efectuar foi identificado pelos intervenientes na direcção de obra como um elemento de elevada importância. No entanto, verificou- -se que este nem sempre é eficaz e que, raramente, o mesmo é cumprido na totalidade à data de controlo definida. O planeamento pode então ser encarado como um ponto de melhoria no qual a aplicação da metodologia Lean poderia trazer benefícios. Uma visualização padronizada do planeamento pode contribuir para que todos os intervenientes na direcção tenham uma melhor percepção do desempenho real. O seguimento visual do desempenho poderia introduzir benefícios como melhor controlo do seguimento das actividades, verificação da eficácia do planeamento, actualização permanente da evolução dos trabalhos, leitura rápida da situação actual e, por comparação com o planeamento inicial, melhor discernimento das actividades merecedoras de maior atenção e maior antecipação de eventuais problemas e condicionamentos. Foram também identificados desperdícios inerentes ao processo de execução de cada empreitada, sendo que, devido às diversas condições de execução e sistemas de gestão em vigor, certos desperdícios assumem maior relevância em certos tipos de obras. Em obras cujo prazo de execução é menor os desperdícios associados à correcção de erros de execução tomam maior importância. Outro desperdício identificado corresponde ao aprovisionamento desnecessário de materiais em estaleiro; no entanto, nas obras com maior disponibilidade de espaço em estaleiro, este tipo de desperdício foi considerado menor. Apesar da variabilidade observada quanto à 40

55 relevância dos desperdícios, certos tipos de desperdício foram identificados como sendo comuns a todas as obras analisadas. Os movimentos e transportes desnecessários ganham importância uma vez que causam perda de tempo e maior desorganização em estaleiro, condicionando também movimentos realmente necessários. Os desperdícios directamente ligados à mão-de-obra, equipamento e material são considerados importantes dado que podem reflectir mau planeamento e má gestão de recursos. Outros exemplos de desperdícios decorrentes de um planeamento insuficiente e de má alocação de recursos estão relacionados com a falha de comunicação interna e a deficiente preparação das tarefas a iniciar (Gonçalves, 2009). Naturalmente, a existência de desperdícios tem impactos negativos, principalmente nos resultados financeiros, cumprimento de prazos e satisfação do cliente. Assim, a sua identificação foi de extrema importância uma vez que os mesmos apresentam possíveis pontos de melhoria. A aplicação da filosofia Lean, que sugere a eliminação dos desperdícios como forma de acrescentar valor ao produto, apresenta-se então, como uma mais-valia para atenuar os constrangimentos ao funcionamento do processo identificado Modelo Proposto Por forma a minimizar ou eliminar, sempre que possível, os problemas decorrentes do método de gestão aplicado nas obras estudadas foi proposto um modelo baseado na ferramenta mapeamento de fluxo de valor e apresenta cinco partes fundamentais: 1. Seleção do produto ou serviço; 2. Desenho do mapa de estado actual do processo; 3. Análise do mapa de estado actual do processo; 4. Desenho do mapa de estado futuro; 5. Implementação e controlo da evolução das melhorias aplicadas. Este modelo tem como principal objectivo introduzir as metodologias Lean que relacionem o empreiteiro principal e os diversos subempreiteiros. A implementação do modelo será efectuada na montagem das caixilharias referentes à obra do Novo Pier Norte, já anteriormente apresentado. Com este modelo pretende-se diminuir ou eliminar os desperdícios, a variabilidade e a inflexibilidade do sistema de gestão, melhorar a comunicação em todos os processos e tornar o fluxo de valor continuo e simplificado. 41

56 Descrição do modelo proposto O mapeamento de fluxo de valor tem por objectivo identificar todas as actividades que ocorrem durante um fluxo de valor. Segundo Don Tapping e Tom Shuker, o fluxo de valor compreende todos os fluxos necessários para produzir valor para o cliente (Tapping e Shuker, 2003). Com base na ferramenta de fluxo de valor foi elaborado o modelo da Figura 3.3. Selecção de produto ou serviço Esquema Top-down Diagrama SIPOC Desenho do mapa de estado actual Fluxo de materiais Fluxo de informação Desenho do mapa de estado futuro Análise do mapa de estado atual Brainstorming Desperdícios, lead time e recomendações Estabilização Padronização Simplificação Implementação e controlo Figura Esquema do modelo proposto (Gonçalves, 2009). De seguida será efectuada uma breve análise a cada um dos pontos propostos no modelo apresentado na Figura

57 Selecção do produto ou serviço A selecção do produto ou serviço a melhorar é uma questão fundamental, visto que mapear todos os produtos é extremamente complexo e difícil. Para determinar os produtos ou serviços com maior potencial de melhoria cria-se um gráfico top-down 6 em que se hierarquiza todas as actividades. No 6 Top-down: em português cima-baixo. 43

58 Anexo A encontra- -se um gráfico top-down do processo de montagem de caixilharia exterior referente à obra em análise (Novo Pier Norte). De seguida procede-se à elaboração de um esquema SIPOC (Suppliers, Inputs, Process, Outputs, Customer) 7, no qual se pretende fazer um levantamento de todos os intervenientes do processo assim como dos elementos básicos do mesmo. Este levantamento é fundamental pois facilita bastante a execução do desenho do mapa de estado actual apresentado de seguida. Um exemplo do esquema SIPOC pode ser igualmente consultado no 7 Suppliers, Inputs, Process, Outputs, Customer: em português fornecedores, variáveis de entrada, processos, variáveis de saída e cliente. 44

59 Anexo A. Desenho do Mapa de Estado Actual O mapa de estado atual permite obter a informação actualizada e real face ao processo e fluxo de valor. Esta informação permite identificar todas as actividades específicas que ocorrem em cada ciclo de valor. Um ponto importante relacionado com o mapa de estado actual é que o responsável pelo mapeamento siga todos os processos de ponta-a-ponta de modo a identificar todas as actividades. Este aspecto é bastante relevante visto que, na maioria dos casos, os intervenientes no processo só têm conhecimentos aprofundados sobre a actividade onde actuam. Após a identificação de todas as actividades constantes no projecto, elabora-se um mapa com o fluxo das mesmas. Para isso enumeram-se as actividades relevantes para cada ciclo de valor e que são descritas da esquerda para a direita seguindo a sequência temporal com que surgem. Um exemplo das actividades do mapa de estado actual pode ser encontrado no 45

60 Anexo A, sendo que somente as actividades destacadas apresentam valor acrescentado para o produto final (Gonçalves, 2009). Elaborado o mapa de estado actual de actividades adiciona-se o fluxo de materiais. Para tal é necessário que no início de cada passo do processo seja efectuado um inventário dos materiais necessários para o mesmo e os materiais sejam transitados de uma actividade para a outra. Tão importante como o fluxo de actividades e o fluxo de materiais é o fluxo de informação. Para que o processo funcione é fundamental que a informação circule e transite entre os vários intervenientes. É fundamental implementar um fluxo de informação escrito e oral de modo a que nenhuma informação se perca. Em actividades que funcionam por turnos ou nas quais o trabalho seja muito dinâmico, estes fluxos de informação ganham uma relevância ainda maior. É também necessário adicionar ao mapa de estado actual o máximo de informação possível, que possa ser útil para os restantes intervenientes no processo. Dados de inventário, número de operários, quantidade de material transportada, são apenas alguns exemplos de informação que deve ser adicionada ao mapa de estado actual através da adição de caixas de dados. Outro constrangimento inerente a qualquer projecto é o tempo. Para controlar o tempo de realização de cada actividade pode ser colocado por baixo do mapa de estado actual o tempo padrão para realização da actividade e o tempo que foi efectivamente consumido. Com esta ferramenta é possível verificar se o tempo estimado para a realização de uma dada actividade está a ser cumprido ou não. Análise do Mapa de Estado Actual A grande vantagem da elaboração do mapa de estado actual, onde é representado todo o processo end-to- -end, é verificar os desperdícios presentes no processo assim como - e mais importante ainda - a fonte dos mesmos. Exemplos de desperdícios facilmente identificáveis são: sobreprodução, movimentações desnecessárias, tempos de espera, interrupções do fluxo. Para tentar identificar os desperdícios presentes e a solução para os mesmos, efectuam-se sessões de brainstorming entre toda a equipa. No caso do projecto de construção de caixilharia foram encontrados vários desperdícios. Por exemplo, quando é entregue uma nova peça de vidro a mesma não vem referenciada. Caso a peça fosse entregue com a referência do local exacto de aplicação ao invés de ser entregue aleatoriamente, evitar-se-iam desperdícios de tempo. Desenho do Mapa de Estado Futuro São três as ideias fundamentais na elaboração do mapa de estado futuro: estabilização, padronização e simplificação. O mapeamento por si só não é sinónimo de sucesso, permite apenas visualizar o processo de uma ponta a outra e identificar as potenciais melhorias. 46

61 o Estabilização Com esta ideia pretende-se estabilizar a procura e fornecimento do produto ou serviço. É fundamental conhecer bem as capacidades da empresa de modo a que a mesma possa satisfazer as necessidades dos clientes. Os pedidos dos clientes tornam-se estáveis à medida que os clientes têm confiança na empresa e nos prazos apresentados. Na estabilização inclui-se o conceito de inventário de segurança, permitindo assim que a produção seja estável e não sofra interrupções (Vrijhoef e Koskela, 2005). A ferramenta Last Planner System ganha uma notoriedade acrescida na estabilização. Com esta ferramenta pretende-se efectuar um planeamento semanal detalhado, sendo que, no fim de cada semana analisam-se os resultados e calcula-se a percentagem de plano concluído (PPC). Caso o mesmo seja inferior a 100% analisam-se as causas que provocaram esse desvio e tentam encontrar-se soluções para tal. É também importante precaver quaisquer imprevistos que possam acontecer, planeando acções a efectuar quando determinada situação acontece. O objectivo primordial desta ferramenta é evitar a todo o custo interrupções no fluxo de produção (Peneirol, 2007). o Padronização Com a padronização pretende-se manter o fluxo de produção continuo. Se todos aqueles que estão envolvidos na cadeia de produção efectuarem as acções da mesma forma, conseguem-se melhorias significativas na qualidade do fluxo e do processo, optimizam-se os recursos disponíveis e evitam-se problemas de danificação do material e necessidade de mais espaço de armazenamento. A utilização do sistema Pull permite que a movimentação de uma dada matéria de uma actividade para a outra seja desencadeada pela actividade receptora somente quando necessita. Com este sistema evitam-se stocks desnecessários. Em comunhão com este sistema é importante utilizar um sistema de calendarização da execução do trabalho e das entradas e saídas do armazém. Assim, é possível escalonar o trabalho a efectuar e evitar desperdícios. A padronização permite que um dado material seja utilizado em diversas etapas do processo de produção, evitando assim múltiplas referências que podem provocar atrasos no processo. Permite igualmente simplificar a formação de novos intervenientes e melhorar a produtividade, qualidade e segurança do processo. o Simplificação Após as etapas de estabilização e padronização, deve-se simplificar ao máximo os processos e os seus fluxos através de uma melhoria contínua dos mesmos. 47

62 Esta etapa é bastante importante visto que existe uma tendência para que, com o tempo, exista uma regressão na eficiência dos métodos a utilizar. É necessário existir um esforço entre todos os intervenientes para que não se acomodem e procurem sempre melhorar o processo a utilizar. Um exemplo do mapa de estado de futuro, após terem sido aplicadas as várias etapas pode ser encontrado no 48

63 Anexo A. Implementação e controlo Após a aplicação de todas as técnicas explicadas anteriormente, é necessário efectuar um acompanhamento do processo com vista a adaptá-lo no caso de surgirem novas ideias ou entraves. A utilização de benchmarks pode ser uma ferramenta bastante útil, uma vez que permite um devido controlo do processo de produção e a comparação do mesmo com outros processos ou mesmo com o processo utilizado anteriormente. Indicadores relevantes a analisar em benchmarks são, por exemplo: satisfação do cliente, produtividade, custo, tempo de execução, entre outros. Para além da utilização de benchmarks é importante estar sempre alerta para potenciais oportunidades de melhoria do processo, assim como analisar as melhorias obtidas com a implementação do mesmo de modo a expandi-las para outras áreas de actividade Implementação do modelo, resultados e análise A implementação do modelo proposto não foi possível no seu todo devido a alguns impedimentos como a limitação do tempo de implementação, a natureza dos trabalhos e as condições fornecidas para a sua implementação. Foram então introduzidas duas das ferramentas propostas, o Last Planner System e a Gestão Visual, já que estas abrangem todo o processo e permitem efectuar um controlo geral da produção. A ferramenta Last Planner System compreende não só o planeamento semanal como um planeamento a médio prazo. Foram efectuadas reuniões semanais em obra com a presença e colaboração do encarregado e de um dos engenheiros responsáveis, nas quais se procedia à análise do ponto de situação e à verificação das condições fornecidas pelo cliente isto porque muitas vezes os requisitos do cliente vão sendo ajustados ao longo do processo e dos recursos disponíveis para o cumprimento das mesmas. O planeamento de actividades para a semana seguinte e as condicionantes para o seu início eram também definidos na reunião, sendo também analisadas as causas do não cumprimento das actividades planeadas para a semana em análise. O acompanhamento da aplicação desta ferramenta foi feito durante seis semanas nas quais foi calculado a Percentagem de Planeamento Concluído (PPC) - um indicador de controlo do desempenho da produção. O valor médio apurado de PPC foi de 59%, tendo os resultados das semanas finais sido bastante superiores aos das duas 49

64 primeiras semanas, o que pode ser explicado, entre outras razões, por um planeamento mais ajustado à realidade após a fase inicial de adaptação ao modelo. Foi também verificada a não existência de uma relação directa entre o número de actividades e o valor de PPC, o que se deveu a uma boa coordenação e alocação dos recursos afectos às actividades planeadas. As causas para o não cumprimento das actividades planeadas foram maioritariamente associadas à indisponibilidade dos requisitos necessários ao início da actividade. A aplicação do Last Planner System foi iniciada aquando do começo dos trabalhos, permitindo aferir problemas que poderiam comprometer o planeamento de execução restante. A análise dos planeamentos semanais e das causas do não cumprimento do planeamento é também vantajosa para o apuramento de responsabilidades, de negociação de novos prazos de entrega e condições de trabalho com o cliente. Ainda que a aplicação desta ferramenta tenha trazido vantagens para a cadeia de produção, foi inicialmente vista negativamente pelos trabalhadores, cuja resistência à mudança criou uma limitação ao seu sucesso. O uso da Gestão Visual foi conseguido através da colocação de um quadro no espaço do estaleiro, visível para todos os trabalhadores, actualizado diariamente e com controlo semanal. A informação presente no quadro permitiu um melhor controlo de execução melhor percepção das actividades executadas e das actividades seguintes - bem como a contabilização da produção média diária das equipas. O planeamento semanal e a produtividade das equipas podem, então, ser melhor calculados e ajustados com o auxílio desta ferramenta. De notar que um melhor conhecimento da produtividade das equipas permite prever com maior precisão a data de conclusão dos trabalhos. A Gestão Visual teve uma grande receptividade por parte dos trabalhadores tendo sido bastante utilizado, sendo as suas vantagens reconhecidas pelos funcionários (Gonçalves, 2009) Considerações Finais Após uma cuidada análise do caso apresentado é possível afirmar que a filosofia Lean constitui um aspecto inovador no sector da construção civil, uma vez que permite tornar projectos mais competitivos devido à sua potencialidade de redução de custos e aumento da satisfação do cliente. Isto é conseguido através da redução de desperdícios, melhoria da qualidade dos produtos e garantia de entrega dentro dos prazos estipulados. Um outro factor importante é a possibilidade de visualização das perdas e das oportunidades de melhoria do sistema produtivo o foco é o processo no seu todo (optimização dos fluxos de produção) ao invés de apenas nas operações de conversão (optimização localizada). A possibilidade de aplicação da filosofia Lean à indústria da construção civil, tirando partido da simplicidade de aplicação das suas ferramentas a uma indústria complexa, indicia boas perspectivas no que toca à aplicação desta 50

65 mesma filosofia a outros campos/indústrias, também eles complexos, nomeadamente na Engenharia Electrotécnica. 51

66 4. Conclusões e Perspectivas Futuras 4.1. Conclusões Nesta dissertação pretendeu-se estudar e verificar a aplicabilidade das metodologias ágeis a diferentes campos da engenharia. Uma vez que o foco do trabalho esteve na engenharia informática e na engenharia civil, foram identificadas, para cada uma das áreas, boas práticas que conduziram ao aumento do rendimento do projecto. De seguida é apresentado um breve resumo das boas práticas identificadas para cada um dos campos estudados. Engenharia Informática: o Entregas periódicas do produto ao cliente entregas periódicas e demonstrações dos resultados intermédios levam a um resultado final com melhor qualidade, visto que, durante as diversas iterações o projecto é adaptado às necessidades do cliente; o Inclusão de elementos do cliente no projecto ao incluir elementos do cliente no projecto pode ser uma grande mais-valia, visto que, esses elementos têm uma maior sensibilidade do âmbito do projecto, assim como do resultado final pretendido com o mesmo; o Planeamento e definição descriminada dos requisitos a implementar ao determinar quais os requisitos que são necessários implementar e qual a duração da implementação dos mesmos, é possível determinar com maior rigor a duração do projecto e custo do mesmo; o Utilização de plataformas online para gerir o projecto a utilização de uma aplicação com base online para efectuar a gestão do projecto permite que todos os intervenientes do projecto consigam consultar e interagir com a plataforma independentemente do local onde se encontram; o Prazos definidos e inalteráveis a introdução de prazos rigorosos que não podem ser alterados permite que o cliente se sinta mais confortável com o projecto e com o sucesso do mesmo; o Pontos de situação periódicos entre a equipa do projecto reuniões (de preferência) diárias incluindo toda a equipa que está a desenvolver o projecto pode trazer enormes mais-valias, pois permite que toda a equipa esteja em sintonia relativamente ao desenvolvimento do projecto; o Definição clara do papel de cada elemento a definição do papel a desempenhar por cada elemento do projecto e a adequada distribuição dos vários requisitos a desenvolver é uma parte fundamental do projecto. 52

67 Engenharia Civil: o Redução ao máximo do desperdício devem-se excluir todas as actividades que não tragam valor acrescentado ao projecto; o Aumento da transparência do projecto tornar o processo mais transparente, torna-o mais facilmente observável, sendo mais fácil observar possíveis melhorias do mesmo; o Pontos de situação periódicos entre a equipa do projecto; o Implementação de um método de contabilização da percentagem de projecto realizado com este indicador é possível verificar se o projecto está a decorrer conforme esperado e caso isso não esteja a acontecer, efectuar os ajustes necessários; o Disponibilização do estado do projecto a todos intervenientes no mesmo ao colocar num local visível para todos o ponto de situação em que a implementação do projecto se encontra, permite que todos os intervenientes no projecto tenham a mesma informação, aumentando assim a sintonia entre todos. Acontece que um dos principais objectivos deste trabalho era verificar a aplicabilidade das boas práticas identificadas nos casos estudados à Engenharia Electrotécnica. Para esse efeito, foi elaborada a Tabela 4.1 Tabela 4.1, onde estão listadas as boas práticas identificadas e a que áreas as mesmas podem ser aplicadas. Tabela 4.1 Aplicabilidade à Engª Electrotécnica das boas práticas identificadas. Boa Prática Aplicabilidade Engª Informática Engª Civil Engª Electrotécnica Entregas periódicas do produto ao cliente Inclusão de elementos do cliente no projecto Planeamento e definição descriminada dos requisitos a implementar Utilização de plataformas online para gerir o projecto Prazos definidos e inalteráveis Pontos de situação periódicos entre a equipa do projecto Definição clara do papel de cada elemento Redução ao máximo do desperdício Aumento da transparência do projecto 53

68 Implementação de um método de contabilização da percentagem de projecto realizado Disponibilização do estado do projecto a todos intervenientes no mesmo Conforme pode ser observado na Tabela 4.1, para a totalidade das boas práticas identificadas, não existem, aparentemente constrangimentos que indiquem que as mesmas não possam ser aplicadas a projectos de Engenharia Electrotécnica. Como tal, pode concluir-se que as mesmas são aplicáveis a projectos no âmbito da Engenharia Electrotécnica, podendo ter que ser ligeiramente adaptadas se o projecto assim o exigir. Mas o factor adaptação a cada caso é um factor sempre presente na gestão projectos onde cada projecto e o respectivo contexto prefiguram identidades específicas. As boas práticas identificadas anteriormente podem ser aplicadas em todo o tipo de projectos no âmbito da engenharia electrotécnica, tais como: Planeamento e dimensionamento de um projecto de implementação de uma rede de telecomunicações a elaboração do projecto para efetuar o planeamento e dimensionamento de uma rede de telecomunicações pode facilmente ser concebido, recorrendo a algumas das boas práticas identificadas na Tabela 4.1. Efectuar reuniões periódicas com o cliente, definir claramente o papel de cada interveniente no projecto, efectuar reuniões periódicas entre os elementos do projecto, definir prazos inalteráveis, disponibilizar o estado do projecto a todos os intervenientes e utilizar ferramentas online para gerir o projecto são alguns exemplos de boas praticas que podem ser aplicadas neste projecto específico. Implementação de uma rede de telecomunicações um projecto para implementação de uma rede de telecomunicações, também pode ser efectuado recorrendo a metodologias ágeis de gestão de projectos e às boas práticas apresentadas acima. Entregas periódicas do produto ao cliente, efectuar reuniões periódicas com o cliente, definir claramente o papel de cada interveniente no projecto, efectuar reuniões periódicas entre os elementos do projecto, definir prazos inalteráveis, reduzir ao máximo o desperdício, disponibilizar o estado do projecto a todos os intervenientes e utilizar ferramentas online para gerir o projecto são alguns exemplos de boas praticas que podem ser aplicadas neste projecto específico. 54

69 Introdução de uma nova tecnologia na rede móvel um projecto para implementação de uma nova tecnologia na rede móvel (i.e. LTE-Advanced 8 ), pode igualmente ser efectuado através de metodologias ágeis. Se, ao invés de implementar a tecnologia em toda a área coberta por um dado operador, implementar de forma faseada geograficamente e obtendo feedback por parte do cliente à medida que o processo avança, está-se a aplicar os proncipios das metodologias ágeis. Entregas periódicas do produto ao cliente, efectuar reuniões periódicas com o cliente, definir claramente o papel de cada interveniente no projecto, efectuar reuniões periódicas entre os elementos do projecto, implementar um método de contabilização da percentagem de projecto realizado, definir prazos inalteráveis, reduzir ao máximo o desperdício, disponibilizar o estado do projecto a todos os intervenientes e utilizar ferramentas online para gerir o projecto são alguns exemplos de boas praticas que podem ser aplicadas neste projecto específico. Concluindo, a aplicação de metodologias ágeis a projectos de engenharia electrotécnica pode ser uma grande maisvalia para os mesmos e para os seus intervenientes. As metodologias ágeis e a sua adequada aplicação, permitem reduzir de uma forma substancial a duração dos projectos e consequentemente os custos dos mesmos Perspectivas Futuras Como trabalho futuro, propõe-se a aplicação das boas práticas identificadas nesta dissertação em casos práticos reais no âmbito da Engenharia Electrotécnica. Essa aplicação permitiria quantificar o resultado da aplicação das boas práticas identificadas aos projectos em questão. Pode ser igualmente explorada em trabalhos futuros a identificação de outras boas práticas utilizadas em projectos desenvolvidos recorrendo a metodologias ágeis, em diferentes ramos da engenharia, tais como a Engenharia Mecânica, Engenharia Aeroespacial, Engenharia Química ou Engenharia Biológica. 8 LTE-Advanced (Long Term Evolution Advanced) evolução da tecnologia de transmissão de dados LTE. 55

70 Bibliografia Abdelhamid, T. and Salem, O. Lean Construction: A New Paradigm for Managing Construction Projects. Cairo, Egipto. : The International Workshop on Innovations in Materials and Design of Civil Infrastructure, Abrahamsson, Pekka ; Outi, Salo; Ronkainen, Jussi; Warsta, Juhani Agile software development methods: Review and analysis. s.l. : VTT Publications, Abrahamsson, Pekka; Warsta, Juhani; Siponen, Mikko T.; Ronkainen, Jussi New Directions on Agile Methods. IEEE Agile Alliance. Agile Alliance: The Twelve Principles of Agile Software. [Online] [Citação: 9 de Outubro de 2013.] Ballard, G. and Howell, G. Can Project Controls Do Its Job? Birmingham, Reino Unido : Proc. 4th annual IGLC Conference, Ballard, G. and Howell, G. What Kind of Production is Construction? Guarujá, Brasil : Proc. 6th Ann. Conf. of the Int l. Group for Lean Constr., IGLC-6. Beck, Kent. Extreme programming explained: embrace change. s.l. : Addison-Wesley, Chitla, V. Performance Assessment Of Planning Processes During Manufactured Housing Production Operations Using Lean Production Principles. s.l. : Master Thesis, Cockburn, Alistair. Agile Software Development. s.l. : Addison-Wesley, Cohen, David, Lindvall, Mikael and Costa, Patricia. An Introduction to Agile Methods. ADVANCES IN COMPUTERS,. 2004, Vol. 62. Estatística, Instituto Nacional de. Estatísticas do Emprego - 2º Trimestre de Lisboa : Instituto Nacional de Estatística, Francisco, Rui Miguel Ferreira. Ferramenta de Gestão de Processos de Desenvolvimento, Tese de mestrado. s.l. : Instituto Superior Técnico, Gonçalves, Wilma Karina Fernandes. Utilização de Técnicas Lean e Just in Time na Gestão de Empreendimentos e Obras, Dissertação de mestrado. Lisboa : Instituto Superior Técnico, Highsmith, James A. Adaptive software development: a collaborative approach to managing complex systems. s.l. : Dorset House, Koskela, L. An exploration towards a production theory and its application to construction. Espoo, Finland : Technical Research Center of Finland, Koskela, L. and Howell, G. The Underlying Theory of Project Management is Obsolete. Pag : Proceedings of the PMI Research Conference,

71 Koskela, L. Application of the new production philosophy to construction. Center for Integrated Facility Engineering. Department of Civil Engineering : Stanford University, Neves, Andreia Luisa Henriques Costa dos Santos. Agilidade e Lean Construction - Metodologia de Planeamento e Controlo da Produção baseada na integração de práticas ágeis com a filosofia Lean, Tese de mestrado. s.l. : Instituto Superior Técnico, Nunes, Iara Jussara Diogo. Aplicação de ferramentas lean no planeamento de obras, Dissertação de mestrado. Lisboa : Instituto Superior Técnico, Ohno, Taiichi. Toyota Production System: Beyond Large-Scale Production. s.l. : Productivity Press, Peneirol, Nelson Luís Sampaio. Lean Construction em Portugal: Caso de estudo de implementação de sistema de controlo da produção Last Planner, Dissertação de Mestrado. Lisboa : Instituto Superior Técnico, Pries, Kim H. and Quigley, Jon M. Scrum Project Management. s.l. : CRC Press, Schwaber, Ken. Agile Project Management with Scrum. s.l. : Microsoft Press, Silva, Alberto and Videira, Carlos. UML Metodologias e Ferramentas CASE. s.l. : Centro Atlantico, Tapping, Don and Shuker, Tom. Value Stream Management for the Lean Office. New York, USA : Productivity Press, Venâncio, Ana Catarina Gonçalves. Metodologia de Planeamento e Controlo da Produção baseada na integração de práticas ágeis com a filosofia Lean. Lisboa : Instituto Superior Técnico, Vrijhoef, R. and Koskela, L. Revisiting the Three Peculiarities of Production in Construction. Sydney, Australia : Proceeding of IGLC 13 Conference, Womack, James P. and Jones, Daniel T. Lean Thinking. Londres : Free Press Business Management, Womack, James P. and Jones, Daniel T. Lean Thinking: Banish the Waste and Create Wealth in Your Corporation. Londres : Free Press Business Management, Womack, James P., Jones, Daniel T. and Roos, Daniel. The Machine That Changed the World: The story of Lean Production. s.l. : HarperCollins,

72 58

73 Anexo A Figura Esquema top-down referente à montagem de caixilharia (Gonçalves, 2009). 59

74 60 Figura 5.2 Exemplo de esquema SIPOC simplificado (Gonçalves, 2009).

75 Figura Exemplo de actividades de um mapa de estado actual (Gonçalves, 2009). Figura Exemplo de actividades de um mapa de estado futuro (Gonçalves, 2009) 61

Manifesto Ágil - Princípios

Manifesto Ágil - Princípios Manifesto Ágil - Princípios Indivíduos e interações são mais importantes que processos e ferramentas. Software funcionando é mais importante do que documentação completa e detalhada. Colaboração com o

Leia mais

Metodologias Ágeis. Aécio Costa

Metodologias Ágeis. Aécio Costa Metodologias Ágeis Aécio Costa Metodologias Ágeis Problema: Processo de desenvolvimento de Software Imprevisível e complicado. Empírico: Aceita imprevisibilidade, porém tem mecanismos de ação corretiva.

Leia mais

Engenharia de Software I

Engenharia de Software I Engenharia de Software I Curso de Sistemas de Informação Karla Donato Fook karladf@ifma.edu.br DESU / DAI 2015 Desenvolvimento Rápido de Software 2 1 Para quê o Desenvolvimento Rápido de Software? Os negócios

Leia mais

METODOLOGIA ÁGIL. Lílian Simão Oliveira

METODOLOGIA ÁGIL. Lílian Simão Oliveira METODOLOGIA ÁGIL Lílian Simão Oliveira Fonte: Pressman, 2004 Aulas Prof. Auxiliadora Freire e Sabrina Schürhaus Alexandre Amorin Por quê???? Principais Causas Uso das Funcionalidades Processos empírico

Leia mais

Guia Projectlab para Métodos Agéis

Guia Projectlab para Métodos Agéis Guia Projectlab para Métodos Agéis GUIA PROJECTLAB PARA MÉTODOS ÁGEIS 2 Índice Introdução O que são métodos ágeis Breve histórico sobre métodos ágeis 03 04 04 Tipos de projetos que se beneficiam com métodos

Leia mais

Scrum. Introdução UFRPE-DEINFO BSI-FÁBRICA DE SOFTWARE

Scrum. Introdução UFRPE-DEINFO BSI-FÁBRICA DE SOFTWARE Scrum Introdução UFRPE-DEINFO BSI-FÁBRICA DE SOFTWARE scrum Ken Schwaber - Jeff Sutherland http://www.scrumalliance.org/ Scrum Uma forma ágil de gerenciar projetos. Uma abordagem baseada em equipes autoorganizadas.

Leia mais

Universidade Federal do Espírito Santo Centro Tecnológico Departamento de Informática Programa de Pós-Graduação em Informática

Universidade Federal do Espírito Santo Centro Tecnológico Departamento de Informática Programa de Pós-Graduação em Informática Universidade Federal do Espírito Santo Centro Tecnológico Departamento de Informática Programa de Pós-Graduação em Informática Disciplina: INF5008 Prof.: (monalessa@inf.ufes.br) Conteúdo 8. Metodologias

Leia mais

SCRUM. Fabrício Sousa fabbricio7@yahoo.com.br

SCRUM. Fabrício Sousa fabbricio7@yahoo.com.br SCRUM Fabrício Sousa fabbricio7@yahoo.com.br Introdução 2 2001 Encontro onde profissionais e acadêmicos da área de desenvolvimento de software de mostraram seu descontentamento com a maneira com que os

Leia mais

Desenvolvimento Ágil de Software

Desenvolvimento Ágil de Software Desenvolvimento Ágil de Software Métodos ágeis (Sommerville) As empresas operam em um ambiente global, com mudanças rápidas. Softwares fazem parte de quase todas as operações de negócios. O desenvolvimento

Leia mais

Processo de Desenvolvimento de Software. Unidade V Modelagem de PDS. Luiz Leão luizleao@gmail.com http://www.luizleao.com

Processo de Desenvolvimento de Software. Unidade V Modelagem de PDS. Luiz Leão luizleao@gmail.com http://www.luizleao.com Processo de Desenvolvimento de Software Luiz Leão luizleao@gmail.com http://www.luizleao.com Conteúdo Programático desta aula Modelo Cascata (Waterfall) ou TOP DOWN. Modelo Iterativo. Metodologia Ágil.

Leia mais

METODOLOGIA DE GERENCIAMENTO DE PROJETOS SCRUM: ESTUDO DE REVISÃO. Bruno Edgar Fuhr 1

METODOLOGIA DE GERENCIAMENTO DE PROJETOS SCRUM: ESTUDO DE REVISÃO. Bruno Edgar Fuhr 1 METODOLOGIA DE GERENCIAMENTO DE PROJETOS SCRUM: ESTUDO DE REVISÃO Bruno Edgar Fuhr 1 Resumo: O atual mercado de sistemas informatizados exige das empresas de desenvolvimento, um produto que tenha ao mesmo

Leia mais

RESUMO PARA O EXAME PSM I

RESUMO PARA O EXAME PSM I RESUMO PARA O EXAME PSM I Escrito por: Larah Vidotti Blog técnico: Linkedin: http://br.linkedin.com/in/larahvidotti MSN: larah_bit@hotmail.com Referências:... 2 O Scrum... 2 Papéis... 3 Product Owner (PO)...

Leia mais

UNIVERSIDADE ESTADUAL DE CAMPINAS - UNICAMP FACULDADE DE TECNOLOGIA - FT GUSTAVO ARCERITO MARIVALDO FELIPE DE MELO

UNIVERSIDADE ESTADUAL DE CAMPINAS - UNICAMP FACULDADE DE TECNOLOGIA - FT GUSTAVO ARCERITO MARIVALDO FELIPE DE MELO UNIVERSIDADE ESTADUAL DE CAMPINAS - UNICAMP FACULDADE DE TECNOLOGIA - FT GUSTAVO ARCERITO MARIVALDO FELIPE DE MELO Análise da Metodologia Ágil SCRUM no desenvolvimento de software para o agronegócio Limeira

Leia mais

Engenharia de Software I. Aula 15: Metodologias Ágeis. Prof. Márcio D. Puntel marcio@puntel.org

Engenharia de Software I. Aula 15: Metodologias Ágeis. Prof. Márcio D. Puntel marcio@puntel.org Engenharia de Software I Aula 15: Metodologias Ágeis Prof. Márcio D. Puntel marcio@puntel.org Março - 2008 Antes... Manifesto Mudança de contratos Foco nas premissas... 2 Algumas metodologias Extreme Programming

Leia mais

Ágil. Rápido. Métodos Ágeis em Engenharia de Software. Introdução. Thiago do Nascimento Ferreira. Introdução. Introdução. Introdução.

Ágil. Rápido. Métodos Ágeis em Engenharia de Software. Introdução. Thiago do Nascimento Ferreira. Introdução. Introdução. Introdução. Introdução Métodos Ágeis em Engenharia de Software Thiago do Nascimento Ferreira Desenvolvimento de software é imprevisível e complicado; Empresas operam em ambiente global com mudanças rápidas; Reconhecer

Leia mais

Scrum How it works. Há quatro grupos com papéis bem definidos:

Scrum How it works. Há quatro grupos com papéis bem definidos: Scrum É um processo de desenvolvimento iterativo e incremental. É utilizado quando não se consegue predizer tudo o que irá ocorrer. Em geral, utiliza-se em projetos complexos, de difícil abordagem pela

Leia mais

Gestão de Projectos. Processos e Aproximações de Desenvolvimento de Projectos. Informáticos. Selecção da Aproximação de Projectos

Gestão de Projectos. Processos e Aproximações de Desenvolvimento de Projectos. Informáticos. Selecção da Aproximação de Projectos Gestão de Projectos Informáticos Processos e Aproximações de Desenvolvimento de Projectos Informáticos Prof. Alberto Silva & Dra. RosárioBernardo Departamento de Engenharia Informática Selecção da Aproximação

Leia mais

LISTA DE EXERCÍCIOS METODOLOGIAS ÁGEIS ENGENHARIA DE SOFTWARE 10/08/2013

LISTA DE EXERCÍCIOS METODOLOGIAS ÁGEIS ENGENHARIA DE SOFTWARE 10/08/2013 LISTA DE EXERCÍCIOS METODOLOGIAS ÁGEIS ENGENHARIA DE SOFTWARE 10/08/2013 Disciplina: Professor: Engenharia de Software Edison Andrade Martins Morais http://www.edison.eti.br prof@edison.eti.br Área: Metodologias

Leia mais

Manifesto Ágil - Princípios

Manifesto Ágil - Princípios USP UNIVERSIDADE DO ESTADO DE SÃO PAULO Métodos Ágeis Alunos: Rogério Guaraci dos Santos - rgsantos@ime.usp.br Giulian Dalton Luz - gdaltonl@ime.usp.br Manifesto Ágil - Princípios Indivíduos e interações

Leia mais

Após completar este módulo você deverá ter absorvido o seguinte conhecimento: Uma ampla visão do framework Scrum e suas peculiaridades

Após completar este módulo você deverá ter absorvido o seguinte conhecimento: Uma ampla visão do framework Scrum e suas peculiaridades Objetivos da Aula 1 Após completar este módulo você deverá ter absorvido o seguinte conhecimento: Uma ampla visão do framework Scrum e suas peculiaridades Entendimento sobre os processos essenciais do

Leia mais

5. Métodos ágeis de desenvolvimento de software

5. Métodos ágeis de desenvolvimento de software Engenharia de Software 5. Métodos ágeis de desenvolvimento de software Nuno Miguel Gil Fonseca nuno.fonseca@estgoh.ipc.pt Desenvolver e entregar software o mais rapidamente possível é hoje em dia um dos

Leia mais

PONTIFÍCIA UNIVERSIDADE CATÓLICA DE GOIÁS Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas

PONTIFÍCIA UNIVERSIDADE CATÓLICA DE GOIÁS Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas PONTIFÍCIA UNIVERSIDADE CATÓLICA DE GOIÁS Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas CMP1141 Processo e qualidade de software I Prof. Me. Elias Ferreira Sala: 210 F Quarta-Feira:

Leia mais

Desenvolvimento ágil de software

Desenvolvimento ágil de software Desenvolvimento ágil de software Desenvolvimento ágil de software (do inglês Agile software development) ou Método ágil é um conjunto de metodologias de desenvolvimento de software. O desenvolvimento ágil,

Leia mais

GESTÃO DA QUALIDADE DE SOFTWARE

GESTÃO DA QUALIDADE DE SOFTWARE GESTÃO DA QUALIDADE DE SOFTWARE Fernando L. F. Almeida falmeida@ispgaya.pt Principais Modelos Capability Maturity Model Integration (CMMI) Team Software Process and Personal Software Process (TSP/PSP)

Leia mais

Metodologias Ágeis de Desenvolvimento de Software

Metodologias Ágeis de Desenvolvimento de Software "Antes de imprimir pense em sua responsabilidade e compromisso com o MEIO AMBIENTE." Engenharia de Software de Desenvolvimento de Software Givanaldo Rocha de Souza givanaldo.rocha@ifrn.edu.br http://docente.ifrn.edu.br/givanaldorocha

Leia mais

Análise comparativa entre a engenharia de requisitos e o método de desenvolvimento ágil: Scrum

Análise comparativa entre a engenharia de requisitos e o método de desenvolvimento ágil: Scrum Análise comparativa entre a engenharia de requisitos e o método de desenvolvimento ágil: Scrum Patrícia Bastos Girardi, Sulimar Prado, Andreia Sampaio Resumo Este trabalho tem como objetivo prover uma

Leia mais

DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Desenvolvimento Ágil Modelos Ágeis. Profª Esp.: Maysa de Moura Gonzaga

DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Desenvolvimento Ágil Modelos Ágeis. Profª Esp.: Maysa de Moura Gonzaga DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Desenvolvimento Ágil Modelos Ágeis Profª Esp.: Maysa de Moura Gonzaga 2º Semestre / 2011 Extreme Programming (XP); DAS (Desenvolvimento Adaptativo de Software)

Leia mais

GESTÃO DO CONHECIMENTO PARA O DESENVOLVIMENTO DE SOFTWARE COM MÉTODOS ÁGEIS

GESTÃO DO CONHECIMENTO PARA O DESENVOLVIMENTO DE SOFTWARE COM MÉTODOS ÁGEIS GESTÃO DO CONHECIMENTO PARA O DESENVOLVIMENTO DE SOFTWARE COM MÉTODOS ÁGEIS Jeandro Maiko Perceval 1 Carlos Mario Dal Col Zeve2 Anderson Ricardo Yanzer Cabral ² RESUMO Este artigo apresenta conceitos sobre

Leia mais

SCRUM Gerência de Projetos Ágil. Prof. Elias Ferreira

SCRUM Gerência de Projetos Ágil. Prof. Elias Ferreira SCRUM Gerência de Projetos Ágil Prof. Elias Ferreira Métodos Ágeis + SCRUM + Introdução ao extreme Programming (XP) Manifesto Ágil Estamos descobrindo maneiras melhores de desenvolver software fazendo-o

Leia mais

Uma introdução ao SCRUM. Evandro João Agnes evandroagnes@yahoo.com.br

Uma introdução ao SCRUM. Evandro João Agnes evandroagnes@yahoo.com.br Uma introdução ao SCRUM Evandro João Agnes evandroagnes@yahoo.com.br Agenda Projetos de Software O que é Scrum Scrum framework Estrutura do Scrum Sprints Ferramentas Projetos de software Chaos Report Standish

Leia mais

UTILIZAÇÃO DAS METODOLOGIAS ÁGEIS XP E SCRUM PARA O DESENVOLVIMENTO RÁPIDO DE APLICAÇÕES

UTILIZAÇÃO DAS METODOLOGIAS ÁGEIS XP E SCRUM PARA O DESENVOLVIMENTO RÁPIDO DE APLICAÇÕES UTILIZAÇÃO DAS METODOLOGIAS ÁGEIS XP E SCRUM PARA O DESENVOLVIMENTO RÁPIDO DE APLICAÇÕES Marcelo Augusto Lima Painka¹, Késsia Rita da Costa Marchi¹ ¹Universidade Paranaense (Unipar) Paranavaí PR Brasil

Leia mais

Sistemas de Informação e Programação II Odorico Machado Mendizabal

Sistemas de Informação e Programação II Odorico Machado Mendizabal Sistemas de Informação e Programação II Odorico Machado Mendizabal Universidade Federal do Rio Grande FURG C3 Engenharia de Computação 16 e 23 de março de 2011 Processo de Desenvolvimento de Software Objetivos

Leia mais

Engenharia de Software

Engenharia de Software Engenharia de Software Processos de software Departamento de Matemática Universidade dos Açores Hélia Guerra helia@uac.pt Processo Um processo é uma série de etapas envolvendo actividades, restrições e

Leia mais

Comparativo entre Processos Ágeis. Daniel Ferreira dfs3@cin.ufpe.br

Comparativo entre Processos Ágeis. Daniel Ferreira dfs3@cin.ufpe.br Comparativo entre Processos Ágeis Daniel Ferreira dfs3@cin.ufpe.br O que discutiremos: Histórico Os Princípios Ágeis Comparação Do ponto de vista incremental Do ponto de vista funcional Vantagens e Desvantagens

Leia mais

PRIMAVERA BUSINESS SOFTWARE SOLUTIONS, SA

PRIMAVERA BUSINESS SOFTWARE SOLUTIONS, SA PRIMAVERA BUSINESS SOFTWARE SOLUTIONS, SA Introdução Nesta edição do Catálogo de Serviços apresentamos os vários tipos de serviços que compõe a actual oferta da Primavera na área dos serviços de consultoria.

Leia mais

SCRUM: UM MÉTODO ÁGIL. Cleviton Monteiro (cleviton@gmail.com)

SCRUM: UM MÉTODO ÁGIL. Cleviton Monteiro (cleviton@gmail.com) SCRUM: UM MÉTODO ÁGIL Cleviton Monteiro (cleviton@gmail.com) Roteiro Motivação Manifesto Ágil Princípios Ciclo Papeis, cerimônias, eventos, artefatos Comunicação Product Backlog Desperdício 64% das features

Leia mais

PHC TeamControl CS. A gestão de equipas e de departamentos

PHC TeamControl CS. A gestão de equipas e de departamentos PHC TeamControl CS A gestão de equipas e de departamentos A solução que permite concretizar projectos no tempo previsto e nos valores orçamentados contemplando: planeamento; gestão; coordenação; colaboração

Leia mais

FireScrum: Ferramenta de apoio à gestão de projetos utilizando Scrum

FireScrum: Ferramenta de apoio à gestão de projetos utilizando Scrum C.E.S.A.R.EDU Unidade de Educação do Centro de Estudos e Sistemas Avançados do Recife Projeto de Dissertação de Mestrado FireScrum: Ferramenta de apoio à gestão de projetos utilizando Scrum Eric de Oliveira

Leia mais

Requisitos para Gestão de Requisitos no Desenvolvimento de Software que Utilizam Prática Ágeis

Requisitos para Gestão de Requisitos no Desenvolvimento de Software que Utilizam Prática Ágeis Requisitos para Gestão de Requisitos no Desenvolvimento de Software que Utilizam Prática Ágeis Abstract. Resumo. 1. Introdução Vinicius A. C. de Abreu 1 Departamento de Ciência da Computação - DCC Universidade

Leia mais

Métodos Ágeis de Desenvolvimento de Software

Métodos Ágeis de Desenvolvimento de Software Conteúdo Métodos Ágeis de Desenvolvimento de Software Engenharia de Software Profa. Elisa Yumi Nakagawa 2. Semestre 2005 Material inicialmente elaborado por André Figueiredo e mantido por pesquisadores

Leia mais

Por que o Scrum? o Foco na Gerência de Projetos; o Participação efetiva do Cliente.

Por que o Scrum? o Foco na Gerência de Projetos; o Participação efetiva do Cliente. Por que o Scrum? o Foco na Gerência de Projetos; o Participação efetiva do Cliente. Desenvolvido por Jeff SUTHERLAND e Ken SCHWABER ; Bastante objetivo, com papéis bem definidos; Curva de Aprendizado é

Leia mais

Estudo de compatibilidade entre PMBOK e SCRUM

Estudo de compatibilidade entre PMBOK e SCRUM Estudo de compatibilidade entre PMBOK e SCRUM Resumo Marcela Silva Kardec O objetivo deste estudo é fazer uma revisão do conhecimento sobre o gerenciamento de projetos, sob a ótica do que é classificado

Leia mais

Scrum Guia Prático. Raphael Rayro Louback Saliba Certified Scrum Master. Os papéis, eventos, artefatos e as regras do Scrum. Solutions. www.domain.

Scrum Guia Prático. Raphael Rayro Louback Saliba Certified Scrum Master. Os papéis, eventos, artefatos e as regras do Scrum. Solutions. www.domain. Scrum Guia Prático Os papéis, eventos, artefatos e as regras do Scrum Solutions www.domain.com Raphael Rayro Louback Saliba Certified Scrum Master 1 Gráfico de Utilização de Funcionalidades Utilização

Leia mais

Com metodologias de desenvolvimento

Com metodologias de desenvolvimento Sociedade demanda grande quantidade de sistemas/aplicações software complexo, sistemas distribuídos, heterogêneos requisitos mutantes (todo ano, todo mês, todo dia) Mas, infelizmente, não há gente suficiente

Leia mais

PHC TeamControl CS. A gestão de equipas e de departamentos

PHC TeamControl CS. A gestão de equipas e de departamentos PHC TeamControl CS A gestão de equipas e de departamentos A solução que permite concretizar projetos no tempo previsto e nos valores orçamentados contemplando: planeamento; gestão; coordenação; colaboração

Leia mais

CRITÉRIO 3: SISTEMA DE DESENVOLVIMENTO E GESTÃO DO DESEMPENHO

CRITÉRIO 3: SISTEMA DE DESENVOLVIMENTO E GESTÃO DO DESEMPENHO CRITÉRIO 3: SISTEMA DE DESENVOLVIMENTO E GESTÃO DO DESEMPENHO Este capítulo inclui: Visão geral O Ciclo de Gestão do Desempenho: Propósito e Objectivos Provas requeridas para a acreditação Outros aspectos

Leia mais

MANIFESTO ÁGIL. Esses conceitos aproximam-se melhor com a forma que pequenas e médias organizações trabalham e respondem à mudanças.

MANIFESTO ÁGIL. Esses conceitos aproximam-se melhor com a forma que pequenas e médias organizações trabalham e respondem à mudanças. METODOLOGIAS ÁGEIS SURGIMENTO As metodologias ágeis surgiram em resposta ao problema dos atrasos no desenvolvimento de software e aos cancelamentos, devido ao fato dos sistemas demorarem muito tempo para

Leia mais

SCRUM. Ricardo Coelho

SCRUM. Ricardo Coelho SCRUM Ricardo Coelho AGILE 2 Scrum Scrum- ban ( ) Kanban AGILE ( ) Extreme Programming Lean 3 Scrum Scrum- ban ( ) Kanban AGILE ( ) Extreme Programming Lean ADAPTIVE vs. PREDICTIVE 4 Scrum Scrum- ban (

Leia mais

A utilização do Scrum em um sistema web: um estudo de caso

A utilização do Scrum em um sistema web: um estudo de caso ISSN 23162872 T.I.S. São Carlos, v. 1, n. 1, p. 7681, jul. 2012 Tecnologias, Infraestrutura e Software A utilização do Scrum em um sistema web: um estudo de caso Flávia dos Santos Zenaro Abstract: This

Leia mais

5.1 Introdução. 5.2 Project Management Institute (PMI)

5.1 Introdução. 5.2 Project Management Institute (PMI) 5 NORMALIZAÇÃO DA GESTÃO DE PROJETOS 5.1 Introdução Embora tradicionalmente o esforço de normalização pertença à International Standards Organization (ISO), no caso da gestão de projetos a iniciativa tem

Leia mais

XXVIII. Qualidade do Novo Edifício Hospitalar ÍNDICE

XXVIII. Qualidade do Novo Edifício Hospitalar ÍNDICE XXVIII Qualidade do Novo Edifício Hospitalar ÍNDICE 1. Sistema de gestão de qualidade... 2 1.1 Objectivos do sistema... 2 1.2 Estrutura organizativa... 4 1.2.1 Organização interna... 4 1.2.2 Estrutura

Leia mais

PRODUTOS INOVADORES: O DESAFIO DO MERCADO RECURSOS TÉCNICOS PARA O EMPREENDEDORISMO DE BASE TECNOLÓGICO

PRODUTOS INOVADORES: O DESAFIO DO MERCADO RECURSOS TÉCNICOS PARA O EMPREENDEDORISMO DE BASE TECNOLÓGICO ÍNDICE INTRODUÇÃO Sobre o guia Utilizadores Beneficiários CONCEITOS CHAVE NOTAS METODOLÓGICAS E PRÉ-REQUISITOS PROCESSO METODOLÓGICO Parte I Referencial para o lançamento de produtos inovadores no mercado

Leia mais

Gestão Ágil de Projetos e a certificação PMI-ACP

Gestão Ágil de Projetos e a certificação PMI-ACP Gestão Ágil de Projetos e a certificação PMI-ACP Apresentação Roberto Gil Espinha Mais de 15 anos de experiência em Projetos Bacharel em Administração de Empresas pela UNIVILLE Pós-Graduado em Gestão Empresarial

Leia mais

UNIVERSIDADE CANDIDO MENDES PÓS-GRADUAÇÃO LATO SENSU INSTITUTO A VEZ DO MESTRE

UNIVERSIDADE CANDIDO MENDES PÓS-GRADUAÇÃO LATO SENSU INSTITUTO A VEZ DO MESTRE UNIVERSIDADE CANDIDO MENDES PÓS-GRADUAÇÃO LATO SENSU INSTITUTO A VEZ DO MESTRE BOAS PRÁTICAS DO PMI COM OS MÉTODOS ÁGEIS Por: Sheyla Christina Bueno Ortiz Orientador Prof. Nelsom Magalhães Rio de Janeiro

Leia mais

SCRUM. É um processo iterativo e incremental para o desenvolvimento de qualquer produto e gerenciamento de qualquer projeto.

SCRUM. É um processo iterativo e incremental para o desenvolvimento de qualquer produto e gerenciamento de qualquer projeto. SCRUM SCRUM É um processo iterativo e incremental para o desenvolvimento de qualquer produto e gerenciamento de qualquer projeto. Ken Schwaber e Jeff Sutherland Transparência A transparência garante que

Leia mais

Agilidade parte 3/3 - Scrum. Prof. Dr. Luís Fernando Fortes Garcia luis@garcia.pro.br

Agilidade parte 3/3 - Scrum. Prof. Dr. Luís Fernando Fortes Garcia luis@garcia.pro.br Agilidade parte 3/3 - Scrum Prof. Dr. Luís Fernando Fortes Garcia luis@garcia.pro.br 1 Scrum Scrum? Jogada do Rugby Formação de muralha com 8 jogadores Trabalho em EQUIPE 2 Scrum 3 Scrum Scrum Processo

Leia mais

Quais são as características de um projeto?

Quais são as características de um projeto? Metodologias ágeis Flávio Steffens de Castro Projetos? Quais são as características de um projeto? Temporário (início e fim) Objetivo (produto, serviço e resultado) Único Recursos limitados Planejados,

Leia mais

Manifesto Ágil e as Metodologias Ágeis (XP e SCRUM)

Manifesto Ágil e as Metodologias Ágeis (XP e SCRUM) Programação Extrema Manifesto Ágil e as Metodologias Ágeis (XP e SCRUM) Prof. Mauro Lopes Programação Extrema Prof. Mauro Lopes 1-31 45 Manifesto Ágil Formação da Aliança Ágil Manifesto Ágil: Propósito

Leia mais

INTRODUÇÃO AOS MÉTODOS ÁGEIS

INTRODUÇÃO AOS MÉTODOS ÁGEIS WESLLEYMOURA@GMAIL.COM INTRODUÇÃO AOS MÉTODOS ÁGEIS ANÁLISE DE SISTEMAS Introdução aos métodos ágeis Metodologias tradicionais Estes tipos de metodologias dominaram a forma de desenvolvimento de software

Leia mais

Processo de Desenvolvimento de Software Scrum. Prof. Antonio Almeida de Barros Jr.

Processo de Desenvolvimento de Software Scrum. Prof. Antonio Almeida de Barros Jr. Processo de Desenvolvimento de Software Scrum Manifesto da Agilidade Quatro princípios Indivíduos e interações mais que processos e ferramentas Software funcionando mais que documentação compreensiva Colaboração

Leia mais

Metodologias Ágeis. Gerenciando e Desenvolvendo Projetos de forma eficiente. Gabriel Verta 0767948 Rafael Reimberg 0767701 Vinicius Quaiato - 0767697

Metodologias Ágeis. Gerenciando e Desenvolvendo Projetos de forma eficiente. Gabriel Verta 0767948 Rafael Reimberg 0767701 Vinicius Quaiato - 0767697 Metodologias Ágeis Gerenciando e Desenvolvendo Projetos de forma eficiente Gabriel Verta 0767948 Rafael Reimberg 0767701 Vinicius Quaiato - 0767697 Introdução Ao longo dos anos a indústria de desenvolvimento

Leia mais

Scrum-Half: Uma Ferramenta Web de Apoio ao Scrum

Scrum-Half: Uma Ferramenta Web de Apoio ao Scrum Scrum-Half: Uma Ferramenta Web de Apoio ao Scrum Diego R. Marins 1,2, José A. Rodrigues Nt. 1, Geraldo B. Xexéo 2, Jano M. de Sousa 1 1 Programa de Engenharia de Sistemas e Computação - COPPE/UFRJ 2 Departamento

Leia mais

1 Serviços de Planeamento e Transformação Empresarial Os Serviços de Planeamento e Transformação Empresarial da SAP incluem:

1 Serviços de Planeamento e Transformação Empresarial Os Serviços de Planeamento e Transformação Empresarial da SAP incluem: Descrição de Serviços Serviços de Planeamento e Empresarial Os Serviços de Planeamento e Empresarial fornecem serviços de consultoria e prototipagem para facilitar a agenda do Licenciado relativa à inovação

Leia mais

PHC dteamcontrol Interno

PHC dteamcontrol Interno PHC dteamcontrol Interno A gestão remota de projectos em aberto A solução via Internet que permite acompanhar os projectos em aberto em que o utilizador se encontra envolvido, gerir eficazmente o seu tempo

Leia mais

Exemplo de Exame de Gestão da Produção e das Operações

Exemplo de Exame de Gestão da Produção e das Operações Exemplo de Exame de Gestão da Produção e das Operações A. Resolva os seguintes problemas (8 valores) 1. Uma determinada empresa faz a lavagem de cisternas rodoviárias na zona norte do País. Com equipamento

Leia mais

Desafios no Uso do Scrum em Ambientes CMMI

Desafios no Uso do Scrum em Ambientes CMMI Desafios no Uso do Scrum em Ambientes CMMI Teresa Maria de Medeiros Maciel UFRPE/INES/UFPE tmmaciel@gmail.com Base de conhecimento disponível Maior controle ISO9001 MPS BR Padronização processual

Leia mais

Gerenciamento Ágil de Projetos de Desenvolvimento de Softwares na Secretaria de Estado da Casa Civil

Gerenciamento Ágil de Projetos de Desenvolvimento de Softwares na Secretaria de Estado da Casa Civil Gerenciamento Ágil de Projetos de Desenvolvimento de Softwares na Secretaria de Estado da Casa Civil Claryanne A. Guimarães 1, Daniel Dias S. Rosa 1 1 Departamento de Computação Universidade Federal de

Leia mais

PHC dteamcontrol Externo

PHC dteamcontrol Externo PHC dteamcontrol Externo A gestão remota de projectos e de informação A solução via Internet que permite aos seus Clientes participarem nos projectos em que estão envolvidos, interagindo na optimização

Leia mais

Análise de Sistemas. Conceito de análise de sistemas

Análise de Sistemas. Conceito de análise de sistemas Análise de Sistemas Conceito de análise de sistemas Sistema: Conjunto de partes organizadas (estruturadas) que concorrem para atingir um (ou mais) objectivos. Sistema de informação (SI): sub-sistema de

Leia mais

Guia do Nexus. O Guia Definitivo para o Nexus: O exoesqueleto do desenvolvimento Scrum escalado. Desenvolvido e mantido por Ken Schwaber e Scrum.

Guia do Nexus. O Guia Definitivo para o Nexus: O exoesqueleto do desenvolvimento Scrum escalado. Desenvolvido e mantido por Ken Schwaber e Scrum. Guia do Nexus O Guia Definitivo para o Nexus: O exoesqueleto do desenvolvimento Scrum escalado Desenvolvido e mantido por Ken Schwaber e Scrum.org Tabela de Conteúdo Visão Geral do Nexus... 2 O Propósito

Leia mais

Praticando o Scrum. Prof. Wylliams Barbosa Santos wylliamss@gmail.com Optativa IV Projetos de Sistemas Web

Praticando o Scrum. Prof. Wylliams Barbosa Santos wylliamss@gmail.com Optativa IV Projetos de Sistemas Web Praticando o Scrum Prof. Wylliams Barbosa Santos wylliamss@gmail.com Optativa IV Projetos de Sistemas Web Créditos de Conteúdo: Left (left@cesar.org.br) Certified Scrum Master Preparação Agrupar os membros

Leia mais

SCRUM: UMA DAS METODOLOGIAS ÁGEIS MAIS USADAS DO MUNDO

SCRUM: UMA DAS METODOLOGIAS ÁGEIS MAIS USADAS DO MUNDO SCRUM: UMA DAS METODOLOGIAS ÁGEIS MAIS USADAS DO MUNDO RESUMO Eleandro Lopes de Lima 1 Nielsen Alves dos Santos 2 Rodrigo Vitorino Moravia 3 Maria Renata Furtado 4 Ao propor uma alternativa para o gerenciamento

Leia mais

Análise da aplicação da metodologia SCRUM em uma empresa de Desenvolvimento de Software

Análise da aplicação da metodologia SCRUM em uma empresa de Desenvolvimento de Software Análise da aplicação da metodologia SCRUM em uma empresa de Desenvolvimento de Software Carolina Luiza Chamas Faculdade de Tecnologia da Zona Leste SP Brasil carolchamas@hotmail.com Leandro Colevati dos

Leia mais

Gestão de Configurações II

Gestão de Configurações II Gestão de Configurações II Bibliografia Livro: Software Configuration Management Patterns: Effective Teamwork, Practical Integration Gestão de Projecto 14 Padrões de Gestão Os padrões de gestão de configurações

Leia mais

Workshop SCRUM. Versão 5 Out 2010 RFS. rildo.santos@etecnologia.com.br

Workshop SCRUM. Versão 5 Out 2010 RFS. rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos 2006 e 2010 Objetivo: Estudo de Caso Objetivo: Apresentar um Estudo de Caso para demonstrar como aplicar as práticas do SCRUM em projeto de desenvolvimento de

Leia mais

Wesley Torres Galindo

Wesley Torres Galindo Qualidade, Processos e Gestão de Software Professores: Alexandre Vasconcelos e Hermano Moura Wesley Torres Galindo wesleygalindo@gmail.com User Story To Do Doing Done O que é? Como Surgiu? Estrutura Apresentar

Leia mais

Ferramenta para gestão ágil

Ferramenta para gestão ágil Ferramenta para gestão ágil de projetos de software Robson Ricardo Giacomozzi Orientador: Everaldo Artur Grahl Agenda Introdução Objetivos Fundamentação teórica Desenvolvimento Resultados e discussões

Leia mais

Wesley Torres Galindo. wesleygalindo@gmail.com

Wesley Torres Galindo. wesleygalindo@gmail.com Wesley Torres Galindo wesleygalindo@gmail.com Wesley Galindo Graduação em Análise e Desenvolvimento de Sistemas Mestrado em Engenharia de Software Engenheiro de Software Professor Faculdade Escritor Osman

Leia mais

PHC dteamcontrol Interno

PHC dteamcontrol Interno O módulo PHC dteamcontrol Interno permite acompanhar a gestão de todos os projectos abertos em que um utilizador se encontra envolvido. PHC dteamcontrol Interno A solução via Internet que permite acompanhar

Leia mais

Plataforma de Gestão de Actualizações de Software Descrição do Problema

Plataforma de Gestão de Actualizações de Software Descrição do Problema Plataforma de Gestão de Actualizações de Software Descrição do Problema Pedro Miguel Barros Morgado Índice Introdução... 3 Ponto.C... 4 Descrição do Problema... 5 Bibliografia... 7 2 Introdução No mundo

Leia mais

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 06 PROFª BRUNO CALEGARO

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 06 PROFª BRUNO CALEGARO UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 06 PROFª BRUNO CALEGARO Santa Maria, 27 de Setembro de 2013. Revisão aula anterior Desenvolvimento Ágil de Software Desenvolvimento e entrega

Leia mais

2. Quantas iterações precisa-se?

2. Quantas iterações precisa-se? Gerenciamento ágil de projetos Gerenciamento ágil de projetos é uma metodologia especificamente devenvolvida para projetos na área de software. É caracterizado pela vasta desistência de uma metodologia

Leia mais

Desenvolvimento Ágil de Software em Larga Escala

Desenvolvimento Ágil de Software em Larga Escala Desenvolvimento Ágil de Software em Larga Escala Jutta Eckstein Encontro Ágil 2009 1 Agilidade é Quente Gerenciamento Ágil de Projetos Testes Ágeis Arquitetura Ágeis Offshore Ágil Investimento Ágil PLM

Leia mais

Projecto de Modelação, Engenharia de Software e Sistemas Distribuídos 2008-09. Requisitos para a 3ª entrega do projecto.

Projecto de Modelação, Engenharia de Software e Sistemas Distribuídos 2008-09. Requisitos para a 3ª entrega do projecto. Departamento de Engenharia Informática Modelação, Engenharia de Software, Sistemas Distribuídos Requisitos para a 3ª entrega do projecto Test O Matic 10 de Maio de 2009 1 Índice 1 Índice... 1 2 Sumário...

Leia mais

Workshop. Workshop SCRUM. Rildo F Santos. rildo.santos@etecnologia.com.br. Versão 1 Ago 2010 RFS. www.etcnologia.com.br (11) 9123-5358 (11) 9962-4260

Workshop. Workshop SCRUM. Rildo F Santos. rildo.santos@etecnologia.com.br. Versão 1 Ago 2010 RFS. www.etcnologia.com.br (11) 9123-5358 (11) 9962-4260 Workshop www.etcnologia.com.br (11) 9123-5358 (11) 9962-4260 Rildo F Santos twitter: @rildosan skype: rildo.f.santos http://rildosan.blogspot.com/ Todos os direitos reservados e protegidos 2006 e 2010

Leia mais

GIBDQA: GESTÃO INTEGRADA DE BASES DE DADOS DA QUALIDADE DA ÁGUA

GIBDQA: GESTÃO INTEGRADA DE BASES DE DADOS DA QUALIDADE DA ÁGUA GIBDQA: GESTÃO INTEGRADA DE BASES DE DADOS DA QUALIDADE DA ÁGUA Sandra CARVALHO 1, Pedro GALVÃO 2, Cátia ALVES 3, Luís ALMEIDA 4 e Adélio SILVA 5 RESUMO As empresas de abastecimento de água gerem diariamente

Leia mais

05/05/2010. Década de 60: a chamada Crise do Software

05/05/2010. Década de 60: a chamada Crise do Software Pressman, Roger S. Software Engineering: A Practiotioner s Approach. Editora: McGraw- Hill. Ano: 2001. Edição: 5 Introdução Sommerville, Ian. SW Engineering. Editora: Addison Wesley. Ano: 2003. Edição:

Leia mais

[Agile] Scrum + XP. Wagner Roberto dos Santos. Agilidade extrema. Arquiteto Java EE / Scrum Master wrsconsulting@gmail.com. Globalcode open4education

[Agile] Scrum + XP. Wagner Roberto dos Santos. Agilidade extrema. Arquiteto Java EE / Scrum Master wrsconsulting@gmail.com. Globalcode open4education [Agile] Scrum + XP Agilidade extrema Wagner Roberto dos Santos Arquiteto Java EE / Scrum Master wrsconsulting@gmail.com 1 Apresentação Arquiteto Java EE / Scrum Master Lead Editor da Queue Arquitetura

Leia mais

Versão 7 TraceGP Ágil

Versão 7 TraceGP Ágil Versão 7 Cadastro de Produtos Será possível cadastrar todos os produtos da empresa bem como descrever suas características particulares através da seleção de atributos dinâmicos para cada produto. Manutenção

Leia mais

ESTUDO DE CASO: SCRUM E PMBOK UNIDOS NO GERENCIAMENTO DE PROJETOS. contato@alinebrake.com.br. fs_moreira@yahoo.com.br. contato@marcelobrake.com.

ESTUDO DE CASO: SCRUM E PMBOK UNIDOS NO GERENCIAMENTO DE PROJETOS. contato@alinebrake.com.br. fs_moreira@yahoo.com.br. contato@marcelobrake.com. ESTUDO DE CASO: SCRUM E PMBOK UNIDOS NO GERENCIAMENTO DE PROJETOS (CASE STUDY: SCRUM AND PMBOK - STATES IN PROJECT MANAGEMENT) Aline Maria Sabião Brake 1, Fabrício Moreira 2, Marcelo Divaldo Brake 3, João

Leia mais

Desenvolvimento Ágil. O Manifesto para o Desenvolvimento de Software Ágil

Desenvolvimento Ágil. O Manifesto para o Desenvolvimento de Software Ágil Desenvolvimento Ágil 02561-5 Engenharia de Software Profa. Rosângela Penteado Aula de 24/8/2006 1 O Manifesto para o Desenvolvimento de Software Ágil Nós estamos descobrindo melhores maneiras de desenvolver

Leia mais

Tópicos. Métodos Ágeis. Histórico; Valores; Métodos Ágeis x Modelos Tradicionais; Exemplo: Referências Bibliográficas.

Tópicos. Métodos Ágeis. Histórico; Valores; Métodos Ágeis x Modelos Tradicionais; Exemplo: Referências Bibliográficas. Métodos Ágeis Edes Garcia da Costa Filho edes_filho@dc.ufscar.br 1 Tópicos Histórico; Valores; Métodos Ágeis x Modelos Tradicionais; Exemplo: Extreme Programming (XP). Referências Bibliográficas. 2 Histórico

Leia mais

Os Desafios da Segurança no Desenvolvimento com Métodos Ágeis. OWASP Education Project. The OWASP Foundation http://www.owasp.org

Os Desafios da Segurança no Desenvolvimento com Métodos Ágeis. OWASP Education Project. The OWASP Foundation http://www.owasp.org Os Desafios da Segurança no Desenvolvimento com Métodos Ágeis Education Project Rafael Dreher Porto Alegre Chapter - Co-founder Security Consultant @ Dell dreher@owasp.org Copyright 2007 The Foundation

Leia mais

A PRIMMER possui casos importantes nesta área. Venha compartilhar conosco desta experiência magnífica no mundo das metodologias ágeis.

A PRIMMER possui casos importantes nesta área. Venha compartilhar conosco desta experiência magnífica no mundo das metodologias ágeis. METODOLOGIAS ÁGEIS Boas Práticas para o Gerenciamento de Projetos de TI utilizando métodos ágeis baseados em SCRUM e XP etc. DIFERENCIAIS Avaliação prévia das necessidades de cada participante para customização

Leia mais

Sem o recurso às tecnologias disponibilizadas pela Microsoft, a solução criada seria difícil de obter num tão curto espaço de tempo.

Sem o recurso às tecnologias disponibilizadas pela Microsoft, a solução criada seria difícil de obter num tão curto espaço de tempo. Caso de Sucesso Microsoft Finsolutia cria solução completa de suporte ao negócio com.net Framework 3.5 Sumário País: Portugal Indústria: Banking&Finance Perfil do Cliente A Finsolutia é uma joint venture

Leia mais

Metodologias Ágeis para Desenvolvimento de Software

Metodologias Ágeis para Desenvolvimento de Software Metodologias Ágeis para Desenvolvimento de Software ADRIANA TAVARES FIGUEIREDO Graduaçao em Licenciatura para Computação UNILASALLE RJ / 2006 Pós Graduada em Design Estratégico e MKT Management ESPM RJ

Leia mais

Gerenciamento Ágil de Projetos

Gerenciamento Ágil de Projetos Gerenciamento Ágil de Projetos Autor: Vitor Massari Atuando desde 1998 na área de projetos de TI. Sócio-diretor da Hiflex Consultoria. Autor do primeiro livro em Português voltado para a certificação PMI-ACP

Leia mais

UM SISTEMA ÁGIL NA GESTÃO DA CONSTRUÇÃO

UM SISTEMA ÁGIL NA GESTÃO DA CONSTRUÇÃO Coimbra, Portugal, 2012 UM SISTEMA ÁGIL NA GESTÃO DA CONSTRUÇÃO Manuela Cristina de Oliveira Pereira dos Santos Timóteo Fernandes Escola Superior de Tecnologia do Barreiro Instituto Politécnico de Setúbal

Leia mais

Agradecimento. Adaptação do curso Scrum de Márcio Sete, ChallengeIT. Adaptação do curso The Zen of Scrum de Alexandre Magno, AdaptaWorks

Agradecimento. Adaptação do curso Scrum de Márcio Sete, ChallengeIT. Adaptação do curso The Zen of Scrum de Alexandre Magno, AdaptaWorks S C R U M Apresentação Tiago Domenici Griffo Arquiteto de Software na MCP, MCAD, MCSD, MCTS Web, Windows e TFS, ITIL Foundation Certified, MPS.BR P1 Experiência internacional e de offshoring Agradecimento

Leia mais

Scrum. Gestão ágil de projetos

Scrum. Gestão ágil de projetos Scrum Gestão ágil de projetos Apresentação feita por : Igor Macaúbas e Marcos Pereira Modificada por: Francisco Alecrim (22/01/2012) Metas para o o Metas para treinamento seminário Explicar o que é Scrum

Leia mais