http://www.adaptivepath.com/ideas/essays/archives/000925.php
Segunda-feira, 23 de Junho de 2008
Sexta-feira, 20 de Junho de 2008
Vipassana, XP e Mudanças sem Medo

No começo de maio tive o privilégio de mais uma vez participar de um mini-retiro de Vipassana. Um curso inteiro de Vipassana dura 10 dias. Alunos que já fizeram o curso se reunem uma vez por mês para o retiro de um dia. Nesse dia meditam 7 horas e o propósito é reascender a disciplina de praticar a meditação continuamente. No curso de Vipassana aprendemos que a continuidade da prática é o segredo do sucesso (Melhoria Contínua). A prática de Vipassana está fortemente ligada à idéia de mudança. Praticar Vipassana ajuda cada pessoa a entender profundamente como os processos de mudanças acontecem na natureza humana e como lidar de forma objetivo com a mudança.
O título em inglês do livro de Padrões para Introduzir
Novas Idéias é "Fearless Change" (Mudança sem Medo). Toda inovação, toda idéia nova significa uma mudança. Morre o velho, nasce o novo. A inovação é um processo de transformação. Para introduzir uma nova idéia é preciso convencer a grande massa a mudar, a aceitar a morte do que não é mais adequado ao novo tempo. A própria aceitação da nova idéia causa transformação. Essa transformação cria mais mudança e outras novas idéia. Um fluxo contínuo e insessante de mudanças, como a vida. Todos nós estamos imersos nesse fluxo e um dos maiores entraves para a evolução é o medo da morte.
O sub-título do livro do Kent Beck sobre XP: "Embrace Change" (Abrace a Mudança). O quarto preceito do manifesto ágil lembra a importância de adaptar-se a mudanças. Tudo em métodos ágeis remete a mudança. Fica cada vez mais claro que os melhores projetos de software são aqueles que conseguem implantar melhoria contínua no seu processo de desenvolvimento. Melhoria contínua só é possível quando se tem baixo custo de mudança. Uma das forças que aumenta o custo de mudança é a força de resistência, o medo.Como se pode ver, não é por acaso que cito freqüentemente essas fontes (Vipassana, Padrões, XP). Todas elas estão fortemente ligadas. São pontos de vistas diversos sobre um mesmo assunto: mudança. Um outro ponto em comum é que todas falam de práticas. Não se aprende Vipassana falando sobre ela. É preciso praticar. São se aprende XP discutindo e racionalizando seus conceitos. XP é trabalho, é dia-a-dia, é melhoria contínua. Uma idéia inovadora não é nada se só existe na cabeça de seu criador. É preciso prática! Padrões são práticas. É preciso viver a experiência para aprender a lidar com as situações inusitadas e "criar" novos padrões (padrões na verdade não são criados, eles já existem, porém precisam ser identificados e nomeados).
A Vipassana trabalha a nossa relação com mudanças numa esfera mais profunda e subjetiva. Promove sabedoria de dentro para fora. XP e Padrões para Introduzir Novas Idéias lidam com questões mais superficiais e promovem sabedoria de fora para dentro. E sabedoria é entender como ocorrem as mudanças, por que elas ocorrem e principalmente, como lidar com elas.
Terça-feira, 17 de Junho de 2008
Aprender a escrever escrevendo
Há algum tempo falei sobre a relação entre poesia e programação. Desde esse post venho praticando minha escrita de poesias. Com isso viso melhorar:
- Minha habilidade de escrever
- Meus conhecimentos da língua portuguesa
- Minha habilidade de me expressar em uma língua
- Minha habilidade de programar, já que programar não deixa de ser uma maneira de expressar idéias usando uma linguagem definida
Do que é que se trata
Só trabalho de trabalho
Que trabalho me esbugalho
Quebro o galho me atrapalho
Mas não falho nem me canso
Tem reunião de reunião
Que reunião não abro mão
De discussão aprovação
E solução não tem descanso
Não sei dormir só produzir
Mais investir me instruir
E progredir pra onde ir
Não vou medir nenhum esforço
Para parar paralizar
De trabalhar vou disparar
Do chão pro ar me preparar
Pra programar roendo o osso
Sou animal que toca o pau
E não faz mal não ter sinal
No meu ramal de alguém normal
Isso é legal e não é pouco
Trabalho assim não é pra mim
É que compus sombra sem luz
Você já viu é como um rio
Um não sem til correndo louco
(São Paulo - 10/03/2008)
Sexta-feira, 13 de Junho de 2008
Blog Sarau
Criei um blog.sarau.art.br que servirá de espaço para organizar eventos artísticos.Quem quiser participar é só postar lá!
Quinta-feira, 5 de Junho de 2008
Já pensou em arte hoje?
Certo sábado escrevi no quadro branco da equipe os seguintes dizeres:JÁ PENSOU EM ARTE HOJE?
- música
- dança
- pintura
- escultura
- poesia
- teatro
- cinema
Usei o padrão "No Seu Espaço" do livro Padrões para Introduzir Novas Idéias. Queria deixar visível uma idéia. A idéia de usar arte dentro do ambiente de desenvolvimento de software. O curioso é que na segunda-feira, os dizeres não estavam mais no quadro. Alguém tinha apagado. Por já conhecer os padrões "A Última Maioria" (último grupo de pessoas a aceitar uma idéia nova) e "Retardatários" (grupo que nunca aceita, ou que aceita forçadamente), não me incomodei em ser impedido de expressar o que queria. Afinal, o padrão "O Suficiente" diz para respeitar o tempo de aceitação das pessoas. Uma informação de cada vez. Quem viu a mensagem viu. Quem não viu, verá numa próxima oportunidade.
Eu continuo convicto, afinal, sou um "Defensor Dedicado" e me apóio em idéias de "Grandes Personalidades": Richard Gabriel, Paul Graham, Kent Beck, Valdemar Setzer. Tenho o aval do meu orientador Prof. Dr. Fábio Kon.
A questão que fica em aberto é: como ter arte no dia-a-dia de uma empresa de tecnologia? O que eu não estou enxergando?
Segunda-feira, 2 de Junho de 2008
Rede Neural de XP
A Mariana Vivian Bravo da Agilcoop criou uma linda imagem, relacionando os valores, os princípios e as práticas de XP. Parabéns, Mari, pelo trabalho
Sábado, 10 de Maio de 2008
Vamos nos divertir e integrar
Semana passada ministrei um curso prático de XP pela AgilCoop. O formato do curso é bem interessante e ideal para pessoas nunca tiveram contato com a metodologia OU conhecem a teoria mas nunca usaram as práticas.
O curso tem 20 horas de duração. O objetivo é usar a metodologia para desenvolver em 4 ciclos de 4 horas uma Pizzaria Online - a AgilPizza. As outras 4 horas são destinadas a explicações básicas e encerramento do curso.
Cada ciclo de 4 horas está dividido em 30min de planejamento, 3.5h de desenvolvimento e 15 minutos de retrospectivas.
O curso é uma versão no meio do caminho entre o Jogo de XP (onde cada iteração dura 1 minuto) e o ambiente de desenvolvimento real (onde cada iteração tem em média de 5 a 20 dias de duração).
A atmosfera de brincadeira e diversão criada em torno desse projeto de pizzaria é um dos atributos chave para o aprendizado da metodologia. Esse ambiente descontraído deveria ser levado mais a sério nas áreas de desenvolvimento das empresas. Se nós conseguimos criar um software de qualidade, com funcionalidades úteis para o cliente numa brincadeira, por que não podemos fazer essa brincadeira todos os dias em nossos escritórios?
Uma pessoa mais desavisada que assiste ao vídeo do jogo do planejamento (nesse curso usamos Planning Poker) não consegue saber se as pessoas estão jogando ou trabalhando.
John Maddog lembrou isso em sua palestra no FISL 9.0. O título da palestra era "Fun and Software Livre! Return of the Jedi!". Ele contou a história dos grandes projetos de Softwares Livre. A maioria deles surgiu como uma brincadeira, feitos por divertimento pelos criadores (Linus Torvalds no caso do Linux, Mark Spencer no caso do Asterisk).
No modelo do ócio criativo de Domenico Di Masi vemos uma perfeita sincronia entre trabalhar, estudar e o brincar. Os métodos ágeis tem tudo a ver com esse modelo. Quem é ágil brinca, estuda e trabalha! Tudo Junto!
A arte inspira o que é fora da regra, o que é humano, o que é criação. A arte pode ajudar a trazer ludicismo para o trabalho. O estudo ajuda a aperfeiçoar as técnicas de arte e as práticas no ambiente de trabalho. Como vemos, todas essas coisas, trabalho, jogos, estudos e arte estão integradas, interligadas.
O curso tem 20 horas de duração. O objetivo é usar a metodologia para desenvolver em 4 ciclos de 4 horas uma Pizzaria Online - a AgilPizza. As outras 4 horas são destinadas a explicações básicas e encerramento do curso.
Cada ciclo de 4 horas está dividido em 30min de planejamento, 3.5h de desenvolvimento e 15 minutos de retrospectivas.
O curso é uma versão no meio do caminho entre o Jogo de XP (onde cada iteração dura 1 minuto) e o ambiente de desenvolvimento real (onde cada iteração tem em média de 5 a 20 dias de duração).
A atmosfera de brincadeira e diversão criada em torno desse projeto de pizzaria é um dos atributos chave para o aprendizado da metodologia. Esse ambiente descontraído deveria ser levado mais a sério nas áreas de desenvolvimento das empresas. Se nós conseguimos criar um software de qualidade, com funcionalidades úteis para o cliente numa brincadeira, por que não podemos fazer essa brincadeira todos os dias em nossos escritórios?
Uma pessoa mais desavisada que assiste ao vídeo do jogo do planejamento (nesse curso usamos Planning Poker) não consegue saber se as pessoas estão jogando ou trabalhando.
John Maddog lembrou isso em sua palestra no FISL 9.0. O título da palestra era "Fun and Software Livre! Return of the Jedi!". Ele contou a história dos grandes projetos de Softwares Livre. A maioria deles surgiu como uma brincadeira, feitos por divertimento pelos criadores (Linus Torvalds no caso do Linux, Mark Spencer no caso do Asterisk).
No modelo do ócio criativo de Domenico Di Masi vemos uma perfeita sincronia entre trabalhar, estudar e o brincar. Os métodos ágeis tem tudo a ver com esse modelo. Quem é ágil brinca, estuda e trabalha! Tudo Junto!A arte inspira o que é fora da regra, o que é humano, o que é criação. A arte pode ajudar a trazer ludicismo para o trabalho. O estudo ajuda a aperfeiçoar as técnicas de arte e as práticas no ambiente de trabalho. Como vemos, todas essas coisas, trabalho, jogos, estudos e arte estão integradas, interligadas.
Sábado, 3 de Maio de 2008
Ser humano acima de tudo

