Essa semana começou bem.
Hoje, terça-feira, fiz com a minha equipe (desfalcada, pois um dos integrantes está viajando de férias) uma retrospectiva final do projeto, abrangendo os dois anos que estivemos juntos. Algumas coisas interessantes aconteceram :) Vou listá-las amanhã para vocês (hoje estou moído!).
E na sexta-feira irei fazer uma "palestra-dinâmica" para uma turma de pós, na universidade. Será legal ter um público diferente. Para isso, estou adaptando a dinâmica para funcionar melhor. Depois posto ela aqui para vocês utilizarem. Acho que ficará mais divertida :)
Abração
Mostrando postagens com marcador SCRUM. Mostrar todas as postagens
Mostrando postagens com marcador SCRUM. Mostrar todas as postagens
Terça-feira, 22 de Julho de 2008
Segunda-feira, 21 de Julho de 2008
Voltando...
Pois então, pessoal. Estou de volta.
Semana passada foi meio crítica. O meu pai, no sábado, baixou hospital com algumas dores abdominais, que foram identificadas como uma infecção no local onde ele havia feito uma cirurgia há meses atrás. É um fato raro de acontecer, mas aconteceu.
Deu tudo certo! Na sexta passada ele saiu do hospital e está novo em folha! :)
Mas são nestes momentos que a gente percebe como somos frágeis neste mundo. De uma hora para a outra, podemos estar deitados em uma cama de hospital. A gente começa a refletir um pouco sobre nossos hábitos, sobre a beleza das pequenas coisas, como estar em família. Tirei a semana de folga no trabalho, pois não conseguiria me concentrar sabendo que o meu pai estava hospitalizado. E meus dois irmãos (irmão e irmã) também. Logo, convivemos todos (mais a minha mãe) como antigamente, os cinco juntos. Coisa assim era bastante corriqueira: janta, um final de semana na praia, etc. Mas a semana inteira não :)
E como é bom isso. A gente percebe como a família é mais importante do que tudo.
Refletindo um pouco, a gente as vezes pensa em quantas vezes passamos horas e horas na frente do computador trabalhando. E em quantos momentos já deixamos de fazer algo com a família ou com a gente mesmo, para se dedicar um pouco mais ao trabalho. Por mais que a gente goste de trabalhar, talvez algumas vezes devessemos repensar nossas prioridades. Será que perder uma sexta-feira a noite, ou um final de semana, adiantando trabalho vale a pena? Será que não poderíamos usar esse tempo para nos dedicar a família?
Muito se fala em qualidade de vida. Eu acho que a qualidade de vida está entre balancear corretamente a nossa vida no trabalho com a vida pessoal.
Numa palestra com o Daniel Wildt, no mesmo dia em que eu fiz a palestra sobre o "Scrum in Hell", ele falou uma coisa que acho que mostra a essência de como um processo como o SCRUM pode melhor inclusive a nossa vida pessoal: ele disse que em uma empresa, havia um analista cujo horário de trabalho normalmente ia até as 21h. Então ele tomou este cara como exemplo e desafio e prometeu para ele: "uma das minhas funções aqui é fazer com que tu saia do trabalho às 18h". E conseguiu! Ou seja, o SCRUM (e o agile como um todo) com certeza ajudou a dar mais qualidade de vida para este analista :)
Enfim, estou voltando. E espero voltar a manter a periodicidade diária do blog. Podem me cobrar ;)
Um grande abraço
Semana passada foi meio crítica. O meu pai, no sábado, baixou hospital com algumas dores abdominais, que foram identificadas como uma infecção no local onde ele havia feito uma cirurgia há meses atrás. É um fato raro de acontecer, mas aconteceu.
Deu tudo certo! Na sexta passada ele saiu do hospital e está novo em folha! :)
Mas são nestes momentos que a gente percebe como somos frágeis neste mundo. De uma hora para a outra, podemos estar deitados em uma cama de hospital. A gente começa a refletir um pouco sobre nossos hábitos, sobre a beleza das pequenas coisas, como estar em família. Tirei a semana de folga no trabalho, pois não conseguiria me concentrar sabendo que o meu pai estava hospitalizado. E meus dois irmãos (irmão e irmã) também. Logo, convivemos todos (mais a minha mãe) como antigamente, os cinco juntos. Coisa assim era bastante corriqueira: janta, um final de semana na praia, etc. Mas a semana inteira não :)
E como é bom isso. A gente percebe como a família é mais importante do que tudo.
Refletindo um pouco, a gente as vezes pensa em quantas vezes passamos horas e horas na frente do computador trabalhando. E em quantos momentos já deixamos de fazer algo com a família ou com a gente mesmo, para se dedicar um pouco mais ao trabalho. Por mais que a gente goste de trabalhar, talvez algumas vezes devessemos repensar nossas prioridades. Será que perder uma sexta-feira a noite, ou um final de semana, adiantando trabalho vale a pena? Será que não poderíamos usar esse tempo para nos dedicar a família?
Muito se fala em qualidade de vida. Eu acho que a qualidade de vida está entre balancear corretamente a nossa vida no trabalho com a vida pessoal.
Numa palestra com o Daniel Wildt, no mesmo dia em que eu fiz a palestra sobre o "Scrum in Hell", ele falou uma coisa que acho que mostra a essência de como um processo como o SCRUM pode melhor inclusive a nossa vida pessoal: ele disse que em uma empresa, havia um analista cujo horário de trabalho normalmente ia até as 21h. Então ele tomou este cara como exemplo e desafio e prometeu para ele: "uma das minhas funções aqui é fazer com que tu saia do trabalho às 18h". E conseguiu! Ou seja, o SCRUM (e o agile como um todo) com certeza ajudou a dar mais qualidade de vida para este analista :)
Enfim, estou voltando. E espero voltar a manter a periodicidade diária do blog. Podem me cobrar ;)
Um grande abraço
Quinta-feira, 10 de Julho de 2008
Sugestão para "intranet"
Amigos,
estamos aqui no trabalho precisando de uma ferramenta para fazer as vezes de "intranet". Tentamos usar os wikis, que são poderosos, mas ao mesmo tempo não são tão intuitivos.
Encontrei essa ferramenta, já consideravelmente conhecida, chamada Zoho Projects (www.zoho.com). Criei um projeto para ver como funciona e gostei muito do que eu vi.
Pode ser adaptada pro SCRUM tranquilamente. É bem simples e bem funcional! Vale a pena e fica a minha sugestão. Algumas features que ela provê:
- Quatro tipos de usuários (admin, contractor, manager, employee) com visões e atribuições diferentes.
- Forum para discussões
- Visualização de o usuário está online ou não (faltou um chat integrado)
- Cadastro de horas trabalhadas (para empresas mais rígidas)
- Controle de arquivos (com versionamento)
- Agendamento de reuniões
- Criação de milestones que contem grupo de tarefas e que contem tarefas. Aqui, basta mudar para sprint (milestone), user story e impediment backlog (grupo de tarefas) e tarefas. As tarefas podem ficar sem atribuições de pessoas, podendo ser atualizada durante a daily meeting.
- Feed RSS para aviso de mudanças
- Log com mudanças que ocorram na página
- Possibilidade de inserir notas em tarefas, reuniões, etc.
Enfim, para quem procura uma ferramenta bem simples e gratuita para controlar o seu projeto, eu recomendo esta.
Fica a sugestão :)
estamos aqui no trabalho precisando de uma ferramenta para fazer as vezes de "intranet". Tentamos usar os wikis, que são poderosos, mas ao mesmo tempo não são tão intuitivos.
Encontrei essa ferramenta, já consideravelmente conhecida, chamada Zoho Projects (www.zoho.com). Criei um projeto para ver como funciona e gostei muito do que eu vi.
Pode ser adaptada pro SCRUM tranquilamente. É bem simples e bem funcional! Vale a pena e fica a minha sugestão. Algumas features que ela provê:
- Quatro tipos de usuários (admin, contractor, manager, employee) com visões e atribuições diferentes.
- Forum para discussões
- Visualização de o usuário está online ou não (faltou um chat integrado)
- Cadastro de horas trabalhadas (para empresas mais rígidas)
- Controle de arquivos (com versionamento)
- Agendamento de reuniões
- Criação de milestones que contem grupo de tarefas e que contem tarefas. Aqui, basta mudar para sprint (milestone), user story e impediment backlog (grupo de tarefas) e tarefas. As tarefas podem ficar sem atribuições de pessoas, podendo ser atualizada durante a daily meeting.
- Feed RSS para aviso de mudanças
- Log com mudanças que ocorram na página
- Possibilidade de inserir notas em tarefas, reuniões, etc.
Enfim, para quem procura uma ferramenta bem simples e gratuita para controlar o seu projeto, eu recomendo esta.
Fica a sugestão :)
Terça-feira, 8 de Julho de 2008
E na reta final... uma ultrapassagem perfeita!
Como é o destino...
Meus dois últimos posts foram bem pessimistas. Disse inclusive que o meu projeto encerraria com 95% dele finalizado, apenas. Porém, desde o post, só aconteceram coisas boas! E o resultado é que o projeto está 99,9% entregue! :) Sim, teoricamente, mas parece que todo mundo resolveu dar um último gás no último segundo, e o panorama mudou.
Sexta-feira, o desenvolvedor da parte do software ficou até tarde trabalhando no laboratório. Queria tentar resolver os bugs que haviam aparecido nos testes. Enquanto isso, eu me dedicava a fazer o vídeo do nosso projeto. Ele estava irritado pois não achava o erro. E eu estava preocupado pois não encontrava vídeos onde pudessem aparecer cenas no campo, já que nosso projeto é de agricultura de precisão. Precisava de tratores, colheitadeiras, etc.
Sábado, envio um email para o meu chefe e ele me diz que encontrou umas fotos e vídeos antigos que fizemos quando fomos na fazenda dele, ainda no início do projeto. Bingo! Todo o material que eu precisava estava lá!! Ao mesmo tempo, o desenvolvedor de software voltou para trabalhar durante toda tarde no laboratório, para encerrar de uma vez o software. Ao final do dia, envia um email comemorando por ter resolvido (teoricamente) todos os bugs que tínhamos. E ainda deu tempo de fazer um sistema DEMO para rodar no dia da feira!
Domingo, finalizo o filme e um documento contendo todos os custos do nosso protótipo. Envio para o pessoal e todos ficam animadíssimos com o filme.
Então chega o dia da feira, segunda-feira. Acordo cedo, 6h30, para levar a namorada na rodoviária. Tinha que estar no trabalho às 8h30. Então durante uma hora e meia finalizo alguns outros materiais e corro para o trabalho. Lá apresento a versão final do filme e todos comemoram pois o resultado ficou realmente muito bacana! O documento dos custos é aprovado por todos também, pois era algo que iríamos precisar MUITO na feira.
Chegando na feira, diversas outras empresas já se encontravam lá. Arrumamos nossa mesa da seguinte forma:
- Notebook rodando o vídeo, em loop;
- Notebook rodando a demonstração do produto;
- Nosso protótipo (numa caixa e acabamento bem razoável) rodando o demo (acendendo luzinhas!);
- Um banner explicativo, bem bacana;
- Cartões de visita, folders, etc.
A nossa principal missão é agradar a comissão avaliadora, que veria os resultados produzidos pelo projeto. Organizamos nosso espaço de forma bem bacana e ainda tivemos sorte de que nossos vizinhos eram projetos extremamente simples (um era sobre abacates!!! Sabe-se lá o que era aquilo hehe).
Durante toda feira pudemos ver que das aproximadamente 20 empresas que estavam no local, éramos sem dúvida nenhuma a segunda melhor a apresentar seus produtos. Não fomos a primeira pois uma das empresas desenvolveu um scanner sensacional, e já estava em versão de produto... impossível competir com um produto tão perfeito, vamos ser sinceros. Fora isso, não tenho dúvidas que o nosso projeto era o que melhor foi divulgado lá.
Os resultados: várias pessoas interessadas em conhecer nosso produto, nenhum problema durante a apresentação, nenhum problema na avaliação (inclusive conseguimos encantar vários avaliadores). Internamente falando, TODA equipe de desenvolvimento estava satisfeita e orgulhosa do resultado. O meu chefe também ficou muito feliz e satisfeito. E eu, claro, me senti muito orgulhoso em ver que tudo havia dado certo. Tanto que não me preocupei em ficar aproximadamente seis horas de pé!
Essa semana iremos fazer a finalização do documento. E meu chefe agora se empolgou e quer fazer o teste final na fazenda, em um trator. Assim podemos ter um vídeo bem completo de todo o projeto. Além disso, a documentação do conhecimento adquirido no projeto será feita via vídeo também. Ninguém conseguirá escrever muito nessa semana, então decidi fazer vídeo. Não vai adiantar muito, mas pelo menos é alguma coisa.
Na sexta-feira faremos a retrospectiva final do projeto. Vamos analisar nossos erros, acertos, o que poderíamos ter feito de melhor, etc. Acho que isso será muito importante. Além disso, tentarei fazer uma sessão de feedback, para discutirmos a atuação individual de cada um. Isso também eu acho que será bem interessante.
Enfim. Essa reta final mostrou que quando um projeto deixa de ser apenas trabalho e passa a ser visto como uma realização pessoal, a coisa muda completamente de figura. Eu jamais imaginei que o desenvolvedor iria trabalhar um sábado inteiro para finalizar a parte dele. Essa foi uma das atitudes que mais me supreenderam nos últimos meses. Graças a ele pudemos ter algo bem tangível com relação ao nosso produto.
Foi uma prova de que se conseguirmos fazer essa mentalidade em toda a equipe, qualquer projeto que pegarmos será um sucesso. Agora, se tratarmos a equipe como "recursos" e um projeto como trabalho, realmente a coisa não irá fluir naturalmente. E o resultado tenderá ao fracasso.
Uma lição aprendida na prática.
Um grande abraço
Meus dois últimos posts foram bem pessimistas. Disse inclusive que o meu projeto encerraria com 95% dele finalizado, apenas. Porém, desde o post, só aconteceram coisas boas! E o resultado é que o projeto está 99,9% entregue! :) Sim, teoricamente, mas parece que todo mundo resolveu dar um último gás no último segundo, e o panorama mudou.
Sexta-feira, o desenvolvedor da parte do software ficou até tarde trabalhando no laboratório. Queria tentar resolver os bugs que haviam aparecido nos testes. Enquanto isso, eu me dedicava a fazer o vídeo do nosso projeto. Ele estava irritado pois não achava o erro. E eu estava preocupado pois não encontrava vídeos onde pudessem aparecer cenas no campo, já que nosso projeto é de agricultura de precisão. Precisava de tratores, colheitadeiras, etc.
Sábado, envio um email para o meu chefe e ele me diz que encontrou umas fotos e vídeos antigos que fizemos quando fomos na fazenda dele, ainda no início do projeto. Bingo! Todo o material que eu precisava estava lá!! Ao mesmo tempo, o desenvolvedor de software voltou para trabalhar durante toda tarde no laboratório, para encerrar de uma vez o software. Ao final do dia, envia um email comemorando por ter resolvido (teoricamente) todos os bugs que tínhamos. E ainda deu tempo de fazer um sistema DEMO para rodar no dia da feira!
Domingo, finalizo o filme e um documento contendo todos os custos do nosso protótipo. Envio para o pessoal e todos ficam animadíssimos com o filme.
Então chega o dia da feira, segunda-feira. Acordo cedo, 6h30, para levar a namorada na rodoviária. Tinha que estar no trabalho às 8h30. Então durante uma hora e meia finalizo alguns outros materiais e corro para o trabalho. Lá apresento a versão final do filme e todos comemoram pois o resultado ficou realmente muito bacana! O documento dos custos é aprovado por todos também, pois era algo que iríamos precisar MUITO na feira.
Chegando na feira, diversas outras empresas já se encontravam lá. Arrumamos nossa mesa da seguinte forma:
- Notebook rodando o vídeo, em loop;
- Notebook rodando a demonstração do produto;
- Nosso protótipo (numa caixa e acabamento bem razoável) rodando o demo (acendendo luzinhas!);
- Um banner explicativo, bem bacana;
- Cartões de visita, folders, etc.
A nossa principal missão é agradar a comissão avaliadora, que veria os resultados produzidos pelo projeto. Organizamos nosso espaço de forma bem bacana e ainda tivemos sorte de que nossos vizinhos eram projetos extremamente simples (um era sobre abacates!!! Sabe-se lá o que era aquilo hehe).
Durante toda feira pudemos ver que das aproximadamente 20 empresas que estavam no local, éramos sem dúvida nenhuma a segunda melhor a apresentar seus produtos. Não fomos a primeira pois uma das empresas desenvolveu um scanner sensacional, e já estava em versão de produto... impossível competir com um produto tão perfeito, vamos ser sinceros. Fora isso, não tenho dúvidas que o nosso projeto era o que melhor foi divulgado lá.
Os resultados: várias pessoas interessadas em conhecer nosso produto, nenhum problema durante a apresentação, nenhum problema na avaliação (inclusive conseguimos encantar vários avaliadores). Internamente falando, TODA equipe de desenvolvimento estava satisfeita e orgulhosa do resultado. O meu chefe também ficou muito feliz e satisfeito. E eu, claro, me senti muito orgulhoso em ver que tudo havia dado certo. Tanto que não me preocupei em ficar aproximadamente seis horas de pé!
Essa semana iremos fazer a finalização do documento. E meu chefe agora se empolgou e quer fazer o teste final na fazenda, em um trator. Assim podemos ter um vídeo bem completo de todo o projeto. Além disso, a documentação do conhecimento adquirido no projeto será feita via vídeo também. Ninguém conseguirá escrever muito nessa semana, então decidi fazer vídeo. Não vai adiantar muito, mas pelo menos é alguma coisa.
Na sexta-feira faremos a retrospectiva final do projeto. Vamos analisar nossos erros, acertos, o que poderíamos ter feito de melhor, etc. Acho que isso será muito importante. Além disso, tentarei fazer uma sessão de feedback, para discutirmos a atuação individual de cada um. Isso também eu acho que será bem interessante.
Enfim. Essa reta final mostrou que quando um projeto deixa de ser apenas trabalho e passa a ser visto como uma realização pessoal, a coisa muda completamente de figura. Eu jamais imaginei que o desenvolvedor iria trabalhar um sábado inteiro para finalizar a parte dele. Essa foi uma das atitudes que mais me supreenderam nos últimos meses. Graças a ele pudemos ter algo bem tangível com relação ao nosso produto.
Foi uma prova de que se conseguirmos fazer essa mentalidade em toda a equipe, qualquer projeto que pegarmos será um sucesso. Agora, se tratarmos a equipe como "recursos" e um projeto como trabalho, realmente a coisa não irá fluir naturalmente. E o resultado tenderá ao fracasso.
Uma lição aprendida na prática.
Um grande abraço
Terça-feira, 1 de Julho de 2008
Palestra "Scrum in Hell - Implantando agilidade em ambientes difíceis"
Salve pessoal,
Ontem realizei a palestra a convite do pessoal do GUMA-RS (Grupo de Usuários de Métodos Ágeis) onde trouxe um caso prático da aplicação do SCRUM, no meu trabalho.
O link para download é este.
Utilizei a conotação "ambiente difícil" para ilustrar ambientes onde os processos são caóticos, a comunicação normalmente é ruim, a cultura é autocrática, etc. que normalmente remetem a empresas de pequeno porte - e no meu caso, em grupos de pesquisa acadêmicos.
A apresentação não foi muuuito bem conduzida. Muito porque eu não tive tempo suficiente para prepará-la. Então acredito que o material apresentado tenha sido bem interessante, porém não consegui conduzir muito bem (em alguns momentos eu nem lembrava ao certo o porque havia escrito aquilo). Mesmo assim, com algumas correções, essa apresentação ficará redonda e bem ilustrativa de como aplicar SCRUM em sua empresa :)
Na verdade acredito que vou mudar o contexto dessa apresentação. Ao invés de ser "Scrum in Hell" será algo do tipo "YES YOU CAN!", que remete a um bordão americano famoso - usado incessantemente por um daqueles apresentadores de programa estilo "Márcia Goldschimitt" nos Estados Unidos, nos anos 90.
No post anterior, o Jefferson comentou que achou muito interessante o processo que eu abordei. Pretendo trabalhar mais em cima disso, mostrando como é simples de aplicar o SCRUM em sua empresa, seja ela pequena, grande, autocrática ou democrática. Podem ser iniciativas que partem desde o modelo "top-down", ou seja, vendendo a idéia para a diretoria para então implantar no operacional, ou "bottom-up", fazendo o inverso.
Então esperem que a próxima palestra será sim bem melhor e bem mais focada :) Tenho certeza que irão gostar mais ainda.
Uma pena que haviam 50 inscritos para a palestra e apenas metade compareceu ao evento, no dia. Espero que estas pessoas não tenham tirado o lugar de outros que não puderam ir!
O link para download da apresentação é este.
Vou ver se consigo com o Daniel para publicar a apresentação dele, que possuia muitos links interessantes.
Um grande abraço
Ontem realizei a palestra a convite do pessoal do GUMA-RS (Grupo de Usuários de Métodos Ágeis) onde trouxe um caso prático da aplicação do SCRUM, no meu trabalho.
O link para download é este.
Utilizei a conotação "ambiente difícil" para ilustrar ambientes onde os processos são caóticos, a comunicação normalmente é ruim, a cultura é autocrática, etc. que normalmente remetem a empresas de pequeno porte - e no meu caso, em grupos de pesquisa acadêmicos.
A apresentação não foi muuuito bem conduzida. Muito porque eu não tive tempo suficiente para prepará-la. Então acredito que o material apresentado tenha sido bem interessante, porém não consegui conduzir muito bem (em alguns momentos eu nem lembrava ao certo o porque havia escrito aquilo). Mesmo assim, com algumas correções, essa apresentação ficará redonda e bem ilustrativa de como aplicar SCRUM em sua empresa :)
Na verdade acredito que vou mudar o contexto dessa apresentação. Ao invés de ser "Scrum in Hell" será algo do tipo "YES YOU CAN!", que remete a um bordão americano famoso - usado incessantemente por um daqueles apresentadores de programa estilo "Márcia Goldschimitt" nos Estados Unidos, nos anos 90.
No post anterior, o Jefferson comentou que achou muito interessante o processo que eu abordei. Pretendo trabalhar mais em cima disso, mostrando como é simples de aplicar o SCRUM em sua empresa, seja ela pequena, grande, autocrática ou democrática. Podem ser iniciativas que partem desde o modelo "top-down", ou seja, vendendo a idéia para a diretoria para então implantar no operacional, ou "bottom-up", fazendo o inverso.
Então esperem que a próxima palestra será sim bem melhor e bem mais focada :) Tenho certeza que irão gostar mais ainda.
Uma pena que haviam 50 inscritos para a palestra e apenas metade compareceu ao evento, no dia. Espero que estas pessoas não tenham tirado o lugar de outros que não puderam ir!
O link para download da apresentação é este.
Vou ver se consigo com o Daniel para publicar a apresentação dele, que possuia muitos links interessantes.
Um grande abraço
Segunda-feira, 30 de Junho de 2008
É hoje a palestra!
Hoje é a palestra que irei dar ao público aqui em Porto Alegre entitulada: "SCRUM IN HELL - Uma abordagem prática da aplicação do SCRUM em ambientes difíceis". O nome é mesmo para instigar :)
Irei conceituar o que eu chamo de ambientes difíceis (micro e pequenas empresas e, no meu caso, grupo de pesquisa universitário) e depois apresentarei o que eu fiz para iniciar a implantação do SCRUM no ambiente de trabalho. Não será uma palestra que fala sobre a metodologia do SCRUM, mas sim uma visão de como ela pode nos ajudar no dia-a-dia.
Espero que consiga passar a mensagem para o público e que pelo menos alguns, se animem a tentar mudar em suas empresas :)
Depois conto como foi.
---------------------------
Essa é a semana decisiva do projeto Agritec. Semana passada os guris acabaram queimando um pequeno circuito da placa, que já foi trocado (felizmente não foi nada grave). Essa semana faremos os testes e depois prepararemos a apresentação que será feita na outra segunda-feira.
Tomara que tudo corra nos conformes...
Irei conceituar o que eu chamo de ambientes difíceis (micro e pequenas empresas e, no meu caso, grupo de pesquisa universitário) e depois apresentarei o que eu fiz para iniciar a implantação do SCRUM no ambiente de trabalho. Não será uma palestra que fala sobre a metodologia do SCRUM, mas sim uma visão de como ela pode nos ajudar no dia-a-dia.
Espero que consiga passar a mensagem para o público e que pelo menos alguns, se animem a tentar mudar em suas empresas :)
Depois conto como foi.
---------------------------
Essa é a semana decisiva do projeto Agritec. Semana passada os guris acabaram queimando um pequeno circuito da placa, que já foi trocado (felizmente não foi nada grave). Essa semana faremos os testes e depois prepararemos a apresentação que será feita na outra segunda-feira.
Tomara que tudo corra nos conformes...
Quarta-feira, 25 de Junho de 2008
Evento de Metodos Ágeis em Porto Alegre - 30/06
No próximo dia 30/06 (segunda-feira) o Grupo de Usuários de Metodos Ágeis do RS (GUMA) estará promovendo um encontro com os interessados em conhecer um pouco mais sobre SCRUM, XP, e outros métodos.
Eu farei a segunda palestra, sobre "SCRUM IN HELL - uma abordagem prática da aplicação da metodologia ágil em ambientes difíceis", um nome bem-humorado para mostrar algumas dificuldades que passei na tentativa de implantação da metodologia no meu trabalho.
Fica o convite para quem quiser assistir, trocar algumas idéias e conversar. Você, de Porto Alegre e região, não deixe de ir.
Mais informações no site: http://www.rs.sucesu.org.br/inscricao/guma_30-06
Horário: 18h30min
Local: Auditório 517 da Faculdade de Informática da PUCRS (prédio 32)
Eu farei a segunda palestra, sobre "SCRUM IN HELL - uma abordagem prática da aplicação da metodologia ágil em ambientes difíceis", um nome bem-humorado para mostrar algumas dificuldades que passei na tentativa de implantação da metodologia no meu trabalho.
Fica o convite para quem quiser assistir, trocar algumas idéias e conversar. Você, de Porto Alegre e região, não deixe de ir.
Mais informações no site: http://www.rs.sucesu.org.br/inscricao/guma_30-06
Data: 30 de junho de 2008
Horário: 18h30min
Local: Auditório 517 da Faculdade de Informática da PUCRS (prédio 32)
Segunda-feira, 23 de Junho de 2008
Implantando o SCRUM a conta-gotas.
Não existe dúvida que a implantação de qualquer metodologia (ou prática ou padrão) requer um pré-requisito principal para funcionar: o apoio da direção.
De nada adianta nossa boa vontade, nossa motivação, iniciativa e conhecimento técnico se os maiores patrocinadores da mudança não demonstrarem pelo menos metade disso.
Por isso, vou listar aqui algumas idéias para você implantar alguns conceitos de agile e SCRUM aos pouquinhos. De forma que, em pouco tempo, a implantação completa seja só um pequeno passo.
Observação importante: essa é a minha opinião :)
Vamos lá
1) DAILY MEETINGS. Nada mais simples do que isso. Reuna a sua equipe diariamente e comece a fazer as três famosas perguntas: "O que você fez ontem? O que fará hoje - ou o que pretende fazer para amanhã ? Quais seus impedimentos?". Essa é uma poderosa forma de maximizar a comunicação da sua equipe! E tem como bonus, a vantagem de que pelo menos uma vez por dia TODOS irão estar reunidos em um horário certo.
2) SPRINTS. Tente criar o conceito de sprints, mesmo sem seus chefes saberem. Defina "deadlines" a cada 2 semanas ou 1 mês e mantenha fixo.
3) PRODUCT BACKLOG. Defina o seu primeiro product backlog. Tente levantar as funcionalidades que precisam ser feitas, priorize e discuta cada uma, criando estimativas e definições de finalizado.
4) CRIE UM TASKBOARD. Um simples local onde você tem as suas tarefas em "todo", "doing" e "done" já é um bom começo para ter o seu termômetro do status do projeto. Agregue valor com o tempo (stories, burndown, impedimentos, tarefas não planejadas, etc).
5) RETROSPECTIVAS. Ao final de um sprint, use o taskboard como repositório e faça uma retrospectiva com sua equipe. Veja o que foi bom, o que poderia ser melhorado e no que vocês irão focar para melhorar. Detalhe: faça dessa reunião algo bem informal, compre uns salgadinhos e refrigerantes.
E lembre-se, você pode implantar o SCRUM na sua empresa de duas maneiras: pelo jeito "bottom-up" ou pelo jeito "top-down". Bottom-up seria você começando diretamente com a sua equipe e com isso mostrando ao seu chefe os resultados das práticas ágeis. Top-down é o inverso, ou seja, você vende a idéia para o seu chefe e depois tenta vender para sua equipe.
Ambas são eficientes, e dependem do seu ambiente de trabalho. Tenha isso em mente, quando for pôr em prática estas cinco preciosas práticas que eu deixo aqui :)
São as minhas cinco dicas para quem quiser tentar colocar um pouco de agilidade em seu ambiente :) Se você tem outras dicas, poste aí nos comentários!
Abraços
De nada adianta nossa boa vontade, nossa motivação, iniciativa e conhecimento técnico se os maiores patrocinadores da mudança não demonstrarem pelo menos metade disso.
Por isso, vou listar aqui algumas idéias para você implantar alguns conceitos de agile e SCRUM aos pouquinhos. De forma que, em pouco tempo, a implantação completa seja só um pequeno passo.
Observação importante: essa é a minha opinião :)
Vamos lá
1) DAILY MEETINGS. Nada mais simples do que isso. Reuna a sua equipe diariamente e comece a fazer as três famosas perguntas: "O que você fez ontem? O que fará hoje - ou o que pretende fazer para amanhã ? Quais seus impedimentos?". Essa é uma poderosa forma de maximizar a comunicação da sua equipe! E tem como bonus, a vantagem de que pelo menos uma vez por dia TODOS irão estar reunidos em um horário certo.
2) SPRINTS. Tente criar o conceito de sprints, mesmo sem seus chefes saberem. Defina "deadlines" a cada 2 semanas ou 1 mês e mantenha fixo.
3) PRODUCT BACKLOG. Defina o seu primeiro product backlog. Tente levantar as funcionalidades que precisam ser feitas, priorize e discuta cada uma, criando estimativas e definições de finalizado.
4) CRIE UM TASKBOARD. Um simples local onde você tem as suas tarefas em "todo", "doing" e "done" já é um bom começo para ter o seu termômetro do status do projeto. Agregue valor com o tempo (stories, burndown, impedimentos, tarefas não planejadas, etc).
5) RETROSPECTIVAS. Ao final de um sprint, use o taskboard como repositório e faça uma retrospectiva com sua equipe. Veja o que foi bom, o que poderia ser melhorado e no que vocês irão focar para melhorar. Detalhe: faça dessa reunião algo bem informal, compre uns salgadinhos e refrigerantes.
E lembre-se, você pode implantar o SCRUM na sua empresa de duas maneiras: pelo jeito "bottom-up" ou pelo jeito "top-down". Bottom-up seria você começando diretamente com a sua equipe e com isso mostrando ao seu chefe os resultados das práticas ágeis. Top-down é o inverso, ou seja, você vende a idéia para o seu chefe e depois tenta vender para sua equipe.
Ambas são eficientes, e dependem do seu ambiente de trabalho. Tenha isso em mente, quando for pôr em prática estas cinco preciosas práticas que eu deixo aqui :)
São as minhas cinco dicas para quem quiser tentar colocar um pouco de agilidade em seu ambiente :) Se você tem outras dicas, poste aí nos comentários!
Abraços
Sábado, 14 de Junho de 2008
Porto Alegre Agile Meeting 1
Sexta-feira tive a oportunidade de conhecer e papear com algumas pessoas fantásticas. Ocorreu em Porto Alegre o treinamento de CSM (Certified Scrum Master) pela Teamware. Eu havia conversado com o Juan, que estava promovendo o curso, da possibilidade de fazermos um encontro após o curso (que eu não pude participar). Ele então achou ótima a idéia e ajudou a divulgar. Saiu então o primeiro "Porto Alegre Agile Meeting", que infelizmente só teve presença de 5 pessoas, incluindo eu.
Estavam presentes dois alunos do curso (agora certificados!), o Juan, o canadense Robin Dymond (instrutor do curso) e eu. Cheguei atrasado, pois precisava buscar a namorada na rodoviária (e ela acabou indo e achou bastante interessante devido a sua área de interesse ser de RH e o Agile ter uma forte presença nessa área). Encontrei o pessoal e pudemos papear (meio em português, meio em inglês para o Robin participar) sobre Agile e até mesmo assuntos banais. Pude conversar com o Robin um pouco e foi bem legal pois ele já trabalhou com sistemas embarcados em hardware, o que me ajudou bastante a entender algumas idéias para aplicar no meu trabalho!
O bacana foi a possibilidade de trocar experiências e lições aprendidas, discutir conceitos, concordar, discordar, fazer networking, enfim. É exatamente o tipo de evento que eu sempre busco organizar!
Portanto, preparem-se os moradores de Porto Alegre e região, pois tentarei organizar estes encontros pelo menos 1x por mês.
A foto dos "mosqueteiros" que foram ao encontro está abaixo:
Da esquerda para a direita: Eduardo Bobsin Machado (da Human Mobile), Juan Bernabo (da Teamware), Flávio Steffens (eu!), Marcos Moraes (da Suryatec) e Robin Dymond (da Innovel).
Estavam presentes dois alunos do curso (agora certificados!), o Juan, o canadense Robin Dymond (instrutor do curso) e eu. Cheguei atrasado, pois precisava buscar a namorada na rodoviária (e ela acabou indo e achou bastante interessante devido a sua área de interesse ser de RH e o Agile ter uma forte presença nessa área). Encontrei o pessoal e pudemos papear (meio em português, meio em inglês para o Robin participar) sobre Agile e até mesmo assuntos banais. Pude conversar com o Robin um pouco e foi bem legal pois ele já trabalhou com sistemas embarcados em hardware, o que me ajudou bastante a entender algumas idéias para aplicar no meu trabalho!
O bacana foi a possibilidade de trocar experiências e lições aprendidas, discutir conceitos, concordar, discordar, fazer networking, enfim. É exatamente o tipo de evento que eu sempre busco organizar!
Portanto, preparem-se os moradores de Porto Alegre e região, pois tentarei organizar estes encontros pelo menos 1x por mês.
A foto dos "mosqueteiros" que foram ao encontro está abaixo:
Da esquerda para a direita: Eduardo Bobsin Machado (da Human Mobile), Juan Bernabo (da Teamware), Flávio Steffens (eu!), Marcos Moraes (da Suryatec) e Robin Dymond (da Innovel).Terça-feira, 10 de Junho de 2008
SCRUM como cultura... e não superficial
É comum a gente encontrar artigos na internet criticando o Agile e até mesmo o próprio SCRUM, em particular. Até mesmo em discussões esse assunto é recorrente. Eu considero que quem critica o SCRUM, na maioria dos casos (vale ressaltar), tem uma visão MUITO superficial do que os processos ágeis sugerem.
Não vou entrar no mérito da discussão destas pessoas. O meu foco é, novamente, mostrar porque é tão difícil de implementar o SCRUM em um ambiente hostil (como eu costumo chamar), como é o caso de um grupo de pesquisa onde os projetos não são vistos como deveriam ser.
Uma das maiores pré-condições para que qualquer processo ágil funcione é: COMUNICAÇÃO. Eu costumo dizer que o SCRUM é mais do que um processo iterativo: é um processo interativo, antes de tudo!
Partindo disso, podemos dizer que o esforço da implantação de agilidade em um lugar onde as interações não acontecem como deveriam, o SCRUM não funcionará corretamente. E é exatamente isso que estou vivendo no meu grupo de pesquisa.
Já cansei de falar de situações onde os coordenadores pegam alguns funcionários, sem me avisar, e alocam em outros projetos. Isso é recorrente, mas é uma das primeiras coisas que pretendemos acabar. Porém, ontem aconteceu algo mais crítico ainda.
Temos que desenvolver um protótipo para logística de ônibus até o início de Junho. Havia sido definido que faríamos uma maquete e um simulador que faria tudo em cima dessa maquete. Dois recursos seriam utilizados, um para desenvolver o "core" do simulador, e outro para desenvolver as aplicações extras.
Estava tudo bem, estávamos avançados até no sistema, inclusive já pensando em questões finais... quando ontem um dos meus coordenadores comenta que iremos utilizar GPS ao invés de simular.
Como assim?! Pois é, fizeram uma mudança enorme de escopo e, claro, não nos consultaram para ver da possibilidade de realizar a mudança. É assim... temos um prazo de menos de um mês e as coisas mudam para uma complexidade x². O simulador morreu. Agora iremos fazer um caso com um ônibus real. Haverá mapeamento, cálculos complexos, recepção de sinais de GPS, envolvimento com hardwares...
Obviamente toda a parte de produção (e os gerentes) foram os últimos a saber. E, claro, cortaram um funcionário e colocaram outro no lugar, sem nos avisar. De novo.
Vendo isso acontecer, de novo, eu me lembro do email que um dos coordenadores me enviou (e que causou aquele meu momento de raiva, há algum tempo atrás) e pego um trecho do email que tem muito a ver com isso:
Coloquei em negrito alguns trechos mais "interessantes" para mostrar a realidade: os coordenadores NÃO percebem que são ELES os maiores culpados disso tudo. Eles realmente NÃO percebem.
SCRUM em ambientes hostis... é um desafio. Eu estou comprando esse desafio. Mas, se não houver um envolvimento e comprometimento de todos, se a visão for superficial e a cultura de agilidade (principalmente COMUNICAÇÃO e INTERAÇÃO) não for absorvida, realmente não me restará outra opção a não ser abandonar o barco. Mudar uma cultura é difícil, eu sei. Só que se eles sequer estiverem dispostos a mudar, daí não tem porque ficar gastando energia a toa.
Não vou entrar no mérito da discussão destas pessoas. O meu foco é, novamente, mostrar porque é tão difícil de implementar o SCRUM em um ambiente hostil (como eu costumo chamar), como é o caso de um grupo de pesquisa onde os projetos não são vistos como deveriam ser.
Uma das maiores pré-condições para que qualquer processo ágil funcione é: COMUNICAÇÃO. Eu costumo dizer que o SCRUM é mais do que um processo iterativo: é um processo interativo, antes de tudo!
Partindo disso, podemos dizer que o esforço da implantação de agilidade em um lugar onde as interações não acontecem como deveriam, o SCRUM não funcionará corretamente. E é exatamente isso que estou vivendo no meu grupo de pesquisa.
Já cansei de falar de situações onde os coordenadores pegam alguns funcionários, sem me avisar, e alocam em outros projetos. Isso é recorrente, mas é uma das primeiras coisas que pretendemos acabar. Porém, ontem aconteceu algo mais crítico ainda.
Temos que desenvolver um protótipo para logística de ônibus até o início de Junho. Havia sido definido que faríamos uma maquete e um simulador que faria tudo em cima dessa maquete. Dois recursos seriam utilizados, um para desenvolver o "core" do simulador, e outro para desenvolver as aplicações extras.
Estava tudo bem, estávamos avançados até no sistema, inclusive já pensando em questões finais... quando ontem um dos meus coordenadores comenta que iremos utilizar GPS ao invés de simular.
Como assim?! Pois é, fizeram uma mudança enorme de escopo e, claro, não nos consultaram para ver da possibilidade de realizar a mudança. É assim... temos um prazo de menos de um mês e as coisas mudam para uma complexidade x². O simulador morreu. Agora iremos fazer um caso com um ônibus real. Haverá mapeamento, cálculos complexos, recepção de sinais de GPS, envolvimento com hardwares...
Obviamente toda a parte de produção (e os gerentes) foram os últimos a saber. E, claro, cortaram um funcionário e colocaram outro no lugar, sem nos avisar. De novo.
Vendo isso acontecer, de novo, eu me lembro do email que um dos coordenadores me enviou (e que causou aquele meu momento de raiva, há algum tempo atrás) e pego um trecho do email que tem muito a ver com isso:
- Nao vi nenhum de voces acompanhando o desenvolvimento disto com o Beltrano e/ou Sicrano (os dois da equipe atual) na ultima semana. Nao adianta simplesmente passar as tarefas para eles e nao acompanhar o desenvolvimento diario delas, assim como as dificuldades que eles estao tendo. Onde esta o scrum?
- Voces como gerente de projetos devem saber como as coisas sao/foram implementadas, pois voces sao a memoria da equipe. Se desenvolvedores saem da equipe, isto, em principio, nao deveria afetar em nada o trabalho em relacao a parte tecnica.
- Sempre falei que qq sistema deveria ser modular e de facil re-adaptacao. O codigo objeto deve ser realizado segundo as metodologias de projeto adequadas para que isto nao ocorra mais. Nao podemos ficar sempre tendo que reaprender codigo de outros. Onde foram para as metodologias de projeto? engenharia de sw?
Coloquei em negrito alguns trechos mais "interessantes" para mostrar a realidade: os coordenadores NÃO percebem que são ELES os maiores culpados disso tudo. Eles realmente NÃO percebem.
SCRUM em ambientes hostis... é um desafio. Eu estou comprando esse desafio. Mas, se não houver um envolvimento e comprometimento de todos, se a visão for superficial e a cultura de agilidade (principalmente COMUNICAÇÃO e INTERAÇÃO) não for absorvida, realmente não me restará outra opção a não ser abandonar o barco. Mudar uma cultura é difícil, eu sei. Só que se eles sequer estiverem dispostos a mudar, daí não tem porque ficar gastando energia a toa.
Segunda-feira, 9 de Junho de 2008
Em algum lugar do Brasil...
Mensagem da listeira "Keylla", na lista E-Plan. Uma realidade não tão distante... para ler e pensar.
Sim, Keylla... TODOS nós já vivemos situações parecidas. Ou não é?
Fui contratada por uma empresa, que não possui um histórico de gerência de projetos, para ajudar a colocar um projeto no trilho. Este projeto já está em andamento há uns 4 anos e já teve várias renegociações de prazos de entrega.
Desde que eu entrei para o projeto obtivemos consideráveis melhorias no seu gerenciamento, entretanto, chegamos em um ponto que tem me deixado sem ação (e me tirado o sono, também).
Este projeto, que é de desenvolvimento de software, tem sofrido com graves problemas técnicos: erros, usabilidade ruim e baixa performance. A cada dia que passa um novo problema surge, gerando um novo retrabalho. Por causa disso, apesar de ter conseguindo inserir um certo nível de planejamento e acompanhamento, confesso estar sem controle sobre o projeto, pois a cada dia precisamos alterar as prioridades das atividades dos membros da equipe para refazer alguma coisa que já estava pronta causando atrasos e mais atrasos.
Em outras palavras, a cada dia que passa novas atividades precisam ser inseridas no projeto, empurrando o final do projeto sempre para mais longe.
Gostaria de saber se alguém já passou por uma situação parecida e quais ações poderiam ser tomadas para gerenciar de forma mais efetiva esses projeto.
Sim, Keylla... TODOS nós já vivemos situações parecidas. Ou não é?
Terça-feira, 3 de Junho de 2008
SCRUM "aways visible" ou também chamado de "low-tech" :)
Uma pergunta bem interessante levantada pelo colega Ronan, na lista "SCRUM-BRASIL".
Eu sou meio contra utilizar o SCRUM com alguma ferramenta computacional. O legal do SCRUM é o fato de promover a iNteração entra as pessoas. Uma ferramenta computacional já é um passo para começar a voltar ao bom e velho método da comunicação pela internet/rede.
Se alguém quiser adotar alguma ferramenta, eu sugiro que seja apenas para você mesmo. Ou seja, crie uma planilha para fazer um tracking do andamento, levantar métricas para usar nos planejamentos, anotar lições aprendidas para posteriormente divulgar... enfim. Evite ao máximo fazer com que sua equipe tenha que diariamente acessar algum sistema para ler/entrar com alguma informação ou dado. Dependendo do local onde você trabalha, esse tipo de coisa tende a começar a ceder em menos de duas semanas.
Para a organização do seu backlog, utilize as index cards. Eu já postei um exemplo aqui, mas novamente eis uma imagem de exemplo de uma index card:
Baixe aqui
Eu utilizo exatamente esse index card. Com o tempo, vamos adequar ao que precisamos. Mas é possível manter um histórico de tudo, saber o "Definition of Done" de cada atividade e também alterar estimativas e prioridades.
Enfim. Seja bem cético quanto a usar programas para "controlar" o seu dia-a-dia no SCRUM. Normalmente as pessoas tendem a deixá-los de lado. Use uma boa e velha taskboard para criar o conceito de "Always visible" :)
Abraços
Como vocês costumam administrar os Backlogs?
Pergunto isso porque o quadro branco "armazena" apenas as tarefas da Sprint atual, certo? Mas como gerenciar as estórias pedentes e suas prioridades/estimativas?
Sei que existem ferramentas como o ScrumWorks, mas queria saber como a comunidade "costuma" de fato gerenciar isto.
Estou pensando em desenvolver essa funcionalidade no sistema da empresa.
Eu sou meio contra utilizar o SCRUM com alguma ferramenta computacional. O legal do SCRUM é o fato de promover a iNteração entra as pessoas. Uma ferramenta computacional já é um passo para começar a voltar ao bom e velho método da comunicação pela internet/rede.
Se alguém quiser adotar alguma ferramenta, eu sugiro que seja apenas para você mesmo. Ou seja, crie uma planilha para fazer um tracking do andamento, levantar métricas para usar nos planejamentos, anotar lições aprendidas para posteriormente divulgar... enfim. Evite ao máximo fazer com que sua equipe tenha que diariamente acessar algum sistema para ler/entrar com alguma informação ou dado. Dependendo do local onde você trabalha, esse tipo de coisa tende a começar a ceder em menos de duas semanas.
Para a organização do seu backlog, utilize as index cards. Eu já postei um exemplo aqui, mas novamente eis uma imagem de exemplo de uma index card:
Baixe aqui
Eu utilizo exatamente esse index card. Com o tempo, vamos adequar ao que precisamos. Mas é possível manter um histórico de tudo, saber o "Definition of Done" de cada atividade e também alterar estimativas e prioridades.
Enfim. Seja bem cético quanto a usar programas para "controlar" o seu dia-a-dia no SCRUM. Normalmente as pessoas tendem a deixá-los de lado. Use uma boa e velha taskboard para criar o conceito de "Always visible" :)
Abraços
Sexta-feira, 30 de Maio de 2008
Transformando um problema em uma oportunidade
Não consegui falar com o meu chefe a respeito daquele email que ele havia enviado. Ele acabou viajando e só vai retornar na outra semana.
Porém, resolvi transformar esse problema em uma oportunidade para implantar uma mudança que já estou há algum tempo querendo realizar: reestruturação do fluxo da comunicação.
Ficou bastante evidente que ele, como chefe, estava tendo uma percepção totalmente errada do que eu e o meu colega fazemos aqui. Ao mesmo tempo, ficou evidente que ele não contextualiza as coisas, ou seja, não percebe que boa parte das nossas dificuldades decorrem da falta de organização e de comunicação DELES próprios.
Coisas que eles fazem como: solicitar demandas/pegar funcionários para outros projetos sem nos avisar, jogar demandas e (alguns) projetos no nosso colo com um deadline para ontem, falta de paciência para planejamentos e reuniões, recursos (humanos e de infra) insuficientes na maioria das vezes...
Mas não quero ficar de milongas aqui, chorando por todas essas dificuldades. Se eu perdesse tempo tentando rebater tudo isso, só causaria mais atrito e conflitos. Então ontem tomei a decisão de usar esse fato do email, para apresentar a nossa proposta de remodelação de alguns processos de comunicação seja na empresa, seja no laboratório.
Iremos, primeiro, definir os canais de comunicação. Eu já havia comentado isso em um post anterior, mas novamente, a idéia é usar algo similar a isso:
CLIENTES / PRODUCT OWNERS / DIRETORIA <--> GERENTES / SCRUM MASTERS <--> EQUIPES
Esse fluxo mostra que os gerentes/SM deverão ter TOTAL visão e informação das decisões. Não poderá ocorrer uma comunicação (solicitação de demandas, etc) diretamente para as equipes, sem passar por nós. Isso deve ser bem pontual.
Em contra-partida, iremos exigir que realmente nós, como gerentes/SM, tenhamos autonomia para tomar decisões de nível tático, inclusive se for necessário excluir pessoas da equipe. E iremos só levar os problemas com propostas de solução, para a diretoria, quando for algo estratégico.
Também, semanalmente, iremos emitir um relatório sobre os projetos/alocações/status/etc para a diretoria. Dessa forma, eles terão total capacidade para saber o que está acontecendo. O desafio será criar um status report simples e objetivo, que não seja maior do que 2 folhas (contendo todos os projetos) e que o conteúdo, por item, não supere 2 linhas. Assim a gente garante que os diretores poderão ler sem perder tempo demais (posso dizer que esse mesmo chefe que me enviou o email, não leria um status report grande).
Sim, estou trazendo um pouco de burocracia para o SCRUM. Mas vejo isso como uma necessidade para o nosso ambiente, e também como uma forma de nos cercarmos de todas garantias para evitar que novas percepções erradas surjam e gerem "emails inesejáveis". E teremos documentos ESCRITOS para evitar os "disse-que-disse".
Enfim, o email apenas mostrou que a falta de comunicação não é ruim só para os projetos. É ruim também para nós, gerentes/SM, que temos que não só realizar nosso trabalho, mas também temos que MOSTRAR que estamos realizando nosso trabalho.
Vamos ver o que acontece. Quando eu tiver o modelo do status report, eu posto aqui para quem quiser.
Abraços!
Porém, resolvi transformar esse problema em uma oportunidade para implantar uma mudança que já estou há algum tempo querendo realizar: reestruturação do fluxo da comunicação.
Ficou bastante evidente que ele, como chefe, estava tendo uma percepção totalmente errada do que eu e o meu colega fazemos aqui. Ao mesmo tempo, ficou evidente que ele não contextualiza as coisas, ou seja, não percebe que boa parte das nossas dificuldades decorrem da falta de organização e de comunicação DELES próprios.
Coisas que eles fazem como: solicitar demandas/pegar funcionários para outros projetos sem nos avisar, jogar demandas e (alguns) projetos no nosso colo com um deadline para ontem, falta de paciência para planejamentos e reuniões, recursos (humanos e de infra) insuficientes na maioria das vezes...
Mas não quero ficar de milongas aqui, chorando por todas essas dificuldades. Se eu perdesse tempo tentando rebater tudo isso, só causaria mais atrito e conflitos. Então ontem tomei a decisão de usar esse fato do email, para apresentar a nossa proposta de remodelação de alguns processos de comunicação seja na empresa, seja no laboratório.
Iremos, primeiro, definir os canais de comunicação. Eu já havia comentado isso em um post anterior, mas novamente, a idéia é usar algo similar a isso:
CLIENTES / PRODUCT OWNERS / DIRETORIA <--> GERENTES / SCRUM MASTERS <--> EQUIPES
Esse fluxo mostra que os gerentes/SM deverão ter TOTAL visão e informação das decisões. Não poderá ocorrer uma comunicação (solicitação de demandas, etc) diretamente para as equipes, sem passar por nós. Isso deve ser bem pontual.
Em contra-partida, iremos exigir que realmente nós, como gerentes/SM, tenhamos autonomia para tomar decisões de nível tático, inclusive se for necessário excluir pessoas da equipe. E iremos só levar os problemas com propostas de solução, para a diretoria, quando for algo estratégico.
Também, semanalmente, iremos emitir um relatório sobre os projetos/alocações/status/etc para a diretoria. Dessa forma, eles terão total capacidade para saber o que está acontecendo. O desafio será criar um status report simples e objetivo, que não seja maior do que 2 folhas (contendo todos os projetos) e que o conteúdo, por item, não supere 2 linhas. Assim a gente garante que os diretores poderão ler sem perder tempo demais (posso dizer que esse mesmo chefe que me enviou o email, não leria um status report grande).
Sim, estou trazendo um pouco de burocracia para o SCRUM. Mas vejo isso como uma necessidade para o nosso ambiente, e também como uma forma de nos cercarmos de todas garantias para evitar que novas percepções erradas surjam e gerem "emails inesejáveis". E teremos documentos ESCRITOS para evitar os "disse-que-disse".
Enfim, o email apenas mostrou que a falta de comunicação não é ruim só para os projetos. É ruim também para nós, gerentes/SM, que temos que não só realizar nosso trabalho, mas também temos que MOSTRAR que estamos realizando nosso trabalho.
Vamos ver o que acontece. Quando eu tiver o modelo do status report, eu posto aqui para quem quiser.
Abraços!
Quarta-feira, 28 de Maio de 2008
E o SCRUM? Tá vivo, sim senhor!
Apesar dos meus últimos posts não terem a ver com SCRUM, podem ter certeza que está tudo ativo ainda :)
O meu projeto segue com o SCRUM (ontem tivemos uma reunião para definir o sprint, mas por motivo de tempo a reunião durou 20 min hehe) e hoje eles devem já ter começado.
Com o novo projeto aprovado, agora sim poderei fazer um SCRUM desde o começo com a equipe. E isso vai ser bacana, já que poderei aplicar o ciclo completo e não apenas usar o SCRUM como bombeiro.
Hoje eu passei o dia fora em um seminário sobre energia termoelétricas. Minha empresa pensou que pudesse haver algum interesse nessas provedoras de energia a respeito das nossas soluções, mas não, tudo o que foi apresentado é fora do nosso contexto. Enfim, um dia perdido, mas que foi interessante para conhecer a estrutura da FIERGS, aqui em Porto Alegre. Fiquei impressionado.
O meu projeto segue com o SCRUM (ontem tivemos uma reunião para definir o sprint, mas por motivo de tempo a reunião durou 20 min hehe) e hoje eles devem já ter começado.
Com o novo projeto aprovado, agora sim poderei fazer um SCRUM desde o começo com a equipe. E isso vai ser bacana, já que poderei aplicar o ciclo completo e não apenas usar o SCRUM como bombeiro.
Hoje eu passei o dia fora em um seminário sobre energia termoelétricas. Minha empresa pensou que pudesse haver algum interesse nessas provedoras de energia a respeito das nossas soluções, mas não, tudo o que foi apresentado é fora do nosso contexto. Enfim, um dia perdido, mas que foi interessante para conhecer a estrutura da FIERGS, aqui em Porto Alegre. Fiquei impressionado.
Quarta-feira, 21 de Maio de 2008
Dinâmica na turma de gerenciamento de projetos
Hoje apliquei aquela conhecida dinâmica da fábrica de aviões na turma de gerenciamento de projetos, da faculdade.
A grande dificuldade foi adaptar a dinâmica, inicialmente orientada para DOIS grupos, para uma nova realidade com OITO grupos. Na prática, já que alguns alunos não foram na aula, foram "só" SEIS grupos, mas ainda assim a coisa foi complicada.
Eu tentei mudar um pouco o escopo, acrescentando "barcos de papel" na dinâmica. O resultado foi interessante, mas causou mais cansaço nos participantes. Acho que o ideal é manter ou avião ou barco, não os dois.
Dessa vez eu também organizei uma apresentação dos protótipos de cada equipe, o que foi o ponto alto da dinâmica: todos se divertiram e deram boas risadas. No fim, eu dei o feedback como cliente, e novamente nos divertimos mais.
Por questões do tempo, as 6 sprints previstas ficaram reduzidas as 4. Apesar de tudo ser "jogo rápido", a confusão entre as sprints (contagem de produção, reorganização do 'caos', etc) acaba tomando todo o tempo que eu não queria.
Acredito que foi uma dinâmica bacana. A maioria pegou a essência da coisa: trabalho em equipe, melhoria contínua, motivação, etc. A dinâmica precisa ser melhor adaptada para grupos maiores, de repente com tempos menores ainda.
Vamos ver se teremos novos agilistas saindo daquela turma... :)
Abraços!
A grande dificuldade foi adaptar a dinâmica, inicialmente orientada para DOIS grupos, para uma nova realidade com OITO grupos. Na prática, já que alguns alunos não foram na aula, foram "só" SEIS grupos, mas ainda assim a coisa foi complicada.
Eu tentei mudar um pouco o escopo, acrescentando "barcos de papel" na dinâmica. O resultado foi interessante, mas causou mais cansaço nos participantes. Acho que o ideal é manter ou avião ou barco, não os dois.
Dessa vez eu também organizei uma apresentação dos protótipos de cada equipe, o que foi o ponto alto da dinâmica: todos se divertiram e deram boas risadas. No fim, eu dei o feedback como cliente, e novamente nos divertimos mais.
Por questões do tempo, as 6 sprints previstas ficaram reduzidas as 4. Apesar de tudo ser "jogo rápido", a confusão entre as sprints (contagem de produção, reorganização do 'caos', etc) acaba tomando todo o tempo que eu não queria.
Acredito que foi uma dinâmica bacana. A maioria pegou a essência da coisa: trabalho em equipe, melhoria contínua, motivação, etc. A dinâmica precisa ser melhor adaptada para grupos maiores, de repente com tempos menores ainda.
Vamos ver se teremos novos agilistas saindo daquela turma... :)
Abraços!
Sexta-feira, 16 de Maio de 2008
Burndown - como eu utilizo
Uma das ferramentas do SCRUM mais legais e mais motivadoras, é o gráfico de Burndown.
O gráfico de Burndown é uma forma visual e rápida de enxergar o status atual do projeto. Ele possui uma estrutura simples, onde:
- Eixo X: representa os dias do sprint
- Eixo Y: representa o trabalho restante
O trabalho restante pode ser definido de acordo com a sua necessidade. Algumas pessoas utilizam pontos, algumas pessoas utilizam horas, outros dias e assim por diante. O uso com pontos, geralmente ocorre com a atualização do gráfico apenas quando uma user story é finalizada. Ou seja, teoricamente teremos um gráfico cuja linha será horizontal até a finalização de uma tarefa, algo mais ou menos com está apresentado abaixo:
Notem que dessa forma o gráfico é facilmente atualizado, mas não representa uma visão de curto prazo. Já com a utilização de métricas baseadas nas tarefas, conseguimos um resultado mais real do atual status do projeto. O gráfico irá representar, diariamente, se as horas/dias/task stories foram vencidas ou não. E ainda poderá apresentar um acréscimo de horas, quando surgirem tarefas não-planejadas. O gráfico ficaria mais ou menos assim:
Notem que temos uma visão mais de curto prazo, o que torna o gráfico mais interessante para visualização. A dificuldade, neste caso, é mantê-lo atualizado sempre, pois basta um dia perdido, e você se perderá na hora de atualizá-lo novamente.
Como eu disse, existem várias formas de medir o trabalho restante: horas, dias, user stories e até mesmo task points. Isso vai muito da vontade de cada um de estimar as tarefas de cada user story. Só não recomendo o uso de "task points" pois é realmente uma perda absurda de tempo para isso!
Eu tentei estimar as tarefas. Porém comecei a ver que estávamos já andando para o "micromanagement", ou seja, estávamos perdendo tempo estimando um esforço que não seria necessário. Por quê? Pois utilizamos o conceito de ONE-DAY TASK, ou seja, as tarefas devem ter no máximo 1 dia de duração. Para facilitar, pensamos em tarefas que durem MEIO-DIA ou UM DIA.
Pensando dessa forma, qual seria a necessidade de perder tempo setando que a tarefa A tem 4 horas (meio-dia) e a tarefa B tem 8 horas (um dia, não considerando "horas trabalhadas")? Vocês concordam que seria bastante complicado ficar atualizando o gráfico assim?
- "Pessoal, vamos atualizar nosso Burndown. Faltavam 84 horas ontem. Hoje matamos as tarefas A, B e C. A tarefa A tinha 4 horas, a B e a C 8 horas. Portanto temos que descontar 12 horas".
Parece mais uma daquelas "historinhas matemáticas" que tínhamos que resolver no colégio.
Ao invés disso, resolvemos simplificar lá no trabalho. Agora nós apenas CONTAMOS as tarefas. Se temos 20 tarefas, então temos 20 "pontos" para vencer. Se uma tarefa não-planejada surgir, então acrescentamos 1 "ponto" ao gráfico.
Muitos afirmam que isso é inútil. Afinal, se for para contar apenas as tarefas, basta olhar para a taskboard e ter essa visão. Pode ser. Mas sinceramente, eu já percebi que o Burndown tem uma característica única: ele é um agente motivador!
TODOS os meus subordinados, quando falei que voltaríamos a usar o SCRUM, pediram para voltarmos a usar o burndown. Durante a palestra que eu dei para aquela turma de GP, a grande maioria concordou que olhariam primeiro para o burndown para depois olharem as tarefas.
Esta é, portanto, a minha maneira de utilizar o burndown. Ele não representa pontos nem horas, pois não perdemos muito tempo estimando as tarefas. O burndown, para nós, é apenas um agente motivador. Uma ferramenta visual para agilizar e motivar o grupo a cumprir as tarefas.
Eu sinceramente não acredito em certo e errado em qualquer metodologia. Eu acredito em aplicar as ferramentas de acordo com a sua realidade e necessidade. E por isso, posso afirmar que o burndown dessa forma não só resolve nosso problema, como também é um agente motivador.
Abraços!
O gráfico de Burndown é uma forma visual e rápida de enxergar o status atual do projeto. Ele possui uma estrutura simples, onde:
- Eixo X: representa os dias do sprint
- Eixo Y: representa o trabalho restante
O trabalho restante pode ser definido de acordo com a sua necessidade. Algumas pessoas utilizam pontos, algumas pessoas utilizam horas, outros dias e assim por diante. O uso com pontos, geralmente ocorre com a atualização do gráfico apenas quando uma user story é finalizada. Ou seja, teoricamente teremos um gráfico cuja linha será horizontal até a finalização de uma tarefa, algo mais ou menos com está apresentado abaixo:
Notem que dessa forma o gráfico é facilmente atualizado, mas não representa uma visão de curto prazo. Já com a utilização de métricas baseadas nas tarefas, conseguimos um resultado mais real do atual status do projeto. O gráfico irá representar, diariamente, se as horas/dias/task stories foram vencidas ou não. E ainda poderá apresentar um acréscimo de horas, quando surgirem tarefas não-planejadas. O gráfico ficaria mais ou menos assim:
Notem que temos uma visão mais de curto prazo, o que torna o gráfico mais interessante para visualização. A dificuldade, neste caso, é mantê-lo atualizado sempre, pois basta um dia perdido, e você se perderá na hora de atualizá-lo novamente.
Como eu disse, existem várias formas de medir o trabalho restante: horas, dias, user stories e até mesmo task points. Isso vai muito da vontade de cada um de estimar as tarefas de cada user story. Só não recomendo o uso de "task points" pois é realmente uma perda absurda de tempo para isso!
Eu tentei estimar as tarefas. Porém comecei a ver que estávamos já andando para o "micromanagement", ou seja, estávamos perdendo tempo estimando um esforço que não seria necessário. Por quê? Pois utilizamos o conceito de ONE-DAY TASK, ou seja, as tarefas devem ter no máximo 1 dia de duração. Para facilitar, pensamos em tarefas que durem MEIO-DIA ou UM DIA.
Pensando dessa forma, qual seria a necessidade de perder tempo setando que a tarefa A tem 4 horas (meio-dia) e a tarefa B tem 8 horas (um dia, não considerando "horas trabalhadas")? Vocês concordam que seria bastante complicado ficar atualizando o gráfico assim?
- "Pessoal, vamos atualizar nosso Burndown. Faltavam 84 horas ontem. Hoje matamos as tarefas A, B e C. A tarefa A tinha 4 horas, a B e a C 8 horas. Portanto temos que descontar 12 horas".
Parece mais uma daquelas "historinhas matemáticas" que tínhamos que resolver no colégio.
Ao invés disso, resolvemos simplificar lá no trabalho. Agora nós apenas CONTAMOS as tarefas. Se temos 20 tarefas, então temos 20 "pontos" para vencer. Se uma tarefa não-planejada surgir, então acrescentamos 1 "ponto" ao gráfico.
Muitos afirmam que isso é inútil. Afinal, se for para contar apenas as tarefas, basta olhar para a taskboard e ter essa visão. Pode ser. Mas sinceramente, eu já percebi que o Burndown tem uma característica única: ele é um agente motivador!
TODOS os meus subordinados, quando falei que voltaríamos a usar o SCRUM, pediram para voltarmos a usar o burndown. Durante a palestra que eu dei para aquela turma de GP, a grande maioria concordou que olhariam primeiro para o burndown para depois olharem as tarefas.
Esta é, portanto, a minha maneira de utilizar o burndown. Ele não representa pontos nem horas, pois não perdemos muito tempo estimando as tarefas. O burndown, para nós, é apenas um agente motivador. Uma ferramenta visual para agilizar e motivar o grupo a cumprir as tarefas.
Eu sinceramente não acredito em certo e errado em qualquer metodologia. Eu acredito em aplicar as ferramentas de acordo com a sua realidade e necessidade. E por isso, posso afirmar que o burndown dessa forma não só resolve nosso problema, como também é um agente motivador.
Abraços!
Quarta-feira, 14 de Maio de 2008
Sobre cursos, palestras, blog...
Pelo visto, estou me tornando um "disseminador" de Agile. :)
Isso é muito bacana. Sempre é legal disseminar lições e experiências. Mas eu tenho os pés no chão.
Certa vez escutando um podcast do Ricardo Viana Vargas, um dos maiores nomes de gerenciamento de projetos no Brasil, ele falou uma coisa que eu sigo ao pé da letra: "Não tente vender aquilo que você não sabe".
Se formos ver, isso é corretíssimo. Uma pena que existam pessoas que fazem isso... uma pena para a própria pessoa, pois normalmente ela é desmascarada logo de cara.
Nas palestras e "workshops internos" que eu tenho feito, eu sempre deixo claro que estou apresentando a minha visão de agile, baseado nas minhas experiências e aprendizados (seja na prática, seja na teoria, seja nas discussões nas listas). Mas eu NUNCA tento me passar por "mago" ou o "bambambam" do SCRUM.
O meu próprio blog foi feito com o intuito de divulgar as minhas experiências, mostrar que ser gerente de projetos (iniciante - quando eu comecei o blog) e em ambientes "hostis" (pesquisa, micro e pequenas empresas) não é um bicho de sete cabeças. É difícil, sim. Mas a gente aprende... com erros e acertos.
Eu sigo essa filosofia. Exponho a minha vivência, a minha visão. Não pretendo nunca ser um xiita e dizer que "tenho a fórmula mágica para a solução dos seus problemas!".
Fico feliz em receber feedback de leitores, felizes com as experiências que eu exponho aqui. Mas tenham isso em mente: o que eu faço não é certo nem errado. É apenas a minha interpretação de agile, baseado no meu ambiente de trabalho.
Fuja de formulismos, e busque você também moldar o agile conforme as suas necessidades e situação.
Um abraço!
Isso é muito bacana. Sempre é legal disseminar lições e experiências. Mas eu tenho os pés no chão.
Certa vez escutando um podcast do Ricardo Viana Vargas, um dos maiores nomes de gerenciamento de projetos no Brasil, ele falou uma coisa que eu sigo ao pé da letra: "Não tente vender aquilo que você não sabe".
Se formos ver, isso é corretíssimo. Uma pena que existam pessoas que fazem isso... uma pena para a própria pessoa, pois normalmente ela é desmascarada logo de cara.
Nas palestras e "workshops internos" que eu tenho feito, eu sempre deixo claro que estou apresentando a minha visão de agile, baseado nas minhas experiências e aprendizados (seja na prática, seja na teoria, seja nas discussões nas listas). Mas eu NUNCA tento me passar por "mago" ou o "bambambam" do SCRUM.
O meu próprio blog foi feito com o intuito de divulgar as minhas experiências, mostrar que ser gerente de projetos (iniciante - quando eu comecei o blog) e em ambientes "hostis" (pesquisa, micro e pequenas empresas) não é um bicho de sete cabeças. É difícil, sim. Mas a gente aprende... com erros e acertos.
Eu sigo essa filosofia. Exponho a minha vivência, a minha visão. Não pretendo nunca ser um xiita e dizer que "tenho a fórmula mágica para a solução dos seus problemas!".
Fico feliz em receber feedback de leitores, felizes com as experiências que eu exponho aqui. Mas tenham isso em mente: o que eu faço não é certo nem errado. É apenas a minha interpretação de agile, baseado no meu ambiente de trabalho.
Fuja de formulismos, e busque você também moldar o agile conforme as suas necessidades e situação.
Um abraço!
Palestra de SCRUM para turma de gerenciamento de projetos - II
Hoje, terça-feira, dei a palestra para o pessoal.
Confesso que estava um pouco ansioso no começo, afinal, será que conseguirei apresentar algo que muitos não conhecem, da forma correta? Eu costumo perceber que algumas vezes atropelo enquanto falo. Então tenho que me cuidar nas palestras para não atropelar.
Passei o dia preparando a apresentação, quando sobrava um tempo no trabalho. Eu queria ter tido a oportunidade de falar de diversas coisas, além do SCRUM, como comunicação, organizações, etc. Havia preparado uma apresentação com 60 slides, um número bem alto, mas que continham na maioria imagens para ilustrar.
Então, faltando 1 hora para a apresentação, resolvi ensaiar. Passada 1h20 do ensaio, eu percebi que ainda faltava coisa para acabar! Bateu o desespero!! Precisava reduzir drasticamente o número de slides e assuntos abordados. Fiz isso. Porém, isso me deixou um pouco inseguro, mas eu estaria alterando o meu plano... teria que improvisar um pouco. Mas nada que me preocupasse demais, pois é um assunto que eu me sinto à vontade para falar e expôr.
Testei o Powerpoint pelo menos umas dez vezes para ver se tudo funcionava (ainda mais os multimidias). Tudo ok. Pelo ensaio eu percebi que precisaria de bastante água, pois falar mais de uma hora é algo que deixa a garganta seca! hehe
Me encontrei com o professor substituto que me acompanharia na aula e fomos para a sala. Conversamos um pouco eu, ele e um mestrando dele, que também tinha interesse em metodologias ágeis e iria acompanhar a palestra. Foi uma conversa bacana, pois pudemos ver como todos nós praticamos um pouco dos conceitos de agile, mesmo sem perceber que é agile.
O professor comentou, num momento, que havia solicitado para um subordinado que ele realizasse por um período a seguinte agenda: chegar no trabalho, checar emails ou fazer algumas de suas coisas, e passar o resto do dia se comunicando com o pessoal. O subordinado reclamou: "O que? Mas eu vou acabar ficando sem fazer nada!!". No terceiro dia, ele já reclamava: "Poxa, eu não tenho tempo para fazer quase nada! Não sabia que haviam tantos problemas a serem resolvidos". Mais uma prova de que a COMUNICAÇÃO e as RELAÇÕES HUMANAS são os dois fatores mais importantes em um projeto.
Quando entrei na aula, de aproximadamente 40 alunos, haviam uns 5. Fiquei meio preocupado... "Será que o fato de não ser uma aula, ainda com um professor substituto e um palestrante de fora, o pessoal não vai matar a aula? Ainda mais iniciando às 21h?". Eram 21h já... e ao que parecia, seria mais um workshop do que uma palestra.
Por volta das 21h15 o pessoal começou a chegar e a sala encheu. Acho que deveriam ter umas 40 pessoas, mesmo. Mas o tempo ficou mais curto (ainda bem que reduzi a palestra a tempo!). Não perdi tempo e iniciei.
Usei basicamente o mesmo modelo daquela palestra que postei anteriormente (na dinâmica de SCRUM cujo link está ali do lado). Mas acrescentei algumas coisas interessantes para dar mais agilidade à palestra... sendo de noite, precisava colocar mais pontos de interação com o pessoal.
O link para baixar a apresentação é aqui.
Logo no início já fizemos aquele levantamento dos problemas que ocorrem nas empresas de TI. Todos os citados se encaixavam na tríade de causas "PESSOAS" "CLIENTES/STAKEHOLDERS" "PROCESSOS".
Em seguida, apresentei para eles um clipe que eu retirei do episódio 12 da 6a temporada do Aprendiz com Donald Trump. O vídeo mostrava 3 duplas que deveriam fazer uma campanha de marketing e vendas de um empreendimento do Trump. E o resultado foi que uma equipe encantou ele, outra fez uma coisa meia-boca, mas que pecaram fatalmente num item (telefone de contato errado no folder!!) e a outra dupla foi um desastre total.
O vídeo pode ser baixado aqui.
Analisamos então o que aconteceu com cada uma das equipes. E por fim, concluimos que a equipe vencedora havia trabalhado em equipe, se comunicado corretamente, estavam motivados e confiantes... e que, sem querer, eles usaram praticamente o conceito do AGILE!
Aí começa a palestra com toda a explicação sobre Agile e SCRUM. Todo o ciclo de vida... e é a parte mais "tensa" da palestra, pois ai sim vira um monólogo. Mesmo eu tentando interagir um pouco com o pessoal, eu noto que é difícil mantê-los atentos e interessados até o fim. Mas consegui levar bem, acredito eu.
Quando chegamos nas estimativas, em Planning Poker, eu fiz uma dinâmica que eu considerei bem divertida: escolhi 3 voluntários ("escolher voluntários" faz parte da brincadeira hehe) e dei para cada um jogo de cartas (metade de folhas A4) com alguns pontos em Fibonacci. 3-5-8-13-21.
A dinâmica consistia em: eu falaria o nome de um país, e eles deveriam estimar o tamanho do país em extensão territorial, sendo 3 para países pequenos e 21 para países grandes. Escolhi países que eu achei que eles não fossem saber ao certo.
Dividi em 2 países em 2 rodadas. A grande sacada aqui era a seguinte: na primeira rodada, eu iria INFLUENCIAR o resultado. Então os países eram Tunísia e Mongólia. Eu tentei induzí-los ao erro falando: "Estimem então a Tunísia, um dos maiores países da África". Eles começaram a rir, mas o resultado saiu que cada um colocou uma coisa diferente. Dai discutimos porque do maior e o menor valor e fizemos outra rodada. Para a Mongólia, eu induzi eles falando: "A Mongólia que é um pequeno país na Ásia oriental". Mas um aluno lá no fundo da aula já falou "Mas a Mongólia é um país grande!!". hehehe Tive que tentar manter o foco, fingindo que era um país pequeno.
Na segunda rodada, eu apenas falava o nome dos países. Marrocos e Chile. Para minha surpresa, aqui houve quase consenso nos dois casos. Talvez porque eu tenha usado países que são teoricamente conhecidos (da próxima vez vou pegar uns mais malucos!).
Aplaudimos os voluntários e perguntei a eles se eles notaram o motivo de eu ter feito duas rodadas. Após algumas respostas, um matou a charada: "Tu induziu eles à responderem!".
Expliquei então das vantagens do Planning Poker: tornar o ambiente de estimativa algo divertido, como foi a dinâmica. Facilitar a discussão das estimativas e evitar que ocorra influência de uma pessoa, já que todos estimam ao mesmo tempo.
Continuei então a palestra, aqui notei que o pessoal já estava mais ativo novamente. Chegamos então para explicar a Sprint Review. Falei de como deveria ser, alguns conceitos interessantes para serem aplicados... e quando mencionei que o Sprint Review evita os 99%, apresentei outro vídeo divertido que era uma propaganda da EDS. Mostra um avião sendo construido no ar.
O vídeo pode ser baixado aqui.
Continuando, finalizei a palestra e entrei nas conclusões. Aqui o pessoal já estava se mexendo na cadeira para sair... normal, já eram 22h30 e mesmo que o assunto seja o mais interessante possível, todos já estão cansados.
Aproveitei o último slide para mostrar uma "receita para aplicar SCRUM" na sua empresa. A idéia era me contradizer, pois no início da palestra eu havia dito que não havia fórmula mágica para nada, nem receita de bolo.
Mas a minha receita para quem quer começar a introduzir o conceito do Agile/SCRUM na sua empresa é:
1) Introduza as daily meetings
2) Crie um product backlog do seu projeto
3) Crie o conceito de "time box"
4) Crie uma taskboard
5) Faça uma retrospectiva
Eu tenho a convicção, pela experiência que eu tenho, que se você colocar esses conceitos em prática na sua empresa, você começará a ver resultados em pouco tempo. Você pode não estar aplicando o SCRUM propriamente dito, mas estará maximizando a comunicação e, principalmente, introduzindo um processo simples e prático de gerenciamento.
Finalizei a palestra falando da dinâmica que faremos na 3a-feira que vem, que eu acredito que será muito divertida. Aprenderemos muitos conceitos de SCRUM na prática, com uma brincadeira. Será uma aula bem diferente, que todos poderão tirar suas lições aprendidas e relaxar.
Ao final da palestra, alguns alunos vieram conversar comigo para tirar dúvidas e bater papo sobre SCRUM. É nesse momento que a gente tem um feedback do pessoal. Pelas pessoas que conversaram comigo, percebi que todos entenderam o conceito do agile. E mais do que isso, viram como é simples e benéfico aplicá-los. Isso é muito bom, eu espero mesmo que todos os alunos na sala apliquem pelo menos um dos itens que eu citei acima, e comece a perceber como uma simples mudança de processo/atitude, resulta em grandes resultados.
Dois alunos me falaram uma coisa que eu achei que valeu pela palestra. Comentaram que não costumavam ficar até o final da aula, durante o semestre. Mas hoje não só ficaram até o fim, como foram os que sairam comigo conversando e papeando sobre as metodologias ágeis. Esse é um dos melhores elogios que um palestrante pode ter. :)
Fazendo um balanço da experiência, posso dizer que foi muito bacana. Apesar do horário extenso e de alguns momentos de monólogo, consegui segurar a atenção do pessoal por muito tempo. As dinâmicas foram legais e os vídeos deram um ar bem informal e prático à palestra.
Talvez eu deva reduzir um pouco mais a apresentação, de forma a não tornar muito cansativo e extenso. Mas a experiência foi feita e o resultado acredito que tenha sido bom.
Agora notei como vida de professor é difícil. Falar durante 1h30 é cansativo! Sem contar toda a preparação para a apresentação...
Se você é um dos alunos da palestra, por favor, poste aqui seu feedback. Pode ter certeza que isso será de grande valor para mim. Afinal de contas, como eu disse, VALOR é a alma do agile ;) hehe
Arquivos para download:
Apresentação
Vídeo Aprendiz
Vídeo Avião construído no ar
Um grande abraço e até mais! :)
-----------------
PS: O video do Aprendiz eu faço upload no dia 14. Ele tem 100mb...
Confesso que estava um pouco ansioso no começo, afinal, será que conseguirei apresentar algo que muitos não conhecem, da forma correta? Eu costumo perceber que algumas vezes atropelo enquanto falo. Então tenho que me cuidar nas palestras para não atropelar.
Passei o dia preparando a apresentação, quando sobrava um tempo no trabalho. Eu queria ter tido a oportunidade de falar de diversas coisas, além do SCRUM, como comunicação, organizações, etc. Havia preparado uma apresentação com 60 slides, um número bem alto, mas que continham na maioria imagens para ilustrar.
Então, faltando 1 hora para a apresentação, resolvi ensaiar. Passada 1h20 do ensaio, eu percebi que ainda faltava coisa para acabar! Bateu o desespero!! Precisava reduzir drasticamente o número de slides e assuntos abordados. Fiz isso. Porém, isso me deixou um pouco inseguro, mas eu estaria alterando o meu plano... teria que improvisar um pouco. Mas nada que me preocupasse demais, pois é um assunto que eu me sinto à vontade para falar e expôr.
Testei o Powerpoint pelo menos umas dez vezes para ver se tudo funcionava (ainda mais os multimidias). Tudo ok. Pelo ensaio eu percebi que precisaria de bastante água, pois falar mais de uma hora é algo que deixa a garganta seca! hehe
Me encontrei com o professor substituto que me acompanharia na aula e fomos para a sala. Conversamos um pouco eu, ele e um mestrando dele, que também tinha interesse em metodologias ágeis e iria acompanhar a palestra. Foi uma conversa bacana, pois pudemos ver como todos nós praticamos um pouco dos conceitos de agile, mesmo sem perceber que é agile.
O professor comentou, num momento, que havia solicitado para um subordinado que ele realizasse por um período a seguinte agenda: chegar no trabalho, checar emails ou fazer algumas de suas coisas, e passar o resto do dia se comunicando com o pessoal. O subordinado reclamou: "O que? Mas eu vou acabar ficando sem fazer nada!!". No terceiro dia, ele já reclamava: "Poxa, eu não tenho tempo para fazer quase nada! Não sabia que haviam tantos problemas a serem resolvidos". Mais uma prova de que a COMUNICAÇÃO e as RELAÇÕES HUMANAS são os dois fatores mais importantes em um projeto.
Quando entrei na aula, de aproximadamente 40 alunos, haviam uns 5. Fiquei meio preocupado... "Será que o fato de não ser uma aula, ainda com um professor substituto e um palestrante de fora, o pessoal não vai matar a aula? Ainda mais iniciando às 21h?". Eram 21h já... e ao que parecia, seria mais um workshop do que uma palestra.
Por volta das 21h15 o pessoal começou a chegar e a sala encheu. Acho que deveriam ter umas 40 pessoas, mesmo. Mas o tempo ficou mais curto (ainda bem que reduzi a palestra a tempo!). Não perdi tempo e iniciei.
Usei basicamente o mesmo modelo daquela palestra que postei anteriormente (na dinâmica de SCRUM cujo link está ali do lado). Mas acrescentei algumas coisas interessantes para dar mais agilidade à palestra... sendo de noite, precisava colocar mais pontos de interação com o pessoal.
O link para baixar a apresentação é aqui.
Logo no início já fizemos aquele levantamento dos problemas que ocorrem nas empresas de TI. Todos os citados se encaixavam na tríade de causas "PESSOAS" "CLIENTES/STAKEHOLDERS" "PROCESSOS".
Em seguida, apresentei para eles um clipe que eu retirei do episódio 12 da 6a temporada do Aprendiz com Donald Trump. O vídeo mostrava 3 duplas que deveriam fazer uma campanha de marketing e vendas de um empreendimento do Trump. E o resultado foi que uma equipe encantou ele, outra fez uma coisa meia-boca, mas que pecaram fatalmente num item (telefone de contato errado no folder!!) e a outra dupla foi um desastre total.
O vídeo pode ser baixado aqui.
Analisamos então o que aconteceu com cada uma das equipes. E por fim, concluimos que a equipe vencedora havia trabalhado em equipe, se comunicado corretamente, estavam motivados e confiantes... e que, sem querer, eles usaram praticamente o conceito do AGILE!
Aí começa a palestra com toda a explicação sobre Agile e SCRUM. Todo o ciclo de vida... e é a parte mais "tensa" da palestra, pois ai sim vira um monólogo. Mesmo eu tentando interagir um pouco com o pessoal, eu noto que é difícil mantê-los atentos e interessados até o fim. Mas consegui levar bem, acredito eu.
Quando chegamos nas estimativas, em Planning Poker, eu fiz uma dinâmica que eu considerei bem divertida: escolhi 3 voluntários ("escolher voluntários" faz parte da brincadeira hehe) e dei para cada um jogo de cartas (metade de folhas A4) com alguns pontos em Fibonacci. 3-5-8-13-21.
A dinâmica consistia em: eu falaria o nome de um país, e eles deveriam estimar o tamanho do país em extensão territorial, sendo 3 para países pequenos e 21 para países grandes. Escolhi países que eu achei que eles não fossem saber ao certo.
Dividi em 2 países em 2 rodadas. A grande sacada aqui era a seguinte: na primeira rodada, eu iria INFLUENCIAR o resultado. Então os países eram Tunísia e Mongólia. Eu tentei induzí-los ao erro falando: "Estimem então a Tunísia, um dos maiores países da África". Eles começaram a rir, mas o resultado saiu que cada um colocou uma coisa diferente. Dai discutimos porque do maior e o menor valor e fizemos outra rodada. Para a Mongólia, eu induzi eles falando: "A Mongólia que é um pequeno país na Ásia oriental". Mas um aluno lá no fundo da aula já falou "Mas a Mongólia é um país grande!!". hehehe Tive que tentar manter o foco, fingindo que era um país pequeno.
Na segunda rodada, eu apenas falava o nome dos países. Marrocos e Chile. Para minha surpresa, aqui houve quase consenso nos dois casos. Talvez porque eu tenha usado países que são teoricamente conhecidos (da próxima vez vou pegar uns mais malucos!).
Aplaudimos os voluntários e perguntei a eles se eles notaram o motivo de eu ter feito duas rodadas. Após algumas respostas, um matou a charada: "Tu induziu eles à responderem!".
Expliquei então das vantagens do Planning Poker: tornar o ambiente de estimativa algo divertido, como foi a dinâmica. Facilitar a discussão das estimativas e evitar que ocorra influência de uma pessoa, já que todos estimam ao mesmo tempo.
Continuei então a palestra, aqui notei que o pessoal já estava mais ativo novamente. Chegamos então para explicar a Sprint Review. Falei de como deveria ser, alguns conceitos interessantes para serem aplicados... e quando mencionei que o Sprint Review evita os 99%, apresentei outro vídeo divertido que era uma propaganda da EDS. Mostra um avião sendo construido no ar.
O vídeo pode ser baixado aqui.
Continuando, finalizei a palestra e entrei nas conclusões. Aqui o pessoal já estava se mexendo na cadeira para sair... normal, já eram 22h30 e mesmo que o assunto seja o mais interessante possível, todos já estão cansados.
Aproveitei o último slide para mostrar uma "receita para aplicar SCRUM" na sua empresa. A idéia era me contradizer, pois no início da palestra eu havia dito que não havia fórmula mágica para nada, nem receita de bolo.
Mas a minha receita para quem quer começar a introduzir o conceito do Agile/SCRUM na sua empresa é:
1) Introduza as daily meetings
2) Crie um product backlog do seu projeto
3) Crie o conceito de "time box"
4) Crie uma taskboard
5) Faça uma retrospectiva
Eu tenho a convicção, pela experiência que eu tenho, que se você colocar esses conceitos em prática na sua empresa, você começará a ver resultados em pouco tempo. Você pode não estar aplicando o SCRUM propriamente dito, mas estará maximizando a comunicação e, principalmente, introduzindo um processo simples e prático de gerenciamento.
Finalizei a palestra falando da dinâmica que faremos na 3a-feira que vem, que eu acredito que será muito divertida. Aprenderemos muitos conceitos de SCRUM na prática, com uma brincadeira. Será uma aula bem diferente, que todos poderão tirar suas lições aprendidas e relaxar.
Ao final da palestra, alguns alunos vieram conversar comigo para tirar dúvidas e bater papo sobre SCRUM. É nesse momento que a gente tem um feedback do pessoal. Pelas pessoas que conversaram comigo, percebi que todos entenderam o conceito do agile. E mais do que isso, viram como é simples e benéfico aplicá-los. Isso é muito bom, eu espero mesmo que todos os alunos na sala apliquem pelo menos um dos itens que eu citei acima, e comece a perceber como uma simples mudança de processo/atitude, resulta em grandes resultados.
Dois alunos me falaram uma coisa que eu achei que valeu pela palestra. Comentaram que não costumavam ficar até o final da aula, durante o semestre. Mas hoje não só ficaram até o fim, como foram os que sairam comigo conversando e papeando sobre as metodologias ágeis. Esse é um dos melhores elogios que um palestrante pode ter. :)
Fazendo um balanço da experiência, posso dizer que foi muito bacana. Apesar do horário extenso e de alguns momentos de monólogo, consegui segurar a atenção do pessoal por muito tempo. As dinâmicas foram legais e os vídeos deram um ar bem informal e prático à palestra.
Talvez eu deva reduzir um pouco mais a apresentação, de forma a não tornar muito cansativo e extenso. Mas a experiência foi feita e o resultado acredito que tenha sido bom.
Agora notei como vida de professor é difícil. Falar durante 1h30 é cansativo! Sem contar toda a preparação para a apresentação...
Se você é um dos alunos da palestra, por favor, poste aqui seu feedback. Pode ter certeza que isso será de grande valor para mim. Afinal de contas, como eu disse, VALOR é a alma do agile ;) hehe
Arquivos para download:
Apresentação
Vídeo Aprendiz
Vídeo Avião construído no ar
Um grande abraço e até mais! :)
-----------------
PS: O video do Aprendiz eu faço upload no dia 14. Ele tem 100mb...
Segunda-feira, 12 de Maio de 2008
Palestra de SCRUM para turma de gerenciamento de projetos
A convite de meu antigo professor e orientador de trabalho de conclusão, irei fazer uma palestra sobre Metodologias Ágeis (foco SCRUM) para uma turma de gerenciamento de projetos do curso de Sistemas de Informação.
Usarei como base a apresentação que fiz para o pessoal do meu grupo, acrescentando algumas coisas a mais. Será um desafio enfrentar uma turma com quase 50 pessoas. Mas não estou preocupado...
Pretendo deixar a apresentação mais interativa. Ensinar de uma forma mais dinâmica e divertida, ao invés de investir no monólogo. Usarei um vídeo do "Aprendiz 6 com Donald Trump" onde três equipes deveriam fazer uma apresentação e cada uma obtem um resultado diferente: uma faz um excelente trabalho, uma faz um trabalho meia-boca e outra faz um terrível trabalho. Será um ótimo mote para iniciar a discussão sobre os problemas de projetos.
Posteriormente, na semana que vem, voltarei à turma para fazer uma dinâmica.
Espero que muitos alunos vistem o blog e virem leitores assíduos também.
Um abraço!
Usarei como base a apresentação que fiz para o pessoal do meu grupo, acrescentando algumas coisas a mais. Será um desafio enfrentar uma turma com quase 50 pessoas. Mas não estou preocupado...
Pretendo deixar a apresentação mais interativa. Ensinar de uma forma mais dinâmica e divertida, ao invés de investir no monólogo. Usarei um vídeo do "Aprendiz 6 com Donald Trump" onde três equipes deveriam fazer uma apresentação e cada uma obtem um resultado diferente: uma faz um excelente trabalho, uma faz um trabalho meia-boca e outra faz um terrível trabalho. Será um ótimo mote para iniciar a discussão sobre os problemas de projetos.
Posteriormente, na semana que vem, voltarei à turma para fazer uma dinâmica.
Espero que muitos alunos vistem o blog e virem leitores assíduos também.
Um abraço!
Sangue novo no projeto
Hoje tive a reunião "checkpoint" com o pessoal do meu projeto principal. Estamos muito atrasados nas stories para entregar todas até o fim da semana. Expressei essa preocupação com eles, e sugeri excluírmos uma story da sprint backlog.
Para minha surpresa, eles pediram para não tirar. Disseram que vão se esforçar para cumprirmos o prometido. Gostei dessa reação deles. De fato, a pior parte já passou. As tarefas mais empíricas estão finalizadas. Agora é refatoração e correções. Então eles precisarão realmente fazer algumas horas extras para apresentarmos os resultados na próxima segunda. Confesso que sai impressionado com a mudança de postura da equipe. O SCRUM realmente dá uma agitada legal neles. Motiva!
Em seguida, fizemos a reunião com nosso coordenador do projeto. Levantei a possibilidade de escrevermos artigos científicos com base no que estamos desenvolvendo, e todos acharam a idéia ótima, desde que seja feita ao final do projeto. Isso será algo excelente para o currículo pessoal de cada um, para o projeto e para o laboratório. Pesquisa requer produção científica, e é esse um dos focos que pretendo dar aos nossos projetos do laboratório. Eu mesmo escreverei um artigo sobre o SCRUM em um projeto de ambiente universitário. Um case bacana.
Ao final do dia, fui até a livraria da universidade, para comprar uma caneta para mim. Então já que estava lá, resolvi fazer um estoque de suprimentos que volta-e-meia a minha equipe (e as outras) solicitavam: chaves de fenda, chaves phillips, trena métrica, estilete... todos adoraram a surpresa quando eu cheguei.
Pretendo em breve conversar com todos para ver o que mais falta no laboratório. E ao invés de negociar com os coordenadores, apenas comprar e apresentar a nota. Tem horas que a iniciativa conta mais do que os trâmites burocráticos hehe
Um bom dia, no fim das contas.
Abraços
Para minha surpresa, eles pediram para não tirar. Disseram que vão se esforçar para cumprirmos o prometido. Gostei dessa reação deles. De fato, a pior parte já passou. As tarefas mais empíricas estão finalizadas. Agora é refatoração e correções. Então eles precisarão realmente fazer algumas horas extras para apresentarmos os resultados na próxima segunda. Confesso que sai impressionado com a mudança de postura da equipe. O SCRUM realmente dá uma agitada legal neles. Motiva!
Em seguida, fizemos a reunião com nosso coordenador do projeto. Levantei a possibilidade de escrevermos artigos científicos com base no que estamos desenvolvendo, e todos acharam a idéia ótima, desde que seja feita ao final do projeto. Isso será algo excelente para o currículo pessoal de cada um, para o projeto e para o laboratório. Pesquisa requer produção científica, e é esse um dos focos que pretendo dar aos nossos projetos do laboratório. Eu mesmo escreverei um artigo sobre o SCRUM em um projeto de ambiente universitário. Um case bacana.
Ao final do dia, fui até a livraria da universidade, para comprar uma caneta para mim. Então já que estava lá, resolvi fazer um estoque de suprimentos que volta-e-meia a minha equipe (e as outras) solicitavam: chaves de fenda, chaves phillips, trena métrica, estilete... todos adoraram a surpresa quando eu cheguei.
Pretendo em breve conversar com todos para ver o que mais falta no laboratório. E ao invés de negociar com os coordenadores, apenas comprar e apresentar a nota. Tem horas que a iniciativa conta mais do que os trâmites burocráticos hehe
Um bom dia, no fim das contas.
Abraços
Assinar:
Postagens (Atom)
