Archive for the ‘Métodos Ágeis’ Category

Escola – Fábrica de Pessoas, parecida com a de Software

junho 20, 2010

O Fabrício me emprestou o livro Você Está Louco, do Ricardo Semler. As palestras que já havia visto dele na internet são muito boas, o cara é sensacional. Mas, o tempo passava e eu nunca lia o livro dele, até que ele veio parar na minha mesa. Não vou falar muito mais sobre o livro, vou falar de um aspecto que ele levantou quando falava de escola e do projeto Lumiar, e que tem muito a ver com software.

No mundo de software, muito dinheiro, estudo e tempo foram gastos tentando trazer o conceito de linha de montagem para o software. O paralelo era claro: se entra ferro e sai um carro, pode muito bem entrar uma idéia e sair um software, é só cada um ter sua atividade muito bem definida, sem bem específico. O final da história todos conhecem: este modelo vem fracassando com o passar do tempo e as pessoas têm ido em busca de algo mais humano, que valorize o indivíduo e a interação entre eles.

Até aí nada de novo e o que tem a escola a ver com isso? Vejam a observação que ele faz no livro e que está transcrita abaixo:

Pós-revolução industrial, o importante era fazer transitar massas de crianças pela escola, para alimentar o dragão do mercado de trabalho. Assim, emulou-se a linha de montagem nas escolas, com carteiras fixas, professor para 20 ou 30 alunos (40 ou mais até), estruturar modular de 55 minutos e disciplinas verticalmente construídas.

É… realmente parecia que este modelo estava fadado ao sucesso, muito bem pensado. Assim conseguimos ganhos extraordinários construindo carros. Mas as coisas ficaram mecânicas demais e esqueceu-se de levar em conta que não era só chegar e despejar conteúdo para alunos que são chamados pelo número. É necessário despertar o prazer de ler, aprender, descobrir coisas novas. Você não está despejando conteúdo, está formando a pessoa.

Além disso, assim como na fábrica de software, praticamente não aproveitamos a interação entre diferentes matérias. Existem algumas tentativas em projetos conjuntos, mas as coisas são bem separadas.

Recuperando o contato pessoal

Na proposta de educação do projeto Lumiar, as crianças seriam acompanhadas por um tutor desde os primeiros anos de vida até se formarem. Este tutor cuida de cerca de 15 crianças e determina em conjunto com os pais e as crianças quais as aulas mais importantes para ela no momento. Simples e eficiente. Sem testes, mas sim, o tutor avaliando em conjunto com pais e aluno se ele está pronto para mais conhecimento.  Além disso, as aulas são dadas somente por pessoas que gostem muito do assunto. Faz todo sentido né ?

Educando uma criança, um grande projeto de escopo fechado

Por que ao entrarmos na escola, com cerca de 6 anos, já temos um cronograma definido do que vamos aprender até os 14? Os pais, o tutor ou alguém que acompanhe de perto o aluno e o próprio aluno poderiam definir o que é o mais apropriado para a criança aprender naquele momento, o que irá trazer mais valor para o cliente, no caso a criança.

Como disse o Ricardo Jordão no seu blog, porque raios eu tenho que decorar quem foi Mem de Sá? Está no Google e quando vou precisar disso, quantas vezes você precisou?

É ingenuidade minha, mas nunca havia pensado nas escola como um modelo de fábrica. É claro que tem escolas que tentam ser diferentes, mas achei interessante este paralelo do modelo convencional de escola, com o modelo convencional de software.

Ahh… e leiam o livro, nem é novo…  é muito bom!

Resumo Geral do Falando em Agile

outubro 30, 2008

Pessoal,

No blog http://andrefaria.com, foi colocado um post muito bom sobre tudo o que aconteceu no evento Falando em Agile 2008.

E no blog do pessoal da Sea Tecnologia, que fez uma apresentação bem completa sobre um case de utilização do scrum na Aeronáutica. http://blog.seatecnologia.com.br/

Até mais,

André

O desenvolvimento de software da Voice no Basix

outubro 27, 2008

Neste post falaremos sobre algumas melhorias que implantamos no processo de desenvolvimento aqui no Basix. Nestas melhorias  (Eu, Fontes, Antonio e o pessoal de desenvolvimento) fomos fortemente influenciados pelas metodologias ágeis, em especial o Scrum. Mas, não prentendíamos seguir nada “by the book”, à ferro e fogo. Estamos tentando implementar aos poucos e vendo o que melhor se adequa a nossas necessidades. Vou listar agora alguns pontos que trabalhamos:

Primeiro: era preciso mensurar de alguma forma o trabalho, criar um ritmo.

  • Dividimos o trabalho em iterações de uma semana. O tempo de iteração não foi maior porque teoricamente tínhamos somente duas semanas para desenvolver este release (o prazo era muito curto). Ao início do projeto, o pessoal estimou as tarefas que iriam executar nesta semana.
  • Para que todos visualizassem o progresso, colocamos uma folha A3 impressa na parede, com as tarefas daquela semana. Assim que alguém terminava, riscava ali as tarefas. Preferimos começar assim ao invés do quadro de tarefas com post-it.
  • Definimos o conceito de pronto. Um código do desenvolvedor só estaria pronto depois que fosse testado por ele (mesmo que manual). Este conceito ficou claro para todos os desenvolvedores.
  • Definimos que todo commit deveria ser comentado no SVN e que cada commit só poderia conter alteração referente a uma tarefa. Recomendou-se que baixasse o código do SVN todas as manhãs (mas isto não foi cobrado).
  • Ao começo de cada iteração,

    Imagem da Avaliação de Impacto

    avaliamos como as tarefas previstas iriam afetar o produto. Agrupávamos as tarefas por produto e por nível (classificados de 1 a 5) e gerávamos uma Avaliação de Impacto. Esta avaliação foi útil para informar para todos quais módulos sofreram as alterações mais graves. Isto é muito importante visto que não possuímos testes automatizados para todo o produto.

  • Ao final de uma semana, juntamos a equipe para rever o que ocorreu e planejar a próxima semana. Identificamos o porquê das tarefas não terem sido cumpridas e quais tarefas serão feitas na próxima.

Resultados:

Na segunda iteração a equipe estimou com mais precisão e, principalmente, aprovou o novo método. As padronizações no SVN foram seguidas e elogiadas por todos. Em três iterações, a grande maioria das tarefas estavam entregues.

Porém, diversos aspectos poderiam ter sido melhores: maior integração com a área de qualidade, definir antes o que seria testado, produzir mais testes automatizados e principalmente uma quantidade menor de bugs encontrados pela área de qualidade. Mas acreditamos que estamos no caminho certo, é só continuar trabalhando.

Ao final do trabalho, montamos um “livro” da versão, que continha tudo que aconteceu nas 5 iterações, todos os impedimentos que foram encontrados ao longo do caminho.  Quem quiser é só falar que eu envio.

Próximos Passos

  • Ao planejar a iteração, envolver a equipe de qualidade, definindo como um item será testado.
  • Maior integração com área de qualidade.
  • Automatização de testes.

Próximo Post

Falaremos sobre a reunião de lições aprendidas que realizamos.

Até mais,

André

P.S. : Fontes, Antonio e todo mundo, fiquem à vontade para complementar este artigo.

Falando em Agile 2008 – Impressões

outubro 23, 2008

Pessoal,

Hoje eu e o Joemir fomos ao Falando em Agile, um evento organizado pela Caelum e que tinha por objetivo falar um pouco mais sobre Agile, Scrum, XP e tudo que envolve o mundo de desenvolvimento ágil.

Tivemos diversas palestras, quase todas muito boas(com exceção de uma). Neste primeiro post vou colocar minhas impressões sobre a primeira palestra.

Achieving Success with Agile Management
por David Anderson, participou do projeto onde foi criado o FDD (Feature-Driven Design), trabalha ultimamente no mundo Microsoft e é antigo entusiasta do Agile.

Um time mal gerenciado, mas que entrega os projetos

Um time mal gerenciado, mas que entrega os projetos

Ele fez uma citação bacana, na verdade não era dele, era de alguém que eu não lembro:

“Um gerenciamento ruim pode aumentar os custos do software mais rápido que qualquer outro fator.”

Por isso, a culpa não é só dos programadores e testadores. Mas, para terminar um projeto mal conduzido, é necessário que estes sejam heróis. E em um projeto curto até podemos ser heróis, mas é difícil sustentar o heroísmo no longo prazo.

Antes de contratar a Liga da Justiça, é preciso reduzir a variação no processo e seu fluxo. Garantir que todos façam sempre igual. Não com um processo rígido bem definido no papel, mas passando a filosofia para todos, o que é importante.

Ele passa uma receita para o sucesso, não é uma fórmula imbatível, mas dá um bom direcionamento:

  • Foco na Qualidade: dê permissão para o seu time produzir bug zero. Se um programador ou tester estiver em dúvida entre a forma mais rápida e a de melhor qualidade permita a eles escolher a de melhor qualidade.
  • Reduza o Work in Progress: tenha um conceito bem definido de pronto para cada etapa do processo. Não deixe muitos itens sendo trabalhados ao mesmo tempo. Isto aumenta a complexidade, diminui a qualidade e aumenta a quantidade de defeitos. E quanto mais defeitos, mais Work in Progress.
  • Balanceie a demanda e o que é produzido: Tenha controle sobre o que está sendo produzido, tente achar uma previsibilidade. É preciso achar qual o ritmo de sua equipe. Isto deixará o cliente mais confortável, a equipe e superiores mais confiantes. E não altere este ritmo na primeira ventania que aparecer, tente não saturar a equipe, trabalhar no ritmo.
  • Priorização: Uma boa priorização é fundamental para o sucesso do projeto. Devemos ser capazes de priorizar os itens mais importantes para o cliente. Não precisamos gastar tempo priorizando itens que só serão tratados no futuro. No caso de produto, uma boa priorização seria: primeiro o que é commodity, depois o que reduzirá custo, em seguida features legais que concorrentes tem e por último o que seria diferencial do seu produto.

