Analista Ágil: Como Ser Ágil em 10 Passos

Para executarmos estas práticas e conceitos ágeis na prática eu montei o Framework Ágil de atividades.

Este framework apresenta uma lógica de trabalho baseada em gerarmos o mínimo de desperdício com o máximo de eficiência no trabalho de desenvolvimento de software. Para isso, existem 10 passos cruciais para que um projeto não dê errado.

Entenda este processo e mude seu mindset logo para se adaptar a esse mundo novo que te apresento agora.

O framework apresentado não é somente uma série de recomendações soltas. É um processo de trabalho. E, assim como todo processo, necessita também de uma ferramenta para isso.

Mas esqueça, não vou te recomendar um software para isso. Com apenas uma planilha simples de poucas abas e recursos específicos já resolve é possível manter o controle deste processo de análise ágil e não deixar passar nada.

Utilize a partir de agora os dois templates que disponibilizei. Ambos serão necessários para entender a lógica do curso e para colocar tudo em prática.

IMPORTANTE: escolha um caso para colocar em prática no documento de template que está vazio. Pode ser um projeto que você já passou, um projeto que vem pela frente, uma ideia de negócio ou site... Enfim, escolha um case para estudar e já colocar essa cultura de trabalho ágil em prática e mudar a sua maneira de trabalhar com soluções de software.

Aqui você vai ler atentamente o caso da PizzaX e montar um cenário desejado também para o seu caso.

Da descrição da situação atual você terá que desvendar quais são os benefícios que o seu cliente espera receber. Em nível de negócio mesmo, em alto nível.

Imagine que o interessado aqui em visualizar os benefícios é o CEO, ou dono da empresa.

O usuário é quem deve saber o que pedir?
Ou o analista é o responsável por captar tanto o que está explícito quanto o implícito? As entre-linhas.

O quê está faltando entre as duas situações?

Esta pergunta é respondida no 3º passo. E já conseguimos assim pistas de "partes de solução" que poderemos propor ao nosso cliente/usuário.

Ok, vou começar a pensar em soluções para propor um escopo.

Mas peraí: quais são as limitações que tenho que considerar para isso?

Custo, tempo para entrega, o que o cliente deseja de antemão receber logo, com quem eu posso ou não posso ter acesso direto? Essas são perguntas que devem ser antecipadas para que possamos propor soluções dentro da realidade do cliente.

Premissas e restrições PERMEIAM o escopo da solução.

Não pense em telas de sistema.
Não pense em botões, funcionalidades específicas, regras de negócio.
Não pense em dar detalhes aqui.

Os temas da solução são pedaços macro do que vai ser proposto. O grau de abstração aqui deve ser alto.

Não cometa o erro de definir COMO será o comportamento da solução. Defina aqui O QUÊ vai compor a solução.

Desta aula você deve tirar uma lista de coisas a fazer sob forma de requisitos. O detalhamento de cada requisito será feito DEPOIS, normalmente durante os sprints que aparecerão lá no final do curso.

Você definiu os cenários. Você entendeu os problemas que ocorrem hoje e os benefícios esperados.
Depois você definiu um escopo para trabalhar em cima e entregar enfim o caminho para chegar na situação desejada, certo?

Bem, aqui nesta aula, você será capaz de justificar cada pedaço de escopo com cada objetivo de negócio.

Serve também para comprovar ou não a necessidade de uma mudança no escopo, de novos requisitos, de alteração de requisitos.

MUDANÇAS SÃO BEM VINDAS! Porém, desde que bem planejadas.

Ok, vamos pensar em entregar então isso tudo ao cliente?
Mas vamos analisar agora tudo no detalhe, construir todas as soluções e entregar tudo de uma vez daqui a "trocentos" meses? Não!

Agora é a hora de formar uma fila de prioridades para cada etapa do escopo. Afinal, depois vamos definir as diversas iterações do produto para entregarmos ao negócio de forma contínua.

Qual será a primeira entrega?

Vale a pena entregar uma tela de cadastro de clientes, e só? Aqui vamos exercitar e discutir como saber qual a menor parte da solução que deve ser entregue, mas que não seja pequena ao ponto de não servir para nada. O MVP deve ser algo mínimo (rápido ou fácil) mas que agregue de verdade ao negócio.

+ Produção enxuta
- Desperdício

Entenda como os fundamentos de Lean se aplicam ao analista ágil.

Após o MVP, o que vamos entregar? E depois?

Entenda como planejar um roadmap de entregas e como comunicar esse planejamento para quem deseja saber.

Nota: todo planejamento pode ser replanejado. O plano não importa. Planejar importa!

Do mais detalhado ao mais abstrato. Esqueça a velha maneira de especificar com foco SOMENTE no programador. Especifique sob o ponto de vista do cliente. Entenda que a solução deve ser construida para que alguém a utilize e tire daí resultados de negócio! Melhoria nos processos!

É difícil passar a escrever corretamente uma user story. É uma quebra de paradigma e ao mesmo tempo um exercício de escrita.

Tá difícil? Leia, estude, mas principalmente PRATIQUE. Valide sempre a US com o seu cliente ou usuário.

"Tá pronto! Uhuuuuuu!!!
Só falta testar..."

Existem "prontos" e "prontos"... Entenda de uma vez o que significa PRONTO para quem pratica a agilidade.

Toda mudança é difícil, todo mundo sabe disso. Mas mudar requer um primeiro passo.

Se você chegou até aqui, ao sair desse curso, coloque em prática!

Entenda aqui como fazer isso.

Quebra de paradigmas normalmente gera conflitos. Entenda como lidar com eles e o motivo pelo qual eles acontecem.

É sabido que o ser humano resiste a mudanças constantemente. Todos desejamos estar em uma zona de conforto e buscamos isso todos os dias.

No mundo corporativo é a mesma coisa. As empresas tem medo de mudar, de arriscar um pouco que seja para fazer diferente e, talvez assim, ter resultados diferentes.

Entenda porque isso acontece e o que eu proponho para mudar esse paradigma.

Para qualquer mudança é necessário um aprendizado novo. Entenda aqui quais são os super poderes que você precisa adquirir para trabalhar de forma ágil.

Te proponho uma reflexão sobre as competências fundamentais para esse trabalho.

Auto-crítica + auto-conhecimento.

Aqui te proponho uma maneira totalmente fora da caixinha para captar do cliente como os requisitos devem ser feitos. Entender um processo olhando o papel é uma coisa. Vendo o processo acontecer na sua frente é outra bem diferente.

Aprenda aqui como parar de fazer somente aquela reunião burocrática com seu cliente e tirar de uma vez por todas benefícios das técnicas que estou te apresentando.

Receita para Levantar Requisitos de Software

Com o passar do tempo e das minhas trocas de experiências eu montei um framework de técnicas para captação de requisitos de forma prática e rápida, porém, com uma assertividade muito superior aos métodos tradicionais.

Aprenda aqui como utilizar este framework.

Networking: você sabe como usar?

Adicionar no LinkedIn não é fazer networking. É adicionar no LinkedIn, só isso.

Estou aqui e em outros lugares para dividir experiências e aprendizados. Após esse curso siga em frente, continue, coloque tudo isso em prática. Depois venha me contar como foi!