ITIL vs Scrum ou ITIL + Scrum?
Thiago Isaac
possível (e viável) integrar elementos da mais fllexível das
filosofias de gerenciamento de projetos (que por natureza é uma área
de conhecimento transitória - projetos tem inicio meio e fim) à
realidade do gerenciamento da TI, onde o objetivo é a estabilidade e a
mudança é muitas vezes encarada como "o inimigo"?
Adriano Bizerril
comparação é feita. (escopo).
Alguns fatores seriam relevantes na hora de se discutir esse tópico:
Maturidade da organização.
Nicho de trabalho ou área de atuação.
Stakeholders.
Se a TIC é fim ou meio.
Velocidade exigida entre a entrada e a saida do sistema produtivo.
E assim por diante.
Mas minha experiencia mostra que as metodologias, filosofias,
frameworks que estão no mercado, são otimos isoladamente em seus
ambientes de demonstração, academicos ou de treinamentos, mas na
prática tudo deve ser adaptado para a realidade em que se deseja
trabalhar.
Exemplo: Scrum puro não me ajuda, mas o conceito de burndown e de
quadro Kanbam me dariam um ganho significativo em minha realidade.
Então porque não os adaptar a minha realidade, se vai me ajudar e
ajudar a organizacao!!!
Adriano Bizerril
Thiago Isaac
A título de discussão vamos supor o seguinte cenário: O departamento
de TI de uma grande empresa (mais de 500 estações de trabalho) com uma
metodologia baseada no ITIL com uma boa maturidade (a maioria dos
processos da TI estão próximas ao nível 3 de maturidade do padrão
CobiT - Processos definidos, documentados e seguidos na grande maioria
dos casos)
O desafio: O negócio da empresa demanda mudanças constantes, tanto nas
aplicações eer, m produção quanto na própria infraestrutura.
A pergunta: Como, com que ferramentas podemos aproveitar a agilidade
que as metodologias ágeis trazem às mudanças sem perder completamente
o controle?
2010/2/24 Adriano Bizerril <adri...@gmail.com>:
> --
> Você está recebendo esta mensagem porque se inscreveu no grupo "SCRUM PARAÍBA - user group Oficial na ScrumAlliance" dos Grupos do Google.
> Para postar neste grupo, envie um e-mail para scr...@googlegroups.com.
> Para cancelar a inscrição nesse grupo, envie um e-mail para scrumpb+u...@googlegroups.com.
> Para obter mais opções, visite esse grupo em http://groups.google.com/group/scrumpb?hl=pt-BR.
>
>
Adriano Bizerril
Nesse cenário e em qualquer outro cenário a junção dos dois (SCRUM +
ITIL) seja o ideal a ser feito.
O ITIL vai te dizer "O que fazer", "com o que deve ser feito" e "por
quem" (Processo, Função e Papel). Já o Scrum te guiaria no COMO FAZER.
Os processos definiriam o Backlog do Produto
Os papeis do ITIL teriam que ser mapeados para o papeis do SCRUM
( Cliente, PO, SC e EQUIPE)
A execução das tarefas seguiriam o padrão definido pelas funções ITIL.
Talvez o mais dificil e fascinante nessa abordagem seja o tratamento
do Gerenciamento de Mudanças dentro do Scrum para essa situação. Como
você colocou no seu case, o negócio da empresa demanda mudanças
constantes, sendo assim haveria uma relação direta entre a velocidade
das mudanças e o tamnha da sua SPRINT. Você teria que definir um
tamanho de Sprint confortável para acomodar a velocidade de mudanças
que sua empresa demanda.
Vamos para uma caso extremo... sua sprint pode ser de 1 dia. Onde voce
poderia dividir 30 min para SP1, gerando o backlog da sprint, 30mim
para SP2 para definir como irão realizar as atividades da sprint, de 6
a 6,5 horas de execução, 30 min para Sprint Review e Retrospectiva.
Isso acontece, tem empresas que tem Sprints de 1 dia.
Claro que para que essa dinâmica funcione existem aspectos que estao
ligados a maturidade da empresa:
- Captação das necessidades/demandas da empresa gerando os requisitos
para o backlog dos produto.
- Capacidade, Maturidade e Compromentimento de sua equipe.
- Mecanismo de comunicação super, hiper eficientes entre as partes
( Cliente, PO, SC e Equipe)
- Etc.
Adriano Bizerril
On 24 fev, 15:24, Thiago Isaac <thiagoik...@gmail.com> wrote:
> Adriano
>
> A título de discussão vamos supor o seguinte cenário: O departamento
> de TI de uma grande empresa (mais de 500 estações de trabalho) com uma
> metodologia baseada no ITIL com uma boa maturidade (a maioria dos
> processos da TI estão próximas ao nível 3 de maturidade do padrão
> CobiT - Processos definidos, documentados e seguidos na grande maioria
> dos casos)
>
> O desafio: O negócio da empresa demanda mudanças constantes, tanto nas
> aplicações eer, m produção quanto na própria infraestrutura.
>
> A pergunta: Como, com que ferramentas podemos aproveitar a agilidade
> que as metodologias ágeis trazem às mudanças sem perder completamente
> o controle?
>
> 2010/2/24 Adriano Bizerril <adrian...@gmail.com>:> Thiago, acredito que isso vai depender do contexto a que essa
Thiago Isaac
Acredito que o principal desafio não seria nem tanto o tamanho do
sprint, mas também a relação Gerenciamento de mudanças - Gerenciamento
de liberação.
Após a RFC (solicitação de mudança) ser aprovada pelo CAB (comite de
gerenciamento de mudanças), ela segue para o gerenciamento de
liberação que deve elaborar um plano de ação e reapresentá-lo ao CAB
para aprovação. Após a implantação da mudança o Gerenciamento de
liberação a reapresenta ao CAB que encaminha as informações sobre a
mudança ao gerenciamento de configuração
Na minha visão o scrum estaria totalmente aninhado dentro do
Gerenciamento de Liberação. Mas como conciliar a ida-e-vinda do
projeto (aprovação da RFC, elaboração do plano de ação, aprovação do
plano de ação, implantação, retorno ao CAB para avaliação) com a
agilidade do scrum?
Penso que a melhor alternativa para isso seria acumular ao Scrum
Master a responsabilidade de documentar o Planejamento do Sprint em um
artefato (comparável ao Termo de Abertua ou à Declaração preliminar do
escopo) e antes de iniciar o Sprint propriamente dito aprovar este
artefato junto ao CAB. O mesmo seria válido também para o Sprint
review.
No entanto temo que essa abordagem possa tirar muito da agilidade da
equipe. Caso o plano não seja aprovado, a equipe já terá iniciado o
trabalho. Seria possível inserir um "gap" entre o planejamento do
Sprint e seu inicio propriamente dito?
O que vocês acham?
2010/2/25 Adriano Bizerril <adri...@gmail.com>: