Como formar Times de alta performance

Como formar Times de alta performance: Diversas metodologias foram criadas para sistematizar o desenvolvimento de software. Tais metodologias podem ser divididas em tradicionais, que enfatizam a documentação de cada processo do desenvolvimento de software, ou ágeis, que consideram um novo paradigma de desenvolvimento de software. Os métodos ágeis focam em simplicidade, software funcional no início das iterações, flexibilidade e intensa comunicação, tanto internamente quanto com clientes. Além disso, aplicam o desenvolvimento iterativo e incremental, planejamento adaptativo, flexibilidade e rápida resposta a mudanças.

O Scrum é uma metodologia ágil para gerência de projetos, baseado em inspeção e adaptação, é iterativo e incremental, e pode ser aplicado a qualquer produto ou no gerenciamento de qualquer atividade complexa. Assim, o Scrum é um processo leve para gerenciar e controlar projetos de desenvolvimento de software e para criação de produtos. Cada iteração dura aproximadamente trinta dias, sendo conhecida como Sprint. Ao final de cada Sprint deve ser entregue ao cliente parte do produto concluído e funcional.

Times de Alta Performance é um conceito dentro do desenvolvimento das organizações referente a equipes, organizações ou grupos virtuais, que são altamente focados nas suas metas e alcançam resultados de negócio surpreendentes.

Não existe um modo de aplicar um questionário e dizer com certeza que um time é de alta performance. O cliente deve perceber a evolução dos times e reconhecê-los como tal. Para isso, é importante extrair informações e métricas que indiquem que o seu time está na direção certa, de modo que a avaliação do time não fique somente na percepção superficial do cliente e sim em uma percepção formada por fatos concretos.

Este artigo retrata técnicas e experiências em projetos Scrum relacionadas à formação de times de alta performance e demonstração de ganho para o cliente através de métricas de projeto.

Saiba mais: Teoria de gestão de equipes aplicado ao Scrum

Um dos principais assuntos em destaque nas mídias especializadas em gestão e TI (Tecnologia de Informação) é a construção de times de alta performance (HPT – High Performance Teams), como pode ser observado em fontes virtuais, quando o termo é procurado em algum “buscador” qualquer, sendo surpreendente o número de resultados relativamente retornados. Outra linha que também se destaca o assunto é a acadêmica, pelo número de trabalhos relacionados ao assunto atualmente.

Um exemplo de time de alta performance é a seleção brasileira de vôlei, conforme discurso do técnico Bernardinho, sobre a formação do time onde, como em qualquer time de alta performance, há garra, treino, conhecimento dos pontos fortes de cada um, evolução contínua e conhecimento do jogo (negócio e metodologia).

O que poucas pessoas conseguem lembrar quando veem um time vencedor é o caminho que foi trilhado para chegar ao status de campeão. Pensando nesse caminho, pode-se fazer uma comparação direta com um time de desenvolvimento. Embora se tenha experiência individual dos componentes da equipe, de inicio ainda não formam um time. Em conjunto é possível desenvolver diversas competências técnicas e comportamentais, para então se tornarem um time e através de ciclos de melhoria gradual formarem um time de alta performance. O que será apresentado neste artigo é justamente este caminho.

Iniciar um projeto é sempre um desafio, é preciso lidar com um novo produto, novas expectativas, novas percepções e, muitas vezes novos clientes. Este entendimento, anterior ao início do projeto, é conhecido como fase de concepção. Nesta fase, antes de pensar em desenvolver os times é necessário encontrar pessoas adequadas ao novo desafio, dimensionar e montar um ou mais times de desenvolvimento.

Dificilmente um projeto será entregue a um time de desenvolvimento já existente, que já trabalha junto há muito tempo, sem mudanças de papel ou de pessoas. No mundo real, não existe o conceito de times fixos, com pessoas que não mudam de emprego, nem de área de atuação. A carreira de TI é sujeita a mudanças e constantemente nos deparamos com situações imprevisíveis no que diz respeito às alocações internas e externas de pessoas, assim como não existe garantia nas contratações de desenvolvedores de que os mesmos vão atender às expectativas e atingir o resultado previsto.

