quarta-feira, janeiro 24, 2007

Workshop sobre Feature Driven Development ( FDD )

A Heptagon, empresa do amigo Adail Retamal, convida a comunidade CMM-Brasil para o 1o. Workshop de Introdução à FDD - Feature Driven Development, em São Paulo-SP, inicialmente previsto para os dias 9 e 10 de fevereiro de 2007 (sexta e sábado).

Lembrando que FDD é uma das metodologias ágeis para desenvolvimento de software que possui forte aderência ao modelo CMMI e recomenda o uso de modelagem desde o início do projeto.

Para maiores detalhes visite a página:

http://www.heptagon.com.br/ws-fdd-sp

Marcadores:

segunda-feira, janeiro 22, 2007

Matriz de rastreabilidade: um artefato obrigatório para atender ao modelo CMMI nível 2?

Enviei a resposta abaixo em uma discussão no grupo xprio acerca da questão da matriz de rastreabilidade. O ponto é interessante pois muitas pessoas acreditam que a matriz de rastreabilidade é algo obrigatório nos projetos da empresa para se obter uma avaliação CMMI nível 2. Abaixo há uma explicação de que isso não é correto:

Em teoria não existe obrigação de se ter uma matriz de rastreabilidade para atender ao modelo CMMI nível 2. Por que digo isso? Porque a realidade é que a única coisa que importa é você atender aos "goals" (metas) de cada PA do CMMI. As práticas específicas são um apoio para avaliar se você atendeu à meta. As subpráticas (e é só no nível das subpráticas que encontramos o item matriz de rastreabilidade) são apenas dicas de como podemos fazer para atingir a prática específica.

Se você tiver meios (por ferramentas ou de cabeça) de provar que consegue rastrear determinadas informações (lembrando que requisitos para o CMMI não são apenas requisitos de usuário, mas não me alongarei aqui) então você está atendendo a necessidade.

Vou dar um exemplo: muitas das ferramentas de issue tracking como JIRA, Mantis, etc já possuem funcionalidade que faz integração dos issues com o sistema de controle de versão. Quando você dá um commit no código pode colocar no comentário qual "issue" ( incidência ) está atendendo com aquelas alterações de código. Esse tipo de coisa atende plenamente o modelo ( a não ser que você pegue um avaliador CMMI que adore waterfall e matrizes explícitas ) sem a necessidade de se ter formalmente uma matriz de rastreabilidade numa planilha Excel ou qualquer coisa do gênero. Além disso você acaba atendendo a rastreabilidade com o planejamento, pois cada tarefa (que pode ser aberta pelos próprios desenvolvedores) estará na ferramenta de issue tracking e terá o relacionamento com os códigos-fonte alterados. Tudo isso sem ter que gastar tempo demasiado e "deixar de castigo" um pobre desenvolvedor para preparar uma matriz formal de rastreabilidade.

Marcadores:

quinta-feira, janeiro 11, 2007

Scrum, OpenUP e CMMI

Este artigo se originou de uma pergunta endereçada à lista de discussão OpenUP/Basic. A pergunta original questiona a possibilidade de conseguir ser avaliado como CMMI nível 2 utilizando o OpenUP.

O OpenUP/Basic segue a filosofia do manifesto ágil e prega que "Software executando é mais importante que documentação" e que "Pessoas são mais importantes que processos". Isso não significa que não há documentação e processo, o que é provado pelos inúmeros artefatos existentes, pelas disciplinas e pela existência do planejamento em cinco níveis das metodologias ágeis. Apenas ilustra o fato que devemos nos focar fortemente nas pessoas e nas interações entre elas, especialmente na transferência de conhecimento tácito. E que também devemos lembrar que o processo iterativo é fundamental para gerar software executável em curtos períodos de tempo.

Eu, particularmente, considero que ele atende tranquilamente o CMMI 2 já que o OpenUP/Basic:

Possui disciplina de requisitos -> atende a PA de REQM
Possui disciplina de Gestão de Configuração e Mudança -> atende a PA de CM
Possui disciplina de Testes -> atende a PA de PPQA
Possui disciplina de Gestão de Projetos -> atende a PA de PP e PMC
Possui gestão e avaliação de resultados de iteração e de projetos (tem por padrão o Project Burdown e o Iteration Burndown. Permite definição de mais métricas ) -> atende a PA de MA (você poderia usar o Practical Software Measurement para detalhar ainda mais outras métricas que você tiver interesse em incluir).

