A agilidade, ou a capacidade de responder às mudanças em seu mercado, costuma ser considerada um dos preditores mais significativos do sucesso de uma empresa. Na verdade, os projetos ágeis desfrutam de uma chance 60% maior de sucesso em comparação aos projetos mais tradicionais do tipo “cascata”.. 

Mas o que é Ágil? O conceito de uma abordagem Agile é algo que é muito discutido. Mas pode haver muita confusão sobre o que isso realmente implica. Tem algo a ver com paredes cheias de post-its coloridos? É um software sofisticado de gerenciamento de projetos? Ou algo que você só aprende com consultores especializados?

Nesta publicação, abordaremos os principais e mais importantes conceitos e processos do desenvolvimento de produtos Agile e como você pode aplicá-los à sua própria organização.

Primeiro, antes de olharmos para Agile, vamos dar uma olhada em cascata:

Cascata (Waterfall)

‘Cascata" (Waterfall) é o nome do estilo mais tradicional de desenvolvimento de produtos, tanto para software quanto para produtos físicos.

Segue um processo linear. Para começar, normalmente há um longo processo de planejamento (Planning), onde absolutamente tudo para todo o projeto é planejado. Esta fase de planejamento pode levar vários meses.

Após a conclusão do planejamento, o projeto passará para a próxima etapa, 'Design', onde todo o design do produto é finalizado. O projeto continua passando pelas etapas, sempre completando a última etapa completamente antes de passar para a próxima.

Finalmente, o produto acabado completo é lançado no mercado, meses, senão anos, após o estágio inicial de planejamento. Como resultado, o produto errado pode ser lançado no mercado. O que originalmente poderia ter sido um produto bem planejado com um ótimo ajuste ao mercado, agora pode estar desatualizado quando for lançado. A tecnologia pode ter mudado ou a demanda do mercado pode ter mudado.

Cascata (Waterfall) x Ágil

Então, olhamos para a Cascata (Waterfall), mas o que isso tem a ver com o Agile?
Bem, com o Agile, dividimos o processo em Cascata em partes menores.
Primeiro, fazemos apenas o planejamento necessário para começar. Em vez de planejar o produto inteiro, planejaremos apenas um componente muito pequeno dele, talvez apenas um ou dois recursos.

Em seguida, pretendemos construir e projetar apenas o suficiente para podermos enviar esse pequeno conjunto de recursos - também conhecido como 'versão incremental'.
No Agile, todo esse processo, desde o planejamento até a liberação incremental, geralmente leva cerca de 2 semanas e é frequentemente chamado de 'sprint'.
Depois de fazer um lançamento, começamos o ciclo novamente. A cada vez, estamos planejando apenas o suficiente para criar a próxima versão incremental de software funcional.

Ao enviar pequenos lançamentos regulares, o processo do produto é flexível. À medida que enviamos pequenos conjuntos de recursos ou versões incrementais, podemos começar a testar rapidamente e coletar feedback do usuário sobre cada recurso enviado. Esse teste contínuo significa que podemos responder rapidamente a requisitos novos e em constante mudança. Como resultado, podemos ajustar continuamente o roteiro de curto prazo para atender às necessidades do cliente, o que significa que temos muito mais chances de entregar um produto final que nossos usuários adoram.

Princípios Agile

O desenvolvimento ágil de produtos é baseado nos 12 princípios ágeis. No entanto, a fim de manter este artigo amigável para iniciantes, vamos nos concentrar apenas em 4 princípios-chave abaixo que acho útil ter em mente se você for novo no Agile.

1-Refletir e ajustar: Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz, então sintoniza e ajusta seu comportamento de acordo.

2-Satisfazer o cliente: Nossa maior prioridade é satisfazer o cliente por meio da entrega antecipada e contínua de software valioso.

3-Entregue com frequência: Entregue o software funcionando com frequência, de algumas semanas a alguns meses, com preferência pela escala de tempo mais curta.

4-Equipes auto-organizadas: As melhores arquiteturas, requisitos e designs surgem de equipes auto-organizadas.

Como você pode ver pelos princípios, Agile não é uma lista de processos a serem seguidos ao criar um produto, mas sim um conjunto de valores e crenças orientadoras que podem ser usados para ajudar a tomar decisões ao desenvolver produtos.