Mesmo que no framework Scrum não exista escopo de projeto fixo, definido na concepção, muitas vezes existe um prazo para entrega definido pela área de negócio, para um conjunto de funcionalidades básicas, viabilizando que o produto retorne valor (por exemplo, uma data de estreia de campanha comercial, uma data fixada pelo governo para funcionamento de uma alteração fiscal, entre outras).

Existem técnicas para garantir que o cliente receba este “produto mínimo entregável”, através da realização de engenharia de valor, redimensionamento de times, entre outras.

No entanto, independente de problemas de cronograma de projeto, os times devem ser trabalhados para a evolução constante. Pois a expectativa do cliente é que a quantidade e qualidade das entregas melhorem a cada Sprint, mantendo a produtividade. Muitas vezes esta melhoria é negociada no momento de fechar um contrato, propondo uma velocidade de início abaixo da expectativa do cliente e projetando um ganho de velocidade Sprint a Sprint até chegar a um valor que oscila, pouco conhecido como “velocidade de cruzeiro”. Portanto, uma empresa de TI que vende times Scrum, na verdade vende times de desenvolvimento que conhecem e utilizam Scrum, mas não tem como garantir que eles sejam “Times de Alta Performance” por mais que conheçam estes times e por mais que eles tenham tido sucesso em projetos anteriores.

O que são Times de Alta Performance?

A performance, no contexto de células ou times de desenvolvimento, está intimamente relacionada com a maturidade do time como um todo. Uma definição de maturidade é “estado das pessoas ou das coisas que atingiram completo desenvolvimento”. Para um time de desenvolvimento, maturidade pode ser considerada como o conjunto de características que mostram um alto grau de desenvolvimento técnico e comportamental. Entretanto, ter um time reconhecido como maduro não garante um início com alta performance.

A definição de HPT, ou High Performance Teams, segundo o livro “The Wisdom of Teams”, traduzido para o português, “Times de Alta Performance”, é um conceito dentro do desenvolvimento das organizações referente a times, organizações ou grupos virtuais que são altamente focados nas suas metas e alcançam resultados de negócio superiores, superando todos os outros times similares e também as expectativas dadas a sua composição.

Analisando a definição acima, pode ser observado que é comparativa.Ou seja, para identificar um time como de alta performance utiliza-se comparação com outros times em situação semelhante.

A definição de HPT também é subjetiva, considerando as expectativas do cliente. Não existe um modo de aplicar um questionário e dizer com certeza que um time é um HPT. O cliente deve perceber a evolução dos times e reconhecê-los. Para isso, é importante extrair informações e métricas que indiquem que o seu time está na direção certa, de modo que a avaliação do time não fique somente na percepção superficial do cliente e sim em uma percepção formada por fatos concretos.

Para ser um time de alta performance é necessário superar as expectativas, entregar cada vez mais e cada vez melhor, sobre uma meta possível, evitando situações comuns, onde o cliente considera alta performance a entrega de tudo o que gostaria de ter, simplesmente guiado pelo desejo e gerando uma avaliação baseada em emoção e não em resultados.

Custo X Adequação

Para viabilizar um projeto existem diversas combinações possíveis de montar times de desenvolvimento. Fatores como distribuição, experiência técnica e maturidade das pessoas devem ser levados em conta antes de garantir que determinado conjunto de pessoas atende a necessidade do negócio.

O Scrum prega que quanto mais multidisciplinar for um time, melhor será para o projeto. Se possível, o time todo deve ser capaz de planejar, executar e testar estórias, assim como executar tarefas de Front-end e Back-end, com praticamente o mesmo esforço. Porém, sempre haverá pessoas com mais facilidade para um tipo de atividade e menos para outro tipo, mas deve haver o incentivo a multidisciplinaridade e o trabalho conjunto sempre que possível, o que auxilia ter um time menos sujeito a situações imprevisíveis.

