[Seminário] Modelagem de Negócio

1. Modelagem de negócios

Com a revolução da tecnológica a mesma passou a ser um ponto crucial na hora de elaborar estratégias e na formação de inteligência de negócios, aumentando cada vez mais o nível de exigência dos clientes de tecnologia que cada vez espera um retorno maior do seu investimento. Atualmente a empresa que possui um sistema de tecnologia eficiente e bem acoplado está à frente de suas concorrentes, para que seja possível a elaboração de um software eficiente é necessário entender a rotina da empresa a qual vai trabalhar.

2. Importância da modelagem de negócios

Com a evolução tecnológica as empresas começaram a ver a TIC (tecnologias de informações e telecomunicações) como novas fontes de investimentos e retorno, com isso a tecnologia esta em constantes mudanças sendo elas em escala pessoal como empresarial. O cenário competitivo atual obriga as empresas a pensarem em novas maneiras de gerenciamento, visto que estão diante de um novo mundo, novas políticas, novas formas de relacionamentos, novas organizações e uma nova economia.

O profissional de TI precisa compreender que esta área está voltada para a criação de ferramentas que será utilizado por diversas outras ciências, ou seja, as empresas estão investindo na área de TI para poder agregar valor e qualidade ao produto final.

3. O que é modelagem de negócios

Modelagem de negócios é a combinação de TIC com as estratégicas de negócios. Com isso foi criada uma nova classe o “analista de negócios”, pois para que haja esta combinação de forma efetiva é necessária a compreensão por completa das necessidades dos clientes, ou seja, é necessário compreender o dia-a-dia, as aplicações, equipamentos, expectativa do cliente e o resultado final.

As modelagens de negócios vão se basear no processo de negocio na organização Sommerville, que define esses processos como sendo processos usados para atingir algum objetivo de negócio. Como o citado em baixo:

· Domínio da empresa: Empresa de seguros.

· Processo de negocio: Emissão de apólice de seguros.

O resultado da modelagem de negócios são os modelos de negócios. Esses modelos refletem a representação de um conjunto de atividades que serão executadas para transformar entradas e saídas em trabalho. A modelagem de negócios resulta em analises e reflexões sobre a natureza do negócio e a forma como ela é executada.

4. Objetivos da modelagem de negócios

Podemos citar como principais objetivos da modelagem de negócios:

• Entender o negócio: Através de atividades de modelagem de negócios as equipes analisam e observam o dia-a-dia e os processos do cliente, para que seja feita a implementação do sistema
• Entender problemas atuais e sugerir melhorias: com a convencia no dia-a-dia a equipe tem uma visão diferenciada e pode sugerir otimizações mais eficientes para o problema atual do cliente
• Assegurar o entendimento comum sobre a organização e seu negocio: a equipe de modelagem e as pessoas que trabalham na organização necessitam entrar em um senso comum. Tendo noção do que o software irá gerar a empresa e o resultado final.
• Documentar os processos de negócios e capturar a relação entre esses conceitos: gerar artefatos técnicos a fim de mapear, validar e documentar os processos de negócios, ajudando não só a equipe, mas como a organização a encontrar falhas.
• Derivar os requisitos de sistema necessários para sustentar a organização: através dos resultados das modelagens de negócios, esta equipe de projetos pode derivar os requisitos de sistema para apoiar a organização

5. Notações para modelar processos de negócios

Notação de modelagem de processos de negócios é uma linguagem gráfica ou textual para representar um conhecimento ou domínio. Atualmente esta sendo mais utilizadas as notações de UML e BPMN.

5.1 UML (unified modeling language)

É uma linguagem padronizada para documentar projetos de software. A linguagem prove de uma lista de diagramas para representar diferentes visões do sistema. Na UML podemos utilizar o Diagrama de atividades com finalidade de destacar a lógica de realização de um tarefa, mostrando o fluxo entre atividades e a seqüência dessas como suporte para comportamentos. Elementos do diagrama de atividades são:

• Atividades representam tarefas ou sub-atividades de um processo
• Transições: quando o fluxo de controle passa para outra atividade
• Decisões: são caminhos alternativos no fluxo de controle das atividades, pode ser uma bifurcação ou união
• Barras de sincronização: utilizadas para sincronizar atividades em processos
• Raias: utilizadas para mostrar responsabilidades

5.2 BPMN (business process modeling notation)

Mais utilizados para organizações e processos maiores e complexos. A especificação da notação BPMN prove uma notação gráfica para expressar os processos de negócios em forma de diagrama de processo de negócios, o objetivo da BPMN é dar suporte ao gerenciamento de processos de negócios. A notação esta agrupadas nos seguintes grupos:

• Objetos de fluxos: são os principais elementos gráficos para definir o comportamento do processo de negócios são eles: atividades eventos e decisões.
• Objetos de conexão: conectam objetos de fluxo: fluxo de seqüência, fluxo de mensagem e associação
• Swinlanes : servem para agrupar elementos do processo, normalmente associados a unidades organizacionais, departamentos e grupos
• Artefatos: são usados para fornecer informações adicionais sobre o processo. Existem quatro artefatos padronizados, mas o fabricante de software esta livre para adicionar quaisquer outros artefatos.

6. Ferramentas

As ferramentas mais comuns para a criação da modelagem de projetos são:

UML

• Astah community e a starUMl

BPMN

• iLog, IntalioBPMS, BizAgi e billfish

[Seminário] O processo unificado integrado ao desenvolvimento Web

O processo unificado integrado ao desenvolvimento Web

Com o propósito de auxiliar os fornecedores de soluções de software que utilizam como plataforma a internet, este artigo objetiva formalizar idéias práticas, explicando como o desenvolvimento de sistemas Web pode ser integrado ao Processo Unificado. Serão apresentados alguns artefatos para controlar o desenvolvimento de um Web Site, além das vantagens e os cuidados a tomar com a integração de forma a facilitar a entrega. Serão apresentados também alguns pontos relacionados com a gerência e o plano de execução.

Além disso, explica-se como o Processo Unificado pode ser configurado de acordo com o tempo que uma empresa possui para desenvolver um projeto voltado para internet.

Processo Unificado

O Processo Unificado é um processo de desenvolvimento fortemente ligado à orientação a objetos, porém, pode-se utilizá-lo em qualquer projeto mesmo sendo ele estruturado, sem que perca suas características básicas. Ele utiliza alguns princípios modernos (componentização, revisões, etc) na área de engenharia de software.

Algumas características básicas do Processo Unificado são:

· Direcionado por casos de uso: O início do processo deve ser marcado pela utilização dos casos de uso, a fim de se definir uma linguagem entre os usuários e o sistema, facilitando a especificação dos requisitos.

· Centrado na arquitetura: O processo procura modelar uma arquitetura através dos aspectos estáticos e dinâmicos de um projeto, que podem ser obtidos junto a um estudo direcionado pelos casos de uso mais significativos.

· É iterativo e incremental: Uma das práticas do processo é dividir grandes projetos em mini-projetos. Cada mini-projeto possui uma iteração, que quase sempre abrange todo o fluxo de trabalho. Olhando como um todo, essa iteração resulta em um incremento para o projeto. É válido lembrar que as iterações são planejadas de acordo com os casos de uso.

