Para o Ciclo de Manutenção, Agilidade Já !

Um ciclo de trabalho mais inteligente para um planeta mais Inteligente

Um ciclo de trabalho mais inteligente para um planeta mais Inteligente

Moacyr Cardoso de Mello Filho, Certified IT Specialist, IBM

Moacyr Cardoso de Mello FilhoMoacyr Mello é consultor e Certified IT Specialist da IBM Brasil. É formado Engenheiro Eletricista pela Escola Politécnica da Universidade de São Paulo – USP, e realizou especialização em Gerenciamento de Projetos pela Fundação Getúlio Vargas – FGV. Possui experiência de 24 anos na área de TI, exercendo funções de analista de sistemas, projetista de software, gerente de projetos e gerente funcional. Trabalhou no Instituto de Pesquisas Tecnológicas – IPT, em gerência de redes na Itaudata Itaú Informática Ltda, no Centro de Computação Eletrônica da Universidade de São Paulo – USP, em metodologia de desenvolvimento de sistemas, e foi Gerente de Tecnologia da Informação na TecBan - Tecnologia Bancária S/A, onde implantou processos iterativos de desenvolvimento de software. Desde 1999 é Senior Software Engineer Specialist, nas disciplinas de Processos, Gerência de Projetos, Modelagem de Negócios e Gerenciamento de Requisitos da Rational Software.



23/Set/2009

Enquanto todos querem agilidade e a maioria ainda discute a agilidade, sem buscá-la realmente, alguns já iniciaram o caminho que levará a um ciclo de trabalho mais inteligente. Isto irá transformar a maneira de TI suportar o seu negócio e melhorará seu desempenho no desenvolvimento de software.

Um assunto recorrente, sempre que discutimos projetos de software, é a questão da manutenção de sistemas, sempre encarada como o primo pobre pelos processos ou metodologias de desenvolvimento. Apesar de ser um assunto importante, pois é a maioria do volume de trabalho desenvolvido nas organizações de hoje, frequentemente a manutenção é tratada como um caso particular do problema geral de desenvolvimento. Estima-se que de 75% a 85% do volume de software desenvolvido por organizações que não tem por objetivo de negócio desenvolvimento de software é manutenção de sistemas. Sem dúvida as mesmas técnicas e métodos aplicados a projetos novos podem ser aplicadas também na manutenção, mas há peculiaridades que poderão ser melhor exploradas se entendermos a questão da natureza da manutenção. É nesse campo que a adoção de métodos ágeis tem-se revelado mais vantajoso.

Apesar da enorme diversidade escondida no termo manutenção, diversidade esta correspondente à variedade do próprio universo dos aplicativos, é comum encontrarmos as manutenções classificadas como evolutivas, adaptativas ou corretivas:

  • Evolutivas - novos requisitos e funções;
  • Adaptativas - alterações para manter a adequação à legislação ou ao negócio;
  • Corretivas - eliminação de um erro, defeito ou mau desempenho.

O debate sobre a classificação, frequência e dimensão, isto é, o tamanho, é infindável. Esse debate justifica soluções particulares e customizações mas, em princípio, as manutenções adaptativas ou corretivas não significam isoladamente grande quantidade de trabalho. Consequentemente geram menos mudança no código e no design. Esta constatação é interessante pois se a arquitetura do software já existe, estamos afinal mantendo... e o volume de trabalho associado aos requisitos é pequeno, um processo mais simples e que não necessariamente abandonasse o design, mas eliminasse o peso de sua responsabilidade, seria possível e desejável pois aceleraria o ritmo das coisas e facilitaria a manutenção.

Por outro lado as manutenções evolutivas, teoricamente, tem potencial para nos preocupar pois podem corresponder a grandes trasnformações nos sistemas em que se aplicam, algumas vezes até alterando a finalidade original da aplicação. Pensando nestes cenários, poderíamos caracterizar as manutenções em dois grupos, adaptativas-corretivas e as evolutivas, podendo cada grupo necessitar de uma abordagem de processo diferente. Antevemos uma abordagem mais formal e consequentemente mais pesada para este caso da evolutiva onde a preocupação com a arquitetura e o design ainda subsistem.

Parece que precisamos então de dois processos. Mas um problema surge em contato com a realidade: em geral não conseguimos separar, na prática, o esforço em cada categoria de manutenção. Quando aquela manutenção evolutiva a tantas semanas aguardando o término das manutenções corretivas emergenciais finalmente ficou pronta para ser implementada, eis que surge uma importante manutenção adaptativa porque o Banco Central modificou um parâmetro no Sistema de Pagamentos Brasileiro! É assim que a realidade faz questão de misturar situações e o planejador, procurando a opção mais econômica, se vê na contingência de planejar manutenções que envolvam, por exemplo, novos requisitos (que seria uma linha de evolução), mudança de legislação ou negócio (uma linha de adaptação) e alguma correção. A manutenção em lote é uma contingência da realidade, mas talvez possamos tirar proveito disso.

