Continuando o post anterior sobre desenvolvimento, estava falando sobre como um software surge a partir de uma necessidade. É importante notar que, apesar da necessidade orientar o desenvolvimento do um sistema, ele sempre vai existir em uma plataforma, sendo exemplos de plataformas comuns: Windows (consumindo serviços WCF ou acessando direto o banco), web (hospedado localmente ou em algum provedor e acessado por um browser) ou alguma plataforma móvel (android, iOS). A definição da plataforma normalmente implica em algum tipo de restrição ou característica especial no software sendo construído.
Existem ainda as diversas questões de infra-estrutura: a aplicação vai usar banco de dados (SGBD)? Qual? Onde será hospedado? Qual versão de .NET? MS-MVC ou Monorail? E assim por diante… Para simplificar, vou assumir a plataforma web MS-MVC (devo comentar algo sobre outras plataformas no decorrer dos artigos), utilizando a versão mais atual do .NET, utilizando um banco de dados típico (que no meu caso usualmente é o Microsoft SQL Server) e que será desenvolvida utilizando o nosso framework – aplicações que não fazem uso dele ficam tão mais caras que na maior parte das vezes são inviáveis.
Voltando ao exemplo do post anterior, imaginem uma planilha para, por exemplo, controlar viagens de funcionários de uma empresa. As viagens são controladas por funcionário e cada viagem possui informações como data, custo, meio de transporte, destino, despesas diversas e reembolsos. Por alguma razão (volume, por exemplo), alguém avaliou que um sistema poderia diminuir custos de gestão desta planilha, disseminar melhor a informação e facilitar a vida do usuário permitindo, por exemplo, que ele digite as informações diretamente por uma página da intranet da empresa.
Se fosse assumir um sistema deste, a primeira coisa seria entender qual o custo atual do cliente para operar as planilhas, o quanto ele espera gastar e obter com o sistema e avaliar se o que é esperado é factível dentro do que eu acho que seria gasto, baseado na minha experiência no desenvolvimento de aplicações com nosso framework. Teria que ver também se o cliente já está familiarizado com o formato ágil de desenvolvimento e com a nossa forma de trabalho. Caso positivo, teria que identificar a seguir aspectos sobre a infra, ver se já existe um SGBD disponível, onde o servidor web está localizado, se a equipe de infra tem experiência em instalar e manter a aplicação, se os servidores estão atualizados com as últimas versões do .NET etc… Se houver algum problema com algum destes pontos, eu tento resolvê-lo antes mesmo de iniciar o desenvolvimento, pois ele pode se tornar um impeditivo para todo o projeto.
A seguir, ainda na parte de infra, eu identifico como será feita a autenticação de usuários. Normalmente, para aplicações intranet, espera-se uma autenticação integrada com o Active Directory ou algum serviço similar. Para aplicações públicas da Internet, é necessário ver também as questões de segurança, como acesso seguro, certificados para HTTPS, firewalls etc… Muitos desenvolvedores acham que estas tarefas não cabem a nós; eu não consigo concordar com isto, pois falhas nestas áreas podem tornar o melhor software do mundo completamente inútil.
Finalmente, tem-se que decidir como fica o direito de propriedade e uso do software e se o cliente deseja exclusividade sobre algumas porções do software – caso positivo, isto também torna o desenvolvimento mais caro. Como se pode ver, é um grande esforço destinado somente à análise de custo e da infraestrutura, antes mesmo que qualquer hora seja empregada no software em si. Não adianta fazer um excelente software se ele não puder se pagar, ser instalado ou ser mantido adequadamente. Mas apesar da quantidade de tópicos, um checklist com todos estes itens pode ser preenchido em uma ou duas reuniões com as pessoas certas.
Após esta fase, eu posso iniciar a construção da infra-estrutura do sistema. Utilizando o framework, eu posso montar a parte básica da aplicação, que contém uma página default, o banco de dados vazio com a tabela de usuários do sistema, a tela de login com seus respectivos controllers e toda a parte de integração com um sistema de autenticação. Normalmente eu consigo colocar isto no ar em menos de 4h após o início do projeto, pois tenho estas estruturas padronizadas no framework de desenvolvimento. Os casos que demoram mais são os que exigem uma aparência específica do site feito por um designer que me obriga a recortar htmls para a geração dos layouts. Em casos extremos, isto pode levar alguns poucos dias. Esta etapa seria o que alguns chama de Iteração 0. Eu não uso um nome específico, simplesmente utilizo uma parte do esforço da primeira iteração. Como resultado, o cliente já tem o site rodando e logando, caindo na página inicial, com toda a parte de segurança funcionando, e, quando aplicável, com funcionalidades como troca de senhas, “esqueci minha senha” e login integrado.
Paralelamente a esta fase, é feita a primeira reunião de priorização de atividades com o cliente. Nesta reunião são identificadas as funcionalidades principais do sistema e feita a priorização das mesmas. Quando eu faço isto, eu tento já identificar o que pode trazer maior ROI ou maior impacto positivo para o cliente é já sugiro uma ordem de atividades. Quando mais experiência o cliente tem em desenvolvimento no formato ágil, mais ele consegue contribuir nesta etapa. Mas, de uma forma ou de outra, eu tento sempre conduzir para que ele utilize o esforço de desenvolvimento da maneira mais benéfica possível para atingir o objetivo do sistema. No caso da planilha, o que seria mais positivo? Colocar a página pública logo para que os funcionários pudessem já ver o novo sistema e começar a testar o lançamento de dados? Ou colocar a apuração de despesas disponível? Ou facilitar, por exemplo, uma exportação de dados da planilha? Estas decisões são feitas caso a caso, mas imaginemos que no nosso o mais benéfico fosse o lançamento de dados pelo funcionário.
Bom, o post está ficando muito longo, assim vou ter que continuar num próximo, provavelmente a ser publicado só depois do Natal. Até lá e aproveito para desejar a todos um Feliz Natal e Boas Festas!
Alexandre Valente's Blog 