No dia 7 de Agosto de 2010, sábado, acontecerá o Café Ágil em Curitiba realizado pela ThoughtWorks nas dependências das Faculdades Opet. Será uma ótima oportunidade para bater papo de alto nível com o Daniel Wildt e Klaus Wuestefeld, consultores da ThoughtWorks, as palestras abordarão um assunto muito importante mas pouco utilizado na prática, Testes de software e Agilidade.

Lógico, que eu já garanti minha inscrição e estarei lá!

Confira a agenda do evento:

Das 8h30 às 9h, Café e recepção
Das 09h às 10h, Como você está testando seu software? – Daniel Wildt
Das 10h às 11h, Automated Software Testing for Advanced Gurus – Klaus Wuestefeld
Das 11h às 12h, Discussão sobre Agilidade, Testes e Desenvolvimento de software com a platéia.

Como você está testando seu software?

Nesta palestra, venha praticar valores, princípios e técnicas sobre as formas de testar, criando um ambiente que gere transparência e visibilidade sobre o desenvolvimento de Software.
Perguntas que serão discutidas na palestra:

• Que técnicas de teste você utiliza?
• Que ferramentas servem de apoio ao seu processo de teste de software?
• Como você testa as funcionalidades desenvolvidas?
• Como você valida a qualidade do seu código fonte?
• E a auditoria de código como fica?
• Você integra seu software de forma contínua?
• E Test Driven Development, você está utilizando?

Daniel Wildt é consultor da ThoughtWorks Brasil, trabalha com Métodos Ágeis desde 2003, fundou o Grupo de Usuários de Metodologias Ágeis do Rio Grande do Sul em 2004. Um dos organizadores do Agile Brazil 2010. O que é Agilidade? Atitude, foco em entrega de software, trabalho em equipe e mehoria contínua. Mais informações em http://danielwildt.com/

Automated Software Testing for Advanced Gurus

Mocks, Stubs, Signals, Domain Specific Languages (DSLs) para teste, Adapters, injeção de dependências, teste de código concorrente… Está na hora desses conceitos não serem mais mistério para você. Venha ver essas coisas em ação numa apresentação 100% executada em código Java.

Klaus Wuestefeld já trabalhou em par com Kent Beck, Vinicius Teles e Scott Ambler. Participou da primeira conferência internacional de XP, em 2000, na Itália. Realizou os eventos “Extreme Programming Brasil 2002 e 2004″ com a presença de Beck, Ambler, Teles, Tom e Mary Poppendieck, entre outros. É o culpado pelo Prevayler e pelo manifesto da computação soberana. Lidera projetos de desenvolvimento e treinamento em XP para empresas como TV Globo, Siemens, TIM e Banco Central do Brasil.

Faça já sua inscrição aqui: http://www.thoughtworks.com/cafe-agil-em-curitiba

Data: 06/05/2010 (Quinta-feira)
Horário: 08h00min às 17h30min
Local: Estação Embratel Convention Center (Rua Sete de Setembro, 2775)

Inscrições: R$ 50,00 Clique aqui e faça a sua inscrição.

Nos encontramos lá!

Se você é desenvolvedor a algum tempo com certeza já se deparou com a questão da promoção de sênior a gerente. Por algumas razões que iremos analisar as pessoas não só aceitam este fato como esperam por ele.

Não é incomum durante uma entrevista perguntar para o candidato a uma vaga de desenvolvedor onde ele se vê daqui a 5 – 10 anos, e a resposta costuma ser “como gerente”. A razão para isso é simples: dinheiro. Historicamente a pessoa na posição de Gerente ganha mais que a pessoa na posição de desenvolvedor, seja qual for a sua classificação ou maturidade. Mas esse, espante-se, não é o único fator. A chamada da sereia do poder é prazerosa.

As empresas acham que promover a pessoa de desenvolvedor sênior para gerente é uma coisa boa. Não é. E as pessoas na sua extrema visão curta só enxergam essa opção.  Não é segredo que todos queremos ganhar mais, então quando a pessoa diz que quer ser gerente o que ele está dizendo, na verdade, é que quer mais dinheiro. Nesse ponto eu desclassifico o candidato já que ele ainda não deixou de ser júnior e já quer ficar mandando nos outros.

Por razões que o tempo conhece as empresas se habituaram a pensar que criar software é difícil e que a probabilidade do projeto de software dar errado é grande. Portanto, os diretores que não querem ver o seu na reta adotam a política de: 1) por um lado criar bodes expiatórios na pessoa do gerente. Se o projeto der errado eles serão culpabilizados e o diretor manterá o seu emprego; 2) é preciso microcontrolar tudo o que os desenvolvedores fazem para que assim não existam imprevistos e não existam atrasos.

