A recente participação na Desconf 2011, assim como conversas e acontecimentos não tão recentes, me fizeram refletir sobre o nosso comportamento como agente transformador de nosso ambiente de trabalho. Muitas e muitas vez ouvimos ou começamos debates com a frase “isso nunca funcionaria onde trabalho”, acontece… mas você nunca terá certeza até tentar.

Um ano atrás twittei feliz que estava saindo de Natal para encarar novas tarefas, conhecer novas pessoas, imergir em novos domínios e encarar de peito aberto as mudanças. O que não me soava estranho na época, apesar de ter sido alertado pelo GLeydson Lima, mas que hoje faz todo o sentido era a minha posição em tudo isso. Acredito que todos já passaram ou devam passar por um situação destas, de se colocar menor ao desafio com única perspectiva de que irá absolver muito mais estando apenas em uma posição passiva na aprendizagem. Acontece que as coisas nem sempre são como imaginamos e ser surpreendido aprendendo enquanto fazia, fala ou apenas ajudava tem sido excelente.

Este ano tive o prazer de participar de vários eventos e ouvir muita gente boa e inteligente, @dwildt, @brunopedroso, @alegomes, @rwilli, @andrefaria, @joaostein,  @julioprotzek,  @miprotzek,  @fkenjikamei,  @lcparzianello,  @manoelp,  @rafb3, @hugocorbucci,  @dtsato,  @nukdf,  @paulocaroli, @rafajagua e @thiagoesser, em comum possuíam apenas a vontade de aprender. Participei do meu primeiro grande evento o Agile Brazil 2011 e também do mais inovador desconf 2011, participei dos primeiros passos de um novo grupo e entre erros e sucessos aprendi muito!!

Nestas últimas duas semanas, tenho me movimentado muito para retomar o Stefanini OpenTalks ajudando no possível para continuarmos a mudança. Precisamos pensar em mudança e em como fazer nós mesmos oque esperamos que seja feito por todos, se não conseguimos melhorar como podemos cobrar o mesmo dos demais.

Pelos lugares por onde passei, vejo que qualquer equipe é capaz e deve lutar para estabelecer relações não só profissionais mas de amizade e compromisso sobre o crescimento intelectual dos colegas, um crescimento mútuo. Tenho trabalhado em uma grande equipe, e cada dia que passa damos mais um passo na direção que procurava ao vir para cá, mas estou bem surpreso como pode ser ainda melhor ser uma parte ativa da transformação. Semana passada transmiti esta idéia aos novos integrante da Stefanini, e espero que 2012 venha com mais personalidade, open talks, grupos de estudos e muito aprendizado. Como disse o Rafael Bandeira… existe muita experiência off-line nos esperando!!

No último sábado, 29 de Novembro de 2011, tive o prazer de trocar várias idéias durante a segunda edição de uma nova modalidade de evento que trás a inovação em seu nome DESCONF!

Sediada pela Faculdade Dom Bosco a DESCONF 2011 mustache edition, declarou a liberdade de expressão na sua temática bigodes, com um formato nada convencional que mesclava espaços abertos e lightning talks, tendo uma representatividade de 62% de seus participantes registrados como conferencistas, mas que em proporções de tempo dentro e fora do auditório todos acabam por definir e debater suas linhas de pensamentos, não conseguiu oferecer nada menos que um dia de grande aprendizagem.

O evento foi iniciado às 09h com o credenciamento e um excelente coffee break. Logo na entrada ficava evidente a intenção da equipe organizadora em promover um ambiente descontraído com o Rafael Bandeira e o Felipe Cabral na mesa com bigode e barba respectivamente bem caracterizados, assim como a Natalia Arsand que entregava bigodes postiços para os imberbes!

Perto das 10h tivemos a primeira intervenção à desordem organizada, convocados pelo Bandeira fomos todos para o auditório onde foram feitas as primeiras atividades para quebrar o gelo, com muitos aplausos aos organizadores, patrocinadores e brindes! Tivemos definidas as regras abaixo e foram iniciados os lightning talks.

• Não deveríamos sair do campo de visão da camera, para que as ideias alcançassem mais do que os 80 participantes;
• Cada apresentação não deveria superar 5min;
• Todos deveriam aplaudir ao termino destes 5min.
• E quem se pronunciasse mais rápido seria o próximo.

A largada foi dada em uma rápida e descontraída apresentação de fatos, história e fotos sobre a temática do evento. Sem nenhuma dúvida ficou bem claro que ter barba é sinônimo de liberdade, minha esposa que não me escute….

Apresentei minha visão sobre a possibilidade do sucesso dos projetos além dos curtos ciclos de aprendizagem, pregados pelo Eric Ries, com um acompanhamento de idéias promissoras com fatores restritivos atuais ao longo do tempo por meio do livro de possibilidades.

Houveram várias convergências de idéias e assuntos complementares, e a cada novo conferencista uma nova surpresa. Falaram sobre mantras de possibilidades, história de marinheiros e suas reais eficiências, sobre despertar o UAU nos clientes e em como as idéias convergiam mais rápidamente em ecologias criativas. Tivemos insights sobre negociação, hackerspaces, startups e os seus lados negros. Design e UX. Todos os temas e gostos!

