Scrum Remoto: Praticando Planning Poker

Olá Pessoal,

O post de hoje é bem mais uma dica. Mas a pergunta é: como fazer estimativa se meu time está remoto? Ou melhor, como se beneficiar do planning poker?

Lets go..

Starting…

Aqui na ITS temos projetos presenciais e remotos, mas a maioria é remoto, ou seja, o time trabalha de casa. Depois farei um post sobre como é o nosso trabalho remoto. Voltando ao problema, como fazer as estimativas com planning poker se o time está remoto? Pesquisando sobre alguma ferramenta que pudesse nos auxiliar, encontrei http://www.planningpoker.com/ realmente sensacional. Além de ser free, é muito simples de usar. Aqui na ITS estamos usando a ferramenta e está sendo uma boa experiência.

Como funciona?

  1. Você faz o cadastro, que é simples e rápido;
  2. Você escreve a estória;
  3. E dá um start;

As cartas aparecem e você escolhe a sua estimativa. Quando todos estimarem, o resultado aparece e o time discute. Se for aceito, a estimativa é associada com User Story.

Simples, não?

Era isso que queria compartilhar com vocês, mais uma experiência com gerenciamento de projeto Scrum Remoto.

Abraços, See ya!!

Série Scrum Remoto: Adotando uma ferramenta online ideal para o time

 

Opa Pessoal, 

Vamos a mais um post da série Scrum Remoto. Nesse primeiro projeto aqui na ITSLabs com Scrum remoto realmente não sabíamos qual ferramenta adotar, e como há várias no mercado e algumas se demonstraram até como a solução ideal, preferimos analisar com cautela. 

Lets go…

Qual a ferramenta ideal para Scrum? 

Ouço e vejo muito essa pergunta. Eu digo sempre que não há ferramenta ideal. Uma que funciona bem para um determinado projeto e equipe, pode não funcionar bem para outra. Em um ambiente físico eu ainda gosto de ter as coisas na parede, quadro, etc. Mas e em um time remoto? Aí temos que usar uma ferramenta que pode ser uma planilha eletrônica, uma aplicação, um software desktop, etc. A escolha é da equipe. Mas qual adotar? Vou pelo custo ou por aquela que é famosa na comunidade?

O custo tem que ser analisado sim, e nem sempre o mais caro é o melhor. Pense nisso sempre. O mesmo vale para a segunda pergunta, o fato de ser famosa na comunidade também não quer dizer que é a melhor, e o fato de todo mundo usar não quer dizer que é a ideal ou a melhor do mundo. Há estratégias de marketing por detrás de qualquer produto e é preciso extrair e olhar apenas para o produto seco. É o que faço sempre antes de adquirir qualquer produto, busco identificar essa parte, ignorar e tomar uma decisão com base na razão e necessidade.

E como eu fiz aqui na ITSLabs?

Aqui tínhamos um problema como esse. Uma lição que aprendi é não tomar uma decisão corrida para a escolha da ferramenta apenas porque o Sprint 1 começa amanhã. É uma decisão importante e cara, mas também não posso deixar o team sem nada e as informações precisam estar compartilhadas de alguma forma para termos um tracking do Sprint corrente e saber como estamos indo. E pesquisando no velho Google achei um template feito no Microsoft Excel que parecia atender ao que precisávamos enquanto não tínhamos uma ferramenta ideal para o nosso time. Vejam o template dela:

scrumxls

Claro que não íamos ficar trocando emails com essa planilha, daí, o que usar? O dropbox. Então sempre que ela for atualizada todos são notificados.

O problema

Na planilha que encontrei acima descobri que é ideal para um projeto pequeno e rápido, mas não se encaixa no nosso. Por quê? Simples. Como fazer o tracking de todos os Sprints? A cada release os investidores querem saber como fomos nas últimas 3 Sprints. Quanto tempo gastamos, número de bugs, etc. Iai o que fazer? Mandar cada XLS do Sprint por email e dizer para ele olhar? Ou melhor, criar um novo XLS com essas informações compiladas e mandar pra ele. Mas terei que fazer isso a cada release, e quanto tempo vai custar para isso?

Outro problema que tivemos com a sincronização do DropBox: em alguns casos não funcionava bem. No IOS não atualizava às vezes e aconteceu de um membro da equipe ficar com  o XLS desatualizado.

Em projetos que já trabalhei com Scrum, já usei várias ferramentas, muitas já eram default nas empresas, outras estavam em testes, etc (como Jira, Scrumworks, IceScrum, Mingo etc), mas para o projeto que estou agora a ferramenta ideal foi a Rally pelo seguinte ponto:

– Atende ao nosso projeto;

– O team achou muito fácil de usar e ela se encaixa bem para o nível do projeto;

– Customização da tela;

