•   

Lean IT

 
  • Login
  • Cadastre-se
  • Receba nossos informativos

(11) 2528-2354

contato@leanti.com.br

  •   
  • A Empresa
    • Sobre Nós
    • Sistema Toyota de Produção
    • Saiba mais sobre Lean
    • O que é Lean IT?
    • Framework Lean TI
  • CONSULTORIA
    • Consultoria Lean
    • Consultoria Business Agility
    • Consultoria Lean Agile
    • Consultoria Lean Healthcare
    • Consultoria Lean BIM
    • Consultoria em Planejameto Estratégico
    • Consultoria LGPD
    • Gestão de Crise
    • Plano de continuidade de negócios
    • Palestras sobre lean
  • LGPD
  • TREINAMENTOS
  • CERTIFICAÇÃO LEAN IT
  • Conteúdo
    • Artigos (todos)
    •   De conceitos gerais
    •   De estratégia
    •   De desenvolvimento
    •   De cotidiano
    •   De melhoria contínua
    • Lean IT na mídia
    • Videos
  • Clientes
  • Softwares
    • Lean Score
    • Software de OKR
  • Contato

Incluindo qualidade no processo de desenvolvimento de software

  • Você está aqui: 
  • Artigos  
 

Por: Marcelo Palladino     7614 visualizações     Tempo leitura: 13 min

Introdução:

A ideia do “pensamento enxuto” (Lean Thinking) é algo que de uma forma ou de outra está aí desde 1990. No entanto, quem viveu esta época no desenvolvimento de software teve que conviver com análise estruturada, processo de desenvolvimento em cascata, espiral e outras diversas práticas de engenharia de software que vão contra alguns princípios do pensamento enxuto. O foco muitas vezes estava em entregar artefatos, documentar e especificar todo o software antes desenvolver.

Desde a criação do XP (~1997) e posteriormente do manifesto ágil, por volta de 2000, muita coisa tem mudado no mundo do desenvolvimento de software. Por exemplo, o pensamento pragmático com foco na entrega de valor tem tido cada vez mais espaço nas corporações e, com isso, diversas abordagens surgiram com o objetivo de alinhar processos de produção, que já existiam, às novas tendências de desenvolvimento de software. Uma das abordagens resultantes deste processo foi o Lean Software Development, apresentado por Mary Poppendieck e Tom Poppendieck, o qual mostra como os princípios Lean originais podem ser aplicados/adaptados em abordagens de desenvolvimento de software ágil.

7 princípios Lean aplicados ao desenvolvimento de software

  1. Elimine desperdícios
  2. Inclua a qualidade no processo
  3. Crie conhecimento
  4. Adie decisões e comprometimentos
  5. Entregue o quanto antes
  6. Respeite as pessoas e a equipe
  7. Otimize o todo

Como desenvolvedor da Lambda3, é impossível para mim não fazer conexões com estes princípios, uma vez que na Lambda somos constantemente forçados a pensar de forma pragmática em qualidade e entrega de valor. Toda conversa, seja ela sobre arquitetura de software, tecnologias a serem empregadas nos projetos ou metodologias, sempre tem como alvo a qualidade e a entrega de valor real para os clientes, de forma constante e ágil.

Sendo assim, este artigo tem o objetivo de compartilhar algumas coisas que fazemos na Lambda3 e que se relacionam com os princípios estabelecidos por Mary e Tom. Mais especificamente falarei sobre o segundo princípio que trata sobre a inclusão da qualidade no processo.

Pensamento pragmático: O triângulo das restrições

Temos que ter um cuidado especial ao falar de qualidade. Já vi muitos times falharem por não saberem definir o que é qualidade e/ou levarem esta discussão para o âmbito puramente passional. As perguntas são simples: qual o conceito de qualidade em seu projeto? O time sabe exatamente o que significa qualidade para o projeto em questão?

Uma boa forma de definir a meta de qualidade de um projeto é usar o triângulo das restrições, também conhecido pelas alcunhas de trângulo de ferro, triângulo do projeto, triângulo das triplas restrições, triângulo das dependências e por aí vai.

Triângulo das restrições

As partes deste triângulo se relacionam de forma que não há como alterar um lado sem afetar os outros dois e isso está totalmente conectado ao conceito de qualidade do projeto. Esta conexão é tão forte que uma forma bastante honesta de representar o triângulo pode ser esta aqui:

Triângulo das restrições

A qualidade é afetada por mudanças em qualquer lado do triângulo e isso tem que estar bem claro para todos no time.

Pensamento pragmático: Uma história real sobre (in)definição de qualidade

Certa vez trabalhei em uma empresa cujo gerente de projeto entendia que os três lados do triângulo das restrições eram sagrados e nunca deveriam ser alterados após o aceite do cliente. Uma típica estrutura em cascata. A equipe de levantamento de requisitos trabalhava no início para viabilizar o projeto junto ao cliente e coletava todos os requisitos funcionais. Depois disso, o gerente de projeto orçava o software e definia um prazo baseado em sua experiência e nos requisitos funcionais documentados por sua equipe.

Quando o projeto chegava ao time de desenvolvimento, já havia diagramas de caso de uso, modelos de dados, diagramas de classes e protótipos de tela. Além disso, havia um documento bem bonito no MS-Project estipulando todos os prazos e atividades. Os prazos e os custos normalmente não estavam alinhados com a definição de pronto * do time de desenvolvimento. Nós gostaríamos de incluir o máximo de testes automatizados, especialmente aqueles de aceitação, os quais idealmente deveríamos contar com o apoio do time de analistas para escrevê-los. No entanto, isso normalmente ia de encontro com as expectativas de prazos/custos. Nossas definições de qualidade eram diferentes: o time de desenvolvimento queria testes como apoio para entrega íntegra, a gerência achava que isso não influenciava a qualidade externa, que era uma questão de purismo técnico. No final isso nos colocava em uma constante e desgastante queda de braço, na qual nunca havia um vencedor de fato. Todos perdíamos, inclusive os clientes.

* Definição de pronto
A definição de pronto de um time de desenvolvimento está ligada aquilo que deve ser feito em uma funcionalidade para que ela possa ser considerada “pronta”. Isto pode envolver desde o aceite da história por parte do usuário até aspectos mais relacionados ao apoio do time.
Um exemplo de definição de pronto poderia ser:
-A funcionalidade deve possuir testes de aceitação
-A funcionalidade deve possuir testes de unidade
-O código deve ter sido revisado por outra pessoa
-Todos os testes devem estar passando no build
-A funcionalidade deve ter sido publicada em homologação

O cliente tinha uma planilha na qual ele definia as relações e parâmetros entre os diversos centros de lucro da empresa. Esta planilha estava enraizada na cultura da empresa e todos a utilizam há anos. Parte do nosso trabalho era levar aqueles dados para dentro de um módulo do software de forma a aumentar sua visibilidade, permitir o versionamento e sua utilização em outros módulos. Fora alguns problemas na modelagem, o requisito previa a criação de várias telas (não me lembro do número, mas passava de 10), as quais deveriam ser utilizadas pelos usuários para criar e manter exatamente as mesmas informações que ele mantinha em um único documento do MS-Excel. Aquilo não parecia certo, de maneira que a equipe de desenvolvimento alterou o requisito. Criamos uma única interface que tratava a planilha como uma entrada de dados, validando seu conteúdo, alimentando as entidades do banco de dados e tratando adequadamente suas versões. O modelo ficou um pouco mais complexo, pois a alteração do requisito entregava mais valor. Além disso, escrevemos diversos testes de unidade para as rotinas de leitura e validação, cobrindo na totalidade as regras de negócio impostas pela planilha.

Para tornar curta uma história que é longa, o cliente adorou. Era exatamente o que ele esperava e nós o encantamos. No entanto, mudamos todos os lados do triângulo sem que isso gerasse mais receita para o projeto, já que o cliente não aceitou pagar mais por algo que era exatamente o que ele queria desde o começo.

O gerente do projeto entendeu o ponto da equipe de desenvolvimento, mas defendeu a ideia que deveríamos ter feito “errado”, mantendo as restrições para depois vender uma provável requisição de alteração. Esta história mostra bem como uma clara definição de qualidade devidamente compartilhada é importante. Além disso, esta história mostra como um time mal organizado pode comprometer a integridade do projeto, o que vai nos levar ao ponto central deste artigo.

Qualidade é inegociável

Desenvolvendo software há muitos anos, tive a oportunidade de trabalhar em empresas de vários tamanhos, times dos mais variados tipos e clientes dos diversos ramos de atividade. Independente de todas as circustâncias variáveis, pelo que consigo me lembrar, a busca pela qualidade sempre foi uma meta constante e inegociável.

Neste tocante, Mary e Tom Poppendieck determinaram que há dois tipos de integridade no processo de desenvolvimento de software: integridade percebida e conceitual. A integridade percebida é aquela em que o software alcança um equilíbrio entre funções, usabilidade, confiabilidade, economia, etc, ou seja, exatamente aquilo que o cliente precisa e espera. Integridade conceitual é aquela na qual os conceitos e partes centrais do sistema trabalham harmonicamente, de forma coesa, como um todo. Os componentes ou módulos se integram e trabalham bem conjuntamente. É fácil perceber que como a integridade conceitual é fator crítico para a entrega de integridade/qualidade percebida.

A pergunta é: como um time de desenvolvimento de software, que entrega funcionalidades de forma ágil, pode garantir a integridade daquilo que está sendo entregue?

Ferramentas e práticas visando integridade

Desenvolver software é um processo complexo, o que torna a tarefa de entregar software com integridade bem difícil. Tendo isto em vista, o que você pode fazer para controlar a complexidade e aumentar suas chances de entregar software íntegro?

Testes automatizados

Testes automatizados são obrigatórios! Se seu projeto não possui uma boa bateria de testes, com cobertura de código, como você pode garantir que seu sistema continua funcionando a cada nova submissão de código? Em outras palavras, como você pode garantir a integridade do seu software?

O quadrante do testes ágil

Já que falamos em testes automatizados, vale estendermos um pouco mais esta leitura e falarmos sobre outros tipos de testes. Brian Marick cunhou uma série de termos para as diversas categorias de testes conforme seu objetivo e os organizou em um quadrante denominado “Quadrante de testes ágil”.

Quadrante de Testes Ágil

Quadrante 1 (suporte ao time): Dentro deste quadrante podemos agruprar os testes de unidade (que validam métodos) e os testes de componentes (que podem validar classes ou grupos de classes). Estes testes se caracterizam por serem executados muito rapidamente e por darem um ótimo feedback sobre a qualidade do código.

Quadrante 2 (suporte ao time): Ainda visando o suporte ao time, neste quadrante ficam os testes que envolvem a qualidade externa do software. Normalmente estes testes são focados no negócio e também podem ser automatizados. Outra possibilidade aqui é termos especialistas em UX criando wireframes e protótipos para validação junto ao cliente.

Quadrante 3 (crítica ao produto): Assumindo que seus testes de unidade e testes funcionais estejam passando 100%, mesmo assim pode ocorrer de seu software não atender realmente a necessidade do usuário. Neste quadrante os testes irão criticar o produto e normalmente serão feitos por usuários reais. Estes testes podem fazer parte da definição de pronto de uma funcionalidade.

Quadrante 4 (crítica ao produto): Os testes neste quadrante são mais técnicos e criticam o produto em termos de performance, carga e segurança. Ou seja, cada parte do seu código foi testada (unidade e componente) e você criou testes para garantir que seu software entrega o que o usuário precisa. Legal! Agora, seu software funciona adequadamente para a quantidade de usuários esperada?

Code review / code inspection

Em alguns projetos da Lambda3 temos a prática de revisão de código definida no fluxo de desenvolvimento. Esta é uma atividade em que um desenvolvedor analisa um código que não é seu em busca de defeitos e/ou corrupção de padrões e/ou oportunidades de melhoria. Esta prática funciona especialmente bem quando seu time não está tão equilibrado em termos de conhecimentos dos participantes. Ou seja, você pode determinar que os membros mais experientes revisem as requisições de submissão daqueles que possuem menos experiência no ambiente. No entanto, mesmo que seu time seja composto apenas pelos melhores especialistas, ainda sim você pode encontrar vantagens em colocar esta prática para funcionar. Desenvolvedores profissionais adoram receber feedback sobre seu código.

Integração contínua

Integração contínua é obrigatória! Ok, seu time trabalhou duro criando testes automatizados, então vocês devem possuir um ambiente de integração contínua. Este ambiente irá maximizar as vantagens de possuir uma boa bateria de testes automatizados para seu software.

Martin Fowler define integração continua da seguinte forma:

“Integração Contínua é uma pratica de desenvolvimento de software onde os membros de um time integram seu trabalho frequentemente, geralmente cada pessoa integra pelo menos diariamente – podendo haver multiplas integrações por dia. Cada integração é verificada por um build automatizado (incluindo testes) para detectar erros de integração o mais rápido possível. Muitos times acham que essa abordagem leva a uma significante redução nos problemas de integração e permite que um time desenvolva software coeso mais rapidamente.”

