Já venho discutindo e analisando esse assunto a pelo menos dois meses. Quando eu me detive um pouco mais para entender a Lei de Little percebi pelo menos duas coisas: é perigoso nos basearmos tanto em algo que foi provado por negação - não ser verificado nenhum caso onde a lei não se aplica; e sua adoção em sistemas complexos e, consequentemente, para justificar algumas práticas do Kanban, é questionável. Pelo menos eu estou questionando.
terça-feira, 13 de agosto de 2013
segunda-feira, 12 de agosto de 2013
Por que prefiro quadros físicos?
A pergunta é pertinente e me pego frequentemente explicando estes motivos. Então nada mais justo que surgir uma "curtinha" no blog. É óbvio que o quadro eletrônico tem suas vantagens, como facilidade para times distribuídos e geração automática de gráficos complicados, como um CFD, mas na minha experiência, sempre que possível, opte pelo físico. Por que?
- Normalmente é mais barato. Até softwares gratuitos exigem um servidor, backup de dados, etc.;
- Mais fácil de usar que um software, particularmente por pessoas menos técnicas e por aquelas que estão envolvidas esporadicamente;
- Mais fácil de customizar. Escreva nele, adicione um post-it, adicione outros tipos de adesivos, etc. e pronto. A maioria dos pacotes de software são menos flexíveis ou necessitam de customização da empresa que fornece;
- Mais visível. Um quadro em uma área comum é algo que as pessoas vêem todos os dias e o dia todo. Isso reforça as tarefas em andamento, comunica o processo e impressiona até quem está fora do time. Com isso, torna as dores mais visíveis e ajuda na argumentação para resolve-las. Age como um ponto focal - um campo de batalha do time, onde podem as pessoas podem se reunir e discutir possíveis problemas e riscos;
- Um ponto menor, mas a maioria das pessoas gostam da satisfação do tato de mover o post-it de uma coluna para outra e da criatividade em desenhar figuras e símbolos para mostrar o status ou impedimentos, em vez de apenas olhar para colunas de texto;
- Mesmo que optássemos por uma TV, para demonstrarmos toda as informações disponíveis em alguns quadros físicos, precisaríamos de pelo menos 4 TVs - uma para o fluxo principal, uma para o fluxo de issues da daily, uma para o fluxo das retrospectivas e uma para os gráficos.
Os quadros de vários projetos onde atuo como consultor são muito ricos e com a passagem destes quadros para o meio eletrônico perderíamos muita informação.
Bem, é isso. E você? Prefere o eletrônico? Por que?
quinta-feira, 11 de julho de 2013
Transição - Não existem métodos porta de entrada
Tenho visto uma onda de pensamentos modernos sobre como iniciar uma transição ágil. Modernos se estivéssemos na década passada. Parece que voltou a "moda" de que o Scrum seria uma boa porta de entrada dos métodos ágeis nas empresas. Apesar de respeitar quem pense dessa forma, eu tenho as minhas dúvidas. Para esse post, chega de rapidinhas.
quarta-feira, 3 de julho de 2013
Transição Ágil x Evolução Ágil
Muito tenho discutido ultimamente sobre o uso do termo transição para indicar um processo de mudança do processo tradicional para o processo moderno de desenvolvimento de software.
Como transição entendemos uma mudança do estado A para o estado B. No nosso caso, da cultura tradicional para a cultura moderna de gerenciamento de softwares.
Os defensores do termo "evolução" argumentam que não conseguimos definir um ponto B claro. Que na verdade o processo é mais evolutivo que transicional. Como eu já disse em alguns fóruns de discussão (e em discussões de mesa de bar), não acho que essa abordagem esteja incorreta. Mas também não acho que usar o termo transição esteja. O motivo é bem simples: eu costumo definir de forma clara o ponto B.
O ponto B, na minha visão, ocorre quando a empresa tem consciência de que é um sistema complexo, valoriza a descentralização, a auto-organização e tem clara ciência do processo de melhoria contínua evolutivo, de como ele ocorre e o que precisa fazer para fomentá-lo. E neste momento, acontece a mágica, aconteceu a transição.
A empresa não precisa mais de um consultor para indicar que é necessário um diagnóstico contínuo do processo. Não precisa de um consultor para dizer que precisa identificar a restrição no sistema. Não precisa mais de um consultor para dizer que é preciso submeter o sistema à restrição. A empresa, como "entidade" se tornou um Jonah. Existe um capítulo inteiro no livro do Goldratt, Theory of Constraints, sobre como se tornar um Jonah. Estou pensando em escrever sobre esse capítulo, pois procurei referências para linkar aqui e não encontrei. Se algum leitor desse singelo espaço conhecer/encontrar, fique a vontade para colocar nos comentários.
Como a transição, na maioria dos casos, acontece como uma evolução do ponto A para o B, os conceitos se intercalam. Eu não passo a adotar o termo evolução em vez de transição porque transição me remete a algo infinito e, na minha visão, o trabalho de um bom consultor/consultoria deve ser finito. O consultor precisa ser capaz de deixar a empresa independente, sendo capaz de conduzir a sua própria evolução, seu próprio processo de melhoria contínua. Quando a empresa acordar para o kaizen e souber como conduzi-lo, a transição estará terminada e teremos apenas a evolução.
Enfim esta é a justificativa do motivo pelo qual uso o termo transição e vou continuar usando, pois ninguém ainda me convenceu a não usar.
Como transição entendemos uma mudança do estado A para o estado B. No nosso caso, da cultura tradicional para a cultura moderna de gerenciamento de softwares.
Os defensores do termo "evolução" argumentam que não conseguimos definir um ponto B claro. Que na verdade o processo é mais evolutivo que transicional. Como eu já disse em alguns fóruns de discussão (e em discussões de mesa de bar), não acho que essa abordagem esteja incorreta. Mas também não acho que usar o termo transição esteja. O motivo é bem simples: eu costumo definir de forma clara o ponto B.
O ponto B, na minha visão, ocorre quando a empresa tem consciência de que é um sistema complexo, valoriza a descentralização, a auto-organização e tem clara ciência do processo de melhoria contínua evolutivo, de como ele ocorre e o que precisa fazer para fomentá-lo. E neste momento, acontece a mágica, aconteceu a transição.
A empresa não precisa mais de um consultor para indicar que é necessário um diagnóstico contínuo do processo. Não precisa de um consultor para dizer que precisa identificar a restrição no sistema. Não precisa mais de um consultor para dizer que é preciso submeter o sistema à restrição. A empresa, como "entidade" se tornou um Jonah. Existe um capítulo inteiro no livro do Goldratt, Theory of Constraints, sobre como se tornar um Jonah. Estou pensando em escrever sobre esse capítulo, pois procurei referências para linkar aqui e não encontrei. Se algum leitor desse singelo espaço conhecer/encontrar, fique a vontade para colocar nos comentários.
Como a transição, na maioria dos casos, acontece como uma evolução do ponto A para o B, os conceitos se intercalam. Eu não passo a adotar o termo evolução em vez de transição porque transição me remete a algo infinito e, na minha visão, o trabalho de um bom consultor/consultoria deve ser finito. O consultor precisa ser capaz de deixar a empresa independente, sendo capaz de conduzir a sua própria evolução, seu próprio processo de melhoria contínua. Quando a empresa acordar para o kaizen e souber como conduzi-lo, a transição estará terminada e teremos apenas a evolução.
Enfim esta é a justificativa do motivo pelo qual uso o termo transição e vou continuar usando, pois ninguém ainda me convenceu a não usar.
terça-feira, 2 de julho de 2013
Rapidinha - Será que você sabe o que é um silo?
Hoje vi algo que me deixou preocupado. Em uma comunidade que fala de agilidade, vi o assunto silo surgir de uma forma estranha. Silos em nada se parece com divisão de frentes de trabalho. Silos não se comunicam, silos são isolados. Divisão em frentes de trabalho é uma forma de lidar com a complexidade: descentralização.
Quando estamos lidando com sistemas complexos, quanto mais centralizamos decisões e ações, caminhamos a passos largos para o caos. Da mesma forma, se você acredita que ser multidisciplinar é ter um bolo de atividades e um bolo de pessoas "puxando", você também me parece caminhar a passos largos para o caos.
Multidisciplinaridade pode (e deve) acontecer com frentes de trabalho. Trazendo um pouco dos conceitos do Kanban para este post, se temos um limite ideal do work-in-progress, alguém ficou ocioso e não pode puxar mais nenhuma atividade, esse alguém vai ajudar na etapa do processo onde o gargalo apareceu. Essa técnica também tem um pé na teoria das restrições:
Como eu prometi, esse post seria uma rapidinha. Discussões serão muito bem vindas nos comentários.
Até a próxima.
Quando estamos lidando com sistemas complexos, quanto mais centralizamos decisões e ações, caminhamos a passos largos para o caos. Da mesma forma, se você acredita que ser multidisciplinar é ter um bolo de atividades e um bolo de pessoas "puxando", você também me parece caminhar a passos largos para o caos.
Multidisciplinaridade pode (e deve) acontecer com frentes de trabalho. Trazendo um pouco dos conceitos do Kanban para este post, se temos um limite ideal do work-in-progress, alguém ficou ocioso e não pode puxar mais nenhuma atividade, esse alguém vai ajudar na etapa do processo onde o gargalo apareceu. Essa técnica também tem um pé na teoria das restrições:
- Identify the system's constraint(s) (that which prevents the organization from obtaining more of the goal in a unit of time)
- Decide how to exploit the system's constraint(s) (how to get the most out of the constraint)
- Subordinate everything else to the above decision (align the whole system or organization to support the decision made above)
- Elevate the system's constraint(s) (make other major changes needed to increase the constraint's capacity)
- Warning! If in the previous steps a constraint has been broken, go back to step 1, but do not allow inertia to cause a system's constraint.
Como eu prometi, esse post seria uma rapidinha. Discussões serão muito bem vindas nos comentários.
Até a próxima.
quarta-feira, 5 de junho de 2013
Uma pequena história de transição
Eis que ontem, se aproxima de mim, com uma expressão de ótimas intenções, uma menina de QA que me diz:
- Celso, estamos com a intenção de implementar Lean Six-Sigma aqui e gostaria de verificar como deixar as métricas aderentes ao processo de desenvolvimento ágil que a empresa está implementando;
- Ok, eu disse desconfiado. Mas de quem partiu essa iniciativa?
- Do meu diretor.
- Ok, podemos falar amanhã de 9hs as 10hs?
- Marcado.
E hoje cheguei para a reunião, com todas as cicatrizes que outras transições me infligiram.
Ela começa a reunião e no primeiro slide começa a falar sobre as métricas e sobre como medir a performance individual, eficiência individual, etc.
Falou por 10 minutos e não saiu do primeiro slide.
Levantei pedindo a palavra para explicar os princípios e valores daquilo para onde estamos transicionando. Expliquei sobre lead time, throughput, pontos de bug por pontos de história (sim, Agile-MMA), sobre times de fato e sobre o quanto é nociva para a empresa a medição individual. Expliquei sobre times cross funcionais, sobre como poderíamos chegar até isso e que métricas individuais atrapalhariam e muito nesse objetivo.
Expliquei como a área de QA deveria atuar neste novo contexto, buscando oportunidades de melhoria no fluxo e não medindo e apontando dedo para desenvolvedores. Falei que em muito breve QA estaria definitivamente no contexto do time e como os testers agora abraçariam o desenvolvimento, iniciando o fluxo e terminando-o e, principalmente, colaborando para o resultado final e não fazendo uma caça as bruxas.
Expliquei um pouco sobre o Lean, sobre o que eu acho do Lean Six Sigma e que, apesar de não gostar muito, ele está aderente ao nosso discurso de transição.
Então ela me disse que estava adaptando o Lean Six-Sigma ao modelo atual de trabalho deles e que conversaria com blackbelts sobre isso. Tirem suas conclusões. Por questões éticas, não vou colocar aqui as minhas.
Enfim, ela saiu da reunião espantada e disse que nada do que estavam fazendo estava aderente às minhas explicações. Ela fechou o notebook e uma reunião entre diretores será marcada e os pontos ajustados.
De uma coisa eu tenho certeza: Essa menina nunca mais será a mesma.
- Celso, estamos com a intenção de implementar Lean Six-Sigma aqui e gostaria de verificar como deixar as métricas aderentes ao processo de desenvolvimento ágil que a empresa está implementando;
- Ok, eu disse desconfiado. Mas de quem partiu essa iniciativa?
- Do meu diretor.
- Ok, podemos falar amanhã de 9hs as 10hs?
- Marcado.
E hoje cheguei para a reunião, com todas as cicatrizes que outras transições me infligiram.
Ela começa a reunião e no primeiro slide começa a falar sobre as métricas e sobre como medir a performance individual, eficiência individual, etc.
Falou por 10 minutos e não saiu do primeiro slide.
Levantei pedindo a palavra para explicar os princípios e valores daquilo para onde estamos transicionando. Expliquei sobre lead time, throughput, pontos de bug por pontos de história (sim, Agile-MMA), sobre times de fato e sobre o quanto é nociva para a empresa a medição individual. Expliquei sobre times cross funcionais, sobre como poderíamos chegar até isso e que métricas individuais atrapalhariam e muito nesse objetivo.
Expliquei como a área de QA deveria atuar neste novo contexto, buscando oportunidades de melhoria no fluxo e não medindo e apontando dedo para desenvolvedores. Falei que em muito breve QA estaria definitivamente no contexto do time e como os testers agora abraçariam o desenvolvimento, iniciando o fluxo e terminando-o e, principalmente, colaborando para o resultado final e não fazendo uma caça as bruxas.
Expliquei um pouco sobre o Lean, sobre o que eu acho do Lean Six Sigma e que, apesar de não gostar muito, ele está aderente ao nosso discurso de transição.
Então ela me disse que estava adaptando o Lean Six-Sigma ao modelo atual de trabalho deles e que conversaria com blackbelts sobre isso. Tirem suas conclusões. Por questões éticas, não vou colocar aqui as minhas.
Enfim, ela saiu da reunião espantada e disse que nada do que estavam fazendo estava aderente às minhas explicações. Ela fechou o notebook e uma reunião entre diretores será marcada e os pontos ajustados.
De uma coisa eu tenho certeza: Essa menina nunca mais será a mesma.
quinta-feira, 2 de maio de 2013
Transição - Como buscar uma boa reunião diária?
Em uma transição, é natural esperarmos diversos níveis de maturidade nas cerimônias e modus operandi de times diferentes. Uns estão mais maduros, outros menos. Dessa forma, compilei aqui alguns pontos de atenção que identifiquei em times ágeis em transição, em vários níveis de maturidade.
sábado, 16 de março de 2013
Os passos para uma transição ágil
Muito se fala sobre agilidade, principalmente desde o manifesto. As pessoas já vinham há uma década buscando formas diferentes de desenvolver software, como Scrum e a Extreme Programming. Mas em 2001, o conhecimento da época foi "verbalizado" pelo manifesto, na forma de 4 valores e 12 princípios.
Não, esse não é mais um texto sobre agilidade e seus princípios. Percebi que muito barulho foi feito em cima dessa nova forma de desenvolver software, muitas empresas nasceram ágeis, mas muito pouco foi falado sobre como realizar uma transição do modelo tradicional para o modelo ágil.
Não, esse não é mais um texto sobre agilidade e seus princípios. Percebi que muito barulho foi feito em cima dessa nova forma de desenvolver software, muitas empresas nasceram ágeis, mas muito pouco foi falado sobre como realizar uma transição do modelo tradicional para o modelo ágil.
quinta-feira, 31 de janeiro de 2013
Especialistas não servem para transição
O Kanban parece estar se direcionando para outra estrada que considero perigosa: os níveis de maturidade/profundidade no sistema. O perigo nessa abordagem reside, na minha visão, na facilitação para o aparecimento do xiitismo, além de ter pouca eficiencia. Mas isso é assunto para outro dia.
É interessante termos especialistas, como sempre foi interessante em todas as áreas e em todos os tempos. O problema é que esse tipo de mindset simplesmente não serve para uma transição. Disso estou convencido.
Vamos inicialmente deixar claro quem estou chamando de generalistas, especialistas e o que é essa transição.
Quando começo um trabalho de change agent em uma empresa, um dos maiores princípios da abordagem dos sistemas complexos, norteia as minhas ações: observar como o sistema se comporta para então sugerir mudanças. Esse "detalhe" é tão importante que pode significar o sucesso ou o fracasso de uma transição. Precisamos entender que o sistema está acostumado a se comportar daquela forma. As pessoas estão acostumadas a se comportarem daquela forma. Uma ruptura imediata, vai gerar stress no sistema. Uma transição já gera stress demasiado e não precisamos de change agents gerando mais stress. Na verdade, o papel dessa figura é justamente aliviar a tensão que toda a mudança naturalmente gera.
O sistema é elástico, está sofrendo tensão e está ansioso para voltar ao seu estado inicial. Se tentarmos gerar uma ruptura logo de início, vamos obter como resposta uma resistência (natural) e a tendencia é de tudo voltar a ser como era antes. Entretanto, se tentarmos a abordagem do sapo fervido, temos uma chance muito maior de que a ruptura aconteça sem o sistema perceber. E o melhor: com as pessoas que antes eram resistentes, vendendo as novas idéias como se fossem delas.
Isso quer dizer que não precisamos mais de especialistas no mundo? Não, precisamos de especialistas. Mas especialistas não podem atuar como change agents. Os especialistas não terão independência suficiente das suas especialidades para se afastar do sistema (como nos afastamos de um desenho ou quadro) e buscar a melhor opção. Em uma transição, os generalistas chegam primeiro e os especialistas depois.
Entretanto, neste contexto, os generalistas precisam ser especialistas em uma área de atuação: o pensamento sistêmico e sua derivação, os sistemas complexos. Esse cara precisa saber como analisar o comportamento do sistema e que tipo de mudança será mais eficiente e gerará menos impacto. A consolidação dessas pequenas mudanças e, principalmente, os seus resultados, serão responsáveis por fortalecer o processo de transição e dará aos responsáveis estratégicos da empresa a percepção de que esse processo está indo no caminho certo.
Estou convencido que esse mindset contribui sobremaneira para a implantação dos princípios do Lean, com uma cadência adequada ao contexto, sem rupturas bruscas que poderiam levar uma grande empresa a falência.
É interessante termos especialistas, como sempre foi interessante em todas as áreas e em todos os tempos. O problema é que esse tipo de mindset simplesmente não serve para uma transição. Disso estou convencido.
Vamos inicialmente deixar claro quem estou chamando de generalistas, especialistas e o que é essa transição.
- Generalistas: Pessoas que conhecem diversos métodos/sistemas/processos/frameworks para desenvolvimento de software ágil, saindo do waterfall que teve a sua importância na sua época, mas que hoje é reconhecidamente ultrapassado e ineficiente;
- Especialistas: Pessoas que conhecem apenas um método/sistema/processo/framework para desenvolvimento de software ágil;
- Transição: Processo onde uma empresa quer mudar do waterfall para outra forma mais eficiente de desenvolvimento de softwares, comumente próximo do Lean.
Quando começo um trabalho de change agent em uma empresa, um dos maiores princípios da abordagem dos sistemas complexos, norteia as minhas ações: observar como o sistema se comporta para então sugerir mudanças. Esse "detalhe" é tão importante que pode significar o sucesso ou o fracasso de uma transição. Precisamos entender que o sistema está acostumado a se comportar daquela forma. As pessoas estão acostumadas a se comportarem daquela forma. Uma ruptura imediata, vai gerar stress no sistema. Uma transição já gera stress demasiado e não precisamos de change agents gerando mais stress. Na verdade, o papel dessa figura é justamente aliviar a tensão que toda a mudança naturalmente gera.
O sistema é elástico, está sofrendo tensão e está ansioso para voltar ao seu estado inicial. Se tentarmos gerar uma ruptura logo de início, vamos obter como resposta uma resistência (natural) e a tendencia é de tudo voltar a ser como era antes. Entretanto, se tentarmos a abordagem do sapo fervido, temos uma chance muito maior de que a ruptura aconteça sem o sistema perceber. E o melhor: com as pessoas que antes eram resistentes, vendendo as novas idéias como se fossem delas.
Isso quer dizer que não precisamos mais de especialistas no mundo? Não, precisamos de especialistas. Mas especialistas não podem atuar como change agents. Os especialistas não terão independência suficiente das suas especialidades para se afastar do sistema (como nos afastamos de um desenho ou quadro) e buscar a melhor opção. Em uma transição, os generalistas chegam primeiro e os especialistas depois.
Entretanto, neste contexto, os generalistas precisam ser especialistas em uma área de atuação: o pensamento sistêmico e sua derivação, os sistemas complexos. Esse cara precisa saber como analisar o comportamento do sistema e que tipo de mudança será mais eficiente e gerará menos impacto. A consolidação dessas pequenas mudanças e, principalmente, os seus resultados, serão responsáveis por fortalecer o processo de transição e dará aos responsáveis estratégicos da empresa a percepção de que esse processo está indo no caminho certo.
Estou convencido que esse mindset contribui sobremaneira para a implantação dos princípios do Lean, com uma cadência adequada ao contexto, sem rupturas bruscas que poderiam levar uma grande empresa a falência.
segunda-feira, 27 de agosto de 2012
O Poder da Iteração
Depois de um pouco mais de um ano com o meu cliente que trabalha com gerenciamento de risco, rastreamento de frotas por GPS, estou aos poucos conseguindo demonstrar o poder do desenvolvimento iterativo. Neste sistema estamos, gradualmente, aumentando o nosso amadurecimento nos processos ágeis. Sim, não adianta apenas uma pessoa ser experiente em determinado assunto. O que importa é o time. O todo não é a soma das partes, mas a soma da interação entre elas.
sexta-feira, 24 de agosto de 2012
[Resenha] Using Kanban to Turn Around Distressed Projects
O autor deste artigo, Steve Andrews, abordou um assunto que me interessa bastante: transição ágil. Neste post vou colocar os meus comentários sobre os pontos que achei interessante e vou terminar com uma observação que julgo importante, mas que aparentemente foi excluida pelo autor do artigo, depois que fiz o comentário no site.
sexta-feira, 10 de agosto de 2012
Consultoria Ágil
Amanhã nossa empresa iniciará mais um trabalho de consultoria ágil em um cliente. Durante o contato inicial, o cliente informou que pretende tocar um projeto novo observando os princípios da XP. Isso foi uma boa notícia. Adicionalmente, vou sugerir o Kanban como sistema de melhoria contínua do processo da empresa.
A idéia central deste trabalho é:
A idéia central deste trabalho é:
- Coach com um dos donos, alinhando expectativas. A principio esta pessoa será o gerente deste projeto (Gestão 3.0);
- Explicar o que é e como aplicar o Gerenciamento 3.0;
- Mentoring em XP;
- Mentoring em Kanban e Lean;
- Auxilizar na análise e acompanhamento do lead time;
- Respeito as pessoas;
- Oberservação e ação nos estágios de Tuckman para formação de times ágeis;
- Mentoring na formação dos times, com possível aplicação de técnicas AgileMMA;
- Análise do valor;
- Análise e mapeamento do fluxo de valor;
- Mentoring em definição de metas;
- Motivação intrinseca;
- Débito técnico;
- Princípios importantes do desenvolvimento de software, principalmente SOLID e DDD (possivel treinamento);
sexta-feira, 6 de julho de 2012
Que tipo de profissionais de TI as empresas de sucesso contratam?
Esse texto é de autoria da minha amiga Annelise Gripp, ScrumMaster na globo.com, e fala sobre como as empresas 2.0 contratam. Ela escreveu tão bem sobre isso na RioAgile que pedi um texto para publicar:
"Estou no mundo de TI desde 1994, quando usavamos o famoso XT. Nessa época, me lembro bem, que as empresas não se preocupavam com o comportamento dos desenvolvedores. O importante era ser técnico, programar em alguma linguagem (cobol, basic) e entregar no prazo. Não era levado em consideração seus aspectos comportamentais ou seu conhecimento sobre o produto. As pessoas mau se olhavam e cumprimentavam. Pois bem, passamos decadas com esse tipo de profissional e acreditem, eles ainda existem na maioria das empresas....
Reparem se as empresas que mantem esse tipo de funcionário, obtem sucesso no mercado da tecnologia. Com certeza a sua resposta será NÃO!
Partindo dessa análise, posso confirmar pra vocês que o fator de sucesso de grandes empresas como a Globo.com estão nas pessoas. Pessoas que além de ter um vasto conhecimento técnico possuem aspectos comportamentais de grande valor como: boa comunicação, boa integração, trabalham bem em equipe, adquirem e repassam conhecimentos e experiências, participam de cursos e palestras, enfim, pessoas que se socializam, que compartilham para conquistar.
Logo, o processo de contratação de um novo desenvolvedor, que eu faço com o time, consiste em 3 etapas: na primeira etapa, fazemos uma entrevista por skype (voz e vídeo). Perguntamos sobre a vida profissional, conhecimentos e experiencias. Depois passamos uns exercícios de lógica que o desenvolvedor pode fazer em qualquer linguagem. Essa primeira etapa leva mais ou menos 1h e 30 minutos. O candidato só vai para a segunda etapa, caso tenha passado pela primeira. A segunda etapa consiste em avaliar o conhecimento do desenvolvedor para aquela vaga especifica. Um exemplo: se temos uma vaga para desenvolvedor client-side, enviamos para o candidato um exercício com foco em client. Se for uma vaga para server-side, enviamos para o candidato um exercício com foco em server. O candidato tem 24 horas para retornar por email os exercicios prontos. O próprio time constroi e avalia o exercício do candidato. Caso o candidato tenha passado nos exercícios, nós convidamos e pagamos a passagem do candidato para passar 1 dia conosco. Ele chega de manhã, participa do daily meeting, pega tarefas para fazer com o time e retorna para casa no fim do dia. Damos o resultado logo depois.
Profissionais que passam por esse processo com sucesso são contratados, pois eles trazem dinamismo e criatividade para a organização. O trabalho flui com naturalidade e o ambiente se torna seguro, colaborativo, para ele e para o time. Surgem novos produtos, novas propostas, novas tecnologias, satisfação e orgulho de fazer parte daquela empresa.
O trabalho de um lider coach ou de um scrum master é captar esses profissionais no mercado, desenvolver as pessoas que integram o seu time, nos dois aspectos, tecnico e comportamental. É fazer com que pessoas com personalidades diferentes, trabalhem juntas para alcançar uma única meta. Logo, se encontramos profissionais com potencial no mercado, contratamos imediatamente e integramos a equipe."
Obrigado Anne!
"Estou no mundo de TI desde 1994, quando usavamos o famoso XT. Nessa época, me lembro bem, que as empresas não se preocupavam com o comportamento dos desenvolvedores. O importante era ser técnico, programar em alguma linguagem (cobol, basic) e entregar no prazo. Não era levado em consideração seus aspectos comportamentais ou seu conhecimento sobre o produto. As pessoas mau se olhavam e cumprimentavam. Pois bem, passamos decadas com esse tipo de profissional e acreditem, eles ainda existem na maioria das empresas....
Reparem se as empresas que mantem esse tipo de funcionário, obtem sucesso no mercado da tecnologia. Com certeza a sua resposta será NÃO!
Partindo dessa análise, posso confirmar pra vocês que o fator de sucesso de grandes empresas como a Globo.com estão nas pessoas. Pessoas que além de ter um vasto conhecimento técnico possuem aspectos comportamentais de grande valor como: boa comunicação, boa integração, trabalham bem em equipe, adquirem e repassam conhecimentos e experiências, participam de cursos e palestras, enfim, pessoas que se socializam, que compartilham para conquistar.
Logo, o processo de contratação de um novo desenvolvedor, que eu faço com o time, consiste em 3 etapas: na primeira etapa, fazemos uma entrevista por skype (voz e vídeo). Perguntamos sobre a vida profissional, conhecimentos e experiencias. Depois passamos uns exercícios de lógica que o desenvolvedor pode fazer em qualquer linguagem. Essa primeira etapa leva mais ou menos 1h e 30 minutos. O candidato só vai para a segunda etapa, caso tenha passado pela primeira. A segunda etapa consiste em avaliar o conhecimento do desenvolvedor para aquela vaga especifica. Um exemplo: se temos uma vaga para desenvolvedor client-side, enviamos para o candidato um exercício com foco em client. Se for uma vaga para server-side, enviamos para o candidato um exercício com foco em server. O candidato tem 24 horas para retornar por email os exercicios prontos. O próprio time constroi e avalia o exercício do candidato. Caso o candidato tenha passado nos exercícios, nós convidamos e pagamos a passagem do candidato para passar 1 dia conosco. Ele chega de manhã, participa do daily meeting, pega tarefas para fazer com o time e retorna para casa no fim do dia. Damos o resultado logo depois.
Profissionais que passam por esse processo com sucesso são contratados, pois eles trazem dinamismo e criatividade para a organização. O trabalho flui com naturalidade e o ambiente se torna seguro, colaborativo, para ele e para o time. Surgem novos produtos, novas propostas, novas tecnologias, satisfação e orgulho de fazer parte daquela empresa.
O trabalho de um lider coach ou de um scrum master é captar esses profissionais no mercado, desenvolver as pessoas que integram o seu time, nos dois aspectos, tecnico e comportamental. É fazer com que pessoas com personalidades diferentes, trabalhem juntas para alcançar uma única meta. Logo, se encontramos profissionais com potencial no mercado, contratamos imediatamente e integramos a equipe."
Obrigado Anne!
sábado, 16 de junho de 2012
E a Analise de Pontos de Função?
Como eu repito normalmente, APF para mim é uma forma pseudo-científica que tenta uma conciliação entre os envolvidos para algo incerto parecer que pode ser certo.
Resumindo: para mim, falha ao tentar resolver um problema, o da metrificação. Em vez de lidar com a incerteza da complexidade, tentar simplificar o que é complexo.
Resumindo: para mim, falha ao tentar resolver um problema, o da metrificação. Em vez de lidar com a incerteza da complexidade, tentar simplificar o que é complexo.
terça-feira, 12 de junho de 2012
E a definição de pronto?
Vamos relembrar alguns conceitos básicos do desenvolvimento de software? Na verdade o conceito mais básico.
A definição de pronto está estritamente ligada, em sua maior parte, ao que significa pronto para o cliente. Ter ou não alguns artefatos, documentação, evidencias, robustez, etc. Esta definição está relacionada ao contexto. Só existe um princípio que é obrigatório para qualquer definição de pronto e, por ele estar normalmente subentendido pela lógica, as pessoas normalmente nem o colocam em discussão: é o princípio da correção. Eu nunca pensei que pudesse ter problemas com isso, mas fui surpreendido.
Bem, como meu objetivo nunca é a caça às bruxas e trabalho simultaneamente em alguns projetos pessoais, além do meu emprego, contar isso aqui não vai revelar a identidade das pessoas. Só os envolvidos saberão que estou me referindo a eles.
Vamos dizer que eu tenho um projeto onde eu tenho um backlog atual de 30 funcionalidades. Estas funcionalidades estão, em sua maioria, divididas em 3 tarefas: recuperar dados, gravar dados e gerar um arquivo CSV.
É necessário entender que, para atingir o princípio básico (higiênico) da correção, precisamos garantir a correção das 3 subtarefas. Se existe um problema na geração dos arquivos CSV, a funcionalidade não está pronta. Não interessa se você chama a funcionalidade de tarefa, estoria, papelzinho ou de qualquer outro nome. Para mover de building para built é necessário que o princípio da correção tenha sido atendido. É o mínimo.
Percebi que o board estava com muitas funcionalidades na coluna "built". Fui tentar entender o que estava acontecendo e lembrei que estávamos trabalhando com one piece flow e que precisávamos fazer fluir aquela coluna. Grande foi a minha surpresa quando descobri que as funcionalidades estavam em built, mas que ainda havia um "probleminha" na geração do CSV. Tentei explicar por alguns minutos que isso não existe, pois para estar em built a funcionalidade precisa estar errrrrr built.
Sem sucesso. Como sou responsável pela revisão do código, falei que começaria a revisão e que, como estávamos com um "probleminha" na geração do CSV, eu rejeitaria e devolveria as funcionalidades. Recebi como resposta: não não, você não pode revisar agora (!?). Eu já sabia que surgiria uma pérola dessa.
Então para provocar ainda mais, falei que iria pular a revisão e liberar as funcionalidades para o tester verificar se estava OK. Também recebi um "não não, só pode envolver o tester na semana que vem" (!!??). Tentei por mais um tempo mostrar que os princípios estavam errados, que estavam usando o quadro para controlar funcionalidades, mas ainda com a cultura waterfall. Em built tem uma "represa". Sem sucesso. Fui descobrir como tratarão este erro no futuro e descobri que criaram uma atividade chamada "Acertar arquivo CSV" (!!!???).
Isso é débito técnico, e dos piores, pois não diz respeito "apenas" a qualidade da funciolidade, mas diz respeito a um princípio higiênico, o da correção. Enfim, recebi seguidos "não concordo", com argumentos que, para mim, não fizeram o menor sentido.
Na maior observação que já tive que fazer do princípio do Lean "Respect for People", resolvi então deixar correr. Posso estar errado, mas decidi deixar o barco tentar navegar e ver o que vai acontecer. Vou rastrear quaisquer problemas para essa decisão duvidosa do time. Chamei o tester e expliquei a situação (ele também achou um absurdo algo estar em "construido" sem estar de fato construido) e pedi para esperar um pouco.
EDIT:
Como sou chato, devo voltar nesse assunto mais algumas vezes nos próximos dias.
A definição de pronto está estritamente ligada, em sua maior parte, ao que significa pronto para o cliente. Ter ou não alguns artefatos, documentação, evidencias, robustez, etc. Esta definição está relacionada ao contexto. Só existe um princípio que é obrigatório para qualquer definição de pronto e, por ele estar normalmente subentendido pela lógica, as pessoas normalmente nem o colocam em discussão: é o princípio da correção. Eu nunca pensei que pudesse ter problemas com isso, mas fui surpreendido.
Bem, como meu objetivo nunca é a caça às bruxas e trabalho simultaneamente em alguns projetos pessoais, além do meu emprego, contar isso aqui não vai revelar a identidade das pessoas. Só os envolvidos saberão que estou me referindo a eles.
Vamos dizer que eu tenho um projeto onde eu tenho um backlog atual de 30 funcionalidades. Estas funcionalidades estão, em sua maioria, divididas em 3 tarefas: recuperar dados, gravar dados e gerar um arquivo CSV.
É necessário entender que, para atingir o princípio básico (higiênico) da correção, precisamos garantir a correção das 3 subtarefas. Se existe um problema na geração dos arquivos CSV, a funcionalidade não está pronta. Não interessa se você chama a funcionalidade de tarefa, estoria, papelzinho ou de qualquer outro nome. Para mover de building para built é necessário que o princípio da correção tenha sido atendido. É o mínimo.
Percebi que o board estava com muitas funcionalidades na coluna "built". Fui tentar entender o que estava acontecendo e lembrei que estávamos trabalhando com one piece flow e que precisávamos fazer fluir aquela coluna. Grande foi a minha surpresa quando descobri que as funcionalidades estavam em built, mas que ainda havia um "probleminha" na geração do CSV. Tentei explicar por alguns minutos que isso não existe, pois para estar em built a funcionalidade precisa estar errrrrr built.
Sem sucesso. Como sou responsável pela revisão do código, falei que começaria a revisão e que, como estávamos com um "probleminha" na geração do CSV, eu rejeitaria e devolveria as funcionalidades. Recebi como resposta: não não, você não pode revisar agora (!?). Eu já sabia que surgiria uma pérola dessa.
Então para provocar ainda mais, falei que iria pular a revisão e liberar as funcionalidades para o tester verificar se estava OK. Também recebi um "não não, só pode envolver o tester na semana que vem" (!!??). Tentei por mais um tempo mostrar que os princípios estavam errados, que estavam usando o quadro para controlar funcionalidades, mas ainda com a cultura waterfall. Em built tem uma "represa". Sem sucesso. Fui descobrir como tratarão este erro no futuro e descobri que criaram uma atividade chamada "Acertar arquivo CSV" (!!!???).
Isso é débito técnico, e dos piores, pois não diz respeito "apenas" a qualidade da funciolidade, mas diz respeito a um princípio higiênico, o da correção. Enfim, recebi seguidos "não concordo", com argumentos que, para mim, não fizeram o menor sentido.
Na maior observação que já tive que fazer do princípio do Lean "Respect for People", resolvi então deixar correr. Posso estar errado, mas decidi deixar o barco tentar navegar e ver o que vai acontecer. Vou rastrear quaisquer problemas para essa decisão duvidosa do time. Chamei o tester e expliquei a situação (ele também achou um absurdo algo estar em "construido" sem estar de fato construido) e pedi para esperar um pouco.
EDIT:
Como sou chato, devo voltar nesse assunto mais algumas vezes nos próximos dias.
Assinar:
Postagens (Atom)
