"Nada na vida é completamente errado. Até um relógio quebrado, duas vezes ao dia está marcando a hora certa."

counterstrikeOlá Pessoal! Não escondo que sou “meio” viciado em quadrinhos, games, filmes, etc. Pois bem, depois de algum tempo parado decidi voltar a jogar um dos games mais viciantes da minha adolescência: O Counter-Strike. Voltei a jogar somente para dar uma surra no pessoal do escritório (@hrosko e @andrepiresmct), mas acabei deixando-o instalado e jogando eventualmente.

Apensar das coisas não terem muito a ver uma com a outra, comecei a traçar uma linha entre Counter-Strike e Desenvolvimento de Software, uma espécie de “boas práticas” comuns para ambos. Pensei muito antes de escrever esse post, depois desencanei e vi que o máximo que pode acontecer é que essas dicas ajudem vocês a desenvolver melhor ou a jogar melhor, então vamos lá:

Não adianta ser estrela em time que está perdendo: Mesmo com o melhor jogador no seu time, não há garantias de que o mesmo será campeão. É muito mais efetivo ter membros de nível mediano e bem entrosados em um time do que ter várias “estrelas” jogando no estilo cada um por si.

Evite ser herói: Quando damos de cara com vários membros do time adversário, a melhor estratégia é “correr”. Correndo você poderá enfrentar cada adversário separadamente. Alguns desenvolvedores/times trabalham com várias estórias em simultâneo, o que dá uma falsa impressão de produtividade. Quando falamos em requisitos, a melhor estratégia também é dividir para conquistar, ou seja, ao invés de “atacar” várias ao mesmo tempo, podemos atacá-las uma de cada vez (Imagine todo o time atirando em um único membro do time adversário :) ).

90% não é 100%: É sempre melhor tirar 100% de um adversário do que 70% de dois. Um adversário com 1% de life ainda atira, e com ajuda da Lei de Murphy ele pode levar vários membros do time antes de morrer.  Em uma Sprint temos que nos concentrar em terminar cada estória antes de passar para próxima, assim, ao final da Sprint mesmo que não tenhamos concluído todas as estórias teremos algumas concluídas ao invés de todas em 90% (e nada efetivo para entregar).

Ao final de um round, devemos nos preparar para o próximo: Fases rápidas não habilitam a compra de itens no início do round, porém, ao final podemos ir a pontos específicos do mapa e comprar coletes e granadas. Estar preparado no início de uma Sprint pode fazer tanta diferença quanto lançar uma granada no início do round, mas, afinal de contas o que seria estar preparado? Poderia ser a obtenção de um conhecimento específico que adiantaria todos os requisitos em 50% de todas as estórias por exemplo.

Ser efetivo e econômico traz grandes vantagens: Se você pode acabar com um adversário com uma única bala (Headshot), por que usar 10? Quanto menos balas você gastar menos terá que recarregar durante o round, o que pode salvar sua vida. Ninguém começa no CS conseguindo 100% de Headshots, esse número vai crescendo com o tempo e experiência (pelo menos com os jogadores normais). Na área de desenvolvimento, ninguém nasce extremamente produtivo, porém, é nossa obrigação buscar aumentar a produtividade através de novos conhecimentos e/ou novas ferramentas.

Quem fica parado morre: Preciso argumentar? :)

Adaptabilidade é crucial: Você pode ter sua arma predileta, mas ela pode não ser a mais efetiva em algumas fases ou em algumas situações. Na área de desenvolvimento temos cada desenvolvedor tem sua ferramenta preferida, pode ser um linguagem, um framework, uma IDE, etc. O ideal no ramo de desenvolvimento é não ficar preso as coisas somente pela predileção, mas sim pela sua efetividade no contexto em que será aplicada.

Poderia enumerar aqui várias outras práticas que ajudam em ambas as partes, mas prefiro deixar vocês pensarem no assunto e quem sabe compartilharem aqui os seus pensamentos.

Para variar, vou jogar um pouquinho.

Abraços!

Tagged with:
 
Faça da pedra de tropeço, um degrau de subida. Transforme cada fato negativo, em uma experiência positiva. - "Bruce Lee"

