Universidade de Pernambuco

Escola Politcnica de Pernambuco

Departamento de Sistemas e Computao

GAP Gesto gil de Projetos

Disciplina: Gerncia de Projetos

Professora: Cristine Gusmo

Equipe: Anderson Tenrio, Danillo Wanderley, Frederico Menezes, Nathlia Silva, Renata Melo

l> processos e ferramentas;

Software rodando > documentao compreensvel;

Colaborao do cliente > negociao do contrato;

Responder s mudanas > Seguir um plano.

Note que os elementos da esquerda so mais valorizados que os da direita. Porm, os elementos da direita no so descartados e mantm sua importncia.

A aplicao de Scrum no significa somente uma preocupao com agilidade, mas uma necessidade de responder melhor s mudanas. Elas esto presentes nos projetos de diferentes formas:

Os requisitos e suas prioridades podem mudar, pois nem sempre os

usurios tm uma real compreenso do seu problema. Muitas funcionalidades no

previstas so adicionadas, e muitas funcionalidades originais so abandonadas.

As ferramentas podem mudar durante o desenvolvimento do projeto, pois

novas tecnologias e novos releases so lanados e as capacidades reais podem variar

das expectativas iniciais.

12

A composio da equipe do projeto pode mudar e a interao entre os

membros pode ser complexa.

Softwares complexos podem possuir uma rede de dependncias muito

abrangente gerando dificuldades de prever atividades, suas dependncias e impactos

de suas mudanas.

Na verdade, a agilidade e o tratamento de mudanas esto ligados, j que a principal preocupao manter os prazos e um bom desempenho mesmo com as constantes mudanas.

Ou seja, projetos conduzidos em ambientes complexos e caracterizados por muitas incertezas iniciais, com dificuldades para detalhamento do escopo e de elaborao de um planejamento completo, com elevado grau de mudanas e com constantes presses pela entrega de resultados em curtos perodos de tempo so timos candidatos a se beneficiarem com a adoo de Scrum.

O Scrum possui algumas premissas que devem ser consideradas:

Conceito Time Box

o Prazo fixo o Custo fixo Lista de funcionalidades que pode variar

Perca funcionalidades, no datas!

Funcionalidades so priorizadas pelo cliente

o Cliente precisa de algo no previsto? o Sem problemas, inclua. Mas exclua algo! o Cliente entende que funcionalidades no final da lista podem ficar de fora

O Scrum d maior nfase ao gerenciamento do projeto e independe da escolha da tecnologia e do modelo de desenvolvimento de software adotado. Ele mais uma postura, um sentimento, uma filosofia, do que um processo.

Papis

O Scrum possui papis que so atribudos aos membros da equipe de desenvolvimento. Eles so descritos a seguir.

Product Owner

o Tipicamente o cliente, alguma pessoa de marketing ou um usurio chave

13

o Determina as funcionalidades do Product Backlog o Prioriza o Product Backlog Scrum Master

o Garante que a equipe de desenvolvimento utilize os valores e as prticas do Scrum

o o representante da equipe o Relaciona-se com o cliente e com cada membro da equipe o Escuta os relatos de cada um o No deve interferir nas decises da equipe a menos que seja solicitado o Retira os impedimentos do projeto Scrum Team

o Tipicamente, 5 a 10 pessoas o Todos devem trabalhar coletivamente para completar o ciclo de Sprint (o

significado de Sprint ser explicado mais adiante)

o Engenharia, Designer, QA no esto em times separados, todos esto no mesmo time

o O time auto-gerencivel, no existe mais o papel do gerente dizendo o que eles tm que fazer

o O sucesso do Scrum depende do comprometimento do Time Users e Stakeholders

o Aqueles que usaro o sistema

Funcionamento

