Uma das reuniões previstas no Scrum é a Sprint Retrospective. Nesse encontro, a equipe discute o sprint anterior, o que foi bom (e deve ser mantido), o que não foi bom (e precisa ser melhorado ou não repetido) e o que poderia ser feito de novo para melhorar ainda mais os próximos sprints.

É um momento excelente para captar opções de melhorias vindas do próprio time, com base em fatos concretos e experiências reais.

Contudo, fica uma questão: como manter esse conhecimento ao longo do tempo e transformá-lo em um ‘asset’ da empresa, aplicável não apenas para o time em questão, para todos os times de scrum, replicando as melhores práticas e evitando cometer os mesmos erros?

Uma forma que aplicamos, com relativo sucesso (importando a ideia dos métodos de gerenciamento da rotina) foi a criação de um checklist – uma lista de perguntas que é aplicada sempre ao final das reuniões de planning e atualizada ao final de cada reunião de retrospective.

Serve como uma verificação de que os pontos principais levantados pela equipe no passado estão sendo considerados no planejamento e não foram esquecidos. Questões como:

• Reservamos tempo suficiente para testes? E homologação?
• Existe algum item de backlog que não está claro?
• Todos sabem o objetivo de cada um?
• Temos algum evento previsto para ocorrer durante o próximo sprint?
• Algum membro do time tem algum compromisso marcado, férias, ou precisará se ausentar? Se sim, irá impactar nos prazos?

Essa lista, que pode parecer simples e óbvia para equipes mais experientes, pode auxiliar muito novas equipes, evitando falhas comuns no planejamento e auxiliando a alcançar o objetivo assumido pela equipe.

No modelo que implementamos, fica a critério dos Scrum Masters (ou do PMO, quando existir um) selecionar os pontos que devem ou não ser incluídos nessa lista comum.

É importante separar o que é específico de um projeto, e portanto deve ser incluído apenas naquele contexto, e o que pode beneficiar todos os demais times de Scrum. É uma tarefa importante, que irá transformar o conhecimento adquirido pelas equipes em conhecimento corporativo, fazendo com que velhos erros não sejam repetidos, mesmo por equipes novas.

O checklist pode ficar disponivel online, em ferramentas como blogs e wikis corporativos, e ser consultado por todos.

Lançado durante o evento para desenvolvedores Google I/O, o Google Wave promete revolucionar a comunicação na internet.

Criado como uma espécie de agregador de diversas ferramentas de comunicação, o Wave é uma mistura de e-mail, blog, wikis, redes sociais, messenger, além de permitir compartilhamento de arquivos e fotos. Mais legal ainda: tudo em tempo real.

Um dos recursos mais inovadores do Wave é possibilitar criar conversar dentro de conversas. Um usuário pode, por exemplo, selecionar parte de uma conversar (literalmente) e iniciar uma conversa nova (paralela à principal) a partir daquele trecho. Outro usuário pode comentar o comentário anterior, e assim uma nova linha surge a partir da conversa original.

Outro recurso bacana é a possibilidade de arrastar arquivos e imagens diretamente para a janela do browser. Esse recurso ainda não é suportado pelo HTML atual, sendo previsto para a próxima versão (HTML 5), portanto é necessário instalar um plug-in fornecido pelo Google para suportar a funcionalidade. Mas vale a pena.

A ferramenta está em beta (e qual não está?), sem data prevista de lançamento, mas o Google deve liberar um beta em breve. O vídeo do lançamento é um pouco longo (1:30h) mas vale a pena assistir.

O CMMi, sigla para Capability Maturity Model Integration, é definido como um modelo de referência que contém práticas necessárias à maturidade em áreas/disciplinas específicas, como engenharia de sistemas, engenharia de software, desenvolvimento de processo, entre outros (fonte: wikipedia, br).

Trocando em miúdos, define um conjunto de boas práticas de gerenciamento para o processo de desenvolvimento de software.

