Há muitos vídeos e textos disponíveis na web que podem dar a impressão de que o uso de metodologias ágeis, em especial o Scrum, é a coisa mais fácil do mundo. Comecei a escrever sobre o Scrum em 2006, sempre procurando expor práticas que aprendi, utilizei e, por vezes, adaptei. Descobri, ao longo de minha aprendizagem, que, uma vez implantada a cultura do Scrum, tudo é, realmente, fácil, desde que não se deixe a peteca cair.
Mas e antes da implantação? Como começar a criar a cultura de agilidade no planejamento estratégico de uma empresa e na gestão de seus projetos? Não há bala de prata, claro. Os lobisomens são todos diferentes.
Algumas empresas fornecedoras e muitas das consumidoras já não aguentam mais o Grande Contrato, aquele que define qual será o sistema que estará pronto para o uso daqui a dois anos, amarrado aos requisitos de hoje e que, em suma, não será útil para muita coisa quando for entregue. Empresas e seus clientes, assim como tecnologias, mudam. Planos e sistemas devem ter agilidade para acompanhar as mudanças, não para servirem de obstáculos a elas.
Porém as empresas também já estão fartas de promessas feitas por consultores (ou consultorias) que, de tempos em tempos, apresentam uma bala de prata que deveria resolver problemas de planejamento, desenvolvimento, contratações. Em alguns casos, o Scrum, em conjunto ou não com outros métodos ágeis, foi apresentado dessa forma. Aí não faltam detratores que digam que o Scrum não funciona para este ou aquele tipo ou tamanho de projeto, que sistemas desenvolvidos com métodos ágeis padecem de documentação e outras mentiras de maior ou menor tamanho.
O Scrum requer pequenas mágicas essenciais para funcionar bem. Todas elas estão descritas na clássica apresentação do Mike Cohn, “Uma introdução ao Scrum”. Pode ser mais interessante, porém, não dar nome às mágicas na hora em que você for introduzir o Scrum em uma empresa ou em um grupo de desenvolvimento. De forma interessante, há um nome para essa tática de introdução camuflada do Scrum: Stealth Scrum!
Um artigo do Scrum Alliance sugere o uso de mapas mentais para a criação de um dos artefatos mais importantes do Scrum: o Product Backlog. O bacana é que muita gente já utiliza mapas mentais como artefatos para o planejamento de qualquer coisa, e, assim, uma lista priorizada com o que se espera de resultado de um projeto ou itens que irão compor um sistema ou produto podem brotar a partir de um mapa mental. Ninguém precisa usar o jargão do Scrum (e até aí nenhum jargão) para criar aquilo que nós chamaremos, talvez não na frente dos outros, de Product Backlog.
Vou usar como exemplo o projeto para um “Portal Ibero-Americano de Colaboração e Desenvolvimento Tecnológico”, que imaginei quando trabalhei em um projeto financiado pelo governo finlandês, que buscava fortalecer a associação do uso de software livre à geração de emprego e renda (parte disso acabou sendo utilizado, mais tarde, no Portal do Software Público Internacional).
A ideia buscaria o financiamento de governos, instituições e empresas de vários países para manter um grupo pequeno (entre cinco e dez pessoas) que trabalhasse tanto na pesquisa de necessidades quanto na articulação de contatos que tornassem viáveis projetos que pudessem ser úteis a várias geografias. Em resumo, se existisse um projeto na Argentina que pudesse atender a alguma necessidade específica do México, da Espanha e do Brasil, seria criada uma rede entre os potenciais usuários e financiadores para que o projeto se tornasse economicamente viável e, mais do que isso, que pudesse gerar receita para empresas envolvidas no seu suporte e desenvolvimento – com isso criando também novos postos de trabalho. A ideia não era tão inédita assim, mas buscava agregar boas práticas e vontades que desenvolvemos nesse trabalho para o governo finlandês.
Enquanto pensava em como exemplificar as ferramentas de acompanhamento e controle de histórias do Scrum, concluí que o melhor era partir direto para a prática e usar o “Portal Ibero-Americano de Colaboração e Desenvolvimento Tecnológico” como base para este exercício. Espero que os leitores concordem.
Descrição do projeto
Este portal não pretende criar novamente o que já existe, mas, ao usar o máximo possível estruturas e sistemas desenvolvidos. Seu intuito é que sua própria implementação já sirva como uma experiência de integração entre projetos da comunidade. Assim, alguns elementos clássicos e de sucesso entre a comunidade de software livre serão devidamente reconhecidos, valorizados e agregados a este projeto.
Para o repositório de software, será usada a estrutura do GitHub.com, a maior comunidade de desenvolvimento de código aberto. Será criada uma interface personalizada para o acesso ao GitHub, incluindo os seguintes serviços:
1. Registro e hospedagem de projetos
Será permitida a seleção da linguagem em que o registro do projeto será feito (inicialmente português e espanhol), facilitando a hospedagem de projetos com um “template básico” para a criação de um sítio web, fóruns de discussão e outros itens que podem ser agregados posteriormente à medida que o desenvolvedor se torna mais experiente com a ferramenta.
Nota: Aqui imagino um assistente automatizado, disponibilizando uma página básica e uma seleção guiada da inclusão de ferramentas ou não, explicando uma a uma.
Exemplo: Deseja criar listas de discussão para o seu projeto? Recomendamos, caso seja usado esse recurso, que se criem ao menos duas listas, uma para usuários e outra para desenvolvedores de seu projeto. Se você desejar, criaremos agora uma lista chamada projeto-user e outra chamada projeto-devel. Caso prefira escolher outro nome para as suas listas ou acessar a configuração avançada, clique aqui.
Este assistente poderá ser chamado várias vezes dentro da página de gestão do projeto, mas não pode ser destrutivo. Ele sempre deve detectar o que o usuário já possui e apenas oferecer novas ferramentas a serem agregadas.
Ao classificar um projeto, seu criador pode escolher categorias às quais o mesmo pertence, mas um administrador do portal pode “recategorizar” o projeto de forma a garantir sua correta exposição na busca por categorias e mesmo para “alinhar” projetos de natureza similar, buscando a interação entre eles.
Projetos hospedados em outros sítios podem ser categorizados também aqui, servindo este portal, então, como um apontador para outros repositórios como o SourceForge, Savanah e outros.
2. Notícias
As notícias podem ser relativas aos projetos, de responsabilidade dos desenvolvedores e publicadas com destaque na página principal (de todos os projetos), na página do projeto (apenas as relativas a ele) e devem poder ser exportadas para outros sítios em formatos como o RSS.
Notícias postadas pela comunidade ibero-americana também serão aceitas de várias formas, com níveis de mediação. Notícias postadas anonimamente sempre passarão pelo crivo do gerente de conteúdo. Notícias postadas por usuários registrados terão prioridade, mas também passarão pelo crivo de um gerente de conteúdo. O gerente de conteúdo pode autorizar alguns usuários a postarem notícias no portal sem a necessidade de mediação.
Notícias que vêm de outros portais podem ser incluídas neste por meio de mecanismos como RSS.
3. Multi-idiomas
Inicialmente, todo o portal terá sua interface em português e espanhol. Os conteúdos podem ser disponibilizados em apenas uma língua, havendo neste caso, quando da exibição do conteúdo em uma língua para o qual não foi traduzido, a opção para que o leitor ou colaborador “envie uma tradução”. Por exemplo, um projeto com desenvolvedores brasileiros postará suas notícias e demais informações em português. Quando alguém de língua espanhola acessar uma informação não traduzida, ele a lerá na língua original, mas terá a possibilidade de colaborar com uma tradução. Isso pode ser expandido para outros idiomas.
4. Gestão do ambiente e estrutura de suporte
Este portal visa ser referência e ponto de integração no desenvolvimento de software livre para a comunidade ibero-americana. Além da ação prática de hospedagem de projetos (ou apontadores para outros portais), ele será a base de uma ação de integração e busca de recursos para desenvolvimentos que estejam ligados à geração de emprego e renda, inclusão social e resolução de conflitos.
Dessa forma, a fim de que o portal atinja o sucesso em suas metas, propomos a montagem de uma estrutura que pode ser ampliada à medida que seu uso se intensifique:
Comitê Gestor
Formado por membros da comunidade, mediante indicação dos financiadores desse portal e com vagas abertas para a eleição democrática de outros membros da comunidade ibero-americana.
Equipe de suporte
- Gerente de conteúdo (para aprovar as notícias e negociar relações com as fontes).
- Analistas de suporte (2) (para resolver questões técnicas e cuidar da saúde operacional do sistema).
- Diretor executivo (representante do portal perante a comunidade, ligação entre o comitê gestor e a equipe de suporte).
- Tradutor português-espanhol e vice-versa.
Ideias para o cronograma de implantação (planejamento de versões)
• Fase 0: integração do GitHub.com ao portal ibero-americano, treinamento dos analistas de suporte.
• Fase 1: criação das interfaces de registro de projetos baseadas, interagindo de forma transparente com o GitHub, conforme leiaute definido pela equipe de arte contratada à parte.
• Fase 2: sistema de notícias.
• Fase 3: multi-idiomas. Testamos toda a interface em português e depois se faz o porte para o espanhol, deixando aberta a possibilidade de tradução para outras línguas.
• Fase 4: suporte continuado.
Numa estimativa inicial, cheguei a oito semanas de desenvolvimento para as fases 0 a 3, com o envolvimento semi-integral de um gestor e o uso de pessoas contratadas para a escrita de código.
Mapa mental
Note como a discussão sobre o que será o projeto fica bem mais “visível” com o uso do mapa mental (Figura 5.1). Cada um dos itens de trabalho pode ainda ser mais detalhado e facilmente expandido (como, de fato, alguns já foram). Com o mapa exposto para a equipe de projeto e seus patrocinadores fica fácil de, olhando cada ramo do mapa, priorizar as histórias usando, por exemplo, o Poker do Planejamento (sobre o qual falaremos logo a seguir) ou qualquer outra técnica que você preferir.
Figura 5.1 – Mapa mental proposto para o Portal Ibero-Americano de Software Livre
Criadas e priorizadas as histórias (você tem seu Product Backlog e nem chegou a falar nisso!), você as distribui em fases semanais (seus Sprints) buscando garantir que o esforço em cada semana será dividido da maneira mais uniforme possível. No caso do surgimento de uma nova história ou da necessidade de repriorização, volte ao mapa mental. Por meio dele será fácil mostrar que uma nova história pode impactar o projeto como um todo, incluindo o tempo para a sua conclusão.
