PROJETO 001

7 opções para lidar com interrupções em Scrum e outras práticas ágeis

noreply@blogger.com (Rafael F. Buzon) — Thu, 19 Jan 2012 02:02:00 +0000

Primeiro artigo próprio no InfoQ
http://www.infoq.com/br/news/2012/01/7opcoes-para-evitar-interrupcoes

Abs,
Buzon

Novos posts no InfoQ

noreply@blogger.com (Rafael F. Buzon) — Thu, 05 Jan 2012 13:07:00 +0000

Novos posts no InfoQ:

Desenvolvimento de software como gerenciamento de riscos?

http://www.infoq.com/br/news/2011/10/desenvolvimento-risco

Projetos de TI: 400% acima do orçamento e 25% dos benefícios esperados

http://www.infoq.com/br/news/2011/11/software-alto-risco

Adoção de Agile em ambientes de Medo

noreply@blogger.com (Rafael F. Buzon) — Wed, 03 Aug 2011 14:48:00 +0000

Mais uma tradução minha para o InfoQ Brasil
http://www.infoq.com/br/news/2011/08/agile-medo

Abs,
Buzon

O legado de Eli Goldratt

noreply@blogger.com (Rafael F. Buzon) — Thu, 28 Jul 2011 22:14:00 +0000

Mais um artigo que traduzi para o InfoQ Brasil.
http://www.infoq.com/br/news/2011/07/LegadoEliGoldratt

Abs,
Buzon

Scrum Alliance reforça a certificação de CSP e anuncia exame Beta

noreply@blogger.com (Rafael F. Buzon) — Tue, 19 Jul 2011 01:40:00 +0000

http://www.infoq.com/br/news/2011/07/ScrumAllianceStrengthensCSP

Meu primeiro post (tradução) no InfoQ Brasil.

Abs,
Buzon

Torre de Babel nos guetos organizacionais

noreply@blogger.com (Rafael F. Buzon) — Tue, 12 Jul 2011 17:03:00 +0000

http://franciscogaristo.blogspot.com

Todos conhecem a estória da Torre de Babel: Depois de ver a pretensão do homem em construir uma torre que chegasse ao céu, Deus confundiu suas línguas para que não se entendessem e, com isso, o projeto da torre também não avançou mais. Isso aconteceu por volta de 200 a.C. (wikipedia)

O que poucos sabem, entretanto, é que esta intervenção divina aconteceu também na construção de software, que até hoje nos faz buscar o entendimento mútuo para realizar coisas até menos pretensiosas que uma torre, como lançar um site.

Se falar outras "línguas", todavia, dificultou nosso entendimento e nosso progresso como um todo, por outro lado nos abriu os olhos para resgatar e refletir sobre aquilo que pretendemos construir juntos. É a oportunidade de analisarmos a natureza daquilo que queremos realizar. É a oportunidade de firmarmos práticas e valores e avaliar a forma como medimos nossas ações. Detalhe: JUNTOS!!

É nítido e real este fenômeno de construção conjunta. A Web 2.0, redes sociais, Wikipedia, etc... são provas que o mundo tende a ser mais colaborativo. Mas, indo na contra-mão das tendências comportamentais e muitas vezes se mantendo inertes e enraizados à modelos ultrapassados, estão algumas áreas conhecidas como "guetos organizacionais".

Estes "guetos" falam "línguas" diferentes, tem "crenças" diferentes, defendem ações diferentes, vivem rotinas diferentes e enxergam somente pela perspectiva que os convém. São órgãos isolados em um organismo vivo. São eternos mantenedores da instituída Torre de Babel.

Mas tem jeito...

Se na Torre de Babel o homem se desorganizou e dispersou através da diferença da língua, é no falar de várias línguas que ele se reúne novamente, como narra nos Atos dos Apóstolos em Pentecostes (ainda explorando citações bíblicas). Mas qual a diferença?

Sem querer me apegar a questões religiosas, a diferença está no elemento comum envolvido nas línguas de Pentecostes: o amor. A amor, assim como a simplicidade, a valorização da pessoa sobre processos, o estar preparado para mudanças ao invés de seguir um plano, software funcionando ao invés de documentação extensa, são valores que fundamentam as ações. Logo, não importa que língua você fale, desde que entenda e busque os mesmos valores em conjunto.

O egoísmo derrubou a torre de babel. Em gestão de projetos, ou em qualquer outra gestão, é a defesa de valores que irá destituir os guetos e criar sinergia entre áreas. Nada menos que isso resolve!

Veja também:
http://projeto001.blogspot.com/2009/10/cultura-como-sabedoria-organizacional.html

Transcenda!!
Buzon

O terror para as reuniões improdutivas

noreply@blogger.com (Rafael F. Buzon) — Mon, 11 Jul 2011 11:00:00 +0000

Senhoras e senhores, lhes apresento a revolução da gestão do tempo, o "pulo do gato" no controle de pauta, o suprassumo da objetividade, o terror para as reuniões improdutivas, ele, o timer de tomate.

