Agilidade é um meio, não o fim

Esse excelente artigo escrito por Alisson Vale, trata bem da questão que sofremos por conta do modismo e das ideologias.

https://medium.com/software-zen/a-morte-do-agilismo-e-o-que-isso-pode-significar-pra-voc%C3%AA-4b365a289301#.4p6aj68pf

Ignorar o contexto e "usar por usar" ou "fazer por fazer" tem um custo alto e que muitas vezes fica imperceptível até surgir aos nossos olhos como fracasso.
Para os desenvolvedores, sendo mais específico: metodologias, frameworks, patterns, práticas... entenda em que podem ser usados e o porque de seu uso, além das interdependências de seus pedaços. Entenda o conceito por trás de cada coisa sem ficar preso a ela. Abra sua mente. Isso amplia seu conhecimento e, consciente de seus problemas reais, permite que a ferramenta certa seja usada na hora e na situação mais adequada. Como dizem: não pense fora da caixa; pense como se não houvesse caixa.
É uma tarefa árdua para quem aprendeu que existe um "melhor", um "correto" e vive na zona de conforto sem desafiá-la como se o mundo tivesse que mudar aos moldes de seu restrito conhecimento. Somos moldados assim e é difícil lidar com isso.
Nosso objetivo está claro? Vamos atender ao cliente? Vamos desenvolver o melhor produto dadas as restrições? Sendo assim, podemos utilizar técnicas e ferramentas de um grande leque que temos disponível. Mas quais? Simplesmente... depende! Temos acesso a muito conhecimento explícito hoje em dia (a internet a total disposição!), que junto ao nosso conhecimento tácito, à nossa experiência e à consciência do meio que nos cerca podemos conseguir muito e garantir a melhoria contínua!

E a agilidade? Continua ajudando muito, obrigado! Ela auxilia a alcançarmos o objetivo. Ninguém e nenhuma empresa deve ter como meta simplesmente ser ágil. Não devemos ser por ser. O objetivo é resolver o problema; entregar a solução para o cliente. Então, agilidade é um meio, não o fim.

Ferramentas ágeis e gestão de tarefas

Similar ao post anterior, segue uma lista de ferramentas ágeis em plataforma web. Algumas têm foco na gestão de tarefas, mas podem ser usadas da mesma forma. Todas as listadas são ou tem planos gratuitos com certas limitações de quantidade de projetos e quantidade de colaboradores. Confira:

serviço (limite de quadros; limitede usuários)

• http://leankit.com (3 kanbans; até 10 usuários)
• http://www.swiftkanban.com (10 quadros; 20 usuários)
• https://www.kanbanpad.com (única opção de conta = free)
• http://flow.io (1 quadro; 1 usuário)
• http://www.hansoft.com (sem limite de projetos/programas; 9 usuários *)
• http://www.targetprocess.com (sem limite de projetos; até 5 usuários ¹)
• https://www.mavenlink.com (projetos, tarefas e colaboradores ilimitados ¹)
• https://asana.com/ (projetos ilimitados; até 15 colacoradores ¹)
• https://trello.com/ (projetos, tarefas e colaboradores ilimitados ¹)

* possui plano educacional mais completo que a versão gratuita
¹ tem app para tablet/smartphone

A Parábola dos Lenhadores

Este conto eu ouvi do consultor da IBM Gustavo Grillo e achei uma excelente parábola sobre o uso errado de uma ferramenta.
Consegui encontrar na internet o link do post do próprio Gustavo. Segue o link e o conteúdo da "estória".
https://www.ibm.com/developerworks/community/blogs/rationalbrasil/entry/a_f_c3_a1bula_dos_lenhadores10?lang=en

