Resumo TDC 2010 – Domingo

By Gabriel Rubens

Agora o último resumo feito pelo André, é um resumo de como foram as palestram de domingo no TDC 2010.

Para mim Domingo foi disparado o melhor dia! Segui a trilha de Agile.

Primeira palestra: Código Limpo:

Palestrante: Hugo Corbucci: http://twitter.com/hugocorbucci

A mesma palestra, só que num evento anterior: http://devinsampa.blip.tv/file/4024593/

Falou da importância de ser ter código fácil de se manter, ser profissional, somos pagos para testar, documentar e escrever código correto.

Temos que corrigir o código assim que possível, não deixar a DÍVIDA TÉCNICA crescer de forma a ficar impossível de ser refatorar depois.

Se o código está muito sujo, mesmo que seja de outro programador, devemos ir corrigindo aos poucos.

Código sujo, de uma forma resumida, é código que não segue padrões, sem identação adequada, com nomes de variáveis, métodos que não correspondem ao que eles realmente fazem.

Podemos medir um código ruim, pelo quantidade de “Que porra é essa” ditas por minutos, uma alusão ao tempo que você demora para entender código de outro programador.

Código limpo, é aquele que você bate o olho e sabe dizer o que ele faz, mesmo sem ler o bloco de código.

Dicas para manter um Código Limpo:

Refatorar o código sempre:

1. Controle o tamanho do código. Em geral um método não pode ser maior que sua tela, ou seja, umas 30 40 linhas, reparta em métodos menores;

2. Revele suas intensões: Escolha bons nomes para suas Classes, Variáveis, Métodos, enfim, tudo. Cuidado com comentários: É muito constante ocorrer o fato de você arrumar ou refazer um código e deixar o comentário antigo lá, atrapalhando o entendimento. Por último: faça testes unitários!!! Na hora você consegue saber o comportamento de um método.

3. Controle fatores externos: Proteja o software, Faça testes de integração, afinal, as classes tem que conversar umas com as outras. Faça o tratamento de erros corretamente e não se esqueça da concorrência, ou seja, execução simultânea de um mesmo bloco de código entre duas threads.

4. Formatação do código: Siga a padronização! Use muita identação. Nós identificamos muito mais rapidamente pelo VISUAL; Deixe o código formatado de uma maneira que só de bater o olho dá para saber o que ele faz. (Peça a opinião de outra pessoa). Use também o espaçamento vertical: separe os blocos de código como numa redação: reúna as linhas que executam uma mesma idéia.

5. Regra do escoteiro: Sempre que você ver um código ruim, arrume-o! Se o código é grande, faça uma pequena correção apenas para entender o que ele faz. Desse modo, sempre que algum programador passar por ele, vai corrigindo em pequenas partes até ficar bom.

Pergunta no final da palesta:

Como eu faço se eu encontrar um código péssimo, extremamente crítico para a aplicação, de modo que se eu mexer errado pode ocorrer uma tragédia, ou seja, uma verdadeira bomba atômica.

Resposta:

1. primeiro escreva um teste básico e rode! Provavelmente você não vai conseguir rodar porque vai ter uma porrada de dependências no código;

2. Vá criando mocks necessários e tentando rodar o teste;

3. Quando conseguir isolar a bomba, ou seja, conseguiu criar os mock necessários o passar no teste básico, comece a criar os testes pra valer;

4. Após ter criado todos os testes que você conseguir identificar como necessários, comece a “cortar os fios” da bomba.

Todo esse processo demora muito. Dependendo do código, se antes de começar a cortar os fios você descobriu que alguns testes falham, mostre para os responsáveis, pois até ai você ainda não mexeu em nada do código original.

Segunda Palestra: Integração Contínua

Palestrante: Giovanni Bassi, http://twitter.com/giovannibassi

Slide: http://www.slideshare.net/giovanni.bassi/integrao-contnua-5033914

Integração contínua é uma prática. Mostrou opções de como aplicá-la em ambientes diversos, com repositórios centralizados e distribuídos. Ele recomendou SVN, Mercurial ou GIT, sendo que repositórios distribuídos tem um sistema de merge e controle de versão superiores e permite o desenvolvimento de branchs em paralelo. É importante eleger alguém para o papel de integrador, ou seja, que funcionalidade entra ou não no trunk principal.

Para funcionar é essencial se automatizar tudo o que for repetitivo. Item principal: Escrever TESTES.

Mostrou como seria o fluxo ideal de desenvolvimento concorrente:

- Início do trabalho: Baixar todo o código commitado;

- Mandar executar o teste integral. Desde modo você se certifica que não baixou código quebrado, que não compila ou roda.