Ele não é um timer qualquer. É um timer em formato de tomate (o que faz toda a diferença!!). Nem é simplesmente um tomate, o que faria sentido nenhum. E eu explico o porquê...

1) Primeiro, o timer é vermelho, e, de acordo com o estudo de cores, influencia na ação, na atenção e aguça os sentidos e o foco nos objetivos da reunião.

2) E segundo, o tic, tac do timer lembra uma bomba relógio, que traz um efeito psicológico de urgência nas discussões. E, por ser um tomate, parece que vai explodir e espirrar molho em todo mundo a qualquer momento. :)

OK! Parece um pouco terrorismo, mas time is money. Você tem o dever moral de respeitar o tempo das pessoas ali presentes. Começar e terminar pontualmente uma reunião, discutindo tudo o que fora planejado, muitas vezes com pessoas de perfis bem variados, é um desafio grande. Mas com o timer de tomate, sua vida fica mais fácil.

O ministério da gestão adverte: Muitas reuniões podem tonar sua vida improdutiva! Não adianta controlar o tempo de reuniões que nem deveriam ter nascido. Pense nisso!

Referências:

Técnica Pomodoro - Gestão do tempo
http://www.pomodorotechnique.com/

Jason Fried: Why work doesn't happen at work
http://www.youtube.com/watch?v=5XD2kNopsUs
Caso tenha o poder para isso, cancele a próxima reunião e seja feliz.

Frase do dia

noreply@blogger.com (Rafael F. Buzon) — Sun, 06 Feb 2011 15:27:00 +0000

Premissa: é tido como verdade para apoiar uma ação - Restrição: limita a ação, pois é uma verdade!

Frase do dia

noreply@blogger.com (Rafael F. Buzon) — Sat, 05 Feb 2011 15:24:00 +0000

A única restrição do projeto PARAÍSO foi: Não comer a maçã! Isso prova como os projetos dependem totalmente das pessoas.

Frase do dia

noreply@blogger.com (Rafael F. Buzon) — Fri, 04 Feb 2011 15:21:00 +0000

Metade das pessoas entende que 2 mulheres não geram um nenê em 4,5 meses. A outra metade está parindo freneticamente!

Frase do dia

noreply@blogger.com (Rafael F. Buzon) — Thu, 03 Feb 2011 15:17:00 +0000

"De médico e gerente de projetos, todo mundo tem um pouco. Alguns são gerentes de projeto médicos"

Como você faz Melhoria Contínua?

noreply@blogger.com (Rafael F. Buzon) — Thu, 03 Feb 2011 10:00:00 +0000

Como você trata melhoria contínua em suas equipes de projeto? É bullshit quem diz que faz melhoria contínua e não defini práticas para que isso aconteça.

Em Scrum temos o ritual da Retrospectiva. O time todo avalia o que aconteceu no sprint anterior para repensar processos, melhorar práticas e opinar sobre possibilidades. Mas, O DIFERENCIAL, documentamos os principais itens como tarefas do sprint seguinte.

Os resultados da reunião são estudados, analisados (por vezes com técnicas como "espinha de peixe" e outras) e as práticas a serem melhoradas entram no roadmap do projeto como ações concretas de mudança que tornam efetiva as transformações e, enfim, a melhoria contínua acontece.

E ai? Como você faz Melhoria Contínua?

Você só conhece a equipe quando estima com ela!

noreply@blogger.com (Rafael F. Buzon) — Wed, 02 Feb 2011 10:00:00 +0000

Ei você, GP. Já estimou com sua equipe?

Eu tenho uma grande "estima" por quem estima com a equipe rsrs. A estimativa em grupo é, com certeza, uma das práticas das quais é possível identificar e inferir valores e insights para sua gestão. Pare de ler neste ponto se você só estima com previsões de ordem de magnitude. É preciso vivenciar os detalhes (Deus está nos detalhes. Ou na versão americana: Devil is in the detail)

Estimar com a equipe traz transparência e segurança ao projeto e aos envolvidos. Ninguém está sozinho estimando tarefas particulares, mas todos como equipe estimam e opinão em todas as tarefas.

Estimar com toda a equipe gera empatia ao time. Contribui para o desenvolvimento da equipe auxiliando-a a passar de estágios no processo de normatização.

Estimar com a equipe gera comprometimento e engaja o time. Sem contar que é uma atividade muito sadia para todos os envolvidos.

Estime você também!

Diga-me como me medes que te direi como me comportarei

noreply@blogger.com (Rafael F. Buzon) — Tue, 01 Feb 2011 10:16:00 +0000

http://www.infoq.com/br/news
/2009/11/good-agile-metrics

Como você mede o desempenho do seu time? Como você mede o seu desempenho? As respostas para estas perguntas podem mudar a sua vida e dizer o quanto você já evoluiu na gestão de sua carreira.

