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: [email protected]: http://jean-streleski.blogspot.commsn: [email protected]
Top Related