AgileBrazil

28 de junho de 2010 1 comentário

Sem dúvida nenhuma foi um evento de imenso sucesso. Realizado em Porto Alegre nos dias 24 e 25 de junho, este evento teve a participação de várias personalidades da comunidade ágil, porém, para mim dois palestrantes se destacaram dos demais: Martin Fowler e Philippe Kruchten. É claro que tivemos outras palestras excelentes como a do Manoel Pimentel, Klaus Wuestefelde e outros, mas as do Fowler e Kruchten tiveram uma “bagagem” de experiência e visão holística de mundo ágil incríveis.

Para mim os quatro conceitos mais importantes retirados de suas apresentações foram:

  1. Se alguma coisa dói, faça com maior frequência
  2. Levar mais tempo fazendo um bom design porém simples, aumenta a sua velocidade
  3. O que funciona para o outro, pode não funcionar para você
  4. Agilidade não é uma receita e sim uma cultura

Tentarei agora resumir um pouco da minha percepção sobre cada um dos tópicos.

Se alguma coisa dói, faça com maior frequência


A idéia central aqui é que se alguma coisa gera um grande esforço ou uma grande preocupação deve ser feita com maior frequência, isto porque  quanto mais vezes fazemos alguma coisa e quanto menor o seu intervalo de repetições menor será o impacto ou conflitos encontrados. Um exemplo típico e comum que encontramos em várias equipes de desenvolvimento é o processo de deploy (publicação). Quem nunca ouviu de algum líder de equipe que ficou sem dormir as vésperas de alguma grande publicação ou troca de versão. O cara já sai de casa falando para a esposa: “Meu bem, hoje iremos colocar o sistema no ar. Não sei que horas chego em casa, vou comer alguma coisa na rua”. Geralmente o pobre coitado não volta para casa naquela noite, fica de plantão cheio de pepinos para resolver de madrugada, toma bronca por telefone do cliente, da esposa e do dono da empresa.

Bom, se você já viu ou viveu uma situação dessas você sabe do que estou falando, então porque ao invés de fazer esse grande processo de publicação com varias mudança de sistema e mega homologações de cliente, não fazer várias publicações menores? Por exemplo, se você tem uma funcionalidade nova faça uma publicação para essa funcionalidade. Seu horizonte de bugs, erros, modificações ou problemas fica menor, sua homologação mais simples e seu processo de publicação menos traumático.

Nessas horas começam a aparecer as desculpas: “Ah, não posso fazer isso porque meu cliente não deixa”, “Ah, ai vou ter que testar o sistema todos varias vezes”, “Ah isso não funciona”, “Ah isso não da certo, pois meu refactor muda o sistema todo”. Bem nunca vi um cliente que não goste de receber uma funcionalidade nova no sistema que o ajude em seu processo de operação e reduza seu trabalho de homologação, testar o sistema todo varias vezes? você conhece testes automatizados? Sim, antes de você vir com a próxima desculpa, dá para automatizar testes de interface sim, já existem varias ferramentas para isso. Isso não funciona? porque? já tentou?, quantas vezes você faz um refactor que altera toda a base do seu sistema? Bem essas são algumas perguntas que devem ser feitas antes de sair criticando um Continuous Delivery (Publicação continua)

Este conceito se aplica a varias outras partes do processo de desenvolvimento de um software como, por exemplo: integração contínua, refactor e outros

Levar mais tempo fazendo um bom design porém simples, aumenta a sua velocidade


Este é um ponto que gera muita polêmica na comunidade, isto porque é um ponto com um pouco de subjetividade ou difícil de mensurar. Por exemplo: o que é um bom design? ou aumenta a velocidade, em quanto? levar mais tempo, qual o tempo ideal? Bom, não irei entrar nesse mérito simplesmente explicarei o conceito.

