Desenvolvimento Ágil de Software

Desenvolvimento de Software sob Demanda: do seu jeito e com nossa expertise. 


O desenvolvimento de software ágil vêm ganhando espaço nas empresas que procuram cada vez mais ganhos de produtividade, qualidade e custo reduzido. 

Há vários aspectos que diferenciam o Desenvolvimento de Software Ágil do Tradicional. Entre eles, ciclo de vida do projeto, entrega, planejamento e execução.

Quer conhecer todas as práticas e diferenciais do Desenvolvimento Ágil de Software ? O Agile Team Objective desenvolveu um completo ebook  detalhando todas as práticas e diferenciais desta Metodologia que aplicamos em grandes empresas ao longo de 18 anos. 

Conte conosco para uma consultoria, desenvolvimento de software  ou treinamento no seu próximo projeto. 

Buscamos incessantemente a solução mais inteligente ao seu negócio através de 3 modelos para garantir a entrega de forma ágil, prática e efetiva.

Modelo Ágil (Full Agile)

Este modelo oferece grandes benefícios, pois reduz os custos, potencializa o valor e gera também um ambiente de confiança e parceria entre as empresas.

  1. Entregas frequentes e curtas

    Entregas frequentes e curtas: em períodos tipicamente de uma semana o cliente passa a receber, em produção, parte do software funcionando. Isso traz uma experiência real muito cedo e redireciona investimentos, foco e escopo para o que faz diferença para o objetivo do produto.

  2. Planejamento não especulado

    O máximo do planejamento feito é para atender à próxima entrega curta. Assim, evita-se especulações sobre futuro e concentra-se os esforços em o que deve ser feito para a próxima entrega. Isso de forma nenhuma significa falta de planejamento. Ao contrário, o planejamento neste formato acaba até sendo maior, mas é realizado de forma bem particionada e muito direcionado ao prático em si, uma vez que está focado nas tarefas concretas da próxima semana.

  3. Ciclos de refactoring

    É a característica de manter sempre o código no seu melhor estado de qualidade possível. Assim, no próprio processo de desenvolvimento, a fase de refactoring do que já está sendo feito faz parte do ciclo de produção. Algumas melhorias de design, contudo, exigem um investimento arbitrário em tempo para qualidade e é de comum acordo entre cliente e desenvolvedores que tal custo é necessário não para o aumento do valor do produto em si na próxima entrega, mas sim para a garantia de sustentabilidade de mudanças constantes no produto. Desta forma, podem existir alguns períodos onde não existe entrega de novas funcionalidades em benefício à manutenção do fluxo de entregas. Tal medida é normal dado que não existe pré-acordado de tempos para atuação nestes tipos de riscos. É um investimento pontual somente no risco que se mostrar real.

  4. Build sempre estável

    Esta prática é a possibilidade de se colocar um build novo em produção a qualquer momento. Embora existam ciclos de entrega, por tempo fechado ou não, temos a premissa de que qualquer linha de código commitada deve estar estável em relação a todo o sistema já em produção. Isso significa que poderíamos ter um novo build em produção a cada commit de qualquer desenvolvedor. A opção pelos períodos determinados é mais uma questão processual e por impactos em treinamentos e usabilidade. Tal técnica é ainda muitíssimo eficiente pois elimina períodos de estabilização, testes separados, desperdícios de contextualizações e demais overheads de processos tradicionais.

  5. Participação interativa e contínua do cliente

    Está previsto neste modelo uma disponibilidade contínua do cliente no projeto. Tal característica é necessária, dado que não existem tempos demasiados em planejamentos e contratos. O foco do trabalho é atender ao cliente de forma rápida com entregas de máximo valor. Para tanto, o cliente, neste modelo, não é apenas um requerente, mas um co-participante do desenvolvimento direcionando todas as ações através de decisões rápidas e validando as entregas de forma ininterrupta. Assim, ao longo do projeto, a relação de transparência naturalmente sobressai e a característica de ‘play to win’ prevalece. Interessante ainda notar que, mesmo quando se encontram barreiras em decisões, as ações muitas vezes são tomadas rapidamente de acordo com a expectativa mais natural. Afinal, com a capacidade de mudança garantida pelas demais práticas, uma reversão de decisão errada é bem menos custosa que o tempo de arrasto pela espera de uma decisão completamente assertiva.

  6. Facilidade de encerramento do contrato

    Dado a confiança estabelecida pelas práticas, um processo de encerramento do contrato por quaisquer razões é facilitada. Em um time com transparência e com ambos os lados comprometidos com o resultado de um produto com qualidade, caso alguma das partes perceba uma incapacidade de continuidade do desenvolvimento, ou mesmo que o valor suficiente já tenha sido gerado, esta tem total liberdade para finalização do contrato ao final da próxima entrega. Não existem obrigatoriedades de cliente ou fornecedor em escopo especulado, exceto ao que está sendo entregue naquele ciclo.

  7. Sustentabilidade do projeto

    É de comum acordo entre as partes que sobre-esforço diminui a produtividade e qualidade e, portanto, clientes e fornecedores trabalham sempre no ritmo sustentável esperado por dia. Da mesma forma, ferramentas e melhorias do ambiente também possuem influência direta na capacidade de execução de um trabalho com qualidade e, portanto, passam a ser uma responsabilidade da própria equipe a sua evolução e gestão de investimento.

  8. Visibilidade

    Deixar a gestão, ambiente, foco e status visíveis é uma das características mais importantes para a transparência e engajamento de todos. Assim, neste modelo, promove-se fortemente o uso de lousas, indicadores, monitores e dashboards de forma a, rapidamente, todos terem acesso aos dados relevantes do projeto e qual a saúde real do desenvolvimento. Tais mecanismos sempre são pensados de forma à visibilidade como time e não de forma individual e, portanto, costumam estar nas paredes, televisores/projetores, ou mesmo mecanismos físicos capazes de trazer além da transparência dos dados, ludicidade para a melhor absorção das informações.

  9. Código, ferramentas e testes compartilhados

    Aliado ao build contínuo, também é uma das práticas a reintegração constante de todo o código produzido. Outra forma de compartilhamento de código é a utilização da técnica de pair programming e revezamento constante de pares. Assim, todo o código produzido passa a ser de propriedade coletiva com praticamente nenhum risco de dependência individuais.

  10. Sprints curtos ou fluxo contínuo

    A prática de entregas em intervalos mínimos é indispensável para que este modelo tenha sucesso. Contudo pode-se optar por entrega em sprints (timebox curtos fechados) ou ainda por fluxo contínuo. Nesta segunda forma, as entregas são feitas por módulos parciais que agreguem valor. O timebox não é fixo mas existe intervalo máximo definido para que ocorra a entrega. Cada projeto determina qual a melhor estratégia para a entrega contínua.

