1

O impacto da metodologia de desenvolvimento de software GEM na competitividade em equipas

de home-banking

Estudo de caso: Espírito Santo Informática

Bruno de Sousa Costa Marques Coelho

Projeto de Tese de Mestrado em Gestão / 7ª edição

Orientador: Professor Doutor Nuno Goulart Brandão

Co-Orientador: Professor Dr. José Lopes Costa

Lisboa

2012

2

Índice Geral

1 - Título e Subtítulo Provisório .......................................................................... 4

2 - Tema ............................................................................................................. 4

3 - Objetivos da Investigação ............................................................................. 4

4 - Problemática de Partida ................................................................................ 4

5 - Estado da Arte .............................................................................................. 7

5.1 – Teorias de Liderança ............................................................................. 7

5.1.1 – Teoria dos Traços dos Líderes ........................................................ 7

5.1.2 – Liderança Comportamental ............................................................. 8

5.1.3 – Liderança Servidora ........................................................................ 8

5.1.4 – Liderança Situacional .................................................................... 11

5.1.5 – Liderança Transformacional .......................................................... 12

5.2 – Metodologias de Desenvolvimento de Software .................................. 15

5.2.1 – Scrum ............................................................................................ 19

5.2.2 – Lean IT .......................................................................................... 20

6 - Esboço das Hipóteses em Investigação ..................................................... 24

7 - Metodologia ................................................................................................. 24

7.1 - Enquadramento da Empresa ................................................................ 24

7.2 - Estratégia Metodológica ....................................................................... 25

8 - Relevância da Investigação ........................................................................ 26

9 - Índice Geral (provisório) da Investigação .................................................... 26

10 - Bibliografia ................................................................................................ 28

10.1 – Referências Bibliográficas ................................................................. 28

10.2 – Webgrafia .......................................................................................... 30

10.2 – A consultar ......................................................................................... 30

11 - Planeamento (Cronograma) da Investigação ............................................ 31

12 - Orientador / Co-Orientador ........................................................................ 31

3

Índice de Figuras

Figura 1 – Evolução dos indicadores do Chaos Report desde 1994 até 2009 ... 5

Figura 2 – Fatores críticos de Sucesso de um projeto ....................................... 5

Figura 3 - Fatores críticos de Sucesso do Chaos Report de 2009 ..................... 6

Figura 4 – Lucros Southwest em 2004 ............................................................... 9

Figura 5 – Adaptado de Blanchard e Hersey (1986) ........................................ 11

Figura 6 - O quadro geral de um projeto de desenvolvimento de software. ..... 15

Figura 7 - A metodologia Waterfall segundo Royce ......................................... 17

Figura 8 - Os princípios Lean organizados numa pirâmide .............................. 22

Figura 9 - A pirâmide organizacional invertida do Lean ................................... 23

Figura 10 - Estrutura Empresarial da Espírito Santo Informática ..................... 25

Índice de TabelasÍndice de TabelasÍndice de TabelasÍndice de Tabelas

Tabela 1 - Indústria de Software vs Indústria Tradicional ................................. 16

4

1 - Título e Subtítulo Provisório

O impacto da metodologia de desenvolvimento de software GEM na competitividade em equipas de home-banking Estudo de caso: Espírito Santo Informática

2 - Tema

Liderança e Metodologias de Desenvolvimento de Software.

3 - Objetivos da Investigação

A investigação será baseada num estudo de caso sobre a equipa responsável pelos Canais Diretos, do sistema de home-banking,1 do Banco Espírito Santo (BES)

Os objetivos da investigação são, resumidamente, os seguintes:

• Analisar o impacto que a metodologia de desenvolvimento de software (GoTo Evolution – GEM) teve na produtividade e competitividade de uma equipa de desenvolvimento de software, nomeadamente ao nível dos indicadores on-time2, on-budget3 e on-target4 dos projetos realizados entre 2010 e 2011;

• Perceber o contributo da Liderança para na implementação da metodologia GEM.

4 - Problemática de Partida

A Standish Group International (SGI) é uma empresa, formada em 1985, que se dedica a investigar o desempenho dos projetos de desenvolvimento de software e a razão pela qual eles falham.

Segundo a SGI (2001:2), as definições de um projeto ter sucesso, ser um falhanço e ou ser desafiado são as seguintes:

• Sucesso: entregar um projeto on-time, on-budget e com os requisitos desejados

• Desafiado: atrasado, para além do orçamentado e/ou com menos requisitos do que o combinado

1 Aplicação alojada na web que permite a um cliente de uma instituição bancária realizar operações sobre as contas que controla 2 on-time significa dentro do prazo combinado com o cliente 3 on-budget significa dentro do orçamento disponível para o projecto 4 on-target significa entregar os requisitos funcionais que o cliente pediu

5

• Falhanço: cancelado antes de ter sido concluído ou entregue e nunca usado.

Apesar das décadas de experiência a desenvolver software, ainda em 2009, as empresas de desenvolvimento de software apenas conseguiram que 32% dos seus projetos tivessem Sucesso! Historicamente, a percentagem de sucesso nunca ultrapassou os 35% desde 1994 (SGI, 2009).

Figura 1 – Evolução dos indicadores do Chaos Report desde 1994 até 2009

Fonte: SGI (2009)

O Chaos Report (SGI, 2001) indica também os dez fatores críticos de sucesso dos projetos de desenvolvimento de software. Os primeiros quatro fatores de 2001 contribuem em 60% para o Sucesso do projeto e estão focados em fatores humanos, nomeadamente a liderança.

Figura 2 – Fatores críticos de Sucesso de um projeto

Fonte: SGI (2001, p. 4)

Em 2009, os quatro primeiros fatores críticos de Sucesso representam 61% (SGI, 2009). Mais uma vez, os fatores são baseados em questões de liderança do que no know-how específico sobre desenvolvimento de software.

6

Figura 3 - Fatores críticos de Sucesso do Chaos Report de 2009

Fonte: (SIG, 2009)

Os dados do Chaos Report da Standish Group (SGI, 2009) revelam que as metodologias atuais, não estão a conseguir responder às necessidades tanto das equipas de desenvolvimento como dos clientes e utilizadores do software.

As metodologias atuais de desenvolvimento de software não são competitivas porque não estão focadas em melhorar o desempenho da equipa ou em inovar. Desta forma, projetos com caraterísticas semelhantes não são desenvolvidos nem em menos tempo nem melhores que os anteriores.

