Como fundamentar seus argumentos para buscar investimentos em Qualidade de Software?

Vamos ao 1º post de 2015! 🙂

Na maioria das vezes quando nos deparamos com o desafio de estruturar um processo de desenvolvimento de software que contemple teste de software. Ficamos preocupados em justificar o investimento na área, coletamos métricas da situação atual para nos embasarmos e projetamos os objetivos que seriam alcançados, caso a empresa tivesse um processo definido, por simples que fosse. Dependendo da empresa, principalmente da visão de Qualidade de Software que seus gestores possuem, pode ser algo que se faça com uma maior facilidade.

Entretanto, se os gestores possuírem uma visão mais ortodoxa (por diversas razões), esta atividade poderá se tornar um trabalho árduo, uma vez que será necessário utilizar outras formas para justificar tal investimento. Quando isso ocorre, algumas perguntas poderão surgir, tais como: o que podemos fazer? Para que lado eu vou? Quem poderá me mostrar o “caminho das pedras”? Se subíssemos um ou mais níveis para analisarmos a organização como um todo, veríamos que não seria apenas definir um processo de desenvolvimento e implantá-lo.

Contextualizando…

Atualmente, grande parte dos negócios não conseguem se manter sem a tecnologia. Com isso, a tecnologia tornou-se parte indispensável para as transações das organizações. Além disso, o mercado está cada vez mais competitivo, onde ter um produto com qualidade traz para a imagem da empresa a confiança de seus clientes, o que faz aumentar seu faturamento. A partir da implantação da Governança de TI na organização, é possível identificar como pode ser feita a medição do desempenho da TI através do ponto de vista da Qualidade de Software, uma vez que irá auxiliar no processo de tomada de decisão na gestão da TI, utilizando como base os níveis de maturidade do framework CobiT.

Governança de TI

A Governança de TI busca o compartilhamento de decisões de TI com os demais dirigentes da organização, assim como estabelece as regras, a organização e os processos que darão um rumo para o uso da tecnologia da informação pelos usuários, departamentos, divisões, negócios da organização, fornecedores e clientes, determinando como a TI deve prover os serviços para a
empresa. A Governança de TI vai muito além do que simplesmente implementar modelos de melhores práticas. Diante disso, a Governança de TI possui os seguintes papéis:
* Garantir o alinhamento da TI ao negócio, em suas estratégias e objetivos, tanto em relação às aplicações como à infraestrutura de serviços de TI;
* Garantir a continuidade do negócio contra interrupções e falhas;
* Garantir o alinhamento da TI aos marcos de regulação externos como Sarbanes-Oxley, Basiléia II e outras normas e resoluções.
Seu objetivo principal é alinhar a TI aos requisitos de negócio, onde está baseado na continuidade do negócio, no atendimento das estratégias e no atendimento dos marcos externos de regulamentação. O ciclo de vida da Governança de TI é composto por 4 etapas:

Etapas do Ciclo de Vida da Governança de TI

Podemos destacar alguns dos principais modelos de melhores práticas para implantação da Governança de TI. Os mais conhecidos são: CobiT, CMMI, ITIL, ISO/IEC 27001 e ISO/IEC 27002, Modelos ISO, PMBOK, BSC e Seis Sigma.

Framework CobiT 

O CobiT (Control Objectives for Information and related Technology) possui padrões internacionais técnicos, profissionais, regulatórios e específicos para controle dos processos de TI. Tem como principal objetivo auxiliar no êxito da entrega de produtos e serviços de TI, baseando-se nas necessidades do negócio da organização com objetivo de controle.
Seus pilares estão fundamentados em 5 áreas-foco: Alinhamento Estratégico, Agregação de Valor, Gerenciamento de Recursos, Gerenciamento de Riscos e Medição do Desempenho. O modelo está estruturado em 4 domínios: Planejamento e Organização, Aquisição e Implementação, Entrega e Suporte e Monitoração e Avaliação. Cada domínio dá cobertura a um conjunto de processos, para que se possa garantir a gestão da TI, onde ao todo totalizam 34 processos. Além disso, o CobiT possibilita utilizar como matriz o ciclo tradicional de melhoria contínua (ciclo PDCA).

