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.

Uma reportagem na revista Info comenta sobre a possível tecnologia sucessora da 3G – trata-se da LTE (Long Term Evolution). Segundo o texto, as 750 operadoras de telefonia móvel integrantes da GSM Association (GSMA) já confirmaram a intenção de trabalhar com o LTE.

É intenção por enquanto, pois neste momento a atenção do mercado está voltada para o WiMAX, principalmente nos Estados Unidos, em função de um projeto que envolve uma parceria entre a Intel (infra-estrutura) e a Clear (provedora), que já “instalou” uma rede WiMAX que cobre completamente as cidades americanas de Baltimore(MD) e Portland(OR), desde janeiro deste ano.

A previsão é que a tecnologia que sucederá a 3G comece a ser utilizada já em 2011. No Brasil, deverá ter um atraso de dois anos em função de as operadoras ainda estarem investindo dinheiro em 3G, e portanto aguardarão o retorno dos investimentos.

Além da vantagem de ter o apoio da GSMA, o analista de Telecom do IDC, Vinicius Caetano, afirma que “o LTE terá a vantagem de ser uma tecnologia mais barata, por causa da alta escala de produção dos aparelhos”. A vice-presidente de redes da Ericsson, Luciana Pailo, afirma que “algumas operadoras já estão construindo as redes 3G com equipamentos pré-LTE”.

Ainda é cedo para saber qual tecnologia vai prevalecer; mesmo assim não podemos deixar de observar que esta evolução que está muito próxima de acontecer no Brasil influenciará muito no comportamento do usuário que passa mais horas conectado à internet no mundo.

Mais sobre a LTE na Wikipedia.

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.

É a primeira parceria entre dois grandes players de cloud computing: o Google App Engine e o Force.com poderão se integrar através de uma API.

A integração trará muitos benefícios para os aplicativos desenvolvidos para os consumidores do App Engine que buscam e realizam operações nos serviços corporativos do Force.com.

Qual será o movimento do serviço de cloud da Microsoft?

Mais no Techcrunch:
Force.com + Google App Engine = Cloud Relationship Management.

A Yahoo acaba de lançar o Zimbra Desktop – um client de e-mail que a pessoa instala em sua máquina e pode configurar inúmeras contas e centralizar calendário e contatos em um só lugar. Todo o serviço fica hospedado em cloud computing.

A idéia é competir com o Outlook Exchange da Microsoft, permitindo acessar seus dados mesmo estando offline.

Já a Microsoft pensa em algo mais ousado com o seu Windows Azure. A idéia é ter um sistema operacional em cloud que permita o desenvolvimento de aplicações todas voltadas à internet.

O mais legal é que o sistema não será amarrado apenas para rodar linguagens da própria Microsoft – será possível desenvolver em PHP, Ruby e Python. Para a linguagem da casa, ASP.NET, o Visual Studio 2008 tem SDK que permite o desenvolvimento offline de aplicações para depois colocá-las no Azure.

No Yahoo, o Zimbra Desktop.
Na Microsot, o WindowS Azure.

Não está longe o dia em que vamos conviver com robôs. Os japoneses acreditam nesta oportunidade de negócio e estão sempre apresentando novidades, como este robô que fotografa e publica posts em blogs.

Foi apresentado na Robo Japan, evento em Yokohama, no Japão, que em três dias de exibição mostrou dezenas de robôs, muitos já conhecidos.

O NetTansor Web, fabricado pela Bandai, tem uma câmera CMOS e permite escrever e fazer o upload de blogs com fotos digitais. Chega no Japão para o fim do ano, com preço sugerido de US$ 500.

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.

Widsets é um aplicativo para mobile que permite que você configure vários widgets (como se fosse um Favoritos) que possam ser acessados em apenas um clique.

Tem uma interface muito legal, onde você navega em um scroll horizontal e vê um mapa dos seus widgets.

Os principais widgets disponiveis são:

• Flickr
• Wikipedia
• Twitter
• G1 (globo.com)
• Push mail – onde você pode configurar qualquer conta para acessar direto do celular (como Gmail e Yahoo)

Mais no site Widsets.
Para baixar o aplicativo direto do celular: Widsets Mobi.