c )
Desde o advento da indústria de tecnologia, ela procura a "Baleia Branca" - a métrica trabalhista dos desenvolvedores. Talvez o próprio desejo de contar programadores de KPI tenha nascido de uma frase comum nos negócios tradicionais: "Você não pode planejar, se não puder medir".
Após as centenas de KPIs diferentes que os programadores estavam tentando contornar, surgiram muitos métodos diferentes para analisar dados operacionais - desde o rastreamento da direção da aparência do monitor até Scrum e Kanban. As medições da qualidade do trabalho funcionaram tão bem em muitos setores que parecia lógico transferir essa experiência para o desenvolvimento de software. O resultado foi desanimador.
Medir e gerenciar a produtividade do desenvolvedor não levou a um único padrão internacional de qualidade. As empresas de TI de alta tecnologia estão desenvolvendo suas próprias métricas ... algumas delas são quase impossíveis de comparar com os KPIs tradicionais em outros campos de atividade.
Neste artigo, falaremos sobre as métricas atuais mais interessantes e sobre as "métricas" em TI.
Já é difícil encontrar (pelo menos em código aberto) informações sobre como usar o número de horas trabalhadas, o número de linhas no código-fonte (SLOC), Pontos de Função ou o número de bugs criados por cada desenvolvedor como uma métrica.
No discurso público, foi possível chegar a um consenso de que trabalhar mais
não significa trabalhar melhor, que uma solução com 200 linhas de código pode ser mais rápida ou produtiva do que uma solução com mil linhas, e a métrica de Pontos de Função criada em 1979 está irremediavelmente desatualizada.
Mas o que aconteceu com o desejo de medir e calcular tudo? Aparentemente, não desapareceu.
Netflix
c )
A Netflix se concentrou em superar as barreiras que separam os usuários do conteúdo. Sempre que algo o impede de assistir ao próximo episódio de sua série favorita, os desenvolvedores corrigem o problema e medem o tempo necessário para resolvê-lo.
A plataforma de streaming testa novas idéias em termos reais e mede as diferenças estatisticamente significativas nas interações do usuário com o produto. Além disso, erros no estágio de testar hipóteses são bastante aceitáveis - "o único erro real que é inaceitável na Netflix é a incapacidade de inovar".
O desenvolvimento de produtos na Netflix começa com uma hipótese parecida com esta:
Algoritmo / função / design (×) aumentam a interação dos assinantes com o serviço e, finalmente, sua retenção.
A hipótese pode ser aumentar a relevância dos resultados da pesquisa, usar um novo design para interfaces de usuário ou um novo recurso - por exemplo, mostrar aos participantes o que seus amigos das redes sociais estão vendo na Netflix. A intuição e uma idéia de como melhor prestar serviços aos assinantes se tornam a base da abordagem de desenvolvimento.
A segunda etapa de desenvolvimento é escrever um teste que mede o impacto da hipótese. Às vezes, isso significa que você pode criar imediatamente um protótipo que reflete a essência do conceito, o que permitirá que você teste rapidamente a hipótese e se esforce para criar uma solução melhor.
O terceiro passo é o próprio teste, no qual centenas de milhares de espectadores podem participar. O protótipo é implantado para os participantes do experimento por um determinado período de tempo. Ele pode ter duas coortes para testes ou 20, cada uma das quais usa uma abordagem diferente ou mistura novos elementos diferentes. Dezenas de testes de consumidor diferentes podem ser lançados a qualquer momento.
Mesmo uma falha na hipótese é considerada um resultado alcançado. Consequentemente, a probabilidade de que a hipótese a seguir se torne melhor apenas aumenta. A equipe de desenvolvimento tem grande liberdade na aplicação de idéias ao produto por um longo período de tempo.
Ibm
c )
A métrica mais antiga e mais "óbvia" para o desenvolvimento de software é contar o número de linhas produzidas por um desenvolvedor ou equipe individual e a quantidade de tempo gasto nela. Essa métrica foi usada pela primeira vez pela IBM. No documentário Triumphof the Nerds: The Rise of Accidental Empires, Steve Ballmer observou que, nos anos 80, a IBM parece ter transformado a religião nesse indicador.
Em 2011, a IBM
introduziu uma ferramenta para analisar automaticamente o código-fonte quanto ao desempenho, segurança e complexidade técnica. Os desenvolvedores cujo código foi o mais alto classificado receberam a maior pontuação do sistema. Os indicadores de baixo desempenho serviram como um sinal para prestar atenção ao treinamento dos funcionários (a IBM alegou que uma pontuação final baixa não foi usada como punição).
No entanto,
publicações posteriores dão a impressão de uma mudança de paradigma - a metodologia para construção de hipóteses já é mencionada no cerne do desenvolvimento. O desenvolvimento hipotético não pode prescindir da perda de tempo e recursos.
O principal nessa métrica é o feedback do cliente sobre o produto. Precisamos focar no que é mais importante para os clientes e abandonar as funções que não são benéficas ou até interferem nos usuários. Essa estratégia está representada no diagrama acima.
Spacex
c )
As informações sobre o trabalho dos desenvolvedores no SpaceX são extremamente pequenas, o que está associado ao sigilo geral dos projetos dessa empresa não pública. Mas, de acordo com
informações indiretas, você pode entender os contornos aproximados da imagem geral. E essa imagem fala da importância dos testes.
Na ciência dos foguetes, os testes são a base do design. No software de programação para foguetes,
os mesmos princípios são usados . Por exemplo, se o foguete pousasse com segurança, todas as equipes responsáveis pelo desenvolvimento concluíram o KPI. Sem testes preliminares, não é possível concluir com êxito esse projeto.
Dados os problemas enfrentados pelas equipes envolvidas na preparação de equipamentos para o ambiente espacial hostil, não é difícil entender qual é a responsabilidade deles.
A SpaceX está
tentando paralelizar o código entre diferentes projetos - com esse paradigma de desenvolvimento, a correção de erros de um projeto (relativamente falando, foguetes) se estende automaticamente a outros projetos.
A empresa escolheu C ++ como a principal linguagem de programação. Primeiro, ele permite que você contrate muitos desenvolvedores de alto nível, pois o idioma ainda é relativamente popular. Ao mesmo tempo, a escolha é muitas vezes feita em favor dos desenvolvedores de jogos que estão acostumados a escrever código e trabalhar em ambientes com memória e poder de computação limitados.
Em segundo lugar, eles se beneficiam do grande ecossistema C ++. Não há necessidade de criar software especial quando você pode usar ferramentas conhecidas há muito tempo, como gcc e gdb.
E, finalmente, no desenvolvimento, é dada muita atenção aos testes de métricas. Os desenvolvedores e engenheiros são aconselhados a verificar a segurança e a tolerância a falhas em tudo o que você pode imaginar.
Os dados coletados durante o teste são armazenados junto com o código-fonte que funcionou durante os testes. Se ocorrer algum mau funcionamento durante o teste de foguete, o SpaceX poderá recriar o ambiente exato de inicialização, reproduzir o problema e corrigi-lo.
A integração contínua é usada para testar automaticamente todo o código. Eles ainda têm plataformas de teste com todos os componentes do motor para simular completamente a partida e detectar possíveis problemas.
Amazônia
A Amazon tem uma das estratégias mais interessantes descritas nesta entrevista de 40 minutos com o diretor do AWS Developer Tools.
A idéia principal de formar equipes de desenvolvimento é a escala mitótica. As equipes são divididas em grupos menores, preservando totalmente a continuidade e as funções das equipes "mãe".
Jeff Bezos, CEO da AWS Developer Tools,
acredita que uma equipe ideal não deve incluir mais pessoas do que duas pizzas podem preencher.
Em equipes pequenas, a comunicação é muito mais eficaz, elas permanecem descentralizadas, independentes, desenvolvem-se mais rapidamente e introduzem inovações.
A Amazon originalmente possuía uma arquitetura monolítica e de software (Perl / Mason / C ++). Em seguida, a arquitetura foi decomposta em serviços e a estrutura da organização em equipes de pizza. Portanto, o serviço de nuvem Amazon Elastic Compute Cloud (Amazon EC2) foi formado por um grupo composto por apenas duas "equipes de pizza".
A Amazon está comprometida em automatizar totalmente todos os processos (compilação, implantação, transferência de confirmação etc.). Dentro de cada implantação, vários tipos diferentes de testes são usados: integração, navegador, web e carregamento. Assim, tudo é controlado e medido.
A segurança é monitorada durante todo o processo de lançamento do produto, e é por isso que é perfeitamente normal que a Amazon "pense como um engenheiro de segurança" em qualquer cultura da Amazon. Ao iniciar um novo projeto, os desenvolvedores trabalham principalmente no modelo de arquitetura e ameaça.
As validações são incorporadas a todos os pipelines por meio de uma combinação de políticas de confiança locais e globais. O líder pode definir de forma independente a política de auditoria para sua equipe (por exemplo, antes da implantação, cada novo commit deve ser coberto por testes de unidade em 70%).
Ao mesmo tempo, existem regras gerais da Amazon que cobrem todas as implantações (por exemplo, uma proibição de implantação única em cada região).
São os desenvolvedores da equipe, e não o arquiteto, os responsáveis pela arquitetura do projeto. E só então é considerado por um arquiteto ou engenheiro-chefe. A mesma situação com segurança e teste: a equipe gerencia todo o processo. Embora essa abordagem tenha um sinal de menos, que consiste em um longo período de treinamento.
A cada ano, as equipes preparam um plano operacional em seis páginas (esses "planos de negócios" são apresentados em todos os níveis da Amazônia). O plano indica o que será realizado no próximo ano com recursos fixos e o que poderá ser alcançado com recursos adicionais. Os gerentes coletam documentos de seis páginas de todas as equipes que gerenciam, criam seus próprios documentos de seis páginas e os submetem à gerência - e assim por diante até Jeff Bezos. Na direção oposta, os recursos são alocados para as equipes.
O que as startups têm lá
Graças às pesquisas
conduzidas pela Stackify (uma plataforma em nuvem para monitorar e solucionar problemas de aplicativos da web), foi possível descobrir a atitude em relação às métricas em algumas start-ups e empresas conhecidas como "intermediárias".
O CircleCI é um serviço popular de integração contínua, incluindo na Rússia, com configurações flexíveis para aplicativos da Web e móveis. Rob Zuber, CTO CircleCI, acredita que a melhor métrica para medir a produtividade e a eficácia do desenvolvimento de software é uma medida do tempo que leva para o código ir do comprometimento à implantação - tempo de comprometimento para implantação (CDT).
O objetivo de medir o CDT é “rastrear” as barreiras à implantação. Idealmente, se você usar automação e / ou testes de boa qualidade, poderá ir para a implantação em minutos (ou até segundos) para um microsserviço. Se você usa principalmente o processo de controle de qualidade manual, isso provavelmente significa que a implantação levará mais tempo.
A análise CDT do CircleCI mostra onde encontrar oportunidades de melhoria. As melhorias podem ser mais técnicas (por exemplo, tornar os testes mais eficazes), mais orientadas ao processo ou uma combinação de ambas. Quanto menor o seu commit, mais rápido eles podem ser lançados, respectivamente, mais rápido você pode corrigir a situação se algo der errado.
A Adeva é uma empresa de recrutamento e formação de equipes de desenvolvimento prontas para startups. Para oferecer um melhor serviço aos clientes, ela pesquisa métricas de desempenho de programadores há vários anos. A conclusão é simples: não há uma medição formal e objetiva da eficácia e produtividade do desenvolvimento de software.
Em vez de usar o KPI, o Adeva organiza breves reuniões com os desenvolvedores, nas quais a gerência ouve cuidadosamente histórias sobre conquistas e falhas. Para determinar a eficácia do departamento como um todo, os desenvolvedores são questionados sobre a utilidade e a conscientização do restante da equipe. Nessas reuniões, todos podem expressar idéias que podem ajudar a si mesmos e a outros membros da equipe.
Além das comunicações interpessoais, a Adeva analisa como o código do desenvolvedor se integra à base de códigos, verifica seu desempenho, segurança e determina se o código terá um custo menor de serviço a longo prazo.
A Scorchsoft, uma desenvolvedora inglesa de aplicativos para web e dispositivos móveis, estima os prazos de entrega do projeto. Como a maioria dos clientes da Scorchsoft espera receber um produto a um preço fixo, a empresa deve identificar imediatamente uma especificação clara e inequívoca. O desempenho é medido em termos de tempo de desenvolvimento com base nas ferramentas Toggl (rastreador de tempo) e Jira.
Um projeto é considerado bem-sucedido se o cliente estiver satisfeito e a equipe cumprir o prazo.
Conclusão
Às vezes, com a avaliação das métricas, você ainda pode chegar a um denominador comum - esse é um foco no conforto do usuário. Em vez de tentar medir diretamente a produtividade do programador, o foco está em medir tudo o que impede o progresso na entrega de valor ao cliente.
Quando o cliente final é o principal indicador de sucesso, é muito mais fácil usar métricas provenientes do marketing: taxa de conversão, comportamento do usuário ou avaliações de classificação. Nesta área, o sucesso depende em grande parte da administração, que pode tomar a decisão errada. Por exemplo, o desenvolvimento de uma função que não é necessária para o cliente tem um impacto muito mais negativo nos negócios do que um desenvolvedor que se destaca dos "padrões".