Resultado de uma retrospectiva

Este é o resultado da última reunião de retrospectiva da equipe onde trabalho.

É muito interessante como esse feedback dá um panorama geral do projeto, e não apenas dos desenvolvedores.

A partir desse feedback você pode tomar decisões importantes e impactantes no projeto.

Pra quem não conhece, a retrospectiva tem como objetivos avaliar e melhorar o processo de desenvolvimento.

Os integrantes da equipe desenham, num pedaço de papel:
- uma carinha feliz, pra colocar o que achou legal
- uma triste , pra colocar o que acha que tem que melhorar
- e deixam um espaço em branco, pra colocar o que não foi ruim nem bom.


Avaliação da equipe:

Coisas Boas =)
- Entrosamento da equipe
- Aprendizado (2 vezes)
- Dinamismo entre o grupo (Ambiente de trabalho) (2 vezes)
- Refatoração e testes
- Feedback do cliente
- Fato do projeto começar do zero
- A paciência do Scrum Master
- Flexibilidade de horário
- Liberdade de expressão
- Galera caiu dentro
- Gerência no excel
- Conseguimos atingir a meta no final do ano
- Equipe firme para este ano
- Crescimento do projeto
- Cliente satisfeito

Coisas a melhorar =(
- Pagamento atrasando direto (5 vezes)
- As doideiras que o cliente pede
- Ter que refatorar muita coisa
- Ninguém dava um rolé no sistema no sistema para achar erros e só ficavam perguntando o que tinha pra fazer
- Ninguém ia aos dojos
- Perda de foco nas reuniões com o cliente
- Ausência por alguns momentos do Scrum Master
- Isolamento da equipe do restante da equipe
- Ausência do gerente de projetos
- Falta de enfoque em tarefas gerenciais

Não foi ruim nem bom =|
- Layout "abandonado"
- Ferramentas de trabalho

Atividades para melhoria do processo
- Fazer um diagrama de classe (feito)
- Scrum Master passar feedback dos outros projetos e eventos
- Galera comparecer nos outros projetos e eventos
- Fazer o cliente focar no sistema na planning
- Justificativa da falta no trabalho
- Forçar a equipe a ser mais independente do Scrum Master (auto-gerenciável)
- Criar um mecanismo para nos proteger do atraso no pagamento

Comandos mais usados do svn

Estou criando esta lista pra gente ter sempre à mão os comandos mais usados do svn no terminal, de modo simples e compacto.

* Para mais comandos e detalhes: http://www.tigris.org/scdocs/ddUsingSVN_command-line

checkout (co)
add
del
move (mv)
status (st)
diff
log
revert

update (up)
resolved
commit (ci)


Esteja na pasta que foi realizado o checkout para executar os comandos.

checkout

Baixa o projeto
svn co http://svn.address.com/trunk dest_folder --username user

add

Adiciona um novo arquivo ao versionamento
svn add file

del

Remove um arquivo do versionamento

--keep-local mantém o arquivo localmente, porém fora do versionamento

svn del file --keep-local

moveRenomeia ou move um arquivo no versionamento (deletando o antigo e adicionando o novo)

svn mv orig dest

status

Visualiza se um arquivo será ou foi adicionado, deletado, ou modificado localmente ou no repositório

-u para ver modificações do repositório
svn st -u

diffVisualiza as alterações feitas no arquivo

svn diff file

logVisualiza a mensagem de commit do arquivo

svn log file

revertReverte a alteração local feita no arquivo

svn revert file

update

svn up

resolvedRemove o status de conflito do arquivo

svn resolved file

commitEnvia as alterações para o repositório

svn ci -m message

Resumão OSGI

http://www.springsource.org/training/osgi/online

Spring - DM Server -> Dinamic Modules Server

1-OSGi -> Sistema de modularização dinâmica para Java -> Modularização de verdade

Modular:
-Projetos (módulos), que são chamados de Bundles
-JAR files com meta-data
-Baseado em pacotes
-Versionamento de pacotes e bundles

Dinâmico:
-Adicionar, remover, startar e parar bundles em runtime
-Usa serviços compartilhados para compartilhar objetos, não apenas tipos

"Bundles usam JAR Manifest para meta-data" -> a configuração é feita no Manifest.mf dentro do META-INF

Por default um bundle não consegue enxergar as classes dos outros

Para que um suas classes (tipos) fiquem disponíveis para os outros bundles é necessário exportar seus pacotes

BOAS PRÁTICAS
-Separe as interfaces das implementações
*Coloque-os em pacotes diferentes
*Exporte apenas as API públicas e esconda os detalhes
*Exponha as implementações como serviços
-Versione seus pacotes
*Libere várias versões no mesmo runtime
*Clientes pegam a versão que eles precisarem

Para ter acesso aos tipos dos outros bundles é necessário importar os pacotes disponíveis (você pode especificar um range da versão que quer usar. Ex: "[1.0.0,2.0.0)" - incluindo a 1 e excluindo a 2)

Os containers OSGi têm um pequeno core e são leves
-Equinox (RI - eclipse)
-Apache Felix
-Knoplerfish

Bundles são instalados no container OSGi e têm um lifecicle
-Installed (faltando dependências)
-Resolved (parado, mas com as dependências satisfeitas)
-Starting
-Started (serviços disponíveis)
-Stopping
-Uninstalled (sai no restart)

Você deve disponibilizar os tipos (interface) através do manifest.mf e deve exportar os serviços em uma classe que estende org.osgi.framework.

BundleActivator.

Para utilizar o serviço você deve importar, no manifest.mf a classe que está disponível e, em um BundleActivator, recuperar a instância do serviço

2-OSGi + Spring

Simplifica o uso do OSGi através do applicationContext

Os arquivos do Spring ficam em META-INF/spring

namespace osgi

Você usa o bean de outro bundle como dependência e o Spring injeta (osgi:reference)

O Spring disponibiliza o serviço para você (osgi:service)

BOAS PRÁTICAS
-Separar arquivos normais de configuração do Spring dos arquivos de configuração do Spring-DM

3-Enterprise OSGi

OSGi não suporta aplicações web, então a Spring implementou isto no seu servidor DM

Não possui nenhuma das funcionalidades de EJB, JNDI, etc..

4-Modularização da aplicação

-Vertical
*Por funcinalidade
°Pedidos, Pagamentos, Vendas...
-Horizontal
*Por camadas
°Web, Repositório, Serviço...

Compartilhar infa-estrutura faz sentido
-DataSources
-TransactionManager
-JMS

Qual o tamanho de um Bundle?
-Responsabilidade definida
-Alta coesão
-Baixo acoplamento

Modularização horizontal tende a acoplar os módulos

5-Sumário

OSGi modulariza de verdade dinamicamente

Muitos benefícios em potencial, mas não são fáceis de se conseguir

OSGi é uma área que ainda está no início da evolução (2008) e novos produtos e padrões estarão surgindo