Além do SCRUM – Kit Ágil para Agilistas

O Scrum, método ainda pensando em 1986 no seminal artigo The New New Product Development Game, ganhou muito popularidade no Brasil nos últimos anos e disseminou alguns valores e princípios ágeis entre times de projetos em tecnologia da informação. O universo de métodos ágeis, entretanto, é muito mais vasto que as práticas apresentadas pelo Scrum. Compilo neste artigo algumas referências importantes para agilistas que queiram avançar nas práticas e valores de métodos ágeis.

  1. Livro Peopleware, de Tom de Marco. Um clássico escrito nos anos 70 e reeditado em 2013 que apresenta princípios e práticas da liderança efetiva de pessoas em TI e organização de times.
  2. O blog de Allistair Cockburn, que nos apresenta um grande número de informações de primeira linha sobre métodos ágeis e a sua excelente (mas pouco conhecida) metodologia Crystal. Recomendo, sobre este método, o excelente livro Crystal Clear: A Human-Powered Methodology for Small Teams: A Human-Powered Methodology for Small Teams.
  3. A página do método Entrega Ágil Disciplinada, do famoso agilista Scott Ambler, que apresenta um conjunto de práticas que estendem o Scrum para situações complexas de projetos de TI e realidades culturais diversas.
  4. Manufatura enxuta para desenvolvimento de software, que fornece poderosos princípios para redução do tempo de ciclo na entrega de software e redução de desperdícios. Um artigo introdutório ao tema é apresentado aqui e alguns excelentes livros sobre o tema foram escritos pelo casal Poppendick – Agile Toolkit,  Implementing the Lean Software Development e Leading Lean Software Development.
  5. Os artigos do Uncle Bob (Robert Martin), muito sensatos, e os seus clássicos livros Clean Code e Clean Coder.
  6. O trabalho de extensão de métodos ágeis para o nível organizacional descrito no excelente trabalho do método ágil corporativo Scale Agile Framework.

 

O radar técnico da ThoughtWorks, em português

A ThoughtWorks possui uma excelente publicação técnica, com tendências tecnológicas em técnicas, linguagens, plataformas e ferramentas de desenvolvimento de software. Originalmente publicado em inglês, esteve inacessível àqueles não versados na língua do Tio Sam. Felizmente, eles lançaram o novo Radar Técnico também em português.

Neste radar, de Janeiro de 2014, os temas centrais por eles pontuados são:

Alerta e recuperação antecipados em produção – Estamos observando uma infinidade de novas ferramentas e técnicas para capturar logs, monitorar, armazenar e consultar dados operacionais. Quando combinadas com uma rápida recuperação oferecida pela virtualização e automação de infraestrutura, as empresas podem reduzir a quantidade de testes necessários antes da implantação, talvez até mesmo executando os testes no próprio ambiente de produção.

Privacidade versus Big Data – Ao mesmo tempo em que estamos animados com as novas perspectivas de negócio possibilitadas pela coleta exaustiva de dados, também estamos preocupados com o fato de muitas empresas armazenarem grande quantidade de dados pessoais desnecessariamente. Defendemos que as empresas adotem uma atitude de “datensparsamkeit” e armazenem apenas o mínimo de informações pessoais necessárias sobre seus clientes.

O rolo compressor do JavaScript continua – O ecossistema em torno do JavaScript continua evoluindo como uma importante plataforma de aplicação. Muitas ferramentas interessantes têm surgido para testes, gerenciamento de dependências e construção de aplicações JavaScript, tanto do lado servidor, como do cliente.

A fusão do mundo físico e digital – dispositivos de baixo custo, plataformas de hardware aberto e novos protocolos de comunicação estão levando a experiência de usar um computador para mais perto do mundo ao nosso redor, longe das telas. Um grande exemplo é a proliferação de dispositivos vestíveis para rastrear dados biométricos e o suporte de hardware em outros dispositivos móveis, como telefones e tablets, para interagir com os mesmos.