Qualquer empresa gostaria de ter em seus times somente pessoas com muitos anos de experiência comprovada, um time inteiro sênior. Na maioria das vezes, isso não é possível, seja por motivo de falta de colaboradores com esse perfil no mercado, seja pelo alto custo. O que deve estar claro é que a não ser que o cenário exija e possibilite um time de sêniores, o aconselhável a fazer é montar um time balanceado. Onde desenvolvedores menos experientes tenham apoio técnico de um desenvolvedor mais experiente, assim como um testador júnior possa ser responsável por executar os testes, enquanto um testador mais experiente possa ser responsabilizado pela criação dos cenários e validação dos requisitos, de modo a focar em planejamento e não na execução de testes.

Na maioria das vezes, o sucesso de um projeto tem uma relação direta entre o equilíbrio de qualidade, custo e prazo.

Pilares: Escopo x Custo x Prazo

As três primeiras áreas a serem estudadas pelo PMI (Project Management Institute), Escopo, Custo e Prazo, ajudaram a formar um diagrama, chamado de Trinômio Sagrado do Gerenciamento de Projetos. Este diagrama mostra resultados das variações sobre o escopo, custo e prazo do projeto e seu impacto na qualidade.

Para o sucesso de um projeto é necessário equilibrar esses três pilares, que são relacionados como vértices de um triângulo (veja a Figura 1). Se a opção for um custo menor, deve-se aumentar o prazo ou reduzir o escopo. Se a busca for pela entrega em menor prazo, provavelmente haverá um custo maior ou será necessária redução do escopo.

Mas e a qualidade? Por que a qualidade não é negociável?

O pilar qualidade fica entre os três vértices, o que impossibilita que seja negociado. Qualquer problema com qualidade gera impacto direto em custo, prazo e/ou escopo. Não existe motivo para diminuir a qualidade, mesmo que a falta de cuidado com a qualidade pareça atraente por diminuir o custo, como nos casos que há diminuição no time de testes ou no escopo de testes, por exemplo. O problema é que se não há garantia de qualidade, dificilmente haverá como dizer que entregaremos no prazo ou que respeitaremos o custo. Então o ganho aparente será posto em prova quando defeitos em desenvolvimento, homologação ou produção começarem a impactar negativamente no prazo e no custo, um risco que não vale a pena correr.

Diante disso, existe um cuidado com times de desenvolvimento que não deve ser negligenciado, o de produzir com qualidade, acima de velocidade ou previsibilidade.

Desenvolvimento contínuo

Para atingir as metas de velocidade sem perder qualidade, o ideal seria iniciar o projeto com um time de técnicos especialistas nas tecnologias do projeto, com profundo conhecimento no negócio, no cliente e comprometido com a entrega do produto. Esta realidade é possível para equipes que desenvolvem produtos diretamente para a empresa onde atuam, trabalhando em conjunto com a área de negócio e com conhecimento prévio do sistema que será criado ou evoluído.

Esta não é a realidade das consultorias e fábricas de software, pelo fato de que tanto na contratação dos profissionais, quanto na formação da equipe, não existe garantia de que os colaboradores tenham conhecimento técnico necessário. Dificilmente os colaboradores conhecerão o negócio do cliente antes de iniciar o projeto e muito menos haverá garantia de que todos estejam comprometidos com a entrega. Por este motivo é importante entender que times diferentes, compostos por pessoas com nível técnico e de maturidade diversificados, terão início de projeto com resultados diferentes. Por isso, quando não existe garantia de iniciar um projeto com alto rendimento, os colaboradores devem ser conduzidos pelo processo de melhoria contínua, de forma a serem capazes de alcançar o desenvolvimento técnico e pessoal necessário para atender a necessidades identificadas.

O Scrum é um framework iterativo, baseado em ciclos de PDCA; sigla em inglês que significa Planejar, Executar, Validar e Atuar (Plan, Do, Check, Act). Deste modo, as fases que compõem uma iteração (ou ciclo) devem ser analisadas para dar aos times insumos para o desenvolvimento, aumentando a percepção do próprio time sobre seus pontos fortes e de melhoria.

Com o foco na melhoria contínua e considerando o aproveitamento máximo e feedback das iterações, alguns pontos de atenção devem ser levados em consideração, os quais serão analisados na sequência.