O Processo Unificado visa tornar clara a necessidade de atribuições de tarefas a grupos ou indivíduos envolvidos diretamente no desenvolvimento de um projeto. Além disso, deve-se definir o quanto antes, quais as etapas (iterações) e os artefatos que serão envolvidos durante o processo. Com essas características, conclui-se que o Processo Unificado é um modelo configurável, ou seja, deve ser ajustado de acordo com os tipos de projeto que se necessita desenvolver.

Concepção ou iniciação: Essa fase tem como objetivo verificar a viabilidade do projeto, bem como os riscos e um dos fatores não menos importantes: definir os casos de uso mais críticos obtendo as funções chave do sistema. É através do tipo do projeto, dos casos de uso e consequentemente dos requisitos, que se realizará o ajuste de quantas iterações o processo terá. De acordo com os casos de uso, pode-se definir também quais as etapas exigirão maior cuidado.

Elaboração: Durante essa fase, a maioria dos casos de uso são especificados e detalhados. A arquitetura do sistema é projetada utilizando artefatos que podem ser estáticos ou dinâmicos. Neste instante são apresentados, o Baseline completo do projeto, os componentes que formarão a equipe de desenvolvimento, etc. No final dessa fase os envolvidos devem estar aptos a planejar a fase de construção em detalhes.

Construção: A fusão de vários artefatos de software ocorre neste momento, possibilitando que o sistema seja implementado quase que completamente. Tem-se uma visão geral de como o Baseline do projeto está sendo seguido. No final dessa fase, o sistema deve estar totalmente preparado para a transição ao usuário.

Transição: O objetivo dessa fase é garantir que todos os requisitos do projeto foram atendidos e implementados corretamente. O produto final pode ser liberado em uma versão beta. Existem ainda outras atividades que, de acordo com o projeto, podem ocorrer de maneira paralela, por exemplo, a preparação do ambiente, a conclusão do manual do usuário, identificação e correção de defeitos. No final dessa fase deve-se tirar uma conclusão geral do projeto, obtendo os pontos positivos e negativos os quais devem ser utilizados durante a concepção de projetos futuros.

Em relação aos fluxos de trabalho, ou disciplinas, tem-se os seguintes esclarecimentos.

Modelo do negócio: O objetivo principal desse fluxo é que o fornecedor entenda muito bem o problema a ser resolvido, elaborando se necessário uma análise de risco e de viabilidade para o projeto como um todo. Neste momento, existe uma grande interação entre o fornecedor e o cliente. A fim de que possam ser gerados os casos de uso e consequentemente a extração dos requisitos. Entender o modelo de negócio do cliente é peça fundamental antes que um requisito possa ser definido.

Requisitos: Nesse fluxo procura-se extrair os requisitos do sistema a ser desenvolvido. A grande dificuldade nesta etapa e no desenvolvimento de software é capturar requisitos de forma que os clientes possam entender claramente o que o sistema se propõe a fazer. A base para isso é que o fornecedor entenda o domínio do problema e consequentemente construa um bom modelo de casos de uso. A extração dos requisitos, através dos casos de uso, irá compor um artefato que será evoluído durante todo o projeto.

Análise e Projeto: No início desse fluxo de trabalho, desenvolve-se uma visão “arquitetural”, incluindo os artefatos significativos para o modelo de projeto. O objetivo aqui é compreender os casos de uso mais importantes, que serão insumos para a elaboração de alguns artefatos, como: um diagrama de classes, de estado, de iteração, de seqüência, de colaboração, etc. É válido lembrar que não é necessária a utilização de todos os artefatos, mas apenas aqueles que sejam relevantes a fim de que o cliente entenda perfeitamente o que será construído. Com artefatos bem elaborados, a equipe de desenvolvimento terá grandes facilidades em realizar a implementação. No início deste fluxo encontra-se, caso necessário, protótipos de funcionalidade e de interface, como também uma descrição da arquitetura básica do sistema. Durante o desenvolvimento do projeto alguns artefatos poderão sofrer ajustes de acordo com as implementações realizadas.

Implementação: No início desse fluxo, os desenvolvedores poderão buscar componentes (funções) que foram utilizados em outro sistema. Ainda na fase de concepção, pode-se ter um protótipo de funcionalidade como um produto final em primeira instância. No decorrer deste fluxo, procura-se ter um sistema executável a cada iteração, além da implementação baseada nos artefatos criados no modelo de análise e projeto. O conceito de componentização deve ser sempre levado em consideração, com o intuito de que estes segmentos de códigos possam ser aproveitados mais tarde por outros sistemas.

Testes: Neste fluxo, um plano de teste deve ser elaborado, definindo e identificando qual procedimento e quais tipos de testes serão realizados. Esse plano poderá ser alterado de acordo com a melhor definição dos requisitos do sistema. Ele também poderá ser utilizado durante todo o projeto, sendo modificado a cada iteração, mostrando a situação do executável que foi entregue ao cliente. Nas fases de concepção e de elaboração têm-se os testes de módulos e na fase de construção têm-se os testes de integração. O número de testes de integração poderá se repetir de acordo com a quantidade de alterações nos requisitos do sistema.

Implantação: Descreve-se nesse fluxo de trabalho, a instalação do sistema no ambiente do cliente. Durante toda a fase de elaboração, até o meio da fase de construção, um simples documento especificando algumas características do ambiente do cliente poderá ser realizado. Este artefato pode conter, por exemplo, especificações técnicas sobre a infra-estrutura de rede e de sistemas suportada pela empresa contratante. Além disso, algumas dicas de instalação podem ser acrescentadas nesse artefato de forma a reduzir mais tarde, o número de erros de instalação e consequentemente o tempo de testes. No final da fase de construção, inicia-se a migração do sistema para o ambiente de testes do cliente. Posteriormente, no final da fase de transição, já se pode observar a completa migração e configuração do sistema no ambiente de produção do cliente.

Gerência de configuração e mudança: É durante esse fluxo de trabalho que são controlados todos os artefatos do projeto, bem como suas versões. Antes de realizar uma mudança, deve-se fazer uma análise em relação ao que deve ser modificado e saber em quais artefatos e áreas da implementação isso irá afetar. Um bom controle de mudança é crucial para garantir o sucesso e a qualidade do projeto. À medida que o projeto entra na fase de construção, a dificuldade no controle de mudança e gerência de configuração aumenta. Isso ocorre porque o projeto está maior, com mais requisitos implementados e com maiores chances de que uma alteração possa afetar outras áreas do sistema. Ter rastreabilidade e saber relacionar os requisitos é uma tarefa importante do engenheiro de software. Após uma modificação, necessita-se de novos testes em várias áreas do sistema, garantindo que a mudança foi implementada corretamente. Não menos importante, a alteração da documentação deve estar completamente condizente com o que foi implementado.

Gerenciamento de projeto: Nesse fluxo se escolhe os artefatos a serem utilizados no desenvolvimento da aplicação, de acordo com o tipo do projeto e o entendimento do cliente. O gerente deve ter uma visão clara do que o cliente deseja, do que está documentado e do que está sendo implementado. A atividade de gerenciamento de projeto é constante durante todo o ciclo de vida do software, elaborando reuniões com RTF (Revisão Técnica Formal), garantindo a correta mudança dos artefatos, além da necessidade de manter um bom relacionamento com o cliente.

