Comentando a palestra “Análise de Negócios em Projetos Ágeis”

Ontem fui assistir à palestra do Claudio Kerber sobre análise de negócios ágil. Confesso que a idéia de entregar software rodando (software rodando, software rodando) mais rápido seduz, em um primeiro contato.

Porém houveram alguns pontos da palestra em que discordei do inteligentíssimo palestrante, que vou discorrer a seguir.

A melhor maneira de testar um conceito de um requisito é fazendo um protótipo funcionando do software que será entregue, numa versão “rascunho”.

Nessa ocasião, foi dado o exemplo da criação do sistema sob discussão numa página em Php, descobrir eventuais problemas do software e com a engenharia reversa, desenhar o caso de uso para que o time trabalhe.

Questionei a iniciativa pois a maioria dos analistas de negócio que conheço, conhecem código, e assim como eu, não possuem habilidade técnica para tal. Foi-me sugerido então, aplicação num Excel, Access, o que seria perfeitamente possível.

Porém, ainda discordo da prática, pois acredito que me utilizando de software para provar um requisito, apesar de parecer boa prática, corro o risco de me distanciar das necessidades do usuário e “puxar a sardinha” para o desenvolvimento. Mesmo que software rodando seja um bom argumento, há o outro lado da moeda: O stakeholder aceitar o software entregue, mesmo não atendendo 100% suas necessidades, só porque “veio rápido” e é possível “se adaptar ao software”.

Se o mundo acabasse hoje, e houvessem apenas baratas e desenvolvedores, sairia software.  Mas, se o mundo acabasse hoje e houvessem apenas baratas e analistas de negócios, não haveria software.

Hora de “puxar a sardinha” pro meu lado, não é? (rs) Se o mundo acabasse hoje e houvessem apenas baratas e desenvolvedores: Bem, não acredito que sairia software. Desenvolvedores, em sua maioria, possuem perfil detalhista e grande dificuldade de comunicação com áreas usuárias. Numa estrutura onde já houvessem stakeholders responsáveis pelo levantamento de requisitos  e priorização dos mesmos, pode até ser que isso aconteça. Num mundo onde desenvolvedores possuam grande capacidade de visualizar soluções e não componentes, também.  Desenvolvedores tendem a fazer o que é desafiador a eles, não o que agrega valor ao cliente. Bem, num mundo onde só há baratas, desenvolvedores fariam um software qualquer.

Num mundo onde só existem baratas e analistas de negócios, também não haverá software, a menos que o analista de negócios seja aquele que desenvolve algo para testar o conceito. Aí sim, teríamos software. Mas,  como eu não concordo com essa prática, minha conclusão é:

Analistas de Negócios e Desenvolvedores são habilidades complementares e não sobrevivem sozinhas, salvo raras exceções.

Como eu saí do caos completo e fui agregando valor ao meu trabalho utilizando UML e RUP, para mim parece estranho ignorar todo o resto porque simplesmente “não funciona”. Os processos do RUP, PMBOK, funcionam tão bem quanto Scrum, Kanban e Agile se aplicados corretamente. Todos os processos permitem flexibilização e aplicação de acordo com o dia-a-dia. A flexibilização também é uma faca de dois gumes:  Abre precedente para falácias sobre os processos, e aplicação dos mesmos de forma incorreta. O que mais se ouve no mercado é “trabalhamos com as melhores práticas do mercado: RUP e PMBOK”, “Usamos metodologia ágil”, ou “Temos um Scrum adaptado”. Não preciso dizer que em nenhum dos casos as empresas sequer arranham as metodologias citadas. A metodologia usada nesses casos, geralmente, é a TVN (Te vira negão).

O que é legal no Agile

Divisão do escopo

A divisão do escopo do software em pequenas partes é uma boa idéia. A iteração já era prevista no RUP, mas utilizada de forma incorreta.  Dividindo o escopo em pequenas partes, podemos validar com antecedência se o requisito levantado está sendo atendido adequadamente, eliminar riscos, etc.  Neste caso, o cliente precisa “comprar” a idéia e topar homologar a versão quinzenalmente. Entretanto, não vejo como dividir escopo em projetos de migração de dados e projetos “Big Bang”.

Indivíduos e interação entre eles mais que processos e ferramentas

É certo que ruídos de comunicação podem ser responsáveis por arruinar todo um projeto. Aquilo que é uma seção no PMBOK, é premissa no Agile. Deveria ser premissa em todos os projetos. A alta interatividade entre o próprio time possibilita entrega de valor mais rápido.

Software rodando

Sem dúvida esta é a mais legal das vantagens do Agile. Surpreender o cliente e obter feedbacks do que está bom ou não, é o que mais motiva a comunidade ágil a continuar. Poder melhorar a cada iteração é uma grande vantagem.

Feedbacks constantes

No Agile é possível verificar erros imediatamente, obter feedbacks da liderança rapidamente e o crescimento profissional e aprendizado é exponencial. Também deveria ser uma prática a ser adotada em qualquer projeto.

Colaboração com o cliente mais que negociação de contratos

Colaboração com o cliente, e colaboração do cliente, seriam as melhores ferramentas para trabalhar num projeto de software. Quebrar barreiras e diminuir distâncias é um desafio na análise de sistemas desde que ela existe.

Conclusão

Acredito que Agile, mais do que uma metodologia, é uma cultura que poderia, em grande parte, ser implantada nas fábricas de software e em clientes. Comunicação, agilidade, vontade de trabalhar, entregar valor e colaborar com o cliente, embora óbvias, são coisas que muitas vezes são esquecidas num projeto de software, tanto na cultura ágil quanto na cultura tradicional de gestão de projetos. Gerentes falastrões, analistas pouco preocupados com o resultado ou inexperientes, desenvolvedores cansados e clientes não envolvidos não darão resultado em nenhuma metodologia.

Um comentário em “Comentando a palestra “Análise de Negócios em Projetos Ágeis”

  1. Pri, fiquei muito feliz em ver a sua análise. Fico honrado com a atenção que você prestou anotando os pontos de interesse para discussão.

    Quanto às suas dúvidas, é normal, eu passei por toda essa fase de comparação entre as formas com as quais eu trabalhava e as propostas agile. Hoje, depois de muita prática posso dizer com convicção que para desenvolvimento de software, na imensa maioria dos casos, agile funciona muito, mas muito melhor do que cascata, tanto pela filosofia quanto pelas questões práticas.

    Estou pensando em publicar a palestra no youtube para as pessoas poderem assistir.

    um abraço,
    Claudio Br

    Curtir

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair /  Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

Conectando a %s