Ficaria faltando a PA de SAM (sendo que gestão de fornecedores - SAM - também não é tratada pelo RUP 7.0 em sua versão base).

A diferença é que, dependendo do assessor que irá verificar suas práticas (talvez seja uma pessoa que goste de ter evidências mais explícitas em formas de documentos do que evidência tácitas em forma de entrevistas), talvez você precise gerar documentos adicionais (Por exemplo, um plano de gerência de configuração. Ele existe no RUP mas não existe no OpenUP/Basic). A vantagem é que você pode utilizar a ferramenta EPF Composer para customizar o OpenUP do jeito que você necessita.

Mas vale sempre lembrar um detalhe: o foco do OpenUP e de todos os processos ágeis é te dar um aumento radical de produtividade e qualidade (reduções em até 50% no prazo de entrega de projetos, mantendo alta a qualidade). Ele não tem como objetivo apenas demonstrar que você está aderente a um modelo ou não. Muitas empresas se focam no CMMI e não em realmente melhorar seu processo. O que ocorre muitas vezes é que acabam burocratizando demais seus processos, tornando seus projetos lentos e pesados.

Segundo o artigo da InfoQ, o uso de Scrum, quando bem implementado, pode trazer o processo de uma organização para o CMMI nível 3. O OpenUP/Basic utiliza muitas práticas e princípios do Scrum e, portanto, creio que essa afirmação também se adequa ao OpenUP. Recomendo a leitura dos seguintes endereços para apoiar no processo de ser avaliado em níveis do CMMI utilizando processos ágeis:

http://www.cmmifaq.info/

http://www.agilecmmi.com/

http://www.infoq.com/news/2006/11/case-for-agile-cmmi5

http://www.entinex.com/agilecmmi/

http://agile2005.org/XR14.pdf

http://jeffsutherland.com/scrum/2006/11/scrum-supports-cmmi-level-5.html

Marcadores: , , ,

quarta-feira, janeiro 10, 2007

Impressões sobre o treinamento Certified Scrum Master - 05 a 06 de janeiro de 2007

O treinamento Certified Scrum Master, ministrado por Boris Gloger da Sprint-IT e por Gerald Huesch da Boston Business School, foi realizado com sucesso e realmente foi excelente! Novas turmas, para quem quiser fazer o curso, podem ser encontradas em SPRiNT-iT Scrum Trainings .

O treinamento iniciou com uma surpresa de tirar o fôlego de algumas pessoas! Mas não a contarei aqui :-) .

Logo no início realizamos um exercício para entender como funciona o trabalho de equipe sob pressão, através de um jogo em que preparamos em apenas 59 minutos uma brochura sobre a Terra para visitantes marcianos.

Depois utilizamos os conceitos e as técnicas de retrospectivas para entender o que fizemos bem e o que poderia ser melhorado no nosso processo de trabalho.

Tivemos uma importante lição sobre a necessidade do comprometimento pessoal quando nos atrasamos um 'pouquinho' na volta do primeiro coffee break!

Um jogo com bolas de tênis, com quatro iterações, nos ensinou os conceitos mais importantes do Scrum como: Timebox, Regras Simples, Objetivos claros, Auto-organização, comprometimento, objetivos intermediários e estimativas definidas pela equipe.

Uma breve história da agilidade fechou a parte da manhã do primeiro dia de treinamento.

Na segunda parte realizamos o jogo dos 60 passos para entender ainda mais a diferença entre uma cultura de comando e controle e uma cultura de lideranca e colaboração, bem como porquê essa última é mais produtiva e mais motivadora para uma equipe.

Depois Boris entrou em detalhes acerca dos papéis existentes no Scrum e sobre o processo inicial do planejamento de todos os releases de um projeto (planejamento estratégico). Entendemos os conceitos de Backlog de produto, estimativas de tamanho através de comparações relativas, uso de números Fibonnacci para realizar as estimativas, valor de negócio dos requisitos e priorização do backlog.

