Gerenciamento de níveis com Scrum e RUP – parte 01

Scrum é um excelente framework para a condução do micro-ambiente.
Suas práticas ágeis são fantásticas para aumentar a colaboração e
levantar problemas e resolver impedimentos da equipe. Scrum ajuda muito
no dia-a-dia da equipe de desenvolvimento de software. Através das
reuniões diárias conseguimos tanto antecipar e corrigir problemas, como
ter o posicionamento do que a equipe está fazendo.

A visão
compartilhada de uma equipe é essencial. Se você tem pessoas
trabalhando para sua empresa em uma sala, não necessariamente você tem
uma equipe. Para ter uma equipe você precisa de indivíduos que
compartilhem o mesmo goal. Assim como em equipes esportivas, não existe
possibilidade de um ganhar e os outros perderem, ou todos ganham ou
todos perdem.

O Scrum possibilita que a equipe evolua e cresça
como equipe através de retrospectivas e momentos de planejamento de
prestação de contas sobre o que foi desenvolvido.

Dashboard

O
Dashboard é um elemento fundamental na adoção de práticas do Scrum, ele é um painel de controle para equipe. Você até pode tirar
informações daqui e colocar em outros documentos ou até mesmos em
soluções de CMS, mas não deve retirar o dashboard porque ele serve à
equipe.

Já trabalhei em empresas em
que o dashboard ficava na sala da direção e não da equipe. Isso é um
erro, pois a equipe precisa mais do dashboard do que a gestão. Isso
poderia ser compartilhado através de uma foto.

O Scrum é bom, mas é a solução para tudo?

De
fato, não é. No Scrum existe a deficiência da gestão tradicional de PMI
onde se aborda riscos, recursos, tempo, calendário. Além de ter uma deficiência de planejamento a médio/longo prazo. Um framework que
possibilita planejamento de médio/longo prazo é o RUP, porém ele
peca na colaboração e nas práticas do dia-a-dia. Nesse sentido de
práticas do dia-a-dia métodos ágeis como Scrum e XP funcionam muito
melhor e ajudam a equipe a ser, de fato, mais veloz, integrando valor ao
negócio com mais freqüência. O uso de RUP não elimina de forma alguma o
uso de Scrum e XP.

A colaboração é importante

Todos
querem atingir o sucesso, todo mundo quer ter um processo documentado. Eu não vejo problemas nisso. Porém, sempre temos que balancear o que
documentar e como documentar, porque se estamos falando de gestão de
conhecimento, é importante, sim, registrar o conhecimento. Neste sentido
uma solução colaborativa como o XWiki ou um CMS pode ser o caminho
ideal para disseminar o conhecimento e obter o engajamento da equipe.

Cartoon clássico de Scrum

Neste
cartoon existe a visão clara da colaboração, aqui temos um exemplo de
envolvimento e comprometimento. O porco está comprometido, mas a galinha
só está envolvida. Voltando às pessoas, colocar pessoas em uma sala e
dar responsabilidades a elas não faz com que elas se comprometam e logo
desta forma você não tem um time, e isso além de um risco é um problema.

Gestão por objetivos

A
maneira mais efetiva de gerir um projeto é aplicar a gestão em níveis.
Esta gestão em níveis vai levar tudo de forma nivelada, e isto significa
riscos, priorização, estimativas, objetivos e planos. O problema
da abordagem tradicional da WBS é que, de início, é impossível prever
tudo que irá acontecer no projeto. Muitas vezes isto leva a gestão a
ficar pilotando o projeto, tentando achar datas que são inatingíveis.

Definindo Objetivos

O
primeiro passo é definir objetivos. Eles podem ser definidos
através de BSC com um simples diagrama de atividades ou um mero esquema
gráfico que mostre o seu balanceamento. O legal aqui é fazer o
cascateamento do planejamento estratégico da empresa, cascateado para a
TI e depois para seu projeto.