Ambiente: Esse fluxo representa o ambiente de trabalho da empresa que desenvolverá o projeto. Ele pode ser caracterizado pelo tipo de plataforma, pela rede, pela organização dos diretórios no qual ficarão os artefatos e os códigos fonte, pelo sistema de backup etc. Pode-se perceber na

As iterações, nada mais são do que marcos durante a construção de um sistema utilizando o Processo Unificado. Um aspecto muito importante é que o número de iterações deve ser definido logo no início de cada projeto (elas podem variar de número de acordo com o tamanho do sistema a ser desenvolvido). Uma iteração normalmente é marcada pela entrega de uma versão executável do sistema e uma reunião formalizada através de uma RTF (Revisão Técnica Formal). Em geral, o resultado de uma iteração é um incremento para o sistema. Entende-se também que uma iteração é como se fosse uma “foto” tirada da aplicação num determinado instante. É um marco indicando o final de um mini-projeto.

Artefatos específicos utilizados no desenvolvimento de projetos Web

Durante a construção de aplicações web pode-se utilizar inúmeros tipos de artefatos. Serão citados a seguir, alguns documentos que poderão ser utilizados no Processo Unificado.

Prioridade: Indica o nível de importância que o requisito possui para o sistema em geral, podendo ser baixa, média ou alta.

· Dificuldade: Indica o nível de dificuldade para implementar este requisito, podendo ser baixa, média ou alta.

· Atendido: Representa o status do requisito, indicando se o mesmo foi ou não implementado no sistema.

· Comentários: Fornece informações sobre o requisito, dizendo, por exemplo, o motivo que um determinado requisito ainda não foi implementado (indicando mais especificamente, quais são as dificuldades).

A planilha de requisitos é um artefato “vivo” no ciclo de vida do projeto e deve ser incorporado à área de SCM (Software Configured Management) do Processo Unificado. A expressão artefato “vivo” indica que a planilha está apta a sofrer alterações no decorrer do projeto.

Projeto Linear

Além da planilha de requisitos, esse é um dos artefatos mais importantes para o desenvolvimento de um sistema Web. Nele poderão ser mapeados os requisitos do sistema com as áreas ou páginas de uma aplicação. Cada página receberá um código, que por sua vez será relacionado com nenhum, um ou mais requisitos.

Através deste documento busca-se um maior controle do sistema, pois se houver quaisquer modificações nos requisitos o fornecedor saberá quais áreas devem sofrer mudança. Este também é um artefato “vivo” e deve ser incorporado ao fluxo de trabalho de gerência de configuração e mudança (SCM - Software Configured Management). A Figura 4 apresenta um exemplo de como seria uma simples representação de um Projeto Linear, mostrando algumas áreas do site, com seus respectivos requisitos relacionados.

Web Content

O Web Content é um artefato de software responsável pelo armazenamento de todo o conteúdo textual utilizado em um site. Não existe um documento padrão de Web Content. Normalmente cada empresa que desenvolve aplicações web possui o seu.

O Web Content é formado de acordo com os requisitos do sistema e entende-se que o mesmo pertence ao fluxo SCM (Software Configured Management) do Processo Unificado. Na

É muito importante lembrar que esse artefato é formado não só de uma, mas várias seções, onde cada uma indica o conteúdo de cada página do site. Com o Web Content, o fornecedor consegue agrupar e gerenciar melhor o conteúdo de um site.

FDD (Wireframes)

O FDD (Functional Design Document) é um conjunto de Wireframes onde cada um representa uma página da aplicação. Um Wireframe é uma maquete da página Web que se dirige somente à disposição de elementos, não à estética. Ele é o esboço de como seria uma página, desprezando cores e imagens. A vantagem em utilizar um Wireframe como guia para implementação, é que ele trabalha representando o fluxo da informação estabelecido anteriormente no Projeto Linear. Ele pode ser desenvolvido pelo arquiteto de informação.

O uso de um FDD estabelece uma forte ligação da arquitetura da informação com a estrutura do site, colocando a informação no seu respectivo local. Além disso, um FDD bem organizado pode oferecer fortes soluções para os problemas de usabilidade. Outra característica importante deste artefato é que ele pode informar onde encontrar o conteúdo para aquela respectiva página dentro do Web Content.

A desvantagem do FDD é que ele não apresenta uma solução gráfica para o projeto, apesar de ter um papel muito importante em conduzir a proposta de layout a ser construída pelo designer. Em relação ao desenvolvimento de um Web Site, o FDD torna-se um dos artefatos mais completos, que auxiliam muito os programadores, pois eles criam uma relação entre a página a ser implementada e o conteúdo a ser aplicado.

Protótipo de interface

O protótipo pode ser uma parte da aplicação implementada, protótipo de funcionalidade, ou uma proposta de layout, protótipo de interface, feita pelo designer e aprovada pelo cliente. Este item fornece algumas informações apenas sobre o protótipo de interface. Para chegar até o protótipo, o designer precisa utilizar o FDD ou pelo menos uma parte dele para ter noções de como será a divisão do site. A principal função deste artefato é fornecer ao cliente quais serão as cores básicas da aplicação, uma parte da arquitetura de informação e como ficarão disponibilizadas as informações aos usuários dentro do site. A vantagem na utilização deste artefato é direcionar totalmente a equipe de análise e projeto, bem como a equipe de implementação.

O PROCESSO UNIFICADO INTEGRADO AO DESENVOLVIMENTO WEB

Descreve-se o esforço gasto para construir cada artefato web em razão das fases do progresso.

CONFIGURANDO O PROCESSO UNIFICADO

Antes de iniciar o desenvolvimento de qualquer projeto utilizando o processo unificado, e necessário determinar o fluxo de trabalho mais utilizados, o numero e o tempo de cada iteração dentro das fases. Modelo de negócio, requisitos, analise de projetos, implementação, teste e implementação. Para este artigo, o desenvolvimento de uma web cite contendo de um prazo de três meses. Definido o prazo de entrega, o processo começa a ser modelado à medida que Baseline e construído.

RELACIONADO ARTEFATOS, FASES DO PROCESSO E FLUXOS DE TRABALHO.

O que deve ser feito em todos os fluxos de trabalhos, através do numero de interações definidas na configuração do processo unificado.

Fase de Concepção 1ª Iteração

A primeira iteração ocorre praticamente depois de toda fase de concepção do projeto. No final dessa iteração, deixa se claro quais os artefatos faram parte da gerencia de configuração e mudança, artefatos que ainda sofreram algum tipo de alteração no decorrer do desenvolvimento do projeto.

Modelos de Negócios: Pode-se realizar um documento indicado a análise de viabilidade e risco do projeto. O diagrama e a descrição de casos de usos do sistema. Neste fluxo, o Baseline do projeto começa a ser construído, contemplando custos, prazos, cargos e números de pessoas envolvidas. E valido destaca-se que às vezes o Baseline pode ser modificado de acordo com as interações do processo.

Requisito: A extração dos requisitos deve ser feita à medida que os casos de uso do sistema são realizados e validos. O próprio cliente já pode obter informações sobre o que deseja, em relação ao conteúdo que será aprese3ntado em sua aplicação.

