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

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

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

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

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

Base de Dados para Administrações de Condomínios

Base de Dados para Administrações de Condomínios Base de Dados para Administrações de Condomínios José Pedro Gaiolas de Sousa Pinto: ei03069@fe.up.pt Marco António Sousa Nunes Fernandes Silva: ei03121@fe.up.pt Pedro Miguel Rosário Alves: alves.pedro@fe.up.pt

Leia mais

Modelo Cascata ou Clássico

Modelo Cascata ou Clássico Modelo Cascata ou Clássico INTRODUÇÃO O modelo clássico ou cascata, que também é conhecido por abordagem top-down, foi proposto por Royce em 1970. Até meados da década de 1980 foi o único modelo com aceitação

Leia mais

Gestão dos Níveis de Serviço

Gestão dos Níveis de Serviço A Gestão dos Níveis de Serviço (SLM) Os sistemas e tecnologias de informação e comunicação têm nas empresas um papel cada vez mais importante evoluindo, hoje em dia, para níveis mais elevados de funcionamento

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

ISO 9000:2000 Sistemas de Gestão da Qualidade Fundamentos e Vocabulário. As Normas da família ISO 9000. As Normas da família ISO 9000

ISO 9000:2000 Sistemas de Gestão da Qualidade Fundamentos e Vocabulário. As Normas da família ISO 9000. As Normas da família ISO 9000 ISO 9000:2000 Sistemas de Gestão da Qualidade Fundamentos e Vocabulário Gestão da Qualidade 2005 1 As Normas da família ISO 9000 ISO 9000 descreve os fundamentos de sistemas de gestão da qualidade e especifica

Leia mais

Começo por apresentar uma breve definição para projecto e para gestão de projectos respectivamente.

Começo por apresentar uma breve definição para projecto e para gestão de projectos respectivamente. The role of Project management in achieving Project success Ao longo da desta reflexão vou abordar os seguintes tema: Definir projectos, gestão de projectos e distingui-los. Os objectivos da gestão de

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

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

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 Serviços CS. A gestão de processos de prestação de serviços

PHC Serviços CS. A gestão de processos de prestação de serviços PHC Serviços CS A gestão de processos de prestação de serviços A solução que permite controlar diferentes áreas de uma empresa: reclamações e respectivo tratamento; controlo de processos e respectivos

Leia mais

INTRODUÇÃO objectivo

INTRODUÇÃO objectivo INTRODUÇÃO O tema central deste trabalho é o sistema de produção just-in-time ou JIT. Ao falarmos de just-in-time surge de imediato a ideia de produção sem stocks, inventários ao nível de zero, produção

Leia mais

GESTÃO de PROJECTOS. Gestor de Projectos Informáticos. Luís Manuel Borges Gouveia 1

GESTÃO de PROJECTOS. Gestor de Projectos Informáticos. Luís Manuel Borges Gouveia 1 GESTÃO de PROJECTOS Gestor de Projectos Informáticos Luís Manuel Borges Gouveia 1 Iniciar o projecto estabelecer objectivos definir alvos estabelecer a estratégia conceber a estrutura de base do trabalho

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

GereComSaber. Disciplina de Desenvolvimento de Sistemas de Software. Sistema de Gestão de Serviços em Condomínios

GereComSaber. Disciplina de Desenvolvimento de Sistemas de Software. Sistema de Gestão de Serviços em Condomínios Universidade do Minho Conselho de Cursos de Engenharia Licenciatura em Engenharia Informática 3ºAno Disciplina de Desenvolvimento de Sistemas de Software Ano Lectivo de 2009/2010 GereComSaber Sistema de

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

NP EN ISO 9001:2000 LISTA DE COMPROVAÇÃO

NP EN ISO 9001:2000 LISTA DE COMPROVAÇÃO NP EN ISO 9001:2000 LISTA DE COMPROVAÇÃO NIP: Nº DO RELATÓRIO: DENOMINAÇÃO DA EMPRESA: EQUIPA AUDITORA (EA): DATA DA VISITA PRÉVIA: DATA DA AUDITORIA: AUDITORIA DE: CONCESSÃO SEGUIMENTO ACOMPANHAMENTO

Leia mais

Programa de Parcerias e Submissão de Propostas 2014/15