Sendo o Scrum uma tcnica de gerncia voltada para funcionalidades, o primeiro passo para a sua aplicao obter uma lista delas. A essa lista damos o nome de Product Backlog. As entidades responsveis por este documento so o Product Owner, a representao do cliente no projeto, e a equipe de Scrum. No Product Backlog, temos a lista de funcionalidades necessrias ao sistema ordenadas por importncia, sendo que essa lista pode ser atualizada aps os Sprints. Nesse caso, importncia um termo mais adequado ao problema que prioridade, j que em geral, nveis de prioridade so vistos como uma numerao decrescente (menor o nmero, maior a prioridade), onde a maior prioridade costuma ser 0 (zero) ou 1 (um). Acontece que no Scrum, possvel que o Product Owner decida que existe uma funcionalidade mais importante que aquela com nvel de prioridade 0. O que ele faria? Usaria uma prioridade -1 que poderia acabar

14

sendo vista como algo no importante, sendo negativo? Usando uma escala de importncia crescente, possvel que uma funcionalidade tenha, por exemplo, importncia 100, e uma outra acabe tendo mais importncia que essa usando a numerao 200. O Product Backlog pode incluir tambm uma estimativa do tempo necessrio para a realizao da tarefa, alm de instrues de como demonstrar o funcionamento de cada item.

Durante a elaborao do Product Backlog, o cliente explica para a equipe cada uma das funcionalidades, enquanto atribui o valor de importncia para elas. Vale ressaltar que por virem do cliente, todas as explicaes e funcionalidades so feitas em termos de negcios, nunca tcnicos, o que mantm o foco na funcionalidade. A quebra em tarefas tcnicas feita em uma prxima etapa do processo. A equipe faz uma estimativa de quanto tempo / pessoas necessrio para realizar tais tarefas.

Sprint Planning

Uma vez que o Product Backlog esteja pronto, hora de realizar o Sprint Planning, uma reunio entre a equipe inteira que realizar o Sprint, o Product Owner e o Scrum Master, para decidir que funcionalidades entre as listadas sero includas no prximo Sprint. Apenas as funcionalidades de maior importncia iro ser includas no possvel, por exemplo, preencher uma lacuna de tempo com uma funcionalidade menor, mas menos importante, a no ser que o Product Owner decida que ela importante. O segundo critrio usado na priorizao de funcionalidades a complexidade da mesma. Nessa reunio as principais decises a serem tomadas so:

A meta para o prximo Sprint

A durao do Sprint

Uma lista dos membros do time (e seu nvel de comprometimento, se no

for 100%)

Um Sprint Backlog (uma lista de funcionalidades a serem implementadas

no Sprint)

Uma data para a demonstrao das funcionalidades implementadas

Hora e local para realizar as reunies dirias da equipe

A figura abaixo, ilustra esse processo para um Sprint com durao de 2 a 4 semanas.

15

Figura 2: Atividades de um Sprint com durao de 2 a 4 semanas.

A meta no uma lista de funcionalidades, mas importante para lembrar equipe, num momento de desmotivao, a razo pela qual aquele Sprint est sendo realizado. A pergunta chave a fazer para decidir essa meta : Porque iremos fazer esse Sprint ao invs de todos tirarmos frias?. A meta deve ser indita para aquele projeto, caso contrrio, a meta j ter sido alcanada.

A lista de funcionalidades deve tambm ser includa na reunio e tambm no Sprint Backlog, documento que lista as atualizaes que sero implementadas nesse Sprint. As funcionalidades discutidas nesse documento so quebradas em tarefas menores, possibilitando um melhor entendimento da funcionalidade como um todo e facilitando a distribuio das tarefas durante o Sprint.

O Sprint deve ser curto, buscando seguir o princpio de mudanas rpidas do Scrum, mas deve ser tambm longo o suficiente para evitar excesso de reunies de demonstrao e planejamento, alm de permitir equipe se recuperar de problemas internos. Afinal, um Sprint antes de tudo um compromisso, e deve ser cumprido. No existe um perodo ideal de durao, cada equipe / projeto se adapta melhor com um perodo diferente.

