UNIVERSIDADE DO SUL DE SANTA CATARINA GUILHERME ANTUNES PASSOS WELLINGTON ANTUNES DANIEL

Transcrição

1 UNIVERSIDADE DO SUL DE SANTA CATARINA GUILHERME ANTUNES PASSOS WELLINGTON ANTUNES DANIEL RECOMENDAÇÕES PARA ATINGIR O NIVEL G DO MPS.BR COM BASE EM METODOLOGIAS ÁGEIS: UM ESTUDO DE CASO Palhoça 2013

2 GUILHERME ANTUNES PASSOS WELLINGTON ANTUNES DANIEL RECOMENDAÇÕES PARA ATINGIR O NIVEL G DO MPS.BR COM BASE EM METODOLOGIAS ÁGEIS: UM ESTUDO DE CASO Trabalho de Conclusão de Curso apresentado ao Curso de Graduação em Sistemas de Informação da Universidade do Sul de Santa Catarina, como requisito parcial à obtenção do título de Bacharel em Sistemas de Informação. Maria Inés Castiñeira, Dra Palhoça 2013

3 Dedicamos esse trabalho de conclusão de curso a todos que fizeram parte do processo de sua elaboração, em especial à empresa SoftPC, por ter dado a oportunidade de realizarmos nosso estudo.

4 AGRADECIMENTOS Após meses de muito empenho e dedicação, consegui concluir mais essa etapa em minha vida. Agradeço a todos que direta ou indiretamente participaram desse processo de aprendizado e desafios. A Deus por todas as oportunidades que a mim foram dadas. A Professora Maria Inés Castiñeira, por ter aceitado ser nossa orientadora. Pelo seu esforço junto a nós durante todo o ano. Ela sem dúvidas, esclareceu e tirou nossas dúvidas em diversos assuntos relacionados à àrea na qual decidimos realizar o trabalho de conclusão de curso. Além disso, emprestou diversos livros, os que acrescentaram muito em nosso aprendizado. Ao Clayton Antunes, também membro da banca e sócio fundador da empresa SoftPC. Sem o apoio dele, o trabalho não seria realizado e aplicado na prática como realmente ocorreu. Agradecemos portanto, a ajuda que ele deu para cumprirmos todas as etapas desse trabalho. Depois de meses de estudo junto a SoftPC, hoje temos ciência de que a empresa cresceu significativamente com as propostas elaboradas por este trabalho e nós também crescemos em termos de aprendizado e profissionalmente. A todos os colaboradores da empresa SoftPC, por ter dado o espaço para que estudássemos e apresentássemos as propostas, conforme o andamento do trabalho Aos meus pais, João Daniel e Maria Bernadete, que contribuíram para minha formação, desde o Ensino Fundamental até o Ensino Superior. Aos meus Avós, que me criaram e me educaram. Sem eles eu não teria chegado aqui hoje. A todos esses que me acompanharam e continuam comigo até hoje. Ao meu amigo Guilherme Antunes, que se mostrou esforçado e dedicado em todas as etapas de elaboração do trabalho. Sempre prestativo, conseguimos fazer todas as tarefas, sem deixar de lado a vida social e amigos. A Universidade do Sul de Santa Catarina e professores, que me deram a base para que eu ingressasse no mercado de trabalho e aprendesse o que há de mais importante para o desenvolvimento de um bom profissional na área de tecnologia da informação. Wellington Antunes Daniel

5 AGRADECIMENTOS Após todo esse período acadêmico, este trabalho vem a simbolizar o fim de um ciclo, que através de toda a dificuldade percorrida foi possível adquirir o conhecimento necessário, e ao olhar para trás, vejo que foi válido todo esse esforço. Agradecer aos meus pais, Ariosto Pereira Passos e Veronica Antunes de Oliveira, por todo o esforço cedido para que tudo isso fosse possível, e pela criação e educação em que me foi dada. A minha namorada Luana Rodrigues Samboranha por toda compreensão e dedicação que foram indispensáveis nesse período acadêmico. Ao companheiro de TCC e amigo Wellington Antunes Daniel, que no processo de desenvolvimento do trabalho, sempre se demonstrou competente e capaz, e através de uma ótima comunicação conseguimos dividir o trabalho para que não se tornasse massante e complicado. A minha família e amigos que direta ou indiretamente contribuem para minha formação, são apoios indispensáveis para enfrentar os obstáculos da vida. A todos os colaborados da empresa SoftPC, principalmente ao Clayton Antunes, que sempre que necessário esteve disponível para auxiliar com o andamento do trabalho. A todos os professores da UNISUL, que puderam repassar o conhecimento necessário para que seja possível ser reconhecido profissionalmente na área de Tecnologia da Informação. E a professora Maria Inés, que aceitou nosso convite para ser orientadora do trabalho, e com todo seu conhecimento na área pode nos direcionar no melhor caminho para realização do projeto, fornecendo todo apoio e material necessário. Guilherme Antunes Passos

6 RESUMO Este trabalho teve como objetivo estudar melhorias nos processos de desenvolvimento de software em uma empresa estudo de caso seguindo diretrizes do modelo MPS.BR e considerando algumas prtáticas dos modelos ágeis. Para isso, foi feito um estudo inicial nos processos existentes na empresa, gerando uma representação gráfica e textual desses processos. Posteriormente foi realizado um levantamento baseado nos conceitos de gerência de projetos e gerência de requisitos, conforme o nível G do MPS.BR. É através deles, que a empresa conseguirá atingir o objetivo proposto. Em paralelo, foi realizado um estudo nos modelos ágeis de desenvolvimento Scrum e Kanban, para apresentá-los à empresa e assim esta poder identificar quais das práticas desses modelos poderiam ser adotadas para auxiliar a empresa a otimizar seus processos e reduzir falhas. Essas metodologias servirão como apoio para que o níve G seja alcançado. A partir da análise dos processos e dos resultados esperados para o nível G do MPS.BR foi gerada uma lista de recomendações para atingir esse nível. Algumas dessas recomendações já foram incorporadasnos processos da empresa a partir das práticas do Scrum e Kanban. Outras das recomendações ainda serão contempladas. Dessa forma será possível identificar as falhas no processo, e consequentemente corrigi-las, a fim de que a empresa consiga a qualidade necessária para que esteja forte no mercado de tecnologia de informação. Palavras-chave: nível G do MPS.BR. Kanban. Gerência de Projetos. Gerência de Requisitos. Qualidade de Processos

7 LISTA DE SIGLAS AP - Atributos do Processo CA - Consultores de Aquisição CASE - Computer-Aided Software Engineering CMMI - Capability Maturity Model Integration DSDM - Dynamic Systems Development Methodology ETM - Equipe Técnica do Modelo FCC - Fórum de Credenciamento e Controle FDD Feature Driven Development GPR - Gerência de Projetos GRE - Gerência de Requisitos IA - Instituições Avaliadoras IEEE - Institute of Electrical and Electronics Engineers ISO - International Organization for Standardization MA-MPS Modelo de Avaliação para Melhoria de Processo de Software MN-MPS - Modelo de negócio para Melhoria de Processo de Software MPS - Melhoria para Processo de Software MPSBR Melhoria para Processo de Software brasileiro MR-MPS - Modelo de Referência para Melhoria de Processo de Software MR-MPS-SW - Modelo de Referência MPS para Software PMBOK Project Management Body of Knowledge RAP - Resultados esperados dos Atributos do Processo SoftPC Software para Processos Corporativos WIP - Work in Progress

8 LISTA DE FIGURAS Figura 1 O ciclo de vida do software Figura 2 Modelo em cascata Figura 3 Desenvolvimento Incremental Figura 4 Equipes do Scrum Figura 5 Lista de entregáveis Figura 6 Product backlog e Sprint backlog Figura 7 Quadro Kanban Figura 8 Quadro Kanban Figura 9 Quadro Kanban Figura 10 Etapas do Desenvolvimento Figura 11 Desenho da Solução Figura 12 Papéis do analista Figura 13 Processo do Analista Figura 14 Papéis do Programador Figura 15 Processo do Programador Figura 16 Papéis do Cliente Figura 17 Processo do Cliente Figura 18 Processos da empresa Figura 19 Representação do Nível G Figura 20 Representação do Quadro Kanban Figura 21 Representação do Quadro Kanban Figura 22 Kanbanize on line Figura 23 Kanbanize on line Figura 24 Processos da empresa com a utilização do Kanban

9 LISTA DE QUADROS Quadro 1 Esquema simplificado do ciclo de vida do software Quadro 2 Níveis de maturidade do MR-MPS-SW Quadro 3 Gerência de Projetos existentes na empresa Quadro 4 Gerência de Requisitos existentes na empresa Quadro 5 Diferenças entre Scrum e Kanban

10 SUMÁRIO 1. INTRODUÇÃO PROBLEMÁTICA OBJETIVOS OBJETIVO GERAL OBJETIVOS ESPECÍFICOS JUSTIFICATIVA ESTRUTURA DA MONOGRAFIA REVISÃO DA LITERATURA ENGENHARIA DE SOFTWARE PROCESSO DE SOFTWARE MODELOS DE PROCESSOS DE SOFTWARE Ciclos de vida do Software Modelo Cascata Modelo Incremental Modelo Espiral Modelos Ágeis Scrum Kanban PRODUTOS E PROCESSO QUALIDADE DE SOFTWARE Garantia da Qualidade MPS.BR NIVEIS DE MATURIDADE DO MPS.BR Capacidade do Processo GERÊNCIA DE PROJETOS GERÊNCIA DE REQUISITOS CONSIDERAÇÕES FINAIS MÉTODO CARACTERIZAÇÃO DO TIPO DE PESQUISA ETAPAS DESENHO DA SOLUÇÃO DE DESENVOLVIMENTO DE SOFTWARE DELIMITAÇÕES DESENVOLVIMENTO DESCRIÇÃO DA EMPRESA DESCRIÇÃO DOS PROCESSOS DE DESENVOLVIMENTO DA EMPRESA ANÁLISE DO PROCESSO CONSIDERANDO O MPS.BR GERÊNCIA DE PROJETOS EXISTENTES NA EMPRESA GERÊNCIA DE REQUISITOS EXISTENTES NA EMPRESA CONSIDERAÇÕES FINAIS PROPOSTA DA SOLUÇÃO RECOMENDAÇÕES PARA A APLICAÇÃO DOS PROCESSOS DE GERÊNCIA DE PROJETOS RECOMENDAÇÕES PARA A APLICAÇÃO DOS PROCESSOS DE GERÊNCIA DE REQUISITOS APRESENTAÇÃO DOS RESULTADOS PRELIMINARES PARA A EMPRESA DESCRIÇÃO DOS PROCESSOS DA EMPRESA APÓS APRESENTAÇÃO DOS RESULTADOS CONCLUSÕES E TRABALHOS FUTUROS... 99

11 6.1 CONCLUSÕES TRABALHOS FUTUROS REFERÊNCIAS APÊNDICE - QUESTIONÁRIO APÊNDICE CRONOGRAMA

12 12 1. INTRODUÇÃO Segundo Pressman (2006), à medida que a importância do software cresceu, a comunidade de software tem continuamente tentado desenvolver tecnologias que tornem mais fácil, mais rápido e menos dispendioso construir e manter programas de computador de alta qualidade. O mesmo autor afirma: O processo de software forma a base para controle gerencial de projetos de software e estabelecem o contexto no qual os métodos técnicos são aplicados, os produtos de trabalho (modelos, documentos, dados, relatórios, formulários etc.) são produzidos, os marcos são estabelecidos, a qualidade é assegurada e as modificações são adequadamente geridas. Conforme Paula (2000), mesmo depois de terminado um projeto, é importante que os resultados sejam guardados e controlados. Pode ser necessário atualizá-los em caso de manutenção. Documentos e modelos consistentes são indispensáveis para facilitar a manutenção, e evitar que esta introduza novos defeitos. Assim como o processo de software tem merecido atenção dos pesquisadores, também tem surgido diversos modelos de qualidade de software, alguns de abrangência internacional, outros idealizados no Brasil. Entre os primeiros pode se destacar o CMMI (Capability Maturity Model Integration) uma abordagem comprovada para gerenciamento de desempenho, com décadas de resultados mostrando que funciona. As organizações que usam CMMI têm custo previsível, cronograma e resultados de qualidade de negócio que servem como diferencial para os seus concorrentes (CMMI Institute, 2013). Já o MPSBR (SOFTEX, 2011) é um programa mobilizador almejado por empresas brasileiras no ramo de desenvolvimento de software, o qual serve de guia para auxiliá-las a otimizar seus processos de desenvolvimento. O MPS.BR, um facilitador, tornando tanto a parte de processos reduzida, assim, as empresas conseguem se adequar a uma estrutura madura e de qualidade. Segundo a SOFTEX (2011) - Associação para Promoção da Excelência do Software Brasileiro mantedora do MPS.BR, originado em dezembro de 2003, o modelo tem como objetivo incentivar as empresas de desenvolvimento a se estruturarem de acordo com determinado prazo.

13 13 Este trabalho abordará a aplicação de diretrizes de qualidade junto com modelos de desenvolvimento de software ágeis. Segundo (PRESSMAN, 2006), nas metodologias ágeis de desenvolvimento: A engenharia de software combina uma filosofia e um conjunto de diretrizes de desenvolvimento. A filosofia encoraja a satisfação do cliente e a entrega incremental do software logo de início; equipes de projeto pequenas, altamente motivadas; métodos informais; produtos de trabalho de engenharia de software mínimos e simplicidade global do desenvolvimento. As diretrizes de desenvolvimento enfatizam a entrega em contraposição à análise e ao projeto (apesar dessas atividades não serem desencorajadas) e a comunicação ativa e contínua entre os desenvolvedores e clientes. Neste trabalho será apresentada a utilização do MPS.BR (Melhorias de Processo de Software Brasileiro) em uma empresa estudo de caso, a SoftPC, englobando algumas especificações de metodologias ágeis de desenvolvimento de software. 1.1 PROBLEMÁTICA A Empresa estudo de caso está localizada em uma incubadora na cidade de Florianópolis e tem como foco principal o desenvolvimento de soluções na área governamental. A empresa SoftPC é iniciante no segmento de desenvolvimento de software, motivo pelo qual possui vários problemas no seu processo de desenvolvimento. Entre estes pode - se citar a área de análise, de testes, a gerência de projetos, dentre outras. Como a equipe de colaboradores da empresa é reduzida, acaba faltando uma pessoa focada somente para o setor de qualidade e documentação, deixando de documentar desde a parte de análise com o cliente até a etapa de entrega do produto. Dessa forma, a parte documental é bem reduzida, prejudicando e causando retrabalho, além de dificultar a manutenção do software. De forma geral percebe-se que a empresa não tem um processo de desenvolvimento de software bem definido. Desde seu início até os dias de hoje, a empresa tem dificuldade em estabelecer seus prazos e custos. O fato de não existir um planejamento acurado no projeto acaba interferindo no processo e na confiabilidade do cliente para com o produto. Essas deficiências podem abrir margem para a concorrência.

14 14 Assim, a problemática pode ser resumida na seguinte pergunta de pesquisa: é possível auxiliar a empresa estudo de caso, gerando recomendações de adequação do seu processo de desenvolvimento, seguindo as diretrizes do modelo MPSBR e de modelos ágeis de desenvolvimento de software? 1.2 OBJETIVOS Serão apresentados a seguir os objetivos deste trabalho OBJETIVO GERAL Este projeto tem como objetivo principal, definir recomendações para que a empresa SOFTPC alcance o nível G do modelo de referência MPSBR no setor de tecnologia da informação, utilizando algumas práticas das metodologias ágeis de desenvolvimento de software OBJETIVOS ESPECÍFICOS Como objetivos específicos, são apresentados os seguintes: estudar qualidade de software, com ênfase para o modelo MPS.BR; pesquisar os modelos ágeis de desenvolvimento de software; fazer um levantamento e diagnóstico do processo e das atividades de desenvolvimento de software realizados pela empresa estudo de caso; realizar algumas intervenções (entrevista, brainstorming, apresentação ou outro) com participantes da empresa para direcionamento e escolha do modelo ágil mais adequado;

15 15 gerar recomendações e elaborar um macroprocesso a ser aplicado pela empresa para atingir o nível G do MPS.BR. 1.3 JUSTIFICATIVA Com o desenvolvimento do projeto, a empresa em estudo tenderá a qualificar todo o seu processo de desenvolvimento de software, pois, através do MPS.BR, alcançará um certo grau de maturidade. Isso irá facilitar o entendimento de toda equipe, especificando cada etapa no processo de desenvolvimento. Conforme SOFTEX (2012): As mudanças que estão ocorrendo nos ambientes de negócios têm motivado as empresas a modificar estruturas organizacionais e processos produtivos, saindo da visão tradicional baseada em áreas funcionais em direção a redes de processos centrados no cliente. A competitividade depende, cada vez mais, do estabelecimento de conexões nestas redes, criando elos essenciais nas cadeias produtivas. Alcançar competitividade pela qualidade, para as empresas de software, implica tanto na melhoria da qualidade dos produtos de software e serviços correlatos, como dos processos de produção e distribuição de software. Além do MPS.BR, com a adoção de algumas das práticas dos modelos ágeis, se espera que as melhorias no processo de desenvolvimento também contemplem as seguintes atividades características: a análise e levantamento de requisitos no cliente serão mais completos, determinando prazos e custos mais precisos, que, consequentemente, diminuirão a margem para possíveis erros; a modelagem do sistema e desenvolvimento do código em interface web será compreendida com mais clareza, logo as manutenções corretivas vão ser identificadas mais facilmente; os testes farão com que muitos erros possam ser evitados de chegar ao cliente; a documentação do software será um depósito de informações, permitindo que novos colaboradores conheçam e aprendam normas ou regras definidas pela empresa.

16 ESTRUTURA DA MONOGRAFIA estrutura do trabalho: Este trabalho está dividido em cinco capítulos. A seguir, será apresentada Capítulo 1 Introdução: este capítulo apresenta a introdução, problema, os objetivos e a justificativa do trabalho. Capítulo 2 Revisão da literatura: este capítulo apresenta temas relacionados ao MPS.BR, Metodologias Ágeis, Engenharia de Software, Gerência de Projetos e Gerência de Requisitos. Capítulo 3 Metodologia: apresentação da metodologia de pesquisa, a proposta da solução e as delimitações do projeto. Capítulo 4 Desenvolvimento: este capítulo apresenta a descrição da empresa estudo de caso, do seu processo de desenvolvimento, análise do mesmo processo e recomendações para atingir o nível G do MPS.BR, usando práticas das metodologias ágeis propostas. Capítulo 5 Proposta da solução: apresentação das sugestões para adequação dos processos de gerência de projetos e gerência de requisitos, a fim de que a empresa alcance o nível G do MPS.BR. Capítulo 6 Conclusões e trabalhos futuros: este capítulo apresenta as conclusões deste trabalho e sugestões para trabalhos futuros.