– Custo x benefício;

É possível saber como as coisas estão muito facilmente.

O que precisa melhorar? 

– Sincronização. Se uma informação é atualizada, é preciso dar reload na página para ser atualizada; a ferramenta deveria atualizar automaticamente;

– Adicionar novo usuário. Se o usuário tem cadastro no rally, não conseguimos adicionar ele ao projeto. Acho que a ferramenta deveria permitir buscar usuários já cadastrados e adicionar ao projeto.

Depois de uma análise, decidimos usar a ferramenta no Sprint 2. Fizemos alguns testes antes com projetos fake para entender e ver se realmente nos ajudaria.

Conclusão 

Nessa busca de ferramenta online para projetos Scrum descobri que não importa a ferramenta que você usa, mas sim se o time está confortável com ela e se a mesma agrega valor para o seu projeto. Não adianta querer empurrar uma ferramenta para o time ou projeto só porque alguém do comercial fez um bom negócio com a criadora da ferramenta. O motivo? A ferramenta pode atrapalhar a equipe, principalmente na curva de aprendizado. Outro aprendizado que ficou é que para cada projeto o melhor é sempre analisar qual ferramenta se adéqua melhor, usar um X tudo pode ser mais fácil, e em alguns casos parece ser mais barato, porém hoje há varias opções onde que você contrata serviços apenas para o que precisa e acho que ter a ferramenta ideal por projeto é mais importante do que querer ter uma ferramenta “for all”.E lembrando que as pessoas são mais importantes que as ferramentas, não adianta investir milhões em aquisição de ferramentas “inovadoras” enquanto não se valoriza e não investe nas pessoas.

Vou ficando por aqui. E você, qual ferramenta Agile tem usado em seus projetos? O que tem considerado para a escolha?

Abracos, see ya!

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. 

retrosprint

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 Dropbox: Por que usar easyJavaDropboxAPI?

Olá Pessoal, 
 
Hoje vou falar rapidinho sobre a easyJavaDropbox API. Recebi um e-mail recentemente de um leitor perguntando por que ele deveria usar a easyJavaDropboxAPI já que pode usar diretamente API do dropbox. 
 
Lets go… 
 
 
Por que usar easyJavaDropboxAPI? 
 
A motivação com que criei a easyJavaDropboxAPI foi para encapsular algumas funcionalidades da API do dropbox. Se você usa muito recurso da API vai ver que tende a criar código repetido ou terá que criar uma classe utilitária para tratar e evitar código repetido. Ao invés de criarmos uma classe utilitária, que tal uma API que pudesse ser usada em outros projetos? Assim nasceu a easyJavaDropboxAPI. 
 
A API ainda está em uma fase bem inicial e simples. Estamos já com a pre-release da versão 1.2.0 e vamos atualizando constatemente à medida que identificamos novas funcionalidades que seria interessante na API e que deveria ser encapsulada. 
 
Quando devo usar? 
 
– Se precisa salvar um arquivo no dropbox via upload temos um método que resolve isso facilmente; 
– Se precisa listar e obter arquivos que estão no dropbox; 
– Se quer pesquisar um arquivo no dropbox, temos essa funcionalidade já implementada; 
  
Ainda temos poucas funcionalidades, na verdade todas elas foram nascendo com cases reais de projetos, e vamos evoluindo a API dessa maneira, pegando requisitos de mercado e melhorando.
 
Conclusão 
 
Se você quer uma forma mais simples de se conectar com o dropbox, a easyJavaDropbox API vai te ajudar evitando escrever mais código do que precisa. Uma outra vantagem que ganhamos foi de separar o código de terceiros do nosso código de negócio, pois apesar de usarmos as funcionalidades do dropbox para resolver problemas de negócio queríamos manter o código separado porque se amanhã deixarmos de usar o serviço do dropbox, o que iremos fazer? Então mantivemos isso separado usando a API e a troca do dropbox por um outro serviço, seja de terceiro ou próprio. É simples, fácil e com um custo de manutenção aceitável. Nada de big refactoring :). 
 
Github do Projeto
 
 
Vou ficando por aqui, e não deixe de mandar sugestões, críticas etc.

Série Dropbox Case com dropbox API

Olá Pessoal

No post de hoje gostaria de compartilhar com vocês uma experiência que tivemos aqui na ITS usando API do DropBox para resolver alguns problemas e facilitar a vida do usuário. Aqui no blog já apresentei para vocês como  usar API do Dropbox, hoje veremos como fazer umas coisas legais na sua aplicação.

Lets go…

Starting…

Case 1

