Agile/Scrum/TDD – Página: 2

Série Scrum Remoto: Fazendo retro usando realtimeboard

Olá Pessoal,

No post de hoje da série Scrum Remoto vamos ver como fazemos as nossas retros na ITSLabs. Era um ponto que não fazia ideia como faria ao iniciar o projeto, mas sabia que deveria achar uma solução antes do final do primeiro Sprint.

Lets go…

Como fazer retrospectiva com time remoto?

Essa é uma pergunta que muitos devem fazer e que eu também fazia, mas um dia reservei 1hr do tempo para buscar ferramentas que pudessem auxiliar para atingir esse objetivo, pois não bastava ter uma conferência sem saber como o time ia colocar os posts-its. Aí veio algumas ideias do time:

– Podemos usar o google docs e criar uma planilha e as respectivas colunas: Good | Bad | Should be better. Assim todos iam vendo;

– Podemos usar o whiteboard e desenhar como fazemos fisicamente.

E então, qual delas?

Para ser sincero não estava confortável com nenhuma das opções acima. Elas seriam minha última opção e eu queria algo melhor, com um custo x benefício aceitável dentro do orçamento do projeto.

RealTime Board

Esse cara ai foi a melhor solução que achei e caiu como uma luva. Muito bom. Ele tem templates prontos e um deles era o KanBan. Algumas vantagens que identifiquei:

– Podemos ter 3 projetos private;

– Sem refresh em browser ou algo do tipo; atualização realmente em tempo real;

– Nada de share de tela;

– Muito fácil de usar;

– A versão paga possui um custo x beneficio aceitável;

Vejam a seguir como foi a retro da Sprint 0 e o time todo colocando os posts-it remotamente durante a call.

Fantástico, não?

Conclusão

Achei o RealTime uma ótima ferramenta quando queremos refletir um ambiente fisico KanBan em um ambiente remoto, e para quem já estava acostumado não vai sentir diferença.

E você, como tem feito suas retrospectivas com time Scrum remoto?

Abracos, see ya!!!

Série Scrum Remoto: Team remoto com Scrum rola ou não?

Olá Pessoal,

Estou começando mais uma série no blog e a ideia é compartilhar com vocês o que venho aprendendo no meu último projeto, que é ter um time Scrum 100% remoto. Será que rola? Não é difícil achar essa discussão e ouvir opiniões bem diferentes. No final do post eu vou dar a minha. A ideia da série é compartilhar o aprendizado, e a cada post da série vou compartilhar com vocês como foi a última Sprint e a semana do time. As Sprints são curtas, não duram mais que 2 semanas. Não pretendo entrar nos detalhes durante os posts e também vou omitir informações confidenciais de negócio do projeto. Dúvidas? Deixem nos comentários.

Lets go…

Starting…

Eu venho trabalhando em projetos Scrum desde 2011, mas sempre foi presencial, ou seja, o time estava alocado fisicamente, e o melhor: todos bem próximos e se possível na mesma mesa. Mas mesmo assim sofríamos de vários problemas que não está realizado ao framework. Até porque o Scrum não te diz como vamos implementar as soluções para cada problema que temos. E já ouvi muito isso aqui:

“Scrum só funciona se o time estiver fisicamente junto”

“Scrum não funciona remoto, não tem como fazer daily meeting e nem um quadro de como estão as coisas”

“Não dá para fazer Scrum usando ferramentas on line, já o framework diz que não devemos usar ferramentas” (sério que diz isso? Nunca vi isso).

Enfim, há muitas outras que é comum ouvir por ai. Mas iai, rola ou não rola?

Minha Experiência – Projeto Case

Eu sempre tive essa dúvida, mas nunca afirmei alguma das frases acima ou algo parecido, até por que é complicado afirmar algo assim já que há N variáveis. Mas agora estou em um desafio onde recentemente (julho/2013) entrei em um projeto onde todo o desenvolvimento será remoto e usaremos Scrum framework como ferramenta.

É isso mesmo que você está pensando, a daily meeting, planning etc, será tudo remoto. Não tem como os membros do time estarem fisicamente no mesmo local, a única coisa em comum é o timezone, por ser um projeto nacional.

Quando caí no projeto, apesar de já ter trabalhado assim, mas não usando Scrum, eu parei e pensei: “e agora, como será tudo remoto?”

Começando…

