Open UP - Papéis e artefatos

Prosseguindo com os estudos de Open UP, este post irá abordar os papéis propostos pela metodologia, mostrando quais são os artefatos relacionadas a cada um dos papéis.

Durante o processo de criação de um software diversas pessoas interagem com o projeto. Estas pessoas tem visões, perfis e responsabilidades diferentes.

Uma equipe é considerada ideal quando consegue trabalhar estas diferenças de uma forma colaborativa, buscando o que há de melhor em cada um.

Os papéis propostos na Open UP são extremamente válidos pelo fato de serem perfeitamente adequados para pequenas e médias equipes, sem o inchaço de papéis sugeridos no RUP, por exemplo.

A imagem abaixo mostra os papéis e como estes se relacionam seguindo os conceitos da metodologia.

Percebemos a existência de seis papéis, trabalhando com foco em três áreas gerais de atuação, através de um ambiente de comunicação e colaboração.

Os papéis,

• StakeHolder -Este papel representa o cliente, o interessado no desenvolvimento do projeto. Sua participação é essencial durante todo o ciclo do projeto, para a coleta de requisitos, definição de prioridades, avaliação das versões entregues, feedback das versões apresentadas. Apesar desta importância, inicialmente, o stakeholder não terá a responsabilidade de gerar artefatos durante o processo. Ele é considerado participante indireto na confecção de outros artefatos.

