AgileZ

Fim de ano sempre é sinônimo de reflexão, seja no aspecto pessoal ou profissional. Paramos para refletir sobre o que funcionou e o que não funcionou no ano que termina, fazendo novos planos para o ano que chega. O que podemos melhorar em nossa vida pessoal? E na profissional? Seja qual for sua profissão, uma coisa é sempre certa: seu objetivo é solucionar problemas. O marceneiro resolve o problema da dona de casa ao construir uma nova mesa, o dentista resolve algum problema de carie, o motorista um problema de trânsito e o analista de sistemas um problema de software. Cada um em sua especialidade, sempre procurando a melhor solução.
O famoso físico alemão Albert Einstein dedicou a sua vida a solucionar o maior problema da física até hoje: encontrar uma teoria que explicasse, de forma única, o funcionamento de tudo o que existe no universo. Ele não teve sucesso. Hoje existem algumas teorias que tentam resolver o mesmo problema, entretanto não são soluções simples. Destaquei a palavra simples por um motivo. Einstein acreditava que toda solução deveria ser simples para ser correta. Até os últimos instantes de sua vida ele perseguiu esse ideal. Eu acredito que ele estava certo. Durante o dia nos deparamos com inúmeros desafios, mas será que aplicamos as soluções mais simples? Leia a pequena estória abaixo:

Leia mais…

Antes que você estranhe o título acima, informo que este não será um artigo sobre engenharia civil, e sim de engenharia de software. Aproveitei a relação entre as duas engenharias para fazer uma analogia entre ambas e tentar quebrar um pouco a ‘rigidez’ predominante nos processos de desenvolvimento de software atuais. Falar de modelagem hoje é uma tarefa delicada, pois modelagem é uma das etapas mais importantes e também uma das mais difíceis do ciclo de desenvolvimento de um sistema de informação. Dependendo do modelo de desenvolvimento que sua equipe pratica, a modelagem estará presente em praticamente todas as fases de seus projetos, seja durante o levantamento de requisitos até a entrega. Um trabalho de criação de modelo bem feito é – quase sempre – o detalhe que definirá o sucesso ou fracasso de sua empresa. Até então creio não ter levantado nada de novo. Se você se sente bem com suas ferramentas de modelagem atuais ou é fã de modelos como CMMI ou MPS.br, provavelmente não irá gostar do que vou dizer aqui, porém, se quer continuar a leitura, considere-se advertido de que não costumo respeitar muito a tradição, independente do prestígio gozado por ela.

Leia mais…

Se você programa em alguma linguagem de programação orientada a objeto, com certeza conhece os termos “Private”, “protected” e “public” e muito provavelmente sabe para que eles servem. Métodos ou membros públicos são aqueles que podem ser acessados por outras classes, os protegidos apenas pelos descendentes e os privados só possuem visibilidade local, ou seja, dentro da própria classe. Parece simples, porém, é muito comum encontrar programadores que parecem não seguir critério algum ao definir o nível de visibilidade dos membros de suas classes, ou então aplicam alguma metodologia aleatória para este fim. Propriedades que eram protegidas são publicadas durante o desenvolvimento de outras classes clientes, conforme a necessidade. Classes “amigáveis” (class friendly) são criadas para permitir acesso a funções protegidas. Práticas como essas acabam por criar uma arquitetura extremamente confusa, com componentes de difícil entendimento, difíceis de serem testados e expandidos. Qual seria então o melhor critério para evitar esse tipo de problema?

Leia mais…

Há alguns anos, quando a internet ainda estava distante, o conhecimento era compartilhado por meio de livros ou de boca-a-boca. Era raro alguém possuir conhecimento aprofundado em vários segmentos e por isso o conhecimento era sinônimo de sucesso, garantia de emprego e prestígio social.

Com o decorrer dos anos e o surgimento da internet, um novo canal de compartilhamento de informações nasceu. Quanto mais popular e acessível a rede mundial de computadores ficava, mais fácil e palpável o conhecimento se tornava. Enquanto o autodidata de outrora era limitado pelos livros disponíveis – muitas vezes caros e em idioma estrangeiro – o autodidata dos tempos atuais tem a sua disposição bilhões de fontes de conteúdo a um clique do mouse. Começava então uma era onde o conhecimento se tornava comum e, consequentemente, deixava de ser considerado como critério de classificação e diferenciação entre as pessoas.

