quinta-feira, 14 de agosto de 2014

O papel do product owner

O papel do product owner

O PO representa o cliente na equipe de scrum, ele trabalha em conjunto com a equipe de Scrum para criar e controlar o Product Backlog. A respon sabilidade principal dele é maximizar o valor do produto e o trabalho da equipe de desenvolvimento.

O PO é responsável por gerenciar o product backlog, mantendo o product backlog em ordem para que o objetivo seja alcançado da melhor forma, garantir que o product backlog esteja visível, transparente e que mostre qual seram os próximos trabalhos da equipe.

O PO deve trabalhar em período integral na função e nunca deve executar a função de scrum master e PO ao mesmo tempo. Sua função  não é hierárquica, mas sim colaborativa, ele pode representar os desejos de um comitê de stakeholders.

A figura abaixo mostra a comparação de como as empresas que não trabalham com SCRUM e como as empresas que trabalham com SCRUM funcionam.

Figura 1 - Comparação entre gerenciamento de projetos tradicional e o SCRUM

É importante ver como a visão do cliente chega a equipe de desenvolvimento e como ela passa por várias etapas e documentos.

Quando a visão chega para a equipe de desenvolvimento ela já chega distorcida como a brincadeira de "telefone sem fio".

Se surgir uma dúvida no desenvolvimento, talvez ela nem chegue ao cliente, que é a pessoa mais indicada a respondê-la.

Na gestão tradicional de projetos, se gasta muito tempo na análise dos requisitos que podem mudar no decorrer do projeto. O PO no SCRUM tem como responsabilidade trazer os requisitos minimos para o produto e transformá-lo em histórias de usuários para então priorizá-las, quando uma história de usuário é levada para os desenvolvedores, aí sim a análise dos requisitos é mais profunda e feita em conjunto com a equipe.

O PO também é responsável por definir o que ele entende por trabalho feito, ele aceita ou nega o resultado da entrega da sprint..No final do desenvolvimento o produto é entregue com o que os desenvolvedores entenderam da documentação de requisitos.

O papel do gerente de projetos é dividido entre o PO e a equipe SCRUM.O Scrum Master faz controle das atividades executadas, remove os impedimentos, estimula o entendimento dos requisitos.

Referências:
Scrum Guide Aqui
Gestão de Produtos com Scrum Aqui

quinta-feira, 13 de fevereiro de 2014

Alinhamento de projetos

Esse post mostra como manter as áreas da empresa alinhadas criando uma rotina de reuniões bem organizada.

Uma das metas ágeis é a comunicação, eu junto com o coach ágil Abu organizamos a rotina das minhas reuniões para que o gerente de TI dê o status dos projetos que estão em execução para os outros gerentes e para a diretoria.

Antes as reuniões só eram feitas quando existia alguma emergência em um determinado projeto.

Agora, as reuniões são feitas no começo da semana, nós temos as priorizações da diretoria, que vem da sexta feira.

Nas reuniões de sexta feira, a diretoria passa as novas demandas e é feito o direcionamento dos projetos, nessa reunião são resolvidos conflitos de prioridade ou problemas.

Eu como product owner tenho contato diário com as equipes de TI e produtos, essas duas áreas estão sempre muito bem alinhadas.

O gerente de TI está sempre atualizado com o resultado dessas reuniões.

Seguindo o modelo abaixo, consigo o sincronismo das equipes, gerando visibilidade de quando inicia e termina as sprint's e isso permite a equipe de desenvolvimento se organizem para atender as demandas. Também permite projetos com mais de uma equipe terem um build real ao termino das sprints, por estarem alinhadas.



Veja na figura abaixo, minha rotina de reuniões semanais:



A figura abaixo é um modelo do processo das reuniões com a descrição do que se espera nessas reuniões.



Como PO tenho que manter a comunicação com os stakeholders, e este modelo permite manter o alinhamento entre todos, mantenho, junto com o gerente de TI, o portifólio sempre atualizado.


Fábio Sanches

sexta-feira, 7 de fevereiro de 2014

Kanban de TI

Nesse post vou falar sobre o kanban da equipe web de TI e como ele se adaptou do ano passado até hoje.

Quando começamos a implementar o kanban dividimos por etapas do processo nas colunas e por projeto nas linhas.

Este foi nosso primeiro kanban:


Logo no começo eu já criei o avatar de todos na equipe. Eu usei o site (www.faceyourmanga.com) é muito rápido e fácil de usar, em 5 minutos o avatar fica pronto.

O avatar serve para identificar quem está fazendo a tarefa.

Esse é o meu avatar:

Veja o exemplo de como ele é usado:



A cor do post-it diz qual sistema, o avatar mostra quem está fazendo e o número 3 circulado mostra quantos pontos essa tarefa recebeu no sprint planning. A relação entre pontos e tempo definida nesse sprint de exemplo foi de 1,3. Então, essa tarefa demora em torno de 4 horas para ser finalizada.