Após todo o dia não tinha mais nada a fazer do que agradecer a todos os que participaram, pelas ideias que ouvi e discuti. As pizzas estavam ótimas e o ambiente realmente propicio ao aprendizado e a evolução de idéias. E da idéia de que a #desconf deveria ir ao mainstream deixo a pergunta se apenas os mais experientes devem ser ouvidos, e a frase do Christian Heilmann ”Where do Known speakers come from?”. MUITO OBRIGADO A DESCONF! Que venha a edição de 2012.

KYEO

Costumo pensar que todo projeto, seja aqui ou na China, tem algo semelhante em seu início, algo que permite a fundamentação, o crescimento e a melhoria continua. . . Seguindo os encalorados discursos sobre Lean Startups, dentre muitos outros que já ouvi de pequenos, médios e grandes empreendedores, é certo concluir que o sucesso é um longo caminho de aprendizados, no qual nossa única certeza é que as ideias irão surgir e quando implementadas podem ser bem sucedidas ou não.

Aprender, o que? Pensar, publicar, extrair e aprender… certo? Bem, realmente temos que aprender, mas as nossas ideias e a percepção dos envolvidos em nossos projetos (usuários, colaboradores e fornecedores) são fruto de algo mais profundo, e simplesmente descartá-las não soa nada HIGIÊNICO ou inteligente. As pessoas mudam, e este algo mais profundo A CULTURA está em constante mudança.

Recentemente fiz uma jornada introspectiva para entender um pouco mais sobre a cultura envolvida por trás das redes socias, conversei com pessoas, as ouvi e também fiz minhas experiências passando minhas ideias e vendo-as se transformarem sobre novas perspectivas.Após 233 checkins, 11 badges e inumeras dicas seguidas, acho que tive um vislumbre do que me motivaria e talvez outras pessoas a usa-las. Badges? Envolvimento social? Elevação de status? Inundar-se de cool?

Esta é uma experiência válida quando não estamos construindo uma nova aplicação para atender os nossos problemas. Quando não conhecemos de perto o nosso público, nada melhor do que uma boa conversa ao sofá ou na mesa ao almoço, algo subjetivamente demorado e franco.

Durante este tempo incontáveis idéias foram escritas em um caderno que sempre me acompanha, e quantos de nós não já tiveram ideias e mais ideias que foram comentadas, anotadas, implementadas e miseravelmente esquecidas. Neste último sábado, 26 de Novembro de 2011, apresentei durante a DESCONF 2011 um vislumbre deste meu aprendizado fundado sobre idéias co-evoluídas. IDÉIAS SÃO MUITO IMPORTANTES PARA SEREM ESQUECIDAS SEM PESTANEJAR, o ato de LEMBRAR-MOS E ESQUECER-MOS DELAS pode nos levar as margens do sucesso e da vanguarda tecnologica.

Lembrar e Esquecer idéias? Acompanhe-as e descarte sabiamente

Há algum tempo vendo o filme Last Holiday, que apresenta a história de vida por trás da personagem principal interpretada pela Queen Latifah na sua ultima semana de vida, me deparei como uma relação positiva entre os livros de possibilidades do filme e nossos backlogs, e o venho aplicando desde então. A personagem possuía um livro em que todas as suas pretensões futuras como marido perfeito, casa, viagem e elterodomésticos eram armazenados e trabalhados para se concretizarem. As vezes temos que tirar o chapéu para romancistas que concretizam e personificam comportamentos culturais em suas obras. E após minha analise sobre a cultura por trás da sociedade virtual do foursquare, tinha meu livro de idéias, UM LIVRO DE POSSIBILIDADES.

O LIVRO DE POSSIBILIDADES em minha visão de empreendedorismo complementa o conceito de sucesso pelo aprendizado, e este aprendizado não precisa ser finito, nem datado ao fim, ele pode ser um acompanhamento continuo de mudanças tecnológicas, financeiras, legais e culturais que o restringe. Sendo assim deveriamos adicionar ao nosso trabalho diário, ou junto ás ativades de nosso PO, o acompanhamento de idéias que vemos possíveis a um futuro próximo que poderão nos levar a posições de vanguarda. Manter o MVP pode ser nos dias atuais garantia para o sucesso, mas quando todos apresentam o mesmo comportamento, não olhar mais sim acompanhar, fatores influentes podem lhe dar a preferência no sucesso.

Ouvi durante o agile brazil 2011, do Henrique Imbertti, as adaptações do time do MEME da Yahoo havia adaptado o seu storyboard para implementar o ciclo de aprendizado, e acredito que oque é percebido não sendo necessário agora não devesse ser totalmente descartado e sim acompanhado quando detectadas restrições que não sejam temporariamente imutáveis e que possam significar grande vantagem competitiva.

Várias empresas produzem sistemas de qualidade mas que nada servem para os seus usuários, pivoteiam inumeras vezes mas parecem sempre apontar para o caminho errado. Com idéias mapeadas e a cultura inerente ao segmente que se destina nossa aplicação acompanhada de perto, o empresário deve sair da posição de irmão mais novo desesperadamente tentando acompanhar a brincadeira dos irmãos mais velhos. Canais e ondas de consumo surgem todos os dias, ou você possui um ambiente onde elas normalmente afloram e se transformam ou você cria um. MAS NÃO ESQUEÇA DE MANTER OS SEUS OLHOS ABERTOS!