E depois de fazer tudo isto, Reduza a variação! Treine a equipe, faça tabalho colaborativo, feedback rápido, pair programming, crie padrões de codificação e design, faça retrospectiva e corrija o que deu errado, etc… Vá criando um ambiente colaborativo, com feedback e que “aprenda”.

Nesta palestra ele abordou diversos conceitos que são úteis para qualquer equipe de desenvolvimento, depois vou postando outras coisas que achei legal.

Até mais,

André Pantalião Ferreira

Encontro Ágil 2008

outubro 13, 2008

Neste sábado, dia 11 de outubro, eu e o Joemir fomos ao Encontro Ágil. Este é um evento gratuito sobre desenvolvimento ágil de software. O evento aconteceu no IME-USP, Institudo de Matemática e Estatística da USP. Os professores do IME foram um dos primeiros a abordar o XP e as metodologias ágeis dentro das universidades, criando inclusive uma disciplina dentro do curso de ciência da computação.

O evento foi organizado pela Agilcoop. Criada em 2005, a Agilcoop é uma cooperativa de alunos, ex-alunos e professores do IME. Eles disponibilizam muito conteúdo no site deles (www.agilcoop.org.br). Muito boa a iniciativa deles, produzindo conteúdo que possa ser utilizado por outras pessoas, espalhando o conhecimento sobre as metodologias ágeis.

O conteúdo das palestras foi muito bom e a organização também. Teve até almoço e coffee-break, hehe…
Irei comentar um pouquinho sobre as palestras que assisti.

Planejamento Ágil de Projetos

O Dairton falou sobre como podemos planejar um projeto ágil, quais as características e benefícios deste tipo de planejamento.Palestra muito boa!

Ele mostrou o principal problema do planejamento tradicional que é o fato de planejarmos tudo que iremos fazer em detalhes no início do projeto, justamente o momento que conhecemos menos do que devemos fazer.

Mostrou também algumas causas para falhas nos projetos atuais e como podemos planejar um projeto de forma ágil. Vale a pena dar uma olhada na apresentação dele, foi muito boa!

Debate sobre CMM, RUP X metodologias ágeis

Este debate foi bom e como em todo debate encontramos opções variadas. Resumidamente, minha opinião sobre este assunto é:

CMMi é um selo muito bom para empresas que desejam desenvolver software aqui ou no exterior. Porém, muitas empresas não focam em qualidade, cliente bem atendido e só no procedimento. Aí, o CMMi vira um elefante branco. E o mesmo pode acontecer com as práticas ágeis, principalmente se as pessoas que estão implementando não acham a simplicidade do processo algo importante.

Acho que não podemos dizer que o CMM e RUP não prestam para nada e metodologias ágeis são o futuro, embora eu goste muito mais das metologias ágeis. As metodologias ágeis estão à frente em um quesito, a satisfação do cliente em primeiro lugar.

Seja para RUP, XP, Scrum ou CMM, temos que nos esforçar em produzir métricas que indiquem o quanto de valor e qualidade estamos entregando para o cliente, e não se estamos fazendo certo ou não uma determinada tarefa.

O debate foi polêmico, bem conduzido e muito agradável de assistir.

Dificuldade na implantação de métodos ágeis
O professor Dr. Fabio Kon do IME fez uma apresentação das dificuldades encontradas na apresentação dos métodos ágeis. Ele já trabalha e estuda métodos ágeis desde 2001. Nesta apresentação ele iria apresentar somente problemas e não soluções.

Resumidamente, os problemas encontrados são: Apoio de instâncias superiores, a equipe não quer implementar, iteração com outros departamentos e clientes que não conhecem ou estão adaptados ao uso do XP.

A maior parte das dificuldades não estão relacionada ao código, tecnologia ou metodologia e sim as pessoas. É muito importante se preocupar com elas e como elas enxergam a metodologia que está sendo implantada.

De negativo somente o fato que ele focou muito em XP, polemizando com Scrum e outras técnicas. Acho que não se deve levantar a bandeira que somente o XP é bom, RUP é ruim, Scrum é mais ou menos. Temos que enxergar os benefícios que cada técnica traz.

Bate-papo sobre testes automatizados

O Jorge Diz da Globalcode estava fazendo uma apresentação sobre Desconfiométricas. Ele é um bom palestrante, já havia visto uma palestra dele no OpenTDC. Algo muito importante em sua palestra é o que ele diz que mais do que focar em métricas, temos que entender qual a dinâmica do processo, para saber realmente quais informações devem ser medidas.

Depois iniciou-se um debate sobre testes e testes automatizados. Foi um debate morno em que era possível ver que todos possuem problemas em criar e principalmente manter os testes automatizados. E de acordo com o perfil e a posição que defendiam, era possível ver aqueles que eram testers e os desenvolvedores (hehe).

Não ficamos para a última palestra, mas o evento foi muito bom e podemos ver que muitas pessoas estão interessadas e estudando o assunto.

Até mais,

André