Era uma vez, nas profundezas de uma densa floresta, uma vila de lenhadores. A vila era sustentada pelos lenhadores que cortavam árvores com seus reluzentes, ainda que antigos, machados. Eles eram bons nisso.
A cada ano que passava eles precisavam cortar mais e mais árvores para acompanhar a demanda, que era cada vez maior. Ao mesmo tempo, alguns lenhadores, decepcionados com a vida dura que levavam, acabavam indo embora da vila para tentar novos trabalhos, e não eram substituídos pois não haviam mais jovens na vila.
Um belo dia, um dos lenhadores pensou: "Não é possível, deve haver uma maneira melhor de fazer isso!" e resolveu viajar até uma vila do outro lado da montanha para descobrir como eles cortavam as árvores por lá.
Eis que ele volta todo entusiasmado e com uma nova ferramenta: uma serra de corte transversal, dessas que lembram um serrote, só que com a lâmina bem mais comprida em que fica um lenhador de cada lado e quando um puxa o outro empurra. Ele havia aprendido como usar a nova serra e desenvolveu um novo processo para cortar as árvores com esta nova ferramenta.
Este lenhador treinou toda a vila à exaustão, fazendo com que todos aprendessem a usar a nova serra e seguissem o novo processo. Os lenhadores se tornaram mais produtivos e ficaram felizes apesar de alguns pequenos problemas que a nova serra causava.
Algum tempo depois, um vendedor itinerante chegou à vila dos lenhadores e percebeu que eles usavam a serra transversal. Ele reuniu os lenhadores e anunciou:"Eu tenho uma ferramenta que vai revolucionar a forma como vocês trabalham". E mostrou a ferramenta.
Os lenhadores ficaram um pouco céticos, e disseram: "Ok, vamos testar a sua ferramenta, mas temos uma exigência. Sabe, nós gastamos tanto tempo e esforço, treinando no uso da serra transversal e no processo que nós não queremos mudar a forma como trabalhamos, nem o nosso processo. Deu muito trabalho desenvolver isso tudo e vamos tentar usar a sua ferramenta, mas do nosso jeito"
O vendedor coçou a cabeça, ficou meio apreensivo, mas acabou concordando. Ele trouxe os melhores técnicos da sua empresa para ensinar os lenhadores a usar a nova ferramenta, mas depois de poucos dias de testes e demonstrações os lenhadores concluíram que eles eram mais produtivos com as suas velhas serras transversais do que com a nova ferramenta.
Desapontado, o vendedor voltou com os técnicos para a sua empresa. O dono da empresa o chamou para que explicasse como não havia conseguido efetuar a venda:
- Nós temos a melhor ferramenta do mercado para cortar madeira! Ela é insuperável no corte de árvores! A economia deles é baseada no corte de árvores! Como as demonstrações não mostraram isso?
E ele respondeu:
- Bom, nós realmente temos a melhor ferramenta. Mas os lenhadores precisariam ter ligado as motosserras, e as utilizado da forma que uma motosserra deve ser usada.

Moral da história: Se você usa uma motosserra como machado, não reclame que ela não atende às suas necessidades.

As sete ferramentas da qualidade

Segue o link para um post que descreve muito bem as 7 ferramentas de qualidade organizadas por Ishikawa. Estas ferramentas conseguiriam tratar a grande maioria dos problemas.

http://www.blogcmmi.com.br/qualidade/as-sete-ferramentas-da-qualidade

São elas:

• Diagrama de pareto
• Diagrama de causa e efeito
• Histograma
• Folhas de verificação
• Gráfico de dispersão
• Fluxogramas
• Cartas de controle

Vale a pena ler!

Guerra de gerações no projeto

Essa guerrinha não levará ninguém a lugar algum. Nunca levou e não vai levar. Na realidade levará sim... para o mesmo alugar onde a arrogância sobre o outro empurra: para trás.

Estava acompanhando um webinar sobre gestão de projetos, técnicas de facilitação etc, quando um participante escreveu no chat do grupo um problema que passava em sua empresa com relação a novas ferramentas e formas de trabalho. Muitos concordaram e, para o meu espanto, o bom senso foi muito maior que eu esperava na pequena discussão (que logo acabou para retornar à apresentação). Vejo, felizmente como muitos outros (sim, felizmente), que nas empresas (principalmente nas maiores) os mais experientes tem certa resistência em aceitar novas formas de trabalho. E em contrapartida, há muitos recém chegados da faculdade, que fizeram alguns cursos ágeis ou participaram de um projeto em uma startup, achando ter a solução para todas as respostas sem nem saber quais são as perguntas.

OK...vou explicar melhor. Entre a teoria e a prática há hiato. Junto com a cultura, esse hiato desencorajou os mais antigos que aprenderam - e sempre viveram com isso em mente - que este é um vale proibido (você assistiu Planeta dos Macacos? Tipo aquilo). Os recém chegados, por outro lado, estão repletos de novas técnicas (+), cheios de si (+), mas têm certeza que são os salvadores do mundo (-) e que todo o resto é uma cambada de ignorante (-). Muitas vezes estes não entendem realmente os conceitos e nem o status quo da empresa que estão entrando, partindo da suposição que só existe uma forma das coisas funcionarem: a novíssima metodologia que alguém inventou em um lugar distante e que ele viu num blog por aí. É claro que testar técnicas é válido, mas antes de aceitar o risco, identifique-o.

