Para ajudar o pessoal, vou passar um definição geral e não muito detalhada mas que poderá ajudá-los com essa “sopa”.

O Cobit trata-se de um modelo de referência para gestão de TI. E ai já começa a confusão. Alguém poderia estar pensando neste momento: “mas, a ITIL não tem a mesma finalidade?”. Definitivamente não. A camada de atuação de ambas não é a mesma.
Através das ferramentas do Cobit, o gestor de ti irá cuidar da TI para que ela atenda as espectativas de negócio da empresa.
Vou explicar através de um case pois o entendimento ficará mais simples.

Imagine um grande banco. Este banco pretende expandir seus negócios no Brasil. Irá abrir 57 novas agências até o final de 2010, e seu atendimento ao cliente que era somente no horário comercial, de segunda a sexta, agora passará a ser 24×7. Além disso, a diretoria sênior do banco já preve a abertura de mais 35 agências para o primeiro semestre de 2011.

Ok. Agora que a diretoria já decidiu seu plano de expansão, teremos que ter TI para que tudo isso funcione correto? Alguém já viu uma agência sem sistemas para controlar saque de dinheiro, depósitos, investimentos ou um sistema para o sac registrar os chamados? É, eu também nunca vi. Toda esta expansão sem TI simplesmente não aconteceria.

O diretor de TI que participava desta reunião de divulgação dos planos de expansão ficou atento a estes números. Após a apresentação do plano, o presidente nacional do banco, olhou para ele e disse “Fulano, em 4 semanas quero uma apresentação para a diretoria nos exibindo o que precisamos investir em TI para que nossa expansão ocorra sem problemas. Quero saber além da necessidade técnica, o orçamento e o retorno que termos sobre este investimento”.

É nesta camada que o COBIT atua. O Cobit está mais próximo do negócio do que qualquer outra prática, framework, metodologia ou o que for. O Cobit auxilia a diretoria de TI a decidir e controlar os investimentos em TI, a gerar indicadores e a justificar o investimento. Utilizamos a Cobit para conseguir definir o que é preciso comprar, desenvolver ou alugar para que os objetivos de negócio sejam concretizados.

Em nosso case, o objetivo é a abertura das novas agências e o sac de 24×7.

Neste caso poderiamos exemplicar de forma extremente resumida que seria necessário:

- aquisição de 7500 computadores
- 7 servidores com arquitetura risc
- contratação se XPTO funcionários
- etc

Vamos dar mais um passo. Realizamos a apresentação para a diretoria, exibimos o que é preciso de TI para atender o objetivo do negócio, exibimos o orçamento, os riscos, as vantagens, o ROI etc e a diretoria aprovou o investimento. Fase 1 concluída.

Agora é hora de colocar esse plano em ação. Quem irá realizar a implantação, configuração dos 7500 computadores e dos 7 servidores? Sim a equipe de GESTÃO DE PROJETOS.

O orçamento de TI foi aprovado agora a “bola” passa da mão do pessoal de governança de TI (Cobit), para o pessoal de gestão de projetos (PMI, PRINCE2 etc).

O pessoal de gestão de projetos poderá utilizar as melhores práticas do PMI e com base nelas criar sua própria metodologia, utilizar uma metodologia padrão de mercado como a Prince2 ou outra de sua preferência.

Serão criados planos para gerir a qualidade do projeto, o escopo, o tempo, as comunicações etc, tudo visando que as 7500 máquinas sejam implantadas corretamente, assim como os servidores. O gerente de projeto irá acompanhar e coordenar a execução de atividade por atividade, como por exemplo:

- instalação de cpu
- instalação do monitor
- instalação do sistema operacional
- instalação do sistema bancário
- testes de conexão com o servidor
- etc

Ok. Projeto entregue e implantado com sucesso. Servidores rodando perfeitamente, agências operando e sac 24×7 a todo vapor.

Pois é, e agora, quem irá MANTER tudo isso? Opa, agora sim aparece a ITIL para gerir a TI. Agora que o projeto já está em operação, não é mais de responsabilidade do pessoal de projetos, mas sim do pessoal que cuida da infraestrutura de TI, do pessoal que trabalha com ITIL.
Através da ITIL a equipe de infraestrutura terá processos bem definidos para gerenciar estação por estação, para gerenciar os servidores, para gerencia a capacidade, ou seja, se o tamanho do disco rígido é adequado, se o tamanho do hd é adequado, para gerenciar a liberação de software, garantindo que só softwares originais e licenciados estejam em uso, acorda níveis de serviço (SLA), define os planos de continuidade do negócio, por exemplo, redundância de servidores para que, em caso de desastre, um seja acionado automaticamente caso o outro pare, dentre outros controles.

Para resumir o entendimento, basicamente falamos que:

- COBIT
Atua na definição que o negócio tem referente a TI para poder atingir suas metas.

- GESTÃO DE PROJETOS
Atua na concretização da necessidade de TI levantada pelo pessoal da governana de TI (COBIT).

- ITIL
Após a implantação do projeto, o ITIL tem o dever de manter a infraestrutura de TI operante, ou seja, cuida do dia-a-dia.

Algumas definições:

- PMI
Não é uma metodologia, não são as melhores práticas e nem é o nome de uma certificação.
PMI significa Project Management Institute, ou seja, Instituto de Gerenciamento de Projetos. Trata-se do instituto que com a ajuda de profissionais do mundo todo definiu as melhores práticas para se gerenciar projetos e as publicou no PMBOK.

- PMP
PMP trata-se da certificação para profissionais de gestão de projetos criada pelo PMI. Esta certificação garante que o profissional possui um nível aceitável de conhecimento em gerenciamento de projetos.

- PMO
PMO não é um cargo. PMO significa PROJECT MANAGEMENT OFFICE, ou seja, Escritório de Gerenciamento de Projetos.
Trata-se do departamento que coordena os projetos em execução na compania.

- PRINCE2
Prince2 é uma metodologia comercial para gestão de projetos. No Brasil não possuimos muitos adeptos, mas no exterior sim. De qualquer forma o padrão adotado mundiamente em grande escala são as melhores práticas do PMBOK e a partir delas cada empresa cria sua metodologia.

Fonte: http://gestaodeprojetos.net

 Putinhas, safadas, zoofilia, sexo, ninfetas, anal.

E ninguém melhor para falar sobre sucesso em uma carreira do que uma pessoa que chegou lá. É o caso do Ricardo Vargas, autor conhecido no âmbito do Gerenciamento de Projetos no Brasil, e que é “Especialista em planejamento, gestão e controle de projetos. Foi, nos últimos dez anos, responsável por mais de 30 projetos de grande porte no Brasil, coordenando uma equipe de mais de 500 profissionais de gerenciamento de projetos nas áreas de telecomunicações, informática, finanças e energia, com um portfólio de investimentos superior a 5 bilhões de dólares.”

 Em mais um de seus podcasts sobre gerenciamento de projetos, desta vez Vargas escolheu um tema que me interessou bastante: conselhos dedicados a quem está começando sua carreira na área, frisando que se trata de um apanhado de opiniões, e não de um tratado sobre o que é certo ou errado na carreira de cada um.

 Ele começa elencando o que considera como os fatores clássicos de sucesso em gerenciamento de projetos: entender o que é projeto e o que está acontecendo na área de projetos, e especialmente entender que projeto está relacionado a investimento, a novos negócios, a desafios, a trabalhos não-rotineiros.