O curioso é que são exatamente essas medidas de “contingência” que fazem o projeto atrasar.

O resultado é que em uma hierarquia de um diretor de produção de software é comum existirem vários “gerentes”, os quais tentam microcontrolar a equipe de desenvolvimento. A pessoa no papel de gerente  rapidamente  sacrifica os membros  da equipe para manter um salário um pouco melhor que eles sendo que ele seria incapaz de realizar o mesmo trabalho. A imagem do feitor de escravos me vem à mente.  O pior de tudo nem sequer é isso. O pior de tudo é que, normalmente, a pessoa na posição de gerente não tem capacidade técnica nem política para desempenhar esse papel. Sim, a pessoa foi desenvolvedor sênior 20 anos atrás. Isso não lhe dá conhecimento nenhum sobre como o software é feito hoje.  Não apenas a linguagem e o paradigma utilizado hoje são diferentes, como também as técnicas e ferramentas em volta (uso de repositório de código, por exemplo). Quanto mais cedo a pessoa passou de sênior a gerente mais óbvio é este fato, no limite absurdo de comparar, por exemplo, a plataforma Java com linguagens como Clipper, Delphi ou VisualBasic. Você já reparou como o seu gerente reduz tudo a operações no banco de dados e desconhece o conceito de “Servidor de Aplicação” ou o confunde com “servidor web” ?

Quanto à parte política, a pessoa na posição de gerente não tem qualquer escrúpulo ou vergonha em pedir ao desenvolvedor para trabalhar extra para manter o (famoso) cronograma. Mas  peraí! Não é o gerente que criou o cronograma? Se houver atraso não é responsabilidade dele? Infelizmente no mundo atual não. Nada nunca é responsabilidade do gerente e ele faz de tudo para que assim não seja. O clássico é pedir que os desenvolvedores estimem o cronograma. Ele pede que “estimem” mas o que ele quer dizer é “assinem com sangue um chute de quanto tempo vai ser necessário”. Depois o gerente faz a seguinte conta: se a “estimativa” é X então como temos N desenvolvedores vai demorar X/N tempo. A estimativa … quer dizer, a corda no pescoço da equipe de escra… desenvolvedores ficou ainda mais apertada. Nestas condições totalmente indecentes a equipa tem zero motivação , zero ajuda, zero autoridade, total responsabilidade e lá para quando faltarem dois meses para o final do prazo do cronograma fajuto a equipa ainda passa a ser chicoteada diariamente com a pergunta “Quantos porcento falta para estar pronto?”. O que revela que a pessoa no lugar de gerente não sabe o estado das coisas, ou seja, ela esteve fazendo o quê enquanto os desenvolvedores criavam o software? Esperar-se-ia que estivesse exatamente calculando quanto tempo falta. Certo ?

O diretor (a pessoa hierarquicamente acima do gerente e que o contratou como bode expiatório profissional) não se preocupa com a performance do gerente. Apenas com a da equipe. Afinal todos os males advém da equipe de desenvolvedores. Esses seres abjetos que o diretor é obrigado a tolerar para poder vender alguma coisa a alguém. Ao diretor tanto lhe faz se o gerente explora os desenvolvedores da mesma forma que o senhor lhe importa um pepino que o feitor chicoteie os seus escravos. Não só isso, como o diretor espera que o gerente aja assim.  Tanto isso é verdade que em empresas maiores (leia-se “com mais níveis de isolamento dos seres abjetos da equipe”) existem uma camada de gerentes. O diretor delega para N gerentes, cada um deles delega para M outros gerentes, que delegam a outros … em um cadeia até que se chega no gerente que controla a equipe. Vejam bem o estado da coisa. O gerente não serve para gerenciar o projeto. Não. Isso é fácil, qualquer excel ou project pode fazer isso. O gerente serve para controlar a equipe em uma mistura de babysiter com capataz e a empresa é tanto maior quanto mais gerentes forem controlados por outros gerentes.

Parece então óbvio porque um desenvolvedor quer virar gerente: 1) mais dinheiro no fim do mês; 2) menor ou nenhuma responsabilidade sobre o projeto ou o software; 3) direitos de fustigar a equipe como e quanto quiser; 4) receber todos os louros dos superiores quando o projeto dá certo; e 5) nunca ser “castigado” por nada.