O Sprint Backlog deve ser decidido de acordo com uma estimativa de velocidade da equipe, para que sejam includas apenas funcionalidades que possam ser implementadas no perodo determinado para tal. Quando o Sprint Backlog estiver pronto e detalhado, um quadro preenchido (em geral, um quadro com bilhetes ou post-its usado) com as funcionalidades, para facilitar a visualizao por toda a equipe. Cada funcionalidade quebrada em tarefas menores e de entendimento mais simples e tcnico.

O objetivo de um Sprint ter, ao seu final, uma funcionalidade implementada totalmente para ser demonstrada para o cliente. Logo, devem ser marcadas uma data e hora para que o cliente assista a essa demonstrao e avalie o resultado desse Sprint. H sempre uma representao do cliente nas Sprint Plannings, mas se mesmo assim o

16

cliente no ficar satisfeito com o resultado obtido, foi descoberto o problema num estgio adiantado da implementao, e ainda h tempo para mudanas no curso do desenvolvimento, seguindo os princpios de agilidade. A forma de demonstrao de cada funcionalidade deve estar descrita no Sprint Backlog ou ser discutida durante o Sprint. As demonstraes servem tambm para motivar a equipe, j que software funcionando bem agrada ao cliente e gera elogios para a equipe.

As reunies dirias de Scrum (Daily Sprint Meeting) com a equipe servem para manter o quadro de tarefas atualizado, para a equipe reportar ao Scrum Master os impedimentos existentes para a realizao das tarefas. Os pontos principais da reunio so:

O que voc fez desde a ltima reunio?

O que voc pretende fazer at a prxima reunio?

Existe alguma coisa lhe impedindo de fazer o seu trabalho?

Todos os membros do time so consultados sobre os trs pontos, visando dar uma idia para todos sobre o andamento do projeto e uma soluo para os problemas da equipe. permitida a qualquer pessoa a entrada em uma reunio da equipe, mas apenas os membros podem se expressar. Em geral, so planejadas de modo a serem curtas (em torno de 15 a 30 minutos).

Outro objetivo dos Daily Meetings atualizar o Burndown Chart, grfico que ilustra o andamento do Sprint em horas restantes. Grficos burndown muito discrepantes da viso mdia podem dar boas indicaes equipe da necessidade de mudar a quantidade de funcionalidades includas no Sprint. O aspecto de um grfico burndown ilustrado na figura abaixo.

Figura 3: Aspecto de um grfico burndown. A linha azul indica a progresso ideal, a linha verde indica a fronteira do atraso. A linha vermelha indica a progresso real e pode ser atualizada a cada hora ou a cada

dia.

17

Sprint Retrospective

Quando o Sprint termina (aps a reunio de demonstrao), cabe ao time fazer uma retrospectiva daquele perodo, numa reunio chamada Sprint Retrospective. Essas reunies do s equipes a chance de listar (e posteriormente reparar) os erros cometidos durante o Sprint. Todos os participantes (o Scrum Master, o Product Owner e os membros da equipe) tm a chance de opinar sobre o que eles acharam que foi bom, o que poderia ter sido melhor e o que eles gostariam de fazer diferente no prximo Sprint.

importante lembrar que as funcionalidades acordadas no Sprint Planning devem ser entregues, exceto em casos em que a equipe percebe durante o andamento que no ser possvel e faz um novo acordo com o cliente para incluir menos funcionalidades na prxima demonstrao. Entregar as funcionalidades acordadas ao final de cada Sprint mais importante que entregar todo o software pedido ao final do prazo estipulado em contrato, j que as funcionalidades feitas a cada Sprint so sempre as mais importantes para o cliente / projeto naquele momento.

18

CAPTULO III

XP EXTREME PROGRAMMING:

UMA VISO GERAL