Goldratt (também responsável pela teoria das restrições) comentou certa vez que o modo como você mede influencia diretamente o modo como vai obter os resultados. Meio óbvio, não? Mas poucos usam esta ferramenta da forma correta ou, quando a utilizam, estão modelados ainda na forma do trabalhador manual e não do conhecimento.

Peguemos um exemplo do feliz mundo do software. Você mede e valoriza o trabalho final da equipe ou mede individualmente os membros? Seu foco é no fim ou nos meios? Você vê o trabalho de cada grupo de forma isolada ou mede o trabalho integrado como resultado final? O modo como você sorri para os fatos pode contribuir para a definição de uma cultura boa ou ruim.

Medir individualmente as pessoas, ou as células de conhecimento de determinada equipe, pode ser um fiasco se você não sabe exatamente o que medir ou valoriza os comportamentos errados. Muitas vezes uma evolução rápida de um membro da equipe não quer dizer que este está entregando um trabalho de qualidade, pois pode não estar aderente ao cliente ou mesmo aos padrões de qualidade da sua empresa. Neste caso, se você avalia, mesmo que informalmente, o trabalho desta pessoa como excepcional, pode estar dando um tiro no pé! E no pé da equipe! Seu foco está sendo prazo (tempo) e não qualidade. E todos nós sabemos o que custa mais na entrega do projeto, não? Sem contar que você pode estar incentivando o individualismo.

Medir, entretanto, o resultado final da equipe, pode também não ser o melhor dos mundos, pois você irá sempre se contentar com um resultado médio nos projetos. Pode contribuir positivamente para que a integração dos processos e trabalhos aconteça de forma mais pensada, mas ainda assim está fadado a um comportamento mediano.

Preste atenção: Você, que costuma medir os resultados finais das equipes, deve parabenizá-los com menos frequência do que gostaria. Ou deve se surpreender às vezes com projetos fora da curva, ou MUITO bons ou MUITO ruins. A questão é que você não sabe o que está gerenciando. SURPRESA!!

O segredo, portanto, está em medir a essência dos trabalhos em si. Não medir a rapidez por si só, mas em união com as validações de qualidade. Não medir os resultados isolados, mas como foram atingidos. Medir o processo convencionado pela equipe. Medir o grau de comprometimento da equipe na missão definida. Medir se o time está engajado nas tarefas que eles mesmos criaram. Medir valores e princípio que formam o framework de uma cultura que apoia processos, práticas e resultados.

É isso ai,

Abraços,
Buzon

Junior X Senior - Escopo

noreply@blogger.com (Rafael F. Buzon) — Fri, 07 Jan 2011 14:15:00 +0000

Era uma vez, na Coleta dos Requisitos:

GP Júnior: "Vamos começar logo, porque o projeto já está ficando atrasado"

GP Senior: "Só vamos terminar quando todos os requisitos, de todos os envolvidos, forem documentados e resolvidos os conflitos. Só assim posso te passar uma estimativa precisa."

GP Revoltado:"Não, isso não pode ser feito. Conversa com meu patrocinador. Vamos tomar um café!"

Era uma vez, na criação da WBS:

GP Júnior: "Não precisa, já temos os requisitos e estou terminando o cronograma. É mais rápido assim!!"

GP Senior: "Sem a WBS não temos como estimar NADA no projeto. É o fundamento de escopo e tempo"

GP Revoltado:"Insere mais uma folha neste organograma ai, porque a droga dos requisitos mudaram novamente... Ninguém sabe o que quer?? Vamos tomar um café!"

Era uma vez, na Definição do Escopo:

GP Júnior: "Pronto. Já fiz um documento que explica como será o escopo"

GP Senior: "Resolvendo esta questão no caminho crítico, tenho alguns questões que apareceram na análise de Monte Carlo que fiz "

GP Revoltado:"Vamos refinando com o tempo, porque não vamos conseguir definir isso mesmo. Vamos tomar um café!"

Era uma vez, no Controle de Escopo:

GP Júnior: "Hummm, podemos fazer sim... Creio que seja uma mudança simples."

GP Senior: "Preciso da solicitação formal da mudança para iniciar o processo de gestão de mudanças. Se aprovado, depois da análise de impacto, podemos fazer com a nova data de entrega que iremos definir."

GP Revoltado:"Você ficou louco? Quer mudar novamente o escopo? Nunca vai dar pra entregar este projeto desse jeito. Vamos tomar um café!"

Era uma vez, na Verificação do Escopo:

GP Júnior: "Não temos tempo. Ou mostramos como está ou o cliente vai ficar bravo"

GP Senior: "Com a entrega validada pela nossa área de qualidade, vamos preparar a demonstração ao cliente. Vamos verificar o que está se tornando um gargalo deste fluxo"

GP Revoltado:"Cliente nunca está satisfeito. Pede para ele ver, mas considerar que não temos tudo pronto ainda... qualquer coisa, pede pra conversar comigo. E vamos tomar um café?"

Otimismo em projetos de software

noreply@blogger.com (Rafael F. Buzon) — Thu, 06 Jan 2011 12:14:00 +0000