Modelo Escopo Priorizável

Neste modelo é preciso uma formalização do valor do projeto e um escopo macro definido. As práticas ágeis e entregas contínuas são realizadas, existe uma limitação de custo e algumas barreiras de escopo. Nas empresas que existem uma limitação de contratação no modelo completamente ágil, este é o melhor modelo aplicável.

  1. Práticas ágeis e técnicas mantidas

    Todas as práticas ágeis de questão técnica do Modelo Ágil (Full Agile) são preservadas. Assim, temos ainda: build estável, entregas contínuas, código compartilhado, visibilidade e refactoring. No caso desta última prática, são determinadas fases de refactoring já no planejamento inicial.

  2. Interação com o cliente

    Neste modelo a interação com o cliente é um pouco menor, mas mesmo assim fundamental. Os aceites das entregas ainda são fator determinante bem como a priorização do escopo ainda não desenvolvido. Também para o detalhamento do escopo são necessárias decisões rápidas por parte do cliente e equipe

  3. Acompanhamento do escopo faltante

    Dado que existe um custo e escopo macro definido, existe a necessidade de controle de planejado versus executado. Monitoria e reuniões de checkpoints são realizados para tal fim.

  4. Change Requests

    Neste modelo não estão previstas recontratações de mudanças já que o detalhamento do escopo é feito ao longo do projeto. Contudo, caso alguma mudança extrapole o macro escopo, é necessário um novo anexo ao contrato para ajuste do valor e definição geral do escopo.

  5. Melhoria contínua

    O processo de melhoria contínua como desenvolvimento de ferramentas, automações ou qualquer outro investimento não ligado diretamente ao produto somente é possível caso exista um acordo inicial ao projeto. Assim, tal processo acaba sendo viável em grandes contratos, mas em menores fica restrito às políticas internas da própria contratada, Objective.

Modelo Ágil ‘para dentro’ (Agile to Waterfall Adapter)

Se a sua empresa procura um nível de prescritividade maior, sentindo-se mais seguro com entregas determinadas e sem muita interação com o fornecedor é possível também atendê-lo, embora abrindo mão das vantagens que a gestão ágil pode trazer. Assim, o cliente acaba estabelecendo um contrato com escopo e custo fechado. Acreditamos que neste modelo ainda as práticas ágeis se tornam como melhor forma de atuação nos riscos, gestão e qualidade do produto entregue.
Portanto, mesmo que a gestão visível ao cliente não seja conduzida de forma ágil, a gestão interna, a arquitetura e a interação de nossos times continua acompanhando o que estabelecemos como sendo a cultura da empresa. Em outras palavras, continuamos agindo de forma ágil. Para melhorar um pouco a gestão de riscos, costumamos dividir o escopo em entregas faseadas de forma a conseguir aceites parciais e, eventualmente, corrigirmos desvios ao longo do desenvolvimento.

  1. Práticas ágeis técnicas mantidas

    Práticas ágeis técnicas mantidas: Todas as práticas ágeis de questão técnica do modelo anterior são preservadas. Assim, temos ainda: build estável, entregas contínuas (fases), código compartilhado, visibilidade, refactoring e melhorias. Refactorings e melhorias são cobrados com base no histórico de outros projetos aliada a gestão de riscos, ou por investimento arbitrário da contratada.

  2. Validações formais

    Neste modelo, também ficam previstas em contrato as validações formais das entregas, dado que existe um escopo definido. Portanto, para cada fase são estipulados critérios e tempos de aceite.

  3. Garantias definidas

    Nos modelos anteriores, a atuação em defeitos faz parte do acordo de trabalho e, portanto, entram no fluxo de desenvolvimento como novas tarefas. Já neste modelo existe uma necessidade de garantia futura do que está sendo entregue. Assim, são definidos políticas de multas e garantias e adicionados custos para gestão destes riscos.

  4. Acompanhamento real do projeto

    Embora seja um projeto de maior risco, com nossas ferramentas de gestão e análise de históricos conseguimos trazer grande visibilidade e alta capacidade de decisão perante novos desafios se compararmos com projetos puramente ‘cascata’. Tal característica deve-se ao fato de que metodologias ágeis impulsionam processos simples e automatizados, facilitando assim o controle e transparência do que está acontecendo

Cases de Sucesso sobre Desenvolvimento de Software