Neste post escrevo sobre a palestra do Alexandre Magno, intitulada "Mr. Roi e a verdadeira história de um projeto Scrum"
O Alexandre Magno, diretor da Adaptworks, empresa patrocinadora Ouro do evento, além da palestra também ministrou o Treinamento Oficial CSPO (Certified Scrum Product Owner) nos dias iniciais do Seminário, sendo aqui o perfil dele e aqui como foi anunciada a sua palestra no evento.
A sua palestra baseia-se no uso de 2 personagens, o Mr. Roi (de Return of Investiment=Retorno sobre Investimento, representando um devoto dos métodos ágeis) e o Mr. Walter Fall (de waterfall=cascata, representando um "engessado" por métodos tradicionais de desenvolvimento).
Ao começo tentou tirar que a palestra seria focada só em TI (Tecnologia da Informação), mas não teve como, é um nerd, e notei que alguns que olhavam a sua palestra deram uma boiada em alguns termos, mas nada que prejudicasse o entendimento geral, acredito eu, e depois de algum embasamento teórico sobre os métodos, onde como costume, ao ouvirem que em Agile não se trabalha com escopo fechado, teve aquele "murmurinho", e então apresentou esta figura na qual está o "kernel" (núcleo, centro) da explanação.
A fonte original desta figura talvez não seja esta, mas eu copiei daqui http://www.lostgarden.com/2006/04/managing-game-design-risk-part-i.html.
A figura, dedutivelmente, tem em X a tecnologia a ser usada e Y os requisitos do sistema, e baseia-se em que quanto menos se souber dos requisitos, e menos se ter conhecimento da tecnologia a ser usada, maior terá que ser o seu acordo com o seu Santo preferido. E pensando-se em TI, o Mr. Walter Fall fará todo o Gerenciamento do Projeto pensando estar na área verde da figura, sendo que atualmente desconheço algum projeto que não tenha estado sua vida em maior parte na área laranja, a denominada Complexa da figura, portanto, o Mr. Roi se dando melhor no Gerenciamento por este estar atrelado ao Scrum, que obviamente foi o método no qual o Alexandre baseou a sua apresentação.
Gostei da questão que comentou que os métodos ágeis serem excelentes para processos empiricos, ou seja, ideial para TI, mas que para certos projetos o modelo do Mr. Walter Fall é mais eficiente, como na área de engenharia civil.
E até foi este o assunto de um dos melhores bate-papos que tive durante o seminário com alguns conhecidos, onde apesar de eu ser signatário dos métodos ágeis, fui o defensor do modelo tradicional, o waterfall, para estes tipos de projetos de engenharia civil, e um engenheiro civil que defendeu os métodos ágeis para a construção, interessante, mas algo que não descobrimos como fazer na prática, ainda.
Retornando aos pontos que achei interessante da palestra, o Alexandre, salientou bem a questão da medição do andamento do projeto, em métodos ágeis marcamos a evolução do projeto sobre a quantidade de entregas, mas no modelo tradicional é um porcentagem do total, mas e se nessa porcentagem não tiver sido gerado nada ainda, como um levantamento de requisitos não terminado mas que já consumiu algumas semanas/ meses? De acordo com o plano do projeto pode já se ter uns 30% concluídos, mas nestes 30% não tem nada "entregável", fora toda aquela questão de princípios, valores e práticas, sendo sobre esta parte de entrega a melhor de todas, a de se ter um feedback real, pois, sempre se deve trabalhar com a premissa que o cliente não sabe o que ele realmente quer, até mesmo entre setores de TI de acordo com muitos bate-papos informais, mas claro, há excessões.
Findando a palestra, obviamente o Mr. Roi terminou o seu projeto com sucesso e o Mr. Walter Fall ainda está enrolado com as mudanças requiridas pelo cliente, pois o modelo tradicional só trata de mudanças ao término e coisas assim.
Gostei muito, e usarei com certeza, a imagem mais semelhante de como é o trabalho de um Gerente de Projetos (ou outro dos infindáveis nomes usados).
E para encerramento ele citou uma frase do Stephen Hawking dizendo estarmos no século da complexidade, e reforçou para que todos os presentes estudem sistemas complexos, e como naturalmente um agilista faz, deixou uma "pulga atrás da orelha" em todos, não seria a hora de trabalharmos em Gestão de Produto ao invés de Gestão de Projetos?
Até o próximo post :D