A idéia e que se fizermos um software com uma bom design utilizando boas práticas de programação será muito mais fácil acrescentarmos novas funcionalidade a ele. “Uau, nossa nunca ninguém me disse isso antes”. Bom é claro que todos sabem disso ou já ouviram isso antes, mas na prática nem sempre isso acontece. Vocês por acaso nunca encontraram um código “macarronico” em um sistema? nunca encontraram uma função ou serviço com um grande acoplamento? nunca teve pressão de um líder ou gerente para entregar um código para ontem e não fez da melhor forma possível, deixando o refactor para uma outra oportunidade?  Bom se você respondeu não para as três perguntas anteriores ou você não é e nunca foi um desenvolvedor, ou você começou a programar ontem.

Esse tópico apesar de simples e até mesmo intuitivo serve para nos lembrar da importância da qualidade de código que estamos fazendo hoje e que nos poupará tempo amanhã.

O que funciona para o outro, pode não funcionar para você


Bem isso foi muito legal de se ouvir. Está em linha com que eu penso sobre processo e práticas de desenvolvimento de software. Cada empresa tem seu processo de trabalho, certo ou errado ele é único! Isto porque cada empresa possui suas particularidades que englobam área de atividade, posição geográfica, situação financeira, qualidade de mão de obra. Temos que entender que não é porque um conjunto de práticas que deram certos em uma empresa será o melhor para outras. Temos que estudar, entender e escolhermos os processos que podem e devem se adequar em nosso contexto. Ai começam as discussões dos xiitas: “Ah mas se não fizer tudo igualzinho X fez então teremos um Ybut” ai começam os scrumbut, agilebut, xpbut. Bem se um scrumbut me fizer produzir software com melhor qualidade e com melhores resultado que um scrum seguido ao pé da letra, que seja. O importante é estudar e entender o custo e o benefício de cada umas das práticas que serão seguidas ou não.

Não estou aqui defendendo empresas que usam uma ou duas praticas ágeis e se dizem agilistas. Estou defendendo pessoas que estudam métodos ágeis entendem seus conceitos, entendem seus ambientes, sabem de seus benefícios e suas limitações e adaptam esses métodos as suas realidades.

Por exemplo, eu tenho uma equipe de desenvolvedores que sentam em uma mesma sala, conversam e trocam idéias durante o dia todo, uns ajudam aos outros em código e dúvidas, almoçam juntos e gostam de falar sobre trabalho mas não fazem stand-up meeting. Ai você conta isso para alguém e o cara fala: “Se você não tem stand-up metting, você não usa scrum” nossa nem vale a pena continuar a conversa.

Agilidade não é uma receita e sim uma cultura


Bem, acredito que esse último conceito é o resumo de tudo que foi percebido no decorrer do artigo. Agilidade não é uma receita mágica, siga ao pé da letra que você será bem sucedido. Agilidade são idéias e práticas que nos ajudam a desenvolver software com maior qualidade, facilidade, simplicidade e valor. Essas práticas buscam nos orientar e a nos disciplinar a buscar mecanismos que nos auxiliem a ter sucesso. Agilidade não tem linguagem de programação, não tem banco de dados, não tem hardware, ao invés disso, temos comunicação, simplicidade, conceitos de valor agregado, prioridades, transparência e clareza.

Sem tempo!!!

2 de maio de 2010 Deixe um comentário

Bom pessoal, desculpem a ausência mas esse mês foi terrível em matéria de tempo. Várias coisas aconteceram: a WhiteFox mudou de endereço, viemos para a Barra e estamos no Downtown, migração do TFS para versão 2010, aumento de demanda dos clientes, palestrar no Community Launch Rio 2010, fazer a CSM, ufa fiquei cansado.

Espero que esse mês as coisas se estabilizem mas em breve teremos nvos artigos sobre: Mock X Stub, TDD x BDD x ATDD, boas práticas de programação, Aplicando SCRUM. É muita coisa boa na lista, fiquem de olho….

Categorias:Uncategorized

Community Launch VS 2010 – Rio

19 de abril de 2010 Deixe um comentário

O evento que aconteceu nesse sábado 17/04/2010 foi um sucesso!