Parte-se da premissa de que a qualidade do produto final (os sistemas entregues) está diretamente ligada à maturidade do processo responsável por sua construção. Embora tenha perdido parte de sua popularidade, o CMMi continua importante, em especial para fábricas de software, pois diversas organizações somente adquirem software ou serviços relacionados de empresas com certificação nível 3 – entre elas o governo americano, possivelmente um dos maiores compradores de software do mundo.

Scrum, por sua vez, é uma metodologia de gerenciamento ágil de projetos, que vem ganhando ampla adesão da comunidade e empresas ligadas ao processo de criação de software. Entre outras razões, destacam-se os resultados obtidos, além da simplicidade do processo.

É considerado um dos métodos “light”, pois possui poucas práticas e controle, quando comparado a métodos mais “tradicionais”. A pergunta que fica é: é possível para uma organização adotar as práticas do Scrum e ainda assim obter o grau de CMMi? O método é suficiente para obter a certificação?

O CMMi é dividido em níveis de maturidade. Quanto mais avançado em seus níveis, mais estável é o processo de desenvolvimento da organização e maior o seu grau de maturidade. De forma resumida:

• Nível 1: processo ad-hoc. Não definido, não existe um processo claro de desenvolvimento. Nesse nível, os resultados não podem ser previstos.
• Nível 2: processo repetido. Nesse nível, um processo inicial é definido e seguido sempre.
• Nível 3: processo definido. Aqui o processo é claramente definido; suas entradas, etapas e saídas estão claras, e ele é seguindo sempre.
• Nível 4: gerenciado. O processo é medido e são tomadas ações corretivas (gerenciamento).
• Nível 5: melhoria continua. O processo inclui, em si mesmo, revisões frequentes, com o objetivo de otimizá-lo continuamente.

.

No início o CMMi foi relacionado ao modelo tradicional de desenvolvimento de software, ou “waterfall”. Essa comparação, embora natural, não é uma restrição do modelo. Se compararmos os níveis de maturidade do CCMi com as práticas previstas no Scrum, começando pelo nível 2, veremos que ele atende muitos dos requisitos previstos:

Nível 2 – processo repetido

Ao adotar Scrum como metodologia, a organização passa automaticamente a contar com um processo sobre o qual operar.

As reuniões de planejamento de releases servem para construir uma visão para o projeto, bem como definir os objetos e o produto final, ainda que em alto nível, sem o grau de detalhamento previsto em outras metodologias.

As reuniões de planejamento de Sprint definem ou reavaliam prioridades, decisões e soluções adotadas, adaptando o projeto à realidade corporativa, que está em constante evolução.

As reuniões diárias servem como ponto de comunicação constante entre os membros da equipe, realinhando e adaptando o projeto em uma base diária.

Nível 3 – processo definido

Da mesma forma, Scrum passa a ser o processo definido para a organização. Entretanto, será necessário (re)definir as práticas de engenharia de software que serão aplicadas – Scrum é um método para gerenciamento de projetos e não prevê organicamente nenhuma dessas práticas. Para atingir esse estágio, será necessário complementar o processo, com a ajuda da(s) equipe(s), já que a metodologia é empírica.

Nível 4 – processo gerenciado (quantitativo)

Existem poucos controle “formais” previstos no Scrum, destacando-se o burndown chart, que permite avaliar a taxa de “consumo” do backlog, tando dos sprints como dos releases. Além disso, é possível medir a velocidade da equipe, a taxa com que ela consegue entregar software completo e funcional (itens do backlog).

Com isso em mãos, é possível tomar medidas corretivas e buscar aumentar a velocidade – ferramentas, automação de processos repetitivos etc., que são a chave para o próximo nível.

Fica a critério da organização definir controles e métricas adicionais que julgar necessários. Vale lembrar, contudo, que a maioria dos controles do Scrum ocorre nas diversas reuniões previstas, de maneira mais informal. Esses checkpoints se configuram como as melhores fontes de informação para identificar se o projeto está nos trilhos.