Parece muito melhor que a vida de um desenvolvedor que 1) ganha pouco para aquilo que faz e a responsabilidade que tem; 2) tem toda a responsabilidade sobre o resultado mas nenhum autoridade para guiar o processo; 3) é interrompido a todo o momento com perguntas idiotas que não são da sua responsabilidade responder como “Quantos porcento do projeto já está completo?” 4) nunca recebe o agradecimento real de ninguém nem o reconhecimento real do esforço (eu disse real e não aquele tapinha nas costas ou aquele e-mail de agradecimento modelo B) e 5) é sempre “castigado” por tudo no limite de ser despedido por justa causa por erros cometidos pelo gerente, pelo diretor ou até pelo erro estratégico da empresa como um todo.

Se você teve estômago para ler até aqui, parabéns. Vejamos agora um pouco do outro lado. Afinal, nem todo o mundo é mentecapto e alguma pessoas querem realmente ganhar dinheiro a sério e não apenas para pagar as contas. Qualquer economista, por muito ruim que seja, sabe que uma forma de ganhar mais é gastar menos. É fácil gastar menos com desenvolvimento de software.

Primeiro, foque no que dá dinheiro. No caso do software o que dá dinheiro é o software, funcional e entregue. Muito importante o entregue.

Segundo, desenvolvedores são pessoas com educação superior e qualificadas a resolver problemas lógicos e matemáticos complexos. Não os trate como animais de curral. Converse com eles e ouça o que eles dizem. Melhor que ninguém eles sabem quais são os problemas com o software. E ninguém melhor que ele sabe como traduzir o que é esperado pelo mercado em código. Eles podem ajudá-lo não apenas a resolver problemas técnicos mas até problemas que impactaram na venda do software ou na aceitação pelo público. O seu foco é fazer software, então dê recursos aos desenvolvedores para o fazerem. O foco da empresa é o software e todos devem ajudar a conseguir que ele seja feito nas melhores condições de mercado possíveis.  Simplifique os processos. Coloque no lixo a hierarquia militar de passar ordens entre níveis.  Muita informação se perde dessa forma quando o assunto é complexo como um software. Pode até funcionar para a guerra onde as ordens são simples, mas não numa empresa de software.  Uma muito boa forma de conseguir isto com facilidade, sem gastar dinheiro e com um retorno imediato é substituir todos os que se dizem gerentes por desenvolvedores sênior (realmente sênior e não apenas júniors disfarçados). Implementar Scrum também não é má ideia, mas se você tem um outro processo que realmente funciona para a sua empresa (eu disse, realmente - o que significa que todo o mundo na empresa acha que funciona) então mantenha esse.

Implemente um mecanismo de carreira. Não separe os desenvolvedores por anos de trabalho  e sim preveja que todos têm mais do que uma habilidade. Não é demérito para ninguém só saber programar bem. Saber escrever código limpo, bem estruturado, que aproveita ao máximo as funcionalidades da linguagem não é pecado. Nem todos têm  de ser arquitetos. Não é demérito para ninguém ser um bom tester que sabe escrever testes automáticos com boa cobertura.

A vida de um desenvolvedor têm várias partes e não são: júnior , sênior, gerente. São: programador, engenheiro,  tester, designer, analista e arquiteto. E isto não é uma sequência. Cada um pode ser mais do que uma coisa. Aliás tem que ser mais do que uma. Existe o básico que é ser programador (saber programar não é suficiente) e existe o complexo: analise é uma tarefa ao mesmo tempo técnica, interpessoal e até política onde poucos engenheiros e arquitetos se sentem bem. Moral da história, monte uma equipe multidisciplinar sem gerentes fustigadores mas com pessoas que ajudem a resolver os problemas políticos, burocráticos e administrativos e deixe o desenvolvimento com quem entende.

A próxima década não terá pena de quem não se ajustar à nova ordem. Quem ainda quiser ficar fuçando no código como se fazia à 20 ou 30 anos atrás não vai chegar a lado nenhum diferente da falência. A concorrência é maior que nunca e o mercado de tecnologia é maior do que nunca. Quem não primar pela qualidade não vai vingar.

A escravatura das fábricas de software tem que acabar. O primeiro passo é que você, desenvolvedor,  não aceite esses termos.  Aspire a ter capacidades de análise, conhecimento de arquitetura, design ou teste, e não a ser um gerente mentecapto e escravocrata.  Afinal, você gostaria que pensassem de si o que você pensa do seu gerente?