- Desenvolver seu código.

- Testar seu código.

- Testar todo o código (teste integral).

- Baixar todo o código commitado até agora.

- Rodar o teste integral. Importante: se não passar no teste, interrompa o trabalho dos envolvidos e resolve na hora.

- Commita todas suas alterações.

- Compila e testa na máquina de homologação.

Práticas de Integração contínua:

1. Estrutura do repositório de código: (centralizado ou distribuído)

Projeto

|— Branch1

|— Branch2

|— Trunk

—–|— docs //-> manuais, documentação

—–|— libs //-> todas as libs usadas na versão atual do trunk

—–|— src

———–|— meu projeto

—–|— toots

2. Build Automático:

Tudo tem que estar configurado para ser executado com um único click, incluindo banco de dados e testes. As ferramentas atuais permitem isso.

3. Frequência de commits:

Pelo menos 1 vez por dia. Terminar uma tarefa por dia. Se não está conseguindo terminar, reduza o tamanho das tarefas.

Importante: O seu commit gera um build? Então só termina após o build passar em todos os testes.

Se os testes são demorados use testes de fumaça, ou seja, rodar os testes básicos e deixa os demais testes agendados.

É necessário ter uma máquina dedicada ao build. A partir dela são geradas as releases.

O teste do ambiente tem que ser equivalente ao da produção.

Permitir que qualquer desenvolver tenha acesso fácil ao build, seja um EXE ou WAR/EAR

Todas as informações de compilação do build e dos testes precisam estar disponíveis na hora.

Em algumas empresas, quando um desenvolvedor quebra o build, sua foto é divulgada, em painel eletrônico ou e-mail, com um grande #FAIL anotado. Fica lá até o problema se resolvido.

Ir para produção? Tem que ser com um click também. E ter a opção de retornar ao estado anterior imediatamente, com um click também (Ctrl+Z)

Terceira Palestra: Cultura mais que a práticas – Na minha opinião, essa palestra valeu o evento inteiro!!!

Palestrante: André Nascimento: http://twitter.com/alnascimento

Gerente executivo da Stefanini IT Solutions em São Paulo.

Ainda não tem o slide, mas, vendo o blog, encontrei um post muito bom: http://blog.anascimento.net/2010/07/14/faz-sentido-bloquear-internet/

Nossa área está prostituída!!! Fábricas de software contratam a rodo profissionais sem nenhuma experiência, juniores, estagiários, que aceitam qualquer valor, para “desenvolver” até sistemas críticos, com prazos impossíveis. Só querem ganhar dinheiro, entregar o lixo e sair correndo!

Fecharam contrato com uma gigante para desenvolver seu e-commerce.

Uma equipe com os analistas mais experientes levantou os requisitos e casos de uso do cliente.

Um ano depois entregaram uma tonelada de documentação. Eles mesmo não conseguiam entender perfeitamente toda a documentação imaginem o cliente, que não conseguia validar. Desenvolvimento iniciou, já havia comprometido metade do orçamento, quando eles perceberam que não ia dar.

Para tudo! Se sabe que vai cair no abismo, não tem o porquê continuar empurrando.

Se reuniram para decidir qual atitude tomar para trazer novamente o projeto aos trilhos. Ouviram falar de um tal de Scrum, metodologia ágil, essa promete! Reuniram os líderes, fizeram o melhor curso que encontraram, voltaram e estava decidido: “Agora somos ágeis, vamos trabalhar assim”. A equipe não entendeu nada o que eles estavam falando, então deram treinamento de 15~30 dias para o resto da equipe. Não adiantou bosta nenhuma. Equipe ficou perdida, entregaramum sistema ruim (lembram-se daquela e-loja famosa que oferecia notebooks a 9,90, macbooks a 100 reais?, pois é…), ficaram decepcionados e agora tinham motivos pra falar mal dessa tal metodologia ágil.

Eles tentaram seguir o conceito do K.I.S.S (Keep It Simple Idiot), mas não é bem assim, ser ágil exige uma equipe interdisciplinar madura, que além de dominar conceitos de TDD, BDD, sabe que a responsabilidade é de todos, inclusive do cliente. Antes a equipe era composta de programadores, dbas, designers e testers, ou seja, cada um estava preocupado só com a sua parte, como numa “Fábrica”, mas ninguem se responsabilizava pelo todo. As pessoas costumam ser tratadas como “recurso”.

Também não adianta impor uma tecnologia, uma metodologia, nem dar treinamento e largar lá pra “se virarem”. Tem que ter coaching, tem que ficar do lado. Hoje eles tem gente lá que só faz isso, inclusive, tem até coaching para ensinar o cliente a ser Product Owner.