17 17 2. REVISÃO DA LITERATURA Este capítulo apresenta uma revisão sobre Processos de Software, Modelos de Processo de Software, produtos e processo, qualidade de software, MPSBR e seus níveis de maturidade, além da capacidade de processos, que inclui gerência de projetos e gerência de requisitos. 2.1 ENGENHARIA DE SOFTWARE Segundo Pressman (2006), diversos autores conceituaram engenharia de software, no entanto uma definição criada por Fritz Bauer na conferência que iniciou a discussão sobre o assunto, ainda serve como base. A definição de engenharia de software tem como foco a utilização de alguns conceitos da engenharia, com o objetivo de obter softwares eficientes e econômicos, sendo confiáveis e dessa maneira estabelecendo qualidade nos produtos envolvidos. O mesmo autor afirma que o modelo criado por Fritz tem suas limitações. Descreve pouco sobre os conceitos de qualidade de software, não comenta sobre a pontualidade, não relata de forma eficiente a importância de um processo de amadurecimento e a necessidade de satisfação do cliente, não contextualiza sobre a importância das medidas e unidades. Mesmo assim, o conceito dá uma diretriz aos engenheiros de software, podendo ter um direcionamento, mesmo que básico. Como já destacado (2006, p. 18): Os métodos de engenharia de software fornecem a técnica de como fazer para construir softwares. Eles abrangem um amplo conjunto de tarefas que incluem comunicação, análise de requisitos, modelagem de projeto, construção de programas, testes e manutenção. Os métodos de engenharia de software repousam num conjunto de princípios básicos que regem cada área da tecnologia e incluem atividades de modelagem e outras técnicas descritivas. O alicerce da engenharia de software é a camada de processo, as camadas de tecnologia permitem o desenvolvimento racional e oportuno de softwares de computador. Os processos de softwares formam a base que controlam e gerenciam os projetos de software e

18 18 estabelece um contexto no qual os métodos técnicos são aplicados, os produtos de trabalho (documentos, modelos, dados, relatórios, documentos, entre outros) são produzidos, estabelecendo os pontos principais, a qualidade é assegurada e as modificações são adequadamente administradas (PRESSMAN, 2006). Segundo Sommerville (2003), a engenharia de software é uma disciplina da engenharia que se ocupa de todos os aspectos da produção de software, desde os estágios iniciais de especificações do sistema até a manutenção desse sistema, depois que ele entrou em operação. Para Pressman (2006), engenharia de software é uma disciplina que integra processo, métodos e ferramentas para o desenvolvimento de software de computador. Foram propostos vários e diferentes modelos de processo para a engenharia de software, mas todos definem um conjunto de atividades de arcabouço, uma coleção de tarefas que são conduzidas para realizar cada atividade, produtos de trabalho produzidos como consequência das tarefas, é um conjunto de atividades que se espalham por todo o processo. Padrões de processo podem ser usados para definir as características de um processo. 2.2 PROCESSO DE SOFTWARE De acordo com Sommerville (2003), o processo de software é um conjunto de atividades e resultados associados com a produção de um produto de software. Esse processo pode envolver desenvolvimento de software desde o início, embora, cada vez mais ocorra o caso de um software novo ser desenvolvido mediante expansão e a modificação de sistemas já existentes. Para Paula (2000), os processos podem ser definidos para atividades como desenvolvimento, manutenção, aquisição e contratação de software. Um processo de desenvolvimento abrange subprocessos como requisitos, análise, desenho, implementação e testes. Em um processo de desenvolvimento de software, o ponto de partida para a arquitetura de um processo é a escolha de um modelo de ciclo de vida. Segundo Pressman (2006), o melhor processo de software é aquele que se aproxima do pessoal que fará o serviço. Se um modelo de processo de software tiver sido desenvolvido no nível da empresa ou da organização, ele pode ser efetivo apenas se for

19 19 suscetível a adaptações significativas de modo a satisfazer as necessidades da equipe de projeto que está realmente fazendo o trabalho de engenharia de software. Numa instalação local, cada engenheiro do software criaria um processo que melhor satisfizesse as suas necessidades, ao mesmo tempo, as necessidades mais globais da equipe e da organização. De acordo com Borges (2010), a ISO é uma norma definida pela International Organization for Standardization, que se aplica em engenharia de software. Esta estabelece um processo de ciclo de vida do software, contendo processos, atividades que são aplicadas durante a aquisição e configuração dos serviços do sistema, de forma a melhorálos. Esta norma tem como principal objetivo fornecer uma estrutura comum para que o adquirente, fornecedor, desenvolvedor, mantenedor, operador, gerentes e técnicos, envolvidos com o desenvolvimento de software, utilizem uma linguagem comum que é estabelecida na forma de processos bem definidos. 2.3 MODELOS DE PROCESSOS DE SOFTWARE Segundo Sommerville (2003), os processos de software são complexos e, como todos os processos intelectuais, dependem de julgamento humano. Por causa da necessidade de utilizar o julgamento e a criatividade, tentativas de automatizar o processo de software têm tido sucesso limitado. As ferramentas CASE podem apoiar algumas atividades de processo, mas não existe a possibilidade de uma automação mais extensiva, na qual o software assuma o projeto criativo, liberando os engenheiros envolvidos no processo de software. Existem diversos modelos para definir os processos de software. Para muitos sistemas de grande porte, naturalmente, não existe apenas um processo de software que possa ser utilizado. Processos diferentes são utilizados para desenvolver diferentes partes do sistema, (SOMMERVILLE, 2003).

20 Ciclos de vida do Software Rezende (2005), afirma que o ciclo de vida natural de um software abrange basicamente as fases de: concepção (nascimento do sistema ou software); construção (análise e programação); implantação (testes e disponibilização aos clientes ou usuários); implementações (pequenos ajustes pós-implantação);maturidade e utilização plena(software sedimentado); declínio (dificuldade de continuidade); manutenção (tentativa de sobrevivência); morte (descontinuidade do sistemas ou do software). Para Paula (2000), como todo produto industrial, o software tem um ciclo de vida: ele é concebido a partir da percepção de uma necessidade; desenvolvido, transformando-se em um conjunto de itens entregue a um cliente; entra em operação, sendo usado dentro de um algum processo de negócio, e sujeito a atividades de manutenção, quando necessário; é retirado de operação, ao final de sua vida útil. Paula (2000) afirma que cada fase do ciclo de vida tem divisões e subdivisões, que serão apresentadas a seguir. É interessante observar, no Quadro 1, que a Codificação, que representa a escrita final de um programa em forma inteligível para um computador, é apenas uma pequena parte do ciclo de vida. Para a maioria das pessoas, inclusive muitos profissionais da informática, essa parece ser a única tarefa de um programador, ou seja, um produtor de software.

21 21 Quadro 1 Esquema simplificado do ciclo de vida do software: Fonte: Paula (2000). De acordo com Sommerville (2003), os problemas que os engenheiros de software têm para solucionar são bastante complexos. Compreender a natureza dos problemas pode ser muito difícil, especialmente se o sistema for novo. Conseqüentemente, é difícil estabelecer com exatidão o que o sistema deve fazer. As descrições das funções e das restrições são os requisitos para o sistema, e o processo de descobrir, analisar, documentar e verificar essas funções e restrições é chamado de engenharia de requisitos. Segundo Pressman (2011), antes de iniciar qualquer trabalho técnico, é uma boa ideia aplicar um conjunto de tarefas de engenharia de requisitos. Essas levam a um entendimento de qual será o impacto do software sobre o negócio, o que o cliente quer e como os usuários finais irão interagir com o software. Os requisitos de um software, também chamados de requerimentos de software ou de requisitos funcionais de um sistema, devem ser elaborados no início de um projeto de sistemas ou software. Para facilitar a elaboração dos requisitos funcionais, devem ser utilizadas técnicas de levantamento de dados e a analise de requisitos, que são tarefas contempladas na engenharia de software para atender os anseios do cliente ou usuário. (REZENDE, 2005).

22 22 As metodologias tradicionais fazem referência a um conjunto de práticas que se aplicam com certo êxito desde muitos anos, nas quais encontra-se tendências a ocupar e centrar esforços na documentação, nas práticas bem definidas, nos avanços e progressos prédefinidos. Essas metodologias tentam reduzir o risco mediante um forte levantamento de requisitos e um planejamento detalhado para não deixar lugar aos imprevistos (PRIOLO, 2009). Os ciclos de vida apresentados serão: cascata, espiral e incremental. Eles são um dos principais modelos de processo software Modelo Cascata Conforme Sommerville (2003), por causa da sequência em cascata de uma fase para outra, esse modelo é conhecido como 'modelo em cascata'. Os principais estágios do modelo retratam as atividades de desenvolvimento fundamentais, conforme figura abaixo: Figura 1 O ciclo de vida do software: Fonte: Sommerville (2003, p. 38).

23 23 Para Pressman (2006), o modelo cascata sugere uma abordagem sistemática e sequencial para o desenvolvimento de softwares que começa com a especificação dos requisitos pelo cliente e progride ao longo do planejamento, modelagem, construção e implantação, culminando na manutenção progressiva do software acabado, como demonstrado na figura abaixo: Figura 2 Modelo em cascata: Fonte: Pressman (2006, p. 39) Modelo Incremental Pressman (2006), afirma que existem diversas situações nas quais os requisitos do software são razoavelmente bem definidos, mas o escopo global do esforço de desenvolvimento elimina um processo puramente linear. Além disso, pode gerar uma forte necessidade de fornecer rapidamente um conjunto limitado de funcionalidades de software aos usuários e depois, refinar e expandir aquela funcionalidade em versões subsequentes do software. Nessas situações, é necessária a utilização de um modelo de processo que é destinado a produzir o software em incrementos. Para Sommerville (2003), em um processo de desenvolvimento incremental, os clientes identificam, em um esboço as funções a serem fornecidas pelo sistema. Eles identificam quais funções são mais importantes e quais são menos importantes para eles. Em

24 24 seguida é definida uma série de estágios de entrega, com cada estagio fornecendo um subconjunto das funcionalidades do sistema. Figura 3 Desenvolvimento Incremental: Fonte: Sommerville (2006, p. 43) Modelo Espiral Para o mesmo autor, o ciclo da espiral começa com a elaboração de objetivos, como, desempenho, funcionalidades etc. Meios alternativos de atingir esses objetivos e as restrições impostas a cada uma dessas alternativas são então enumerados. Cada alternativa examinada em relação a cada objetivo, isso, normalmente, resulta na identificação de causas de riscos do projeto. Segundo Paula (2000): O produto é desenvolvido em uma série de iterações. Cada nova iteração corresponde a uma volta na espiral. Isto permite construir produtos em prazos curtos, com novas características e recursos que são agregados na medida em que a experiência descobre sua necessidade. As atividades de manutenção são usadas para identificar problemas; seus registros fornecem dados para definir os requisitos das próximas liberações. O principal problema do ciclo de vida em espiral é que requer gestão muito sofisticada para ser previsível e confiável.

25 25 Conforme Pressman (2006), o modelo é uma abordagem realista do desenvolvimento de sistemas e softwares de grande porte. Como software evolui a medida que o processo avança, o desenvolvedor e o cliente entendem melhor, e reagem aos ricos de cada nível evolucionário. O modelo espiral utiliza a prototipagem como um mecanismo de redução de risco, no entanto permite ao desenvolvedor utilizar a abordagem em qualquer estágio de evolução do produto Modelos Ágeis Devido à existência de diversas práticas com características semelhantes, seus fundadores decidiram organizar e unificar critérios. Com essa idéia, surgiu o manifesto ágil (PRIOLO, 2009). Para Pressman (2011), agilidade pode ser aplicada a qualquer processo de software. Entretanto, para obtê-la é essencial que a equipe possa adaptar e alinhar tarefas; possa conduzir o planejamento compreendendo a fluidez e abordagem do desenvolvimento ágil; possa eliminar tudo, exceto os artefatos essenciais, conservando os enxutos; e enfatize a estratégia de entrega incremental, conseguindo entregar ao cliente, o mais rapidamente possível, o software operacional para o tipo de produto e ambiente operacional. Borges (2010), afirma que existem várias metodologias que podem ser consideradas como abordagens ágeis, entre elas: Scrum, Programação extrema, FDD, Crystal Clear, DSDM, entre outras. Neste trabalho será dado ênfase ao Scrum e Kanban por serem os modelos de interesse da empresa estudo de caso Scrum Segundo Ken Schwaber e Jeff Sutherland (2011), Scrum é um framework estrutural que está sendo usado para gerenciar o desenvolvimento de produtos complexos desde o início de Scrum não é um processo ou uma técnica para construir produtos, é

26 26 um framework dentro do qual você pode empregar vários processos ou técnicas. O Scrum deixa claro a eficácia relativa das práticas de gerenciamento e desenvolvimento de produtos, de modo que você possa melhorá-las. De acordo com os autores, O framework Scrum consiste nas equipes do Scrum associadas a papéis, eventos, artefatos e regras. Cada componente dentro do framework serve a um propósito específico e é essencial para o uso e sucesso do Scrum. Para eles, Scrum é fundamentado nas teorias empíricas de controle de processo, ou empirismo. O empirismo afirma que o conhecimento vem da experiência e de tomada de decisões baseadas no que é conhecido. O Scrum emprega uma abordagem iterativa e incremental para aperfeiçoar a previsibilidade e o controle de riscos. Ken Schwaber e Jeff Sutherland (2011) afirmam que três pilares apoiam a implementação de controle de processo empírico: transparência, inspeção e adaptação. Na transparência, aspectos significativos do processo devem estar visíveis aos responsáveis pelos resultados. Essa transparência requer aspectos definidos por um padrão comum para que os observadores compartilharem um mesmo entendimento do que está sendo visto. Na inspeção, os usuários Scrum devem, frequentemente, inspecionar os artefatos Scrum e o progresso em direção ao objetivo, para detectar indesejáveis variações. Essa inspeção não deve, no entanto, ser tão frequente que atrapalhe a própria execução das tarefas. As inspeções são mais benéficas quando realizadas de forma diligente por inspetores especializados no trabalho a se verificar. Já, na adaptação, se um inspetor determina que um ou mais aspectos de um processo desviou para fora dos limites aceitáveis, e que o produto resultado será inaceitável, o processo ou o material sendo produzido deve ser ajustado. O ajuste deve ser realizado o mais breve possível para minimizar mais desvios. Scrum é uma estrutura processual (framework) para suportar o desenvolvimento e manutenção de produtos complexos. O Scrum consiste em Equipes do Scrum associadas a seus papéis, eventos, artefatos e regras. Cada componente dentro do framework serve a um propósito específico e é essencial para o uso e o sucesso do Scrum, (SCHWABER e SUTHERLAND, 2011). Segundo eles, quanto aos papéis, o Time Scrum é composto pelo Product Owner, a Equipe de Desenvolvimento e o Scrum Master. Times Scrum são auto-organizáveis e multifuncionais. Equipes auto-organizáveis escolhem qual a melhor forma para completarem seu trabalho, em vez de serem dirigidos por outros de fora da equipe. Equipes multifuncionais possuem todas as competências necessárias para completar o trabalho sem depender de outros

27 27 que não fazem parte da equipe. O modelo de equipe no Scrum é projetado para aperfeiçoar a flexibilidade, criatividade e produtividade. Times Scrum entregam produtos de forma iterativa e incremental, maximizando as oportunidades de realimentação. Entregas incrementais de produto Pronto garantem que uma versão potencialmente funcional do produto do trabalho esteja sempre disponível. De acordo com os autores Ken Schwaber e Jeff Sutherland (2011), o Product Owner, ou dono do produto, é o responsável por maximizar o valor do produto e do trabalho da equipe de Desenvolvimento. De como isso é feito pode variar amplamente através das organizações, Times Scrum e indivíduos. O Product Owner é a única pessoa responsável por gerenciar o Backlog do Produto. O gerenciamento do Backlog do Produto inclui: expressar claramente os itens do Backlog do Produto; ordenar os itens do Backlog do Produto para alcançar melhor as metas e missões; garantir o valor do trabalho realizado pelo Time de Desenvolvimento; garantir que o Backlog do Produto seja visível, transparente, claro para todos, e mostrar o que o Time Scrum vai trabalhar a seguir; e, garantir que a Equipe de Desenvolvimento entenda os itens do Backlog do Produto no nível necessário, (SCHWABER e SUTHERLAND, 2011). Os autores, também, afirmam que, para que o Product Owner tenha sucesso, toda a organização deve respeitar as suas decisões. As decisões do Product Owner são visíveis no conteúdo e na priorização do Backlog do Produto. Ninguém tem permissão para falar com a Equipe de Desenvolvimento sobre diferentes configurações de prioridade, e o Time de Desenvolvimento não tem permissão para agir sobre o que outras pessoas disserem. A Equipe de Desenvolvimento, segundo Ken Schwaber e Jeff Sutherland (2011), consiste de profissionais que realizam o trabalho de entregar uma versão usável que potencialmente incrementa o produto Pronto ao final de cada Sprint. Somente integrantes da Equipe de Desenvolvimento criam incrementos. Essas equipes são estruturadas e autorizadas pela organização para organizar e gerenciar seu próprio trabalho. A sinergia resultante aperfeiçoa a eficiência e a eficácia da Equipe de Desenvolvimento como um todo. As Equipes de Desenvolvimento tem as seguintes características:

28 28 Elas são auto-organizadas. Ninguém (nem mesmo o Scrum Master) diz a Equipe de Desenvolvimento como transformar o Backlog do Produto em incrementos de funcionalidades potencialmente utilizáveis; Equipes de Desenvolvimento são multifuncionais, possuindo todas as habilidades necessárias, enquanto equipe, para criar o incremento do Produto. O Scrum não reconhece títulos para os integrantes da Equipe de Desenvolvimento que não seja o Desenvolvedor, independentemente do trabalho que está sendo realizado pela pessoa; Não há exceções para esta regra. Individualmente os integrantes da Equipe de Desenvolvimento podem ter habilidades especializadas e área de especialização, mas a responsabilidade pertence à Equipe de Desenvolvimento como um todo; e, Equipes de Desenvolvimento não contém sub-equipes dedicadas a domínios específicos de conhecimento, tais como teste ou análise de negócios. O tamanho ideal da Equipe de Desenvolvimento é pequeno o suficiente para se manter ágil e grande o suficiente para completar uma parcela significativa do trabalho. Menos de três integrantes na Equipe de Desenvolvimento diminuem a interação e resultam em um menor ganho de produtividade. Equipes de desenvolvimento menores podem encontrar restrições de habilidades durante a Sprint, gerando uma Equipe de Desenvolvimento incapaz de entregar um incremento potencialmente utilizável. Havendo mais de nove integrantes, é exigida muita coordenação. Equipes de Desenvolvimento grandes geram muita complexidade para um processo empírico gerenciar. Os papéis de Product Owner e de Scrum Master não são incluídos nesta contagem, ao menos que eles também executem o trabalho do Backlog da Sprint (SCHWABER e SUTHERLAND, 2011). Os autores, também, afirmam que o Scrum Master é responsável por garantir que o Scrum seja entendido e aplicado. O Scrum Master faz isso para garantir que o Time Scrum adere à teoria, práticas e regras do Scrum. O Scrum Master é um servo-líder para o Time Scrum. O Scrum Master ajuda àqueles que estão fora do Time Scrum a entender quais as suas interações com o Time Scrum são úteis e quais não são. O Scrum Master ajuda a todos mudarem essas interações para maximizar o valor criado pelo Time Scrum. Segundo Ken Schwaber e Jeff Sutherland (2011), o Scrum Master serve o Product Owner de várias maneiras, incluindo: encontrando técnicas para o gerenciamento efetivo do Backlog do Produto; claramente comunicar a visão, objetivo e itens do Backlog do Produto para a Equipe de Desenvolvimento; ensinar a Time Scrum a criar itens de Backlog do Produto de forma clara e concisa; compreender a longo-prazo o planejamento do Produto no ambiente empírico; compreender e praticar a agilidade; e, facilitar os eventos Scrum conforme exigidos ou necessários.