Como não conseguem determinar se é necessário ou não intervir sobre o funcionamento normal da equipa, as metodologias correntes introduzem ainda ineficiências no seu processo de desenvolvimento. Uma das ineficiências é a criação de reuniões obrigatórias diárias, onde toda a equipa pára para tentar determinar se existe algum desvio face ao planeado, mesmo quando esse desvio foi justificado e é benéfico para o cliente. Isto implica que mesmo quando tudo corre como planeado: a equipa pára.

A motivação da equipa de desenvolvimento, algo essencial para criar e manter a energia necessária para ter um desempenho acima da média, não é trabalhada pelas metodologias de software atuais. Nestes casos, os elementos da equipa sentem que estão envolvidos em algo que está a ser feito para eles e não com eles.

A avaliação do desempenho individual, que é essencial não só para reconhecer quem está a contribuir positivamente para o sucesso da equipa mas também para ajudar ou redirecionar os esforços de quem não está a conseguir, não está incluído nas metodologias atuais.

7

5 - Estado da Arte

A globalização e a revolução tecnológica levaram o Mundo a negociar num contexto económico extremamente competitivo. O mercado onde as equipas de desenvolvimento de software estão inseridas não é exceção.

Neste tipo de realidade económica, a liderança desempenha um papel fundamental no sucesso das equipas de desenvolvimento de software.

5.1 – Teorias de Liderança

5.1.1 – Teoria dos Traços dos Líderes Uma das primeiras teorias sobre liderança é a Teoria do “Homem Extraordinário” estudada pelo Historiador Thomas Carlyle (2001).

Para Carlyle (2001, p. 5), “a História Universal, a história do que o homem concretizou neste mundo, é no fundo a História dos Homens Extraordinários que trabalharam aqui. Eles foram líderes de homens, estas pessoas extraordinárias; os modeladores, os padrões e, num sentido lato, criadores do que quer que seja que a massa geral de homens conseguiu fazer ou alcançar; todas as coisas que nós vemos erguidas e realizadas no mundo são propriamente o resultado material externo, a realização prática e a personificação dos Pensamentos que habitavam nos Homens Extraordinários enviados ao mundo; a alma da história de todo o mundo, pode ser justificadamente considerada, a história destes.”

As investigações relacionadas com esta teoria levaram a que os investigadores se concentrassem no estudo das caraterísticas dos líderes que, por sua vez, resultou na criação da teoria com mesmo nome – a Teoria dos Traços dos Líderes (Kirkpatrick e Locke, 1991).

Esta teoria assume que os líderes detêm um conjunto de caraterísticas especiais que os permitem estar preparados para assumir este papel.

Kirkpatrick e Locke, investigadores desta teoria, identificaram seis traços únicos dos líderes, a saber: “(1) a força, composta pela concretização, ambição, energia, tenacidade e iniciativa; (2) a motivação para liderar; (3) a honestidade e integridade; (4) a autoconfiança e a habilidade cognitiva; (5) o conhecimento do negócio; (6) e outros traços, tais como, o carisma, a criatividade, a originalidade e a flexibilidade” (Kirkpatrick & Locke, 1991 : 49-56).

8

Recentemente, Jim Collins (2001, p. 21) identificou a Humildade e Dedicação como duas caraterísticas fundamentais dos Líderes de Nível 55. Este tipo de líderes “canalizam as necessidades do seu ego para longe deles e para o objetivo maior de construir uma empresa extraordinária. Isto não quer dizer que os Líderes de Nível 5 não tenham ego ou interesse em si próprios. Na verdade, eles são incrivelmente ambiciosos – mas a sua ambição é acima de tudo e em primeiro lugar para a instituição, não para eles.”

No entanto, apesar de Jim Collins (2001) referir que estes líderes não estão focados neles próprios é importante referir que os alvos do foco destes líderes (os seus valores, o seu trabalho, a sua empresa e a causa) representam quem eles são. Tal como o pintor orgulhoso não aponta para si próprio, mas sim para os quadros que representam quem ele é, o Líder de Nível 5 aponta para aquilo que o representa – os resultados que a sua empresa atingiu.

5.1.2 – Liderança Comportamental As teorias de liderança que baseavam-se em caraterísticas inatas dos líderes para justificar o impacto das suas ações, foram alvo de críticas por parte de alguns investigadores. Foram realizadas novas investigações com o objetivo de estudar não os traços dos líderes, mas antes o seu comportamento. Estes investigadores acreditavam que se conseguissem identificar os padrões comportamentais chave dos líderes extraordinários, conseguiriam fazer com que a liderança pudesse ser ensinada. Assim, surgiu a Teoria da Liderança Comportamental (Blanchard & Johnson, The One Minute Manager, 2003).

Ken Blanchard e Spencer Johnson (2003) criaram uma teoria de liderança conhecida como Gestão-Minuto (One Minute Management) que defende que o comportamento de um gestor extraordinário baseia-se em “tirar um minuto extra para garantir que os colaboradores conhecem quais são os seus objetivos; andar pela organização para apanhar alguém a fazer bem as tarefas e dar um elogio de um minuto; garantir que se alguém não está a fazer o que deveria estar, é redirecionado se for um aprendiz ou, se já devia saber como fazer e é um problema de atitude, recebe uma reprimenda num minuto” (Blanchard, 2008).

5.1.3 – Liderança Servidora Dentro das teorias da liderança comportamental existe uma que se foca no papel de servo do líder. Este estilo de liderança, definido pela primeira ver por Robert Greenleaf (1991), é conhecido como Liderança Servidora.

Greenleaf (1991 : 9) diz que “o Líder-Servidor é um servo primeiro. Começa com um desejo natural de, em primeiro lugar, querer servir. Depois a escolha

5 Líderes de Nível 5 é a forma pela qual Jim Collins se refere aos líderes que levaram as suas empresas a passarem de boas a extraordinárias, numa investigação conhecida como “Good to Great”

9

consciente leva-o a aspirar a liderar. Ele é drasticamente diferente da pessoa que é, em primeiro lugar, um líder, talvez devido à necessidade de satisfazer os desejos de poder ou de adquirir bens materiais. Para essa pessoa, servir vai ser uma escolha tomada mais tarde – depois da liderança estar estabelecida.

Como a Liderança Servidora mistura dois conceitos opostos segundo o ponto de vista de liderança tradicional baseado na Autoridade – inspirado no modelo militar e popularizado durante a Era Industrial, alguns investigadores criticaram este estilo.

Quay (1997 : 83) referiu que “é mais inteligente confiar na competição e no equilíbrio de poderes do que confiar que aqueles que estão no poder são justos”. Brumback (1999) classificou a Liderança Servidora como um conjunto de ideias obscuras e impraticáveis (Brumback, 1999). Bridges (1996 : 17) disse que “não existe nada de ‘melhor’ ou ‘mais elevado’ sobre este tipo de liderança. [...] é simplesmente uma ferramenta diferente para uma tarefa diferente”.