Levar a sério os ritos do Scrum

O Scrum utiliza ritos formais para marcar as diferentes fases dentro da iteração, sendo o resultado da aplicação correta refletido diretamente na eficiência de cada rito. Por isso, quanto mais próximo da metodologia um time executa os Sprints, melhor é o resultado. Este cuidado com a fidelidade ao processo é conhecido como execução do Scrum “by the book”.

Existem sugestões de ações para aperfeiçoar a execução dos ritos Scrum durante os projetos, são elas:

• Planning Meeting: As planning meetings são reuniões de planejamento das funcionalidades do produto, que serão compromisso da próxima entrega e devem estar focadas em um produto simples e que resolva o problema proposto pelo PO (Product Owner). Geralmente o time pensa em entregar um produto completo de funcionalidades e esteticamente agradável, mas as funcionalidades básicas e a facilidade de uso devem ser prioridades para a maioria dos casos. Pode até ser que a estética seja o foco do desenvolvimento como, por exemplo, no caso de desenvolvimento de sites, mas este requisito deve ser alinhado e não tomado como meta do Sprint, devido ao interesse do time. O importante é que o PO atue ativamente no planejamento, ficando com a decisão do que é prioritário para a entrega e que todos saiam da reunião alinhados com o consenso de aceite do Sprint.

O time deve pensar no compromisso da entrega e focar em conseguir entregar as estórias das quais houve o comprometimento. É esperado que o time tenha capacidade de negociar, caso o escopo não seja coerente com a velocidade prevista pelo time. Às vezes, uma solução mais simples que a proposta, ou uma funcionalidade (não essencial) que seja retirada de uma estória, permite que o produto entregue traga maior valor. O questionamento do que é prioridade na maioria das vezes fica sobre responsabilidade do Scrum Master, mas quando há a responsabilidade do time com o produto que está desenvolvendo, negociando diretamente com o Product Owner, se tem um compromisso maior de ambos os lados e maior flexibilidade na resolução dos desafios, conforme forem surgindo;

• Daily Meeting: A daily meeting é uma reunião diária que permite um alinhamento do time com as atividades do Sprint, geralmente realizada com o time em pé e seus membros respondendo questões, como, O que você fez ontem? O que você está fazendo hoje? O que está te impedindo de realizar o seu trabalho? De forma resumida;

Acompanhando a daily meeting, o Scrum Master deve interromper quando o time está fazendo uma apresentação para cada membro ao invés de para o time todo. A importância da daily meeting é passar, além do status, a percepção do desenvolvedor sobre a meta do Sprint e as dificuldades encontradas no desenvolvimento de sua atividade, de modo que todos possam entender e participar das atividades de todos. Portanto, deve-se utilizar esse tempo para refletir sobre as atividades do time, um exemplo seria um desenvolvedor dar uma ideia que resolva o problema de outro, um testador perceber um risco em determinado cenário e planejar testes mais específicos para este cenário, o Scrum Master detectar um impedimento antes mesmo dele se concretizar, ou seja, é o momento do time esquecer as dificuldades individuais e trabalhar na construção do produto como um todo e não como um conjunto de atividades;

• Demo Meeting /Sprint Review Meeting: Chegou o momento da entrega do Sprint e o time todo se reúne com o PO para demonstrar o produto, sendo notável a reação do PO quando se alcança o resultado esperado, assim como quando a expectativa era maior que o produto entregue. A apresentação do Review meeting não altera a qualidade da entrega, mas contribui para que na próxima Planning meeting estes feedbacks sejam incorporados ao produto;
• Retrospective Meeting: Reunião realizada no final de todo Sprint, onde é realizada toda a retrospectiva do Sprint com um olhar crítico. Nesta reunião todos são convidados a apontar claramente “o que deu certo” e “o que não deu certo” no Sprint e chegar a um consenso sobre quais itens devem ser melhorados.