29 29 Para os autores, o Scrum Master serve a Equipe de Desenvolvimento de várias maneiras. São elas: treinar a Equipe de Desenvolvimento em auto-gerenciamento e interdisciplinaridade; ensinar e liderar a Equipe de Desenvolvimento na criação de produtos de alto valor; remover impedimentos para o progresso da Equipe de Desenvolvimento; facilitar os eventos Scrum conforme exigidos ou necessários; e treinar a Equipe de Desenvolvimento em ambientes organizacionais nos quais o Scrum não é totalmente adotado e compreendido. Eles também mencionam que o Scrum Master serve a Organização. As maneiras são as seguintes: liderando e treinando a organização na adoção do Scrum; planejando implementações Scrum dentro da organização; ajudando funcionários e partes interessadas a compreender e tornar aplicável o Scrum e o desenvolvimento de produto empírico; causando mudanças que aumentam a produtividade do Time Scrum; e trabalhando com outro Scrum Master para aumentar a eficácia da aplicação do Scrum nas organizações. Eventos prescritos são usados no Scrum para criar uma rotina e minimizar a necessidade de reuniões não definidas no Scrum. O Scrum usa eventos time-boxed, sendo que todo evento tem uma duração máxima. Isso garante que uma quantidade adequada de tempo seja gasta no planejamento sem permitir perdas no processo de planejamento. Além da Sprint, que é um container para outros eventos, cada evento no Scrum é uma oportunidade de inspecionar e adaptar alguma coisa. Esses eventos são especificamente projetados para permitir uma transparência e inspeção criteriosa. A não inclusão de qualquer um dos eventos resultará na redução da transparência e da perda de oportunidade para inspecionar e adaptar (SCHWABER e SUTHERLAND, 2011). Afirmam ainda que o coração do Scrum é a Sprint, um time-box de um mês ou menos, durante o qual um Pronto, versão incremental potencialmente utilizável do produto, é criado. Sprints têm durações coerentes em todo o esforço de desenvolvimento. Uma nova Sprint inicia imediatamente após a conclusão da Sprint anterior. As Sprints são compostas por uma reunião de planejamento da Sprint, reuniões diárias, o trabalho de desenvolvimento, uma revisão da Sprint e a restrospectiva da Sprint. Durante ela: Não são feitas mudanças que podem afetar o objetivo da Sprint; A composição da Equipe de Desenvolvimento permanecem constantes; As metas de qualidade não diminuem; e o escopo pode ser clarificado e renegociado entre o Product Owner e a Equipe de Desenvolvimento quanto mais for aprendido.

30 30 De acordo com os mesmos, cada Sprint pode ser considerada um projeto com horizonte não maior que um mês. Como os projetos, as Sprints são utilizadas para realizar algo. Cada Sprint tem a definição do que é para ser construído, um plano projetado e flexível que irá guiar a construção, o trabalho e o resultado do produto. Sprints são limitadas a um mês corrido. Quando o horizonte da Sprint é muito longo, a definição do que será construído pode mudar, a complexidade pode aumentar e o risco pode crescer. Sprints permitem previsibilidade que garantem a inspeção e adaptação do progresso em direção à meta pelo menos a cada mês corrido. Sprints também limitam o risco ao custo de um mês corrido. Também enfocam que o trabalho a ser realizado na Sprint é planejado na reunião de planejamento da Sprint. Esse plano é criado com o trabalho colaborativo de todo o Time Scrum. A reunião de planejamento da Sprint é uma time-box de oito horas para uma Sprint de um mês de duração. Para Sprints menores, esse evento deve ser proporcionalmente menor. O objetivo da Sprint dá a Equipe de Desenvolvimento alguma flexibilidade em relação as funcionalidades a serem implementadas dentro da Sprint. Conforme a Equipe de Desenvolvimento trabalha, ela mantém o objetivo em mente e, no caminho de buscar satisfazer o objetivo da Sprint, ela implementa a funcionalidade e a tecnologia. Caso o trabalho acabe por ser diferente do esperado pela Equipe de Desenvolvimento, então eles colaboram com o Product Owner para negociar o escopo do Backlog da Sprint dentro dela. O objetivo da Sprint pode ser um marco contido no propósito maior no roteiro do produto, (SCHWABER e SUTHERLAND, 2011). Segundo os autores, a Reunião Diária do Scrum é um evento time-boxed de 15 minutos, para que a Equipe de Desenvolvimento possa sincronizar as atividades e criar um plano para as próximas 24 horas. Essa reunião é feita para inspecionar o trabalho desde a última Reunião Diária e prever o trabalho que deverá ser feito antes da próxima Reunião Diária. Ela é mantida no mesmo horário e local todo dia para reduzir a complexidade. Durante a reunião, cada integrante da Equipe de Desenvolvimento esclarece: o que foi completado desde a última reunião, o que será feito até a próxima reunião e quais os obstáculos que estão no caminho. Mencionam que a Equipe de Desenvolvimento usa a Reunião Diária para avaliar o progresso em direção ao objetivo da Sprint e para avaliar se o progresso tende para completar

31 31 o trabalho do Backlog da Sprint. A Reunião Diária aumenta a probabilidade da Equipe de Desenvolvimento atingir o objetivo da Sprint. A Equipe de Desenvolvimento frequentemente se encontra imediatamente após a Reunião Diária, para re-planejar o restante do trabalho da Sprint. Todos os dias, a Equipe de Desenvolvimento deve estar apta a esclarecer para o Product Owner e para o Scrum Master como pretendem trabalhar em conjunto, como um time auto-organizado, para completar o objetivo e criar um incremento previsto desejado no restante da Sprint. O Scrum Master assegura que a Equipe de Desenvolvimento tenha a reunião, mas a Equipe de Desenvolvimento é responsável por conduzir a Reunião Diária. O Scrum Master ensina a Equipe de Desenvolvimento a manter a Reunião Diária dentro da time-box de 15 minutos. O Scrum Master reforça a regra de que somente os integrantes da Equipe de Desenvolvimento participem da Reunião Diária. A Reunião Diária não é uma reunião de status, é voltada para as pessoas que transformam os itens do Backlog do Produto em um incremento. Reuniões Diárias melhoram as comunicações, eliminam outras reuniões, identificam e removem impedimentos para o desenvolvimento, destacam e promovem rápidas tomadas de decisão e melhoram o nível de conhecimento da Equipe de Desenvolvimento. Essa é uma reunião chave para inspeção e adaptação. De acordo com os autores Schwaber e Sutherland (2011), a Revisão da Sprint é executada no final da Sprint para inspecionar o incremento e adaptar o Backlog do Produto se necessário. Durante a reunião de Revisão da Sprint, o Time Scrum e as partes interessadas colaboram sobre o que foi feito na Sprint. Com base nisso e em qualquer mudança no Backlog do Produto durante a Sprint, os participantes colaboram nas próximas coisas que precisam ser prontas. Essa é uma reunião informal e a apresentação do incremento destina-se a motivar e obter comentários e promover a colaboração. Assim, o resultado da Reunião de Revisão da Sprint é um Backlog do Produto revisado que define o provável Backlog do Produto para a próxima Sprint. O Backlog do Produto pode também ser ajustado completamente para atender novas oportunidades. A Retrospectiva da Sprint é uma oportunidade para o Time Scrum inspecionar a si próprio e criar um plano para melhorias a serem aplicadas na próxima Sprint. A Retrospectiva da Sprint ocorre depois de sua revisão e antes da reunião de planejamento da próxima Sprint. Esta é uma reunião time-boxed de três horas para uma Sprint de um mês. Proporcionalmente, um tempo menor é alocado para Sprints menores.

32 32 Ao final da Retrospectiva da Sprint, o Time Scrum deverá ter identificado melhorias que serão implementadas na próxima Sprint. A implementação dessas melhorias na próxima Sprint é a forma de adaptação à inspeção que o Time Scrum faz a si próprio. A Retrospectiva da Sprint fornece um evento dedicado e focado na inspeção e adaptação, no entanto, as melhorias podem ser adotadas a qualquer momento (SCHWABER e SUTHERLAND, 2011). Os autores também destacam que os artefatos do Scrum representam o trabalho ou o valor das várias maneiras que são úteis no fornecimento de transparência e oportunidades para inspeção e adaptação. Os artefatos definidos para o Scrum são especificamente projetados para maximizar a transparência das informações chave necessárias para assegurar que o Time Scrum tenha sucesso na entrega do incremento Pronto. De acordo com Ken Schwaber e Jeff Sutherland (2011), o Backlog do Produto é uma lista ordenada de tudo que deve ser necessário no produto e é uma origem única dos requisitos para qualquer mudança a ser feita no produto. O Product Owner é responsável pelo Backlog do Produto, incluindo seu conteúdo, disponibilidade e ordenação. O Backlog do Produto lista todas as características, funções, requisitos, melhorias e correções que formam as mudanças que devem ser feitas no produto nas futuras versões. Os itens do Backlog do Produto possuem os atributos da descrição, ordem e estimativa. Os autores afirmam que o Backlog da Sprint é um conjunto de itens do Backlog do Produto selecionados para a Sprint, juntamente com o plano de entrega do incremento do produto e atingir o objetivo da Sprint. O Backlog da Sprint é a previsão da Equipe de Desenvolvimento sobre qual funcionalidade estará no próximo incremento e do trabalho necessário para entregar a funcionalidade. O Backlog da Sprint define qual trabalho a Equipe de Desenvolvimento realizará para converter os itens do Backlog do Produto em um incremento Pronto. O Backlog do Produto torna visível todo o trabalho que a Equipe de Desenvolvimento identifica como necessário para atingir o objetivo da Sprint. Para Schwaber e Sutherland (2011), O Backlog da Sprint é um plano com detalhes suficientes para que as mudanças em progresso sejam entendidas durante a Reunião Diária. A Equipe de Desenvolvimento modifica o Backlog da Sprint ao longo de toda a Sprint, e o Backlog da Sprint vai surgindo durante a Sprint. Esse surgimento ocorre quando a Equipe de Desenvolvimento trabalha segundo o plano e aprende mais sobre o trabalho necessário para alcançar o objetivo da Sprint. Segundo eles, Em qualquer ponto do tempo na Sprint, o total do trabalho remanescente dos itens do Backlog da Sprint pode ser resumido. A Equipe de

33 33 Desenvolvimento monitora o total do trabalho restante, pelo menos, a cada Reunião Diária. A Equipe de Desenvolvimento acompanha esses resumos diários e projeta a probabilidade de alcançar o objetivo da Sprint. Com o rastreamento do trabalho restante em toda a Sprint, a Equipe de Desenvolvimento pode gerenciar o seu progresso. O Scrum não considera o tempo gasto trabalhando nos itens do Backlog da Sprint. O trabalho restante e a data são as únicas variáveis que interessam. O incremento é a soma de todos os itens do Backlog do Produto completados durante a Sprint e tudo das Sprints anteriores. Ao final da Sprint, um novo incremento deve estar Pronto, o que significa que deve estar na condição utilizável e atender a definição de Pronto do Time Scrum. Esse deve estar na condição utilizável independente do Product Owner decidir por liberá-lo realmente ou não (SCHWABER e SUTHERLAND, 2011). Esses autores concluem que papéis, artefatos, eventos e regras do Scrum são imutáveis e, embora seja possível implementar somente partes do Scrum, o resultado não é Scrum. Scrum existe somente na sua totalidade, funcionando bem como um container para outras técnicas, metodologias e práticas. Scrum é um modelo de desenvolvimento ágil que trabalha em iterações. Mike Cohn 2007 (apud KNIBERG 2007) prega que no Scrum a equipe deve completar alguma parte palpável de trabalho que seja entregável ao fim de cada iteração. Essas iterações são pensadas para serem curtas e com espaço de tempo definido. Esse foco em entregas de código funcionando em um curto espaço de tempo significa que equipes Scrum não tem tempo para teorias. Ele não persegue o desenho do diagrama UML perfeito em ferramentas CASE (Computer Aided Software Engeneering), a escrita do documento de requisitos perfeito ou a escrita do código que poderá acomodar todas as mudanças futuras imagináveis. Ao invés disso, equipes Scrum focam em ter as coisas prontas. Essas equipes aceitam que cometem erros ao longo do caminho, mas também compreendem que o melhor modo de identificar esses erros é parar de pensar sobre o software em um nível teórico de análise e design e mergulhar fundo, sujar as mãos e começar a construir o produto. Segundo Henrik Kniberg (2009), Product Backlog é a lista de coisas que o Product Owner (aquele que cria a visão do produto e prioridades) quer que sejam feitas nos sprints futuros. Para Kniberg (2007), O product backlog é o coração do Scrum. É aqui que tudo começa. O product backlog é basicamente uma lista de requisitos, estórias, coisas que o cliente deseja, descritas utilizando a terminologia do cliente. Elas são chamadas de estórias, ou, algumas vezes, apenas de itens do backlog.

34 34 Segundo Kniberg (2007), outras pessoas além do product owner podem adicionar estórias ao product backlog. Mas elas não podem associar uma escala de importância. Esse é um papel exclusivo do product owner. Eles também não podem estimar prazos. Essa é uma tarefa exclusiva da equipe. O planejamento de sprint é uma reunião crítica, provavelmente o evento mais importante no Scrum, segundo Kniberg (2007). Um encontro de planejamento de sprint mal feito pode bagunçar totalmente um sprint. O propósito da reunião de planejamento do sprint é dar à equipe informação suficiente para trabalharem em paz por algumas semanas e para dar ao product owner confiança suficiente para deixá-los fazerem isso. Para Kniberg (2007), Escopo e importância são definidos pelo product owner. A estimativa é definida pela equipe. Durante uma reunião de planejamento do sprint, essas três variáveis são refinadas continuamente por diálogo cara-a-cara entre equipe e product owner. Normalmente, o product owner inicia a reunião, resumindo seu objetivo para o sprint e as estórias mais importantes. Em seguida, a equipe toma a frente e estima o tempo de cada estória, começando pela mais importante. Em alguns casos, a estimativa de tempo para uma estória não será aquela que o product owner esperava. Isso poderá fazê-lo mudar a importância da estória, ou mudar o escopo da estória, que, por sua vez, fará a equipe reestimar. As reuniões diárias, para o mesmo autor, são seguidas bem a risca. Elas começam exatamente na hora, todo dia no mesmo lugar. Elas são feitas na sala da equipe, em frente do quadro de tarefas. Normalmente, o quadro de tarefas é atualizado durante a reunião diária. Conforme cada pessoa descreve o que fez ontem e o que fará hoje, vai colocando post-its no quadro de tarefas. Enquanto essa pessoa descreve um item não planejado, também cria um post-it para este item. Quando atualiza uma estimativa de prazo, atualiza a mesma no respectivo post-it, escrevendo a nova e riscando a estimativa antiga. Às vezes, o scrum master faz o trabalho com os post-its enquanto as outras pessoas conversam. Algumas equipes têm a política de que cada pessoa deve atualizar o quadro de tarefas antes de cada reunião. Segundo ele, isso também funciona bem. Independente do formato do sprint backlog, é importante que toda a equipe se envolva na tarefa de mantê-lo atualizado. A fim de fazer o planejamento de release, o product owner precisa de estimativas, ao menos para todas as histórias que estão inclusas no contrato, segundo HENRIK (2007). Assim como no planejamento do sprint, esse é um esforço cooperativo entre o product owner e a equipe a equipe estima, o product owner descreve os itens e responde questões. De acordo Kniberg (2009), o Scrum pode ser entendido da seguinte forma:

35 35 Divida sua organização em equipes pequenas, multifuncionais e auto-organizadas, conforme mostrado na Figura, a seguir: Figura 4 Equipes do Scrum. Fonte: Kanban e Scrum Obtendo o melhor de ambos (2009, p. 22). Divida o seu trabalho em uma lista de entregáveis pequenos e concretos. Classifique a lista por prioridade e estime o esforço relativo de cada item.

36 36 Figura 5 Lista de entregáveis. Fonte: Kanban e Scrum Obtendo o melhor de ambos (2009, p. 23). Divida o tempo e pequenas e curtas iterações de duração fixa (geralmente 1 4 semanas), com código potencialmente entregável demonstrado depois de cada iteração. Otimize o plano de entrega e atualize prioridades em colaboração com o cliente, baseados em insights através de inspeção da entrega depois de cada iteração. Otimize o processo executando uma retrospectiva depois de cada iteração. Segundo KNIBERG (2009), uma equipe Scrum tem uma pequena reunião (de no máximo 15 minutos) todos os dias na mesma hora e local. O objetivo da reunião é difundir informação sobre o que está acontecendo, planejar o trabalho do dia em curso e identificar os problemas mais importantes. Isso, às vezes, é chamado de reunião diária em pé, porque geralmente é realizada em pé (para mantê-la curta e manter um alto nível de energia). Para Henrik Kniberg (2009), em Scrum, o sprint backlog é apenas uma parte de algo maior a parte que mostra o que a equipe está fazendo durante o sprint atual. A outra parte é o product backlog a lista de coisas que o Product Owner quer que sejam feitas nos sprints futuros. O Product Owner pode visualizar, mas não pode tocar no sprint backlog. Ele pode modificar o product backlog a qualquer momento, mas tais mudanças não terão efeito até o próximo sprint.

37 37 Figura 6 Product backlog e Sprint backlog. Fonte: Kanban e Scrum obtendo o melhor de ambos (2009, p. 71). Quando o sprint está pronto, a equipe entrega código potencialmente entregável para o Product Owner. Então a equipe termina o sprint, faz sua revisão e orgulhosamente demonstra as funcionalidades A, B, C, e D ao Product Owner. O Product Owner agora pode decidir se vai produzir. A última parte colocar realmente em produção usualmente, não é incluída no sprint, portanto, não é visível no backlog do sprint Kanban O Kanban, segundo David Anderson (2009), é baseado numa idéia muito simples. As Atividades em andamento devem ser limitadas. Algo novo só deve ser iniciado quando uma peça de trabalho existente é liberada ou quando uma função automática inicia isso. De acordo com Anderson (2009), o Kanban, ou cartão de sinalização, é um sinal visual produzido, indicando que novo trabalho pode ser iniciado e que a atividade atual não coincide com o limite acordado. Isso não soa muito revolucionário nem parece afetar profundamente o desempenho, cultura, capacidade e maturidade de uma equipe e a

