Novatec Editora Ltda. [2013]. Todos os direitos reservados e protegidos pela Lei de 19/02/1998. É proibida a reprodução desta obra, mesmo

Transcrição

1 Cesar Brod Novatec

2 Novatec Editora Ltda. [2013]. Todos os direitos reservados e protegidos pela Lei 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 Revisão gramatical: Marta Almeida de Sá Capa: Carolina Kuwabata Editoração eletrônica: Carolina Kuwabata ISBN: Histórico de impressões: Agosto/2013 Primeira edição Novatec Editora Ltda. Rua Luís Antônio dos Santos São Paulo, SP Brasil Tel.: Fax: novatec@novatec.com.br Site: Twitter: twitter.com/novateceditora Facebook: facebook.com/novatec LinkedIn: linkedin.com/in/novatec OG

3 parte I Para entender o Scrum Praticar o Scrum é como tocar violão: com poucos acordes e um mínimo de talento é possível obter um bom resultado e impressionar muita gente. Mas daí a ser o solista em uma orquestra há um bom caminho de estudos a ser trilhado. O Scrum, por sua simplicidade e suas práticas rápidas e eficazes, é o caminho para o paraíso e uma tentação para o inferno, algo que os críticos e detratores não cansam de enfatizar. Ao contrário do que muitos são levados a pensar, o Scrum exige projetos bem documentados e possui um conjunto de formalidades em sua prática (mesmo que essas formalidades fujam da burocracia como o diabo foge da cruz). Nos capítulos desta parte I serão abordados os cenários que favorecem o uso do Scrum, sua origem e definição, seus ritos e artefatos. 23

4

5 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. 25

6 26 Scrum 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 a forma por meio da qual os projetos devem ser desenvolvidos. Quase dez anos depois, comecei a estudar Extreme Programming, que usei junto com a UML (Unified Modeling Language) na gestão de desenvolvimento do projeto Gnuteca 1 (um sistema de gestão de acervo e circulação para bibliotecas) a partir de 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 1

7 Capítulo 1 Contratos em tempos ágeis 27 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 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 na medida em 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á três anos, imaginou que esses clientes passariam a utilizar o Twitter 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 do Twitter. Mas é possível (ou mesmo vantajosa) a integração do sistema atual de relacionamento, de alguma forma automática ou semiautomática, com o Twitter? 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

8 28 Scrum Twitter de que há publicação de um conteúdo novo em seu portal desde que se tenha o 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. 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 é, talvez, 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, a meu ver, é de três meses. Ainda há muitas empresas que estão começando a explorar melhor seus portais de conteúdo, sistemas de relacionamento com clientes e muitos outros para os quais há uma infinidade de sistemas 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.