http://jornale.com.br/mirian/

O pessoal de TI é o mais otimista que eu conheço. O projeto pode estar atrasado 2 semanas, mas nós acreditamos muito que conseguiremos entregar amanhã, no final do dia. : D

Acreditamos que estamos fazendo um bom código, acreditamos que tudo está dentro do prazo e que os testes serão rápidos, que o ambiente de produção estará ok e precisaremos apenas "virar a chave", enfim, e mesmo que não acreditemos nisso, esperamos que o impacto seja bem baixo e simples de ser resolvido caso aconteça.

Um pouco do otimismo talvez se deva à flexibilidade que o código te dá para mudanças. Assim como um escritor ou um pintor, é possível em software rever alguns conceitos, reescrever algumas telas e adequar ao gosto do freguês. O que já não acontece na construção de um prédio, por exemplo. O cliente não poderá chegar no meio da construção, mudar a planta e querer outra composição de andares, que irá impactar no alicerce ou na reconstrução de todo o plano. Na verdade, até pode, mas vai inviabilizar a obra como um todo.

O problema do otimismo em projetos de software acontece quando há má comunicação e feedbacks demorados. O otimismo se estende até o ponto de virar crise, quando, então, morre um otimismo para nascer outros: "vamos resolver esta crise rapidamente", "deve ser algo simples que estamos esquecendo", "se eu fizer isso aqui acho que já resolve". E isso dura 2 ou mais semanas, mas sempre com o otimismo da equipe elevado.

É por ser diferente de um prédio e possibilitar tanta flexibilidade que a forma mais adequada de se conduzir tais projetos é trazer todo o ciclo de vida em iterações de curta duração. Por ser um trabalho intelectual e cheio de possíveis interpretações e aprendizados, a equipe só realmente conhece o que está construindo "em voo". Com iterações curtas a vida das questões otimistas também se reduz, não virando crises sérias a serem tratadas.

É isso ai...

Abs,
Buzon

Medida primária de progresso em software - Case pessoal

noreply@blogger.com (Rafael F. Buzon) — Wed, 05 Jan 2011 13:34:00 +0000

Existe a questão do PRONTO como medida de progresso efetivo. E o problema do falso "pronto" eu vivenciei bem na industria de software.

Gerenciei vários projetos de software no modelo cascata, onde a maioria da equipe era junior, incluindo eu. E, apesar da boa vontade, a % concluída nunca é real ou tem algum significado confiável. Ter 80% do projeto concluído, imaginando que isso represente toda a fase de desenvolvimento, não significa que os 20% restante (testes e ajustes) irão gastar somente 20% do tempo. E isso pode acontecer por vários motivos, mas principalmente pela quantidade de débito técnico deixado no meio do caminho, pela "junioridade" dos recursos, pelo não entendimento de algum requisito e terem construído "como entenderam", etc.. (não culpo o modelo cascata somente).

Tentamos sempre melhorar em cada novo projeto, e uma abordagem interessante foi a criação de iterações com a presença e validação do cliente em cada uma. Algo mais próximo das práticas ágeis. Mas ainda assim havia muito estress nas entregas (devido à bugs), questões que eram postergadas por terem achado problemas próximo da apresentação ao cliente (o tempo é sempre curto), dentre outras questões, mas que, no geral, já era um bom avanço para a equipe.

Entretanto ainda apresentávamos o sistema em nossas máquinas de homologação e, apesar do cliente já conhecer seu produto e aprender com ele nas iterações, ainda tínhamos questões técnicas, de deploy em produção por exemplo, que impediam dizer que estava realmente pronto. E, como não tínhamos, em alguns casos, tempo nem recursos para realizar testes em produção paralelos ao desenvolvimento, sempre encontrávamos surpresas nesta etapa que levava a data efetiva de conclusão para mais longe. E quando todos respiravam aliviados, lembrávamos que os manuais precisavam ser revisados para contemplar as mudanças feitas. : (

É por isso que práticas como as da XP pregam que a medida primária é ter o SOFTWARE FUNCIONANDO NO CLIENTE, EM PRODUÇÃO, DE FORMA INCREMENTAL, pois se antecipa os aprendizados e evita-se procrastinar atividades essenciais à entrega.

Está ou não está pronto?
http://projeto001.blogspot.com/2010/12/esta-pronto-ou-nao-esta-dilema-de.html

Grande abraço,
Buzon

Escopo negociável - Já experimentou?

noreply@blogger.com (Rafael F. Buzon) — Mon, 03 Jan 2011 15:26:00 +0000

"O escopo muda ou não muda?" A resposta é não e sim. Nesta ordem. : )

Alguns conceitos de gestão ágil, principalmente para desenvolvimento de sistemas, pregam a mudança dos contratos tradicionais, onde o escopo, tempo e custo são fixos, para contratos de escopo negociável. Esta talvez seja uma das mudanças mais significativas e uma das mais temidas, tanto pelo cliente quanto pelo fornecedor. Um pouco se deve ao preconceito e à dúvida na efetividade da prática.

