A maturidade organizacional em desenvolvimento de processos cresceu, e com ela, também aumentaram a busca pela alta competitividade e qualidade.

Além disso, as empresas não têm tido tempo a perder com projetos de escopo fechado, que duram mais de 6 meses.

Por isso, as organizações estão adotando cada vez mais abordagens ágeis, com o principal objetivo de aumentar o valor de negócio para a organização.

Com este interesse pelos métodos ágeis em voga, muitas dúvidas surgem no mercado a respeito desses modelos. Veja algumas:

• É possível usar uma combinação de modelos tradicionais (PMBOK, por exemplo) e agilidade?
• As duas abordagens são compatíveis (tradicional e ágil) e/ou complementares?

Entendendo que os modelos tradicionais de gestão e os métodos ágeis tem o mesmo objetivo, que é alcançar o sucesso do projeto, como adaptar as práticas ágeis ao contexto organizacional? Qual abordagem ágil é a melhor para minha empresa?

Iniciaremos com uma linha do tempo sobre as metodologias ágeis que surgiram inicialmente na área de TI (Tecnologia da Informação) e hoje são amplamente utilizadas por outros domínios, tais como oficinas mecânicas, hospitais, comércios, advogados e até para o uso pessoal.

Ao longo dos anos, essas metodologias foram surgindo e, com elas, mitos e histórias sobre sua eficácia também vieram à tona.

Muitas pessoas duvidavam da eficiência dos processos ágeis e afirmavam as seguintes mentiras, que, aliás, foram desmistificadas e esclarecidas com o tempo:

• Os ambientes ágeis são ad hoc, caóticos e indisciplinados.
• Adotar a agilidade significa nenhuma documentação.
• Processos ágeis são imaturos e não são rigorosamente seguidos.
• Processos ágeis não funcionam para equipes geograficamente distribuídas.
• Agilidade não funciona com equipes grandes.
• Metodologias ágeis não funcionam em empresas que não são de software (Neste item posso afirmar que existem muitas empresas que não são de software como McDonald´s, Oficinas Mecânicas e até escritórios de contabilidade usando metodologias ágeis).

Percebe como estas afirmações não fazem sentido? É totalmente incoerente dizer que não adotar uma gestão ágil é adotar um processo sem documentação.

Se existem documentos que devem ser gerados, eles devem ser previstos como tarefas e sua revisão nos critérios de “done”.

Os valores e princípios da agilidade se remetem a agregar valor ao cliente. Se para o cliente tais documentos são importantes, os mesmos serão gerados.

Os ambientes ágeis, por promover um senso comum e espírito de equipe, costumam ser bem mais silenciosos e disciplinados que as equipes tradicionais.

Alguns times possuem regras claras quanto ao uso de celular e conversas paralelas fixadas no quadro.

Normalmente equipes ágeis são mais maduras e, por isso, sabem da importância que deve ser dada as cerimônias e aos indicadores e acompanhamento do projeto.

Equipes geograficamente distribuídas e/ou grandes são um desafio para qualquer tipo de abordagem, seja ela tradicional ou ágil.

Para auxiliar nisso, existem técnicas de facilitação ou coaching que estão sendo amplamente usadas em projetos que facilitam o team building e encurtam distâncias.  

Por exemplo: os congressos sobre métodos ágeis possuem trilhas específicas para áreas que são e que não são de TI comentarem e relatarem suas experiências.

É possível notar a presença de médicos, advogados e até empresas de seguros nestas trilhas.

Manifesto Ágil – Valores e Princípios Ágeis

Para falar de metodologias ágeis, não se pode deixar de mencionar os manifestos ágeis – seus princípios e valores.

O surgimento do manifesto ágil se deu em meados de 2000, quando um grupo de agilistas influentes da comunidade do XP (Extreme Programming) decidiu discutir novas técnicas para eliminar algumas falhas em processos.

Conheça a história completa do Manifesto Ágil.

O manifesto ágil é simples, direto e claro. Conheça os 4 valores e 12 princípios desta metodologia:

Valores:

• Indivíduos e interações mais que processos e ferramentas.
• Trabalhar no software mais que documentação abrangente.
• Colaboração do cliente mais que negociação contratual.
• Responder às mudanças mais que seguir um plano.

Existem interpretações a respeito deste manifesto, onde traduzem o advérbio de intensidade “mais que” por não ter.

O Manifesto estabelece uma priorização a respeito de questões comuns em projetos, inserindo um pensamento de colaboração, simplificação e ação.

Para detalhar este pensamento, listo abaixo os princípios ágeis. Eles podem ser resumidos em (Aprendizado, Feedback e Desenvolvimento iterativo):

Princípios

1. VALOR

“Nossa maior prioridade é satisfazer o cliente por meio da entrega cedo e frequente de software com valor”.

O foco no desenvolvimento do produto ou serviço está em prover entregas de valor ao cliente, ou seja, a preocupação maior está na satisfação do cliente.

Mudar sempre que necessário seja o escopo e/ou o planejamento realizado anteriormente é prioritário, já que entregar algo de valor é mais importante que seguir um planejamento inicial.

2. FLEXIBILIDADE

“Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se adequam a mudanças, para que o cliente possa tirar vantagens competitivas”

Os processos Ágeis utilizam a mudança em favor da vantagem competitiva para o cliente.

Aceitar a mudança como algo que sempre vai existir e se preparar para lidar com ela é fundamental.

Quando definimos ciclos curtos de feedback, permite-se essa evolução do conhecimento da equipe e do cliente.

Um processo de mudança burocrático desencoraja e muitas vezes impede uma mudança que é extremamente necessária para o sucesso do projeto.

3.  FREQUÊNCIA

“Entregar software funcionando com freqüencia, na escala de semanas até meses, com preferência aos períodos mais curtos.”

Entregar de forma frequente partes do produto e/ou serviço que tenham valor para o usuário e/ou cliente.

Assim, é possível dar um feedback rápido ao cliente, reduzindo diversos riscos do projeto (sejam eles de escopo, prazo ou tecnologia).

Esse princípio se opõe a realizar poucas ou, no limite, uma entrega de valor única, apenas ao final do projeto (o ciclo de vida cascata tradicional).

4.   TRABALHO EM EQUIPE

“Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em conjunto e diáriamente, durante todo o curso do projeto.”

O Trabalho em conjunto e a comunicação constante precisam realizados de forma frequente, objetiva e diária.

Esse princípio se opõe a falta de comunicação entre usuários e o time, entre o próprio time e entre o time e seus líderes. Pessoas não trabalham de forma obscura e individual.

5.  MOTIVAÇÃO DE EQUIPE

“Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte necessário, e confiar que farão seu trabalho.”

Dar valor às pessoas e à necessidade de motivação diária com o aumento da visibilidade e das regras do jogo. Confiança é a chave de um trabalho em equipe.

6. COMUNICAÇÃO

“O método mais eficiente e efetivo de se transmitir informação para e entre uma equipe de desenvolvimento é a conversa cara a cara”

A melhor forma de comunicação entre membros do time que desenvolve o produto e /ou serviço e entre esse time e o mundo externo é a comunicação face a face.

Em outros casos, é possível a utilização de ferramentas e técnicas de team building para construir algo bem próximo a sinergia existente na face-face.

7. FUNCIONALIDADE

“Software em funcionamento é a principal medida de progresso.”

Ter o principal objetivo de gerar produto/ou serviço que possui algum valor ao cliente do que algo que não vai ser utilizado.

A documentação deve ser útil e com o objetivo de aumentar o valor agregado ao cliente, traduzido em partes de produtos ou serviços.

8. MANTER UM RITMO CONSTANTE EM UM AMBIENTE SUSTENTÁVEL

“Processos ágeis promovem um ambiente sustentável. Os patrocinadores, desenvolvedores e usuários, devem ser capazes de manter indefinidamente, passos constantes.”

Os processos Ágeis promovem o desenvolvimento sustentável. Por isso, deve ser definido um ritmo constante e sustentável para o trabalho do time que desenvolve o produto e/ou serviço, o que se torna possível quando esse ritmo é apoiado por toda a cadeia, incluindo a Alta Direção e os Clientes.

Horas extras trazem desmotivação e falta de qualidade de vida, o que prejudica a produtividade e consequentemente o alcance dos objetivos do projeto.

9. PREOCUPAÇÃO COM QUALIDADE

“Contínua atenção à excelência técnica e bom design, aumenta a agilidade.”

A preocupação com a qualidade deve ser única e constante. A qualidade deve ser mais prioritária que o prazo e a produtividade.

10. SIMPLICIDADE

“A arte de se maximizar a quantidade de trabalho não feito – é essencial.”

Quando não se realiza algo que não é necessário, evita-se o desperdício do desenvolvimento do produto e serviço.

Portanto, para começar, elabore uma documentação útil para ser utilizada e planeje os detalhes que se conhece.

11. ORGANIZAÇÃO

“As melhores arquiteturas, requisitos e projetos emergem de equipes que se auto-organizam.”

Equipes com maior autonomia e auto-organizadas são mais eficientes. Esta característica de não esperar um comando traz responsabilidade e liberdade para decidir qual a melhor forma de realizar um trabalho.

12. AUTOCRÍTICA

“Em intervalos de tempo regulares, a equipe reflete sobre como se tornar mais efetiva e então refina e ajusta seu comportamento de acordo.”

Para se tornar cada vez mais efetiva, a equipe regularmente inspeciona suas formas de trabalho e se adapta, quando oportunidades de melhoria são identificadas, promovendo a melhoria incremental contínua.

É um processo iterativo e incremental para o desenvolvimento de qualquer produto e gerenciamento de qualquer projeto.

SCRUM – UM DOS MANIFESTOS ÁGEIS MAIS POPULARES DO MUNDO

Finalmente, explicado o que são processos ágeis e toda a sua história, podemos falar dele, um das maiores formas de otimização de processos, conhecido mundialmente.

Desenvolvido para atuar no gerenciamento de processos mais complexos, o SCRUM resumidamente tem como características:

• Não é metodologia;
• É um framework;
• É adaptável;
• Promete alta qualidade;
• Promete alta produtividade e;
• Baixo custo
• É atitude!

O SCRUM tem como pilares:

• Transparência – Tudo que afeta o resultado final deve ser visível para aqueles que gerenciam os resultados.
• Inspeção – O processo deve ser inspecionado com uma frequência suficiente para identificar variações inaceitáveis. É importante ressaltar que inspeções demais podem atrapalhar dependendo do contexto.
• Adaptação – O processo deve ser inspecionado com uma frequência suficiente para identificar variações inaceitáveis.

O Scrum é baseado em:

• Times de Scrum (Papéis) -Product Owner (PO), Scrum Master (SM) e Team (Time)
• Time-Boxes (Eventos) – As cerimônias devem ter um time-box de no máximo 4 horas (no caso de planejamento de sprints de 4 semanas).
• Artefatos – Os artefatos User Story, Task Board, Product e Sprint Backlog  e BurnDown Chart são utilizados ao longo de todo o ciclo do Scrum.
• Regras – As regras como critérios de done, aceitação e regras de time são estabelecidas e seguidas ao longo do ciclo Scrum (seja de 2 ou 4 semanas).

Times de Scrum

Product Owner: O Product Owner tem o papel de garantir o ROI, conhecer as necessidades do cliente, manter os itens do backlog atualizados e priorizados, aceitar ou rejeitar o que foi produzido, ter alta participação no início e no fim do sprint, gerenciar os requisitos e planejar entregas (releases) e esclarecer dúvidas.

Scrum Master: este time tem responsabilidade de remover os impedimentos do time, garantir o uso do Scrum, proteger o time de interferências externas, ensinar a maximização do valor agregado, melhorar o dia-a-dia dos membros do time, combater a ilusão do comando-controle, priorizar os impedimentos e removê-los e facilitar as reuniões.

Team: deve ser multi-disciplinar, auto-gerenciado, produzir com qualidade e valor para o cliente, ter no máximo 9 integrantes comprometidos, responsáveis pelo alcance do objetivo, comunicativos e responsáveis pela resolução de conflitos.

O Fluxo do Scrum

O Fluxo do Scrum, ilustrado na figura abaixo, é caracterizado por ciclos regulares de 2 ou 4 semanas no máximo, chamados Sprints.

O ciclo de vida pode ser considerado evolutivo (o conhecimento sobre os requisitos evolui a medida que os incrementos vão sendo executados).

Os requisitos a serem produzidos em um projeto são mantidos em uma lista nomeada Product Backlog.

No início de cada Sprint, faz-se um Sprint Planning Meeting 1 e 2, ou seja, uma reunião de planejamento  na qual o Product Owner prioriza os itens que estão no Product Backlog  (Sprint Planning 1) e a equipe define e estima as tarefas que ela será capaz de implementar durante o Sprint que está iniciando.

As tarefas alocadas em um Sprint são incluídas então no Sprint Backlog.

Diariamente, ao longo da Sprint, a equipe faz uma breve reunião (normalmente de manhã), chamada Daily Scrum.

O objetivo desta reunião é tornar visível o andamento das tarefas e identificar impedimentos e priorizar o trabalho do dia que se inicia.

Ao final de um Sprint, a equipe apresenta o que foi produzido ao Product Owner em uma cerimônia chamada de Sprint Review Meeting. Finalmente, faz-se uma Sprint Retrospective, onde são discutidos os pontos de melhoria e ações para a próxima Sprint (melhoria contínua).

Em seguida, a equipe parte para o planejamento do próximo Sprint. Assim reinicia-se o ciclo.

Enfim, assim funciona o SCRUM. Se interessou? Conte aqui nos comentários sobre os processos de implementação desse framework e nos contate caso queira saber mais sobre como fazer!