Nível 5 – melhoria continua

Sprint Review e Sprint Retrospective são previstos como momentos para apresentar o trabalho desenvolvido e para que a própria equipe encontre métodos para melhorar o trabalho, baseado na experiência passada, respectivamente. As lições aprendidas devem ser registradas, devem passar a fazer parte da base de conhecimentos da empresa e transmitidas aos demais times. Com essas informações, a gerência e o próprio time podem tomar medidas que ampliem a capacidade de resposta do time, melhorem a qualidade e eliminem processos desnecessários.

Em seu livro Agile Projet Management with Scrum, Ken Schwaber faz um breve comparativo entre algumas das KPAs (key practice areas) dos niveis dois e três do CMMi e as práticas do Scrum, que reproduzo aqui. Uma marca simples significa aderência parcial, uma dupla significa aderência completa:

Level – Key Process Area – Rating

2 – Requirements management – **
2 – Software Project planning – **
2 – Software Project tracking and oversight – **
2 – Software subcontract management – **
2 – Software quality assurance – **
2 – Software configuration management – *
3 – Organization process focus – *
3 – Organization process definition – *
3 – Training program – *
3 – Integrated Software management – *
3 – Software product engineering – **
3 – Intergroup coordination – **
3 – Peer review – **

O que não está previsto no método – práticas de engenharia de software – são as principais adaptações que deverão ser incluídas pela organização. Essas práticas deverão provir das melhores práticas de arquitetura, complementadas com a experiência da equipe, obtida de forma empírica. Quando definidas, devem ser comunicadas, reforçadas e medidas pela gerência.

Uma combinação das práticas do Scrum (para projetos) e de XP (Extreme Programming), para complementar a engenharia de software, pode ajudar. Para níveis de maturidade superiores ao três, contudo, diversos novos processos de controle deverão ser adotados, tanto técnicos quanto gerenciais.

Conclusões

O que vimos é que Scrum pode fornecer o arcabouço sobre o qual construir (e evoluir) o gerenciamento de projetos de software, com algumas adaptações, sendo em uma primeira análise, compatível com a maioria dos processos do CMMi, ao menos até o nível 3.

Acima desse nível (4 e 5) serão necessárias diversas adaptações, incluindo novos processos e controles – de engenharia de software como de gestão. Valerá uma análise de custo-benefício com relação à adoção dessas práticas complementares. O desafio, como sempre, é manter a flexibilidade e agilidade, com a organização necessária para garantir a qualidade do produto final.

Mais sobre Scrum na Wikipedia.
Mais sobre CMMi na Wikipedia (em inglês).

Scrum é uma metodologia de gerenciamento ágil de projetos que vem ganhando popularidade nos últimos anos. É utilizada principalmente em projetos de desenvolvimento de software, onde o grau de incerteza e a variação de escopo tendem a ser altos.

Assim como a maioria dos métodos ágeis, Scrum funciona melhor com times relativamente pequenos, de até sete ou oito integrantes. Isso se deve em grande parte ao fato de que a comunicação direta e constante é um dos fundamentos do método.

Quando o time cresce acima desse limite – que é empírico, como tudo no Scrum – o esforço de comunicação começa a se tornar gradativamente maior, as informações tendem a fluir mais lentamente e começa a ser necessário empregar outros mecanismos para garantir que os stakeholders recebam as informações de que necessitam. Em resumo, a eficiência começa a cair gradativamente.

Considere ainda que, em diversos projetos, não é possível ter todo o time compartilhando o mesmo ambiente físico. Em alguns casos, as equipe podem estar inclusive em países e fusos horários diferentes, o que dificulta ainda mais a comunicação e interação entre os integrantes da equipe.

Uma das soluções propostas por Ken Schwaber, um dos criadores do Scrum, em seu livro “Agile Project Management with Scrum” (que recomendo fortemente) para aplicar a metodologia em equipe maiores é o chamado “Scrum of Scrums”.