É o momento oficial para apontar ações de sucesso e discutir melhorias. Os feedbacks devem ser focados em ações possíveis de serem implantadas, por exemplo, não adianta apontar que se tivessem um supercomputador se ganharia tempo com a geração de builds, se não é possível conseguir esse supercomputador. Também deve se eleger poucas ações para melhorar o próximo Sprint, não adiantando eleger quinze pontos de melhoria e no final do Sprint conseguir atuar em apenas três. Neste caso, a melhor estratégia seria trabalhar em três a cinco ações possíveis por Sprint e realmente resolvê-las, além de refletir sobre a solução do problema para que não volte a ocorrer. Outra atitude que contribui para a efetividade das retrospectivas é não deixar para lembrar os problemas na última hora. Assim, é necessário procurara estimular os times a anotar os problemas conforme eles acontecem durante o Sprint, para diminuir o risco de esquecer algo importante e melhorar a dinâmica da própria reunião de retrospectiva.

Exercitar o Feedback sempre

Uma grande vantagem de um framework com iteração é a possibilidade de trabalhar com melhoria contínua. Para fornecer a retroalimentação necessária à análise dos pontos de melhoria existe a prática da Retrospective Meeting.

Realizar feedback apenas uma vez por Sprint não é suficiente, esse deve ser exercitado sempre que possível, fornecendo ao time uma régua para medir o quanto alinhados estão com a necessidade do projeto. Não existe uma regra, nem é interessante utilizar tempo do time se não existir nenhum acontecimento pertinente, mas se possível deve-se exercitar o feedback diário.

O modo mais fácil de não cometer o mesmo erro mais de uma vez é tomar conhecimento do problema o quanto antes. Deste modo, aumenta a chance de que uma ação de resultado positivo seja aplicada novamente, antecipando um novo problema, e expondo a todos o resultado para que sejam estimulados a aplicar iniciativas de sucesso.

Capacitação e treinamentos direcionados

A evolução de um time compreende enfrentar desafios, mas muitas vezes se deparam com situações técnicas e comportamentais para as quais não estão preparados. É importante reconhecer os momentos onde o time precisa de ajuda para se desenvolver, podendo ser através de um treinamento, que pode ser realizado no dia a dia do Sprint, direcionado para a solução do problema ou de um treinamento mais formal. O que importa é que o time entenda que tem um problema a resolver e seja encorajado a se desenvolver, tendo apoio para isso. No caso de ter um colaborador do time com dificuldades, é sugerido treinamento específico de forma a equalizar o conhecimento em que ele esteja defasado dos demais.

Exibir claramente os resultados sobre as metas aceitas

O PO é uma das chaves para o sucesso do projeto. Ele deve acreditar no Scrum e defender seu uso perante os stackeholders e sponsors do projeto. O sucesso ou a falha da entrega do time é o sucesso ou a falha da entrega do PO, que sabe o valor de cada entrega, o compromisso firmado com o time e tem condições de justificar o desempenho do time se for questionado.

De nada adianta o time estar orgulhoso em cumprir o acordo do Sprint se ao apresentar o produto ao PO ele estiver com uma expectativa maior. Por isso é importante que o acordo firmado na planning esteja alinhado com a expectativa do cliente, também é importante ao PO conhecer e acreditar na metodologia, ou seja, entender as regras do jogo, de modo que participe ativamente dos resultados, já que ele está construindo o produto junto ao time. Para que exista o comprometimento entre o time e o cliente, todos devem ter ferramentas para acompanhar os resultados dos Sprints de modo claro e intuitivo.

Com todas estas diretivas se cria um ambiente com condições para o time se desenvolver, afinal, o próprio time deve ser capaz de visualizar sua condição atual e o caminho para se tornar melhor. Ações de melhoria e corretivas podem ser planejadas e executadas, mas se o time não estiver comprometido a evoluir, não se tornará um HPT.

O cliente enxerga a alta performance do seu time?

No momento da entrega, pouco vale o fornecedor estar orgulhoso do seu time HPT e do produto construído, se o cliente não enxerga o mesmo. Mas, como medir e demonstrar performance para seu cliente?

