Busca avançada

Apenas fazer o software é suficiente?

quinta-feira, 12 de abril de 2018 por Eduardo Spaki
Apenas fazer o software é suficiente?

Um software geralmente é concebido seguindo uma das duas fórmulas: Uma pessoa senta na frente de um computador e começa a programar ou uma equipe em uma empresa começa a codificar um software - Será que “só isso” é suficiente?

Há aquela famosa “história” do jovem que senta na frente de seu computador e cria um aplicativo revolucionário e fica bilionário. Isso de fato pode acontecer… como também não pode! Como não vemos bilionários surgindo todos os dias, podemos concluir que essa “história” não é a regra, mas sim a exceção.

O que significa que muitos softwares tem que ser exaustivamente trabalhados para alcançar sucesso! E para trabalhar esses softwares de maneira profissional, colocar uma equipe codificando “apenas”, não é bom o suficiente. Pois esse software deve ser testado, publicado e orientado conforme as necessidades do negócio/cliente/stakeholder.

Então, fazer um software não se resume a simplesmente escrever código para ele. Se resume em saber o que escrever e adaptar rapidamente conforme o mundo muda e, por consequência, as demandas. Significa alterar algo em como era antes, para se questionar o porquê da mudança e se isso é certo. Significa fazer algo de qualidade, por tanto testá-lo. Significa distribuir ele, e em caso de serviços, escalá-los. 

Assim como a gerência de projetos (construção civil, naval e/ou aeronáutica) se apoia em matérias como o PMBoK, ou até mesmo profissionais de infraestrutura de TI usam ITIL, COBIT e afins, a área de software também tem uma série de estratégias, frameworks e ferramental para apoiar seus projetos.

Por volta de 2010, um termo entrou na moda: o ALM - Application Lifecycle Management. Curiosamente, por volta de 2015 ele foi engolido por um “novo” termo da moda no mercado: o DevOps. Mas eles estão longe de ser a mesma coisa, ou concorrentes. O DevOps é apenas um pedaço do ALM. O pedaço que engloba a dinâmica entre desenvolvedor, infraestrutura e clientes para entregas rápidas de novas features, tanto é que quando se fala em ferramental de DevOps, orquestradores de deploy como Octopus, Jenkins e Kubernates fatalmente vem à mente. Mas sabemos que um software não é resumido à isso!

Então o ALM é sim importante para projetos maduros de software hoje em dia! Um software sem o correto ritmo de desenvolvimento (o que implica em uma gerência, seja central, ou distribuída), enfrenta problemas de perda de qualidade, timing e investimentos desnecessários (literalmente queimar/jogar dinheiro fora).

Muito do mundo hoje é baseado em tecnologia (software por consequência), como a bolsa de valores, telefonia digital, serviços como uber ou comércio eletrônico. A tecnologia vai se fazer cada vez mais presente, seja com carros autônomos, ou exercendo atividades como medicina e advocacia, como já discutido nesses dois textos aqui no blog:

•    Os robôs estão entre nós
•    Futuro sem Emprego?

Com isto, temos um paradoxo: de um lado há o uso contínuo e massivo de aplicações no dia-a-dia das empresas e usuários e do outro lado, a dificuldade em produzir as mesmas aplicações de forma sofisticada e com a qualidade desejada.

Ao traduzirmos o ALM, Gerenciamento de Ciclo de vida de Aplicação, é possível reparar que a intuito da expressão vem da ideia de englobar o software desde sua ideia, levantamento de requisitos, escrita de código, gerenciamento da equipe, estimativa, build, teste, entrega, revisão e evolução… recomeçando o processo de maneira contínua. E para dar vazão rápida e dinâmica, é possível automatizar várias etapas e tarefas do processo!

Primeiro: O ALM é estruturado em cima de três pilares que se complementam, são eles: pessoas, processos e ferramentas. 

As pessoas do projeto geralmente exercem diferentes papéis: DBA, Desenvolvedor, Analista, Arquiteto, Testador etc - Cada empresa tem sua maneira de montar equipe e trabalho… sua cultura. Mas o importante aqui é definir a interação dessas pessoas, criando um fluxo com uma entrada única de requisitos, evitando aquela história de pedir coisas conflitantes para membros diferentes e gerar aquele “diz que me disse”.

O ALM também é composto por fases, onde a construção (codificação) é apenas uma parte. Gerenciar software não é somente ter um repositório GIT de códigos!

Definir uma metodologia de trabalho, ajuda a ditar o ritmo do fluxo e das pessoas. Metodologias existem várias: CMMI, Scrum etc. 

Aqui entra uma questão interessante: e o ferramental para suportar tudo isso?

As ferramentas devem suportar desde minhas rotinas de teste, como as de deploy (lembram do DevOps!?). Devem gerir código fonte, histórico de trabalho e documentos. Devem me fornecer relatórios de andamento e previsões para tomadas de decisões estratégicas, e o mais importante: não podem ser empecilho para a equipe!

Existem várias que podem ser combinadas, como GitLab + Jenkings. Ou soluções que se integram naturalmente como JIRA e Bitbucket. Existem ainda plataformas inteiras já integradas, como o Visual Studio Team Services (o antigo TFS da Microsoft).

Sabia que há ferramentas que ajudam a testar seu software, inclusive nos testes manuais!? Sua empresa está preparada para isso? A Code 21 tem consultoria especializada em ALM e implantação dessas ferramentas, além de profissionais certificados Scrum! Também fornece treinamentos e acompanhamento de projeto. E sim, somos certificados TFS!

Entre em contato e tenha um ambiente profissional para desenvolver seu software, com ferramentas e processos certeiros!

Compartilhar

Eduardo Spaki
Autor
Eduardo Spaki

Arquiteto de Soluções da Code 21. Atua há 14 anos com desenvolvimento de tecnologias, tendo participado de projetos em diversos países. É especialista em softwares para a Internet e possui MBA em Gerência de Projetos. Já publicou livro e artigos na área de tecnologia e vem palestrando sobre carreira profissional, inovação e TI. Se deseja viabilizar seu software web ou mobile, migrar para nuvem ou implantar ferramentas de TI, entre em contato com ele pela Code 21.