Certificado da Scrum Alliance

Semana passada recebi meu login da Scrum Alliance... muita emoção quando eu vi aquele e-mail na minha caixa postal :)

Agora mais do que nunca é fazer valer este certificado!!!

Time Box e Sprint Planning

Hoje passei por uma experiência que provou muita coisa a respeito de Time Box na hora de executar o Sprint Planning.

O que aconteceu foi o seguinte: Precisávamos especificar algumas ferramentas para nosso projeto, cada uma destas ferramentas seriam um Product Backlog e então entramos na reunião com o Product Owner, que veio com alguns 'cartões de estória' para cada um destes, e dai retiraríamos então nossos Sprint Backlogs. Já partindo do pressuposto que nossa Sprint teria o Time Box de duas semanas, começamos a ver o primeiro Product Backlog, já priorizado pelo PO.

Começamos a ler cada um dos 'cartões de estória' e tirar nossas dúvidas com o PO, em seguida resolvemos levantar os pontos, que por sugestão do gestor acabou sendo visto em dias, logo vimos que o primeiro item já seria o suficiente para ocupar a nossa Sprint, com uma certa possibilidade (baixa) de sobrar tempo e podermos então pegarmos um novo item. Apesar de avisado sobre isso o gestor resolveu que deveríamos ver todos os outros itens de backlog que o PO já havia feito os 'cartões de estória', mesmo após a argumentação que este conhecimento muito provavelmente seria perdido durante o tempo decorrido, nosso gerente argumentou que deveríamos ver, pois haviam itens que se repetiam nos itens de backlog e isso poderia nos ajudar a ter a visão de criar "dispositivos reutilizáveis".

Bom, mesmo descordando (eu) seguimos (toda equipe) em frente. Gastamos 2,5H pela manhã e 1,5H na parte da tarde. Isso basicamente conversando com o PO e discutindo algumas coisas técnicas com a equipe. Depois disso tudo claro que devíamos ainda analisar os itens vistos e separar em tarefas pequenas que não tivesse mais de 2 dias de trabalho, nesta parte estávamos só nós sem o PO e o gerente. Vimos tudo que foi levantado distribuímos os pontos nas tarefas e então obtivemos a visão de tudo que teríamos que fazer nos próximos dias, como de costume... muuuuito trabalho! :)

Vamos apontar o que esteve errado nisso tudo:

1º - O time box foi totalmente desrespeitado. Partindo do princípio que no Sprint Planning devemos levantar os itens que serão 'atacados' durante a sprint e logo definirmos seus pontos de esforço. Ou seja, deveríamos usar as 4Hs para fazer tudo isso e não perder quase o dia todo em reunião.

2º - Ao vermos tantos Products Backlogs no mesmo dia, quando fomos levantar as tarefas, toda a equipe estava confusa com alguns requisitos de um item para outro. Claro que excesso de informação pode ser prejudicial ehehe

3º - Se um novo integrante entrar na equipe ele vai ter que tirar todas as suas dúvidas com os membros da equipe e com o PO, é claro, mas deixou de ter todo aquele Brain Storn do Sprint Planning. Ou seja acabou lembrando Waterfall!

4º - Reuniões demoradas e sem pausa causam um certa fadiga onde gera falta de atenção e comprometimento dos envolvidos. Desta forma deveríamos ter tido uma leve pausa no período da manhã.

O que eu vejo que deveria ter sido feito:

1º - Para atender o gerente o Scrum Master devería ter analisado o documentos juntamente com o gerente e o PO (se possível), afim de ter a visibilidade dos itens a seguir conforme o solicitado. Isto é possível porque o Scrum Master (eu) possui um perfil técnico que faz parte da equipe como arquiteto/desenvolvedor e ainda conhece do negócio (praticamente um severino). Desta forma o Scrum Master poderia passar para a equipe um visão do que ocorreria nos próximos passos que poderia ser reaproveitado.

2º - Deveria ter sido respeitado o Scrum e feito da maneira correta: 4Hs para toda a Sprint Planning, pois o Time Box é algo que o Scrum bate muito forte para que seja seguido a risca.

3º - Tentar tirar dúvidas técnicas entre a equipe junto com o PO pode ser bem desastroso e tomar o tempo precioso dele. Acho que o PO deve participar de forma bem ativa, mas só até o time ter todo o entendimento do negócio, depois o PO pode ser dispensado e a equipe parte para a divisão das tarefas e devida pontuação, claro que em determinados momentos pode haver dúvidas que devem ser tiradas com o PO.