O cliente muitas vezes quer saber quantas horas/minutos/segundos o time levou para desenvolver cada estória, se considera este dado o mais importante para seu planejamento. Dentro de um cenário complexo de gestão de projeto muitas variáveis interferem nas estimativas de entrega. Então, porque no planejamento do Sprint se usa Story Points, em vez de estimar o prazo de desenvolvimento em horas? Porque cada estória é diferente da outra. Mesmo tendo levado três dias para entregar uma estória de treze Story Points, não existe garantia de que uma estória, aparentemente parecida com os mesmo treze Story Points, será entregue em três dias também.

Nenhuma estimativa é tão precisa e é por isso que se usa a escala de Fibonacci para medir o esforço, porque ela possui valores com intervalos crescentes e não sequenciais. Por isso pode-se concluir que uma estória de treze Story Points leva mais esforço para entregar do que uma de oito Story Points, mas menos que uma estória de vinte e um Story Points. Existe um intervalo entre os valores que cresce conforme a pontuação aumenta, mostrando que quanto maior o esforço total para entregar uma estória maior o erro de estimativa, ou desvio, possível de ocorrer.

O planejamento do projeto sempre fica sujeito a desvios de prazo, mas no Scrum este desvio já é previsto, de modo que pode ser gerenciado alterando o escopo de entrega, mas mantendo o foco no desenvolvimento das funcionalidades que possuem mais valor.

Para medir desvios positivos ou negativos sobre custo, prazo e qualidade de um projeto, podem ser usados três pilares: Produtividade, Previsibilidade e Qualidade.

Previsibilidade

A métrica de previsibilidade mede o desvio das datas de entrega, no momento do planejamento do roadmap sobre as datas de entrega efetivas. Para o cliente, é a capacidade de prever o que será entregue e quando. Para garantir uma medida correta de previsibilidade é importante manter o controle de Baseline do projeto, atualizando qualquer desvio ocorrido. Para medir o desvio após a entrega de um Sprint é necessário realizar o grooming do backlog, ou seja, a análise do backlog restante, com foco em rever qual o esforço necessário para entregar as demais estórias e avaliar se essas foram alteradas para mais complexas ou menos complexas, com base na pontuação das estórias já entregues. Através de um backlog inicial pode ser gerado um release e um gráfico de burndown que mostra na linha do tempo a conclusão dos Sprints de um release, para medir o quão próximo do planejado se esta após o término de cada sprint e deste modo demonstrar desvios por aumento de escopo de produto, consequente aumento do backlog.

Com a percepção de desvios nas entregas dos Sprints, pode-se replanejar datas do projeto ou cortar escopo, de modo a concretizar a entrega na data inicial proposta. Lembrando que quando entra uma estória (funcionalidade) nova ou aumenta a complexidade de alguma existente no backlog, automaticamente necessita se despriorizar outra estória, de preferência que entregue menor valor ao negócio. O escopo do projeto, que forma o backlog, deve ser visto como um espaço limitado, onde não cabem mais estórias e para que entre uma, outra de mesmo tamanho deva sair. O importante é que as trocas sejam feitas pelo PO, junto ao Scrum Master e/ou o time e devidamente alinhadas com as áreas de negócios.

No exemplo da Figura 2 pode ser acompanhado o total previsto de pontos que deveriam ser entregues em nove Sprints.

O gráfico mostra através da linha verde (entrega executada) que houve um atraso nos quatro primeiros Sprints, através dos Story Points (SP) restantes acumulados. Acompanhando a linha vermelha (entrega planejada), que mostra os Story Points restantes planejados para o final de cada Sprint, como pode ser observado o atraso foi compensado a partir do Sprint cinco. No oitavo Sprint o time entrega todos os pontos restantes e ainda sobraram seis, de modo que poder ser aceita uma (ou mais) estória, somando seis SP e manter a previsão de entrega.

Produtividade

A produtividade é a capacidade de entrega de um time, sendo a quantidade de funcionalidades que um time consegue entregar em um período de tempo. Essa pode ser medida utilizando a velocidade do time (velocity) em Story Points, essa velocidade é calculada pela quantidade de pontos que o time consegue entregar por Sprint, considerando a quantidade de desenvolvedores fixa ou a taxa resultante da quantidade total de Story Points dividida pela quantidade de desenvolvedores, caso o time sofra alterações.