Nessa semana realizamos o II Fórum para Gerentes de Sistemas na Mindworks em Vitória-ES. Realizamos a primeira versão do evento no mês passado a pedido da própria Microsoft, e depois de uma série de pedidos para realização de uma segunda versão, decidimos organizar um evento semelhante, porém, voltado para a comunidade local.

Acredito que a segunda versão do evento ficou ainda melhor que a primeira. Mudamos algumas abordagens, inserimos alguns assuntos importantes e procuramos trabalhar de uma forma dinâmica e interativa com os participantes. Vou relatar agora um pouco do que aconteceu no evento:

.NET 4.0 e Visual Studio 2010

Nesse evento procuramos apresentar todos os recursos do Framework .NET desde a sua primeira versão lançada em 2003. O objetivo principal dessa parte do evento foi mostrar a maturidade da plataforma e como a mesma vem sendo melhorada de forma contínua e incremental (desde sua versão 2.0).

Como a idéia era fazer uma espécie de túnel do tempo das tecnologias Microsoft, procuramos abordar desde as características mais básicas da versão 2.0 do framework até as novidades mais quentes da versão 4.0 (versão mais atual).

Depois do apanhado histórico sobre o framework, fizemos algumas demonstrações das ferramentas de arquitetura do Visual Studio 2010, tais como: Gráfico de Dependências e Diagrama de camadas.

É impressionante perceber o mundo de ferramentas que temos à disposição no Framework .NET, e essa foi a idéia dessa apresentação, mostrar o poder que temos nas mãos utilizando essa plataforma.

Scrum e Agilidade

O André Pires apresentou o Scrum de uma forma muito interativa e dinâmica. Visitamos os conceitos do Scrum, seus papéis, artefatos, regras, cerimônias e recomendações. Acredito que todos os participantes tiveram uma visão bem clara do framework.

Gosto muito de discutir sobre Agile e Scrum. Apesar de não ser o palestrante desse tema, foi muito rico só ouvir os questionamentos feitos pelos gerentes de projetos que estavam presentes. O André apresentou com maestria o tema discorrendo sobre as grandes dúvidas e questionamentos dos gerentes de projeto tradicionais ao mundo ágil.

A apresentação terminou com uma dinâmica que exemplificava a utilização do Scrum. Os participantes tinham que atingir um objetivo específico em um tempo limite. O bacana é que o PO (André) passava pelas equipes gerando pequenos impedimentos e interferindo nos trabalhos, o que gerou fortes reações pela parte de alguns ScrumMasters. :)

Volto a destacar que, apesar de entender do tema, nada paga a troca de experiências que temos com os participantes do evento.

Técnicas de engenharia de software e TDD

Diferente da versão anterior desse evento, abordamos a importância da orientação a objetos e das técnicas de engenharia em projetos de software que usem processos interativos e incrementais na produção.

Fizemos algumas reflexões sobre qualidade de software e discutimos como é importante utilizar técnicas para construir o projeto que façam com que o custo de evolução não seja discrepante do custo de produção. Afinal de contas, em processos iterativos estamos sempre evoluindo o projeto.

Aprofundamos alguns conceitos que o André havia citado na palestra sobre Scrum. Falamos sobre POO, Design Patterns, CI, ORMs (Entity Framework e NHibernate), Programação em par, Testes unitários, DDD e TDD. Foi muito legal apresentar uma visão geral sobre esses assuntos que estão em alta nas listas de discussão mais ativas.

Finalmente, apresentamos o TDD de uma forma resumida como primeira prática a ser adotada dentre todas as práticas que havíamos discutido nessa etapa do evento.

O objetivo principal dessa parte do evento foi mostrar aos participantes que investir nas disciplinas apresentadas é um investimento tão importante quanto o investimento feito no aprendizado das tecnologias (ou mais).

Fotos do evento

Estamos preparando muitas novidades para o próximo evento, fiquem ligados!

Abraços!

Tagged with:
 
"Seja como a água que abre caminho através das pedras: não se oponha ao obstáculo; contorne-o!" - Bruce Lee

Olá Pessoal! Para auxiliar quem está começando ou quer começar a utilizar o TDD, estou disponibilizando um vídeo com uma demostração da ténica. O objetivo do vídeo é apresentar a utilização do TDD e fornecer algumas dicas sobre como se sair bem na utilização da técnica. Espero que gostem do vídeo:

Dicas gerais sobre TDD

Sempre inicie com uma lista de testes : No TDD, não saímos codificando. Antes de iniciar a construção de qualquer coisa, elabore uma lista de testes inicial. Caso seja necessário, você poderá incluir mais itens na sua lista de testes mesmo depois de já ter iniciado a codificação;

Sempre inicie pelo teste mais simples : Após elaborar sua lista de testes, inicie a codificação pelo teste mais simples da sua lista. Desenvolvendo dessa forma, você não só ganha ritmo, mas também vai aprendendo de pouco a pouco sobre o problema que está resolvendo.

Comece a construção do seu código pela construção do seu teste : Desenvolvendo o teste primeiro (como preza o TDD) temos a oportunidade de tomar decisões de design das nossas classes antes mesmo de construí-las. Iniciar a construção do código pelo teste possibilita que você veja o seu código pela perspectiva de quem o utilizará, ou seja, você terá um feedback de utilização antes mesmo de codificar sua classe.

Comece o teste pela assertiva : Iniciar o teste pela assertiva é definir o objetivo do teste. Escrever a assertiva é definir onde você quer chegar no teste, qual objetivo quer alcançar, se isso não estiver bem definido não adianta escrever o teste.

Simule até construir realmente : Sempre que possível, construa implementações falsas. Deixe para construir as implementações reais só quando for realmente necessário.

Busque o verde o mais rápido possível : Quando o teste estiver vermelho, procure fazê-lo passar o mais rápido possível, mesmo que a implementação feita não seja a mais agradável de ver. Quando o teste estiver verde, substitua a implementação feita por uma implementação mais elegante, afinal, a fase de refatoração serve para isso. :)

Construa somente o necessário para o teste passar : Não construa nada além do que o seus testes pedirem. Se desejar realizar alguma codificação, escreve primeiro um teste e depois o código. TDD também exige muita disciplina.

Passos de bebê : Procure sempre dar passos pequenos durante a construção dos seus testes, evite assumir um teste muito difícil ou grande logo de cara, deixe sempre os testes mais complicados para o final.

Links

Faça download do projeto construído: ConversaoNumerosRomanos

Veja outros links sobre TDD no delicious: delicious.com/denisferrari/tdd

Abraços!

Tagged with:
 
"Meus seguidores em Jeet Kune Do, atendem a isso: todas as normas fixas são incapazes de adaptabilidade ou flexibilidade; a verdade está fora de todas as normas fixas." - Bruce Lee

No dia 16/06 tive a oportunidade e a honra de palestrar na faculdade UNES em Cachoeiro-ES. O Evento foi organizado pelo MIC e marcou a inauguração do mais novo prédio da faculdade. A minha palestra representou a comunidade de desenvolvedores capixabas, o MSDev-ES. A segunda palestra foi realizada pelo Cleyton Santana do grupo MSInfraES.

Falar para pessoas que estão iniciando na área de desenvolvimento de software é uma extrema responsabilidade, por isso, ao invés de falar somente sobre TDD procurei mostrar alguns problemas da área e boas práticas através do case do meu primeiro projeto de software relevante (tinha 17 ou 18). Esse projeto foi realmente traumático, porém, definiu muitos dos meus paradigmas atuais sobre a carreira e o desenvolvimento de software em geral.

Troquei muitas informações com os profissionais locais após a minha palestra, fizemos tanto networking que acabei nem assistindo a segunda palestra do evento. Outro ponto relevante é que muitas pessoas que estavam lá tinham comparecido ao Maré-VIX, evento que organizei no CET-Faesa poucos dias antes.

Fotos

Slides da apresentação

Espero que os presentes tenham gostado do evento assim como eu gostei. Agradeço ao MIC e a UNES pela oportunidade e pela confiança.

Abraços!

Tagged with:
 
"A preguiça é a mãe do progresso. Se o homem não tivesse preguiça de caminhar, não teria inventado a roda."

