Building Minds - o Blog da OnCast

Oracle compra Sun

Não é de hoje que a Sun está mal das pernas. A ação que valia $25 há 2 anos, chegou menos de $3 antes do início das negociações com a IBM. Todas as empresas de TI deste porte sofreram com a crise, mas em pouco casos a desvalorização ultrapassou 50%. Não é por acaso que o valor de mercado da Sun parece não refletir seu tamanho. A própria Oracle comprou a PeopleSoft por $10 bi, a BEA por $8,5 bi e agora compra a Sun por “apenas” $7 bi.

Consequências

E agora, o que será do Java e outros produtos da Sun?

“The acquisition of Sun transforms the IT industry, combining best-in-class enterprise software and mission-critical computing systems”, Larry Ellison, CEO da Oracle + Sun.

Java é tão importante para a Oracle que já havia se tornado sua tecnologia padrão para sua estratégia de midleware (Oracle Fusion Middleware). A importância também é demonstrada na posição oficial da Oracle, de continuar investindo e inovando em Java:

“Java is one of the computer industry’s best known brands and most widely deployed technologies. Oracle Fusion Middleware is built on top of Sun’s Java language and software. Oracle can now ensure continued innovation and investment in Java technology for the benefit of customers and the Java community”.

Apesar dos aparentes benefícios, pelo simples fato de haver uma fusão entre empresas, é natural que agora surjam várias dúvidas em torno do futuro do Java. Ainda deve haver algum tempo até o acordo ser confirmado, até os novos interesses se assentarem, definições de RH, etc. Até lá não deverão haver grandes lançamentos ou planos por parte da Sun. Quanto mais ágil este processo for concluido melhor para nós, desenvolvedores Java.

Java 7 e JCP

O entrega do Java 7, até então planejada para início de 2010, agora é duvidosa. O Java 7 virá (viria) com algumas inovações interessantes, como suporte a linguagens dinâmicas, novo suporte a computação paralela e o novo garbage colector G1. Apesar da Oracle ter uma certa cultura de software livre com seu envolvimento no Linux, ainda há curiosidade sobre seu grau de abertuda no JCP e uma eventual mudança nas licenças Java.

JVM

Além da JVM oficial, o JRockit da Oracle era uma grande iniciativa. Não parece lucrativo manter os esforços separados, entretando uni-los reduziria nossas opções como desenvolvedores. Outra dúvida é se a Oracle vai continuar investindo em Java para mobile. Como a Oracle está se firmando no mercado de aplicações corporativas (com soluções de hardware, SO, SGBD, midleware), será que vão arriscar perder o foco e investir na JME?

Glassfish e Netbeans

Para os amantes do Glassfish parece uma boa notícia e sinal de continuidade, já que a Oracle investia “recursos significativos de desenvolvimento”. Isto não vale para usuários do Netbeans. A estratégia da Oracle para IDEs sempre foi investir no Eclipse e no seu JDeveloper e, até o momento, não havia interesse em adotar qualquer tecnologia Netbeans.

MySQL

Na compra da Sun, a Oracle ganha de brinde o MySQL. Ela acaba com um concorrente e ganha uma nova opção de mercado para bancos de dados. O MySQL, líder open-source e para soluções de 1 a 10 mil usuários, possui mais mercado que o Oracle 9i, 10g ou 11g isolados. Agora não se sabe como o MySQL será mantido. O mais provável é que ele fique um pouco de lado e não evolua tão rapidamente quanto seria na Sun ou na antiga MySQL.

Solaris, OpenOffice, ODF

A Oracle já havia escolhido o Solaris como uma plataforma importante para o banco Oracle, principalmente se tratando de 64 bits. Mais importante que esta sinergia, agora a Oracle tem mais que apenas uma extensão do RedHat, ela tem seu próprio SO, o que pode representar uma vantagem competitiva em outros mercados. Espero que a Oracle venha com um novo impulso de capital e inovações para o Solaris e isto também vale para o OpenOffice e o ODF.

