domingo, 27 de junho de 2010

InfoQ:Lançamentos rápidos e confiáveis

    Rolf Russell & Andy Duncan discutem liberações rápidas e confiáveis dos pontos de vistas:

  • Construção;
  • Lançamento;
  • Desenvolvimento.

    Levando em consideração relações entre as equipes envolvidas, métricas necessárias para medir o desempenho alcançado, as competências exigidas e as remoções de desperdícios:

    InfoQ: Rapid and Reliable Releases

    Bye see you next post


sexta-feira, 25 de junho de 2010

O que significa ser ágil?

Laurie Williams, professora da North Carolina State University, recentemente conduziu uma pesquisa para descobrir quais os princípios e práticas que são utilizados pelas equipes ágeis.
Através de uma pesquisa de 300 respostas os resultados foram divulgados. As conclusões foram que os princípios mais importantes para equipes ágeis são:
  • Há maior prioridade é satisfazer o cliente através da entrega antecipada e contínua de software valioso;
  • Software de trabalho é a principal medida de progresso;
  • Entregar software funcionando frequentemente em duas semanas ou no máximo um mês;
  • Construir projetos em torno de indivíduos motivados. Dê-lhes o ambiente de apoio e confiança para fazer o trabalho;
  • Em intervalos regulares, a equipe reflete sobre como tornar-se mais eficaz.

A pesquisa também perguntou quais as práticas essenciais para uma equipe ser considerado ágil. As cinco primeiras foram:

  • Iterações curtas (30 dias ou menos);
  • Integração contínua;
  • "Done" critérios;
  • Os testes automatizados são executados a cada compilação;
  • Automatização de testes unitários.

Professora Laurie Williams está fazendo uma pesquisa seguindo os princípios ágeis. Você pode participar da pesquisa até dia 9 de julho de 2010 e ver os resultados:

http://www.surveymonkey.com/s/TQFTP5V

Fonte: http://blog.mountaingoatsoftware.com/what-does-it-mean-to-be-agile by Mike Cohn’s Blog

Bye see you next post

quarta-feira, 23 de junho de 2010

InfoQ: Kanban for Video Game Development

Clinton Keith é um coach ágil independente. Certified Scrum Trainer com 15 anos de experiências em desenvolvimento de jogos de vídeo.

Clinton introduziu a indústria do jogo de Scrum em 2003 e Lean / Kanban em 2006. Autor do livro "Agile Game Development com Scrum", que será publicado no início de 2010.

InfoQ: Kanban for Video Game Development 

Seu site http://www.ClintonKeith.com

Bye see you next post

Instalação do SVN e VisualSVN Server – Controle de Versão

Subversion é um sistema de controle de versão com estruturação para substituição do antigo CVS(que tinha algumas limitações).

Para implementar a integração contínua podemos utilizar as seguintes ferramentas, por exemplo:

 Controlar de versões (Subversion);

Automação de build e de dependências (Maven)

Repositório e proxy de artefatos (Nexus);

Agendamento de builds (Hudson);

Vou falar mais sobre uso e instalação do Subversion no eclipse.

1) Escolhi o VisualSVN Server standard edition http://www.visualsvn.com/server/getting-started/ como IDE Visual na criação de repositórios e usuários.

Apenas clicando com botão direito no usuário posso definir permissões. Através de um clique direito em repositório posso atribuir os usuários com opção propriedade. Ferramenta intuitiva.

visualsvn

 

 user

repositorio

Lembrando VisualSVN Server standard edition poderá ser usado também para sincronização do repositório, atualização e outras operações no ambiente Windows. Fora do ambiente eclipse.

Como próprio nome diz é também voltado para Visual Studio. 

Uma outra opção de ferramenta é TortoiseSVN http://tortoisesvn.tigris.org/. Temos ferramentas para Mac, Linux e outros.

2) O segundo passo abrir o eclipse que no exemplo é o Galileu, mas funcionamento nas outras versões e escolher a opção do menu:

Help-> Install New Software –> Add

install

Logo após adicione site subeclipse.tigris.org e Clique OK:

svn

Selecione todas opções que foram escolhidas na tela e clique next:

install core

Revise dos itens que serão instalados, clique next:

O SVN e o SVNKit serão instalados.

install deta

Aceite a licença e clique finish:

lincença

O processo de instalação iniciará e quando terminar o eclipse será reinicializado. 

Se pedir permissão ao firewall quando estiver instalando o software, permita para instalação completa do software.

Após a reinicialização do eclipse escolha:

Windows-> Preferences->Team-> SVN

preferences

Na General SVN settings desmarque JavaHL e SVN interface escolha SVNKit. Isto permitirá usar mais de usuário no SVN.

