O processo de desenvolvimento de software na organização estudada é baseado no modelo de desenvolvimento ágil Scrum e encontra-se em pleno estágio de evolução, pois foi adotado apenas de julho de 2011 pra cá. Por essa razão, o documento que apresenta o referido processo possui um capítulo especificamente dedicado a apresentar os principais conceitos envolvidos no lean thinking, que é uma das principais influências do modelo Scrum. São apresentadas informações gerais e, também, uma breve comparação com o modelo tradicional.
A organização trabalha com Sprints divididos em três fases principais: a preparação, que se dá antes do início de cada Sprint e existe para garantir que todos os pré-requisitos necessários para realização do trabalho previsto sejam atendidos; a execução, com as atividades que efetivamente caracterizam o Sprint, ou seja, a construção do software propriamente dita; e a avaliação, que tem como objetivo deixar todo o trabalho efetivamente pronto, com as pendências eventualmente existentes resolvidas. A Figura 28 apresenta um esquema dessa divisão do Sprint.
Figura 28 - Divisão do Sprint na organização estudada
Fonte: Dados do STF (2011).
Durante a preparação, ocorre a prática chamada Grooming, que é utilizada para preparar a equipe antes do início da fase de execução. Essa preparação pode envolver, por exemplo, o esclarecimento de incertezas quanto à interpretação das estórias de usuário e a consulta a especialistas.
Na preparação, o responsável pela equipe tem o primeiro contato com o backlog do produto a ser construído e analisa as estórias para identificar quais podem ser construídas na próxima iteração, observada a capacidade da equipe. O objetivo maior é garantir o bom andamento da planning meeting e do próprio fluxo de desenvolvimento, por isso, o Grooming deve garantir que o Product Owner tenha total domínio das estórias que serão discutidas.
Marcando a transição entre a etapa de preparação e a etapa de execução, a organização executa a planning meeting. Um projeto Scrum é composto de uma série de miniprojetos com prazo, recursos e qualidade fixa, sendo variável apenas o escopo do Sprint. O foco da planning meeting é a definição do escopo do Sprint.
Da planning, participam a Equipe Scrum e o Product Owner. O Scrum Master, que é um dos integrantes da Equipe Scrum, conduz a reunião, que se inicia com uma revisão de informações como datas de início e fim do Sprint, data e local da demo meeting. Em seguida, é definido, de forma conjunta entre a Equipe Scrum e o Product Owner, um objetivo para o Sprint, que é representado por uma declaração do que se pretende atingir no período. O Product Owner apresenta as estórias de maior prioridade do product backlog, a equipe esclarece eventuais dúvidas, a fim de absorver todo o conhecimento necessário para executar cada estória, e, por fim, define quais estórias farão parte da execução.
É na etapa de execução que, conforme mencionado, os softwares são efetivamente construídos, ou seja, essa etapa é o Sprint propriamente dito. Durante ela, diariamente é feita uma reunião de no máximo quinze minutos em que a Equipe Scrum se reúne para responder a três questões básicas: o que você fez desde a última reunião? o que você fará até a próxima? existe algum impedimento? A equipe não resolve os problemas durante a reunião, mas eles são reportados ao Scrum Master, que busca solucioná-los após a reunião. Os principais objetivos são: a divulgação em relação ao que está acontecendo no Sprint; a comunicação em relação ao andamento do Sprint; e a identificação de obstáculos.
A demo meeting marca o final da etapa de execução do Sprint. Nela, a Equipe Scrum apresenta ao Product Owner – e a outros interessados em participar, como gerentes e clientes – o que foi feito durante o Sprint. Durante a demo meeting, o resultado é comparado ao objetivo, definido durante a planning meeting. A demo é a oportunidade para que a equipe demonstre objetivamente o valor que está sendo entregue.
Por fim, na organização estudada, acontece a retrospective meeting, que tem como principal foco a promoção do aprendizado, da melhoria contínua, da observação em relação
ao que deu certo e ao que não deu certo no último Sprint. Da retrospective meeting, participam os integrantes da Equipe Scrum. O Scrum Master anota todas as respostas dadas às questões levantadas e, após a reunião, define ações de melhoria.
As tarefas de design, especialmente aquelas relacionadas à arquitetura de software e à modelagem de dados, são realizadas por meio da aplicação do conceito de emergent design. A ideia central é que o design seja realizado à medida que as estórias são desenvolvidas, de forma incremental, emergindo de dentro do Sprint. Nesse aspecto, verifica-se que a organização adota um conceito denominado Sprint setup, que se refere ao Sprint 0 de um projeto e que visa a realizar tudo o que for necessário para promover e sustentar os passos seguintes. Nele, são feitas as definições arquiteturais e de modelo de dados, as quais são incrementadas nos Sprints subsequentes.
A organização preza, até mesmo em função dos princípios inspiradores do modelo adota, pela entrega de valor rápida e constante. Por isso, cada Sprint visa à geração de produtos potencialmente entregáveis. Quando um produto potencialmente entregável é implantado, geralmente no ambiente de produção, ele começa a gerar valor para o cliente. Para que uma nova versão entre em produção, a organização faz uso do conceito de release Sprint, que é um período para estabilização da nova versão no ambiente de produção, com o objetivo de que as correções de defeitos sejam feitas com a maior brevidade possível. Nesse período, toda a equipe é fica de prontidão.
Os release Sprints não são obrigatórios e não têm tamanho definido. Essas questões dependem da complexidade do projeto, sendo comum existirem em projetos complexos ou projetos novos, nos quais a equipe ainda não conhece a sua taxa de débito técnico – a quantidade de defeitos no produto que está sendo desenvolvido, causados pelo próprio trabalho de construção. Ciclos de release dependem do roadmap do projeto, sendo possível rodar uma determinada quantidade de Sprints sem nenhum release. A Figura 29 exemplifica o processo como é implantado na organização estudada.
Figura 29 - Exemplo de roadmap de um projeto de software na organização
Fonte: Dados do STF (2011).
A organização utiliza um modelo, denominado Heijunka, que busca o nivelamento do fluxo de produção, cujo objetivo maior é converter a instabilidade da demanda dos clientes em um processo de produção nivelado e previsível. A ideia é promover um fluxo contínuo na produção, de forma que os recursos – times, hardware e software – alocados ao projeto sejam utilizados de maneira otimizada, as necessidades de melhoria no processo sejam rapidamente percebidas e a percepção de valor pelo cliente agilizada.
Para isso, as atividades da etapa de preparação de um Sprint ocorrem durante a etapa de execução o Sprint anterior, garantindo que cada Sprint tenha os insumos necessários para seu início no primeiro dia e que o fluxo de trabalho da equipe não seja interrompido. O esquema apresentado na Figura 30 exemplifica a implementação do modelo na organização estudada.
Figura 30 - Modelo Heijunka na organização estudada
Fonte: Dados do STF (2011).
Como principal ferramenta para apoio às atividades de gerenciamento do desenvolvimento de software, a organização utiliza o Atlassian Jira. Os times acompanham o trabalho realizado durante a construção das soluções, o que inclui funcionalidades de planejamento, status, testes funcionais e registro de defeitos.
A organização destaca que os próprios processos adotados já estimulam a geração de melhorias, especialmente em função de conceitos baseados em grandes sistemas produtivos. Nesse sentido, entende como essencial a geração de indicadores que possibilitem o melhor entendimento do processo. Até o momento da pesquisa, dois indicadores principais – relacionados ao processo – eram utilizados: o de Capacidade produtiva, que apresenta a relação entre as atividades de desenvolvimento que geram valor – as correções de defeito não são contabilizadas – e a capacidade total da equipe; e o de Projetos vs. Operações, que mostra o esforço destinado a projetos de desenvolvimento e o esforço destinado a projetos de sustentação (operações).
7 RESULTADOS E ANÁLISES
Neste capítulo, são apresentados resultados e análises oriundos das informações obtidas no estudo de caso, categorizadas de acordo com o modelo teórico previamente construído, no qual são apresentados os pontos de interação identificados a partir da teoria.
Para tanto, serão apresentadas a seguir as descrições e as interpretações das informações coletadas, que passaram pelas etapas de preparação, unitarização e categorização. A apresentação está estruturada em cinco subtópicos, dos quais quatro correspondem às categorias definidas com base nos pontos de interação identificados a partir da teoria e o último serve à apresentação de uma visão-geral do que fora verificado.
7.1 INTERFACES RELACIONADAS À IDENTIFICAÇÃO DE NOVOS