Juntamente com o Scrum, o XP situa-se como uma das tcnicas mais utilizadas para o gerenciamento gil de projetos de software. Sua filosofia de desenvolvimento baseia-se na execuo simultnea das principais fases para a criao de um produto: planejamento, anlise, implementao e teste. Com isso, no h distino temporal longo prazo destas fases, sendo todas realizadas diariamente. Os marcos temporais que definem o andamento de um projeto deixam de ser o fim de uma dessas fases, passando a ser o fim de uma iterao. A iterao pode ser definida como uma unidade de tempo onde todas as fases foram executadas simultaneamente e um produto foi liberado ao seu trmino.

Ciclo de vida do XP

Como as fases para a criao de um produto so realizadas diariamente, uma equipe de desenvolvimento que trabalha sob as regras e especificaes do XP so capazes de liberar produtos toda semana. Contudo, quando falamos de produtos em XP, no significa necessariamente o produto completo, mas sim subconjuntos de funes caractersticas e recursos deste.

O fato de uma equipe liberar produtos em intervalos curtos, devido implementao do XP, no significa que esta equipe aumentou sua produtividade, mas sim que esta equipe agora capaz de dar feedbacks de forma mais rpida. Como conseqncia, esta equipe agora capaz de identificar de forma mais rpida as causas latentes que determinam o sucesso ou fracasso da entrega dos produtos.

A quantidade de trabalho a ser realizada em cada iterao estrategicamente pequena em relao ao todo, o que permite equipe corrigir rapidamente erros de programao em pleno vo sem que haja o comprometimento da entrega semanal.

Com este feedback mais rpido a equipe de desenvolvimento pode refinar rapidamente seu planejamento para a prxima iterao. Isso facilita a insero ou

19

modificao de requisitos definidos pelo cliente, visto que este agora tambm tem acesso a prottipos do seu produto semanalmente.

Como o XP trabalha?

Como j mencionado anteriormente, o XP trabalha com a execuo simultnea das fases de planejamento, anlise, implementao, teste e entrega de produtos semanalmente. Com isso, a mtrica temporal de acompanhamento do projeto passa a ser atravs de iteraes.

Em cada iterao, a equipe trabalha com o desenvolvimento de produtos baseados em histrias que correspondem a recursos ou pedaos de recursos que devem estar contidos no produto final. Semanalmente, uma equipe trabalhando sob a filosofia deve liberar entre quatro a dez histrias, sendo que cada histria trabalhada em todas as suas fases de desenvolvimento (planejamento, anlise, design, implementao, teste e liberao).

Como cada fase de desenvolvimento trabalhada em XP?

A seguir, faremos uma breve descrio de como cada fase de desenvolvimento trabalhada pelo XP.

Planejamento

Embora a fase de planejamento, como todas as outras fases tratadas pelo XP, seja executada continuamente, os esforos dedicados para sua execuo so maiores nas primeiras semanas de um projeto. Isto ocorre porque na etapa inicial de planejamento, contida nas primeiras iteraes, quando ocorre uma elevada interao entre clientes e equipe de desenvolvimento. Isto serve, entre outras finalidades, para refinar e tornar mais claras as histrias que sero abordadas para a criao dos produtos de cada iterao. Esta etapa de negociao entre clientes e equipe para definir prioridades do projeto denomina-se the planning game. No contexto XP, um cliente no necessariamente o cliente final do software, mas pode ser tambm um especialista na rea de atuao do software.

No tempo remanescente do projeto, esta interao se mantm contnua, porm menos intensa, sendo a participao dos clientes direcionada para revises de requisitos e criao de novas vises para contornar eventos no previstos.

Por fim, semanalmente a equipe deve detalhar o planejamento para as atividades a serem desenvolvidas na prxima iterao. Alm disso, deve-se preconizar encontros

20

dirios breves assim como um workspace para a avaliao contnua do status atual do projeto.

Anlise