Começamos o projeto agora no inicio de agosto, pois em julho foi mais preparação do ambiente, equipe, reuniões estratégicas, budget e coisas administrativas do projeto. Depois de algumas semanas em reuniões para resolver assuntos administrativos, e também o valor disponível para saber onde podemos usar com eficiência, definimos o inicio do Sprint 0, que seria uma Sprint de setup de ambiente, análises tecnológicas e pequenos testes.

O que fizemos no Sprint 0

Aqui definimos se íamos ter um ambiente de desenvolvimento local ou remoto com base no nosso budget e optamos em ter tudo usando cloud computing, pois foi o que saiu melhor em custo x benefício. Para isso temos:

Integrator VPN (show de bola o serviço oferecido, vou fazer um post comparando cada solução de cloud que testamos – jelastic, openshift etc)
- É nele que teremos nosso ambiente de continuous integration, deploy para test e homologação.
- GitHub (repositório privado)
- RealTime Board: usamos esse cara para evitar compartilhar a tela e ter um whiteboard em tempo real. É fanstástico. Dá para usar um kanban nele. Usamos para retrospectiva. Mas usamos ele na Sprint 0 para jogar todas as tasks que tínhamos que fazer para preparação de ambiente.
- Planning poker: usamos para estimativas das estorias
- Rally Dev: de ferramenta online, usamos e aprovamos. Vai ter um post exclusivo.

Por enquanto é isso que precisamos para iniciar o Sprint 1. Vamos adicionados mais soluções à medida que avançamos nas entregas, adicionando mais carne no esqueleto do projeto.

Vou escrever um post sobre como montar um ambiente de desenvolvimento remoto visando custo x beneficio.

Os problemas

Nem tudo são flores. Como o team é novo com Scrum e algumas soluções técnicas como o Git, GitHub, CI etc, preciso respeitar o tempo de aprendizado e ensinar aos membros como o Scrum funciona, a importância de usarmos Git e termos um ambiente de CI, etc. Então não tenho a velocidade de entrega do meu time, não sei se eles são capazes de entregar 5 ,10, 15 pontos por Sprint, e não quero pressioná-los para entregar de qualquer jeito, já espero que até o terceiro Sprint eles se adaptem e errem bastante. Duvido também que consigam fazer o Sprint passar, mas considero esse tempo como investimento e aprendizado: quanto mais cedo eles errarem e aprenderem melhor.

E o tamanho do Sprint? Ainda não sabemos também, é outro problema. Como definir se o team é novo, se estamos remotos e ainda preciso ensinar aos poucos sobre o Scrum, ambiente etc? Dificil, né? Usar o fator foco pode não funcionar, porque não trata só se está focado na task e sim outros fatores. Iai o que fazer? Nada. Pega a primeira estória que está no topo do product backlog e coloca para o time fazer, mas não crie expectativa que será entregue e não pressione sua equipe para vender a alma e entregar a estória. Isso pode frustrar os iniciantes e bloquear o aprendizado deles. E você não quer isso. Quer que eles aprendam no menor tempo possível.

Outro problema foi encontrar uma ferramenta scrum. Há varias no mercado, porém o mais importante é escolher aquela que se adapta bem ao seu time, e não adquirir uma que é famosa. Então minha primeira decisão foi não adotar uma ferramenta online antes do Sprint 1. Daí usei um XLS que gera o burndown e é compartilhado via dropbox. Só isso.

E no final rolou ou não?

Por incrível que pareça rolou. Tínhamos reuniões diárias, extra meeting, planning e retro, tudo remoto usando o Google hangout. Terminamos o Sprint 0 com o ambiente de desenvolvimento pronto, ou seja, todo o setup finalizado e apto para começar a desenvolver na Sprint 1. Nesse timebox do Sprint 0, o team pode discutir e testar várias soluções e frameworks que seriam utilizados no projeto e decidir qual seria o ideal para o nosso projeto e o porquê. Cada um tinha que defender a sugestão e no final o time entrava em um consenso e a tecnologia era escolhida. Não temos uma pessoa que vai enfiar a tecnologia pela garganta do time, quem vai decidir somos nós. E foi muito divertido ver a discussão do que usar ou não e cada um defendendo. O melhor de tudo foi que sugiram tecnologias que os membros do time não têm conhecimento e nunca trabalharam, mas que é o ideal para o projeto e será adotada. O team agora é responsável por aprender a tecnologia e fazer o bom uso para atingir o objetivo final que temos até o final do ano.