Começando do inicio, acredito que a maior parte de nós em algum momento já se deparou com um shell de linha de comandos.O shell como é mais utilizado é uma interface textual para as funcionalidades do sistema operacional, no MacOS você o acessa por meio do Terminal ou iTerm2. Existem muitos shells a serem escolhidas, e a maioria dos sistemas operacionais/distribuições acabam “facilitando” esta escolha definindo alguma padrão. Durante muito tempo só conhecia o mais popular deles GNU Bourne Again Shell ou bash, uma excelente escolha quando você precisa repetir os mesmos comandos que já estão no histórico, para iniciar algum container ou ver logs… mas uma péssima, quando você passa certo tempo usando Git e RVM (

 para lembrar o branch que estou e 

 para ver a versão do ruby e gems) ou aprendendo comandos novos e utilizando novas técnicas do universo devops (fiz recentemente o curso da egenial de imersão sys deploy).

zsh?

O Z-shell ou zsh é um dos shells mais completos em termos de funcionalidades e usabilidade dentre os disponíveis no Darwin que traz como default o tsch desde a v.7.0 presente no Mac Os X Panther. A equipe do zsh já faz um excelente trabalho explicando e e advogando ao seu respeito, mas como todos tenho meus pontos preferidos.

1. Corretor ortográfico: Quem nunca escreveu rmv, fnd, mkdr ou qualquer outro comando incorretamente? O zsh possui um corretor que varre e apresenta entre comandos e sub-comandos o mais próximo ao incorreto informado. Estava errado me corrija?
   zsh: correct ‘rmv’ to ‘rvm’ [nyae]?
2. Tab completion: A maior parte dos shells como o bash possuem tab completion, mas não tão simples ou amigável quanto o zsh. Tanto no sentido de configuração quanto de usabilidade, o zsh dá um banho. Ele apresenta em um menu navegável de sub-comandos e opções de preenchimento como a lista de diretórios quando executamos um ls, ou a lista de processos quando executamos um kill.
3. Compartilhamento de histórico: Manter histórico entre as sessões ao invés de sobrepor-las, não tem nada pior do que perder o histórico de comandos executados pois uma sessão havia sido sobreposta, o zsh mantem o histórico das várias sessões.
4. Globbing. O zsh se preocupou muito com seus wildcards, e o resultados foram incríveis ls git*~*flow* ou ls (GOL|TAM)*POA*, sempre dou uma olhada  na introdução do zsh.
5. Criar funções com aliases. O zsh permite a criação de funções chamadas pelos seus aliases, de forma fácil e ágil.

   1	function juntarpdfs { gs -q -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -sOutputFile=merged.pdf "$@" }

6. É bem parecido com o bash. Passei um bom tempo utilizando o zsh exatamente como fazia no trabalho com o bash, e mesmo assim foi impossível não aprender algo novo e que aumentasse minha produtividade, ele é simples e amigável.

Como já havia falado antes, o zsh está presente no darwin, ou seja, se você tem instalado em sua maquina uma nova versão ou antiga do MacOsx como eu tinha, não vai precisar realizar várias buscas no google por zsh, e olhar vários how-tos. Nem mesmo para personalizar em cores, aliases, funções e auto-completes se você usar o oh-my-zsh. Como descreve no link ao lado no README do projeto, o zsh é mágico para quem não tem muito tempo a perder:

“A community-driven framework for managing your zsh configuration. Includes optional plugins for various tools (rails, git, OSX, brew,…), nearly 80 terminal themes, and an auto-updating tool so that you can keep up with the latest improvements from the community.”

Para colocar tudo isso para funcionar,  você pode fazer o seguinte:

• Use o instalador automático criado pelo Robby Russell:

  1	wget --no-check-certificate https://github.com/robbyrussell/oh-my-zsh/raw/master/tools/install.sh -O - | sh

Caso você não tenha o wget instalado é bem provável que você verá um erro no console. Esta é  uma ótima oportunidade de fazer isso usando o brew.

• Para instalar o brew:

  1	curl -L http://github.com/mxcl/homebrew/tarball/master | tar xz --str

• Para instalar o wget:

  1	brew install wget

Quando terminar tudo você verá uma tela como a seguinte, daí é só abrir uma nova sessão para ver o thema do Robby Russel fazendo a sua mágica.

Para que não ficasse assim tão simples minha participação nos eventos,  quando estava em Natal/RN invejava a distância, após 6 meses de minha mudança para Porto Alegre para trabalhar junto a equipe de services da Dell, fui aceito para apresentar no Agile Brazil 2011 dois lightining talks bem pertinho de onde saí. Então vamos a um resumo sobre o que vou apresentar!!

Agile Brazil 2011

Dia 27 e 28 de Junho:
Ainda estarei em POA, mas assim como no ano passado, quando pude participar destes dias, digo a quem puder ir que aproveite estes dois dias anteriores a abertura oficial do evento,  pois acontecerão cursos muito interessantes pelo seu conteúdo, dos quais terão a sua frente figuras da comunidade ágil como o @giovannibassi, @hroriz, @axmagno, Christopher G. Thompson do Lean Institute Brasil e por fim aqueles que tive o prazer de acompanhar o sucesso de conhecimento no curso de XP do último Agile Brazil @brunopedroso, @dbassi, @dwildt, @hugocorbucci, @mauricioaniche e @rwilli.