Fica difícil caracterizar o tamanho de uma manutenção de software genérica como a imaginada aqui mas, para efeito do próximo raciocínio vamos arbitrariamente simplificar as coisas. Vamos imaginar uma manutenção típica que seria caracterizada como:

  • Solicitada através de um ou mais pedidos, comunmente chamados demanda, onde um texto traduz a intenção do pessoal de negócios mas não se caracteriza como um grande projeto;
  • As tais demandas acumulam-se e podem ser tratadas num esquema em lote ("batch");
  • A própria equipe de desenvolvimento ou um analista designado, avaliam a demanda, a classificam e a traduzem em termos de impacto na aplicação e no trabalho diário;
  • A equipe é pequena, no máximo de 2 a 3 pessoas;
  • A arquitetura da aplicação está bem estabelecida (a aplicação já existe!);
  • O estilo de desenvolvimento é interno, não há subcontratação;
  • As implantações são feitas com baixo nível de cerimônia.

Em manutenções desse tipo, o principal elemento dirigente do processo passa a ser a prioridade do cliente e/ou da equipe de negócios. Não há considerações de engenharia como as que afetam um sistema sendo construído do zero. As demandas aparecem ao longo do tempo refletindo novas necessidades e o óbvio desafio do planejador é compor um pacote que seja ao mesmo tempo econômico do ponto de vista da implementação e que atenda às prioridades, seja em conteúdo ou em prazo.

Fila de espera, backlog
O primeiro elemento de inteligência é a criação de um backlog (aquela lista de espera das demandas solicitadas, que é vista com pesar e culpa em TI). Não falo de um backlog espontâneo, devido talvez à falta de velocidade no atendimento às demandas, falo de um backlog proposital que possibilite trabalhar o elemnto de planejamento em lote. Quanto menor o volume de trabalho de um requisito, em outras palavras, mais pontual a manutenção, maior serão os gastos com setup do processo, trabalho e retrabalho pensando num prazo longo se não instituirmos alguma composição de demandas estaremos perdendo dinheiro continuamente, desperdiçando recursos valiosos . Voltaremos muitas vezes a modificar o código de um determinado trecho do programa diminuindo a eficiência da manutenção e retrabalhando. No pior caso, o cenário em que não há empacotamento (lote) algum e cada demanda é implementada individualmente, o planejador não consegue combinar requisitos e potencializar recursos em programação. Essa é uma situação típica de correção emergencial. Viver assim durante muito tempo cria um perpétuo ambiente de emergência, acostuma a "memória muscular" da organização a sempre responder aos trancos.

Passo consistente, cadência
Por outro lado, se for possível, ao gerente planejador compor um pacote de requisitos para serem tratados conjuntamente, o tal do lote, priorizando de acordo com as necessidades do negócio e colocando na fila para implementação e implantação, será possível criar um processo que mantenha um fator muito importante denominado cadência. Explico: em tarefas repetitivas, mesmo as intelectuais, se a demanda de trabalho é desorganizada, a reação da equipe se tornará variável e será imprevisível seu rendimento. Essa situação pode ser consertada se estabelecermos uma passo constante, uma cadência de trabalho que volte a criar a vontade de implementar manutenção de software. Uma cadência assim deve começar com um período de trabalho de tempo fixo, uma iteração ou sprint (na linguagem do Scrum) devem possuir sempre um tempo igual a 30 dias, por exemplo, para fundamentar a cadência. Portanto cadência e backlog são elementos que andam juntos. A duração da sprint é em última instância uma questão de aprendizado e adaptação.

Em sistemas que estão em produção há muito tempo, e consequentemente estão em manutenção também há muito tempo, a equipe já sabe avaliar o impacto de uma mudança e provavelmente já aprendeu, de acordo com o ritmo da organização, qual é o melhor intervalo para a liberação de releases. A implantação de novas relesases de um sistema maduro obedece a um ritmo próprio cujo intervalo ótimo depende de fatores como eficiência da equipe, capacidade do usuário em absorver a nova release, demanda do negócio, etc. As equipes descobrem empiricamente esse intervalo e ajustam seus recursos e esforços para atender às demandas num volume em lote adequado ao intervalo. É lógico que este aprendizado vem acompanhado de compromissos e acordos realizados pelo gerente planejador junto às áreas usuárias e a direção da organização.