Em resumo, significa quebrar o time em equipes menores, multi-disciplinares, evitando assim os “silos de competências”. Esses times menores, que estarão dentro do limite de integrantes recomendado, devem ser auto-suficientes, no sentido de serem capazes de entregar conjuntos completos de funcionalidade a cada sprint.

Para sincronizar os esforços dos diversos times, os Scrum Masters de cada equipe devem se reunir em uma reunião equivalente a “Daily Meeting” – participam apenas os representantes de cada time e o Scrum Master principal.

Nessa reunião também se aplicam os mesmos princípios da original: os representantes de cada time dizem o que foi realizado desde a reunião anterior, em que irão trabalhar até a próxima e o que está impedindo-os de realizar seu trabalho ou obter o máximo desempenho.

Para auxiliar as diversas equipes é recomendado que exista a figura do Scrum Master central. Este herda as mesmas atribuições dos Scrum Masters no Scrum tradicional, mas seu compromisso é relativo ao conjunto dos times. Por exemplo, se diversas equipes reportam problemas com o ambiente de homologação, é seu papel conseguir (de alguma forma) que esse impedimento seja removido. As retrospectivas, que ocorrem no final de cada sprint, também devem ser realizadas de forma semelhante, com os representantes de cada time.

Para isso, algumas condições devem ser observadas. Em especial, o projeto deve ser passível de ser dividido em funcionalidades e essas distribuídas aos diversos times, o que nem sempre é simples. É preciso também criar uma arquitetura inicial, padrões e práticas claras de engenharia, de forma a evitar que o sistema se torne uma colcha de retalhos.

Em seu livro, Ken menciona algumas equipes que utilizaram, com sucesso, um “Sprint Zero”, onde especialistas (engenheiros seniores) foram responsáveis por criar uma arquitetura inicial, além de definir os padrões que seriam utilizados no restante do projeto.

Nos sprints seguintes, cada um dos diversos times que foram formados recebeu pelo menos um dos integrantes do Sprint Zero, que se tornou responsável por disseminar o conhecimento da arquitetura e garantir a aderência das novas funcionalidades desenvolvidas aos padrões e práticas de engenharia de software. Esses integrantes se tornaram a ponte para disseminar a visão comum do projeto entre os times.

É claro que coordenar os esforços de um conjunto de equipes tende a ser um desafio maior do que em times simples – e exigirá deles, do Scrum Master e Product Owner as conhecidas adaptabilidade, flexibilidade e criatividade tão conhecidas no Scrum.

Caberá ao time do projeto bolar soluções para os problemas que surgirem, não apenas nas questões técnicas, mas também em aspectos como comunicação e integração, fatores críticos ao sucesso de qualquer projeto, e em especial para equipes geograficamente separadas.

Soluções criativas como blogs, wikis, programas de mensagens instantâneas podem auxiliar bastante. Existem opções gratuitas para todas essas ferramentas. Pessoalmente, recomendo ainda que a reunião diária seja realizada utilizando uma ferramenta de videoconferência, ou no mínimo, com um conference-call. Uma conversa de alguns minutos pode eliminar algumas dezenas de e-mails.

Precisando abrir documentos do MS Word, planilhas Excel, apresentações, imagens?

Uma boa opção é o complemento para o Firefox Open IT Online 1.5. O plug-in para o browser é gratuito e funciona com os seguintes formatos de documentos: *.doc, *.rtf, *.odt, *.sxw, *.xls, *.csv, *.ods, *.sxc, *.ppt, *.pps, *.odp, *.sxi, *.jpg, *.gif e *.png.

Quando o usuário abre um arquivo de qualquer um desses formatos usando o Firefox aparece uma tela oferecendo um serviço online com recursos de edição. Clicando OK, o Open It Online redireciona para uma ferramenta online com capacidade para editar o arquivo (Google Docs, por exemplo).

Além de simples, o complemento é bem rápido, claro, dependendo da sua conexão de internet.

