Metodologias de Desenvolvimento

de Software Integradas

Frank CoelhoEspecialista em desenvolvimento de software.

Solução organizacional para otimização de processosde desenvolvimento de software,

visando o desenvolvimento com qualidade com foco na entrega.

Tecnologias

• Linux• Apache• MySQL• PHP

• C#• VB.NET• SharePoint• Project

Server• Exchange

Server• Windows

Server

• JBossApp Server

• Oracle Weblogic

• Hibernate• Spring

Framework• Struts

Framework

• Oracle• PostgreSQL• IBM DB2• MySQL

Java DatabaseMicrosoft .N

ET

LAMP

Tópicos abordados

* Problemas comuns em projetos de desenvolvimento de software.

* O que é uma metodologia?

* Metodologias para desenvolvimento de software.

Problemas comuns em projetos de desenvolvimento de software.

Falhas de Comunicação

Estatísticas

Motivos

• Consomem mais recursos que o orçado;

• Consomem mais tempo que o estimado;

• Não entregam o que foi combinado;(+) 500 mil projetos (pequeno - grande porte) de software nos Brasil.

Para resolver esses problemas, seguimos uma metodologia.

O que é uma Metodologia?

Padrões

Comunicação

Objetivo comum

Aproveitamento recursos

Metodologia

Equipe

Metodologias para Desenvolvimento de Software

• Metodologia tradicional: PDI-SW (Processo de Desenvolvimento Iterativo de Software)

• Metodologia ágil: SCRUM

SCRUM

• Metodologia de desenvolvimento ágil nascida em empresas de fabricação de carros em 1986 (Takeuchi e Nonaka).

• Jeff Sutherland, John Scumniotales, e Jeff McKenna – documentaram e implementaram - Easel Corporation em 1993.

• Tipo de formação do Rugby.

• Passou a ser utilizado no mundo a partir de 1995.• Aborda uma filosofia de gerenciamento com foco no resultado.

Sprint

• Cada sprint é uma iteração que segue um ciclo e entrega incremento de software pronto.

• Um backlog é conjunto de requisitos, priorizado pelo Product Owner (responsável pelo ROI “retorno sobre investimento” e por conhecer as necessidades do cliente);

• Há entrega de conjunto fixo de itens do backlog em série de interações curtas ou sprints;

• Breve reunião diária, ou daily scrum, em que cada participante fala sobre o progresso conseguido, o trabalho a ser realizado e/ou o que o impede de seguir avançando (também chamado de Standup Meeting ou Daily Meeting, já que os membros da equipe geralmente ficam em pé para não prolongar a reunião).

• Breve sessão de planejamento, na qual os itens do backlog para uma sprint (iteração) são definidos;

• Retrospectiva, na qual todos os membros da equipe refletem sobre a sprint passada.

BACKLOGPlanejamento de sprint (Sprint Planning): Antes de todo sprint, o Product Owner, o Scrum Master e a Equipe decidem no que a equipe irá trabalhar durante o próximo sprint. O Product Owner mantém uma lista priorizada de itens de backlog, o backlog do produto, o que pode ser repriorizado durante o planejamento do sprint. A Equipe seleciona itens do topo do backlog do produto. Eles selecionam somente o quanto de trabalho eles podem executar para terminar. A Equipe então planeja a arquitetura e o design de como o backlog do produto pode ser implementado. Os itens do backlog do produto são então destrinchados em tarefas que se tornam o backlog do sprint.Product BacklogUm backlog é uma lista de itens priorizados a serem desenvolvidos para um software. O Product Backlog é mantido pelo Product Owner e é uma lista de requisitos que tipicamente vêm do cliente. O Product Backlog pode ser alterado a qualquer momento pelo Product Owner ou por decisão deste.Sprint BacklogO Sprint Backlog é uma lista de itens selecionados do Product backlog e contém tarefas concretas que serão realizadas durante o próximo sprint para implementar tais itens selecionados. O Sprint Backlog é uma representação em tempo real do trabalho que o Development Team planeja concluir na sprint corrente, e ele pertence unicamente ao Development Team.Burndown ChartO Burndown é um simples gráfico, com dois eixos X e Y, baseado nas atividades que não ultrapassem um dia de trabalho. O eixo X indica o número de tarefas existentes no Sprint e o eixo Y os dias que representam o tamanho do Sprint.

Os papéis principais em equipes Scrum são aqueles comprometidos com o projeto no processo do Scrum - são os que produzem o produto (objetivo do projeto).