Se você não tem
planejamento estratégico ou não quer trabalhar com BSC, pode trabalhar
com objetivos no nível de projetos, que seriam como metas. Então você
tem que estabelecer a visão do projeto, onde essas metas maiores estariam
esclarecidas. Isso é a prática de visão do RUP e começa a entrar na
prática de visão compartilhada do OpenUp.

Os níveis

Visão do Níveis

Este
modelo é proposto pelo Kurt Bittener e o Ian Space, que são os
principais consultores do Ivar Jacobson. Ela não chega a especificar a
junção com método ágeis, isto é uma coisa que eu e meu amigo Nilseu Padilha fizemos. Em linhas gerais tudo é nivelado, isso significa:

• Gestão
• Planejamento
• Mitigação de Riscos
• Priorização
• Critério de Aceite
• Execução

Com isso, nos níveis mais acima as coisas são mais abstratas e menos
precisas e, por conta disso, focam um horizonte bem maior. Aqui
encaixamos as coisas de longo prazo. Neste ponto podemos encaixar
metodologia para gerência de programas, como o prince2. Isso é bem útil
se o seu projeto não é só desenvolvimento de software e tem marketing e
outros projetos que devem ser gerenciados de forma dependente.

No plano geral, entra a gestão tradicional do PMI onde fica a alocação dos
recursos financeiros e de pessoas. Aqui podemos aplicar estimativas por
esforço em horas ou dias com a técnica de wideband delphi.

Na
evolução acontece o planejamento de médio prazo. É neste ponto que entra
o RUP. Aqui utilizamos os patterns de evoluções do RUP. Um erro comum
de quem usa RUP é usar o mesmo pattern o projeto todo, ou seja, o pattern
clássico de concepção, elaboração, construção e transição.

Nas
Sprints para baixo que entram as metodologias ágeis onde são muito
efetivas e ajudam a linkar o micro-ambiente com o macro-ambiente. Aqui
podo ser utilizado o Scrum e algumas práticas do XP também são muito
bem vindas, como o papel do Tracker e como os Big Visible Charts que o
Ron Jefries fala tanto.

Com este modelo

Podemos
ter a tão sonhada gerência por exceção, logo o gerente de projeto pode
delegar responsabilidades a uma gerencia de evolução/sprint que pode
ser efetuada pelo papel do ScrumMaster.

E a equipe ganha em
produtividade e foco, pois como existem planos ela sabe os objetivos
que vão ser atacados a curto/médio prazo, isso evita diversos
desperdícios e evita desgastes entre a equipe e a gestão. É comum
existirem problemas de comunicação e alinhamento da gestão tradicional
com a execução tática. Este método como um todo ajuda a diminuir estes
ruídos e a colocar o foco na execução e não nos cargos das pessoas.

Planejando a evolução

No
planejamento da evolução vai existir o planejamento parecido como o do
Scrum só que em um nível de granularidade bem mais alta. É neste momento
que será criado o roadmap com a descrição textual do que será feito,
mas em um nível de detalhamento mais alto do que o de atividades e
tarefas, este tipo de detalhamento acontece nas sprints através do
Scrum.

No planejamento da evolução também acontece a alocação
dos riscos que serão mitigados nesta evolução. Após isto feito, são
realizadas as estimativas a partir do resultado das estimativas que
sabemos o esforço da evolução o gerente pode querer cortar coisas do
escopo ou adicionar mais recursos qualificados para execução desta
evolução.

Feito isso acontece a quebra em sprints, logo se sabe
quantas sprints vão ter e quando vai acabar a evolução. A evolução e as
sprints são sagradas, ou seja, não se mexe no timebox, aconteça o que
acontecer elas iniciam e começam na mesma data. O que ocorre é que você
adianta ou atrasa coisas, mas a data não mexe.

Ainda existe muito a falar sobre este método, mas isso fica para outros posts.

Até a próxima, pessoal!