Programa de Parcerias e Submissão de Propostas 2014/15 DEPARTAMENTO DE INFORMÁTICA Programa de Parcerias e Submissão de Propostas 2014/15 O Departamento de Informática (DI) da Faculdade de Ciências da Universidade de Lisboa (FCUL) procura criar e estreitar

Leia mais

PHC dteamcontrol Externo

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

Leia mais

DESENVOLVER E GERIR COMPETÊNCIAS EM CONTEXTO DE MUDANÇA (Publicado na Revista Hotéis de Portugal Julho/Agosto 2004)

DESENVOLVER E GERIR COMPETÊNCIAS EM CONTEXTO DE MUDANÇA (Publicado na Revista Hotéis de Portugal Julho/Agosto 2004) DESENVOLVER E GERIR COMPETÊNCIAS EM CONTEXTO DE MUDANÇA (Publicado na Revista Hotéis de Portugal Julho/Agosto 2004) por Mónica Montenegro, Coordenadora da área de Recursos Humanos do MBA em Hotelaria e

Leia mais

Processo do Serviços de Manutenção de Sistemas de Informação

Processo do Serviços de Manutenção de Sistemas de Informação Processo do Serviços de Manutenção de Sistemas de Informação 070112=SINFIC HM Processo Manutencao MSI.doc, Página 1 Ex.mo(s) Senhor(es): A SINFIC agradece a possibilidade de poder apresentar uma proposta

Leia mais

Organização. Trabalho realizado por: André Palma nº 31093. Daniel Jesus nº 28571. Fábio Bota nº 25874. Stephane Fernandes nº 28591

Organização. Trabalho realizado por: André Palma nº 31093. Daniel Jesus nº 28571. Fábio Bota nº 25874. Stephane Fernandes nº 28591 Organização Trabalho realizado por: André Palma nº 31093 Daniel Jesus nº 28571 Fábio Bota nº 25874 Stephane Fernandes nº 28591 Índice Introdução...3 Conceitos.6 Princípios de uma organização. 7 Posição

Leia mais

XI Mestrado em Gestão do Desporto

XI Mestrado em Gestão do Desporto 2 7 Recursos Humanos XI Mestrado em Gestão do Desporto Gestão das Organizações Desportivas Módulo de Gestão de Recursos Rui Claudino FEVEREIRO, 28 2 8 INDÍCE DOCUMENTO ORIENTADOR Âmbito Objectivos Organização

Leia mais

ISO/IEC 12207: Gerência de Configuração

ISO/IEC 12207: Gerência de Configuração ISO/IEC 12207: Gerência de Configuração Durante o processo de desenvolvimento de um software, é produzida uma grande quantidade de itens de informação que podem ser alterados durante o processo Para que

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

TECNOLOGIAS DA INFORMAÇÃO E COMUNICAÇÃO. SISTEMAS DE GESTÃO DE BASE DE DADOS Microsoft Access TECNOLOGIAS DA INFORMAÇÃO E COMUNICAÇÃO

TECNOLOGIAS DA INFORMAÇÃO E COMUNICAÇÃO. SISTEMAS DE GESTÃO DE BASE DE DADOS Microsoft Access TECNOLOGIAS DA INFORMAÇÃO E COMUNICAÇÃO TECNOLOGIAS DA INFORMAÇÃO E COMUNICAÇÃO Microsoft Access TECNOLOGIAS DA INFORMAÇÃO E COMUNICAÇÃO CONCEITOS BÁSICOS 1 Necessidade das base de dados Permite guardar dados dos mais variados tipos; Permite

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

GereComSaber. Desenvolvimento de Sistemas de Software. Universidade do Minho Conselho de Cursos de Engenharia Licenciatura em Engenharia Informática

GereComSaber. Desenvolvimento de Sistemas de Software. Universidade do Minho Conselho de Cursos de Engenharia Licenciatura em Engenharia Informática Universidade do Minho Conselho de Cursos de Engenharia Licenciatura em Engenharia Informática Desenvolvimento de Sistemas de Software Ano Lectivo de 2009/10 GereComSaber Ana Duarte, André Guedes, Eduardo

Leia mais

PROJECTO DE CARTA-CIRCULAR SOBRE POLÍTICA DE REMUNERAÇÃO DAS INSTITUIÇÕES FINANCEIRAS

PROJECTO DE CARTA-CIRCULAR SOBRE POLÍTICA DE REMUNERAÇÃO DAS INSTITUIÇÕES FINANCEIRAS PROJECTO DE CARTA-CIRCULAR SOBRE POLÍTICA DE REMUNERAÇÃO DAS INSTITUIÇÕES FINANCEIRAS No âmbito da avaliação realizada, a nível internacional, sobre os fundamentos da crise financeira iniciada no Verão

Leia mais

ISO 9001:2008. A International Organization for Standardization (ISO) publicou em 2008-11- 14 a nova edição da Norma ISO 9000:

ISO 9001:2008. A International Organization for Standardization (ISO) publicou em 2008-11- 14 a nova edição da Norma ISO 9000: A International Organization for Standardization (ISO) publicou em 2008-11- 14 a nova edição da Norma ISO 9000: ISO 9001:2008 Esta nova edição decorre do compromisso da ISO em rever e actualizar as Normas,

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

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

Direcção Regional de Educação do Centro. Agrupamento de Escolas de Canas de Senhorim. Escola EB 2.3/S Eng. Dionísio Augusto Cunha.

