Quarta feira, 17 horas.
Esse é o horário da reunião mais importante deste ano. Será a reunião onde será decidido como será o nosso próximo projeto. Iremos focar, principalmente, no perfil das equipes. Eles, meus chefes, pretendem mostrar que querem uma mudança radical de atitude das pessoas do laboratório.
Será a minha chance para apresentar a questão da gestão por competências.
O que me deixa meio preocupado é que eles querem mudar... não mudando. Ou seja, vão aproveitar muitos dos que já estão no laboratório e, além disso, querem manter os salários (as bolsas) das pessoas no mesmo nível atual. Daí eu pergunto: se eles realmente querem mudar o perfil, por que agem CONTRA isso?
Mas o ponto mais tenso da reunião será quando falarmos de salários. O salário dos gerentes.
Um dos meus chefes havia me dado a incumbência de fazer o planejamento financeiro de RH do projeto. Eu fiz, prevendo diversas variáveis (inclusive o valor que fica aplicado no banco, gerando rendimentos financeiros). Para o meu salário, peguei a média dos gerente de projetos e taquei ali: R$ 3700,00.
Numa primeira reunião, entre eu, meu colega e meus dois chefes, já houve um princípio de divergência. "Não estão inflacionando o mercado, com este valor?". Eu fui firme: "Não. É o valor de mercado". Deu pra ver que eles não ficaram muito satisfeitos.
No outro dia, marcaram uma nova reunião (essa agora) em que eu e o meu colega estaremos junto com meus dois chefes, mais um coordenador e um diretor da empresa. Ou seja, o cenário está todo armado para que nós façamos uma revisão dos nossos salários.
É claro que eu vou considerar que o ambiente é acadêmico e que a empresa é microempresa. A carga horária também é menor (6h). E quero ouvir deles, quais serão nossas responsabilidades.
Agora, sinceramente, eles também tem que valorizar E MUITO nosso trabalho. Eu e o meu colega recebemos este ano duas ou três tijoladas (projetos incendiários) em que tivemos que agir e recuperá-los. Eu consegui resgatar o meu projeto atual, e o meu colega terminou o dele com antecedência. Temos que lidar com o pessoal do laboratório diariamente, liderando e mantendo a motivação do pessoal. Além disso, eu sou o "escritor oficial" de projetos do laboratório. Sempre que há um edital de projeto, eu sou convocado a auxiliar os meus chefes para escrever. Este que irá começar, de RFID, eu fui o responsável por boa parte do projeto. Também nunca deixamos eles na mão. Sempre fomos integros e honestos. E, por fim, este ano estou fazendo três anos na empresa!
São motivos mais do que de sobra para ter uma remuneração compatível com o mercado. Minha meta é ficar na proximidade de 3000-3200. Abaixo disso, eu já vou pensar muito se fico ou não.
Quero tratar este projeto como meu filho, isso eu já falo há tempos. Irei fazer o possível para entregá-lo em um ano (e alguns meses). Irei me dedicar muito ao projeto. Sei que será um excelente projeto para se ter no currículo, inclusive.
Mas preciso pensar na parte financeira também. Auto-realização não é só fazer o que gosta. É também receber o que se merece.
Enfim. Amanhã é o dia. Vamos ver como estamos cotados lá dentro.
Abraços!
Mostrando postagens com marcador reuniões. Mostrar todas as postagens
Mostrando postagens com marcador reuniões. Mostrar todas as postagens
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
Quinta-feira, 19 de Junho de 2008
Água fria nas idéias... pelo menos por enquanto.
É impressionante o mundo corporativo (seja uma empresa, seja um grupo de pesquisa). Cheguei no trabalho com a idéia que mencionei no post anterior, de tentar criar o conceito de gestão por competências.
Conversando com o meu colega, contei a história da Nissan para expressar a essência deste conceito. Ele achou bacana. Mas nesse momento, fomos interrompidos por um dos meus chefes.
Ele me disse que eles todos estavam em reunião e tiveram algumas decisões:
+ Eles querem equipes bem centradas e experientes, e com isso pode haver uma reformulação total na equipe do laboratório. Pior do que isso, dependendo do que eles entendem por "experientes" podemos ter um acréscimo que não foi previsto na folha de pagamento.
+ Eles simplesmente definiram que um dos meus subordinados atuais faria o papel de gerente de projetos de hardware e analista de processos, nas empresas. OPA! Peraí!! Como é? Eles escolheram a pessoa mais introvertida, entre os que estão ali. Um cara muito técnico com bons conhecimentos, só que não tem na comunicação o seu forte. E querem que ele vire GERENTE? E pior, que ele visite empresas e identifique processos?! Isso me soou de uma insanidade que só demonstra como os responsáveis por essas decisões não conhecem a equipe que tem.
+ O meu colega, analista e que faria a função de gerente, foi nomeado como analista de processos da empresa. Obviamente, ele foi o último a saber. Avisaram ele hoje, sem saber se ele tinha interesse ou não. Pela reação dele, no momento e depois da reunião, notei que ele estava meio puto da cara. Pois sabe que está se metendo numa encrenca daquelas... ele sabe que vai ter que acompanhar o tiroteio da empresa, que ao invés de se focar em uma tecnologia para se especializar e oferecer serviços, está tentando pegar tudo o que pode (projetos espaciais, de RFID, de software, de sistemas embarcados, etc).
+ Eu fui mantido de gerente de projetos do grupo de pesquisa. Aqui foi a notícia boa. Eu pretendo, posteriormente, alcançar posições mais altas (obviamente não será no grupo e nem na empresa que tem uma hierarquia pequena e monolítica), mas nem por isso vou pular degraus. Quero gerenciar mais alguns projetos (este principalmente, que terá um apelo bem interessante) para acumular experiência e me preparar para os novos desafios.
Enfim, novamente houve uma mistura enorme entre empresa e grupo de pesquisa. Eu vou exigir, antes de começar o projeto, que os papéis e responsabilidades estejam BEM DEFINIDOS. Isso significa que não haverá possibilidade de alguém que tem o foco só no grupo, tenha que prestar algum serviço para a empresa. Vou ser bem incisivo nisso. Se eu vou realmente ser do grupo, vou representar o GRUPO e não a empresa.
Apesar dessa reunião ter demonstrado algumas decisões que eu não concordo (como a saida do meu colega contra a vontade dele - aparentemente - para a empresa e a nomeação do gerente de projetos de hardware de uma pessoa sem o perfil) eu ainda acho que consigo transformar o laboratório em um local para a gestão de competências. A proposta só sofreu um adiamento... mas eu não vou desistir, pois acho que o conceito é o que nós realmente precisamos. Só vou precisar vender a idéia para os meus chefes.
Enfim... o alinhamento estratégico é inexistente ou está misturado. O que pode acontecer?
Conversando com o meu colega, contei a história da Nissan para expressar a essência deste conceito. Ele achou bacana. Mas nesse momento, fomos interrompidos por um dos meus chefes.
Ele me disse que eles todos estavam em reunião e tiveram algumas decisões:
+ Eles querem equipes bem centradas e experientes, e com isso pode haver uma reformulação total na equipe do laboratório. Pior do que isso, dependendo do que eles entendem por "experientes" podemos ter um acréscimo que não foi previsto na folha de pagamento.
+ Eles simplesmente definiram que um dos meus subordinados atuais faria o papel de gerente de projetos de hardware e analista de processos, nas empresas. OPA! Peraí!! Como é? Eles escolheram a pessoa mais introvertida, entre os que estão ali. Um cara muito técnico com bons conhecimentos, só que não tem na comunicação o seu forte. E querem que ele vire GERENTE? E pior, que ele visite empresas e identifique processos?! Isso me soou de uma insanidade que só demonstra como os responsáveis por essas decisões não conhecem a equipe que tem.
+ O meu colega, analista e que faria a função de gerente, foi nomeado como analista de processos da empresa. Obviamente, ele foi o último a saber. Avisaram ele hoje, sem saber se ele tinha interesse ou não. Pela reação dele, no momento e depois da reunião, notei que ele estava meio puto da cara. Pois sabe que está se metendo numa encrenca daquelas... ele sabe que vai ter que acompanhar o tiroteio da empresa, que ao invés de se focar em uma tecnologia para se especializar e oferecer serviços, está tentando pegar tudo o que pode (projetos espaciais, de RFID, de software, de sistemas embarcados, etc).
+ Eu fui mantido de gerente de projetos do grupo de pesquisa. Aqui foi a notícia boa. Eu pretendo, posteriormente, alcançar posições mais altas (obviamente não será no grupo e nem na empresa que tem uma hierarquia pequena e monolítica), mas nem por isso vou pular degraus. Quero gerenciar mais alguns projetos (este principalmente, que terá um apelo bem interessante) para acumular experiência e me preparar para os novos desafios.
Enfim, novamente houve uma mistura enorme entre empresa e grupo de pesquisa. Eu vou exigir, antes de começar o projeto, que os papéis e responsabilidades estejam BEM DEFINIDOS. Isso significa que não haverá possibilidade de alguém que tem o foco só no grupo, tenha que prestar algum serviço para a empresa. Vou ser bem incisivo nisso. Se eu vou realmente ser do grupo, vou representar o GRUPO e não a empresa.
Apesar dessa reunião ter demonstrado algumas decisões que eu não concordo (como a saida do meu colega contra a vontade dele - aparentemente - para a empresa e a nomeação do gerente de projetos de hardware de uma pessoa sem o perfil) eu ainda acho que consigo transformar o laboratório em um local para a gestão de competências. A proposta só sofreu um adiamento... mas eu não vou desistir, pois acho que o conceito é o que nós realmente precisamos. Só vou precisar vender a idéia para os meus chefes.
Enfim... o alinhamento estratégico é inexistente ou está misturado. O que pode acontecer?
Terça-feira, 17 de Junho de 2008
Seleção de pessoal. Uma tarefa difícil!
Pois então.
O projeto de três anos foi aprovado. Agora terei a missão de formar uma equipe talentosa e capaz de realizar o projeto da melhor maneira possível.
Minha grande dúvida é: como identificar os aspectos comportamentais de um candidato? Lancei a pergunta na lista de "Agile-Brasil" e recebi algumas respostas bacanas. Vou compartilhar com vocês.
O Daniel Wildt respondeu o seguinte:
O Manoel Pimentel respondeu:
O Rodrigo Araújo:
O Roberto Brum:
Por fim, o MT veio com uma resposta bacana:
Enfim. Se você está pensando em selecionar os seus candidatos, vale a pena ler as sugestões e adaptar da melhor forma na sua empresa. Acredito que o ideal seja não decidir com base em UMA entrevista e com UMA opinião. As percepções podem enganar e nos fazer realizar escolhas que depois iremos nos arrepender...
Abraços!
O projeto de três anos foi aprovado. Agora terei a missão de formar uma equipe talentosa e capaz de realizar o projeto da melhor maneira possível.
Minha grande dúvida é: como identificar os aspectos comportamentais de um candidato? Lancei a pergunta na lista de "Agile-Brasil" e recebi algumas respostas bacanas. Vou compartilhar com vocês.
O Daniel Wildt respondeu o seguinte:
Qual o teu foco de contratação? Estagiários? Pessoas com experiência em TI? CLT? PJ? Consultor? Tudo isto vai influir em que perguntas devem ser feitas.
Lembrar que a pessoa deve se ambientar ao time e vice-versa. Teu time será efetivo e vai entregar software se as pessoas saberem trabalhar como uma equipe. A pessoa deve ajudar e buscar ajuda. A pessoa deve ser crítica com relação ao que faz e saber sugerir melhorias e indentificar algo que não esteja de acordo no trabalho sendo desenvolvido, para permitir a geração de ações de melhoria contínua. Que excelência técnica deve ser buscada por todo o time. Deve gostar de se comunicar com o cliente, e também com os colegas de trabalho, para poder conhecer mais do que deve ser desenvolvido e entregue para o cliente.
Vais procurar por softskills, isto é um problema em muitos dos casos de entrevistas. Em uma entrevista, a pessoa pode estar nervosa ou ter um curso de teatro e tudo pode parecer maravilhoso ou horrível.
Resumindo tudo isto... tomar cuidado com uma seleção estilo "blink". Evita os pré-julgamentos.
http://en.wikipedia.org/wiki/Blink_(book)
Uma referência legal:
http://webinsider.uol.com.br/index.php/2006/10/09/identificar-contratar-e-reter-talentos/
O Manoel Pimentel respondeu:
Olá Flávio, legal sua questão.
Creio que só uma entrevista simples não lhe revelará esses traços,
portanto, de repente você poderia fazer dinâmicas de grupo com os
candidatos, com objetivo de identificar esses perfis desejados.
Mas caso não seja possível aplicar essas dinâmicas, talvez seja
interessante, fazer no lugar de uma entrevista formal, uma espécie de
bate-papo informal, para analisar quais as reações dos candidatos as
diversos tipos de questões e principalmente observar se eles terão a
iniciativa de "puxar" algum assunto novo dentro do tema em questão e
de que forma eles se comportam dentro de um diálogo, inclusive você
pode simular questões de concordância e questões de divergências de
idéias para instanciar diferentes climas durante a conversa, assim
será possível avaliar as reações dos candidatos a situações normais e
a situações tensas.
Agora caso queira algo mais formal e com técnica (porém mais difícil
de aplicar), uma boa alternativa é o teste de PI(Predictive Índex),
que é um forma bem técnica e embasado por princípios de psicologia
para identificar e avaliar perfis (ver mais informações nesse fórum:
http://www.via6.com/topico.php?tid=41689).
O Rodrigo Araújo:
Olá Flávio, aqui no Centro de Informática da UFPE nos temos um grupo de pesquisa com o professor Fábio Queda que aborda justamente esse ponto de formação de times baseados em perfis. Em quase todos nossos trabalhos temos nos baseados nos perfis de Belbin (http://www.belbin.com/), porém o acesso aos questinários para avaliação dos perfis é pago. Se você ou mais alguém se interessar pelo assunto posso passar links para artigos e teses que temos publicado a respeito desse assunto.
O Roberto Brum:
Se você será o responsável, você deverá se sentir bem com ele, deve ter empatia. Faça perguntas abertas para fazê-lo falar.
Sugestão (se você nunca fez entrevista de emprego): Comece falando da empresa, dos produtos, da política, para ver se interessa ao candidato. Não adianta contratar alguém muito bom se ele não se sentir bem no ambiente. Depois de apresentar a empresa, você pode ir lendo o currículo e fazendo perguntas como:
Por que você saiu desta empresa?
O que você mais gostou quando trabalhou lá?
O que menos gostou?
E o que te deixou orgulhoso neste emprego?
Por fim, o MT veio com uma resposta bacana:
Algumas dicas que aprendi nos meus tempos de Rational Software:
1 - Envolva mais pessoas. Não sei se é possível agora, mas ter pelo
menos 3 pessoas em cada entrevista dilui riscos e permite que
aspectos sutis sejam captados com mais facilidade. Quando o candidato
sair, façam o "debriefing" imediatamente e anote na ficha do cara.
2 - A palavra final deve ser de quem vai trabalhar com o candidato.
3 - Elabore uma lista de características que vc quer, separando-as
por categoria. Ex: Conhecimento Técnico, Habilidades Interpessoais,
Iniciativa e Liderança, etc. Tente, em cada categoria, fazer uma
lista de "features" que essa pessoa deve ter. Ex: em Liderança, ver
se já participou de gremio ou centro academico. É sindico do predio?
Já foi orador da turma? etc,etc, etc. Vc tem que dar "notas"
ou "ok's" para esses pontos durante a entrevista.
4 - Use uma abordagem "comportamental". Existe uma técnica
chamada "behaverial interview", que usa o passado da pessoa para
saber como ela é. Em vez de perguntar "como vc lida com conflitos"
ou "se houver um conflito com outra pessoa, como vc resolve?", vc
pergunta assim, como quem não quer nada "me conte, vc já teve alguma
discussão no trabalho? Já enfrentou algum tipo de problema com algum
colega? Conte-me mais, como foi? Conte o 'causo' em detalhes". E vá
explorando a história, perguntando detalhes do que o candidato fez na
situação. A idéia é que as pessoas não mudam muito e o que o cidadão
fez no passado é um sinal muito bom do que ele fará no futuro na
mesma situação.
Um exemplo interessante: uma vez, fui entrevistar um candidato em
cujo curriculo as palavras "lider" ou "liderança" apareciam um monte
de vezes. Perguntei-lhe se ele já tivera a experiência de 2 membros
da equipe dele discutirem ou discordarem em algo. Depois, perguntei o
que ele fez para solucionar a questão. Resultado: ele, mesmo, nunca
resolveu nenhum conflito de colegas ou subordinados, sempre levou
para a gerência. Que tipo de liderança esse cara mostrou?
A lista de características combinada com a abordagem comportamental é
uma ferramenta muito poderosa.
Finalmente, considere ter 2 ou 3 entrevistas, sendo uma geral, uma
técnica e uma para aspectos pessoais.
Enfim. Se você está pensando em selecionar os seus candidatos, vale a pena ler as sugestões e adaptar da melhor forma na sua empresa. Acredito que o ideal seja não decidir com base em UMA entrevista e com UMA opinião. As percepções podem enganar e nos fazer realizar escolhas que depois iremos nos arrepender...
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, 13 de Maio de 2008
Um bom dia até... a noite chegar.
Havia comentado que 2a feira havia sido um bom dia.
Pois à noite recebi a resposta de um cliente, perguntando o motivo do cancelamento da reunião. Eu consegui esquecer da reunião!!!!!
Por algum motivo eu escrevi a reunião nas minhas anotações, mas rasurei. Então me esqueci completamente!
Felizmente agendamos outra para 5a-feira.
O pior é que já estamos em débito com eles... e estávamos tapando este buraco.
Que droga! Agora terei que agir em dobro.
Pois à noite recebi a resposta de um cliente, perguntando o motivo do cancelamento da reunião. Eu consegui esquecer da reunião!!!!!
Por algum motivo eu escrevi a reunião nas minhas anotações, mas rasurei. Então me esqueci completamente!
Felizmente agendamos outra para 5a-feira.
O pior é que já estamos em débito com eles... e estávamos tapando este buraco.
Que droga! Agora terei que agir em dobro.
Segunda-feira, 12 de Maio de 2008
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
Quinta-feira, 8 de Maio de 2008
Dicas para comunicação
Como mencionei em um post anterior (o quilométrico!), li um livro sobre "Supercomunicação com neurolinguística". E ali existem duas dicas bem interessantes para facilitar a comunicação, principalmente para o caso de pessoas que não conhecemos (olha aí uma dica importante para começar um networking!).
O autor menciona a necessidade de termos as perguntas certas, e as vezes não sabemos muito bem como nos aproximar. Então ele sugere usar o método FROGS. Que significa perguntar:
F = familia e amigos
R = recreação e lazer
O = ocupação
G = geografia
S = vida social
Olhando isso, vemos como realmente é simples! "Você tem filhos? Você é casado?", "O que você gosta de fazer? Gosta de futebol? Gosta de fotografia?", "Como está o seu trabalho? Como você motiva sua equipe?", "Onde você passou as suas férias? Você já esteve no Rio Grande do Sul?", "Você costuma sair muito? Já foi naquele restaurante tal?".
São perguntas não muito evasivas e não muito particulares. Dá uma margem boa para iniciar uma conversa e identificar pontos em comum. Identificados estes pontos, fica muito mais simples de fluir com a conversa. "Você também é gremista? Que legal! O que achou do jogo ontem?".
Uma frase do autor, em seguida, é bem interessante: "Se você fizer boas perguntas, ouvir com atenção e fornecer alimento emocional à sua conversa, gradualmente ganhará respeito e autoconfiança".
O alimento emocional que o autor menciona pode ser descrito pelo acrônimo AARDVARC (meio chatinho de decorar, admito, mas interessante):
A = apreciação
A = aceitação
R = respeito e reconhecimento
D = desejo
V = valor
A = aprovação
R = reestabelecimento de confiança
C = contratulações, elogios
"Para ser interessante, seja interessado" ele termina o capítulo. O que significa cada um desses itens?
Apreciação: por exemplo, apreciar o fato da outra pessoa estar lhe disponibilizando um tempo para você. Durante a reunião, tentar apreciar o conhecimento dele. O fato aqui é "massagear o ego" da pessoa com a qual você está conversando. Segundo o autor, se você apreciar o seu modo de pensar, o que está dizendo e o seu sentimento, é quase certo que ele mostrará apreciação pela próxima coisa que você disser, dando crédito por ela.
Aceitação: é o combustivel do ser humano. Todos nós precisamos nos sentir aceitos, isso é fato. O desejo de qualquer pessoa é encontrar alguém com que possa se sentir à vontade, você concorda? Aqui não tem grandes dicas. Diz apenas para você aceitar a pessoa com a qual você está conversando.
Reconhecimento/Respeito: Usando a questão da reunião de negócios, você pode em um certo momento expressar que sente um enorme respeito pela maneira como ele está conduzindo o projeto. Você afaga o ego dele de novo, e isso o torna ainda mais confiante em relação a você. O difícil, neste caso, é não parecer um bajulador barato, pois isso tende a apenas piorar as coisas. Honestidade e sinceridade devem valer. Se ele é um péssimo gerente de projetos, tente elogiar alguma atitude dele. "Um grande respeito pela sua atitude na forma como conduziu aquele conflito com seu time".
Desejo: no mundo dos negócios, essa palavra não tem muita aplicação. Mas sabemos que todo ser humano gosta de se sentir desejado (como apreciado). Só cuidado para não expressar o seu desejo por aquela loira da foto, que pode vir a ser a pessoa com a qual você negocia :)
Valor: as pessoas gostam de se sentir úteis e que suas opiniões ou atitudes tem valor. Durante uma reunião, um simples: "A sua opinião sobre este assunto seria de grande valor para mim". Seria como dizer: "Seu que você é inteligente". Ou utilize isso no final da reunião com um "Ótima reunião! Suas opiniões foram valiosas para nós".
Aprovação: somos todos eternas crianças. Portanto, sentimos a necessidade de aprovação o tempo todo. Você deve aprovar as atitudes de seus subordinados, por exemplo, sempre quando convir. Aqui vale aquela regra do "gerente-minuto": flagre seus funcionários fazendo coisas boas e certas, e elogie! Demonstre sua aprovação com isso. E se algo não estiver realmente bom? Use um "Realmente posso perceber que você está se esforçando bastante; está ficando muito bom" e em seguida você pode usar um "MAS" e em seguida sugerir algumas alterações. Isso não é mais correto do que usar um "Não!! Está tudo errado!! Suma da minha frente com isso e refaça!!"?
Restabelecimento da confiança: todos precisam que sua confiança seja restabelecida em um ou outro estágio. Um exemplo bem clássico é aquela pessoa que recém se acidentou com o carro. Ele demora um tempo até ter novamente confiança em fazer aquilo que antes era tão trivial. Por isso, mesmo que você ache que a pessoa que você está dialogando ainda está satisfeito com alguma coisa, busque se informar se realmente está tudo ok. Certifique-se de que ele ainda confia em você da mesma forma.
Congratulação: um elogio sincero geralmente é um dos maiores motivadores nas empresas. Uma dica interessante aqui é personalizar os elogios. Ao invés de elogiar um trabalho realizado, tente elogiar a forma com que a pessoa realizou o trabalho. Dessa forma você está elogiando explicitamente não só o resultado, mas também a pessoa que o realizou.
A dica final que o livro traz é de elogiar sempre com sinceridade. Se você descobrir que o seu cliente tem um interesse em comum com você (um hobby, por exemplo) você pode quebrar o gelo e começar a estabelecer um sentimento de confiança quase que instantâneo. Um exemplo simples: você entra na sala de um cliente e nota que ele tem uma placa de prata com o seu nome, diversas folhas de papel em cima da mesa, um computador notebook de última geração, um quadro onde aparecem sua filha bonita e alguns troféus de campeonatos de boliche.
O que você apreciaria? Eu, particularmente, tentaria os troféus de boliche. Visivelmente é algo que ele gosta de fazer e dedica um bom tempo nisso, ao ponto de participar de campeonatos. De repente ele menciona algo sobre os filhos, e você já emenda dizendo que a filha dele é muito bonita (sem demonstrar excitação, por favor!) e pergunta se tem mais filhos. Aí a conversa já pode entrar na tática FROGS. Você deixou ele falar a respeito de um assunto que com certeza abriu um leque de opções interessantes para vocês dois se conhecerem melhor. E é mais fácil negociar com alguém que se sente mais a vontade, do que negociar com alguém que o olha com desconfiança.
Se você elogiasse seu notebook, fizesse algum comentário sobre a placa de prata ou sobre as folhas de papel (ou pior ainda, falasse da filha diretamente) você seria muito superficial. Imagine o elogio ao notebook. Ele possivelmente falaria que "é uma boa máquina realmente". O que você falaria em seguida? "Onde você comprou"? "Roda GTA4"? Ou quem sabe "Quanto custou"? Todas essas perguntas não acrescentariam nada, não acham?
Enfim. Acho que essas dicas acrescentam bastante no nosso dia-a-dia. Seja com nossos subordinados, seja com nossos chefes, seja com clientes ou mesmo quando quisermos realizar networking com colegas de cursos e afins.
Espero que gostem das dicas!! :)
Um abraço
Segunda-feira, 5 de Maio de 2008
SCRUM para resgatar o projeto!
Hoje tivemos nossa reunião para começar o sprint. Não foi uma reunião oficial, daquelas em que passamos o dia planejando e tudo mais. Mesmo assim tivemos definições importantes.
Temos 7 semanas até o fim do projeto. Então decidimos fazer 3 sprints de 2 semanas, com mais 1 semana de "pulmão" para ajustes e afins. Temos inicialmente 11 stories para cumprir. No primeiro sprint 4 stories serão "atacadas".
Definimos como será o nosso taskboard. A princípio ele será conforme a figura abaixo:
(1) São as user stories em forma de index cards (veja mais adiante)
(2) Identifica a coluna que acrescentamos, a VERIFY
(3) Indica o nosso burndown chart
(4) As tarefas não planejadas, as famosas "tarefas rosas"
(5) São as informações da sprint, número, data de início e fim e o tamanho em pontos
(6) É o backlog de impedimentos
A coluna VERIFY eu acredito que seja a melhor mudança introduzida. Por quê? Pois ela "força" uma pessoa a dar o aval se a tarefa está pronta ou não. No caso, serei eu (scrum master) que validarei as tarefas para DONE. O processo é bem simples:
SE AS TAREFAS ESTIVEREM PRONTAS, VÃO PARA DONE
SE ALGO NÃO ESTIVER CONFORME, VOLTA PARA DOING
O legal é que todos da equipe aprovaram isso. O Scrum Master começa a se integrar mais com as atividade de fato, sem ficar na esperança de que os caras tenham feito as coisas mesmo.
O nosso gráfico de BURNDOWN seguirá o modelo que usamos anteriormente, o qual não é recomendado, mas devido ao nosso baixo tempo para estimar tarefas e também ao pedido da equipe pelo gráfico, ele será mensurado da seguinte forma:
X-AXIS : dias do sprint (5/5, 6/5, 7/5... 15/5, 16/5).
Y-AXIS : tarefas restantes (número de tarefas. Quando surgirem rosas, o gráfico sobe)
O pessoal recomenda usar horas ou pontos. Como eu disse, não tínhamos tempo (e sinceramente, nem saco) para estimar cada uma das tarefas. Então faremos assim... o gráfico dará apenas uma visão gráfica da taskboard. Servirá apenas como "motivador".
As tarefas não planejadas são todas aquelas que não foram levantadas durante a reunião de hoje (2a feira). Se uma atividade não planejada durar mais do que 1 hora, ela vira uma tarefa rosa. Portanto, "Resetar o computador" não é uma tarefa rosa. Mas "Reinstalar o Windows" já poderia ser considerada :)
O campo das informações do sprint são bem legais. Ali fica visual o dia de início e fim da sprint, o sprint goal (no nosso caso é "Finalizar o sistema de software") e também tem o número de pontos estimados para as 4 stories que colocamos no sprint. Uma de 13 pontos, duas de 8 pontos e uma de 5 pontos. Total 34 pontos.
O backlog de impedimentos será bem simples. Cada impedimento que ocorrer gera um post-it (no nosso caso, será aqueles "reciclados" cor cinza). Marcamos a data que surgiu e quem gerou o impedimento e quando ele for resolvido, será apenas "riscado".
As tarefas planejadas devem conter apenas o nome da pessoa que está realizando, como extra. Se forem 2 pessoas, ou se colocam os dois nomes ou alguém que responderá por ela.
Por fim, as INDEX CARDS. Finalmente usamos o conceito das index cards. Ela está exatamente como a figura abaixo mostra:
Temos o campo "ID" apenas para identificação rápida da story, o nome da story, a sua prioridade (na faixa de 1 a 150), algumas notas (que eu usei para descrever o objetivo e algumas informações extras sobre a story), a estimativa (usando planning poker ou apenas marcando Fibonacci ali 1-2-3-5-8-13-21) e o campo mais importante e útil de todos: o DoD (definition of done, ou definição de finalizado).
O DoD é tão importante e tão útil, que enquanto eu escrevia nele eu percebi o tamanho da ajuda que ele apresenta. Lembram na dinâmica do SCRUM que eu descrevi há algumas semanas atrás, quando mencionei que durante a sprint review eu não havia feito um DoD das stories, e assim eu não sabia o que avaliar nas apresentações? Pois é. Agora temos um "checklist" das coisas importantes que a story deve considerar.
Por exemplo, em uma story chamada "Manual do Usuário", um dos "DoD's" é:
- O documento identifica todas as funcionalidades do sistema
- O documento apresenta passo a passo os procedimentos para as funções
- Os pontos de interação com o usuário estão descritos no documento
E assim por diante. Na story chamada "Criação de uma placa de alimentação" temos alguns "DoD's" como:
- Todos os componentes necessários estão disponíveis
- Foi realizada uma medida de consumo do sistema e a placa atende a isso
Enfim, agora temos alguns critérios para avaliar se as stories estão realmente DONE ou não! Além disso, a utilização dos DoD's facilita (e facilitou mesmo) a definição das tarefas. Cada uma dessas DoD's vira no minimo uma tarefa... geralmente mais de uma até.
Os DoD's podem funcionar até mesmo como casos de teste. Se fosse uma story que descrevesse uma tela de login (usuário e senha), por exemplo. Os DoD's poderiam ser:
- O sistema não aceita menos de 5 caracteres nos campos de usuário e senha
- O sistema não aceita números sequenciais como senha (12345, 67890, etc)
E assim por diante. Eu posso dizer que o DoD realmente é uma das coisas mais importantes que sua story deve possuir. Sem dúvida nenhuma! :)
Pois então é isso. Temos 7 semanas para tocar o projeto. É a chance de recuperar um projeto que parecia morto e transformá-lo em um protótipo interessante e com uma documentação bem completa.
O que falta mudar agora é a atitude da equipe... eles estavam largados nesse meio tempo. Mas agora a pressão vai vir não só de mim... mas do taskboard também ;)
Um abraço!
Temos 7 semanas até o fim do projeto. Então decidimos fazer 3 sprints de 2 semanas, com mais 1 semana de "pulmão" para ajustes e afins. Temos inicialmente 11 stories para cumprir. No primeiro sprint 4 stories serão "atacadas".
Definimos como será o nosso taskboard. A princípio ele será conforme a figura abaixo:
(1) São as user stories em forma de index cards (veja mais adiante)
(2) Identifica a coluna que acrescentamos, a VERIFY
(3) Indica o nosso burndown chart
(4) As tarefas não planejadas, as famosas "tarefas rosas"
(5) São as informações da sprint, número, data de início e fim e o tamanho em pontos
(6) É o backlog de impedimentos
A coluna VERIFY eu acredito que seja a melhor mudança introduzida. Por quê? Pois ela "força" uma pessoa a dar o aval se a tarefa está pronta ou não. No caso, serei eu (scrum master) que validarei as tarefas para DONE. O processo é bem simples:
SE AS TAREFAS ESTIVEREM PRONTAS, VÃO PARA DONE
SE ALGO NÃO ESTIVER CONFORME, VOLTA PARA DOING
O legal é que todos da equipe aprovaram isso. O Scrum Master começa a se integrar mais com as atividade de fato, sem ficar na esperança de que os caras tenham feito as coisas mesmo.
O nosso gráfico de BURNDOWN seguirá o modelo que usamos anteriormente, o qual não é recomendado, mas devido ao nosso baixo tempo para estimar tarefas e também ao pedido da equipe pelo gráfico, ele será mensurado da seguinte forma:
X-AXIS : dias do sprint (5/5, 6/5, 7/5... 15/5, 16/5).
Y-AXIS : tarefas restantes (número de tarefas. Quando surgirem rosas, o gráfico sobe)
O pessoal recomenda usar horas ou pontos. Como eu disse, não tínhamos tempo (e sinceramente, nem saco) para estimar cada uma das tarefas. Então faremos assim... o gráfico dará apenas uma visão gráfica da taskboard. Servirá apenas como "motivador".
As tarefas não planejadas são todas aquelas que não foram levantadas durante a reunião de hoje (2a feira). Se uma atividade não planejada durar mais do que 1 hora, ela vira uma tarefa rosa. Portanto, "Resetar o computador" não é uma tarefa rosa. Mas "Reinstalar o Windows" já poderia ser considerada :)
O campo das informações do sprint são bem legais. Ali fica visual o dia de início e fim da sprint, o sprint goal (no nosso caso é "Finalizar o sistema de software") e também tem o número de pontos estimados para as 4 stories que colocamos no sprint. Uma de 13 pontos, duas de 8 pontos e uma de 5 pontos. Total 34 pontos.
O backlog de impedimentos será bem simples. Cada impedimento que ocorrer gera um post-it (no nosso caso, será aqueles "reciclados" cor cinza). Marcamos a data que surgiu e quem gerou o impedimento e quando ele for resolvido, será apenas "riscado".
As tarefas planejadas devem conter apenas o nome da pessoa que está realizando, como extra. Se forem 2 pessoas, ou se colocam os dois nomes ou alguém que responderá por ela.
Por fim, as INDEX CARDS. Finalmente usamos o conceito das index cards. Ela está exatamente como a figura abaixo mostra:
Temos o campo "ID" apenas para identificação rápida da story, o nome da story, a sua prioridade (na faixa de 1 a 150), algumas notas (que eu usei para descrever o objetivo e algumas informações extras sobre a story), a estimativa (usando planning poker ou apenas marcando Fibonacci ali 1-2-3-5-8-13-21) e o campo mais importante e útil de todos: o DoD (definition of done, ou definição de finalizado).
O DoD é tão importante e tão útil, que enquanto eu escrevia nele eu percebi o tamanho da ajuda que ele apresenta. Lembram na dinâmica do SCRUM que eu descrevi há algumas semanas atrás, quando mencionei que durante a sprint review eu não havia feito um DoD das stories, e assim eu não sabia o que avaliar nas apresentações? Pois é. Agora temos um "checklist" das coisas importantes que a story deve considerar.
Por exemplo, em uma story chamada "Manual do Usuário", um dos "DoD's" é:
- O documento identifica todas as funcionalidades do sistema
- O documento apresenta passo a passo os procedimentos para as funções
- Os pontos de interação com o usuário estão descritos no documento
E assim por diante. Na story chamada "Criação de uma placa de alimentação" temos alguns "DoD's" como:
- Todos os componentes necessários estão disponíveis
- Foi realizada uma medida de consumo do sistema e a placa atende a isso
Enfim, agora temos alguns critérios para avaliar se as stories estão realmente DONE ou não! Além disso, a utilização dos DoD's facilita (e facilitou mesmo) a definição das tarefas. Cada uma dessas DoD's vira no minimo uma tarefa... geralmente mais de uma até.
Os DoD's podem funcionar até mesmo como casos de teste. Se fosse uma story que descrevesse uma tela de login (usuário e senha), por exemplo. Os DoD's poderiam ser:
- O sistema não aceita menos de 5 caracteres nos campos de usuário e senha
- O sistema não aceita números sequenciais como senha (12345, 67890, etc)
E assim por diante. Eu posso dizer que o DoD realmente é uma das coisas mais importantes que sua story deve possuir. Sem dúvida nenhuma! :)
Pois então é isso. Temos 7 semanas para tocar o projeto. É a chance de recuperar um projeto que parecia morto e transformá-lo em um protótipo interessante e com uma documentação bem completa.
O que falta mudar agora é a atitude da equipe... eles estavam largados nesse meio tempo. Mas agora a pressão vai vir não só de mim... mas do taskboard também ;)
Um abraço!
Sexta-feira, 2 de Maio de 2008
Murphy e a solução mágica
Fomos até a entidade onde deixaremos o nosso sistema rodando. Aparentemente tudo estava ok. Entramos em reunião com o responsável, conversamos que iríamos mostrar o sistema e... ERRO! Que beleza. Ficamos uns 15 minutos tentando identificar o problema. E NADA! E o cara da entidade ali do lado... com aquela cara de "Putz, esses caras não testaram isso?". Combinamos que iríamos resolver o problema até o fim do dia, para que na 2a feira pudessemos nos reunir novamente.
Voltamos para o laboratório desanimados. Enquanto o meu colega e a equipe tentavam identificar o problema, eu me reuni com a minha equipe do projeto antigo para definirmos os rumos. Em 20 minutos decidimos algumas coisas, mas eles tinham que ir para a aula.
Após isso, fui ver se o meu colega tinha resolvido o problema. Ele estava desanimado... sem esperança de resolver até o cara que desenvolveu o sistema voltar. Esse cara trabalha em outra empresa, e só poderia estar disponível pelas 18h. MEDO!
Resolvi então auxiliá-los. Pedi para eles gerarem a exceção que estava causando o erro. Logo identificamos que era no banco de dados (Oracle). Isso já havia sido identificado, mas eles não tinham visto alguns atributos interessantes na exceção.
Fomos no ambiente onde o sistema estava rodando. Abrindo o Oracle, logo identifiquei que haviam três "sequencias" (não sei ao certo o que significa, nunca fui um DBA) mas que não havia no outro ambiente onde os erros ocorriam. Geramos os SQL's para a criação dessas "sequencias" e colocamos no ambiente novo. Rodamos o sistema e...
BINGO! O sistema estava funcionando!!!!
Um sentimento de alegria e festa tomou a equipe! Da sensação de desesperança e desespero, o alívio tomou conta!
E foi assim que encerramos o dia. Felizes por ter resolvido um pepino enorme. A resposta estava ali... se a equipe fosse mais pró-ativa para pesquisar um pouco mais, teriam resolvido. Em 10 minutos eu resolvi um problema em que eles estavam em cima há uma tarde. Mas as vezes é assim mesmo... tem que entrar uma pessoa "não condicionada" para seguir um caminho diferente.
--------------
Hoje um ciclone extra-tropical está perto do RS. Teremos chuva com ventos até domingo. Devia ser proíbido ter que ir trabalhar nessas condições. Passei o dia encharcado! Fora o caos que é o trânsito na saída. Que saco. Chuva ainda vá... mas chuva forte com vento?! Ninguém aguenta!
Abraços e bom final de semana :)
Voltamos para o laboratório desanimados. Enquanto o meu colega e a equipe tentavam identificar o problema, eu me reuni com a minha equipe do projeto antigo para definirmos os rumos. Em 20 minutos decidimos algumas coisas, mas eles tinham que ir para a aula.
Após isso, fui ver se o meu colega tinha resolvido o problema. Ele estava desanimado... sem esperança de resolver até o cara que desenvolveu o sistema voltar. Esse cara trabalha em outra empresa, e só poderia estar disponível pelas 18h. MEDO!
Resolvi então auxiliá-los. Pedi para eles gerarem a exceção que estava causando o erro. Logo identificamos que era no banco de dados (Oracle). Isso já havia sido identificado, mas eles não tinham visto alguns atributos interessantes na exceção.
Fomos no ambiente onde o sistema estava rodando. Abrindo o Oracle, logo identifiquei que haviam três "sequencias" (não sei ao certo o que significa, nunca fui um DBA) mas que não havia no outro ambiente onde os erros ocorriam. Geramos os SQL's para a criação dessas "sequencias" e colocamos no ambiente novo. Rodamos o sistema e...
BINGO! O sistema estava funcionando!!!!
Um sentimento de alegria e festa tomou a equipe! Da sensação de desesperança e desespero, o alívio tomou conta!
E foi assim que encerramos o dia. Felizes por ter resolvido um pepino enorme. A resposta estava ali... se a equipe fosse mais pró-ativa para pesquisar um pouco mais, teriam resolvido. Em 10 minutos eu resolvi um problema em que eles estavam em cima há uma tarde. Mas as vezes é assim mesmo... tem que entrar uma pessoa "não condicionada" para seguir um caminho diferente.
--------------
Hoje um ciclone extra-tropical está perto do RS. Teremos chuva com ventos até domingo. Devia ser proíbido ter que ir trabalhar nessas condições. Passei o dia encharcado! Fora o caos que é o trânsito na saída. Que saco. Chuva ainda vá... mas chuva forte com vento?! Ninguém aguenta!
Abraços e bom final de semana :)
Papéis, responsáveis, comunicação.... e assumindo as rédeas!
Estava conversando agora pela manhã com o meu colega, que ESTÁ gerente de projeto junto comigo. Ele na verdade é analista, mas devido à demanda de projetos e pela experiência bem sucedida dele como GP em outro projeto, nada mais justo. Estamos assumindo juntos quase todos os projetos. E eu comecei a ver que isso levou ao mesmo problema de sempre: falta de clareza de papéis, responsáveis e dificuldade na comunicação.
Defini com ele, agora a pouco, quem assumiria o que. Dessa forma as equipes saberão claramente a quem se reportar, quem é o responsável pelas decisões e, principalmente, quem disseminará as informações aos demais.
Na quarta-feira eu notei que essa atuação conjunta não estava rendendo como deveria. Temos alguns projetos curtos em andamento (testes, por exemplo) e que não teriam motivos para eu e ele atuarmos junto, o que causava mais confusão do que ajudava.
Percebi também que a minha equipe antiga, cujo projeto ainda está em andamento, estava solta demais. Resolvi assumí-la novamente para evitar isso... antes que descambe para a "festa", já que gente sem ter o que fazer acaba causando impactos negativos no ambiente de trabalho.
Hoje iremos levantar o que falta do projeto, o nosso "product backlog". Iremos utilizar o SCRUM até o final do projeto, previsto para o meio de junho. Serão a princípio 8 itens, entre funcionalidades e documentos, quase todos importantes.
Assim, pelo menos uma equipe estará praticando o SCRUM lá dentro :)
Abraços
Defini com ele, agora a pouco, quem assumiria o que. Dessa forma as equipes saberão claramente a quem se reportar, quem é o responsável pelas decisões e, principalmente, quem disseminará as informações aos demais.
Na quarta-feira eu notei que essa atuação conjunta não estava rendendo como deveria. Temos alguns projetos curtos em andamento (testes, por exemplo) e que não teriam motivos para eu e ele atuarmos junto, o que causava mais confusão do que ajudava.
Percebi também que a minha equipe antiga, cujo projeto ainda está em andamento, estava solta demais. Resolvi assumí-la novamente para evitar isso... antes que descambe para a "festa", já que gente sem ter o que fazer acaba causando impactos negativos no ambiente de trabalho.
Hoje iremos levantar o que falta do projeto, o nosso "product backlog". Iremos utilizar o SCRUM até o final do projeto, previsto para o meio de junho. Serão a princípio 8 itens, entre funcionalidades e documentos, quase todos importantes.
Assim, pelo menos uma equipe estará praticando o SCRUM lá dentro :)
Abraços
Terça-feira, 29 de Abril de 2008
Implantando o sistema em um cliente
Após o aviso de que teríamos uma implantação do sistema em um dos nossos clientes (como descrito no post anterior), hoje foi o dia da correria.
A reunião de apresentação era as 14h. Cheguei no laboratório às 13h. O meu colega estava desesperado... já estava me dizendo que não daria para ser naquele dia. Ele estava pessimista.
Eu achei que poderíamos cumprir o prazo. E em 1 hora conseguimos configurar o ambiente, testar e validar o sistema remotamente, na máquina do cliente! Claro, metade das coisas eu e o meu colega tivemos que dizer ("eles tem o JRE lá? A base tá ok lá?"), mas isso a gente já está acostumado.
No fim das contas, a reunião não foi de apresentação do sistema, mas foi importantíssimo termos participado. Pois conseguimos reaver um cliente quase perdido e também nos alinhamos melhor com eles, ao invés de ter a comunicação intermediada pelos coordenadores.
Me senti satisfeito por ter conseguido recuperar isso, pois todos estavam pessimistas. Amanhã iremos levantar mais requisitos junto a eles.
SCRUM? Nada... ainda não deu tempo ;/
Abraços
A reunião de apresentação era as 14h. Cheguei no laboratório às 13h. O meu colega estava desesperado... já estava me dizendo que não daria para ser naquele dia. Ele estava pessimista.
Eu achei que poderíamos cumprir o prazo. E em 1 hora conseguimos configurar o ambiente, testar e validar o sistema remotamente, na máquina do cliente! Claro, metade das coisas eu e o meu colega tivemos que dizer ("eles tem o JRE lá? A base tá ok lá?"), mas isso a gente já está acostumado.
No fim das contas, a reunião não foi de apresentação do sistema, mas foi importantíssimo termos participado. Pois conseguimos reaver um cliente quase perdido e também nos alinhamos melhor com eles, ao invés de ter a comunicação intermediada pelos coordenadores.
Me senti satisfeito por ter conseguido recuperar isso, pois todos estavam pessimistas. Amanhã iremos levantar mais requisitos junto a eles.
SCRUM? Nada... ainda não deu tempo ;/
Abraços
Segunda-feira, 28 de Abril de 2008
Comunicação? Não... não é tão importante. E também: o guri de 18 anos.
Semana passada implantei a metodologia de SCRUM para atacar um dos principais problemas do laboratório: COMUNICAÇÃO. Pois não é que hoje eles conseguem me pregar mais uma peça?!
Fui para uma reunião de manhã, na empresa (para situar os novatos: trabalho em um laboratório de pesquisa E na empresa que é parceira de muitos projetos deste laboratório), para um projeto que a empresa fará em conjunto com uma empresa americana, para um portal coorportativo. Na saída, um dos sócios da empresa, que cuida da área comercial, comentou comigo:
- E ai, Flavio, amanhã vamos apresentar o sistema então?
- Hein? Qual sistema? (surpreso)
- O da administração da universidade, para o controle de ativos!
- Não estou sabendo de nada!!! (aflito)
- Não te avisaram então? Acho que um dos coordenadores deve falar contigo ainda hoje.
- Ah... tá bem, mas estou sabendo por ti agora. (resignado)
O sistema está pronto há 2 semanas. Ficamos todo esse tempo apenas mexendo aqui, ajeitando ali, nada de muito útil. Então, de um dia para o outro, resolvem fazer a apresentação sem nem ao menos nos consultar. Resultado? Boa parte da equipe não estava lá no laboratório, para fazer os testes finais e afins. Tivemos que passar o dia inteiro correndo atrás para deixar tudo pronto para amanhã e correndo atrás dessas pessoas responsáveis. Um deles chegou às 18h.
De tarde um dos coordenadores me falou da reunião. Não sei a visão que eles tem de implantar o sistema em um cliente, mas ao que parece, para eles é algo trivial e simples... por isso que 24h é mais do que o suficiente para nos avisar. Ainda mais no nosso ambiente atual de trabalho.
----------------------------------
Não foi um dia de SCRUM hoje. Não tive tempo de fazer nada do que pretendia (levantar o product backlog de pelo menos um projeto). Os incêndios vem e vão, é difícil de implantar agilidade em curto prazo...
Mas quero falar de um dos guris que trabalha lá. Ele tem 18 anos, é um dos mais novos. Eu mesmo o entrevistei para entrar em um projeto envolvendo PDA/PALM. Achei ele um guri novo, mas que pesava por ter sido o melhor dos entrevistados. Me pareceu com potencial.
O projeto acabou morrendo, embora ele cumpriu o que prometeu (desenvolveu uma aplicação em PDA). E agora está trabalhando fazendo os testes com RFID, para identificarmos casos de aplicabilidade e margem de leitura das antenas (melhores configurações para cada situação).
Inicialmente, nos passaram essa tarefa meio à bangu: "Tem que fazer testes, faz assim, assim e assim". Eu estava atarefado na época e montei uma planilha com as variáveis possíveis e passei para ele testar. Ele fez os testes, mas ficou muito dependente da pessoa que mexe com o software e as antenas.
Na apresentação disso a um dos coordenadores, ele foi bastante criticado, pois os testes não diziam nada. Assumi parte da culpa por não ter orientado ele e então com o meu colega fizemos um esboço de testes. Decidimos utilizar o conceito de cenários. Ou seja, para cada cenário específico, levantaríamos o que queríamos concluir com os testes e "setávamos" as variáveis envolvidas. Pedimos para o guri fazer o plano de testes baseado nisso.
Três dias, e ele continua na mesma. Hoje o meu colega deu um ultimato (de forma clara mas tranquila "Vamos virar essa página hoje?") mas eu senti que ele não havia novamente entendido o que seria o plano de testes. Ali pelas 17h30, sentei com ele e falei: "Ok me mostra o que tu tens". Ele estava fazendo planos de teste baseado novamente apenas nas variáveis... e isso estava gerando 300 casos de teste!!!
Questionei se ele faria tudo isso e ele achou graça. Então falei que ele iria acabar novamente gerando 300 casos de teste e não teria conclusão nenhuma. "O caso 195 foi o que garantiu 100% de leitura", ok, mas e aí? Onde seria aplicado? Como?
Então tive que, literalmente, ditar o documento para ele entender como queríamos. Estruturei o documento, onde eram explicados o cenário, o que queríamos testar, as condições, as variáveis e o objetivo do teste. E então, os planos de testes. Conseguimos queimar algumas variáveis dali, pois elas se sobrepunham (tag entrando do lado esquerdo e direito? Qual a diferença? Então colocamos tag entrando junto à antena). Não sei quantos casos de teste deu, deixei isso como tarefa para ele, mas acredito que não deve ter chegado a 30. E com um objetivo claro definido!
Além disso, com o pior caso possível poderemos propôr outro cenário de testes para tratá-lo. "O caso de teste 24 apresentou um aproveitamento de 30%. Para essa situação, iremos criar o cenário 2...".
Eu entendo que ele é um guri de 18 anos, entendo que a faculdade não ensina o pessoal a escrever, entendo que ele possa ter algumas dúvidas sobre os testes. Mas poxa, chegamos a essas conclusões do documento apenas pensando, imaginando a situação!! Reduzimos as variáveis apenas pensando!
Por que será que alguns dos meus funcionários teimam em não pensar um pouco nas tarefas que damos? A gente incentiva isso! Quando eu digo que as vezes fico desmotivado no trabalho, este é um dos principais motivos... as pessoas que nós gerenciamos parecem que não levam nada a sério.
Fui para uma reunião de manhã, na empresa (para situar os novatos: trabalho em um laboratório de pesquisa E na empresa que é parceira de muitos projetos deste laboratório), para um projeto que a empresa fará em conjunto com uma empresa americana, para um portal coorportativo. Na saída, um dos sócios da empresa, que cuida da área comercial, comentou comigo:
- E ai, Flavio, amanhã vamos apresentar o sistema então?
- Hein? Qual sistema? (surpreso)
- O da administração da universidade, para o controle de ativos!
- Não estou sabendo de nada!!! (aflito)
- Não te avisaram então? Acho que um dos coordenadores deve falar contigo ainda hoje.
- Ah... tá bem, mas estou sabendo por ti agora. (resignado)
O sistema está pronto há 2 semanas. Ficamos todo esse tempo apenas mexendo aqui, ajeitando ali, nada de muito útil. Então, de um dia para o outro, resolvem fazer a apresentação sem nem ao menos nos consultar. Resultado? Boa parte da equipe não estava lá no laboratório, para fazer os testes finais e afins. Tivemos que passar o dia inteiro correndo atrás para deixar tudo pronto para amanhã e correndo atrás dessas pessoas responsáveis. Um deles chegou às 18h.
De tarde um dos coordenadores me falou da reunião. Não sei a visão que eles tem de implantar o sistema em um cliente, mas ao que parece, para eles é algo trivial e simples... por isso que 24h é mais do que o suficiente para nos avisar. Ainda mais no nosso ambiente atual de trabalho.
----------------------------------
Não foi um dia de SCRUM hoje. Não tive tempo de fazer nada do que pretendia (levantar o product backlog de pelo menos um projeto). Os incêndios vem e vão, é difícil de implantar agilidade em curto prazo...
Mas quero falar de um dos guris que trabalha lá. Ele tem 18 anos, é um dos mais novos. Eu mesmo o entrevistei para entrar em um projeto envolvendo PDA/PALM. Achei ele um guri novo, mas que pesava por ter sido o melhor dos entrevistados. Me pareceu com potencial.
O projeto acabou morrendo, embora ele cumpriu o que prometeu (desenvolveu uma aplicação em PDA). E agora está trabalhando fazendo os testes com RFID, para identificarmos casos de aplicabilidade e margem de leitura das antenas (melhores configurações para cada situação).
Inicialmente, nos passaram essa tarefa meio à bangu: "Tem que fazer testes, faz assim, assim e assim". Eu estava atarefado na época e montei uma planilha com as variáveis possíveis e passei para ele testar. Ele fez os testes, mas ficou muito dependente da pessoa que mexe com o software e as antenas.
Na apresentação disso a um dos coordenadores, ele foi bastante criticado, pois os testes não diziam nada. Assumi parte da culpa por não ter orientado ele e então com o meu colega fizemos um esboço de testes. Decidimos utilizar o conceito de cenários. Ou seja, para cada cenário específico, levantaríamos o que queríamos concluir com os testes e "setávamos" as variáveis envolvidas. Pedimos para o guri fazer o plano de testes baseado nisso.
Três dias, e ele continua na mesma. Hoje o meu colega deu um ultimato (de forma clara mas tranquila "Vamos virar essa página hoje?") mas eu senti que ele não havia novamente entendido o que seria o plano de testes. Ali pelas 17h30, sentei com ele e falei: "Ok me mostra o que tu tens". Ele estava fazendo planos de teste baseado novamente apenas nas variáveis... e isso estava gerando 300 casos de teste!!!
Questionei se ele faria tudo isso e ele achou graça. Então falei que ele iria acabar novamente gerando 300 casos de teste e não teria conclusão nenhuma. "O caso 195 foi o que garantiu 100% de leitura", ok, mas e aí? Onde seria aplicado? Como?
Então tive que, literalmente, ditar o documento para ele entender como queríamos. Estruturei o documento, onde eram explicados o cenário, o que queríamos testar, as condições, as variáveis e o objetivo do teste. E então, os planos de testes. Conseguimos queimar algumas variáveis dali, pois elas se sobrepunham (tag entrando do lado esquerdo e direito? Qual a diferença? Então colocamos tag entrando junto à antena). Não sei quantos casos de teste deu, deixei isso como tarefa para ele, mas acredito que não deve ter chegado a 30. E com um objetivo claro definido!
Além disso, com o pior caso possível poderemos propôr outro cenário de testes para tratá-lo. "O caso de teste 24 apresentou um aproveitamento de 30%. Para essa situação, iremos criar o cenário 2...".
Eu entendo que ele é um guri de 18 anos, entendo que a faculdade não ensina o pessoal a escrever, entendo que ele possa ter algumas dúvidas sobre os testes. Mas poxa, chegamos a essas conclusões do documento apenas pensando, imaginando a situação!! Reduzimos as variáveis apenas pensando!
Por que será que alguns dos meus funcionários teimam em não pensar um pouco nas tarefas que damos? A gente incentiva isso! Quando eu digo que as vezes fico desmotivado no trabalho, este é um dos principais motivos... as pessoas que nós gerenciamos parecem que não levam nada a sério.
Sábado, 26 de Abril de 2008
Implantação do SCRUM no laboratório - Parte X
Sexta-feira foi o nosso último dia da dinâmica de uma semana de SCRUM.
Por algumas das pessoas terem provas e trabalhos, ficamos bastante desfalcados. Além disso, um dos grupos teve que deixar uma user story de lado, por solicitação do coordenador, para realizar outra mais crítica.
Nem todos acabaram suas user stories. Mesmo assim, tentei fazer algo parecido com um sprint review (demo), mas foi feito da forma mais precária possível... por quê? Como não utilizamos index cards para detalhar as user stories, não deixamos claro o que seria o DoD (definição de finalizado - Definition of Done). Ou seja, não havia como mensurar ou quantificar se aquelas coisas prometidas estavam feitas de acordo.
Ou seja, a sprint review foi apenas uma formalidade. Não funcionou para nada.
A retrospectiva, por falta de tempo, também tive que adaptar de uma forma mais ágil do que já é! Ou seja, não foi uma retrospectiva, mas quase um feedback.
Juntei todos na sala de reuniões, expliquei que aquela retrospectiva era uma das partes mais importantes do SCRUM e expliquei que teríamos aquela reunião em grupos, não com todos como estava sendo. Falei que são levantados os pontos positivos, negativos e as sugestões de melhorias para o próximo sprint. Então pedi para cada um falar.
De positivo, quase todos disseram que se tratava de uma metodologia legal. Concordaram que a comunicação melhorou bastante, além de todos saberem o que tem que ser feito. Dos comentários um foi bem interessante: um falou que achou o fato das tarefas terem responsáveis muito boa. Por quê? Pois assim as "mijadas" (broncas) seriam endereçadas às pessoas certas. Na hora eu não havia entendido que era isso que ele tinha dito, quem em avisou foi o meu colega, posteriormente.
De negativo, algumas coisas foram levantadas por desconhecimento do SCRUM e outra por falta de crença na mesma! Um falou que achava difícil levantar user stories até o fim do projeto, pois elas mudariam durante o projeto. Então eu expliquei que ele havia entendido errado, pois as mudanças são inerentes aos projetos, principalmente de TI. E mostrei que nós levantamos as user stories, mas só nos preocupamos em detalhar aquelas que iremos fazer. As outras podem sofrer as mudanças que quiserem! Outro comentário foi de que eu e o meu colega estávamos muito ocupados fazendo as reuniões, e isso tirou um pouco a nossa disponibilidade para conversar ou tomar decisões com eles. Expliquei, então, que essa semana foi anormal. Nós estávamos ocupados por estarmos coordenando a implantação e que depois, com os papéis definidos, isso acabaria e nós teríamos muito mais tempo.
O meu colega levantou a última questão que ele achou negativa, mas falou em "private" comigo, após a reunião. Ele disse que estava descrente quanto à reunião diária. Disse que muitas pessoas poderiam acabar "enchendo o saco" de ter que falar todo o dia. E sugeriu a idéia de termos as reuniões na 2a, 4a e 6a. Eu falei que posteriormente, se identificarmos esse descontentamento, podemos analisar isso. Mas, sinceramente, DUVIDO que alguém reclame... a não ser que ele próprio não tenha gostado :)
De melhorias, além de questões de infra-estrutura (um espaço maior para a taskboard e um armário para guardarmos o material dos projetos e também nossas coisas) eles deram duas sugestões para o SCRUM.
O primeiro foi para termos o chart burndown. Como eu esperava, a equipe que já tinha conhecimento do SCRUM, gostou de ter o gráfico representando o andamento. Eu defendo este gráfico, não tanto como informativo, mas mais como agente motivador. É realmente legal ver o nosso andamento graficamente!
E a segunda sugestão foi de termos uma coluna intermediária, após o "DOING", que se chamaria "VERIFY". Teríamos então:
TO DO --- DOING --- VERIFY --- DONE
O "verify" serviria para alguém, possivelmente o Scrum Master ou líder técnico, checar se a tarefa/user story estava finalizada de acordo com o esperado. É bem interessante e faz com que os SM se tornem mais presentes no dia-a-dia... mesmo que ele não tenha conhecimento técnico, pode dizer "ok" ou "não ok". Basta que as tarefas sejam explícitas no que irão produzir.
Então encerramos a reunião e demos fim à nossa dinâmica. Prometi para a semana que vem realizarmos as reuniões para levantarmos o product backlog e já começarmos os sprints. Principalmente porque a diretoria está ansiosa por resultados... mas isso é comum né?!
Muito saiu do meu planejamento durante essa semana. Não consegui praticar as coisas com as equipes como eu queria. Tivemos um review e retrospectiva muito aquém do que devíamos ter... mas no mundo de tecnologia, tempo é algo precioso. E eu tenho que considerar isso. Se não dá para usar o tempo como gostaríamos, temos que nos adaptar de alguma forma.
E com o décimo capítulo, encerro essa "Implantação de SCRUM no laboratório". A partir de agora, irei descrever o dia-a-dia, mas também voltarei a discutir outros assuntos.
Espero que estes posts possam servir como referência e até lições aprendidas para muitos que anseiam em implantar o SCRUM em suas empresas e organizações. Não temam! Se algo ocorrer errado, adaptem. Essa é a palavra-chave.
Abraços!
Por algumas das pessoas terem provas e trabalhos, ficamos bastante desfalcados. Além disso, um dos grupos teve que deixar uma user story de lado, por solicitação do coordenador, para realizar outra mais crítica.
Nem todos acabaram suas user stories. Mesmo assim, tentei fazer algo parecido com um sprint review (demo), mas foi feito da forma mais precária possível... por quê? Como não utilizamos index cards para detalhar as user stories, não deixamos claro o que seria o DoD (definição de finalizado - Definition of Done). Ou seja, não havia como mensurar ou quantificar se aquelas coisas prometidas estavam feitas de acordo.
Ou seja, a sprint review foi apenas uma formalidade. Não funcionou para nada.
A retrospectiva, por falta de tempo, também tive que adaptar de uma forma mais ágil do que já é! Ou seja, não foi uma retrospectiva, mas quase um feedback.
Juntei todos na sala de reuniões, expliquei que aquela retrospectiva era uma das partes mais importantes do SCRUM e expliquei que teríamos aquela reunião em grupos, não com todos como estava sendo. Falei que são levantados os pontos positivos, negativos e as sugestões de melhorias para o próximo sprint. Então pedi para cada um falar.
De positivo, quase todos disseram que se tratava de uma metodologia legal. Concordaram que a comunicação melhorou bastante, além de todos saberem o que tem que ser feito. Dos comentários um foi bem interessante: um falou que achou o fato das tarefas terem responsáveis muito boa. Por quê? Pois assim as "mijadas" (broncas) seriam endereçadas às pessoas certas. Na hora eu não havia entendido que era isso que ele tinha dito, quem em avisou foi o meu colega, posteriormente.
De negativo, algumas coisas foram levantadas por desconhecimento do SCRUM e outra por falta de crença na mesma! Um falou que achava difícil levantar user stories até o fim do projeto, pois elas mudariam durante o projeto. Então eu expliquei que ele havia entendido errado, pois as mudanças são inerentes aos projetos, principalmente de TI. E mostrei que nós levantamos as user stories, mas só nos preocupamos em detalhar aquelas que iremos fazer. As outras podem sofrer as mudanças que quiserem! Outro comentário foi de que eu e o meu colega estávamos muito ocupados fazendo as reuniões, e isso tirou um pouco a nossa disponibilidade para conversar ou tomar decisões com eles. Expliquei, então, que essa semana foi anormal. Nós estávamos ocupados por estarmos coordenando a implantação e que depois, com os papéis definidos, isso acabaria e nós teríamos muito mais tempo.
O meu colega levantou a última questão que ele achou negativa, mas falou em "private" comigo, após a reunião. Ele disse que estava descrente quanto à reunião diária. Disse que muitas pessoas poderiam acabar "enchendo o saco" de ter que falar todo o dia. E sugeriu a idéia de termos as reuniões na 2a, 4a e 6a. Eu falei que posteriormente, se identificarmos esse descontentamento, podemos analisar isso. Mas, sinceramente, DUVIDO que alguém reclame... a não ser que ele próprio não tenha gostado :)
De melhorias, além de questões de infra-estrutura (um espaço maior para a taskboard e um armário para guardarmos o material dos projetos e também nossas coisas) eles deram duas sugestões para o SCRUM.
O primeiro foi para termos o chart burndown. Como eu esperava, a equipe que já tinha conhecimento do SCRUM, gostou de ter o gráfico representando o andamento. Eu defendo este gráfico, não tanto como informativo, mas mais como agente motivador. É realmente legal ver o nosso andamento graficamente!
E a segunda sugestão foi de termos uma coluna intermediária, após o "DOING", que se chamaria "VERIFY". Teríamos então:
TO DO --- DOING --- VERIFY --- DONE
O "verify" serviria para alguém, possivelmente o Scrum Master ou líder técnico, checar se a tarefa/user story estava finalizada de acordo com o esperado. É bem interessante e faz com que os SM se tornem mais presentes no dia-a-dia... mesmo que ele não tenha conhecimento técnico, pode dizer "ok" ou "não ok". Basta que as tarefas sejam explícitas no que irão produzir.
Então encerramos a reunião e demos fim à nossa dinâmica. Prometi para a semana que vem realizarmos as reuniões para levantarmos o product backlog e já começarmos os sprints. Principalmente porque a diretoria está ansiosa por resultados... mas isso é comum né?!
Muito saiu do meu planejamento durante essa semana. Não consegui praticar as coisas com as equipes como eu queria. Tivemos um review e retrospectiva muito aquém do que devíamos ter... mas no mundo de tecnologia, tempo é algo precioso. E eu tenho que considerar isso. Se não dá para usar o tempo como gostaríamos, temos que nos adaptar de alguma forma.
E com o décimo capítulo, encerro essa "Implantação de SCRUM no laboratório". A partir de agora, irei descrever o dia-a-dia, mas também voltarei a discutir outros assuntos.
Espero que estes posts possam servir como referência e até lições aprendidas para muitos que anseiam em implantar o SCRUM em suas empresas e organizações. Não temam! Se algo ocorrer errado, adaptem. Essa é a palavra-chave.
Abraços!
Sexta-feira, 25 de Abril de 2008
Implantação do SCRUM no laboratório - Parte IX - a
Falei que ontem de noite eu havia enviado um email para os meus chefes explicando o porque eu preferia que eles não fossem os "clientes" dessa dinâmica, pois temia que eles não entendessem que utilizamos a semana para eles vivenciarem o SCRUM e desenvolverem pequenas partes dos projetos em que atuam.
Recebi essa resposta por email:
"(...) Como cliente ancioso, gostaria de ver o andamento dos projetos durante esta semana. Pois, acredito que a adocao da metodologia foi um plus no trabalho de cada projeto e entendi que os projetos continuariam fncionando a toda carga. (...)".
A dificil arte de agradar gregos e troianos.
PARTE X
Recebi essa resposta por email:
"(...) Como cliente ancioso, gostaria de ver o andamento dos projetos durante esta semana. Pois, acredito que a adocao da metodologia foi um plus no trabalho de cada projeto e entendi que os projetos continuariam fncionando a toda carga. (...)".
A dificil arte de agradar gregos e troianos.
PARTE X
Quinta-feira, 24 de Abril de 2008
Implantação do SCRUM no laboratório - Parte IX
Segundo dia de sprint. Hoje eu já tentei deixá-los mais "a vontade". Em praticamente todos os grupos surgiram impedimentos, mas só em um deles era um impedimento real. Nos demais eu deixei claro a diferença entre impedimento e pró-atividade, novamente.
O grupo em que já possuia um gerente, eu os deixei à vontade para conduzir a reunião como eles preferissem. E acho que o resultado foi bacana... parece o grupo mais empolgado e ativo no SCRUM. Infelizmente é o grupo que possui mais atividades não-planejadas... muito por culpa do "cliente" deles.
Com o projeto de testes, em que temos uma pessoa só trabalhando, hoje fiz algo bastante interessante. Como se trata de um "gurizão" (como chamamos aqui no Sul :), já que tem menos de 20 anos, ele ainda está naquela fase de insegurança... o meu colega me passou uma idéia para os testes e eu apenas conduzi para que o responsável pelos testes tomasse a decisão que ele achava mais conveniente. Ou seja, ao invés de chegar e dizer "Ok, tu tens que fazer isso, isso e aquilo" eu apresentei duas propostas e na conversa com ele deixei-o decidir pela melhor. E ao mesmo tempo questionei o motivo. O resultado foi que chegamos na mesma conclusão. Foi o primeiro passo para a pró-atividade dele, espero!
No mais, foi um dia corrido, com diversas tarefas para fazer em paralelo. Exatamente o tipo de dia que eu gosto :)
Aliás, estou fazendo jus aquela máxima que diz que "o gerente de projetos é sempre aquele que nunca está na sua mesa". Estou sempre em reunião, em contato com meus subordinados, colegas, chefes... ou seja, em total comunicação. Hoje eu posso dizer tranquilamente o que cada uma das pessoas está fazendo dentro do laboratório. Ou seja, aparentemente o problema de comunicação está quase resolvido!
------------------------------------------------
Amanhã é o dia da sprint review (demo) e retrospectiva. Ainda não me preparei para isso, mas já avisei a eles que EU serei o cliente, ao contrário dos nossos chefes. O motivo? Não quero inibí-los... tanto os chefes quanto as equipes. Será difícil para os chefes entenderem que tivemos uma dinâmica nessa uma semana e, portanto, os "entregáveis" são bem pequenos, quase nada. E isso pode fazer com que passe a imagem de que o SCRUM não trouxe benefício nenhum. De lambuja, ainda pode desmotivar as equipes.
Avisei a todos, porém, que eu serei um cliente fiel. Vou dar o feedback necessário, conforme o que foi prometido. Eles tem que sentir, mesmo que de forma teatral, como seria a reação com um cliente caso eles não entreguem ou entreguem sem qualidade.
Vou até preparar um "checklist" de perguntas que farei ;)
----------------------------------------------------
Para a semana que vem pretendo criar o product backlog real com todas as equipes. Talvez demore a semana toda... mas gostaria de que na 5a e 6a pudessemos iniciar as reuniões já. Tomara que dê tempo.
Abraços a todos!
PARTE IX - a
O grupo em que já possuia um gerente, eu os deixei à vontade para conduzir a reunião como eles preferissem. E acho que o resultado foi bacana... parece o grupo mais empolgado e ativo no SCRUM. Infelizmente é o grupo que possui mais atividades não-planejadas... muito por culpa do "cliente" deles.
Com o projeto de testes, em que temos uma pessoa só trabalhando, hoje fiz algo bastante interessante. Como se trata de um "gurizão" (como chamamos aqui no Sul :), já que tem menos de 20 anos, ele ainda está naquela fase de insegurança... o meu colega me passou uma idéia para os testes e eu apenas conduzi para que o responsável pelos testes tomasse a decisão que ele achava mais conveniente. Ou seja, ao invés de chegar e dizer "Ok, tu tens que fazer isso, isso e aquilo" eu apresentei duas propostas e na conversa com ele deixei-o decidir pela melhor. E ao mesmo tempo questionei o motivo. O resultado foi que chegamos na mesma conclusão. Foi o primeiro passo para a pró-atividade dele, espero!
No mais, foi um dia corrido, com diversas tarefas para fazer em paralelo. Exatamente o tipo de dia que eu gosto :)
Aliás, estou fazendo jus aquela máxima que diz que "o gerente de projetos é sempre aquele que nunca está na sua mesa". Estou sempre em reunião, em contato com meus subordinados, colegas, chefes... ou seja, em total comunicação. Hoje eu posso dizer tranquilamente o que cada uma das pessoas está fazendo dentro do laboratório. Ou seja, aparentemente o problema de comunicação está quase resolvido!
------------------------------------------------
Amanhã é o dia da sprint review (demo) e retrospectiva. Ainda não me preparei para isso, mas já avisei a eles que EU serei o cliente, ao contrário dos nossos chefes. O motivo? Não quero inibí-los... tanto os chefes quanto as equipes. Será difícil para os chefes entenderem que tivemos uma dinâmica nessa uma semana e, portanto, os "entregáveis" são bem pequenos, quase nada. E isso pode fazer com que passe a imagem de que o SCRUM não trouxe benefício nenhum. De lambuja, ainda pode desmotivar as equipes.
Avisei a todos, porém, que eu serei um cliente fiel. Vou dar o feedback necessário, conforme o que foi prometido. Eles tem que sentir, mesmo que de forma teatral, como seria a reação com um cliente caso eles não entreguem ou entreguem sem qualidade.
Vou até preparar um "checklist" de perguntas que farei ;)
----------------------------------------------------
Para a semana que vem pretendo criar o product backlog real com todas as equipes. Talvez demore a semana toda... mas gostaria de que na 5a e 6a pudessemos iniciar as reuniões já. Tomara que dê tempo.
Abraços a todos!
PARTE IX - a
Quarta-feira, 23 de Abril de 2008
Implantação do SCRUM no laboratório - Parte VIII
Primeiro dia oficial do sprint relâmpago. Algumas constatações:
- Para a equipe que já possui experiência em SCRUM, utilizamos o tempo para levantar as atividades, coisa que ficou faltando ontem. Feito isso, encerrou-se a reunião com eles. Não há muito o que falar ou explicar.
- Para a equipe da API, a função principal foi introduzí-los ao daily scrum, sendo eles liderados pelo meu colega. Foi um momento interessante, onde eu apenas assisti e escutei. Ao final, expressei ao meu colega que ele cometera dois erros: discutiu assuntos técnicos DURANTE a reunião (o que fez com que perdessemos tempo nisso) e não questionou a equipe sobre impedimentos, esperou que eles mencionassem alguma coisa. Além disso, notei que a equipe falou como se estivesse se reportando ao gerente e não à própria equipe. Essa é uma das coisas mais difíceis de mudar no pessoal, mas acredito que eles vão estar sentindo a reunião como um acerto de ponteiros e não como um "report" em breve.
- Para a equipe de um projeto de HW, no qual o scrum master é o gerente da própria equipe, eu apenas expliquei rapidamente o que se tratava a daily scrum e depois solicitei ao scrum master que conduzisse a reunião, sendo que eu apenas escutaria e não iria intervir. Foi uma reunião bem bacana, para a primeira vez de todos ali! Levantamos tarefas não-planejadas, todos disseram o que fizeram e o que pretendem fazer para a amanhã e também levantamos o primeiro impedimento. Um dos projetos de HW foi modificado por um dos "chickens" (cliente) e ainda não foi reenviado para a equipe. Agora o scrum master terá já um impedimento para atacar. Depois da reunião, eles trataram rapidamente de assuntos técnicos, sendo bem como eu estava planejando. No final, um dos guris da equipe veio falar que a reunião estava sendo bem legal pois ele estava começando a se sentir mais "dentro" do projeto. Ele reclamou que no projeto anterior ele recebia demandas de diversas pessoas diferentes e no final era cobrado por uma delas só (que nunca estava pronta). É o tipo de pessoa que eu sempre escutei que "ele só fica na internet, não trabalha", mas acho que agora começo a entender que era um funcionário que estava com a motivação a dois palmos abaixo do fundo do poço. E noto nele um foco de motivação com essa mudança. Felizmente! E fico feliz por ele dar este feedback.
- Por fim, para o outro projeto, de testes, estamos com mais dúvidas do que soluções. Não sabemos ao certo o que testar, pois para qualquer caso são muitas variáveis envolvidas. Então decidimos começar do básico... testar uma antena por completa para saber TUDO sobre ela: potencia, angulo de atuação, leitura, etc. Mas perdemos boa parte da tarde discutindo. Como é um projeto em que apenas UMA pessoa está trabalhando não seria justo exigir algo muito pesado. Então a "user story" deste projeto para esse sprint relâmpago será a criação do plano de testes documentado.
==========================================
Hoje o meu colega, que está atuando comigo, também falou que uma das coisas que desmotiva aqui no trabalho é a falta de pró-atividade das pessoas. Ele comentou como é chato ter que estar sempre tendo que apontar os caminhos para os funcionários... lembram daquela máxima: "Traga-me soluções e não problemas"? Pois é, isso não se aplica aqui.
Mas isso é algo que quero atacar DEPOIS. Primeiro, é a comunicação.
Abraços
PARTE IX
- Para a equipe que já possui experiência em SCRUM, utilizamos o tempo para levantar as atividades, coisa que ficou faltando ontem. Feito isso, encerrou-se a reunião com eles. Não há muito o que falar ou explicar.
- Para a equipe da API, a função principal foi introduzí-los ao daily scrum, sendo eles liderados pelo meu colega. Foi um momento interessante, onde eu apenas assisti e escutei. Ao final, expressei ao meu colega que ele cometera dois erros: discutiu assuntos técnicos DURANTE a reunião (o que fez com que perdessemos tempo nisso) e não questionou a equipe sobre impedimentos, esperou que eles mencionassem alguma coisa. Além disso, notei que a equipe falou como se estivesse se reportando ao gerente e não à própria equipe. Essa é uma das coisas mais difíceis de mudar no pessoal, mas acredito que eles vão estar sentindo a reunião como um acerto de ponteiros e não como um "report" em breve.
- Para a equipe de um projeto de HW, no qual o scrum master é o gerente da própria equipe, eu apenas expliquei rapidamente o que se tratava a daily scrum e depois solicitei ao scrum master que conduzisse a reunião, sendo que eu apenas escutaria e não iria intervir. Foi uma reunião bem bacana, para a primeira vez de todos ali! Levantamos tarefas não-planejadas, todos disseram o que fizeram e o que pretendem fazer para a amanhã e também levantamos o primeiro impedimento. Um dos projetos de HW foi modificado por um dos "chickens" (cliente) e ainda não foi reenviado para a equipe. Agora o scrum master terá já um impedimento para atacar. Depois da reunião, eles trataram rapidamente de assuntos técnicos, sendo bem como eu estava planejando. No final, um dos guris da equipe veio falar que a reunião estava sendo bem legal pois ele estava começando a se sentir mais "dentro" do projeto. Ele reclamou que no projeto anterior ele recebia demandas de diversas pessoas diferentes e no final era cobrado por uma delas só (que nunca estava pronta). É o tipo de pessoa que eu sempre escutei que "ele só fica na internet, não trabalha", mas acho que agora começo a entender que era um funcionário que estava com a motivação a dois palmos abaixo do fundo do poço. E noto nele um foco de motivação com essa mudança. Felizmente! E fico feliz por ele dar este feedback.
- Por fim, para o outro projeto, de testes, estamos com mais dúvidas do que soluções. Não sabemos ao certo o que testar, pois para qualquer caso são muitas variáveis envolvidas. Então decidimos começar do básico... testar uma antena por completa para saber TUDO sobre ela: potencia, angulo de atuação, leitura, etc. Mas perdemos boa parte da tarde discutindo. Como é um projeto em que apenas UMA pessoa está trabalhando não seria justo exigir algo muito pesado. Então a "user story" deste projeto para esse sprint relâmpago será a criação do plano de testes documentado.
==========================================
Hoje o meu colega, que está atuando comigo, também falou que uma das coisas que desmotiva aqui no trabalho é a falta de pró-atividade das pessoas. Ele comentou como é chato ter que estar sempre tendo que apontar os caminhos para os funcionários... lembram daquela máxima: "Traga-me soluções e não problemas"? Pois é, isso não se aplica aqui.
Mas isso é algo que quero atacar DEPOIS. Primeiro, é a comunicação.
Abraços
PARTE IX
Terça-feira, 22 de Abril de 2008
Implantação do SCRUM no laboratório - Parte VII
Hoje foi o primeiro dia da "dinâmica".
Primeiramente, me deparei com alguns problemas operacionais. Comprei post-its (rosa, amarelo, laranja e um reciclável) e três cartolinas. As cartolinas eram pequenas... só vi na hora em que coloquei os post-its. Nada que atrapalhe para ESSA semana, mas para as demais, teremos que rever algumas coisas.
Bom, eu havia marcado para a partir das 14h começar a fazer as reuniões. 15h30 começamos, pois foi a hora que pelo menos UM dos grupos estava totalmente presente.
Eu cheguei as 13h. Fiquei montando os cartazes (taskboards) e pensando em formas de usar o processo no resto da semana. Essa demora para o pessoal chegar já me desmotivou um pouco. Eu noto que eles estão bem interessados em aplicar o SCRUM, mas por ser um laboratório de pesquisa, eles também se sentem descompromissados. É a velha reclamação sobre comprometimento... é dose, não sei mais como usar argumentos e conversar a respeito.
Nessas 1h30 (+/-) que fiquei sozinho, refleti sobre a dificuldade que terei em atingir os objetivos que pretendo. Por um lado eu encaro isso como um baita desafio... é aquela coisa de que temos que superar os limites com os recursos que temos, de ser posteriormente reconhecido por isso. Porém, ao mesmo tempo bate o desânimo em contar com pessoas que faltam um pouco com suas responsabilidades.
Bom, a reunião acabou sendo prejudicada também pois não consegui imprimir as index cards e nem as cartas para o planning poker. Então foi tudo improvisado. O feriado me atrapalhou um pouco e hoje de manhã acabei não tendo tempo de fazer isso.
A agenda foi a seguinte, com cada grupo: homologar as user stories, estimá-las com planning poker (só para eles saberem como funciona), gerar as tarefas e depois agendar a daily scrum.
Definimos que os post-its terão as seguintes cores:
AMARELO (padrão) : tarefas planejadas (planned tasks)
LARANJA : user stories
ROSA : tarefas não planejadas (unplanned tasks)
RECICLADOS : impedimentos
Cada tarefa deve ter no máximo 1 dia de duração, com no mínimo meio-dia. Definimos também que cada tarefa deverá ter só o nome da pessoa que está a fazendo, ou que responderá por ela (caso seja feita por mais de uma pessoa).
Um dos grupos foi bem tranquilo isso, o problema é que é o único projeto em que eu não tenho a menor idéia do que se trata. hehe
Outro grupo também foi tranquilo, pois foi o meu projeto piloto quando fiz a experiência com SCRUM. Eles já conhecem o processo todo.
Porém, nos outros três projetos tivemos problemas.
Um deles, decidimos momentaneamente tirar da dinâmica. Motivo? É um projeto muito teórico que é a base de dois mestrados e alguns trabalhos de conclusão e doutorado. Não consigo ver a geração de valor nele, pois haverá pesquisa, pesquisa e mais pesquisa. Seriam artefatos na forma de relatórios... além disso, as duas pessoas responsáveis não estão mais no laboratório, mas nas baias que servem para os mestrandos/doutorandos. Não teriam a taskboard à vista. E eles não possuem um gerente de projetos... essa é a figura direta de um dos coordenadores. Enfim, um projeto bem difícil e bem complicado para aplicar SCRUM. Decidimos deixá-lo de lado no momento.
O outro projeto trata exclusivamente de testes com RFID. Notamos que a pessoa (é uma só) responsável por ele, estava gerando testes e mais testes mas só obtendo dados... sem ter muita informação. Decidimos então criar cenários de testes, para homologarmos qual será a melhor configuração para captar o máximo de tags para aquela situação específica. Assim teremos um objetivo bem claro e um resultado aparente. Este projeto deixamos em separado, pois como envolve uma pessoa apenas, iremos exigir na dinâmica apenas um "ante-projeto" destes testes. Nada mais.
E por fim, o outro projeto problemático. O SCRUM prevê user stories onde representam a interação do sistema com o usuário. Exemplos de user stories, que achamos por aí:
"O usuário pode depositar o dinheiro na conta"
"O usuário pode definir quais são as pessoas que podem visualizar seu perfil"
"O usuário pode buscar livros pelo autor, nome do livro e código"
São coisas bem específicas e fáceis de visualizar. Mas um dos "projetos" é a criação de uma API para a comunicação da leitora de RFID com a antena. E aí, não há como definir um usuário!! Ficamos quase 1 hora em reunião para conseguir achar duas míseras user stories para essa situação e acabamos definindo coisas técnicas: a geração da versão em Java e a modelagem e estrutura padrão para as API's.
Nessa hora eu percebi como o conceito de user story precisa ser aprofundado por mim e pelo meu colega que está me auxiliando. Ainda temos dúvidas nesse tipo de situação. Um sistema pode ser um ator? E no caso de envolver só hardware ou este tipo de camada mais baixa? Criamos uma user story grandona (que suba até o alto nível) ou deixamos ela mais técnica mesmo? Questionamentos, questionamentos...
Foi um dia de reuniões, pra variar. Agora irei disparar um email avisando os grupos dos horários das daily scrum. E vamos começar a ver o que acontece. Tomara que todos consigam cumprir suas user stories, pois não estamos exigindo nada demais.
Vou levantar um questionário e tasklist de itens que precisamos levantar para a semana que vem, para termos uma taskboard direita e também para lembrarmos de coisas para a retrospectiva.
Ufa, o dia hoje foi isso. Conversa, conversa e um pouco de desmotivação...
Será que consigo mudar? O tempo dirá.
Um abraço a todos!
PARTE VIII
Primeiramente, me deparei com alguns problemas operacionais. Comprei post-its (rosa, amarelo, laranja e um reciclável) e três cartolinas. As cartolinas eram pequenas... só vi na hora em que coloquei os post-its. Nada que atrapalhe para ESSA semana, mas para as demais, teremos que rever algumas coisas.
Bom, eu havia marcado para a partir das 14h começar a fazer as reuniões. 15h30 começamos, pois foi a hora que pelo menos UM dos grupos estava totalmente presente.
Eu cheguei as 13h. Fiquei montando os cartazes (taskboards) e pensando em formas de usar o processo no resto da semana. Essa demora para o pessoal chegar já me desmotivou um pouco. Eu noto que eles estão bem interessados em aplicar o SCRUM, mas por ser um laboratório de pesquisa, eles também se sentem descompromissados. É a velha reclamação sobre comprometimento... é dose, não sei mais como usar argumentos e conversar a respeito.
Nessas 1h30 (+/-) que fiquei sozinho, refleti sobre a dificuldade que terei em atingir os objetivos que pretendo. Por um lado eu encaro isso como um baita desafio... é aquela coisa de que temos que superar os limites com os recursos que temos, de ser posteriormente reconhecido por isso. Porém, ao mesmo tempo bate o desânimo em contar com pessoas que faltam um pouco com suas responsabilidades.
Bom, a reunião acabou sendo prejudicada também pois não consegui imprimir as index cards e nem as cartas para o planning poker. Então foi tudo improvisado. O feriado me atrapalhou um pouco e hoje de manhã acabei não tendo tempo de fazer isso.
A agenda foi a seguinte, com cada grupo: homologar as user stories, estimá-las com planning poker (só para eles saberem como funciona), gerar as tarefas e depois agendar a daily scrum.
Definimos que os post-its terão as seguintes cores:
AMARELO (padrão) : tarefas planejadas (planned tasks)
LARANJA : user stories
ROSA : tarefas não planejadas (unplanned tasks)
RECICLADOS : impedimentos
Cada tarefa deve ter no máximo 1 dia de duração, com no mínimo meio-dia. Definimos também que cada tarefa deverá ter só o nome da pessoa que está a fazendo, ou que responderá por ela (caso seja feita por mais de uma pessoa).
Um dos grupos foi bem tranquilo isso, o problema é que é o único projeto em que eu não tenho a menor idéia do que se trata. hehe
Outro grupo também foi tranquilo, pois foi o meu projeto piloto quando fiz a experiência com SCRUM. Eles já conhecem o processo todo.
Porém, nos outros três projetos tivemos problemas.
Um deles, decidimos momentaneamente tirar da dinâmica. Motivo? É um projeto muito teórico que é a base de dois mestrados e alguns trabalhos de conclusão e doutorado. Não consigo ver a geração de valor nele, pois haverá pesquisa, pesquisa e mais pesquisa. Seriam artefatos na forma de relatórios... além disso, as duas pessoas responsáveis não estão mais no laboratório, mas nas baias que servem para os mestrandos/doutorandos. Não teriam a taskboard à vista. E eles não possuem um gerente de projetos... essa é a figura direta de um dos coordenadores. Enfim, um projeto bem difícil e bem complicado para aplicar SCRUM. Decidimos deixá-lo de lado no momento.
O outro projeto trata exclusivamente de testes com RFID. Notamos que a pessoa (é uma só) responsável por ele, estava gerando testes e mais testes mas só obtendo dados... sem ter muita informação. Decidimos então criar cenários de testes, para homologarmos qual será a melhor configuração para captar o máximo de tags para aquela situação específica. Assim teremos um objetivo bem claro e um resultado aparente. Este projeto deixamos em separado, pois como envolve uma pessoa apenas, iremos exigir na dinâmica apenas um "ante-projeto" destes testes. Nada mais.
E por fim, o outro projeto problemático. O SCRUM prevê user stories onde representam a interação do sistema com o usuário. Exemplos de user stories, que achamos por aí:
"O usuário pode depositar o dinheiro na conta"
"O usuário pode definir quais são as pessoas que podem visualizar seu perfil"
"O usuário pode buscar livros pelo autor, nome do livro e código"
São coisas bem específicas e fáceis de visualizar. Mas um dos "projetos" é a criação de uma API para a comunicação da leitora de RFID com a antena. E aí, não há como definir um usuário!! Ficamos quase 1 hora em reunião para conseguir achar duas míseras user stories para essa situação e acabamos definindo coisas técnicas: a geração da versão em Java e a modelagem e estrutura padrão para as API's.
Nessa hora eu percebi como o conceito de user story precisa ser aprofundado por mim e pelo meu colega que está me auxiliando. Ainda temos dúvidas nesse tipo de situação. Um sistema pode ser um ator? E no caso de envolver só hardware ou este tipo de camada mais baixa? Criamos uma user story grandona (que suba até o alto nível) ou deixamos ela mais técnica mesmo? Questionamentos, questionamentos...
Foi um dia de reuniões, pra variar. Agora irei disparar um email avisando os grupos dos horários das daily scrum. E vamos começar a ver o que acontece. Tomara que todos consigam cumprir suas user stories, pois não estamos exigindo nada demais.
Vou levantar um questionário e tasklist de itens que precisamos levantar para a semana que vem, para termos uma taskboard direita e também para lembrarmos de coisas para a retrospectiva.
Ufa, o dia hoje foi isso. Conversa, conversa e um pouco de desmotivação...
Será que consigo mudar? O tempo dirá.
Um abraço a todos!
PARTE VIII
Sábado, 19 de Abril de 2008
Implantação do SCRUM no laboratório - Parte VI
Conforme o planejado, hoje foi o dia em que sentamos com cada uma das equipes (definimos que teremos CINCO projetos) e definimos quais seriam as user stories que eles teriam que cumprir até o fim.
Usei bastante o conceito do livro "User stories" do Mike Cohn, onde ele geralmente descreve uma user story com "Um usuário [pode/deve] [fa
Usei bastante o conceito do livro "User stories" do Mike Cohn, onde ele geralmente descreve uma user story com "Um usuário [pode/deve] [fa