Vivemos uma época transformadora no desenvolvimento de software. A partir da segunda década do século XXI só vai sobreviver quem fizer software barato (leia-se: sem “gordura”),  recheado de valor, feito com responsabilidade e entregue no prazo. É a hora de separar o trigo do joio.

Os sufixos júnior e sênior me aborrecem enormemente desde sempre. Especialmente quando utilizados fora de contexto ou como sinônimos de “tempo de serviço”. Mas o que realmente faz de você um júnior ou um sênior?

A resposta a esta pergunta pode não ser o que você esperava ouvir. Mas se quiser trabalhar com software nos próximos decênios é bom que a aceite.

A diferença entre júnior e sênior não está na idade, nem no tempo de serviço. Está na maturidade técnica e na maturidade profissional.

Para um júnior, trabalhar muito é sinônimo de “bom”. Trabalhar até altas horas e acumular um monte de horas extra é um sinal de dignidade. Para um sênior só de isso ser sugerido, é um insulto. O sênior sabe que se algo der errado não é com horas a mais ou fins de semana longe da família que o problema se resolve. Bem pelo contrário. Se agrava. Então a posição do sênior é não ter problemas. Para isso ele usa todos os seus skills técnicos para que problemas não aconteçam ou sejam facilmente mitigados. Um bom design, uma bateria de testes automatizados e muito refactoring são ferramentas básicas do sênior para não deixar “a vaca ir pro brejo”.

Para um júnior, boas práticas são subjetivas e discutíveis e gambiarra é um martelinho de ouro que resolve todos os problemas com uma pancada só. Para o sênior, as boas práticas são como leis da natureza, objetivas e irrevogáveis, e a gambiarra um pecado demoníaco intolerável que tem ser exorcizado a qualquer custo de todo aquele de quem se apodera. O sênior sabe que seguir bons princípios e boas práticas fazem as coisas fluírem mais facilmente e responder mais eficazmente a imprevistos enquanto o júnior ignora que as suas gambiarras são aquilo que está fazendo seus fins de semana serem perdidos na empresa ao invés de poder estar em casa ou em passeio com os amigos ou a namorada.

O júnior acha que o objetivo de construir um software é fazer o programa funcionar. O sênior sabe que o objetivo de criar um software é fazer uma aplicação de fácil manutenção. Pois é na manutenção que está o custo e não na criação.

O júnior acha que com 3 anos de serviço pode ser um pleno. Um pleno tapado será se pensa que o tempo traz experiência. O trabalho é que traz experiência. O sênior sabe que desenvolver software é uma arte e um arte não se aprende com o tempo e sim com a prática.

O júnior tende a usar pouco a cabeça, tentando seguir ao máximo “receitas de bolo”, sem se ater ao contexto. O sênior racionaliza o problema e encontra a solução mais flexível até à solução. Normalmente esta solução só é possível com o uso de alguma técnica avançada de desenvolvimento de software como o uso de  objetos  em vez de rotinas. Como para o júnior boas práticas são piadas que se contam aos amigos este tipo de técnica passa

No dia 14 de maio aconteceu em Curitiba o 11º Encontro de Profissionais da Internet promovido pela Locaweb.

Fomos ao evento eu, Igor Musardo, e o Tagôre Cauê, e lá encontramos o SaintBR.

Eu e o SaintBR no CofeeBreak.

O evento foi bem interessante com palestras bacanas, embora ache que para os próximos anos possam ter sessões de desenvolvimento e de design ocorrendo em paralelos e com conteúdo mais técnico e profundo como será no 14º Encontro de Design e Tecnologia Digital que ocorrerá dia 6 de junho também em Curitiba.

A palestra mais aguardada foi a do Fabio Akita com o tema desenvolvimento ágil. O Fabio abordou de forma simples e clara a essência do desenvolvimento ágil de software, infelizmente o tempo foi curto para a palestra do Akita e por isso perdemos alguns conceitos e conclusões de raciocínios.

Consegui gravar boa parte da palestra, portanto se você não pode comparecer ao evento assista agora. A palestra está separada em quatro partes.

Os slides, o próprio Akita já disponibilizou.

Foi a primeira vez que assisti a uma palestra dele, e posso dizer que é bem interessante e reflexiva sua maneira de palestrar, com as cenas teatrais de insulto gratuíto.

A abortagem feita sobre a metodologia XP é muito assertiva, e leva o público a no mínimo re-pensar o processo de desenvolver software contra as absurdas comparações com fábrica e construção civíl.

O vídeo postado por ele está hospedado no Viddle.

