JORNADA DA INFORMÁTICA - UNESP BAURU

O que é Open UP? Core Principles Ciclo de Iterações Ciclo do Projeto Papéis e Artefatos Informações Adicionais Dúvidas

Apresentação, origem e situação atual

Experiência dos participantes

Metodologias conhecidas

Áreas de atuação

Motivação pessoal para estudo

Teve suas origens no Rational Unified Process(RUP), processo proprietário da IBM, embasado em um framework de processos

Abordagem mais “clean” do RUP

Foi de encontro as necessidades de pequenas e médias equipes, com uma abordagem agilista (Manifesto Ágil)

Metodologia Ágil baseada nos princípios do Unified Process

Abordagem Iterativa e Incremental

Baseada em Casos de Uso, cenários e com foco na comunicação entre equipe e cliente

Open Source: Extensível e adaptável

Mantido pela Eclipse Foundation

É essencial a participação direta do stakeholder como membro da equipe

Encontra-se atualmente na versão 1.0, recentemente lançada (Agosto 2007)

Lançada inicialmente pela IBM e após a liberação do código, mantida pela Eclipse Foundation

Library Open Source disponível para download e extensível através do uso do EPF (Eclipse Process Framework)

Os quatro conceitos chaves

“Balance competing priorities to maximize stakeholder value ”

Prioridades definidas junto ao cliente

Business Centric X Architecture Centric

Metodologia Iterativa e Incremental – Prova constante de valor

Três fatores de entendimento entre equipe e cliente: O Problema a ser resolvido

Custos, Recursos, Cronograma do Projeto

Funcionalidades da Solução

“Balance competing priorities to maximize stakeholder value ”

Práticas Conheça muito bem seu cliente e o que ele quer, mantendo-o na

“equipe do projeto”

Entenda muito bem o problema antes de pensar na solução

Faça a equipe conhecer o projeto como um todo

Utilize cenários e casos de uso para captura de requisitos

Alinhe prioridades continuamente durante o projeto

Gerencie mudanças naturalmente, elas são inevitáveis!!!

“Collaborate to align interests and share understanding ”

Software é criado por pessoas com diferentes visões e interesses que devem trabalhar juntas;

Desenvolva práticas que criem um ambiente colaborativo, alinhando interesses de toda equipe;

Opõe modelos adotados nas chamadas “Fábricas de Software”

Equipe motivada

“Collaborate to align interests and share understanding ”

Práticas Mantenha um entendimento comum do projeto dentro da equipe

através de artefatos e comunicação clara e pró-ativa

Desenvolva um ambiente saudável onde cada membro da equipegerencie seu próprio trabalho. Transparência e clareza nas atribuiçõese responsabilidades

Compartilhe responsabilidades permitindo que todos da equipe se sintam parte do projeto

Aprendizado contínuo – Workshops internos

“Focus on the architecture early to minimize risks and organize development ”

Foco na arquitetura do sistema no início do projeto

O foco na arquitetura auxilia a equipe a avaliar complexidade, mitigar riscos arquiteturais e organizar o desenvolvimento

A arquitetura deve ser a o alicerce do sistema, o meio para se chegar ao fim, que é o objetivo do negócio

A arquitetura deve ser dirigida a atender as necessidades de negócio

“Focus on the architecture early to minimize risks and organize development ”

Práticas Pense em uma arquitetura para aquilo que se conhece hoje, sem

querer prever o futuro – Business Centric

Use a arquitetura como uma forma de centrar os desenvolvedores no objetivo do projeto

Organize a arquitetura evitando acoplamento e com componentesreutilizáveis

Reuse e aprenda com componentes de outros projetos

“Evolve to continuously obtain feedback and improve ”

Promova práticas que permitam a equipe obter feedback e provar valor continuamente ao cliente

Gerenciamento de Mudanças - Através do feedback contínuo, as mudanças tem um impacto muito menor

A equipe sente-se motivada e participante direta do projeto

Esqueça a blindagem do seu projeto!!

“Evolve to continuously obtain feedback and improve ”

Práticas Desenvolva o projeto em iterações

Foque a equipe na entrega do próximo build

Gerencie os riscos continuamente à partir do feedback obtido

Gerencie as mudanças de seu projeto

Meça o progresso continuamente, permitindo o redimensionamentode recursos

Faça encontros regulares com a equipe, absorvendo idéias e resolvendo problemas de cotidiano

Organização e geração das iterações

As iterações no Open UP agrupam um ou mais requisitos em períodos fixos, de um mês em média

Uma iteração contempla todas as fases da construção do software

Ao final da iteração, uma versão do software rodando é entregue ao cliente, comprovando o trabalho realizado até então