Conclusão

Não importa se você faz scrum presencial ou remoto, o mais importante é o seu time. Esse sim é quem define se vai funcionar usando Scrum ou qualquer outra técnica Agile. Claro que a estrutura base para o time trabalhar é importante e ajuda, mas não define. Aqui trabalhamos com uma estrutura mínima e usamos muitos serviços de cloud computing que nos ajuda a não ficar preocupados em gerenciar ou cuidar de atividades administrativas. Aquilo que não é importante para o negocio, mas é importante para o projeto, buscamos automatizar. Por exemplo, ter um servidor local. Talvez financeiramente seja barato, caso já tenha o servidor na empresa, mas você tem vários problemas relacionados em cuidar desse servidor; se você tem na cloud evita vários micro trabalhos que não agregam valor ao negócio.

Vou ficando por aqui. Até o próximo post da série.

Abraços.

Review de um leitor: Livro SCJP e TDD na Prática

Opa Pessoal,

Hoje recebi um email do leitor Thiago, autor do blog http://www.varallos.com.br que fez um review: Guia do Exame SCJP e TDD na Prática.

Confiram aqui:

Review Guia do Exame SCJP

http://www.varallos.com.br/site/review-guia-do-exame-scjp/

Review TDD na Prática

http://www.varallos.com.br/site/review-tdd-na-pratica/

abraços, see ya!!!

IMasterPro: Curso de TDD em Java

Olá Pessoal,

O post de hoje na verdade é para apresentar para vocês mais um curso que estou lançando no IMasterPro, o objetivo é para aquele que querem aprender TDD, já até tentou, mas não conseguiu ir muito adiante e não pegou o jeito da coisa. E como eu já passei por isso e tive bastante dificuldade na época em encontrar material mais focado e bem direcionado em nosso idioma, resolvi montar o curso online para ajudar quem está chegando agora. A seguir falo um pouco sobre o curso.

lets go..

Sobre o Curso

Se você espera um curso teorico e cheio de bla bla, esquece. Nem eu gosto de curso assim. Fiz o curso bem focado na prática, ou seja, mão na massa. Com problemas, exercicios práticos para que você possa ir resolvendo a medida que vamos evoluindo no aprendizado. Não tem jeitinho brasileiro, receita de bolo para aprender. A única forma é praticar e não ter preguiça de fazer os exercicios e resolver o problema, só aprende programar orientado a teste programando e não lendo. Já viu alguém aprender a dirigir lendo um livro de como dirigir?

Quem não deveria fazer o curso

– quem não gosta de programar;

– quem gosta de respostas prontas;

– quem gosta de seguir passos para resolver um exercicio e achar que aprendeu;

– quem acha que TDD é coisa de desenvolvedor nerd e é frescura :);

O que vou ver no curso?

– Muito código Java;

– problemas para resolver através de unit tests;

– entender o ciclo de TDD e ser direcionado para aplicar nos exercicios e problemas existente;

– Meter mão na massa do inicio ao fim.

Mais sobre o curso vocês podem conferir aqui.

Dúvidas? Comentem 🙂

abracos see ya!!

Utilizando o Selenium para testes Automatizado

Olá Pessoal,

No post de hoje vamos ver como usar o Selenium para criação de testes funcionais. A ideia é um teste simples para mostrar a potência do framework e daí cabe a cada um usar de forma que atenda as necessidades do projeto. Para o post vou usar a versão selenium-server-standalone-2.32.0.jar disponível http://docs.seleniumhq.org/

lets go…

Overview sobre o Selenium

Bem, se você usar o Google e pesquisar sobre “Selenium unit test” verá vários links para a definição, então não há motivos para repetir no post. Veja no famoso Wikipedia. Há um post que gosto bastante sobre o Selenium que está no blog da Caelum.

Em poucas palavras, nos permite realizar teste funcionais simulando ações que um usuário estaria fazendo.

Mas por que usar um framework para isso?

Há vários motivos para fazer isso de maneira automatizada, como por exemplo:

– produtividade;
– qualidade;
– custo;
– feedback.

Contratar um time de profissionais para fazer testes que você pode automatizar, além de custar caro, o tempo gasto é muito maior que de forma automatizada e isso é importante. Assim podemos contratar profissionais para realizar em pontos estratégicos onde não temos como testar de forma automatizada. Como toda e qualquer ferramenta sempre há uma limitação e ai que entra o fator o humano.

