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.
segunda-feira, 27 de agosto de 2012
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.
quinta-feira, 24 de maio de 2012
Lean - Respect for people
Hoje li em Implementing Lean Software Development um comentário contundente sobre a importância deste princípio, colocando-o acima de todos os outros. Em um primeiro momento, achei estranha a argumentação, pois vejo muita importância, também, em identificação do valor, mapeamento do value stream e análise deste value stream para identificação e redução de desperdícios. Mas ao refletir cuidadosamente e conforme fui avançando na leitura do capítulo seis, percebi que concordo sem restrições com o que foi proposto pelos Poppendiecks. O objetivo deste post é repercutir esta idéia e, quaisquer dúvidas e/ou idéias para somar, fiquem a vontade para postar nos comentários.
Segue o trecho retirado da primeira página do capítulo:
“Year after year, Toyota has been able to get more out of its people than its competitors have been able to get out of theirs,”[1] according to Gary Hamel. “It took Detroit more than 20 years to ferret out the radical management principle at the heart of Toyota’s capacity for relentless improvement....Only after American carmakers had exhausted every other explanation for Toyota’s success—an undervalued yen, a docile workforce, Japanese culture, superior automation—were they finally able to admit that Toyota’s real advantage was its ability to harness the intellect of ‘ordinary’ employees.”
[1] “Management Innovation,” by Gary Hamel, Harvard Business Review, February, 2006, p. 74.
Lean is a management system that creates engaged, thinking people at every level of the organization and most particularly at the front line. If you implement all of the lean principles save one—respect for people—you will reap only a shadow of the potential advantages that lean can bring. If you implement only one principle—respect for people—you will position the people in your organization to discover and implement the remaining lean principles.
Bom, that is it.
Segue o trecho retirado da primeira página do capítulo:
“Year after year, Toyota has been able to get more out of its people than its competitors have been able to get out of theirs,”[1] according to Gary Hamel. “It took Detroit more than 20 years to ferret out the radical management principle at the heart of Toyota’s capacity for relentless improvement....Only after American carmakers had exhausted every other explanation for Toyota’s success—an undervalued yen, a docile workforce, Japanese culture, superior automation—were they finally able to admit that Toyota’s real advantage was its ability to harness the intellect of ‘ordinary’ employees.”
[1] “Management Innovation,” by Gary Hamel, Harvard Business Review, February, 2006, p. 74.
Lean is a management system that creates engaged, thinking people at every level of the organization and most particularly at the front line. If you implement all of the lean principles save one—respect for people—you will reap only a shadow of the potential advantages that lean can bring. If you implement only one principle—respect for people—you will position the people in your organization to discover and implement the remaining lean principles.
Bom, that is it.
segunda-feira, 21 de maio de 2012
Agile - Carta semi aberta para um amigo
Considerei a carta semi aberta porque vou ocultar a identidade da pessoa. Basicamente esse meu amigo me comparou ao Hitler nesta montagem. Interessante, mas que pecou em um conceito: Waterfall é para projetos grandes e iterações e small batches para projetos pequenos.
Segue a minha resposta que, por abordar um assunto importante, resolvi postar aqui:
Cara, não pode ser eu... não pode ser eu mesmo!
Eu não falaria o absurdo que os métodos ágeis só servem pra pequenos projetos. =)
Em primeiro lugar, os métodos ágeis, na maioria, tentam lidar diretamente com a complexidade, isto é, com ambientes onde a incerteza reina. Lembra da metáfora dos sistemas complexos? "O bater de asas de uma borboleta na China pode causar um tsunami nos EUA".
Com pequenas iterações (e pequenos lotes), os métodos ágeis tentam reduzir as previsões e o ciclo, tentando diminuir a imprevisibilidade e as incertezas. Eles te dizem para aprender com o seu ambiente e com a sua experiência.
O waterfall não existe. Esta péssima interpretação do paper do Winston Royce ( http://www.youtube.com/watch?
Todas as demandas estouram custo e/ou prazo e/ou qualidade. Normalmente os três. Fazem isso em benefício de um escopo fixo e assinado em contrato. Simplesmente não funciona e está provado.
Você provavelmente já voou em um avião montado sob o Pensamento Lean - http://www.youtube.com/watch?
Então small batches não é para small projects. Uma coisa não tem nada a ver com a outra.
Princípios ágeis funcionam muito bem em grandes projetos. Os princípios do Lean funcionam muito bem em grandes projetos.
Este livro fala muito de sistemas complexos e da nova escola de gerenciamento de projetos. Recomendo muito: http://www.amazon.com/
Para quem quer ter uma ideia do livro e da abordagem do Jurgen quanto aos Sistemas Complexos, aqui está o blog: http://www.management30.com/
Divirta-se!
Segue a minha resposta que, por abordar um assunto importante, resolvi postar aqui:
Cara, não pode ser eu... não pode ser eu mesmo!
Eu não falaria o absurdo que os métodos ágeis só servem pra pequenos projetos. =)
Em primeiro lugar, os métodos ágeis, na maioria, tentam lidar diretamente com a complexidade, isto é, com ambientes onde a incerteza reina. Lembra da metáfora dos sistemas complexos? "O bater de asas de uma borboleta na China pode causar um tsunami nos EUA".
Com pequenas iterações (e pequenos lotes), os métodos ágeis tentam reduzir as previsões e o ciclo, tentando diminuir a imprevisibilidade e as incertezas. Eles te dizem para aprender com o seu ambiente e com a sua experiência.
O waterfall não existe. Esta péssima interpretação do paper do Winston Royce ( http://www.youtube.com/watch?
Todas as demandas estouram custo e/ou prazo e/ou qualidade. Normalmente os três. Fazem isso em benefício de um escopo fixo e assinado em contrato. Simplesmente não funciona e está provado.
Você provavelmente já voou em um avião montado sob o Pensamento Lean - http://www.youtube.com/watch?
Então small batches não é para small projects. Uma coisa não tem nada a ver com a outra.
Princípios ágeis funcionam muito bem em grandes projetos. Os princípios do Lean funcionam muito bem em grandes projetos.
Este livro fala muito de sistemas complexos e da nova escola de gerenciamento de projetos. Recomendo muito: http://www.amazon.com/
Para quem quer ter uma ideia do livro e da abordagem do Jurgen quanto aos Sistemas Complexos, aqui está o blog: http://www.management30.com/
Divirta-se!
quarta-feira, 16 de maio de 2012
5 Whys - Comunicação e Confiança
Vou começar a colocar aqui no blog algumas experiencias de exemplos práticos de como utilizar os "5 whys" do pensamento Lean para investigar a(s) verdadeira(s) causa(s) raiz dos problemas que possam aparecer no dia a dia.
Vamos começar com uma suposta falha de comunicação entre desenvolvedor e gerencia/liderança.
Cenário: Uma informação, necessária para uma reunião de status report, chegou até a gerencia via cliente enquanto ainda estava havendo a validação se o problema realmente era um problema. Isso aconteceu porque a reunião de status report aconteceria muito em breve.
Os exemplos práticos que colocarei aqui são resultados da minha mente psicopata, portanto, não fazem parte do meu dia a dia. O recado é: não pare no primeiro "por que" ele pode te levar a um diagnóstico simplista demais. Medidas para remediar o primeiro "por que" podem não surtir o efeito desejado e, mesmo aplicando a inspeção, podemos estar agindo na causa errada. Errada pois por trás dela existem causas muito maiores que não estão sendo endereçadas. Daí pode estar vindo a sensação de "enxugar gelo" e de que, na verdade, as pessoas não estão se esforçando para realizar as "determinações de melhoria". Um conselho para você que acredita nisso: "Isso não é verdade! Você está tratando as causas erradas."
Vamos começar com uma suposta falha de comunicação entre desenvolvedor e gerencia/liderança.
Cenário: Uma informação, necessária para uma reunião de status report, chegou até a gerencia via cliente enquanto ainda estava havendo a validação se o problema realmente era um problema. Isso aconteceu porque a reunião de status report aconteceria muito em breve.
- Por que essa informação não foi passada pelo time? Porque ainda estava em validação.
- Por que então foi antecipada? Porque era necessária para uma reunião inadiável de status report que aconteceria em breve e o cliente estava sendo cobrado por sua liderança/gerencia.
- Por que uma reunião de status report, ainda mais inadiável? Porque falta confiança.
- Por que falta confiança? Porque já aconteceram muitas releases com problemas.
- Por que já aconteceram muitas releases com problemas? Pela ausencia de um processo mais eficiente de testes, UAT e deploy.
Os exemplos práticos que colocarei aqui são resultados da minha mente psicopata, portanto, não fazem parte do meu dia a dia. O recado é: não pare no primeiro "por que" ele pode te levar a um diagnóstico simplista demais. Medidas para remediar o primeiro "por que" podem não surtir o efeito desejado e, mesmo aplicando a inspeção, podemos estar agindo na causa errada. Errada pois por trás dela existem causas muito maiores que não estão sendo endereçadas. Daí pode estar vindo a sensação de "enxugar gelo" e de que, na verdade, as pessoas não estão se esforçando para realizar as "determinações de melhoria". Um conselho para você que acredita nisso: "Isso não é verdade! Você está tratando as causas erradas."
quinta-feira, 10 de maio de 2012
Pesquisa - Devo criar outro blog sobre processos, teorias, sistemas?
Desde que me posicionei definitivamente como um change agent na empresa onde trabalho, tem sido muito difícil voltar a ler livros com conteúdo técnico. Um livro sobre sistemas e processos puxa outro, que puxa outros sobre teorias (sistemas complexos, teoria das filas, teoria das restrições, etc) e meu backlog de livros técnicos vai ficando cada vez mais distante do meu momento atual.
Sei que o bom entendimento do ambiente em que vivemos é extremamente importante para um a criação de um software de qualidade. Sou contra a lei da causalidade que ainda é muito comum nas empresas: se uma aplicação tem baixa qualidade, a culpa é do desenvolvedor. O Yoshima escreveu sobre isso no blog Débito Técnico e uma de suas frases fala sobre a efemeridade deste pensamento:
Ninguém aplica a lei dos "cinco por ques" do pensamento Lean. Normalmente param no primeiro. É mais fácil... é mais cômodo.
Assim, resolvi lançar uma pesquisa, que ficará no ar por 90 dias, para saber se vocês acham melhor eu criar outro blog para falar sobre estes assuntos (gestão moderna, sistemas de melhoria contínua, sistemas complexos, teorias, etc) ou se posso continuar escrevendo neste espaço, tendo em vista que estes assuntos também contribuem para melhorar um ambiente que é essencial para o desenvolvimento de uma aplicação de qualidade.
Votem!
Sei que o bom entendimento do ambiente em que vivemos é extremamente importante para um a criação de um software de qualidade. Sou contra a lei da causalidade que ainda é muito comum nas empresas: se uma aplicação tem baixa qualidade, a culpa é do desenvolvedor. O Yoshima escreveu sobre isso no blog Débito Técnico e uma de suas frases fala sobre a efemeridade deste pensamento:
Gestores dizendo que as coisas não fluem porque as pessoas não se esforçam é um diagnóstico simplista, preguiçoso e fora da realidade.Esta frase faz parte, hoje em dia, da minha assinatura nos meus emails pessoal e profissional.
Ninguém aplica a lei dos "cinco por ques" do pensamento Lean. Normalmente param no primeiro. É mais fácil... é mais cômodo.
Assim, resolvi lançar uma pesquisa, que ficará no ar por 90 dias, para saber se vocês acham melhor eu criar outro blog para falar sobre estes assuntos (gestão moderna, sistemas de melhoria contínua, sistemas complexos, teorias, etc) ou se posso continuar escrevendo neste espaço, tendo em vista que estes assuntos também contribuem para melhorar um ambiente que é essencial para o desenvolvimento de uma aplicação de qualidade.
Votem!
terça-feira, 8 de maio de 2012
Copie princípios não práticas
Práticas são dependentes de contexto. Princípios tem maior facilidade de ser transportado de um contexto para outro. Mary e Tom Poppendieck falam sobre isso em seu livro, Lean Software Development, além de ser uma questão comprovada por estudos e experiência.
sábado, 5 de maio de 2012
Kanban - Envolvendo o cliente
Vamos continuar a série saga de como estamos trabalhando para implantar a cultura da melhoria contínua no nosso ambiente. Hoje vou mostrar como expliquei o sistema para o cliente e solicitei o seu envolvimento no nosso processo interno. Quem não quer arruma desculpa. Quem quer, procura a solução em vez de ficar de mimimi.
terça-feira, 10 de abril de 2012
Kanban - O que é o WiP e por que limita-lo?
As pessoas que trabalham comigo já conhecem este texto, pois enviei em um email para o time. Como não falei nada específico da empresa e do cliente e, na verdade, o que fiz foi apresentar conceitos, decidi extender para a comunidade.
quarta-feira, 4 de abril de 2012
SOLID - Single Responsability Principle
O principio da responsabilidade única é o primeiro do acrônimo S.O.L.I.D., um conjunto de princípios que auxiliam na criação de um software de qualidade. Single responsability é o princípio mais fácil de entender, mas o mais difícil de aplicar.
quarta-feira, 28 de março de 2012
Do que chamar o Scrum?
Hoje lendo o scrum-brasil fórum da scrum-brasil hoje, me deparei com uma mensagem que me chamou a atenção.
O assunto principal, é como chamar o Scrum. Eu respondi por lá, mas parece que moderaram a minha resposta. Fica difícil saber a verdade, mas como eu tenho meu espaço, vou colocar aqui a minha resposta, e quem quiser discutir de forma sadia, fique a vontade. Uma rapidinha sobre como chamar o Scrum.
O assunto principal, é como chamar o Scrum. Eu respondi por lá, mas parece que moderaram a minha resposta. Fica difícil saber a verdade, mas como eu tenho meu espaço, vou colocar aqui a minha resposta, e quem quiser discutir de forma sadia, fique a vontade. Uma rapidinha sobre como chamar o Scrum.
quarta-feira, 21 de março de 2012
Como ser ágil em um ambiente cascata?
Em primeiro lugar, gostaria de pedir desculpas aos meus leitores, pois há muito não coloco um conteúdo mais técnico e tenho falado muito em processos, sistemas, gerenciamento e assuntos nessa linha.Vou me redimir, uma dia.
Neste post, vou informar como estamos transformando uma equipe para observar os valores da agilidade, dentro de um ambiente, até certa forma, hostil ao movimento ágil. Como os leitores mais antigos já devem desconfiar, o sistema principal escolhido foi o Kanban. Entretanto, neste contexto complexo, decidimos aplicar um conceito mais amplo, o AgileMMA, termo cunhado pelo grande pensador Manoel Pimentel.
Neste post, vou informar como estamos transformando uma equipe para observar os valores da agilidade, dentro de um ambiente, até certa forma, hostil ao movimento ágil. Como os leitores mais antigos já devem desconfiar, o sistema principal escolhido foi o Kanban. Entretanto, neste contexto complexo, decidimos aplicar um conceito mais amplo, o AgileMMA, termo cunhado pelo grande pensador Manoel Pimentel.
Por que aprender sobre pessoas?
Algumas pessoas essencialmente técnicas esbarram nesta questão. Outras perguntariam por que estudar sobre gerenciamento se eu não quero ser gerente?
As pessoas que me dão a honra de me acompanhar no twitter, sabem que estou lendo Management 3.0 do Appelo. Também sabem que prefiro a área técnica e que não tenho a pretensão de me tornar um gerente. Não um gerente tradicional. Então por que nos últimos meses tenho me dedicado a um estudo mais detalhado de Lean, Kanban e de pessoas?
As pessoas que me dão a honra de me acompanhar no twitter, sabem que estou lendo Management 3.0 do Appelo. Também sabem que prefiro a área técnica e que não tenho a pretensão de me tornar um gerente. Não um gerente tradicional. Então por que nos últimos meses tenho me dedicado a um estudo mais detalhado de Lean, Kanban e de pessoas?
quinta-feira, 1 de março de 2012
Fevereiro de 2012 - Um marco na historia do Kanban
De fato, na minha visão, o mês de fevereiro transformou-se em um marco na vida do sistema Kanban. Infelizmente, também na minha visão, este é um marco negativo e vou contar aqui porque.
segunda-feira, 16 de janeiro de 2012
Kanban - De olho no seu processo
Demos início ao mapeamento/análise do nosso processo utilizando o sistema Kanban. Vou mostrar aqui como foi a mudança de processo e de cultura, assim como esse sistema nos ajudou a mapear e melhorar nosso processo de desenvolvimento.
Assinar:
Postagens (Atom)