PrevisibilidadeA cada dia que passo na área de desenvolvimento de software percebo que a mesma é peculiar em vários aspectos. É comum pessoas de outras áreas formarem opiniões sobre a nossa área usando como referência suas áreas de conhecimento, o problemas disso é que, geralmente, só quem é da área de software consegue ter uma visão realista sobre as características e problemas da área.

Após vários debates sobre o tema, decidi fazer um post sobre Previsibilidade em desenvolvimento de software. Decidi abordar o tema em uma apresentação ao invés de escrever, pois acredito que assim consegui expressar melhor as características que fazem com que seja tão difícil na nossa área estimar o tempo de desenvolvimento dos projetos.

Veja mais sobre previbilidade em desenvolvimento de software na tag “Previsibilidade” no delicious: delicious.com/denisferrari/Previsibilidade

Fico no aguardo dos feedbacks!

Abraços!

Tagged with:
 

Como você define qualidade de software?

"A qualidade nunca se obtém por acaso; ela é sempre o resultado do esforço inteligente." (John Ruskin)
Doctor Who

Doctor Who

Muitos profissionais da nossa área têm dificuldades em definir qualidade de software devido à quantidade de aspectos que precisam ser considerados para avaliar se um software possui ou não qualidade. Apesar do processo de avaliação da qualidade ser amplo e complexo, a definição de qualidade de software é simples de ser compreendida.

Para avaliar a qualidade de um computador, avaliamos separadamente a qualidade de seus componentes, como vídeo, som, capacidade de processamento e quantidade de memória. A qualidade do computador pode ser considerada uma média das avaliações individuais de seus componentes. No software, a mesma idéia pode ser aplicada, porém, ao invés de olharmos para os componentes que o formam devemos olhar para como ele atende aos seus stakeholders: o cliente que paga pelo software, o usuário que trabalha diretamente com o software no seu dia-a-dia e o fornecedor que constrói ou mantém o software.

Um software que atende ao cliente é aquele que atende ao objetivo para o qual ele foi construído (atender ao objetivo é mais importante do que respeitar o escopo inicial). Outro fator importante é fazer com que o software seja construído de forma a preservar o investimento do cliente, ou seja, fazer com que o trabalho de mapeamento do domínio e de seus processos não se perca quando uma tecnologia específica precisar ser substituída (a camada de apresentação, por exemplo).

Um software que atende ao usuário é aquele que resolve os principais problemas do seu dia-a-dia de forma simples e objetiva e usa como base da comunicação a linguagem que o usuário domina: A linguagem de seu domínio.

Um software que atende ao fornecedor é aquele que visa não só a construção rápida do projeto, mas também práticas de engenharia e testes que possibilitem à equipe responsável pela manutenção do sistema tenham total autonomia na execução de suas tarefas. Usar práticas que facilitem a manutenção do software é fazer com que o investimento do cliente dure ao máximo, e todo profissional da área tem a responsabilidade de construir softwares pensando na próxima pessoa que irá manter o projeto.

Um software de qualidade é a base para um bom relacionamento com o cliente, com os usuários e com as equipes de desenvolvimento. Um software que não atende aos três stakeholders terá uma vida curta e será responsável por muitas dores de cabeça.

Cada área de estudo citada aqui direta ou indiretamente possui métodos e processos específicos para garantia da qualidade. É dever de todo profissional de desenvolvimento conhecer essas técnicas e utilizá-las da melhor forma possível visando obter um bom resultado ao final da jornada de desenvolvimento.

Aguardo feedbacks!

Recomendações de leitura:

Ubiquitous Language

DDD

Integração contínua

Negociação de contratos

Veja também:

Tagged with:
 
"Provérbio chinês: Se você não mudar a direção, terminará exatamente onde partiu."
Albert Einstein

Albert Einstein

Nossa área de desenvolvimento de software é muito nova, e como consequência disso, ainda estamos aprendendo quais são as técnicas que funcionam e quais só atrapalham o dia-a-dia dos nossos projetos. É dever de todo profissional da área buscar meios para melhorar o nosso objetivo principal: Construir softwares que atendam aos clientes, aos usuários e às equipes de desenvolvimento.

Práticas ágeis são um meio e não um fim, não deve-se utilizar as técnias se não é evidente quais problemas elas tentam resolver, usar por usar não melhora em nada o resultado final do seu projeto. Você só deve usar essas práticas se realmente entender porquê elas são necessárias, e não porquê estão na moda.