Esse é um trecho que escrevi em abril de 2003, refletindo sobre o absurdo de se comparar o ser humano com o computador
Opiniões de muitos cientistas renomados por todo o mundo ajudam a confirmar a idéia de que a ciência é muitas vezes, arrogante ao colocar com veemência certas afirmações que estão bem longe de serem verdade. A postura científica é a de basear-se na idéia de que tudo pode ser explicado matematicamente ou fisicamente. A questão é: a ciência tem um conhecimento limitado da ”verdade” e isso induziu ao longo da história (e ainda induz) a erros grotescos.
Cientistas de Inteligência Artificial afirmam absurdos, baseados apenas em elocubrações mentais. Eles muitas vezes ignoram a grandeza da mente humana ao supor que um computador pode pensar como o homem. Ignoram os sentimentos, a criatividade, a capacidade de improvisação, enfim, tudo que eles mesmos possuem e que em sã consciência sabem que um computador jamais terá.
Várias verdades incontestáveis podem ser colocadas contra as incoerências desses cientistas radicais: um computador não tem vontade própria: ele não tem fome. Talvez eles digam: "um computador pode ter sensores para detectar que sua bateria está acabando e então sentir 'fome de carga'". Mas isso não é fome. A fome está além disso! Nós, seres humanos, pensamos: "hoje estou com uma vontade de comer aquela pizza de queijo brie com damascos..."