38 38 organização na qual está inserida. O Kanban parece uma mudança pequena e, no entanto, muda tudo a respeito de uma empresa. Mas o que se percebe para David é que o Kanban é uma abordagem para mudança gerencial. Ele não é um processo ou ciclo de vida de gerenciamento de projetos ou de desenvolvimento de software. O Kanban é uma abordagem para introduzir mudanças em um ciclo de desenvolvimento de software ou metodologia de gerenciamento de projetos. Você entende seu processo atual ao mapear o fluxo de valor e ao concordar, em seguida, em limitar as Atividades em andamento (do inglês WIP: Work in Progress) para cada estágio desse processo. A partir, daí você começa a rastrear as atividades pelo sistema para iniciá-las quando os sinais do Kanban aparecerem. Conforme David Anderson (2009), o Kanban tem sido útil para equipes ágeis de desenvolvimento de software, mas tem ganhado popularidade, igualmente, em equipes que utilizam uma abordagem mais tradicional. Ele está sendo introduzido como parte de uma iniciativa Lean (enxuta) para moldar a cultura das organizações e encorajar a melhoria contínua. Porque o WIP é limitado em um sistema Kanban, tudo que fica bloqueado por qualquer motivo tende a parar o sistema. Se certa quantidade de itens de trabalho fica bloqueada, todo o processo pára de funcionar. Isso cria a necessidade de concentrar toda a equipe e toda a empresa na solução do problema para desbloquear o item e restaurar o fluxo. De acordo com ele, o Kanban usa um mecanismo de controle visual para acompanhar o trabalho à medida que ele flui através das várias etapas do fluxo de valor. Tipicamente usa-se um quadro branco com post-its ou um sistema de cartões eletrônicos. Fazer os dois é, provavelmente, uma boa prática. A transparência que isso gera também contribui para a mudança cultural. Métodos ágeis têm sido bons provendo transparência sobre as atividades em andamento e concluídas, e reportando métricas como velocidade (a quantidade de trabalho finalizado em uma iteração). O Kanban, no entanto, vai um passo além e dá transparência ao processo e seu fluxo. Ele expõe gargalos, filas, variabilidade e desperdício. Tudo que impacta o desempenho da organização em termos de quantidade de trabalho de valor entregue e o tempo de ciclo necessário para entregá-lo. Proporciona aos membros da equipe e às partes interessadas externas a visibilidade sobre os efeitos de suas ações (ou falta de ações). Assim, os primeiros estudos de caso estão mostrando que o Kanban muda o comportamento e incentiva uma maior colaboração no trabalho. A visibilidade dos gargalos, desperdício e variabilidade e seus impactos, também incentivam a discussão sobre melhorias e as equipes, rapidamente, iniciam as melhorias nos seus processos.

39 39 Como resultado, o Kanban encoraja a evolução incremental de processos existentes, evolução que é geralmente alinhada a valores Ágeis e Lean. Ele não demanda uma revolução drástica no modo de como as pessoas trabalham, encoraja, ao invés disso, uma mudança gradual. É mudança entendida e aceita por consenso entre trabalhadores e seus colaboradores. É através da natureza de um sistema puxado, ou seja, um sistema em que os times é que puxam o trabalho, na medida de sua capacidade, e não o oposto, quando o trabalho é empurrado à equipe, que o Kanban encoraja também comprometimento tardio, tanto em priorização de trabalho novo quanto na entrega de trabalho existente. Tipicamente, os times vão concordar em uma cadência de priorização para atender partes interessadas que estejam contra a maré e decidir a próxima coisa em que trabalhar. Essas reuniões podem ser feitas regularmente porque são normalmente muito curtas. De acordo Kniberg (2007), o Kanban pode ser entendido da seguinte forma: visualiza o fluxo de trabalho: Divide o trabalho em partes, escreve cada item em um cartão e coloca na parede e usa colunas nomeadas para ilustrar onde cada item está no fluxo de trabalho; limite o trabalho em progresso (WIP - Work in Progress) associa limites explícitos para quantos itens podem estar em progresso em cada estado do fluxo de trabalho; acompanha o tempo de execução da tarefa (tempo médio para completar um item, algumas vezes chamado de tempo de ciclo ). Otimiza o processo para tornar o tempo de execução o menor e mais previsível possível. Segundo Kniberg (2007): Scrum prescreve 3 papéis: Product Owner (cria a visão do produto e prioridades), Equipe (implementa o produto) e ScrumMaster (remove impedimentos e fornece liderança de processo). Kanban não prescreve papel nenhum. Isso não significa que você não possa ou não deva ter o papel de um Product Owner em Kanban! Significa apenas que você não precisa. Tanto em Scrum quanto em Kanban, você é livre para incluir quaisquer papéis adicionais que precisar. Mas tenha cuidado ao incluir papéis, tenha certeza de que os papéis adicionais realmente agregam valor e não entram em conflito com outros elementos do processo. Você tem certeza de que precisa do papel de Gerente de Projetos? Em um grande projeto talvez seja uma grande idéia, talvez seja a pessoa que ajuda a sincronizar múltiplos projetos e Product Owners entre si. Em um projeto pequeno esse papel pode ser um desperdício, ou pior, pode levar a uma sub-otimização e ao micro gerenciamento.

40 40 Scrum e Kanban para Kniberg (2009) são sistemas puxados, que correspondem ao princípio de gestão de inventário de Just In Time (JIT) do Lean. Isso significa que a equipe escolhe quando e quanto de trabalho irá se comprometer para então puxar o trabalho quando estão prontos para começar, ao invés de ter que empurrar o trabalho de algum lugar. Ambos dão ênfase à resposta de mudança ao invés de seguir um plano pré-estabelecido (embora o Kanban tipicamente permita uma resposta mais rápida do que o Scrum), um dos quatro valores do manifesto ágil. Em Scrum, a priorização é sempre feita por triagem do product backlog e as mudanças de prioridades realizam-se no próximo sprint. Em Kanban, você pode escolher qualquer plano de prioridade e as mudanças realizam-se assim que a equipe estiver disponível. Pode-se ou não ter um product backlog e pode-se ou não ser priorizado. Na prática, isso faz pouca diferença. Em um quadro de Kanban, a coluna mais à esquerda desempenha, tipicamente, o mesmo objetivo do product backlog de Scrum. Seja a lista ordenada ou não por prioridade, a equipe precisa de algum tipo de regra para a decisão de quais itens devem ser realizados primeiro. De acordo com Kniberg (2007), reuniões diárias não são prescritas no Kanban, mas, de qualquer maneira, a maioria das equipes de Kanban costuma fazê-las. É uma excelente técnica, independentemente do processo utilizado. Em Scrum, a reunião diária é orientada à pessoa cada pessoa passa a informação, um a um. Muitas equipes Kanban usam um formato mais orientado ao quadro, concentradas nos gargalos e outros problemas visíveis. Essa abordagem é mais escalável. Figura 7 Quadro Kanban. Fonte: Kanban e Scrum obtendo o melhor de ambos (2009, p. 72).

41 41 No exemplo acima, a coluna Backlog é, apenas, uma lista de coisas desejáveis, sem qualquer ordem especial. A coluna Selecionados contém os itens com maiores prioridades, com o limite Kanban igual a 2. Dessa forma, deve conter apenas 2 itens com alta prioridade ao mesmo tempo. Sempre que a equipe estiver pronta para começar a trabalhar em um novo item, ela irá pegar o primeiro item da coluna Selecionados. A qualquer momento o Product Owner poderá fazer mudanças nas colunas Backlog e Selecionados, mas não poderá mudar as demais colunas. A coluna Desenvolver (dividida em duas sub-colunas) mostra o que está sendo desenvolvido no momento com umlimite Kanban de 3. Em termos de infra-estrutura de rede, o limite Kanban corresponde a largura de banda e o tempo de execução corresponde ao ping (ou tempo de resposta). Por que nós dividimos a coluna Desenvolver em duas sub-colunas Iniciado e Pronto? Para dar à equipe de produção a oportunidade de saber quais itens eles podem mover para a produção. O limite de 3 é compartilhado pelas duas sub-colunas. O motivo é imaginar que temos dois itens em Pronto : Figura 8 Quadro Kanban. Fonte: Kanban e Scrum obtendo o melhor de ambos (2009, p. 73). Isto significa que só podemos ter 1 item em Iniciado. Assim teremos capacidade em excesso. Desenvolvedores que poderiam iniciar um novo item, mas não estão liberados em virtude do limite do Kanban. Isso lhes dá forte incentivo para concentrar esforços e ajudar

42 42 a colocar as coisas em produção, limpar a coluna Pronto e maximizar o fluxo. Este efeito é bom e gradual quanto mais coisas em Pronto, menos coisas serão permitidas no Iniciado o que ajuda à equipe concentrar-se nas coisas certas. Kniberg (2009), afirma que um fluxo contínuo é um tipo de cenário com um fluxo perfeito, em que um item flui através do quadro sem ficar preso em nenhuma coluna. Isso quer dizer que, a todo o momento, existe alguém trabalhando naquele item. Figura 9 Quadro Kanban. Fonte: Kanban e Scrum obtendo o melhor de ambos (2009, p. 74). Onde B está sendo desenvolvido, nesse momento, A está sendo colocado em produção nesse momento. Sempre que a equipe estiver pronta para o próximo item, ela irá perguntar para o Product Owner qual é o item mais importante, e ela terá uma resposta na hora. Se este cenário ideal continuar, podemos nos livrar das duas colunas Backlog e Escolhido e assim ter um tempo de resposta realmente curto. O limite das atividades em andamento existe para impedir que problemas fujam do controle. Então, se as coisas estão fluindo bem, os limites das atividades em andamento não são realmente usados.

43 PRODUTOS E PROCESSO Conforme Pressman (2006), se o processo for fraco, o produto final sofrerá inevitavelmente, mas uma ênfase exagerada no processo também é perigosa. O ideal é manter-se em um ponto intermediário entre os dois extremos, o foco da continuidade do software desloca-se constantemente, pois uma nova força é aplicada, se houver falhas nesse andamento. Para Rezende (2005), os componentes de software são criados por meio de uma série de conversões que mapeiam as exigências do cliente para código executável em máquina. Um modelo das exigências é convertido num projeto. E, posteriormente, o projeto sendo convertido numa forma de linguagem que especifica a estrutura de dados de software, os seus atributos e requisitos relacionados. Segundo Paula (2000), a tecnologia só resolve problemas, quando é usada por pessoas qualificadas, dentro de processos adequados. Os sistemas de informática são os produtos da tecnologia de tratamento da informação. De acordo com Hauck (2007), a abordagem ASPE/MSC é constituída de fases e atividades, de forma que uma organização possa modelar o seu processo em ciclos de melhoria contínua. Além da definição de todas as atividades necessárias para se modelar um processo de uma micro ou pequena empresa, a abordagem ASPE/MSC também fornece um conjunto de templates de documentos utilizados para a modelagem. Durante toda a modelagem dos processos, o gerenciamento da sua aplicação é realizado em paralelo com as demais atividades para garantir o encerramento com sucesso. Para Piattini (2011), o modelo IDEAL foi originalmente concebido como ciclo de vida para a melhoria do modelo de processo de software baseado no CMM e, em seguida, o modelo foi revisado para proporcionar um alcance mais amplo. IDEAL constitui é uma abordagem útil e compreensível para a melhoria contínua, estabelecendo os passos necessários que se devem seguir para a realização de um programa melhor e proporcionando um enfoque na engenharia e uma abordagem disciplinada. O modelo IDEAL esta composto por cinco fases que são: Iniciação, diagnostico, estabelecimento, atuação, aprendizagem. Sendo que cada fase é formada por uma seria de atividades.

44 QUALIDADE DE SOFTWARE Pressman (2006), diz que a melhoria dos processos de software pode ser implementada de diferentes a maneiras. Ela pode ocorrer por meio de padronização de processos, quando a diversidade dos processos de software em uma organização é reduzida. Isso leva a melhoria da comunicação e a redução do tempo de treinamento e faz com que o apoio ao processo automatizado seja mais econômico. A padronização é também uma primeira etapa essencial na introdução de novos métodos e novas técnicas de engenharia de software e também de boas práticas de engenharia de software. Para Pressman (2011), a necessidade de maior qualidade de software começou realmente, quando o software passou a se tornar cada vez mais integrado em todas as atividades de nossas vidas. Na década de 1990, as principais empresas reconheciam que bilhões de dólares por ano estavam sendo desperdiçados em software que não apresentava as características e as funcionalidades prometidas. Rezende (2005), afirma que a qualidade do produto de software está relacionada à qualidade do processo de software. Dessa forma, os modelos e as normas de um processo devem garantir o sucesso dos projetos de software. Segundo Paula (2000, p. 17): Geralmente, a qualidade de um produto decorre diretamente da qualidade do processo utilizado na produção dele. Note-se que importa aqui a qualidade do processo efetivamente utilizado, não do "processo oficial", que pode eventualmente estar descrito nos manuais da organização. Muitas vezes os processos oficiais não são seguidos na prática, por deficiência de ferramentas, por falta de qualificação das pessoas, ou porque pressões de prazo levam os gerentes dos projetos a eliminar etapas relacionadas com controle da qualidade. De acordo com Pressman (2006), no desenvolvimento de software, a qualidade de projeto abrange os requisitos, as especificações e o projeto do sistema. A qualidade de conformidade é um assunto relativo, principalmente a implementação. Se a mesma segue o projeto e o sistema resultante satisfaz os requisitos e metas de desempenho, a qualidade de conformidade é alta.

45 45 Conforme Magalhães (2007), um dos grandes desafios para a Engenharia de Software vem sendo desenvolver software de qualidade, atendendo os prazos estabelecidos, esforços e custos estabelecidos. Ao mesmo tempo em que requer software cada vez mais complexo, o mercado anseia por produtos de maior qualidade. Nessa direção, empresas desenvolvedoras de software têm se preocupado cada vez mais com a qualidade dos produtos de software que geram, sendo necessário criar mecanismos por meio dos quais a qualidade possa ser planejada, controlada, avaliada e alcançada Garantia da Qualidade Para Pressman (2006), a garantia da qualidade é uma atividade essencial para qualquer negócio que faz produtos para serem usados por outros. Antes do século XX, a garantia da qualidade era de responsabilidade tão somente do artesão que construía um produto. Segundo Paula (2000), em todas as fases do desenvolvimento de software, as pessoas introduzem defeitos. Eles decorrem de limitações humanas: erros lógicos, erros de interpretação, desconhecimento de técnicas, falta de atenção ou falta de motivação. Em todo bom processo existem atividades de garantia da qualidade tais como, revisões, testes e auditorias. Essas atividades removem parte dos defeitos introduzidos, quando atividades de controle da qualidade são cortadas, parte dos defeitos deixa de ser removida em um ponto do projeto. O propósito da garantia da qualidade é assegurar que os objetivos planejados no início do projeto, serão cumpridos. De forma geral, isso significa estabelecer sistemas para controlar tudo o que ocorre durante o ciclo de vida, com o propósito de garantir que o programa que será fabricado fará aquilo que se espera dele. (KOSCIANSKI; SOARES, 2007). Pressman (2011), diz que qualidade de software pode ser definida como uma gestão de qualidade efetiva aplicada, de modo a criar um produto útil que forneça valor mensurável para aqueles que o produzem e para aqueles que utilizam. De acordo com a SOFTEX (2012), a norma ISO/IEC foi publicada em dezembro de 2005 e tem como objetivo fornecer um padrão de referência comum para

46 46 qualquer empresa oferecer serviços de TI para clientes internos ou externos. Essa norma prevê a adoção de uma abordagem de processos integrada para a gestão de serviços. A ISO/IEC consiste em cinco partes sob o título geral Tecnologia da Informação Gerenciamento de Serviço. Conforme SOFTEX (2012), o CMMI: Auxilia as organizações nas iniciativas de melhoria de processos de software multimodelos, seja no âmbito das implementações ou das avaliações de processos. O problema é que ele pode se muito oneroso para pequenas empresas, por isso o surgimento do MPSBR. O modelo MPS, de acordo com a SOFTEX, deve ser adequado ao perfil de empresas com diferentes tamanhos e características, públicas e privadas, embora com especial atenção às micro, pequenas e médias empresas. Também, se espera que o modelo MPS seja compatível com os padrões de qualidade aceitos internacionalmente e que tenha como pressuposto o aproveitamento de toda a competência existente nos padrões e modelos de melhoria de processo já disponíveis. Dessa forma, ele tem como base os requisitos de processos definidos nos modelos de melhoria de processo e atende a necessidade de implantar os princípios de engenharia de software de forma adequada ao contexto das empresas, estando em consonância com as principais abordagens internacionais para definição, avaliação e melhoria de processos de software. 2.6 MPS.BR SOFTEX (2012) afirma que o objetivo do programa MPS.BR é a Melhoria de Processo do Software Brasileiro, com 2 metas a alcançar a médio e longo prazos. A primeira é a meta técnica, que visa à criação e aprimoramento do modelo MPS, com resultados esperados, tais como guias do modelo MPS, Instituições Implementadoras (II) credenciadas para prestar serviços de consultoria de implementação do modelo de referência MR-MPS- SW. O MR-MPS-SW é o Modelo de Referência MPS para Software, que define níveis de maturidade que são uma combinação entre processos e sua capacidade. A capacidade do

47 47 processo é a caracterização da habilidade do processo para alcançar os objetivos de negócio, atuais e futuros; estando relacionada com o atendimento aos atributos de processo associados aos processos de cada nível de maturidade. Instituições Avaliadoras (IA) credenciadas para prestar serviços de avaliação, seguem o método de avaliação MA-MPS, Consultores de Aquisição (CA) certificados para prestar serviços de consultoria de aquisição de software e serviços relacionados. A segunda meta é a de mercado, que visa à disseminação e adoção do modelo MPS, em todas as regiões do país, em um intervalo de tempo justo, a um custo razoável, tanto em PME (Pequenas e Médias Empresas) (foco principal) quanto em grandes organizações públicas e privadas. Os resultados esperados são: criação e aprimoramento do modelo de negócio MN-MPS; cursos, provas e workshops; organizações que implementaram o modelo MPS; organizações com avaliação MPS publicada (prazo de validade de três anos). SOFTEX, ainda, afirma que o programa MPS.BR conta com duas estruturas de apoio para o desenvolvimento de suas atividades, o Fórum de Credenciamento e Controle (FCC) e a Equipe Técnica do Modelo (ETM). Por meio dessas estruturas, o MPS.BR obtém a participação de representantes de universidades, instituições governamentais, centros de pesquisa e de organizações privadas, os quais contribuem com suas visões complementares que agregam qualidade ao empreendimento. É tarefa do FCC: emitir parecer que subsidie decisão da SOFTEX sobre o credenciamento de Instituições Implementadoras e Instituições Avaliadoras (IA); monitorar os resultados das Instituições Implementadoras e Instituições Avaliadoras (IA), emitindo parecer propondo à SOFTEX o seu descredenciamento no caso de comprometimento da credibilidade do modelo MPS. Cabe à ETM apoiar a SOFTEX sobre os aspectos técnicos relacionados ao Modelo de Referência (MR-MPS-SW) e Método de Avaliação (MA-MPS), para a criação e aprimoramento contínuo do MR-MPS, MA-MPS e seus guias específicos; capacitação de pessoas por meio de cursos, provas e workshops. A SOFTEX (2012) apresenta um guia de implementação de um Modelo de Referência de Processo (MR-MPS) e um Modelo de Avaliação de Processo (MA-MPS), que estão sendo desenvolvidos no Projeto MPSBR. Segunda ela, esse projeto visa a melhoria de processo de software brasileiro, a um custo acessível. O desenvolvimento e aprimoramento do Modelo MPS deve ser compatível com o CMMI e em conformidade com as normas ISO/IEC e ISO/IEC