Para Vargas, os pilares de uma carreira sólida na área são três: desenvolvimento profissional com experiência internacional (mesmo que seja participação em congressos e cursos) + certificação; relacionamento e networking; e a experiência, mesmo que começando por baixo – ele frisa que às vezes vale a pena até mesmo aceitar determinados projetos sem lucro financeiro para si, para adquirir a experiência e até para enriquecer o currículo.

 Se ele tivesse que reiniciar sua carreira na área hoje, eis o que ele priorizaria:

•  Treinamento formal – MBA, especialização ou outra pós-graduação em gerenciamento de projetos, curso específico, curso de férias fora do país, ou o que estiver ao alcance. Pensar globalmente, mesmo que só possa agir localmente. Vale muito para o currículo, e agrega à experiência.
• Certificação: Ele começaria por obter a qualificação necessária para poder buscar a certificação PMP, do PMI, que é o que o mercado conhece e pede. Deixaria outras certificações que servem como diferencial (PRINCE2 e outras) para um segundo momento, como foi de fato o caso da carreira dele.
• Networking profissional: investiria muito no networking profissional, com um profile caprichado no LinkedIn (existe algum equivalente nacional tão bem aceito?), participando ativamente nos fóruns e listas de discussão, indo a congressos sem esquecer de trocar cartões e apertar mãos.
• Idiomas: para ele, é fundamental aprender e dominar outro idioma, preferencialmente o inglês, que é básico. Outros idiomas são diferenciais.

Ele deu ainda uma dica: procurar entrar como voluntário em organizações voltadas ao gerenciamento de projetos, como o PMI, porque é uma grande oportunidade de agregar conhecimento, experiência e enriquecer o networking.

 Ele termina lembrando que conselho se fosse bom seria vendido, e não dado, mas estes são os conselhos que ele pode compartilhar conosco. Eu gostei, e recomendo!

 Para saber mais, consulte a a área de podcasts do site do Ricardo Vargas.

Fonte: http://www.efetividade.net

1. Escolha e adote uma metodologia:

Uma metodologia é um processo a seguir que dá maior controle sobre os recursos que serão utilizados no projeto. Controlando melhor o processo a equipe será mais eficiente pois entregará o projeto com maior grau de acerto em termos de prazos e custos. O bom uso de uma metodologia é importante porque permite evitar práticas que levam ao insucesso e com isso reproduzir o sucesso.

A Microsoft usa o MSF (Microsoft Solutions Framework) no desenvolvimento de seus produtos. Muitas empresas na área de software optam pelo CMM (Capability Maturity Model). A opção pela metodologia deve ser tomada a partir de alguns fatores: as exigências de cada mercado em que a empresa atua, a disponibilidade de mão-de-obra e a cultura organizacional necessária para adotá-la. Para exportar software, muitas empresas nacionais têm se alinhado com o padrão CMM para dar credibilidade a sua iniciativa em mercados dominados por indianos e chineses, que já possuem capacitação neste padrão.

Em última instância, uma metodologia é um conjunto de regras de como conduzir um projeto com sucesso. Pode até não ter siglas bonitas, mas é importante que já tenha se mostrado eficiente dentro da sua empresa, de preferência em situação similar à que você está vivendo no seu projeto atual. Para quem gosta de siglas, há uma que está bem na moda: a UML (Unified Modeling Language) que, como já diz o nome, não é uma metodologia mas uma linguagem, uma forma de se documentar um projeto. Uma linguagem de modelagem é uma notação, em geral feita com símbolos gráficos, que se usa para traduzir processos abstratos. A empresa que criou a UML desenvolveu uma metodologia conhecida como RUP, “Rational Unified Process”.

2. Comunique-se:

Quando falta comunicação, os boatos e outras formas de ruídos tomam seu lugar. Na falta de versão oficial, ficam circulando informações que podem minar a moral da equipe e levantar suspeitas sem fundamento. O gerente de projeto deve evitar esse tipo de prática, conhecida por “rádio-peão”, dando informações claras e confiáveis sobre o status do projeto. Certamente esta é uma área em que a diplomacia é essencial. Se há um problema, o gerente de projetos pode e deve não só falar sobre ele, mas também informar que está trabalhando na solução, e não apenas comunicar que o problema existe. Problemas sem uma perspectiva de solução são angustiantes e causam um desconforto na equipe que muitas vezes é desnecessário.

A criação de relatórios de progresso do projeto ajuda no processo de comunicação, sobretudo por que torna o processo impessoal e mais objetivo. Imagine o efeito de um email onde se critica um membro da equipe pelo atraso do projeto. Imagine a mesma informação vinda de um relatório em que a data de término real de uma tarefa está em branco: objetivamente a situação é a mesma, o indivíduo não fez a sua parte, mas no caso do email a pessoa envolvida pode se melindrar. No relatório, temos um dado objetivo, que salta aos olhos, mas que não gera ressentimentos.

3. Defina o escopo do projeto e detalhe as atividades:

O “escopo do projeto” é o trabalho que deve ser realizado para se obter um produto ou serviço com determinadas características e recursos. Comece por definir o que deve ser feito e o que não deve. Esse processo nos permite entender os contornos do projeto e traçar uma linha divisória entre o que deve ser feito e o que não deve ser, pelo menos neste momento. Muitos novatos se perdem em discussões intermináveis sobre recursos do produto final que o tornariam “perfeito”. Sempre me lembro de um amigo muito experiente que, ante a minha ânsia em acertar todos os detalhes logo de cara, me dizia que “o ótimo é inimigo do bom”, ou seja: enquanto perseguimos o “ótimo” nos distanciamos de algo que está bem mais próximo, o “bom”, é que temos mais chance de conseguir atingir. Com o tempo achei uma forma elegante de contornar as exigências de projeto sem decepcionar os clientes: não é que não faremos o que está sendo pedido, mas devemos ver que este recurso cabe na versão 2, 3, etc… mas não cabe na versão 1, que é o que estamos tentando desenvolver neste momento ! Afaste o fantasma da perfeição.

Para você não se perder numa lista interminável de características da versão 1, uma boa idéia é pedir ao cliente que liste só que o que é “absolutamente essencial”. Claro que se você der a ele 30 minutos para responder, tudo será “absolutamente essencial”. Não adianta, temos de ser realistas, o tempo é curto é temos de escolher só o que realmente é importante. Se “escrever é cortar” como dizem os grandes escritores, a arte de se definir o escopo do projeto passa por saber o que abandonar e o que reter do universo de necessidades do cliente.

Bom, definido o escopo do projeto, podemos passar para a fase de detalhamento das tarefas. O objetivo é chegar ao WBS (Work Breakdown Structure), onde temos as “unidades de trabalho” com tempo medido em dias ou horas de trabalho. Como regra, uma atividade deve ocupar entre 4 e 80 horas, nem mais, nem menos.

Em paralelo, deve ser elaborado um orçamento levando em conta quantas horas de cada profissional serão necessárias. Veja um modelo simples:

Para montar este modelo, você precisa saber o custo-hora de cada profissional e estimar o tempo que cada um gastará no projeto. Os profissionais podem estar envolvidos em outros projetos e quando o programador está cuidando de uma fase do projeto A, o gerente de projeto já pode estar planejando o projeto B, só voltando ao projeto A quando for para entregar ao cliente e obter a sua aprovação, sobre o que falaremos mais adiante.

