Desenvolvimento Ágil de Software no segmento de Construção Civil da Softplan

No ano de 2016, o segmento de Construção Civil da Softplan tomou a decisão estratégica de mudar seu modelo de negócios. 

Assim, a empresa substituiu a comercialização de Licenças de Uso Perpétuo de Software (LUs) pela distribuição no modelo de Software como Serviço (Software as a Service – SaaS). 

Naquele momento, foi identificado que seria necessário criar e aprimorar competências internas  na nossa área responsável pelas soluções para a Indústria da Construção .

Em um modelo tradicional de licenças de uso, é normal que o cliente aguarde meses para receber uma nova versão de seu sistema. 

Já um sistema do tipo SaaS libera as atualizações de software constantemente. Seja para corrigir falhas e vulnerabilidades, ou para disponibilizar funções novas ligadas às inovações tecnológicas ou de negócio.

No modelo SaaS, com pagamento de assinatura recorrente, o cliente não precisa realizar grandes investimentos iniciais para adquirir as licenças de uso de software. Ao mesmo tempo em que isto facilita a entrada de um cliente, também facilita sua saída. 

Isto porque o cliente não desembolsou um grande montante financeiro que ainda precisará gerar Retorno Sobre Investimento (Return Over Investment – ROI). 

Portanto, investir nas soluções de software é uma forma de facilitar a retenção de clientes, visto que tem como foco a sua satisfação.  

Identificamos dois grandes objetivos. São eles: liberações frequentes de software e garantia de satisfação do cliente a partir da qualidade do mesmo.

Para alcançar os objetivos acima, algumas mudanças seriam necessárias. São elas:

• Melhorias de código;
• Melhorias na documentação;
• Modernização de práticas de engenharia de software;
• Melhoria nos processos que regiam o desenvolvimento do Sienge – sistema especializado de Construção Civil. 

A fim de promover essas melhorias, o segmento de Construção Civil da Softplan investiu no Desenvolvimento Ágil de Software. 

Nesse conteúdo, vamos explicar o que é o Desenvolvimento Ágil de Software, como realizamos o processo, resultados obtidos e muito mais sobre o tema. Continue a leitura!

Desenvolvimento Ágil de Software

O Desenvolvimento Ágil de Software corresponde a comportamentos, processos e práticas utilizadas na criação de software, que tem como objetivo serem mais leves ou ágeis que os processos “tradicionais”. 

A maior parte dos “frameworks” de processos para desenvolvimento ágil de software considera a entrega de pequenos incrementos do sistema em períodos curtos e delimitados de tempo. 

Este período compreende todas as etapas do ciclo de vida de um software necessárias à entrega desses incrementos: 

• Planejamento;
• Análise;
• Programação
• Testes;
• Documentação. 

O objetivo do período em si é realizar esses complementos graduais no sistema. 

O Desenvolvimento Ágil de Software é um processo empírico: entregas curtas visam viabilizar ciclos curtos de obtenção de feedback, aprendizado e adaptação (dos requisitos, do design da solução e do planejamento). Dessa maneira, a solução que está sendo desenvolvida surge durante o desenvolvimento a partir desses ciclos.

Outra característica é a ocorrência mais direta e constante de comunicação e colaboração entre o desenvolvimento e o negócio/cliente no entendimento, validação e desenvolvimento da solução.

As práticas ágeis de desenvolvimento ágil de software 

As práticas ágeis de desenvolvimento de software evoluíram a partir dos anos de 1990, identificadas inicialmente como métodos “leves”, em oposição aos métodos tradicionais e “pesados”.

Na primavera do ano 2000, líderes da comunidade de Extreme Programming (XP) se reuniram para discutir as práticas desta metodologia. 

Também discutiram a relação do XP com os demais métodos “leves”. Estes métodos incluíam o Scrum, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming e outros.

Eles foram discutidos em conjunto porque eram entendidos como uma alternativa aos métodos pesados. A partir deste momento, Robert Cecil Martin resolveu criar um encontro com pessoas interessadas em Métodos Leves.

O evento ocorreu em fevereiro de 2001, em Utah, nos Estados Unidos. Nele, 17 profissionais de programação e especialistas em tecnologia se reuniram e criaram o que hoje conhecemos como Manifesto Ágil.

Os métodos ágeis compartilham algumas características, como o desenvolvimento interativo. Eles são mais adequados quando os requisitos de um produto mudam com frequência.

Recomenda-se também para projetos com times pequenos, pois, com o aumento de tamanho, a comunicação face a face se torna mais difícil. 

Além disso, é necessário que alguns fatores chave de sucesso sejam garantidos: 

• Uma cultura organizacional que suporte os métodos; 
• A confiança das pessoas; 
• Autonomia e apoio às decisões tomadas pelos times técnicos;
• A presença de um ambiente que facilite a comunicação entre os membros.

Desenvolvimentos de Software para a Construção Civil em 2016 na Softplan

Em 2016, a solução de software produzida pelo segmento de Construção Civil da Softplan – o Sienge – liberava versões a cada 45 dias para entrega de funcionalidades novas, e versões menores para correção de bugs. 

O ciclo de vida de desenvolvimento de um software adotava uma abordagem mais tradicional, do tipo cascata. 

Os times de desenvolvimento eram grandes, tendo em média 20 integrantes. Estes times eram compostos por papéis especializados, citados a seguir.

• Gerente de Desenvolvimento: Responsável pela gestão funcional dos times e pela gestão técnica / evolutiva do produto;
• Coordenador de Desenvolvimento: Responsável por auxiliar o gerente de desenvolvimento na gestão funcional dos times;
• Analista de Requisitos: Responsável pela escrita detalhada da especificação dos requisitos das funcionalidades a serem implementadas;
• Programador: responsável pela codificação do sistema;
• Testador: responsável pela condução dos testes em suas diferentes camadas. À época, a maior parte dos testes era conduzida de forma manual. Também havia uma boa cobertura de testes automatizados na camada da interface gráfica do sistema.

A evolução do produto era guiada principalmente a partir das solicitações dos clientes e dos prospects.

O projeto Jano

A primeira tentativa de adoção de agilidade na área de soluções para a Indústria da Construção ocorreu em 2010, com o framework Scrum. 

Naquela situação, times pequenos que desenvolviam funcionalidades do sistema, como os times de Engenharia e de Suprimentos, foram unificados para estarem mais aderentes à proposta Scrum.

O papel de PO havia sido introduzido em uma adoção anterior do Scrum no ano de 2010, mas acabou sendo esquecido ao longo do tempo. Na prática, o coordenador de desenvolvimento junto ao cliente decidia as funcionalidades do produto. 

Como dito anteriormente, as equipes possuíam papéis especializados. Havia um atrito entre os papéis do analista de requisitos e do programador. 

Os programadores reclamavam de não possuírem qualquer autonomia sobre a especificação das funcionalidades, visto que recebiam o Use Case completo e pronto dos Analistas de Requisito. 

Visando minimizar este atrito, além de atingir outros objetivos, o projeto “JANO” substituiu os Use Cases por User Stories.

O projeto HAT

Em 2016, uma nova iniciativa de agilidade foi lançada, com total patrocínio da gestão da unidade. Este projeto foi denominado HAT. 

O sucesso do projeto HAT seria crucial para o êxito da mudança no modelo de negócio da unidade, passando da modalidade de venda de licenças perpétuas (LUs) para o modelo SaaS.

Assim, um comitê de agilidade foi formado. Este comitê era composto principalmente por profissionais técnicos de desenvolvimento de software, mas incluía até o diretor de operações da área, com participação ativa nas discussões. O grupo atuava no papel de coach para adoção de agilidade.

Os grandes times foram divididos, adequando-se aos padrões de tamanho sugeridos pelos frameworks ágeis. Cada time era responsável por um módulo principal do Sienge e também por alguns módulos secundários. 

Times não funcionais e funcionais

Também foram estabelecidos dois times não funcionais, que atuavam dando suporte aos demais: os times de infraestrutura e arquitetura.

Cada time funcional passou a contar com um Scrum Master, que era também um integrante do comitê de agilidade. 

Acreditava-se que o papel de Scrum Master seria temporário, pois seu objetivo era ensinar o time a ser ágil, tornando sua própria existência dispensável no futuro.

Os coordenadores de desenvolvimento passaram a desempenhar o papel de Product Owner, migrando de um cargo de gestão funcional para um cargo mais técnico. 

Os papéis especializados de Analista de Requisitos, Programador e Testador deixaram de existir. 

T-shaped professional

A partir da diretriz de tecnologia de garantir a perenidade do Sienge como sistema SaaS, o papel de Desenvolvedor de Software passou a adotar um perfil conhecido no mercado como “T-shaped professional”. 

É esperado que este profissional apresente desempenho avançado em uma área de competência e, também, desempenho básico ou médio em áreas de competência complementares. 