48 48 Para a SOFTEX (2012): Uma das metas do Programa MPS.BR é definir e aprimorar um modelo de melhoria e avaliação de processo de software e serviços, visando preferencialmente às micro, pequenas e médias empresas (MPME), de forma a atender as suas necessidades de negócio e ser reconhecido nacional e internacionalmente como um modelo aplicável à indústria de software e serviços. O modelo MPS estabelece dois modelos de referência de processos de software e serviços, e um processo/método de avaliação de processos. Esta estrutura fornece sustentação e garante que o modelo MPS seja empregado de forma coerente com as suas definições. O modelo MPS estabelece também um modelo de negócio para apoiar a sua adoção pelas empresas desenvolvedoras de software e prestadores de serviços. SOFTEX (2012) menciona que os níveis de maturidade estabelecem patamares de evolução de processos, caracterizando estágios de melhoria da implementação de processos na organização. O nível de maturidade em que se encontra uma organização permite prever o seu desempenho futuro ao executar um ou mais processos. O MR-MPS-SW define sete níveis de maturidade. O último, isto é, o maior nível é A (Em Otimização), antes o B (Gerenciado Quantitativamente), C (Definido), D (Largamente Definido), E (Parcialmente Definido), F (Gerenciado) e o primeiro é G (Parcialmente Gerenciado). A escala de maturidade se inicia no nível G e progride até o nível A. Para cada um desses sete níveis de maturidade é atribuído um perfil de processos que indicam onde a organização deve colocar o esforço de melhoria. O progresso e o alcance de um determinado nível de maturidade do MR-MPS-SW se obtém quando são atendidos os propósitos e todos os resultados esperados dos respectivos processos e os resultados esperados dos atributos de processo estabelecidos para aquele nível. A divisão em 7 estágios tem o objetivo de possibilitar uma implementação e avaliação adequada às micros, pequenas e médias empresas. A possibilidade de se realizar avaliações, considerando mais níveis, também permite uma visibilidade dos resultados de melhoria de processos em prazos mais curtos.

49 NIVEIS DE MATURIDADE DO MPS.BR A seguir serão apresentados cada um dos níveis de maturidade do MPSBR. Nível G - O nível de maturidade G, segundo a SOFTEX, (2012) é composto pelos processos Gerência de Projetos e Gerência de Requisitos. Nesse nível, a implementação deve satisfazer os atributos de processo que atinge seus resultados definidos e processos gerenciados. Assim, ela afirma que o propósito do processo Gerência de Projetos é estabelecer e manter planos que definem as atividades, recursos e responsabilidades do projeto, bem como prover informações sobre o andamento do projeto que permitam a realização de correções, quando houver desvios significativos no desempenho do projeto. O propósito desse processo evolui à medida que a organização cresce em maturidade. Assim, a partir do nível E, alguns resultados evoluem e outros são incorporados, de forma que a gerência de projetos passe a ser realizada com base no processo definido para o projeto e nos planos integrados. No nível B, a gerência de projetos passa a ter um enfoque quantitativo, refletindo a alta maturidade que se espera da organização. Novamente, alguns resultados evoluem e outros são incorporados. Já o propósito do processo Gerência de Requisitos é gerenciar os requisitos do produto e dos componentes do produto do projeto e identificar inconsistências entre os requisitos, os planos do projeto e os produtos de trabalho do projeto. Nível F - O nível de maturidade F é um nível gerenciado, composto pelos processos do nível de maturidade anterior (G) acrescidos dos processos Aquisição, Garantia da Qualidade, Gerência de Configuração, Gerência de Portfólio de Projetos e Medição. Nível E É o nível parcialmente definido e é composto pelos processos dos níveis de maturidade anteriores (G e F), acrescidos dos processos Avaliação e Melhoria do Processo Organizacional, Definição do Processo Organizacional, Gerência de Recursos Humanos e Gerência de Reutilização. O processo Gerência de Projetos sofre sua primeira evolução, retratando seu novo propósito: gerenciar o projeto com base no processo definido para o projeto e nos planos integrados. Nível D É o nível largamente definido, que é composto pelos processos dos níveis de maturidade anteriores (G ao E), acrescidos dos processos Desenvolvimento de Requisitos, Integração do Produto, Projeto e Construção do Produto, Validação, e Verificação.

50 50 Nível C É o nível definido. Ele é composto pelos processos dos níveis de maturidade anteriores (G ao D), acrescidos dos processos Desenvolvimento para Reutilização, Gerência de Decisões e Gerência de Riscos. Nível B É o nível gerenciado quantitativamente. É composto pelos processos dos níveis de maturidade anteriores (G ao C). Nesse nível, o processo de Gerência de Projetos sofre sua segunda evolução, sendo acrescentados novos resultados para atender aos objetivos de gerenciamento quantitativo. Nível A Esse é o nível em otimização. É composto pelos processos dos níveis de maturidade anteriores (G ao B) Capacidade do Processo A capacidade do processo, segundo SOFTEX (2012), é representada por um conjunto de atributos de processo descrito em termos de resultados esperados. A capacidade do processo expressa o grau de refinamento e institucionalização com que o processo é executado na organização/unidade organizacional. No MR-MPS-SW, à medida que a organização/unidade organizacional evolui nos níveis de maturidade, um maior nível de capacidade para desempenhar o processo deve ser atingido. O atendimento aos atributos do processo (AP), pelo atendimento aos resultados esperados dos atributos do processo (RAP), é requerido para todos os processos no nível correspondente ao nível de maturidade, embora eles não sejam detalhados dentro de cada processo. Os níveis são acumulativos, ou seja, se a organização está no nível F, esta possui o nível de capacidade do nível F que inclui os atributos de processo dos níveis G e F para todos os processos relacionados no nível de maturidade F (que também inclui os processos de nível G). Isto significa que, ao passar do nível G para o nível F, os processos do nível de maturidade G passam a ser executados no nível de capacidade correspondente ao nível F. Em outras palavras, na passagem para um nível de maturidade superior, os processos anteriormente implementados devem passar a ser executados no nível de capacidade exigido nesse nível superior.

51 51 Os diferentes níveis de capacidade dos processos são descritos por nove atributos de processo (AP). O alcance de cada atributo de processo é avaliado utilizando os respectivos resultados esperados de atributo de processo (RAP), conforme definido a seguir: AP 1.1 o processo é executado; AP 2.1 o processo é gerenciado; AP 2.2 os produtos de trabalho do processo são gerenciados; AP 3.1. o processo é definido; AP 3.2 o processo está implementado; AP 4.1 o processo é medido; AP 4.2 o processo é controlado; AP 5.1 o processo é objeto de melhorias incrementais e inovações; AP 5.2 o processo é otimizado continuamente. O quadro 2 exibe os níveis de maturidade do modelo MR-MPS-SW. Mostra os seus processos e os atributos necessários para cada nível.

52 52 Quadro 2 Níveis de maturidade do MR-MPS-SW. Fonte: MPS.BR - Melhoria de Processo do Software Brasileiro - Guia Geral MPS de Software (2012, p. 23). Como este trabalho irá aprofundar no nível G, a seguir são apresentados os conceitos sobre gerência de projetos e requisitos.

53 GERÊNCIA DE PROJETOS De acordo com Cordeiro (2002), projeto é um esforço temporário empreendido para criar um serviço ou produto exclusivo. Temporário significa que todo projeto tem começo e fim definidos. Exclusivo significa que o produto ou serviço é de alguma forma diferente de todos os produtos e serviços semelhantes. Segundo PMBOK (2004), os projetos e as operações diferem principalmente no fato de que as operações são contínuas e repetitivas, enquanto os projetos são temporários e exclusivos. Os objetivos dos projetos e das operações são fundamentalmente diferentes. A finalidade de um projeto é atingir seu objetivo e, em seguida, terminar. Por outro lado, o objetivo de uma operação contínua é manter o negócio. Os projetos são diferentes porque o projeto termina quando seus objetivos específicos foram atingidos, enquanto as operações adotam um novo conjunto de objetivos e o trabalho continua. IEEE (Institute of Electrical and Electronics Engineers) (1990, apud SOFTEX 2011) diz que a gerência de projetos de software pode ser definida como a aplicação de planejamento, coordenação, medição, monitoramento, controle e divulgação de relatórios, com o intuito de garantir que o desenvolvimento e a manutenção de software sejam sistemáticos, disciplinados e qualificados. E, segundo a norma internacional ISO/IEC, 12207, o propósito da gerência de projetos é identificar, estabelecer, coordenar e monitorar as atividades, tarefas e recursos que um projeto necessita para produzir um produto, no contexto dos requisitos e restrições do projeto. O processo Gerência de Projetos (GPR), segundo a SOFTEX, (2011), envolve várias atividades, como: desenvolver um plano geral de controle do projeto; obter o comprometimento e mantê-lo ao longo de toda a execução do projeto e conhecer o progresso do projeto, de maneira que ações corretivas possam ser tomadas, quando a execução do projeto desviar do planejado. Gestão de Projetos é a aplicação do conhecimento, habilidades, ferramentas e técnicas na administração eficaz e eficiente das atividades integrantes do projeto. O profissionalismo obtido com estudos e práticas dinamiza os processos de iniciação, planejamento, execução, controle e encerramento que compõem o projeto. Um projeto é bem sucedido, quando realizado conforme planejado, (MARTINS, 2003).

54 54 O desenvolvimento do plano do projeto inclui: identificar e estimar o escopo, os produtos de trabalho e as tarefas do projeto; estabelecer recursos necessários; identificar e analisar riscos do projeto; estabelecer compromisso e definir cronograma de execução baseado no ciclo de vida definido para o projeto. O plano do projeto estabelece a base de execução e controle para as atividades do projeto junto aos seus interessados (especialmente o cliente). Todos os interessados devem estar comprometidos com ele. O progresso da execução do projeto é determinado pela comparação dos atributos reais de produtos de trabalho e tarefas, esforço, custo e cronograma com o que foi planejado nos marcos ou em pontos de controle predefinidos no planejamento do projeto. Um marco é um ponto de revisão, por exemplo, o início ou o final de cada fase do projeto ou algumas atividades de fundamental importância para o seu sucesso. A revisão de início de fase de projeto tem por objetivo verificar se as condições para que uma fase seja iniciada estão atendidas. Pode ser que, mesmo que a fase anterior não esteja encerrada, seja possível iniciar a nova fase, nas condições atendidas e com prazos para o cumprimento de algumas outras condições. A revisão de fim de fase de projeto tem por objetivo verificar se todos os critérios de encerramento de fase foram cumpridos. As revisões em marcos podem ter um caráter formal, com participação de gerências superiores, representantes do cliente e outras partes interessadas no projeto. Sempre que necessário, deve-se realizar um replanejamento e uma nova análise de sua viabilidade. Pontos de controle representam pontos entre um marco e outro nos quais revisões são realizadas para avaliar o andamento do projeto, porém não estão no caminho crítico do projeto, ou seja, o projeto pode prosseguir mesmo que a revisão de um ponto de controle não tenha sido concluída. A visibilidade apropriada possibilita a tomada de ações corretivas quando o status do projeto se desvia significativamente do esperado. Tais ações podem exigir o replanejamento, para incluir a revisão do plano original, o estabelecimento de novos acordos ou atividades adicionais de mitigação de riscos no plano. Alguns resultados do processo Gerência de Projetos (GPR) evoluem e outros são adicionados ao processo nos níveis de maturidade E e B do MR-MPS. Essa parte do Guia de Implementação apresenta orientações apenas para implementar nas organizações os resultados do processo Gerência de Projetos (GPR) a partir do nível de maturidade G do MR-MPS. A SOFTEX (2011), afirma que os resultados esperados do nível G para a gerência de projetos serão listados abaixo:

55 55 GPR1 - O escopo do trabalho para o projeto é definido: o escopo do projeto define todo o trabalho necessário e somente, ele, para entregar um produto que satisfaça as necessidades, características e funções especificadas para o projeto, de forma a concluí-lo com sucesso. O escopo é o ponto de partida para o planejamento do projeto. A definição do escopo deve estabelecer o que está e o que não está incluído no projeto. Para isso, o escopo em geral contém a definição do objetivo e da motivação, os limites e restrições, todos os produtos que serão entregues e os outros produtos gerados pelo projeto, entre outras informações. GPR2 - As tarefas e os produtos de trabalho do projeto são dimensionados utilizando métodos apropriados: o escopo do projeto, identificado na forma dos seus principais produtos de trabalho e das tarefas do projeto, deve agora ser decomposto em componentes menores, mais facilmente gerenciáveis e possíveis de serem dimensionados. Uma estrutura de decomposição do trabalho apropriada deve ser estabelecida. Essa estrutura de decomposição pode ser a EAP (Estrutura Analítica do Projeto) do projeto ou estrutura equivalente. A estrutura de decomposição fornece uma referência para a atribuição de tamanho, esforço, cronograma e responsabilidades e é utilizada como uma estrutura subjacente para planejar, organizar e controlar o trabalho executado no projeto. O tamanho é a principal entrada de muitos modelos utilizados para estimar o esforço, custo e cronograma. GPR3 - O modelo e as fases do ciclo de vida do projeto são definidos: o ciclo de vida de um projeto consiste de fases e atividades que são definidas de acordo com o escopo dos requisitos, as estimativas para os recursos e a natureza do projeto, visando oferecer maior controle gerencial. O ciclo de vida de projeto define um conjunto de fases, que por sua vez geram produtos de trabalho necessários para o desenvolvimento de fases posteriores. Essa organização em fases permite planejar o projeto, incluindo marcos importantes para o controle e revisões. As fases do ciclo de vida representam, de forma abstrata, o esqueleto do processo, que pode ser chamado de modelo de ciclo de vida. De maneira geral, esse modelo descreve a estrutura de organização de atividades do processo em fases e define como essas fases estão relacionadas. Entretanto, ele não descreve um curso de ações precisas, recursos, procedimentos e restrições. A escolha de um modelo é fortemente dependente das características do projeto. O ciclo de vida dos projetos pode estar predefinido no âmbito organizacional, ou seja, a organização pode preestabelecer que todos os projetos tenham o mesmo ciclo de vida. Pode-se, ainda, predefinir mais de um modelo de ciclo de vida para a organização. Nesse caso, para cada projeto, será selecionado aquele que melhor atender às suas características. A

56 56 determinação das fases do ciclo de vida do projeto possibilita períodos planejados de avaliação e de tomada de decisões, nos quais compromissos significativos são realizados com relação aos recursos, abordagem técnica, reavaliação de escopo e custo do projeto. GPR4 - (Até o nível F) O esforço e o custo para a execução das tarefas e dos produtos de trabalho são estimados com base em dados históricos ou referências técnicas: as estimativas de esforço e custo são, normalmente, baseadas nos resultados de análises, utilizando modelos e/ou dados históricos aplicados ao tamanho, atividades e outros parâmetros de planejamento. É importante destacar que dados históricos incluem os dados de custo, esforço e tempo de projetos executados anteriormente, além de dados apropriados de escala para equilibrar as diferenças de tamanho e complexidade. As estimativas de esforço e custo tipicamente consideram: o escopo, produtos de trabalho e as tarefas estimadas para o projeto; os riscos; as mudanças já previstas; o ciclo de vida escolhido para o projeto; viagens previstas; nível de competência da equipe do projeto, dentre outros. Normalmente, as estimativas do escopo, produtos de trabalho e as tarefas estimadas para o projeto são afetadas pelos parâmetros de produtividade, resultando nas estimativas de esforço e custo. Os parâmetros de produtividade são baseados em dados históricos e devem ser periodicamente calibrados. Os parâmetros de produtividade podem ter valores diversos, conforme fatores como tecnologia adotada, experiência do profissional, grau de ineditismo do serviço para a organização ou para os profissionais alocados. Empresas implementando o nível G do MR-MPS, geralmente, não possuem bases de dados históricas. Entretanto, para alcançar níveis superiores de maturidade, é preciso que essa base seja construída e os dados obtidos pelos projetos executados, mesmo no nível G, são fortes candidatos a alimentá-la. GPR5 - O orçamento e o cronograma do projeto, incluindo a definição de marcos e pontos de controle, são estabelecidos e mantidos: as dependências entre tarefas são estabelecidas e potenciais gargalos são identificados utilizando métodos apropriados (por exemplo, análise de caminho crítico). Os gargalos são resolvidos quando possível e o cronograma das atividades com início, duração e término é estabelecido. Recursos requeridos são refletidos nos custos estimados. Uma forma de se definir o cronograma é utilizando a EAP e as estimativas de esforço e custo (GPR4), considerando as dependências entre as tarefas e os marcos e pontos de controle eventos que são considerados significativos no

57 57 âmbito do projeto. É importante ter-se o cuidado de manter a coerência entre ciclo de vida, EAP, estimativas e cronogramas. O orçamento do projeto é estabelecido com base no cronograma e na estimativa de custos. Esse resultado é importante porque o cronograma e o orçamento são instrumentos fundamentais para o acompanhamento do dia a dia do projeto. Dessa forma, sempre que necessário, devem ser revistos e atualizados. GPR6 - Os riscos do projeto são identificados e o seu impacto, probabilidade de ocorrência e prioridade de tratamento são determinados e documentados: projetos têm riscos e eles precisam ser identificados, analisados e priorizados. Para facilitar a identificação dos riscos, é interessante elaborar uma lista de riscos mais comuns a ser examinada pelo gerente do projeto e/ou equipe do projeto para identificar quais desses são potenciais riscos para o projeto em questão. A análise da probabilidade de ocorrência e da gravidade dos problemas decorrentes de sua ocorrência ajuda a definir a prioridade dos riscos. Os riscos identificados devem ser registrados, bem como o acompanhamento dos seus estados e ações tomadas. Uma planilha de riscos, contendo dados como identificador, descrição, probabilidade, impacto e prioridades no seu tratamento, pode ser utilizada para identificação dos riscos, monitoração dos riscos identificados e atualização da lista de riscos do projeto à medida que novos riscos forem sendo identificados. É importante demonstrar que essa planilha está sendo monitorada e atualizada. Esse resultado não significa o Gerenciamento de Riscos, ou seja, a identificação, o gerenciamento e a redução contínua dos riscos nos níveis organizacionais e de projeto, que são tratados pelo processo Gerência de Riscos (GRI). No nível G, os riscos são acompanhados para verificar como afetam o projeto e para se tomar ações, mesmo que ainda sem um gerenciamento completo (previsto a partir do nível C do MPS pela incorporação do processo Gerência de Riscos). GPR7 - Os recursos humanos para o projeto são planejados considerando o perfil e o conhecimento necessários para executá-lo: o planejamento de recursos humanos determina funções, responsabilidades e relações hierárquicas do projeto. As funções do projeto podem ser designadas para pessoas ou grupos, os quais podem ser internos ou externos à organização. O planejamento de recursos humanos inclui informações de como e quando o recurso será envolvido no projeto, critérios para sua liberação, competência necessária para a execução das atividades, mapa de competências da equipe e identificação de necessidades de

