07 set 09 O Design de Software está morto?
Martin Fowler, famoso por, entre outros, ser o autor de livros como “Refactoring: Improving the Design of Existing Code”, “Patterns of Enterprise Application Architecture” e “UML Distilled”, escreveu um artigo intitulado “Is Design Dead?”, que foi muito bem traduzido para o português pela equipe do InfoQ.
No texto, Fowler fala sobre o mito de que metodologias ágeis de software, especialmente o XP, vêm abolindo a prática de projetar o software.
O autor começa descrevendo os dois principais tipos de design, o planejado e o evolucionário, este último adotado por XP. Sabemos que existem problemas com os dois casos: o planejado sofre com as mudanças (principalmente de requisitos), e o evolucionário com o “codifica-e-corrige”. O Extreme Programming determina uma série de práticas que podem resolver tais problemas. Fowler então descreve o jeito particular de XP tratar o design.
Confira o artigo na íntegra, em português ou inglês. Recomendo fortemente.
13 ago 09 Hummm… Já vi isso em algum lugar!
Algo familiar? Ou será que o chefe do Dilbert é o único que acha que o ponto determinante no sucesso do desenvolvimento é a metodologia ou framework utilizado?
Infelizmente não. No mundo real ainda há muitas pessoas com tal mentalidade e, pior, muitas também com poder de decisão. No final, quando tudo vai por água abaixo, a culpa é da pobre metodologia…
Tags: Desenvolvimento Ágil, Dilbert
10 ago 09 O declínio dos métodos ágeis
Outro dia lendo o blog do James Shore (ele de novo!), me deparei com um artigo intitulado “The Decline and Fall of Agile“. Isso me chamou muito a atenção, uma vez que o autor é, declarado, um agilista. Após concluir a leitura, concordei com vários dos argumentos postos. Eis o que considero de principal:
Scrum mal aplicado
Não é culpa do Scrum. Desenvolvimento ágil não trata apenas de boas práticas de engenharia. É também sobre o reconhecimento da importância das pessoas no processo de desenvolvimento, formando equipes multidisciplinares, com comunicação em larga escala, constantemente refletindo e melhorando, entregando valor, e mudando planos para melhor aproveitar as oportunidades.
E Scrum inclui todos esses pontos. Diz, por exemplo, para colocar a equipe em um ambiente de trabalho compartilhado. Diz que no final de cada Sprint um produto de valor deve estar pronto para ser entregue, e diz também que a equipe deve se auto-organizar, descobrir impedimentos e removê-los.
Scrum também tem algumas poucas coisas mecânicas a respeito de Sprints mensais e Scrum diário. Coisas triviais comparadas com todo o resto. Mas, infelizmente, é essa a única parte que muitas pessoas adotam. Ciclos rápidos, mas nada daquelas boas práticas que fazem o ciclo rápido ser sustentável.Você está fazendo errado
Neste momento, há muitas equipes falhando com o desenvolvimento ágil. Esses times estão trabalhando em ciclos pequenos. A crescente freqüência de planejamento deu-lhes um maior controle sobre seu trabalho e eles estão descobrindo e consertando alguns problemas. Eles se sentem bem, e eles realmente parecem mais bem sucedidos do que eram antes.
Mas eles não estão trabalhando em ambientes de trabalho compartilhados, nem enfatizando a necessidade de comunicação de larga escala. Eles não mantêm os clientes por perto do local de trabalho. Eles nem mesmo terminam todas as suas Estórias até o final de cada Sprint, e certamente não utilizam boas práticas de engenharia.
Esses times se dizem ágeis, mas eles estão apenas praticando um tipo de “planejamento freqüente”. Ciclos curtos e capacidade de re-planejar são apenas os benefícios que o desenvolvimento ágil lhe dá. É a recompensa, não o método. Essas equipes pseudo-ágeis estão comendo a sobremesa toda noite e pulando o prato principal, os vegetais. Deixando de lado todo o resto (o ‘resto’ realmente ágil), elas estão bem encaminhadas para “dentes cheios de cáries”, “obesidade” e, conseqüentemente, estão fadados a falhar. No começo se sentem bem, mas isso não dura por muito tempo.
Resumindo, pare e pense: você está querendo pular o arroz-com-feijão, os brócolis e a salada, para ir direto a sobremesa? Se sim, você está, como muitos, deturpando os valores defendidos no manifesto ágil, e está no caminho errado.
Metodologias ágeis são tão boas quanto as pessoas que as usam!
Tags: Desenvolvimento Ágil, Scrum
08 ago 09 O “mito” da documentação
Ultimamente tenho lido muito respeito de desenvolvimento ágil, principalmente no que diz respeito a Scrum. Navegando por aí, caí no blog de James Shore, co-autor do livro “The Art of Agile Development“, da editora O’Reilly. Vasculhando o blog, vi um artigo chamado “The Documentation Myth”, que pode ser lido
na íntegra (e em inglês) clicando neste link. Vale ressaltar que, assim como grande parte das pessoas que postaram comentários no referido blog, eu concordo/discordo de partes do texto, e cabe a cada um fazer sua avaliação pessoal. Mas achei bastante interessante e aqui sintetizo, em português, a idéia do mesmo:
O mito da documentação
Um dos grandes mitos do desenvolvimento ágil é que equipes ágeis não documentam seu trabalho. Realmente, equipes ágeis preferem conversas cara-a-cara do que comunicação através de documentos, e preferem escrever documentação para manutenção, no final do projeto, do que no começo (significando menos retrabalho e garantido conteúdo atualizado).
Junto com as acusações de más práticas de documentação, há um outro mito: “Documentação é uma coisa boa”.
Pessoas pensam “estou tendo problemas para entender isto!” e, depois de quebrar a cabeça, amaldiçoam o desenvolvedor pela sua falta de visão de documentação.
Muitos programadores escrevem linhas e mais linhas de comentários, antes de realmente começar a implementar. Mas isso não significa que a implementação que vem a seguir é de qualidade! O bom, desta forma, não vem automaticamente (e necessariamente) da prévia documentação. Isto é um mito!
Então o que é realmente bom? O que é que estamos procurando quando vamos atrás da documentação? A resposta é: Respostas.
Se você mudar sua forma de pensar, procurando as respostas, e não apenas documentação em si, você irá mudar inteiramente sua perspectiva. Documentação então é um meio para um fim, e não um fim em si própria.
A realidade é: queremos respostas, elas sim nos ajudam. E o quanto mais rápido as temos, melhor é.
O melhor caso é quando, as vezes o próprio código fonte, bem escrito e com partes bem nomeadas, não precisa nem de comentários, é intuitivamente óbvio. XP prega isso, e realmente não é uma coisa fácil de atingir, mas é o que se deve tentar.
O segundo melhor caso é quando é possível perguntar a alguém e obter logo a resposta. É o caso de equipes ágeis, onde se recomenda ter equipes com seus membros distribuídos através de várias funções. Os ganhos de produtividade por causa da comunicação são incríveis.
Ainda, continua sendo bom ser possível ir ao Google e procurar pela respostas. Algumas vezes vou ao Google e digito minha mensagem de erro. Descubro que 500 pessoas tiveram o mesmo erro, e proveram soluções. Fantástico.
Por último da lista de como/onde obter resposta, está a atividade de ler documentação atrás da mesma. è claro que algumas vezes a documentação é divinamente organizada, maravilhosamente escrita, e prazerosa de ler. Sim. Mas muitas vezes não. E quanto mais documentação você tiver que ler para obter sua resposta, pior. Ter muita documentação não é bom. A única coisa boa sobre ter toneladas de documentação é o jeito como isso soa.
Então, da próxima vez que você ouvir alguém reclamando sobre a falta de comentários ou de documentação, pare-o por um momento. Do quê realmente ele está reclamando? O código não está claro? A biblioteca tem uma organização pobre? Talvez corrigir isso primeiro fosse a melhor solução. Ou, talvez, nada está errado, e esta pessoa está sucumbindo ao mito da documentação.
Tags: Desenvolvimento Ágil, Scrum
16 abr 09 Engenharia de Software para quê?
Para não evitar esse tipo de situação, talvez?
Tags: Dilbert, Engenharia de Software, Qualidade de Software
17 out 08 SWEBOK
Para começar falando da área de Engenharia de Software, eis uma boa dica de leitura, o SWEBOK.
Definição Wikipedia: O Guide to the Software Engineering Body of Knowledge, conhecido pela sigla SWEBOK, é um documento criado sob o patrocínio da IEEE com a finalidade de servir de referência em assuntos considerados, de forma generalizada pela comunidade, como pertinentes a área de Engenharia de Software. O SWEBOK apresenta uma classificação hierárquica dos tópicos tratados pela Engenharia de Software, onde o nível mais alto são as Áreas do Conhecimento.
Os objetivos gerais do guia são promover uma visão consistente da engenharia de software no mundo, clarear e marcar as fronteiras entre a engenharia de software e as outras disciplinas relacionadas, caracterizar o conteúdo da disciplina de engenharia de software e classificar em tópicos a área de conhecimento da engenharia de software. É claro que essa classificação em tópicos é arbitrária, podendo não ser considerada ideal por outros pesquisadores e profissionais.
É possível baixar o PDF do guia ou encontrar uma versão HTML no site http://www.swebok.org/. Pessoalmente, pelo que estudei a respeito, achei um ótimo guia, e fica aqui dica.
Tags: Engenharia de Software, Guias