Dia 29 de Junho:
Estarei apresentando o primeiro lightning talk “Como empresa com grande rotatividade aprende?“, onde farei um apanhado de técnicas e estratégias que participei como cobaia ou como agente pelas empresas por onde passei, que objetivaram o trabalho de aprendizagem continua, passagem de conhecimento e retenção de membros. Objetivo da palestra: Aprender algo leva tempo, estou nesta vida a 25 anos e sempre volto ao dicionário para algumas palavras. Como empresas alcançam o sucesso sem se preocupar com seus funcionários. Vamos minerar as vontades da geração y e debater soluções criativas para a criação de uma cultura de aprendizagem, para que no final todos possam dizer… EU FICO!!

Dia 30 de  Junho:
Estarei apresentando o segundo lightning talk “Ramones ou Jazz? Ou os dois? Buscando produtividade com músicas” em parceria com o @dwildt. Objetivo da palestra: Gerar concentração, buscar motivação, acreditar que uma música pode ajudar a buscar resultados. Tudo isto usando a pomodoro technique em um ritmo alterado, através das músicas e do “songdoro”, que mistura pomodoro technique com o conceito das powersongs.

Esperem por mais notícias durante o evento, estarei diariamente postando sobre as palestras e os temas interessantes vistos neste que novamente será um dos maiores eventos sobre agilidade do Brasil!! Se você ainda não se inscreveu, ainda pode se inscrever online. Vejo vocês lá em Fortaleza!

Uma pessoa motivada pode mover montanhas, e manter-se motivado é algo estranhamente comum e que acontece muitas vez comigo quando escuto as palavras certas, o ritmo certo! SONGDORO vem para aliar a anulação ou transformação do som ambiente para algo que motiva e entusiasma à conclusão dos objetivos.

Acho que todos temos aquela música que nos deixa antenado! Um padrão de notas que deixa o nosso organismo pronto para alguma ação. Essas são as power songs… músicas ou seqüências de musicas que aditivam sua motivação e descobri-las e alinha-las é o que tem me ajudado em vários momentos a cumprir prazos ou me deixar mais animado!!

Assim como o Pomodoro a regra é trabalhar em ciclos de concentração curtos, com espaço para reflexão e adaptação algo em torno de 30 minutos, sendo 25 minutos de execução de tarefa(s) e 5 minutos de descanso/reflexão. Comigo os 25 minutos musicais tem funcionado muito bem. A idéia é construir playlists com este tempo, que lhe apontem assim como na sua corrida de fim de semana no parque que momento você deve andar… correr ou apreciar a natureza!!!

Existem instruções bem formuladas no blog do Daniel para aqueles que desejam se aprofundar!!

http://danielwildt.wordpress.com/tag/songdoro/

Esta nova iniciativa proposta pelo colaborador Marcelo Schmidt juntamente à equipe administrativa da Stefanini responsável pela conta do cliente DELL, tem como intenção envolver os colaboradores da instituição em volta dos mais variados temas. Tendo origem nos brown bags seminars, o evento segue a divisão dos lightinig talks com 15 minutos de apresentação e outros 15 minutos para dúvidas.

Neste primeiro encontro apresentei a técnica pomodoro, criada pelo Francesco Cirillo, relatando como a utilizei na refatoração de um dos sistemas da DELL, e quais foram os benefícios encontrados na utilização desta técnica e o seu impacto no resultado final do trabalho.

O Pomodoro é uma técnica de poucas regras e muito efeito para gerenciamento de tempo, fundamentada em ciclos muito curtos (30 minutos), onde se realiza execução, reflexão, adaptação e descanso. Este formato permite aos seus utilizadores um trabalho ainda mais focado, com chances ainda maiores para elaboração de estratégias e ações visando melhoria continua pessoal e do processo.

Durante estes 30 minutos temos dois timeboxes, um com 25 minutos para a execução da atividade planejada e os demais 5 minutos para adaptação/descanso; estes ciclos acontecem quatro vezes e então tem-se um intervalo um pouco maior de 15 à 30 minutos. Durante todo este ciclo um pequeno conjunto de regras rege a orquestra possibilitando a tecnica auxiliar o seu utilizador a visualizar facilmente problemas em sua utilização, como diferentes tipos de interrupções (internas e externas) e problemas com o planejamento.

Para utilizar o Pomodoro faz-se necessário apenas um espaço para anotações das atividades que surgem e são estimadas ou apenas despriorizadas, e um outro para a separação do que será feito no dia. Após estimar e equilibrar a lista para o dia, basta definir o timebox e trabalhar o melhor que você pode dentro do que foi planejado.

Durante o correr do dia e a conclusão das atividades planejadas, sempre surgem novos problemas que precisam ser gerenciados (anotados, analisados e resolvidos), o importante é que estes não sejam esquecidos, e para tal é interessante, e é algo que costumo acrescentar ao escopo da técnica quando estou aplicando, são as regras da profundidade e o conhecimento da sujeira. A regra da profundidade, não sei se existe algo realmente com este nome (por favor se alguem tiver um nome para isto me avise), que me veio em conceito no livro do Kent Beck Test Driven development: By example, que define que um determinado erro encontrado, para qual abstraí a uma nova possível tarefa, deve ter um limite para aprofundamento, uma vez que um problema de código pode trazer muitos níveis de refatoração que iriam interfirir diretamente no planejado.  Já a regra da sujeira diz respeito a conhecer estatisticamente quão sujo estava seu ambiente(no caso desta minha aplicação em ambientes de refatoração), e quão melhor ele está ficando, costumo utilizar como fator para esta analise a quantidade de interrupções ou possíveis interrupções, que vejo durante uma refatoração, relativas ao próprio código(Estas são marcadas na minha TODO list como um +); quanto menos + vejo ao decorrer dos dias de uma refatoração, mais acredito em uma possível melhoria no código.