As áreas de competência estabelecidas para o Desenvolvedor de Software (Software Developer) do Sienge foram as seguintes:

• Análise e projeto: envolve a capacidade analítica sobre a necessidade (requisito) a ser implementada no sistema;
• Programação: envolve a codificação de software que atenderá os requisitos levantados pela Análise e projeto;
• Qualidade/Testes: incentiva a correta adoção das diferentes camadas da pirâmide de testes na entrega de cada funcionalidade;
• Times e Processos: envolve conhecimentos e habilidades para potencializar o trabalho em time (condução de cerimônias, técnicas de facilitação, técnicas estruturadas de feedback) e domínio de frameworks para auxílio na organização e produtividade (Scrum, Kanban, XP, etc);
• DevOps: inclui conhecimentos técnicos relacionados ao movimento DevOps e também a preocupação com os aspectos não funcionais do código a ser produzido: segurança, capacidade, alta disponibilidade, recuperação de desastres, etc.

Esta alteração do perfil do desenvolvedor foi explicada a todos os integrantes da área de tecnologia. 

Os perfis especializados deixariam de existir e as pessoas precisariam buscar os conhecimentos esperados para o “perfil em T”. 

O maior desafio, em geral, recaiu sobre aqueles que não programavam. Existiam então duas opções: o profissional precisaria aprender a programar, contando com o auxílio da empresa, ou optar por deixá-la. 

Ambos os casos ocorreram, mas a maioria optou por permanecer na organização, aprendendo programação.

Horizontalização na hierarquia de tecnologia da unidade

Durante o projeto HAT, o Gerente de Desenvolvimento deixou de conduzir a gestão funcional dos colaboradores. Ele ficou focado na gestão técnica e de evolução do produto. 

Ocorreu, por consequência, um achatamento, ou horizontalização, na hierarquia de tecnologia da unidade. 

Onde antes existia um diretor, um gerente, coordenadores e os times, restaram apenas os times ligados diretamente ao diretor.

O achatamento da hierarquia deu mais autonomia aos times de desenvolvimento. Entre as mudanças, todos passaram a contar muito mais com o feedback dos pares e não somente com o feedback da gestão.

Essa autonomia dos times podia ser observada em diferentes situações:

Durante um processo de contratação

Existe uma fase de entrevista do candidato pelo time o qual ele fará parte. A gestão do segmento de Construção Civil acredita que o “team building” deve iniciar pela oportunidade de o time escolher seu novo integrante. Assim, a equipe tem autonomia e poder de veto ou aprovação do candidato.

Desligamentos

Desde 2017, a empresa desligou três colaboradores. Destes três desligamentos, o próprio time decidiu por dois, por não enxergar mais cooperação dos profissionais desligados.

Escolha de processos e metodologias

 Os times têm autonomia e liberdade na escolha das metodologias de desenvolvimento que adotam. Alguns times respeitam mais fielmente o framework Scrum, alguns optam pelo Scrumban, e alguns trabalham em um modelo de esteira contínua, característico do Kanban. 

Até mesmo o período de interação não é padronizado e varia entre os times. Alguns adotam interações de uma semana, outros de duas semanas.

A partir de um processo de avaliação 180º (entre pares), os desenvolvedores promovem as ações salariais de seus colegas. Este processo, denominado Apex Dev, será tema de outro artigo. Acompanhe o blog para conferir!

Os resultados obtidos com as inovações tecnológicas na construção civil

Além da adoção de práticas de agilidade na readequação dos times, as práticas técnicas também evoluíram. A união das práticas processuais e técnicas permitiu alcançar uma grande mudança na frequência de liberações do Sienge. 

Desde o ano de 2017, o Sienge passou a liberar versões novas quase que diariamente. No ano de 2020, que possuiu 253 dias úteis, 207 versões do Sienge foram liberadas.

Aplica-se cada uma dessas versões a todo o datacenter Sienge, gerando a atualização de milhares de clientes. Elas são também disponibilizadas para que clientes on premise possam aplicá-las.

O novo modelo de negócios baseado em SaaS atingiu seus objetivos estratégicos. Além disso, a transição da Cultura Tradicional para a Cultura Ágil alcançou seu objetivo ao suportar este novo modelo de negócios.

Gostou de conhecer a Adoção de Agilidade no segmento de Construção Civil da Softplan?

Confira mais conteúdos como esse em nosso Blog!

Quer ser nosso próximo Tech Writer? Confira nossas vagas na página Carreira!

Até a próxima!