Embora muitas das tecnologias do radar ainda sejam muito exóticas para a maior parte do público de TI do Brasil, é notável a tendência de crescimento do JavaScript, que também tenho observado em relatório do Gartner e até da nossa base pessoal de projetos e da observação de clientes. É o JavaScript, criado na quinta divisão do futebol inglês e que caminha a passos largos para a Champions League da tecnologia.

Para os curiosos, o relatório pode ser baixado neste sítio.
Boa leitura nerd, agora em português!

Desenvolvedores Frágeis. Você é um deles?

O discurso de métodos ágeis nunca esteve tão popular no Brasil. Isto é muito bom e demonstra que estamos questionando os clássicos métodos da engenharia de software estabelecidos ainda no fim dos anos 60 nas famosas conferências de engenharia de software da OTAN.

É lamentável, entretanto, que pessoas sem as mínimas noções de engenharia de software e muito menos de métodos ágeis levantem bandeiras como se fossem do seu time de futebol ou partido político preferido por simplesmente desconhecer e não aplicar técnicas ágeis.

Baseado nas essências de técnicas ágeis sólidas de métodos como o XP e a Entrega Ágil Disciplinada, coloquei aqui um teste de fragilidade técnica. Notas baixas indicam um desenvolvedor pseudo-agilista que carrega uma bíblia mas sem saber nem o pai-nosso e a ave-maria de cada dia.

Teste de Fragilidade – Proibido para garotos enxaquecas que somente reclamam da vida, do chefe e do governo…