O computador não possuí instintos. Ele não tem o desejo de se reproduzir, nem mesmo de fazer sexo. O computador não chora quando o seu HD queima, nem quando o seu vizinho de mesa morre. O computador não está atrás de uma companheira "computadora" para se relacionar, para beijar. Ele não se sente sozinho, não se sente acompanhado, não precisa de carinho. A máquina não se ofende quando o usuário xinga a "mãe" dela por não funcionar como o esperado.
A máquina não espera receber elogios por executar um cálculo difícil. Ela não se olha no espelho e pensa: "hoje estou horrível", nem vai na academia fazer ginástica para simplesmente se sentir bem, ou para ficar mais fortinha, ou para impressionar as outras máquinas. A máquina não ri quando você conta uma piada para ela: ela não sabe quando a piada é engraçada ou não!
Sexta-feira, 18 de Abril de 2008
Forum Internacional do Software Livre - FISL 9.0 - vídeo
Estou no maior evento de software livre da América do Sul. Em breve farei um post com os melhores momentos do FISL 9.0. Por hora, fiquem com um vídeo que eu fiz passeando pelo evento.
Terça-feira, 1 de Abril de 2008
Criação, Padrões e Arte
Uma ótima maneira de aprender a fazer alguma coisa e fazendo. Os livros de português e gramática estão aí e ajudam muito no ensino da escrita, mas para aprender a escrever é preciso escrever. Assim como para aprender a fazer software é preciso programar. Só se aprende a meditar meditando. São atividades cujo aprendizado vem da prática, não da teoria.
Estou relizando um trabalho que aborda prática, não as teorias. Recomendo a ação e a arte. Arte é ação, é criação. Do dicionário:
cri.a.ção sf (lat creatione)

