Iremos participar do Flex For Kids. Venha você também!

É um pouco em cima da hora, mas decidimos: a Infobits, os Gwibbers, a Gerência de Tecnologia da Informação da Universidade Estadual de Montes Claros e boa parte da comunidade Flexer de Montes Claros irão participar do Flex For Kids!

O objetivo do evento é ajudar as crianças do Cotolengo, uma instituição do Mato Grosso do Sul que acolhe pessoas com necessidades especiais.

Iremos assistir às apresentações de grandes nomes da comunidade Flex brasileira ao vivo na Unimontes (local exato ainda por decidir. Muito provavelmente no auditório ou na sala de multimeios do Centro de Ciências Exatas e Tecnológicas) no dia 6 de Fevereiro (Sábado), das 8:00 às 17:00 horas.

Todos os interessados devem procurar à Infobits de 7:30 às 12:00 ou entrar em contato por email (infobitsunimontes@infobitsunimontes.com.br). Para participar do evento, é necessário desembolsar a quantia de R$15,00.

Só pra informação: NÃO temos pretensão de lucrar com isso. O dinheiro será gasto na contribuição simbólica para participarmos do Flex For Kids e com despesas e custos, como o almoço (feijoada!), refrigerantes e o café da tarde.

Informações completas sobre o Flex For Kids podem ser encontradas no site: www.flexforkids.com

E aí? Animou?

Resultados do Dojo #1

Ontem realizamos o primeiro Coding Dojo na Unimontes. O grupo foi batizado de DojoMoc e contou com a presença de 7 pessoas. O envento não foi intensamente divulgado de propósito: queríamos ter uma maior experiência antes de sair convidando toda galera.

Começamos um pouco atrasados e vamos tentar chegar pelo menos 10 minutos antes para montar a estrutura (notebook, projetor, etc) e começaremos impreterivelmente às 19:30. Quem chegar depois, vai ficar sobrando

O próximo Dojo foi marcado para Terça-Feira, no mesmo horário. Sexta feira é meio complicado de se fazer um Dojo… há uma concorrência muito grande na Sexta.

O problema que escolhemos foi o Karate Chop que é basicamente uma busca binária. Tivemos problemas na hora dos testes, pois, da mesma forma que uma busca binária passa nos testes, uma busca linear também passa nos testes.

Tivemos que terminar mais cedo, pois alguns participantes já haviam marcado compromisso e como já começamos perto das 20:00, não deu tempo de fazer muita coisa…

Apesar de tudo, muita gente ainda não conhecia TDD, Baby Steps ou programação em pares. Como o ambiente estava bem amigável, todo mundo conseguiu se enturmar rápido e aprender como o TDD funciona.

Abaixo, a retrospectiva que fizemos

Gostei:

• TDD
• Baby Steps
• Treinamento

Poderia ter sido melhor:

• Usar mais os recursos da IDE (NetBeans). Fizemos algumas coisas na mão.
• Pontualidade

Não gostei:

• Celular ligado
• Dia e horário do Dojo
• Uma hora foi muito pouco tempo
• Deveria ter codificado a proposta (Busca binária) desde o início, ao invés de fazer só pra passar nos testes (linear)

Como vocês podem ver, tivemos poucos itens bons em comparação com Poderia ter sido melhor e Não gostei. Normal para uma primeira tentativa

Algumas fotos do evento:

Todas as fotos podem ser vistas no nosso álbum do Flickr.

É isso aí pessoal. Muito bom o Dojo! Até o próximo!

CodingDojo na Unimontes – 11/12/2009 – Apareça lá!

Fim das aulas, agora nos “sobra” tempo para fazer algumas atividades que não conseguimos fazer durante o semestre. Uma delas é o CodingDojo, prática que queríamos ter tempo de fazer há alguns meses.

Pra quem não sabe o que é um Coding Dojo, segue um vídeo:

Não há necessidade de saber TDD. Se souber, ótimo. Se não souber, você irá aprender

O Coding Dojo começará às 19:30 de sexta-feira (11/12/2009) na sala de multimeios  do Centro de Ciências Exatas e Tecnológicas (CCET) da Unimontes e a linguagem será decidida na hora! Já estamos ajeitando o material necessário (o projetor é o principal) e não é necessário nenhuma contribuição financeira para participar do Coding Dojo.

No entanto, é costume levar comes e bebes para consumirmos durante a sessão.

Cada sessão dura aproximadamente uma hora e meia, então o horário previsto de término será às 21:00. Fiquem atentos à esse post, pois qualquer mudança de planos será comunicada aqui!

Alguns links interessantes:

• Google Video
• CodingDojo.Org
• Agileblog da Locaweb

See you!

== EDIT ==