Estas estimativas são mais precisas à medida em que se avança no detalhamento do projeto. Para estimativas iniciais, admite-se uma variação de -25% a +75%. Na fase de planejamento, o orçamento deve ter uma variação de -10% a +25%. Lembre-se que nesta fase, o gerente de projeto já envolveu quem realizará a tarefa. Na estimativa final, a margem de erro é menor: de -5% a +10%. Aqui, o conhecimento do gerente de projeto de situações anteriores fará diferença. Eu, por exemplo, sei que quando lido com determinados clientes, haverá tanto “overhead” administrativo, como dezenas de reports para cima e para baixo antes que cada passo importante seja dado, que eu já estimo 50% a mais do tempo nas tarefas em que o cliente está diretamente envolvido. Vai da experiência do gerente, mas nessa hora, se a empresa têm um histórico de projetos semelhantes, vale a pena se basear neste background, mesmo que tenha sido com outras equipes e outros gerentes de projeto.

Um dos grandes segredos do gerenciamento de projetos é proteger o seu escopo. Projetos que ficam mudando o escopo durante sua execução têm sérias dificuldades em cumprir o cronograma e estouram o orçamento. O risco mais comum é o que se chama de “scope creep”, quando o escopo vai crescendo a medida que o cliente vai entendendo suas necessidades e reformulando seus objetivos. Há quem chame este problema de “Jacques”. Seria uma homenagem a um francês ilustre ? Não, trata-se apenas da forma como o cliente costuma abordar o assunto: “já que o sistema faz isso, ele pode então fazer aquilo. Agora eu quero aquilo também incorporado ao projeto.” O gerente do projeto deve ter calma e analisar com cuidado cada demanda: ao rejeitar um pedido, ele pode se indispor com o cliente, mas se aceitar ele pode estar dando um tiro no próprio pé, já que o prazo e orçamento não serão tão “elásticos” quanto as exigências. Devemos sempre contar com uma certa “margem de manobra”, mas nos tempos atuais, em que eficiência é a palavra que está na ordem do dia, não há muita “gordura para queimar” e os compromissos assumidos pelo gerente podem se transformar num sacrifício, muitas vezes desnecessário, para toda a equipe.

Em projetos de software, o “scope creep” é uma situação tão comum que não dá para começá-los sem tomar algumas precauções. O primeiro cuidado é negociar a forma de remuneração: fixa ou variável. Se for fixa, o risco das mudanças está toda com o gerente do projeto, se for variável, o cliente assume os custos extras. Mesmo neste caso, o gerente do projeto deve cuidar para que o cliente seja informado a priori dos novos custos. Por precaução, eu sempre redijo um adendo ao escopo colocando o que será feito, em quanto tempo e a que custo. Colho a assinatura do cliente e só depois autorizo a execução da tarefa. Gerentes financeiros não participam destas reuniões e podem alegar que não há previsão de recursos para os extras, então mantenha-os informados das novas condições para evitar dissabores na hora do recebimento.

O segundo cuidado é documentar meticulosamente o escopo do projeto. Este documento resume o que será feito, com que características e com que recursos. Ele é um “quase-contrato” mas não traz as cláusulas de rescisão e as penalidades. Neste momento, tudo está bem e todos concordam. Só que, na cabeça de cada um, há uma imagem diferente do que será o produto final. Á medida que este produto vai tomando forma e sendo entregue, o cliente vai vendo que o que ele imaginou “não é bem aquilo” e podem começar as decepções.

A satisfação do cliente depende em muito do que será dito e prometido no que se chama de “pré-venda”. É neste momento que o gerente de projetos deve entrar em cena para meticulosa, cuidadosa e disciplinadamente escrever tudo o que o sistema deve ter e fazer. Este processo é o “planejamento de escopo” e num software dele abrange das telas até os relatórios. Esta tarefa pode ser delegada para um analista, mas a responsabilidade não sai nunca das mãos do gerente. Eu costumo especificar toda a interface dos usuários com o sistema: telas e relatórios. Depois de “colocar tudo no papel”, o gerente deve obter do cliente um “de acordo”, de preferência assinado no final do documento em que todas as páginas serão rubricadas com um “visto” para que ele tome ciência do que será feito. Não há palavras para expressar a importância deste planejamento em que as expectativas serão levantadas e moldadas, de forma que, diante do produto final, o cliente não possa se dizer decepcionado.

O terceiro cuidado é definir prioridades. O gerente deve ter a sensibilidade para identificar quais são os requisitos obrigatórios e quais os desejáveis, marcando cada um segundo com a sua prioridade. Isso evita que alguém arbitre o que é importante no lugar do cliente. Há gerentes de projeto que vão mais longe e pedem ao cliente para definir o que ele considera “sucesso” do projeto. Por exemplo, num sistema em que havia desperdício de 30% da matéria-prima, foi considerado sucesso reduzir esta taxa para 15%. Mas este número ainda é alto, diria você. Sim, mas o cliente considerou que uma redução de 50% dos desperdícios já representaria benefícios suficientes que compensariam os investimentos no projeto. Além do mais, lembre-se de que: “o ótimo é inimigo do bom”.

Em suma: definir o escopo, no fundo, é saber o que deve ser feito para atender a necessidade do cliente.

4. Conheça os envolvidos e monte seu time:

Todos os envolvidos no projeto são os “stakeholders”. Nesse grupo estão não apenas os membros da equipe, mas também os clientes e fornecedores envolvidos. Dentro da empresa do cliente, há uma pessoa que se destaca por ser a patrocinadora (“sponsor”) do projeto. Ela é que cria as condições para a contratação do projeto, mesmo que não seja ela que vá usar o produto final.

É importante que o gerente do projeto conheça os interesses de todos os envolvidos. Imagine como é arriscado contar com um membro da equipe que não está disposto a colaborar. Ele pode ser um problema mais do que uma solução dentro do grupo: sabendo disso, melhor pensar em chamar outra pessoa. Eu passei por uma situação destas quando fui destacado para gerenciar um projeto onde havia um colaborador mais antigo e que entendia que ele é quem deveria estar gerenciando. Eu não percebi seu ressentimento a princípio e à medida que o projeto avançava esta pessoa se tornava um problema cada vez maior, na medida em que, não só ele não fazia a sua parte, como minava os demais membros da equipe contra minhas decisões. Um dia, eu o chamei e abri o jogo. Ele então me explicou o que estava sentindo e fizemos um acordo: ele se enquadraria para completar o projeto, que graças a ele já estava atrasado, e eu o apoiaria junto à direção para que recebesse seu próprio projeto para gerenciar. É claro que manter um “profissional” com este tipo de atitude não é bom negócio para a empresa no longo prazo, porque cedo ou tarde ele vai acabar atirando contra a própria equipe novamente, só para mostrar que as “coisas têm de ser feitas do jeito dele”.

No processo de definição do escopo, as habilidades necessárias vão ficando mais claras. Nesse momento, é importante formar uma equipe com competência diversificada e com experiência nas áreas de atuação do projeto. Em projetos em que há muito conhecimento técnico envolvido, surge a figura do “líder de projeto”, um profissional com grande conhecimento técnico e com capacidade de liderança entre os técnicos. Em geral é um profissional sênior, com credibilidade junto aos demais técnicos e com muita bagagem. A experiência desse especialista pode economizar muito tempo e dinheiro no projeto. Dê-lhe voz ativa, cobre dele insights que você não tem e respeite a sua opinião. Só assim ele estará sempre do seu lado, mesmo quando você errar.

 5. Desenvolva o cronograma junto com quem põe a mão na massa:

Uma vez que temos as tarefas definidas a partir do escopo, temos de estimar a duração de cada uma. Procure fazer esta estimativa de tempo de execução com a ajuda de quem está escalado para executar o trabalho. Ao mesmo tempo em que essa pessoa é quem melhor sabe quanto tempo precisará, ela estará se comprometendo com um prazo para a sua execução. Por outro lado, quando se trabalha com consultores externos, o custo será função direta do tempo estimado para a execução do projeto. Ao fixar o cronograma, o profissional está dando por tabela um orçamento da sua parte.

Veja estas atividades que representam as linhas gerais de um projeto de sistema:

Note que além de saber o que deve ser feito, as tarefas têm três propriedades importantes: duração, inter-dependência e responsável. A duração é importante mas se as tarefas podem ser realizadas em paralelo, como é ilustrado neste caso onde há duas figuras: o analista e o programador, a duração total do projeto encurta. Dessa possibilidade de trade-off entre tempo e recursos alocados, alguns gerentes acreditam que se o projeto está atrasado, então “basta colocar mais gente” que o problema se resolve. Isso raramente ajuda uma vez que com mais gente, os problemas de comunicação aumentam e o projeto que já está atrasado atrasa mais ainda. Trazer mais gente pode ser útil quando se precisa de especialistas em temas que os membros não dominem. A rigor, se o planejamento foi bem-feito, já se sabe que esta mão-de-obra será recrutada em algum momento do projeto. A atitude de simplesmente aumentar a equipe para acelerar a produção é que está errada e deve ser combatida. Só que alguns gerentes de projeto medem seu poder pelo tamanho da equipe que gerenciam. Você pode imaginar como isso acaba: contratamos mais pessoas, eu fico mais “poderoso” e temos todas as explicações para os atrasos, afinal o projeto era mesmo “muito grande”.

O gerente de projetos deve trazer sua experiência para corrigir as expectativas muito otimistas de algum colaborador mais afoito. Sim, há quem estime 50 horas e depois, com a maior tranqüilidade, cobre pelas 120 horas que foram necessárias para realizar a tarefa. Ele só errou em 140% ! Se o preço é fechado, o risco fica todo com o consultor, mas a sua boa-vontade e a qualidade do produto final podem sofrer em decorrência da pressa. Se a remuneração ficar vinculada ao tempo de prestação de serviço, o contratante precisa de um mecanismo de controle minimamente confiável. Eu não uso uma fórmula geral, prefiro trabalhar segundo as características do profissional mas de todos exijo um relatório de horas que contém o dia, data de hora e início, tempo de trabalho e a(s) tarefa(s) realizadas no dia.

Se no planejamento da semana há tarefas que não foram realizadas, na reunião de avaliação, eu pergunto porque a coisa não seguiu o ritmo programado e quanto isso impacta na data final de entrega. Procure estabelecer pontos de controle, “check-points”, que são datas onde se medirá o andamento do projeto em face do cronograma que havia sido programado. Nestas datas, pode-se estar apenas executando-se uma verificação do progresso das atividades (“milestones”) ou pode haver entrega de produtos ou sub-produtos (“deliverables”) tais como desenhos, especificações, protótipos, modelos, etc…

Quem já reformou ou construiu uma casa sabe que esta tão trivial experiência de gerenciamento de projeto pode acabar mal. Quantas histórias existem de gente que foi pagando o pedreiro sem atrelar os pagamentos a entregas de tarefas determinadas. Nestas histórias tristes, o dinheiro acaba antes da obra, e o pedreiro some, deixando o cliente sem dinheiro e sem a sua casa. Tudo porque ele não cuidou de atrelar entregas de tarefas a pagamentos, não criou pontos de controle que lhe dariam visibilidade do atraso. Sabendo antes que a “vaca está indo para o brejo” o cliente pode optar por “apertar” o pedreiro ou suspender os trabalhos enquanto ainda tem dinheiro, que poderá ser usado para pagar uma equipe mais eficiente.

É verdade que em projetos de TI nem sempre dá para “trocar o pedreiro” porque há muito conhecimento e estudo envolvidos. Mas por isso mesmo, temos de ser muito mais cuidadosos na monitoração para saber em que momento o projeto começa a atrasar e como fazer para recuperar o ritmo no futuro próximo.

6. Monitore os riscos e seja pró-ativo

Agora que todos sabem o que devem fazer, é importante mitigar os riscos que podem impedir o bom desenvolvimento do projeto. Desenvolva uma lista de fatores de risco e um plano para lidar com eles. Mas lembre-se de que são duas coisas diferentes: a monitoração do risco e controle do risco.

A monitoração dos riscos envolve acompanhar o status de cada risco e as opções de ações definidas para enfrentá-los, caso eles venham a se tornar problemas reais. A monitoração também se preocupa em avaliar a probabilidade de ocorrência de um risco, qual o seu impacto no andamento do projeto e como contorná-lo. Por exemplo, numa determinada tarefa crítica a contratação de dois profissionais pode parecer um exagero mas o gerente do projeto sabe que se algo acontecer nesta área do projeto o impacto será grande no restante. Os profissionais passam a ser um backup do outro dentro da linha de que “quem tem um, não tem nenhum”.

Voltando ao nosso projeto de exemplo, chamo a atenção para um recurso que o MS Project tem e que deve ser usado para se identificar riscos. Veja a tela do diagrama de Gantt que obtivemos a partir da lista de tarefas que elaboramos acima:

Note que há uma seqüência de tarefas que quando alinhadas compõem o prazo de duração do projeto todo. Destaquei o início e o final só para que você perceba que se trata de uma série de processos que devem ser gerenciados mais de perto uma vez que o atraso em algum deles acarretará o atraso do projeto todo. Por isso é que se chama este de “caminho crítico”. Os riscos que estão embutidos nestas tarefas são os que se deve gerenciar mais de perto, de forma mais pró-ativa.

O controle dos riscos é o processo de executar o plano de ações e divulgar seus relatórios de status. Inclui também possíveis mudanças no plano de riscos, e eventualmente até nos planos do projeto. Essas mudanças são referentes a recursos, funcionalidades ou cronograma.

7. Formalize o início e o encerramento do projeto

O início do projeto é um momento solene. O patrocinador deve formalizar a todos os envolvidos que o projeto está iniciado e o cronômetro está correndo. Muita gente não gosta de se preocupar com isso, mas imagine que haja resistência de setores da empresa que se opõem ao projeto. Sem um documento que atesta que o projeto começou, o gerente pode não conseguir apoio algum. Além disso, este documento funciona como um “cumpra-se” de uma autoridade da empresa: não cabe discutir a ordem, o projeto começou e todos os “arrolados” devem participar.

Outro momento importante é o do encerramento do projeto. É preciso formalizar o final para que fique claro para todos os envolvidos, especialmente para o cliente, que o projeto está concluído e que novas necessidades serão atendidas em um novo projeto. Qualquer extensão ou alteração deverá ser orçada e todo o ciclo se inicia novamente. Com relação à manutenção do sistema entregue, não se pode considerá-lo um projeto na medida em que, a princípio, trata-se de um processo contínuo. O que pode ocorrer é definir-se projetos ao longo da vida útil do sistema com o objetivo de melhorá-lo. Por exemplo, a atualização dos equipamentos eletrônicos (“aviônicos”) de um avião para auxílio ao vôo é um projeto que se distingue da sua manutenção rotineira.