Analise e Projeto: Esse fluxo utilizará ate o momento, todos os requisitos construídos e aprovados dentro da planilha. E no Projeto Linear que serão mapeados os códigos de cada pagina do site, a descrição da área e identificação dos requisitos. Do site poderá esta relacionada a nenhum, um ou vários requisitos. Mediante a construção do Projeto Linear e da Web Content iniciar-se a montagem de FDD. Servirá como a guia para o designer montar o protótipo de interface do site. A aprovação do cliente marcam o final da 1ª iteração.

Implementação: Buscar funções e componentes já desenvolvidos em outros projetos, os quais servirão para a realização desta aplicação. Como a instalação de software e ferramentas necessárias para a implementação. A construção do diagrama de classes, bem como outros diagramas UML que os engenheiros de software acharam necessários, para o entendimento e validação do sistema pelo cliente.

Teste: Marcado com o inicio da construção de um artefato chamado plano de teste. Após a primeira iteração, o wireframe deverá ser enviado ao designer, construção da proposta de layout. Ao final desta iteração, os artefatos sob gerencia de configuração e mudança: FDD, Projeto Linear, Web Content, planilha de requisitos, descrição dos casos de uso, plano de teste, documentos de Baseline e quaisquer outros artefatos da UML que podem ser incluídos mediante a necessidade do projeto. A RTF e o protótipo de interface, não faram parte da gerência de configuração e mudança, pois são artefatos “mortos”.

Fase de Elaboração – 2ª Iteração

Já não existe mais esforços voltados para o protótipo de interface. Ele servira apenas para guiar a montagem da estrutura dos templates do site, levará mais tempo para acontecer do que a primeira, pois os esforços vão se concentrado e os envolvidos no projeto precisam entender e resolver os problemas mais críticos que começaram a aparecer.

Modelos de Negócios: O domínio do problema deve ser entendido completamente e uma solução deve ser descrita através dos casos de uso que estarão 80% finalizados no final deste fluxo de trabalho.

Requisitos: Continuam sendo extraídos dos casos de usos e compondo a planilha. Desta iteração tem-se 80% dos requisitos já documentados e aprovados pelo cliente. A base para a construção dos artefatos, como um FDD, Web Content e o Projeto Linear.

Analise e Projeto: O Web Content e o Projeto Linear são documentos que possuem forte ligação com o FDD. Alguns artefatos da UML poderão ser desenvolvidos nesta fase, com o objetivos de ajudar o cliente a entender o sistema.

Implementação: Inicia-se a junção de todas as funções e componentes pesquisados no inicio do projeto, os desenvolvedores precisam estar aptos a entender não só os artefatos como os FDD, Web Content e o Projeto Linear, mas também os possíveis diagramas da UML.

Teste: Pode apresentar alterações no plano de teste devido ao numero de requisitos já extraídos. São realizados testes de módulos, com o objetivo de verificar o que estar sendo feito. Estes testes não irão validar um requisito, mas apenas verificar se ele foi implementado corretamente.

Implantação: De acordo com o resultado, algumas funções poderão exigir um cuidado especial e sem modificadas. Poderão surgir alguns requisitos não funcionais. No final desta iteração, os artefatos estarão quase que totalmente concluídos. Eventuais ajustes podem ocorrer na Baseline e deve ser feitos pelo gerente do projeto. A RTF e construída avaliando e formalizando todas as iterações, servindo de aprendizado para a próxima fase do projeto.

Fase Construção – 3ª de 4ª Iteração

Irão compor toda a fase de construção do projeto. A terceira iteração indica o meio da fase de construção enquanto que a quarta marca o final desta fase.

Modelo de Negocio: Dificilmente durante essas iterações, tem-se de reconstruir um modelo de casos de uso do negocio, a não ser que o cliente solicite uma nova característica para o projeto.

Requisitos: Continuam sendo extraídos dos casos de usos e compondo a planilha. Tem-se em torno de 95% dos requisitos já documentados e aprovados pelo cliente. Desta forma, o FDD, a Web Content, o Projeto Linear, estarão também, quase completamente elaborados.

Analise e Projetos: Alguns artefatos da UML escolhidos para melhor representar as características do sistema serão finalizados durante essas iterações. O desenvolvedor poderá necessitar de algum outro artefato da UML o qual não havia escolhido anteriormente para representar alguma parte do sistema.

Implementação: Os programadores deveram possuir um suporte quase completo dos artefatos web citados anteriormente. Dos esforços do projeto são voltados agora para implementação. Para a gerência das possíveis mudanças nos requisitos e consequentemente nos artefatos. Cuidados especiais devem ser tomados de forma a garantir que uma mudança não afete outra parte do sistema.

Teste: Nesse fluxo, consegue-se entender os pontos críticos de implementação e elaborar o plano de teste totalmente “caixa preta”, são muito importante nestas iterações, pois, eles irão verificar a conformidade do sistema como as exigências do cliente. Desenvolvedores farão teste de módulos e integração.

Implantação: Uma versão executável do sistema poderá ser implantada no ambiente do cliente. A implantação é também uma forma de verificar se o que esta sendo feito funcionará do lado do cliente. O gerente continua a trabalhar atentamente na gerencia de configuração e mudança, que serve tanto para o Baseline quanto para todos os artefatos “vivas” do projeto.

Fase de Transição 5ª Iteração

A ultima iteração, integrando o desenvolvimento web como processo unificado. Marca o termino do projeto, bem como a construção completa de todos os artefatos.

Modelo de negocio: Dificilmente nessa etapa existiram tarefas que exigem analises de viabilidade e de risco. Devem-se armazenar os casos de uso do projeto com boas descrições representativas, afim de que sejam facilmente encontrados, de forma a servir como modelo para projetos futuros.

Requisitos: Os requisitos nesse fluxo são mínimos. Os artefatos devem estar finalizados de acordo com todos os requisitos funcionais e não funcionais encontrados ate o momento.

Analise e Projeto: Tem-se a finalização do FDD, Web Content, Projeto Linear e UML.

Implementação: O ideal e que os desenvolvedores façam ajustes no sistema, apenas para a adaptação ao ambiente do cliente.

Teste: Testes de sistemas e de validação podem ser realizados também pelo cliente.

Implantação: A versão executável final do sistema deverá ser colocada no ambiente de teste e no ambiente de produção, mediante aprovação do cliente, o gerente ou o engenheiro de software continuará a realizar o seu trabalho, alguns artefatos poderão ser ajustados. A RTF indicará os pontos fortes e fracos do projeto. Uma boa documentação e importante, de forma a facilitar a recuperação dos componentes para o projeto futuros.

Um requisito mudou, e agora?

Uma das grandes preocupações do gerente do projeto e saber exatamente o que fazer quando um requisito e alterado pelo cliente. O gerente terá de verificar e se e necessário fazer a alteração imediata. Todos os requisitos do sistema, bem como seus respectivos códigos indicadores. O código que indica o requisito alterado precisa ser modificado pelo gerente, que em seguida, deve abrir o Projeto Linear e verificar quais as áreas do site usam os requisitos modificados. O gerente deve pesquisar na Web Content a fim de saber quais paginas do site sofreram alteração. Não e o objetivo do gerente de projeto efetuar as alterações, mas identificar o impacto que as solicitações de alterações podem causar. Uma mudança de funcionalidade, esta deverá impactar na alteração de outros artefatos, como o diagrama de classes, diagrama de componentes, diagrama de sequencia ou qualquer outro diagrama.