Algumas pessoas perguntam se escolher a linguagem na hora pode ser prejudicial, então, por enquanto, a linguagem a ser usada no nosso primeiro Dojo será Java. A maioria da galera conhece Java e quem não conhece aprende rápido (pelo menos para o Dojo

Final de período/ano

Final de período e ano sempre são complicados para todos os acadêmicos. Nós não somos exceção.

Ainda estamos trabalhando e atualizando o blog para os nossos (poucos) subscribers.

O que podemos dizer agora é que temos muito trabalho ainda (o lado bom é que para nós ele nunca falta e alguns planos de trabalho para as férias, momento onde tudo se ajeita.

Estamos contando com a ajuda de alguns egressos e isso está sendo de grande valia, pois alguns alunos dos períodos iniciais não tem tanta noção da área quanto o pessoal que já saiu da Universidade.

Procuraremos daqui em diante manter os nossos leitores e membros mais atualizados através do blog , afinal ficar um mês sem postar nada é fim de carreira

Um resumo da nossa experiência

O GWIB teve seus primeiros passos no fim de Maio deste ano. A proposta era criar um grupo para estudos de tecnologias Web para trabalhar na Infobits (nessa época, a empresa ainda não estava formalizada, por isso éramos um grupo informal ainda).

Como a maioria nunca tinha trabalhado em um projeto profissional, tivemos que começar do início. Adotamos pois, a idéia de alguem explicar na frente de todos no laboratório e os outros participantes acompanharem a explicação. Resultado: ficamos mais de um mês passando conteúdo duas ou três vezes na semana e pouca gente conseguiu aprender o básico de CSS e HTML. Sensação de aproveitamento paupérrimo no fim do semestre.

Diante essa análise de produtividade, resolvemos fazer algo um pouco diferente: treinar o mínimo de pessoas possível para que essas pessoas tenham capacidade de passar esse conhecimento. Fizemos o treinamento em pares: sentávamos junto a alguem que estava querendo aprender algo, explicávamos de forma sucinta e pedíamos para a pessoa reproduzir de outra forma.

O resultado foi muito bom: ao invés de tentar treinar 10 ou 15 pessoas de uma vez com resultados ruins, treinávamos três ou quatro de maneira que ia além do razoável. Em uma semana, conseguimos fazer mais do que fizemos em um mês e meio e tudo isso graças a essa espécie de pair programming voltada ao ensino.

O único problema é que nós éramos um grupo totalmente aberto: bastava chegar e pedir pra alguem ensinar algo. Dessa forma não funcionava muito bem, pois a idéia é que a pessoa que aprendesse pudesse passar os conhecimentos que ela adquiriu para outras pessoas e simplesmente algumas pessoas desistiam ou não voltavam depois de aprender algo. Resolvemos fechar o grupo: sem mais visitantes esporádicos.

Depois de algum tempo, alguns problemas foram solucionados e outros surgiram. Devido à falta de estrutura da Universidade, tivemos problemas com servidores, controles de versão, laboratórios (é difícil, pois não temos prioridade nas máquinas e não é somente nós que mexemos). Conseguimos sanar a maioria desses problemas e estamos conseguindo trabalhar razoavelmente bem.

Hoje temos um sistema de gerenciamento de projetos, um Wiki, um blog, um site e um servidor na Internet para controle de versões. Estamos passando por alguns problemas com o controle de versões, pois um roteador da nossa operadora de serviços de Internet aparentemente está bloqueando o WebDAV, por isso não conseguimos usar o mesmo. Já entramos em contato com os responsáveis e não deve demorar muito para o problema ser sanado.

Estamos sentindo falta de uma metodologia para trabalhar com pessoas nas nossas condições. Como alguns trabalhos são voluntários, não podemos exigir dedicação, então, metologias como o Scrum e o XP estão fora do nosso alcance atualmente (estamos adotando algumas práticas, mas não a metodologia completa ainda). Algumas pessoas nos sugeriram o Kanban. Gostaríamos de ver algumas opiniões a respeito

Ainda hoje estamos com um nível de conhecimentos desigual dentro do grupo e o mesmo cresceu de uma forma que fica um pouco difícil organizar como somente um grupo (temos mais de dez pessoas… imagine como é uma reunião diária com dez pessoas). Estamos pensando em uma separação, mas não deve acontecer por agora.

Ainda procuramos ver algumas coisas novas em momentos mais calmos. Semana passada vimos o básico de TDD e ainda vimos como fazer algo na prática usando o CakePHP com o SimpleTest. Ainda vimos um pouco de TDD usando Java. Estamos pensando em organizar um Coding Dojo, mas não é algo que deva acontecer esse ano ainda.

Apesar das dificuldades, ainda temos entusiasmo para tocar o grupo pra frente e continuar desenvolvendo projetos

Site online!

Hoje, finalmente, o GWIB hospedou o site da Infobits. Resolvemos problemas com servidor da hospedagem e o nosso endereço de acesso é o www.infobitsunimontes.com.br

Trata-se de uma versão inicial. Não contém muita coisa ainda e o próximo passo é criar uma área administrativa um pouco mais completa e colocar os feeds para as notícias.

Até mais.

Um pouco sobre histórias de usuário

Na Academia, costumamos documentar requisitos através de casos de usos e seus fluxos. A maioria das pessoas reclamam por terem que detalhar, modelar e observar os relacionamentos de todos os casos de uso com o argumento que nem tudo aquilo será usado. O problema é que muitos de nós vemos isso como um dogma, uma tarefa que tem que ser feita somente dessa mesma forma e que se for feita de outra, ninguem vai se responsabilizar se seu projeto falhar por falta de documentação.

A novidade é que há formas menos dolorosas/trabalhosas de coletar requisitos. Uma delas são as histórias de usuário (user stories).

As histórias de usuário servem para o mesmo propósito dos casos de uso, mas não são a mesma coisa. Segundo Matin Fowler, as histórias de usuário geralmente são mais granulares pois elas precisam ser completamente feitas em uma iteração. Geralmente, o cliente coloca a descrição, a prioridade da história e o nome dela, o(s) desenvolvedor(es) dão as estimativas do tempo necessário para se implementar a história e podem ou não adicionar notas e comentários.

Um outro propósito das histórias de usuário é servir de guia para os testes de aceitação.

Você pode desenhar um caso de uso e talvez escrever seu fluxo para uma história. Modelos e diagramas são bem vindos quando nos ajudam compreender o domínio e a lógica de um problema. O foco das histórias é servir como documentação útil dos requisitos do cliente para que os desenvolvedores possam estimar o tempo que a mesma levará para ser produzida. No Scrum, o conjunto de todas as histórias de um projeto é chamado de Product Backlog.

Exemplo de um product backlog bem simples com duas histórias (retirado de Scrum e XP direto das trincheiras de Henrik Kniberg).

Geralmente, as histórias são escritas à mão em um cartão. Quando uma história não é o suficiente para descrever o requisito, novas discussões podem ser feitas e novas histórias podem ser escritas.

Um exemplo de cartão de história retirada daqui. Nesse exemplo, a bolinha laranja no canto superior esquerdo diz respeito ao progresso de desenvolvimento da história e no resto do cartão, nós temos informações como o dono da história (quem a escreveu), a estimativa inicial, o progresso de desenvolvimento e a história em si.

Há muito material disponível na Web e em livros sobre histórias de usuários. Seguem alguns links importantes:

• http://www.brod.com.br/diario/scrum-user-stories
• http://improveit.com.br/xp/praticas/historias
• http://pt.wikipedia.org/wiki/Teste_de_aceita%C3%A7%C3%A3o
• http://www.martinfowler.com/bliki/UseCasesAndStories.html
• http://www.agilemodeling.com/artifacts/userStory.htm
• http://c2.com/cgi/wiki?UserStoryAndUseCaseComparison
• http://www.extremeplanner.com/blog/2006/01/writing-good-user-stories.html
• http://www.agile-software-development.com/2009/02/user-stories-v-use-cases.html
• http://www.amazon.com/exec/obidos/ASIN/0321205685/ambysoftinc/

P.S: Acho que deu pra perceber que esse post está muito sucinto e acho que pode gerar algumas dúvidas. Portanto, não deixem de comentar e perguntar. É com base nos comentários que iremos escrever outros posts sobre o assunto.

É isso aí e até a próxima!

Habemos servidor!

Depois de muita luta, conseguimos um servidor provisório para colocar o Apache, MySQL e o SVN.

É provisório porque estamos usando um desktop para hospedar esses serviços, não está com o sistema operacional que desejamos (Ubuntu Server) e ainda não temos um ponto de rede (está pela rede wireless da Unimontes).

Apesar de tudo, agora temos a mínima infraestrutura para trabalhar. Estamos trabalhando para colocar uma VPN para possibilitar os membros trabalharem de casa.

Primeiro Gwibbers Knowledge Journey!

Como de costume, o GWIB ministra um “trote” nos novatos com algum tipo de atividade. Dessa vez decidimos planejar um seminário que tratará sobre desenvolvimento colaborativo de software, algumas ferramentas que não conhecemos na academia e metodologias ágeis de desenvolvimento de software.

Todo o seminário será ministrado pelos membros e poderá contar contar com ajuda de outros profissionais da área.

Alguns dos tópicos são estranhos para o nosso âmbito acadêmico, porque não são muito discutidas dentro da academia, principalmente entre os professores. Outras já consagradas são  pouco usadas seja por resistencia das empresas ou por parte dos próprios desenvolvedores.

Os temas a serem descutidos são os seguintes:

Controle de versão de código (git, svn e outros)

Bug Tracking

phpUnderControl – Cruise Control

Xdebug

MVC e CakePHP (ou Simphony)

Wikis e microblogging

Estudo de caso do grupo sobre programação em pares

Alguns temas já estão definidos, com pessoas interessadas em fazer pesquisa sobre eles. Outros ainda não. De fato, ainda não fechamos qual será a programação oficial e estamos abertos à sugestões de temas para o nosso seminário.

Todas as apresentações serão gravadas e publicadas em algum serviço de hospedagem de vídeo (de preferência o viddler ou o vimeo) e a parte escrita da pesquisa será postada aqui no blog.

Diferentemente de um trabalho acadêmico convencional, esse seminário servirá para despertar o interesse dos membros para alguns assuntos e para ajuda-los a fazer pesquisa de verdade, pois eles terão que correr atrás de empresas em busca de alguns depoimentos e cases para enriquecer o trabalho e não precisarão se preocuparem com notas

Como de costume, o GWIB ministra um “trote” nos novatos com algum tipo de atividade. Dessa vez decidimos planejar um seminário que tratará sobre desenvolvimento colaborativo de software, algumas ferramentas que não conhecemos na academia e metodologias ágeis de desenvolvimento de software.

Todo o seminário será ministrado pelos membros e poderá contar com ajuda de outros profissionais da área.

Alguns dos tópicos são estranhos para o nosso âmbito acadêmico, porque não são muito discutidas dentro da academia, principalmente entre os professores. Outras já consagradas são  pouco usadas seja por resistencia das empresas ou por parte dos próprios desenvolvedores.

Os temas a serem discutidos são os seguintes:

• Controle de versão de código (git, svn e outros)
• Bug Tracking
• phpUnderControl – Cruise Control
• Xdebug
• MVC e CakePHP (ou Simphony)
• Wikis e microblogging
• Estudo de caso do grupo sobre programação em pares
• Drupal

Alguns temas já estão definidos, com pessoas interessadas em fazer pesquisa sobre eles. Outros ainda não. De fato, ainda não fechamos qual será a programação oficial e estamos abertos à sugestões de temas para o nosso seminário.

Todas as apresentações serão gravadas e publicadas em algum serviço de hospedagem de vídeo (de preferência o viddler ou o vimeo) e a parte escrita da pesquisa será postada aqui no blog.

Diferentemente de um trabalho acadêmico convencional, esse seminário servirá para despertar o interesse dos membros para alguns assuntos e para ajuda-los a fazer pesquisa de verdade, pois eles terão que correr atrás de empresas em busca de alguns depoimentos e cases para enriquecer o trabalho e não precisarão se preocuparem com notas

Um pouco sobre desenvolvimento ágil de software

Uma coisa que não vimos muito aqui na universidade é pessoas e professores comentando sobre desenvolvimento ágil de software.  O assunto foi um pouco comentado hoje durante a reunião e foi possível ver que a maioria das pessoas ficaram “boiando” quando ouviram expressões como: scrum, sprint, product backlog, product owner, burndown, estórias, integração contínua, test driven development e etc.

Por isso, decidimos postar no nosso blog algum material sobre o assunto. O primeiro é um vídeo do Vinícius Manhães Teles que fala sobre Extreme Programming (XP) e metodologias ágeis em geral.

Um outro vídeo bastante interessante que foi lançado recentemente, é o Agilidade, Qualidade e Futuro, do Fábio Akita. No vídeo, o Akita compara o modelo de desenvolvimento de software em cascata com os métodos ágeis e dá uma visão geral do Scrum dentre várias outras metodologias, como o Lean.

Agilidade, Qualidade e Futuro from Fabio Akita on Vimeo.

Como algumas pessoas empolgam mais quando vêem que a ferramenta funciona na prática, decidimos colocar o estudo de caso da globo.com, que resolveu adotar o Scrum:

Deixando os vídeos um pouco de lado e passando para materiais escritos, a primeira recomendação é o Scrum e XP direto das Trincheiras, um ebook gratuito escrito pelo Henrik Kniberg. Se trata de um livro extremamente interessante onde o Henrik conta de forma divertida e descontraída como ele aplica o Scrum e o XP no seu trabalho. É um MUST-READ para quem quer conhecer mais do assunto.

Como o livro do Henrik foca mais em Scrum, um outro MUST-READ é o material de XP que a Improve-it disponibiliza.

Esse material está extremamente incompleto se comparado com a documentação disponível sobre o assunto, mas já serve para dar vários esclarescimentos sobre o assunto e evitar que se fique “boiando” quando alguem conversar sobre o assunto. Não deixem de comentar se acharem algo interessante na Web sobre o assunto, ok?

Bons estudos

===EDIT===
Pessoal, esqueci de postar duas grandes referências:

1. Agile Manifesto
2. www.extremeprogramming.org/

Deve haver várias outras. Vou postando a medida que for encontrando.