Posts Marcados Web
Desenvolvimento Ágil e Processos
Publicado por Alexandre Valente em Desenvolvimento em 20/09/2009
Esta semana tive a oportunidade de conversar com vários clientes sobre o desenvolvimento ágil e a quantidade de controles e processos que devemos utilizar para suportá-lo. No meu caso, a virada de 180 graus de um desenvolvimento waterfall clássico (com especificação, aprovação e execução) para um desenvolvimento ágil teve como conseqüência inicial a abolição completa de controles e processos – até porque os controles e processos waterfall não se aplicam a um desenvolvimento ágil.
Porém, esta abolição completa está começando a gerar efeito colateral negativo, em dois aspectos: rastreabilidade de decisões e controle de faturamento. A deficiência nestes dois aspectos me foi apontada por clientes e vem sido também sentida internamente pela equipe de desenvolvimento.
A questão da rastreabilidade significa entender, às vezes muito tempo depois da implantação, porque uma determinada funcionalidade foi implementada de uma certa maneira ou porque determinada decisão de negócio (ou de arquitetura) foi feita em detrimento de outras. E, em um desenvolvimento ágil, isto comumente se perde já que os itens de backlog vão sendo implantados e código produzido, ainda que bem comentado, não é suficiente para se manter a visão destas características. Embora as práticas ágeis não sejam contra a documentação (muito ao contrário), fica a questão do quanto e como se documentar. Uma documentação que não seja realmente útil significa gastar horas que poderiam estar melhorando o ROI gerando novas funcionalidades.
A questão do faturamento do trabalho produzido por uma equipe ágil também é um ponto problemático.Mesmo assumindo que o cliente já tenha comprado a idéia de usar uma metodologia ágil, ainda assim ele vai querer uma contabilização do que foi gasto e aonde. E embora o product manager e o cliente específico da funcionalidade tenham uma comunicação extensiva, muitas vezes existem outras pessoas para as quais é importante prestar conta das atividades realizadas. Ainda que a produtividade seja alta, algumas vezes é difícil se ter uma visão do trabalho gerado em cada interação, especialmente em longos períodos de tempo.
Desta forma, nestes dois aspectos, é necessário se definir artefatos e processos mínimos que sejam capazes de gerar e armazenar estas informações. No nosso caso, o que temos feito é tentar automatizar estes processos através de sistema interno específico, para minimizar o tempo despendido na geração destes artefatos e para padronizar as informações produzidas. Assim, para a gestão do backlog, controle das atividades realizadas em cada iteração e armazenamento de notas referentes às tarefas realizadas, estamos desenvolvendo um produto web específico que denominamos Iterator. Nele, teremos a gestão do backlog, a definição das iterações com as específicas tarefas, um amplo suporte a notas, descrições e arquivos anexados a cada tarefa e uma visibilidade por perfil. Ele possui também um módulo windows que é utilizado pelos desenvolvedores para apontar, de maneira simples, rápida e minimamente intrusiva, as atividades em que atuou, permitindo a visibilidade pelos membros da equipe e stakeholders do projeto.
Alguns podem achar que desenvolver um sistema internamente para isto é um overkill, já que existem alguns produtos voltados à gestão e controle do desenvolvimento ágil. Porém, os melhores que analisamos ou são caros (outro conceito relativo, mas caros no nosso cenário) ou são voltados exclusivamente para a gestão de backlog (sem o lado de faturamento) ou simplesmente são muito complexos para se adotar, gerando custo excessivo de treinamento e adaptação. Desta forma, acredito que o custo de desenvolvimento do Iterator (que com o framework, não é tão alto assim), acaba sendo compensado por estes fatores. Finalmente, existe o objetivo de transformá-lo em um produto, o que traz outras compensações.
Se alguém possuir necessidades similares ou que use um produto que não atenda completamente e quiser influenciar no desenvolvimento, basta entrar em contato. Conforme formos evoluindo e quando tivermos algo disponível publicamente, eu notifico a todos por aqui. Até a próxima.
Produtividade – Conclusão
Publicado por Alexandre Valente em Desenvolvimento em 11/09/2009
Oi pessoal, este é um último post da série sobre produtividade. Nos anteriores, eu descrevi a infra-estrutura de desenvolvimento que é usada pela minha equipe atualmente. Toda esta infra-estrutura nada mais é do que uma ferramenta utilizada por nós para se realizar a construção de sofware. Nossos clientes, na grande maioria dos casos, não se preocupam se o software é feito em C# ou em Clipper, ele quer saber se o que ele precisa é barato pra fazer e manter e se é simples e fácil de usar.
Assim, eu vejo esta infra-estrutura toda muito com esta visão pragmáticas, de ser algo que deve permite entregar ou modificar rapidamente uma funcionalidade de negócio, sendo produtivo na hora de atender uma necessidade. Isto faz a diferença para mantermos o nosso cliente satisfeito, com retorno que ele julgue satisfatório para o que ele gasta para se construir software.
Neste sentido, estou bastante satisfeito com a nossa infra-estrutura. Ela é rápida para se iniciar algo do zero, muito rápida para se fazer coisas triviais (como CRUDs) e tão ou menos complexa que outras alternativas para se fazer coisas complicadas. Acho que isto o máximo que podemos esperar de qualquer framework. O meu pragmatismo é aplicado todo o tempo e qualquer alteração no framework (que é sempre caro pra fazer) se justifica somente se ela vai trazer mais produtividade em algum aspecto. Usando o framework atual, estamos conseguindo colocar no ar uma aplicação nova, com controle de acesso (vou detalhar mais isto em posts futuros), estrutura básica e layouts iniciais em poucas horas. Fazer um CRUD de uma entidade leva menos de 15 minutos, considerando do tempo de criação da tabela ao final da tela!
Claro que a produtividade final não depende somente da infra-estrutura. Na minha experiência, 90% do tempo de construção (ou manutenção) de qualquer aplicativo grande fica restrito a umas poucas telas de maior complexidade. Assim, é importante saber trabalhar com o cliente no sentido de minimizar a existência deste tipo de interface. Neste sentido, acho que fazer software não é só entender a necessidade de negócio, é também saber o que é simples ou não de fazer e propor soluções funcionais que sejam mais fáceis de desenvolver. Desta forma, a maneira como se desenvolve acaba também influenciando a necessidade, em uma via de duas mãos. Daí a importância de quem está entendendo a necessidade conhecer muito bem como aquilo vai ser feito, sob pena de se orçar muito mal ou se gastar muito para fazer, com prejuízos para o cliente ou para a própria empresa que desenvolve. Este é um conceito que parece que muitas “analistas” não compreendem, e a causa da falha ou prejuízo de muitos projetos.
Ainda tenho muitas melhorias a serem feitas neste framework. Ainda existem tipos de telas que podem ser melhor suportados, novas funcionalidades que podem ser integradas e alguns serviços que estão sendo refatorados a todo tempo. Porém acho que ele já está maduro o suficiente pra ser empregado em qualquer sistema. Existem áreas para as quais eu ainda não tenho uma solução boa. A geração de relatórios é uma delas. Gerar relatórios na web em geral é algo complexo, pois é difícil montar os layouts e nós sempre encontramos com uma série de limitações de desempenho e banda causadas pelo volume transitado. Não gosto de nenhuma das alternativas existentes atualmente e ainda estou buscando uma que me permita fazer gerar uma DSL e que tenha um comportamento preditível. Informo aqui quando encontrar!
Espero ter contribuído para quem teve a paciência de ler até aqui. Como citei no início, esta infra-estrutura é um exemplo que é difícil de ser replicado para outras equipes ou de suportar uma escalabilidade maior, já que ele exige um treinamento e conhecimentos muito específicos. Mas acredito que os princípios sejam gerais, e possam ser aplicados a outros cenários. Nos próximos meses eu vou adicionar adendos a esta série toda vez que houver uma evolução ou fato novo referente ao framework ou relativo à produtividade em si. Até a próxima.
Response.Flush()
Publicado por Alexandre Valente em Uncategorized em 27/07/2009
Nestes últimos 2 dias eu perdi um tempo impressionante com algo que em tese deveria ter sido extremamente simples de fazer, tipo 5 minutos… A idéia era fazer um página que iria rodar uma operação longa ir mostrando o andamento da operação, algo como “Passo 1 executado”, “Passo 2 executado” e assim por diante…
Como a regra de negócio estava pronta, achei que fosse trivial ir gerando as tags <p> e ir mostrando o andamento com flushs… Não poderia estar mais errado! Inicialmente tentei usar o HtmlWriter do Render pra ir fazendo os Writes intercalados com os Response.Flush() (fiz um teste com Sleep() pra simular o processamento). Mas não funcionou, ele mostrava a página só no final, com todos os passos de uma vez.
Aí comecei o processo conhecido de buscar no google alguma dica ou esperiência pra entender o que estava errado. Nem precisa falar que o help da MSDN era inútil, aliás copiei e colei o exemplo deles e mesmo comportamento. Comecei a ver que este é um problema para muitas pessoas, aparentemente em algumas situações o Response.Flush() simplesmente não funciona e um mesmo código que funciona para um (como o exemplo da MSDN) não funciona pra outros.
Claro que deve ter algo na página ou no ambiente que faz com que este probelma apareça. Gastei umas boas 4 horas tentando eliminar o que era, utilizando as dicas que achei de pessoas no google para tentar mapear o que era. Mas a questão é que parecia que vários tipos de problemas acabavam se sobrepondo, o principal sendo um próprio entendimento do que o Flush() deveria fazer. Na minha visão (e na visão de várias pessoas que eu vi), ele deveria simplesmente fazer com que o conteúdo gerado até ali fosse para o browser. Mas até sobre isto haviam dúvidas. E aí vinham várias receitas, pra ligar ou desligar buffer, pra fazer com código <% %> intercalado na página ou em determinado evendo em code-behind e até para fazer várias vezes em sequência o comando Flush() para que ele funcionasse! Nenhuma alternativa funcionou pra mim, fui dormir para tentar de novo no dia seguinte.
No dia seguinte, mais 2h. O tempo gasto nisto já estava absurdo e poderia até ter feito com javascript simples, mas vocês sabem, vira questão de honra! Continuando as busca no google, achei um comentário dizendo que uma instrução específica, faria toda a diferença: Response.BufferOutput = false. E neste cenário, realmente funcionou, mas somente no código aspx direto! Já que neste caso estava funcionando, comecei a tentar isolar o que realmente causava o probelma. Mas não tive sucesso, qualquer pequena alteração fazia com que o código deixasse de funcionar. Desisti, o código final ficou desta forma:
—————————————————————————————————————–
Enfim, é impressionante como perdemos tempo com coisas triviais. Esta do Response.Flush é mais um exemplo. Fazer software é muito bom, mas este tipo de coisa não é muito!