Alguns de cabeça antiga esperam ser solicitados, são passivos e não discutem com seu superior, pois seria falta de respeito (muitas vezes este superior acha isso mesmo quando alguém o questiona). Os de cabeça nova querem revolucionar a empresa de forma drástica, ignorando o ambiente como um todo e pensando somente no seu quadrado e naquele período de tempo: uma errada interpretação de coragem, iteração e acolhimento de mudanças. Decorar não é entender e muitos decoraram o manifesto; têm a resposta na ponta-da-língua para tudo... desde que se enquadre no seu cenário perfeito, claro.

Você não concorda que há algo de errado quando o "Sr. João" vê um fracasso, muitas vezes óbvio, de quem voluptuosamente inicia uma empreitada sem conhecer o terreno (desconsiderando as características do local onde está e achando que tudo ocorrerá igualzinho de como naquela empresa caso-de-sucesso da palestra do Agile Brazil), como justificativa para não mudar nada?

Você não concorda que algo não está certo quando o "Marquinhos", teoricamente mais esclarecido (pois aprendeu numa escola a frente de seus colegas de trabalho mais antigos), cometer os mesmos erros básicos de algumas pessoas de gerações atrás que ignoraram a adaptação, interpretaram as coisas como lhe convinham e achavam que estava tudo errado até a ideia deles surgir para simplificar exageradamente a complexidade? Enaltecer os defeitos do outro quando se está prestes a repeti-los não é nada bom... assim como é péssimo achar que a diferença dele para o super-homem é que o super-homem enfraquece com a criptonita.

Num ambiente complexo, temos que estabilizar ou minimizar um grande número de variáveis para que seja possível lidar melhor com tudo que está fora do nosso controle. É isso que o ágil propõe. Se o problema dos projetos é comunicação e é possível utilizar formas de mantê-la eficiente, vamos utilizar estas técnicas e nos organizar de forma a mitigarmos este tipo de preocupação e, assim, podermos focar mais na mudança de requisitos, por exemplo. A maioria das técnicas e ferramentas, assim como os conceitos básicos por trás do manifesto, não foram criados agora; é tudo coisa velha aglutinada de forma excelente! É o uso correto de todo esse conhecimento unido ao entendimento dos conceitos por trás de cada princípio a ser adotado que faz e fará a diferença. É a integração das novas misturas e novos sabores com o que já existia que impulsionará o mundo. É a adaptação com a boa estratégia de mudanças na organização que levará sua empresa ao sucesso. Se você está em uma startup, excelente! Muitos problemas carregados de "outras vidas" não existirão! Mas se você está em uma multinacional (ou governo) com estrutura e pensamentos antigos e problemas culturais gigantescos, o caminho para a excelência será traçado de uma forma um pouco diferente dos desenhos Disney, como é pregados em muitos testemunhos ágeis.

Quanto ao "Sr. João" e ao "Marquinhos", deve haver bom senso e desejo de vitória coletiva, cientes de que todos erramos, sempre aprendemos e precisamos conhecer antes de criticar. É um cabo de guerra que não leva ninguém a lugar nenhum. Ao invés de se complementarem e crescerem juntos, "Srs Joões" e "Marquinhos" ficam todos numa disputa querendo apontar o erro do outro. Entender os conceito ágeis é uma excelente forma de começar. Eu disse entender, não decorar. Entender as razões de um grupo de experientes pessoas terem chegado a tais "mandamentos" é essencial, assim como entender a cultura da sua empresa e o perfil de seus colegas de trabalho.

Recomendo artigos do Klaus Wuestefeld e do Manoel Pimentel, na internet ou no MundoJÁgil; sempre falam deste ponto que para mim é o mais delicado e decisivo: comportamento. E também este link para entender um pouco como as pessoas da geração Y são como são: Porque os jovens profissionais da geração y estão infelizes.

... Má interpretação do gráfico da baleia... "pessoas precisam ser mandadas e pressionadas"... "o importante é entregar (qualidade ninguém vê)"... "nós fizemos o que o cliente pediu".
Software não é um prédio. O produto é abstrato. O projeto de desenvolvimento é algo criativo; gera um resultado único. O desenvolvimento não uma linha de produção.
Algumas certezas foram trazidas e algumas comparações foram feitas no passado e nos fizeram chegar em alguns problemas de entendimento. Por favor, entusiasta de métodos ágeis, não cometa os mesmos equívocos!

Agile Trends 2014 SP - pontos positivos e negativos do evento

Boa noite galera!
Após deixar meus registros dos dois dias de evento, gostaria de sintetizar pontos positivos e negativos na minha perspectiva.

Positivos:

• Palestrantes muito bons com temas no mesmo nível.
• Deram, enfim, mais valor a empresas reais que são pelo menos um pouco maiores do que normalmente falam nos eventos (normalmente o foco são as startups). Isso foi muito bom, pois direciona melhor como realmente o ágil pode ser aplicado em empresas que já andam por si, empresas com um número de milhares de pessoas e empresas que desenvolvem há décadas com cultura forte em outras metodologias e formas de gestão. A importância da estrutura formal/hierárquica, a maneira como a alta gerência lida com isso e falta de capacitação adequada são os grandes problemas que precisam ser vencidos.
• O feedback ao final de cada trend talk, como vem acontecendo também no Agile Brazil, continua sendo uma ótima ferramenta.
• O quadro de feedback do evento também funcionou muito bem, como por exemplo, o ar condicionado que estava forte demais de manhã foi amenizado após o almoço.
• Sempre teve espaço para as pessoas participarem dos eventos escolhidos.
• Happy Hour no primeiro dia de evento para integração e networking.
• Mais situações reais e dicas de como mudar o nosso dia-a-dia de maneira prática e realista.

Negativos:

• Um trend talk de Análise de Negócio de uma pessoa que não vou citar o nome foi muito agressiva e até faltou com respeito com o Cláudio Keber, que apresentou o mesmo assunto anteriormente com uma ótica um pouco diferente. Achei no início que estava brincando, mas ficou muito chato mesmo... Esse não volta.
• Ar condicionado do auditório principal (sala Insights) muito forte nos 2 dias; no segundo estava absurdo e corrigiram após o almoço.
• A tela da outra sala menor (Sinapses) estava muito baixa no primeiro dia; subiram um pouco no segundo.
• Muita gente reclamou de falta de guarda-volume no primeiro dia; no segundo já tinha :)
• Atraso no início dos talks prejudicava as rodadas de discussões que a organização frisava ser o mais importante do evento. Acabava que essa rodada tinha tempo somente para 2 perguntas - quando tinha.
• Ao final dos talks sobre "Aprendendo a tomar decisões em equipe" (Haddad) e "The PornoAgile" (Manoel Pimentel), a Erica (garota de cabelo cor-de-rosa) fez a melhor pergunta ou explanação do evento justamente colocando em questão o que é ignorado nos eventos de agile - em que muitas vezes os cenários são tratados sempre em estado de Nirvana, num mundo perfeito como se em todos os lugares as premissas para o ágil perfeito estão presentes. Ao terminar sua colocação, a staff deste trend talk encerrou o a rodada de perguntas pelo timebox ter acabado (ainda tinha 2 minutos e depois seria o almoço de 1h). Ninguém se incomodaria em perder 5 min do almoço que fosse para escutar os palestrantes colocarem suas posições sobre a importância financeira na quebra de paradigma de uma empresa já inserida no mercado. Muito negativo para o evento em que os staffs precisam ter sensibilidade e talvez um conhecimento mínimo do assunto para não fazer uma besteira dessa. Para mim era o ápice do dia e ele foi cortado de forma ridícula chata.
• No primeiro dia teve duas palestras meio fora da curva o que ajudou a cair a qualidade nesta data.
• Alguns agilistas xiitas sem vivência do agile fora de startups ou sem visão empresarial impondo certos pensamentos que muitos visitantes acabam ignorando - para este tipo de pensamento e material pegamos na internet e não precisaríamos ir em um evento de tendências. É bom para quem está conhecendo métodos ágeis e por isso deve-se manter nos eventos, porém com cautela e de forma equilibrada com os demais pontos focais.

Bem... apesar dos pontos negativos parecerem muitos, não influenciaram na qualidade do evento que foi excelente!

Em suma, pontos básicos foram ignorados inicialmente (o que mostrou certa falta de experiência talvez dos staffs) e corrigidos durante o evento (força da melhoria contínua). Para mim o excesso de confiança de parte da organização e a falha de uma comunicação correta entre eles (orientação de comportamento e valores) foram os responsáveis pelos pontos negativos. Já o feedback foi a palavra chave para o sucesso do Agile Trends 2014, usando outros eventos como base para o planejamento deste e os quadros para correções pontuais no decorrer dos 2 dias.

Abraço!

Agile Trends 2014 SP - segundo dia

O dia começou com um aviso de correções de pequenos problemas do primeiro dia (atrasos, guarda-volume e importância da rodada de discussões). Depois disso veio um lote de palestras excelentes deixando o segundo dia bem melhor que o primeiro.

Para registro, os atrasos continuaram e as rodadas foram prejudicadas novamente, além do clima glacial do auditório ser motivo de reclamação coletiva.