Por fim, nós acabamos tendo todo este trabalho, creio eu, pelo fato do PO tirar férias daqui a uns 50 dias e por isso o gerente quis adiantar as coisas, mas acabou dando um pouco errado. Penso que o Scrum foi elaborado para ser seguido e algumas de suas partes adaptadas, mas não tudo.

Ainda precisamos arrumar uma solução para esta falta no PO em determinada parte do projeto, pois desta forma perdemos um dos pontos fortes do Scrum que é ter o PO o mais junto da equipe o possível.

Abraços!

Curso CSM com Alexandre Magno (final)

Com toda a empolgação do mundo fui para última parte do curso. Tive que correr um pouco na hora do almoço para poder almoçar, tomar um banho e fazer o checkout do hotel, que me permitiu ficar aqui na recepção até a hora de eu partir de Porto Alegre.

Antes de mais nada, CSM significa Certified Scrum Master e não Curso de Scrum Master... por favor!!! ehehehe 

Na ultima parte do curso tivemos uma verdadeira aula de como escrever User Story, identificar épicos, divisão de tarefas e tudo acompanhado de exercícios práticos. Aliás o estilo do curso foi todo assim vários exercícios e muitos cases para ilustrar e dar um rumo. Vimos também como é possível aumentar a velocidade da equipe adicionando mais membros na equipe, devido ao processo ser interativo... ou seja adeus waterfall!

Outro ponto bacana foram explicações simples de porque não existe uma relação direta entre pontos e horas, as vezes coisas tão básicas como: O sapato numero 40 equivale a quantos cm? Resposta: depende do fabricante! E isso é óbvio não é? Então porque fazer relação entre pontos e horas? ehehehe A quebra de paradigmas é sem dúvida uma dos grandes problemas e outro que é seu complemento é a cultura das pessoas :)

Para fechar o curso... mais um atividade :0) 

E não daria para esperar menos. Foi feito um exercício de Scrum escalável!!! Quatro equipes trabalhando no mesmo projeto, como se fosse uma em cada país. Cada uma possuía seu quadro (Kanban) com seu Scrum Master. 