A montagem das iterações é umas das disciplinas mais complicadas na adoção de uma metodologia iterativa e incremental

Cada iteração é composta por vários itens de trabalho. Exemplo: Modelar banco, desenvolver camada de acesso a dados, etc;

Para cada item de trabalho, o membro da equipe cria os seus micro incrementos

O micro incremento entrega código e/ou artefato diariamente para agregar valor a iteração

Através dos micro incrementos, o arquiteto pode avaliar a qualidade do código produzido pelos desenvolvedores

Para as n iterações do projeto, repetem-se as ações abaixo:

O Ciclo completo do projeto

É durante o ciclo de vida do projeto que os artefatos serão gerados, permitindo ao stakeholder e a equipe, tomarem decisões a cerca do negócio, do projeto, dos riscos que envolvem o processo de desenvolvimento

Um projeto é composto por várias iterações

O projeto é organizado em quatro fases e cada iteração pode conter as mesmas fases que organizam o projeto

Fase 1 – Inception - Esta fase objetiva a criação de uma visão geral do problema a ser resolvido, propor os pontos chaves do sistema, sugerindo ao menos uma solução, baseando-se em variáveis como custo, cronograma e recursos

Fase 2 – Elaboration – É nesta fase em que a equipe se preocupará com o detalhamento dos requisitos e como a arquitetura proposta irá trabalhar com os requisitos. Neste momento a equipe deverá mitigar riscos técnicos e não técnicos, alinhando as ações junto ao stakeholder

Fase 3 – Construction - Aqui, efetivamente, o sistema será desenvolvido, focando em atender requisitos propostos pela iteração. Ao final desta fase, será entregue uma versão estável e testada do sistema

Fase 4 – Transition – O foco nesta fase é fazer a transição da versão nova do software do ambiente do desenvolvimento para o stakeholder. Aqui são realizados e aplicadas técnicas de testes, de forma que o software entregue na iteração seja totalmente funcional

Redução do risco e criação constante de valor

A relação entre os papéis e artefatos

Uma boa equipe conta com profissionais com diferentes habilidades

Open UP sugere a divisão de responsabilidades em papéis. Cada papel irá trabalhar com um ou mais artefatos

Artefato é qualquer tipo de saída do processo de desenvolvimento de software, seja ele código, diagrama ou documentação

O stakeholder representa o real interessado no projeto. Pode ser uma pessoa ou um grupo de pessoas representando uma instituição

O stakeholder deve participar ativamente de todas as fases do projeto

Não é responsável direto por nenhum artefato, porém participa indiretamente da confecção e avaliação de outros artefatos

Responsável por ser o elo de ligação entre o cliente e a equipe.

Em uma nova abordagem, tem o foco no negócio, Analista de Negócio

A interação do Analista com os artefatos

Responsável pela modelagem da solução, a arquitetura do software

Deve coordenar tecnicamente os desenvolvedores

A interação do Arquiteto com os artefatos

Responsável pelo desenvolvimento do software, incluindo seguir a arquitetura proposta, implementando testes unitários, garantindo a qualidade do código desenvolvido

A interação do Desenvolvedor com os artefatos

Responsável pela equipe de projeto, coordenando a interação com o stakeholder, mantendo a equipe focada no projeto

Deve ter um perfil de liderança e organização

A interação do Gerente de Projeto com os artefatos

Responsável imediato pela avaliação de cada versão do software liberada para o stakeholder

Deve coordenar os testes de forma sistemática, notificando a equipe dos resultados e sugerindo correções

A interação do Tester com os artefatos

Ferramentas de apoio e referências

Por ser uma ferramentas open source e relativamente nova, existem poucas ferramentas de apoio ao gerenciamento do projeto.

Recentemente foram lançadas duas ferramentas, a Project Koach e a Mingle.

Análise da Project Koach, em meu blog

Documentação completa para consulta on-line e também para download http://www.epfwiki.net/wikis/openup/index.htm http://www.eclipse.org/epf/downloads/openup/openup_downloads.php

EPF Composer – Ferramenta baseado na plataforma Eclipse para extensão do OpenUP

http://www.epfwiki.net/wikis/openup/index.htm

Project Koach – Ferramenta de apoio ao gerenciamento do projeto http://www.projectkoach.com/

Blogs com conteúdo sobre OpenUP e metodologias Meu Blog - http://jean-streleski.blogspot.com José Paulo Papo - http://josepaulopapo.blogspot.com/ Paulo Vasconcellos - http://finito-log.blogspot.com/

Manifesto Ágil http://agilemanifesto.org/

E-mail: jrs.net@gmail.comBlog: http://jean-streleski.blogspot.commsn: jeanjrs@hotmail.com