Eu vi esse processo acontecer, na prática, numa equipe de desenvolvimento que mantinha um produto para ATMs (automated teller machine) . No início, sob pressão da área de marketing, a gerente de produto postulou que fariam entregas de releases de 15 em 15 dias. O sistema já estava maduro e o backlog podia ser traduzido em manutenções pontuais. Mas os problemas com disponibilidade de laboratório de testes, disponibilidade de máquinas e tempo de homologação, impediam sempre o cumprimento da meta. Depois de alguns percalsos o tempo da iteração foi aumentado para 45 dias, que se mostrou mais do que suficiente para acomodar as dificuldades de ambiente. Na próxima etapa, com o consentimento da equipe, foi diminuido o período das releases para 30 dias, e manteve-se a produtividade e a qualidade de software. Será uma coincidência ter-se chegado à duração recomendada para a sprint pelo Scrum?

Scrum
Esse processo de auto organização e descoberta empírica do tempo de liberação das releases, se assemelha muito à maneira que a metodologia Scrum trata o projeto de desenvolvimento de software. O Scrum começou a nascer por volta de 1986 a partir do estudo e das idéias de Takeuchi e Nonaka sobre a criação de conhecimento organizacional através de inovação e interação. Mais tarde, em 1995, Ken Schwaber formalizou a definição do Scrum para gerenciamento de processos de software. Esse processo ágil de desenvolvimento está baseado em ciclos de observação e adaptação que terminaram por dar forma ao ciclo de iterações e releases chamado sprint usado hoje. (Scrum e sprint são termos emprestados do jogo de Rugby).

Um projeto Scrum é composto de sprints, tal como o RUP, IBM Rational Unified Process, é composto de iterações. A sprint é um ciclo de trabalho e, como nas iterações do RUP, entrega uma release de software executável, neste caso externa, isto é, que se pode colocar em operação no ambiente do cliente. As sprints se sucedem sem uma divisão por fases que as caracterize. Sem a preocupação de construir uma arquitetura, este modelo se encaixa muito bem no problema da manutenção. Os requisitos em geral estão na forma declarativa, mas podem estar em outra forma qualquer. Estórias de usuários e mesmo casos de uso são formas comuns dos requisitos em Scrum. Quando os requisitos foram analisados e priorizados formam o backlog do produto, que é o conjunto total de requisitos, priorizados do ponto de vista do cliente. Já o backlog da sprint é o conjunto de requisitos escolhidos para serem implementados numa particular sprint.

Scrum de Scrums
O desenvolvimento transcorre com reuniões diárias, para feedback e planejamento, onde se pode verificar o progresso, o trabalho que falta ou, o mais importante, o que impede o avanço do trabalho. Esses impedimentos para execução do trabalho surgem de variadas fontes do ambiente e são um problema para o Scrum master resolver. Caso este não os resolva, os impedimentos são levados sucessivamente a uma equipe gerencial intermediária e em seguida à equipe com o executivo principal. Todos os níveis gerenciais da organização que está implantando Scrum conhecem e participam de alguma forma do esforço de implantação, mas principalmente um canal com a direção da organização é aberto e tem importância fundamental.

A verdadeira contribuição do Scrum para o desenvolvimento de software veio da sua proposta de implantação. Como as iterações são curtas e muito focadas, os impedimentos surgem e precisam de decisão, a implementação do processo de melhoria durante o período de transição força a existência de um canal direto com a direção da empresa. Equipes gerenciais, inclusive a equipe do executivo principal, executam iterações de Scrum, de menor duração, com o foco na resolução de problemas. Isto dá agilidade e compromisso com a transição.

Smart work
É claro que durante a transição muitas dificuldades aparecerão colocadas à luz pelo próprio processo. Em geral não apreciamos quem traz má notícia ... Ken Schwaber nos diz "não mate o mensageiro!" o Scrum é apenas o mensageiro, aquele que irá mostrar as dificuldades. Mesmo quando a adoção não é perfeita, ela já é um ganho organizacional, mas a maior vantagem é que o processo é um instrumento de auto-correção. O período de implantação inicial é estimado de 6 a 12 meses e o esforço concentrado resulta numa organização mais ágil e mais moderna, quer dizer, uma organização mais inteligente num planeta mais inteligente.


Download

DescriçãoNomeTamanho
Para o Ciclo de Manutenção, Agilidade Já !tmpRSA-Automated-Model-Transformation.pdf671KB

Comentários

developerWorks: Conecte-se

Los campos obligatorios están marcados con un asterisco (*).


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Los campos obligatorios están marcados con un asterisco (*).

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Rational
ArticleID=451687
ArticleTitle=Para o Ciclo de Manutenção, Agilidade Já !
publish-date=09232009