Ao final faz-se também uma reunião de avaliação dos erros e acertos da equipe. Chamadas de reuniões “post-mortem”, elas servem para se gerar uma lista de “melhores práticas” contribuindo para a formação de uma base de conhecimento que poderá ser muito útil em projetos futuros. Da minha experiência pessoal, posso dizer que tirei grandes lições quanto às “piores práticas”, atitudes e decisões que se mostraram ruins e que devem ser evitadas em projetos futuros.

Conclusão

Acima de tudo, gerenciar projetos é planejar e acompanhar a execução com “um olho no peixe e outro gato”. O gerente do projeto deve se manter alerta e flexível com os acontecimentos do dia-a-dia mas deve estar sempre se reportando ao plano inicial para não perder o controle. A principal qualidade do gerente de projeto é saber se comunicar bem com todos. Ele é o ponto focal das informações, nele convergem as informações que ele depois deverá processar e divulgar para todo o restante da equipe.

O segredo é envolver a equipe, cliente e fornecedores de tal forma que todos se sintam diretamente responsáveis pelo sucesso do projeto. Como diz aquele velho ditado caipira, “quando todos empurram na mesma direção, ná há carroça que não saia do atoleiro”.

Fonte: http://www.microsoft.com/brasil

Segundo Philip, o autor deste artigo, o analista deve ser focado nas regras de negócio.

“O analista deve trabalhar em conjunto com os stakeholders para gerar uma visão única do projeto (já que possivelmente cada stakeholder que uma coisa diferente) e transformar isso em algo que possa ser executado (histórias). No meio do caminho eles ajudam a eliminar desperdício, introduzir idéias novas, validar os pedidos, conferir viabilidade e tudo mais que não faz parte do papel de um desenvolvedor e sim de alguém que, de fato, entenda do negócio do cliente.”

“Note que o papel do analista de negócios não elimina a necessidade de termos um cliente presente. Não existe mapeamento de requisitos ou coisas do tipo, além de usar seu expertise naquele domínio em específico, o analista de negócios age como facilitador e não como ponte entre cliente e desenvolvedores. Ele também não é um tradutor, os termos de negocio e os processos devem ser entendidos por todos os envolvidos.”

Particularmente, eu sou de acordo com a idéia que o analista deve sim ser expert em entender a regra de negócio, ou ainda, ter perfil de negociador, isto é, alguém que sabe como fazer o cliente expor as informações chaves e necessárias para solução do problema dele, e principalmente para convencer o cliente do que ele realmente necessita. Pois o que temos hoje são equipes que possuem desenvolvedores que não entendem do negócio e clientes que não sabem exatamente o que necessitam, resultando em sistemas que vão ao ar não contendo “exatamente o que o cliente necessita, seja por falha de comunicação ou porque ele mudou de idéia e “esqueceu” de avisar aos desenvolvedores”.

Para uma metodologia mais ágil de gerenciamento de projetos, essa visão de analista seria muito mais eficaz, uma vez que o analista seria o facilitador para que a equipe pudesse trabalhar de forma mais objetiva e específica, atuando no problema bem definido e não na “lista interminável de desejos do cliente” que só descobre não serem necessários no final, quando já se gastou muito tempo e esforço para o seu desenvolvimento.

Portanto é preciso avaliar cada cenário e diagnosticar qual será a verdadeira função de um analista dentro de cada cenário.

Quem quiser ler o artigo do Philip, acesse: http://blog.fragmental.com.br/2008/11/23/deixa-para-os-analistas-de-verdade/ – Deixa Para os Analistas de Verdade… por Philip Calçado

 Foder, cuzinho, boquete, oral, chupeta, gostosas.

Fonte: www.gerenciamentodeprojeto.com

Esse é o objetivo do UML. E todos nós usamos a tecnica no dia-a-dia sem percebemos. Por exemplo, quando vamos determinar um objetivo no dia criamos uma classe de eventos e desenhamos como iremos fazer isso. Digamos que o que vamos fazer no dia é ir para faculdade.

Você (Classe:humano\nome,estudante\estagiario\trabalhador\Ir até faculdade) pegar o metro,onibus, a pé ou taxi\carona afetiva(amigos)\Vans. Quantos processos terá que fazer?

Primeiro acordar. Segundo vestir-se e pegar a condução. Se for a pé(pegar a melhor rota), se for de veiculo pegar o mais barato\melhor rota e melhor horário (No caixa é preciso pagar o valor).

Chegar no local de destino, entrar na faculdade. Assistir as aulas e refazer o caminho de volta.

O número de processo duplica, e sabemos que com o tempo tornamos o processo automático, e na maioria das vezes erramos neste processo quando o alteramos um milésimo do lugar. E o que fazemos quando erramos?Corrigimos e geralmente nestes casos,tarde demais.

Por isso o UML é uma forma de organizar as entidades que iremos encontrar. São elas:

• Onibus (trocador,motorista,passageiros);
• Taxi (motorista,taximetro)
• Metro (condutor,passageiros,bilheteria)
• A pé (sinais de transito,rotas)
• E você.

Viu quantas entidades pelo caminho encontra-se. E o UML trata dos eventos,estados,casos de uso?Não. Ele trata da definição de classes,atributos e operações. Tudo que podemos considerar como dados. Vamos ver o que este UML significa, veja a figura a seguir (logo abaixo a fonte)

Figura UML-Exemplo 1.0:

(Fonte: Nigini’s Page )

Interpretação do exemplo 1.0:

O que vemos aqui é uma classe e subclasses. A definição de classe é a que encontramos no dicionário – “classificação”. Quando queremos definir um grupo de dados, o classificamos pela sua natureza. Grupo de alunos,grupo de músicos,grupos de cineastas e etc.

A classe é a entidade. Os atributos que podemos encontrar são os dados da classe,em outras palavras as características. (Quais os atributos do grupo de alunos[Nome,matricula,notas,turma,colégio,idade,série],quais os atributos do musicos[Instrumentos,solo\grupo,genero de musica) e operações e funções.

Estas operações são em resumo o "fazer" da classe. Por exemplo, um grupo de alunos tem de fazer algo. Senão a lógica de existir o grupo deixa de ter sentido. O grupo é um conjunto de pessoas que são reunidas para realizar alguma função. (Estudar,bagunçar,ajudar).

Então digamos que função tem característica de realizar algo, o objetivo do grupo.

Mas se o UML só serve para definir as entidades, do que adianta ele num planejamento? Adianta no quesito de definição, mas para visualizar eventos (processos em andamento) é preciso entrar em Diagramas de caso de uso (DCU). É uma forma transparente de ver os processos acontecendo. Lembra da pessoa que ia até a universidade no começo deste artigo? Sabe o que faremos agora?

Iremos definir as ações unido com o seu UML entidade. Vamos ver o diagrama de caso de uso á seguir:

Figura DCU - Exemplo 1.1:

(Fonte: Macorati )

Os exemplos possuem dados da informática, mas este artigo tem o objetivo de demostrar que o UML e o DCU podem ser usados em qualquer área que possa existir.

A ilustração do exemplo 1.1 é conhecida na análise de sistemas como DFD (Diagrama de fluxo de dados) ou como podemos definir Diagrama de casos de uso (DCU) e devemos saber que estes diagramas nos dizer como as funções irão atingir a meta do sistema. Quando vamos á algum lugar, vamos mediante a função. Em função de, fazemos algo. É claro e objetivo. O DCU\DFD não pode ser de maneira alguma confuso, senão não adianta nada diagramar.

Figura DFD - Exemplo 1.2:

(Fonte: Linha de codigo DFD )

Interpretação do DFD do exemplo 1.2:

• Quadrado é entidade atuante (PC,Humano)[Entidade externa];
• Seta é entrada de dados,consulta,alteração ou exclusão de dados[Fluxo de dados];
• Circulo é o evento(ação);
• Duas retas paralelas é o banco de dados (depósito)

Isso que chamamos de DCU ou DFD. É bom lembrar que DFD pode ser definido em dois tipos de DFD. O DFD(1-9) e o DFD-Z(Z de zero). Respectivamente, o DFD-X (X variando de 1 á 9) define diagramas de casos de uso detalhado) e no caso do DFD-Z ele define todos os casos em um só diagrama sem detalhamento.