Ví uma melhoria significativa em qualidade e eficiência em meu trabalho com a utilização desta técnica, por isso achei interessante a apresentação dela para os demais membros da equipe. Agradeço a Stefanini pelo espaço e a equipe pela participação; e espero que os próximo Stefanini Open Talks sejam ainda melhores.

Paulo Caroli Agile Day Porto Alegre 2010

A apresentação foi iniciada evidenciando Taylor e suas contribuições ao aumento da eficiência industrial, com uma ressalva a uma de suas teorias de gerência, a scientific management, que em linhas gerais integrava a lógica produtiva a especialização de cada operário, aproveitando estas vantagens empregando-as em um determinado ponto no caminho para a construção desejada. A este conjunto de pontos e o seu entre fluxo no caminho de se objetivar um sucesso  foi dado o nome de WORKFLOW, e é aí que entra a importância do Taylor nesta apresentação.

Para o Caroli este workflow foi ressaltado um pouco adiante por Frederick Brooks que ressaltou que o objetivo deste fluxo, para equipes de TI, seria apenas criar um produto de software; o que não sua visão é incompleto uma vez que não ressalta a melhoria do processo de desenvolvimento. Outro ponto de ressalva foi o tamanho de cada etapa dos workflows, que segundo Caroli, quando muito grandes não são interessantes para abordagem diretamente na parede, sendo excelente então a simplificação ou o ataque por etapa com a estratégia de Card Wall.

Para o entendimento de workflows foi apresentado logo a seguir um conjunto de fotos, sobre as quais foram tecidos comentários cada uma delas com uma característica das linhas de montagens, mas sempre um ponto em comum, FEEDBACK e AMBIENTE INFORMATIVO. Dentre estes flows foi aberto um adendo para exemplificar o processo realizado pela starbucks, uma vez que este é um processo simples, claro e visível.

Na Starbucks é fácil, aos clientes, a verificação há todo tempo sobre a velocidade e a previsão de seu atendimento. Se existe fila, sei quantas pessoas precisam ser atendidas antes de mim, não existem pessoas sentadas esperando os seus pedidos, em seguida a sua compra existe uma fila de copos até a sua execução pelo barista.

Este workflow representado em um card wall tornaria tão simples sua verificação, quanto a já existente em chão de fábrica, visualizável como definido anteriormente. Neste card wall dividiríamos nossas etapas em raias (Na fila, caixa, barista e bebida pronta) e faríamos representações das pessoas e copos no mesmo. Sendo assim, qualquer pessoa pode rápidamente saber quantas pessoas faltam ser atendidas em qualquer uma das fases instantaneamente.

Dentro do universo de software, temos a algum tempo estas idéis aplicadas, todo software tem um conjunto de fases, e mesmo que hoje em dia realizemos críticas a modelos clássicos como o cascata, as fases ainda são a mesma, mas em pequenas dosagens que fazem toda a diferença mas isso não vem ao caso. Então tendo Analise, Design, Codificação, Teste e Read To GO, colocando estas etapas na parede temos nosso workflow na parede! Para o Paulo Caroli a fase de quality assurance esta em todo o processo isso é um atributo da equipe!

O Caroli apresentou logo em seguida o card wall para software mais utilizado por ele tem, que é composto por backlog, in dev, in quality control e Read To significa off, e esclareceu que para se trabalhar efetivamente esta técnica deve-se trabalhar o formato de pull, então todos puxam uma tarefa e movimenta quando estão livres e não ao contrário, nenhum gerente aponta, o time decide e ele sabe quando receber novas entradas!

Para trabalharmos de forma pareada o card wall apresenta quando devemos separar duplas, criá-las! O objetivo é eliminar problemas; o trabalho tem que acontecer o mais rápido possível, não devemos parar, e com card walls os gargalos estão visíveis na parede! Existem casos em que algum responsável esta ausente, esse é um gargalo… então não deixe tornar isto visível! Holding, idle! Todos devem estar visíveis.

Dentro deste contexto entram em cena os Waiting stages e os action stages! Para o Paulo é muito importante deixarmos visíveis também quais das etapas de nosso workflow devem ser prioridades, quais delas realmente representam um momento em que algo não pode ser alterado por um tempo, para o não permitir acúmulos! Etapas marcadas como Waiting stages devem permitir pausas e estas por sua vez não serão preocupantes, fazem parte do fluxo. Em contrapartida etapas marcadas como action stages devem fornecer uma preocupação extra enquanto a longas permanências e acúmulos.

Os card walls também ajudam o time a entender seu próprio progresso, detalhando ainda mais suas métricas. Um time pode realizar dois projetos com a mesma velocidade,  mas vivenciando situações completamente diferentes durantes suas iterações. Enquanto em um estes podem completar todo o trabalho apenas no último dia sobre trancos e barrancos, o outro podem conseguir construir com a mesma velocidade mas em pequenas e confortáveis conclusões diárias. Para tal o time utilizara-se de três medidas o bandwidth, latency e o throughtput  que são nesta ordem a quantidade de stories ou tarefas que você consegue fazer simultaneamente (O kanban define o limite do seu bandwidth por etapa), o tempo que cada uma destas demora até que seja concluída e por fim a vazão, que leva em consideração a quantidade de tempo na passagem de uma etapa para a outra, muito usada para a quantidade de conclusões diárias.