Como os clientes so os responsveis por caracterizar e informar os requisitos do software a ser desenvolvido, eles colaboram com a equipe de desenvolvimento em tempo integral nas fases de anlise. Isto ocorre devido aos conhecimentos especficos que os clientes possuem sobre os problemas e processos que sero assessorados e/ou solucionados pelo software. Aliado a esses conhecimentos especficos, os clientes contam com tcnicas tradicionais de levantamento de requisitos para organizar, formalizar e descrever os requisitos do produto final na forma de histrias que sero ento passadas para a equipe de programao.

Alm disso, tendo em vista a complexidade e dificuldade de entendimento de alguns requisitos por parte da equipe de programao, os clientes devem sempre estar presentes e preparados para eventuais perguntas a serem efetuadas pela equipe de programao.

Design e Implementao

Como forma de agilizar os processos de design e implementao do projeto, o XP faz uso da metodologia TDD (do ingls Test-Driven Development). Isto permite a construo dos produtos de forma contnua em pequenas etapas que guiam juntamente teste, implementao e design.

Para que a equipe de implementao suporte este tipo de metodologia, os programadores trabalham em duplas, o que aumenta consideravelmente a capacidade de raciocnio da equipe, visto que em cada dupla h sempre um componente com tempo disponvel para pensar nas questes de design em um nvel de abstrao mais elevado.

Os programadores so tambm os responsveis pela organizao do seu ambiente de desenvolvimento. Para isto, eles utilizam ferramentas para atualizao das verses dos cdigos implementados, de forma a manter sua implementao mais automtica. Isto permite que todas as duplas de programao integrem seus cdigos implementados em poucas horas, com o intuito de se liberar um produto funcional. Alm disso, as duplas devem manter um estilo de programao nico, que permita a integrao rpida dos cdigos e o rastreamento de erros de codificao e a identificao do autor do erro.

Por fim, em termos de modificao de cdigo, o XP trabalha fortemente com a idia de refactoring, com o intuito de se manter o cdigo robusto suficiente para sofrer alteraes sem que o seu comportamento final seja comprometido

21

Teste

O XP possui um elegante conjunto de tcnicas de teste. Com isso, uma equipe trabalhando sob a filosofia XP produz, teoricamente, apenas um pequeno punhado de bugs em seus produtos mensalmente. Para tanto, todos os membros da equipe (programadores, clientes e equipe de teste) devem dar suas contribuies para aumentar a qualidade dos produtos.

Os programadores do sua contribuio devido a utilizao da metodologia TDD em seus trabalhos. A TDD preconiza a integrao e automatizao dos testes de cdigos. Os clientes, por sua vez, contribuem para que os programadores realmente entendam as suas expectativas, quanto aos requisitos propostos. Os clientes so os responsveis por revisarem o progresso da implementao dos produtos e tambm produzem exemplos para que os programadores tenham uma melhor viso sobre o deve ser realmente implementado.

Por fim, a equipe de teste tem a responsabilidade de verificar se os produtos esto sendo desenvolvidos com cdigos de alta qualidade. Para isso, eles utilizam tcnicas exploratrias para procurar eventos inesperados e gaps nos cdigos implementados. Quando um bug encontrado pela equipe de teste, toda a equipe realiza uma anlise do tipo root-cause e estuda como reestruturar os processos do projeto para prevenir o surgimento de bugs similares no futuro. Alm disso, a equipe de teste deve explorar as caractersticas no funcionais dos produtos, como performance e estabilidade. Com estas informaes em mos, os clientes ento decidem o melhor caminho para a criao de histrias adicionais.

Entrega de produtos

A equipe deve sempre estar preparada para a liberao de produtos ao final de cada iterao. Os produtos so liberados para os clientes e investidores semanalmente, para avaliao.

22

CAPTULO IV

OUTRAS TCNICAS DE GERENCIAMENTO GIL