Mercado

O mercado de desenvolvimento de software poderá ter aplicações escritas com tecnologia Oracle, rodando em servidores de aplicação Oracle, banco de dados Oracle (o original ou o MySQL). Tudo isto em servidores de processamento ou armazenamento hardware Oracle e SO Oracle. É, faz tempo que Oracle deixou de ser apenas um banco de dados robusto.

Adriano Campestrini Ferramentas

Outro dia, quando Caio e eu estivemos em um de nossos clientes, estávamos conversando com uma pessoa do setor de vendas e sentimos dificuldade em explicar-lhe como o desenvolvimento ágil pode ser bom no que diz respeito às mudanças. Ficamos neste embate até que me surgiu uma idéia, correndo o risco de me tornar o metafórico da OnCast, vou transcrever a estória que contei para ele:

Imagine que você nos contrate para fazer um garfo, pois fora convidado para um jantar e tinha que levar seu talher.

Depois de iniciado o processo de confecção do garfo você descobre que o cardápio do jantar vai ser sopa. Portanto o garfo não será de grande serventia, melhor seria usar uma colher.

Se estivesse dependendo do desenvolvimento tradicional, teria que esperar o garfo ficar pronto para que então fosse iniciado o processo de confecção da colher.

Se fosse através do desenvolvimento ágil, teríamos durante o processo de confecção do garfo uma mudança no sentido, e passaríamos a fazer não mais um garfo, porém uma colher.

É isso que temos com o desenvolvimento ágil, a facilidade em aceitar uma mudança no sentido do projeto. A perda com essa mudança é proporcional ao seu tamanho e também ao tamanho do projeto. Ou seja, se, no exemplo acima, ao invés de uma colher precisássemos mudar de um garfo para um Hachi (aqueles pauzinhos usados no oriente) teríamos muito mais dificuldade e possivelmente um aumento no número de iterações.

Essa resposta rápida às mudanças é um dos quatro valores do desenvolvimento ágil “Responder às mudanças sobre seguir um plano” e é também um dos princípios abordados no manifesto ágil “Até mesmo mudanças tardias de escopo no projeto são bem-vindas.”. Por ser um dos alicerces de nossa metodologia, temos que  acreditar, aceitar e, o mais complicado, fazer com que o cliente acredite nisso.

Marcelo Silva Metáforas, Riscos

Essa foi a pergunta que a Mirela, nossa Assessora de Marketing, fez ao Adriano e ao Samuel, dois dos três sócios da OnCast Technologies. Após receber várias respostas enumerando as qualidades do SCRUM/XP/Lean, me permitiram que falasse sobre uma delas. Expliquei que havia me identificado bastante com a característica do processo ágil que permite desenvolvimento de software sustentável, um dos princípios elencados no Manifesto Ágil.
Uma das maneiras de se atingir isso é com a criação de código simples, outro princípio discretizado no Manifesto Ágil. Com um código simples torna-se fácil a percepção de falhas precocemente, atacando cedo, aquele que poderia ser o câncer de todo o processo. Acabei criando o seguinte exemplo para explicar essa faculdade:

Imagine que um cliente nos peça que façamos uma casinha de Lego de determinada cor. Para isso nos entrega todas as peças necessárias sem notar que nos havia entregue uma peça de outra cor.

Caso executássemos essa tarefa utilizando o desenvolvimento tradicional, tirando toda burocracia envolvida, faríamos a casa e ao terminar, perceberíamos que na base da casa havia uma peça de cor errada. Isso implicaria em desconstruir toda a casa e, por sua vez, reconstruí-la, perdendo um tempo que o cliente provavelmente não possuía.

Caso estivéssemos usando o desenvolvimento ágil, teríamos notado a peça errada antes mesmo de terminar a casa, faríamos sua troca pela peça correta e continuaríamos nosso desenvolvimento sem essa perda tão considerável de tempo.

