Tips to Agile

Dando uma passeada pelo blog Teach Me To Code, Andy Hunt (@PragmaticAndy) mostra 11 dicas onde ele diz “o que você precisa para se tornar ágil e por onde começar”:

Faça um pouco de coisas certas todo o tempo (Baby Steps)

Você será o expert no projeto no fim do projeto! Adie as decisões importantes até que você entenda o problema.

Faça reuniões em pé.

Defina regras. Porém elas devem ser básicas, simples.

Certifique-se que você tem um ambiente de controle de versão e desenvolvimento estável.

Faça testes unitários.

Pratique a integração contínua

Revisões de Código/Pair Programming – Formas de checar o código

Envolva o cliente no projeto.

Produza algo no período de 1-4 semanas.

Retrospectivas – Sempre obtendo Feedback do Projeto

Encontros do GuruPI – parte 3

Continuando a seqüência de posts com as apresentações do GuruPI, as palestras do quarto encontro:

4º GuruPI (21/mai/2011)
Leilão de centavos com NodeJS + Socket.io + Rails 3.1 + MongoDB + Redis – @caironoleto

Usabilidade para designers e coders – @artefaelmarques

Começando com HTML5: Dicas e Boas práticas – @cleitonfco

1º GuruPI (18/set/2010)
2º GuruPI (20/nov/2010)
3º GuruPI (12/fev/2011) – Não houveram palestras, apenas #horaextra! 🙂

Encontros do GuruPI – parte 2

Continuando a seqüência de posts com as apresentações do GuruPI, as palestras do segundo encontro:

2º GuruPI (20/nov/2010)
Introdução a Sinatra: use o framework certo pra sua aplicação (ou não) – @samflores

Quebrando janelas – Migre para *nix e seja um desenvolvedor eficiente/feliz – @weldyss

Caindo na Real: faça menos virar mais – @pauloh

– @dmitrynix

1º GuruPI (18/set/2010)
3º GuruPI (12/fev/2011) – Não houveram palestras, apenas #horaextra! 🙂
4º GuruPI (21/mai/2011)

Encontros do GuruPI – parte 1

Salve, galera!

Nesta seqüência de posts colocarei todas as palestras que se passaram no GuruPI, desde o primeiro encontro até o quarto.

1º GuruPI (18/set/2010)

RVM – Ruby Version Manager – @caironoleto

O universo em torno do Ruby/Rails – @cleitonfco

2º GuruPI (20/nov/2010)
3º GuruPI (12/fev/2011) – Não houveram palestras, apenas #horaextra! 🙂
4º GuruPI (21/mai/2011)

Chamando o TextMate do terminal

Se todas as tentativas forem em vão, tente esta:

alias mate='/Applications/TextMate.app/Contents/Resources/mate'

e tudo volta ao normal 🙂
Dica do mdskinner.com

Venha fazer parte do GuruPI

Pra galera da #CaravanaPI que foi ao #braziljs (ou não) e que não conhece ainda o Grupo de Usuário Ruby do Piauí:

O GuruPI foi criado em agosto/09, no período do primeiro Oxente Rails, porém somente após o segundo Oxente Rails (agosto/10) o grupo começou a ter encontros regulares, com lightning talks dos membros, disseminando os mais variados temas (não apenas relacionados à linguagem Ruby). Nessa época passamos a trocar idéias pela lista de discussões. Você pode também conferir novidades sobre encontros no perfil do twitter.

Quer falar como você fez aquela app e mostrar pra galera como/o quê você (ou a equipe) aprendeu durante o desenvolvimento?
Tá afim de falar daquele livro de Django, Extreme Programming, REST ou JQuery?
Pode falar também o quanto você apanhou e como conseguiu fazer deploy da sua app usando Capistrano.
Ou quer passar pra galera o que você aprendeu naquele curso de Node.JS?

Então venha fazer parte do grupo! 🙂
Teremos o maior prazer em receber você.
Ah, e sempre tem #horaextra depois.

Será um prazer contar com a presença de todos na lista 🙂

mudanças são do mal

calma, não to afirmando isso!
depois de ver umas leituras aqui, aqui e este vídeo, afirmei aquilo que eu sempre imaginava: mudanças em desenvolvimento de software são inevitáveis!

