Scrum Guia Prático para Projetos Ágeis - 2ª edição

2ª EDIÇÃO

Cesar Brod

Novatec

Copyright © 2013, 2015 da Novatec Editora Ltda.

Todos os direitos reservados e protegidos pela Lei 9.610 de 19/02/1998. É proibida a reprodução desta obra, mesmo parcial, por qualquer processo, sem prévia autorização, por escrito, do autor e da Editora.

Editor: Rubens Prates Assistente editorial: Priscila A. Yoshimatsu Revisão gramatical: Viviane Oshima Editoração eletrônica: Carolina Kuwabata Capa: Carolina Kuwabata ISBN: 978-85-7522-441-0 IG20150625 Histórico de impressões: Julho/2015 Agosto/2013

Segunda edição Primeira edição (ISBN: 978-85-7522-376-5)

Novatec Editora Ltda.

Rua Luís Antônio dos Santos 110 02460-000 – São Paulo, SP – Brasil Tel.: +55 11 2959-6529 E-mail: novatec@novatec.com.br Site: www.novatec.com.br Twitter: twitter.com/novateceditora Facebook: facebook.com/novatec LinkedIn: linkedin.com/in/novatec

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.

29

30

Scrum 2ª edição

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 os meios pelos quais os 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 Gnuteca1 (um sistema de gestão de acervo e circulação para bibliotecas) a partir de 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 desenvolvem 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 seu atendimento. 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 1 http://www.gnuteca.org.br

Capítulo 1 ■ Contratos em tempos ágeis

31

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 desejava. Infelizmente, 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 muito forte baseada na compra e na venda de produtos finalizados. Infelizmente, 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á alguns anos, imaginou que esses clientes passariam a utilizar o Twitter ou o Facebook como a sua forma preferencial de elogiar ou reclamar dos produtos da empresa? Mais do que isso, eles esperam que a empresa se manifeste também por meio das 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 essas 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 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 aos seguidores da empresa, no Twitter, 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.

32

Scrum 2ª ediçã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. Não total, é claro. 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 de tempo é três meses. Ainda há muitas empresas que estão começando a explorar melhor sua presença web, 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 a seu negócio. Essa confiança suplantará, então, a necessidade de um contrato.