P ROJETO C ARACTERÍSTICAS

PROCERGS (ECa03)

Tamanho da equipe 6 pessoas

- 1 PO

- 1 analista de sistemas

- 1 scrummaster / desenvolvedor - 2 desenvolvedores

- 1 analista de qualidade Tempo médio de experiência com

métodos ágeis 2 anos

Tempo de duração do projeto 36 meses

Tempo de duração das iterações No início mensal e atualmente quinzenal

Clientes DETRAN/RS e o Setor de Trânsito da

PROCERGS

Característica do software - Migração do modelo cliente/servidor para o modelo web

- Inclusão de melhorias no processo de trabalho atual

Orçamento Não divulgado

Método de desenvolvimento Método de Desenvolvimento PROCERGS (MDP), baseado no Scrum

PROCERGS (ECa04)

Tamanho da equipe 6 pessoas

- 1 PO

- 1 analista de sistemas

- 1 scrummaster / desenvolvedor - 2 desenvolvedores

- 1 analista de qualidade Tempo médio de experiência com

métodos ágeis 2 anos e meio

Tempo de duração do projeto 30 meses

Tempo de duração das iterações No início mensal e atualmente quinzenal

Clientes DETRAN/RS e o Setor de Trânsito da

PROCERGS

Característica do software - Migração do modelo cliente/servidor para o modelo web

- Inclusão de melhorias no processo de trabalho atual

Orçamento Não divulgado

Método de desenvolvimento Método de Desenvolvimento PROCERGS (MDP), baseado no Scrum

Os levantamentos permitiram constatar que os orçamentos estão subdimensionados, tendo em vista que dotações para tecnologia da informação que dizem respeito a despesas com pessoal ativo que atua diretamente no projeto de desenvolvimento do produto de software não estão sendo alocadas como dotações para tecnologia da informação no orçamento geral do projeto. Isso vem acontecendo apesar da existência de modernas técnicas orçamentárias.

No âmbito da AP, não é incomum que a OP (desenvolvedor) também seja cliente para seu próprio esforço de desenvolvimento, nos quais enquadram-se os quatro casos estudados. Da mesma maneira, todos os projetos estudados são sistemas longevos, cujo o comportamento do software precisa ser mantido ao longo do tempo, os quais não são resistentes ao tempo. Assim, por conta das mudanças tecnológicas e de processos, eles precisam ser migrados para novas plataformas e evoluídos do ponto de vista de negócio. Os casos (ECa02) (ECa03) (ECa04) enquadram-se como exemplos de projetos de migração e integração de sistemas.

Outra característica comum encontrada foi o tempo de execução dos projetos que ocorre em vários anos, o que pode aumentar os custos para sua execução. Porém, com métodos ágeis, as entregas de software acontecem semanalmente ou mensamente, bem como, as implantações em produção acontecem em meses em vez de anos. Assim, os benefícios advindos de uma solução de TI podem retornar aos seus _{“investidores” o mais} cedo possível. Além disso, constatou-se que os quatro projetos tiveram tempo e condições para experimentar, avaliar e usar várias práticas e tecnologias para o desenvolvimento de software.

Na PROCERGS, constatou-se pouco espaço individual e mais espaço coletivo e tudo bem próximo para o desenvolvimento de software, o que exige um exercício diário da essência da auto-organização. Por outro lado, no CNPTIA constatou-se mais espaço individual e menos espaço coletivo e pessoas distantes, o que exige a ajuda de ferramentas, e-mails e telefones para comunicação. O desafio nestes ambientes, embora com abordagens diferentes, é aprender a trabalhar juntos, bem como, garantir que as pessoas estarão disponíveis no momento em que elas são solicitadas. Conforme constatado nos casos (ECa01) (ECa02), um grande inibidor do trabalho em equipe é a alocação de pessoas concomitantemente em vários projetos.

Por último, três projetos estudados são de migração tecnológica, incluindo a migração de dados, migração do modelo cliente/servidor para um modelo web e integração com outros sistemas existentes (ECa02) (ECa03) (ECa04). De acordo com essas equipes, esse tipo de projeto é mais desafiador para métodos ágeis - especificamente para o princípio de entrega de valor mais cedo para o cliente - porque o novo produto de software precisa conviver em produção por algum tempo com o sistema existente, ou seja, o lançamento de software em produção com base em incrementos incluí desafios técnicos difíceis de resolver para manter ambos os sistemas em funcionamento na prática. Porém, essas três equipes recomendaram fortemente que essas questões técnicas sejam consideradas e tratadas desde o início do projeto para evitar surpresas e problemas futuros.

4.4.3 Características e Aspectos da Engenharia de Software

