13 Razões para Programadores Java aprenderem Flex e BlazeDS
Treze razões para que programadores java aprendam Flex e BlazDS. Ele discute sobre o porquê que Flex e BlazeDS é uma das melhores opções para desenvolver aplicações ricas de internet.
Rastreando mudança e inovação na comunidade de desenvolvimento de software corporativo.
Postado por Henrik Kniberg , traduzido por Vários Voluntários em 05 Dez 2008 05:30 PM

Uma das coisas que mais dificultam para quem está començando no agile é o fato de não haver nenhum manual dizendo exatamento o que você deve fazer. Você tem que experimentar e continuamente adaptar o processo até que ele se encaixe na sua situação específica.
Este livrooferece a voc6e um ponto de início, através de um conto detalhado sobre como uma empresa sueca implementou Scrum e XP com um time de aproximadamente 40 pessoas e como ele continuamente melhoraram seu processo ao longo de 1 ano.
Sob a liderança de Henrik Kniberg eles experimentaram diferentes tamanhos de time, diferentes tamanhos de sprint, diferentes definições para "feito", diferentes formatos para o product backlog, diferentes estratégias de testes, diferentes modos de realizar demonstrações, diferentes modos de sincronizar múltiplos times de Scrum, etc. Eles também experimentaram práticas XP - diferentes modos de fazer builds contínuos, programação em par, test driven development, etc e também omo combinar tudo isso com Scrum.
As restrições de seu time podem ditar formas diferentes de configuração das práticas (e até mesmo comprometimento), mas aqui está um exemplo de como alcançar o processo de "melhoria contínua" que fará seu processo ágil o melhor para você.
Este livro inclui:
148 Páginas, ISBN: 978-1-4303-2264-1
Cortesia de Henrik Kniberg e InfoQ.com/br, nós estamos felizes em oferecer uma versão gratuita para download, para distribuir esse conhecimento em quantas pessoas for possível Faça o download deste livro GRÁTIS (PDF) (Necessário Login)
Aqui você encontra as versões traduzidas do livro:
Prefácio por Jeff Sutherland
Prefácio por Mike Cohn
1. Introdução
2. Como fazemos product backlogs
3. Como nos preparamos para o planejamento do Sprint
4. Como planejamento Sprint
5. Como comunicamos Sprints
6. Como fazemos Sprint backlogs
6. Como arrumamos a sala da equipe
6. Como fazemos as reuniões diárias
7. Como fazemos apresentações de Sprint
7. Como fazemos retrospectivas de Sprints
8. Intervalo entre sprints
9. Como fazemos o planejamento de release e contratos com preço fixo
13. Como combinamos Scrum e XP
11. Como fazemos testes
12. Como lidamos com várias equipes
16. Como lidamos com equipes distribuídas geograficamente
17. Checklist do Scrum Master
18. Últimas Palavras
Leituras Recomendadas
Sobre o Autor
Sobre a Tradução
Henrik Kniberg é consultor na Crisp em Estocolmo (http://www.crisp.se), especializando em Java e desenvolvimento ágil de software. Ele fundou várias empresas suecas de software e é apaixonado por aprender, ensinar e aplicar a arte do desenvolvimento de software. Henrik tem uma abordagem holística e gosta de exercer diferentes papéis como gerente, desenvolvedor, Scrum Master, professor e coach. Para mais informações veja http://www.crisp.se/henrik.kniberg.
Treze razões para que programadores java aprendam Flex e BlazDS. Ele discute sobre o porquê que Flex e BlazeDS é uma das melhores opções para desenvolver aplicações ricas de internet.
Rob Bazinet e Matthew Bass, ambos da InfoQ, tiveram a oportunidade de conversar com Jeremy McAnally, sobre o livro "Ruby in Practice" no qual foi co autor junto à Assaf Arkin.
Danijel Arsenovski tenta esclarecer alguns mitos sobre refatoração e como isso se aplica para desenvolvedores .NET
Em maio, Adobe lançou a primeira versão beta do Flex 4, codinome Gumbo. A lista a seguir proporciona uma visão geral de alto nível dos itens que foram modificados na última versão do framework RIA.
Um dos anúncios mais interessantes recentemente feito à comunidade Ruby foi o lançamento da IDE JetBrains RubyMine para aplicações Ruby e Ruby on Rails.
Data Services são serviços de software que encapsulam operações das entidades chave relevantes para a empresa.
O uso do XML traz consigo desvantagens, como problemas em potencial com desempenho, mas também oferecem um nível de abstração que permite diminuir o acoplamento entre as partes envolvidas na troca.
Como programadores, a nossa primeira prioridade é criar código que funciona. Infelizmente, código que simplesmente “funciona” não é suficiente.