Gerenciamento de Níveis com Scrum e RUP parte 1
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, este dashboard é 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 por que ele serve a equipe.
Já trabalhei em empresas em que o dashboard ficava na sala da direção e não da equipe e isso é um erro, por que 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 facto 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 um deficiência de planejamento a médio/longo prazo. Um framework que possibilita planejamento de médio/longo prazo é o RUP, porem o mesmo 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 de facto a ser mais veloz integrando valor ao negocio 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, porem sempre temos que balancear o que documentar e como documentar, por que 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
Gestão por objetivos
A maneira mais efetiva de gerir um projeto é aplicar a gestão em níveis. Está gestão em níveis vai levar tudo de forma nivelada, isto significa tanto riscos, priorizarão, estimativas, objetivos e planos. O problema da abordagem tradicional da WBS é que de inicio é impossível prever tudo que irá acontecer no projeto, muitas vezes isto leva a gestão a ficar pilotando o project tentando achar dadas que são inatingíveis.
Definindo Objetivos...
O primeiro passo é definir objetivos, estes objetivos podem ser definidos através de BSC com um simples diagrama de atividades ou um mero esqueça gráfico que mostre o seu balanceamento, o legal aqui é fazer o cascateamento do planejamento estratégico da empresa, cacateado para a TI e depois cascateado 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 estaria esclarecidas. Isso é a prática de visão do RUP e começa entrar na prática de visão compartilhada do OpenUp.
Os níveis...
Visão do Níveis
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, este dashboard é 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 por que ele serve a equipe.
Já trabalhei em empresas em que o dashboard ficava na sala da direção e não da equipe e isso é um erro, por que 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 facto 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 um deficiência de planejamento a médio/longo prazo. Um framework que possibilita planejamento de médio/longo prazo é o RUP, porem o mesmo 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 de facto a ser mais veloz integrando valor ao negocio 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, porem sempre temos que balancear o que documentar e como documentar, por que 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á envolvido. Voltando as 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. Está gestão em níveis vai levar tudo de forma nivelada, isto significa tanto riscos, priorizarão, estimativas, objetivos e planos. O problema da abordagem tradicional da WBS é que de inicio é impossível prever tudo que irá acontecer no projeto, muitas vezes isto leva a gestão a ficar pilotando o project tentando achar dadas que são inatingíveis.
Definindo Objetivos...
O primeiro passo é definir objetivos, estes objetivos podem ser definidos através de BSC com um simples diagrama de atividades ou um mero esqueça gráfico que mostre o seu balanceamento, o legal aqui é fazer o cascateamento do planejamento estratégico da empresa, cacateado para a TI e depois cascateado 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 estaria esclarecidas. Isso é a prática de visão do RUP e começ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:
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 e 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 gerencia 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 disperdicios 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 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 sera 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.
- Gestão
- Planejamento
- Mitigação de Riscos
- Priorização
- Critério de Aceite
- Execução
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 e 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 gerencia 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 disperdicios 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 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 sera 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.