No daily meeting, a reunião é feita de pé em frente ao kanban, cada membro da equipe aponta sua tarefa (post-it).

Com o tempo o kanban começou a evoluir, sempre com sugestões da equipe e do Abu (coach ágil da empresa), essas sugestões eram colhidas na retrospectiva ou durante o dia a dia.


As sugestões que apareceram com o tempo, foram:

- Etiqueta no post-it para mostrar que tipo de tarefa era aquela (ex: nova feature, bug, melhoria, etc..).

- Figura para mostrar qual era o projeto, pela figura você identificava qual era o projeto, da para ver isso no canto esquerdo da imagem.

- Burndown chart, veja na imagem do lado direito.

- Roadmap dos projetos, veja na parte inferior da imagem, as três folhas de sulfite. O roadmap tem o nome de todos os próximos projetos da área, divididos por mês. Isso deixa a equipe atualizada e assim ela sabe qual o rumo que a área está tomando.

- Histórias de usuário no backlog

- Separar as tarefas por histórias.

Com uma simples olhada no kanban você consegue identificar quem está fazendo, qual a tarefa, quanto tempo vai demorar, que estado ela esta, quais os próximos projetos, se a meta da sprint será alcançada, qual histórias está sendo feita.

O kanban é uma ferramenta muito útil e tem que sempre estar em evolução.

Fábio Sanches

