Posts Marcados Scrum
Como eu Desenvolvo Software – Parte 1
Publicado por Alexandre Valente em Desenvolvimento em 25/07/2010
Olá pessoal. Acabei ficando um longo tempo sem escrever, tenho estado anormalmente ocupado nestes últimos meses. Junho foi um mês muito complicado, com as paradas para a Copa do Mundo e a presença no Agile Brazil – isto sem falar em alguns projetos críticos sendo entregues e o tempo dedicado a novos projetos. Com isto, na White Fox, passamos o mês bem sobrecarregados e só agora em Julho é que começamos a voltar ao ritmo normal. Finalmente agora volto a ter um pouco de tempo para escrever alguns artigos!
O evento Agile Brazil foi muito bom. Contou com a presença de grandes nomes do desenvolvimento mundial, como o Martin Fowler e o Philippe Kruchten. E foi excelente pra fazer contato com o pessoal da comunidade .NET do Brasil. Mas este post é sobre algo que conversei bastante com outras pessoas lá e que gera sempre discussões “acaloradas” toda vez que é levantado em uma roda de desnvolvedores (ou em listas de desenvolvedores como a excelente dotnetarchitects): qual o melhor “jeito” de desenvolver software.
Com a aceitação cada vez maior das metodologias ágeis, a minha impressão era que a comunidade estaria mais tranquila sobre metodologias e técnicas para desenvolvimento. Elas sempre evoluem, claro, mas pelo menos em linha gerais, estaríamos em um caminho mais definido. Mas o que eu vejo é que ocorreu algo diferente, uma profusão de metodologias e técnicas e de pessoas que pregam que determinada linha é muito melhor do que qualquer outra. Acho que isto piorou ainda mais porque o modelo “waterfall”, hoje praticamente execrado pela maior parte dos desenvolvedores “modernos”, foi pintando como o maior vilão e origem de todos os males e que a metologia XXX ou YYY chegou para resolver isto!
Longe de mim defenter o uso de waterfall, na maior parte dos cenários. Mas, apesar de todos os problemas e falhas deste tipo de desenvolvimento, o fato é que até hoje temos muitos e muitos exemplos de sucesso, e que continuam a acontecer ainda hoje. A palestra do Kruchetn foi muito boa neste aspecto, ele citou justamente esta “demonização” do waterfall como um sinal de que nem tudo está bem.
E para quem está começando, eu tenho notado, em geral, uma total confusão. Como as universidades estão alguns ciclos atrás (a maior parte delas ainda prega o waterfall como única e melhor maneira de desenvolver) e sem ter a experiência de ter passado por sucesso e falhas em determinada metologias, os iniciantes ficam sem saber que caminho seguir: Waterfall? nem pensar! Scrum? Como viver com todos os scrum-buts? XP? Como aplicar no meu dia a dia? Isto sem falar nas múltiplas variantes técnicas da construção em si, onde entra TDD, BDD, DDD etc., aliada a uma miríade de plataformas, frameworks, ORMs etc. E sem nem entrar no mérito de linguagens em si, onde temos novamente uma outra gama de escolhas como C#, C++, Java, Rubi, Python etc. E em todos estes, temos muitos “gurus” que afirmam que aquilo é o supra-sumo da agilidade e é a melhor invenção do mundo deste a pólvora, sendo a única maneira de fazer software bem. Realmente é difícil não ficar confuso. Felizmente temos algumas vozes de bom senso, como o Alistair Cockburn, no seu “Juramento de Não-Lealdade”, que talvez comecem a melhorar este cenário.
Na minha visão, escolher uma forma de desenvolver não deveria causar tanta dificuldade. É certo, desenvolver software é algo complicado, exige um misto de dedicação, talento, experiência e muito, muito estudo. Mas, em toda a minha experiência, o que eu tenho visto é que as pessoas que se eforçam para se tornar bons codificadores acabam o sendo de uma maneira geral. Ou seja, um bom programador em C# vai ser um bom programador em Python (claro que uma transição não é simples, pelo volume de novas informações, mas se isto for desejado ou necessário, vai acontecer). Ou seja, os princípios básicos, o cuidado e o gosto pelo que se faz, são fatores mais importantes no sucesso do que qualquer linguagem metodologia, tecnologia ou plataforma que exista. E pra mim, isto vai continuar sendo assim mesmo com o todo o nosso ritmo de evolução… (acho que só vai parar o dia que pudermos solicitar um programa verbalmente e o próprio computador o gerar… ou seja, daqui a muito tempo!). Óbvio também que nada existe sem contexto, isto é especialmente válido para desenvolvimento de software. Assim, levando em consideração o contexto, algumas escolhas podem levar a uma maior produtividade do que outras.
Para tentar ajudar nestes dilemas, resolvi escrever este e mais um artigo sobre desenvolvimento, e como eu o vejo. Vou colocar alguns princípios que adoto, na medida do possível, de onde eles vieram, e como eu vejo a inserção de toda esta parafernália metodológica/técnica no meu processo de desenvolvimento. Meu objetivo é tentar defender a idéia mais importante dos princípios ágeis, de que pessoas são mais importantes do que qualquer processo, metodologia ou ferramenta, e que os principios básicos ainda são comuns a qualquer atividade de desenvolvimento. Vou também colocar um pouco do meu contexto, para justificar algumas escolhas que faço e como isto afeta a nossa produtividade.
Até a próxima!
Manutenção de Sistemas
Publicado por Alexandre Valente em Desenvolvimento em 01/06/2010
Hoje passei grande parte do dia conversando com clientes e parceiros sobre o processo de desenvolvimento em sistemas onde a maior parte do código é legado. Feliz ou infelizmente este é o caso da White Fox, onde o maior volume de esforço é feito em sistemas que já possuem muitos (alguns mais de 10) anos de existência (vieram por herança da empresa de onde a White Fox foi spin-off). Se por um lado isto demonstra um certo grau de satisfação do cliente por ter mantido o desenvolvimento conosco este tempo todo; por outro significa uma maior complexidade para manter e evoluir o sistemas.
Um ponto interessante que muitas pessoas parecem não compreender é que um sistema “envelhece”. Um argumento comum é “se funcionou até hoje, porque iria parar de funcionar?”. O que este argumento não leva em consideração é que todo sistema tem partes mutáveis. Sejam os dados que mudam de forma ou de volume, seja a plataforma que tem que ser evoluída por obsolescência de hardware ou software. E quanto menos se mexe, mais este processo é visível; tivemos um caso recente em que vulnerabilidades no IIS 6.0 fizeram-nos mudar para o IIS 7.0, porém componentes feitos para rodar no IIS antigo não funcionavam mais no novo e para completar, o fabricante do componente nem existia mais, o que impedia o seu simples upgrade. Acho que a comparação é como a da manutenção de um carro: é possível rodar sem manutenção até um ponto onde componentes começam a parar ou apresentar defeito…. Mas quanto mais se demora para se fazer as manutenções iniciais, mais caro vai ser quando elas se tornarem inevitáveis.
Outro ponto interessante comumente visto é a concepção errônea de que um modelo waterfall seria menos propenso a erros em um processo de manutenção. Definitivamente não é verdade, o que um modelo waterfall normalmente define é um tempo alocado explicitamente para planejamento de migração de legado, testes e garantia. Porém, isto acontece a um custo bem mais elevado do que em uma metodologia ágil. Em uma metodologia ágil também seria possível planejar e gerar testes caso isto traga valor para o cliente. A único questão é quantificar este valor para que a relação custo/benefício faça sentido e estas tarefas sejam adequadamente priorizadas, de forma tão ou mais importante do que as novas funcionalidades.
E interessante que a maior parte da literatura para o desenvolvimento de software trate de novos projetos, existindo pouca coisa específica para o processo de manutenção. Metodologias como o Scrum nem sequer se aplicam a processos de manutenção. Isto me deixa intrigado pois, a meu ver, a maior parte do esforço mundial de desenvolvimento deveria ser em manutenção; não faz sentido nem é sempre economicamente viável reescrever um sistema do zero a cada grande mudança. E nas metodologias ágeis há um dilema já logo no início, pois todas pregam a preparação de um sprint com aquelas tarefas que geram maior valor para o cliente. Ora, evoluir algo que já funciona dificilmente vai ter mais valor para o cliente do que qualquer nova funcionalidade, por menor que seja. Assim, evoluções acabam sempre ficando para segundo plano até o ponto onde acontece um problema grave com uma funcionalidade antiga e aí é um deus-nos-acuda para portar a mesma à toque de caixa ou achar um guru que ainda consiga mexer no legado de uma forma relativamente segura.
Há algum tempo atrás escrevi um post sobre a necessidade de refatoração de grandes sistemas. Hoje vou mais adiante, acho que além da refatoração, é necessário um esforço constante de migração e evolução dos sistemas e componentes legado. Isto deve ser feito enquanto o conhecimento de negócio e técnico ainda está disponível na empresa, para que o custo de atualização fique em um patamar viável. Neste aspecto, a existência de testes unitários e de integração são de grande valia, pois o tempo gasto na geração deste tipo de artefato acaba também se pagando na hora de uma eventual atividade de evolução. Toda a questão é como vender este tipo de atividade para um cliente. O que temos feito recentemente é tentar definir um percentual fixo das horas de desenvolvimento exclusivamente para serem gastas na evolução de partes antigas do sistema. Claro que estas tarefas também estão sujeitas a uma priorização entre si, usando como critério as funcionalidades que são mais críticas para o negócio do cliente e o grau de obsolescência das mesmas.
Outro ponto crítico na questão da manutenção é o procedimento de deploy. Em um sistema novo, fazer deploy é sempre algo trivial (acabamos de encerrar um sistema, por exemplo, onde o deploy é uma simples cópia de arquivos e uma pequena configuração do IIS; daqui a 3 anos duvido que este processo seja tão simples se a aplicação não for evoluída). E o esforço para se manter atualizado uma documentação de deploy para cada Service Pack ou alteração de infra-estrutura não é trivial e convencer o cliente de que isto é algo prioritário e que deve ser feito durante algum sprint é também algo extremamente complicado. De novo o grande motivador é a ocorrência de um erro mais grave, porém aí tudo já vai ser feito sob uma considerável quantidade de stress.
Ainda não sei qual é a melhor maneira de lidar com estas situações. Na White Fox estamos trabalhando com alguns clientes no sentido mitigar estes problemas e trabalhar ativamente na migração de legado. Os sistemas são tão grandes, no entanto, que é necessário um bom trabalho de priorização e um critério rígido de limites para que este esforço não consuma todo o previsto de uma deterimada sprint. Estamos tendo sucesso em alguns casos, porém ainda temos muito a melhorar e acredito também que algumas ferramentas poderiam ser de grande valia na avaliação dos resultados de determinada linha de ação.
White Fox: O Início
Publicado por Alexandre Valente em Desenvolvimento em 25/05/2010
Após a definição do conceito do que buscava nesta minha nova empreitada, a White Fox está finalmente pronta e iniciou suas operações oficialmente este mês! É sempre algo muito especial participar da construção de uma empresa nova; mais especial ainda quando é uma empresa que representa um ideal buscado por muito tempo. Claro que iniciar uma empresa é sempre muito trabalho, muitos trâmites burocráticos, investimentos, implantação de toda a parte de infra-estrutura (ambiente, rede, telefonia etc.) e planejamento financeiro, tudo isto simultaneamente às atividades cotidianas e com uma equipe mínima! Muito cansativo, mas está valendo muito!
Estamos conseguindo começar com um time pequeno, mas totalmente alinhado ao conceito do que queremos para a empresa. Estamos também definindo os contratos de prestação de serviço com os clientes existentes para adaptá-los 100% a um formato ágil. Há uma grande necessidade de negociação, pois, por maior que seja a maturidade deles, sempre é complicado definir um contrato baseado neste tipo de desenvolvimento. Estamos tendo sucesso até agora e acredito que esta experiência vai tornar mais fácil a negociação com novos clientes.
Apesar de contarmos com uma grande vantagem inicial, que é a existência de clientes ativos, a White Fox vai agora encarar desafios bem importantes para se manter e crescer. Na minha visão, os problemas mais difíceis são a definição do processo de prospecção/venda mantendo o resultado, a gestão do crescimento e a definição de um processo interno de desenvolvimento. A questão da prospecção/venda é a mais difícil de ser equacionada. Prospectar significa ter tempo livre, fazer concessões a potenciais clientes (consultorias, análises, demonstrações) para que seja possível mostrar o nosso serviço e permitir que eventualmente seja fechado um contrato de desenvolvimento. Porém, este processo é caro já que o tempo investido é um tempo que deixa de ser aplicado no atendimento de clientes existentes e que, portanto, deixa de gerar receita. E um modelo agile prevê uma confiança enorme da contratante na contratada, o que faz com que muitas prospecções, para funcionar, exijam um grande investimento. Desta forma, prospectar pode significar comprometer grande parte, senão todo, o resultado obtido nos projetos em andamento para tentar trazer clientes novos. Assim, isto é algo que tem que ser pesado com muito cuidado e o que estamos fazendo é praticamente “escolhendo a dedo” os potenciais clientes que achamos que vale a pena prospectar. O lado negativo é que o crescimento é extremamente lento.
A gestão do crescimento é outro grande desafio. Encontrar profissionais prontos com o nível que necessitamos na White Fox é uma tarefa quase impossível. Encontrar pessoal com potencial é bem mais simples, porém treinar alguém com potencial até que esteja no ponto necessário é algo demorado e caro. E escolher o momento de incluir alguém também é algo que exige grande cuidado, já que para prospectar é necessário ter algum tempo livre de pessoas excelentes; no entanto a prospecção é lenta e o treinamento também, assim estes custos podem comprometer completamente o resultado de um período. Estamos tentando balancear isto com um programa de estágio para tentar identificar pessoas com grande potencial e ter um tempo de treinamento mais longo e com isto conseguir um tempo maior para prospecção.
O outro desafio que eu vejo é com relação à gestão interna do processo de desenvolvimento. Nós. por princípio temos uma equipe muito pequena, mas ainda assim é necessário um fluxo de trabalho que garanta o andamento das atividades básicas. Além disto, todos os clientes exigem algum tipo de contabilidade para a gestão de custos, o que significa que tudo o que fazemos deve ser de alguma maneira registrado e totalizado para efeito de faturamento. E como quase todos os nossos projetos são muito antigos, temos que funcionar bem com a manutenção e evolução de sistemas legados de qualidade variada. O que temos feito é dedicar um tempo na busca e definição de metodologia e ferramentas para nos apoiar nesta gestão. Gostamos muito do Scrum mas ele não é aplicável a projetos de manutenção. Da mesma forma, a maior parte das ferramentas de gestão de processos ágeis existentes deixa muito a desejar nesta parte de manutenção e contabilização. Estamos avaliando várias e considerando também a possibilidade de desenvolvimento de uma nossa, simples, mas quer iria atender por completo as nossas necessidades. Acredito que nas próximas semanas nós iremos chegar a uma definição.
No mais, muito trabalho, mas com uma equipe muito motivada. Estamos adotando uma postura minimalista com relação à parte administrativa e financeira; terceirizando quase tudo e adotando práticas que simplifiquem isto ao máximo. O mesmo vale para a parte de infra-estrutura, estamos utilizando quase tudo na Cloud; a única exceção é o source-control, que ainda assim fica em um espaço contratado de um datacenter. Conforme fomos evoluindo vou postando aqui as soluções e caminhos que adotamos. Até a próxima!
Refatorando Grandes Sistemas
Publicado por Alexandre Valente em Desenvolvimento em 03/01/2010
Olá, feliz 2010! Eu estou muito animado, as perspectivas para 2010 são muito boas! Fiquei agradavelmente surpreso com a reação das pessoas à White Fox, ela foi muito bem recebida e recebi várias mensagens de apoio, obrigado! Estou muito convicto de estar no caminho certo e construindo uma empresa que será um local excepcional para se trabalhar e prosperar. E o ano começa animado, este mês estamos entregando 2 primeiras versões de novos sistemas além de continuarmos com a manutenção dos existentes.
Conversando com um amigo na semana passada, caímos no assunto de grandes sistemas e do processo necessário à manutenção (evolutiva ou corretiva) para sistemas de grande porte em geral. O que me levou a refletir sobre isto pois, apesar de achar que processos e especialização por segmentos (silos) no desenvolvimento de software seja algo nocivo, não consegui achar nada de errado ou que eu faria diferente naquele caso específico.
O ponto é que grandes sistemas necessariamente exigem uma grande infra-estrutura. Por menor que seja uma mudança, para se garantir que um sistema não seja afetado por ela, é necessário avaliar todo o impacto, preparar uma sequência de testes específicos para a mudança e executar todo o conjunto de testes de integração e funcionais – muitos dos quais, até pelo volume, podem não ser totalmente automatizados. Isto sem falar no processo de liberação de versão em si, que envolve muitas vezes compilações e execuções de testes unitários que podem demorar várias horas. Em um time agile, mesmo com o máximo de automatização, este processo todo iria significar que o time iria passar a menor parte do tempo implementando a mudança e a maior parte do tempo, planejando, testando, integrando e verificando se tudo ficou ok. Não é algo viável, na minha visão. Acho que é por isto que o pessoal de Scrum afirma que Scrum é para novos projetos somente, não sendo adequado para manutenções.
Então o que fazer? Será que para grandes sistemas não é possível usar métodos ágeis? Ou que temos que assumir que para grandes sistemas, irão existir silos (testes e/ou gestão de configuração, por exemplo) e que isto é algo que não tem solução? Os que me conhecem sabem que esta resposta não é satisfatória pra mim. Porém, uma vez que o sistema tenha um certo tamanho, não consigo ver como fazer as coisas diferentes. Talvez então a saída seja não deixar os sistemas passarem de um tamanho crítico.
Claro que certas áreas exigem software de grande porte. O caso de um sistema operacional como o Windows, um aplicativo como o SAP ou mesmo um aplicativo como o Word, são sistemas que irão exigir toda uma infra-estrutura pesada para permitir manutenção e evolução. Não é à toa que o processo de testes da Microsoft, por exemplo, é algo extenso e complicado. Porém, não acho que isto deva ser usado para software de menor porte. Aliás, acho justamente o contrário, usar este tipo de técnica/processo para software de menor porte significa aumentar em ordens de grandeza o custo para desenvolvimento/manutenção e dificultar significativamente o uso de metodologias ágeis.
Assim, quando possível, acho que devíamos buscar quebrar grandes sistemas em aplicações menores. Usando os mesmos princípios aplicados em refatoração de código (tais como responsabilidade única, baixo acoplamento etc.), poderíamos tentar quebrar os sistemas em módulos para que, apesar de funcionarem em conjunto, sejam entidades separadas. Isto seria possível com uma definição clara de fronteiras, com o apoio de interfaces de serviços (SOA) e com um isolamento de interfaces com o usuário. Áreas de negócio distintas poderiam ser separadas de maneira que o domínio de negócio fosse separado, fazendo com que mudanças em um determinado setor do domínio não afetasse os demais. E mudanças na interface de serviços poderiam ser feitas de maneira versionada e evolutiva, no formato tipicamente usado em SOA.
Claro que uma refatoração de sistema só é possível com a participação direta do cliente, já que isto significa por si só uma mudança em processos, modo de trabalho e até mesmo na relação comercial, já que diversos módulos podem também significar mais de um fornecedor. Mas acredito que se isto gerar uma economia significativa no custo de desenvolvimento, será algo que terá grandes chances de ser adotado pelo cliente. O que mais uma vez ressalta a importância da área de contato com o cliente deter também todo o conhecimento técnico para propor e justificar mudanças como esta. Uma área puramente comercial teria muitas dificuldades em entender e vender algo deste tipo. Felizmente este não é o caso da White Fox.
Na White Fox nós temos alguns sistemas que estão começando a entrar no estágio em que a manutenção está começando a ficar cara, talvez seja este o momento de se pensar em uma refatoração deste tipo. Irei tentar colocar algo assim em prática e vou postando os resultados aqui. Novamente, um feliz 2010 para todos!
White Fox: O Conceito
Publicado por Alexandre Valente em Uncategorized em 13/12/2009
Nestes mais de 15 anos de carreira, meu sonho sempre foi ter meu próprio negócio, uma empresa de desenvolvimento de software que fosse algo diferente e reconhecida pela qualidade do seu pessoal e de seus produtos. Nestes anos, eu tive algumas empresas, todas buscando atingir esta meta, porém, por várias razões, nenhuma delas chegou a atingir este ideal.
Sonhos não morrem, eles permanecem no inconsciente e em momentos propícios, voltam com toda a força. E mais uma vez, está chegando a hora de tentar de novo e atingir o meu ideal. Estou na fase de concepção de uma nova empresa, a White Fox Consultoria e Desenvolvimento de Software. Neste post quero falar um pouco sobre o que estou buscando, quais as motivações e que valores eu estou trazendo para esta nova empresa.
Desta vez acho que tenho grandes chances de atingir meu sonho. Em todos estes anos, eu tive a oportunidade de ver o que funciona e o que não funciona na gestão de uma empresa de desenvolvimento, tanto em aspectos de relação interpessoal quanto na parte de resultados e controle. Acredito que esta experiência, acumulada com muitos erros e acertos (quero crer que tenham sido mais acertos do que erros), é essencial para que a White Fox possa ter sucesso.
Uma das lições mais importantes que eu aprendi é que para que uma pequena empresa tenha sucesso, os seus sócios devem fazer mais do que gerir. Não tenho dúvida que administrar bem em todos os aspectos (especialmente o financeiro) é fundamental para o sucesso. Porém isto não é nem de longe o suficiente. Pois por melhor que seja, um bom gerente administrativo não é capaz de trazer aquilo que cada vez mais eu acho que seja o mais importante: a paixão pelo que se faz, a inspiração para si e para seu time de fazer o melhor e buscar o melhor sempre, o orgulho e o prazer de se estar fazendo algo excepcional. E tudo isto só é possível quando o líder consegue ser a representação disto para todo o time; desta forma ele tem que ser (ou pelo menos ter sido) antes de tudo, um excelente técnico.
Assim, a White Fox está sendo concebida com o melhor de todos estes mundos. A paixão por desenvolvimento e tecnologia é o que move cada integrante da nova empresa. A gestão transparente e minimalista garante que todo o esforço seja voltado para o negócio da empresa, que é fazer bom software para seus clientes. E um time ultra-selecionado, com os melhores profissionais da área produz a mistura que irá permitir que ela tenha muito sucesso.
A White Fox traz alguns conceitos pouco usuais na nossa área. Um deles é que o time seja realmente formado por somente arquitetos/seniores, do tipo que é capaz de fazer um sistema do zero em pouco tempo e que é capaz de atuar em todos os aspectos de um sistema, do banco de dados à interface, passando pela gestão de atividades e pela interação com o cliente. A excelência técnica e o pragmatismo são as características mais relevantes dos membros do time da White Fox. Outro conceito é que cada integrante é um sócio na empresa, sendo responsável pelas decisões da sua alçada e recebendo uma parcela do resultado geral do negócio. Finalmente, iremos buscar um ambiente de trabalho extremamente agradável, sem nenhum tipo de burocracia desnecessária. A idéia é fazer da White Fox o local ideal de trabalho para um desenvolvedor.
O formato de desenvolvimento é o agile. Fortemente baseado no Scrum, mas sem ser Scrum, a empresa irá ter como missão produzir com software com ROI extremamente vantajoso para os seus clientes. O formato implica também uma certa maturidade do cliente. Contratar no formato agile significar que o cliente é também parte do desenvolvimento e o sucesso de qualquer projeto é diretamente proporcional à qualidade e envolvimento do pessoal do cliente. Claro que este formato não é para todos, mas para os que se encaixarem neste perfil, a recompensa será software sendo desenvolvido de maneira rápida e com um ROI excepcional.
Outro diferencial é emprego de um framework de desenvolvimento em todos os produtos construídos. Este framework tem sido evoluído ao longo de vários anos e agora está maduro o suficiente para permitir o desenvolvimento incrivelmente rápido de sistemas sem nenhum sacrifício de usabilidade ou manutenabilidade. O uso e padronização do framework no desenvolvimento da White Fox facilita também o treinamento de pessoal e a manutenção de todos os sistemas produzidos. E, pela qualidade das pessoas do time, o framework vai sendo evoluído a todo tempo para permitir ainda mais velocidade e qualidade final.
A empresa será lançada oficialmente no início do ano que vem. Extra oficialmente ela já está a todo vapor, o time inicial está definido e ela já tem faturamento suficiente para garantir o início das operações. O web site está sendo construído para representar todos estes valores e os clientes estão sendo apresentados à esta nova forma de trabalho (com muito sucesso até agora!). Antes que perguntem sobre o nome, Fox é uma palavra de relevância especial para mim, ligada à agilidade que quero representar. A cor branca transmite simplicidade, clareza e transparência. O logo final está abaixo:
Se você se identificou com este sonho e quiser fazer parte deste empreendimento, me mande um email. O time inicial está pronto, mas a perspectiva é de crescimento rápido. Aguardem então para mais notícias sobre o andamento desta nova empresa!
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.
Alexandre Valente's Blog 