O valor de 1-9 vem da percepção humana, que diz que só conseguimos perceber 9 objetos ao mesmo tempo. (Tire suas próprias dúvidas sobre isso, teste se é capaz de entender e perceber mais do que 9 objetos, ou se consegue 15 ou 3) A questão é que a percepção deve ser conclusiva, saber que a entidade A1 está relacionada com A9.

Tem dúvidas? Entre em contato pelo comentário. Ou visite os sites, pois as fontes possuem artigos que explicam cada um dos exemplos ilustrativos com outras palavras.

Comentários adicionais:

Na minha opnião existe muita tecnologia, que fica restritivo ao ramo da computação, que é ignorado pelo fato de haver termos de orientação á objetos (00), linguagem UML (Star UML), na verdade estes conceitos são de administração.

E foram automatizados, não sei se a área de administração desenvolve DFDs desta forma ou se existe uma variante do mesmo.

Concluindo, a UML(+DFD) torna o planejamento mais objetivo e conciso.

A maior parte, senão tudo, é UML voltado para desenvolvimento de software. Mas o conceito do UML é administração é tratado dia-a-dia por todos nós. mesmo sendo ou não da área de informática.

A reunião inicial visa apresentar a todos os participantes, os objetivos e metas a serem atingidos com a execução do projeto. Além disto, deve-se divulgar o cronograma das atividades, as responsabilidades, os principais aspectos metodológicos que serão utilizados e os principais riscos do projeto, para que todos se sintam compromissados com os resultados pretendidos. É através da reunião inicial que todos os participantes têm a oportunidade de se conhecer pessoalmente, por isso, recomenda-se que ao final da reunião se realize um evento social, como um coquetel ou algo similar, buscando facilitar a comunicação futura no projeto e integrar as equipes. Nesta reunião são divulgados os procedimentos operacionais que serão utilizados, como: lançamentos de horas e critérios adotados para relatórios de despesas dos participantes. O gerente de projetos que é responsável pela organização da reunião inicial, sua divulgação e realização, deve ter em mente que a presença do patrocinador do projeto é requisito indispensável para sua realização.

As reuniões de progresso ou de avanço de projeto são realizadas conforme periodicidade previamente definida, ou em função de necessidades identificadas pelo gerente no transcorrer de sua execução. Um aspecto relevante é que toda reunião tenha data, local, horário, duração e pauta previamente definidos. Neste tipo de reunião devem participar somente os profissionais que exerçam papel de coordenadores ou líderes de frentes de trabalho, o gerente de projeto e se possível, o patrocinador. Um item para se desmistificar é a presença de todos os participantes do projeto: isto é pouco viável em termos logísticos e não é nada produtivo, pois há uma tendência a se discutir minúcias, perdendo-se o foco principal que é discutir os desvios dos cronogramas, identificar as ações corretivas e preventivas para as ocorrências do projeto, sejam na área de recursos humanos, de gestão da qualidade dos deliveries, de aquisições, etc. Estas reuniões devem ser obrigatoriamente documentadas. Neste aspecto, destaca-se que a documentação deve ser objetiva e registrar as principais decisões tomadas e as ações pendentes, com os respectivos responsáveis e prazos. Evidentemente, que a distribuição deve ser realizada logo após a sua realização.

As reuniões executivas podem ser planejadas com periodicidade previamente definida ou conforme necessidade identificada pelo gerente do projeto. Estas reuniões, com indispensável presença do patrocinador, devem ter duas sessões: a primeira, que apresenta a evolução do projeto, uma visão gerencial do cronograma e dos indicadores de desempenho; por exemplo, os indicadores de mercado como o CPI (Cost Performance Index) e SPI (Schedule Performance Index), respectivamente o indicador de custos e de prazos no projeto, embora possam existir outros indicadores próprios da organização (de comunicação, de riscos, de satisfação do usuário final e outros). A segunda parte da reunião é acerca de discussões de novas demandas e necessidades no projeto, pois toda e qualquer alteração de escopo deve ser discutida e aprovada, após apresentação dos impactos em custos e prazos. Assim, a primeira parte da reunião é informativa, e a segunda parte, decisória.

As reuniões de encerramento de fase ou de projeto têm por objetivo formalizar o encerramento da fase ou projeto, divulgando a toda equipe o caminho percorrido, os resultados obtidos, os indicadores de desempenho do projeto e as próximas etapas, caso existam. É recomendado que os profissionais que excederam o desempenho esperado, e que fizeram a diferença para o atingimento dos resultados da fase ou do projeto, sejam reconhecidos e premiados. Caso haja recursos financeiros disponíveis no orçamento do projeto, uma comemoração coletiva pode ser extremamente gratificante para a equipe participante.

Além das reuniões de abertura do projeto, das reuniões de progresso, das executivas e de encerramento que são detalhadamente apresentadas pelo autor Henri-Pierre Maders em seu livro “Piloter un projet d’organisation” (Editora Eyrolles, Paris, 2008), a autora JoAnn T. Hackos em seu livro “Information development: managing your documentation projects, portfolio and people” (Editora Wiley, Indianápolis, 2007) recomenda que ao final de um projeto haja a realização de reunião específica para captura de “lições aprendidas” no projeto (o que deu certo, o que deu errado), pois as informações capturadas transformam-se em base de conhecimento para os próximos projetos na organização. A autora destaca a importância em identificar os participantes da reunião, valorizando o convite e a presença. Para os não-convidados (mas que participaram do projeto), deve existir uma comunicação específica informando da realização da reunião e dos critérios para elaboração dos convites, para não criar melindres e para que o profissional não se sinta desvalorizado.

Assim, as reuniões de projeto deixam de ser “burocracia” ou “perda de tempo” como argumentam algumas pessoas que resistem a metodologias ou disciplinas de gestão. As reuniões de projeto há muito deixaram de ser necessárias, passaram a ser imprescindíveis ferramentas de comunicação e gestão!

Fonte: http://www.artigonal.com

Fonte: www.pmkb.com.br

Muitos autores e profissionais da aérea questionam o uso de UML em projetos. Particularmente eu acredito que a UML traz muito valor para um projeto OO, porém devemos discernir quais diagramas são válidos para a realização da Análise de Requisitos, Design e Arquitetura. O próprio Scott Ambler questiona muito o uso “inicial” de ferramentas para a diagramação. A abordagem recomendada por ele é que após um determinado momento do projeto, quando o Domínio já está mais maduro, que seria interessante diagramar em uma ferramenta.

Bom, voltando ao RUP, vou explicar um pouco mais o processo. Talvez depois dessa explicação muitos mitos que você ouviu ou ainda ouve possam ser explicados. Caso a sessão abaixo não acabe com suas “Dúvidas, Angustias, Agonias e Tristezas” não se preocupe, no final vou fazer um resumo em grandes tópicos desmistificando diversas “Besteiras” que eu e com certeza você já deve ter ouvindo sobre o processo.