Porém se você enfrentar lentidão, como eu enfrentei, para efetuar do download do Viddle, pode fazer o download daqui mesmo do meu Blog.

Palestra – Extreme Programming – Parte 01 (100mb)
Palestra – Extreme Programming – Parte 02 (96mb)

Boa palestra!

Nesse final de semana ocorrerá o evento The Developer’s Conference 2008 em São Paulo, o mesmo é voltado ao mundo Java, mas ocorrerão várias sessões de Metodologias Ágeis (Scrum, XP e Testes), dentre os palestrantes está o papa de eXtreme Programming do Brasil, Vinícius Manhães Teles da ImproveIT.

Pelo conteúdo apresentado o preço da inscrição está bastante acessível.

Não sei se conseguirei ir lá, mas caso você consiga, vá, pois os palestrantes são de primeira linha.

Fonte: http://blog.marcomendes.com/2007/09/12/o-famoso-gerente-de-ti-e-ai-ta-pronto/#comments

Projetos de TI (Tecnologia de Informação) impõe desafios únicos, muitas vezes não observáveis em projetos de engenharia, tais como requisitos extremamente variáveis, pressões de tempo muitas vezes não realistas e dificuldades de aferir e medir a qualidade do produto entregue. Neste cenário já conturbado, infelizmente presenciamos mais uma força negativa, que vou apelidar aqui de Gerente: E Aí?.

O que é o Gerente: E Aí?.

É fácil reconhecê-lo pelas seguintes características:

• Possui pouco domínio do contexto e das tecnologias usadas.
• Possui extrema dificuldade de expressar, seja pessoalmente ou por falta de apoio de um líder técnico competente, os entregáveis do projeto em uma lista detalhada de atividades técnicas necessárias para realizar aquele entregável.
• Usa mecanismos de pressão com o time. O paradigma do século XIX “Cenoura e chicote” é bastante usado.
• Não consegue criar um isolamento e ambiente saudável de trabalho para o time.
• Não se comunica com a equipe, a não ser por emails e reuniões formais e impessoais. Fica quase todo o dia na frente do seu computador, em uma sala especial com mobiliário de padrão melhor que seu time. Afinal, precisa demonstrar que é o chefe.
• Abusa da manipulação gerencial. Frases como “Precisamos de mais empenho!”, “Vamos trabalhar este final de semana para o bem do projeto.” e “Vocês precisam ter mais compromisso.” são comuns no vocabulário deste tipo de gerente.
• Abusa das perguntas “E aí, tá pronto?”; “Já terminou?”, “Fica pronto para hoje, ok?”.

Infelizmente, o Gerente: E Aí? o não consegue obter o respeito do time. Normalmente ele é alvo de piadas de todo o time. Um dos maiores malefícios deste tipo de gerente é afetar o moral e motivação do time. Steve McConnell (em seu excelente livro Rapid Development) e Tom de Marco (em seu excelente livro Peopleware) mostram a correlação negativa da taxa de sucesso de projetos e gerentes manipuladores.

Capers Jones, outro excelente estudioso de fatores de sucesso e fracasso de projetos de TI, observa também que times sob pressào extrema introduzem até 40% a mais de defeitos que times similares em um ambiente saudável. Um excelente texto sobre ambientes saudáveis em TI pode ser achado na seção “Hygienic factors”, do livro supra-citado do Steve McConnell.

O novo milênio e os novos paradigmas pedem novos tipos de gerentes. Projetos de complexidade como observados em TI pedem um novo tipo de gerência. Vamos chamar este gerente de Como posso te ajudar.

O Gerente Como posso te ajudar? pode ser reconhecido pelas seguintes características:

• Possui bons ou excelentes conhecimentos do domínio em que atua. Este tipo de gerente não precisa ser certificado Java ou .NET, mas deve conseguir manter um diálogo técnico mínimo com a sua equipe. Por exemplo, você já viu um projeto de um prédio de vinte andares que não tenha sido gerenciado por um Engenheiro?
• Consegue expressar claramente os entregáveis de um projeto em uma lista de atividades precisa, com o apoio de processos como o RUP, EUP ou metodologias ágeis. Conhece bem processos de software.
• Isola, a todo custo, o time das pressões comerciais dos clientes e da alta gerência das empresas do time. Este tipo de gerente sabe que o que não ajuda, pode atrapalhar.
• Usa mecanismos de motivação para fazer o time trabalhar bastante. Como Barry Boehm observa do alto de sua experiência de quase 50 anos em TI e mais de 80 de idade, a motivação é o fator que mais contribui isoladamente para diferenciar times de projeto de mesma capacidade técnica em tecnologias similares.
• Está em constante circulação, fisicamente ou virtualmente, com suas equipes exercendo um papel pró-ativo e removendo os empecilhos encontrados pelo time. Este gerente é um “coach”, na melhor definição do termo.
• Conhece profundamente técnicas de negociação “Ganha Ganha ou Nada feito”. Com isso, consegue um profundo respeito do time e portanto um sentimento de compromisso de toda a equipe para bater as metas de projeto.
• Acima de tudo, reconhece que ele não é chefe, mas um mero servidor. Um gerente “servidor” existe para o bem único e exclusivo de apoiar o time a cumprir as metas do projeto.