Alm de Scrum e XP, outras vrias tcnicas de gesto gil so utilizadas para se alcanar um gerenciamento satisfatrio de projetos. Pela figura abaixo, pode-se observar a porcentagem de uso de algumas destas tcnicas.

Figura 4: Porcentagem de uso de algumas tcnicas de gesto gil.

DSDM Dynamic Systems Development Method

Mtodo Dinmico de Desenvolvimento de Sistemas

O DSDM uma abordagem de desenvolvimento de software que enfatiza o envolvimento contnuo do usurio, sendo seu objetivo entregar sistemas no tempo e oramento previstos, enquanto se ajusta a mudanas de requisitos ao longo do processo de desenvolvimento. O Consrcio DSDM foi fundado em janeiro de 1994, no Reino Unido, e atualmente a nica metodologia gil formal reconhecida para uso pelo governo daquele pas. Foi desenvolvido por uma associao entre empresrios e especialistas na rea de desenvolvimento de sistemas de informao, onde foram utilizadas as experincias em ambas as reas.

23

A tcnica consiste em trs fases: pr-projeto, ciclo de vida do projeto e ps-projeto. A fase de ciclo de vida subdividida em 5 estgios, que so o estudo da possibilidade de concretizao, estudo de negcio, interao funcional de modelo, iterao de design e construo e implementao. E em algumas circunstncias possvel integrar prticas de outras metodologias.

A metodologia guiada por nove princpios:

1. Envolvimento ativo do usurio imperativo

2. O time precisa ter poder para tomar decises

3. O foco est na entrega freqente de produtos

4. Adaptao para fins de negcios o critrio essencial de aceitao de deliverables

5. Desenvolvimento iterativo e incremental necessrio para convergir em uma soluo de negcio precisa

6. Todas as mudanas durante o desenvolvimento so reversveis

7. Requisitos so baseados em alto nvel

8. Testes so integrados com o ciclo de vida

9. Colaborao e cooperao entre steakholders essencial

FDD Feature Driven Development

Desenvolvimento Guiado por Funcionalidades

O FDD um mtodo gil e altamente adaptativo que combina as melhores prticas do gerenciamento gil de projetos com uma abordagem completa para Engenharia de Software orientada a objetos.

Teve sua origem entre 1997 e 1998, em Singapura, durante o desenvolvimento de um grande sistema de emprstimos para o banco internacional Unites Overseas Bank. Tal sistema foi considerado muito complexo e impossvel de ser desenvolvido. Havia 3.500 pginas de casos de uso e um modelo de objetos com centenas de classes. Foi, ento, tomada a deciso de implantar as metodologias de anlise e modelagem orientadas a objetos - OOAD - de Peter Coad e o gerenciamento de projetos de Jeff De Luca. Como resultado, 15 meses aps a contratao destes profissionais 2.000 features foram entregues por uma equipe de 50 pessoas.

24

O termo feature pode ser entendido como funcionalidade ou caracterstica. Tem um conceito muito prximo ao de requisito funcional. Mapeia passos em uma atividade de negcios, podendo ser um passo de um caso de uso ou o prprio caso de uso. Deve ser pequena o suficiente para ser implementada em no mximo duas semanas e oferece valor ao cliente. A figura abaixo detalha a estrutura de uma feature.

Figura 5: Quebra da estrutura de uma feature.

As features seguem o seguinte modelo: .

Exemplos:

Calcular o total de uma venda

Autorizar uma transao com carto de um cliente

Enviar uma nota fiscal para um cliente

Por ser muito objetiva, a metodologia possui somente 2 fases:

1. Concepo e Planejamento, com durao entre uma e duas semanas;

2. E Construo, que ocorre de forma iterativa.

Entre as caractersticas da FDD esto:

Fornecer estrutura suficiente para equipes maiores;

Enfatizar a produo de software de qualidade;

Entregar resultados freqentes, tangveis e funcionais a cada duas

semanas ou menos;

25

Realizar trabalho significativo desde o incio, antes de tornar-se