Product Owner (dono do produto)O Product Owner representa a voz do cliente e é responsável por garantir que a equipe agregue valor ao negócio. O Product Owner escreve centrado nos itens do cliente (histórias tipicamente do usuário), os prioriza e os adiciona para o product backlog. Equipes de Scrum devem ter um Product Owner, e, embora esse possa também ser um membro da equipe de desenvolvimento, recomenda-se que este papel não seja combinado com o de ScrumMaster.Equipe (Development Team)A equipe é responsável pela entrega do produto. A equipe é tipicamente composta de 5-9 pessoas com habilidades multifuncionais que fazem o trabalho real (analisar, projetar, desenvolver, testar técnicas de comunicação, documentos, etc.) Recomenda-se que a equipe seja auto-organizada e auto-conduzida, mas que muitas vezes trabalhem com alguma forma de projeto ou gestão de equipe.Scrum MasterScrum é facilitado por um Scrum Master, que é responsável pela remoção de impedimentos à capacidade da equipe para entregar o objetivo do sprint / entregas. O Scrum Master não é o líder da equipe, mas age como um tampão entre a equipe e qualquer influência ou distração. O Scrum Master garante que o processo Scrum seja usado como pretendido. O Scrum Master é o responsável pela aplicação das regras. Uma parte fundamental do papel do Scrum Master é proteger a equipe e mantê-la focada nas tarefas em mãos. O papel também tem sido referido como um líder-servo para reforçar essa dupla perspectiva.

Papéis principais

Obrigado!

Proposta.• Usar os pilares fundamentais do RUP e seus conceitos e

métodos, unificado com as melhores praticas do CMMI. Definição de processo organizacional sobre a gestão do SCRUM.

• Utilizar aspectos básicos definindo um mínimo de documentação inicial tanto quanto necessário.

• Foco na entrega com garantia de qualidade.

• Reuso de artefatos e funcionalidades (Frameworks)

• Formar muito mais que um time, um grupo de pessoas com os mesmos objetivos e que acreditem no negocio.

Pilares do RUP

Gráfico de esforço nas fases

Concepção Esta fase do RUP abrange as tarefas de comunicação com o cliente e planejamento. É feito um plano de projeto avaliando os possíveis riscos, as estimativas de custo e prazos, estabelecendo as prioridades, levantamento dos requisitos do sistema e preliminarmente analisá-lo. Assim, haverá uma anuência das partes interessadas na definição do escopo do projeto, onde são examinados os objetivos para se decidir sobre a continuidade do desenvolvimento.

Elaboração Abrange a Modelagem do modelo genérico do processo. O objetivo desta fase é analisar de forma mais detalhada a análise do domínio do problema, revisando os riscos que o projeto pode sofrer e a arquitetura do projeto começa a ter sua forma básica. Indagações como “O plano do projeto é confiável?”, “Os custos são admissíveis?” são esclarecidas nesta etapa.

Fase de Construção: Desenvolve ou Adquire os componentes de Software. O principal objetivo desta fase é a construção do sistema de software, com foco no desenvolvimento de componentes e outros recursos do sistema. É na fase de Construção que a maior parte de codificação ocorre.

Fase de Transição: Abrange a entrega do software ao usuário e a fase de testes. O objetivo desta fase é disponibilizar o sistema, tornando-o disponível e compreendido pelo usuário final. As atividades desta fase incluem o treinamento dos usuários finais e também a realização de testes da versão beta do sistema visando garantir que o mesmo possua o nível adequado de qualidade.

Fase de Concepção • Finalidade– Definir objetivos e viabilidade do projeto (o ideia do projeto) e o escopo de vários aspectos• Atividades– Definir: critérios de sucesso de projeto, riscos, recursos necessários e data de realização dasprincipais etapas– Delimitar o escopo do projeto– Identificar os atores que interagem com o sistema– Identificar as interações dos atores com o sistema (casos de uso)• Resultados (artefatos)– Documento de visão: visão geral dos requisitos, características e restrições essenciais doprojeto.– Modelo inicial de casos de uso (10%-20%).– Glossário do projeto (opcionalmente um modelo de domínio).– Definição de objetivos e viabilidade do projeto incluído contexto, critérios de sucesso e prognóstico financeiro.– Avaliação inicial de riscos.– Plano de projeto, com fases e interações.– Modelo de negócios, se necessário.– Um ou vários protótipos.• Critérios de Satisfação– Concordância quanto à definição de escopo e estimativas de custo e cronograma.– Compreensão dos requisitos funcionais.– Credibilidade das estimativas de custo, cronograma, prioridades, riscos, e processo dedesenvolvimento.– Profundidade e amplitude dos protótipos desenvolvidos.– Custos planejados versus realizados.

Fase de Elaboração• Finalidade– eliminar os elementos de maior risco do projeto através da criação de uma arquitetura coerentee consistente da solução• Atividades– Construir protótipos executáveis, em uma ou mais interações– Atacar os casos de uso críticos, que expõe os maiores riscos técnicos– Construir protótipos evolucionários ou descartáveis, com objetivo de analisar custos-benefícios,demonstrar para investidores, clientes e usuários• Resultados (artefatos)– Modelo de casos de uso (80% ou mais).– Requisitos não funcionais– Descrição da arquitetura do software– Protótipos arquiteturais executáveis– Revisão da visão de negócios e lista de riscos– Plano detalhado de desenvolvimento do projeto, com interações e critérios de avaliação– Plano de processo de desenvolvimento– Manual de usuário preliminar• Critérios de Satisfação (para suporte à decisão sobre continuar ou não com o projeto)– A visão do produto é estável?– A arquitetura é estável?– A demonstração executável mostrou que os elementos de maior risco foram abordadossatisfatoriamente?– O plano de desenvolvimento está suficientemente detalhado e preciso? O plano é consistente ecoerente?– Todos os interessados concordam quando à coerência entre visão, plano e arquitetura?– Os custos planejados e executados estão aceitáveis?

Fase de Construção• Finalidade– Desenvolver todos os componentes e características não resolvidas nas fasesanteriores, testando-as e integrando-as na forma de um produto.• Atividades– Diversas• Resultados (artefatos)– O produto, descrito e integrado nas plataformas adequadas• Critérios de Satisfação– A release do produto é suficientemente estável e amadurecida para ser entregue aousuário?– Todos os envolvidos e interessados estão preparados para a fase de transição?– O consumo de recursos é ainda aceitável?

Fase de Transição • Finalidade– Realizar a transição do produto para a comunidade de usuários• Atividades– “beta teste”– Operações paralelas com sistema legado– Conversão de bases de dados– Treinamento de usuários a mantenedores– Roll-out para setores de marketing, distribuição e vendas• Resultados (artefatos)– Em conformidade com atividades• Critérios de Satisfação– O usuário ainda está satisfeito?– Os custos de manutenção ainda são aceitáveis?

Ferramentas de gerenciamento do ciclo de vida e produção

• Visual Studio• Arquitetura • Dados• Testes

• TFS• Versionamento• Tarefas• Sprints• Backlogs

• Project • Cronograma• Tarefas• Custos

• Studio manager SQL• Modelo de dados

Perfil do time técnico

• Gerente de Projetos• Arquiteto de Software• Analista de requisitos• Analista de sistema• Desenvolvedores• Analista de Testes• Documentador

Fluxo de trabalho

Descrição para as fases

CMMI• CMMI é uma família de conjuntos de melhores práticas para apoiar a

melhoria de desenvolvimento, serviços e aquisição.

• Implementar um modelo baseado nas melhores praticas, levando em conta o cenário especifico e atual da empresa, voltado para melhoria continua e crescimento do grau de maturidade do ciclo de vida da construção de software.

• Processo continuo visando o alcance dos resultados esperados.

• Trabalhar nos detalhes no intuito de evitar esforço desnecessário.

• União das dimensões de construção do CMMI:• Pessoas• Ferramentas• Procedimentos

O que esperar.• Não existe retorno a curto prazo.• Certificação CMMI• Certificação ISO• Controle absoluto de projetos e custos• Baixo Custo de manutenção• Produtos robustos e escaláveis• Melhoria estratégica de posição no mercado• Gerencia de configuração consolidada• Lucros maiores• Ser um caso de sucesso• Atingir a EXCELENCIA

Fazer a coisa certa é uma escolha que deve ser mantida, que exige esforço e comprometimento e o retorno só é visto depois.

Obstáculos são apenas grandes oportunidades de sermos melhores...

Homens comuns contam histórias, homens extraordinários fazem a história...

Referências

• http://www.infoq.com/presentations/The-Roots-of-Scrum

• http://pt.wikipedia.org/wiki/Scrum

• http://www.agilealliance.org/system/article/file/888/file.pdf

• http://pt.wikipedia.org/wiki/IBM_Rational_Unified_Process#Fase_de_Concep.C3.A7.C3.A3o

• http://www.cmmi.de/#el=CMMI-DEV/0/HEAD/folder/folder.CMMI-DEV