Para cada resposta A, some 3 pontos.
Para cada resposta B, some 2 pontos.
Para cada resposta C, some 1 ponto.
Para cada resposta D, não some pontos.

  1. O código fonte é o ativo mais importante resultante do trabalho do seu dia a dia. Você cuida dele apropriadamente? Se sim, quantas vezes por semana você aplica técnicas de refatoração sobre ele?
    1. 5 vezes. [Dou banho todo dia no meu código e observo métricas de qualidade de código como complexidade ciclomática com rigor]
    2. 3 ou 4 vezes [Ok. Às vezes me esqueço de dar banho no meu código.]
    3. 1 ou 2 vezes [Então. Sou meio porquinho e não gosto muito de tomar banho e não me importo com o mau cheiro dos meus códigos também.]
    4. 0 vezes [Refatoração? O que é isso?]
  2. Defeitos são indesejados e podem ser comparados a resíduos industriais de empresas ou baratas em esgotos. Você tem disciplina de testes de desenvolvimento? Se sim, quantas vezes por semana você cria testes de unidade e executa testes de regressão sobre o seu código?
    1. 5 vezes. [Piso em toda barata que vejo na rua! Portanto só saio do escritório com o teste de regressão executado com sucesso.]
    2. 3 ou 4 vezes [Sou atento e gosto de fazer testes de unidade mas às vezes falho para executar smoke testes e testes de regressão no fim do dia]
    3. 1 ou 2 vezes [Então. Sou meio preguiçoso para criar testes de unidade. Gosto de inventar desculpas e acho que isso é problema dos analistas de testes chatos que só fazem pegar no meu pé]
    4. 0 vezes [Regressão? Tem a ver com vidas passadas, certo?]
  3. Desenvolvedores normalmente trabalham em times e criam projetos através de repositórios como SVN, Microsoft TFS ou GIT. Quantas vezes por semana você tem contato com o seu repositório SCM?
    1. 5 vezes. [Desço e subo código todo dia, conheço e uso padrões SCM com excelência.]
    2. 3 u 4 vezes [Ok. Ás vezes deixo o meu código na minha máquina antes de ir embora para casa. Gosto de viver emoções fortes]
    3. 1 ou 2 vezes [“I’m a cave man. I’m a jungle man. A young man. A young man. I fight with my hands….”, Homem Primata, Titãs, Cabeça de Dinossauro.]
    4. 0 vezes. [SVN? Isso é marca do novo isotônico, certo?]
  4. Desenvolvedores normalmente trabalham em linguagens OO como Java, C# ou mesmo em linguagens híbridas OO-Procedural como C++ ou PHP. Quantas vezes por semana realizo modelagem ágil e organizo apropriadamente o meu modelo de classes executável?
    1. 5 vezes [Conheço padrões de análisepadrões de desenho e padrões GRASP e os uso com parcimônia sobre os meus códigos. Além disso, faço junto do meu time diversas sessões de modelagem com o uso de quadro branco]
    2. 3 ou 4 vezes [Gosto e aplico sessões de modelagem ágil, mas ainda não conheço plenamente técnicas de padrões e modelagem]
    3. 1 ou 2 vezes [Veja bem, a minha empresa não tem quadro brancos, nem cartolinas, nem papel, nem caneta? O que posso fazer?]
    4. 0 vezes [Comunicar com outros seres humanos em sessões de modelagem? Não, obrigado. Programar para mim é uma atividade individual. A propósito, o que é parcimônia mesmo?]
  5. Times ágeis entregam software funcionando em pequenos incrementos para os seus usuários com o uso de técnicas como integração contínua ou entrega contínua. Quantas vezes por semana você gera produtos potencialmente demonstráveis (Alfas ou Betas) para o seu Product Owner, Analista de Negócio ou cliente.
    1. 5 vezes. [Me espelho em projetos como a IDE Eclipse, que tem quase 50 milhões de linhas de código, é construído de forma distribuída no mundo inteiro e ainda assim gera produtos em base diária]
    2. 3 ou 4 vezes [Gosto de liberar produtos com frequência para demonstração para o PO, mas tenho dificuldades em fazer isso e às vezes falho]
    3. 1 ou 2 vezes [Estou começando a aplicar esta técnica, mas ainda tenho um longo caminho para trilhar neste aspecto.]
    4. 0 vezes [Veja bem. Na minha empresa tudo é impossível fazer isso e além disso você já sabe que gosto de inventar desculpas para enrolar no meu trabalho, não é]
  6. A priorização de requisitos e o cumprimento de acordos das metas dos sprints e metas diárias é parte indissociável de todo desenvolvedor ágil? Quantas vezes por semana você conversa com o seu time para reportar as metas diárias, impedimentos e o progresso em relação às metas semanais.
    1. 5 vezes [Faço stand-up meetings faça sol ou faça chuva. Cumpro religiosamente as minhas metas diárias e reporto impedimentos imediamente quando os mesmos surgem]
    2. 4 vezes [Ainda não tenho tanta disciplina e às vezes falho em cumprir minhas metas diárias e em me comunicar com o meu time.]
    3. 1 ou 2 vezes [Então. Tenho dores de barriga com frequência, estudo à noite e minha namorada fica me ligando toda hora. Não tenho tranquilidade para produzir código e portanto falho as minhas metas com frequência]
    4. 0 vezes [Já não te disse que não gosto de conversar com outros seres humanos!! *$*##&@)# ]
Se você fez 15 ou mais pontos, parabéns, você é realmente ágil. Continue assim.
Se você fez entre 10 e 14 pontos, você já compreendeu os princípios ágeis, mas ainda precisa se disciplinar e disciplinar o seu time.
Se você fez entre 5 e 9 pontos, sinto lhe informar que você é tão ágil quanto uma sucuri que acabou de comer uma paca de 40 kilos. É hora de acabar com a nhem-nhem-nhem e aplicar técnicas ágeis para valer.
Se você fez até 4 pontos, você é definitivamente frágil e precisa estudar seriamente os princípios e técnicas ágeis antes de sair por aí fazendo propaganda de métodos ágeis.

Os Sete Pecados Capitais do Desenvolvimento de Software

O quadro o Jardim das Delícias Terrenos é um dos mais impactantes quadros a avisar aos transgressores da fé católica o destino deles ao final de uma vida impura. Obra-prima de quase 2 metros de altura e largura, o quadro retrata o inferno dos luxuriosos, gulosos, avarentos, invejosos, preguiçosos, iracundos e vaidosos.

O Jardim das Delícias Terrenas
Obra prima de Hieronymus Bosch, pintor holandês contemporâneo de Leonardo da Vinci

 

Se a engenharia de software tivesse um inferno, poderíamos nos arriscar, como Dante Aligheri, a descrever os sete pecados capitais do desenvolvimento de software que os porquinhos de software cometem em base diária. Mary Poppendieck, uma das autoras doLean Software Development, descreva 7 formas de desperdício no desenvolvimento de software. Apresento e contextualizo estes pecados capitais abaixo no dia a dia do trabalho de software.

1. Funcionalidades extras. Pesquisas de institutos como o Standish Group (XP Conference, 2002) mostram que metade das funcionalidades de um software são raramente ou nunca usadas. Ainda assim, é muito comum que desenvolvedores “criativos” introduzam funcionalidades não desejadas em seus software que não trazem valor agregado algum para os seus clientes. A redução do desperdício tem forte relação com escrever menos linhas de código.

2. Transferência de responsabilidades, conhecimentos, ações e feedbacks. O uso de papéis muito especializados é um sintoma deste problema. “Arquitetos” e “projetistas” que não sabem codificar, “desenvolvedores” que não sabem testar ou implantar software e “gerentes de projeto” que se orgulham de não entrar em temas técnicos são exemplos de handovers (repassese fontes comuns de desperdício.

3. Defeitos. Se orgulhar de ter um time de testes que encontra muitos defeitos é no mínimo contra-produtivo. Devemos nos lembrar que defeitos são desperdícios, ou dinheiro jogado fora. As ações de projetos devem impedir que defeitos sejam introduzidos em primeiro lugar, e não focar em pegar defeitos ao final.  Um exemplo simples é no ciclo tradicional de especificação, codificação e testes. Ao invés, o teste deve validar e corrigir a especificação antes que a primeira linha de código seja escrita, visto que a maior parte dos defeitos nasce ainda na especificação do software. Da mesma forma, é papel do desenvolvedor usar técnicas diversas (refatoração, teste de unidade e integração contínua) para reduzir a quantidade de defeitos introduzidas no software.

4. Débito Técnico. Fazer código de má qualidade tende a gerar débito técnico no código, módulo e arquitetura de um produto. O débito técnico gera um efeito muito ruim a médio e longo prazo e gera efeitos colaterais no produto em pontos não imaginados. Livros como “Clean Code”, do Robert Martin, exploraram a criação de código de qualidade

5. Trabalho em progresso. Manter uma longa lista de tarefas com o status em  ”execução” esconde problemas e eventualmente gera desperdício. Cada pessoa de um time deve manter o mínimo número de tarefas abertas. Cada tarefa aberta deve ser rapidamente terminada para reduzir o seu tempo de ciclo, evitar retrabalhos e trabalho multitarefa. Um exemplo vem da metodologia japonesa chamada Kanban, que introduz o conceito chamado (WIP). O WIP (Work In Progress) tem um valor limite pequeno (tipicamente 3) e impede que uma pessoa tenha mais de 3 tarefas em execução. Um outro exemplo de combate a este desperdício é a prática de entregar software com frequência para os usuários chave, que limita o tamanho do backlog de tarefas em aberto para todo o time de desenvolvimento.

6. Trabalho multitarefa. Há algum tempo este mito assola os times de software, atolados no trabalho de novas demandas e na resolução de defeitos e adaptações de diversos softwares em paralelo. Estudos diversos mostram que o fator multitarefa reduz a produtividade, gera desmotivação e trabalho de pior qualidade, o que introduz mais defeitos e gera mais trabalho em progresso.

7. Esperas e atrasos. Provocar esperas e atrasos gera um efeito nocivo na produtividade do time e é também uma forma de desperdício. Por exemplo, enviar um email para uma equipe de desenvolvimento validar um documento de casos de uso gera espera, atraso e descontinuidade do trabalho. Apresentar este documento ao vivo melhora o entendimento para todos e também reduz ciclo de validação do documento gerado. Allistar Cockburn descreve a prática chamada de “Radiadores de Informação” em seu método ágil chamado Crystal Clear, que consiste em manter pessoas próximas e privilegiar a comunicação ao vivo com o uso de quadros brancos. Outros métodos ágeis como o Scrum ou o XP também advogam práticas similares.

Eliminar desperdícios é chave para gera software mais eficaz e em menos tempo para clientes. Um bom livro sobre este tema é o livro: Implementing Lean Software Development: From Concept to Cash, de Mary e Tom Poppendieck.

Lean Software Development

O Débito Técnico Arquitetural

Uma arquitetura de software executável é o conjunto de códigos executáveis que suportam os requisitos (casos de uso, estórias do usuário ou telas) mais importantes para o negócio e que afetam os elementos técnicos de um sistema em amplitude. Idealmente, a construção de uma arquitetura executável deve possuir códigos para todos os mecanismos arquiteturais identificados em uma arquitetura candidata (documento de arquitetura de software ou caderno arquitetural). Um mecanismo arquitetural é uma tática técnica importante para o desenvolvimento de uma solução de software, como por exemplo a autenticação em sistemas de home banking, a usabilidade facilitada em redes sociais ou a eficiência operacional na entrada de dados em call-centers.

O mundo real e a pressão por entregas em produção, entretanto, é implacável. Gerentes e clientes pressionam os times técnicos por prazos cada vez mais arrojados. Como mágicas e unicórnios não existem, uma técnica chamada de gestão do débito técnico arquitetural pode ajudar nesta questão.

Débito Técnico Arquitetural

Uma arquitetura de software ideal implementa táticas arquiteturais. Uma arquitetura evolutiva, ao invés, implementa m|m < n táticas arquiteturais. Uma tática arquitetural deliberadamente ausente será adiada na primeira entrega em produção. Esta ação irá gerar dois efeitos (um positivo e um negativo).

  • O atendimento a prazos de negócio como por exemplo regulações ou pressões da área de marketing de uma empresa para lançar um novo produto;
  • Um produto que deve um atributo de qualidade não realizada por alguma tática. Por exemplo, um código com manutenibilidade reduzida ou uma aplicação Web com ausência de portabilidade entre navegadores.

Os Juros do Banco Arquitetural

O banco arquitetural cobra juros altos, proporcionais ao tamanho do sistema em termos de seus requisitos e o custo da refatoração de cada caso de uso.

Débito Arquitetural = ƒ (Número de Requisitos, Custo Médio de Refatoração Arquitetural por Requisito)

Como exemplo, se um sistema tem 70 telas e o custo de refatoração e testes para portabilidade ao navegador Chrome é de 8 horas por caso de uso, temos um débito arquitetural de 560 horas. Se o custo médio de um profissional de uma fábrica de software é de 60 reais, então podemos até quantificar o débito técnico da arquitetural em R$ 33.600 reais.

É importante lembrar que que sistemas crescem em termos de suas funcionalidades ao longo do tempo e portanto o débito aumenta à medida que o tempo aumenta. Este aumento não é linear pois quanto mais tempo decorre menor se torna o conhecimento sobre os atributos de qualidade originalmente implementados, i.e., o custo de unidade da refatoração também tende a aumentar.

Ir ou não ao Banco Arquitetural?

Se o benefício de negócio é maior que o débito técnico gerado, então o uso de uma arquitetura evolutiva pode se tornar um bom negócio para a empresa. Embora isso incomode os engenheiros de software e arquitetos mais puristas, é importante entender que um projeto de software é apenas uma engrenagem no contexto de uma empresa e que muitas vezes o débito pode ser tornar uma questão de sobrevivência empresarial.

Por exemplo, se no exemplo anterior a área de marketing estimou que um produto lançado 2 meses antes devido a ausência de suporte ao Chrome poderá gerar R$ 100.000 reais de benefícios de negócio, então a portabilidade multi-navegador poderia ser hipoteticamente adiada para uma v2.0 do produto. O lucro com a decisão poderia gerar quase R$ 70.000 reais para a empresa, descontados já o pagamento do débito.

A análise no mundo real, naturalmente, deve ser mais criteriosa e pode considerar uma análise quantitativa de riscos para incluir ao valor do débito arquitetural. A mensagem final, entretanto, é que arquiteturas evolutivas podem ser excelentes mecanismos para responder a pressões de mercado e atendimento a elementos regulatórios.