Vários desenvolvedores compareceram ao evento e nos prestigiaram com pergunta e aplausos. Sem dúvida nenhuma, foi um evento que veio fortalecer o grupo DotNetArchitects RJ e mostrar aos outros estados que temos condições e competência para criarmos um grande evento aqui no Rio. Não podemos esquecer de agradecer aos nossos patrocinadores: WhiteFox, Infnet, Microsoft e Rcosta, assim como nossos palestrantes que preparam palestras  alta padrão técnico e visual: Alexandre Bispo, Vinicios Quaiato, Sydney Lima, Alexandre Valente, Fernando Bichara, Rodrigo Vidal e Carlos Eduardo.

De minha parte, contribui com a apresentação sobre Test Driven Development, onde mostro os conceitos básicos e aspectos importantes para sua prática.

Categorias:Desenvolvimento

Análise Ibovespa 19/03/2010

21 de março de 2010 Deixe um comentário

Mais uma semana onde o índice tenta ultrapassar os 70000 pontos e não consegue. Bom para quem esta vendido coberto como eu! O tempo passa, o tempo voa e as opções vão caindo de preço numa boa. O mercado demonstra que essa resistência realmente é forte, diminuindo o otimismo dos mais animados. Mas nem tudo esta perdido, o gráfico de 6 meses ainda mostra uma figura bem animadora, entretanto, se olhamos nos últimos 3 meses estamos montando um M, figura que me preocupa. Até 68000 pontos não compromete o gráfico, mas abaixo disso a coisa azeda bem, então de olho nesse suporte! O índice vai andando de lado na faixa de 68000 a 70000, quem está vendido coberto relaxe e aproveite, mas atenção aos perdes do suporte e da resistência. Quem está liquido recomendo que permaneça assim.

Categorias:Uncategorized

Análise Ibovespa 12/03/2010

14 de março de 2010 Deixe um comentário

O mercado se comportou como esperado. O índice testou a resistência dos 70.000 pontos por três vezes mas não conseguiu rompe-la, dando uma aliviada na pressão compradora na sexta-feira. O gráfico abaixo mostra uma grande bandeira de alta na figura de 6 meses o que nos leva a crer em uma melhora no quadro geral da bovespa. No entanto, estamos bem perto da resistência principal de 71.000, com isso o mercado vai ficando de olho na realização dos lucro. Não aconselho compras agora, esperaria uma recuada do mercado para os 67.500. Caso o Ibovespa perca esse suporte, as realizações podem aumentar. Para os conservadores a semana deu vários pontos de venda valendo uma venda coberta com exercício alto.

Categorias:Uncategorized

Nerd – Ser ou não ser? Eis a questão

7 de março de 2010 Deixe um comentário

Triumph of the Nerds

Este filme deveria ser obrigatório para todos os empreendedores, principalmente os da área de TI. Garanto que todos que trabalham em desenvolvimento de software já quiseram criar algo inovador para ficar rico e conhecido? Bem, não é garantia de sucesso, mas este vídeo mostra algumas pessoas que conseguiram transformar sonhos em realidade.

Parte 1
Parte 2
Parte 3
Parte 4
Parte 5
Parte 6

Categorias:Tecnologia

Ibovespa 05/03/2010

7 de março de 2010 1 comentário

O mercado teve uma semana de recuperação! Após três tentativas frustradas de rompimento da resistência em 67700, finalmente, na sexta seu rompimento foi confirmado com o Ibovespa fechando a 68847. Esse rompimento deve ser acompanhado de uma boa abertura na segunda, consolidando desta forma o caminho rumo a próxima resistência em 70000 pontos. Após as sucessivas queda até o dia 05/02, o Ibovespa vem apresentando topos e fundos ascendentes o que é bem positivo e deixando o gráfico bem atraente. Do lado negativo, o mercado volta a perder força na perda dos 64500 pontos. Não devemos e esperar um grande rally de alta pois as bandas de bollinger estão abertas. Então, muita calma nessa hora e vamos montando a carteira aos poucos. Fiquem de olho em PETR4, GGBR4 e BVMF3. Bons negócios.

Categorias:Finanças