Estimar um projeto é um processo um tanto complexo. No entanto, é uma exigência sempre presente, afinal, nenhuma empresa inicia um projeto sem ter nenhuma dimensão, ainda que vaga, de quanto tempo, esforço ou recursos serão necessários para sua execução. Já que não podemos fugir desse cenário, vamos compreender um pouco melhor as razões que levam estimativas usuais a falharem, bem como formas de estimar projetos, do ponto de vista ágil.
Com a grande difusão das práticas dos métodos ágeis, é comum vermos pessoas que executam seus rituais sem conhecer suas reais motivações. Esses profissionais, muitas vezes, partem de um conhecimento adquirido na prática do dia a dia, o que pode gerar uma compreensão superficial. O que está por trás dessa abordagem? Para contribuir com esse entendimento, propomos uma revisão dos 12 princípios que originaram os métodos ágeis. Mais do que descrever o princípio, buscou-se apresentar cenários e exemplos que facilitam sua compreensão. No primeiro post da série desmistificou-se o princípio A Satisfação do Cliente. Hoje vamos ao segundo princípio!
Nenhum plano é perfeito. E quando se trata de processos e projetos complexos, como na indústria do desenvolvimento de software, as incertezas e mudanças são enormes. Por mais que planejemos minuciosamente o desenvolvimento de um sistema, novas necessidades são identificadas, outras mudam, as prioridades do cliente são revistas, e planos ficam defasados em questão de semanas.
Hoje isso é amplamente aceito na comunidade, em parte pela influência daqueles por trás do manifesto ágil. Quando ele foi lançado, o modelo tradicional de desenvolvimento de software que predominava era o denominado waterfall, pois era constituído de uma sequência de grandes blocos de planejamento, arquitetura, desenvolvimento, testes, homologação, etc. Do planejamento à entrega as necessidades haviam mudado, uma boa parte do software necessitaria revisão, outra parte seria descartada e algumas novas necessidades precisariam ser incluídas. Projetos fracassavam.
Este ano comemoramos os 15 anos do manifesto ágil. Com o passar do tempo, a adoção de metodologias ágeis cresceu em larga escala mas ainda assim é comum encontrarmos pessoas que adotam práticas, sem compreender plenamente os princípios que as originaram. Por isso, proponho aqui no blog uma revisão dos 12 princípios que originaram os métodos ágeis.
Para quem está começando nesse mundo, o manifesto ágil é uma declaração de valores do desenvolvimento ágil de software, criada por um grupo pessoas que estavam mudando as práticas do mercado, pois queriam mais que tudo entregar software de valor para os seus clientes.
Hoje os métodos ágeis já estão bastante disseminados, e várias são as metodologias, frameworks e ferramentas de desenvolvimento consideradas ágeis. Sabemos que os métodos ágeis vieram para ficar, e que geram mudanças impactantes na forma como entregamos software, e em como nos relacionamos melhor como clientes e fornecedores.
O framework Scrum possui uma dinâmica de funcionamento relativamente simples, que é composta por um pequeno conjunto de eventos, papéis e artefatos. Mas tão ou mais importante que a implementação desta mecânica, é a vivência do valores do Scrum. Quando praticados pelo Time do Scrum, os valores do comprometimento, coragem, foco, abertura e respeito criam o ambiente em que os pilares do Scrum, de transparência, adaptação e inspeção, são vivos e a confiança do time é estabelecida.
São cinco os valores que sustentam um Time de Scrum:
O Scrum é um framework de desenvolvimento iterativo de produtos, que tem suas raízes no desenvolvimento de software ágil, dentro do qual pessoas são estimuladas a resolver problemas complexos e adaptativos, de forma incremental.
Esta postagem é uma introdução básica ao Scrum, e a primeira de uma série onde pretendo explorar os diversos princípios, estruturas, papéis e cerimônias, além de experiências práticas com o Scrum.
Quando falamos em microgerenciamento dentro de projetos, seja de qual natureza este for, normalmente a primeira imagem que nos vem na cabeça é negativa: Por exemplo, um gerente de projetos controlando todas as atividades de uma ou mais equipes, através de ferramentas de gestão. Seja planilhas, diagramas de Gantt e outros. Tudo com bastante rigor e preciosismo.
Mas associar esta imagem com o termo microgerenciamento é uma visão limitada que inclusive gera bastante descrédito para a prática em si e para o gerenciamento de projetos como um todo. Acredito que o microgerenciamento tem o seu aspecto positivo quando se busca atributos como desempenho e qualidade.
Na minha opinião microgerenciamento é uma atividade inerente ao trabalho em equipe. Ele faz parte da convivência em família, do trabalho escolar em grupo, e do desenvolvimento profissional de projetos em times. Logo a definição de bom ou ruim está muito mais relacionada ao como ele é feito e por quem, do que sua simples execução.