Conhecimento e experiência em gerenciamento de projetos foram encontrados como críticos para o desempenho e resultados dos projetos de software estudados, o que não deve ser uma descoberta nova. Em dois projetos estudados, esse aspecto da ES foi compartilhado entre algumas pessoas da equipe (Product Owner, Analista de Sistemas, Analista de Qualidade e o ScrumMaster), o que ilustra um exemplo de responsabilidade compartilhada pela equipe em vez de pessoas específicas, sendo completado com algumas capacidades organizacionais, incluindo serviços de mentoring e programas de treinamentos (ECa03) (ECa04). Por outro lado, nos outros dois projetos estudados, o papel específico do gerente de projeto ainda é obrigatório na formulação, aprovação e execução do projeto (ECa01) (ECa02), entretanto durante sua execução constatou-se um comprometimento compartilhado em relação ao cumprimento dos objetivos que a equipe aceitaria.

Com relação ao alinhamento com os objetivos de negócio, os quatro projetos estudados apresentaram uma nova solução de negócio em vez de apenas o fornecimento de um produto de software. Nestes casos, a gestão dos impactos organizacionais oriundas das mudanças de negócio foram gerenciadas desde o início do projeto. Eles constituíram comitês ou grupos - formados por clientes, representantes dos usuários e alguns projetos com pessoas de TI - para fornecer orientação e direção visando alcançar objetivos comuns e não coibir as iniciativas da equipe. Essa estratégia de governança do projeto mostrou-se adequada para aceitação efetiva do produto de software na organização. Porém, ela exige que os comitês ou grupos tenham participação ativa no processo de desenvolvimento e na resolução de problemas organizacionais, bem como, representem também os interesses dos usuários do sistema. Por outro lado, um projeto composto por um comitê formado por um número maior de pessoas encontrou dificuldades na tomada de decisão, o que ocasionou atrasos no andamento do projeto (ECa01). A partir disso, pode-se inferir que comitês ou grupos maiores são propensos a atrasos porque decisões consensuais e rápidas são mais difíceis de acontecer, principalmente quando não existe uma pessoa orientando o trabalho do comitê ou do grupo, ajudando e facilitando a tomada de decisão.

Com relação ao acompanhamento do projeto, dois projetos (ECa03) (ECa04) apresentaram evidências de como um gráfico de burndown bem feito oferece a percepção real de quanto o trabalho em andamento será concluído na data prevista ou não. A estratégia adotada em ambas as equipes consistiu em reestimar diariamente em horas o tempo restante para conclusão das tarefas, o que tornou o gráfico de burndown mais preciso. Essas equipes relataram o uso de ferramentas de gestão visual na forma de um quadro kanban para o acompanhamento do projeto também. Elas apontaram as reuniões

diárias como importantes para auxiliar o acompanhamento do projeto, bem como, as reuniões de revisão com o cliente para avaliar se o projeto está na direção certa. Por outro lado, as equipes dos projetos (ECa01) (ECa02) encontraram dificuldades para estabelecer uma rotina de reuniões diárias com os desenvolvedores por conta da participação deles em outros projetos de maneira simultânea. O acompanhamento do projeto foi realizado baseado em informações contidas em planilhas eletrônicas (ECa01) e ferramentas de apoio ao processo de desenvolvimento de software (ECa02).

Com relação ao desenvolvimento de software, os quatro projetos apresentaram evidências do uso da abordagem iterativa e incremental, estabelecendo ciclos de feedback bem definidos ajustando o software para criar uma interpretação ótima do produto. Além disso, três projetos (ECa02) (ECa03) (ECa04) preferiram incorporar aspectos de testes de software no início e durante as iterações em vez de deixá-los para o final. Dois projetos (ECa03) (ECa04) declararam estar praticando a criação de cenários de testes com base na técnica BDD com apoio do analista de qualidade, porém evidências da escrita de testes de unidade e automação de testes não foram encontradas para esses projetos, o qual foi declarado como desafio cultural na organização. Por outro lado, o projeto (ECa02) apresentou evidências na criação e execução de testes automatizados, abrangendo testes de unidade e testes funcionais; além disso, essa equipe apresentou bons conhecimentos em integração de código e lançamento de software em produção de maneira automatizada. Por último, nenhum dos projetos estudados apresentou evidências do uso de TDD.

Com relação a ambientes e ferramentas de apoio ao desenvolvimento de software, todas as equipes relataram a importância de ter ambientes específicos para o projeto, incluindo ambiente de desenvolvimento, testes, homologação, treinamento e produção. Duas equipes (ECa03) (ECa04) alegaram dificuldades em obter dados reais para desenvolvimento e testes, uma vez que muitos deles são sigilosos, não podendo ser disponibilizados para a equipe. Todas as equipes relataram o uso de ferramentas de apoio ao desenvolvimento de software, preferencialmente de código aberto para projetos escritos em Java. Uma equipe (ECa01) informou o uso frequente de ferramenta de gerenciamento de conteúdo para compartilhar informações com todos os membros do projeto, uma vez que eles estão distribuídos em várias regiões do Brasil. Essa mesma equipe apontou a importância do uso de outras formas de comunicação quando os clientes e usuários estão dispersos geograficamente, incluindo equipamentos de videoconferência, e-mail e telefone. Por último, não foram encontradas características plenas de multidisciplinaridade pessoais, pelo contrário, gerentes, arquitetos, analistas, desenvolvedores, projetistas de interfaces e testadores ainda são uma realidade em OP por opção.