58 58 treinamento. A existência de registros das necessidades e disponibilidade evita a alocação com base em critérios subjetivos. Este resultado esperado possui dois pontos principais: (i) planejamento prévio das necessidades de pessoal em relação a competências (conhecimento, habilidades, atitudes e experiências) para que as tarefas previstas no decorrer do projeto possam ser executadas de forma adequada e de acordo com a responsabilidade esperada; (ii) a alocação dos recursos humanos ao projeto de acordo com o planejamento realizado. Dessa forma, esse resultado implica que o planejamento da alocação de recursos humanos com base na análise de suas competências possuídas e requeridas para desempenhar as tarefas no projeto. GPR8 - (Até o nível F) - Os recursos e o ambiente de trabalho necessários para executar o projeto são planejados: esse resultado faz referência à necessidade de se planejar, com base na EAP (ou estrutura equivalente), as tarefas e previstos os recursos e o ambiente necessários, incluindo, por exemplo, equipamentos, ferramentas, serviços, componentes, viagens e requisitos de processo (processos especiais para o projeto). Os recursos humanos, incluindo treinamentos, são tratados pelo GPR7. Todos os recursos precisam ser explicitamente planejados, mesmo os já considerados como existentes e disponíveis ou que serão compartilhados com outros projetos, uma vez que se trata da sua alocação para uso. Esses itens podem, por exemplo, estar registrados no plano do projeto. Caso não haja necessidade de nenhum recurso a ser adquirido para o projeto deve-se registrar o fato de que a questão foi examinada. Esse resultado é importante porque recursos especiais precisam de orçamento e planejamento de sua aquisição, o que pode se tornar crítico em alguns projetos. GPR9 - Os dados relevantes do projeto são identificados e planejados quanto à forma de coleta, armazenamento e distribuição. Um mecanismo é estabelecido para acessálos, incluindo, se pertinente, questões de privacidade e segurança: os dados do projeto são as várias formas de documentação exigidas para sua execução, por exemplo: relatórios; dados informais; estudos e análises; atas de reuniões; documentação; lições aprendidas; artefatos gerados; itens de ação; e indicadores. Os dados podem estar em qualquer formato e existir em qualquer meio, como: impressos ou desenhados em diversos materiais; fotografias; meio eletrônico e multimídia. Alguns dados podem ser disponibilizados aos clientes, enquanto outros não necessariamente o serão. A distribuição pode ocorrer de várias formas, incluindo a transmissão eletrônica. A identificação, coleta, armazenamento, distribuição (incluindo regras de segurança e confidencialidade) para garantir a integridade, acesso e segurança aos dados

59 59 devem ser planejados. É importante identificar os dados relevantes do projeto para, depois, coletá-los, armazená-los e distribuí-los de forma controlada, lembrando que isso implica custo. Dessa forma, os dados devem ser coletados somente quando forem necessários. A confidencialidade das informações, mesmo quando não declarada pelo cliente, pode ter que ser tratada com cuidado. É recomendável, portanto, explicitar a existência ou não de dados confidenciais. Se a organização tem um critério padrão para execução dessas atividades, isso deve ser registrado no plano do projeto ou em outro documento. GPR10 - Um plano geral para a execução do projeto é estabelecido com a integração de planos específicos: o objetivo desse resultado esperado é garantir que todos os planos que afetam o projeto estejam integrados e que a dependência entre esses planos tenha sido identificada e levada em consideração durante o planejamento, conciliando o trabalho a ser realizado aos recursos e condições existentes. A realização do planejamento do projeto é garantida pelos resultados esperados no escopo do nível G do MR-MPS do processo Gerência de Projetos (GPR), que prevê, dentre outros, a criação do cronograma de atividades, o planejamento de recursos humanos, custos, riscos, dados etc. A reunião desses documentos é entendida como sendo o Plano de Projeto. As tarefas do processo definido para o projeto podem, também, fazer parte deste Plano do Projeto. Essa integração entre os planos pode acontecer de várias formas, entre elas: cronograma gerado com base nas atividades previstas para o projeto; plano de custos derivado do custo de cada profissional contemplado no plano de recursos humanos; plano de treinamentos derivado das tarefas a serem realizadas no projeto e das habilidades e competências dos colaboradores, conforme o plano de recursos humanos. É importante existir um alinhamento entre o que foi estimado, o que está sendo planejado e o que será acompanhado. A utilização de uma mesma referência propicia maior visibilidade ao projeto, facilitando, em muito, não só o seu gerenciamento, mas também a formação de uma base histórica. Essa base histórica dá visibilidade ao projeto, facilitando, em muito, não só o seu gerenciamento, mas também a formação de uma base histórica. Essa base histórica poderá beneficiar a organização em etapas posteriores de melhoria. O monitoramento efetivo do projeto dependerá de uma organização adequada dessas informações de planejamento. Ao longo do projeto, elas deverão ser comparadas aos dados obtidos durante sua execução, em busca de uma maior visibilidade do andamento do projeto. Quando necessário, o planejamento deverá ser revisto.

60 60 GPR11 - A viabilidade de atingir as metas do projeto é explicitamente avaliada, considerando restrições e recursos disponíveis. Se necessário, ajustes são realizados: o estudo de viabilidade considera o escopo do projeto e examina aspectos técnicos (requisitos e recursos), financeiros (capacidade da organização) e humanos (disponibilidade de pessoas com a capacitação necessária). Pode-se considerar, também, os objetivos de negócio e a composição do portfólio de projetos da organização. Muitas vezes, é preferível não iniciar ou parar um projeto já iniciado do que prosseguir com um projeto inviável, que pode implicar perdas maiores, tanto para o fornecedor como para o cliente. No início do projeto, uma avaliação preliminar pode ser conduzida, a partir da visão geral dos objetivos e características dos resultados pretendidos, dos recursos financeiros, técnicos e humanos, bem como de restrições impostas pelo cliente, ambiente externo e interno, além de condições para o desenvolvimento. À medida que o projeto evolui, a viabilidade de sucesso pode ser reavaliada com mais precisão. As mudanças de requisitos são eventos que podem levar à necessidade de reavaliar a viabilidade do projeto. De qualquer forma, a viabilidade do projeto deve ser avaliada de forma explícita. Muitas vezes, essa avaliação é feita de forma subjetiva ou automática, o que pode aumentar os riscos da organização em relação ao projeto sendo executado. Em marcos do projeto e mesmo durante as atividades de acompanhamento, pode ser necessária a confirmação da viabilidade de continuidade do projeto. GPR12 - O Plano do Projeto é revisado com todos os interessados e o compromisso com ele é obtido e mantido: para obter compromissos dos interessados relevantes, é importante revisar o planejamento com eles e conciliar as diferenças existentes entre os recursos estimados e disponíveis. Negociações devem ser realizadas, quando existirem conflitos entre as diversas variáveis do projeto, como requisitos, custos e prazos. Por exemplo: o escopo pode sofrer redução para que as metas de prazos e custos sejam cumpridas ou, ao contrário, aumenta-se o orçamento do projeto para que os requisitos sejam atendidos na íntegra, dentro da meta de prazo. Obter o compromisso pode envolver a interação entre todos os interessados relevantes internos e externos ao projeto. Os indivíduos ou grupos que se comprometem deverão ter a confiança de que o trabalho pode ser executado dentro das restrições de custo, cronograma e desempenho. Ao longo do projeto, de acordo com a dinâmica de sua execução, novos interessados podem ser identificados e compromissos anteriormente obtidos podem precisar ser modificados ou revistos. Dessa forma, é necessário verificar se os compromissos assumidos pelas partes interessadas estão sendo cumpridos ou negociados, sejam eles internos

61 61 ou externos, visando a identificar aqueles que não foram satisfeitos ou que possuem um grande risco de não serem satisfeitos. GPR13 - O escopo, as tarefas, as estimativas, o orçamento e o cronograma do projeto são monitorados em relação ao planejado: a aderência aos diversos planos deve ser avaliada continuamente durante todo o ciclo de vida do projeto. Os resultados e os critérios de conclusão de cada tarefa são analisados, as entregas são avaliadas em relação às suas características (por meio de revisões e auditorias, por exemplo), a aderência ao cronograma e o dispêndio de esforços são examinados, bem como o uso dos recursos. Essa é uma atividade essencial de gerenciamento: acompanhar o que foi planejado, detectar problemas e corrigi-los. O objetivo desse resultado esperado é assegurar que haja monitoração do projeto em relação a aspectos relacionados às tarefas, estimativas, orçamento e cronograma. Em geral, durante um monitoramento, faz-se uma análise do que foi planejado anteriormente com os valores atuais das variáveis consideradas. Por exemplo, o conjunto de tarefas planejadas inicialmente pode sofrer alterações ao longo da execução do projeto; estimativas precisam ser adequadas em decorrência de alterações no escopo do projeto em termos de tarefas e/ou trabalho previsto, adequações de fatores de ajuste de produtividade etc.; o orçamento do projeto pode sofrer alterações em decorrência dos valores reais dos custos diretos e indiretos do projeto; parte das atividades presentes no cronograma do projeto pode estar atrasada ou adiantada. O acompanhamento pode ser realizado, utilizando-se ferramentas de planejamento, em que se pode examinar o previsto contra o realizado, usando-se indicadores de progresso e cumprimento de marcos, entre outros. O acompanhamento também pode ser feito por meio de reuniões e comunicação pessoal. Contudo, é importante ressaltar que devem existir registros desses acompanhamentos. GPR14 - Os recursos materiais e humanos bem como os dados relevantes do projeto são monitorados em relação ao planejado: o objetivo desse resultado esperado é garantir que o projeto seja monitorado em relação aos itens planejados referentes a recursos materiais e recursos humanos. Em geral, durante um monitoramento, faz-se uma análise do que foi planejado anteriormente com os valores atuais das variáveis consideradas. Por exemplo, a saída de um membro da equipe pode disparar a alocação de uma nova pessoa ou, até mesmo, a contratação de um novo funcionário na organização. Da mesma forma, pode ser necessário alocar um novo membro da equipe devido à identificação de um novo perfil ou competência para conclusão de uma tarefa. Da mesma forma, pode ser necessária a compra de novos equipamentos ou softwares ao longo da execução do projeto. Outro ponto a ser

62 62 considerado é identificar se novos documentos devem ser incluídos no repositório do projeto ou se os produtos de trabalho intermediários do projeto estão de fato sendo produzidos e armazenados adequadamente. GPR15 - Os riscos são monitorados em relação ao planejado: no decorrer do projeto novos riscos podem ser identificados para o projeto e os parâmetros dos riscos já identificados podem ser alterados. Além disso, pode ser necessário executar ações de mitigação para evitar que os riscos aconteçam ou, no caso de riscos terem se concretizado, pode ser preciso executar ações de contingência para minimizar seus efeitos. Também é importante que a lista de riscos seja reavaliada periodicamente em conjunto com uma avaliação dos seus parâmetros de análise (probabilidade e impacto) e prioridade. Alterações realizadas no planejamento de riscos devem ser comunicadas aos interessados conforme pertinente. GPR16 - O envolvimento das partes interessadas no projeto é planejado, monitorado e mantido: devem ser identificados os interessados relevantes no projeto, em que fases eles são importantes e como eles serão envolvidos (comunicações, revisões em marcos de projeto, comprometimentos, entre outros). Uma vez identificado e planejado o envolvimento, esse deverá ser seguido, monitorado e mantido ao longo de todo o projeto. Os interessados no projeto podem incluir os clientes e os usuários (ou seus representantes), a direção da organização e os membros da equipe do projeto. Em projetos pequenos, essas atividades podem ser simplificadas devido ao pequeno número de interessados e a pouca comunicação necessária em função do curto prazo. GPR17 - Revisões são realizadas em marcos do projeto e conforme estabelecido no planejamento: revisões em marcos do projeto não devem ser confundidas com o acompanhamento descrito em GPR13, GPR14 e GPR15, que é derivado do acompanhamento do dia a dia do projeto. Os marcos do projeto precisam, assim, ser previamente definidos ao se realizar o planejamento do projeto. Esse resultado é importante porque as revisões em marcos são oportunidades para verificar, de forma ampla, o andamento de todo o projeto, independente do acompanhamento do dia a dia. Em projetos grandes essas revisões são fundamentais, questionando, inclusive, a viabilidade de continuidade do projeto. GPR18 - Registros de problemas identificados e o resultado da análise de questões pertinentes, incluindo dependências críticas, são estabelecidos e tratados com as partes interessadas: as atividades de revisão em marcos (GPR17) e de monitoramento (GPR13, GPR14 e GPR15) do projeto possibilitam a identificação de problemas que estejam

63 63 ocorrendo nos projetos. É natural que problemas e desvios em relação ao planejamento aconteçam durante a execução dos projetos. Esses problemas e desvios devem ser analisados e registrados, por exemplo, por meio de ferramentas específicas, planilhas ou outros tipos de mecanismos de gerenciamento de problemas. A falha na execução dessa tarefa pode afetar a habilidade de executar ações para correção dos desvios, afetando o bom andamento do projeto. GPR19 - Ações para corrigir desvios em relação ao planejado e para prevenir a repetição dos problemas identificados são estabelecidas, implementadas e acompanhadas até a sua conclusão: como resultado do acompanhamento do projeto (GPR13, GPR14 e GPR15) e das revisões em marcos (GPR17), problemas são identificados, analisados e registrados (GPR18). Ações corretivas devem ser estabelecidas para resolver problemas que possam impedir o projeto de atingir seus objetivo,s se não forem resolvidos de forma adequada. As ações corretivas definidas devem ser gerenciadas até serem concluídas. O controle dos problemas levantados, as ações tomadas, os responsáveis pelas ações e os resultados devem ser registrados. Os problemas identificados e, devidamente, registrados, provêem a base para a tomada de ações corretivas. Quando apropriado e, quando o impacto e os riscos associados são identificados e gerenciados, as mudanças podem ser realizadas no projeto. Essas mudanças podem tomar a forma de ações corretivas, podem envolver a incorporação de contingências para que ocorrências similares sejam evitadas e/ou encadear a revisão de vários planos e documentos relacionados para acomodar os problemas inesperados e suas implicações. Acompanhar o andamento de uma ação corretiva até sua conclusão inclui verificar, com uma certa frequência, se ela já foi resolvida e atuar em possíveis pendências. Caso não se consiga resolver nesse nível, deve-se escalonar a resolução das ações a níveis superiores de gerência. As ações corretivas estabelecidas podem ser reportadas para a gerência de alto nível da organização e para os interessados no projeto, como clientes e usuários.

64 GERÊNCIA DE REQUISITOS O principal objetivo da Gerência de Requisitos, conforme A SOFTEX, é controlar a evolução dos requisitos. O processo Gerência de Requisitos (GRE) gerencia todos os requisitos recebidos ou gerados pelo projeto, incluindo requisitos funcionais e não-funcionais, bem como os requisitos impostos ao projeto pela organização. Para assegurar que o conjunto de requisitos acordados é gerenciado e fornecer apoio às necessidades de planejamento e execução do projeto, SOFTEX (2012) afirma que a organização deve executar um conjunto de passos definidos e apropriados. Quando um projeto recebe requisitos de um fornecedor de requisitos pessoa autorizada a participar de sua definição e a solicitar modificação, estes devem ser revisados para resolver questões e prevenir o mau entendimento, antes que os requisitos sejam incorporados ao escopo do projeto. Quando o fornecedor de requisitos e a organização chegam a um acordo, é obtido um compromisso das demais partes interessadas sobre os requisitos. Outras atribuições do processo Gerência de Requisitos são documentar as mudanças nos requisitos e suas justificativas, bem como manter a rastreabilidade bidirecional entre os requisitos e produtos de trabalho em geral e identificar inconsistências entre os requisitos, os planos do projeto e os produtos de trabalho do projeto. De acordo com a SOFTEX (2011), os resultados, esperados do nível G para a gerência de requisitos, serão listados abaixo: GRE1 - O entendimento dos requisitos é obtido junto aos fornecedores de requisitos: o objetivo desse resultado é garantir que os requisitos estejam claramente definidos a partir do entendimento dos requisitos realizado junto aos fornecedores de requisitos. Informações sobre esses fornecedores podem ser identificadas no plano do projeto, bem como informações sobre de como será a comunicação com eles. Essas comunicações devem ser registradas formalmente em atas, s, ferramentas de comunicação ou outros meios. Como comprovação do entendimento, os requisitos devem ser documentados. Essa documentação pode assumir diferentes formas de acordo com as necessidades da organização, por exemplo, uma lista de requisitos, especificações de casos de uso, especificações de estórias, ou ainda detalhados, conforme uma metodologia própria da organização.

65 65 Após a identificação dos requisitos do produto e dos componentes do produto do projeto, é importante garantir que os requisitos propostos atendam às necessidades e expectativas do cliente e dos usuários. Após a avaliação dos requisitos, um registro de aceite dos requisitos deve ser obtido pelos fornecedores de requisitos. Esse registro pode ser tratado como um marco do projeto a partir do qual mudanças nos requisitos devem ser tratadas formalmente para minimizar o impacto dessas mudanças no projeto em termos de escopo, estimativas e cronograma, bem como compromissos já estabelecidos. Sempre que forem aprovadas mudanças nos requisitos, deve-se obter novas aprovações dos requisitos do projeto, se possível, a partir de critérios estabelecidos. GRE2 - Os requisitos são avaliados com base em critérios objetivos e um comprometimento da equipe técnica com esses requisitos é obtido: a avaliação e aprovação por parte do cliente após o entendimento dos requisitos por si só não é suficiente para que os requisitos sejam refinados e refletidos em modelos de análise e projeto para a codificação. A avaliação dos requisitos deve envolver, além do cliente, também, a equipe técnica da organização, podendo ser realizada de diversas formas. Além disso, um comprometimento formal da equipe técnica com os requisitos deve ser obtido e registrado, por exemplo, na forma de ata de reunião, ou algum outro mecanismo. Em geral, é aconselhável que os requisitos sejam avaliados pela equipe técnica antes de serem submetidos para aprovação pelo cliente para evitar retrabalho ou a apresentação de um documento sem qualidade técnica adequada para o cliente. GRE3 - A rastreabilidade bidirecional entre os requisitos e os produtos de trabalho é estabelecida e mantida: esse resultado indica a necessidade de se estabelecer um mecanismo que permita rastrear a dependência entre os requisitos e os produtos de trabalho. Ter definida a rastreabilidade facilita a avaliação do impacto das mudanças de requisitos que possam ocorrer, por exemplo, nas estimativas do escopo, nos produtos de trabalho ou nas tarefas do projeto descritas no cronograma. Ao longo do projeto, os requisitos assumem diferentes abstrações e denominações. Por exemplo, podem estar descritos na forma de necessidades e restrições do cliente, requisitos de cliente, requisitos funcionais e não funcionais, casos de uso, requisitos técnicos, requisitos de produto, estórias etc. Os requisitos, dentro do ciclo de vida do projeto, são posteriormente derivados em elementos de análise e projeto (design) e, então, transformados em código fonte para, então, serem testados (preferencialmente com base em casos de testes específicos).

66 66 GRE4 - Revisões em planos e produtos de trabalho do projeto são realizadas visando a identificar e a corrigir inconsistências em relação aos requisitos: consistência entre os requisitos e os produtos de trabalho do projeto deve ser avaliada e os problemas identificados devem ser corrigidos. Esse resultado sugere, portanto, a realização de revisões ou de algum mecanismo equivalente para identificar inconsistências entre os requisitos e os demais elementos do projeto como, por exemplo, planos, atividades e produtos de trabalho. As inconsistências identificadas devem ser registradas e ações corretivas executadas a fim de resolvê-las. Exemplos de revisões com esse objetivo são revisões de monitoração e controle do projeto e inspeções baseadas em critérios explícitos para identificar inconsistências entre os planos, atividades e produtos de trabalho com os requisitos e com mudanças nesses requisitos. Quando há mudanças nos requisitos, é importante examinar se os demais artefatos estão consistentes com as alterações realizadas como, por exemplo: verificar se a planilha de estimativas está contemplando todos os requisitos e mudanças; verificar se as mudanças dos requisitos foram incorporadas ao escopo ou cronograma do projeto e outros. As ações para correções das inconsistências devem ser acompanhadas até que sejam resolvidas. GRE5 - Mudanças nos requisitos são gerenciadas ao longo do projeto: durante o projeto, os requisitos podem mudar por uma série de motivos. Dessa forma, requisitos adicionais podem ser incorporados no projeto, requisitos podem ser retirados do projeto e/ou mudanças podem ser feitas nos requisitos já existentes. Ressalta-se que, devido às mudanças, os requisitos podem ter que ser revistos, conforme definido no GRE4. As necessidades de mudanças devem ser registradas e um histórico das decisões acerca dos requisitos deve estar disponível. Essas decisões são tomadas por meio da realização de análises de impacto da mudança no projeto e podem incluir aspectos como: influência em outros requisitos, expectativa dos interessados, esforço, cronograma, riscos e custo. É importante destacar que o mecanismo de rastreabilidade bidirecional instituído é um importante mecanismo para facilitar a análise de impacto. Muitas vezes, mudanças nos projetos acontecem em diferentes níveis de abstração dos requisitos, não apenas nos requisitos de cliente. Por exemplo, mudanças, em casos de uso ou que afetem protótipos de telas, podem precisar ser gerenciadas, utilizando um mecanismo mais formal de controle de mudança. Dessa forma, é indicado que a organização determine a aplicabilidade da gerência de mudança, conforme descrito nesse resultado esperado.

67 CONSIDERAÇÕES FINAIS Este capítulo apresentou um levantamento da literatura sobre a teoria que embasa o presente trabalho. Os conceitos de engenharia de software, processo de software e seus modelos. Além de ciclos de vida de um software, que englobam modelos tradicionais e ágeis (Scrum e Kanban). Também foram levantados conceitos de MPS.BR e seus níveis de maturidade, gerência de projetos e gerência de requisitos. A seguir é apresentado o método desta pesquisa.

68 68 3. MÉTODO Este capítulo descreve o tipo de pesquisa utilizada, a proposta da solução e as delimitações do trabalho. O cronograma do projeto encontra-se no apêndice A. 3.1 CARACTERIZAÇÃO DO TIPO DE PESQUISA Segundo Rodrigues (2012), em uma pesquisa aplicada, os conhecimentos adquiridos são utilizados para uma aplicação prática, voltados para a solução de problemas concretos da vida moderna e têm como objetivo investigar, comprovar ou rejeitar hipóteses sugeridas pelos modelos teóricos. O presente trabalho é uma pesquisa aplicada, pois pretende resolver a problemática da empresa estudo de caso com respeito ao seu processo de desenvolvimento de software. Segundo Neves (1996), a pesquisa qualitativa costuma ser direcionada, ao longo de seu desenvolvimento, além disso, não busca enumerar ou medir eventos e, geralmente, não emprega ferramentas estatísticas para analise de dados. Dela faz parte a obtenção de dados descritivos mediante contato direto e interativo do pesquisador com a situação objeto de estudo. Assim, esse trabalho pode ser caracterizado como uma pesquisa qualitativa. Um estudo de caso pode ser caracterizado como: Um estudo de uma entidade bem definida como um programa, uma instituição, um sistema educativo, uma pessoa, ou uma unidade social. Visa conhecer em profundidade o como e o porque de uma determinada situação que profundidade o como e o porque de uma determinada situação que supõe ser única em muitos aspectos, procurando descobrir o que há nela de mais essencial e característico. O pesquisador não pretende intervir sobre o objeto a ser estudado, mas revela-lo tal como ele o percebe. O estudo de caso pode decorrer de acordo com uma perspectiva interpretativa, que procura compreender como é o mundo do ponto de vista dos participantes, ou uma perspectiva pragmatica, que visa simplesmente apresentar uma perpectiva global, tanto quanto possivel completa e coerente, do objeto de estudo do ponto de vista do investigador. (FONSECA, 2002, P.33, apud GERHARDT e SILVEIRA, 2009).

69 69 Este trabalho pode ser caracterizado como um estudo de caso. De acordo com as autoras Marconi e Lakatos (2003), a pesquisa exploratória ou pré-leitura é uma leitura de sondagem, tendo em vista localizar as informações, uma vez que já se tem conhecimento de sua existência. Parte-se do princípio de que um capítulo ou tópico trata de assunto que nos interessa, mas pode omitir o aspecto relacionado diretamente com o problema que nos preocupa. A pesquisa bibliográfica é elaborada a partir de material já publicado, constituído principalmente de: livros, revistas, publicações em periódicos e artigos científicos, jornais, boletins, monografias, dissertações, teses, material cartográfico, internet, com o objetivo de colocar o pesquisador em contato direto com todo material já escrito sobre o assunto da pesquisa. Em relação aos dados coletados na internet, devemos atentar à confiabilidade e fidelidade das fontes consultadas eletronicamente. Na pesquisa bibliográfica, é importante que o pesquisador verifique a veracidade dos dados obtidos, observando as possíveis incoerências ou contradições que as obras possam apresentar. (PRODANOV e FREITAS, 2013). Uma das etapas deste trabalho consiste na pesquisa bibliográfica sobre as teorias que sustentam o estudo de caso.

70 ETAPAS A metodologia de pesquisa apresenta as etapas de desenvolvimento do projeto, demonstrada pela figura 10. Figura 10 Etapas do Desenvolvimento. Fonte: Elaborado pelos autores, A empresa estudo de caso nasceu com dois sócios, sem espaço físico, desenvolvendo software sob demanda. Após sete anos, a empresa sente a necessidade de definir um processo de desenvolvimento de software para qualificar seus processos e produtos resultantes, seguindo as diretrizes do modelo MPSBR. O presente trabalho elabora uma proposta de adequação de modelos ágeis para a empresa atingir o nível G do MPSBR, para isso foram definidas as etapas mostradas na Figura 10. As etapas metodológicas são iniciadas na definição da empresa estudo de caso. Posteriormente, serão identificados, os processos relacionados com o desenvolvimento de

71 71 software. Em seguida, serão definidos quais processos vão ser analisados e estudados para aplicação no trabalho. Após a análise dos processos da empresa, será realizado um estudo sobre os modelos ágeis SCRUM e KANBAN para adaptação junto à empresa estudo de caso. Em seguida, irá ser feito uma verificação dos resultados esperados para atingir o nível G do MPS.BR. De acordo com as pesquisas realizadas para identificar os processos do nível G, será realizado uma analise baseado nos métodos de avaliação do MPS.BR para identificar o nível G e os processos existentes na empresa. Caso a empresa possa ser enquadrada em um nível superior ao nível G, será feita uma verificação para adequação a algum nível superior ao apresentado. Na sequência, será feita uma análise para verificar quais processos existentes nos modelos SCRUM e KANBAN serão utilizados para auxiliar que a empresa possa alcançar o nível G do MPS.BR. Para concluir as etapas do trabalho, serão apresentadas as recomendações para adequação ao nível G do MPS.BR para a empresa, em paralelo serão feitas as validações desse modelo junto a equipe da empresa. 3.3 DESENHO DA SOLUÇÃO DE DESENVOLVIMENTO DE SOFTWARE O Objetivo deste trabalho é apresentar uma proposta de implantação de um modelo ágil a fim de que a empresa atinja o nível G do MPS.BR. Dessa forma, será apresentada a proposta à empresa, tendo em vista que ela terá de passar por uma validação e reformulação. A solução é ilustrada na figura 11.

72 72 Figura 11 Desenho da Solução Fonte: Elaborado pelo autor, No MPSBR, a escala de maturidade inicia-se no nível G e avança até o nível A, como já descrito anteriormente. Cada nível descrito apresenta processos que devem ser realizados nesse nível e seus correspondentes Atributos do Processo (AP), tendo em vista a organização da empresa. O nível G engloba os processos de gerência de projetos e requisitos e os AP 1.1 e AP 2.1, isto é, esses processos são executados (AP 1.1) e gerenciados (AP 2.1). O foco do projeto é propor recomendações e artefatos que permitam a adaptação da empresa SOFTPC ao nível G do modelo MPS.BR.

73 73 Para que essa recomendação se torne possível, será estudada a utilização das metodologias ágeis SCRUM e KANBAN, que podem ser definidas como os facilitadores, para que se possa alcançar o objetivo que é o nível G do MPS.BR. Em paralelo, será promovido um melhor entendimento por parte da empresa e de seus colaboradores sobre de como atingir os resultados exigidos para a certificação do nível G do MPS.BR. 3.4 DELIMITAÇÕES O resultado deste trabalho será uma proposta de melhoria nos processos de desenvolvimento de software da empresa, visando a atingir o nível G do MPS.BR. Em paralelo, a empresa poderá utilizar os conceitos de metodologias ágeis Scrum e Kanban. No entanto, o uso das recomendações e os resultados obtidos, a partir da proposta gerada, podem chegar a ser utilizadas em etapas futuras. Isso vai depender se a empresa estudo de caso irá se adequar aos conceitos propostos. Este trabalho não irá fazer uma verificação da melhoria dos processos da empresa, através da utilização da proposta aqui gerada.

74 74 4. DESENVOLVIMENTO Neste capítulo, é apresentada a descrição da empresa estudo de caso, do seu processo de desenvolvimento, análise do mesmo processo e recomendações para atingir o nível G do MPS.BR, usando práticas das metodologias ágeis propostas. 4.1 DESCRIÇÃO DA EMPRESA A empresa estudo de caso nasceu com dois sócios, inicialmente não havia muita preocupação com a documentação dos projetos que eram desenvolvidos, e sim com atender as necessidades dos clientes e poder crescer de forma sustentável. Dessa forma não havia regras para levantamento de requisitos e documentação de casos de uso. Os sócios simplesmente vão ao cliente e trazem consigo as idéias de como será implementada a solução. Visando atingir cada vez mais clientes, não há demasiado tempo para se preocupar com melhorias em processo de desenvolvimento. Com o passar do tempo, por volta de quatro anos de existência, a empresa soma à sua equipe mais um sócio e registra sua marca. Começa, então, a surgir mais demanda de trabalho e há a necessidade de contratação de mais recursos. Três programadores começam a fazer parte da equipe, e um dos sócios fundadores vende a sua parte. Atualmente, com sete anos de existência, a empresa possui ao todo cinco colaboradores. Ela determinou desenvolver soluções voltadas para a área de gestão e processo, na qual tem clientes nos setores públicos e privados. Com o avanço de suas tecnologias e aquisição de novos clientes, surge a necessidade de melhorar a qualidade do seu processo de desenvolvimento. Decide-se, assim, realizar uma análise desse processo através do presente trabalho: há necessidade de se verificar os problemas e os pontos que não atendem às questões básicas do MPS.BR quanto ao nível G. Uma das questões direcionadoras deste trabalho é: o quanto a empresa aplica às práticas de gerenciamento de projetos e gerenciamentos de requisitos. A seguir, é apresentado o processo de desenvolvimento da empresa.

75 DESCRIÇÃO DOS PROCESSOS DE DESENVOLVIMENTO DA EMPRESA Inicialmente, é apresentado o quadro funcional da empresa e seus respectivos papéis. A empresa possui dois analistas, que são os sócios, e três programadores. Desses três, um é estagiário e dois são contratados. A seguir, serão descritas as funções de cada profissional na empresa, bem como os processos de desenvolvimento, representados pelos diagramas Descrição do Processo do Analista Os Analistas, também sócios da empresas, geralmente se deslocam até o cliente e realizam a análise e levantamento de requisitos, além de criar um esboço de interfaces. Não é feito um registro formal desses requisitos, assim, eles decidem as ferramentas utilizadas e recursos necessários para que se definam os profissionais responsáveis pelo projeto. Estimam, também, tempo e valor. Os próprios analistas fazem protótipos de telas em ferramentas ilustrativas. Com isso, é apresentado ao cliente para que esse aprove. Após aprovação, os analistas passam aos programadores para estes codificarem telas, funções e definir banco de dados. Após os programadores finalizarem as tarefas, estas são retornadas aos analistas, que, também, participam do processo de desenvolvimento. Posteriormente, os analistas apresentam protótipos das telas ao cliente, e esse avalia se está de acordo com o esperado ou se precisa de alterações. Por fim, os analistas apresentam o software pronto ao cliente.

76 76 Figura 12 Papéis do analista Fonte: Elaborado pelo autor, Figura 13 Processo do Analista Fonte: Elaborado pelo autor, 2013.

77 Descrição do Processo do Programador O programador recebe requisitos e regras de negócio elaboradas pelo analista. O programador desenvolve o software e valida junto ao cliente os testes e possíveis correções. Ao decorrer da utilização do sistema, é realizado um acompanhamento, visando o bom desempenho da solução. Figura 14 Papéis do Programador Fonte: Elaborado pelo autor, 2013.

78 78 Figura 15 Processo do Programador Fonte: Elaborado pelo autor, Descrição do Processo do Cliente O cliente solicita a elaboração de um sistema que atenda suas necessidades. Para isso, ele avalia protótipos de telas junto ao analista. Caso haja necessidade de correções, o analista realiza essas alterações e valida novamente junto ao cliente. Se o cliente aprovar esses protótipos, o programador faz a codificação do sistema, o analista avalia e verifica se está correto e entrega o software ao cliente. Por fim, o cliente é quem realiza os testes e solicita correções.

79 79 Figura 16 Papéis do Cliente Fonte: Elaborado pelo autor, Figura 17 Processo do Cliente Fonte: Elaborado pelo autor, sistema. A seguir, é representado um macro processo com os papéis de cada ator do

80 80 Figura 18 Processos da empresa Fonte: Elaborado pelo autor, ANÁLISE DO PROCESSO CONSIDERANDO O MPS.BR A representação do nível G do MPS.BR, que engloba conceitos de gerência de projetos e gerência de requisitos e suas características, é demonstrado na Figura a seguir:

81 81 Figura 19 Representação do Nível G: Fonte: Elaborado pelos autores, Assim, na sequência será analisada a aderência dos processos da empresa, considerando cada um dos resultados esperados GERÊNCIA DE PROJETOS EXISTENTES NA EMPRESA Segue uma descrição de cada um dos resultados esperados e uma breve análise considerando se a empresa cumpre ou não essas recomendações. GPR 1: a organização tem artefatos que mostram o trabalho a ser realizado, mas com informações insuficientes para se definir projetos com uma estrutura adequada. Isso pode resultar em falhas de escopo.

82 82 GPR 2: as tarefas e os produtos de trabalho do projeto não são dimensionados de forma adequada, pois o analista não utiliza nenhuma ferramenta, os requisitos e controle dessa atividade também são parciais. GPR 3: não existe nenhum modelo de ciclo de vida utilizado pela empresa, ou nenhum processo de desenvolvimento definido. GPR 4: não há estimativas a partir de dados históricos pelo fato de a empresa estar há pouco tempo no mercado e de não armazenar esses dados. Porém, como referência técnica, utilizava dados do mercado de trabalho para estimar o valor da hora de um programador. GPR 5: a empresa não dispõe de qualquer cronograma de projeto ou orçamento. Quem define o cronograma, marcos, pontos de controle e orçamentos é somente o analista. Dessa forma, esse processo está sujeito a falhas. GPR 6: riscos do projeto, probabilidade de ocorrência de erros ou qualquer impacto negativo causador não são identificados. GPR 7: os recursos humanos para o projeto são planejados de acordo com o perfil necessário para a execução da atividade. GPR 8: As tarefas, recursos, ferramentas e o ambiente de trabalho são contemplados, planejados e adquiridos, se necessário e estão aptos a realizar as atividades necessárias. GPR 9: os dados relevantes do projeto são identificados, porém não de forma detalhada. GPR 10: um documento que detalha o andamento do projeto e valida o que está de acordo ou não não é elaborado pelo analista. Este relaciona as informações que devem fazer parte da solução. GPR 11: a viabilidade, para atingir as metas do projeto, são avaliadas, porém somente pelo analista. GPR 12: a revisão do plano do projeto não é feita por todos, somente pelo analista e cliente envolvido no projeto. GPR 13: como o plano do projeto não é feito da maneira adequada, o monitoramento e resultados não são documentados de forma completa. GPR 14: o envolvimento das partes interessadas é pouco gerenciado. GPR 15: os marcos do projeto são praticamente nulos e, por isso, não há como fazer revisões.

83 83 GPR 16: registros de problemas identificados e o resultado da análise de questões pertinentes são estabelecidos e tratados com as partes interessadas, mas podem sofrer algum tipo de mudança no decorrer do projeto. GPR 17: não são tratadas de forma adequada ações para corrigir desvios em relação ao planejado ou para prevenir a repetição dos problemas identificados. GPR 18: não existe planilhas ou outro tipo de ferramenta de gerenciamento de riscos, porém o monitoramento e documentação de resultados são feitos só que não de forma incompleta. Além disso, a pouco gerenciamento dos envolvidos no projeto e revisões são praticamente inexistentes. GPR 19: a verificação do andamento do projeto visando ações para correção é praticamente nula, da mesma maneira que a revisão documental. Além disso, a trativa entre as partes envolvidas é bastante simplificada, na qual o foco é a entrega do sistema e sua revisão fica em segundo plano. O quadro apresentado, na continuação, resume quais resultados são aplicados, total ou parcialmente, no processo de gerência de requisitos.

84 84 Quadro 3 Gerência de Projetos existentes na empresa: PROCESSO APLICA APLICA PARCIALMENTE GPR1 X GPR2 GPR3 GPR4 X GPR5 GPR6 GPR7 X GPR8 X GPR9 X GPR10 X GPR11 X GPR12 X GPR13 X GPR14 X GPR15 X GPR16 X GPR17 GPR18 X GPR19 X NÃO APLICA X X X X X Fonte: Elaborado pelos autores, GERÊNCIA DE REQUISITOS EXISTENTES NA EMPRESA A seguir, são descritos os resultados esperados da gerência de requisitos utilizados na empresa estudo de caso. GRE 1: o levantamentos de requisitos é feito junto ao cliente. GRE 2: existem métodos de aceitação do cliente para com a solução proposta GRE 3: não há documento que descreva a necessidade de origem do requisito, porém alguns requisitos sempre foram aplicados.

85 85 GRE 4: os planos e produtos de trabalho do projeto não são realizados visando a realizar e a corrigir as inconsistências. GRE 5: existem mudanças de requisitos que são apresentadas ao longo do projeto, só que não são gerenciadas de maneira completa. Quadro 4 Gerência de Requisitos existentes na empresa: PROCESSO APLICA APLICA PARCIALMENTE GRE 1 X GRE 2 X GRE 3 X GRE 4 GRE 5 NÃO APLICA X X Fonte: Elaborado pelos autores, CONSIDERAÇÕES FINAIS Com o levantamento realizado, notou-se que empresa possui diversos resultados esperados no grupo de processos de gerência de projetos e gerência de requisitos, porém muitos desses não foram alcançados, devido ao baixo grau de maturidade que a SoftPC, ainda, possui.

