Marcel,
Perfeito!!! Teu texto ficou grande, e na metade, quando eu já
pensava em falar sobre o RUP que menciona a participação do Gestor
ou Gerente de Projetos em varias etapas, voce pediu calma.
Apresentei uma monografia no qual eu procurava uma interseção
entre o ITIL e o PMBoK. Não deu muito certo, pois GP se aplicaria
mais ao CMDB ou projetos que visassem correções de falhas e etc.
Tambem verificamos que o CMMI tem buscado incorporar algumas coisas
do ITIL, e já possuia disciplinas de GP.
O RUP e o CMMI, com ou sem apoio do PMBoK, realmente são aplicaveis
a situações em que temos equipe para preencher tanta papelada. Voce
tambem disse certo. Não é que inexista a documentação no SCRUM,
porem lembretes, fotos, entre outros, servem.
O Ricardo Vargas, um dos membros do PMI-MG, presente no conselho
diretor mundial, mencionou a poucos meses sobre este metodo, e tambem
as alterações no PMBoK 4 ED. Ele tem uma serie de podcasts, são
curtinhos, e outros downloads. Se alguem se interessar e quiser
baixar, o site dele:
Abraço.
On Qui 13/08/09 17:30 , Marcel Fleming [email protected]
sent:
Anderson, Relington.... legal essa discussão.
Vou tentar botar mais lenha na fogueira, no bom sentido.
Se lembram que no meu primeiro post eu mencionei que há dois eixos
ou dimensões na gestão de um projeto? Então. Se vocês tiverem
acesso ao PMBoK, sugiro darem uma olhada no Cap. 2, Project Life
Cycle and Organization.
Mas vamos partir de uma situação utópica...
O Bill é o dono de uma software-house que pensou em um produto
inovador, tem recursos disponíveis de sobra, não precisa dar
resultado para a empresa, nem dar satisfação pra ninguém, não tem
ninguém para dar palpite no produto ou exigir que ele esteja pronto
num dado momento (os tais chamados stakeholders).
Ele monta a equipe e define um processo de desenvolvimento, por
exemplo, baseado em RUP, uma equipe de trabalho. Suponha que ele vai
dizer como o sistema deve funcionar. Então ele pega uma parte da
equipe, os analistas de negócio ou de requisitos, e eles começam a
escrever Casos de Uso mais importantes ou críticos para o sistema.
Esses Casos de Uso serão passados para um arquiteto, na chamada fase
de Concepção, o arquiteto, com base nesses Casos de Uso, irá
definir alguns padrões arquiteturais da aplicação, e definir que,
na fase seguinte, a chamada Elaboração, alguns desses Casos de Uso
serão desenvolvidos para mitigar ou eliminar alguns riscos que ele
viu no conjunto de Casos de Uso.
Na fase de Elaboração, estes Casos de Uso (documentos) serão
passados para os programadores ou arquitetos para serem codificados e
testados, de forma a validar as definições arquiteturais. Em
paralelo, os analistas de negócio continuam a escrever os Casos de
Uso restantes, menos complexos ou críticos, que serão passados para
os desenvolvedores na fase de Construção e por aí vai.
De um modo geral, o que descrevi acima, muito sucintamente, é uma
metodologia de desenvolvimento baseado em RUP. Ela fala em papéis
(analista de negócios, arquitetos), artefatos (casos de uso), fases
(Concepção, Elaboração...). Seria o Eixo de Processo de
Desenvolvimento.
Na visão do PMBoK, este processo acima descreve o chamado Ciclo de
Vida do Projeto, que está muito associado com o tipo de projeto:
para construção de uma casa, o ciclo é outro; para a realização
de um evento, seria um outro ciclo de vida; para os preparativos de
um casamento e lua de mel, ainda um terceiro ciclo de vida.
Tirando alguns pontos, as atividades neste ciclo são voltadas para
a entrega do produto final - o software ou sistema sendo desenvolvido.
Como o Bill não tá nem aí para prazo, custo, riscos.. o processo
acima quase não tem nada de Gestão de Projetos. Muita calma nessa
hora, conhecedores de RUP!!!! -> estou deliberadamente aqui deixando
de lado o workflow de gerência de projeto que o RUP prevê.
Só que, de repente, o Bill teve que fazer uma parceria com uma
empresa que achou a ideia do software interessante. Só que essa
empresa passou a se preocupar com os custos do projeto, o prazo de
entrega, a qualidade do produto a ser entregue etc... Então essa
empresa trouxe para a empresa de Bill toda uma parafernália de
processos, indicadores e melhores práticas de gestão de projetos,
de forma que:
· o escopo seja controlado – o Bill não poderá mais
fazer as mudanças que quiser a seu belprazer, nem achar que nunca
haverá mudanças. Todas as mudanças passam então a ser avaliadas
com relação à importância para o projeto, e impacto no custo e
prazo, se trará riscos ou não e, se aprovadas, o cronograma, o
orçamento do projeto terá que ser revisto.
· o custo e o prazo sejam monitorados e controlados:
mecanismos que permitem identificar eventuais desvios de custo, suas
causas e agir, proativamente, na solução desses problemas.
· os stakeholders (agora eles são vários, antes era só o
Bill) sejam constantemente e corretamente informados do andamento do
projetos, de seus problemas e das estimativas para seu término
(quanto, de fato, o projeto IRÁ custar ao seu final?), das mudança
de escopo, prazo e custo...
Estas ferramentas e práticas que a gestão de projetos traz é que
são propostas pelo PMBoK – é o eixo Gestão de Projetos.
È claro que os dois eixos, Processos (Metodologia) de
Desenvolvimento e o Gestão de Projetos se sobrepõe aqui e ali. Como
eu mesmo brinquei acima, o RUP prevê uma disciplina de gestão de
projetos, menos completo que o PMBoK, mas que pode perfeitamente ser
o modelo dependendo das circunstâncias. Não estou dizendo que as
metodologias de desenvolvimento não se preocupassem com prazo,
escopo etc... mas apenas entendo que a separação desses dois eixos
nos dá uma visão mais clara dos papéis e da organização de um
projeto.
Quanto ao SCRUM, nesta visão ele é uma opção ao RUP. O Scrum é
uma das metodologias ágeis, como o XP, que surgiu do chamado
Manifesto Ágil, que propõe, entre outras coisas, que se faça
somente o essencial em termos de documentação, e uma aproximação
mais do cliente ou usuário, daquele que dirá o que deve ser feito.
Um dos principais motivadores é o reconhecimento de que nos métodos
tradicionais gasta-se muito esforço na produção de documentos que
muitas vezes não transmitem direito os requisitos e depois nunca
são utilizados. E pior, ao não transmitirem os requisitos de forma
não ambígua e completa, corre-se o risco de entregar , no final,
algo que não era o que o usuário queria.
Ao contrário do que possa parecer, há bastante planejamento e
disciplina nos métodos ágeis. O Scrum pode e deve, assim como o
RUP, ser usado em conjunto com as práticas de gestão de projetos. O
número de sprints é definido no início, e no começo de cada sprint
tem-se um planejamento daquilo que caberá no sprint.
Por fim, se estivermos falando de uma implantação de um pacote
pronto (um ERP por exemplo), a gente pode ter uma outra metodologia,
no lugar da metodologia de desenvolvimento, com fases diferentes,
artefatos e papéis diferentes. Mas ainda assim haverá o eixo de
Gestão de Projetos.
E mais, as práticas do eixo de Gestão, propostas pelo PMBoK, podem
ser usadas de maneiras análogas num projeto de adoção de ITIL em
uma organização de TI.
Sobre o Prince2, não o conheço bem, mas imagino que seja um
“substituto” para as práticas do eixo de Gestão de Projetos que
o PMBoK propõe.
Abraços.
2009/8/12 Terra - Anderson M. Pereira
Scrum é um processo de gerenciamento de projetos ágeis, adaptado
para a área de desenvolvimento de SW.
Dentre as técnicas de utilização do Scrum, há a entrega de
produtos em períodos de tempo pré-estabelecidos, nunca inferiores a
uma semana ou superiores a trinta dias.
Para estimular o contato entre empresa e cliente, os projetos são
interrompidos em períodos regulares de tempo. A essas ações dá-se
o nome de Sprint. Ao término de cada Sprint, o cliente recebe um
conjunto de funcionalidades desenvolvidas e prontas para serem
utilizadas.
Importante a participação ativa do cliente no processo de
desenvolvimento.
att
Anderson Marcelino Pereira
Cel.: + 55 ( 11) 8317-5537
DE: [email protected] [mailto:[email protected]] EM NOME
DE Cleyton Santana de Sousa
ENVIADA EM: terça-feira, 11 de agosto de 2009 19:50
PARA: [email protected]
ASSUNTO: Re: [itsm_br] Implementação ERP
scrum é para desenvolvimento de software, certo?
Pelo que sei, são metodologias ágeis para gerencia de SW.
sds,
Cleyton Santana de Sousa
COBIT Certified
ITIL Foundation Certified
Microsoft Certified Professional
http://csantanaes.blogspot.com [2]
Gestão de TI e Gerenciamento de Projetos
"A mente que se abre a uma nova idéia jamais voltará ao seu
tamanho original"
(Albert Einstein)
2009/8/10 Relington
Gislaine,
Se a tua equipe for até 10 pessoas ou projetos curtos, concordo com
o Marcel. Gerenciar projetos em TI pode ser bom dar uma olhada no
Scrum.
abs,
Relington
----- Original Message -----
FROM: Marcel Fleming
TO: [email protected]
SENT: Friday, August 07, 2009 3:37 PM
SUBJECT: Re: [itsm_br] Implementação ERP
Anderson.
Na minha opinião, o PMBOK para quem tá começando e precisando
decidir como gerenciar, em um tempo rápido, não é a referência
ideal. Ele diz tudo que deve ser feito, mas não é muito prático em
mapear circunstâncias, tipos de projetos versus grau de formalismos
do processo.
Neste sentido, algumas leituras que eu recomendaria:
* Gestão de Projetos - Harold Kerzner
* Visualizing Project Management - Kevin Forsberg et alii
* The One Page Project Manager - Clark Campbell
Algum livro que fale sobre PMO pode ser útil, mas não me ocorre
nenhum agora.
Mas talvez alguns cursos possam ser mais efetivos e rápidos.
Algumas das entidades que dão curso preparatório também fornecem
cursos com uma visão mais prática de gestão.
Abraços.
Marcel.
2009/8/5 Terra - Anderson M. Pereira
Bom dia Gislaine
Parabéns e sucesso em seu novo desafio!
Você já leu o PMBOK?
Eu acredito que seria um ponto de partida legal para ter a visão
geral de Gerenciamento de Projetos com base nas melhores práticas e
daí então você dentro do seu projeto e do seu cenário ter visão
de quais templates serão importantes ou não para o Gerenciamento do
seu Projeto. Atual e os que virão pela frente.
Sucesso
Anderson Marcelino Pereira
DE: [email protected] [mailto:[email protected]] EM NOME
DE Gislaine Bueno
ENVIADA EM: segunda-feira, 3 de agosto de 2009 21:01
PARA: [email protected]; [email protected];
[email protected];
[email protected]; [email protected]
ASSUNTO: [itsm_br] Implementação ERP
Boa Noite, Amigos..
Estou iniciando um trabalho novo na Area de Projetos, antes
trabalhava com Infra-Estrutura e agora vou para a area de
desenvolvimento/sistemas e implementação de ERP´s.
Gostaria da ajuda de vcs para entender quais os docs de Projetos que
se aplicam para ambas as áreas.
PIP (plano de integração projeto)
PGM (plano mudança), PGR(plano risco), etc..
Um Abração!
Gislaine
-------------------------
Veja quais são os assuntos do momento no Yahoo! + Buscados: Top 10
[3] - Celebridades [4] - Música [5] - Esportes [6]
Nenhum vírus encontrado nessa mensagem recebida.
Verificado por AVG - www.avgbrasil.com.br [7]
Versão: 8.5.392 / Banco de dados de vírus: 270.13.44/2282 - Data
de Lançamento: 08/04/09 18:01:00
Nenhum vírus encontrado nessa mensagem recebida.
Verificado por AVG - www.avgbrasil.com.br [8]
Versão: 8.5.392 / Banco de dados de vírus: 270.13.50/2296 - Data
de Lançamento: 08/12/09 06:09:00
