Introdução
Apesar de todos os avanços nas ferramentas de software, parece haver algumas verdades que persistem sobre o desenvolvimento de software. Ao compreendermos essas "leis” podemos remover alguns dos mistérios do processo. Neste artigo vamos discutir algumas das regras práticas que parecem aplicar-se em geral à arte da programação.
Conteúdo
Numa grande percentagem de empreendimentos humanos existem princípios fundamentais, leis em alguns casos, que podemos usar para entender todos os tipos de fenómenos, comportamentos e resultados. Nós, humanos temos vindo a desenvolver software há cerca de 50 anos. Durante este tempo algumas verdades básicas, ou mesmo leis, têm surgido; estar ciente destas verdades pode fornecer algum conhecimento e discernimento adicionais. O conhecimento dessas "leis" permite que alguns eventos e projectos deixam de ser um puzzle para compreender.
As primeiras 3 “leis” que vamos enunciar foram discutidas no prefácio do livro “Exploring Scrum: The Fundamentals”, por Jeff Sutherland (co-criador do Scrum): Lei de Ziv, Lei de Humphrey e Lei de Conway. Para além destas, vamos enunciar mais algumas “leis”, que foram aparecendo ao longo dos anos e que parecem ser razoavelmente constantes e confiáveis.
Lei de Ziv
O desenvolvimento de software é imprevisível e as especificações nunca serão totalmente entendidas. Se concordarmos que a natureza fundamental do desenvolvimento de software é essencialmente o desenho de novos produtos, esta lei parece válida. Quando estamos a criar algo novo, independentemente da semelhança que possa ter com o que já foi criado antes, é impossível ter a certeza de todas as necessidades e restrições. Podemos prever com diferentes graus de precisão e devemos ressalvar todas as previsões com um certo grau de certeza, mas não conseguimos realmente prever com exactamente todos os requisitos funcionais e não-funcionais. O tema da incerteza também é abordada na lei de Humphrey.
Lei de Humphrey
O utilizador nunca vai saber o que quer até ver o software a funcionar (talvez nem mesmo assim).
Muitas vezes ouvimos o utilizador final a dizer “Eu saberei o que é, quando o vir” (“I’ll Know It When I See It – IKIWISI”). À medida que os utilizadores interagem com um novo software vão-se tornando mais conscientes sobre o potencial do sistema e as suas funcionalidades. O processo de revisão e sugestão iterativo leva a novas descobertas imprevisíveis. Essas novas descobertas são, para muitos, a razão para que a utilização de abordagens tradicionais de gestão de projetos no desenvolvimento de software não seja uma boa opção, não é tão eficaz como outras abordagens. As abordagens tradicionais assumem, incorretamente, que os utilizadores sabem o que querem antes do software ser desenvolvido.
Lei de Conway
Um sistema de software irá refletir a estrutura organizacional da equipa de desenvolvimento desse software, ou dito de outra forma, as organizações que projectam sistemas são compelidas a produzir projectos que são cópias das estruturas de comunicação da própria organização. Se a equipa de desenvolvimento não comunica bem, então os componentes de software do sistema, provavelmente, também não vão comunicar bem. Isto é compreensível quando se considera que o desenvolvimento de software é um processo humano muito intensivo, com uma infinidade de decisões e interações necessárias. A lei de Conway já existe há muitos anos, remontando à década de 1960.
Lei de Noel
As pessoas vão-se lembrar de prazos falhados, mas não de funcionalidades em falta. Se cumprir o prazo de entrega, mesmo que uma versão não inclua todas as funcionalidades prometidas, há menos probabilidade de ter problemas do que se tivesse entregue todas as funcionalidades, mas numa data posterior ao prazo de entrega.
Al Noel afirma esta "lei" é uma das razões que as abordagens Agile são, por vezes, eficazes. Todas as abordagens ágeis exigem entregas regulares com uma periodicidade não superior a uma semana. Se entregarmos regularmente código para produção nas datas prometidas, os clientes e utilizadores finais tendem a ser permissivos, mesmo que algumas funcionalidades e correções planeadas não sejam entregues na mesma data. Isto é especialmente verdade se os utilizadores estiverem acostumados a receber a maioria das entregas fora de prazo e se tiverem experimentado adiamentos frequentes na programação. Para alguns utilizadores finais, receber alguma coisa, numa base regular, e não necessariamente tudo, pode deixá-los satisfeitos.
Lei de Gilb
Se não atacar os riscos, os riscos vão atacá-lo a si. Novamente, se considerarmos que o desenvolvimento de software é essencialmente a criação de um novo produto, é inevitável haver uma certa quantidade de risco em cada projecto. Além disso, ignorar os riscos não os faz desaparecer, simplesmente eles não vão ser levados em consideração e não vão ser geridos. Se estes riscos não são controlados, podem evoluir para problemas reais que são susceptíveis de o "atacar". Quando algo tem riscos, estes riscos não devem pôr em causa a continuidade do projeto, nem se deve prosseguir o projecto ignorando os riscos e que eles se podem tornar.
Lei de Bradley
O software evolui ou morre. Ao longo do tempo, verifica-se que esta afirmação é verdadeira em muitos casos. Basta pensarmos em todas aquelas ferramentas de software que usámos e que não foram significativamente modificadas e actualizadas, para perceber que já não estão disponíveis. Outras, por sua vez, foram revistas e actualizadas e ainda estão presentes no mercado. Da mesma forma, sistemas de gestão de negócio caíram em desuso porque não foram melhorados ou estendidos. Esta “lei” é mais uma ferramenta para entender o software e o desenvolvimento de software.
Lei de Carriço
O bom software é aquele que funciona. Apesar da lei de Noel, que diz que os utilizadores são mais permissivos com funcionalidades em falta do que com prazos falhados, as funcionalidades disponibilizadas não devem ter bugs. Quando fazemos uma entrega, para além do esforço no cumprimento dos prazos, devemos ter especial atenção aos testes, de forma a garantir que o sistema funcione.
Esta “lei” parece bastante óbvia, mas somente quando a ouvi, numa disciplina do curso de Engª Multimédia, no ISTEC, da boca do Prof. Rui Carriço (um grande bem haja) é que sistematizei o conceito, apesar de, na altura, já contar com mais de 10 anos de experiência de análise e desenvolvimento de software.
Sem qualquer pretensão especial, estas são algumas regras práticas, que podemos apelidar de “leis”, que nos ajudam a entender melhor o trabalho de desenvolvimento de software. Espero que lhes consigam retirar alguma utilidade e aplicação prática.
Baseado no artigo “Some «Laws» of Software Development”, de Al Noel.
Sem comentários:
Enviar um comentário