Se você está aprendendo sobre o 'mundo ágil', há uma boa chance de também ter ouvido outros termos, como 'Scrum' e 'Kanban'. Scrum e Kanban são metodologias ágeis populares. Eles são estruturas de desenvolvimento de produtos projetadas para ajudar as equipes a alcançar os princípios ágeis.

No entanto, embora essas metodologias possam ajudar uma equipe a ser ágil, elas não são necessariamente ágeis em si mesmas. Seguir essas metodologias só resulta em uma prática ágil se ajudar a equipe a alcançar os princípios ágeis. Você não precisa necessariamente seguir uma metodologia ou processos estritamente se achar que não está ajudando sua equipe a alcançar os princípios ágeis. A equipe está refletindo e se ajustando? Você está entregando recursos com frequência? Alcançar os princípios ágeis é o que determina se uma equipe é realmente ágil.

Talvez você esteja seguindo o Scrum, que sugere ter uma reunião diária para se conectar com sua equipe. Mas depois de segui-lo por algum tempo, simplesmente não está funcionando. Você descobre que sua equipe é mais produtiva e satisfeita tendo reuniões sentadas em torno de uma mesa. Tudo bem também! Você pode fazer essa mudança. Parte do Agile está respondendo à mudança, revisando seus processos e adaptando, e isso também pode significar adaptar como você estrutura o desenvolvimento de seu produto.

Por fim, você deve usar o que achar que ajuda sua equipe a tomar melhores decisões ágeis. Não existe um método ou sistema verdadeiro que seja a única maneira de ser Ágil.
Para equipes novas no Agile, pode ser mais fácil seguir uma metodologia estabelecida para começar com alguma estrutura em vigor, então, quando sua equipe se sentir confortável, você pode tentar mudar a fórmula.

Quem compõe uma equipe ágil?

Uma equipe ágil é composta por:

Equipe de desenvolvimento
Essa equipe geralmente inclui habilidades como design, desenvolvimento, teste e entrega. Os membros da equipe geralmente desempenham várias funções, alguns dias eles podem estar testando e outros dias desenvolvendo.

Product owner (Proprietário do produto)
Um Product owner (proprietário do produto) é responsável por maximizar o valor do produto criado pela equipe de desenvolvimento. Essa função interna reúne requisitos técnicos, prepara o backlog do produto e detalha as histórias do usuário.

Partes interessadas / acionistas (Stakeholders)
As partes interessadas podem ser qualquer pessoa afetada pelo desenvolvimento de um projeto de software. Isso inclui uma ampla categoria de pessoas, como usuários finais, executivos e TI.

Entendendo seus usuários

Antes de prosseguirmos, vamos examinar a comunicação com os usuários e entender suas necessidades.

No início do desenvolvimento de um produto, e de forma consistente durante todo o processo, você deve se comunicar e testar com os usuários. Geralmente, esse é um trabalho principalmente para o profissional de UX da equipe, se você tiver um, mas realmente todos os membros da equipe devem ser incentivados a conversar regularmente com usuários reais.

A comunicação com o usuário pode ser feita de várias maneiras:

• Entrevistar usuários atuais sobre como o produto funciona em suas vidas.
• Permitir que os usuários testem seus novos recursos após um sprint e forneçam feedback.
• Perguntar aos usuários em potencial sobre sua experiência com produtos concorrentes.

O objetivo da comunicação com o usuário é identificar as necessidades do usuário. Um exemplo de necessidade do usuário pode ser “comparar convenientemente as tarifas de telefonia móvel”. As necessidades do usuário sempre devem ser baseadas em conversas reais com as pessoas, não nas necessidades que a equipe acha que o usuário deseja.

Definindo a estratégia do produto

No início de um novo projeto de desenvolvimento de produto Agile, você precisa definir a estratégia do produto. Isso resume a necessidade de negócios que seu projeto está abordando. Em termos mais simples: qual é o objetivo final deste projeto Agile e como você o alcançará?

Os proprietários do produto são responsáveis por criar uma estratégia de produto em colaboração com suas partes interessadas para garantir a adesão e o alinhamento. It is optional, but recommended to include key members of the development team too.

Definir uma estratégia clara é crucial em um ambiente Ágil. Às vezes, as equipes de desenvolvimento podem se sentir presas aos detalhes de um projeto e perder de vista o objetivo geral por trás de todo o seu trabalho. A estratégia do produto é uma meta de alto nível à qual a equipe pode se referir para ter certeza de que está vendo o quadro geral.

Para se preparar para uma reunião de estratégia de produto, você já deve ter trabalhado de perto com os usuários para entender seus pontos problemáticos, pesquisado o mercado e estar ciente de seus objetivos comerciais gerais. Existem muitos modelos e ferramentas de tela que você pode usar para ajudá-lo a criar sua estratégia de produto. Um que eu acho muito amigável para iniciantes é o método de Elevator Pitch.

À medida que as oportunidades de inovação e crescimento são reconhecidas, muitas vezes não estão isentas de riscos associados. Gerenciamento de riscos, excelência operacional, segurança e conformidade não podem ser deixados de lado durante o desenvolvimento de software. Gerenciar esses riscos torna-se crítico para a sustentabilidade de uma organização.

Os riscos comumente associados podem ser conformidade com regulamentos, certificações, problemas de produção, e proteção de dados, os quais podem aumentar o custo se não forem mitigados corretamente.

O gerenciamento e a mitigação de riscos podem ser alcançados por:

Isolar e introduzir controles mais rígidos em áreas críticas

Entender as áreas de risco é fundamental para identificar e lidar com todos os riscos aos quais uma organização pode estar exposta. Sistemas críticos são os sistemas cuja falha pode resultar em perda de vidas, danos significativos ou danos ao meio ambiente. Ser capaz de isolar áreas como essas para implementar um controle mais rígido das alterações ajuda a garantir que o risco não esteja sujeito a um ambiente ativo. Isolar áreas que requerem auditorias mais rigorosas, de modo que mudanças em áreas não relacionadas não acionem auditorias, também pode reduzir significativamente o tempo e o esforço necessários para manter auditorias de sistemas críticos.

Adotando uma abordagem estratégica para a conformidade regulatória

Autoridades em todo o mundo divulgam e atualizam recomendações no ambiente de tecnologia, incluindo o uso da tecnologia em nuvem. Espera-se que as organizações cumpram os requisitos estatutários, incluindo leis de tecnologia, leis e regulamentos setoriais. O alinhamento com os regulamentos deve ser uma abordagem estratégica das empresas, com mais atenção aos requisitos e desenvolvimento para minimizar riscos e custos.

O objetivo das regulamentações no desenvolvimento de software é garantir a mais alta qualidade possível do produto final e, ao mesmo tempo, proteger o usuário (de situações como vazamentos de dados). As diretrizes geralmente são estabelecidas para o processo de desenvolvimento e seguir uma abordagem estruturada ajuda a entender cada etapa com facilidade. Isso também permite que cada etapa seja revisada por uma equipe sênior de partes interessadas para garantir que os regulamentos sejam cumpridos e possam ser facilmente adaptados.

Saiba mais sobre como as empresas podem ter a capacidade de responder às mudanças (como regulamentos) no mercado usando a abordagem Agile para desenvolvimento de produtos:

Desenvolvimento Ágil de Produtos na Prática.

Uso de serviços na nuvem para criar ambientes seguros e escaláveis

A escalabilidade da nuvem refere-se à capacidade de aumentar ou diminuir os recursos conforme necessário para atender à demanda em constante mudança. A computação em nuvem, ao contrário das máquinas físicas em data centers (cujos recursos e desempenho são relativamente definidos), pode ser facilmente ampliada ou reduzida por meio do gerenciamento "just-in-time" dos recursos disponíveis. Recursos e aplicativos podem ser deslocados conforme necessário.

Isso aumenta a conveniência e permite flexibilidade, pois as empresas podem atualizar os sistemas para atender a novos requisitos ou aumentar a capacidade e o armazenamento. Além disso, ajudando nos custos de recuperação de desastres, eliminando a necessidade de construir e manter centros de dados secundários.

À medida que o uso da nuvem continua a se expandir, os provedores de nuvem continuam a fazer um investimento significativo para garantir a proteção e a conformidade dos dados. Muitos serviços de nuvem para empresas possuem recursos de segurança integrados, incluindo criptografia, ameaças de terceiros e autenticação baseada em função do aplicativo.

Auditoria e registro projetados como cidadãos de primeira classe - requisitos operacionais