4.4.4 Características dos Métodos Ágeis

Esta seção completa as consolidações anteriores com algumas informações identificadas nos estudos de caso.

4.4.4.1 Razões para Adoção de Métodos Ágeis

Como dito anteriormente, o CNPTIA foi protagonista na adoção de métodos ágeis na AP com o uso de XP em um importante projeto no início da década de 2000 (RSL11). Sua utilização foi motivada como resposta ao fracasso de um projeto anterior. O sucesso do projeto motivou seus protagonistas a disseminarem os princípios e as práticas de XP para outras pessoas, sendo algumas delas adotadas em alguns projetos subsequentes com alguns resultados positivos. Porém, a adoção de XP e de qualquer outro(a) método de desenvolvimento de software não é completo e unânime na Unidade.

Com relação a PROCERGS, a adoção de métodos ágeis começou em 2012, ou seja, bem depois de sua experimentação e avaliação pelo setor privado. Embora iniciada mais tarde, o uso de métodos ágeis para desenvolvimento de software está praticamente completo na Empresa. Sua utilização foi motivada por uma restruturação iniciada recentemente que visa tornar a Empresa mais eficiente e menos burocrática. Atualmente, a PROCERGS é uma boa referência na adoção de métodos ágeis em OP, principalmente para as companhias estaduais e empresas públicas de TI.

4.4.4.2 Benefícios na Adoção de Métodos Ágeis

Os quatro estudos são muito bons para evidenciar que o desenvolvimento ágil de software com base em entregas curtas de valor contribui para que os clientes mantenham- se entusiasmados e comprometidos com os resultados do projeto até o final, o que aumenta a confiança e a satisfação de todos com o trabalho realizado e com o sistema criado. Além disso, parece haver um fato novo, embora os projetos de software em OP ainda sejam de longa duração, a entrega em incrementos de valor para o cliente, bem como, a implantação de software em períodos de tempo menores cria maior capacidade de aceitação do sistema na Empresa, sendo mais resistentes às eventuais mudanças administrativas e políticas, típicas da AP.

4.4.4.3 Dificuldades, Problemas e Soluções na Adoção Métodos Ágeis

De acordo com as informações coletadas, pode-se dizer que as dificuldades do desenvolvimento ágil no CNPTIA estão centradas na alocação de pessoas para trabalhar em vários projetos concomitantemente, na dificuldade da alta administração em determinar

sua utilização de maneira institucional, na dificuldade de compartilhar conhecimento e informações entre as pessoas, na falta de treinamento aliado a coaching in loco e nos diferentes tipos de sistemas existentes. Apesar de existirem diversas maneiras de soluções aplicáveis visando minimizar os problemas na adoção de métodos ágeis em OP, algumas boas soluções foram encontradas na PROCERGS, onde as virtudes para sair melhor no desenvolvimento ágil começaram orientado principalmente à urgência da empresa e de algumas pessoas em usar métodos ágeis, no treinamento e coaching específico nas práticas de gestão de produtos e na formação de equipes alocadas para apenas um projeto, de preferência com pessoas que se conhecem a mais tempo.

4.4.4.4 Formação da Cultura Ágil

De acordo com as informações coletadas, ambas as empresas perceberam oportunidades externas e absorveram o uso de métodos ágeis em projetos-piloto com pessoas dispostas a experimentar o novo, sendo apoiadas pela alta administração. A partir daí suas experiências positivas foram refinadas e expandidas para outros projetos dentro da Empresa. Isso significa que a cultura ágil nasceu nessas duas empresas a partir da experimentação do objeto de estudo em subculturas8_{. Assim, de fato pode-se inferir que as}

OP aprendem e modificam-se a partir de si próprias. Por outro lado, a cultura ágil preconiza que as pessoas devem procurar, proativamente, novas maneiras de aprender e compartilhar conhecimento [Coh11]. Ou seja, outros conhecimentos precisam ser procurados deliberadamente em vez de esperar passivamente o aprendizado ocorrer para não prender-se as primeiras conquistas.

Neste sentido, a PROCERGS está procurando avançar na adoção de práticas de desenvolvimento ágil de software e estratégias de compartilhamento de conhecimento entre equipes. Por outro lado, o CNPTIA não tem conseguido estabelecer novos avanços permanecendo como está, inclusive com algumas dificuldades na formação de equipes e no compartilhamento de experiências entre as pessoas. Por esta razão, métodos ágeis não é percebido como um processo acabado que se finaliza quando uma determinada conquista é alcançada. Pelo contrário, métodos ágeis é algo que se processa de forma contínua e depende de um conjunto de fatores ligados as pessoas e ao ambiente onde ele está inserido para alcançar novos e melhores resultados continuamente. Isto sinaliza para o caráter interativo, contínuo e dinâmico dos métodos ágeis abstraído dos estudos de caso realizados.

8 _{Subcultura é o conjunto de particularidades culturais de um grupo que se distancia do modo de vida}