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.
sábado, 16 de junho de 2012
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)