E quando alterar senha do usuário permitirá trocar a senha.

O SVN esta pronto para ser usado no eclipse e VisualSVN server.

Fonte:

http://subversion.tigris.org/

http://www.visualsvn.com/server/getting-started/

http://josenaves.com/integracao-continua-treinamento-gratuito.htm

http://flaviowd.wordpress.com/2010/05/23/configurando-svn-no-eclipse-e-windows-xp/

Bye see you next post

terça-feira, 22 de junho de 2010

Selenium: visão geral

Selenium: Ferramenta para teste de aceitação no browse

 

Fonte: www.youtube.com/watch?v=78mts_sKNGs&feature=channel

Google London Test Automation Conference (LTAC)
Google Tech Talks
September 8th, 2006
Presenter: Jason Huggins Credits: Presenter:Jason Huggins

Bye see you next post

De tanto enfiar gambiarra para funcionar – Musica de Daniel Cukier

Música de Daniel Cukier sobre conserto de gambiarra, teste automatizado e refatoração. Ficou muita boa a versão da música:

Ocorreu no Dojo Rio.

Fonte:

http://videolog.uol.com.br/video.php?id=488290

Fotos por Rodolfo Carvalho http://rodolfocarvalho.net

Música por Daniel Cukier http://agileandart.blogspot.com

Vídeo por Álvaro Justen – Turicas http://blog.justen.eng.br

Bye see you next post

Lean Summit 2010 - 3 e 4 de agosto em São Paulo

O Lean Summit 2010 visa apoiar empresas e praticantes de diversos setores em diferentes estágios da jornada lean.

Destaques:

  • Gestão lean - liderança, desdobramento da estratégia
    e desenvolvimento de pessoas.
  • Cultura de aprendizado e
    mudança no comportamento das pessoas.
  • Evolução do sistema lean.
  • Ilustração dos conceitos discutidos através
    de casos de aplicação em empresas no Brasil.

mais informações: http://www.leansummit2010.lean.org.br/

Bye see you next post

segunda-feira, 21 de junho de 2010

Kanban no Desenvolvimento Ágil de Software by Dilbert

Parabéns a turma de Gerência de Projetos de Software da FACIN/PUCRS 2009/2:

Fonte: www.youtube.com/watch?v=LJOiFRsp0Z8

Bye see you next post

sexta-feira, 18 de junho de 2010

Projetos ROI

roi

Há uma classe de projeto de software, onde o valor de negócio entregue é a chave. Sendo que as medidas do valor de negócio são quantificáveis em:

  • Redução de custo;
  • Geração de receita;
  • A satisfação do cliente;
  • Redução do ciclo de tempo.

Se eu gastar "X" reais e conseguir "Y" reais valor = benefícios mensuráveis entregue à empresa.

Processo de Aprovação: Segue uma variante do processo em quatro passos:

  • Identificar e quantificar o benefício comercial;
  • Traduzir em requerimento de software;
  • Estimativa: o tempo e o dinheiro necessário;
  • Obter a aprovação com base na análise custo / benefício - a análise pode ser absoluta ou relativa a outros projetos.

Perigo: Para começar o projeto aprovado, o benefício pode ser (consciente ou inconscientemente) exagerado. Como alternativa o custo pode ser subestimado.

Como a metodologia ágil poderá ajudar?

  • Falhando cedo;
  • Com entrega de valor incremental.

Fonte:http://setandbma.wordpress.com/2010/05/04/when-delivering-measurable-business-value-is-not-the-key-to-success-of-a-software-project/

Bye see you next post

Spy – Testes Unitários

O Spy é semelhante ao Stub, mas além de fornecer algumas informações, também faz a gravação das informações que serão usadas nos testes. 

A cada pedido do cliente é enviado um sms.  Na classe Pedido é disparado o serviço enviar da SmsServiceSpy. Através da classe SmsServiceSpy é simulado o armazenamento de envio de sms.

No serviço testEnviaSmsPedido da classe de Teste verifico se sms foi enviado. Isto é feito através do serviço getNumeroMensages da classe SmsServiceSpy que retorna o numero de sms’s enviados, que no teste montado será retornado 1(um). Uma simulação de envio de sms usando List collection.

   @Test
    public void testEnviaSmsPedido() throws Exception {
        Pedido pedido = new Pedido(new Long(3), new Long(45));
        SmsServiceSpy smsService = new SmsServiceSpy();
        pedido.setSmsService(smsService);
        pedido.preencheTelefone(new Cliente("5181989800"));
        Assert.assertEquals(1, smsService.getNumeroMensages());
    }

Aqui temos um spy realizando a gravação das informações para serem testadas:

public class SmsServiceSpy implements SmsService{
    private List<Mensagem> mensagens= new ArrayList<Mensagem>();
  

public void enviar(Mensagem m){
        mensagens.add(m);
    }
  

public int getNumeroMensages(){

        return mensagens.size();
    }

}

Fonte: http://msdn.microsoft.com/en-us/magazine/cc163358.aspx

e

Apresentação sobre Injeção de Dependência e Testes com Dublês (Dummy Object, Stub, Mocks, Fake Objects, Spy) feita no 2o. Locaweb TechDay por Daniel Cukier http://vimeo.com/3596692

Bye see you next post

quinta-feira, 17 de junho de 2010

Dummy Object

Dummy é um objeto que pode ser passado como argumento, eliminando a necessidade de construir um objeto real.

Dummy na realidade é um objeto que nunca é usado, porém é necessário ser passado como argumento para que código funcione.

No exemplo do serviço testAddLinhaItem, temos dois Dummy Objects: Produto e Cliente.

public class TestPedido extends TestCase {

@Test
    public void testAddLinhaItem() throws Exception

  {

        final int QUANTIDADE = 1;
        Produto produto = new Produto("Azeite de Dende");
        Invoice inv = new Invoice(new Cliente());
        LinhaItem expItem = new LinhaItem(produto, inv, QUANTIDADE);
        inv.addLinhaItem(produto, QUANTIDADE);
        List<LinhaItem> linhaItems = inv.getLinhaPedidos();
        assertEquals("numero de itens ", linhaItems.size(), QUANTIDADE);
        LinhaItem atual = linhaItems.get(0);
        assertLineItemsEqual("", expItem, atual);

    }

    private void assertLineItemsEqual(String string, LinhaItem expItem, LinhaItem atual)

  {
        assertNotNull(expItem);
        assertNotNull(atual);
        assertEquals(expItem.getCliente(), atual.getCliente());
        assertEquals(expItem.getQuantidade(), atual.getQuantidade());
        assertEquals(expItem.getProduto().getNome(), atual.getProduto()
                .getNome());

    }

}

dummy

Fonte: http://xunitpatterns.com/Dummy%20Object.html

e

Apresentação sobre Injeção de Dependência e Testes com Dublês (Dummy Object, Stub, Mocks, Fake Objects, Spy) feita no 2o. Locaweb TechDay por Daniel Cukier http://vimeo.com/3596692

Bye see you next post

Perspectiva do Desenvolvimento de Software Lean

lean

1. O Imperativo Lean

O padrão ouro de produtividade é definido por organizações lean que são: Toyota, Wal-Mart e Dell. As organizações lean concentram-se no rápido fluxo de valor, porque eles descobriram o princípio fundamental de Lean Six Sigma: qualidade, rapidez e baixo custo que estão intimamente ligados.

1.1 Alta Produtividade

80% do valor da maioria dos sistemas é entregue em 20% dos recursos, até dois terços das características da maioria dos sistemas são raramente ou nunca utilizados. 

1.2 Resposta Rápida

A maturidade de uma organização é medida pela velocidade com que ele pode repetidamente e confiávelmente executar seus processos de core. A resposta rápida é um fator básico de vantagem competitiva. Qual a velocidade que a sua organização rotineiramente responde a uma necessidade do cliente? Seus concorrentes são mais rápido?

1.3  Qualidade Superior

A  fundamental disciplina de desenvolvimento de software esta no teste. Testes definem os requisitos, o projeto e documentação do sistema. 

1. 4  Relação duradoura

80% do código em qualquer sistema é desenvolvido após a primeira versão de produção. Alguns dos melhores produtos de software tem evoluído a uma década. O software robusto resiste ao teste do tempo é criado por desenvolvedores que têm um conhecimento profundo do domínio.

2.0  Lean Agenda

Inventário reduz o fluxo de dinheiro e torna-se obsoleto. O Pensamento lean para Desenvolvimento de Software conduz ao inventário baixo risco, fornecendo valor ao cliente o mais rapidamente possível.

2.1 Foco no Cliente

Resíduos é algo que não dá valor para o cliente em tempo útil. Identificou quem são seus clientes? Sabe o que clientes realmente querem? Sabe quanto tempo demora para entregar valor ao cliente? Para descobrir o quão bem sua empresa oferece valor ao cliente, comece por analisar o fluxo de valor.

2.2 Fluxo de Processo

Uma equipe de desenvolvimento ágil de software pode adicionar recursos de qualquer ordem, podendo liberar uma versão funcional do software no final de qualquer iteração.

2.3  Responsabilidade Local

Nas organizações realmente eficiente, o trabalho de gestão é proporcionar um modelo organizacional de modo que as pessoas descubram o que fazer sem ser dito. Fluxos de trabalhos eficazes, os controles visuais e a formações de profissionais preparados no mercado de trabalho.