Dependendo do tamanho do seu projeto, a execução dos testes (especialmente os testes de aceitação) pode demorar alguns bons minutos e este é um dos sinais que devem levá-lo a pensar em um servidor de IC (integração contínua). Este servidor será o responsável por baixar todos os fontes a cada commit e realizar os testes. Em caso de sucesso do build, opcionalmente, o processo ainda poderia realizar o deploy em um ambiente de desenvolvimento/homologação com a última versão do código. Isso pode ser feito a cada commit, uma vez por dia ou da forma como for mais apropriado para seu time.

Conclusões

Este artigo apresentou rapidamente algumas práticas que podem ser utilizadas para incluir qualidade/integridade em seu processo de construção de software. Também falamos do triângulo das restrições e como ele pode ser uma boa ferramenta para apoiar uma discussão sobre ações que visam aumentar qualidade no processo de desenvolvimento de software.


Data da publicação: 25/06/2014

  • Marcelo Palladino      
    Lambda3
    public class Palladino: SerHumano, Pai, Esposo, EmpreendedorNasHorasVagas, Gamer, Programador, Lambda { }.


Gostou do artigo? Para receber nossos informativos clique aqui.

Treinamentos abertos

JUN 6

Certificação Lean IT (online ao vivo)

19h às 21h

São Paulo - SP

Todos os treinamentos
Certificação Lean IT
Treinamento Lean IT - Formação de Times Ágeis

Depoimentos

O curso é uma ótima oportunidade de refletir sobre como melhorar os meus processos, simplificando e eliminando o que não gera valor para meus clientes. Gostei bastante de conhecer o histórico dessa jornada Lean na Manufatura e na indústria de Software.

Pierre Simon
IT Services Manager
Leroy Merlin

Fizeram um reconhecimento detalhado de minha necessidade em pontos cruciais e agregaram muito conhecimento. Levaria muito mais tempo para chegar lá sem a experiência e vivência proporcionados pelos treinamentos da Lean IT. Recomendo fortemente.

Júlio Calsinski
Diretor
SCIA

Fazer o curso de Certificação Lean IT foi uma das melhores escolhas que fiz para aprender mais sobre agilidade, geração de valor e foco no cliente. É um treinamento dinâmico que traz situações reais do dia a dia, além de uma excelente didática.

Adriana Borba
Coordenadora Governança
Generali Seguros

As metodologias ágeis fazem parte deste meu “novo mundo, movido a uma pitada do novo normal”... Por isso, indico sempre que procurem a solução mais adequada para se capacitar.

Camila Saraval
Analista de Educação
Bradesco

O Curso de OKR traz uma perspectiva de extrema importância nesse momento em que muitas empresas estão descobrindo e construindo suas Transformações Digitais, se mostrando uma ferramenta poderosa na influência da cultura organizacional através do desdobramento de ideais (intangível) para a direcionamento prático dos times.

Brisa Lorena
Analista de processos
Unimed BH

A certificação é excelente. Recheado de exemplos que vão fazer você olhar os processos da sua empresa sob outra ótica. Recomendado a todos que buscam otimizar processos e eliminar desperdícios.

Filipe Machado
Scrum Master
Grupo GFT

Com a implantação do OKR na Viceri tivemos ganhos significativos no desempenho da empresa. Participei do curso de OKR da Lean TI e foi esclarecedor. Recomendo a todas as empresas!!!

Marcel Pratte
CEO
Viceri

Eu achei o curso de times ágeis muito bom. De todas as iniciativas de agilidade, foi a que mais fez sentido pra mim, a que mais me pareceu trazer real benefício, pois mudava o processo de desenvolvimento, e não de administração do processo.

Rodrigo Canellas
Software Developer

One Piece Flow


Veja mais vídeos

Conheça o A3 Ágil

A3 Ágil

Cadastre seus A3 Grátis

Lean Score - Desdobramento da estratégia

Gerencie seus OKRs

KSMED

Ao continuar utilizando o site www.leanti.com.br você concorda com nosso aviso de privacidade e cookies. Saiba mais

A Empresa

  • Sobre nós
  • Sistema Toyota de Produção
  • Saiba mais sobre Lean
  • O que é Lean IT?

Receba nossos informativos

Cadastre seu e-mail e receba nossas promoções

   

Empresas parceiras:

BIP Consultoria | Heat Advogados | Idest Gestão | BIM Works


Contato

(11) 2528-2354

contato@leanti.com.br

Rua Funchal, 203 - Conj 111
CEP: 04551-904
São Paulo - SP
CNPJ: 22.316.429/0001-25

2012 - 2022 Copyright - Todos os direitos reservados - Aviso de Privacidade e Cookies