Para baixar: Open IT Online 1.5.

Artigo interessante sobre como os mashups estão popularizando o uso de aplicações de Business Intelligence – tradicionalmente restritas a matemáticos e estatísticos – para o grande publico.

Não acho que se trate de salvar ou não o BI, mas sim de ampliar a base de usuários efetivos desse tipo de sistema, trazendo novas e melhores aplicações.

Vejo isso como uma evolução natural, como a que ocorreu com a própria internet, no inicio restrita aos meios militares e acadêmicos, mas que alcançou seu potencial máximo (até agora) quando a maioria da população passou a ter acesso. A ampliação da base de usuários e aplicações somente faz aumentar a demanda por novas soluções, levando a um ciclo positivo de crescimento.

É interessante também o termo BI 2.0… será que temos mais uma buzzword?

Leia mais detalhes no Computerworld:
A Web 2.0 pode salvar o BI?.
Desaparecem empresas específicas de Business Intelligence.

Para quem precisa rodar mais de um sistema operacional na mesma maquina, uma opção simples e prática é o VirtualBox, produto desenvolvido pela Sun.

Apresentada no SunTechDays 2008 e disponível para download gratuito, a máquina virtual permite instalar e executar, por exemplo, Windows em de uma máquina rodando Linux como sistema operacional principal, sem a necessidade de fazer (re)particionamento, dar múltiplos boots etc.

Claro, o contrário também é verdade – podemos rodar Linux dentro do Windows. E o mais interessante, você pode executar um sistema operacional em cada janela, simultaneamente – claro, dependendo da capacidade da sua máquina.

O sistema já roda em diversas versões do Windows, distribuições do Linux e MacOS. É possível ainda configurar aspectos como memória e espaço em disco para cada sistema operacional instalado.

Pode ser uma opção para o usuário Windows que gostaria de se aventurar no mundo Linux, com baixo impacto, sem ter que trocar radicalmente, reformatar, com todo o esforço de migração. Também é uma boa opção para desenvolvedores, que precisam testar suas aplicações em diversos SOs diferentes, ou simulando acesso externo para aplicações web.

Estivemos lá: acompanhe os destaques do SunTechDays, realizado em São Paulo, em 29 e 30 de setembro.

No mundo Java, sempre tema principal do evento, a Sun continua suportando fortemente tecnologias como JSF (JavaServerFaces) e EJB3. Seguindo a tendência apresentada no JustJava, os WebServices RESTful também vem ganhando força, com apoio de frameworks e adoção pela comunidade, se mostrando uma solução viável para a grande maioria das aplicações web, nas quais requisitos como transações e segurança não são tão críticos.

No mundo do desenvolvimento web 2.0, soluções como o JQuery, Dojo e Comet prometem simplificar bastante a vida dos programadores que tem que lidar como tecnologias Ajax e escrever código JavaScript.

Do lado da JVM, foram apresentadas algumas mudanças previstas para a próxima versão e alguns mecanismos para monitorar e melhorar o desempenho das aplicações. O IDE da Sun, o Netbeans, também foi bastante discutido – praticamente todos os demos foram realizados sobre essa plataforma – seu suporte a novos frameworks e mesmo novas linguagens. O ambiente de desenvolvimento em sua última versão já conta com suporte completo ao desenvolvimento de aplicações Ruby e JRuby e para a próxima, foi prometido suporte a PHP.

E nem só de Java vive o SunTechDays. Além das sessões sobre a plataforma da Sun, foram apresentadas também temas envolvendo o banco de dados MySQL, recentemente adquirido pela companhia, e que em breve deverá contar com suporte local no Brasil, da própria Sun. Essa sempre foi uma dos principais barreiras levantadas pelas empresas para adoção do produto.

Solução de virtualização (bastante interessante, por sinal), o VirtualBox, produto simples e gratuito permite executar vários sistemas operacionais simultaneamente (um em cada janela, claro). É uma opção viável para quem quer testar novos ambientes sem ter que montar múltiplos boots, ou ainda para os desenvolvedores que precisam testar suas aplicações em SOs diferentes.