86 86 5. PROPOSTA DA SOLUÇÃO Neste capítulo, serão apresentadas as sugestões para adequação dos processos de gerência de projetos e gerência de requisitos, a fim de que a empresa alcance o nível G do MPS.BR. 5.1 RECOMENDAÇÕES PARA A APLICAÇÃO DOS PROCESSOS DE GERÊNCIA DE PROJETOS Os resultados para o Processo de Gerência de Projetos esperados são apresentados, a seguir, com uma descrição, segundo o referencial teórico: GPR 1: O escopo do trabalho para o projeto é definido: obter artefatos que demonstrem um escopo de forma mais detalhada, com objetivos mais claros e definindo as etapas do produto que será entregue ao cliente. Segundo Kniberg (2009), um plano de iteração é criado, isto é, a equipe puxa um número específico de itens do product backlog, baseado nas prioridades do Product Owner e considerando o quanto a equipe acha que pode completar em uma iteração. Ambos Scrum e Kanban são baseados no desenvolvimento incremental, isto é, quebrar o trabalho em pedaços menores. De uma forma, geral definir o melhor escopo para a sequência do projeto. GPR 2: As tarefas e os produtos de trabalho do projeto são dimensionados utilizando métodos apropriados: para que seja alcançado, é necessária a utilização de uma Estrutura Analítica de Processos (EAP), que, segundo PMBOK (2004), é uma decomposição hierárquica orientada à entrega do trabalho a ser executado pela equipe do projeto, para atingir os objetivos do projeto e criar as entregas necessárias. A EAP organiza e define o escopo total do projeto. A EAP subdivide o trabalho do projeto em partes menores e mais facilmente gerenciáveis, em que cada nível descendente da EAP representa uma definição cada vez mais detalhada do trabalho do projeto. É possível agendar, estimar custos, monitorar e controlar o trabalho planejado, contido nos componentes de nível mais baixo da EAP, denominados pacotes de trabalho.

87 87 GPR 3: O modelo e as fases do ciclo de vida do projeto são definidos: espera-se que empresa siga os ciclos de vida das metodologias ágeis, como Scrum ou Kanban. De acordo com Borges (2010), o termo modelo do ciclo de vida é utilizado para descrever um modelo que visa a descrever um grupo de atividades e a forma de como elas se relacionam. Os modelos mais sofisticados incluem, ainda, uma descrição de quando e de como se deve mover uma atividade para a próxima e os entregáveis que devem ser produzidos em cada etapa. A razão pela qual esses modelos são tão conhecidos é o fato de ajudarem as equipes de desenvolvimento e, em particular, os gestores a obter uma visão geral do projeto de forma a ser possível segui-lo passo a passo, saber quais entregáveis foram especificados, a alocação de recursos e os objetivos propostos. Esses "modelos de ciclo de vida" ou "modelos de processos" são tipicamente produzidos a partir de uma perspectiva de que poderão existir vários modelos para o mesmo processo. Nenhum modelo é capaz de dar uma visão completa de um determinado processo. GPR 4: O esforço e o custo para a execução das tarefas e dos produtos de trabalho são estimados com base em dados históricos ou referências técnicas: a empresa deve documentar o histórico realizado, a fim de que futuramente estime outros trabalhos. Para SOFTEX (2011), as estimativas de esforço e custo são, normalmente, baseadas nos resultados de análises, utilizando modelos e/ou dados históricos, aplicados ao tamanho, atividades e outros parâmetros de planejamento. É importante destacar que dados históricos incluem os dados de custo, esforço e tempo de projetos executados anteriormente, além de dados apropriados de escala para equilibrar as diferenças de tamanho e complexidade. As estimativas de esforço e custo tipicamente consideram: o escopo, produtos de trabalho e as tarefas estimadas para o projeto; os riscos; as mudanças já previstas; o ciclo de vida escolhido para o projeto; viagens previstas; nível de competência da equipe do projeto, dentre outros. Normalmente, as estimativas do escopo, produtos de trabalho e as tarefas estimadas para o projeto são afetadas pelos parâmetros de produtividade, resultando nas estimativas de esforço e custo. Os parâmetros de produtividade são baseados em dados históricos e devem ser periodicamente calibrados. Os parâmetros de produtividade podem ter valores diversos, conforme fatores como tecnologia adotada, experiência do profissional, grau de ineditismo do serviço para a organização ou para os profissionais alocados. Empresas implementando o nível G do MR-MPS, geralmente, não possuem bases de dados históricas. Entretanto, para alcançar níveis superiores de maturidade, é preciso que

88 88 essa base seja construída e os dados obtidos pelos projetos executados, mesmo no nível G, são fortes candidatos a alimentá-la. GPR 5: O orçamento e o cronograma do projeto, incluindo a definição de marcos e pontos de controle, são estabelecidos e mantidos: é necessário definir as atividades com início, duração e conclusão. Assim, deve-se estabelecer orçamento e cronograma para o projeto. Segundo Borges (2010), obtendo a visibilidade desejada, a gerência pode atuar de forma pontual no sentido de atingir os quatro grandes objetivos de um projeto de desenvolvimento de software, quais sejam, desenvolver software de alta qualidade, ter alta produtividade da equipe de desenvolvimento, cumprir o cronograma estabelecido junto ao cliente e não necessitar de recursos adicionais não previstos. Para ele, sem o gerenciamento de projeto, projetos de software podem facilmente sofrer atrasos ou estourar o orçamento. Como, grande número de projetos de software não atende suas expectativas, em termos de funcionalidades, custo, ou cronograma de entrega, ainda, não existe um modelo de processo perfeito para todas as aplicações. GPR 6: Os riscos do projeto são identificados e o seu impacto, probabilidade de ocorrência e prioridade de tratamento são determinados e documentados: riscos têm de ser identificados, tendo participação de toda a equipe envolvida no projeto. Os acompanhamentos dos riscos devem ser documentados, bem como as ações tomadas. Segundo PMBOK (2004), o registro de riscos contém informações sobre os riscos identificados do projeto que a equipe do projeto considera quando produz estimativas de durações das atividades e ajusta essas durações de acordo com os riscos. A equipe do projeto considera até que ponto os efeitos dos riscos estão incluídos na estimativa de duração da linha de base para cada atividade do cronograma, especialmente, os riscos com alta probabilidade ou alto impacto. GPR 9: Os dados relevantes do projeto são identificados e planejados quanto à forma de coleta, armazenamento e distribuição: identificar os dados relevantes do projeto e controle de acesso. Para a SOFTEX (2011), os dados do projeto são as várias formas de documentação exigidas para sua execução, por exemplo: relatórios; dados informais; estudos e análises; atas de reuniões; documentação; lições aprendidas; artefatos gerados; itens de ação; e indicadores. Os dados podem estar em qualquer formato e existir em qualquer meio, como: impressos ou desenhados em diversos materiais; fotografias; meio eletrônico e multimídia. Alguns dados podem ser disponibilizados aos clientes, enquanto outros não

89 89 necessariamente o serão. A distribuição pode ocorrer de várias formas, incluindo a transmissão eletrônica. A identificação, coleta, armazenamento, distribuição (incluindo regras de segurança e confidencialidade) para garantir a integridade, acesso e segurança aos dados devem ser planejados. É importante identificar os dados relevantes do projeto, para depois coletá-los, armazená-los e distribuí-los de forma controlada, lembrando que isso implica em custo. Desta forma, os dados devem ser coletados somente quando forem necessários. A confidencialidade das informações, mesmo quando não declarada pelo cliente, pode ter que ser tratada com cuidado. É recomendável, portanto, explicitar a existência ou não de dados confidenciais. Se a organização tem um critério padrão para execução dessas atividades, isto deve ser registrado no plano do projeto ou em outro documento (SOFTEX, 2011). GPR 10: Um plano geral para a execução do projeto é estabelecido com a integração de planos específicos. Para a SOFTEX (2011), o objetivo do resultado esperado é garantir que todos os planos que afetam o projeto estejam integrados e que a dependência entre esses planos tenham sido identificados e levados em consideração durante o planejamento, conciliando o trabalho a ser realizado aos recursos e condições existentes. A realização do planejamento do projeto é garantida pelos resultados esperados no escopo do nível G do MR-MPS do processo Gerência de Projetos (GPR), que prevê, dentre outros, a criação do cronograma de atividades, o planejamento de recursos humanos, custos, riscos, dados etc. A reunião desses documentos é entendida como sendo o Plano de Projeto. As tarefas do processo definido para o projeto podem, também, fazer parte desse Plano do Projeto. Esta integração entre os planos pode acontecer de várias formas, entre elas: cronograma gerado com base nas atividades previstas para o projeto; plano de custos derivado do custo de cada profissional contemplado no plano de recursos humanos; plano de treinamentos derivado das tarefas a serem realizadas no projeto e das habilidades e competências dos colaboradores, conforme o plano de recursos humanos. É importante existir um alinhamento entre o que foi estimado, o que está sendo planejado e o que será acompanhado. A utilização de uma mesma referência propicia maior visibilidade ao projeto, facilitando em muito não só o seu gerenciamento, mas também a formação de uma base histórica. Essa base histórica poderá beneficiar a organização em etapas posteriores de melhoria. O monitoramento efetivo do projeto dependerá de uma organização adequada dessas informações de planejamento. Ao longo do projeto, elas deverão ser comparadas aos

90 90 dados obtidos durante sua execução, em busca de uma maior visibilidade do andamento do projeto. Quando necessário, o planejamento deverá ser revisto. GPR 12: O Plano do Projeto é revisado com todos os interessados e o compromisso com ele é obtido e mantido: todas as partes interessadas no projeto devem conhecer o plano de projeto. Considerando o modelo ágil Scrum, o propósito da reunião de planejamento do sprint é dar à equipe informação suficiente para trabalharem em paz por algumas semanas e para dar ao product owner confiança suficiente para deixá-los fazerem isto (KNIBERG, 2007). GPR 13: O escopo, as tarefas, as estimativas, o orçamento e o cronograma do projeto são monitorados em relação ao planejado: sugerem-se a utilização de atividades do Scrum, como reuniões diárias. Também, o acompanhamento das atividades baseadas no quadro do Kanban, que mostra o andamento do projeto. De acordo com Borges (2010), a reunião diária é uma breve reunião em que cada participante fala sobre o progresso conseguido, o trabalho a ser realizado e/ou o que o impede de seguir avançando. Segundo Kniberg e Skarin (2009), o quadro Kanban propicia todo um novo nível de transparência. Não apenas fica fácil apontar os problemas, como também levantar questões importantes sobre fluxo, variações e etapas. Começa-se utilizando as etapas como uma maneira para identificar problemas. GPR 14: Os recursos materiais e humanos bem como os dados relevantes do projeto são monitorados em relação ao planejado: espera-se a obtenção de algum artefato que gerencie o envolvimento de todos no projeto. Pode-se citar o quadro do Kanban, no qual as partes interessadas conseguem visualizar o andamento do projeto. É basicamente uma visualização da cadeia de valor e proporciona compreensão sobre os estágios de trabalho, fluxo e tempo através do sistema (tempo de ciclo), (KNIBERG e SKARIN, 2009). GPR 15: Os riscos são monitorados em relação ao planejado: cada projeto deve ter o planejamento revisado, para verificar se atende aos requisitos exigidos, a fim de que todos os critérios sejam atingidos. Ao final de cada etapa, é possível realizar a revisão das atividades, como o Sprint Review, utilizado no Scrum. Segundo SOFTEX (2011), no decorrer do projeto, novos riscos podem ser identificados para o projeto e os parâmetros dos riscos já identificados podem ser alterados. Além disso, pode ser necessário executar ações de mitigação para evitar que os riscos aconteçam ou, no caso de riscos terem se concretizado, pode ser preciso executar ações de

91 91 contingência para minimizar seus efeitos. Também, é importante que a lista de riscos seja reavaliada periodicamente em conjunto com uma avaliação dos seus parâmetros de análise (probabilidade e impacto) e prioridade. Alterações realizadas no planejamento de riscos devem ser comunicadas aos interessados conforme pertinente. GPR 16: O envolvimento das partes interessadas no projeto é planejado, monitorado e mantido. Segundo a SOFTEX (2011), devem ser identificados os interessados relevantes no projeto, em que fases eles são importantes de como eles serão envolvidos (comunicações, revisões em marcos de projeto, comprometimentos, entre outros). Uma vez identificado e planejado o envolvimento, este deverá ser seguido, monitorado e mantido ao longo de todo o projeto. Os interessados no projeto podem incluir os clientes e os usuários (ou seus representantes), a direção da organização e os membros da equipe do projeto. Em projetos pequenos, estas atividades podem ser simplificadas devido ao pequeno número de interessados e a pouca comunicação necessária em função do curto prazo. GPR 17: Revisões são realizadas em marcos do projeto e conforme estabelecido no planejamento: devem-se monitorar as ações para a prevenção de repetição de problemas. De acordo com a SOFTEX (2011), revisões em marcos do projeto não devem ser confundidas com o acompanhamento descrito em GPR13, GPR14 e GPR15, que é derivado do acompanhamento do dia a dia do projeto. Os marcos do projeto precisam, portanto, ser previamente definidos ao se realizar o planejamento do projeto. Este resultado é importante porque as revisões em marcos são oportunidades para verificar, de forma ampla, o andamento de todo o projeto, independente do acompanhamento do dia a dia. Em projetos grandes, essas revisões são fundamentais, questionando, inclusive, a viabilidade de continuidade do projeto. Além das revisões em marcos, outras revisões poderão ser estabelecidas no planejamento do projeto. Caso isto ocorra, estas revisões deverão ser executadas, conforme o planejado. GPR 18: Registros de problemas identificados e o resultado da análise de questões pertinentes, incluindo dependências críticas, são estabelecidos e tratados com as partes interessadas. De acordo com Borges (2010), os problemas devem ser identificados (e a sua definição deve ser consensual) e devem ser propostas soluções em conjunto com as partes interessadas.

92 92 GPR 19: Ações para corrigir desvios em relação ao planejado e para prevenir a repetição dos problemas identificados são estabelecidas, implementadas e acompanhadas até a sua conclusão. Idealmente, a especificação de requisitos deve permitir que o processo de fabricação do software seja controlado. Isso significa que idealmente a qualidade de produtos intermediários deve poder ser mensurada e que os dados obtidos devem trazer informação que possa levar ao controle de desvios, localização de defeitos e outras ocorrências negativas, (BORGES, 2010). 5.2 RECOMENDAÇÕES PARA A APLICAÇÃO DOS PROCESSOS DE GERÊNCIA DE REQUISITOS apresentados a seguir: Os resultados para o Processo de Gerência de Requisitos esperados são GRE 3: A rastreabilidade bidirecional entre os requisitos e os produtos de trabalho é estabelecida e mantida: para ser atendido, é preciso que a rastreabilidade dos requisitos seja feita desde o começo. É necessário que se possa chegar a um documento a partir de sua origem e vice-versa. Segundo Borges (2010), a rastreabilidade, ou seja, a origem dos requisitos, em relação ao cliente, deve estar claramente identificada. Entre outros motivos, isto é importante para facilitar a gestão futura dos requisitos. GRE 4: Revisões em planos e produtos de trabalho do projeto são realizadas visando a identificar e a corrigir inconsistências em relação aos requisitos: é necessário que, no projeto, sejam feitas com freqüência as revisões nos planos de produtos de trabalho, para identificar possíveis inconsistências no requisitos. Assim, é sugerida a aplicação da metodologia Scrum. Segundo a SOFTEX (2011), a consistência entre os requisitos e os produtos de trabalho do projeto deve ser avaliada e os problemas identificados devem ser corrigidos. Este resultado sugere, portanto, a realização de revisões ou de algum mecanismo equivalente para identificar inconsistências entre os requisitos e os demais elementos do

93 93 projeto como, por exemplo, planos, atividades e produtos de trabalho. As inconsistências identificadas devem ser registradas, e ações corretivas executadas a fim de resolvê-las. Exemplos de revisões com esse objetivo são revisões de monitoração e controle do projeto e inspeções, baseadas em critérios explícitos para identificar inconsistências entre os planos, atividades e produtos de trabalho com os requisitos e com mudanças nesses requisitos. Quando há mudanças nos requisitos, é importante examinar se os demais artefatos estão consistentes com as alterações realizadas como, por exemplo: verificar se a planilha de estimativas está contemplando todos os requisitos e mudanças; verificar se as mudanças dos requisitos foram incorporadas ao escopo ou cronograma do projeto; e outros. As ações para correções das inconsistências devem ser acompanhadas até que sejam resolvidas. GRE 5: Mudanças nos requisitos são gerenciadas ao longo do projeto: deve-se realizar a análise de impacto de qualquer mudança nos requisitos ao longo do projeto. De acordo com SOFTEX (2011), durante o projeto, os requisitos podem mudar por uma série de motivos. Desta forma, requisitos adicionais podem ser incorporados no projeto, requisitos podem ser retirados do projeto e/ou mudanças podem ser feitas nos requisitos já existentes. Ressalta-se que, devido às mudanças, os requisitos podem ter que ser revistos, conforme definido no GRE4. As necessidades de mudanças devem ser registradas e um histórico das decisões acerca dos requisitos deve estar disponível. Estas decisões são tomadas por meio da realização de análises de impacto da mudança no projeto e podem incluir aspectos como: influência em outros requisitos, expectativa dos interessados, esforço, cronograma, riscos e custo. É importante destacar que o mecanismo de rastreabilidade bidirecional instituído é um importante mecanismo para facilitar a análise de impacto. Muitas vezes, mudanças nos projetos acontecem em diferentes níveis de abstração dos requisitos, não apenas nos requisitos de cliente. Por exemplo, mudanças, em casos de uso ou que afetem protótipos de telas, podem precisar ser gerenciados, utilizando um mecanismo mais formal de controle de mudança. Dessa forma, é indicado que a organização determine a aplicabilidade da gerência de mudança, conforme descrito no resultado esperado.

94 APRESENTAÇÃO DOS RESULTADOS PRELIMINARES PARA A EMPRESA Foi feita uma apresentação com resultados preliminares para a empresa e conversado sobre a possibilidade do uso de práticas dos modelos ágeis, com ênfase no Scrum e Kanban. A empresa estudo de caso identificou-se mais com o modelo Kanban, pelo fato de não haver tantas regras e por ser mais dinâmico que o Scrum. Isso não quer dizer, que não possa ser usada nenhuma recomendação do Scrum. Tudo dependerá do que será mais cabível e acessível à empresa. Quadro 5 Diferenças entre Scrum e Kanban: Fonte: Elaborado pelos autores, 2013.

95 DESCRIÇÃO DOS PROCESSOS DA EMPRESA APÓS APRESENTAÇÃO DOS RESULTADOS Após apresentação das recomendações, a SoftPC passou a implantar algumas melhorias nos seus processos, com a adoção do Kanban e algumas práticas do Scrum, como, por exemplo, o Backlog do produto. Inicialmente, começaram a gerenciar seus projetos através de um quadro, chamado Quadro Kanban, posto em uma parede. Nele, cada membro do projeto atualiza, diariamente, o status de suas atividades, trocando de posição os papéis identificados por autor e nome de cada atividade. Assim, o analista consegue identificar os gargalos de cada projeto, podendo ser por pontos de falhas ou até mesmo atraso nas atividades. A seguir, apresentam-se algumas imagens ilustrativas: Figura 20 Representação do Quadro Kanban Fonte: Elaborado pelo autor, 2013.

96 96 Figura 21 Representação do Quadro Kanban Fonte: Elaborado pelo autor, Após utilização do Quadro Kanban, que, por ser num meio físico, é de fácil visualização, resolveu-se adotar o uso de uma ferramenta on-line para o gerenciamento de projetos, denominada Kanbanize. Essa ferramenta é similar ao quadro posto na parede, mas muito mais prática e eficaz, pois cada membro da equipe tem um login e senha no sistema e eles acessam e realizam a atualização diária de status para cada atividade do projeto. Atualmente, a empresa utiliza apenas o Kanbanize. Em continuação, segue uma imagem ilustrativa do sistema gerenciador de projetos:

97 97 Figura 22 Kanbanize on line Fonte: Elaborado pelo autor, Figura 23 Kanbanize on line Fonte: Elaborado pelo autor, 2013.