Para fechar o primeiro dia realizamos o excelente "Planning Poker". Mais uma vez aprendemos a importância das estimativas serem realizadas pela equipe que irá realizar o projeto e não por entidades externas como costuma ocorrer na prática atual do mercado de TI.

O segundo dia teve seu foco em detalhar o planejamento tático do Scrum. O planejamento tático demonstrou como uma equipe realiza um Sprint (nome dado ao Scrum a uma iteração, que pode durar de 2 a 4 semanas). Foi fundamental verificar que o uso de uma cartolina e stick-notes ajuda na realização de um planejamento muito mais colaborativo e granular do que estamos acostumados. O uso de ferramentas tão simples não impede que essas informações sejam atualizadas e colocadas diariamente em ferramentas de software de gestão de incidências (como Mantis, Rational ClearQuest, Eventum, Jira, etc) e planejamento (como Project, dotProject, ect).

Aprendemos com o Boris que cada tarefa específica que deve ser realizada no Sprint precisa ter a duração de no máximo um dia. Esse ponto não aparece nos livros do Ken Schwaber (um dos pais do Scrum). Verifiquei depois que esse conceito também estava no livro "Agile Estimating and Planning" de Mike Cohn. Porém só tive a "sacada" do motivo para tarefas de um dia com a explicação do Boris.

Quando nos forçamos, como equipe, a identificar tarefas de um dia para construir uma funcionalidade naturalmente minimizamos o problema da Síndrome do Estudante e do consumo sempre completo de uma tarefa mesmo quando um recurso a termina antes (esse conceito é ligado à natureza humana de deixar as coisas para o final do seu prazo. Se uma tarefa possui 40 horas tende-se a iniciá-la na segunda metade do prazo. Esses conceitos foram bem explicados também para justificar a necessidade da gestão de projetos por corrente crítica). Quando atuamos em tarefas de um dia e temos um processo específico de planejamento diário (o daily stand-up meeting) o comprometimento em realizar algo produtivo todos os dias se torna natural. E se não há progresso na tarefa descobre-se facilmente o que está ocorrendo e isso gera um impedimento que deverá ser trabalhado pelo Scrum Master.

Um projeto costuma atrasar pouco a pouco e esses atrasos costumam não ser notados. O processo do Scrum permite que a equipe possa detectar os problemas diariamente devido ao planejamento diário que é feito.

O segundo dia também teve vários tópicos e ferramentas de liderança. Estes foram especialmente apresentados pelo Gerald e foram sensacionais para ajudar no processo de se tornar um líder servidor trabalhando com equipes auto-organizadas.

O último exercício do segundo dia ajudou a colocar em contexto todas as práticas de planejamento do Scrum. O interessante dos jogos é que fornecem metáforas úteis para facilitar a fixação e compreensão dos conceitos de Scrum e para o entendimento do porquê ele funciona e como ele gera motivação e auto-organização da equipe.

Finalmente terminamos o dia com a parte mais importante: nossa sagração como Certified Scrum Masters!!! Recebemos nossos certificados e aprendemos o mais importante: o aperto de mão secreto e o cumprimento que permite que os Scrum Masters certificados consigam se identificar na multidão :-) !!!

Novos treinamentos de Certified Scrum Master (CSM) ainda ocorrerão no Brasil. Esse foi apenas o primeiro e já organizamos um grupo de discussão para manter ativa a comunidade de CSMs. Recomendo fortemente que, em próximas oportunidades, aqueles que ainda não fizeram o treinamento se inscrevam!

Vocês podem saber das datas de treinamentos no Brasil através do SPRiNT-iT Scrum Trainings .

WUFF!!!

Marcadores:

terça-feira, janeiro 09, 2007

Novas Certificações IBM Rational

Novas certificações da IBM apareceram, relacionadas à sua nova linha de produtos.

A mais interessante, para o pessoal de processos, é a IBM Certified Solution Designer - Rational Unified Process v7.0 . A prova está mais simples do que a prova da versão anterior, a versão 2003. Leia mais sobre os benefícios da certificação RUP 7.

As outras duas provas são:

IBM Certified Solution Designer -- Rational Performance Tester

IBM Certified Solution Designer - Rational Functional Tester for Java

Marcadores:


Veja as Estatísticas