Direcção Regional de Educação do Centro. Agrupamento de Escolas de Canas de Senhorim. Escola EB 2.3/S Eng. Dionísio Augusto Cunha. Direcção Regional de Educação do Centro Agrupamento de Escolas de Canas de Senhorim Escola EB 2.3/S Eng. Dionísio Augusto Cunha Regulamento Da PAP (Prova de Aptidão Profissional) Cursos Profissionais (Portaria

Leia mais

Engenharia de Software II

Engenharia de Software II Engenharia de Software II Aula 5 http://www.ic.uff.br/~bianca/engsoft2/ Aula 5-05/05/2006 1 Dúvidas da aula passada RUP (Rational Unified Process) é uma ferramenta ou um processo? Resposta: os dois. O

Leia mais

Pós-Graduação em Gerenciamento de Projetos práticas do PMI

Pós-Graduação em Gerenciamento de Projetos práticas do PMI Pós-Graduação em Gerenciamento de Projetos práticas do PMI Planejamento do Gerenciamento das Comunicações (10) e das Partes Interessadas (13) PLANEJAMENTO 2 PLANEJAMENTO Sem 1 Sem 2 Sem 3 Sem 4 Sem 5 ABRIL

Leia mais

ENGENHARIA DE SOFTWARE I

ENGENHARIA DE SOFTWARE I ENGENHARIA DE SOFTWARE I Prof. Cássio Huggentobler de Costa [cassio.costa@ulbra.br] Twitter: www.twitter.com/cassiocosta_ Agenda da Aula (002) Metodologias de Desenvolvimento de Softwares Métodos Ágeis

Leia mais

Como elaborar um Plano de Negócios de Sucesso

Como elaborar um Plano de Negócios de Sucesso Como elaborar um Plano de Negócios de Sucesso Pedro João 28 de Abril 2011 Fundação António Cupertino de Miranda Introdução ao Plano de Negócios Modelo de Negócio Análise Financeira Estrutura do Plano de

Leia mais

Documento SGS. PLANO DE TRANSIÇÃO da SGS ICS ISO 9001:2008. PTD3065 - v010-2008-11 Pág 1 de 6

Documento SGS. PLANO DE TRANSIÇÃO da SGS ICS ISO 9001:2008. PTD3065 - v010-2008-11 Pág 1 de 6 PLANO DE TRANSIÇÃO da SGS ICS ISO 9001:2008 PTD3065 - v010-2008-11 Pág 1 de 6 1 Introdução A ISO 9001:2008 e o Processo de Transição da SGS ICS A International Organization for Standardization (ISO) publicou,

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

Certificação da Qualidade dos Serviços Sociais. Procedimentos

Certificação da Qualidade dos Serviços Sociais. Procedimentos Certificação da Qualidade dos Serviços Sociais EQUASS Assurance Procedimentos 2008 - European Quality in Social Services (EQUASS) Reservados todos os direitos. É proibida a reprodução total ou parcial

Leia mais

Indicadores Gerais para a Avaliação Inclusiva

Indicadores Gerais para a Avaliação Inclusiva PROCESSO DE AVALIAÇÃO EM CONTEXTOS INCLUSIVOS PT Preâmbulo Indicadores Gerais para a Avaliação Inclusiva A avaliação inclusiva é uma abordagem à avaliação em ambientes inclusivos em que as políticas e

Leia mais

Manual do Revisor Oficial de Contas. Directriz de Revisão/Auditoria 300 ÍNDICE

Manual do Revisor Oficial de Contas. Directriz de Revisão/Auditoria 300 ÍNDICE Directriz de Revisão/Auditoria 300 PLANEAMENTO Junho de 1999 ÍNDICE Parágrafos Introdução 1-4 Planeamento do Trabalho 5-8 Plano Global de Revisão / Auditoria 9-10 Programa de Revisão / Auditoria 11-12

Leia mais

Índice. Como aceder ao serviço de Certificação PME? Como efectuar uma operação de renovação da certificação?

Índice. Como aceder ao serviço de Certificação PME? Como efectuar uma operação de renovação da certificação? Índice Como aceder ao serviço de Certificação PME? Como efectuar uma operação de renovação da certificação? Como efectuar uma operação de confirmação de estimativas? Como aceder ao Serviço de Certificação

Leia mais

Trabalhos Práticos. Programação II Curso: Engª Electrotécnica - Electrónica e Computadores

Trabalhos Práticos. Programação II Curso: Engª Electrotécnica - Electrónica e Computadores Trabalhos Práticos Programação II Curso: Engª Electrotécnica - Electrónica e Computadores 1. Objectivos 2. Calendarização 3. Normas 3.1 Relatório 3.2 Avaliação 4. Propostas Na disciplina de Programação

Leia mais

IV Fórum do Sector Segurador e Fundos de Pensões. Lisboa, 15 de Abril de 2009

IV Fórum do Sector Segurador e Fundos de Pensões. Lisboa, 15 de Abril de 2009 IV Fórum do Sector Segurador e Fundos de Pensões Lisboa, 15 de Abril de 2009 Foi com todo o gosto e enorme interesse que aceitei o convite do Diário Económico para estar presente neste IV Fórum do sector

Leia mais

Gestão do Risco e da Qualidade no Desenvolvimento de Software

Gestão do Risco e da Qualidade no Desenvolvimento de Software Gestão do Risco e da Qualidade no Desenvolvimento de Software Questionário Taxinómico do Software Engineering Institute António Miguel 1. Constrangimentos do Projecto Os Constrangimentos ao Projecto referem-se

Leia mais

ARTIGO TÉCNICO. Os objectivos do Projecto passam por:

ARTIGO TÉCNICO. Os objectivos do Projecto passam por: A metodologia do Projecto SMART MED PARKS ARTIGO TÉCNICO O Projecto SMART MED PARKS teve o seu início em Fevereiro de 2013, com o objetivo de facultar uma ferramenta analítica de confiança para apoiar

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

Á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

PHC dteamcontrol Interno

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

Leia mais

Curso de Graduação em Administração. Administração da Produção e Operações I

Curso de Graduação em Administração. Administração da Produção e Operações I Curso de Graduação em Administração Administração da Produção e Operações I 22º Encontro - 11/05/2012 18:50 às 20:30h COMO SERÁ NOSSO ENCONTRO HOJE? - ABERTURA - CAPACIDADE E TURNOS DE TRABALHO. 02 Introdução

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

Benefícios Aumento de produtividade; Sincronização directa e sem problemas; Muito fácil de utilizar.

Benefícios Aumento de produtividade; Sincronização directa e sem problemas; Muito fácil de utilizar. Descritivo completo 2007 Se os seus vendedores precisam saber e actualizar as suas visitas e obter informação sobre os clientes e prospects quando estão no terreno, então esta é a solução ideal para si.

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

ARCO - Associação Recreativa dos Correios. Sistema para Gerenciamento de Associações Recreativas Plano de Desenvolvimento de Software Versão <1.

ARCO - Associação Recreativa dos Correios. Sistema para Gerenciamento de Associações Recreativas Plano de Desenvolvimento de Software Versão <1. ARCO - Associação Recreativa dos Correios Sistema para Gerenciamento de Associações Recreativas Versão Histórico da Revisão Data Versão Descrição Autor Página

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

GereComSaber. Disciplina de Desenvolvimento de Sistemas de Software. Sistema de Gestão de Serviços em Condomínios

GereComSaber. Disciplina de Desenvolvimento de Sistemas de Software. Sistema de Gestão de Serviços em Condomínios Universidade do Minho Conselho de Cursos de Engenharia Licenciatura em Engenharia Informática 3ºAno Disciplina de Desenvolvimento de Sistemas de Software Ano Lectivo de 2009/2010 GereComSaber Sistema de

Leia mais

A Gestão, os Sistemas de Informação e a Informação nas Organizações

A Gestão, os Sistemas de Informação e a Informação nas Organizações Introdução: Os Sistemas de Informação (SI) enquanto assunto de gestão têm cerca de 30 anos de idade e a sua evolução ao longo destes últimos anos tem sido tão dramática como irregular. A importância dos

Leia mais

METODOLOGIA DE DESENVOLVIMENTO DE SOFTWARE DO MUSEU PARAENSE EMÍLIO GOELDI

METODOLOGIA DE DESENVOLVIMENTO DE SOFTWARE DO MUSEU PARAENSE EMÍLIO GOELDI METODOLOGIA DE DESENVOLVIMENTO DE SOFTWARE DO MUSEU PARAENSE EMÍLIO GOELDI HISTÓRICO DE REVISÕES Data Versão Descrição Autor 02/04/2014 1.0 Versão Inicial Ewertton Bravo 27/08/2014 1.1 Alteração da Imagem

Leia mais

w w w. y e l l o w s c i r e. p t

w w w. y e l l o w s c i r e. p t consultoria e soluções informáticas w w w. y e l l o w s c i r e. p t A YellowScire iniciou a sua atividade em Janeiro de 2003, é uma empresa de consultoria de gestão e de desenvolvimento em tecnologias

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

Enquadramento 02. Justificação 02. Metodologia de implementação 02. Destinatários 02. Sessões formativas 03

Enquadramento 02. Justificação 02. Metodologia de implementação 02. Destinatários 02. Sessões formativas 03 criação de empresas em espaço rural guia metodológico para criação e apropriação 0 Enquadramento 02 Justificação 02 de implementação 02 Destinatários 02 Sessões formativas 03 Módulos 03 1 e instrumentos

Leia mais

AUTOR: DAVID DE MIRANDA RODRIGUES CONTATO: davidmr@ifce.edu.br CURSO FIC DE PROGRAMADOR WEB VERSÃO: 1.0

AUTOR: DAVID DE MIRANDA RODRIGUES CONTATO: davidmr@ifce.edu.br CURSO FIC DE PROGRAMADOR WEB VERSÃO: 1.0 AUTOR: DAVID DE MIRANDA RODRIGUES CONTATO: davidmr@ifce.edu.br CURSO FIC DE PROGRAMADOR WEB VERSÃO: 1.0 SUMÁRIO 1 Conceitos Básicos... 3 1.1 O que é Software?... 3 1.2 Situações Críticas no desenvolvimento

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

Arquitecturas de Software Licenciatura em Engenharia Informática e de Computadores

Arquitecturas de Software Licenciatura em Engenharia Informática e de Computadores UNIVERSIDADE TÉCNICA DE LISBOA INSTITUTO SUPERIOR TÉCNICO Arquitecturas de Software Licenciatura em Engenharia Informática e de Computadores Primeiro Teste 21 de Outubro de 2006, 9:00H 10:30H Nome: Número:

Leia mais

FrontWave Engenharia e Consultadoria, S.A.

FrontWave Engenharia e Consultadoria, S.A. 01. APRESENTAÇÃO DA EMPRESA 2 01. Apresentação da empresa é uma empresa criada em 2001 como spin-off do Instituto Superior Técnico (IST). Desenvolve tecnologias e metodologias de inovação para rentabilizar

Leia mais

Regulamento Institucional do Serviço de Apoio Psicopedagógico SAPP

Regulamento Institucional do Serviço de Apoio Psicopedagógico SAPP Regulamento Institucional do Serviço de Apoio Psicopedagógico SAPP Regulamento Institucional do Serviço de Apoio Psicopedagógico SAPP Art. 1 - Do serviço de apoio Psicopedagógico - SAPP O serviço de apoio

Leia mais

Sistemas de Informação I

Sistemas de Informação I + Sistemas de Informação I Extreme Programming I Ricardo de Sousa Britto rbritto@ufpi.edu.br Você gostaria de trabalhar assim? Análise de Requisitos Longe de acordo Requerimentos Complexo Anarquia Perto

Leia mais

Seção 2/E Monitoramento, Avaliação e Aprendizagem

Seção 2/E Monitoramento, Avaliação e Aprendizagem Seção 2/E Monitoramento, Avaliação e Aprendizagem www.bettercotton.org Orientação Text to go here O documento Monitoramento, Avaliação e Aprendizagem da BCI proporciona uma estrutura para medir as mudanças

Leia mais

Gestão da Qualidade. Identificação e Quantificação de Indicadores de Desempenho nos SGQ. 09-12-2009 11:12 Natacha Pereira & Sibila Costa 1

Gestão da Qualidade. Identificação e Quantificação de Indicadores de Desempenho nos SGQ. 09-12-2009 11:12 Natacha Pereira & Sibila Costa 1 Gestão da Qualidade Identificação e Quantificação de Indicadores de Desempenho nos SGQ 09-12-2009 11:12 Natacha Pereira & Sibila Costa 1 Indicador de Desempenho definição Um Indicador de Desempenho é uma

Leia mais

DEMONSTRAÇÕES FINANCEIRAS COMBINADAS

DEMONSTRAÇÕES FINANCEIRAS COMBINADAS 24 DEMONSTRAÇÕES FINANCEIRAS COMBINADAS Os mercados de capitais na Europa e no mundo exigem informações financeiras significativas, confiáveis, relevantes e comparáveis sobre os emitentes de valores mobiliários.

Leia mais

Resumo artigo Agile Modeling- Overview

Resumo artigo Agile Modeling- Overview Universidade Federal de Santa Catarina Centro Tecnológico Disciplina: Projetos I Aluno: Diogo Ludvig 0313812-7 Resumo artigo Agile Modeling- Overview Este trabalho se refere ao resumo do artigo Agile Modeling,

Leia mais

OFICIAL DA ORDEM MILITAR DE CRISTO MEDALHA DE EDUCAÇÃO FÍSICA E BONS SERVIÇOS. Circular n.º 023-A/2014 Portal F.P.T. - Inscrições (Aditamento)

OFICIAL DA ORDEM MILITAR DE CRISTO MEDALHA DE EDUCAÇÃO FÍSICA E BONS SERVIÇOS. Circular n.º 023-A/2014 Portal F.P.T. - Inscrições (Aditamento) Circular n.º 023-A/2014 Portal F.P.T. - Inscrições (Aditamento) Exmo. Sr. Presidente, A Direcção da F.P.T. tem emitido, ao longo dos últimos meses, diversas Circulares, com o objectivo de ir informando,

Leia mais

SCRUM. Otimizando projetos. Adilson Taub Júnior tecproit.com.br

SCRUM. Otimizando projetos. Adilson Taub Júnior tecproit.com.br SCRUM Otimizando projetos Adilson Taub Júnior tecproit.com.br Sobre mim Adilson Taub Júnior Gerente de Processos Certified ScrumMaster; ITIL Certified; Cobit Certified; 8+ anos experiência com TI Especialista

Leia mais

Procedimento de Gestão PG 01 Gestão do SGQ

Procedimento de Gestão PG 01 Gestão do SGQ Índice 1.0. Objectivo. 2 2.0. Campo de aplicação... 2 3.0. Referências e definições....... 2 4.0. Responsabilidades... 3 5.0. Procedimento... 4 5.1. Política da Qualidade 4 5.2. Processos de gestão do

Leia mais

ANÁLISE COMPARATIVA ENTRE OS MODELOS DE PROCESSO: PROTOTIPAÇÃO, PSP E SCRUM

ANÁLISE COMPARATIVA ENTRE OS MODELOS DE PROCESSO: PROTOTIPAÇÃO, PSP E SCRUM ANÁLISE COMPARATIVA ENTRE OS MODELOS DE PROCESSO: PROTOTIPAÇÃO, PSP E SCRUM Peterson Vieira Salme 1, Claudete Werner 1 1 Universidade Paranaense (UNIPAR) Paranavaí PR Brasil petersonsalme@gmail.com, claudete@unipar.br

Leia mais

Múltiplos Estágios processo com três estágios Inquérito de Satisfação Fase II

Múltiplos Estágios processo com três estágios Inquérito de Satisfação Fase II O seguinte exercício contempla um processo com três estágios. Baseia-se no Inquérito de Satisfação Fase II, sendo, por isso, essencial compreender primeiro o problema antes de começar o tutorial. 1 1.

Leia mais

Ministério das Finanças Instituto de Informática. Departamento de Sistemas de Informação

Ministério das Finanças Instituto de Informática. Departamento de Sistemas de Informação Ministério das Finanças Instituto de Informática Departamento de Sistemas de Informação Assiduidade para Calendários Específicos Junho 2010 Versão 6.0-2010 SUMÁRIO 1 OBJECTIVO 4 2 ECRÃ ELIMINADO 4 3 NOVOS

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

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

Prognos SMART OPTIMIZATION

Prognos SMART OPTIMIZATION Prognos SMART OPTIMIZATION A resposta aos seus desafios Menos estimativas e mais controlo na distribuição A ISA desenvolveu um novo software que permite o acesso a dados remotos. Através de informação

Leia mais

Manual de administração

Manual de administração Manual de administração Como fazer outsourcing dos sistemas de informação Índice Introdução Passo 1 - Definir o enquadramento Passo 2 - Analisar os recursos e serviços internos Passo 3 - Analisar os recursos

Leia mais

por João Gomes, Director Executivo do Instituto de Planeamento e Desenvolvimento do Turismo e Professor Associado da Universidade Fernando Pessoa

por João Gomes, Director Executivo do Instituto de Planeamento e Desenvolvimento do Turismo e Professor Associado da Universidade Fernando Pessoa COMO AUMENTAR AS RECEITAS DE UM NEGÓCIO: O CONCEITO DE GESTÃO DE RECEITAS (revenue management) (Publicado na Revista Hotéis de Portugal Maio/Junho 2004) por João Gomes, Director Executivo do Instituto

Leia mais

INSPECÇÃO-GERAL DA EDUCAÇÃO PROGRAMA AFERIÇÃO

INSPECÇÃO-GERAL DA EDUCAÇÃO PROGRAMA AFERIÇÃO INSPECÇÃO-GERAL DA EDUCAÇÃO PROGRAMA AFERIÇÃO EFECTIVIDADE DA AUTO-AVALIAÇÃO DAS ESCOLAS PROJECTO ESSE Orientações para as visitas às escolas 1 Introdução As visitas às escolas realizadas segundo o modelo

Leia mais

DEPARTAMENTO DE MATEMÁTICA E CIÊNCIAS EXPERIMENTAIS

DEPARTAMENTO DE MATEMÁTICA E CIÊNCIAS EXPERIMENTAIS DEPARTAMENTO DE MATEMÁTICA E CIÊNCIAS EXPERIMENTAIS Planificação Anual da Disciplina de TIC Módulos 1,2,3-10.ºD CURSO PROFISSIONAL DE TÉCNICO DE APOIO À GESTÃO DESPORTIVA Ano Letivo 2015-2016 Manual adotado:

Leia mais

XP extreme Programming, uma metodologia ágil para desenvolvimento de software. Equipe WEB Cercomp web@cercomp.ufg.br

XP extreme Programming, uma metodologia ágil para desenvolvimento de software. Equipe WEB Cercomp web@cercomp.ufg.br XP extreme Programming, uma metodologia ágil para desenvolvimento de software. Equipe WEB Cercomp web@cercomp.ufg.br Introdução Criada por Kent Baeck em 1996 durante o projeto Daimler Chrysler. O sucesso

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

Como organizar um processo de planejamento estratégico

Como organizar um processo de planejamento estratégico Como organizar um processo de planejamento estratégico Introdução Planejamento estratégico é o processo que fixa as grandes orientações que permitem às empresas modificar, melhorar ou fortalecer a sua

Leia mais