altamente iterativa;

E fornecer informaes de estado e progresso de forma simples e

compreensvel.

Oferece, ento, vantagens sobre os mtodos prescritivos, pois implementa conceitos importantes de planejamento, mas sem excessos de documentao e controle.

As melhores prticas pregadas por esta tcnica so:

Modelagem de objetos do domnio;

Desenvolvimento por feature;

Posse individual de classes (cdigo);

Equipes de features;

Inspees;

Builds regulares;

Relatrio / visibilidade de resultados.

Em cada ciclo iterativo o progresso medido com base em 6 marcos ou milestones bem definidos e a cada etapa cumprida o percentual respectivo agregado ao total de progresso da feature. Com base nisso, o progresso reportado de acordo com uma estrutura composta pelo nome da atividade e seu status, barra de progresso e prazo de entrega, como pode ser observado na figura a seguir, objetivando, como mencionado anteriormente, ser simples e compreensvel.

26

Figura 6: Reportando o progresso.

TOC Theory of Constraints Teoria das Restries

A primeira meno desta tcnica ocorreu no livro A Meta, de Eliyahu Moshe Goldratt. Sua criao se baseou no ambiente de manufatura que, assim como os demais ramos de atuao, est sendo forado a otimizar processos, minimizar custos e aumentar produtividade. A TOC busca solucionar essa questo vendo a empresa no em partes isoladas, mas como um sistema integrado, um conjunto de elementos entre os quais h alguma ligao. Desta forma, o desempenho global do sistema depende dos esforos conjuntos de todos os seus elementos. Logo, a empresa to forte quanto seu elo mais fraco, assim como a velocidade de um comboio a de seu veculo mais lento. Para melhorar o desempenho de um sistema, necessrio conhecer sua principal restrio e atuar nela, promovendo um processo de melhoria contnua.

Tal restrio de um sistema nada mais do que qualquer coisa que o impea de atingir um desempenho maior em relao a sua meta. Para realizar esta medio preciso conhecer a meta do sistema em estudo e definir as medidas que vo possibilitar o julgamento do impacto de qualquer ao local nessa meta. De acordo com esta teoria e com o raciocnio de que a principal meta de qualquer empresa seu resultado financeiro, se a empresa no possusse nenhuma restrio, seu lucro seria infinito. Tem como base a aplicao de princpios cientficos e raciocnio lgico para guiar organizaes humanas. Desta forma foram estabelecidos dois tipos de restries: as fsicas ou polticas e as no-fsicas ou emocionais.

Para realizar mudanas, a TOC responde a trs perguntas atravs do Processo de Pensamento (Thinking Process), que so:

27

1. O que mudar?

2. Como mudar?

3. Mudar para o qu?

Seguindo o algoritmo abaixo, que composto pelos 5 passos da TOC:

Tabela 2: Algoritmo da TOC.

1: Identificar a restrio;

2: Decidir como explorar a restrio;

3: Subordinar e sincronizar todo o resto deciso acima;

4: Elevar a performance da restrio;

5: Se em qualquer um dos passos anteriores a restrio principal for alterada voltar ao passo 1.

Os desafios aumentam em cenrios onde vrios projetos so executados ao mesmo tempo, devendo haver extrema ateno disponibilidade de recursos e forma de sua utilizao.

CCPM Critical Chain Project Management

Gesto de Projetos pela Corrente Crtica

Este mtodo originou-se na TOC, sendo sua utilizao em ambientes de projetos. Foi inicialmente publicado em 1997 por Goldratt no livro Critical Chain. Pode ser aplicado em ambientes mono e multi-projetos, sendo chamado de corrente crtica para ser feita diferenciao com caminho crtico, que um mtodo tradicional do PMBOK e outras metodologias.

