Conforme o planejado, hoje foi o dia em que sentamos com cada uma das equipes (definimos que teremos CINCO projetos) e definimos quais seriam as user stories que eles teriam que cumprir até o fim.
Usei bastante o conceito do livro "User stories" do Mike Cohn, onde ele geralmente descreve uma user story com "Um usuário [pode/deve] [fazer algo de alto nível]".
Ou seja, por exemplo:
* Um usuário pode clicar em diversos pontos do simulador e o sistema irá apresentar as curvas paralelas resultantes (user story de um dos projetos)
* Um usuário pode passar diversos objetos na antena e o sistema apresentará os resultados
Como somos um grupo de pesquisa e a maioria dos projetos envolve hardware ou software de baixo nível, precisamos adequar as User Stories à nossa realidade. A maioria dos livros tratam as user stories como software de mais alto nível ("Um usuário pode buscar pelo nome de um livro" ou "Um usuário pode excluir seus dados pessoais"). Então temos que tentar buscar uma forma de manter o conceito mas adaptando ao máximo para nossa realidade.
Tivemos dificuldades em abstrair isso, mas é assim que a gente aprende: na prática!
Só não conseguimos fechar as user stories de dois projetos. Um pelos membros não terem aparecido e o outro pelo assunto ser muito técnico e nebuloso. Iremos tentar achar alguma parte que possamos apresentar.
Como eu disse, a idéia é fazê-los vencer essa etapa e não sofrer uma nova derrota.
========================================================
No fim do dia, eu e o outro gerente também discutimos a respeito da nova ordem de comunicação que implanteremos. Atualmente vivemos algo como três níveis de hierarquia:
COORDENADORES
GERENTES
EQUIPES
A comunicação correta seria de que os gerentes fossem um filtro. No máximo, na minha opinião, as equipes pudessem consultar os coordenadores. Porém, é comum os coordenadores comunicarem diretamente com as equipes, deixando os gerentes de mãos atadas.
Hoje ocorreu um caso típico: soubemos que um dos recursos de um projeto seria desligado do laboratório e passaria para a empresa parceira. Fomos os últimos a saber, lógico. E contávamos com ele para o nosso planejamento.
Com o SCRUM, a nossa idéia é criar mais um nível hierárquico, algo assim:
CLIENTES / COORDENADORES (stakeholders ou "chickens")
PRODUCT OWNERS
SCRUM MASTERS
EQUIPE
A primeira coisa que você deve estar pensando, aposto, é: "Pô, eles tão tornando tudo mais burocrático aumentando a hierarquia". Eu digo que não, e vou explicar o porque.
Primeiro, pois na nossa visão estaremos deixando os coordenadores apenas como "chickens", ou seja, apenas como envolvidos no projeto e não mais comprometendo eles. Nossos coordenadores já estão com demandas e tarefas até o pescoço! São professores universitários, então eles tem que orientar doutorado, mestrado, dar aulas, corrigir TCC, auxiliar os projetos, etc. Muita coisa!
Segundo, pois isolando os coordenadores, estaremos obrigatoriamente dando os poderes de decisão aos product owners. A minha idéia é que eu e o outro gerente nos transformemos nestes product owners. Porém, lógico, para que isso aconteça, precisamos encontrar scrum masters adequados. E isso vai demandar tempo.
Terceiro, pois criando mais uma hierarquia, deixamos muito mais difícil a comunicação direta entre os coordenadores e as equipes, o caso mais problemático. Em contrapartida, se isso ocorrer, serão DOIS níveis que estarão sem essa "informação".
Ainda assim, acredito que valerá a pena. Os coordenadores trabalharão como clientes ou com os clientes. E caberá aos P.O.'s fazerem essa interface com as equipes e manter os clientes/coordenadores informados do andamento das coisas.
Enfim, iremos apresentar essa proposta de mudança e eu tentarei expôr exatamente o que estou dizendo aqui. Precisaremos do comprometimento deles em acatar isso e não cobrarem as equipes diretamente, ou pior, dar demandas diretamente. Os recursos estão ficando escassos, se eles nos jogarem mais este problema no colo, a situação ficará difícil!
==================================================================
Também ao final da reunião expressei ao outro gerente qual é o meu plano para longo prazo, para o laboratório: torná-lo uma referência dentro da universidade. Como iremos fazer isso?
Bom, um passo de cada vez. Primeiro vamos nos tornar produtivos. Depois vamos buscar começar a aparecer de alguma forma. Os frutos começarão daí.
==============================================================
Terça-feira de manhã iremos adequar todo o laboratório com as taskboards prontas para receberem as user stories e atividades. Terei que comprar todo material de escritório necessário. Vou bancar do bolso, nesse primeiro momento. Depois eu peço um reembolso ;)
Um ótimo final de semana a vocês.
Abraços
PARTE VII
sábado, 19 de abril de 2008
Implantação do SCRUM no laboratório - Parte VI
Marcadores:
conflitos,
Dia-a-dia,
implantação,
lições aprendidas,
mudanças,
reuniões,
SCRUM,
sugestões
Assinar:
Postar comentários (Atom)
Nenhum comentário:
Postar um comentário