Há pouco mais de um ano, o Google anunciava a criação da App Engine com suporte à plataforma Java. A App Engine permite que empresas e desenvolvedores criem aplicações que rodam dentro da infraestrutura do Google. Até então, a empresa americana disponibilizava a App Engine apenas para programação em Python. No início do mês, veio o anúncio do suporte ao Java.

Durante uma conferência realizada hoje na sede da companhia no Brasil, localizada em São Paulo, Andrew Bowers, gerente de produtos do Google, fez uma rápida apresentação da ferramenta. Rápida mesmo. Por meio de um plugin que vem integrado ao Eclipse, ambiente de desenvolvimento, Bowers levou cerca de 10 minutos para construir uma aplicação de guest book, ainda que com algumas partes pré-feitas, e publicá-la na web.

O objetivo do Google ao expandir a App Engine para a plataforma Java foi contemplar um número maior de desenvolvedores, já que a linguagem é bem mais popular que o Phyton. De acordo com Bowers, já são mais de 150 mil desenvolvedores que criaram aplicações em Java, que utilizam a infraestrutura do Google.

“Nosso objetivo foi manter os padrões já estabelecidos pelo Java. Não tínhamos a intenção de criar o nosso próprio Java”, afirma o executivo. Segundo ele, como o universo de aplicativos é muito grande, houve algumas funcionalidades que não foram contempladas no primeiro anúncio. Por isso, no início do mês, a empresa americana anunciou quatro novos recursos para os desenvolvedores.

As 4 novidades
O primeiro deles foi o suporte a cron. O programa usado por programadores Unix permite criar uma agenda para execução de comandos e scripts de forma automática. Com isso, é possível criar rotinas para tarefas regulares, sem necessidade de um monitoramento intensivo.

A importação e a exportação de dados é outro dos novos recursos. Antes limitada, a funcionalidade permite agora aos desenvolvedores transferir dados em lotes de gigabytes por meio de uma ferramenta nativa.

A inclusão de tempo de execução Java (runtime) integra o Google Web Toolkit, além do já citado plugin para o Eclipse. Juntas, as ferramentas tornam a gravação de aplicativos em Ajax, do cliente para o servidor, mais ágil.

Por fim, a possibilidade de acessar dados locais que estão protegidos por firewall direto da nuvem. O recurso, chamado de Secure Data Conector, garante que as informações presentes em banco de dados fiquem devidamente protegidas.

Leia também: Nova linguagem com suporte no Google App Engine

Fonte: Info Professional

Postado por Vikas Hazrati, traduzido por Vinicius Assef em 29 Abr 2009 09:05 AM

As reuniões diárias ajudam a equipe a conhecer o progresso do trabalho comparando-o com o objetivo da iteração. Pressupõe-se que elas sejam um terreno fértil para os membros da equipe comprometerem-se entre si sobre o quê pretendem concluir no dia, e identificar os obstáculos a esse progresso. Entretanto, apesar de as reuniões diárias trazerem muitos benefícios às equipes ágeis, muitos agilistas acreditam que essas reuniões convencionais ficam ruins à medida que a equipe cresce.

Dave Nicolette mencionou o seguinte:

A abordagem de scrum-of-scrums funcionou bem quando não havia tantas equipes, e não era necessário mais do que um nível de hierarquia. Começamos a ter problemas de logística e falhas de comunicação quando o projeto envolvia de 25 a 30 pessoas, divididas em equipes ágeis de tamanho apropriado. Os defensores do scrum-of-scrums dizem que ele escala linearmente, mas, na minha experiência, isso não aconteceu. Ao invés disso, o esforço para gerenciar as reuniões pareceu crescer muito com o aumento da quantidade de reuniões de scrum-of-scrums. As equipes que precisavam de informação sobre outras equipes pareciam ser empurradas mais e mais por essa estrutura, e além disso, começamos a vivenciar alguns dos problemas de comunicação iguais aos da época pré-ágil, quando a maior parte da comunicação era indireta.

Jason Yip citou um problema similar com equipes maiores. De acordo com ele, 

Com equipes grandes, as reuniões diárias são mais propícias a terem os problemas de pouca energia e baixo comprometimento. É mais fácil para a reunião travar e as pessoas ficarem apáticas, no meio de muita gente.