Agradecimento ao Abu (http://blogdoabu.blogspot.com.br/) e toda a equipe de web.

quinta-feira, 6 de fevereiro de 2014

Entidade de transição corporativa

Agora no começo do ano 2014, eu e o Abu fizemos o planejamento por trimestre das atividades do quadro no formato kanban, que é a nossa entidade de transição corporativa (E.T.C.).

Nesse quadro temos tarefas como, marcar uma reunião, criar novos quadros de kanban, falar com pessoas estratégicas sobre Scrum, testar softwares de gerenciamento, dar um treinamento específico.

Esse é um framework ágil de transição corporativa, fornecido pelo Abu.



Nós pegamos esse template, abaixo, do Roman Pichler para definir uma meta por trimestre, total de 4 trimestres para cada meta quais as features e os KPIs de medição de resultado, para saber se o que desejamos foi alcançado.



Na imagem abaixo, podemos ver o quadro que nós montamos, ele é dividido nas colunas pela fase do processo e nas linhas pelos departamentos da empresa. No backlog, já colocamos todas as atividades que conseguimos lembrar. O quadro kanban, dá a visibilidade do que esta sendo feito por departamento e aos poucos buscamos fazer a mudança de cultura e junto com isso a implantação do ágil, tornando uma empresa que faz entregas de forma mais rápida.

Quadro E.T.C.

Lógico, não podemos parar a empresa e "virar a chave" falando: A partir de hoje vai funcionar assim, tentando aplicar várias metodologias e processos. Isso não funciona !

Nós começamos aos poucos a mudança de cultura sempre vinculada as entregas, mantendo o foco nas entregas para não perder os prazos da empresa. O segredo da mudança é ter calma e paciência, nem sempre as pessoas estão animadas para fazer um daily meeting, para isso é importante ter um Scrum Master motivado e de bom humor.

No ano passado nós começamos a implantar o Scrum na área de TI, isso levou 3 meses. Começamos com o kanban, hoje temos todas as cerimonias e a metodologia roda quase que sozinha, todos tem noção do seu papel na equipe.

Já aplicamos kanban na área de marketing e design, PMO, hoje algumas áreas já entendem as pequenas entregas e a melhora continua.

Tivemos um trabalho com a alta direção da empresa, com os gerentes e com os outros departamentos, mostramos todos os benefícios da metodologia ágil. Foi muito positivo, mas o trabalho precisa ser contínuo, sempre precisamos lembrar os benefícios a todos. O Abu, sempre me ajuda com as conversas e com isso formo mais argumentos para convencer as pessoas.

Fábio Sanches

Referência:
http://www.livrariacultura.com.br/scripts/resenha/resenha.asp?nitem=5100834

terça-feira, 4 de fevereiro de 2014

Road Map no Team Foundation Service

Eu montei um roadmap, junto com o Abu, fiz uma pesquisa de todos os projetos que estavam rodando aqui na empresa.
Fui em todas as áreas que tem algum projeto, marketing, comercial e produtos.

Primeiro eu tentei montar o roadmap pelos temas de investimentos que o comercial tem definido, mas quando fui mostrar para o PMO ele visualizou outras áreas e juntos montamos os temos de investimentos.

Eu consigo ter uma visão macro de como está o andamento dos projetos por áreas de investimentos.






Os temas ficaram de uma forma macro e separados pelo status:



Eu consigo prever qual o tempo que os projetos rodam na "esteira", já sei que em média o tempo é de 60 dias:




Nós separamos os temas de investimentos da seguinte forma:


Eventos: São todos os eventos que a empresa está presente e que é necessário uma mobilização de mais áreas além do pessoal de instalação

Entregáveis: São todos os projetos de clientes que pedem alguma customização, são projetos recorrentes sempre existe algum trabalho ou adição de novas features. A maioria do nosso trabalho está nesse tema de investimento.

Parceiros: São projetos de parceiros onde temos um compartilhamento de usuários ou o cliente faz alguma ação para aumentar nossos usuários.

Corporativo: São projetos estratégicos internos da empresa.

Matriz: São projetos solicitados pela matriz.

TI Interno: São projetos da TI que precisam ser priorizados em paralelo com os da empresa.

Inovação: São projetos de inovação, projetos que surgem de ideias e que precisam ser definidos e aprovados pela empresa.

Consigo descer até o nível de backlog do produto, onde eu divido em user stories, e tarefas dentro do projeto.
Consigo ver quanto tempo demora para acabar todo o trabalho por sprint e por história.


Tenho uma visão do burndown do projeto.


É importante ter essa visão no software, mas mais importante ainda é ter essa visão onde todos possam opinar e visualizar, para que toda a empresa saiba a direção que está seguindo. Para isso, fizemos um quadro do road map ao lado do gerente de TI, onde temos a visão de tudo em forma de post-it, tudo que está na parede é replicado ao TFS, o SW me dá as métricas e o quadro ajuda a saber o que é prioridade em conjunto com o gerente de TI.



Agradecimentos ao Abu, que é o coach Ágil da empresa e que me ajudou a escolher o TFS e a montar o roadmap. Agradecimento ao Fabio (PMO) da empresa pela definição das áreas de investimentos.

segunda-feira, 3 de fevereiro de 2014

Kanban para a equipe comercial, customizando

Hoje fizemos uma reunião para customizar um kanban para a equipe comercial.
Onde trabalho existe uma estrutura antiga de duas equipes, os hunters e os farmers.
Hunters são os profissionais que buscam novos clientes e os farmers são os que cuidam dos clientes já "conquistados".
Na reunião juntamos os dois gerentes das equipes, sendo cada um com uma necessidade no kanban.
A proposta inicial de kanban era essa da imagem abaixo:


Backlog de prospects: Aqui colocamos os clientes, que os gerentes colocam como meta, ordenados de cima para baixo de acordo com a prioridade.

Qualificando: Nessa etapa do processo, um vendedor selecionou um cliente do backlog e esta qualificando qual será sua categoria, como esse cliente será abordado e quais os itens serão vendidos.

Agendando: Nessa etapa, o vendedor agenda uma visita para apresentar a empresa e o produto a ser vendido.

Visita: Nessa etapa,  o vendedor faz uma visita comercial, antes de uma visita técnica.

Proposta: Nessa etapa,  o vendedor cria uma proposta, junto com as outras áreas da empresa.

Negociação: Nessa etapa, o vendedor negocia preço com o cliente.

ContratadoNessa etapa, o vendedor finaliza a venda.

Indicadores: Os indicadores mostram, quantos clientes estão em cada etapa do processo.

Road map: O road map serve para o gerente, ter uma noção de quanto está planejado para o ano e se a equipe está atingindo a meta. Podemos quantificar por mês ou por semanas.

A ideia do kanban é ajudar na reunião diária (daily meeting) de 15 minutos, cada vendedor muda o status do kanban na frente de todos, assim todos tem uma visão geral do que esta acontecendo na área de forma visual e simples.

Durante o brainstorm da reunião vimos que esse modelo se encaixaria muito bem para os farmers e com isso começamos a fazer a customização.

Enquanto o gerente falava fui criando os post-its e colocando entre as fases no kanban, apenas para ilustrar como ficaria o kanban.

As outras fases importantes para o gerente de farmer eram: faturamento, relacionamento, clientes com problemas, inovação, processo de implantação e renovação de contrato.





As fases de contratado, negociação e proposta não faziam sentido para os farmers, elas foram retiradas.
Coloquei também um exemplo de como seriam os indicadores. Ao final da reunião já tínhamos um esboço, onde simulei em uma planilha e no final o kanban ficou assim.



Implantação: Depois que o cliente fecha o contrato ele entra na fase de implantação.

Relacionamento: O farmer tem sempre que fazer uma pesquisa com o cliente para saber se ele está satisfeito, se tem problemas, etc.

Inovação: Clientes antigos que precisam de novidades no produto vendido.

Problemas: Clientes com problemas, a ideia é colocar um post-it com outra cor para chamar a atenção.

Faturamento: Levantamento de faturamento com o cliente.

Para a equipe de hunter nós não conseguimos fechar um modelo de kanban, mas conforme o kanban farmer for sendo usado, vamos encontrar uma forma de adaptar e criar o kanban hunter.

Agradecimentos aos colegas que participaram, Abu,  Miguel por ter cedido o template incial, Vivian, entre outros colegas de trabalho.

Fábio Sanches