Qualidade de Software

É um processo sistemático que focaliza todas as etapas e artefatos produzidos com o objetivo de garantir a conformidade de processos e produtos, prevenindo e eliminando defeitos. O produto final do processo de desenvolvimento é exatamente o somatório de todas as decisões e realizações geradas durante todo o ciclo de desenvolvimento. Se for desejado produzir software com alta qualidade, será necessário investir em qualidade em todos os pontos do processo.

Seja método tradicional ou incremental, a disciplina de Teste de Software dará suporte ao processo de desenvolvimento estruturado, assim como a adoção de ferramentas para auxiliar na realização das atividades. Estas informações deverão constar no Portfólio de TI, que faz parte do Plano de TI.

Conclusão

Independente da escolha do modelo de qualidade de software mais adequado ao negócio, a melhoria do processo deve ser uma preocupação constante para empresas que desenvolvem aplicações, pois cada vez mais o mercado exige qualidade dos produtos por eles contratados. As empresas que tiverem a capacidade de integrar, equalizar e catalisar seus processos de desenvolvimento e, principalmente, dar manutenção nos produtos de forma mais efetiva e mais agilidade obterá supremacia diante dos seus concorrentes.

Este ponto de vista traz argumentos que vão além do famoso ROI, que nada mais é do que Retorno sob o Investimento. Muitas vezes, esta métrica pode ser um pouco complicada de ser mensurada, principalmente quanto aos seus benefícios.

Aqui vale o gancho do CobiT… ciclo PDCA! Acredito fortemente que um processo de desenvolvimento de software tenha que ser algo relativamente simples, mas efetivo, e que as pessoas vejam valor nele. Como fazer isso? Eliminando os desperdícios… mas isso é assunto para outro post! 😉

E quando não há um processo de teste definido, o que fazer? Parte 2

** DEFININDO UM PROCESSO DE DESENVOLVIMENTO DE SOFTWARE **

Dando continuidade ao assunto abordado no post anterior, em termos de processo de desenvolvimento e que contemple a etapa de testes, eu sugiro algo baseado no ciclo PDCA, que considero dinâmico e incremental.

PDCA-250

Etapas do Processo de Desenvolvimento em um Ciclo PDCA

Vamos alinhar alguns conceitos utilizados neste ciclo:

  •  Release – termo utilizado para designar uma demanda a ser desenvolvida pelo time. Nesta demanda poderá ter uma ou mais funcionalidade. Uma release poderá ter uma ou mais iterações.
  • Iteração – termo utilizado para classificar um ciclo de desenvolvimento. Uma iteração poderá contemplar uma ou mais funcionalidades para ser(em) desenvolvida(s).
  • Backlog – termo utilizado para designar o estoque de funcionalidades de um projeto.

1. PLAN

1.1. Planejamento da Release
– O analista de negócio revisa a visão do produto, estratégia e objetivos.
– O analista de negócio revisa as datas chave e milestones.
– O analista de negócio apresenta o backlog de produto priorizada.
– O time faz perguntas para entender os requisitos.
– O time estima os requisitos em um alto nível (story points, dias ideais, function points).
– O time estima sua velocidade inicial e/ou capacidade por iteração.
– O time formaliza os objetivos da entrega em um plano de release.
– O facilitador da reunião registra decisões chave, premissas, riscos e/ou questões.
– Consenso de stakeholders é alcançado e o consentimento de prosseguir é dado.

=> O Analista de Teste/Testador participa através…
– Questionamentos para entender as regras de negócio das funcionalidades a serem desenvolvidas pelo time.
– Identificação os critérios de aceitação de cada requisito.
– Estruturação da estratégia de teste da release.
– Realização do planejamento dos testes, onde já é possível identificar os principais cenários de teste para validar as funcionalidades.