Conclusão:

A configuração do processo a cada projeto mostra um acumulo de conhecimento armazenado durante a entrega de cada sistema, fazendo parte de uma melhoria continua.

[Seminário] Seminário de Eng. Sw: Scrum + melhoria de projetos utilizando a metodologia Scrum

Scrum

INTRODUÇÃO

Na indústria de software, devido á alta complexidade e ao desenvolvimento, impulsionada pela necessidade de obter resultados diferentes dos obtidos pelos métodos tradicionais, quando os processos definidos eram menos adequados para obter a alta produtividade e qualidade no produto final, verificou-se que pessoas válidas estavam propondo métodos sérios e factíveis. Desta forma, determinadas práticas ágeis começaram a ser utilizadas em projetos de software sem a agressividade pela adoção plena de uma metodologia ágil.

As empresas de software começaram a estudar essa metodologia, que propõe novos métodos em substituição aos métodos praticados tradicionalmente, pois o mercado de tecnologia da Informação está cada vez mais competitivo, onde as mudanças torna-se cada vez mais desejadas. O método busca primeiramente resolver as questões acerca da organização, distribuição, controle das atividades de um projeto de software, flexibilidade para acomodar as alterações necessárias exigidas durante o desenvolvimento do produto, e que seja baseado em inspeção e adaptação. Este é o Scrum e apresentaremos uma breve explicação da escolha da metodologia Scrum pelo mercado de empresas desenvolvedoras de software. Quanto mais próximo do limite do caos a equipe conseguir trabalhar, porém mantendo a ordem, mais competitivo e útil será o produto resultante.

HISTÓRIA

Alguns estudos e pesquisas fornecidas pelo PMI (Project Management Institute), mostra que aproximadamente 70% dos projetos emitem falhas, que referem-se a problemas com prazos, custos, escopo, insatisfação do cliente e, muitas vezes, tudo isso junto.

Então, utilizando esses números como justificativa, podemos aproveitar a oportunidade e apontar os canhões para os métodos tradicionais de gerenciamento de projetos.

Essas metodologias tradicionais surgiram quando os mainframes ainda reinavam e não existiam ferramentas de apoio ao desenvolvimento; o custo de realizar algum tipo de alteração era altíssimo e a documentação tinha de ser muito mais forte, eles previam todos os requisitos do sistema para assim ser feito um planejamento prévio de como o sistema irá atuar. Este planejamento rigoroso é representado como documentos que guiarão todo o processo de desenvolvimento.

Grande parte das práticas tradicionais de gerenciamento ainda estão baseadas em modelos e conceitos estabelecidos há mais de 50 anos.

Antigamente, o ritmo das mudanças era algo infinitamente menor que nos dias atuais. Essa condição permitia a realização de planejamentos longos, com grande detalhamento de atividades e tarefas, uma vez que a probabilidade da ocorrência de mudanças durante o período de execução do projeto era muito pequena.

A partir do final do século 20, com globalização, internet, acirramento da concorrência, novos perfis de consumidores, lançamento contínuo de novos produtos etc., mudanças frequentes passaram a fazer parte do nosso cotidiano.

Os métodos ágeis surgiram no início da década de 90, como uma alternativa aos processos tradicionais em decorrência da insatisfação dos profissionais de desenvolvimento de software, com a rigidez e resultados limitados obtidos através do uso de práticas tradicionais de gestão de projetos. Tais projetos partem da premissa de que se devem permitir mudanças nos requisitos a qualquer tempo.

Em fevereiro de 2001 Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland e Dave Thomas, um grupo de 17 profissionais, referências no desenvolvimento de software e representantes das diversas abordagens ágeis da época reuniram-se em Wasatch Range nos Estados Unidos para discutir melhores maneiras de desenvolver software encontrando um caminho comum em termos de praticas de gestão de projetos. Esse encontro deu origem ao manifesto ágil para o Desenvolvimento de Software, uma declaração com valores e princípios relacionados ao assunto, sendo eles:

• Interação entre indivíduos é mais importante que processos e ferramentas;
• Produto em funcionamento mais que documentação extensa;
• Colaboração com o cliente mais que negociação de contratos;
• Responder a mudanças mais que seguir um plano.

A metodologia ágil é muito adequada para situações em que a mudança de requisitos é frequente, ou seja, para ser ágil, a metodologia deve aceitar a mudança em vez de tentar prever o futuro.

Em Fevereiro de 1986, os professores Hirotaka Takeuchi e Ikujiro Nonaka da Universidade Hitotsubashi do Japão publicaram um artigo na Harvard Business Review, intitulado “The New New Product Development Game”, ou “O Novo Novo Jogo de Desenvolvimento de Produto” onde o termo Scrum foi utilizado pela primeira vez aplicado no contexto de processo de desenvolvimento.

O estudo identificou que as dentre as várias abordagens utilizadas, destacava-se um modelo holístico de desenvolvimento, adotado por um grupo específico de empresas. Jeff Sutherland é um dos criadores do Scrum e era vice-presidente da Easel Corporation em 1994, quando introduziu algumas das práticas do Scrum com base neste artigo. Este modelo introduzia mais velocidade e flexibilidade ao processo e foi chamado pelos autores Ken Schwaber com Sutherland na Easel de “Abordagem Rugby”, uma vez que sua forma de execução e de organização das pessoas apresentava grande similaridade com a maneira com que as equipes se organizam em círculos para planejar a próxima jogada, no jogo Rugby. É uma forma de mostrar que o projeto deve ser conduzido em pequenos ciclos, mas com uma visão de longo prazo, que é ganhar o jogo.

Scrum é um processo bastante leve para gerenciar e controlar projetos de desenvolvimento de software e para criação de projetos de produtos. , as empresas que adotaram esse processo, conseguiam reduzir drasticamente seus ciclos de desenvolvimento, o que permitia a liberação de novos produtos para o mercado em períodos cada vez mais curtos. O Scrum segue as filosofias iterativa e incremental, ele se concentra no que é realmente importante: gerenciar o projeto e criar um produto que acrescente valor para o negócio. Na maioria das vezes, esses produtos tornavam-se sucesso de vendas, uma vez superavam as expectativas dos clientes devido ao alto nível de atendimento das suas necessidades e também pela incorporação freqüente de inovações. O valor decorre da funcionalidade propriamente dita, do prazo em que ela é necessária, do custo e da qualidade.

Ciclo do Processo do Scrum

No início de um projeto Scrum, mesmo que ainda se tenha uma visão superficial no principio, há uma formalização de todas as coisas que se pretende fazer ou que se precisa construir no projeto. A partir dessa visão inicial, elabora-se uma lista enxuta dos principais itens; cada item desta lista representa um requisito funcional, ou requisito não funcional, ou questão de tecnologia ou infraestrutura. Esta lista é denominada Product Backlog.

Podemos traduzir Product Backlog como uma lista de prioridade de entrega que indica o quanto de valor ele gera para o negócio. Esta lista não precisa estar completa logo no começo, ela pode ganhar outros itens no decorrer do projeto, em outras palavras, é qualquer coisa que represente um trabalho que precisa ser feito para o produto.

No projeto real, o Product Backlog nunca é finalizado. Existe uma natural evolução e maturidade dos requisitos nesta lista. Requisitos novos podem aparecer, requisitos existentes podem perder prioridade e podem até serem eliminados. Apesar de se permitir que áreas usuárias manifestem seus pedidos nesta lista, somente o Product Owner pode priorizar o Backlog.

O Product Owner possui a responsabilidade de definir a ordem que os requisitos serão produzidos pela equipe de desenvolvimento. Esta equipe deve ser pequena, multi-disciplinar e capaz de desenvolver todos os requisitos, ou um gerente de projeto, ou um patrocinador do projeto, um membro da equipe de marketing ou um cliente interno. Estas equipes recebem o nome de Scrum Teams. A preparação dos trabalhos é denominada Sprint Planning.

Sprint Planning é composta dos seguintes ingredientes: Product Backlog, a capacidade de desenvolvimento da equipe, as condições e exigências do negócio, as características da tecnologia a ser usada e o comprometimento em entregar produtos executáveis incrementais. A mistura são revisões, administração e organização. Os resultados são Sprint Goal e Sprint.

O Scrum Team deve desenvolver os itens separados pelo Product Owner em um determinado prazo previamente combinado. No início de cada iteração a equipe seleciona os itens do Product Backlog, de acordo com as suas prioridades e o prazo previamente combinado, este prazo é definido como Time Box e o trabalho de desenvolver os itens separados neste time box é denominado Sprint. Estes itens separados do Product Backlog fazem parte de uma nova lista. Esta lista, chamada Sprint Backlog, será de total responsabilidade do Scrum Team que deverá mantê-la e organizá-la de tal forma a atender os objetivos do específico Sprint.

É importante que a equipe identifique os itens e tamanho do Sprint Backlog, porque ela estará comprometida a finalizar tais tarefas. Os seus membros são quem deverão escolher com o que irão se comprometer e deverá mantê-la e organizá-la de tal forma a atender os objetivos. Nesse momento as tarefas maiores são subdivididas em partes menores.

Logo após o Sprint Backlog estar concluído, o total de horas trabalhadas é comparado com o total previsto anteriormente no Product Backlog. Caso haja uma diferença significativa, a equipe Scrum deve negociar novamente com o cliente o número correto de horas, para que o Sprint seja realizado com maior probabilidade de sucesso.

Este método de liderança é exercido através de recorrentes tipos de reunião:

• Scrum Planning Meeting: É o início de uma Sprint, onde o Product Owner possui a responsabilidade de definir a ordem que os requisitos serão produzidos pela equipe de desenvolvimento e a oportunidade de atualizar a priorização dos itens do Product Backlog e definir juntamente com a equipe um Product Increment a ser entregue ao cliente ao final do Sprint.

Esta reunião é realizada com a presença do Product Owner, Scrum Master (líder facilitador do projeto), de todo Scrum Team (equipe), e quaisquer interessados, diretores ou representantes do cliente. Durante a reunião o Product Owner explica as funcionalidades de maior prioridade para o Scrum Team, e este faz as perguntas que sejam suficientes para que eles possam, depois da reunião, definir quais atividades eles irão mover do Product Backlog para o Sprint Backlog.

A reunião Sprint Planning é composta dos seguintes ingredientes: Product Backlog, a capacidade de desenvolvimento da equipe, as condições e exigências do negócio, as características da tecnologia a ser usada e o comprometimento em entregar produtos executáveis incrementais. O Scrum Team reúne-se separadamente para discutir o que foi dito e decidir o quanto eles se comprometem a fazer durante o próximo Sprint. Em alguns casos, haverá negociações com o Product Owner, mas será sempre prerrogativa do Scrum Team determinar o quanto eles podem se comprometer.

• Daily Scrum Meeting: O desenvolvimento de projetos de software é um desafio constante, é uma atividade complexa. Todo processo complexo exige uma intensa comunicação entre todos os membros do projeto. Scrum Daily Meeting é a resposta para promover a comunicação da equipe. É um encontro diário realizado pela equipe e o Scrum Master onde os membros discutem aquilo em que trabalharam, no que irão trabalhar e possíveis impedimentos que estejam atrapalhando o progresso do trabalho. Esta reunião é uma maneira eficiente de manter os membros cientes dos objetivos e impedir que o projeto “saia do rumo”.

São tipicamente rápidas e objetivas, realizadas em pé, preferencialmente pela manhã, duram de 15 a 30 minutos, para responder a importantes perguntas:

• O que eu fiz desde a última Scrum Daily Meeting até agora?

• O que eu vou fazer hoje?
• O que pode me impedir?

As Daily Scrum Meeting não representam uma forma de cobrança vinda de um gerente de projetos, mas é uma maneira de sincronizar a equipe às tarefas e relatar os impedimentos que podem estar interferindo no bom andamento do Sprint.

• Criação do Product Increment: A finalização das funcionalidades definidas para um determinado Sprint marca a realização de um Product Increment. Os membros da equipe trabalham de maneira colaborativa de forma a realizar todas as metas definidas para aquele Sprint.
• Sprint Review: é uma reunião tipica de final de Sprint, neste momento a equipe exibe o Product Increment, potencialmente utilizável que foi construído, ao Product Owner, que é responsável por validar e/ou solicitar ajustes para que o projeto se torne adequado aos anseios do cliente. Os participantes desta reunião incluem tipicamente: o Product Owner, o Scrum Team, o Scrum Master, a diretoria, clientes e engenheiros de outros projetos. O ideal é que a equipe tenha concluído todos os itens do Product Backlog alocados para o Sprint.
• Sprint Retrospective: é uma reunião que também acontece ao final do Sprint com o objetivo de fortalecer a unidade de ação da equipe. Acontece apos a revisão do Sprint, o Scrum Master faz uma reunião de retrospectiva com a equipe. Esta objetiva identificar os pontos positivos e negativos do Sprint que entregou o último Product Increment e busca corrigir os problemas encontrados com o propósito de aperfeiçoá-los.

Nessa reunião é debatido o que funcionou na Sprint, o que precisa ser melhorado e quais ações devem ser tomadas para colocar as melhorias em prática. Geralmente o Sprint Retrospective tem de três a quatro horas de duração.

• Atualização do Product Backlog: O Product Owner é responsável por re-priorizar toda lista de itens do Product Backlog para que um próximo Sprint possa ser iniciado de acordo com os itens mais prioritários.

Os principais artefatos produzidos no processo do Scrum são o Product Backlog, Sprint Backlog, Burndown Chart e o TaskBoard.

O Burndown Chart é o gráfico de andamento do Sprint, relacionando horas e data em relação ao restante de tempo hábil para o término do ciclo.

Com o Burndown Chart podemos ver claramente o andamento do projeto ao longo do seu ciclo de desenvolvimento (Sprint). Também, no meio do projeto, podemos calcular facilmente a velocidade com que o projeto está andando e assim estimar uma data para que o Sprint seja concluído.

Este dado estimativo pode ser comparado com o prazo que o Scrum Master definiu para que possamos saber se o projeto vai acabar ou não no prazo.

Este é um dos mais importantes trabalhos que o Scrum Master terá que fazer e o Burndown Chart é o indicador perfeito para ele gerenciar o tempo de projeto e sua equipe de desenvolvimento.

O taskboard é um grande painel onde podem ser colocadas várias informações importantes para o acompanhamento do Sprint. O Sprint Backlog, ou seja, as atividades não iniciadas, as que estão em andamento e as concluídas ficam sempre visíveis e disponíveis para todos os interessados no projeto.

Algumas características do taskboard são:

• Normalmente é desenhado em uma parede e as atividades são descritas em post-its;
• Apresenta uma visão geral do Sprint;
• Fica acessível a todos os interessados no projeto.

Papéis da equipe no Scrum

O Scrum trabalha basicamente com três papéis: o Product Owner, o Scrum Master e a equipe do projeto, também chamada de Scrum Team.

O Product Owner é o responsável pela visão de negócios e por representar os interesses das pessoas que apostam no projeto, provavelmente será um gerente de projeto, ou um patrocinador do projeto, um membro da equipe de marketing ou um cliente interno. Suas principais responsabilidades são:

• Definir as funcionalidades do produto;
• Concentrar as informações vindas de usuários, stakeholders ou do mercado de maneira que se obtenha uma visão única dos requisitos do sistema;
• Sua maior responsabilidade é o Return on Investment (ROI) do projeto;
• Priorizar o Product Backlog;
• Decidir sobre a data de término;
• Ajustar recursos e priorizar tarefas a cada Sprint, como necessário;
• Aceitar ou rejeitar os resultados dos trabalhos.

O Scrum Master é uma mistura de gerente de projeto, facilitador e mediador. Ele é um líder e não somente um gerente, está sempre em contato com o Product Owner.

Entre as suas principais responsabilidades, temos:

• Assegurar que a equipe de desenvolvimento funcione plenamente e seja produtiva;
• Ajudar na cooperação entre todas as funções e papéis do time;
• Remover obstáculos da equipe e assegurar que as práticas de Scrum estão sendo executadas com eficiência pelas pessoas envolvidas;
• Proteger a equipe de interferências externas;
• Assegurar-se de que a metodologia está sendo seguida, incluindo chamadas para reuniões diárias (Daily Scrum Meeting), revisões de atividade (Sprint Reviews) e reuniões de planejamento das atividades (Sprint Planning);
• Identificar quais atividades foram concluídas;
• O Scrum Master deve perceber e resolver problemas pessoais ou conflitos entre os integrantes do time.

Por último, a equipe do projeto ou Scrum Team é o grupo de pessoas responsáveis por desenvolver ou construir as funcionalidades do produto.

Algumas características das equipes de desenvolvimento são:

• São auto gerenciadas, auto organizadas e multifuncionais;
• São equipes pequenas, compostas por 5 a 10 membros (o recomendado são 7 pessoas). Podem ser compostas por desenvolvedores e participantes externos (marketing, vendas, clientes, etc.);
• Demonstrar o resultado do Sprint para o Product Owner e outros Stakeholders;
• Deve ter a capacidade e o conhecimento técnico sobre todo o processo de desenvolvimento do produto;
• O time deve ter pessoas capazes de analisar a solução, codificá-la e testá-la sem necessitar de outros times ou outras pessoas;
• Definem metas de cada Sprint, junto ao Scrum Master, e especificam seus resultados de trabalho;
• Têm o direito de fazer tudo dentro dos limites das diretrizes do projeto para atingir a meta de cada Sprint;
• Organizam os trabalhos para atingir os objetivos dos Sprints.

Aceitação do Scrum no mercado atual

Desde 2009 os projetos vêm se reconfigurando diante da crise, as empresas em todo o mundo tiveram que cortar seus orçamentos, sendo que O Fundo Monetário Internacional (FMI) divulgou um relatório no ano de 2009, onde fez uma previsão de que a economia mundial encolheu 1,3%. Mesmo o Brasil, que fortaleceu sua economia e vem resistindo à recessão, também teve previsão de retração destes mesmos índices.

Por consequência, os investimentos em tecnologia sofreram uma queda de 3 ou 4% em 2009, em previsões das consultorias Forrester e Gartner, respectivamente. Os gastos com programas de computador deverão permanecer praticamente estáveis, já que software é visto como algo que pode ajudar as empresas a economizarem, mas os investimentos em hardware e serviços de TI fecharão o ano em queda.

Os projetos de tecnologia, em particular, sofrem um forte impacto. Neste ambiente de incertezas e constantes mudanças, os atores do mercado de projetos já encontram racionalização do uso de recursos, acesso limitado a crédito, pressões por margens menores e problemas financeiros com grande parte dos clientes, tornando o processo decisório mais longo e gerando uma notável redução na demanda por projetos.

Esta nova configuração exige que as organizações mudem sua forma de trabalhar para conseguirem sobreviver, se fazendo necessária uma verdadeira quebra de paradigma.

Essa nova forma de trabalhar deverá:

• Funcionar bem em ambientes que mudam rapidamente, permitindo replanejamento frequente;
• Focar-se em maximizar o retorno do investimento (ROI) do cliente;
• Ajudar a reduzir o tempo de entrada em produção ou o tempo de lançamento do produto no mercado;
• Evitar desperdício de esforço e tempo com subprodutos e funcionalidades que nunca serão utilizados;
• Sempre entregar valor para o cliente, mesmo que o projeto seja interrompido antes do seu final previsto;
• Priorizar a comunicação e feedback entre as pessoas do projeto, para que todos saibam o que deve ser feito e o que está sendo feito.

Scrum é um framework para desenvolvimento de projetos focado em lidar com todas estas questões. Demonstraremos neste artigo que Scrum é a melhor opção para projetos em momentos de crise.

Scrum e a Crise Mundial

Imaginemos alguns personagens do mercado de projetos inseridos na crise financeira:

• Uma organização (ou grupo dentro da organização) prestadora de serviços em projetos que deve aumentar sua competitividade para não perder clientes, internos ou externos;
• Um diretor ou gerente precisando reduzir custos operacionais para sua organização sobreviver, e para isso utiliza-se de projetos internos, visando melhorar seus processos;
• Um cliente que precisa contratar determinados projetos, internos ou externos, mas tem que reduzir custos para torná-los viáveis.

Forneceremos importantes argumentos para ajudar estes e outros decisores e influenciadores a defenderem a escolha de Scrum em suas organizações nestes tempos turbulentos.

Uma breve avaliação da utilização do Scrum para a melhoria no gerenciamento de projetos de software será apresentada abaixo.

Os processos de desenvolvimento de software definidos ou também chamados de tradicionais são às vezes fatores limitadores aos desenvolvedores. Muitas empresas não possuem recursos ou inclinação para processos pesados de produção de software, por isso muitas acabam por não usar nenhum processo, o que pode ocasionar efeitos desastrosos em termos de qualidade de software.

A maioria das metodologias ágeis nada possui de novo, o que as diferencia das metodologias tradicionais são o enfoque e os valores. A ideia das metodologias ágeis é o enfoque nas pessoas e não em processos ou algoritmos.

Para ser considerada ágil a metodologia deve aceitar a mudança ao invés de tentar prever o futuro. Elas variam em termos de práticas e ênfases, mas compartilham algumas características, como desenvolvimento iterativo e incremental, comunicação e redução de produtos intermediários, como documentação extensiva. Dessa forma, existem maiores possibilidades de atender aos requisitos do cliente, que muitas vezes são mutáveis.