Para Blanchard e Hodges (2005), o motivo pelo qual não existem mais líderes a usar este estilo e existirem este tipo de críticas é porque as pessoas estão a confundir dois papéis diferentes do líder: definir a Visão, através da Liderança Estratégica, e garantir a sua Implementação bem-sucedida, através da Liderança Operacional. Enquanto a definição da Visão usa o primeiro papel deste estilo – Liderar, a Implementação usa o segundo – Servir, isto é, garantir que as pessoas responsáveis pela operação têm tudo o que precisam para terem sucesso (Blanchard, 2010).

A Southwest Airlines (2004) é um exemplo que a Liderança Servidora não é uma teoria de liderança impraticável. Na verdade, os resultados obtidos e a competitividade atingida através da utilização deste estilo de liderança são bem reais. Segundo os dados disponíveis no site da empresa:

a) Os lucros da empresa superam em muito os lucros dos seus adversários, ano após ano - durante décadas

Figura 4 – Lucros Southwest em 2004

Fonte: Garryson e Keller (2004 : 6)

10

b) 1.5 biliões de clientes satisfeitos e leais à empresa desde 1971

• Em 21 de Junho de 2011, American Customer Satisfaction Index nomeou Southwest como a melhor no Índice de Transporte para Satisfação do Cliente.

• Em 21 de Maio de 2011, Consumer Reports classificou Southwest Airlines como a melhor Transportadora Aérea no Serviço ao Cliente.

• Em Março de 2011, Keynote Competitive Research classificou southwest.com como a melhor no inquérito de Experiência ao Cliente 2011 para websites de viagens.

• Nomeada vencedora do Prémio Stevie para a Empresa de Transportes do Ano pela International Business Awards pelo extraordinário desempenho e serviço ao cliente.

c) 37000 empregados que adoram trabalhar na empresa

• Em Dezembro de 2010, Southwest Airlines foi classificada como a melhor empresa para trabalhar pela Glassdoor.com., numa lista de 50 melhores lugares nos E.U.A.

• Southwest Airlines foi reconhecida como a Melhor Empregadora numa lista de 100 Military Friendly Employers G.I.Job’s de 2011.

Para além do estudar apenas o comportamento dos líderes, os investigadores de liderança começaram também a analisar como é que o seu comportamento variava em função das situações.

11

5.1.4 – Liderança Situacional Este tipo de teoria de liderança ficou conhecido como Liderança Situacional e foi desenvolvida por Blanchard e Hersey (1986).

Figura 5 – Adaptado de Blanchard e Hersey (1986)

A Liderança Situacional, segundo Blanchard e Hersey (1986) defende que existem quatro estilos de liderança:

● E1 - Dirigir (Telling): os líderes dizem às pessoas exatamente o que fazer e como fazer supervisionando a execução da tarefa;

● E2 - Orientar (Selling): os líderes não dizem simplesmente o que fazer e como fazer. Eles dedicam-se a explicar o que está envolvido nas tarefas “vendendo” a direção tomada de forma a ter o compromisso da equipa para atingir os resultados. Adicionalmente, o líder investe em desenvolver as capacidades da equipa, atuando como um coach (treinador);

● E3 - Apoiar (Participating): os líderes não se focam tanto na direção escolhida mas mais em garantir que a equipa tem acesso aos recursos que precisa para atingirem os resultados, facilitando a tomada de decisões;

● E4 – Delegar (Delegating): os líderes delegam a execução da tarefa inteiramente à equipa, monitorizando o seu progresso e ficam menos envolvidos na tomada de decisões.

12

Cada estilo de liderança, ainda segundo Blanchard e Hersey (1986), deve estar alinhado com o nível de maturidade dos liderados, a saber:

● O Participante empolgado: está empenhado em participar mas não tem os conhecimentos para conseguir realizar a tarefa com sucesso (E1);

● O Aprendiz desiludido: perdeu um pouco do seu empenho porque desiludiu-se com o seu desempenho e com a realidade do seu trabalho. Apesar de já ter desenvolvido algumas capacidades ainda não consegue ter o sucesso desejado na execução das tarefas (E2);

● O Executante capaz mas cauteloso: já tem as capacidades necessárias para realizar as tarefas mas não está completamente confiante que vai ter sucesso ou simplesmente não está disposto ou comprometido a trabalhar na tarefa (E3);

● O Profissional autoconfiante: está comprometido com os objetivos traçados, tem as competências, tem autonomia e confiança suficiente nas suas capacidades de atingir os resultados (E4).

Para além de ser importante identificar qual o grau de maturidade do colaborador para escolher um estilo de liderança, Blanchard e Blanchard (2008), refere que a chave para o sucesso desta abordagem é garantir que o colaborador sabe que está a participar no processo. Por outras palavras, significa que o líder deve garantir que está a fazer isto com os colaboradores e não para eles.

De outro modo podem ocorrer alguns mal entendidos (Blanchard & Blanchard, 2008):

● Por um lado, o participante empolgado pode não perceber porque é que o seu líder está constantemente não só a dizer o que fazer, mas também mostrar como se faz o seu trabalho. Pode confundir com falta de confiança.

● Por outro lado, o executante capaz mas cauteloso pode não perceber porque é que líder está mais distante... Pode pensar que o seu trabalho não é relevante.

Uma das diferenças que Collins (2001) identifica entre os Líderes de Nível 5 e os de 4, é que os primeiros preparam os seus seguidores para evoluírem de modo a conseguirem tomar o seu lugar na organização, fazendo-a crescer e prosperar, enquanto os segundos não o fazem.

5.1.5 – Liderança Transformacional A liderança é então um processo que tem o potencial de transformar as pessoas envolvidas. A teoria que estuda este processo chama-se Teoria Transformacional.

13

Segundo James Burns (1978), a liderança transformacional ocorre quando “líderes e seguidores fazem com que ambos evoluam para um nível mais elevado de moral e motivação”. Ainda segundo o autor “a ação fundamental do líder é induzir nas pessoas a consciência ou a perceção do que eles sentem – para que sintam as suas verdadeiras necessidades de forma tão forte, para definir os seus valores de forma tão significativa, de modo a fazê-los mover em ações com propósito”.

Bernard Bass (1990 : 22) continuou os estudos de Burns e caraterizou a Liderança Transformacional baseando-se em quatro caraterísticas destes líderes:

• Carisma ou Influência Idealizada: a capacidade de se comportar de forma integra para com os seus valores causando não só admiração a um nível emocional como também inspirando confiança nos seguidores;

