Posts Marcados Desenvolvimento Ágil

Manutenção de Sistemas

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.

, , , ,

2 Comentários

White Fox: O Início

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!

, , , , ,

4 Comentários