Princípios do Processo

O RUP se norteia em princípios largamente utilizados no desenvolvimento de software desde o seu surgimento até os dias presentes. O processo, ao contrário que muitos pensam, não prega que devemos fazer tudo exatamente como está no papel, ele prega que devemos seguir as boas práticas de desenvolvimento de software e ele se propõe a ser um guia que ajuda na construção de software de qualidade.

Os princípios que descreverei a seguir são utilizados há mais de uma década pela Rational com sucesso. O Processo prega que o desenvolvimento deve estar cada vez mais próximo na área de negócios, isso é o ideal que muitas vezes não é feito. Quantos de nós não cansamos de ver projetos sendo Sepultados e falhando porque não atenderam as necessidades do negócio? A idéia do processo é fazer com que de fato essas necessidades sejam atendidas.

1º Adaptar o processo: Bom, eu gosto muito de falar que esse é o primeiro principio chave do RUP, porque as pessoas acham que devem utilizar todos os Roles e Artefatos que existem no RUP. Isso só prova a ignorância e desconhecimento do processo.

O Objetivo desse princípio é dimensionar correntemente o processo para o projeto e a empresa em questão. A instrução é que devemos adaptar o grau de cerimônia e controle que o processo prove bem como o tamanho da equipe e quantidade de roles. Todos esses fatores só podem ser realizados projeto a projeto.

Estimativas iniciais: O Processo é claro quando diz que é um Anti-Pattern desenvolver estimativas antecipadas e fixas e bem como planos precisos e gerência através de ajustes nesse plano estático.

Dependendo do projeto e das características do mesmo, o uso maior de cerimônia e controle. Isso pode ser uma realidade em projetos com muitos investidores e quando existem questões de Compliance como SOX. Isso não é muito comum no Brasil (SOX), mas na Europa e Ásia é uma realidade constante, apesar de ser algo relativamente recente.

2º Equilibrar prioridades dos investidores: Esse princípio prega que devemos equilibrar as necessidades dos investidores do projeto como o desenvolvimento de customizações VS e a reutilização de recursos. A idéia do RUP é de otimizar ao máximo o valor do negócio.

O principio é guarda-chuva para a boa prática de priorização de Requisitos e até mesmo priorização de projetos. Novamente o processo é claro quando diz que é um Anti-Pattern documentar os requisitos minuciosamente no início do projeto e negar a mudança de requisitos.

De forma enfática, o RUP prega que, para podemos atender e priorizar as necessidades dos investidores de forma correta, precisamos gerenciar os requisitos efetivamente. Para que isso aconteça de forma efetiva é necessário que o cliente esteja envolvido no projeto para garantir que as necessidades do mesmo sejam compreendidas.

Reutilização: A Reutilização de recursos como sistemas legados, componentes, serviços pode reduzir os custos de um projeto em até 80%. Portanto a reutilização é necessária para que podemos equilibrar os custos. Nesse ponto o processo se encaixa perfeitamente com a Filosofia SOA. E notem que o RUP surgiu muito antes de SOA.

3º Trabalho em Equipe: Esse principio descreve como é possível desenvolver efetivamente o trabalho e colaboração através de equipes. O princípio diz que é importantíssimo desenvolver uma comunicação ampla no projeto através de ambientes de Colaboração. Vejam que muitos desses conceitos que o RUP traz são pregados por métodos ágeis. Mas o RUP veio muito antes do movimento ágil, então como isso é possível? Será que o movimento ágil se inspirou em conceitos que já existiam no RUP? Isso pode ser muito doloroso para alguns, mas a resposta é SIM!

Esse princípio prega que deve haver uma comunicação efetiva entre analistas, desenvolvedores e outros participantes do projeto, além de motivar pessoas e integração com áreas operacionais do negócio.

Novamente existe clareza na definição do processo quando se diz que é um Anti-Pattern ter desenvolvedores heróicos que trabalham horas a fio, incluindo finais de semana.

Outra questão clara e condenada pelo processo é o fato de ter desenvolvedores altamente qualificados com ferramentas e não existir colaboração e comunicação.

4º Demonstrar Valor iterativamente: O desenvolvimento iterativo Incremental que gera o famoso “Incremento de Software” é a maneira mais eficiente na maioria dos casos para se desenvolver software. Independente do processo e metodologia utilizado, usar o modelo de cliclo de vida de projeto “Iterativo incremental” é um fator chave para o sucesso.

Dentre os benefícios dessa abordagem, temos o Feedback que é importantíssimo e com ele podemos fazer correções de rumo no projeto a tempo.

Isso não é do RUP, mas eu acho fantástica a frase “Abrace as pessoas, Gerencie a mudança“. Devemos gerenciar a mudança e não simplesmente aceitá-la sem maiores entendimento e priorização. Pois se não podemos vivenciar o fenômeno de “Creep Requirements“.

No que diz respeito ao RUP, ele fala que devemos gerenciar as alterações e ele vem em uma abordagem Orientada a Riscos. Significando que devemos atacar inicialmente os maiores riscos do projeto.

Novamente o processo é claro quando diz que é um Anti-Pattern planejar detalhadamente todo o ciclo de vida do projeto. Percebam que o RUP não é contra estimativas, pelo contrario, é a favor, porém existe um momento mais apropriado para estimar, e esse momento não é no inicio do projeto. Nesse ponto que entram questões como o Cone de incertezas e modelos de contratos.

Sobre as iterações: A idéia é que a cada iteração realizamos tarefas relacionadas a requisitos, design, arquitetura, implementação, gestão e testes. Essas atividades são repetidas durante várias iterações. Dependendo do tamanho do projeto, a diferença é que a cada iteração essas atividades estarão atuando sobre um conjunto de requisitos diferentes.

5º Elevar o nível de Abstração: Esse conceito não é brinquedo, quando digo isso estou querendo dizer que isso não é uma tarefa simples de ser efetuada. A idéia é que elevando o nível de abstração podemos diminuir a complexidade.

Essa questão está totalmente ligada à quantidade de documentação do processo. Podemos conseguir isso através de reutilização, ferramentas e de modelos arquiteturais. Mas quando eu falo arquiteturais não estou dizendo que a arquitetura deve resolver todos os problemas, mas ela deve resolver os maiores problemas. O princípio reduz a complexidade conforme já relatei antes, mas também é uma fonte poderosa de aumento de produtividade.

O RUP informa que é um Anti-Pattern você desenvolver requisitos vagos de alto nível. É outro Anti-Pattern revisar exaustivamente requisitos capturados ‘Verbalmente’. O RUP coloca como outro Anti-Pattern o fato de colocar a solução de todos os problemas na arquitetura.

Na questão da representação das abstrações, a UML é muito útil pois com ela podemos expressar bem esses modelos.

6º Foco Contínuo na Qualidade: Qualidade é algo com que sempre devemos estar comprometidos. Esse princípio do processo enfatiza que podemos atingir a qualidade através de testes contínuos. E até mesmo automação de testes, sendo que em alguns casos é relevante desenvolver uma solução arquitetural para automatização de testes.

Para que o princípio seja atendido, devemos identificar medidas e critérios. Isso não se trata de apenas “Atender os Requisitos”. A qualidade não deve residir apenas na equipe de testes, ou em profissionais de Q.A. Mas em todos os membros da equipe como analistas, desenvolvedores e gerentes.

Por fim, o processo identifica como um Anti-Pattern o ato de fazer com que os testes aconteçam somente em uma fase e conduzir testes detalhados em todos os artefatos.