Alguns significados da palavra criação são óbvios (1,4,5). Observemos o significado 6: criar é como amamentar uma criança, dar alimento a algo que hoje é pequeno, sem forma, mas que um dia poderá se tornar grandioso. Na denição 8 temos que a criação é um animal alimentado pelo homem. É o homem quem cria, quem alimenta a criação.
A denição 10 é uma das mais surpreendentes. É uma definição puramente material. De todas as definições, é a que melhor pode ser imaginada. Quem não consegue imaginar facilmente um pedreiro preenchendo buracos da parede com argamassa? Essa parece uma imagem interessante: a criação não é o muro todo, mas pequenas partes que preenchem o todo, que completam as lacunas.
O meu trabalho sobre Padrões para Introduzir Novas Idéias não ensina a construir muros (idéias), mas como tornar mais sólidos e concretos os muros (as idéias) que já existem. Todos nós temos grandes idéias, algumas delas maravilhosas e inovadoras. Mas poucos de nós conseguimos realizar, materializar essas idéias. As lições do texto podem ajudar.
Nesse semestre estou trabalhando para escrever a parte 2 deste texto. A parte 1 que já existe fala dos Padrões para Introduzir Novas Idéias. A parte 2 falará sobre como Arte e Padrões para Introduzir Novas Idéias se relacionam: a Arte é uma forma eficaz de introduzir uma idéia; ao mesmo tempo, a indústria não associa Arte com trabalho. Não investe em atividades artísticas para seus colaboradores. Para convencer as empresas da idéia de que usar arte melhora o trabalho e as áreas de criação, usarei Padrões para Introduzir Novas Idéias.
Estou relizando um trabalho que aborda prática, não as teorias. Recomendo a ação e a arte. Arte é ação, é criação. Do dicionário:
cri.a.ção sf (lat creatione)
- Ação ou efeito de criar, de tirar do nada.
- Totalidade dos seres criados.
- O universo visível.
- Produção, obra, invento.
- Estabelecimento, formação, fundação, instituição.
- Amamentação de uma criança.
- Educação.
- Animais domésticos que se criam para alimento do homem.
- Propagação da espécie.
- Alvenaria de pedras miudas e argamassa que serve de enchimento aos vãos deixados pelas pedras mais volumosas.
- Nas agências de publicidade, o conjunto formado pelos departamentos de redação e de arte.