Métricas no card wall - Paulo Caroli

*Vale a pena ler o artigo do Caroli sobre como eles desenvolveram uma tática ecologicamente sustentável, mas socio-higienicamente desfavorável para evidenciar de forma automatizada o latency. Latency and banana

Em seguida o Paulo apresentou efetivamente a adição no card wall de limites, que segundo ele auxiliam na consciência coletiva juntamente ao pull system, promovendo uma movimentação constante no time para actionstages mediante a impossibilidade de promover uma tarefa devido a um limite existente.

Segundo Paulo os limites ainda podem ser agregados à uma sequência de  priorização por elevação no card wall, onde quanto mais próxima do topo do quadro uma story está mais prioritária a mesma é, para que possamos trabalhar ainda mais a reatividade do time as mudanças do processo e do fluxo de forma auto organizada!  Oque está mais elevado é mais importante, cada membro do time só executa uma tarefa por vez, existe um limite em algumas etapas! Então tudo flui prioritariamente e ninguém trabalha fora da ordem necessária!

Em um card wall podem existir também  abaixo do granularidade de user stories, as tasks. O cardwall trabalha com stories, que são divididas em tarefas, então dentro de cada uma das fases teríamos o desenvolvimento em novas raias como to do, doing e done! Vejam o blog do Alisson Vale, que fala um pouco mais sobre esta técnica de sub-representação.

Outra sub-divisão que rondam os card walls e que são realidade em qualquer projeto de software, mesmo aquelas com qualidade superior a 90%, são os BUGS. Para o Caroli este devem ser evidenciados e priorizados! Quando existem muitos bugs este devem ser elevados a uma nova raia que deve ser tratados com regras de uma passing lane, você deve deixá-la sempre desocupada e só usá-la em momentos críticos, quem está nela está sempre em uma velocidade maior e é sempre prioritário!

A apresentação do Apulo acabou com um conjunto de perguntas sobre as quais enfatizou-se a refatoração dos card walls, adaptando durante os tempos coletivamente em sua equipe. Tente aproveitar as outras dimensões do seu quadro! Complemente-o com outras tecnologias!

Slides da Linha de Montagem de Software

Luiz Faias Junior - Aprendizado

Na tarde do dia 29/11 tivemos a frente do palco do Agile Day 2010 Porto Alegre o Luiz Faias Jr.,  diretor de tecnologia da Bluesoft, compartilhando em sua palestra os conceitos e idéias que vem refletindo e aplicando sobre a criação de um ambiente  aprendizagem!

A palestra foi iniciada às 14:30h com várias perguntas rápidas, no qual em pouco tempo o mesmo admitiu se tratar apenas de uma brincadeira para para o pessoal levantar o braço e acordar! Bom início para mobilizar o pessoal e iniciar a dinâmica do nosso aprendizado!

Segundo ele, uma equipe e sua falta de motivação pode se motivar mas este problema não é só dela, e se você é um dos maiores interessados nisto, seja você o gerente ou não como foi o caso dele e do André Farias, você tem que encontrar uma forma! A forma da bluesoft foi encontrar pessoas certas, fomentar boas idéias, criar um momento de aprendizagem com foco no compartilhamento interativo de conhecimento entre outras coisa que resultaram hoje em mais de 100 palestras e um blog que enriquecem ainda mais a comunidade.

Segundo ele a idéia para este ambiente começou com a criação da empresa e foi inspirada pela visão ágil dele e do André mesmo antes deles realmente conhecerem esta palavra. Depois estudando afundo a agilidade, alinhando alguns conceitos promovidos pelo Ricardo Semler, conceitos do google e do jeito Toyota, alterando a forma de tratar cada um dos membros do time como adultos e profissionais, o crescimento prevaleceu!

O ambiente de trabalho tem que inspirar confiança! Neste momento foi exemplificado pelo Luiz  os ganhos em promover a cultura da confiança e como ela incentiva o aprendizado. Na Toyota não é porque ninguém viu que algo não deva ser corrigido, é relatado que no primeiro dia de um funcionário na linha de montagem, após o mesmo cometer um erro que poderia ter gerado um certo prejuízo,  um dado funcionário foi parabenizado pela iniciativa de apresentar o mesmo em seu primeiro dia mesmo tendo em vista uma possível demissão em seu primeiro dia. Segundo o Luiz nao se deve fomentar uma cultura de méritos baseada na não  realização de erros,  ou muito menos passar sempre a mão na cabeça de seu companheiros, deve-se encontrar o equilibrio e criar um ambiente em que os problemas tornem-se oportunidades de melhorias.

Um ambiente de trabalho focado em aprendizagem deve manter todos motivados e propensos a caminhar na mesma direção, empresas buscam lucro, ter sucesso em longo prazo, contribuir para a sociedade, ter excelencia e qualidade; assim como as pessoas que lá trabalhavam visam melhores salários, crescimento profissional, reconhecimento, um bom local de trabalho e trabalhar em algo significativo.Ambos querem prosperar e se estes estiverem navegando em rumo a um ponto comum todos vão chegar lá mais rápido! Para isso deve existir confiança mutua, cada um deve acreditar que o outro fará de tudo para ajudar a alcançar estes objetivos.