A tarefa: Ken Schwaber falando o seguinte: "O exército dos Waterfall Wolves" baniu nossos CST`s das principais cidade do mundo. Agora precisamos nos organizar em uma cidade que proporcione um ambiente familiar de trabalho e lazer para todos os Scrummers do mundo. Precisamos construir a Scrumland!", claro que isso é fantasia e o Ken Schwaber não disse isso!

Em cima disto recebemos itens de backlog para fazermos e logo estes foram divididos entre as equipes. 10 minutos para Sprint Planning... itens devidamente priorizados partimos para identificação das tarefas, tendo em vista que teríamos uma sprint de dois dias de 10 minutos e um Daily Meeting de 2 minutos. Ficamos responsáveis por construir a biblioteca e uma loja de post-its... e tínhamos que realmente montar isso tudo e resistir aos testes de qualidade do Product Owner (petelecos nos prédios).

Após o daily, fomos fazer um Scrum of Scrum para sincronizar as equipes onde foi possível identificar gargalo na minha equipe e folga em outra, logo combinamos de ter uma cooperação dos membros ociosos.

No final atingimos o meta estipulada pelo PO!!!

Daqui para frente é aprofundar ainda mais em Agile e Scrum!!!!

Curso CSM com Alexandre Magno (parte 3)

Hoje na terceira parte do curso foi só Scrum. :)

Nesta terceira parte foram desmistificados cada um dos papeis dentro do Scrum. Claro que como em todas as conversas sobre papeis o mais evidenciado foi o do Scrum Master :P

Entramos na famosa discussão sobre ter um Scrum Master que realiza tarefas técnicas dentro da equipe, tal como o que eu faço hoje, sendo Arquiteto, Desenvolvedor e Scrum Master. Foi bom escutar de um profissional bem gabaritado que isso é meio furado, já que em vários momentos eu vou acabar gerando um impedimento na minha tarefa 'técnica' por estar resolvendo coisas da equipe. Espero que com isso eu também não seja afastado do Scrum e sim focado :)

Chegamos numa conclusão muito boa sobre isso tudo, que seria: É ótimo ter um Scrum Master com o pé firme no desenvolvimento pois ele pode ter visão da próxima Sprint e começar a levantar pontos que podem ser críticos para ela e então já tomar medidas para a prevenção. Mas este Scrum Master deve se ater a isto, no mais deve executar seu papel com qualidade, para que o processo seja garantido, para que a equipe esteja realmente protegida, entre outras. O que pode ser feito e isso é uma prática do Scrum é: Terminou suas todas as tarefas que você deve fazer, não tem outras? Então vá ajudar quem precisa! Go Team!!! Ai sim o Scrum Master vai ajudar o desenvolvimento de uma maneira sadia sem fazer com que ele tenha que ser o famoso Jedi!

Outra coisa que foi bem lembrada é que o Product Owner, precisa ser muito bem treinado para que ele saiba transmitir ao time o que o cliente deseja, de maneira clara com uma linguagem única. O que me faz lembrar la da empresa onde trabalho que acabamos tendo um PO por projeto e que muitas vezes complica, pois é mais um trabalho para demonstrar como tudo funciona para que ele entenda como priorizar o backlog e tudo mais. O ideal segundo discussões no curso é termos um único PO que atende os clientes dos mais variados projetos, claro que se o número de projetos for tão grande que o PO não esteja conseguindo desempenhar suas atividades deve haver mais um e então uma divisão destes projetos para cada. Isso seria incrível, ganharíamos uma velocidade com o levantamento das necessidade ou requisitos e ainda poderíamos ter User Stories vindos praticamente prontos do PO.

Tiveram outros pontos apresentados e muita colaboração de todos com várias explicações e casos de sucesso aplicados pelo Alexandre, citando empresas com a Gol.

Logo publico a última parte do evento.

Curso CSM com Alexandre Magno (parte 2)

Depois do famoso almoço executivo :P

Voltamos para o curso e ai sim entramos no processo do Scrum. Cada um dos itens foi passado, superficialmente, e discutido amplamente até que todos estivessem com suas dúvidas sanadas. Isso eu achei muito legal, porque eu já tinha ouvido falar que no curso seria passado como o processo era e pronto. Já neste a única coisa que foi dita é "evitem tentar ficar tirando apenas dúvidas sobre seus problemas ou da sua empresa e tentem absorver o que é o Scrum e o que ele se presta em resolver". Acho que foi mais ou menos isso que o Alexandre falou. O mais bacana foi ver que eu não sou o único a ter este conceito, porque eu sempre entendi sala de aula como isso! :)

Após tudo isso executamos o famoso Scrum 59! Nele nos foi passada a tarefa de construir um 'Flyer', para um Spa de Cães. Executamos de uma forma rápida (59 minutos) praticamente todos os processos do Scrum, lógico que nesta etapa os participantes ainda não tem noções completas sobre como executar o Scrum, mas a intenção era esta! A de acertar errando. Isso porque o ser humano aprende mais errando, é claro! 

É interessante participar novamente de um simples processo onde você se força a trabalhar com outras pessoas que nunca viu na vida e mesmo assim pode ver as coisas funcionando bem em pouco tempo.

Contamos também com a participação do Daniel Wildt da Dell aqui de Porto Alegre (onde estou no momento), que enriqueceu os debates varias vezes com cases e experiências profissionais.

Lamento apenas não poder ficar para o evento de quarta feira sobre Agile. Mas existem coisas mais importantes como a família :)

Amanhã continuo blogando sobre o evento.

 

Curso CSM com Alexandre Magno (parte 1)

Hoje as 09:05 começou o treinamento ministrado pelo Alexandre Magno (CST) da Caelum.

Na primeira parte vimos pouco sobre o que fala o Scrum, mas tivemos uma base excelente sobre método Interativo e Waterfall, onde ele demonstrou que uma das principais razões do Scrum ser de difícil implantação, é por causa da forma interativa de trabalho, que as pessoas custam a entender. Isso tudo claro devido a anos trabalhando com o modelo waterfall. 

O que achei legal foi um fato que ocorreu com ele tentando mostrar isso a um amigo. Ele disse ao amigo que havia encontrado uma maneira de executar Scrum usando Waterfall e então o amigo começou a identificar os mais variados artefatos usados pelo Scrum, dizendo então que daquele forma o Scrum funcionaria e que ele conseguiria ter várias práticas em cada uma das iterações. Lógico que isso foi só uma jogada para que o citado amigo identificasse que o problema na verdade era a quebra de paradigma e que pudesse compreender aquela mudança.

Toda esta primeira parte tivemos muita interação entre os participantes, formando 3 equipes de 4 integrantes e mais uma de 5. 

Demonstrações de métodos ágeis, com atividades, que nos fizeram ter real noção de como a distribuição de tarefas e responsabilidades podem nos ajudar na execução do projeto.

Em fim logo nesta primeira parte tivemos muito sobre agile, gestão, etc. Sem quebra pau sobre PMP, RUP e outros.. o que me deixou mais feliz, porque ficou algo  muito tranquilo e legal de assistir e aprender.

Ahhh e para que acha que é só ficar dentro da sala e pronto.. se engana o próprio Alexandre já falou que se não demonstrar que absorveu, não leva o CSM e ele já fez isso com algumas pessoas :)

Abraços!

O que o cliente paga é aquilo que recebe?

No final de semana passada passei um micro curso, talvez até mesmo um simples overview. Por incrível que pareça isso foi feito para meu cunhado que é fã do PMI, eheheh.

Passamos por todas as etapas de execução de um projeto, sempre com exemplos e tentando encaixar os conceitos no dia-a-dia dele de gerente de projetos. Bom.. conversa vai, conversa vem e lembrei de um desenho que representa um grande paradigma do desenvolvimento e gestão de projetos.

Este desenho é um espelho da realidade, vou passar meu ponto de vista para cada um dos quadros.

Como o cliente explicou: O cliente quando explica o que quer tenta passar uma visão de algo inovador, grande ou diferente, onde nem sempre condiz com a realidade ou com requisitos técnicos.

Como o líder de projeto entendeu: Uma única pessoa (líder) conversou com o cliente (etapa anterior), coisa que não ocorre com o Scrum onde toda a equipe vai conversar com o Product Owner. Bom um único entendimento e passado adiante, gera um ruído considerável.

Como o analista planejou: Quando o analista recebeu os requisitos do líder e tentou atender as especificações e limitações, ele acaba planejando algo em cima do que compreendeu, ou seja, mais ruído.

Como o programador codificou: O programador recebe do analista o que deve fazer, mas também tem sua interpretação e novamente ruídos. Então ele codifica com todos os requisitos levantados, porém pode ser que não funcione com o esperado.

O que os beta testers receberam: Os testadores das primeiras releases do sistema receberam algo que pouco condizia com o produto esperado e logo irão fazer testes em algo que não está funcionando corretamente, pelo menos não como deveria.

Como o consultor de negócios descreveu: O vendedor faz sempre o produto parecer mais do que é, muitas vezes passando uma falsa visão de como será o produto.

Valor que o cliente pagou: Quando um projeto é feito, sabemos os riscos e o quanto de trabalho teremos, logo conhecemos também as tradicionais falhas e tudo isso é levado em conta, sendo assim este valor é repassado ao cliente, onde muitas vezes ele paga muito mais do que seria realmente preciso. 
Como o projeto foi documentado: Lembre sempre, Agile não é ausência de documentação é sim ter somente a documentação que é necessária e agrega valor após o projeto.

O que a assistência técnica instalou: Se for instalar algo para o cliente, entregue algo funcional. É isso que diz a metodologia e o bom senso é claro, afinal ninguém quer ser enrrolado.

Quando foi entregue: Lógico que atrasos acontecem, mas estamos sempre tentando entregar em dia, muito atraso desgasta a equipe a a imagem da empresa com o cliente.

O que o cliente realmente necessitava: Sempre, eu repito SEMPRE, que o cliente especifica um produto o que ele realmente precisava era algo muito menor e mais simples.

Agora se tivéssemos usado um dos princípios básicos do Scrum que é levar toda a equipe para conversar e tirar as dúvidas com o cliente (product owner), não teríamos mais excessos ou deturpações de requisitos durante o processo de construção do produto. Se resolvêssemos esta parte já teríamos uma grande economia para o cliente, deixaríamos ele mais satisfeito e pouparíamos a equipe, podendo ainda receber novos projetos em um menor período de tempo.

Abraços!