(http://www.epfwiki.net/wikis/openup/openup/roles/stakeholder_9FFD4106.html?nodeId=c89d2426)

• Analista - O papel do Analista no Open UP é chave no processo de captação das necessidades do cliente, fazendo a função de coletar, organizar, filtrar e apresentar à equipe os requisitos do cliente. É responsável direto pela tarefa de definição do documento de visão, pelo captação dos requisitos em alto nível e pelo detalhamento dos requisitos, através de casos de uso, por exemplo. Durante este processo, ele será responsável direto pelos seguintes artefatos: Documento de Visão, Glossário, Especificação dos Requisitos e o Modelo de Casos de Uso. É co-participante em várias outras tarefas e artefatos.

(http://www.epfwiki.net/wikis/openup/openup/roles/analyst_39D7C49B.html?nodeId=fcd72964)

• Arquiteto - Papel responsável por definir a arquitetura do software, tomando decisões sobre de frameworks, ambientes de desenvolvimento, decisões que influenciarão diretamente o design da solução. O arquiteto deverá cuidar da tarefa de gerar a especificação inicial da arquitetura e o mais importante: mante-la alinhada durante o andamento do projeto. Embora estas duas tarefas possam parecer simples, a especificação do Open UP mostra uma série de passos para a manutenção de uma arquitetura eficiente. Além destas duas tarefas iniciais, é responsável direto pelo desenvolvimento da solução, por mitigar riscos de projeto e arquiteturais. Entendo que ele devem ter um skill técnico muito bom. É responsável direto pelo artefato chamado Documento de Arquitetura. Além disto, deve participar da geração de diagramas UML que sejam necessários durante o curso das iterações.

(http://www.epfwiki.net/wikis/openup/openup/roles/architect_E7A12309.html?nodeId=da2d9c24)

Outra Leitura recomendada: (http://josepaulopapo.blogspot.com/)

• Desenvolvedor - Responsável pelo desenvolvimento do projeto, pela codificação, participando diretamente também da fase de testes das iterações. Responsável pelas tarefas de design da solução através de diagramas UML, codificação, testes do desenvolvedor, integração e liberação dos builds. Seus artefatos são Diagramas de Design, Implementação, testes do desenvolvedor e build.

(http://www.epfwiki.net/wikis/openup/openup/roles/developer_C633AB7.html?nodeId=3de31ca6)

• Gerente de Projeto - Tem a função de "limpar os trilhos" para o andamento do projeto. Suas atividades são relacionadas ao cotidiano do projeto, objetivando manter a comunicação com o StakeHolder e focando em ter a equipe determinada a cumprir os prazos, cumprir requisitos. Tem a tarefa de gerar e manter o plano do projeto, participar do planejamento e do gerenciamento das iterações, de mostrar valor continuamente ao cliente. É responsável direto pelos seguintes artefatos: Plano de Projeto, Lista de Riscos, Work Itens List e Plano de Iteração.

(http://www.epfwiki.net/wikis/openup/openup/roles/project_manager_E657F936.html?nodeId=6547a862)

• Tester - Embora este seja um papel não muito valorizado em equipes (inclusive na minha hehehe), é extremamente válido e importante que exista o papel do Tester. Digo isto, baseado na minha experiência como programador. Nunca testava aquilo que eu supunha que o usuário ia fazer. E o usuário sempre faz!!! Para equipes que não tem recursos para manter um pessoa apenas para testes, recomendo que se faça uso de uma outra pessoa para efetuar os testes que não seja o desenvolvedor. O problema é que este papel delega três novos artefatos e tarefas. São os artefatos: Caso de Teste, Log de Teste, Script de Teste.

(http://www.epfwiki.net/wikis/openup/openup/roles/tester_9859B590.html)

É extremamente recomendável que sejam lidos também os links para cada papel e artefato diretamente da fonte, ou seja, da library do Open UP.

Espero que aproveitem!!

Postem dúvidas, críticas, correções e sugestões!!

Até mais!!

Project Koach - Análise de ferramenta para Gerência de Projetos baseados em Open UP

Boas notícias!!

Desde que iniciei os estudos de Open UP tive a preoucupação de ter o auxílio de alguma ferramenta que pudesse controlar o projeto.

Gerenciar artefatos, tarefas, cronograma utilizando ferramentas diversas e disconexas é um trabalho pra lá de complicado.

E a boa notícia apareceu quando vi uma notícia no blog do José Paulo Papo (http://josepaulopapo.blogspot.com/ ) falando do lançamento de duas ferramentas para gerência de projetos, a Project Koach e a Mingle.

Rapidamente isto me animou, ainda mais pelo fato das ferramentas serem livres.

Fiz o download de ambas e consegui fazer uma prévia avaliação da Project Koach.
(Download em : http://www.projectkoach.com/ )

A ferramenta é extremamente leve, com um visual bastante simples (e até meio "feinho"), porém parece cobrir boa parte das tarefas de gerenciamento de projetos.

Me animou o fato dela ser voltada especificamente para Open UP, facilitando assim a distribuição dos requisitos entre iterações, a criação de tarefas e até mesmo dos micro incrementos ( através das "Task's Steps).

A figura abaixo mostra o painel principal da ferramenta:

Um recurso que gostei bastante foi o fato de conseguir fazer Drag'n-Drop entre os painéis, permitindo arrastar requisitos para iterações já criadas.

Outro destaque foi a possibilidade de anexar documentos a notas criadas, ligando-as a tarefas ou requisitos. Isto é extremamente útil para manter ligados documentos do Word a requisitos, casos de uso descritivos, por exemplo.

É uma ferramenta que rodam localmente, portanto para ser acessada por toda equipe deverá estar em um repositório público, podendo ser um cvs, subversion ou Source Safe, por exemplo.

Vale a pena a avaliação da ferramenta. O site do Project Koach mostra funcionalidades específicas para cada papel proposto no Open UP. Com isto, fica fácil identificar a melhor utilização para cada pessoa da sua equipe.

Vou fazer a avaliação da Mingle e posto aqui as primeiras impressões.

Até mais!!

Open UP - Ciclo de Iterações

E ae Pessoas!!

Dando sequência ao workshop de Open UP, vou falar a respeito da organização e funcionamento do ciclo de iterações, pilar de qualquer metodologia que se intitule ágil.

O termo iterativo e icremental nos dá a idéia de algo continuamente em evolução, algo que vem de encontro com a filosofia oriental conhecida como Kaizen (http://pt.wikipedia.org/wiki/Kaizen). Esta filosofia mostra que o dia de amanhã pode e deve ser melhor que hoje!

Filosofias orientais a parte, a idéia é esta mesmo. A próxima iteração deve provar mais valor que a anterior ao cliente e isto deve ocorrer continuamente.

Esta abordagem é extremamente saudável para a equipe, haja vista que todos terão objetivos a curto prazo, estarão focados na entrega da próxima iteração, tendo uma meta que é tangível. Saem de cena programadores desmotivados, codificando algo que só será validado dali a alguns meses. Esta situação cria um ambiente onde a qualidade deixa de ser um opcional ao produto e passa a ser uma constante, já que em breve o código escrito irá ser validado e posto em testes pelo cliente.


No Open UP, isto é organizado à partir dos conceitos básicos que vimos no post anterior, ou seja, através de uma forte participação do cliente no processo de definição de prioridades.

Cada iteração objetiva a entrega de uma versão de software funcional e testada.

E como surgem as iterações?

(Para melhor exemplificar a organização das iterações, vou falar aqui sobre alguns artefatos gerados durante o processo de desenvolvimento. No próximo post, estes serão abordados em detalhes.)

1. Coleta de requisitos e geração do Documento de Visão, onde estarão listados os requisitos levantados junto ao cliente, através de uma abordagem inicial, em alto nível, quase que em modelo contratual.


2. À partir deste documento e dos requisitos em alto nível, cabe ao Gerente de Projeto criar um Plano de Projeto. Este artefato deve ter o tamanho de cada iteração, o número de requisitos que será entregue ao final de cada iteração. Com isto, é possível termos uma estimativa em alto nível de todas iterações do projeto. Dentro de cada iteração, os itens serão trabalhados à partir da Work Items List.

Cada iteração agora será trabalhada abordando todas as fases sugeridas pelo Open UP. São elas: Inception, Elaboration, Construction, Transition. Ou seja, para cada conjunto de requisitos que compõe uma iteração, teremos o refinamento do requisito, a escrita dos casos de uso, a criação dos diagramas UML que identificam processos, focando na arquitetura, a escrita do código e finalmente os testes e a liberação da versão estável da iteração, o milestone.

Antes do início de cada iteração é feito o Iteration Plan, onde são listados os objetivos da iteração, a atribuição de tarefas para a equipe e a criaçaõ do Work Itens List para a iteração.

Ao final de cada Iteração, será feito o review da iteração, identificando os riscos que foram mitigados, as lições aprendidas. Isto é feito de forma rápida e guardada na forma de artefato para futuras consultas.

Desta forma, visualizamos os conceitos básicos do ciclo de iterações no Open UP. Ainda tenho algumas dúvidas quanto a geração e organização da lista de iterações. Em breve estarei postando as dúvidas aqui, caso não consiga solucioná-las através de estudos que venho realizando.

Conforme comentei acima, o próximo post irá abordar os artefatos e suas relações com os papéis definidos na metodologia.

E em um quarto post, serão exploradas em detalhes as fases de cada iteração.

Estou bastante animado com os estudos e o entendimento da equipe frente aos conceitos apresentados. Consegui um espaço para apresentação do Open UP na Jornada de Informática que será realizada no Campus da Unesp Bauru, na terceira semana de outubro. Em breve estarei divulgando datas e horários, além do conteúdo da apresentação.

Aproveitem e bons estudos!!

Open UP 1.0 - Hello World!!!

E ae pessoal!!

Estou devendo a continuação do post anterior. Já comecei escrevê-lo, porém estou meio atarefado com migração de servidores esta semana. Em breve ele estará aqui.

Vou aproveitar o blog para compartilhar publicamente um workshop que estou fazendo aqui na equipe sobre Open UP, de forma que esta se torne nossa metologia de gerência e desenvolvimento de projetos.

Estou em fase de estudos ainda, então caso notem alguma inconsistência no que for escrito, me corrijam através de comentários.

O Open UP foi criado com o intuito de ser uma abordagem mais "clean" do RUP, abordagem comercial do Unified Process mantida pela IBM e oferecida com suas ferramentas de produtividade.

Embora o RUP possa ser considerado um processo ágil, acredito que a abordagem comercial e de MKT da IBM, que não deixava clara a possibilidade de adaptação e flexibilidade do RUP, acabou criando grandes críticas ao produto IBM.

O Open UP é uma metodologia ágil que atende vários princípios do manifesto ágil (http://agilemanifesto.org/) , além de atender as características essenciais do Unified process, com abordagem iterativa e icremental, baseando-se em casos de uso, cenários e forte comunicação na equipe e com o cliente.

O que me chama mais atenção no Open UP é que ele consegue ser ágil, sem os radicalismos (na minha humilde opinião) proposta por metologias como XP, por exemplo, onde quase que a maioria dos artefatos são ignorados e o foco é apenas em codificação

Mas isto é história para outro post....

Abaixo são listados os princípios básicos do Open UP (transcrição livre) e como eu enxergo a aplicação deles no cotidiano de uma equipe:

• Colaboração, compartilhamento de informações e entendimento - Este princípio rege que toda a equipe envolvida no processo deve compartilhar informações de uma forma única, sem restrições. Isto envolve o cliente também. Um desenvolvedor pode e deve conhecer o escopo do projeto em que ele trabalha, por exemplo, através da utilização de um repostiório de projeto, por exemplo. Neste sentido, fico receoso quanto ao conceito de "fabrica de software".

• Trabalhar com prioridades alinhadas a necessidade de mostrar valor continuamente ao cliente - Pense em um cliente que paga por um projeto e só vai ver uma tela com o logo dele após 1 ano, 6 meses....Ou então ele até vê, porém não consegue acompanhar o andamento, dar sugestões, utilizar o sistema. Isto é péssimo para você pois o final do projeto pode ser tarde demais para perceber que o que o cliente falou há um ano atrás, lá na "fase de análise", não é pra ser dar forma como foi feito. Isto é péssimo para o cliente que não conseguirá visualizar valor real no produto que está sendo construído.... À partir disso, o Open UP sugere através da sua abordagem iterativa e incremental mostrar real valor ao cliente ao longo do projeto, através de entregas de build's completos, prontos para utilização e testes por parte do cliente.

• Pensar na arquitetura o quanto antes, minimizando riscos - Este é um princípio que entendo ser até o mais simples de ser seguido em projetos de software, já que ao meu ver, a arquitetura nasce antes do início das linhas de código e é aperfeiçoada durante as iterações. Li e reli a library do Open UP, e ainda fiquei com dúvidas se é uma prática tão simples assim. Para mim, parace óbvio, óbivio demais até...daí a dúvida... De qualquer forma, não adianta pensar em arquitetura apenas para usar o último framework do mercado, a arquitetura tem que ser um suporte para que se atenda uma necessidade do negócio do cliente. Lembre-se: Seu cliente quer saber de resultados palpáveis e raramente se seu framework é a versão 3.0 ou 2.1.

• Obter feedback continuamente - Este princípio rege a necessidade de provar valor ao cliente continuamente e receber retorno do que foi entregue, com avaliações formais da iteração. Simples não? Talvez, se você não tiver medo de perguntar ao cliente o que ele achou ...rs ...É sério! Muitas vezes fiquei receoso em escutar do cliente o que ele achou por medo de mudanças!! Mas lembre-se! Encare as mudanças como algo inevitável num processo de desenvolvimento de software. Esqueça a blindagem do seu projeto!!

Bom, este post era mais pra dar início ao Workshop sobre Open UP.

Gostaria muito de contar com comentários e críticas do pessoal que estuda e utiliza esta metodologia.

No próximo post sobre Open UP, falarei sobre os papéis de uma equipe propostos pelo Open UP.

Um abraço!!!

Justificando o investimento em TI

E ae Pessoal!!

Em minha experiência na área de TI, desde quando eu era um estagiário que desenhava telas em Delphi 4.0, eu sempre me deparei com as famosas perguntas de clientes....

"Mas porque eu vou investir no seu programa se o meu hoje funciona tão bem?"

ou então

"Seu sistema não vai me trazer economia alguma! Apenas me fará gastar um bom dinheiro "

Ou seja, as empresas de TI, em especial as pequenas empresas, estão com dificuldades para provar o valor do investimento em TI.

Empresas consumidoras de serviços de TI geralmente não se importam muito se você utilizou uma arquitetura distribuída baseada em SOA (a moda do momento :) ) ou se você usou uma simples arquitetura client-server pois para eles a TI é um meio para se atingir objetivos do negócio, objetivos relacionados a economia ou aumento de lucratividade.

Neste momento, na apresentação de um projeto, você gerente de TI deve justificar e provar o retorno financeiro de seu projeto.

Qual o alinhamento do seu projeto de TI com as estratégias de negócio da empresa ?
Em quanto tempo a empresa terá o retorno financeiro do investimento em seu projeto?

Estas são questões que devem ser respondidas de bate e pronto por um gestor de TI, principalmente com a infinidade de técnicas e ferramentas que nos auxiliam neste trabalho.

Recentemente fiz um ótimo curso de Formação de Analistas de Negócios, com o também ótimo Paulo Vasconcellos (O blog do Paulo: http://finito-log.blogspot.com/) onde pude conhecer várias técnicas relacionadas a redesenho de processos, análise de negócios, técnicas de justificativa de projeto, dentre outras informações muito valiosas.

Após o curso comecei um trabalho de apresentação de um projeto de integração do sistema aqui da empresa com empresas terceiras. Estas empresas são gigantes em seus segmentos e tinha certeza que o projeto só teria sucesso se o investimento no projeto fosse realmente provado em sua eficácia e retorno.

Este trabalho de justificativa do projeto já foi apresentado as empresas e estou tendo um bom retorno.

Estarei detalhando os itens apresentados neste trabalho de justificativa de projeto no próximo post, bem como colocando algumas dúvidas que ainda tenho no assunto.

Um abraço a todos!!

Enjoy It!!

Boas Vindas!!

Este é um post inicial que estou usando para testar o layout!!
Em breve, conteúdo, atendendo aos milhares, eu dissseeee, milhares de pedidos de post's!!!
rs