O melhor software é projetado por desenvolvedores e especialistas de domínio que desenvolverão conjuntamente um conhecimento profundo do domínio.

2.4 Decisões com base em dados

Quando o objetivo é acertar um alvo móvel, desenvolvimento de software baseado na aprendizagem é uma abordagem a ser considerada. Equipes de desenvolvimento experientes podem implementar características individuais em qualquer ordem e entregar código destacável em menos de um mês.

Implementação de software de aprendizagem baseada em pequenos conjuntos de recursos de desenvolvimento em ordem prioritária, oferecendo tanto o retorno rápido e valor comercial imediato. Empresas de software de sucesso têm utilizado esta abordagem por muitos anos.

3. Implementação Lean

A caminho para o sucesso não consiste em copiar as práticas das organizações de sucesso.

O caminho para o sucesso reside no desenvolvimento da compreensão profunda dos clientes, colaboradores e o contexto competitivo da empresa.

3.1 O Fluxo de Valor

Iniciar um relógio quando um cliente reconhece uma necessidade crítica. Medir o tempo médio necessário para colocar este problema no topo de uma lista de prioridades, desenvolver uma solução, certificar-se do trabalho, implantar a solução e realmente resolver o problema.

A solução do tempo de ciclo de entrega é medida em dias, semanas, meses ou anos? Onde estão os despediçadores de tempo? Reconhecer que estes despediçadores de tempo diminuiem valor, aumentam custo e diminuiem qualidade.

3.2  Construindo Bloco de Disciplinas

1. Um ambiente de trabalho limpo, organização de arquivos no computador, backup e procedimentos de atualização;
2. Normas para a nomeação, codificação, interfaces gráficas, etc;
3. Um sistema de controle de versão;
4. Um rápido processo de construção;
5. Integração diária dos novos códigos;
6. Testes escritos no momento da codificação, automação diária dos testes e durante do ciclo de vida do sistema.

3.3  Software Tolerante a Mudança

As coisas são simples para uma empresa começar o desenvolvimento do seu primeiro produto, não há interfaces ou questões de compatibilidade. Mas com passar do tempo são adicionados novos recursos, sendo assim a complexidade cresce exponencialmente. Complexidade calcifica transformando o  código e o software complexo, quebra fácil.

A maneira de lidar com a complexidade é a construção de tolerância a variações no processo de desenvolvimento - a utilização de um processo que mantém o código simples.

O primeiro passo adicionar testes como parte do processo de desenvolvimento, por isso o código pode ser mudado com regularidade e segurança.

O próximo passo é continuar a simplificar o código: duplicação de código deve ser refatorado usando padrões de projeto.

Os novos códigos devem ser integrados na base de código uma vez por dia ou mais, dependendo da necessidade.

3.4 Gerenciando O Pipeline

Nós vimos algumas idéias para gerenciamento de desenvolvimento de software, mas alguns que trabalham bem. O problema é que a maioria dos sistemas de programação multi-projeto parecem basear-se  numa tentativa de aumentar o "recurso" de utilização.

Primeiro, as pessoas não são recursos fungíveis, desenvolvem competências em áreas específicas e se preocupam com  resultado com sucesso do seu trabalho.

Segundo, sabemos que teoria das filas simples que tentam maximizar a utilização, geralmente atrasam. Quem já esteve preso no tráfego sabe que atrasa.

Terceiro, como o software é um processo de desenvolvimento a variabilidade é fundamental para seu sucesso. Puxando os horários de trabalho quando necessário.

 
3.5  A célula de trabalho Software & The Workplace Visual

Em Lean manufacturing, a complexidade é tratada por simplificar o problema primeiro, segundo passo é automatização.

No desenvolvimento de software, usamos equipes multifuncionais. Uma única equipe de preferência co-localizado com todas as capacidades para conceber, desenvolver e implantar o software é a célula de trabalho do software básico. Essa equipe deve saber o que fazer sem ser dito, deve ser evidente a partir das pistas visuais no local de trabalho. Seguindo a mesma linha do Lean manufacturing.


3.6 Métrica

As medidas de desempenho são a chave para alavancar uma estratégia de toda a organização. Com demasiada freqüência, os objetivos de um departamento não estão alinhados com os objetivos de um departamento de vizinhos e diminuiu a capacidade da organização para entregar valor. Não adicione novas medidas para resolver este problema. Diminua o número de medições.

Quando as pessoas são medidas com base no seu espaço de influência, em vez de sua amplitude de controle, têm um incentivo para colaborar para o bem geral da organização.

Fonte: http://www.poppendieck.com

Bye see you next post