Além desses princípios chave do processo, o RUP é centrado na Arquitetura e em casos de Uso. Casos de uso não significa que têm que ser visuais conforme o diagrama de casos de uso da UML, mas eles podem ser textuais.

O processo é iterativo Incremental, sendo que ele possui marcos. Esses marcos nos ajudam a nos situarmos no projeto e ver se o projeto tem condições de continuar em termos de riscos e se estamos no rumo correto.

A figura acima mostra as fases do processo (Inception, Elaboration, Construction e Transiction).

O propósito da figura, que também é conhecida como gráfico de baleias, é mostrar as disciplinas do projeto como (construção, requisitos, configuração, etc..) através das iterações e com os marcos de fases. O gráfico de baleias mostra a intensidade das disciplinas através das iterações e fases.

Realizando a Adaptação

Também conhecido como tailoring. Essa palavra é temida por muitas pessoas, mas não podemos condenar nossos irmãos mais ignorantes e desprovidos de informações. Baseados nesses conceitos chaves do RUP que apresentei acima, podemos realizar o tailoring do processo de acordo com as necessidades do mesmo.

O RUP define uma série de elementos essenciais que você deve considerar seriamente ao realizar o tailoring do processo. São os elementos:

1. Visão do projeto: Devemos desenvolver uma visão do projeto para deixar registrados os interesses do projeto bem como os seus objetivos e requisitos que devem ser atendidos. Esse recurso nos possibilita alinhamento com os stakeholders do projeto e membros da equipe técnica.

2. Plano de Gerência: Devemos desenvolver um plano de desenvolvimento e gerência do projeto. No plano do projeto iremos expor o planejamento do projeto de forma aberta demonstrando os recursos necessários como orçamento, escopo e pessoas.

3. Mitigar Riscos: Esse é outro ponto essencial em um tailoring do RUP. Sempre devemos levantar os maiores riscos para o projeto e planejar formar de ação contra esses riscos. Devemos criar uma Lista de Riscos e através dela dirigir ações e decisões do projeto.

4. Casos de Negócio: São as informações necessárias do negócio que nos dizem se vale a pena ou não investir no projeto. Seu propósito é para viabilizar o plano econômico do projeto bem como questões relativas a ROI. Através dele são criados argumentos convincentes em termos de Custo vs. Benefícios que dão base à criação do projeto.

5. Projete uma Arquitetura: Com o aumento da complexidade em termos de desenvolvimento de sistemas, uma arquitetura se faz necessária sendo uma estrutura base que trata e interfaceia os principais problemas da aplicação.

6. Uso de Protótipo: Utilizar protótipos para refinar e entender os requisitos e necessidades do usuário. Esse uso está relacionado à idéia de desenvolvimento iterativo e incremental e com testes.

7. Avaliação de Resultados: É importante a comunicação aberta e freqüente provida através de Feedback. Freqüentemente devemos medir os resultados do produto de software e com isso realizar as correções de rumo necessárias para atender as necessidades do cliente bem como a acomodação de mudanças. Sendo que a avaliação da iteração é um elemento chave no desenvolvimento iterativo e incremental.

8. Controle as mudanças: Controlar mudanças não significa “barrar” mudanças. Mudanças sempre irão ocorrer, isso é fato, mas o que devemos fazer é passar essas mudanças por um mecanismo de controle de mudanças gerências por um processo consistente. Uma das vantagens do controle de mudanças é o fato de possibilitar a análise de impacto, que é uma poderosa ferramenta que pode nos “dizer” o quanto será custoso implementar essa mudança.

Nota: Você pode realizar mudanças com ou sem análise de impacto. A questão é que com análise de impacto você sabe onde está pisando. Sem a análise de impacto você pode tomar um susto no momento de codificar a mudança!

9. Suporte ao Usuário: Aqui o RUP se preocupa com questões de “Usabilidade”. E como são importantes essas questões. Dependendo do produto de software, é necessário ter até um guia ou documentação procedente de como se deve utilizar o produto. Essa necessidade irá variar de acordo com o projeto.

10. Adotar um processo: É fundamental escolher um processo que se adapte ao projeto e a organização em questão. Aqui o RUP se referencia ao seu primeiro conceito chave: Adaptar o processo. As questões de adaptação de projetos o RUP tratam em sua disciplina de ambiente.

Verdades e Mitos

Como mencionado antes, espero que após você ter lido o que eu escrevi, diversas “Bobagens” tenham saído de sua cabeça. Mas se isso não aconteceu, agora vou ser mais direto. Então vamos a algumas verdades.

Verdades

• O RUP é um processo de desenvolvimento de software com um grau de cerimônia maior.
• É pago, logo o acesso as informações é dificultado
• Com certeza é o processo mais utilizado hoje em dia, porém foi e é utilizado de forma errada.
• Consultorias do processo são caríssimas.

Mitos

O RUP é Cascata: Eu já cansei de ouvir isso. Muitas pessoas pensam que o RUP é cascata. Se você leu o que eu escrevi acima vai ver que eu disse “Iterativo Incremental”. O RUP não é Cascata!

O RUP é pesado: Essa é outra besteira, o que é pesado é a burrice das pessoas. O que pesa é o tailoring do RUP que você faz ou, muitas vezes, o tailoring que você não faz. Existem cenários em que o RUP vai ser realmente muito cerimonioso e formal, porém isso depende da situação. E o fato de algo ser formal não significa que é ruim, depende muito da situação. O RUP não é pesado!

O RUP prega BIG Especs. Up to Front: De forma alguma! Muitos utilizadores do processo acabam cometendo esse erro. Mas se você leu o que eu escrevi acima não vai mais acreditar nisso. Infelizmente esse erro é muito comum dentro os utilizados da metodologia, muitas vezes por desconhecimento. O RUP não prega BIG Especs. Up to Front.

Casos de uso Textuais são ruins: Olha, pessoal, a forma mais amorosa que eu tenho para responder isso é bom… não vou nem falar. O RUP é baseado em casos de uso, além do mais casos de uso são eficientes para especificarmos. Casos de uso não são ruins.

Com o RUP podemos ter pessoas ‘mais fracas’: Pro diabo! Eu já cansei de ouvir isso também. E o pior de utilizadores da metodologia. O RUP não especifica isso em lugar algum na especificação do processo. Com pessoas ‘fracas’ ou ‘incompetentes’, o resultado será ruim. Não existe processo ou metodologia no mundo que consiga obter sucesso com pessoas ‘fracas’. O RUP não encoraja esse tipo de loucura.

Infelizmente as empresas ainda usam o modelo em cascata, e em muitas vezes tentam transvestir esse modelo em cascata com uma roupinha do RUP. Ao meu ver o processo é bom e pode ser utilizado em diversos cenários.

E quanto às metodologias Ágeis?: Acredito que uma coisa não elimina a outra. É extremamente valioso nós unificarmos valores ágeis com processos de software que o RUP prove. Acredito que sempre devemos estar buscando o equilíbrio projeto a projeto: de disciplina a cerimônia vs. agilidade.

O RUP é um processo muito bom que pode ser utilizado em diversos cenários. O que devemos fazer é adaptar o processo de forma correta sempre pensando nos 6 conceitos chave do processo que descrevi nesse post.

Fonte: http://imasters.uol.com.br

Modelo de Project Charter 1

Nota: A utilização do modelo  fornecidos é de inteira responsabilidade do usuário, não tendo o documento nenhum vínculo com este blog.

Parte 2:

Parte 3: