Scrum - Projetos Ágeis e Pessoas Felizes

Cesar Brod

Capítulos

Prefácio da 3ª edição (rolling edition)

Embarcando na viagem ágil, por Cláudio Machado

Prefácio da 2ª edição

Dos pesquis aos bahs e tchês, passando pelas Cataratas do Iguaçu, por Carolina Borim

Prefácio da 1ª edição

Duas cesarianas no mesmo dia, por Franklin Carvalho

Parte I

Para entender o Scrum

Parte II

A prática do Scrum

Parte III

Aprimorando o Scrum

Parte IV

Outros usos do Scrum

Parte V

Dinâmicas Ágeis

Parte VI

Crônicas do Isolamento Social

Posfácio

A resposta é 42

Capítulo 1 – Contratos em tempos ágeis

Preço e escopo fixo não combinam com dinamismo. Não se aprisione a contratos que tornarão seu trabalho inútil e seu cliente infeliz.

Trabalho com várias formas de integração de sistemas e desenvolvimento de soluções desde o final dos anos 80, sempre usando tecnologias novas e emergentes. Fui apresentado ao livro O mítico homem-mês, do Fred Brooks Jr., em 1988 e ele foi fundamental na formação do meu pensamento sobre as maneiras pelas quais projetos devem ser desenvolvidos. Quase dez anos depois, comecei a estudar Extreme Programming, que usei junto com a UML (Unified Modeling Language) no de desenvolvimento do projeto Gnuteca (um sistema de gestão de acervo e circulação para bibliotecas) a partir do ano 2000. Mais adiante, o Scrum passou a fazer parte não só da vida da minha empresa como também da minha forma de pensar.

Em O projeto do projeto, outro livro de Fred Brooks Jr., o autor cita um texto de G. Pahl e W. Beitz, especialistas em projetos de engenharia:

“Qualquer tentativa de formular todos os requisitos possíveis no início de um projeto falhará e causará atrasos consideráveis.”

Mais adiante, o próprio Fred conclui:

“A pressão por um conjunto de requisitos completo e acordado provém, em última instância, do desejo – com frequência, uma demanda institucional – por um contrato de preço fixo para uma entrega específica. Ainda assim, esta demanda está baseada frontalmente na evidência concreta de que é essencialmente impossível especificar um conjunto completo e preciso de requisitos para qualquer sistema complexo, a não ser através da interação iterativa com o processo de modelagem.”

Parece-me que todos aqueles que adquirem alguma experiência com gestão de projetos acabam chegando a conclusões parecidas. Jeff Sutherland, em sua apresentação “As raízes do Scrum”, comenta que é importante levar em conta que as metas de um projeto são alcançadas a partir de um “espaço de navegação” dinâmico, em que uma série de coisas – como mudanças de tecnologia e requisitos – causarão, inevitavelmente, desvios no rumo dessa navegação, os quais devem ser constantemente considerados.

Eu defendo, sempre, o desenvolvimento de protótipos prematuros, mesmo que não totalmente funcionais, que permitam ao cliente experimentar seus próprios requisitos e a forma como eles são atendidos. Dessa forma, junto à equipe de desenvolvimento, ele é capaz de avaliar, refinar o que está sendo desenvolvido, descobrir o que realmente deseja e, em especial, quais desses desejos realmente trarão as funcionalidades e vantagens realmente importantes para o sistema, todas se alinhando cada vez mais a seu negócio, dentro do espaço de navegação que está sendo explorado.

Vou além. Piamente acredito que contratos de desenvolvimento são absolutamente inúteis e apenas amarram o cliente a definições que ele fez sem o total conhecimento do que ele realmente precisava ou desejava. Infelizmente, ainda hoje, os contratos mais penalizam o cliente do que o auxiliam. Eles dão a desculpa aos fornecedores de entregar, protegidos por um contrato, exatamente aquilo que o cliente não conseguirá utilizar na forma em que foi entregue.

Aí está um problema cuja solução não é fácil e, ainda que exista, ela não pode simplesmente ser replicada em todas as situações em que tal problema ocorre. O ideal é que exista uma relação de confiança absoluta entre cliente e fornecedor, de forma que o cliente não tenha receios em mudar seus requisitos ao descobrir novas necessidades à medida que o sistema é desenvolvido e que o fornecedor não fique em desvantagem ao ter de modificar o que está desenvolvendo – muitas vezes, sendo obrigado a jogar fora parte de seu código e considerar novas opções.

Há uma cultura empresarial muito forte baseada na compra e na venda de produtos finalizados. Tais produtos, especialmente tratando-se de software, existem cada vez em menor quantidade.

Será que uma empresa que adquiriu uma solução de gestão de relacionamento com seus clientes, há dez anos ou mais, imaginou que esses clientes passariam a utilizar as redes sociais como a sua forma preferencial de elogiar ou reclamar dos produtos da empresa? Mais do que isso, tais clientes esperam que a empresa se manifeste, hoje, também por meio dessas redes sociais. Mas é possível (ou mesmo vantajosa) a integração do sistema atual de relacionamento, de alguma forma automática ou semiautomática, com tais redes? Há uma série de outras questões e críticas relativas a graus de automação e integração entre sistemas. Eliminando humanos de certos processos, coisas importantes passarão despercebidas.

Isso dá muito pano pra manga, mas, apenas para citar uma coisa: sou totalmente contra a geração automática de posts e boletins informativos a partir de material que é colocado em sistemas de gestão de conteúdo em uma empresa. Por outro lado, acho legal avisar, de forma automatizada, aos seguidores da empresa, através das redes sociais, que há publicação de um conteúdo novo em seu portal – desde que se tenha pleno conhecimento de que estamos tratando de formas diversas de comunicação.

Mas divago. A oferta de uma solução que atenda a um cliente deve passar por uma fase de aquisição de conhecimento de seu negócio por parte do fornecedor da solução. O cliente sempre dominará seu negócio e qualquer ferramenta tecnológica que entregarmos a ele deverá auxiliá-lo a dominá-lo ainda mais. Ter a pretensão de que entenderemos totalmente o negócio do cliente é a mesma coisa que imaginar que o cliente virá a dominar a linguagem de programação, frameworks e métodos que usaremos para desenvolver uma solução. De novo, devemos navegar, em conjunto com o cliente, no espaço do projeto, da modelagem e da criação de seus sistemas.

Uma forma de se começar a migrar dos grandes contratos para uma solução de plena confiança mútua é usar o passo intermediário de minicontratos. Identifica-se, junto ao cliente, uma área específica de seu negócio para a qual possa ser desenvolvida (ou melhorada) alguma solução, com segurança e compromisso de ambas as partes e um limite de tempo (e consequente limite de funcionalidades) suficiente. O limite mágico, máximo, de tempo é de três meses. Ainda há muitas empresas que estão começando a explorar melhor sua presença nas diversas mídias sociais, seus sistemas de relacionamento com clientes através de aplicativos para dispositivos móveis e muitos outros para os quais há uma infinidade de opções plenamente customizáveis, modulares, que darão o espaço necessário para uma compreensão melhor de outras necessidades. Ao final desse período, sempre em conjunto com o cliente, exploram-se novas oportunidades. No decorrer do tempo, a navegação pelo espaço de projetos e soluções torna-se um processo contínuo e de confiança, em que o fornecedor tem a tranquilidade de sua remuneração e o cliente reconhece que essa remuneração é justa e traz benefícios ao seu negócio. Essa confiança suplantará, então, a necessidade de contratos inúteis.

Capítulos

Prefácio da 3ª edição (rolling edition)

Embarcando na viagem ágil, por Cláudio Machado

Prefácio da 2ª edição

Dos pesquis aos bahs e tchês, passando pelas Cataratas do Iguaçu, por Carolina Borim

Prefácio da 1ª edição

Duas cesarianas no mesmo dia, por Franklin Carvalho

Parte I

Para entender o Scrum

Parte II

A prática do Scrum

Parte III

Aprimorando o Scrum

Parte IV

Outros usos do Scrum

Parte V

Dinâmicas Ágeis

Parte VI

Crônicas do Isolamento Social

Posfácio

A resposta é 42

Utilizamos cookies para melhorar a sua experiência em nosso site. Para mais informações, visite nossa Política de Privacidade.