domingo, 27 de dezembro de 2009
Pensamento 007
É sinal de sabedoria distinguir a hora de estudar e aprender novos conhecimentos da hora de aplicá-los.
sexta-feira, 4 de dezembro de 2009
Pensamento 006
Praticar e aprender a partir da prática é fácil. Difícil é fazer como Kent Beck, Joshua Kerievsky, Alistair Cockburn, Ivar Jacobson, Grady Booch, Dikstra e tantos outros renomados pensadores da computação que tentaram (e conseguiram) traduzir o resultado de suas experiências em algo compreensível para o resto da humanidade, como é o caso das fórmulas publicadas pelo gênio Einstein.
domingo, 4 de outubro de 2009
sexta-feira, 2 de outubro de 2009
O futuro da TI
O campo da Tecnologia da Informação é muito fértil. Deve ser por isso que até hoje ele não estabilizou: suas bases estão mais frouxas do que nunca.
Muitos se apegam a teorias ultrapassadas, como aquelas que propõem um caminho para se encontrar a fórmula da previsibilidade para o conjunto das atividades da chamada engenharia de software - uma quimera - um verdadeiro otimismo irracional. Outros, impulsionados pelo discurso de evangelistas de uma só metodologia, se limitam a simplesmente se rebelar contra tudo e contra todos a seu redor. Fazer críticas sem base é muito fácil. Sabedoria de verdade é integrar as pessoas em torno de uma reflexão madura em que todos da organização têm voz e vez.
Desenvolver sistemas, sofware e/ou hardware, para atender necessidades momentâneas de uma organização é um esforço que pode custar muito caro se implementado sob premissas enganosas.
Há sistemas muito críticos (ex: sistemas das quais vidas ou sociedades inteiras dependem) e há sistemas de baixa criticidade em termos de impacto social, econômico, político, etc. No primeiro caso, pode ser necessário se investir em uma rigorosa especificação prévia, independemente do custo, já que vidas ou sociedades inteiras podem ser prejudicadas. No segundo, pode ser necessário liberar a primeira versão o mais rápido possível, evitando desperdiçar tempo em planejamento e especificação formal de altíssima precisão e alto grau de previsibilidade, para ganhar tempo em cima dos importantes feedbacks dos usuários, e assim evoluir o sistema na direção certa, incrementalmente e com a participação direta de seu público consumidor.
É possível definir um processo unificado para os dois extremos? Sim, é possível, mas não é suficiente nem eficiente. É possível definir dois processos: um para cada extremo? Sim, é possível, mas novamente não é suficiente nem eficiente. Cada grupo de usuários, cada equipe de profissionais de TI, cada projeto, cada organização, cada plataforma tecnológica, cada ambiente de trabalho, cada conjuntura político-econômica e cada momento do projeto são fatores suficientes para tornar um dado processo ou metodologia escolhida à priori num mero plano que precisa ser revisto urgentemente, em outras palavras: uma mera fantasia intelectual produzida num passado não muito distante, cujo resultado projetado poderá levar o projeto para um lugar distante de seus objetivos presentes, atuais.
Para finalizar, o sucesso dos profissionais de TI depende de conhecimento (dos recursos tecnológicos, das necessidades dos usuários), de prática (que leva à experiência e produtividade) e, principalmente, de bom senso, pois a realidade das organizações é dura com aqueles que subestimam a capacidade do ser humano de criar problemas e de resolvê-los de formas cada vez mais imprevisíveis.
Muitos se apegam a teorias ultrapassadas, como aquelas que propõem um caminho para se encontrar a fórmula da previsibilidade para o conjunto das atividades da chamada engenharia de software - uma quimera - um verdadeiro otimismo irracional. Outros, impulsionados pelo discurso de evangelistas de uma só metodologia, se limitam a simplesmente se rebelar contra tudo e contra todos a seu redor. Fazer críticas sem base é muito fácil. Sabedoria de verdade é integrar as pessoas em torno de uma reflexão madura em que todos da organização têm voz e vez.
Desenvolver sistemas, sofware e/ou hardware, para atender necessidades momentâneas de uma organização é um esforço que pode custar muito caro se implementado sob premissas enganosas.
Há sistemas muito críticos (ex: sistemas das quais vidas ou sociedades inteiras dependem) e há sistemas de baixa criticidade em termos de impacto social, econômico, político, etc. No primeiro caso, pode ser necessário se investir em uma rigorosa especificação prévia, independemente do custo, já que vidas ou sociedades inteiras podem ser prejudicadas. No segundo, pode ser necessário liberar a primeira versão o mais rápido possível, evitando desperdiçar tempo em planejamento e especificação formal de altíssima precisão e alto grau de previsibilidade, para ganhar tempo em cima dos importantes feedbacks dos usuários, e assim evoluir o sistema na direção certa, incrementalmente e com a participação direta de seu público consumidor.
É possível definir um processo unificado para os dois extremos? Sim, é possível, mas não é suficiente nem eficiente. É possível definir dois processos: um para cada extremo? Sim, é possível, mas novamente não é suficiente nem eficiente. Cada grupo de usuários, cada equipe de profissionais de TI, cada projeto, cada organização, cada plataforma tecnológica, cada ambiente de trabalho, cada conjuntura político-econômica e cada momento do projeto são fatores suficientes para tornar um dado processo ou metodologia escolhida à priori num mero plano que precisa ser revisto urgentemente, em outras palavras: uma mera fantasia intelectual produzida num passado não muito distante, cujo resultado projetado poderá levar o projeto para um lugar distante de seus objetivos presentes, atuais.
Para finalizar, o sucesso dos profissionais de TI depende de conhecimento (dos recursos tecnológicos, das necessidades dos usuários), de prática (que leva à experiência e produtividade) e, principalmente, de bom senso, pois a realidade das organizações é dura com aqueles que subestimam a capacidade do ser humano de criar problemas e de resolvê-los de formas cada vez mais imprevisíveis.
quarta-feira, 23 de setembro de 2009
Pensamento 004
Se a mente silencia, algo de muito importante encontra-se em gestação.
Quanto mais paciência, mais afinação.
Quanto mais paciência, mais afinação.
sexta-feira, 21 de agosto de 2009
O âmago do desenvolvimento de software
Quais seriam os talentos, as habilidades, os pulos-do-gato a serem dominados por alguém que almeja ser um desenvolvedor de software de mão-cheia?
Particularmente, não creio que os mais experimentados desenvolvedores do mundo tenham uma resposta precisa para essa questão. Eles sequer precisam responder a essa questão para continuar aprimorando suas habilidades e acumulando sucessos em novos projetos. Eles simplesmente aprendem com a prática e com a interação com outros colegas experientes, assimilando e aplicando padrões que apresentem bons resultados de produtividade e de qualidade.
A propósito, em 1999 o renomado enxadrista Garry Kasparov foi perguntado se a sua maestria no jogo de xadrez poderia ser ensinada. Para o consagrado campeão mundial, quem almeja a maestria no xadrez deve ter intuição, deve ter um gongo interior, uma iluminação, de modo que possa ter uma visão panorâmica do que está acontecendo (no torneio). Finalizou dizendo que seria necessário já nascer com essa característica, já que nenhum treinamento poderia contruí-la.
Voltando à engenharia de software, Alistair Cockburn citou 7 habilidades requeridas para o desenvolvimento de software (fonte: Software engineering in the 21st century):
Segundo Mary Poppendieck, especialista em pensamento lean, desenvolver software requer a aplicação consciente de técnicas de solução de problemas. Para ela, é comum novatos optarem pela abordagem depth-first, tomando decisões de design muito cedo. Enquanto se aprende o contexto do problema, é mais seguro adotar a abordagem breadth-first, evitando-se tomar decisões prematuras que possam fazer com que a equipe desperdice energia focando em detalhes com maior risco de impacto de mudanças ao longo do projeto.
Após duas décadas aprendendo, acumulando e combinando técnicas para desenvolver software com qualidade, o que eu posso concluir de tudo isso?
Tenho percebido que as técnicas de desenvolvimento de software evoluem com o passar dos anos, assim como os problemas de negócio e as soluções tecnológicas. Por isso, precisamos usar frequentemente nosso intelecto, intuição, talento, criatividade, conhecimento técnico e habilidade de comunicação/interação com outras pessoas para formatarmos e aplicarmos a técnica correta de acordo com o contexto de cada momento do projeto de desenvolvimento de software. Minha conclusão é a seguinte: precisamos nos manter aprendendo por meio da pesquisa frequente e da interação contínua com os colegas de trabalho, participando ativamente da solução dos problemas que emergem dos projetos reais. Felizmente, a comunidade de desenvolvedores de software dispõe de redes sociais colaborativas que permitem expandir esse aprendizado continuamente conforme o interesse e disponibilidade de cada um.
Particularmente, não creio que os mais experimentados desenvolvedores do mundo tenham uma resposta precisa para essa questão. Eles sequer precisam responder a essa questão para continuar aprimorando suas habilidades e acumulando sucessos em novos projetos. Eles simplesmente aprendem com a prática e com a interação com outros colegas experientes, assimilando e aplicando padrões que apresentem bons resultados de produtividade e de qualidade.
A propósito, em 1999 o renomado enxadrista Garry Kasparov foi perguntado se a sua maestria no jogo de xadrez poderia ser ensinada. Para o consagrado campeão mundial, quem almeja a maestria no xadrez deve ter intuição, deve ter um gongo interior, uma iluminação, de modo que possa ter uma visão panorâmica do que está acontecendo (no torneio). Finalizou dizendo que seria necessário já nascer com essa característica, já que nenhum treinamento poderia contruí-la.
Voltando à engenharia de software, Alistair Cockburn citou 7 habilidades requeridas para o desenvolvimento de software (fonte: Software engineering in the 21st century):
- Decidir o que deverá ser construído
- Gerenciar (pessoas e projetos)
- Modelar
- Design da visão externa
- Design de larga escala (arquitetura)
- Design de pequena escala (programação)
- Validar o trabalho
Segundo Mary Poppendieck, especialista em pensamento lean, desenvolver software requer a aplicação consciente de técnicas de solução de problemas. Para ela, é comum novatos optarem pela abordagem depth-first, tomando decisões de design muito cedo. Enquanto se aprende o contexto do problema, é mais seguro adotar a abordagem breadth-first, evitando-se tomar decisões prematuras que possam fazer com que a equipe desperdice energia focando em detalhes com maior risco de impacto de mudanças ao longo do projeto.
Após duas décadas aprendendo, acumulando e combinando técnicas para desenvolver software com qualidade, o que eu posso concluir de tudo isso?
Tenho percebido que as técnicas de desenvolvimento de software evoluem com o passar dos anos, assim como os problemas de negócio e as soluções tecnológicas. Por isso, precisamos usar frequentemente nosso intelecto, intuição, talento, criatividade, conhecimento técnico e habilidade de comunicação/interação com outras pessoas para formatarmos e aplicarmos a técnica correta de acordo com o contexto de cada momento do projeto de desenvolvimento de software. Minha conclusão é a seguinte: precisamos nos manter aprendendo por meio da pesquisa frequente e da interação contínua com os colegas de trabalho, participando ativamente da solução dos problemas que emergem dos projetos reais. Felizmente, a comunidade de desenvolvedores de software dispõe de redes sociais colaborativas que permitem expandir esse aprendizado continuamente conforme o interesse e disponibilidade de cada um.
terça-feira, 18 de agosto de 2009
Pensamento 003
Quanto maior o feedback, maior o aprendizado.
Essa regra vale para cientistas ao verificar hipóteses, designers ao conceber novos produtos, usuários ao utilizar novas ferramentas.
No contexto computacional, isto se traduz em mais iterações (ciclos de entrega) durante os estágios de desenvolvimento e manutenção de produtos de software e/ou hardware. Também se traduz em menos stress no atendimento das tão aguardadas solicitações de mudança/melhoria.
Essa regra vale para cientistas ao verificar hipóteses, designers ao conceber novos produtos, usuários ao utilizar novas ferramentas.
No contexto computacional, isto se traduz em mais iterações (ciclos de entrega) durante os estágios de desenvolvimento e manutenção de produtos de software e/ou hardware. Também se traduz em menos stress no atendimento das tão aguardadas solicitações de mudança/melhoria.
domingo, 2 de agosto de 2009
Pensamento 002
Os mais experientes são os mais humildes porque aprenderam algo com seus erros e os evitarão daqui para frente.
sábado, 1 de agosto de 2009
TDD com VSTS - parte 7/7
O sétimo vídeo da série de demonstrações de test-driven development usando Microsoft Visual Studio Team System está disponível no Youtube no link:
TDD com Microsoft Visual Studio Team System - parte 7/7
Este vídeo demonstra a criação e implementação de outro caso de teste com cenário negativo - TestDepositoComValorZeroDeveFalhar - o qual foi adicionado à lista "Negocio - testes de unidade". Neste cenário, o teste de unidade se certifica de que uma exceção do tipo ContaException será disparada durante a tentativa de fazer um depósito com valor zero.
TDD com Microsoft Visual Studio Team System - parte 7/7
Este vídeo demonstra a criação e implementação de outro caso de teste com cenário negativo - TestDepositoComValorZeroDeveFalhar - o qual foi adicionado à lista "Negocio - testes de unidade". Neste cenário, o teste de unidade se certifica de que uma exceção do tipo ContaException será disparada durante a tentativa de fazer um depósito com valor zero.
TDD com VSTS - parte 6/7
O sexto vídeo da série de demonstrações de test-driven development usando Microsoft Visual Studio Team System está disponível no Youtube no link:
TDD com Microsoft Visual Studio Team System - parte 6/7
Este vídeo demonstra a criação e implementação de um caso de teste com cenário negativo - TestDepositoComValorNegativoDeveFalhar - o qual foi adicionado à lista "Negocio - testes de unidade". Neste cenário, o teste de unidade se certifica de que uma exceção do tipo ContaException será disparada durante a tentativa de fazer um depósito com valor negativo.
TDD com Microsoft Visual Studio Team System - parte 6/7
Este vídeo demonstra a criação e implementação de um caso de teste com cenário negativo - TestDepositoComValorNegativoDeveFalhar - o qual foi adicionado à lista "Negocio - testes de unidade". Neste cenário, o teste de unidade se certifica de que uma exceção do tipo ContaException será disparada durante a tentativa de fazer um depósito com valor negativo.
TDD com VSTS - parte 5/7
O quinto vídeo da série de demonstrações de test-driven development usando Microsoft Visual Studio Team System está disponível no Youtube no link:
TDD com Microsoft Visual Studio Team System - parte 5/7
Este vídeo demonstra um passo importante do ciclo TDD: refatoração de código. Este passo é caracterizado por modificar o código sem necessariamente implementar nova funcionalidade.
TDD com Microsoft Visual Studio Team System - parte 5/7
Este vídeo demonstra um passo importante do ciclo TDD: refatoração de código. Este passo é caracterizado por modificar o código sem necessariamente implementar nova funcionalidade.
TDD com VSTS - parte 4/7
O quarto vídeo da série de demonstrações de test-driven development usando Microsoft Visual Studio Team System está disponível no Youtube no link:
TDD com Microsoft Visual Studio Team System - parte 4/7
Antes de iniciar um ciclo TDD (RED, GREEN, GREEN), é recomendável executar o seguinte ritual de integração contínua: get latest version, executar lista de testes (GREEN). Após a conclusão do ciclo TDD, o ritual é o seguinte: get latest version, executar lista de testes (GREEN) e, finalmente, check-in. O vídeo demonstra mais um ciclo TDD com atividades de integração contínua (get latest version e check-in), tendo sido adicionado o caso de teste TestDepositoDeveIncrementarSaldo à lista "Negocio - testes de unidade".
TDD com Microsoft Visual Studio Team System - parte 4/7
Antes de iniciar um ciclo TDD (RED, GREEN, GREEN), é recomendável executar o seguinte ritual de integração contínua: get latest version, executar lista de testes (GREEN). Após a conclusão do ciclo TDD, o ritual é o seguinte: get latest version, executar lista de testes (GREEN) e, finalmente, check-in. O vídeo demonstra mais um ciclo TDD com atividades de integração contínua (get latest version e check-in), tendo sido adicionado o caso de teste TestDepositoDeveIncrementarSaldo à lista "Negocio - testes de unidade".
TDD com VSTS - parte 3/7
O terceiro vídeo da série de demonstrações de test-driven development usando Microsoft Visual Studio Team System está disponível no Youtube no link:
TDD com Microsoft Visual Studio Team System - parte 3/7
Um ciclo TDD possui os seguintes passos: rodar o teste falhando (RED), criar a implementação mais simples que faça o teste passar (GREEN), refatorar o código sem quebrar os testes (GREEN). O vídeo apresenta o primeiro passo (RED) ao executar o teste que está disparando a exceção System.NotImplementedException. O segundo passo (GREEN) é então alcançado com a Implementação mais simples do método Conta.getSaldo() que faz o teste passar. O terceiro passo de refatoração não foi necessário pois o código já estava simples, limpo e sem trechos repetidos. O vídeo demonstra a criação de uma lista de testes chamada "Negocio - testes de unidade", na qual é adicionada o primeiro caso de teste: TestSaldoInicialDeveSerZero. Demonstra ainda como se ativa a medição da cobertura de código do assembly Negocio.dll. O TDD tem como meta 100% de cobertura, desde o início do projeto. Por fim, o primeiro check-in no repositório é realizado.
TDD com Microsoft Visual Studio Team System - parte 3/7
Um ciclo TDD possui os seguintes passos: rodar o teste falhando (RED), criar a implementação mais simples que faça o teste passar (GREEN), refatorar o código sem quebrar os testes (GREEN). O vídeo apresenta o primeiro passo (RED) ao executar o teste que está disparando a exceção System.NotImplementedException. O segundo passo (GREEN) é então alcançado com a Implementação mais simples do método Conta.getSaldo() que faz o teste passar. O terceiro passo de refatoração não foi necessário pois o código já estava simples, limpo e sem trechos repetidos. O vídeo demonstra a criação de uma lista de testes chamada "Negocio - testes de unidade", na qual é adicionada o primeiro caso de teste: TestSaldoInicialDeveSerZero. Demonstra ainda como se ativa a medição da cobertura de código do assembly Negocio.dll. O TDD tem como meta 100% de cobertura, desde o início do projeto. Por fim, o primeiro check-in no repositório é realizado.
sexta-feira, 31 de julho de 2009
TDD com VSTS - parte 2/7
O segundo vídeo da série de demonstrações de test-driven development usando Microsoft Visual Studio Team System está disponível no Youtube no link:
TDD com Microsoft Visual Studio Team System - parte 2/7
Neste vídeo é criada uma solution com dois projetos C#: Negocio e NegocioTeste. Seguindo a prática test-driven development (TDD), é criado o primeiro caso de teste: método TestSaldoInicialDeveSerZero(). A partir daí, para que o teste de unidade possa ser compilado e executado, são criadas classes e métodos inicialmente sem implementação. Para garantir cobertura máxima, nenhum código que irá em breve para o ambiente de produção deverá ser implementado sem a existência de um caso de teste que o valide.
TDD com Microsoft Visual Studio Team System - parte 2/7
Neste vídeo é criada uma solution com dois projetos C#: Negocio e NegocioTeste. Seguindo a prática test-driven development (TDD), é criado o primeiro caso de teste: método TestSaldoInicialDeveSerZero(). A partir daí, para que o teste de unidade possa ser compilado e executado, são criadas classes e métodos inicialmente sem implementação. Para garantir cobertura máxima, nenhum código que irá em breve para o ambiente de produção deverá ser implementado sem a existência de um caso de teste que o valide.
TDD com VSTS - parte 1/7
O primeiro vídeo da série de demonstrações de test-driven development usando Microsoft Visual Studio Team System está disponível no Youtube no link:
TDD com Microsoft Visual Studio Team System - parte 1/7
Neste vídeo é feita a preparação do ambiente de desenvolvimento, sendo criado um Team Project chamado "EquipeAgil" com o respectivo repositório de código mapeado para a seguinte pasta local: Desktop\EquipeAgil.
TDD com Microsoft Visual Studio Team System - parte 1/7
Neste vídeo é feita a preparação do ambiente de desenvolvimento, sendo criado um Team Project chamado "EquipeAgil" com o respectivo repositório de código mapeado para a seguinte pasta local: Desktop\EquipeAgil.
Assinar:
Postagens (Atom)