Uma breve explicação:

Contratos de escopo fechado: Fixamos o custo, o tempo e o escopo que serão entregues. Os principais riscos ficam com o fornecedor que terá que suportar e absorver itens mal interpretados, subentendidos e não previstos, terá que criar processos de gestão de mudanças formais e, por vezes, demorados, e caso a estimativa tenha sido imprecisa, o que é comum, terá que arcar com tempo/recursos/dinheiro extra para entregar o escopo prometido.

Deste cenário aparecem alguns efeitos colaterais, como a gordura colocada pelo fornecedor para tratar a incerteza do escopo; stress nos métodos de defesa criados pelo fornecedor que introduz processos, formulários e comitês de aprovação de mudanças para gerir o escopo; e uma qualidade variável, condicionada ao tempo que se tem disponível.

Contratos de escopo negociável: Há uma cadência fixa de trabalho com custo e prazos fixos, mas com escopo negociável. Em práticas ágeis, consegue-se entregar qualidade fixa! Isso mesmo, Qualidade Fixa, pois os processos de desenvolvimento apoiam tal feito.

Sabe-se que o escopo não é conhecido em detalhes no início do projeto; que o cliente e as equipes aprendem durante a execução e que a mudança é benéfica ao projeto, posto que corrige a rota objetivando alto valor agregado ao cliente. Logo, porque não realizar uma abordagem diferenciada para o escopo?
Em escopo negociável admiti-se que todos não conhecem o projeto em detalhes em seu início, compartilham-se os riscos e são criados instrumentos de ganha-ganha e de parceria.

- O contrato prevê uma frequencia na qual o fornecedor será avaliado (ex: 2 meses) podendo o cliente romper o contrato sem multas, por motivos de insatisfação. Neste cenário o fornecedor fará de tudo para atender ás expectativas do clientes neste período para viabilizar os próximos 2 meses.

- Escopo fixo por sprint. Quem é desenvolvedor sabe o quanto é ruim estar trabalhando em algo e ser interrompido no meio porque houve "mudanças de planos". Mas a mudança é importante, pois diz muito a respeito do que foi aprendido com o projeto e como ele deve ser daqui em diante. Assim, atende-se aos 2 mundos, pois o escopo pode variar antes do início de cada sprint, porém dentro do sprint o escopo é fechado! Há o comprometimento de todos com aquelas entregas e o cliente é orientado a conduzi-las e viabilizá-las. E é altamente eficiênte, pois como são períodos curtos, não há grandes progressos sem os redirecionamentos necessários.

Caso contrário, não há métrica que funcione e não há progresso efetivo. É um projeto em colapso!

Novamente voltamos à questão do novo modelo de trabalhador, que passa dos paradigmas da especialização do trabalho e foco mais manual para o trabalhador do conhecimento.

Veja um vídeo sobre como se conduz contratos de escopo negociável (de rafaelfragawalter)

Abs,
Buzon

Na prática a teoria é outra

noreply@blogger.com (Rafael F. Buzon) — Wed, 29 Dec 2010 20:59:00 +0000

Vale a pena republicar:

Dicas para a construção de sites e materiais multimídia

View more presentations from Rafael Buzon.

Cachorro com muitos donos: Vive Feliz!

noreply@blogger.com (Rafael F. Buzon) — Tue, 28 Dec 2010 13:22:00 +0000

http://tomodatikilate.blogspot.com/

Se me permitem, gostaria de fazer uma releitura, à luz do trabalho em equipe, daquele conhecido jargão: "Cachorro com muitos donos: Morre de fome!". Apesar de haver muita verdade nesta frase, para se ter equipes de alta performance e qualidade incomparável com o trabalhador do conhecimento, é necessário que todos abracem a responsabilidade e não haja "corpo mole".

É sabido das boas práticas em gestão termos uma pessoa, e somente uma, associada à uma atividade, pendência, issue e risco, além de uma data bem definida para o deadline de sua resolução. Criei muitas atas e documentos de riscos nos quais para cada item havia 1 pessoa associada e um deadline (ou de entrega ou de controle, para acompanhamento da questão). E realmente eu concordo que é uma forma muito objetiva e clara de se realizar o monitoramento.

Isso acontece porque o ser humano tem a tendência de não se comprometer ou não dar a devida atenção quando fica "nebuloso" de quem é a responsabilidade primária daquele assunto. Definindo 2 pessoas como responsáveis por uma ação, por exemplo, é possível que uma delas acredite que a outra irá resolver ou entender que somente iria acompanhar a questão, porque, de fato, a responsabilidade não era dela. Ou ainda, por não ter o seu nome diretamente exposto como o real responsável, não cria comprometimento e acaba não sendo priorizado em suas atividades cotidianas.

Ou seja, o cachorro morre de forme!!

Já viram aquela parábola da Responsabilidade compartilhada?
http://www.jrsantiago.com.br/parab_95.html

