OpenUP/Basic: Um framework Ágil e Unificado

O OpenUP é um processo para desenvolvimento de software. Ele surgiu junto com o projeto EPF do eclipse. O EPF é um projeto open source que surgiu de um projeto comercial da IBM Rational o RMC que é uma ferramenta para auditoria e bem como tailoring. O RMC vem com todo o RUP e vários tailorings prontos do RUP. O EPF é a versão open source do RMC.

OpenUP é um processo para o desenvolvimento de produtos de software que agrega muitos conceitos do RUP e adiciona valor e práticas ágeis principalmente de metodologias como o XP e o Scrum. O OpenUP/Basic que é o assunto desse posta se foca em projetos com equipes pequenas.





O OpenUP é baseado em 4 princípios básicos que são: Colaborar para alinhar interesses e compartilhar conhecimento, Focar na articulação da arquitetura, Balancear prioridades concorrentes com o retorno de valor para o Stakeholder e Envolvimento continuo para obtenção de feedback e melhorias.

Como você pode perceber a figura a cima ilustra que através de diversos papéis as pessoas gerenciam e desenvolvem soluções mas como a Comunicação e Colaboração como meio para isso.

O OpenUP/Basic é sub-set do RUP muito enxuto e podemos perceber isso pelos papéis, são apenas 6 papéis. São os 6 da figura a cima :) Outra característica ágil do OpenUP/Basic é que ele se propõe a entregar software com o mínimo de formalismo e artefatos gerados. Isso funciona, mas não é uma bala de prata, dependendo do projeto será necessário adicionar mais atividades e artefatos aos roles, por que ele enxuto pra caramba. A questão está totalmente ligada aos níveis de cerimônia do projeto, por que técnicas mais avançadas necessitam de mais cerimônia. Para muitos projetos ele serve como uma luva! Voltando aos papéis...

Stakeholder: Provavelmente você já deve estar acostumado com o termo. Os Stakeholders são todas as pessoas que estão interessadas no projeto, por que? Você irá atender alguma necessidade delas através de software. No Scrum o Stakeholder é o PO(Product Owner) mas pode ser qualquer outra pessoa, até mesmo uma pessoa da equipe técnica.

Project Manager: Clássico gerente de projetos. Esse cara conduz os planejamentos do projeto em conjunto com a equipe e os stakeholders. Ele matem o foco da equipe para a realização dos objetivos do projeto. Parte das responsabilidades dele o Scrum adiciona no Scrum Master. O Project Manager pode fazer tudo o que um Scrum Master Pode faz, mas um Scrum Master não pode fazer tudo o que um PM(Project Manager, não é polícia Militar :)) faz. Este boneco planeja a iteração (Sprint no Scrum) e planeja o projeto.

OBS: No OpenUP o que seria o Product Backlog é o Work Item List. Na prática é a mesma "coisa".

Voltando ao PM, outro valor interessantíssimo que processo tem é o fato de ser dirigido a Riscos. Então o PM também é responsável pela Lista de Riscos. No OpenUP/Basic é considerado bom ter no máximo 20 riscos na lista. Por que devem estar na lista apenas riscos sérios.

Analyst: Famoso Analista. A pessoa(s) por trás desse papel representa os interesses dos stakeholders e usuários do sistema. Ele é responsável por capturar os requisitos do sistema e bem como definir as prioridades dos mesmos.

Architect: Meu role preferido. Como todos sabem ele é responsável por definir a arquitetura de software, tomando decisões que orientam a equipe tanto de design e implementação.

NOTA: Isso não tem no OpenUP/Basic, mas eu adicionaria a equipe de requisitos. Arquitetura e requisitos são duas disciplinas que andam muito juntas. E como o RUP "já dizia" o arquiteto deve conhecer todos os requisitos do projeto.

Bom o arquiteto no processo gera o artefato que se chama "Architecture Notebook" que é +- o mesmo documento que existia no RUP, mas lá é chamado de SAD(Software Architecture Document). Que no final das contas é o bom e velho modelo 4 + 1. Dentre as práticas recomendada para a criação da arquitetura são destaque:
  • Elevar o Nível de Abstração: Como forma de diminuir a complexidade, devemos utilizar modelos de abstração sempre focando nos pontos mais complicados, como relacionamentos e padrões.
  • Solução Dirigida ao Problema: Esse eu adoro! Devemos dirigir a solução arquitetural aos problemas, ou seja, montar a arquitetura com base nos problemas que existam. O que eu já vi acontecer várias vezes é a tecnologia dirigir a arquitetura, e isso é o principio do fim!
  • Baixo acoplamento e Alta coesão: Bom que já viu uma palestra minha sobre algum tema relacionado ao desenvolvimento pode notar que eu sempre falo disso. É muito básico mas na práticas por incrível que pareça as pessoas não utilizam esse principio.
  • Reutilização de recursos existentes: Essa é figurinha carimbada, mas também não acontece, se pensarmos mais à frente reutilização é tudo, é parte importantes na filosofia SOA e ABD(Asset Based Development).
Developer: Aquilo que todos fomos ou ainda vamos ser :) esse papel dispensa qualquer apresentação. O OpenUP/Basic força uma abordagem semelhante a do XP em relação ao TDD. Logo o desenvolvedor é responsável por efetuar testes também.

NOTA: A melhor maneira de encarar os testadores ou a equipe de testes é como uma equipe de contenção. Sendo assim eles não são a primeira barreira para os erros mas na verdade a ultima barreira. O OpenUP/Basic fecha com esse principio e por conta disso o developer também se "mete" com testes.

Tester: Bom esse cara muitas vezes é odiado pelos desenvolvedores. Na prática isso acontece por que muitos desenvolvedores não tem a cultura de testes ainda. Mas acredito que esse tipo de perfil não dure muito no mercado com o passar dos anos. No processo ele cria os Casos e Testes e implementada os testes. Claro ele roda os testes também!

Agora um pouco mais do OpenUP

Como o OpenUP é um sub-set do RUP ele possui as fases: Concepção, Elaboração, Construção e Transcrição e outras coisas boas do RUP.



E o legal é que ele juntou o planejamento e controle de marcos do RUP com o gerenciamento de iteração e micro-ambiente do Scrum. É isso que a figura a cima mostra. Então temos o gerenciamento de micro-ambiente com o work-item que são as tarefas que o desenvolvedor utiliza, nesse ponto podemos adicionar as Stand Up Meetings do XP ou Dally Scrum Meetings do Scrum e práticas das duas metodologias.

No planejamento da iteração é que entra a maioria das práticas de Scrum, porem adicionadas a diciplina de riscos. Aqui podemos ter as iterações de 2-4 semanas. Aqui o foco é no time e o PM resolver os impeditivos e planejar.

No fim exitste um nível maior que é o planejamento do projeto, onde vai existir o plano do projeto e o controle sobre os meses vs as necessidades que os stakeholders precisão. A idéia do OpenUp é cada vez mais aumentar o valor agregado ao cliente e cada vez mais diminuir os riscos.

Até a proxima :)


Popular posts from this blog

Telemetry and Microservices part2

Installing and Running ntop 2 on Amazon Linux OS

Fun with Apache Kafka