Alguns significados da palavra criação são óbvios (1,4,5). Observemos o significado 6: criar é como amamentar uma criança, dar alimento a algo que hoje é pequeno, sem forma, mas que um dia poderá se tornar grandioso. Na denição 8 temos que a criação é um animal alimentado pelo homem. É o homem quem cria, quem alimenta a criação.
A denição 10 é uma das mais surpreendentes. É uma definição puramente material. De todas as definições, é a que melhor pode ser imaginada. Quem não consegue imaginar facilmente um pedreiro preenchendo buracos da parede com argamassa? Essa parece uma imagem interessante: a criação não é o muro todo, mas pequenas partes que preenchem o todo, que completam as lacunas.
O meu trabalho sobre Padrões para Introduzir Novas Idéias não ensina a construir muros (idéias), mas como tornar mais sólidos e concretos os muros (as idéias) que já existem. Todos nós temos grandes idéias, algumas delas maravilhosas e inovadoras. Mas poucos de nós conseguimos realizar, materializar essas idéias. As lições do texto podem ajudar.
Nesse semestre estou trabalhando para escrever a parte 2 deste texto. A parte 1 que já existe fala dos Padrões para Introduzir Novas Idéias. A parte 2 falará sobre como Arte e Padrões para Introduzir Novas Idéias se relacionam: a Arte é uma forma eficaz de introduzir uma idéia; ao mesmo tempo, a indústria não associa Arte com trabalho. Não investe em atividades artísticas para seus colaboradores. Para convencer as empresas da idéia de que usar arte melhora o trabalho e as áreas de criação, usarei Padrões para Introduzir Novas Idéias.
Sábado, 8 de Março de 2008
A Arte como ferramenta para inovação
Hoje sabe-se muito bem que um programador não produzirá 25% a mais se trabalhar 10 ao invés de 8 horas diárias. A vinda de métodos ágeis trouxe muitas mudanças e quebra de preconceitos trazidos da revolução industrial. Ainda assim, existem muitos paradigmas a serem quebrado. Na era industrial, a fórmula de um produto era guardada a sete chaves. Essa fórmula secreta garantia que o produto não seria copiado. Naquela época, a exclusividade na comercialização de produtos foi muito lucrativa para as indústrias.
A partir do surgimento da Internet, a informação tornou-se muito acessível a todos. As fórmulas secretas deixaram de ser secretas. Com uma simples busca no Google é possível encontrar desde, por exemplo, maneiras de construir uma bomba caseira até técnicas de alta costura ou como fazer chocolates trufados. Nos início dos anos 90, tínhamos um colega de colégio que vendia trufas deliciosas nos intervalos das aulas. Naquela época, ninguém da escola podia imaginar como eram feitas aquelas trufas maravilhosas. Todos compravam, mesmo a um preço muito acima do preço de um doce comum.
Para sobreviver num ambiente globalizado como o do mundo atual, onde produtos podem ser copiados facilmente, as empresas precisam diferenciar-se. Hoje, a diferenciação pode ser encontrada em dois quesitos: qualidade e inovação. Na área de software, os métodos ágeis contribuíram fortemente para criar diferenciação no quesito qualidade. Qual seria a ferramenta que a indústria de software necessita para desenvolver inovação? Essa ferramenta se chama Arte.
Para inovar é preciso criatividade. Todo ser humano possui um lado criativo. E o potencial criativo do homem pode ser explorado, desenvolvido, melhorado. Para desenvolver criatividade dentro das empresas, é preciso que existam atividades artísticas no dia-a-dia dos funcionários, os ``criadores''. Usaremos Padrões para Introduir Novas Idéias para desenvolver um ambiente artístico na área de tecnologia de uma empresa de software.
Uma outra abordagem é a de que podemos usar a arte para introduzir uma nova idéia. Usar a arte para introduzir uma idéia pode ser considerado um padrão! Quando as pessoas assistem uma peça de teatro, um filme, ou observam uma pintura, elas estão naturalmente num estado de abertura emocional. As pessoas ficam receptivas quando se deparam com arte. A arte age como um motor de mudança, e mudança induz a inovação.
Uma área de tecnologia puramente baseada em computadores não é capaz de criar. O computador não cria! Quem cria é o ser humano. Algumas dicas de como substituir o pensamento computacional pelo artístcos pode ser encontrados neste artigo do Prof. Valdemar Setzer
A partir do surgimento da Internet, a informação tornou-se muito acessível a todos. As fórmulas secretas deixaram de ser secretas. Com uma simples busca no Google é possível encontrar desde, por exemplo, maneiras de construir uma bomba caseira até técnicas de alta costura ou como fazer chocolates trufados. Nos início dos anos 90, tínhamos um colega de colégio que vendia trufas deliciosas nos intervalos das aulas. Naquela época, ninguém da escola podia imaginar como eram feitas aquelas trufas maravilhosas. Todos compravam, mesmo a um preço muito acima do preço de um doce comum.Para sobreviver num ambiente globalizado como o do mundo atual, onde produtos podem ser copiados facilmente, as empresas precisam diferenciar-se. Hoje, a diferenciação pode ser encontrada em dois quesitos: qualidade e inovação. Na área de software, os métodos ágeis contribuíram fortemente para criar diferenciação no quesito qualidade. Qual seria a ferramenta que a indústria de software necessita para desenvolver inovação? Essa ferramenta se chama Arte.
Para inovar é preciso criatividade. Todo ser humano possui um lado criativo. E o potencial criativo do homem pode ser explorado, desenvolvido, melhorado. Para desenvolver criatividade dentro das empresas, é preciso que existam atividades artísticas no dia-a-dia dos funcionários, os ``criadores''. Usaremos Padrões para Introduir Novas Idéias para desenvolver um ambiente artístico na área de tecnologia de uma empresa de software.
Uma outra abordagem é a de que podemos usar a arte para introduzir uma nova idéia. Usar a arte para introduzir uma idéia pode ser considerado um padrão! Quando as pessoas assistem uma peça de teatro, um filme, ou observam uma pintura, elas estão naturalmente num estado de abertura emocional. As pessoas ficam receptivas quando se deparam com arte. A arte age como um motor de mudança, e mudança induz a inovação.
Uma área de tecnologia puramente baseada em computadores não é capaz de criar. O computador não cria! Quem cria é o ser humano. Algumas dicas de como substituir o pensamento computacional pelo artístcos pode ser encontrados neste artigo do Prof. Valdemar Setzer
Segunda-feira, 3 de Março de 2008
Práticas que vão bem com o plano de iterações
Joca Torres defendeu nesse post algumas vantagens de usar métodos ágeis, do ponto de vista do gerente de produtos. O design incremental e o uso de iterações permite que o cliente veja mais rapidamente aquilo que já está pronto. A partir do momento que o cliente está usando nosso software, ele começa a PAGAR e a ter benefícios (e nós também!).
Porém, do ponto de vista do time de desenvolvimento, existem alguns cuidados que precisam ser tomados para que o software se torne "modificável" para atender as necessidades do cliente. Para entregar funcionalidade de forma incremental, você precisa ter um ambiente de desenvolvimento e uma base de código que facilite e permita essas entregas iterativas.
As práticas de XP são um guia para isso. O gerente de produtos tem muito contato com as práticas de planejamento (histórias, iterações, velocidade etc) mas em software não basta planejar. O código tem que ter alta qualidade e testes (de preferência automatizados). Para se testar, é necessário programar orientado a testes, ou seja, se você começou a fazer um software numa linguagem ou num ambiente que não facilite a criação e manutenção de testes, você está indo no caminho contrário da qualidade e da agilidade. Se você quer acompanhar as mudanças da tecnologia, da vontade do seu cliente e do dia-a-dia dos membros de sua equipe, tenha uma boa base de testes para seu software.
Para escrever bons testes, você precisa ter um design bom e simples. Para transformar seu código legado, obsoleto, em algo testável, você precisa ter bons conhecimentos em Programação Orientada a Objetos e Refatorações.
Quando o time de desenvolvimento é maior do que um time de uma única pessoa, o código será compartilhado. Para diminuir a entropia da comunicação entre pessoas que modificam o mesmo código, você utiliza programação pareada, padronização de código e integração contínua. Além disso, times ágeis não podem ter muito mais do que oito ou dez pessoas.
Resumindo, plano de iterações é parte essencial da agilidade, mas ela só é possível com práticas sustentáveis como testes automatizados, refatorações, integração contínua, propriedade coletiva de código, programação pareada etc.
Porém, do ponto de vista do time de desenvolvimento, existem alguns cuidados que precisam ser tomados para que o software se torne "modificável" para atender as necessidades do cliente. Para entregar funcionalidade de forma incremental, você precisa ter um ambiente de desenvolvimento e uma base de código que facilite e permita essas entregas iterativas.
As práticas de XP são um guia para isso. O gerente de produtos tem muito contato com as práticas de planejamento (histórias, iterações, velocidade etc) mas em software não basta planejar. O código tem que ter alta qualidade e testes (de preferência automatizados). Para se testar, é necessário programar orientado a testes, ou seja, se você começou a fazer um software numa linguagem ou num ambiente que não facilite a criação e manutenção de testes, você está indo no caminho contrário da qualidade e da agilidade. Se você quer acompanhar as mudanças da tecnologia, da vontade do seu cliente e do dia-a-dia dos membros de sua equipe, tenha uma boa base de testes para seu software.
Para escrever bons testes, você precisa ter um design bom e simples. Para transformar seu código legado, obsoleto, em algo testável, você precisa ter bons conhecimentos em Programação Orientada a Objetos e Refatorações.
Quando o time de desenvolvimento é maior do que um time de uma única pessoa, o código será compartilhado. Para diminuir a entropia da comunicação entre pessoas que modificam o mesmo código, você utiliza programação pareada, padronização de código e integração contínua. Além disso, times ágeis não podem ter muito mais do que oito ou dez pessoas.
Resumindo, plano de iterações é parte essencial da agilidade, mas ela só é possível com práticas sustentáveis como testes automatizados, refatorações, integração contínua, propriedade coletiva de código, programação pareada etc.
Terça-feira, 26 de Fevereiro de 2008
Ambiente de Desenvolvimento LocaWeb Telecom
Fiz um resumo do ambiente de desenvolvimento da LocaWeb Telecom e o produto PABX Virtual, contando algumas soluções e técnicas que usamos em nossos testes de aceitação.
Sábado, 15 de Dezembro de 2007
Quarta-feira, 12 de Dezembro de 2007
Meditação Vipassana
Vipassana significa ver as coisas como elas realmente são. Hoje farei uma palestra no Magma para explicar os conceitos básicos dessa técnica de meditação maravilhosa.
Para mais informações sobre cursos de Vipassana no Brasil e no mundo, entre no Site da instituição.
Para mais informações sobre cursos de Vipassana no Brasil e no mundo, entre no Site da instituição.
Quarta-feira, 28 de Novembro de 2007
Injeção de Dependências e Spring
Essa semana fiz um seminário no IME-USP sobre Spring e Injeção de Dependências, um tópico que vem se tornando cada vez mais presente no dia-a-dia do trabalho. Pretendemos começar a colocar em prática essa tecnologia nos próximos meses. A apresentação pode ser baixada em http://gsd.ime.usp.br/seminars/2007/spring.pdf
Estou a disposição para dúvidas
Estou a disposição para dúvidas
Segunda-feira, 20 de Agosto de 2007
Enquete Arte / Computação