Deve ser considerado “ganho positivo” quando o time entrega uma quantidade maior de Story Points do que no último Sprint, projetando velocidade crescente. Mas para este ganho ser real, o time deve mostrar que entrega realmente mais, pois, apenas subir a pontuação das estórias gera uma visão errada de ganho de produtividade. É importante fazer uma análise comparativa do tamanho das estórias Sprint a Sprint.

No final do Sprint podem ser comparadas as estórias e verificar se elas são do tamanho proposto inicialmente. O importante é manter as comparações atualizadas, para que na próxima planning meetings as estimativas sejam baseadas em valores atualizados.

Acompanhando os valores da velocidade do time nos Sprints, o esperado é que o time, ao adquirir maturidade, aumente sua produtividade nos primeiros Sprints, mas em algum momento ele deve estabilizar, pois atinge sua produtividade máxima. O maior desafio, deste ponto em diante, é manter estes valores constantes, pois uma diferença negativa pode aparecer de um Sprint para outro, por motivos que não podem ser controlados. O esperado é que uma vez que o time atingiu um patamar máximo de produtividade, a média de Story Points dos últimos se mantenha estável, com pouca variação em torno deste valor.

Qualidade

Qualidade é prioridade em qualquer projeto. Em qualquer momento deve ser possível negociar prazo, custo, mas qualidade não se negocia. De nada adianta entregar um projeto no prazo, quando se gera inúmeros problemas em produção. O custo de corrigir problemas em produção é alto, quem além de causar problemas para o negócio, também pode consumir margem de um projeto através do cumprimento de um contrato de garantia, por exemplo.

Saiba mais: Introdução a Qualidade de Software

Se um time apresenta erros de desenvolvimento pode se considerar algumas hipóteses, como estórias com requisitos falhos, falta de maturidade técnica do time de desenvolvimento, falta de entendimento entre desenvolvedores e testadores, um PO ausente. Através do levantamento de pontos falhos, ainda durante o desenvolvimento, é possível fixar planos de ação que acompanhados podem reverter o cenário negativo.

Para ter alta performance é necessário que o time conheça e entenda a qualidade do projeto, assim como os meios de monitorar/melhorar a qualidade Sprint a Sprint.

Para definir o que é esperado da qualidade em um projeto e o que será cobrado no momento das entregas, existem compromissos, que firmados em documentos, descrevem definições e critérios que deverão ser atendidos, a saber:

• Definição de READY: O ponto de partida no Scrum para garantir que o que está sendo produzido terá qualidade, é definir as regras para o time de desenvolvimento, com “o que” produzir e “como” produzir. Chamamos estas regras de “Definição de READY” (ou DoR). Este acordo define as características mínimas que uma estória deve ter para ir ao Planning meeting.

Um exemplo é levar para a reunião de planning uma estória que contemple criar uma página principal de um site sem um wireframe (desenho básico dos componentes da tela) ou sem um guia de estilo. Como os desenvolvedores podem saber o que fazer, como fazer, ou até mesmo definir quanto esforço terão que fazer para entregar uma tela que nem imagina como é? Para sanar este problema podemos exemplificar que no projeto “Site Institucional da Empresa X”, todas as estórias que descrevem uma página qualquer do site podem ter as seguintes regras na sua DoR:

• As telas devem possuir um guia de estilo (tipo/tamanho de letra, cores, etc.);
• As telas devem possuir wireframes que expliquem quais componentes devem ser exibidos, sua localização, tamanho, tipo de conteúdo, etc.;
• As telas devem ter sido aprovadas pela área responsável pela usabilidade.

Assim como a definição geral de Ready, que mostra quando uma estória está pronta para ser discutida na planning meeting, é preciso criar regras (critérios), que expliquem claramente para o time durante a reunião de planning qual resultado esperado na entrega de cada estória do backlog;

• Definição de DONE: Assim como a definição de READY é o ponto de partida, para saber o que se deve produzir, a definição de DONE é o acordo para garantir que o que está sendo entregue tenha qualidade. É definir com o PO o que é uma estória pronta para o projeto. Chamamos estas regras de “Definição de Pronto” (Definition of Done ou DoD).