Também foi apresentado o projeto Zembly, iniciativa interessante da Sun, que permite a desenvolvedores (e não desenvolvedores) combinarem aplicativos de redes sociais, como o Meebo e o Facebook, criando seus próprios serviços e disponibilizando para a comunidade, sem custo.

Esses foram pontos em destaque. Novamente não foi possível acompanhar todas as sessões – foram três linhas de palestras simultâneas, uma com foco em Java, outra sobre MySQL e produtividade e a terceira sobre OpenSolaris.

Este mês vamos participar do Software Summit, evento focado em desenvolvimento, que vai ocorrer no Colorado, USA, entre os dias 19 e 24 de outubro. Novidades em breve.

Cloud computing é um modelo de computação em que os dados, arquivos e aplicações ficam em servidores virtuais, acessíveis através de uma rede.

É interessante para empresas, pois simplifica o investimento em infra-estrutura, já que a empresa paga pelo uso dos serviços (máquinas, rede, processamento, memória etc), sem a necessidade de comprar servidores “fisicos” e arcar com custos de datacenter.

Outra vantagem é poder crescer com o sistema. Em alguns minutos, pode-se ter um (ou mais) servidores (virtuais) novos, com as configurações que forem necessárias, rodando sua aplicação e aumentando a capacidade de resposta.

Esse serviço já vem sendo oferecido por players como Google e Amazon. Agora, a Microsoft entra no jogo.

Dentro de um mês, deve revelar ao mercado o “Windows Cloud”, sistema operacional ainda sem nome, voltado para desenvolvedores que atuam com aplicações de cloud computing (computação em nuvem).

Segundo Steve Ballmer, o CEO da Microsoft, há planos de acelerar a oferta de software como serviço e a Microsoft está trabalhando em uma tecnologia que vai permitir que usuários façam edições online de documentos. O sistema não tem relação com o Windows 7, sucessor do Windows Vista.

“Queremos softwares mais poderosos do que aqueles que rodam no navegador”, respondeu Ballmer, quando perguntado sobre uma concorrência com o Google Docs.

• Wikipedia (inglês): Cloud Computing
• Computerworld: Ballmer promete sistema operacional para cloud computing
• ChannelWorld: Microsoft apresenta o conceito de software mais serviço aos canais brasileiros
• ChannelWorld: Windows 7 promete interface multi-touch

As redes sociais continuam mostrando fôlego. Nessa segunda-feira, foi apresentado no SunTechDays, em São Paulo, o Zembly, plataforma que permite aos desenvolvedores (e mesmo não desenvolvedores) criar e combinar pequenos aplicativos para redes sociais e ainda adicionar novas funcionalidades.

O novo serviço fornece um ambiente para desenvolvimento (próximo aos IDEs, dos desenvolvedores), mas diretamente na web – os aplicativos devem ser desenvolvidos em Javascript. Existe também funcionalidades para testes e depuração diretamente na ferramenta, além da hospedagem gratuita.

Usando uma API fornecida, o desenvolvedor pode integrar serviços disponíveis no Facebook, Meebo e integrá-los com iPhone apps, Google gadgets, widgets e outros.

Segundo Sang Shin, evangelista da Sun e palestrante no evento, o serviço pretende ser um “wikipedia para redes sociais”. Essa afirmação é confirmada diretamente na homepage do próprio site.

Ainda segundo Sang, o serviço, hospedado pela própria Sun, ainda está em estágio de beta. Questionado sobre novas funcionalidades, como a possibilidade de armazenamento de dados, ele afirma que “o serviço irá evoluir conforme a necessidade e uso da comunidade. Entretanto, os próprios desenvolvedores poderiam desenvolver um serviço de armazenamento como esse e disponibilizá-los para outros usuários”.

Fica a idéia: que tal um serviço como esse hospedado no Cloud do Google?