Colocando mão na massa

Vamos colocar a mão na massa e criar um projeto muito simples. Faremos um teste que terá como objetivo acessar uma determinada página na internet e fazer uma pesquisa. Se tudo ocorrer bem, o teste vai passar. Mas, por exemplo, se a página estiver indisponível ou o endereço informado para o teste for inválido o teste vai falhar.

Crie um Java project e dê o nome que quiser;
Adicione a biblioteca do Selenium ao classpath do projeto;
Crie uma classe de teste, ou seja, Junit Class. No meu caso criei com o nome de HelloSeleniumTest.java

Vamos criar o nosso primeiro teste que vai acessar a página do Google e pesquisar por “Camilo Lopes”. Veja o código a seguir.

public class HelloSeleniumTest {

       @Before

       public void setUp() throws Exception {

       }

       @Test

       public void testSearchInGooglePage() {

             WebDriver driver = new FirefoxDriver();

//           Digo qual url para acessar

             driver.get(“http://www.google.com”);

//           Agora vamos buscar o elemento na página

             WebElement inputTextGoogle = driver.findElement(By.name(“q”));

             inputTextGoogle.sendKeys(“Camilo Lopes”);

/*           faz um submit na página

*           poderia buscar o botão search e fazer o submit tb.

*/

             inputTextGoogle.submit();

             assertTrue(driver.getPageSource().contains(driver.findElement(By.id(“gbqfq”)).getText()));

       }

}

Entendendo o código

Apesar de que em alguns trechos eu coloquei comentários somente para facilitar o entendimento, vou explicar alguns pontos que considero importantes.

WebDriver: é uma interface do Selenium que todo Web Browser Drivers implementa. O Firefox Browser tem sua implementação, assim como IE e Chrome, cada um com sua particularidade, e é preciso dar uma olhada na documentação sobre como implementar.

Depois que instanciamos o driver, dizemos a URL que queremos testar (nesse caso será do Google), mas em um projeto JEE, por exemplo, vamos colocar o caminho onde está nossa aplicação.

Em seguida pesquisamos pelos elementos na página, para isso no Chrome podemos usar o atalho F12, clica na lupa que fica no rodapé e clica sobre o input text e ver qual o nome daquele campo. Podemos usar o id, nome etc. Veja:

Depois que fizemos isso, criamos uma variável para representar esse campo :

WebElement inputTextGoogle = driver.findElement(By.name(“q”));

E em seguida invocamos o método sendKeys(…) e passamos o valor que queremos que seja digitado no input. Para descobrir e conhecer melhor os métodos disponíveis tem que passar por alguns minutos vendo o que temos na documentação do framework.

inputTextGoogle.sendKeys(“Camilo Lopes”);

Logo em seguida fizemos o submit página

inputTextGoogle.submit();

Criando o assert

Bem, para que seja testado precisamos usar algum assertXXX do framework Junit. Então vamos verificar se após ter feito o submit há um elemento com o id informado na página.

O teste passa. Na verdade esse teste não tem nada de inteligente. Se você reparar, ele verifica se o input que pesquisamos na primeira página do Google é o mesmo na página do resultado da busca.

Claro que em nossa aplicação íamos testar algo mais voltado para regras de negócio. E o método getPageSource() nos ajuda nisso, em busca de um elemento na página corrente.

Execute o teste

Vamos executar os testes e aguardar por alguns segundos e veremos que o Selenium vai abrir o browser que definimos (no caso do post foi o Firefox) e realizar a pesquisa.

Convertendo isso para uma aplicação

Em uma aplicação web, vamos ter que usar a url onde nossa aplicação está rodando. Claro que vamos evitar que o endereço seja informado dentro da classe Java, este pode ser informado de um arquivo .properties por exemplo, efaremos assert voltado para as regras de negócio.

Conclusão

O objetivo desse post não era explorar como escrever bons testes com o Selenium, a ideia era apresentar o framework e vê-lo em ação. Após isso podemos tirar nossas próprias conclusões sobre a eficiência e produtividade gerada quando usamos corretamente. Já passei por algumas empresas e projetos onde falaram que o Selenium foi o responsável pelo aumento do dos prazos nas entregas. Acredito que o problema certamente não foi com o Selenium, mas sim na forma de como este foi usado ou adotado dentro do projeto.

E você tem usado o Selenium em seus projetos? Compartilhe sua experiência…

Abraços, see ya!!!