As metodologias pesadas devem ser aplicadas apenas em situações em que os requisitos do software são estáveis e requisitos futuros são previsíveis. Estas situações são difíceis de serem atingidas, uma vez que os requisitos para o desenvolvimento de um software são mutáveis. Dentre os fatores responsáveis por alterações nos requisitos estão a dinâmica das organizações, as alterações nas leis e as mudanças pedidas pelos stakeholders, que geralmente têm dificuldades em definir o escopo do futuro software.

Ao contrário do que alguns imaginam, as metodologias ágeis não rejeitam os processos e ferramentas, a documentação, a negociação de contratos ou o planejamento, mas simplesmente mostra que eles têm importância secundária quando comparado com as pessoas e interações, com o software estar executável, com a colaboração do cliente e as respostas rápidas a mudanças e alterações. É um equívoco entender que o Scrum não enfatiza o planejamento. O planejamento no seu contexto é dividido em vários Sprints. Se a tarefa for muito complexa, ela pode ser dividida em sub tarefas que são então alocadas em dois ou mais Sprints, onde no primeiro faz-se o planejamento e no segundo acontece a execução.

O Scrum se encaixa muito bem principalmente para produtos com características mutáveis durante o projeto. Como existem projetos de natureza empírica que não funcionam corretamente com processos bem definidos, o Scrum entra como possível solução, sendo um processo definido para projetos empíricos com características muito dinâmicas.

Como toda metodologia ou processo, sempre existem vantagens e desvantagens advindas da sua adoção. Algumas das desvantagens observadas no Scrum são:

• Não é fácil de ser implementada, principalmente devido a resistência de mudanças culturais;
• Ausência de práticas de Engenharia de Software, pois é voltada para o gerenciamento do projeto e não para o desenvolvimento, podendo necessitar da associação de outras metodologias de Engenharia de Software simultaneamente;
• Pode ser mais difícil de se aplicar em grandes equipes ou em equipes geograficamente distribuídas;
• A documentação do software pode acabar sendo desprezada;
• Sensação de informalidade, pois a documentação formal do escopo do software só é criada caso os envolvidos considerem necessário;

Vantagens:

• Melhor adaptação no gerenciamento de projetos com constantes mudanças;
• Encoraja a comunicação entre os membros da equipe e o espírito colaborativo;
• Por ser iterativo e incremental, permite a entrega antecipada de uma parte funcional do software ao cliente, que já poderá validar se está conforme o esperado;
• A entrega do software utilizando Scrum é mais rápida do que se utilizasse alguma outra metodologia tradicional, uma vez que a codificação já se inicia logo nos primeiros Sprints, e não se espera ter antes uma extensa documentação do software;
• A qualidade no software utilizando Scrum advém dos seguintes fatores: as iterações, a remoção de impedimentos, inspeção e adaptação, times multifuncionais e autonomia da equipe, o que significa menor pressão sobre cada membro;
• O Scrum traz um ROI mais rápido, pois minimiza a burocracia dos processos e se aproxima do cliente. Este está sempre envolvido, participando da demonstração do software ao final de cada Sprint, oferecendo feedback e atento às mudanças e suas consequências.

Resultados

As metodologias ágeis mesmo não tendo muito tempo de existência, já apresentam resultados efetivos. Comparando as metodologias ágeis e tradicionais: um estudo mostrou que os projetos usando os métodos ágeis obtiveram melhores resultados em termos de cumprimento de prazos, de custos e padrões de qualidade. Além disso, o mesmo estudo mostra que o tamanho dos projetos e das equipes que utilizam as metodologias ágeis têm crescido. Apesar de serem propostas idealmente para serem utilizadas por equipes pequenas e médias (até 12 desenvolvedores), aproximadamente 15% dos projetos que usam metodologias ágeis estão sendo desenvolvidos por equipes de 21 a 50 pessoas, e 10% dos projetos são desenvolvidos por equipes com mais de 50 pessoas, considerando um universo de 200 empresas usado no estudo.

Vale ressaltar que as práticas do Scrum podem ser aplicadas em qualquer contexto, no qual pessoas precisem trabalhar juntas para atingir um objetivo comum. Ele é recomendado para projetos nas áreas de software, automotiva, telecom e, principalmente, de pesquisa e inovação. Apresenta-se ideal para projetos dinâmicos e suscetíveis a mudanças de requisitos, sejam eles novos ou apenas modificados. No entanto, para aplicá-lo, é preciso entender antes seus papéis, suas responsabilidades, seus conceitos e os artefatos das fases do ciclo.

Observa-se que não existe uma metodologia perfeita, assim como não há uma solução única para todos os casos. O projeto de software tem muito a ganhar com metodologias ágeis e suas práticas, assim como quaisquer projetos de inovação, com alto grau de mudanças, escopo não muito bem definido ou que precisam de resultados no curto prazo.

Por outro lado, as situações em que existem fortes requisitos contratuais, amarrando fortemente prazos e escopo, ou quando a organização já possui maturidade e experiência com projetos semelhantes, podem ser candidatos para uma abordagem mais tradicional.

Conclusão

Esta pesquisa foi realizada com a finalidade de contribuir para a evolução dos conhecimentos relacionados aos processos de adaptação de metodologias ágeis a formas tradicionais de desenvolvimento de software. Vimos que o método Scrum é uma metodologia ágil para gerência de projetos baseado em inspeção e adaptação, iterativo e é um modelo incremental como um precursor do Scrum, pois um dos principais conceitos desta última metodologia – a entrega periódica de software com valor de negócio – está alinhado com a essência do modelo incremental.

O processo do Scrum como uma metodologia ágil e ciente das questões críticas relativas a software estabelece algumas alternativas na tentativa de driblar os problemas existentes no desenvolvimento de software.

Observamos que o mercado de software tem crescido a cada dia e junto com ele crescem também as exigências quanto à complexidade, custos, prazos e qualidade dos sistemas, sendo todas estas questões cruciais e de difícil gerenciamento. No contexto da Tecnologia da Informação, principalmente quando se trata de processos de desenvolvimento de sistemas, a dinamicidade sempre se faz presente, o que explica o surgimento de metodologias de desenvolvimento ágil com a finalidade de atender as necessidades atuais do mercado de software e proporcionar maiores vantagens em relações às metodologias tradicionais.

As metodologias ágeis são uma positiva proposta para as empresas. Para iniciantes em metodologias ágeis, remcomenda-se aprender sobre o Scrum; o mesmo é recomendado para praticantes de métodos ágeis que não conhecem o Scrum.

Portanto, o Scrum serve como um guia de boas práticas para o alcance do sucesso. O conhecimento das suas práticas permite uma aplicação de forma variada, e este é um dos seus aspectos positivos – a adaptabilidade. O Scrum torna-se ideal para projetos dinâmicos e suscetíveis a mudanças de requisitos, sejam eles novos ou apenas modificados, e para isso é necessário entender bem seus papéis, suas responsabilidades, seus conceitos e cada fase do seu ciclo.

Bibliografia

www.google.com : tópicos: Scrum, engenharia de software + scrum;

www.wikipedia.com; tópico: Scrum;

Paula, Renata de Souza Alves: artigo publicado na “Engenharia de Software Magazine”, edição 23, página 8.

PS: para ilustrações, entrar em contato. Grato!!!