Scrum + Kanban para Manutenção de Software

Neste artigo veremos como a adaptação de metodologias ágeis no desenvolvimento de software pode trazer benefícios ao cliente e, principalmente, ao grupo de trabalho.

De que se trata o artigo:

Neste artigo veremos como a adaptação de metodologias ágeis no desenvolvimento de software pode trazer benefícios ao cliente e, principalmente, ao grupo de trabalho. Mostraremos um novo modelo de metodologia ágil criado a partir das boas práticas identificadas no Scrum e no Kanban e que foi definido para atender às necessidades específicas da equipe de manutenção de software.

Para que serve:

O planejamento e o desenvolvimento de um software sob o paradigma ágil oferecem mais flexibilidade do que os modelos tradicionais para a condução de projetos de software que possuem incerteza ou instabilidade. A junção entre Scrum e Kanban traz, às atividades de manutenção de software onde existem contratos rígidos de suporte (SLA), bastante dinamismo, além de direcionar os esforços para os problemas de maior valor e importância para o cliente.

Em que situação o tema útil:

Além de ser um modelo que permite a criação de planos flexíveis, as técnicas ágeis evitam desperdícios de tempo e esforços, pois focam em alcançar rapidamente meios de validar as características do produto em desenvolvimento e a evolução do projeto. A aplicação desses métodos na manutenção de software trouxe benefícios ao ciclo final do produto, mantendo assim, a satisfação do cliente.

Autores: Marcelo Camera e Anselmo Junior

Provavelmente você já tenha ouvido falar em desenvolvimento ágil de software, na utilização de Scrum e Kanban e nos benefícios da adoção das metodologias ágeis. Por outro lado, pouco se tem falado sobre a aplicação de uma dessas metodologias nas operações de manutenção de software, área em que o trabalho é regido por contratos de serviço que determinam prazos, custos e novas prioridades a cada momento.

Pensando nessa situação, seria possível aplicar alguma metodologia ágil para aumentar a produtividade e o tempo de resposta na operação de manutenção de software?

Este artigo revela nossa procura por respostas e a maneira como adotamos e adaptamos algumas das melhores práticas de duas reconhecidas metodologias ágeis, Scrum e Kanban, e como temos obtido benefícios depois que alteramos nossa maneira de trabalhar. Além disso, acreditamos que este artigo possa servir de inspiração para outras organizações que têm sua atividade voltada à operação de manutenção de software.

Como é a operação de manutenção de software

Todo nosso processo tem início quando um projeto de desenvolvimento termina e o cliente aceita formalmente os produtos: software e documentação. A partir do momento da entrega, a responsabilidade pelo produto passa a ser do grupo de manutenção, que vai analisar toda e qualquer falha reportada.

Operacionalmente, quando o cliente observa um comportamento atípico do sistema abre uma ordem de serviço (OS) descrevendo essa possível falha. Nesse momento, a OS é encaminhada a um dos grupos de manutenção para análise e, se for constatada a falha, tem início o desenvolvimento da correção do software (CS).

As OS estão atreladas a um contrato de serviço (SLA) que é estabelecido entre o cliente e a organização e que define como a OS é classificada e como deverá ser tratada pelo grupo de manutenção. Essa classificação varia de acordo com a severidade da falha, sendo 1 a maior severidade e 3 a menor. As SLAs especificam também o tempo máximo de resposta para cada uma das OS, que variam também de acordo com a severidade da falha, sendo 10 dias para severidade 1, 20 dias para severidade 2 e 30 dias para severidade 3. Em função do extenso portfolio de produtos e projetos desenvolvidos, OS são abertas a todo o instante e nas mais diversas prioridades.

Além das classificações anteriores, é denominada blacklist a lista de todas as OS que tiveram seu prazo de resposta perdido. A partir desse dia, passamos a contabilizar o número de dias perdidos por OS, ou seja, o prazo extra gasto na resposta da OS.

Diz-se que uma OS perdeu um dia se ela permanecer na blacklist por um dia, com isso no final do período temos então a quantidade de dias perdidos por OS, que mostra nossa eficiência em responder as OS no prazo." [...] continue lendo...

Artigos relacionados