• Motivação Inspiracional: a capacidade de comunicar uma visão atraente e inspiradora para os seus seguidores. Esta capacidade leva os seguidores a terem um forte sentido de propósito e a estarem motivados a agir;

• Estimulação Intelectual: a capacidade de desafiar o status quo, assumir riscos e promover a capacidade de ultrapassar obstáculos na execução da missão nos seus seguidores;

• Atenção ou Consideração Individualizada: a capacidade do líder de responder às necessidades e receios dos seguidores e de agir como um coach que os ajuda a desenvolver as capacidades de cada um atingir os objetivos.

Enquanto estes investigadores tenderam a focar-se primordialmente na transformação que ocorre nos seguidores, Blanchard e Hodges (2005) focaram-se na transformação que ocorre no líder.

1. O Coração - saber não só quem é mas também de quem é.

Saber quem é implica saber quais são os valores que defende, a visão que tem e a missão que pretende cumprir. Saber de quem é implica saber qual a quem é que o líder responde.

2. A Cabeça - representa o sistema de crenças do Líder e a sua perspetiva das suas funções enquanto líder:

a. Um papel visionário - definir o caminho e o destino. Segundo o dicionário etimológico Merriam-Webster Unabridged, as palavras “lead” (liderar), “leader” (líder) e “leadership” (liderança) partilham a mesma raiz: “to go” (ir).

b. Um papel de implementação - servir ao encarregar e ajudar outros a concretizar a visão

14

3. As Mãos - representam as ações do líder como resultado daquilo que são a sua cabeça e o seu coração. Tal como Peter Drucker (1964) definiu que liderar significa atingir resultados através das pessoas, da mesma forma Blanchard e Hodges (2005) referem que o líder deve ser um perfomance coach6. Para ser um performance coach eficaz existem três partes que devem cumpridas todos os dias:

• Planeamento de desempenho: tanto o líder como o liderado devem concordar e definir qual é o desempenho esperado, o que é suposto atingir e qual o deadline.

• Coaching diário: depois de definido qual é o desempenho esperado, o líder deve garantir que, dia após dia, os seus colaboradores estão alinhados para atingir os objetivos definidos. Por outras palavras, depois de entregar o exame final, o líder encarrega-se de ensinar as respostas aos seus colaboradores.

• Avaliação do desempenho: após ter chegado ao deadline é comparado desempenho esperado com o realizado. Através deste processo é possível identificar o que deve ser repetido e o que deve ser melhorado.

4. Os Hábitos - representam as atividades às quais o líder se dedica de forma consistente.

Liderar é mais do que saber teorias.

Existem líderes que sabem o que é suposto fazerem e que ainda assim não o fazem. Porquê? Porque o que eles sabem que é suposto fazer não está alinhado com o que eles são.

Esta realidade revela-se quando as suas ações diárias não estão alinhadas com aquilo que promovem na teoria. Isto é especialmente notório em situações de elevado stress quando a pressão impede-os de pensar com clareza, acabando por revelar quem realmente são. O resultado final é que a sua autoridade como líder é afetada.

Os líderes extraordinários em situações de stress não precisam de pensar o que fazer. Eles sabem o que fazer porque todos os seus pensamentos, palavras, ações e hábitos até aquele momento, preparam o seu caráter para atingir o seu destino: vencer!

O que fazemos repetidamente representa quem somos. A perfeição é impossível de atingir. No entanto, a excelência é possível atingir porque é o hábito de sistematicamente nos dedicarmos a aperfeiçoar e melhorar quem somos.

6 Treinador de desempenho

15

5.2 – Metodologias de Desenvolvimento de Software

A definição da palavra Metodologia, de acordo com (Lexicoteca, 1985, p. 156), é um “conjunto de regras para o ensino de uma ciência ou arte”.

A diferença entre Método e Metodologia, segundo Royce (1998), é que um método “é um conjunto razoavelmente completo de regras e critérios que estabelecem uma maneira precisa e repetível de desempenhar uma tarefa e chegar a um resultado pretendido” enquanto uma metodologia é “um conjunto de métodos, procedimentos e padrões que definem uma síntese integrada de abordagens de engenharia para o desenvolvimento de um produto”.

Segundo Cockburn (2000 : 65), as metodologias de desenvolvimento de software podem variar entre “as metodologias m-pequeno, descrevendo algumas técnicas e noções de desenho para alguns papéis” e “as metodologias M-Grande que codificam o máximo possível sobre a maneira de trabalhar – processos, técnicas e os padrões fazendo apenas parte do quadro geral”.

O que Cockburn designa por “quadro geral” é tudo o que está relacionado com um projeto de desenvolvimento de software.

Figura 6 - O quadro geral de um projeto de desenvolvimento de software.

Fonte: Cockburn (2000 : 65)

As caraterísticas da indústria do desenvolvimento de software são diferentes das caraterísticas da indústria tradicional de fabrico de produtos físicos. De acordo com Karlström (2004 : 24), existem seis caraterísticas que as diferenciam:

16

Tabela 1 - Indústria de Software vs Indústria Tradicional

Software Indústria Tradicional Construído uma vez Sempre a ser construído

Custo baixo de reprodução Custo alto de reprodução Muito flexível Inflexível

Intangível Fisicamente presente Cliente frequentemente indeciso Cliente determinado Custo elevado de manutenção Custo de manutenção relativamente

baixo Fonte: Karlström (2004)

O fato do desenvolvimento de software ter um custo de reprodução baixo, ser bastante fléxivel e intangível fez com que, no início dos projetos de desenvolvimento de software, a necessidade de seguir uma determinada metodologia de desenvolvimento não fosse percebida. Este período ficou conhecido pelo mesmo nome do modelo utilizado para desenvolver os projetos: “programa-e-arranja” (code-and-fix). “O programa-e-arranja baseia-se em dois passos: 1) Escrever algum código; 2) Arranjar os problemas do código”. (Boehm, 1998 : 61-62)

As limitações principais do modelo “programa-e-arranja” são: a) o custo de manutenção elevado depois da correção de vários bugs7; b) software rejeitado pelo cliente ou desenvolvido novamente para estar alinhado com as necessidades do cliente; c) o custo elevado das alterações ao código para que este seja testado com sucesso e esteja preparado para evoluir (Boehm, 1998 : 62-63).

As primeiras metodologias de desenvolvimento de software foram desenhadas para responder às caraterísticas da indústria tradicional e às limitações do modelo “programa-e-arranja”.

7 Bug é a designação conhecida no mundo do desenvolvimento de software sempre que existe um comportamento anómalo no programa desenvolvido

17

Figura 7 - A metodologia Waterfall segundo Royce

Fonte: Royce W. (1970)