O key note do Roy Singham sobre "Agile's Heritage: Defending a just and free internet" foi excelente e deixou muita gente pensativa sobre como usamos, espionagem, marco civil e como direcionaremos nosso uso daqui para frente. A internet e seu uso foi tema de outro excelente key note depois do almoço do professor-doutor Lulli Radfahrer sobre "A internet de tudo".

Assisti e gostei da palestra do Alexandre Freire sobre falha em projetos ágeis ou não. Também gostei da "Escalando ágil com SAFe" apresentado pela Sandra Santos da IBM, pois não conhecia o SAFe e achei muito interessante para grandes empresas e governo, pois mostra como atuar na organização inteira e não somente no time (dê uma olhada: http://scaledagileframework.com/).

Os talks do Matheus Haddad sobre tomar decisões em equipe e a do Manoel Pimentel sobre o "PornoAgile - uma visão apenas para maiores" foram muito bons com destaque para a do Manoel que trouxe uma visão mais realista de empresas grandes e não startups. No final de ambas, uma falha grotesca da organização finalizou com uma excelente questão de Erica em aberto: -2 para a organização por isso.

Por fim eu fiquei nas técnicas de facilitação do pessoal da K21 (Marcos Garrido e Rafael Sabbagh) com 50min de workshop que pincelou o que um scrum master ou papel similar deve fazer em certas situações na condução de um projeto com equipes reais. Muito bom, mas para quem já havia feito o treinamento de CSM com eles não houve muita coisa de diferente.

O evento continuou até 19h, mas precisei sair às 17h por conta do fretadão para Santos!

Blog sobre Gestão de Projetos

Segue o blog do meu professor, Nelson Rosamilha, no curso de Gerenciamento de Projetos (que terminei faz 3 anos... :o):
http://nelsonrosamilha.blogspot.com.br

Glossário de Gestão de Projetos

Recebi um e-mail comum livro/dicionário de termos de gestão de projetos em inglês. Procurando um pouco na internet, apesar de achar que não tenha todos os detalhes do livro, encontrei alguns sites interessantes com glossários.

• Wideman Comparative Glossary of Project Management Terms v3.1: http://maxwideman.com/pmglossary/ 
• Glossary of Project Management Software Terms: http://glossary.tenrox.com/
•  PMHut PMO and Project Management Dictionary: http://www.pmhut.com/pmo-and-project-management-dictionary  
• Method 123 Project Management Glossary (simples): http://www.method123.com/project-management-glossary.php 
•  Wikipedia: http://en.wikipedia.org/wiki/Glossary_of_project_management

Até!

Gestão de Projetos com Tecnologia Livre

Hoje em dia temos muitas aplicações que agilizam nossas atividades e controlam para nós informações preciosas. Isso acontece em quase todas as áreas e em gestão de projetos também. O problema que o custo de ferramentas para GP, que nos auxiliam no gerenciamento, acompanhamento de um projeto, controle de custo e prazo, entre outras coisas, normalmente é pago.... e bem pago. Sempre fuçando tecnologias livres, me deparei com algumas ferramentas que não conhecia e confrontei com algumas já sabidas para fazer uma análise.

Eu dou muito valor às aplicações web, pois independem de plataforma e podem ser acessadas de qualquer lugar, mas sei que os recursos são restritos. O problema maior é a abrangência e supercialidade de recursos principalmente gráficos que aplicações disponíveis em PHP (ou qualquer uma outra linguaegm web) possuem, pois detêm o conceito do trabalho em grupo, contendo fórum, wiki, gerenciamento de arquivos e envio de tickets para execução das tarefas, enquanto as aplicações desktops tem mais o foco da gestão e acompanhamento.

Em PHP destaco o PHProjekt e o dotProject que são muito bons e possuem recursos similares citados acima: são groupwares.

Já para desktop, destaco estas 2 ferramentas desenvolvidas em Java, que são multiplataformas:

XMind - Projeto similar ao FreeMind, também feito em Java, mas na minha concepção muito mais organizado e amigável. Ele permite escolher o tipo de exibição do diagrama, enquenato o FreeMind apenas trabalha com o de idéias livres. Com o XMind você consegue montar uma EAP, organizar um brainstorming, espinha de peixe, por exemplo, entre outros. 

OpenProj - Também feito em Java, mas muito parecido com o MS Project. É como um pedacinho do software da Microsoft, mas tem tudo que se precisa para gerenciar um projeto: recursos, custos, prazo, gera relatórios, gráficos e uma coisa que o Project não faz: EAP. É leve, fácil e lembra muito, mas muito mesmo o MS Project. Muito melhor que o GanttProject que não tinha nada além de atividades e o gráfico de Gantt.