Esta tcnica leva em considerao a dependncia de recursos, assim como a aplicao de segurana contra atrasos por meio de buffers, ou pulmes, que so dispostos nos locais onde sero mais teis, sendo compartilhados pelas tarefas mais crticas. Defende que o melhor ponto para aplicar a segurana no nas atividades individuais, pois esta prtica acarreta grande aumento no cronograma final, alm de acabar por provocar atrasos. Isto pelo raciocnio de que os responsveis pelas atividades

28

s vo desempenh-las quando o prazo estiver prximo do fim, ento o melhor encurt-los numa poltica agressiva.

Outro ponto interessante a possibilidade de deciso pelo incio posterior das tarefas, evitando o efeito Big Bang e contrariando a mxima de que quanto mais cedo se comea, mais cedo se acaba. Eliminam-se datas de incio e fim de atividades sempre que possvel e o progresso reportado baseado em durao restante e no em porcentagem. Multitarefas so eliminadas, melhorando significativamente foco e qualidade e reduzindo drasticamente a durao das mesmas.

A terceira edio do Guia PMBOK o referencia como uma tcnica de anlise de rede do cronograma, que modifica o cronograma do projeto para que leve em conta recursos limitados. O mtodo da cadeia crtica mistura abordagens determinsticas e probabilsticas da anlise de rede do cronograma.

29

CAPTULO V

CONCLUSO

A realidade dos projetos de software no fcil. Os exemplos de mudanas citados no texto so comuns de acontecer. Ento, por que no adotar uma abordagem que lide com isso ao invs de aderir a uma que defina um plano a ser seguido sem considerar a dinmica do processo? Ns entendemos que os exemplos de tcnicas, prticas ou metodologias de gesto gil de projetos tm muito a oferecer quando usadas adequadamente.

Um ponto em comum que identificamos a filosofia dividir para conquistar. Todas as abordagens apresentadas preocuparam-se em quebrar tarefas complexas em sub-tarefas mais fceis e executveis numa iterao.

Tambm nos chamou a ateno o foco nas pessoas, a comunicao, a interao e, principalmente, o comprometimento que todos os envolvidos devem ter ao adotar estas tcnicas. importante notar que, independente da tcnica escolhida, necessrio um tempo de adaptao a ela.

30

BIBLIOGRAFIA

Shore, J. e Warden, S. The Art of Agile Development. OReilly. 2008.

Augustine, S. Managing Agile Projects. Prentice Hall. 2005.

Apresentao sobre gesto gil com FDD. URL: http://www.visaoagil.com/downloads/ biblioteca/GestaoAgilcomFDD.pdf. Acessado em 23/10/2008.

Aplicando a Gesto gil de Projetos para o Desenvolvimento de Novos Produtos na Indstria de Software. URL: www.abepro.org.br/biblioteca/ ENEGEP2006_ TR490328 _7853.pdf. Acessado em 23/10/2008.

Desmistificando a Gesto, Desenvolvimento e Melhoria gil de Projetos com Scrum. URL: http://www.planoeditorial.com.br/jornada/palestras/campinas/27_11_2007/ JuanBernabo.pdf. Acessado em 23/10/2008.

FDD Feature Driven Development Desenvolvimento Guiado por Funcionalidades. URL: http://www.featuredrivendevelopment.com/. Acessado em 23/10/2008

FDD Feature Driven Development. URL: http://www.heptagon.com.br/fdd. Acessado em 23/10/2008.

Quelhas, O., Barcaui, A. B. A teoria das restries aplicada a gerncia de projetos: Uma introduo corrente crtica. URL: http://www.pmtech.com.br/newsletter/. Acessado em 23/10/2008.

31

Marco_2005/TOC_e_CCPM_em_GP.pdf. URL: http://www.pmtech.com.br/newsletter/Marco_2005/TOC_e_CCPM_em_GP.pdf. Acessado em 23/10/2008.

DSDM Dynamic Systems Development Method Mtodo Dinmico de Desenvolvimento de Sistemas. URL: http://www.dsdm.org/. Acessado em 23/10/2008.