Estas regras variam de projeto para projeto e por isso devem ser combinadas no início para serem utilizadas durante todo o projeto.

• Critérios de Aceite: Para a Definição de Pronto das estórias uma das regras é que “todos os critérios de aceite foram entregues”. Isso porque a visão de qualidade do PO é intimamente ligada aos critérios que foram pedidos para o produto em cada estória, sendo de responsabilidade dele cobrar do time os critérios que foram definidos nas estórias. Qualquer funcionalidade ou característica que não foi definida como critério, não pode ser exigida na Review meeting e deverá ser mapeada em uma nova estória que entrará no backlog, gerando a necessidade de negociação do escopo para que não impacte no prazo de entrega do projeto;

Com todas estas definições alinhadas deve se garantir que os acordos sejam cumpridos. Para isso há métricas que devem ser acompanhadas para gerar ações corretivas, caso o resultado não esteja de acordo.

Métricas de qualidade em desenvolvimento, homologação e produção

A principal métrica que indica se o time está desenvolvendo uma aplicação com qualidade é o número de defeitos. Se há muitos defeitos em desenvolvimento, existe uma chance enorme de ter defeitos em homologação e, consequentemente, muitos defeitos em produção.

Uma meta comum à maioria dos contratos é buscar executar projetos sem defeitos. Mas este resultado não é alcançado na maioria das entregas. Portanto, deve ser determinada uma meta possível, iniciando pelo número de defeitos que seja aceitável em desenvolvimento, e garantir que a homologação seja bem feita, mirando uma produção sem defeitos. É no mundo real que a qualidade do projeto é posta a prova, portanto não adianta fazer um projeto com poucos defeitos na fase de desenvolvimento, se tiver várias ocorrências de defeitos em produção.

Para ter uma medida da qualidade geral do projeto, a quantidade de defeitos deve ser considerada como a principal evidência, mas sem esquecer de avaliar a gravidade de cada um individualmente. Em alguns casos pode ser melhor, do ponto de vista do negócio, ter mais de um defeito simples a um único crítico. Apesar disso, é necessário ter critério na avaliação da qualidade, pois dificilmente haverá muitos erros sem que parte deles seja crítico.

Um modo interessante para o time acompanhar e atuar sobre o número de defeitos é construir um Burnup de Defeitos (Figura 3), uma ferramenta visual para acompanhar a curva de crescimento de defeitos diariamente, de modo que no final de cada Sprint o número total de defeitos seja comparado a um nível máximo aceitável em desenvolvimento. Este limite, ou meta, deve ser negociado por projeto e é geralmente calculado levando em conta o número de desenvolvedores que geram código, a tecnologia em que o projeto está sendo desenvolvido e outras particularidades do projeto. Uma vez que o limite foi definido e o Sprint estiver em andamento, a atualização do gráfico deve ser feita sempre que o testador encontrar um novo defeito.

Através da visão crítica sobre estes dados, o time deve atuar para que o total não passe do limite estabelecido e caso ultrapasse, deve-se tomar ações corretivas para se ter uma diminuição progressiva nos próximos Sprints.

Conclusão

Quem não gostaria de trabalhar sempre em times de alta performance? Times que entregam muito, rápido e com qualidade. Times que surpreendem o cliente com soluções inovadoras e que entregam mais do que o cliente espera. Esta excelência pode e deve ser um objetivo comum aos times, mas não existe como prever objetivamente que um time entregará com “Alta Performance”. A meta que deve ser perseguida é a evolução do time para que ele alcance o desempenho desejado, porque HPT é conquistada diariamente, com conhecimento do negócio, domínio da técnica, comprometimento, atitude colaborativa e muita mobilização para resolver problemas.

Para um fornecedor que pretende vender um time de alta performance é importante mostrar que o time tem potencial de se tornar um HPT, mas para isso existe um caminho, muitas vezes longo, a percorrer para alcançar este objetivo. Times não nascem com alta performance, mas seguindo a meta de melhora continua nas iterações, permitindo conquistar este objetivo em alguns Sprints.