Um excelente livro que discute este novo paradigma gerencial é o livro “O Oitavo Hábito, do autor Steven Covey”. As claras diferenças entre o gerente clássico e o líder são discutidas à exaustão neste livro. Em resumo, o gerente Como posso te ajudar comunica valores corretos às pessoas e com isso libera o potencial das mesmas.

Um aspecto fundamental nesta diferenciação dos gerentes é a autoridade formal vs autoridade moral. A autoridade formal é imposta através de hierarquias. A autoridade moral é conseguida através de liderança.

Como analistas, arquitetos e desenvolvedores, devemos buscar cada vez mais gerentes líderes para nossos projetos e educar gerentes do século XIX a uma profunda mudança de atitude e comportamento.

Finalmente, como gerentes devemos entender como desenvolver nossas habilidades de liderança. Um fonte de inspiração e conhecimento é o autor Warren Bennis, que possui excelentes livros e tratados sobre liderança de times.

Entregar sistemas de software não é uma arte. É uma complexa ciência que requer, dentre vários outros fatores, muito estudo. Para apoiar neste aspecto, compilo artigos que me muito me ajudaram nos últimos anos, escritos por “mestres” na arte de desenvolver sistema e que são uma eterna fonte de inspiração.

1. Uso de processos de Software – The Seven Habits of Effective Iterative Development
2. Projetos Iterativos – Planning an Iterative Project e Iterative Development
3. Planejamento de Projetos – Project planning best practices
4. Gerência de Riscos – Gambling with Success: Software Risk Management
5. Estimativa de Tamanho de Software – Estimating Software Development Effort based on Use Cases – Experiences from Industry
6. Modelagem de Negócios – Effective Business Modeling with UML: Describing Business Use Cases and Realizations
7. Gerência de Requisitos – So You Want to be a Requirements Analyst? e The Five Levels of Requirements Management Maturity
8. Modelagem de Casos de uso – Why Use Cases Are Not Functions, Features, Requirements, Use Cases, Oh My e The Top Ten Ways Project Teams Misuse Use Cases – and How to Correct Them.
9. Escrita Estruturada de Regras de Negócio – Business Rule Overview e Business Rules.
10. Especificação de Glossário de Termos – Glossary Overview.
11. Mapas de Navegação e Prototipação – User experience storyboards: Building better UIs with RUP, UML, and use cases.
12. Análise Robusta e Modelagem de Domínio – Robustness Diagram Overview e Driving Design: The Problem Domain.
13. Modelagem Arquitetural – Reference Architecture: The Best of Best Practices e Capturing Architectural Requirements.
14. Modelagem de Estruturas de Análise e Desenho – Driving Design: The Problem Domain
15. Modelagem Comportamental – Sequence Diagrams: One Step at a Time
16. Mapeamento Objeto Relacional – The Object-Relational Impedance Mismatch.
17. Gerência de Mudanças – Software Change Management.
18. Gerência da Qualidade – Software Quality at Top Speed e Determining Your Project’s Quality Priorities
19. Desenvolvimento Centrado em Testes Generating Test Cases From Use Cases, Test-Driven Development.
20. Refactoring e Testes de Unidade – Refactoring, a first example.

O conteúdo da palestra é de altíssimo nível e mostra o quão importante é você “Machucar” o código, pois só assim você conseguirá alcançar uma melhor qualidade nos seus sistemas.

O post para maiores detalhes sobre a palestra é: Machucando Código por Diversão e Lucro.

Faça o download da palestra em alta qualidade no link que o Marcos Tapajós disponibilizou.

Aproveite.

Eu tenho pensado um pouco sobre isso nos últimos tempos, então decidi falar aqui no blog porque possivelmente muitas pessoas têm questionamentos semelhantes.