Não caiam da Hipe (não siga a onda). Tá cheio de consultoria dizendo que é ágil por ai. Chegam no cliente, “levantam o blacklog” e entregam o “cronograma do Sprint”. Hoje tem até curso de MBA que ensina a fuder com o fornecedor. Explica como usar artifícios de contrato para por toda a responsabilidade em cima do fornecedor. É a cultura do Go Horse, acessem: http://gohorseprocess.wordpress.com/extreme-go-horse-manifesto/

ANTES DE SER ÁGIL, PRECISA TER CULTURA ÁGIL.

Eles querem se livrar do termo “Fábrica de software”, por enquanto estão usando um o nome provisório de “Software Delivery Center”.

NÃO EXISTE CRONOGRAMA DETALHADO! Um cliente pediu: quero o cronograma completo do projeto. Ele respondeu: Cliente, você quer ser enganado? Eu não quero te enganar.

Eles preferem negar o projeto à ter que desenvolver no modelo em cascata. Se o cliente tiver a cabeça fechada e não entender, ou eles mandam fazer com outros, ou tentam passar para as demais filiais que ainda trabalham assim. Somente a equipe dele em São Paulo que pratica metodologia ágil. Eles estão discutindo como fazer para espalhar para as demais unidades.

PRECISA TER APOIO DA GESTÃO!!

Depois do fracasso da primeira tentativa, eles tiveram que dedicar tempo para pensar em como mudar a cultura, trabalhar com as pessoas. Ele ainda acreditava na metologia, sabia que tinha gente capacitada lá para isso, mas sem o apoio da liderança não seria possível.

GESTÃO PARTICIPATIVA!!!

Todos participam, todos precisam ter autonomia para decidir pois, só assim serão auto-gerenciaveis. Ele procurou ler a literatura do Ricardo Semler, para ter exemplos e aplicar na empresa:

- Banir Comando e Controle. (engraçado que ainda ensinam isso na faculdade, eu tive em 2008!!!). Fim do Manda quem pode, Obedece quem tem juízo. O “Gerente/Chefe/Diretor” tem que aprender a ser líder (Leiam: O Monge e o Executivo)

-  Auto organizável: Trabalho verdadeiramente em equipe. As pessoas tem que agir, ser pró-ativo, não esperar alguém te passar serviço. Se não tem o que fazer, vá ajudar aos outros.

- EVIDENCIAR OS PROBLEMAS: FALA LOGO O QUE TA ERRADO, SOBRE SEU TRABALHO, SOBRE AS DEMAIS PESSOAS, ABRA O JOGO! NÁO DEIXEI A MER#@ CRESCER E ESTOURAR. FALE O QUANTO ANTES, PARA TODO MUNDO OUVIR.

A decisão de contratar e demitir é do próprio time. Hoje eles demoram para contratar, mas para demitir é um instante. Certa vez a equipe tentou, ajudou mas um cara não conseguia ser adaptar a cultura da empresa. Então eles sugeriam: “Não tem como remanejá-lo para outra equipe?” e a resposta: “Mas como? querem fazer tráfico de drogas?”. Uma alusão ao fato de que a única pessoa que pode mudar você é você mesmo. Se a pessoa só oferece resistência à mudança, não adianta insistir.

- APRENDER SEMPRE!

Não pode parar de estudar e, inclusive, durante o horário do trabalho se precisar.

O trabalho tem que dar prazer. Eles não pegam projetos em que o cliente comenta: “Vai precisar fazer hora extra e trabalhar nos finais de semana”. Eles não sacrificam os funcionários em trocar de fechar contratos desse tipo, obviamente NÃO porque eles querem ou gostem, mas porque ISSO TRÁS RETORNO FINANCEIRO!!!

Para quem não conhece o Marco Stefanini, O Dono, SÓ PENSA EM DINHEIRO. Ele não ia permitir que tudo isso fosse feito se não desse retorno financeiro.

Atualmente 90% dos projetos estão dentro do tempo, orçamento E FORA DO ESCOPO INICIAL do contrato, ou seja, atendendo em 100% as necessidades do cliente. Mas deixou claro que ainda estão longe do que pretendem aplicar por lá.

Eles também usam a metologia Kanban para manutenção de alguns sistemas.

E finalmente, ele conclui a palestra dizendo que faz parte do grupo de “Cascateiros Anônimos” pois, sabe como é né? Entre um cliente aqui, outra equipe ali, você sempre encontra alguém fumando project por ai…

Nas perguntas do final, ele falou que está numa campanha para tornar o salário público para todos dentro da empresa. Comentou que a diferença salarial entre um júnior recém contrato e um sênior é muito pouca.