Para minha pesquisa de mestrado, gostaria de saber mais a opinião das pessoas sobre a relação entre Arte e desenvolvimento de software. No que você acha os itens abaixo se relacionam com computação?
- Teatro
- Música
- Literatura
- Dança
- Cinema
- Pintura
- Outras formas de expressão artística
Terça-feira, 10 de Julho de 2007
Tracking Subjetivo
O tracker é conhecido como a consciência do time. É ele quem mostra números, gráficos, tabelas. Os dados que o tracker coleta podem ser objetivos (ex: número total de testes, total de horas estimadas por release, estimativas versus realizações) ou subjetivos (ex: nível de satisfação da equipe, qualidade do código. Coloco aqui algumas fotos de tracking subjetivo, tiradas de cartazes feitos durante o segundo semestre de 2007 no Projeto Borboleta
A primeira delas (clique na imagem para vê-la em tamanho grande) é do "humorômetro" da equipe. Durante o semestre, em todos os dias de trabalho, cada membro da equipe era responsável por desenhar a sua "carinha", representando seu estado de espírito: triste, feliz, irritado, etc. Ao longo das primeiras semanas a equipe exagerou no humor. O excesso de humor prejudicou o caráter informativo que o cartaz deveria ter. No cartaz à direita da foto, a equipe tentou melhorar o nível de informação, criando um código de cores para cada estado de humor. As faltas eram marcadas com fantasmas (no cartaz da esquerda) ou hachuras (à direita).
A segunda foto possui um gráfico que mostra a análise da equipe em relação a qualidade do código. No eixo X está o andamento de cada release. No eixo Y uma nota de 0%(ruim) a 100% (ótimo) do que a equipe acredita ser o quesito qualidade. Cada ponto no gráfico corresponde a um dia em que a equipe trabalhou e "votou" na qualidade do código. Observe no release 1.2 a colata de dados começou quando a release já estava 80% completa. Já na release 1.3 houve uma displicência por parte do tracker em coletar os dados. Foram plotados somente os pontos no começo e no fim da iteração, gerando uma linha reta no gráfico, que o coach (eu no caso :-) comentou como "lamentável"
Coletar dados subjetivos sobre a equipe é tão (ou até mais) importante quanto analisar dados objetivos sobre o código. Toda equipe de desenvolvimento de software é composta de seres humanos. Seres humanos são imprevisíveis. Grande parte das informações que se pode obter sobre essa equipe é analógica, subjetiva. Observar com atenção essas informações e torná-las visíveis para a equipe certamente tornará o ambiente agradável, divertido e produtivo.
A primeira delas (clique na imagem para vê-la em tamanho grande) é do "humorômetro" da equipe. Durante o semestre, em todos os dias de trabalho, cada membro da equipe era responsável por desenhar a sua "carinha", representando seu estado de espírito: triste, feliz, irritado, etc. Ao longo das primeiras semanas a equipe exagerou no humor. O excesso de humor prejudicou o caráter informativo que o cartaz deveria ter. No cartaz à direita da foto, a equipe tentou melhorar o nível de informação, criando um código de cores para cada estado de humor. As faltas eram marcadas com fantasmas (no cartaz da esquerda) ou hachuras (à direita).

A segunda foto possui um gráfico que mostra a análise da equipe em relação a qualidade do código. No eixo X está o andamento de cada release. No eixo Y uma nota de 0%(ruim) a 100% (ótimo) do que a equipe acredita ser o quesito qualidade. Cada ponto no gráfico corresponde a um dia em que a equipe trabalhou e "votou" na qualidade do código. Observe no release 1.2 a colata de dados começou quando a release já estava 80% completa. Já na release 1.3 houve uma displicência por parte do tracker em coletar os dados. Foram plotados somente os pontos no começo e no fim da iteração, gerando uma linha reta no gráfico, que o coach (eu no caso :-) comentou como "lamentável"
Coletar dados subjetivos sobre a equipe é tão (ou até mais) importante quanto analisar dados objetivos sobre o código. Toda equipe de desenvolvimento de software é composta de seres humanos. Seres humanos são imprevisíveis. Grande parte das informações que se pode obter sobre essa equipe é analógica, subjetiva. Observar com atenção essas informações e torná-las visíveis para a equipe certamente tornará o ambiente agradável, divertido e produtivo.Segunda-feira, 2 de Julho de 2007
A poesia de programar

O atividade de escrever software deve ser vista como uma atividade criativa. Afinal, software interessante de se fazer é software que nunca foi feito. Essa atividade não pode ser comparada à de criar pontes, por exemplo. Nós construímos pontes há mais de 2000 anos. O software mais antigo não deve ter mais de 50 anos! Mesmo utilizando boas ferramentas, um programador está quase sempre criando uma coisa nova. Se olharmos para o código de vários programadores, veremos o mesmo problema resolvido de várias maneiras diferentes. Existem programas bem e mal escritos. Por ser uma atividade totalmente criativa, programadores deveriam ser treinados como pessoas criativas, artistas e poetas.
E como os poetas são treinados? Eles estudam grandes obras e a vida de grandes poetas! Isso é feito com software? Olhamos para grandes pedaços de código? De maneira geral, a grande literatura de software não é consultada pelos engenheiros.
Para que um poema fique realmente bom, ele normalmente passa pela revisão de várias pessoas. Depois de escrito, normalmente alguém o revisa. O poeta faz então algumas alterações. Uma outra pessoa revisa. Depois vai para a editora. Nova revisão. Nós fazemos isso com software? Nas metodologias ágeis, o processo de criação de software se tornou muito mais interativo: cria-se uma parte do software; o cliente revisa; o software é melhorado; o cliente revisa novamente. É obvio que não podemos planejar todo o software antecipadamente. Se pudéssemos, não haveria a necessidade de lançarmos várias versões!
Dizem que você sabe reconhecer um grande poeta pelo tamanho de sua obra. Isso significa que quanto mais se escreve, mais experiência se obtém e melhores vão ficando os escritos. Quantos poemas possui um grande poeta? 1000? 2000? Quantos softwares você escreveu? 50? 100?
A idéia principal é que para escrever bom software precisamos:
- Consultar uma boa literatura
- Praticar muito
- Ter pessoas criticando o que escrevemos
Quinta-feira, 28 de Junho de 2007
Tracker no Pabx Virtual

Durante 9 meses de trabalho no projeto do Pabx Virtual da LocaWeb, coletamos informações estatísticas do código do projeto. Baseado nessas informações tirei algumas conclusões.
No gráfico à direita vemos claramente que o projeto tinha inicialmente muito código duplicado. Depois de várias Refatorações, foram removidas duplicações e o código ficou muito mais limpo e fácil de alterar.

No gráfico seguinte vemos que, enquanto o número de linhas de código diminuiu
drasticamente, o número de linhas de código de
teste aumentou, o que significa que além de desenvolver novas funcionalidades, melhorar a qualidade do código do produto, ainda criamos uma série de testes automatizados que ajudam a garantir a qualidade do sistemas nas próximas versões.
No próximo gráfico vemos que o número de classes do sistema aumentou bastante, indicando que houve um aumento na modularização e reutilização do código. Mais classes com menos código significa maior especialização das classes, métodos menores e também maior testabilidade.

Todos estes números nos ajudam a ver que a metodologia adotada foi eficaz para melhorar e manter o projeto. Algumas práticas de XP adotadas pela equipe foram: programação pareada, releases curtos, jogo do planejamento, refatoração, design simples, cliente sempre presente, padronização de código.
Assinar:
Postagens (Atom)