Inicialmente vou contextualizar um pouco para depois ficar mais fácil de expôr algumas idéias. Meu time na Globo.com é formado atualmente por 3 desenvolvedores, 1 especialista em client-side e 2 arquitetos de informação (até semana passada eram 3). Temos um backlog de produto enorme, pois a equipe era formada apenas por 2 desenvolvedores antes da minha chegada em Janeiro. O resto do pessoal se juntou ao time em Março.

Uma coisa importante no Scrum (na verdade, em qualquer metodologia hoje em dia) é que os desenvolvedores sejam versáteis, e consigam atuar de várias formas diferentes, mudando de ferramentas, frameworks e linguagens sem problemas. Para que os desenvolvedores consigam fazer isso, é claro que é fundamental que eles estudem bastante e estejam sempre se atualizando, pois as opções de tecnologias disponíveis estão avançando muito rapidamente.

Outra coisa importante é que mais de um desenvolvedor do time seja capaz de realizar qualquer tarefa específica. Isto é importante pelo compartilhamento do conhecimento e para que seja possível lidar tranqüilamente com problemas pessoais, férias, etc. Neste sentido, precisamos pensar muito mais no conhecimento do time do que no conhecimento de indivíduos separadamente.

O que eu quero dizer com isso? Quero dizer que para um time andar bem, as escolhas de tecnologias idealmente devem ser moldadas em torno do time. Com a infinidade de opções que temos de frameworks web, APIs javascript/ajax, linguagens e componentes, não podemos nos dar ao luxo de ficar continuamente acompanhando as novidades e avaliando novas opções. Precisamos fazer algumas escolhas, e avançar com elas. É claro que isso pode e deve ser periodicamente revisto, mas é fundamental escolher algumas opções e se concentrar nelas.

Os 3 desenvolvedores do meu time têm experiência muito mais em Java do que em outras linguagens. Nossas aplicações são todas em Java, embora já estejamos fazendo experimentos com outras linguagens. Entretanto, concordo bastante com um artigo que saiu no InfoQ recentemente, que traz a idéia de que Java pode ser a última grande linguagem. Compartilho da idéia do autor de que provavelmente estaremos nos próximos anos escolhendo linguagens de uma forma semelhante à que escolhíamos frameworks Java nos últimos anos.

Java é uma linguagem de propósito geral. Gosto muito da linguagem e da plataforma. Mas com novas linguagens/frameworks direcionados para problemas específicos, é natural que em alguns nichos Java não seja a melhor opção. Penso que isso está acontecendo com mais força em aplicações web. Novas opções como o Grails, Django e Ruby on Rails oferecem um desenvolvimento muito mais produtivo do que Java em algumas aplicações. Java possui ótimos frameworks web, e já é uma linguagem muito madura. Mas quem já utilizou alguma dessas 3 opções que mencionei já pôde constatar o choque de produtividade delas contra a maioria dos frameworks web Java.

Conversei sobre isso com o resto do time e a minha opinião é de que devemos nos concentrar em torno de um conjunto limitado de opções, para que o time tenha um melhor rendimento. Com isso, o ideal é que o time conheça bem 2 ou talvez 3 frameworks web Java, 1 ou 2 das opções de alta produtividade web, e 1 ou 2 opções de framework javascript/ajax (jQuery por exemplo). As escolhas devem ser feitas pelo time em conjunto, de acordo com as aptidões e conhecimento agregado dos membros.

Trabalhando com um conjunto reduzido de opções, fica muito mais fácil compartilhar o conhecimento dentro da equipe, e conseguimos que os desenvolvedores conheçam bem esses componentes escolhidos e sejam produtivos com eles. Não adianta muito que um dos desenvolvedores saque muito do “melhor framework web da história desse país”, mas só ele conheça esse framework.

É melhor que seja utilizada uma opção que o time de uma maneira geral já conheça e seja produtivo. Pode ser que essa 2a opção não produza flocos tão crocantes como aquele outro framework, mas se é uma boa ferramenta para o problema e o time conhece bem, use essa mesma!

É claro que em algumas situações nós precisamos abrir mão de algo que conhecemos bem para utilizar uma opção que se adequa melhor aos outros membros do time. Vamor supor que um dos desenvolvedores saca muito de Tapestry e considera que ele é o melhor framework web Java. Se os outros 3 desenvolvedores já conhecem bem de JSF, provavelmente a melhor alternativa é que o time use JSF, e aquele desenvolvedor abra mão do Tapestry em favor do JSF. Pode ser que o Tapestry seja melhor tecnicamente do que JSF, mas os resultados têm que ser entregues pelo time, então as escolhas têm que ser feitas em torno das aptidões do time como um todo.