O software poderia ser projetado de forma mais eficaz para gerenciar riscos se o logging não fosse tratado como uma reflexão tardia ou uma ferramenta de depuração, mas sim como um recurso de aplicativo, parte dos requisitos de observabilidade mais amplos. Os requisitos para o logging são ser capazes de registrar os eventos que acontecem, ser capazes de reagir a todos e diferentes tipos de eventos (de várias maneiras), entender os padrões de longo prazo e registrar os eventos corretamente. Ao garantir a excelência operacional durante a auditoria (e a etapa de logging), isso ajuda a minimizar riscos futuros.

Eficácia operacional e controle de custos

Melhorar a eficácia operacional não é um truque de uma etapa, mas sim um esforço combinado de todas as equipes. É uma mentalidade a ser adotada em toda a organização, que maximiza os resultados e ajuda a rastrear e garantir o controle de custos. De acordo com o mantra do DevOps, a dica para fazer com que várias equipes trabalhem juntas é separar sua organização criando uma única equipe de DevOps que supervisiona o desenvolvimento, as operações e tudo mais. A excelência operacional serve como uma meta cultural compartilhada por todas as equipes e membros da equipe durante o processo de desenvolvimento e implantação de software. Ao tornar a excelência parte integrante de sua cultura, você ganha um princípio que pode guiar todas as suas equipes

Engenharia de Confiabilidade do Site (SRE)

A engenharia de confiabilidade do site é um conjunto de práticas e princípios que incorpora a engenharia de software e os aplica a problemas operacionais e de infraestrutura. O resultado, para criar sistemas de software altamente confiáveis e facilmente escaláveis.

As definições mais comuns dos princípios de engenharia de confiabilidade do site são as seguintes:

• Automação ou eliminação de qualquer coisa repetitiva que também seja econômica para automatizar ou eliminar.
• Evitar buscar muito mais confiabilidade do que o estritamente necessário. Definir o que é necessário é uma prática por si só.
• Projeto de sistemas com viés para a redução de riscos de disponibilidade, latência e eficiência.
• Observabilidade, como a capacidade de fazer perguntas arbitrárias sobre seu sistema sem ter que saber antecipadamente o que você deseja perguntar

A Codurance tem o prazer de anunciar que se tornou signatária do Tech Talent Charter (TTC), uma organização sem fins lucrativos com a missão de promover maior igualdade na tecnologia do Reino Unido e reduzir a crescente lacuna de habilidades tecnológicas. O TTC fornece uma comunidade e plataforma de conteúdo e ferramentas para apoiar as iniciativas de inclusão e diversidade de seus membros e criar novas oportunidades para atrair e reter talentos diversos. Eles também produzem um relatório anual de benchmarking usando dados de seus membros que acompanham a diversidade em tecnologia em todo o Reino Unido.

2020 foi um ano estranho, para dizer o mínimo. Aqui na Codurance, tivemos que adaptar nossos processos, sistemas e formas de trabalho para garantir que nossa equipe possa trabalhar remotamente, manter sua saúde e bem-estar e atender nossos clientes sem interrupções. Nem sempre foi fácil, mas continuamos a prosperar com o apoio de nosso pessoal fantástico, ótimas ferramentas e uma cultura de aprendizado. É essa grande cultura que primeiro atraiu nossa chefe de talentos e pessoas para a Codurance, como ela explica abaixo:

Muitas pessoas dentro e fora da comunidade de Software Craftsmanship referem-se a Craftsmanship como uma “Metáfora” para o Desenvolvimento de Software. Nós mesmos frequentemente nos referimos ao Software Craftsmanship como uma metáfora sem pensar muito no que isso significa para nós. Pensando mais profundamente, e olhando para nossos comportamentos e valores dentro da comunidade, não consideramos Craftsmanship como uma metáfora para o Desenvolvimento de Software. Dizer que Craftsmanship é uma metáfora para o desenvolvimento de software é dizer que é como um ofício, mas não literalmente um ofício. Essa não é a nossa perspectiva - achamos que o desenvolvimento de software é um ofício.

O Software Craftsman define o mindset do Software Craftsmanship e o que significa ser um desenvolvedor de software profissional.

Este livro é uma enciclopédia sobre o comportamento, atributos e estrutura de uma organização que se esforça para crescer em profissionalismo e aderir aos princípios de Software Craftsmanship.

Robert C. Martin