Se o conhecimento se tornou tão ordinário, qual seria então o novo parâmetro para diferenciação? Inteligência? Leia mais…

Seguindo a tendência do artigo anterior (Sua equipe de desenvolvimento está no caminho certo?) vou falar um pouco sobre algumas questões que nem sempre são observadas pelos programadores, mas competem para a sua imagem como bom profissional.
É muito comum, principalmente entre programadores mais novos, o ideal do código perfeito. Muitas vezes o programador novato trabalha suas habilidades com a meta de se tornar um melhor codificador a cada dia. Essa fase é plenamente justificável, e faz parte do desenvolvimento do profissional, entretanto, conforme o programador for ganhando maturidade e experiência, é necessário que ele trabalhe outras habilidades não relacionadas à codificação, que podemos chamar de habilidades não técnicas.

Desenvolvi uma lista com algumas questões que devem ser observadas por todo programador. (lista baseada no artigo de Alberto Gutierrez ).

1. Seja disciplinado:
No nosso dia-a-dia nos deparamos com diversas interrupções e tarefas paralelas. Telefone tocando, email, mensagem instantânea, colega chamando e diversas outras. Ser disciplinado significa estabelecer uma metodologia para que essas interrupções prejudiquem o menos possível o seu desempenho e produtividade. Utilização de técnicas como a técnica do pomodoro, por exemplo, é uma excelente metodologia para manter o foco em uma tarefa por vez.

Leia mais…

É difícil descrever todas as responsabilidades de uma equipe de desenvolvimento. Análise, documentação, testes, refatoração e etc. São muitas as competências exigidas, e, se cada uma delas não estiver clara para todo mundo, a chance de algo não sair conforme o esperado é grande. Pensando nisso, me baseei no artigo do Alberto Gutierrez para criar esse checklist com algumas coisas que você deve fazer para ter uma boa equipe.

1. Focar no cliente
O cliente é a razão de tudo. Sem ele não existiria o seu departamento, e, provavelmente, a sua empresa. Por isso, tenha em mente que você deve satisfazer o cliente, entregando coisas que agregam valor para ele. Focar no cliente também inclui abrir a mão de algumas coisas para entregar o que ele precisa. Por exemplo: se aquela refatoração vai atrasar a entrega de uma funcionalidade exigida pelo cliente, abra mão dela por enquanto (faça-a em outro momento mais oportuno).

Leia mais…

Um código fonte ‘sadio’ é uma das chaves para o sucesso de um projeto, e um CVS (control version system) é uma ferramenta fundamental para manter a saúde do seu código fonte. No entanto, somente uma boa ferramenta não garante um bom controle de versão. Ela deve ser amparada por boas práticas que normatizam sua utilização. Para analisar se você utiliza corretamente seu controle de versão, verifique se pelo menos as seguintes perguntas podem ser rapidamente atendidas:

• Como era o método XYZ da classe FooBar na versão 2.0.3.12 do projeto?

• Quais foram as alterações feitas para incluir suporte à NF-e?

• Quando esta linha de código foi adicionada ao método XYZ?

• Consigo compilar e executar o sistema na versão 2.0.2.15 para reproduzir e consertar o bug de um cliente?

Se o seu controle de versão não consegue responder a estas perguntas, então está na hora de rever as práticas do seu time. Uma ferramenta de controle de versão não deve servir somente como um backup do código fonte, onde, ao final do dia, o desenvolvedor deposita seu trabalho inacabado. Ela deve ser um santuário, o repositório sagrado que exige do desenvolvedor todo respeito e cuidado. Afinal, o artefato mais valioso de um projeto, o código fonte, está guardado ali. Portanto, não basta instalar um controle de versão e sair usando. O time deve rever seus conceitos e absorver as mudanças necessárias, que podem ser dolorosas. No entanto, após um tempo, o time começa a colher os frutos do terreno bem preparado.

Há pouco tempo li um artigo muito bom do Eduardo Miranda sobre gerência de versionamento, onde ele cita algumas práticas boas e ruins. Vamos a elas:

Leia mais…

Você se considera uma pessoa produtiva no trabalho ou em sua vida pessoal? Quanto tempo consegue se concentrar em uma determinada tarefa antes de ser interrompido ou mudar o foco? A produtividade de uma pessoa está diretamente ligada a capacidade que ela tem de manter o foco. Quanto mais focada for, melhor e mais rápida vai atingir o objetivo, seja no campo profissional ou pessoal.

Porém, nem sempre ‘mais’ significa ‘melhor’. O cérebro humano tem um limite, e não consegue produzir com qualidade satisfatória após um determinado tempo de esforço contínuo. Cada pessoa tem um ritmo e os intervalos regulares são necessários, seja pra ver emails, conversar, fazer uma ligação ou tomar um café. Leia mais…

A fim de ajudar as pessoas a entenderem melhor o desenvolvimento ágil de software, em 2001 os membros da Agile Alliance refinaram o enunciado do Manifesto Ágil, criando doze princípios que as metodologias ágeis devem seguir. Estes princípios são os seguintes:

1. Nossa maior prioridade é satisfazer o cliente através de entregas rápidas e contínuas de software funcional.
2. Abrace as mudanças de requisitos do projeto, mesmo que ocorram tardiamente. Os processos ágeis apóiam a mudança como uma vantagem competitiva para o cliente.
3. Entregue software funcionando com uma freqüência de duas semanas a dois meses, escolhendo sempre a menor escala de tempo possível.
4. O pessoal de negócio e os desenvolvedores devem trabalhar juntos no projeto diariamente.
5. Construa os projetos com pessoas motivadas. Forneça o ambiente, os equipamentos e as ferramentas de que elas precisam e confie que elas farão o trabalho.
6. Uma conversa cara a cara é a melhor forma de transmitir e receber informação do time de desenvolvimento.
7. Software funcionando é a principal medida de progresso.
8. Processos ágeis promovem um desenvolvimento sustentado. Gerência, desenvolvedores e usuários devem ser capazes de manter um ritmo constante indefinidamente.
9. A atenção contínua à excelência técnica e a um bom design aumentam a agilidade.
10. Simplicidade – a arte de maximizar a quantidade de trabalho desnecessária – é essencial.
11. As melhores arquiteturas, designs e requisitos surgem de times auto-gerenciados.
12. A intervalos regulares, o time reflete sobre como se tornar mais eficaz, e então ajusta seu comportamento de acordo com as reflexões.

Pare por um momento e reflita sobre os princípios acima. Serão tão radicais e impossíveis como algumas pessoas acham ou simplesmente seguem o bom senso? Será tão difícil fazer os projetos funcionarem desta forma? Você realmente acredita que seu cliente prefere uma ótima e farta documentação a um sistema funcionando em um curto prazo? Ou que um e-mail substitua um bom bate-papo? E que tal fazer somente o necessário, sem ficar ‘viajando na maionese’?

Estes princípios formam um senso comum e prático, sobre o qual podemos alicerçar nossos esforços para a construção de um software de sucesso.

(Referência: Agile Modelling – Scott Ambler)

Quem trabalha com desenvolvimento de software sabe que um dos nossos maiores desafios é conseguir mensurar o tamanho de cada tarefa com uma boa precisão, e, conseqüentemente, conseguir prever quando determinado recurso deverá ser concluído. A forma como fazemos nossas estimativas tem um grande impacto na confiabilidade de nossos prazos, porém, nem sempre as equipes tomam consciência desse fato, e continuam dando pouco valor ou dedicando menos esforço do que deveriam a essa atividade.

Seja qual for a metodologia de trabalho que sua equipe utiliza (scrum + XP ou outra mais tradicional) você pode utilizar diversas técnicas de estimativas. Neste artigo vou apresentar a que é mais utilizada por equipes que empregam metodologias ágeis: o Planning Poker.

Antes de começar, devo introduzir um conceito que pode não ser conhecido ou aceito por todos: uma estimativa é da equipe e não de um programador ou analista em específico, ou seja, o ato de estimar é uma atividade de TODA a equipe, e esse detalhe é primordial para o sucesso do Planning Poker. Com isso em mente, vamos à definição:

Leia mais…