Tendo feito as escolhas de tecnologias, o legal é que os desenvolvedores se revezem com alguma freqüência entre as linhas de atuação, para propagar melhor o conhecimento e o time como um todo amadurecer. Eu por exemplo conheço legal de REST, mas os outros 2 desenvolvedores do time já implementaram alguns serviços e clientes REST, e com certeza têm plena condição de trabalhar em qualquer um dos serviços REST que eu implementei.

Aos poucos estamos aprendendo mais da parte client com o especialista do time, e ele também já está aprendendo um pouco de JSF, e com isso vamos todos amadurecendo. Essa gestão de conhecimento do time deve ser muito bem feita, para que os resultados do time vão melhorando progressivamente sprint após sprint. A decisão de se concentrar em algumas escolhas (mesmo que talvez elas não sejam as melhores tecnicamente) é muito importante para que o time se mantenha produtivo.

Todos gostamos muito de software, e de avaliar novidades. Porém, não somos pesquisadores, somos desenvolvedores comprometidos com resultados. Essa decisão das escolhas do time é muito importante. Nosso tempo de estudo é limitado, portanto precisamos ser pragmáticos e focar nos resultados.

Dada a importância, o conteúdo está reproduzido logo abaixo.

Fonte: http://gc.blog.br/2008/01/22/voce-tem-que-ler-os-livros/
Fonte: http://gc.blog.br/2008/03/27/10-livros-recomendados-para-desenvolvedores/

Nos últimos meses já ouví algumas pessoas dizerem que não têm costume de ler livros, ou questionarem a necessidade de lê-los, já que há uma abundância de fontes de leitura por aí na Internet.

Hoje em dia realmente temos milhares de formas de nos informarmos. Me lembro de ter lido em algum lugar que a Internet possui mais de 250 milhões de sites. Se somarmos isso tudo, realmente tem muita informação. Justamente por isso, faz parte da minha rotina diária dar uma navegada no Google Reader, onde tenho cadastrados os feeds de mais de 300 sites e blogs de diversos assuntos que acho interessantes. Essa é basicamente a minha principal fonte de informação diária e é a melhor maneira de me manter atualizado com tantas novidades surgindo por aí todo dia.

Porém, em alguns casos, para aprender e entender certos assuntos, você precisa ler os livros. Não tem jeito! Por exemplo, como é que um desenvolvedor de software pode dizer que entende Domain-Driven Design sem ter lido o livro do Eric Evans ou pelo menos o DDD Quickly? Ou então dizer que sabe sobre metodologias ágeis sem ter lido pelo menos um livro do Ken Schwaber, Kent Beck ou Uncle Bob? Como é que alguém pode se dizer Arquiteto de Software Sênior++ Certified ™ sem ter visto o Patterns of Enterprise Application Architecture e o GoF? Eu respondo: não tem como. Simplesmente não tem jeito, você precisa ler os livros.

Hoje mesmo o Patrick Kua, que trabalha na ThoughtWorks, escreveu um post sobre os livros que ele considera essenciais para saber sobre metodologias ágeis. Ele acredita que você precisa ler 11 livros, O.N.Z.E. livros, para entender sobre o assunto, e ainda completa: “Of course, simply reading the books won’t mean that you’re an expert […] though it’ll definitely help in providing context, advice or skills that you need to practice.”. Ou seja, mesmo lendo todos esses livros, ainda há muita coisa para aprender… E estamos falando sobre um assunto apenas.

Assim como os blogs e os sites, os livros são uma fonte de informação importantíssima e necessária. Se você quer trabalhar com tecnologia e desenvolvimento de software não tem jeito: tem que ler e ler muito!

[...]

Então, resolví criar a lista dos 10 livros que eu particularmente mais gosto e que recomendo fortemente para qualquer desenvolvedor. Estes livros são alguns dos que mais me influenciaram a melhorar minha forma de trabalhar e programar. Além disso, coloquei link para os sites, blogs ou páginas de informações dos autores, caso alguém ainda não tenha:

Infelizmente todos os livros são em inglês e nem sei se existe tradução. Se você não souber inglês, matricule-se urgentemente em algum curso porque saber inglês nesta área é muito importante!

O Rodrigo Yoshima descreve alguns pontos fundamentais onde o Microsoft® Project e o modelo do PMBOK® não atendem as necessidades dos projetos de desenvolvimento de Software.

Boa leitura.

Por que Gantt Charts não servem para projetos de Software?