David J. Anderson mencionou que apesar de não haver nada que impeça uma equipe grande de fazer uma reunião diária, isso não provoca o mesmo sentimento de equipe. E o aspecto da pressão entre os participantes da reunião diária do scrum é completamente perdido.

Dave também disse que em um grupo maior, as atividades não são discutidas de forma coerente. Ao invés disso, elas  dependem da ordem que os membros da equipe falam. Como resultado, é fácil perder o foco sobre a atividade.

Corey Ladas também acrescentou suas preocupações sobre a estratégia de comunicação no scrum-of-scrums para equipes grandes. Ele disse que o scrum-of-scrums poderia criar uma hierarquia profunda à medida que ele for aumentando, o que não é escalável nem muito enxuto.

Então, qual é a melhor maneira de fazer as reuniões diárias para equipes grandes?

Dave sugeriu o formato de ‘Passeio pelo quadro de tarefas’ para as reuniões diárias. De acordo com ele, foi criado um quadro de tarefas para a equipe. Ao invés de a equipe responder as 3 perguntas padrão, os membros moviam estórias sobre o quadro de acordo com seu entendimento individual da situação e dos problemas. Isso deu uma visão concreta do trabalho que estava sendo realizado ou do atraso em alguma estória e refletiu no progresso do projeto. Um artigo similar no InfoQ mencionou as reuniões diárias focadas em estórias como uma alternativa viável às reuniões convencionais, focadas em pessoas.

Jason Yip citou um Formato de diálogo público para conduzir as reuniões diárias para equipes maiores. De acordo com ele,

Nesse formato [de diálogo público], você tem representantes de cada equipe menor em um círculo no meio, com o restante de todo o grupo ao redor deles, só observando. Quanto menor número de participantes que realmente fala, mais rápida a reunião é. E porque os representantes estão sendo vistos pelo restante de suas equipes, é pouco provável que haja ruído ou filtragem na comunicação.

Na prática, esse formato ainda não evita que uma equipe em particular dentro do grupo maior esteja desengajada do processo e não compartilhe nada. Mas eu ainda acho que seja mais energizante do que uma reunião diária geral.

Brian Marick sugeriu a abordagem da Teoria de Rede de Atores, que novamente é focada nas estórias. Nesse formato, ao invés de ficar ao redor das pessoas, as equipes vão às estórias que estão sendo tratadas no momento. Para cada estória um membro da equipe pode dizer o que aconteceu com aquela estória ontem, o que será feito hoje, e se há algum risco para sua finalização.

Desse modo, alguns agilistas acreditam que os processos como o scrum-of-scrums podem escalar apenas até um certo limite. Equipes maiores precisam de um formato alternativo eficaz para que suas reuniões diárias sejam realizadas e terminadas rapidamente. As reuniões diárias baseadas em estórias parecem ser uma boa alternativa para isso. Qual tem sido sua estratégia para uma equipe grande?

Fonte: InfoQ

Por André Dourado

Uma interessante dica para criar, gratuitamente e de qualquer música de sua biblioteca do iTunes, um ringtone que poderá usar no iPhone… utilizando somente o iTunes, sem nenhum outro complemento ou programa instalado (funciona, portanto, em Mac e Windows).

Só um probleminha: o tempo máximo que um ringtone pode ter é 30s.

1.Na lista de músicas de sua biblioteca do iTunes, escolha a música que você quer gerar o ringtone, clique com o botão direito do mouse sobre a música escolhida e escolha a opção “Obter Informações”. Na tela de informações clique sobre a aba “Opções”.  Informe nos campos Início e Fim os tempos referentes ao trecho desejado. Para isso logicamente, antes você deve escutar a música, anotando em que momento da música o trecho iniciará e terminará.

2.De volta a lista de músicas da bibioteca do iTunes,  clique novamente com o botão direiro do mouse sobre a música escolhida e escolha a opção “Criar Versão Para AAC”. Será criada uma cópia da música escolhida com o tempo de duração definido no passo anterior. Feito isso, retorne a tela do passo anterior e desmarque os campos Início e Fim.

3.Clique sobre a versão criada para o ringtone e arraste para a área de trabalho do seu micro.

4.Renomeie o arquivo, trocando a extensão do arquivo de “m4a” para “m4r”.

5.Arraste o arquivo da área de trabalho novamente para o iTunes, sobre a opção “Biblioteca” até que apareça um sinal de “+”, ou simplesmente selecione a opção do menu “Adicionar Arquivo à Biblioteca” e escolha a música renomeada no desktop.