Temos, portanto, exemplos de responsabilidade atribuída de forma explícita e direta e outra atribuída de forma implícita ou indireta. E nas 2 há problemas para trabalhos que envolvem mais conhecimento ou atividades intelectuais. E vou explicar por que penso assim:

- Quando associamos uma questão ou atividade de forma explícita, ganhamos em comunicação e clareza, mas perdemos em colaboração. A atividade é DAQUELA pessoa e eu não "meto a colher". Isso diminui a qualidade de certa forma ou a transfere para outro momento, tornando o processo ineficiente.

- Ao passo que quando a atividade é associada de forma indireta, a duas ou mais pessoas, podemos cair no exemplo onde a responsabilidade não é assumida e o comprometimento não é criado. Ou ainda caímos no mesmo exemplo da atribuição direta, quando a responsabilidade é DAQUELE grupo de pessoas e eu não "meto a colher".

O motivador deste post foi conhecer aquela prática XP, para desenvolvimento de software, que prega a propriedade coletiva do código. Nela, a responsabilidade do trabalho é coletiva, todos são habilitados e recomendados a melhorar um código no qual esteja trabalhando, mesmo que não seja dele. Todos se envolvem com o código de todos, com o trabalho de todos, e todos ganham com isso. A qualidade é potencializada e o acabamento mais preciso e menos suscetível a falhas. É importante, sempre, conhecer a natureza daquilo que você se propõe a gerir e usar novos conceitos e paradigmas.

Nesta filosofia não são criados meios e práticas para se ganhar o comprometimento, mas é incentivado o engajamento das pessoas na construção de algo comum, juntas! É mudança de cultura!

Assim, cachorro com muitos donos: Vive Feliz!

Referências:
http://www.slideshare.net/akitaonrails/encontro-locaweb-1287367
http://www.dtsato.com/blog/2007/05/10/propriedade-coletiva-do-conhecimento/
http://www.martinfowler.com/bliki/CodeOwnership.html

Abraços,
Buzon

Está pronto ou não está? - Dilema de projetos de software

noreply@blogger.com (Rafael F. Buzon) — Thu, 23 Dec 2010 18:22:00 +0000

Quando você pede um lanche no McDonald's e a atendente diz pra você: "Está pronto", você simplesmente pega sua bandeija e vai para sua mesa comer seu lanche. Certo? Neste exemplo a palavra "pronto" induz que está adequado para consumo imediato.

Isso não acontece em outros lugares, como em projetos de software, por exemplo. Por que será?

Indo direto ao ponto, isso não acontece em software porque as métricas de acompanhamento e controle, geralmente adotadas, são erradas ou altamente quebradiças e possibilitam má interpretação em toda cadeia e para todos os interessados.

Há o pronto para a equipe de desenvolvimento, que não enxerga o período de refinamento de testes e ajustes (por trabalharem em cascata e não em iterações, não há um "pronto" da equipe, mas "prontos" de vários grupos de trabalho); Há o pronto dos testes, que não leva em consideração o tempo para transferir o sistema de homologação para produção; Há o pronto de produção, que não leva em conta os documentos e manuais necessários que o cliente vive falando que são importantes.... E nesta inconsistência toda existe o gerente de projetos que, sem experiência e sob pressão, tem espaço e apoio para dizer que hora está pronto e hora não está, dependendo da conveniência.

Apesar de estarmos comparando coisas bem distintas (uma linha de produção de hamburguer, com um trabalho intelectual) é possível ter um entendimento comum do que é estar pronto! Que sempre previsa ser visto através da perspectiva do cliente, que é quem realmente consome o produto.

A medida primária de medida de progresso, em desenvolvimento de sistemas, é software funcionando em produção de forma iterativa, incremental e sendo utilizado pelo clienete. Nada além disso é medida confiável de progresso. Por isso as práticas ágeis investem tanto em trazer todo o ciclo de vida tradicional de um software para iterações rápidas, com participação e validação de todos, inclusive do cliente real.

Em inglês há um termo mais adequado para representar o pronto para entrega total. Eles usam shippable, ou seja, está pronto a ponto de tirar a mão, pegar o produto, colocar em um navio e enviar?!! Não é necessário fazer mais nada referente à entrega?

Parece uma forma melhor de enxergar as coisas.

Abs,
Buzon

Referências:
http://www.infoq.com/news/2008/02/done-shippable-quality
http://www.scrumalliance.org/articles/107-how-do-we-know-when-we-are-done
http://www.scrumalliance.org/articles/105-what-is-definition-of-done-dod

Conheça a natureza daquilo que você se propõe a gerir

noreply@blogger.com (Rafael F. Buzon) — Wed, 22 Dec 2010 15:36:00 +0000

Desde a revolução industrial, alicerçada pelos conceitos de Taylor e Ford, a produtividade não pára de crescer em todas as indústrias do mercado. Com ela consolida-se o mind set da especialização do trabalho, da linha de produção, das teorias motivacionais, dentre outras teorias eficazes para este, então, revolucionário novo modelo de trabalho. E é justificável este mind set, pois nunca na história da humanidade houve um ganho tão grande em produtividade como na revolução industrial.