Quarta Palestra: O sistema Kanban para equipes de manutenção

Palestrante: Dairton Bassi: http://twitter.com/dbassi

Mostrou como funciona o Kanban.

Importante, também sobre cultura: Ao invés de Revolucionar, Evoluir!!! Nunca dizer que vai revolucionar, tentar implantar toda uma metodologia, que exige mudança de cultura, de uma vez só. Vá evoluindo aos poucos, caminhe naturalmente de acordo com o seu ambiente, pois isso reduz a resistência.

Assim como qualquer outra metodologia ágil, Kanban, por ser menos burocrático que Scrum, exige ainda mais uma equipe interdisciplinar madura, com boa experiência em TDD, BDD, Design Patterns, enfim, todas as boas práticas da orientação à objetos.

- Quebrar as funcionalidades em tarefas bem pequenas;

- Limite a quantidade de tarefas de acordo com a capacidade de absorção dos desenvolvedores. Não permita que um desenvolvedor trabalhe simultaneamente em duas ou mais tarefas simultaneamente.

- Kanban não tem iterações como o Scrum, ou seja, não se determina “Sprints” com tempo, incio e fim. Ele implementa fluxos contínuos, onde as funcionalidades vão sendo entregues conforme vão ficando prontas.

- Estimativas são opcionais…

Ele mostrou algumas métricas para medir desempenho da equipe, tempo de duração de desenvolvimento de uma estória, etc…

Para adotar o Kanban (além do que eu já escrevi acima)

- Mapeie seu fluxo de valor;

- Visualize seu workflow;

- Limite o trabalho em progresso;

- Meça seu desempenho;

- Estabeleça uma cadência;

- Viabilize melhoria contínua.

Kanban é puxado. O próximo livre da equipe escolhe a tarefa que vai fazer. Ninguém vai ter passar uma tarefa pra fazer (promover a melhoria do trabalho em equipe);

Comentou do http://alissonvale.com

Quinta Palestra: Porque devo me interessar por Lean?

Palestrante: Samuel Crescêncio: http://twitter.com/screscencio

Slide: http://prezi.com/w6pjte9n4bsq/the-lean-pyramid/

Mostrou a metologia Lean.

Assim como as demais metodologias ágeis: Precisa de uma equipe bem desenvolvida.

Princípios:

- Entregar valor contínuo;

- Promover aprendizado contínuo;

- Criar melhoria contínua.

Ele considera também os valores que os criadores do Lean, Mary e Tom Poppendieck

- Promover a integridade: Somos pagos para fazer software com qualidade, documentado e testado, trabalhando dentro do nosso horário (nada de horas extras e fins de semana)

- Respeitar as pessoas;

- Entregar Rápido;

- Ver o todo: Toda a equipe tem que conhecer seu papel. promover a mistura das pessoas, permitir que elas aprendam todas as partes do projeto, desde arquitetura, build, deploy, banco de dados, etc.

Remover Desperdícios:

Tudo o que não trás valor para o cliente;

Até mesmo no local de trabalho podemos remover desperdícios;

Principais desperdícios:

- Código documentado não codificado;

- Código não sincronizado; (deve ser sincronizado diariamente)

- Código sem testes;

- Código sem documentação;

- Código sem deploy;

Código Limpo:

Exibe o gráfico mostrando como a Dívida Técnica cresce exponencialmente devido à código sujo.

Automatizar tudo o que for repetitivo. (Build, Deploy, Testes, tudo)

Quando ocorrer um erro na produção: PARAR TUDO! Concentrar TODOS para detectar a resolver o problema.

JUST IN TIME.

Ir evoluindo conforme a demanda. Ele não perde tempo pensando na complexidade que “talvez” tenha na próxima estória para desenvolver. Se concentra na estória atual, que já esta ordenada de acordo com o que vai trazer mais valor ao cliente, e só quando chegar a vez da próxima estória, vai analisar e pensar na melhor solução.

A arquitetura do sistema deve ser flexível para permitir isso, ou seja, seguir as boas práticas da orientação à objetos.

Pull System:

Lean também é puxado. Tudo o que é “empurrado” para os outros é ruim. A equipe é quem tem que puxar a próxima tarefa para desenvolvimento.

Nivelar o conhecimento:

Todos devem ter domínio do todo.

Obedecer a cadência da equipe, sem Rush (Horas extras e trabalhar finais de semana)

Gabriel Rubens

Postagens Relacionadas:

• Resumo TDC 2010 – Sábado
• Resumo TDC 2010 – Sexta
• Terceiro Encontro Ágil – Eu Vou!
• Terceiro Encontro Ágil – Eu Fui!