Em um projeto aqui na ITS tínhamos que renderizar imagens em algumas páginas da aplicação e queria fazer isso de maneira simples, fácil e transparente para o usuário final. Considerando que o usuário que coloca as imagens não precisasse conhecer a aplicação, ou melhor, ele poderia nem ter idéia onde aquela imagem que ele criou seria usada, o foco dele era fazer a criação e depois de pronto disponibilizar a imagem em folder chamado de “live” e pronto.  Essa imagem já estaria atualizada na aplicação automaticamente.

Como resolvemos esse problema sem precisar envolver o design com aplicação?

Simples, usando o DropBox.

É isso mesmo. Os designers usam o dropbox para colocar a arte final e uma pasta final onde outro designer faz um review para ver se está ok. Nada de especial aqui, apenas usando o dropbox de maneira tradicional, só que a arte final desse designer ia ser usada na aplicação e precisamos subir a imagem, como fazer?

  • Via upload na aplicação; ou
  • Colocar a imagem direto no servidor e dar uns tapas na app para reconhecer a nova imagem

E o que fizemos?

Usamos dropbox. Para ser sincero eu fui dormir com esse problema, sonhei, e veio o dropbox como solução. Passei alguns dias estudando API e fazendo POC para validar a solução.

A solução

A solução é muito simples: o design vai continuar fazendo o trabalho dele como antes, a aplicação apenas vai buscar imagens na pasta “live” que é uma pasta onde tem a versão final da arte. Daí se o designer fizer alguma alteração nessa imagem, automaticamente ela é atualizada na aplicação. E não precisamos nos preocupar em fazer um novo upload da imagem no servidor  com a versão atualizada, porque há um sync com  a pasta “live”. A esta pasta “live” não é qualquer um que possui acesso, somente Designers mais Seniors tem permissão de escrita nessa pasta. Futuramente vamos facilitar a vida dos designers e implementar um esquema de automatizar os deploys de imagem nessa pasta, mas por enquanto ela ocorre manual. 

O que ganhamos?

– Nada de imagem no Server, então em uma migração de Server não preciso ficar preocupado em copiar imagens e, a depender da quantidade e tipo de negócio, pode demorar a cópia. Quantas imagens você acha que o submarino possui?

– Mais produtividade para o designer. Ele continua focado no trabalho dele fazendo tudo como antes, sem se preocupar onde e quem vai usar aquela imagem;

– Atualização automática da imagem na aplicação. Ou seja, subiu a imagem para pasta “live” já está atualizada na aplicação.

Case 2

Esse aqui também foi fantástico em outro projeto que usava  bastante documentos durante o dia. A vida dos usuários era o Microsoft Word aberto, atualizando os documentos publicados, criando novos  ou corrigindo.  Na versão atual, sempre que um documento é corrigido por uma questão de mudança de lei ou cláusula de contrato, há um prazo de publicação que, a depender da situação, é de até 8hrs a disponibilidade.  Se fosse apenas 1 documento e se acontecesse isso em um período longo, seria fácil, mas não é assim no dia a dia. Hoje o nosso cliente tem que acessar a aplicação, deletar o arquivo anterior e fazer upload do novo. E pior, é interessante manter o antigo como backup, por questão de segurança o delete não remove o arquivo do servidor, apenas move para uma pasta específica. Então o pessoal que trabalha nesses documentos passava boa parte do tempo fazendo upload, fora que às vezes enfrentavam problemas e demora nesse processo, já que tinham arquivos com 10 mb, como projetos com imagens.

E como resolvemos?

Com dropbox API. Os usuários trabalham no dropbox com limitação de acesso, vendo apenas aqueles folders de acordo com o departamento.  Eles não precisam mais se preocupar em fazer upload, apenas trabalham nos docs em uma determinada pasta. Seus superiores podem ir avaliando o documento sendo escrito e já dando feedback. Uma vez concluído, vai para uma pasta que representa o arquivo online e pronto, o arquivo já está atualizado em produção e quem fizer o download já pega o arquivo atualizado.

Fantastico, não?

O que aprendemos?

Nessa solução vimos que apenas saber uma tecnologia não é suficiente; é preciso estar envolvido com o negócio do cliente para chegarmos à solução ideal e sabermos se realmente resolve o problema e agrega valor ao dia a dia do nosso cliente. Não resolver um problema apenas por que temos que resolver, mas buscar como solucionar da melhor forma. É  assim que os profissionais na ITS vivem e respiram todos os dias, e sabemos que negócio & TI não estão separados, e sim juntos. Se você for na API do dropbox é tudo abstrato, o que você vai fazer com ela é uma questão sua. E nós chegamos a essa arquitetura devido ao nível de envolvimento que tínhamos com o negócio, senão ia ser mais uma API disponível como qualquer outra.

Agora temos mais desafios de automatizar alguns trabalhos e permitir que a promoção de uma pasta para outra seja rápida e simples.

Não deixe de conhecer o easyJavaDropboxAPI

Abraços. See ya!