6.Arraste o arquivo da área de trabalho novamente para o iTunes, sobre a opção “Biblioteca” até que apareça um sinal de “+”, ou simplesmente selecione a opção do menu “Adicionar Arquivo à Biblioteca” e escolha a música renomeada no desktop. Agora o ringtone estará disponível na lista de ringtones da biblioteca.

7.Selecione a aba “Toques” do iTunes. O ringtone que você acabou de criar está disponível agora para ser sincronizado ao seu iPhone. Caso o arquivo não apareça na lista de arquivos a serem sincronizados, provavelmente você criou um ringtone com mais de 30s de duração. Aconteceu comigo na minha primeira tentativa.

Após o sincronismo do iPhone, o novo ringtone estará disponível para ser utilizado. Espero que goste e aproveite.

Recentemente li dois posts sobre a questão da cultura ágil e como alguns times usam apenas os processos embutidos nas metodologias ágeis sem absorver a cultura da agilidade:

• Agile development is more culture than process
• Creating The Culture For An Agile Environment

Pesquisando na Wikipedia, encontrei as definições abaixo:

Cultura é um padrão integrado de conhecimento, crença ou comportamento humano que depende da capacidade de pensamento simbólico e de aprendizado social de um determinado grupo de pessoas. É também um conjunto de atitudes, valores, objetivos e práticas compartilhadas que caracterizam esse grupo de pessoas.

Processo é um cojunto de tarefas e atividades relacionadas que produzem um determinado produto ou serviço para um ou mais clientes de uma empresa. Pode ser visualizado com um fluxograma.

Ou seja, o processo é o “como” enquanto a cultura é o “porquê”.

Sem dúvida o que mais importa é a cultura, já que sem o “porquê” é muito mais difícil seguir e manter o respectivo “como”.

As metodologias ágeis, ou seja, os processos de desenvolvimento de software que as metodologias ágeis definem, são consequência da cultura ágil.

A cultura ágil consegue existir sem as metodologias ágeis. Se falarmos apenas no manifesto ágil e em seus princípios para alguém que nunca ouviu falar nas metodologias ágeis, é muito provável que essa pessoa acabe criando os processos necessários para viabilizar a cultura ágil.

Por outro lado, dado o processo ágil, por exemplo o Scrum, é difícil entender o “porquê” esse processo deve ser seguido. Dá até para perceber que esse processo melhora o dia-a-dia do desenvolvimento de software, mas sem saber o “porquê” de o seguir, as chances de que o processo se mantenha ou, mais importante, de que o processo melhore, são bem baixas.

Daí a importância de entender a cultura ágil antes de implementar as metodologias ágeis.

Só que mudar cultura é tarefa de longo prazo, gradual e de difícil mensuração. E como toda tarefa de longo prazo, gradual e de difícil mensuração, é pouco atraente. As pessoas querem os resultados da mudança de cultura, mas não querem gastar o que é necessário para se chegar ao resultado. Daí a busca por receitas de bolo.

Implementar metodologias e mudar processos são tarefas de curto prazo, de impacto e de fácil mensuração (gráficos, pontos, etc.). Daí a preferência natural que temos pelas metodologias, pelas “receitas de bolo”.

É fundamental orientar a implementação das metodologias e as mudanças de processo para garantir que elas não se transformem em atos mecânicos e para que sejam gradualmente absorvidos como cultura da organização.

E orientar a implementação das metodologias e as mudanças de processo não é conhecer muito sobre o tema e fornecer respostas para perguntas do tipo “o que eu faço com os pontos dessa história que não acabamos nesse sprint?” ou “devo pontuar as histórias com pontos ou com horas?” ou “será que devo usar kanbam, lean, XP, Scrum, …?” ou …

A orientação que deve ser dada está em ensinar a “pensar ágil”. As metodologias ágeis são um auxílio para nos ajudar a pensar ágil mas muitas vezes, ao invés de nos ajudar a pensar ágil, nos faz não pensar. :-/

Só se muda uma cultura pensando, discutindo, argumentando, ouvindo, experimentando.

Seguir “receitas de bolo” sem pensar, discutir, argumentar, ouvir e escutar é receita certa para uma implementação mecanizada das metodologias e consquente fracasso.

Como dito no Outliers e em um artigo bem bacana de Scientific American, para ser um especialista em algo, devemos praticar de forma consciente, ou seja, sempre questionando e entendendo o que estamos praticando e nunca executar a “prática cega”.

Por isso, em sua próxima reunião de revisão e planejamento de sprint, ou mesmo na sua reunião diária, lembre-se que antes da metodologia ágil deve vir a cultura ágil. Releia junto com o seu time o manifesto ágil e seus princípios e discutam:

• por que esses princípios são importantes para nosso time?
• o que tem sido feito para seguir esses princípios?
• onde não seguimos esses princípios e por que?

Agilidade é cultura, as metodologias ágeis são os processos que ajudam a sedimentar essa cultura.

Fonte: Metodologias Ágeis de Desenvolvimento (Locaweb)

Postado por Chris Sims, traduzido por Vinicius Assef em 24 Abr 2009 12:26 PM

Uma discussão recente na lista de Extreme Programming do Yahoo Groups explorou o conflito aparente entre desenvolver software reutilizável e a prática do XP de não escrever o código até que ele seja necessário. Ron Jeffries e outras pessoas compartilharam suas idéias sobre os custos e benefí­cios da reutilizacão de código, além de como e quando colocá-la em prática em um ambiente Ágil.

Brandon Olivares iniciou a discussão. Ele havia acabado de dedicar 30 horas em um código quando percebeu que tinha a chance de ser reutilizado. Ele sentiu-se confuso sobre o fato de poder ou não generalizar esse código, de forma que outros projetos também pudessem usá-lo.

Até onde eu entendo, o XP desencoraja você a assumir que alguma coisa seria necessária, até que você realmente perceba que ela é necessária. Também conforme o meu entendimento, isso inclui a abstração de código a fim de torná-lo mais genérico para reutilização, até que haja uma duplicação; então ele pode ser refatorado.

A reutilização de software tem sido bastante apontada como um fator de grande economia de tempo. Assim, desenvolvedores de outro projeto podem beneficiar-se reutilizando seu código, ao invés de reinventá-lo. Brandon perguntou aos membros do grupo como eles decidem quando abstrair e generalizar o código, de forma que outros projetos possam reutilizá-lo.

Ron Jeffries foi o primeiro a responder, explicando algumas das razões pelas quais a reutilização entre as equipes podem ser mais difí­ceis e caras do que parecem a princí­pio.

Eu preciso ter o trabalho de empacotá-lo, o que não precisaria se fosse usado só por mim; preciso documentá-lo; preciso torná-lo mais sólido, retirando problemas que eu poderia contornar facilmente; preciso dar suporte e responder dúvidas a respeito dele; preciso treinar pessoas para usá-lo.

Se eu faço tudo isso, ele fica caro. Se eu não faço, a utilização do meu código por outras pessoas fica difí­cil e aí­ não as ajuda muito.

Tudo isso leva Ron a abordar o assunto dessa maneira:

Eu construo as abstrações que preciso. Se preciso delas novamente, em um contexto diferente, melhoro a abstração. Mas, a menos que o objetivo do meu projeto seja construir infra-estrutura para outros projetos, eu tento não gastar nem tempo nem dinheiro meu, desenvolvendo para os outros.

Outra pessoa observou que a reutilização pode ser facilitada por todos os projetos que compartilham o mesmo sistema de build e um conjunto unificado de testes. Dessa forma, uma equipe que quer reutilizar algum código, pode generalizá-lo para suas necessidades. O sistema de build ajudaria a garantir que nenhum teste dos outros projetos que usam o mesmo código, foi quebrado.

George Dinwiddie, Ralph E. Johnson, e outros recomendaram generalizar na segunda utilização (ou até mais tarde). Adam Sroka chamou essa abordagem de ‘reutilização emergencial’ e observou que ela parece ser mais eficiente do que o ‘projeto para reuso’. Um participante chamado Tim explicou isso para as pessoas de sua empresa da seguinte forma: "Na primeira vez, você paga para o código ser escrito. Na segunda, você paga para ele ser reusado. Na terceira, ele sai de graça."

George alertou que o problema mais difí­cil poderia ser como fazer que outras equipes fiquem sabendo de um código potencialmente reutilizável. O custo de comunicação necessário para uma descoberta útil pode ser significante. Jeff Langr sugeriu que se os desenvolvedores tivessem pares em outros projetos, poderia ser uma forma eficaz de resolver o problema dessa descoberta.

Scott Ambler entrou na discussão dizendo que o open source é uma forma de reutilização que tem tido muito sucesso. Ele também citou que bibliotecas de código, kits de desenvolvimento, e até mash-ups são exemplos de reutilização de software que funciona.

Adam continuou com essa observação:

É importante distinguir quando minha equipe usa o que ela mesmo usou anteriormente e quando ela usa o que outra pessoa usou em outra época. A segunda alternativa requer maior reflexão… até para alguém de fora da minha equipe ficar sabendo disso. Existe um custo nisso e esse custo precisa reproduzir algum valor melhor para o negócio.

Como você decide quando reutilizar seu código? Deixe um comentário e compartilhe sua experiência.

Fonte: InfoQ

Por Davi Carvalho para o Blog SOA, Simples Assim!
em 24/04/2009

A compra da Sun pela Oracle ainda vai render muitos artigos, notas em blogs, provavelmente cases em MBAs, artigos em revistas etc.

Por enquanto, é a notícia mais hot além da atual crise financeira mundial.

Vamos a alguns fatos que venho coletando desde Segunda, 20/04/09, quando foi anunciada a compra.

Existem rumores que a negociação iniciou-se na Quinta (16/04) e foram concluidas no Domingo (19/04). Bastante rápido. O valor da transação envolve cifras da ordem de US$ 7,4 bilhões que vai para um valor líquido de aquisição de US$ 5.6 bilhões (US$ 9.50 / ação).

Duas semanas antes a IBM havia baixado sua oferta de US$ 10,00 / ação para US$ 9.40. Vou listar alguns fatos que ajudam a explicar os motivos que levaram a Sun a recusar a oferta da IBM e a aceitar a do Mr. Ellison:

1. Lawrence J. Ellison, Oracle’s chief executive (CEO), estava de olho na plataforma Java da Sun. Nas palavras dele em uma tradução livre:

…de longe é o maior ativo de software que já adquirimos.

2. De todas as instalações do banco de dados da Oracle no mundo, a grande maioria (ainda não sei o percentual), já roda em servidores e sistema operacionais da Sun (Solaris).

3. Com a Sun, a Oracle pode competir com a IBM, H.P. Agora eles podem oferecer o serviço completo. Nas palavras de Gordon Haff, um analista da empresa Illuminata:

…Oracle is transforming itself into a soup-to-nuts information technology vendor.

4. Ambas nasceram e se estabeleceram no Vale do Silício. De fato, Larry Ellison (CEO Oracle) e Scott McNealy (um dos fundadores da Sun), são amigos. Em 2003, em mais uma das crises da Sun, McNealy brincou em um evento dizendo que tinha as chaves do iate e Ellison. O CEO da Oracle retrucou que precisava sair correndo para trocar as fechaduras. Nesta época havia um boato que a Sun seria vendida para a empresa do Mr. Ellison. Pessoalmente acho que elas tem culturas semelhantes, apesar dos fundadores terem histórias de vida diferentes. McNealy é graduado em economia por Harvard e MBA em negócios por Stanford. Ellison começou a carreira desenvolvendo um banco de dados para a agência secreta americana, cujo nome advinhem, era Oracle.

5. McNealy não gosta da IBM. Acha despezível algumas práticas de negócio da “big blue” e que faltaria um entrosamento no alto comando. Os “engomadinhos” da IBM não iriam entender a cultura dos ripongas e nerds da Sun. Neste ponto concordo com o fundador da Sun

6. McNealy e Ellison estão propensos a assumir mais riscos (diferente da IBM). Se a “big blue” tivesse comprado a Sun, provavelmente iríamos ver a IBM empreender um enorme esforço no sentido de provar que “seus” produtos seriam melhores que a da empresa adquirida

Perguntas que não querem calar:

a) O que vai acontecer com o MySQL adquirido recentemente pela Sun? Veja “Is the Sun/Oracle Deal Good for MySQL Customers?“. Quando a Sun adquiriu o MySQL em Janeiro/2008 muitos líderes de projeto/desenvolvedores do banco de dados deixaram a empresa. Agora com a aquisição pela Oracle, é provável que outros tantos irão. Isto poderia definir o fim de uma das referência em banco de dados open-source. Detalhes aqui.

b) E o OpenOffice? Thanks God, já temos vários forks desta suite open-source. Utilizada por milhões de usuários no mundo inteiro, incluindo governos e escolas que não podem bancar com os custos absurdos das suites pagas, eu espero sinceramente que a Oracle continue apoiando o grupo da Sun que mantém o desenvolvimento de partes do “core” deste produto.

c) Você gostaria de ficar dependente de um único fornecerdor como a Oracle? Provavelmente não, correto?

E aqui no Brasil?

Segundo reportagem do Valor Econômico desta Quarta (22/Abr/09), com a aquisição a Oracle passaria da 11a. posição para a 5a. colocação no ranking nacional de companhias de tecnologia da informação, com um faturamento de R$ 1,3 bilhão, resultado que tira a Microsoft do pódio das 5 maiores. A nova lista seria IBM, Hewlett-Packard (HP), Positivo, Itautec e Oracle.

Ambas empresas são forte no país. Os mercados de Telecom (área onde atuo) e Governo, são quase um nincho de mercado para a Sun. Isto explica porque quase 20% dos negócios globais da Sun estão nos BRIC (Brasil, Rússia, Índia e China).

Por fim, veja abaixo a previsão de Larry Ellison em 29/09/2005, quando do anúncio da Siebel:

No industry remains in this fragmented form. The railroad industry didn’t, the automobile industry didn’t, nor will the computer industry. There’ll be far fewer companies. For example, there aren’t that many auto companies in the world. There doesn’t need to be, nor will there be thousands of software companies.

Não é que ele tinha razão?

Fonte: SOA, Simples Assim!

Por Bruno Pedroso para Blog Visão Ágil
em 24/04/2009

Quando fazemos apresentações sobre ágil ouvimos muitas vezes as mesmas velhas perguntas. Confesso que às vezes acho um pouco … digamos… chato responder a essas perguntas pela vigésima vez (#prontofalei). Mas, cá pra nós, não dá pra negar que essas perguntas são chave para o entendimento da filosofia ágil.

Por isso resolvi iniciar incitar essa série de posts aqui na visão ágil, com o intuito de que tenhamos uma muleta prática em que nos apoiar toda vez que precisarmos responder (ou evitar) essas perguntas.

De minha parte, acho que a pergunta mais frequente de todas, campeã indiscutível, é a velha “e a documentação?”. Então resolvi começar a séria com ela.

Já tive várias respostas para essa pergunta. A primeira que me vem à mente hoje em dia é: mas quem foi afinal que falou pra essa gente que nós não documentamos nada?! Esse é na verdade apenas mais um preconceito bobo cultivado pelo telefone sem fio de pessoas que ouvem cantar o galo mas não sabem onde.

Talvez seja por que o manifesto proclama que “software funcionando vale mais que documentação compreensível”. Quando essas frases ecoam por aí parece que o diz-que-me-disse das pessoas acaba esquecendo de levar junto a frase final do manifesto. (Não vou copiá-la aqui. Vai lá e lê!).

Não é que agilistas não gostem de documentação. Parem com isso! O que não gostamos é do mal hábito que se cultivou em basear absolutamente tudo em documentação formal. Trata-se de uma cultura que se desenvolveu por várias razões em nossa indústria nas últimas décadas, mas que simplesmente não faz mas sentido.

Bem, pra falar a verdade, verdade mesmo, XP realmente diz que a melhor documentação que existe sobre o código fonte é o próprio código fonte. Mas isso de forma alguma deve ser interpretado como “se você escreve documentos, então você não faz XP”. Melhor seria entende-la como “trabalhe no sentido de criar código auto explicativo que dependa cada vez menos de artefatos não integrados ao código”.

A maioria das comunicações que nos acostumamos a fazer com documentos formais seriam muito mais eficientes se feitas pessoalmente, conversando, ou até mesmo por telefone. Documentos formais são caros e chatos de manter atualizados. São raras as situações em que são realmente necessários.

Uma das melhores respostas que já ouvi para a pergunta foi dada pelo Juan Bernabó, em um podcast publicado pela ImproveIT (não me pergunte qual), onde alguém perguntou algo como “mas que documentação vocês fazem em Scrum?” A resposta, de tão curta e direta, não chegou nem a ser entendida de primeira por quem perguntou: “a necessária”.

É isso. Se uma documentação é necessária, faz-se a documentação e pronto. Seja lá pelo motivo que for. Não é raro, por exemplo, encontrar clientes que simplesmente não dão o braço a torcer e querem porque querem a documentação dos casos de uso antes que se comece a desenvolver. O que fazer?

Ora, faça as documentações! Que mal há nisso? Crie cartões ou post-it’s para “escrever a documentação do caso de uso CadastrarUsuário”, estime seu esforço e o coloque no backlog, para ser priorizado. Se seu cliente priorizar a documentação, assim será. O mais provável é que ele se convença, com uma ou duas iterações, de que ele na verdade não precisa daquilo… Mas é assim mesmo. Algumas vezes o caminho mais rápido é o mais comprido e tortuoso.

Acho que a lenda que diz que “ágil não documenta nada” poderia ser corrigida para “ágil recomenda que se reflita a respeito de quais documentações são realmente necessárias”.

Tenho certeza de que ainda existem muitas outras respostas para essa pergunta infame que tanto confunde as pessoas. O que deixei aqui foi apenas um ponto de partida para alguma reflexão e uma pequena provocação para que os colegas complementem com seus pontos de vista.

Bruno Pedroso é Bacharel em Ciência da Computação pela UnB, onde atualmente desenvolve seu projeto de mestrado em engenharia de software. Desenvolvedor com mais de 10 anos de experiência, atua hoje como coach de projetos e coordenador da área técnica da SEA tecnologia, dando grande enfoque à aplicação de valores e princípios XP.

Fonte: Blog Visão Ágil

Um computador na casa de cada pessoa do mundo. Se hoje isso parece algo possível – mesmo que ainda longe da realidade – quando Bill Gates começou a trabalhar era apenas um sonho louco. É o que mostra o documentário da BBC, “Money Programme” exibido pelo canal por assinatura GNT com o título “Como Bill Gates mudou o mundo”.

No programa, Gates, seus colegas de trabalho, rivais e funcionários são entrevistados. Não são apenas belas histórias. O espectador ficará sabendo, por exemplo, dos bastidores do processo que ele enfrentou por concorrência predatória. E também o que dizem seus rivais. A administração de sua fundação beneficente também faz parte do programa. O nerd mais famoso do mundo jura que não pretende deixar sua fortuna para seus filhos. Será?

Parte I:

Parte II:

Parte III:

Parte IV:

Postado por Shane Hastie, traduzido por Flávia Castro de Oliveira em 20 Abr 2009 03:57 PM

Na conferência Software Education SDC em Melbourne – Austrália e Wellington – Nova Zelândia, no mês passado, Ivar Jacobson, autor do trabalho original sobre Casos de Uso, a Unified Modeling Language (UML) e o Rational Unified Process (RUP), disse que o desenvolvimento Ágil precisa “ser mais Smart”.

Ele afirmou que a indústria de tecnologia da informação está muito pendente da moda, tendo uma tendência para se apoderar das balas de prata e listou os seguintes exemplos:

• Quinze anos atrás era tudo sobre OO
• Dez anos atrás era sobre componentes, UML, Unified Process
• Cinco anos atrás era sobre RUP e CMMi
• Dois anos atrás era sobre XP
• Hoje é sobre Scrum

Todos tem bons elementos – mas nenhum deles é o que precisamos, o que nós precisamos é Trabalhar com mais Inteligência. Ele diz “Ser Smart é uma evolução de ser Ágil”:

• Agile significa ser flexível e adaptável
• Agile fornece pontos simples/leves
• Ser smart é saber quando ir além do agile
  • Saber o momento de seguir as regras e quando quebrá-las
  • Saber quando ser consistente e quando mudar
  • Saber quando crescer e quando encolher

De acordo com Jacobson “Smart é Agile++”. Ele continuou a dar exemplos de várias práticas e abordagens smart (e não-smart) que ele reconheceu ao longo dos anos. Algumas das práticas Smart e Não-smart que ele idenficou são:

• Unsmart com as pessoas – visualizar os processos e ferramentas como mais importante do que as pessoas
• Smart com as pessoas – reconhecer e entender que o software é construído por pessoas, não com processos e ferramentas!
  

  “Um tolo com uma ferramenta é ainda um tolo, mas um tolo perigoso”
  

• Unsmart com os Times – Os times organizados em grupos responsabilidades separadas (requisitos, análises, design etc)
• Smart com os Times – Cross funcional, pequeno (idealmente 10 ou menos pessoas) times auto-organizados com uma combinação adequada de habilidades para realizar o trabalho.

  
  “Um time de software é como um time de esporte com todas as competências necessárias para vencer”
  

• Unsmart com os Projetos – Tentar seguir uma abordagem waterfall
• Smart com os Projetos – Construir um “sistema magro” para demonstrar que você eliminou todos os riscos críticos e em seguida adicionou mais capacidades sobre o sistema magro conforme necessário.
  
  “Pense grande, construa em várias etapas”

• Unsmart com os Requisitos – Tentar definir todos os requisitos pela frente (uma constante em desenvolvimento de software é que os requisitos mudarão)
• Smart com Requisitos – Base precoce de decisões sobre requisitos leves e os detalhes de como e quando necessário – requisitos são negociáveis e as prioridades mudarão

  “Desenhe seu projeto para mudanças de requisitos”
  

• Unsmart com Arquitetura – sem arquitetura é tão ruim quanto tentar desenhar tudo antes do desenvolvimento
• Smart com Arquitetura – apenas a arquitetura o suficiente para construir o sistema magro, a arquitetura deve resultar em código executável

  “Começar a construir sistemas magros, mais tarde adicionar músculos em pequenos passos”
  

• Unsmart com Testes – ter dois tipos de pessoas – desenvolvedores e testadores. Os testadores de projetos unsmart são “os limpadores no mundo de software” – pegam a desordem deixada pelos desenvolvedores
• Smart com Testes – todo o time é co-responsável pela qualidade e os testadores são cidadãos de primeira-classe

  “O que você faz, não está feito até que você tenha verificado que você fez o que queria fazer”

• Unsmart com Documentação – preencher cegamente um template de documento só porque algumas regras de processo diz que isso tem que ser feito
• Smart com Documentação – reconhecer a “lei da natureza: as pessoas não lêem documentos”. Documente somente o que é absolutamente necessário

  “Foque no essencial – os espaços reservados para as conversas – as pessoas descobrem o resto por si próprias”
  

• Unsmart com Processo– continuamente se apoderando da última moda e tentando mudar tudo o que faz em resposta ao novo livro de regras
• Smart com Processo – Não jogue o bebê junto com a água da banheira:

  1. Comece com sua maneira existente de trabalhar
  2. Encontre os pontos a problemáticos

  3. Mude uma prática de cada vez

  “As pessoas não lêem livros de processo, para concentrar no essencial, as pessoas descobrem o resto por si próprias”

O elemento chave para se tornar Smart é focar nas pessoas, como Jacobson diz e “isso tudo se resume a você”.

Fonte: InfoQ

Publicada em 20 de abril de 2009 às 09h41
Atualizada em 20 de abril de 2009 às 10h55

Rogil – Após negociação com IBM, Sun é comprada pela Oracle em negócio que pagará US$ 9,5 por ação.

A Oracle comprou a Sun Microsystems por 7,4 bilhões de dólares, impulsionando a desenvolvedora de softwares corporativos no setor de hardware e fazendo com que a Sun seja a mais recente operação de TI englobada pela empresa comandada por Larry Ellison.

A Oracle pagará 9,5 dólares por ação em dinheiro para a Sun, de acordo com a Oracle, aumento de 42% em relação ao preço do seu fechamento na sexta-feira (17/04). Excluindo débitos, a aquisição é avaliada em 5,6 bilhões de dólares.

A aquisição da Sun segue outras compras feitas pela Oracle no setor de tecnologia nos últimos anos, como Siebel, PeopleSoft e BEA Systems.

O acordo é anunciado após a Sun ter se afastado de uma negociação com a IBM há algumas semanas.

Ainda que houvesse boatos sobre uma possível aquisição por parte da Oracle, a empresa nunca tinha tido uma participação nos setores de sistema operacional para servidores ou hardware.

A Oracle afirmou que o acordo com a Sun deve trazer mais receita à companhia no primeiro ano após a compra do que as aquisições da BEA Systems, PeopleSoft e Siebel juntas.

A Sun deverá contribuir com 1,5 bilhão de dólares ao lucro operacional da Oracle no primeiro ano após a fusão, número que deverá ultrapassar a marca dos 2 bilhões de dólares no segundo ano, anunciou a Oracle.

Fonte: IDG Now