Vamos observar os benefícios de algumas técnicas utilizadas no meio ágil:

Com TDD o programador cria o hábito de planejar suas tarefas antes de executá-las, isso se deve ao fato de que nessa técnica você começa pela elaboração de uma lista de testes para o artefato que será desenvolvido, e só depois começa a codificá-lo. Outro benefício do TDD é que o programador deve usar o seu código antes de implementá-lo, apesar de parecer estranho é uma quebra de paradigma excelente começar a codificação pelo teste e tomar as decisões de design do código antes de implementá-lo, isso reduz o retrabalho pois o programador percebe no início da codificação como ficará seu código ao final dela.

Muitos gestores ainda não acreditam nos benefícios da programação em par, sendo um dos motivos a sensação de perda de produtividade quando dois programadores são alocados para a mesma tarefa, essa sensação é falsa, pois existem uma série de fatores que devem ser levados em consideração quando falamos de produtividade. O ritmo de desenvolvimento da dupla é garantido pela  falta de distrações que um programador sozinho teria, dificilmente durante o desenvolvimento em par o “piloto” irá desviar do foco. Outro benefício da programação em par é a revisão que o “co-piloto” faz observando a codificação do piloto, muitos problemas podem ser identificados em tempo de codificação. A comunicação constante entre os programadores faz com que cada decisão seja mais bem pensada, e ainda traz um grande benefício: Dois membros da equipe vão conhecer aquele trecho do código, isso é essencial para contornar problemas de comunicação e troca de membros da equipe durante o desenvolvimento dos projetos.  A programação em par protege o investimento do projeto pois reduz a taxa de retrabalho da equipe e gera um código de qualidade superior, afinal, duas cabeças pensam melhor do que uma.

Desenvolver um software de forma iterativa e incremental traz uma série de benefícios, porém, também traz uma série de problemas. Desenvolver software em ciclos de tempo fechados faz com que cada minuto seja precioso, por isso, vários impedimentos são identificados ao longo do desenvolvimento e resolvidos a medida que as entregas são realizadas no final de cada ciclo. Como o desenvolvimento acontece em ciclos, a equipe de desenvolvimento pode aprender com os problemas enfrentados no ciclo anterior, isso permite que o processo de cada equipe possa ser melhorado continuamente, e essas melhorias sempre atacam um grande impedimento do clico anterior, ou seja, não são apenas melhorias por melhorias. Processos iterativos e incrementais também auxiliam a contornar o grande vilão dos projetos de software que é a mudânça de escopo, caso o cliente descubra uma nova necessidade  a mesma poderá ser implementada no próximo ciclo, já que o ciclo em desenvolvimento não deve ter seu objetivo alterado. Caso a necessidade do cliente mude (ou melhor, quando a necessidade do cliente mudar) e o ciclo desenvolvido não for mais necessário, o cliente só “perde” aquele ciclo, ou seja, o custo da alteração de escopo fica sendo o custo do desenvolvimento do novo ciclo. Outra característica interessante é que nessa forma de desenvolvimento os feedbacks dos usuários chegam muito mais cedo do que no modelo tradicional, já que no final do ciclo a equipe entrega um parte funcional do software, e já que o software entra em produção mais cedo o cliente também começa a usufruir dos benefícios do sistema mais cedo.

As técnicas ágeis são um meio para solucionar alguns dos problemas mais comuns dos ambientes de desenvolvimento como conhecemos (falta de comunicação, retrabalho, escopos rígidos, custos altos, falta de testes, etc.), elas propõem uma nova forma de trabalho, que tem se mostrado muito eficiente para equipes com o perfil adequado. Essas técnicas influenciam positivamente em todas as vertentes de avaliação da qualidade de um software desde que sejam aplicadas de forma correta.

Quer saber mais sobre as técnicas citadas? Seguem algumas referências:

Sobre TDD:

Sobre Programação em Par:

Sobre desenvolvimento iterativo e incremental:

Qual a sua experiência sobre as técnicas ágeis? Você acha que elas são o caminho para aumentarmos a qualidade dos softwares que desenvolvemos?

Aguardo feedbacks!

Tagged with: