Reflexões sobre o Manifesto Ágil – Parte 2: Software Funcional

AGRADEÇA AO AUTOR COMPARTILHE!

Dando continuidade a série de reflexões iniciadas semana passada, sobre os 4 valores do Manifesto Ágil, hoje falarei sobre Software Funcional mais que Documentação Abrangente.

Muitas empresas exigem que qualquer processo de desenvolvimento só pode começar após a área de negócios preencher documentos como Scope Statement, Business Requirement, Change Request, Use Case, fora outras documentações de governança exigidas. Até aí, problema algum! O problema surge quando estes documentos se tornam o principal canal de comunicação entre a área de negócios e o time de desenvolvimento.

reflexoes-sobre-manifesto-agil-software-funcional

Já vi absurdos de alguns times de desenvolvimento exigirem que o documento de especificação tenha no mínimo 50 páginas para passar clareza! Ora, como vimos no artigo anterior, por que não usar e abusar da comunicação verbal para passar clareza?

Outra situação delicada ocorre com empresas que implementam escritórios de PMO da forma mais “engessada” e burocrática possível (lembrando que não são as boas práticas do PMBOK que “engessam” os processos e sim as pessoas que aplicam as boas práticas de forma burocrática). Estes escritórios costumam exigir diversas documentações para atender ao processo de governança.

Mas pergunto: “E a qualidade do meu software? Qual a garantia que todas estas documentações vão gerar um software de qualidade?”. Já vi casos de documentações tecnicamente perfeitas, atendendo a todos os processos de governança, e o software ser uma bela porcaria. Pergunto: “Valeu a pena?”.

Se a interatividade entre business e developers é um dos fatores-chave para o sucesso de um projeto, o canal de comunicação entre eles deve ser “leve”. Utilizem artefatos leves como Kanban, planilha Excel, postites, cartões, usem e abusem de técnicas ágeis como user stories.

Aí você pode me perguntar: “Mas Vitor, isto soa muito anárquico! E se um diretor da minha empresa pedir a documentação do meu projeto? Vou mostrar para ele um monte de postites pendurados na parede?” Minha resposta é: Não. Você deve continuar gerando a documentação “pesada” do seu projeto se necessário, mas esta documentação não deve ser o canal de comunicação com seu Dev. Team e sim a formalização do processo para ser arquivado dentro da empresa. Inclusive recomendo que esta documentação seja elaborada no final de cada Sprint ou mesmo ao final de cada Release, onde já se conhece no detalhe tudo o que está sendo entregue.

Lembrem-se sempre que o projeto deve entregar um produto de qualidade e não somente uma documentação de qualidade. Um exemplo prático: Você lê um longo artigo numa revista dizendo sobre um determinado restaurante. O artigo está bem escrito, dá bastante detalhes dos tipos de comidas servidas, carta de vinhos e preços. Você se interessa e vai ao restaurante, mas quando chega lá encontra garçons mal-educados e comida não tão boa assim. Você voltaria?

Agora faça esse comparativo com um projeto de software, reflita e tire suas conclusões.

Abraços e até semana que vem !

AGRADEÇA AO AUTOR COMPARTILHE!

Vitor Massari

Mais artigos deste autor »

Profissional com mais de 15 anos de experiência em projetos de software. Sócio-proprietário da Hiflex Consultoria, profissional PMP e agilista, acredita no equilíbrio entre as várias metodologias e frameworks voltados para gerenciamento de projetos.
Lema: "Agilista convicto sempre, agilista obcecado jamais"


1 Comentários

Paulo Henrique A Costa
1

Muito bom o artigo, parabéns pela “simplicidade” com a qual demostra os Termos [Isso faz uma diferença enorme como Bibliografia para o treinamento de pessoas dos mais diversos ramos de Ocupação Profissionais.


Att
Paulo Henrique A Costa
Técnico em Informática

Deixe seu comentário

Seu endereço de e-mail não será publicado. Campos com * são obrigatórios!

Você pode usar estas tags e atributos de HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">