{"id":3402,"date":"2018-11-20T05:00:19","date_gmt":"2018-11-20T07:00:19","guid":{"rendered":"https:\/\/rafaelbuzon.com\/site\/?p=3402"},"modified":"2018-11-20T05:00:19","modified_gmt":"2018-11-20T07:00:19","slug":"comentarios-sobre-o-manifesto-agil","status":"publish","type":"post","link":"https:\/\/rafaelbuzon.com\/site\/2018\/11\/20\/comentarios-sobre-o-manifesto-agil\/","title":{"rendered":"Coment\u00e1rios sobre o Manifesto \u00c1gil"},"content":{"rendered":"

Vamos dar um tempo na s\u00e9rie #onovogestor<\/a> e falar um pouco do Manifesto \u00c1gil<\/a> numa perspectiva diferente.<\/p>\n

Se voc\u00ea j\u00e1 conhece o Manifesto \u00c1gil sabe que ele traz 4 valores que foram escritos de uma forma a valorizar mais os itens \u00e0 esquerda do que os da direita. Logo, quando se l\u00ea: “software em funcionamento mais que documenta\u00e7\u00e3o abrangente”<\/em>, ele deve-se privilegiar software funcionando, apesar de saber que documenta\u00e7\u00e3o ainda \u00e9 necess\u00e1ria em alguma medida.<\/p>\n

Muito bem, agora vamos fazer algumas an\u00e1lises menos \u00f3bvias:<\/p>\n

[heading]1) Indiv\u00edduos e intera\u00e7\u00f5es entre eles mais que processos e ferramentas[\/heading]<\/p>\n

Uma coisa pode passar desapercebida para um rec\u00e9m convertido: tudo passa por processos e ferramentas: desde sua chegada \u00e0 empresa, batendo o ponto ou n\u00e3o, at\u00e9 seu pagamento no final do m\u00eas. Alguns s\u00e3o mais claros que outros; alguns mais justos que outros; outros mais coerentes que outros, mas todos est\u00e3o l\u00e1.<\/p>\n

Imagino que este valor aparece no Manifesto fazendo frente \u00e0 burocracia e aos processos e ferramentas que “sempre estiveram l\u00e1” e que n\u00e3o eram adaptados \u00e0 realidade do contexto.<\/p>\n

Logo, minha leitura atualizada do Manifesto seria a seguinte:<\/p>\n

Deve-se promover os processos e ferramentas que promovam intera\u00e7\u00e3o entre os indiv\u00edduos.<\/p><\/blockquote>\n

Exemplos disso podem ser as ferramentas de discovery<\/em> e inception<\/em>, que, apesar de serem ferramentas, buscam atingir um resultado atrav\u00e9s da intera\u00e7\u00e3o dos e com os participantes.<\/p>\n

[heading]2) Software funcionando mais que documenta\u00e7\u00e3o abrangente[\/heading]<\/p>\n

Eu sei que a documenta\u00e7\u00e3o que o Manifesto se refere aqui \u00e9 aquela feita antes da execu\u00e7\u00e3o do trabalho e que busca especificar tudo antecipadamente para evitar erros. E eu concordo com essa orienta\u00e7\u00e3o do Manifesto. Tentar prever tudo antes de come\u00e7ar a desenvolver \u00e9 criar um lote maior do que seria necess\u00e1rio para iniciar os trabalho e o risco acompanha proporcionalmente.<\/p>\n

Mas algu\u00e9m poderia entender documenta\u00e7\u00e3o de uma forma geral, como se ao final do desenvolvimento nada, ou muito pouco, de documenta\u00e7\u00e3o fora necess\u00e1ria. Talvez influenciado pelo valor de\u00a0intera\u00e7\u00e3o entre as pessoas<\/em>\u00a0a documenta\u00e7\u00e3o poderia ser vista como algo frio e que impede a comunica\u00e7\u00e3o cara a cara ou outros tipos de comunica\u00e7\u00e3o mais eficientes.<\/p>\n

Todavia, eu acredito em:<\/p>\n

Ter documenta\u00e7\u00e3o suficiente para entregar uma solu\u00e7\u00e3o ao cliente.<\/p><\/blockquote>\n

Essas minhas releituras s\u00e3o sutis, mas ajudam a passar a mensagem que pretendo. Isso porque, pra mim, \u00e9 totalmente aceit\u00e1vel chegar ao final da execu\u00e7\u00e3o de um trabalho com uma documenta\u00e7\u00e3o abrangente. O benef\u00edcio est\u00e1 no fato dela ter sido constru\u00edda no momento certo, de forma suficiente para permitir um loop<\/em> de feedback<\/em> curto.<\/p>\n

[heading]3) Colabora\u00e7\u00e3o com o cliente mais que negocia\u00e7\u00e3o de contratos[\/heading]<\/p>\n

Na linha da releitura que estou sugerindo aqui para reflex\u00e3o, eu colocaria:<\/p>\n

Criar contratos que permitam a colabora\u00e7\u00e3o.<\/p><\/blockquote>\n

O valor original do Manifesto poderia dar margem para algu\u00e9m entender que os contratos vigentes deveriam ser ignorados, em alguns de seus termos, em prol de mudan\u00e7as oriundas da colabora\u00e7\u00e3o com o cliente.<\/p>\n

Do jeito que sugeri, deixo evidente a necessidade de constar essa possibilidade de colabora\u00e7\u00e3o no contrato, uma vez que esta caracter\u00edstica, que \u00e9 ben\u00e9fica tanto para clientes quanto para fornecedores, deveria ser uma restri\u00e7\u00e3o aceita por ambos antes do in\u00edcio do projeto.<\/p>\n

[heading]4) Responder \u00e0 mudan\u00e7as mais que seguir um plano[\/heading]<\/p>\n

De forma parecida com o que disse no primeiro valor do Manifesto, seguir um plano n\u00e3o \u00e9 algo que dever\u00edamos fazer menos, uma vez que tudo deveria estar dentro de um plano. O problema, portanto, sempre foi n\u00e3o flexibilizar o plano.<\/p>\n

Voc\u00ea pode olhar isso no Scrum quando ele revisa o plano a cada sprint. O plano, de fato, \u00e9 ruim quando n\u00e3o h\u00e1 possibilidade de alter\u00e1-lo quando necess\u00e1rio. Isso requer uma gest\u00e3o atenta \u00e0 estas oportunidades, pois elas aparecer\u00e3o.<\/p>\n

Logo:<\/p>\n

Deve-se ter um plano que possibilite responder \u00e0 mudan\u00e7as facilmente.<\/p><\/blockquote>\n

Creio que algumas restri\u00e7\u00f5es devam ajudar a equilibrar essa “flexibilidade” no plano, como quest\u00f5es or\u00e7ament\u00e1rias, \u00e9ticas, de efici\u00eancia e foco.<\/p>\n

\n

Lembrando que a forma de pensar \u00c1gil n\u00e3o deve ser a \u00fanica em sua organiza\u00e7\u00e3o. Estude e considere outros paradigmas de gest\u00e3o de acordo com o seu contexto de trabalho. Veja #onovogestor<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":"

Vamos dar um tempo na s\u00e9rie #onovogestor e falar um pouco do Manifesto \u00c1gil numa perspectiva diferente. Se voc\u00ea j\u00e1 conhece o Manifesto \u00c1gil sabe que ele traz 4 valores que foram escritos de uma forma a valorizar mais os itens \u00e0 esquerda do que<\/p>\n","protected":false},"author":1,"featured_media":3403,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2,29],"tags":[58],"class_list":["post-3402","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-agile","category-opiniao","tag-opiniao"],"_links":{"self":[{"href":"https:\/\/rafaelbuzon.com\/site\/wp-json\/wp\/v2\/posts\/3402","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/rafaelbuzon.com\/site\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/rafaelbuzon.com\/site\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/rafaelbuzon.com\/site\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/rafaelbuzon.com\/site\/wp-json\/wp\/v2\/comments?post=3402"}],"version-history":[{"count":0,"href":"https:\/\/rafaelbuzon.com\/site\/wp-json\/wp\/v2\/posts\/3402\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/rafaelbuzon.com\/site\/wp-json\/"}],"wp:attachment":[{"href":"https:\/\/rafaelbuzon.com\/site\/wp-json\/wp\/v2\/media?parent=3402"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/rafaelbuzon.com\/site\/wp-json\/wp\/v2\/categories?post=3402"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/rafaelbuzon.com\/site\/wp-json\/wp\/v2\/tags?post=3402"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}