mais que isso, é algo inerente ao projeto, é uma premissa!

lembro que, ainda estagiário, meu sangue esfriava e minha pressão baixava com medo das mudanças no projeto. era visível a cara de medo e tristeza na equipe quando a mudança era dita. quem nunca ouviu falar nas tais “solicitações de mudança”? Ai daquele que acha que produzir software é como levantar um prédio.

a própria imprevisibilidade de requisitos de @martinfowler, fala a respeito disso. a troca de conhecimento em palestras e, claro, experiência, aprendi que mudanças são normais.
veja bem: são normais, o que não impede da equipe aceitá-la sempre ou deixar que ela ocorra. tudo depende do custo de se implementar a mudança. vale a pena fazer a mudança de R$10.000,00 numa sprint de duas semanas? será que aquela mudança que custaria apenas R$100,00 não agregaria mais valor ao projeto?

aí voce pode se perguntar: “e como fica o projeto? o cliente não gosta dessas mudanças!”. acredito que as iterações curtas (de 1 semana) servem para conseguir um feedback constante pro cliente. ou você acha melhor apresentar as funcionalidades 1 mês ou as merdas 1 ano depois? =]

especialista vs generalista

há muito tempo venho batendo cabeça com um tema na área de desenvolvimento de software: devo ser um especialista em determinado assunto ou devo ser um generalista, conhecendo as áreas da engenharia de software por alto?

quando entrei no desenvolvimento , imaginava que as especialidades (analista de negócios, levantador de requisitos, especialista java, arquiteto de software) eram extremamente necessárias.

hoje, vejo que equipes que compõem apenas especialistas (digo, apenas em uma área e nada mais) tendem a agregar sérios riscos aos projetos: comunicação e aprendizado.

depois que vi a palestra do alê gomes* (@alegomes) no Oxente Rails (Start You Up – Não basta desenvolver, tem que empreender), concretizei aquilo que se passava na minha cabeça: projetos de desenvolvimento de software e projetos de engenharia civil não são a mesma coisa.
acredito que tenha sido uma burrice um erro comparar a engenharia de software com a engenharia civil. e ainda trouxeram o tal do comando-controle de lá.

os projetos no modelo comando-controle têm um desempenho medíocre falho. não é preciso bola de cristal ou invocar entidades superiores para prever que o time vai desanimar no decorrer dos projetos.

demorou pouco tempo pra perceber que a engenharia de software é uma área de intensa criatividade, e não deve ser tratada como um modelo de fábrica, onde existem apenas especialistas.

é nisso que acredito. fica minha opinião.

* alê gomes, da SEA Tecnologia, propõe a adoção de novas formas de empreender, liderar e praticar a engenharia de software.

aprendizado de uma equipe

hoje pela manhã apresentei um vídeo do @viniciusteles pra equipe (do projeto que participo) sobre documentação ágil. reflete bastante o que eu penso (com alguns extras). como a experiência e o nome de peso tem mais impacto, acredito que futuramente estarei colhendo alguns bons frutos 🙂
segue aí o vídeo
http://vimeo.com/1450383

balanço após o infofelc 2010

de volta à teresina e aos projetos na remanso 😀

o infofelc está apenas na segunda edição e já mostrou ser um evento muito bem organizado. ao chegar na cidade (uiraúna – pb), me deparei com pessoas acolhedoras e muito interessadas em fazer do evento algo marcante!

no primeiro dia, a apresentação do evento contou com a diretora da fundação, fátima claudino e com palestras com a galera do ifpb de cajazeiras. vale ressaltar as apresentações do francisco braga e a vontade de se tornar commiter do brOffice e a excelente palestra do esequias neto sobre biometria digital.

no segundo dia, palestras com a galera da Remanso: @pauloh (eu :D) sobre agilidade em projetos de software e o @stanleyalves sobre jpa … além do minicurso de iReport com o @ramonmelo.

contei também com um ótimo feedback e networking com a galera de teresina : o gilson alves do Armazém Paraíba, o marlos, da faculdade CET e o João Marcello, da UFPI. e a galera da própria Uiraúna: Rodrigues, Romário, Simone entre outros.

ano que vem esperamos mais profissionais da área no evento, que tem tudo para ser um dos melhores da região!