Gestão de Projetos de TI: Desenvolvimento Rápido Centrado no Usuário Wannyemberg Klaybin da Silva Dantas 1, Adriano Araújo Santos 1 1 Departamento de Matemática, Estatística e Computação Universidade Estadual da Paraíba (UEPB) Campina Grande, PB Brasil {berguim, adriano.nego}@gmail.com Abstract. The process of software development have been going through a series of adjustments over the years, because it is an abstract activity, requires unique methodologies for its management. But since they accepted the premise that it would be beneficial to the effective participation of end users in the development process has made this task even more arduous. Resumo. O processo de desenvolvimento de um software vêm passando por uma serie de adaptações ao longo dos anos, por se tratar de uma atividade abstrata, necessita de metodologias peculiares para o seu gerenciamento. Mas desde que se aceitou a premissa de que seria benéfico à participação efetiva dos usuários finais no processo de desenvolvimento tornou tal tarefa ainda mais árdua. 1. Introdução No cenário atual, constata-se que os avanços das tecnologias de informação e comunicação vêm sendo promovidos de forma exponencial desde o fim do século passado, causando mudanças que chegaram a atingir os mais diversos setores da sociedade, potencializando assim um cenário de integração do mercado financeiro global. Este cenário obrigou as empresas e organizações a se reestruturarem e modernizarem, para que em um meio informatizado pudessem realizar as suas atividades de modo mais eficiente e eficaz, buscando manter-se no mercado e conquistar uma parcela cada vez maior deste. Neste processo de informatização, se encaixa o processo de se desenvolver softwares, atividade que desde o inicio sofre com uma serie de fatores, tais como: Atrasos no projeto, dificuldade no cálculo de custos do projeto, falha na concepção da aplicação entre o usuário e de projetista do software, a qualidade em si do software, etc. Inúmeras tentativas de sistematizar o processo de desenvolvimento de um software foram realizadas, resultando em uma grande diversidade de metodologias e abordagens para o desenvolvimento, cada uma com características próprias e contextos específicos que favorecem ou não na implantação de uma destas abordagens. 2. Metodologias de Desenvolvimento Em um primeiro momento, buscou-se sistematizar o processo de desenvolvimento do software e foi destacada a intersecção de etapas no desenvolvimento de qualquer software, pois segundo Sommerville [2003] embora existam vários processos para o desenvolvimento de software, existem atividades fundamentais comuns a todos, sendo elas: (i) A especificação de software, onde é realizada a definição das funcionalidades e das restrições do software; (ii) o projeto e implementação, onde de acordo com as
especificações o software é produzido e implementado em alguma linguagem de programação; (iii) a validação de software para garantir que todas as funcionalidades especificadas foram implementadas e (iv) a evolução de software para que continue sendo útil ao cliente ao passar do tempo. E a partir da análise desta sistematização, foram se adaptando as mais diversas metodologias de desenvolvimento, os chamados processos de desenvolvimento de software (Software process developement - SPD), que servem para a atribuição de tarefas específicas em momentos estratégicos dentro do desenvolvimento, bem como a atribuição de responsabilidades específicas aos atores envolvidos. Embora usadas por um longo tempo, as metodologias tradicionais de desenvolvimento de software estão entrando em desuso, pois suas atribuições vão diretamente de encontro às tendências mercadológicas atuais, onde podemos citar principalmente: (i) A orientação ao planejamento, onde o maior tempo do processo de desenvolvimento de software era concentrado; (ii) a definição de requisitos previsíveis e estáticos, que atualmente são atribuições atípicas; (iii) o enfoque as tarefas e não às pessoas, que em um cenário onde cada vez se evidencia o usuário final como centro do processo de desenvolvimento. As metodologias tradicionais são também chamadas de pesadas ou orientadas a documentação. Essas metodologias surgiram em um contexto de desenvolvimento de software muito diferente do atual, baseado apenas em um mainframe e vários terminais burros [Royce, 1970]. Na época, o custo de fazer alterações e correções eram muito altos, uma vez que o acesso aos computadores era limitado e não existiam modernas ferramentas de apoio ao desenvolvimento do software, como depuradores e analisadores de código. Por isso o software era todo planejado e documentado antes de ser implementado. 3. Metodologias de Desenvolvimento Ágeis Para se adaptar às novas atribuições impostas pelo mercado, os processos de desenvolvimento de software tiveram que evoluir ao ponto de se tornarem factíveis com as tendências do mercado, de acordo com os ambientes dinâmicos que se encontravam nas organizações. A partir daí surgiram às metodologias ágeis de desenvolvimento, termo que se tornou difundido em 2001, quando dezessete especialistas em processos de desenvolvimento de software, puderam contribuir divulgando os modelos desenvolvidos por eles, bem como adaptando metodologias já existentes, entre eles estão os métodos Extreme Programming [Beck, 1999], Scrum [Schwaber e Beedle, 2002], que se destacam atualmente, por serem os mais adotados para desenvolvimento de projetos de TI. A maioria das metodologias ágeis nada possuem de novo [Cockburn e Highsmith, 2001], o que as diferencia das metodologias tradicionais é o enfoque e os valores, pois as metodologias ágeis priorizam as pessoas e nas interações usuáriodesenvolvedor ao invés de processos e ferramentas. Para tal é utilizado software executável ao invés de documentação, na colaboração junto ao cliente ao invés de negociação de contratos, promovendo respostas rápidas a mudanças ao invés de seguir planos pré-estabelecidos.
3.1. Scrum Trata-se de uma abordagem para desenvolvimento de software, que tem despertado grande interesse entre as organizações de todo o mundo, visto que há tendência para o desenvolvimento ágil de aplicações devido ao ritmo acelerado de mudança na tecnologia da informação, pressões por constantes inovações, concorrência acirrada e grande dinamismo no ambiente de negócios [Boehm, 2006]. Segundo seu autor Schwaber [2004], o Scrum não é um processo previsível, ele não define o que fazer em todas as circunstâncias, porém ele implementa um esqueleto interativo e incremental através de papéis e responsabilidades descritas a seguir: (i) Product Owner é um especialista de negócios que representa todos os clientes, conhece a fundo todas as regras de negócios e é o responsável pelo retorno financeiro do produto. Essa função é constantemente realizada por um gerente de projetos; (ii) Scrum Master é o responsável por fazer o ambiente Scrum funcionar. É ele quem garante o cumprimento de todas as metas esperadas; (iii) Scrum Team trata-se da equipe de desenvolvimento que trabalha de forma participativa. Outra característica importante é a não existência de uma divisão funcional através de papéis tradicionais, por exemplo: o programador programa, o testador testa, o designer faz a programação gráfica, entre outros. Por se tratar de uma equipe multifuncional e (iv) Stakeholders são todos os interessados no software que está em desenvolvimento a começar pelo cliente, usuários finais, equipe de marketing e vendas, entre outros. Cuja participação produz um produto que adere mais estreitamente com as necessidades do cliente, ou seja, todos possuem um senso de propriedade. 3.2. Extreme Programming É uma metodologia ágil para pequenas e médias equipes, que desenvolvem software baseado em requisitos vagos e que se modificam rapidamente [Beck, 1999]. Dentre as principais diferenças do Extreme Programming em relação às outras metodologias estão: (i) Feedback constante; (ii) abordagem incremental e (iii) o encorajamento da comunicação entre as pessoas. A finalidade do princípio de comunicação é manter o melhor relacionamento possível entre clientes e desenvolvedores, preferindo conversas pessoais a outros meios de interação. A comunicação entre os desenvolvedores e o gerente do projeto também é estimulada. No nível de implementação, podemos citar a simplicidade na criação de código que não deve possuir funções desnecessárias, outra idéia importante é a implementação apenas requisitos atuais, evitando-se adicionar funcionalidades que podem ser importantes no futuro. A aposta da programação extrema (extreme programming - XP) é que: seria melhor fazer algo simples hoje e pegar um pouco mais amanhã para fazer modificações necessárias do que implementar algo complicado hoje que talvez não venha a ser usado, sempre considerando que requisitos são mutáveis. A prática do feedback constante implica que o programador terá informações constantes do código e do cliente. A informação do código é dada pelos testes constantes, que indicam os erros tanto individuais, quanto do software integrado.
4. Gerencia do Projeto de TI Seguindo uma Metodologia Ágil com Foco no Usuário Final. A presença de usuários no processo de desenvolvimento, como Stakeholders sempre foi adotado, mas este ator nunca foi tratado como o centro do processo de desenvolvimento do software, sendo constantemente visto como um representante da organização que solicitava o produto de software, mas ao passar dos anos, cada vez mais o desenvolvimento de projeto de software centrado no usuário (User-centered design UCD) [Maguire, 2001] se disseminou, rompendo este paradigma. A participação de usuários finais dentro de um processo de desenvolvimento de software garante a validação de todos os requisitos do sistema ainda durante o desenvolvimento. Porém esta participação pode se tornar um fator negativo dentro do processo, de acordo com problemas na comunicação entre o usuário e desenvolvedor. Um usuário final, pode não saber expressar o modo como o requisito deve ser implementado, já o desenvolvedor dificilmente irá compreender as tarefas que o usuário desempenha fielmente dentro da organização. Então é constante o re-projeto e a reimplementação de requisitos para gerar novas versões do software, que não irão ser compatíveis com a atividade real dos usuários. Além do fator qualidade que é buscado em qualquer projeto, é possível identificar outras variáveis que influenciam dentro de um processo de desenvolvimento de software, conforme ilustrado na Figura 1. Figura 1. A pirâmide de tripla restrição na gerencia de projetos As mudanças nos requisitos geram constantes mudanças no escopo do projeto, e a cada re-projeto, re-implementação e validação destes novos requisitos com o usuário, causa uma alteração no valor de mercado do produto de software. Outra opção é inserir desenvolvedores dentro da própria organização para que estes sejam agentes-observadores de todas as atividades da organização e desenvolvam os requisitos baseado naquilo que foi observado, isso causa uma menor mudança no escopo do projeto durante a sua execução, mas como conseqüência dependeria de mais tempo útil para que fossem levantados tais requisitos, promovendo assim uma elevação no custo do produto de software. Tal alteração no valor pode gerar uma insatisfação do cliente, ou até mesmo incompatibilidade com os valores reais do mercado e conseqüentemente a inviabilidade do projeto. 5. Metodologia de Desenvolvimento Orientado a Mudanças Visto os pontos mais relevantes das metodologias de desenvolvimento tradicionais e ágeis, é proposto um método de desenvolvimento híbrido, onde é realizado o planejamento orientado a mudanças. A validação da metodologia em questão foi realizada, no desenvolvimento de um software que se propunha a viabilizar a gerencia
da comunicação e do conhecimento da empresa Light Infocon, da área de TI. Onde era marcada por perdas de informação pelo extravio de documentos, e centralização do conhecimento em funcionários específicos, que ao se desvincularem da empresa poderiam levar consigo informações estratégicas. A solução encontrada foi a aplicação de conceitos de gerencia eletrônica de documentos - GED, e os trabalhos foram desenvolvidos seguindo uma serie de etapas, listadas a seguir, e validadas de acordo com o uso cotidiano da ferramenta dentro da própria organização. 5.1. Especificação e Projeto de Software Em um primeiro momento, foram levantadas as funções especificas do sistema requerido e o contexto no qual este iria ser executado, bem como definidas as ferramentas de gerência eletrônica de documentos a serem usadas, sendo elas: (i) Gerencia de Imagens de documento, (ii) gerencia de documentos e (iii) workflow. 5.2. Implementação da Camada Mais Baixa Após a especificação e projeto do sistema, promove-se a implementação da camada mais baixa da aplicação, bem como a modelagem do banco de dados. É buscado implementar esta camada inicialmente, pois mudanças nos tipos dos dados são raras, sendo realizadas com mais freqüência nas operações realizadas pelos dados em si e nos relacionamentos entre os tipos de dados. Na construção da aplicação foi modelado o banco de dados para suportar arquivos de imagens e documentos de vários formatos, assim como feito o suporte para cadastro de funcionário da empresa. Nota-se que não foi definido o numero de funcionários da organização, assim como a definição de quais documentos determinado funcionário teria acesso. 5.3. Design da Interface Em um momento posterior, foram desenvolvidos protótipos em papel, com a interface gráfica da aplicação, visando validar as funcionalidades que o sistema deveria conter. O sistema pode ser acessado na internet, na mesma pagina da organização em uma seção especifica para funcionários, conforme pode ser evidenciado na Figura 2. Figura 2. Modelo de acesso via internet As definições dessa etapa servem de base para iniciar a etapa seguinte, bem como já possui participação do usuário final na sua execução.
5.4. Implementação da Camada Crítica A última etapa, a camada de controle, a qual se comunica com as duas outras camadas anteriores, sendo a maior portadora de mudanças. No sistema, foi definido como seria realizada a comunicação entre os integrantes da organização, bem como o caminho que um processo deveria seguir ilustrado na Figura 3, ou como é mais conhecido workflow. Todas estas restrições podendo ser alteradas pelo administrador do sistema. 6. Considerações Finais Figura 3. Formulário de cadastro de suporte Apesar de tantas evoluções no processo de desenvolvimento de softwares, ainda não existe uma metodologia totalmente eficaz para realização de tal tarefa, havendo uma serie de atributos positivos e negativos para cada caso, este cenário faz com que a escolha de uma metodologia para o desenvolvimento dependa exclusivamente do tipo do projeto que é proposto. Então tem-se que isolando as vantagens, das metodologias haveria uma potencialidade no desenvolvimento da aplicação. 7. Referencias Beck, K., Programação Extrema Explicada, Bookman, (1999) Royce, W.W. Managing the development of large software systems: concepts and techniques. Proc. IEEE Westcon, Los Angeles, CA. Sommerville, I. Engenharia desoftware. Editora Addison-Wesley. 592p, 2003. Cockburn, A. e Highsmith, J. Agile Software Development: The Business of Innovation, IEEE Computer, Sept., pp. 120-122,2001. Schwaber, K. and Beedle, M., Agile Software Development with Scrum, NJ, Prentice- Hall, 2002. Boehm, B., A View of 20th and 21st Century Software Engineering, ICSE 2006. Schwaber K., Agile Project Management With Scrum,Microsoft Press, 2004. Maguire M. (2001) Methods to support human-centered design, International journal of human-computer studies, vol. 55, pp. 587 634, 2001.