Mas nem todos conseguem se acostumar com este tipo de pensamento, então para ele existem algumas qualidades importantes que que fundamentam este comportamento, a primeira destas é a iniciativa. Toda e qualquer ação se alcança com movimentação e não inércia, então um bom parceiro para atingir objetivos mutuos deve ter iniciativa para apresentar suas idéias, para se envolver nas idéias alheias, para efetivamente participar da construção dos produtos e de um ambiente melhor. Logo em seguida o Luiz falou da necessidade de ter paixão pelo que se faz, um bom parceiro na busca incondicionalmente algo ele se diverte enquanto faz isso.

Um bom membro para este time deve também buscar todos os dias a excelência, neste ponto houve uma ressalva na qual houve uma unânime concordância, trabalhar muito não significa praticar muito em busca da excelência, você pode estar repetindo algo errado o tempo todo.A prática correta é que leva a perfeição. Trabalhar bem não é trabalhar mais e sim trabalhar melhor!

Escutei de um dos meus líderes técnicos e concordo plenamente que o TRABALHO TEM QUE SER MOTIVANTE, ou ele te motiva ou você motiva ele, caso nenhum dos dois acontecer procura um novo! Não espere que alguém chegue com uma idéia genial que vai mudar teu trabalho, ajude a construí-la.

Para trabalhar as idéias o Luiz apresentou os conceitos de Hansei e kaizen!! O Hansei é uma reflexão profunda para identificar um problema e o kaizen são as iniciativas para melhorar continuamente. Segundo ele estas devem ser praticadas nas retrospectivas em relação a novas idéias ou antigos problemas e sempre que se tiver uma iniciativa de apontamento de solução apoiado pela equipe, alguém deve implanta-lá e constantemente facilitar seu monitoramento, pois idéias não devem ser desperdiçadas !

Um bom membro para esta equipe deve conseguir se adaptar facilmente, estes caras devem ou desejam ser poliglotas, para o Luiz auto-intitularse como desenvolvedor Java pode acontecer, mas ninguém deve se ver como imutável. Este membro gosta de ensinar e normalmente não gosta apenas de dar as respostas, ele faz perguntas aos demais até que eles mesmos descubram! Água parada apodrece, faça o conhecimento circular…

A bluesoft fazendo a parte dela nesta sinergia, tratou de fomentar um ambiente de aprendizagem. Primeiramente criando uma biblioteca de qualidade, com uma série de livros físicos e virtuais, para que todos tenham acesso; em seguida estimulando a leitura e o compartilhamento deste conhecimento, segundo ele sempre tem alguém estudando ou lendo um dos livros para compartilhar este conhecimento.

É importante citar trazer neste ponto algumas das referências passadas por ele, quem souber mais alguma manda um comentário que vou adicionando.

Biblioteca on-line:

1. Safari Books Online:
   http://safaribookshelf.com/ - $22,99 para acessar 10 livros por mês.
2. Audible.com:
   http://www.audible.com/ – $22.95 para ouvir dois audio book por mês.
3. Peepcode Screemcasts:
   http://peepcode.com/ – $12 para baixar um screencast ou $199 para ver todos por um ano.
4. Railscasts:
   http://railscasts.com/ – Gratuito.
5. AkitaOnRails

Outras estratégias legais são os grupos de leitura ou estudo, seja cada um lendo o seu, ou todos lendo o mesmo; programação em par; dojos… O importante é debater e aprender! Ilhas de conhecimento nunca!

A melhor forma de aprender e fazendo! Então sempre depois que você ouvir muito podecast, faca o teu! Depois que você ler um blog faca o teu! Participar de eventos é massa mas passar o conhecimento sobre oque você viu para os demais é ainda melhor! Esse processo ainda faz com que todos melhorem sua atenção, pois terão que ensinar!

Participar de comunidades! Nós já ganhamos muito todos os dias das comunidades e também acho que devemos dar algo em troca, nos temos que mover a máquina, todos nos ajudam a crescer e nós fazemos oque em troca? Participe! Entre no Guj e faça alguns questionamentos ao invés de dar algumas respostas para que bons documentos sejam gerados, contribua intelectualmente ou financeiramente com o  wikipidea, seja comiter de algum framework.

Planejamento e  faça Retrospectiva. Para o Luiz o crescimento deve envolver todo o time e não apenas trabalhar para ele e então aja como um coaching e nao como um instrutor!

Yokotem, todo mundo tem que busar uma forma de desenvolvimento, todas as sementes são iguais em sua origem, mas podem se tornar arvores diferentes. Tudo deve ser entendido e melhorado e não apenas copaiado! Você tem que entender os princípios e não só as praticas!  O ritualdo gato preto foi citado, as vezes repetimos algumas praticas sem saber o motivo então não adianta amarrar o gato que não precisava estar ali!

Nem todo mundo se adapta, se seu time quer evoluir, se todos querem melhorar então todos devem procurar formas para melhorar, se não todos não chegarão!

Por fim o Luiz concluiu com uma afirmação de conceitos, que acredito bastante, ou você paga agora ou vai pagar depois! Este formato de incentivo no qual a empresa apoia a criação e o crescimento desta cultura de aprendizagem não só é o ideal como o mais favorável ao crescimento de profissionais e empresa. Investir dinheiro nisto é aumentar a qualidade técnica e aprimorar os laços de confiança e respeito mutuo.