1.2. Planejamento da Iteração
– O analista de negócio revisa a visão do produto, estratégia e objetivos.
– O analista de negócio revisa as datas chave e milestones.
– O analista de negócio apresenta parte do backlog de produto priorizada.
– O time faz perguntas para entender os requisitos.
– O time estima os requisitos em um alto nível (story points, dias ideais, function points).
– O time estima sua velocidade inicial e/ou capacidade por iteração.
– O time formaliza os objetivos da entrega em um plano de release.
– O facilitador da reunião registra decisões chave, premissas, riscos e/ou questões.
– Consenso de stakeholders é alcançado e o consentimento de prosseguir é dado.

=> O Analista de Teste participa através…
– Caso tenha surgido alguma dúvida sobre os requisitos durante o planejamentos dos testes, este é o momento de esclarecer!
– Complementa os cenários de teste, se for o caso.
– Realiza a estimativa de teste.
– Identifica a necessidade de massa de dados para teste, ambiente específico, etc.
– Verifica a viabilidade da automação dos testes funcionais e/ou a atualização dos scripts já existentes.

2. DO

2.1. Execução
– Ferramenta de qualidade de software configurada para monitorar a qualidade do código gerado.
– Automatizar sempre que for viável! Tanto testes funcionais quanto unitários.
– Documentação deve ser gerada a medida que o software é criado/alterado.

=> O Analista de Teste participa através…
– Enquanto o desenvolvedor codifica, o analista de testes/testador cria os artefatos de que se façam necessários.
– A medida que as demandas são liberadas pelo desenvolvedor, o analista de testes/testador realiza os testes funcionais, tanto manuais quanto automatizados.
– Reporta os problemas encontrados para o desenvolvedor.
– Refaz os testes para verificar a correção dos problemas reportados.
– Cria/atualiza scripts de testes automatizados, de acordo com o planejamento e estratégia dos testes.

2.2. Acompanhamento Diário
– O time reúne-se durante 15 minutos para compartilhar as atividades realizadas, impedimentos, angústias, onde respondem as seguintes perguntas:
a) O que você fez desde nosso último encontro?
b) O que você está planejando fazer até que nos encontremos de novo?
c) Quanto tempo falta para você concluir a atividade atual?
d) O que, se for o caso, você está encontrando de obstáculos que estão impedindo você de fazer progresso?

3. CHECK

3.1. Revisão da Iteração
– O time verifica as funcionalidades concluídas com o analista de negócio.
– O time identifica qualquer histórias incompletas.
– O analista de negócio move e/ou divide histórias incompletas ou itens de backlog para próxima iteração ou as retorna para product backlog, se não for uma prioridade.
– O analista de negócio fecha a iteração e aceita funcionalidades adequadas.
– O time demonstra o software funcional para as partes interessadas.
– Quaisquer questões em aberto/obstáculos e itens de ação são verificadas e atribuídas.

=> O Analista de Teste participa através…
– Acompanhamento da validação da versão pelo analista de negócio/cliente.

4. ACT

4.1. Retrospectiva
– O time revisa o plano de ação da última reunião de retrospectiva.
– O time revisa o que foi bem durante a última iteração.
– O time revisa o que não foi tão bom ou como planejado durante a última iteração e por que.
– O time analisa os números do projeto.
– O time analisa a causa-raiz da ocorrência de não conformidades e propõe ações de melhoria e/ou preventivas.
– O time identifica as questões mais importantes para focar na próxima iteração.
– O time verifica qualquer impedimento que os impeça de adotar as melhorias no processo.

=> O Analista de Teste participa através…
– Leva para a reunião de retrospectiva os pontos positivos e negativos ocorridos durante a iteração.
– Se prontifica a atuar em algum foco do plano de ação.

Portanto, um processo organizacional, seja do desenvolvimento de software como um todo, seja da etapa de teste, deve ser simples e facilmente repetido. As pessoas precisam ver o valor deste processo e passar a adotá-lo naturalmente. Destaco também a relevância do papel do analista de teste/testador como um facilitador dentro do time, ou seja, terá um papel vital para que a comunicação flua dentro do time. Em times de Scrum, poderá exercer o papel de Scrum Master dentro do sprint.

Não se esqueça: faça babies steps! 😉