O que quis dizer com este exemplo é que um problema, dentro do desenvolvimento ágil, é atacado assim que é encontrado, desta forma é suplantado, minimizando o tempo gasto com isso.

Fazendo um gancho do exemplo do Lego com o desenvolvimento de softwares, podemos lembrar do Test-Driven Development (TDD) que é a abordagem que nos ajuda a encontrar a “peça” errada, antes desta “peça” influenciar nas outras “peças” que compõe o software.

Em suma, pode-se dizer que o desenvolvimento ágil tenta mitigar o efeito “bola de neve”, tornando mais simples e contínuo o processo criativo.

Marcelo Silva Ferramentas, Metáforas, Riscos

Um dos problemas mais críticos de um projeto é quando o cronograma foge do controle do time e as estimativas revelam-se erradas e sem maturidade. Isto demonstra que os processos utilizados para chegar a elas podem ter falhas. Frente a problemas como este, é importante ir fundo nas suas causas e planejar que tipo de melhorias podem ser feitas para tornar as próximas iterações bem sucedidas.

Nas primeiras iterações, é inevitável. De certa forma, é esperado que as estimativas não sejam realista por motivos como: desconhecimento do escopo, novas tecnologias e falta de entrosamento da equipe. Esses fatores reunidos, ocasionam a falta de estimativas confiáveis e o desconhecimento da velocidade real do time.

Com o passar do tempo, a fluência da equipe aumenta e é possível confiar mais no que está sendo estimado e  se comprometer com uma quantidade de trabalho, tendo a confiança de poder entregá-la com qualidade e dentro do prazo combinado.

Entretanto, é comum ver projetos já avançados com problemas no cronograma. Atrasados ou adiantados, ambos os casos são ruins. Demonstram que o processo de desenvolvimento tem problemas e que o time pode nao estar conseguindo mensurar corretamente o risco existente em cada estória.

Por isso, é importante recolher métricas, constantemente, para uma melhoria continua dos processos ligados a às estimativas. Depois de cada Daily Meeting, podemos avaliar de uma maneira simples e direta, seja marcando no próprio cartão ou em uma planilha, os resultado das estimativas. Caso elas tenham se cumprido, devem ser consideradas adequadas, caso contrário, baixas ou altas. Também é interessante ter algumas observações referentes aos motivos dos problemas, se for o caso.

Idealmente, a produtividade que foi acordada no inicio deve variar pouco, mostrando que o time é capaz de manter processos sustentáveis de desenvolvimento. Apesar de ser bom manter uma reserva gerencial, ou gordura, para se resguardar de quaisquer problemas que possam acontecer em durante a iteração, se este for um hábito constante, pode acabar ocasionando gráficos parciais e dados irreais, além de um processo opaco tanto para o time quanto para o cliente.

Analisando o gráfico, após uma iteração problemática, é possível notar os pontos que fizeram com que a iteração não fosse bem sucedida. As métricas das atividades fechadas nos dias em que a produtividade oscilou de forma acentuada devem ser analisadas com cuidado. É provavel que essas estimativas estejam marcadas como baixas ou altas, e com o objetivo de melhorar no futuro, podemos nos aprodundar nos motivos que causaram estes desvios.

Se as estimativas foram altas, medidas como planejar escopo extra ou antecipar estórias de alto risco podem ser interessantes para agregar mais valor à iteração e garantir uma entrega completa e com qualidade. É interessante justificar para o cliente que as superestimativas decorrerem de novas abordagens tecnológias ou de negócio do projeto, ou seja, frente a um risco que teve que ser considerado, com isso o time vai ganhar mais maturidade e com a lição aprendida vai saber lidar com situações parecidas em futuras iterações. Entretanto, caso não existirem motivos suficientemente justificados para elas, uma conscientização do time, acerca do problema e de como poderá afeta a imagem do time perante o cliente, deve ser feita.