VALEU LUIZ E ANDRÉ… por mais uma empresa que estimula as boas práticas e a vontade de crescer no nosso mercado.

Construindo uma cultura de aprendizagem

Agile day 2010

O Agile Day 2010 POA, começou oficialmente as 09:00h, com o Daniel Wildt que apresentou a idéia do evento e seu formato com aquele entusiasmo agilista que sempre vemos nele! Para este ano foram 114 inscritos e 1 palestrante faltante, o André Nascimento não foi. Logo em seguida o Klaus foi apresentado e começou um dos keynotes planejados para o dia.

A palestra iniciou-se às 09:20h com o Klaus questionando quais dos congressistas efetivamente trabalhavam com desenvolvimento de software, e destes quais já haviam colocado software em produção! Ele disse que estes eram os caras que ele respeitava.

Klaus Wuestefeld Agile Day 2010

Logo em seguida o Klaus começou a apresentar um pouco da sua historia, desde a casa dos amigos com o código do caça-níquel, escapando de métodos formais após a ida ao evento XP na Itália em 2000 e  passando pelo plug-in Byecycle – fractal feito com o Kent beck em uma semana até o dia de hoje e o agile day e o dilema a ser tratado nesta palestra… Como e até quanto ponderar qualidade de um projeto mediante o pedido imediatista de urgencia de seu P.O.. pois se temos duas variáveis e teoricamente só podemos aumentar uma, diminuindo a outra…

Sem demora o Klaus atirou uma pergunta aos congressistas, quais de nós tinha ou conseguia discernir a qualidade dos seus códigos ou dos demais no dia-a-dia e quais de nós priorizavam um dos dois fatores temas da discussão mais que o outro… Poucos priorizam qualidade, muitos o prazo e um pouco menos em um bom equilíbrio entre ambos!

Logo em seguida impulsionada pelas respostas e fazendo referencia com a natureza fractal dos códigos o Klaus iniciou os trabalhos em exemplos para mostrar a similaridade inconsciente sobre as avaliações qualitativas! Fizemos algumas alterações e por coincidência chegamos em um método mais simples e coletivamente reflexivo como de maior qualidade. Em seguida realizamos uma segunda refatoração, que foi de imediato verificada a não necessidade de todo o método por alguns de nós, mas que calmamente o Klaus nós conduziu em baby steps em toda a refatoração até esta eliminação.

Dentro deste método existia um comentário um pouco inapropriado //METRO DE SAO PAULO, que só foi removido em um dos 5 baby steps sobre gargalhadas. Então o Klaus relatou os níveis de limpeza do metrô de são Paulo mediante a quantidade de passageiros transportados diariamente e nos mostrou um método inconsciente de manter a limpeza de códigos fazendo! Um código limpo de 4 linhas, assim como o metrô, subconscientemente induz o cidadão a pensar duas vezes o lugar que este irá sujar com mais duas linhas criadas de forma não pensada ou elaborada.

Em seguida tivemos questionamentos sobre qual a claridade de nossos códigos, de 0 100%, no qual, segundo o Klaus, 0% são códigos escritos por mil macacos e 100% como algo impecável, onde nada precisa ser mudado. A maior quantidade dos congressistas definiram entre 50 e 70% e pouquíssimas acima disto!

Segundo o Klaus uma equipe de formula 1 tem entre 98% e 99% de qualidade, assim como cozinhas profissionais tem limpeza suficiente para se lamber um balcão. Por um pensamento imediatista e impensado, temos que as atividades realizadas por estas equipes poderiam ter sido feitas da forma aparentemente mais produtiva caso estas não se preocupassem tanto com a qualidade, fazer jantares sem “gastar tempo lavando louça” ou “pegando e guardando ferramentas”. Estudos provam que em longo prazo isto atrasa o processo e demanda muito mais tempo e esforço. Segundo o Klaus a preocupação com a qualidade pode ser momentaneamente aliviada mas nunca deve ser abandonada ou fortemente acumulada!

Foi apresentando em seguida um gráfico de produtividade de equipes de TI, no qual se tornou visível a semelhança comportamental em desempenho de equipes despreocupadas com débito técnico ao longo do tempo. Existirá sempre a dificuldade de realizar algumas tarefas citadas quando não estamos trabalhando com a qualidade suficiente.

O dilema não é prazo vs qualidade e sim produtividade hoje e produtividade sempre. Com qualidade para o Klaus beirando os 98% a equipe chega a sua máxima de produtividade!

Os congressistas estão bem longe disto, existem fatores, explicações e outras desculpas para isso, foram apresentadas a falta de capacidade para avaliação se esta ruim, não se vê a importância disto. overdesign e visão de curto prazo do negocio, como algumas delas.

Para o Klaus muita da sujeira em código esta ligada a dificuldade em se ver, diariamente e de forma simples, o código e sua dependências; uma falha é mais fácil de ver quando tudo está mais simples!

Por fim devemos nos preocupar com padrões e boas práticas técnicas ao invés de nos digladiarmos em dilemas como qualidade e prazo, com toda certeza qualidade sempre para que o prazo seja sempre mais real e a produtividade maior.

Klaus terminou sua palestra com um ditado do GO, ”perca suas primeiras cem partidas a mais rápido possível”.