1 – Agile não é uma metodologia. É um mindset.
Agile alcançou um patamar comum de conhecimento entre profissionais de projetos e negócio, não é mais algo novo, já vem sido discutido e utilizado há mais de 18 anos. Mesmo assim, conforme os profissionais vão se familiarizando, é frequentemente chamado como uma metodologia de desenvolvimento de software ou uma metodologia de gerenciamento de projeto.
Não é nem um nem outro. É uma forma de ver e pensar sobre como abordar trabalho de conhecimento. É um adjetivo não um nome.
Alistair Cockburn descreveu melhor em seu blog. O ponto principal do seu argumento é que metodologia é um conjunto de convenções que o time concorda em seguir. Scrum, Kanban, XP, SAFe, etc. são frameworks que equipes usam como um ponto de partida para criar uma metodologia que melhor se adeque ao seu contexto.
O mindset ágil nos dá caminhos que uma equipe pode seguir quando criando a sua própria metodologia, incluindo a ideia de que equipes podem criar sua própria metodologia logo de início. Eu penso que o mindset ágil é como descrito por Joshua Kerievsky:
Faça as pessoas serem incríveis
Faça a segurança ser um pré-requisito
Experimente e aprenda rapidamente
Entregue valor continuamente
2 – Existe mais nos métodos ágeis que o Scrum
O Scrum ganhou o mercado de framworks de usar com métodos ágeis e é hoje sem dúvida o formato mas utilizado nas organizações que implantam Agile. Isto leva muitas pessoas a concluir que ágil = scrum. Na verdade, scrum é apenas um dos tantos frameworks que se pode utilizar na implantação do Agile em uma equipe. Digamos que Scrum é o bombril do método ágeis.
Porque isso é importante? porque scrum é apenas uma forma de abordagem para usar e trabalhar com os valores e princípios ágeis, não é apropriado em toda a situação e não é uma solução completa. Se as pessoas pensam que tem que usar scrum para ser ágil, elas também concluem que tem de haver sprints, mesmo que a natureza do trabalho leve a si próprio a re-priorizar e entrega muito mais frequente que a cada duas semanas. Também pode direcionar a ignorar a excelência técnica que se obtém através do uso do XP extreme programming.
Importante: Scrum não é um acrônimo. É um termo buscado no rugby.
3 – Análise ainda é relevante
O fato de que a maioria dos frameworks não mencionam analistas de negócios não significa que análise de negócios não é importante. Os frameworks não têm a intenção de cobrir tudo o que precisa.
Os frameworks ágeis foram criados por desenvolvedores de software para resolver problemas que desenvolvedores de software enfrentam. Todos têm o papel de ser responsável por determinar o que é certo para que o time trabalhe. No Scrum este papel é do Product Owner. No XP, este papel é do cliente que trabalha com a iniciativa. A maioria destes frameworks não definem quando o que precisa ser feito é feito.
É aí que entra a análise! As técnicas de análise ainda são muito válidas, mas é preciso entender que como e quando se modifica em um ambiente ágil. Se executa pequenos esforços pontuais de forma mais frequente ao longo do trabalho, para apoiar a comunicação e construir um entendimento comum ao invés de se realizar todo o esforço de análise no início da iniciativa.
4 – Metodologias Ágeis sozinhas não farão você ficar melhor, mais rápido, com menor custo.
Equipes e empresas podem também utilizar análise para definir o que é correto fazer, e o que não fazer. Pois a maioria dos frameworks não menciona isso, eles deixam na responsabilidade de um integrante (exemplo: PO) na equipe, sem muito exploração de como o fazer.
Quando uma empresa começa a utilizar métodos ágeis na TI ou em outras áreas e não fazem mudanças em como gerenciar o portfólio de trabalho, em pouco tempo eles vão perceber que se tornaram mais eficientes em produzir coisas erradas, ou com pouco/nenhum valor.
Apenas quando a empresa combina o processo de decisão focado na entrega, com real valor para o negócio, é que se realmente obtém os benefícios de um mindset ágil.
5 – Escrever e dividir histórias de usuário não é toda a história
Análise de Negócios não existe para levantar requisitos, documentar e gerenciar requisitos. Segundo o Babok, ela existe para “realizar mudanças na organização através da definição de necessidades e recomendação de soluções que tragam valor para os stakeholders”. Logo, requisitos são meios para chegar no fim.
Na mesma linha de pensamento, há muito mais para se pensar em um mindset Ágil além das histórias de usuário e dividir elas com um esforço adequado dentro da sprint. Estes são apenas alguns mecanismos que se pode utilizar para promover o entendimento em comum com a equipe sobre um problema ou solução. Existe muitas outras técnicas que são excelentes para se ter conhecimento e utilizar sempre que necessário, tais como story map, job stories, especificação pelo exemplo, diagrama de contexto, decomposição de processo, prototipagem, wireframes, e uma série de outros.
Na próxima vez que você se ver grudado com as suas histórias de usuário, lembre o que diz Jeff Patton: “Histórias de usuários tem o seu nome por como elas devem ser utilizadas, não o que deve ser escrito”.
Deixei algo de fora?
Adoraria saber o que vocês acham disto. Tem algo importante que eu esqueci o qual o negócio precisa entender? Alguma pergunta sobre o assunto?
Escrevam no comentário para trocarmos uma ideia!