Entretanto, caminhamos a passos largos à também revolucionária Era da informação, do trabalhador do conhecimento, da valorização da criatividade, da arte, do out of the box thinking, e ainda utilizamos muito do mesmo mind set nos atuais trabalhos. "Para um martelo, todo problema é um prego!" Os velhos modelos de apresentar a cenoura, comando e controle, benefícios, aumento de salário por si só, recompensas, hierarquia rígida, especialização do trabalho, dentre outras, inibem a criatividade e o desenvolvimento. (em: http://gecorp.blogspot.com/2007/05/o-trabalhador-do-conhecimento.html)

Logo, se vê necessário conhecer a natureza do novo trabalho que advém da era da informação.

Você já se imaginou gerenciando a construção de um livro? Ou a pintura de um quadro?
Há uma discussão no mundo de gestão de projetos, que discute se o gestor precisa ter conhecimento técnico daquilo que se propõe a gerenciar. É possível que alguém com formação em engenharia gerencie um projeto farmacêutico? Ou alguém da área de sistemas gerenciar a construção de uma ponte? ou ainda um gerente de projetos de publicidade, gerenciar um projeto de software?

O Guia PMBoK® diz que sim, ressaltando, entretanto, que quanto mais conhecimento técnico do gestor, melhor! Mas eu vou além, é ESSENCIAL que o gerente de projetos conheça pelo menos a natureza daquilo que se propõe a gerir. Um exemplo clássico e talvez o mais significativo é o modelo para desenvolvimento de software.

A engenharia de software, e boa parte da tradicional literatura desta disciplina, está carregada do mind set da era industrial, onde há determinismo, especialização do trabalho, e fases muito bem definidas. O modelo que representa claramente estes conceitos é o modelo de cascata de desenvolvimento.

Entretanto, a natureza do desenvolvimento de software é extremamente intelectual e bem pouco manual e repetitiva. Já prestou atenção em como você escreve um e-mail ou uma post em um blog? ou mesmo um livro? Que procedimentos você adotaria para escrever um bom texto?

Provavelmente, você começaria explorando o assunto mentamente, tentando encontrar os tópicos a serem tratados, a ordenação e a forma. Em seguida, começaria a escrever as primeiras linhas. Após alguns parágrafos, você provavelmente faria algumas alterações em trechos já escritos, de modo a aprimorá-los. Ao final, você faria uma re-leitura, corrigiria algumas partes, retocaria alguns trechos, até o texto final estivesse adequado. (Extreme Programming, Vinícius Manhães Teles)

Por certo você também não escreveria linearmente módulo por módulo, de acordo com o índice que você definiu. Provalvemente você está mais preparado para escrever o módulo final a um módulo intermediário. Você aprende mais sobre seus próprios objetivos com o livro enquanto o escreve. Ganha insights para abordar... etc... etc... Neste contexto não há o erro em si, mas a possibilidade de entender mais e aprimorar continuamente.

Enfim, quais técnicas você adotaria para gerenciar este tipo de trabalho. Quais métricas? Quais motivadores para este profissional que depende de muita criatividade, inspiração e que precisa se sentir dono de sua obra? Imagine então uma equipe de profissionais que desenvolve alto intelectual em conjunto...

O fato é que você consegue, de uma forma ou de outra, gerenciar qualquer coisa com métodos mais antiquados. Mas para se ter sucesso efetivo, tanto no resultado final quanto na condução eficiênte do projeto (sem ter todos se jogando pela janela) é necessário um novo paradigma de gestão.

Veja o vídeo abaixo de Daniel Pink que defende um novo modo de motivação do trabalhador do conhecimento.

"Só sei que nada sei"

O poder de sentar junto

noreply@blogger.com (Rafael F. Buzon) — Tue, 21 Dec 2010 14:22:00 +0000

É conhecido, do mundo de práticas ágeis, o conceito de "Sentar Junto", que nada mais é que reunir todos os envolvidos do projeto em uma mesma sala (ambiente) para que possam trocar ideias, se beneficiar da comunicação "osmótica", agilizar decisões, etc...

Mas fora os benefícios de comunicação, que são evidentes, há outros ganhos envolvidos e que não são tão claros. São ganhos psicológicos que fazem a equipe realmente se sentir responsável de forma coletiva pelas entregas. Aquela frase de "colocar no rab* do outro" não existe neste ambiente.

Um dos grandes desafios enfrentados por um gerente de projetos na gestão de equipes é a tendência natural que as pessoas têm em não assumir por completo a responsabilidade ou os possíveis problemas advindos dos compromissos. Há um termo americano para isso chamado accountability que prega que um indivíduo deve assumir, sem desculpas, a total responsabilidade por seus compromissos (ou compromissos assumidos em equipe), ponderando os erros e acertos, trazendo ações para melhorar, caso necessário. Mesmo que sua parte seja apenas pontual na equipe, o compromisso é de todos e todos devem sentir isso de alguma forma, buscando auxiliar e influenciar para benefício comum.

Isso é natural do ser humano: nunca procurar encontrar os problemas em si próprio, mas encontrar um bode expiatório para culpar. E este bode expiatório pode ser uma documentação ambigua ou incompleta, na qual um membro se esconde por detrás e a culpa pelos atuais problemas; pode ser uma má interpretação obtida de algum membro, que não soube transmitir corretamente o que queria; pode ser, em se tratando de sistemas, os testes mal elaborados que deixaram passar problemas ao cliente; pode ser a falta de tempo ou não ter encontrado fulano para tirar a dúvida quando foi necessário.... enfim, vários são os bodes para culpar e quem sofre com isso é o projeto como um todo.

O poder de sentar junto faz de um grupo, um time. Traz o real sentido de "estarem todos no mesmo barco". Corrige um defeito humano de procrastinar questões que inevitavelmente irão explodir ao passo que o projeto caminha para seu fim. Colabora para a excelência, posto que há feedback contínuo e imediato de todos.

Os resutados serão bem melhores:

Abraços,
Buzon

Storytelling - Estórias aplicadas no Scrum

noreply@blogger.com (Rafael F. Buzon) — Mon, 20 Dec 2010 12:40:00 +0000

"Era uma vez, um grupo de pessoas que estava indignada em como os projetos de software falhavam. Começaram então a estudar mais sobre a natureza do software e descobriram que desenvolver um software é um trabalho extremamente intelectual e não manual ou repetitivo. Logo, os modelos de Taylor, sobre especialização do trabalho e motivação dos trabalhadores, que foram herdados na gestão de software, não seriam as práticas mais recomendadas. Na verdade, seriam praticamente opostas".

O pequeno parágrafo que criei acima vem ilustrar uma estória que inicia uma conversa sobre as diferenças entre as práticas tradicionais de desenvolvimento de sistemas (cascata, geralmente) e as práticas ágeis. O propósito é discorrer em seguida sobre as peculiaridades entre os dois princípios, entrando em detalhes bem específicos de cada uma delas. Numa storytelling bem feita.

A maioria das práticas ágeis defende a ideia do uso de estórias em contraponto ao requisito. Estórias têm o poder de transferir um conhecimento (se é que conhecimento possa ser transferido) e uma facilidade de consolidar conceitos de forma mais eficaz que apenas dizer exatamente o que se quer. Uma estória ilustra e está carregada de elementos invisíveis que potencializam a comunicação e o entendimento do recepitor. Logo, é uma das melhores abordagens para se conhecer o escopo e as nuances de um projeto de sistemas junto ao seu cliente. Mas para tanto é necessário aplicar a prática da forma correta.

Escrever os requisitos em post-its e chamá-los de estórias é um erro conceitual da prática. Você usa o kanban, que traz inúmeros benefícios de comunicação ao projeto também, mas não agrega nada no conceito das estórias. A estória, em essência, é um convite à conversa pela qual equipe e cliente irão "preencher as lacunas" conceituais a respeito de determinada funcionalidade ou assunto. Eis o poder das storytelling.

Veja um vídeo abaixo, do Beto do Valle, da TerraForum Consultores.
Ele ilustra, no contexto da consultoria, quão mais eficaz são as storytellings.

E isso faz todo o sentido para o mundo ágil, posto que estes pregam o uso potencializado da comunicação entre todos os envolvidos no projeto e que o software somente atinge seus objetivos de negócio crescendo de forma colaborativa com os clientes.

Outras referências:

http://www.greggmorris.com/storytelling-and-software-development

http://www.scrumalliance.org/articles/87-writing-the-product-backlog-just-enough-and-just-in-time

Abraços,

Buzon

Gestão ágil na celebração de casamento - Ata antecipada!

noreply@blogger.com (Rafael F. Buzon) — Mon, 26 Jul 2010 01:32:00 +0000

Descobri uma coisa interessante durante meu casamento. Pode paracer óbvio agora, mas pra mim soou interessante. O padre, antes mesmo da celebração terminar, já estava lendo a ata do casamento contendo todo o acontecido na celebração. Ata lida, todos assinam, fato consumado, 1 hora de celebração! É gestão ágil no ato religioso.

Depois fiquei pensando em como isso fazia sentido. Quando você cria a ata da reunião, antes da reunião, você já realiza o exercício de pensar nos resultados que quer obter e já lhe ganhar drivers para atingir seus objetivos. E cá entre nós, salvo algumas reuniões de brainstorm, nas quais não se sabe o resultado, a maioria das reuniões tem poucas reviravoltas que exijam uma reformulação completa de sua ata.

Fica ai a dica então: Crie sua ata antes da reunião e ajuste os complementos que serão bem poucos ao final. Com certeza os participantes vão ficar bem surpresos com sua eficiência na distribuição das informações logo após a reunião terminar. ; )