A metodologia Waterfall, criada em 1970, é um exemplo clássico de uma metodologia preparada para a realidade da indústria tradicional. Na verdade, a metodologia nasceu com Royce (1970 : 329), que admitiu “acreditar no conceito, mas a implementação descrita na figura acima é arriscada e convida o falhanço”.

Ainda assim, ao introduzir as fases de análise de requisitos do sistema, do software e da aplicação antes do desenvolvimento da aplicação, a metodologia Waterfall pretende que o produto final esteja preparado com menos bugs e um custo de manutenção e de evolução baixo. Para além da divisão por fases, adicionou ainda a noção de a) feedback loops entre as etapas e b) a prototipagem no início do cíclo de vida do software. Para Boehm (1998 : 63), a principal desvantagem do modelo Waterfall é a ênfase em ter a documentação completamente elaborada como um critério de término das fases de análise de requisitos.

As Metodologias Ágeis, segundo Karlström (2004 : 35-36) surgiram como uma reação dos processos mais rigorosos utilizados durante o terceiro período dos processos de engenharia de software. O desenvolvimento destes processos ocorreu em paralelo até ao fim dos anos 90. As metodologias mais comuns deste tipo, segundo são:

• Extreme Programming (XP): XP foi criado por Ward Cunningham e Kent Beck e involve 12 práticas que individualmente não são novas para a comunidade de Engenharia de Software. A metodologia tornou-

18

se difundida por volta do ano 2000 e uma versão mais atualizada está atualmente a ser publicada.

• Cockburn’s Crystal Family: Cristal foi desenvolvida por Alistair Cockburn no início dos anos 90 com o foco principal de melhorar a comunicação nos projetos de software. Era pretendido incluir três versões para tamanhos diferentes de projetos, mas apenas a versão mais pequena foi terminada até agora.

• Adaptative Software Development (ASD): ASD foi criada por Jim Highsmith. O método foca-se mais na filosofia por detrás da abordagem de desenvolvimento em vez das práticas individuais. Atualmente é considerada um complemento da Crystal, enquanto que os detalhes na Crystal complementam a filosofia da ASD.

• Scrum: Scrum foi criado por Ken Schwaber. O método é considerado um meta-processo ou ‘invólucro’, independente da metodologia de desenvolvimento a ser usada. É, por exemplo, bastante comum usar-se uma combinação de Scrum e XP.

• Feature Driven Developement (FDD): FDD foi desenvolvida por Jeff De Luca e Peter Coad. FDD é um processo designado para produzir resultados frequentes e tangíveis e é uma coleção das melhores práticas.

• Dynamic System Development Method (DSDM): FDD é uma plataforma focada em entregar uma solução de qualidade rapidademente. O método foca-se especificamente no desenvolvimento incremental, envolvimento do utilizador e fazer o que é mais importante primeiro.”

Os métodos ágeis têm como base os princípios incluídos no Manifesto para o Desenvolvimento Ágil de Software (Beck, et al., 2001):

“Indivíduos e interações mais do que processos e ferramentas;

Software funcional mais do que documentação abrangente;

Colaboração com o cliente mais do que negociação contratual;

Responder à mudança mais do que seguir um plano.

Ou seja, apesar de reconhecermos valor nos itens à direita, valorizamos mais os itens à esquerda.”

Como na organização alvo do caso de estudo, explorado nesta investigação, é usado Scrum e LEAN IT, estas metodologias são exploradas em maior detalhe nesta revisão teórica.

19

5.2.1 – Scrum Segundo o seu guia oficial, descrito por Schwaber & Sutherland (2011 : 3), o Scrum é definido como “uma plataforma através da qual as pessoas podem trabalhar problemas adaptativos complexos, enquanto entregam, de forma produtiva e criativa, produtos com o maior valor possível.”

As fundações do Scrum são a teoria empírica de controlo de processos, ou empirismo. Esta teoria defende que o conhecimento surge da experiência e da tomada de decisões baseando-se no que é conhecido (Schwaber & Sutherland, 2011 : 4).

O Scrum tem três pilares:

• Transparência: os aspetos significativos do processo devem ser visíveis pelos responsáveis da entrega. A transparência requer ainda que exista um padrão comum para que os observadores partilhem um entendimento comum (por exemplo: é importante que exista uma definição do que consiste uma tarefa estar “Concluída” (“Done”);

• Inspeção: as entregas devem ser inspecionadas para garantir que existe progresso em direção ao objetivo traçado ou detetar eventuais desvios;

• Adaptação: ao ser detetado um desvio fora dos limites aceitáveis, de tal forma que o seu produto seja inaceitável, deve ser realizado um ajustamento o mais depressa possível para minimizar desvios adicionais. (Schwaber & Sutherland, 2011 : 4)

A Equipa do Scrum, segundo (Schwaber & Sutherland, 2011 : 5-6,) é constituída pelo Dono do Produto, a Equipa de Desenvolvimento e o Mestre Scrum (Scrum Master).

As Equipas do Scrum pretendem ser “multifuncionais contendo todas as competências necessárias para concretizar o trabalho sem depender de outros fora da equipa”.

O Dono do Produto “é o responsável por maximizar o valor do produto e do trabalho da Equipa de Desenvolvimento e é o único com poderes de gestão sobre o Product Backlog8. As suas decisões são visíveis no conteúdo e na ordenação do Product Backlog. Ninguém está autorizado a dizer à Equipa de Desenvolvimento para trabalhar num conjunto diferente de requisitos, e a Equipa de Desenvolvimento não está autorizada a agir sobre o que qualquer outra pessoa disser”.

8 Product Backlog - “uma lista ordenada de tudo o que poderá ser necessário no produto e é única fonte de requisitos para quaisquer alterações a serem feitas no produto” (Schwaber & Sutherland, 2011, p. 12).

20

A Equipa de Desenvolvimento “é constituída por profissionais trabalham para entregar um potencial Incremento ‘Concluído’ do Produto no final de cada Sprint9”. A dimensão das equipas não deve ser menor que três, porque diminui a interação e os ganhos de produtividade são menores, e não devem ser maiores que nove elementos, porque mais requer demasiada coordenação.

O Mestre Scrum (Scrum Master) “é responsável para que o Scrum seja compreendido e praticado, garantindo que a Equipa adere à teoria, prática e regras”. E pela primeira vez, na definição de uma metodologia de desenvolvimento de software, aparece uma referência ao papel da liderança: “o Mestre Scrum é o Líder-Servidor para a Equipa Scrum” (Schwaber & Sutherland, 2011, p. 6). O raio de ação do Mestre Scrum não se restringe apenas à sua equipa porque ele “ajuda os que estão fora da Equipa Scrum a compreender quais das suas interações com a Equipa Scrum são úteis e quais não são”.

O Sprint “é o coração do Scrum e representa um período de tempo de um mês ou menos onde é criado um potencial Incremento ‘Concluído’ do produto. Durante o Sprint não são feitas alterações que afetem o Objetivo do Sprint; a composição da Equipa de Desenvolvimento mantém-se constante; os objetivos de qualidade não diminuem; e o âmbito pode ser clarificado e renegociado entre o Dono do Produto e a Equipa de Desenvolvimento enquanto mais coisas são aprendidas. Um Sprint pode ser cancelado se o Objetivo do Sprint tornar-se obsoleto”.

A noção que uma equipa tem todas as competências para realizar o trabalho mais a sugestão de que o seu tamanho varie entre três e nove elementos, representam uma limitação da aplicabilidade do Scrum. No caso da ESI, estudado na parte prática da tese, existem várias equipas que controlam partes diferentes dos sistemas informáticos do BES. São raros os desenvolvimentos em que não é necessário a participação de uma ou mais equipas para conseguir desenhar, criar e integrar todos os componentes necessários para entregar o projeto que o cliente pretende.

Ao não estar preparado para a colaboração entre equipas, por preferir equipas pequenas e por favorecer períodos de desenvolvimento sem alterações de tarefas, o Scrum não está preparado ser aplicado num ambiente de desenvolvimento empresarial sofisticado (Schwaber & Sutherland, 2011 : 5-8).

5.2.2 – Lean IT Segundo Bell e Orzen (2011), o Lean IT “é muito mais que um conjunto de ferramentas e de práticas; é uma transformação cultural e comportamental profunda que encoraja todos na organização a pensar diferente sobre o papel da informação de qualidade na criação e entrega de valor para o cliente”.

21

A definição de Lean IT segundo Stephen Ruffa (2011 : 14) mantém a mesma orientação, acrescentando ainda que “tornar-se lean é muito mais do que ser bem-sucedido no corte de custos diários – o alvo mais frequente desde tipo de ferramentas e práticas. Em vez disso, requer a construção de capacidades dinâmicas que promovam a estabilidade e consistência, mesmo no meio das condições incertas e em constante mudança de hoje, para que estes resultados sejam possíveis”.

A implementação do Lean IT, segundo as definições apresentadas anteriormente, requer que toda a organização esteja unida e alinhada no mesmo sentido. No entanto, as entrevistas realizadas durante a investigação de Stephen Ruffa identificaram que “apesar da enorme popularidade do Lean entre os executivos e praticantes, existe uma divisão tremenda entre eles e os que estão na força de trabalho e mesmo entre os gestores de nível intermédio”. Uma das razões para esta divisão está na “atenção que é colocada nas ferramentas e técnicas individuais – muitas vezes sem muito foco nos aspetos mais profundos e transformacionais que os métodos Lean tinham a intenção de avançar”. O resultado desta disparidade entre a realidade e a teoria é a inconsistência na implementação do Lean e um nível elevado de frustração (Ruffa, 2011 : 1 - 2).

Para aumentar as probabilidades de sucesso de uma implementação do Lean numa organização é necessário “enfatizar os princípios sobre as ferramentas (Bell & Orzen, 2011)”.

O Lean nasceu e tornou-se popular na Toyota, durante os anos 90, resultado do desempenho fenomenal da empresa (Jones & Roos, 1990). Um dos líderes que criou esta metodologia que ajudou não só a Toyota mas várias empresas da indústria Japonesa, foi Edwards Deming (Noguchi, 1995).

Deming (1986) publicou catorze princípios chave em que os gestores se deviam concentrar para transformarem as suas organizações.

1. “Criar consistência de propósito direcionado para a melhoria do produto e serviço, com o objetivo de se tornar competitivo, permanecer no negócio e para criar emprego.

2. Adoptar a nova filosofia. Nós estamos numa nova era económica. A gestão do ocidente deve despertar para o desafio, deve aprender as suas responsabilidades, e entrar na liderança da mudança.

3. Terminar a dependência na Inspeção para atingir qualidade. Eliminar a necessidade de Inspeção massiva criando qualidade no produto em primeiro lugar.

4. Terminar a prática de premiar negócio baseado no preço. Em vez disso, minimizar o custo total. Avançar para um único fornecedor para cada item, numa relação de lealdade e confiança de longo-termo.

22

5. Melhorar constantemente e para sempre o sistema de produção e serviço, para melhorar a qualidade e produtividade, e consequentemente diminuir os custos constantemente.

6. Instituir o treino no trabalho. 7. Instituir liderança. O objetivo da supervisão deve ser ajudar pessoas,

máquinas e aparelhos a fazer um melhor trabalho. Supervisão da gestão está a precisar de uma remodelação, tal como a supervisão dos trabalhadores de produção.

8. Eliminar o medo, para que todos possam trabalhar eficazmente na empresa.

9. Remover barreiras entre departamentos. Pessoas na investigação, design, vendas, e produção devem trabalhar como uma equipa, para preverem problemas de produção e de utilização que possam ser encontrados no produto ou serviço.

10. Eliminar slogans, exortações e alvos para a força de trabalho a pedir zero defects e novos níveis de produtividade. Esse tipo de exortações apenas cria relações adversárias, como a maioria das causas de baixa qualidade e baixa produtividade pertencem ao sistema e por isso estão para além do poder da força de trabalho.

11. Eliminar os padrões de trabalho (quotas) ao nível da fábrica. Substituir por liderança. Eliminar gestão por objetivos. Eliminar gestão por números e objetivos numéricos. Em vez disso, substituir por liderança.

12. Remover barreiras que roubam o trabalhador “à hora” do seu direito ao orgulho do profissionalismo. A responsabilidade dos supervisores deve ser alterada de apenas números para qualidade. Remover barreiras que roubam às pessoas de gestão e de engenharia do seu direito ao orgulho do profissionalismo. Isto significa, inter alia, a abolição da classificação anual de mérito e à gestão por objetivos.

13. ”Instituir um programa vigoroso de edução e de melhoria pessoal. 14. Colocar toda a gente na empresa a trabalhar para concretizar a

transformação. A transformação é o trabalho de todos.”

Bell e Orzen (2011 : 18) ilustraram a pirâmide que deve governar uma organização Lean, sem cargos organizacionais, mas sim princípios:

Figura 8 - Os princípios Lean organizados numa pirâmide

23

Fonte: Bell e Orzen (2011 : 18)

Em termos de pirâmide de gestão, Bell e Orzen partilham da mesma visão de Ken Blanchard (Blanchard, Invert the Pyramid, 2008) quando promovem que a “pirâmide organizacional”10 deve ser invertida (Bell & Orzen, 2011, p. 20).

Figura 9 - A pirâmide organizacional invertida do Lean

Fonte: Bell e Orzen (2011 : 18)

Inverter a pirâmide não quer dizer que os colaboradores passam a controlar ou a gerir a organização. Por outro lado, os consumidores não interagem diretamente com os líderes empresariais nem sabem qual é a Direção

10 A “pirâmide organizacional” é o nome comum que é atribuído à hierarquia tradicional de poder instituída nas organizações

24

Estratégica que estes definiram para a empresa. O que os consumidores sabem é quão bem são servidos pelos colaboradores da empresa. Por estarem a interagir diretamente com o consumidor, os colaboradores estão numa posição privilegiada para comunicar à gestão formas de melhorar o serviço prestado.

A abordagem da inversão da pirâmide pretende transmitir ainda que, tal como foi referido na Liderança Servidora, depois da Liderança definir a Direção Estratégica a pirâmide deve inverter-se para que a função do líder seja estar com os colaboradores de forma a perceber como melhorar, gerar ideias e garantir que eles têm tudo o que precisam para fazer o seu trabalho (Bell & Orzen, 2011 : 20).

Um dos maiores erros que as empresas cometem ao implementarem o Lean é focarem-se demasiado em reduzir custos (Bell & Orzen, 2011 : 143).

6 - Esboço das Hipóteses em Investigação

As hipóteses que vão ser investigadas são as seguintes:

1. A metodologia de desenvolvimento de software GEM contribuiu positivamente para o aumento de produtividade e competitividade da equipa de desenvolvimento dos Canais Diretos da ESI

2. A liderança usada na aplicação do GEM contribuiu para o crescimento dos colaboradores enquanto líderes

7 - Metodologia

7.1 - Enquadramento da Empresa

A Espírito Santo Informática, ACE é um agrupamento complementar de empresas que iniciou a sua atividade em 2006 com o objetivo de gerir os Sistemas de Informação pertencentes aos membros agrupados:

25

Figura 10 - Estrutura Empresarial da Espírito Santo Informática

A ESI tem 5 direções, 65 núcleos e 530 pessoas onde 55% são colaboradores internos da empresa e 45% estão a trabalhar em regime de outsourcing.

Esta investigação vai focar-se numa equipa designada por Canais Diretos, composta por 1 líder de equipa, 5 gestores, 1 arquiteto técnico, 5 coordenadores técnicos, 8 analistas aplicacionais, 5 analistas funcionais e 2 pessoas de apoio à gestão. A metodologia de desenvolvimento de software GEM foi aplicada à equipa técnica mas o seu impacto estendeu-se aos Canais Diretos como um todo.

7.2 - Estratégia Metodológica

A abordagem para a construção de teoria será indutiva com propósito exploratório e descritivo.

A estratégia de investigação corresponde a um estudo de caso sobre a implementação de uma nova metodologia de desenvolvimento de software (GEM), na equipa de home-banking do BES, segundo um horizonte temporal transversal de 2 anos.

A investigação vai usar os seguintes dados qualitativos e quantitativos:

• Análise dos resultados dos projetos realizados pela equipa entre 2010 e 2011;

o Número de projetos realizados o Dimensão dos projetos (em horas) o Dimensão da equipa o Número de projetos entregue on-time o Número de projetos entregue on-budget o Número de projetos entregue on-target

• Observação participante do investigador durante todo o processo de implementação e evolução da metodologia;

• Análise das respostas ao questionário enviado a: o Equipa de desenvolvimento, o Equipa de gestão

26

o Administradores o Clientes do Software produzido

8 - Relevância da Investigação

A relevância desta investigação está diretamente relacionada com os pontos onde a metodologia de desenvolvimento de software GEM pretende superar as metodologias já existentes:

• As taxas de insucesso dos projetos de desenvolvimento de software provam que as metodologias atuais não estão a conseguir cumprir com o seu objetivo principal: fazer com que os projetos tenham sucesso;

• As metodologias de desenvolvimento de software atuais adicionam ineficiências nas equipas afectando a sua competitividade;

• O papel da liderança no crescimento e evolução das equipas não é explorado nas metodologias atuais;

• No contexto atual de globalização e de elevada competitividade económica é essencial encontrar formas de ser mais eficiente e eficaz. O GEM é uma forma de o fazer.

9 - Índice Geral (provisório) da Investigação

Resumo

Abstract

Agradecimentos

Índice

Introdução

Capítulo 1 – A liderança nas empresas

Capítulo 2 – Metodologias de desenvolvimento de software

Capítulo 3 – GEM: GoTo Evolution

2.1 O que é o GEM 2.2 Planeamento 2.3 Desenvolvimento 2.4 Controlo 2.5 Avaliação 2.6 Melhoria Contínua

Capítulo 4 – Metodologia de Investigação

27

4.1 – ESI: a empresa

4.2 – Canais Diretos: a equipa de desenvolvimento

4.3 – Estratégica metodológica

4.3.1 – Dados Secundários

4.3.1.1 – Observação participante do investigador

4.3.1.2 – Análise do desempenho da equipa em 2010 e 2011

4.3.3 – Dados Primários

4.3.3.1 – Questionário enviado à Equipa

4.3.3.2 – Questionário enviado aos clientes da equipa

Capítulo 5 – Análise dos resultados, interpretações e desenvolvimentos futuros

5.1 – Análise, interpretação e considerações sobre o desempenho da equipa

5.1.1 – Ano 2010

5.1.2 – Ano 2011

5.2 – Análise, interpretação e considerações sobre o questionário

5.2.1 – Enviado à equipa

5.2.2 – Enviado aos clientes do trabalho da equipa

5.3 – Desenvolvimentos futuros

Conclusões

Referências Bibliográficas

28

10 - Bibliografia

10.1 – Referências Bibliográficas

ANTOLIC, Z. (s.d.). An Example of Using Key Performance Indicators for Software Development Process Efficiency Evaluation. Zagreb: R&D Center.

BASS, B. (1990). From transactional to transformational leadership: learning to share the vision. Organizational Dynamics, 18 (3).

BELL, S., & ORZEN, M. (2011). Lean IT - Enabling and Sustaining Your Lean Transformation. New York: Taylor & Francis Group.

BLANCHARD, K., & HERSEY, P. (1986). Psicologia para Administradores: a teoria e as técnicas da liderança situacional. São Paulo: EPU.

BLANCHARD, K., & HODGES, P. (2005). Lead like Jesus. Nashville: Thomas Nelson, Inc.

BLANCHARD, K., & JOHNSON, S. (2003). The One Minute Manager. New York: HarperCollins Publishers Inc.

BOEHM, B. (1998). A spiral model of software development and enhancement. TRW Defense Systems Group.

BRIDGES, W. (1996). Leading the de-jobbed organization. In F. Hesselbein, M. Goldsmith, & R. Beckhard, The leader of the future (p. 17). San Francisco: Jossey-Bass.

BRUMBACK, G. (1999). The power of servant leadership, 52 (3). Personal Psychology.

BURNS, J. (1978). Leadership. New York: Harper & Row Publishers.

CARLYLE, T. (2001). On Heroes, Hero-Worship, and The Heroic in History. Pennsylvania: The Pennsylvania State University.

COCKBURN, A. (2000). Selecting a Project’s Methodology. IEEE SOFTWARE, 65.

COLLINS, J. (2001). Good to Great. New York: HarperCollins Publishers Inc.

DEMING, E. (1986). Out of the Crisis. MIT Press.

DRUCKER, P. (1964). Administração lucrativa, 2ªed. São Paulo: Pioneira.

FREIXO, M. (2011). Metodologia Científica: Fundamentos Métodos e Técnicas. Lisboa: Instituto Piaget.

29

GARRISON, & KELLER. (2004). Southwest Airlines Case Study. Cincinnati: Thomas A. Hauck.

GREENLEAF, R. (1991). The Servant as Leader. Indianapolis: The Robert K. Greenleaf Center.

GUEVARA, J., HALL, L., & STEGMAN, E. (2010). IT Key Metrics Data 2011: Key Application Measures: Project Measures: Current Year. Gartner.

HARTMANN, D., & DYMOND, R. (s.d.). Appropiate Agile Measurement: Using Metrics and Diagnostics to Deliver Business Value.

JONES, D., & ROOS, D. (1990). The Machine That Changed the World. New York: Simon & Schuster Inc.

KARLSTRÖM, D. (2004). Integrating Management and Engineering Processes in Software Product Development. Lund.

KIRKPATRICK, S., & Locke, E. (1991). Leadership: do traits matter? Academy of Management Executive, Vol.5, nº2.

LEXICOTECA. (1985). Moderno Dicionário da Língua Portuguesa. Círculo de Leitores.

NOGUCHI, J. (Dezembro de 1995). The Legacy of W. Edwards Deming. Quality Progress, 28 (12), pp. 35-37.

QUAY, J. (1997). On becoming a servant leader, 9 (3). Journal of Management Consulting, 83.

RAMSIN, R. (2006). The Engineering of an Object-Oriented Software Development Methodology. York: The University of York.

ROYCE, W. (1970). Managing the Development of Large Software Systems. The Institute of Electrical and Electronics Engineers, Inc.

ROYCE, W. (1998). Software Project Management - A Unified Approach. Addison-Wesley Longman.

RUFFA, S. (2011). The going Lean fieldbook: a pratical guide to Lean transformation and sustainable success. New York: Lean Dynamics Research, LLC.

SEZER, B. (2007). Software Engineering Process Improvement. Middle East Technical University.

SGI (2001). The Standish Group Iinternational, Inc. EXTREME CHAOS.

SGI (2009). The Standish Group International, Inc. CHAOS Summary 2009 - The 10 Laws of Chaos.

30

10.2 – Webgrafia

BECK, K., BEEDLE, M., BENNEKUM, A. v., COCKBURN, A., CUNNINGHAM, W., FOWLER, M., . . . THOMAS, D. (2001). Manifesto para o Desenvolvimento Ágil de Software. Obtido em 8 de Abril de 2012, de agilemanifesto.org: http://agilemanifesto.org/iso/ptpt/

BLANCHARD, K. (25 de Julho de 2008). Extra Minute Manager. Obtido em 8 de Abril de 2012, de YouTube: http://www.youtube.com/watch?v=JT6NLYcf7Ps

BLANCHARD, K. (2008). Invert the Pyramid. Obtido em 10 de Abril de 2012, de Youtube: http://www.youtube.com/watch?v=id09a40EvBw

BLANCHARD, K. (25 de Maio de 2010). Where The Action Is. Obtido em 8 de Abril de 2012, de YouTube: http://www.youtube.com/watch?v=B2xasutdbBo

BLANCHARD, K., & BLANCHARD, S. (25 de Julho de 2008). Situational Leadership II. Obtido em 8 de Abril de 2012, de Youtube: http://www.youtube.com/watch?v=M1uyU3YSqes

GONZAGA Mentor Gallery Clip. (25 de Maio de 2010). Where the Action Is. Obtido em 1 de Janeiro de 2012, de YouTube: http://www.youtube.com/watch?v=B2xasutdbBo

SCHWABER, K., & SUTHERLAND, J. (Outubro de 2011). Guia Oficial do Scrum. Obtido em 8 de Abril de 2012, de scrum.org: http://www.scrum.org/storage/scrumguides/Scrum_Guide.pdf

10.2 – A consultar

BUCHANAN, L. B. (1998). The Impact of Big Five Personality Characteristics on Group Cohesion and Creative Task Perfomance. Blacksburg, Virginia: Faculty of the Virginia Polytechnic Institute and State University.

CHEN, J., DUGGER, J., & HAMMER, B. (2001). A Kaizen Based Approach for Cellular Manufacturing System Design: A Case Study. The Journal of Technology Studies.

HERRE, C. (2010). Promoting team effectiveness: How leaders and learning processes influence team outcomes.

31

KRISHNA, Y. R. (2006). Effects of transformational leadership on team performance and commitment: Mediating role of psychological empowerment.

PALMER, V. (2001). Inventory Management Kaizen. Proceedings of the 2nd International Workshop on Engineering Management for Applied Technology.

PARIS, C. R., SALAS, E., & CANNON-BOWERS, J. A. (2000). Teamwork in multi-person systems: a review and analysis. ERGONOMICS, VOL. 43, Nº 8.

QUIGLEY, N. R. (2003). The Relationship Between Leader Core Self-Evaluations, Team Feedback, Leader Efficacy, Transformational Leadership, Team Efficacy, Team Goals, Team Action and Transition Processes, and Team Performance.

SCHILDERMAN, J. (2011). How can a team leader influence performance in a cross-functional team? The effects of diversity belief and conflict management.

TURNER, J. R., & MÜLLER, R. (2005). The Project Manager's Leadership Style as a Success Factor on Projects: A Literature Review. Project Management Journal.

11 - Planeamento (Cronograma) da Investigação

12 - Orientador / Co-Orientador

Orientador: Professor Doutor Nuno Goulart Brandão

Co-Orientador: Professor Doutor José Lopes Costa