Por outro lado se ocorrerem estimativas baixas, isso pode refletir um desconhecimento das técnologias envolvidas ou do negócio, comum no inicio do projeto, e isso vai trazer também maturidade para o time da mesma forma que aconteceu com as superestimativas. Caso as estórias sejam livres de débitos relacionados à novas técnologias ou escopo ainda não trabalhado, uma análise dos impedimentos que podem ter ocorrido durante o desenvolvimento é fundamental para identificar que ações corretivas que foram tomadas no momento em que os problemas aconteceram, e se ajudaram a evitar a queda de produtividade do time. No primeiro sinal de queda da produtividade por problemas de impedimentos é importante parar a atividade até que os impedimentos sejam resolvidos para evitar a desmotivação do e desperdicio do esforço do time, que poderia estar sendo convergido em estórias sem impedimentos.

Caso a desmotivação já tenha dominado o time, tomar medidas corretivas como pair programming ou move people around, podem ajudar a subir a moral do time e estabilizar o processo produtivo.

Com a obtenção e avaliação desse tipo de métrica, podemos entender melhor cada movimento que o gráfico realizou e como isso afetou a iteração e assim o time poderá se desenvolver de uma forma mais transparente,  madura e produtiva, com um alto grau de confiabilidade tanto nas estimativas, quanto na garantia da entrega do que foi assumido com o cliente, aumentando a confiança de ambos os lados e gerando novas oportunidades de negócio para a empresa.

Rodrigo Branas Comunicação, Riscos

Para quem usa Eclipse, agora ficou mais fácil medir a cobertura de código dos testes automatizados.

O EclEmma é um plugin para o Eclipse que mede e apresenta a cobertura de testes no próprio Eclipse. Com o velho Emma ou com o brasileiro Cobertura, era preciso configurar o build para instrumentar o código e rodar a medição. Os resultados era visualizados em relatórios html. Nada realmente integrado à IDE!

Medir a cobertura com o EclEmma parece muito mais natural. Os testes são executados no próprio Eclipse e a apresentação dos trechos cobertos e descobertos é integrada ao editor Java.

Adriano Campestrini Ferramentas

Para quem sente falta de ferramentas simples para gerenciamento de pequenos projetos com Scrum, aí vão duas dicas:

• Scrum Ninja
• Scrumy

São opções bem simples, clean e de fácil acesso pois são SaaS, ous seja, não precisam ser instaladas. O Scrum Ninja tem a vantagem de ser grátis para projetos open source ou projetos com até 3 usuários.

Uma opção mais completa, porém não tão simples é o VersionOne. Ferramenta líder de mercado para gestão ágil de projetos, também possui versão SaaS, abrange técnicas de outras metodologias, o que pode ser útil para projetos maiores.

Seja qual for a ferramenta escolhida, sugiro não deixar de usar o dashboard com post-its e o burndown chart desenhado no quadro branco. A parede e o quadro branco são campeões nos quesitos acessibilidade e visibilidade, além disso, tornam o ambiente de trabalho mais dinâmico e humano.

Adriano Campestrini Ferramentas

Preocupado com o burndown da sua primeira iteração?

Se você é um integrante do time e está preocupado com o burndown da primeira iteração do seu projeto, fique sabendo que é muito provável que você falhe.

É isso mesmo! Na primeira iteração o negócio, a tecnologia e o ambiente podem ser novidades, o time ainda não acertou a mão nas estimativas e não está entrosado. Sem falar que nem todos podem estar maduros com o processo, inclusive o Product Onwer, e na ansiedade que isto gera. Para mitigar seus riscos, aí vão algumas dicas do que o ScrumMaster pode fazer antes, durante e depois da primeira iteração:

Antes da primeira iteração:

Invista na sua comunicação com o Product Owner. Você pode organizar uma reunião de kick-off do projeto, para que sejam definidas as regras do jogo. No planejamento da primeira iteração, o Product Owner deve ficar ciente de que as estimativas devem ser “mais erradas” que o normal, para que ele não se surpreenda com uma entrega incompleta (a única certeza que temos das estimativas é que elas estão erradas, mas isto é outra discussão).

Também não é sadio o Product Owner tratar a primeira iteração decisiva quanto a continuidade do trabalho - chame sua atenção para o fato de que o time deve se estabilizar apenas na terceira iteração.

Defina as datas e locais das próximas reuniões de planejamento e explique sua necessidade. Isto irá desencorajar qualquer desculpa para reagendamento.

Não peque por escassez de planejamento e estimativas. Puxe o time para não ter pressa nem preguiça ao receber tanta informação nova. As regras de negócio costumam ser novidade: intercalar reuniões com e sem os conhecedores do negócio ajudam a refinar o entendimento do escopo. Reserve tempo antes de estimar, para analisar a macro-arquitetura e qualidade do código legado, APIs e estudar novas tecnologias.

Durante:

Mantenha o Product Owner sempre informado, mesmo que seja por email, mesmo que ele não responda. Surpreenda-o o mais cedo possível, mesmo em caso de atraso (que é um caso de visibilidade que você preferiria não estar vendo, mas é forçado pelo burndown). Não deixe-o esquecer que tropeços eram esperados na primeira iteração.

Registre cada suposição mal feita durante o planejamento, cada aumento inesperado de escopo e cada impedimento: será útil para o aprendizado do time na retrospectiva.

Time-boxed: é importante aceitar o fim da iteração na data combinada mesmo com burndown no alto. Finalizar as iterações na data combinada é especialmente importante nas primeira iterações: mostra organização, marca o ritmo do processo e disciplina o time a se planejar melhor para entregar tudo com que se compromete. Em caso extremo, com um burndown chart completamente horizontal, ou burn up, considere dar a iteração por encerrada antes do tempo e realize um novo planejamento.

E depois da iteração 1:

Não alcançou o objetivo da iteração? Tudo bem! O importante é não se acomodar e aprender.

É durante a Reunião de Retrospectiva que ocorre o aprendizado, é quando você vai evitar cometer os mesmos erros na iteração 2.

Recomendo evoluir durante a reunião um Value Stream Map ou uma Análise SWOT. Mapear a cadeia de valor irá tornar a forma de trabalho do time mais focada em gerar valor para o cliente. Na análise SWOT, sugiro avaliar o que pode ser feito para melhorar cada ponto elencado como fraqueza ou ameaça. Atenção especial aos erros de estimativas e aos incrementos de escopo descobertos durante a iteração.

No caso de uma insatisfação do Product Owner quanto à entrega, sugiro ao ScrumMaster expôr a ele os pontos relevantes da análise SWOT e, inclusive, dar seu feedback sobre o Product Owner, a fim de que ele melhore continuamente seu desempenho neste papel.
E agora?

Deixe seu comentário contando como foi sua primeira iteração. E bom trabalho na segunda!

Adriano Campestrini Metodologia, Riscos

Comunicação e código? Por que o primeiro post neste blog falaria sobre algo tão distante de código como comunicação? E comunicação aqui não é nenhum protocolo utilizados em dois sistemas ou duas camadas, é comunicação entre pessoas mesmo.

O problema está justamente aí, comunicação e código são distantes nos paradigmas atuais de engenharia de software, principalmente nos mais tradicionais. Imagine um processo onde uma pessoa tem uma visão sobre um sistema informatizado, ele escreve esta visão, outra pessoa a lê, analisa e escreve outro documento detalhando o que o sistema deve fazer para atingir esta visão. Uma terceira pega este segundo documento, lê e implementa. Que tipos de problemas temos neste modelo de comunicação? Leia mais…

Rodrigo Machado Comunicação