Rational Team Concert - Detalhes da nova solução de ALM da IBM Rational

O Rational Team Concert é uma robusta ferramenta de ALM (Application Lifecycle Management) colaborativa, baseada na plataforma aberta Jazz. Nesse artigo, vou falar sobre seus principais recursos, suas três diferentes edições e preços, a visão futura da plataforma e a questão que ainda confunde novos e antigos clientes: o RTC substitui a suite Rational clássica?

Começando pelas funcionalidades: O RTC conta com um sistema de controle de incidências integrado com controle de versões (possui um sistema de controle de versões próprio e tem conector para o Subversion), wiki, sistema de integração contínua e um servidor portal que gera as mais diversas métricas, relatórios e informações executivas sobre os projetos. É o nirvana dos desenvolvedores e gerentes de projeto!

O Rational Team Concert já vêm com dois processos pré-definidos na "caixinha": são eles o Scrum e o OpenUP. Além é claro da flexibilidade que o RTC fornece para a equipe configurar seu próprio processo. Todas as edições do produto contam com esses recursos. Lembre-se que o Rational Team Concert pode ser usado como um plugin do Eclipse (é uma nova perspectiva) ou através de um browser Web conectado diretamente ao servidor (vide abaixo sobre o futuro do RTC para detalhes específicos relaciuonados a desenvolvedores .NET).

O RTC pode ser usado em três edições distintas (preços de acordo com a página do RTC no site oficial da IBM, na data deste artigo. Para informações mais atualizadas, pode me consultar! ):

- Express-C: permite até 10 usuários. Não possui custo de licença para o servidor e o custo por usuário é de 1200 dólares por desenvolvedor e 600 dólares por contribuidor. Usa como infra-estrutura o Tomcat e o banco de dados Derby.

- Express: permite até 50 usuários. Possui custo de licença de servidor de 6.000 dólares. O valor de licenças para desenvolvedor e contribuidor é o mesmo da edição Express-C. Usa como infra-estrutura o Tomcat ou o WebSphere Application Server e o banco de dados DB2 Express, DB2 ou Oracle. Possui os mesmos recursos que a versão Express-C. A única grande diferença é a quantidade de usuários máximos permitidos.

- Standard: permite até 250 usuários. Possui custo de licença de servidor de 50.000 dólares. O valor de licenças para desenvolvedor é de 3900 dólares e o de contribuidor é o mesmo da edição Express. Usa como infra-estrutura o Tomcat ou o WebSphere Application Server e o banco de dados DB2 Express, DB2 ou Oracle. Além do maior número de usuários possui os seguintes recursos extras: Configuração de permissões de acesso baseado em papéis, Conectores para ClearCase e ClearQuest, Customização de itens de trabalho do gerenciador de incidências (nas versões Express-C e Express não é possível customizar os work itens), Customização de relatórios e dashboards executivos.

Uma dica e vantagem interessante: em qualquer uma das versões você tem o direito de usar 3 (três) licenças de desenvolvedor gratuitamente! Portanto, se você tem uma equipe de até 3 pessoas pode usar o RTC Express-C sem custo algum! Se sua equipe crescer você paga só pelo quarto usuário em diante.

O que podemos esperar para o futuro próximo do Rational Team Concert?

- Lançamento de um plugin para o Microsoft Visual Studio (hoje desenvolvedores .NET podem usar a ferramenta através do servidor Web mas, com o lançamento do plugin, o desenvolvedor não precisará mais sair da IDE para realizar o seu trabalho).

- Lançamento da edição Enterprise do Rational Team Concert (já virá com as novas versões do Rational ClearCase, ClearQuest e BuildForge. Versão 8.0 da suite Rational).

- Lançamento da ferramenta Requirements Composer, que já está em beta. Facilitará o processo de levantamento de requisitos e criação de protótipos rápidos. Essa ferramenta não substitui o RequisitePro. Elas possuem objetivos distintos: o Requirements Composer auxilia o analista de requisitos no levantamento e o ReqPro auxilia na gestão desses requisitos levantados com os stakeholders.

- Lançamento da ferramenta Quality Manager, que já está em beta. Fornecerá funcionalidade de gestão de testes e qualidade (será a evolução do Rational ClearQuest TestManager) já integrada dentro da plataforma Jazz.

E, para finalizar, vamos ajudar a responder a pergunta: o RTC substitui a suite Rational clássica?

Para empresas pequenas e médias ou equipes pequenas ou médias em grandes corporações o Rational Team Concert atenderá às necessidades imediatas que a suite Rational oferece. E com uma grande vantagem: uma velocidade muito maior (e custo menor!) de instalação, configuração, customização, treinamento, mentorização e administração da ferramenta (a suite Rational clássica demanda mais recursos e tempo, devido à sua grande capacidade de customização). Para times pequenos e médios que desejam usar um processo e ferramenta out-of-the box com as melhores práticas de processos e ferramentas existentes no mercado de desenvolvimento de software, essa é a ferramenta ideal.

Grandes empresas, que desejam uma maior flexibilidade de customizações, configurações e adaptações para adequar ferramentas ao seu processo continuarão necessitando da suite Rational clássica e, em 2009, usarão o novo empacotamento dessa suite, chamado de Rational Team Concert Enterprise. Mas já podem já adquirir a suite Rational Team Concert Standard e plugá-la em suas ferramentas atuais, para facilitar aind mais a vida das equipes de desenvolvimento!

Portanto, pequenos e médios times (de 1 a 250 usuários!) já possuem uma solução completa para suas necessidades de desenvolvimento colaborativo: o Rational Team Concert!

Caso você tenha lido este artigo e está avaliando uma possível aquisição deste produto e seus respectivos treinamentos, configurações e mentorizações entre em contato comigo que ajudarei no que for possível, inclusive para detalharmos face a face as vantagens da nova plataforma Jazz!

Vídeo do Debate sobre Metodologias Ágeis no TDC 2008

Participei de um debate sobre metodologias ágeis no The Developer's Conference 2008, realizado no dia 26 de julho de 2008. O Vinícius Teles, que também participou da mesa, gravou tudo e disponibilizou.

Tem assuntos bem interessantes e eu contribuí principalmente falando sobre o RUP e o OpenUP. Também comentei sobre o overhead necessário para se implantar um processo ágil que também atenda ao CMMI, levantando o exemplo do MSF da Microsoft.

Assistam então ao vídeo do debate sobre metodologias ágeis para terem vários pontos de vista acerca do tema.

Scrum (ou Agile) com CMMI - É possível?

Escrevo esse post movido por dois distintos eventos: o primeiro foi o excelente painel sobre metodologias ágeis que ocorreu no TDC 2008 e o segundo foi um posto na lista scrum-brasil sobre o assunto Scrum e CMMI.

A dúvida é: É possível fazer o Scrum ou outro processo ágil ficar aderente ao CMMI e ser avaliado oficialmente por um SCAMPI?

A resposta curta é: Você pode fazer um processo ágil ficar aderente ao CMMI, porém terá um grande overhead (sobrecarga) de custo e prazo em cada um de seus projetos para conseguir isso.

A resposta mais longa e com evidências(he, he!):

Para início de conversa, recomendo fortemente primeiro a leitura do artigo do David Anderson chamado Stretching Agile to fit CMMI Level 3. Anderson foi um dos criadores da nova versão do MSF (processo de desenvolvimento suportado pela Microsoft e mais conhecido por vir como padrão na ferramenta Visual Studio Team System) . Ele explica nesse artigo o que tiveram que fazer para conseguir adequar um processo ágil (o MSF for Agile) para atender o modelo do CMMI.

Fica claro no artigo que existiu um razoável overhead para isso acontecer. Anderson estudou só o overhead para atingir o CMMI nível 3. Se falássemos no nível 4 e no nível 5 o overhead seria ainda maior (teria que incluir controle estatístico de processos, análise causal, gerenciamento quantitativo de projetos, etc).

Segue a conclusão mais interessante de Anderson (negritos meus): "It was therefore necessary to enhance MSF for Agile Software Development with additional activities to cover these aspects of the CMMI. This was non-trivial. The footprint of the guidance material for MSF for CMMI Process Improvement is 150% larger than that of MSF for Agile Software Development. So some large amount of stretching was necessary. For example, MSF for Agile Software Development has 25 work product artifacts whilst the CMMI method has 59. There are 9 metric charts with the agile method whilst the CMMI method has 12. "

Portanto, você pode até atingir o CMMI usando um processo ágil e isso é legal. Porém, tenha em mente que não existe uma solução mágica para isso e avaliadores CMMI (que usam o SCAMPI) ainda determinam a necessidade de documentação explícita (chamados de artefatos diretos e indiretos) para cada uma das práticas específicas das áreas de processo do CMMI.

Tendo isso em mente, você e sua empresa devem estar cientes do grande overhead que será necessário para o processo ágil ficar aderente ao CMMI. Se a empresa realmente necessita do CMMI para governança, como estratégia de marketing ou outro fator qualquer ela antes deve ter consciência que um projeto feito com "Agile CMMI" terá mais custo e será mais lento que um projeto feito com "Agile Agile".

O Adail Retamal da Heptagon respondeu à minha conclusão com um outro dado muito interessante que aqui transcrevo:

"É isso aí, Papo! Nos meus cursos e consultorias sempre saliento esses aspectos também. Minha proposição para um Agile CMMI é:

Nível 2: Scrum, parte da FDD, PSM
Nível 3: + FDD, parte da TOC, algo de Lean
Nível 4: + Six Sigma
Nível 5: + TOC

Claro que outras ajudas serão necessárias para atender certas PAs, mas essa receitinha já abrange uns 80%..."

Mais detalhes sobre esse assunto de Scrum, Agile e CMMI podem ser encontrados no meu artigo Scrum, OpenUP e CMMI.

Evento TDC 2008 - Participação no painel sobre processos de software

Será realizado na cidade de São Paulo, neste próximo final de semana (dias 25 e 26 de Julho), o evento TDC 2008 - The Developers Conference, que é organizado pela empresa GlobalCode.

Nesse evento, além da excelente trilha sobre Java, teremos uma trilha de palestras bem interessantes sobre metodologias ágeis e engenharia de software, feitas por vários colegas e amigos. Serei um dos participantes do painel final no sábado sobre processos de software.

Abaixo a lista de palestras de amigos no evento:

Estratégias para testes: a metáfora da pirâmide alimentar - Jorge Diz e Kleber Xavier

Scrum - Juan Bernabó

Modelagem Ágil - Manoel Pimentel

eXtreme Programming - Vinícius Manhães Teles

Conheça a iniciativa Jazz da IBM - Pessoas constroem grandes aplicações, não empresas! - Rodolpho Rugolini

Painel Gestão, metodologias e processos de software: com a teoria, a prática é outra - Jorge Diz, Vinicius Teles, Manoel Pimentel, André Piza, Adriano Romero, Enio Stein, José Papo

Veja a Programação do TDC para maiores detalhes de todas as palestras.

Scrum Master e sua importância - "Antes de construir software, construir pessoas!"

Pretendo aqui ajudar a esclarecer a importância do Scrum Master, qual seu papel em uma organização de desenvolvimento de software que aprende e como devem ser suas características de liderança.

Resolvi escrever esse artigo baseado em duas inspirações: A primeira é a série de livros fenomenais que descrevem em detalhes o Sistema Toyota de Produção (ou Produção Lean), sua filosofia e cultura(os livros são: The Toyota Way, The Toyota Way Fieldbook, Toyota Talent e Toyota Culture). A segunda inspiração teve como base os debates ocorridos nas listas sobre desenvolvimento ágil, tratando sobre se o scrum master é necessário e se o scrum master é uma função única.

Quando falamos do Scrum Master não estamos falando de uma função meramente técnica. Ela é uma função de liderança. Porém, uma liderança diferente daquela encontrada ainda em muitas empresas: o estilo de gestão comando e controle. Estamos falando de uma liderança servidora. Podemos fazer uma analogia com outras organizações, como por exemplo as religiões judaica e cristã protestante. Nessas organizações, uma premissa fundamental é que os fiéis podem ter um contato direto com o Divino, sem necessidade de intermediários. Porém, mesmo assim encontramos as figuras dos rabinos e pastores. Para que eles servem? Eles são o que considero um modelo da liderança servidora. O papel deles não é dizer que só através deles se chega à salvação. Seu principal objetivo é ajudar e servir à sua comunidade, da melhor maneira possível. Ser um guia espiritual e um visionário, que busca compreender e vivenciar a cada dia que passa um pouco mais sobre sua filosofia e transmiti-la àqueles aos quais servem.

O Scrum Master também é um líder nesse sentido. E o capítulo 15 do livro "The Toyota Way", de Jeffrey Liker, me ajudou a compreender a diferença profunda entre os vários tipos de líderes que encontramos e qual é o líder esperado em empresas que buscam o pensamento ágil, enxuto e de uma "Learning Organization". O capítulo explica o Princípio número 9 do Modelo Toyota: "Crie líderes que entendem em profundidade o trabalho, vivam a filosofia e a ensinem para os outros".

Liker descreveu as diferentes formas de liderança através de uma matriz com duas dimensões e que definem quatro possíveis tipos de líderes. A figura abaixo ajuda a entendê-la.

A primeira dimensão define que o líder pode dirigir de cima para baixo através de regras ou então de baixo para cima em um estilo mais participativo para desenvolver as pessoas de modo que elas pensem e tomem as decisões sozinhas.

A segunda dimensão diz que um líder pode ter um entendimento profundo do trabalho ou conhecimento gerencial genérico. Em muitos lugares, de acordo com Liker, existe ainda a noção de que o gerente bem sucedido típico é aquele que tem um MBA e que pode ir para qualquer negócio e instantaneamente trabalhar nele olhando para números e usando princípios de gestão genéricos. (Nenhum gerente da Toyota aceita essa noção. Todos conhecem e inclusive já trabalharam nas organizações de engenharia e no chão de fábrica).

Vamos então entender os quatro tipos possíveis de gerentes:

Gerente burocrata (Top-down e com conhecimento genérico de gestão): é o menos eficaz de todos. Segundo Liker caracteriza a maioria dos gerentes americanos atuais(será que o Brasil é igual?). Como uma pessoa pode ser eficaz tentando gerenciar uma organização de cima para baixo sem ter um conhecimento íntimo e profundo do que está acontecendo e de como esse trabalho é realizado? Eles só possuem uma chance e a usam: criam toneladas de regras e políticas e medem a performance com base nessas regras e políticas. Isso leva a um gerenciamento dirigido por métricas que tira o foco da satisfação dos clientes ou em construir uma organização que aprende.

Facilitador de grupos (Bottom-up e com conhecimento genérico de gestão): Este tipo de gerente é aquele que se baseia na crença de que se um líder possui fortes habilidades de facilitação, ele pode motivas os empregados a trabalhar em conjunto rumo a um objetivo em comum. Facilitadores são catalisadores, porém não conseguem ensinar ou guiar as pessoas em relação ao que devem fazer no dia a dia. Esses líderes podem ser ótimos para motivar equipes e ajudá-las a se desenvolver. Mas eles realmente podem fazer coaching e mentorizar outros naquilo que eles não entendem? Eles nem mesmo possuem a experiência para julgar as contribuições e o trabalho dos seus subordinados.

Mestre de Tarefas (Top-down e com conhecimento profundo do trabalho): Esse tipo de gerente trata os subordinados como marionetes, puxando todas as cordas. Isso se torna um grande fardo, pois uma corda puxada de forma errada pode fazer o processo de trabalho entrar em colapso. Esse líder costuma desconfiar de outros com menos experiência. Como o gerente burocrata, ele dará ordens, mas ordens para fazer tarefas específicas exatamente como ordenado. Essa é a definição de micro-gerenciamento.

Construtor de Organizações que aprendem (Bottom-up e com conhecimento profundo do trabalho): Por terem uma combinação de entendimento profundo do trabalho e a habilidade para desenvolver, mentorizar e liderar pessoas são respeitados por seu conhecimento técnico e são seguidos por suas qualidades de liderança. Esses líderes raramente dão ordens. De fato, esses líderes frequentemente lideram e mentorizam através de questionamentos. Esse líder fará perguntas sobre uma situação e sobre a estratégia da pessoa ou da equipe para resolvê-la, mas não darão nenhuma resposta a essas questões apesar de terem o conhecimento.

Os grandes líderes da história da Toyota possuem as seguintes características:

- Focados numa visão de longo prazo
- Nunca desviavam dos princípios do "Toyota Way" e se modelavam em torno desses princípios para todos verem. Adotavam uma postura de professores e mentores diariamente.
- Cresceram na hierarquia através do trabalho de chão de fábrica e/ou de engenharia e sempre continuaram indo ao local atual onde o trabalho de valor agregado é feito.
- Viam problemas como oportunidades para ensinar e mentorizar as pessoas.

Uma frase comum ouvida na Toyota é: "Antes de contruirmos carros, construímos pessoas". O objetivo dos líderes na Toyota é desenvolver as pessoas para que estas sejam fortes contribuidores para a empresa e que estejam imbuídas dos princípios de auto-gestão e de melhoria contínua realizada por todos os membros de uma equipe.

O grande desafio do líder é ter as três seguintes características: a visão de longo prazo de saber o que fazer, o conhecimento de como fazer e a habilidade de desenvolver pessoas para que possam entender e fazer seu trabalho de forma excelente. O benefício dessa dedicação é mais profunda e duradoura para a competitividade de uma empresa do que usar um líder apenas para resolver problemas financeiros imediatos ou tomar uma decisão para um situação determinada de curto prazo.

É interessante notar que outro conceito usado na Toyota é o de "não fazer compromissos". Isso significa que eles questionam continuamente o "ou". Discussões - como, por exemplo, o que é melhor... um scrum master com habilidades para lidar com pessoas "OU" um scrum master técnico? - são respondidas com: o melhor é ter um gerente de pessoas "E" um gerente técnico. Ou então: o Scrum Master deve fazer só atividades de facilitação e remoção de impedimentos "OU" fazer atividades técnicas? A resposta Toyota seria: deve fazer ambos :-) . Muitas vezes criamos dicotomias que podem ser implodidas com uma análise mais "lean".

A conclusão então é: o Scrum Master é um papel essencial. Precisamos de figuras de liderança servidora nas organizações criadas por seres humanos. O melhor tipo de líder para se tornar um Scrum Master é o construtor de organizações que aprendem (lideram bottom-up e têm conhecimento profundo sobre desenvolvimento de software, isto é, são líderes servidores/professores que respiram e amam o que fazem).

Espero que essas dicas vindas da precursora do pensamento enxuto (Lean Thinking) possam ajudar a entender melhor o papel e a importância do Scrum Master ou de um líder de projetos numa organização de TI.

Vamos então seguir o mesmo caminho: "Antes de construir software, devemos construir pessoas!"

Considerações sobre o RSDC 2008 em Orlando, EUA

Agora que estou de volta ao Brasil, vou compartilhar importantes informações e insights que tive ao assistir a dezenas de palestras na Rational Software Development Conference 2008 realizada em Orlando - Flórida - Estados Unidos.

Começando pelas palestras dos keynote speakers Danny Sabah, Gerente Geral da IBM Rational; Colleen Arnold, Gerente Geral da IBM Global Services; Steve Mills, executivo do IBM Software Group e Grady Booch, um dos três amigos. O que podemos tirar de ponto mais importante, especialmente para a comunidade de desenvolvimento ágil é: a IBM globalmente está adotando processos ágeis de desenvolvimento. Iniciou e já está em pleno vapor o seu uso nas equipes que desenvolvem os produtos da IBM como o WebSphere, produtos Rational, etc.

As palestras sobre Jazz mostraram claramente que o próprio produto Rational Team Concert foi desenvolvido com base em técnicas ágeis de desenvolvimento (e o Jazz foi construído usando o Jazz!). Colleen Arnold da IBM Services também declarou que já está em andamento o processo de transformação cultural para adoção de agile nas divisões de serviços. Scott Ambler, Erich Gamma, entre outros são líderes nesse processo de transformação dentro da IBM. Eles estão mentorizando equipes IBM ao redor do mundo no uso de desenvolvimento ágil com escala.

Creio que esse é mais um dos exemplos de uma gigante de software e de serviços ligados a Tecnologia da Informação que estão embarcando no uso global dos processos ágeis.

O segundo ponto importante, relacionado ao novo produto Rational Team Concert, é que agora temos uma forma ainda mais simples de obter agilidade com governança. Há muita gente que ainda acredita que existe uma dicotomia entre agilidade e governança, o que é um mito. Já tratei desse assunto em um artigo no meu blog.

Com a ferramenta Rational Team Concert podemos dizer que essa realidade da agilidade com governança se tornou ainda mais simples de atingir. Sua idéia é de ser uma robusta ferramenta de ALM (Application Lifecycle Management) colaborativa. A palavra colaboração aí é a grande novidade dentro desse novo produto. Além disso, o RTC possui um fantástico recurso que, feita a configuração e customização do processo, faz com que a equipe tenha (isso mesmo, seja obrigada!) que realizar atividades (work items) do processo que foram definidas como obrigatórias para poder continuar o seu trabalho. A ferramenta não só lembra as tarefas, como também obriga o time a realizar aquelas fundamentais. Mas é importante reforçar: a ferramenta pode ser configurada para apenas lembrar quais são as tarefas e não obrigar os times a fazê-las. Esse recurso é útil para empresas que precisam seguir padrões de governança como SOX, Cobit, etc e desejam definir atividades de compliance como obrigatórias dentro do processo. Mas todas as atividades podem ser opcionais, se assim for o desejo da equipe e/ou empresa!

O RTC também conta com um sistema de controle de incidências integrado com controle de versões, wiki, sistema de integração contínua e um servidor portal que gera as mais diversas métricas, relatórios e informações executivas sobre os projetos. É o nirvana dos desenvolvedores e gerentes de projeto!

E, se não bastasse, mais uma outra ótima informação para a comunidade ágil. O Rational Team Concert já vêm com dois processos pré-definidos na "caixinha": são eles o Scrum e o OpenUP. Além é claro da flexibilidade que o RTC fornece para a equipe configurar seu próprio processo.

Posso resumir então os principais toques e insights dessa conferência em:

1 - A IBM, como todas as outras gigantes produtoras de software, já embarcaram e entraram de cabeça no mundo do desenvolvimento ágil... só falta você :-) .

2 - O lançamento oficial do Rational Team Concert eleva a um novo patamar a necessária integração entre Agilidade e Governança. A governança agora pode existir sem muitos empecilhos e burocracia, graças à automação proporcionada pela ferramenta.

Com certeza, duas grandes notícias para a indústria de Tecnologia da Informação do Brasil e do mundo!

Futuramente escreverei artigos descrevendo em mais detalhes as mais importantes funcionalidades do Rational Team Concert e como estas auxiliam na adoção de processos ágeis no desenvolvimento de software.

Os doze passos para desenvolver software altamente eficaz

Lendo o livro Dreaming in Code, encontrei uma referência muito interessante para o chamado Joel Test.

Joel Spolsky, um grande desenvolvedor de software. Ex-Microsoft e que possui agora uma companhia que produz uma inovadora ferramenta de gestão de incidências chamada FogBugz.

Ele fez uma lista com 12 passos para medir se um time é bom ou não. O time ganha um ponto para cada passo que possui. 12 é um score perfeito, 11 é tolerável. 10 ou menos e você tem problemas. Segundo ele, que também é um prolífico autor e pesquisador na área de desenvolvimento de software, a verdade é que a maioria das organizações de software possui um score de 2 ou 3!

Aí vão os pontos essenciais:


1. Você usa controle de versões?

2. Você pode criar um build e sua documentação em somente um passo?

3. Você faz builds diários?

4. Você tem uma ferramenta de gestão de defeitos e incidências?

5. Você corrige defeitos antes de escrever código novo?

6. Você tem um cronograma e o mantém continuamente atualizado?

7. Você tem uma especificação?

8. Os programadores tem condições de trabalho tranqüilas?

9. Você usa as melhores ferramentas que o dinheiro pode comprar?

10. Você tem testadores?

11. Novos candidatos escrevem código durante a entrevista?

12. Você faz testes de usabilidade?

Seminário de gestão de projetos de software na FIAP

No dia 10 de maio de 2008, na FIAP, serei um dos palestrantes no seminário de gestão de projetos de software da Tempo Real Eventos.

Vou falar um pouco sobre o OpenUP e como ele pode ajudar as empresas a adotar um processo de desenvolvimento de software ágil e simples de utilizar.

Resumo da minha palestra:

OpenUP - A Abordagem ágil baseada no processo unificado

Tópicos

OpenUP: Origens
Princípios Fundamentais
Ciclo de Vida
Papéis
Artefatos
Gestão de projetos ágil com OpenUP
Aprendendo mais sobre OpenUP.

Pré Requisitos(para se tirar melhor proveito da apresentação): Conhecimento básico de Engenharia de Software.

Público Alvo: Gerentes de projeto, engenheiros de processos, analistas de qualidade, analistas de sistemas, desenvolvedores.

Disciplina de Construção de Componentes de Software no SENAC-SP

Lecionarei a disciplina de Construção de Componentes de Software I e II (20 aulas ao todo) na pós-graduação do SENAC-SP. Estou utilizando uma bibliografia novíssima e trabalhando no coração de como desenvolver sistemas realmente orientados a objetos. Além disso achei importante fornecer técnicas para manter código legado (veja a definição de código legado em meu artigo sobre qualidade interna do software), já que na maior parte do tempo estamos mantendo código existente e não construindo novos sistemas.

A seguir, os tópicos que serão vistos e também a bibliografia. Creio que o pessoal vai gostar bastante, já que percebo poucos ministrando disciplinas que abordam esses temas em profundidade. A idéia é elevar o patamar dos desenvolvedores e ajudá-los a compreender de uma forma didática os conceitos fundamentais e avançados da orientação a objetos. Também falar sobre princípios e práticas para se tornar um desenvolvedor mais eficiente e eficaz, um ás do código de qualidade :-) !

- Fundamentos do design emergente e a natureza do desenvolvimento de software
(Os exemplos de códigos da disciplina estão em Java e C# e eventualmente em C++, C e Visual Basic)

- Qualidades de um bom código OO através de exemplos
• Encapsulamento
• Coesão
• Acoplamento
• Redundância
• Testabilidade
• Legibilidade

- Patologias

- Princípios OO através de exemplos
• Separando uso da criação
• Single-Responsibility Principle
• Liskov-Substitution Principle
• Interface Segregation Principle
• Open-Closed Principle
• Dependency Inversion Principle
• Encapsulamento dos conceitos variáveis
• Dicas da GoF

- Práticas
• Estilo de codificação consistente
• Programação por intenção
• Encapsulamento de construtor
• Análise de Variabilidade

- Tranformando código procedural em código OO através de patterns (Parte 1)

- Tranformando código procedural em código OO através de patterns (Parte 2)

- Dicas para criar rotinas de alta qualidade

- Programação defensiva

- Processo de programação baseada em pseudocódigo

- Técnicas para uso de variáveis

- O poder dos nomes de variáveis

- Uso dos tipos de dados fundamentais

- Organizando código

- Idéias gerais para controle em código

- Usando condições

- Controlando Loops

- Métodos Table-Driven

- Layout e Estilo

- Código auto-documentado

- Técnicas para code tuning

- Medindo a qualidade interna do código

- Estratégias de Integração

- Técnicas de build e release

- Reuso Estratégico de Software e Asset-Based Development

- Testes unitários automatizados e Test-Driven Development

- Refactoring (Parte 1)

- Refactoring (Parte 2)

- Refactoring para Patterns

- Trabalhando com código legado (Parte 1)

- Trabalhando com código legado (Parte 2)

- Domain Driven Design

- Inversão de Controle e Injeção de Dependências – Exemplificado com Google Guice e Unity .NET DI

- MVC e MVC 2 para Web – Exemplificado com Struts 2

- Mapeamento objeto-relacional – Exemplificado com Hibernate e LINQ

- Persistência com o Pattern Transaction Script – Exemplificado com iBatis

- Bancos de dados orientados a objetos – Exemplificado com o db4o

- Trabalhando de forma iterativa com o banco de dados – Refatorando o banco de dados


Bibliografia Básica

1. Steve McConnell, Code Complete, 2nd Edition, Microsoft Press, 2004.
2. Martin Fowler, Refactoring, Addison-Wesley, 1999. (Complemento: http://www.refactoring.com)
3. Scott Bain, Emergent Design, Addison-Wesley, 2008.

Bibliografia Adicional

1. Robert Martin, Agile Principles, Patterns and Practices in C#, Prentice Hall, 2006.
2. David Astels,Test-Driven Development: A Practical Guide, Prentice Hall, 2003.
3. Lasse Koskela, Test Driven, Manning, 2008.
4. Alan Shalloway, Design Patterns Explained, 2nd Edition, 2004.
5. Floyd Marinescu, Domain Driven Design Quickly, 2006.
6. Gary Pollice, Head First OOAD, O’Reilly, 2006.
7. Eric Freeman, Head Fist Design Patterns, O’Reilly, 2004.
8. Craig Walls, Spring in Action, 2nd Edition, Manning, 2007.
9. Robbie Vanbrabant, Google Guice, Apress, 2008.
10. Gavin King, Java Persistence with Hibernate, Manning, 2007.
11. Clinton Begin, iBatis in Action, Manning, 2007.
12. Erik Hatcher, Ant in Action, 2nd Edition, Manning, 2007.
13. Paul Duvall, Continuous Integration, Addison-Wesley, 2007.
14. Chris Richardson, POJOs in Action, Manning, 2005.
15. Kent Beck, Implementation Patterns, Addison-Wesley, 2007.
16. Michael Feathers, Working Effectively with Legacy Code, Prentice-Hall, 2004.
17. Ian Roughley, Practical Apache Struts 2 Projects, Apress, 2007.
18. Jimmy Nilsson, Applying DDD and Patterns with Examples in C#, Addison-Wesley, 2006.
19. Martin Fowler, Patterns of Enterprise Application Architecture, Addison-Wesley, 2002.
20. Scott Ambler, Refactoring Databases, Addison-Wesley, 2006.
21. Joshua Kerievski, Refactoring to Patterns, Addison-Wesley, 2004.
22. Joe DeCarlo et al., Strategic Reuse with Asset-Based Development, IBM Redbooks, 2008.

Metodologias Ágeis - Seminário na PUC-SP

Vou iniciar uma nova disciplina, no formato de seminário, na pós-graduação em Engenharia de Software da PUC-SP. Ela terá como objetivo detalhar os principais processos de desenvolvimento de software ágeis, bem como ensinar como planejar projetos ágeis e iterativos. Depois colocarei algumas das apresentações no meu site pessoal Erudio.

Os tópicos abordados em cada uma das dez aulas são:

Aula 1 - Waterfall and Iterative Game (dinâmica)
Aula 1 - Introdução, o manifesto ágil, processos iterativos versus cascata, motivação para adoção
Aula 2 - Scrum e XP
Aula 3 - OpenUP e RUP
Aula 4 - RUP Game (dinâmica)
Aula 5 - Planejamento de projetos ágeis e iterativos – parte 1
Aula 6 - Planejamento de projetos ágeis e iterativos – parte 2
Aula 7 - Estratégias de automação para projetos iterativos e ágeis (ferramentas e abordagens)
Aula 8 - Test-Driven Development e Programação por Intenção – parte 1 (Laboratório)
Aula 9 - Test-Driven Development e Programação por Intenção – parte 2 (Laboratório)
Aula 10 - XP Game (dinâmica)

Qualidade interna e externa de um software e seu código: Como garantir a entrega de um projeto de software com um bom nível de manutenibilidade

Na vasta maioria de projetos de software requisitados para fornecedores internos (o próprio departamente de TI) ou externos (consultorias e fábricas de software), podemos notar que os principais itens de performance medidos são o prazo de entrega e o custo. Conforme nos mostra Robert Austin magistralmente, no seu livro “Measuring and Managing Performance in Organizations”, medir um sistema complexo através de poucas métricas o torna disfuncional e gera efeitos contrários aos pretendidos.

Quando se mede a performance de um projeto de software apenas por seu custo e prazo nota-se um comportamento disfuncional clássico: como o gerente de projeto e os membros da equipe só serão medidos pela velocidade de entrega, então tudo é feito às pressas e usualmente sem a atenção devida a um bom design, a testes unitários e funcionais e a refatorações constantes. Sem esses cuidados, o sistema costuma entrar com um número de defeitos acima do desejado e ainda se torna um código legado desde sua entrada em produção. Essa medição de performance também faz com que os níveis gerenciais demandem mais de 40 horas semanais dos profissionais (muitas vezes sem o devido pagamento de horas extras), o que ainda gera uma degradação de moral da equipe e um turn-over mais alto na empresa.

Como então podemos obter um bom código, que não vire legado assim que é entregue para a equipe que irá mantê-lo? Primeiro vamos definir o que é um código legado, o que é um código bom e o que significa o requisito não-funcional de manutenibilidade.

Quando se fala a palavra código legado, na cabeça dos desenvolvedores surge uma visão de código impossível de entender, estruturalmente complexo, cheio de condições encadeadas, código macarrônico e métodos com centenas e até milhares de linhas de código! Segundo Michael Feathers (em seu livro “Working Effectively with Legacy Code”) código legado é aquele difícil de entender e, consequentemente, difícil de alterar para implementar novas funcionalidades ou corrigir defeitos. Mas, segundo ele, a definição mais importante é: código legado é código sem testes unitários automatizados. Essa definição radical e inusitada nos mostra a importância de uma suíte de testes unitários para manter a sanidade do código e nossa coragem de fazer modificações quando necessárias. Sem testes os desenvolvedores adotam a postura de não mexer em código que “não é deles”, por medo de gerar defeitos. Também não fazem modificações estruturais para manter o código coeso e com baixo acoplamento, especialmente quando incluem novas funcionalidade. Portanto, sem testes unitários é difícil dar manutenção evolutiva e corretiva no código e mantê-lo bom, evitando que se torne legado e complexo.

Nossa próxima definição é sobre código bom. Essa é uma definição mais complexa. Gosto muito do termo inventado por Kent Beck: “code smell”. O “mau cheiro” em código é um sintoma de que algo está errado. É uma indicação de que o código precisa ser refatorado ou o design deve ser reexaminado. Alguns “maus cheiros” clássicos são (acesse a taxonomia de maus cheiros, caso queira mais detalhes):

• Métodos longos - esse tamanho pode variar, mas algumas pessoas consideram que um método com mais de 50 linhas de código já é um método longo (alguns mais puristas chegam a dizer que um método deve ter no máximo 10 linhas!). Veremos adiante no artigo que a complexidade ciclomática pode nos ajudar a obter um indicador mais preciso.

• Classes grandes e complexas - normalmente as que não seguiram o princípio de alta coesão
• Classes com intimidade com muitas outras classes - as que não seguiram o princípio de baixo acoplamento
• Classes preguiçosas – que não fazem muita coisa ou são executadas com pouca freqüência
• Código duplicado – essa é uma das maiores pragas que devem ser combatidas... rs.

E o requisito não-funcional da manutenibilidade? Bom, esse é, como qualquer requisito não-funcional, fundamental para uma definição da arquitetura de um software. É a facilidade de manutenção para inclusão de novas funcionalidades, correção de defeitos e alterações de regras de negócio. Esse requisito é fundamental para qualquer sistema que venha a ter uma vida útil longa em produção e que sofrerá contínuas modificações. Clientes e outros stakeholders não costumam falar claramente “esse sistema deve durar 10 anos em nossa empresa, é crítico e terá um número grande de requisitos novos mensalmente”. Por isso a manutenibilidade deve ser questionada claramente para os stakeholders. Alguns dizem que não se deve preocupar com manutenibilidade se o código durar pouco tempo. Tome cuidado, porque a tendência de todo código criado é a de continuar sendo usado por tempos razoáveis. Portanto, desconfie se disserem que o sistema ficará pouco tempo em produção. Nem sempre o cliente sabe tudo (vide o livro “O Dilema da Inovação” de Clayton Christensen para detalhes desse fenômeno no mundo dos negócios) !

Agora o problema: tendo em vista que sabemos a importância de se obter um código bom, não legado e com alta manutenibilidade, como medir isso em um fornecedor (interno e/ou externo) e como garantir que essa qualidade existe? Aí vão algumas dicas.

A primeira parte é a mais fácil: medições de código. Hoje temos várias ferramentas (neste artigo estou focando em ferramentas para Java, mas saibam que também existem similares para .NET e outras plataformas) que ajudam em 80% do esforço de detectar problemas. Vamos a algumas delas para exemplificar:

• Usar JUnit para fazer os testes unitários automatizados e, desse modo, não deixar o código virar legado conforme definição do Feathers. Como um cliente pode medir se os testes unitários estão sendo feitos e se são relevantes? Uma forma muito boa é medir a cobertura de código (de linhas e de desvios) realizada pelos testes unitários. Para isso é possível usar uma ferramenta open source como o Cobertura ou uma ferramenta como a embutida no Rational Application Developer.
• Usar uma ferramenta como o JavaNCSS para contar a quantidade de linhas de código e a complexidade ciclomática por método. Com essas métricas pode-se analisar se o código de cada método está complexo demais e se deve ser quebrado para manter a coesão. É possível usar uma ferramenta como o crap4J para tirar métricas combinadas entre cobertura de código e complexidade ciclomática.
• Usar uma ferramenta de análise estática de código como o PMD ou a embutida no Rational Application Developer para avaliar regras básicas de código. Essa é uma ferramenta essencial e que deve ser utilizada antes de qualquer inspeção formal feita por desenvolvedores. Ela irá pegar erros básicos que forem configurados. Ela detecta falhas como:
• Métodos longos
• Nomes de variáveis e métodos curtos
• Nomes de variáveis que não começam com letra minúscula
• Identação de chaves
• Quantidade excessiva de parâmetros
• Acoplamento entre objetos
• Aninhamentos grandes de ifs e elses
• Densidade de switch
• Código não utilizado (variáveis, parâmetros, métodos, etc)
• Usar a ferramenta CPD (Copy/Paste Detector) para identificar código duplicado e passível de refatoração.
• Usar uma ferramenta de análise de dependências de código orientado a objeto como o JDepend ou o Rational Software Architect (com sua capacidade de descoberta arquitetural e detecção de antipatterns arquiteturais).

Todas as ferramentas acima podem ser executadas através de um simples comando do Ant, após feita a configuração correta. Isso pode ser ainda colocado para executar dentro de um servidor de integração contínua, que pode enviar relatórios diários por email do status das métricas de código.

Além de medir o código usando ferramentas, sempre faça auditorias em cada uma das versões entregues (lembre que ferramentas garantem 80% dos casos, normalmente os mais típicos). As ferramentas não excluem o uso de bons desenvolvedores inspecionando formalmente código. Segundo McConnell, no livro “Code Complete”, de 45 a 70% dos defeitos de um código são removidos quando este passa por uma inspeção formal de desenvolvedores experientes.

Agora vamos à parte que dará mais trabalho (em termos de negociação e possíveis conflitos): como garantir essa qualidade de seu fornecedor? A resposta: estabeleça um SLA (Acordo de nível de serviço) para cada parâmetro importante discutido na primeira parte (métricas). Pode-se definir, por exemplo:

• Uma complexidade ciclomática de até 15 como aceitável, de 16 a 30 como aceitável se o fornecedor justificar de forma admissível ou inaceitável quando maior que 30.
• Uma cobertura de linhas de código de 80% como aceitável. Abaixo disso é inaceitável e acima disso é bônus.
• Regras definidas pelo cliente nas ferramentas de análise estática de código devem ser todas seguidas. Não deve aparecer nenhum erro.

Com base nisso pode-se elaborar penalidades no caso do fornecedor não estar dentro do SLA e bônus por ultrapassar os limites aceitáveis do SLA.

È possível também elaborar SLAs para que o fornecedor realize testes funcionais automatizados e testes de performance automatizados. Testes automatizados são mais garantidos porque podem ser executados para confirmar se foram feitos (diferentemente de casos de testes manuais) e ainda se tornarão um ativo de sua empresa, pois serão usados como testes regressivos. Um mínimo de testes funcionais automatizados (nem que sejam apenas os chamados "smoke tests") deve ser requerido.

Com essas técnicas você pode sair da situação da figura abaixo:

Para entrar numa situação bem melhor como essa:

E uma dica: se o seu fornecedor questionar e dizer que terá que aumentar o custo por causa disso, pergunte a ele: como você fazia então para garantir a qualidade e manutenibilidade de seu código sem essas métricas? Ou não fazia? Provavelmente o fornecedor que faz essa colocação não terá uma boa resposta verdadeira.

Outra dica: se o seu fornecedor se diz “agile”, não aceite apenas que haja entregas durante iterações curtas. Isso é apenas um lado (também importante). Exija a qualidade acima para realmente provar a agilidade do fornecedor. Processos ágeis primam muito pela qualidade interna e externa do código. Esse aviso é importante pois já pode-se notar no mercado o que costumam chamar de empresas “pseudo-agile”. São aquelas que dizem que praticam Scrum e XP, mas na verdade praticam mesmo a codificação caótica e indisciplinada, tudo que processos ágeis não são.

Por que estou dando essas informações valiosas? Porque acredito que, se os clientes foram mais exigentes com seus fornecedores de software, então todo o país terá a ganhar. Formaremos profissionais de maior qualidade, que geram um produto (código) de maior qualidade e aí poderemos competir no mercado externo com outros profissionais não apenas nos termos de custo e sim da qualidade do trabalho. Mudaremos de uma estratégia de oceano vermelho de custo para uma estratégia de oceano azul da diferenciação.

Portanto relembrando para o cliente: elabore contratos que demandem entregas curtas (desenvolvimento iterativo) com qualidade interna e externa medida por ferramentas, pessoas e SLAs. Vamos melhorar juntos o nível de qualidade dos nossos produtos!

Dando uma dica para fornecedores: Sejam pró-ativos e ofereçam esse tipo de contrato para seus clientes. Mudem suas estratégias de desenvolvimento e ofereçam qualidade com agilidade. Gerem benefícios de valor agregado, antes que seus concorrentes o façam!

Aguardo comentários de vocês sobre esse artigo. É sempre bom dialogar com os leitores do meu blog!

Em um próximo artigo vou tratar da situação onde você tem um sistema legado, com código "mal-cheiroso", e quer melhorar sua qualidade interna para continuar incluindo novas funcionalidades. Vamos mostrar técnicas para melhorar a manutenibilidade de sistemas já existentes (um problema que muita gente tem hoje na nossa área!).

Planejamento ágil - reuniões para definição de releases e iterações

Na lista de discussões scrum-brasil surgiram algumas dúvidas relativas a aspectos do processo de planejamento de releases (versões) e sprints (ou iterações).

Dúvidas:

1 - Na reunião de planejamento de um release, se o time não se sentir confortável com suas estimativas em pontos, o time pode já quebrar as estórias em tarefas - e estimar essas tarefas em horas ?

2 - Na reunião de planejamento de sprints ou iterações, é necessário que todas as tarefas sejam atribuídas a algum membro já na ? Ou podemos apenas atribuir um conjunto inicial pequeno de tarefas e depois a medida que as tarefas forem sendo encerradas, o membro escolhe qualquer tarefa que ainda não tenha "dono"?

Minhas respostas (lembrando que essas dicas valem para os principais processos ágeis como Scrum, Extreme Programming, Crystal Clear e OpenUP):

1 - A estimativa em pontos é feita no Release Planning. Se no Release Planning eles não se sentem confortáveis para estimar uma estória ou item isso pode significar que: 1 - a estória é muito grande; 2 - Há muitas dúvidas e pontos nebulosos.

2 - As tarefas (tasks) não precisam ser TODAS distribuídas nessa reunião. Elas precisam ser estimadas, mas não alocadas a desenvolvedores específicos. Usualmente os desenvolvedores selecionam uma ou, no máximo, duas tarefas para iniciar a iteração. Essa alocação de tarefas continua ocorrendo, usualmente nos daily stand-up meetings (reuniões diárias em pé). Lembrando que são os desenvolvedores que se alocam nas tarefas. Eles não são alocados por alguém de nível gerencial.

As tarefas não devem ser distribuídas pela equipe durante a reunião de planejamento do sprint por um simples motivo: fazendo isso você está achando que identificou todas as tarefas da iteração e isso não será nunca realidade. Novas tarefas aparecem. Tarefas existentes precisam se dividir em duas ou mais, etc. O modelo comando e controle não ocorrerá porque os próprios desenvolvedores escolherão quais tarefas farão durante os daily stand-up meetings e APENAS após terem completado uma tarefa anterior.

Para corroborar ainda mais minha afirmação cito o excelente e crucial livro "Agile Estimating and Planning" (recomendo a todos que estejam usando Scrum, XP, OpenUP ou outro processo ágil que contenha Release Planning e Iteration Plannings que leiam o livro. Diria até que é leitura obrigatória!!!) do Mike Cohn:

Subtítulo "Tasks are not allocated during iteration planning" na página 147 capítulo 14: "Enquanto se planeja a iteração, tarefas não são alocadas a indivíduos específicos. No início da iteração, pode parecer óbvio quem irá trabalhar em uma tarefa específica. Porém, baseado no progresso de todo o time no conjunto das tarefas, o que é óbvio no início pode não ser o que acontece durante a iteração. Indivíduos não escolhem as tarefas em que vão trabalhar até que a iteração inicie e geralmente só escolhem uma ou duas tarefas relacionadas por vez. Novas tarefas não são iniciadas até que as previamente selecionadas sejam completadas. Não há nada a ganhar e muito a perder ao alocar indivíduos a tarefas específicas durante o planejamento da iteração."

Resenha do livro Head First Software Development da O'Reilly

O livro Head First Software Development, da O'Reilly, segue o mesmo padrão de conteúdo da série Head First: uso de imagens, análise de exemplos reais e simulados para ajudar no entendimento dos tópicos considerados, utilização de exercícios como: palavras cruzadas, preenchimento de lacunas, sessões de perguntas e respostas. Tudo com o intuito de reforçar conceitos estudados em um capítulo.

O livro possui uma meta ousada: Ensinar melhores práticas, técnicas e princípios para um ótimo processo de desenvolvimento de software e mostrar como é o ciclo de vida do desenvolvimento de software.

Os autores optaram claramente por demonstrar neste livro uma abordagem ágil para o desenvolvimento de software. O grande diferencial do livro é seu aspecto lúdico e divertido, o que facilita a leitura.

A seguir o conteúdo de cada capítulo:

1. Great Software Development
2. Gathering Requirements
3. Project Planning
4. User Stories and Tasks
5. Good-enough Design
6. Version Control
7. Testing and Continuous Integration
8. Test-Driven Development
9. Ending an Iteration
10. The Next Iteration
11. Bugs
12. The Real World
Appendix A. Leftovers
Section A.1. #1. UML class diagrams
Section A.2. #2. Sequence diagrams
Section A.3. #3. User stories and use cases
Section A.4. #4. System tests vs. unit tests
Section A.5. #5. Refactoring
Appendix B. techniques and principles
Section B.1. Development Techniques
Section B.2. Development Principles

É interessante notar que também existe um bom tratamento sobre as ferramentas básicas para a montagem de um bom ambiente colaborativo de desenvolvimento nos capítulos 6 e 7. No capítulo 5 encontramos uma breve exploração de conceitos relacionados a design (projeto) e refactoring de software.

Eu, particularmente, já conhecia todas as técnicas mostradas por eles e que são tratadas em diversos outros livros sobre processos ágeis. Recomendo fortemente para pessoas que querem conhecer mais sobre desenvolvimento ágil (e ainda possuem muitas dúvidas) e também para profissionais experientes que desejam ler um livro com uma abordagem mais interessante e diferenciada.

O livro também é muito recomendável para uso em disciplinas de Engenharia de Software, Processos de Desenvolvimento de Software e em treinamentos de métodos ágeis. Seus fortes aspectos didáticos auxiliam no entendimento de todos os tópicos abordados, seus relacionamentos e sua importância para o desenvolvimento de softwares.

Uma Introdução ao OpenUP na revista Visão Ágil

Escrevi um artigo na terceira edição da revista Visão Ágil com uma introdução ao OpenUP. Basta acessar a terceira edição da revista e buscar pela matéria na página 25.

O texto inicia assim:

"OpenUP é um processo enxuto, baseado no 'Unified Process', que possui um ciclo de vida iterativo e incremental. O OpenUP também foi elaborado como uma filosofia ágil, pragmática e que foca na natureza colaborativa do desenvolvimento de software. É um processo de baixa cerimônia e que não indica nenhum tipo de ferramenta específica. Uma das características visíveis do OpenUP é que a disciplina de gestão de projetos é uma adaptação do Scrum (processo ágil empírico com foco nos aspectos de gestão de projetos, sem entrar em detalhes da engenharia de software).

O OpenUP possui princípios (isto é, se você não seguir um dos princípios você não está na realidade adotando o processo como se deve) semelhantes à versão 7 do RUP. Eles são:

● Balancear prioridades competidoras para maximizar o valor aos envolvidos do projeto.
● Colaborar para alinhar interesses e compartilhar entendimento.
● Focar cedo na arquitetura para minimizar riscos e organizar o desenvolvimento.
● Evoluir para continuamente obter feedback e melhorar.

O OpenUP pode ser mais facilmente entendido através dos seus ciclos de visibilidade. Vamos falar sobre cada um deles separadamente, na seqüência do ciclos mais curto até o ciclos mais longo, para dar uma visão clara de como é a vida em um projeto OpenUP...".

Certified Scrum Master: Treinamentos em Janeiro de 2008 no Brasil

Para quem tiver interesse em fazer o treinamento de Scrum e se tornar um Certified Scrum Master aí vai a dica.

Nos dias 21 e 22 de janeiro de 2008 haverá o treinamento CSM em São Paulo.

Nos dias 24 e 25 de janeiro de 2008 haverá o treinamento CSM em Recife.


Não percam, pois o instrutor Boris Gloger é excelente!!! Quem quiser ter uma idéia sobre algumas das atividades que ocorreram no treinamento de Scrum Master, pode visitar meu artigo com impressões sobre o treinamento CSM no Brasil.

Agilidade e Governança: Um falso dilema

Existe uma percepção de que não é possível ter governança de TI ao usar um processo de desenvolvimento de software ágil. Em um próximo artigo resumirei minhas idéias sobre o assunto e mostrarei como isso é uma falácia. Agora pretendo apresentar links de artigos de um mestre. Assim aquilo que eu já sabia se torna ainda mais embasado :-) .

Leia com atenção os seguintes artigos de Scott Ambler (lembrando que ele é um dos evangelistas da IBM Rational e, portanto, está guiando a Visão de produtos e processos da IBM):

Governança no desenvolvimento ágil de software

Melhores práticas para governança de equipes ágeis

Melhores práticas para a governança enxuta de desenvolvimento: Parte 1

Melhores práticas para a governança enxuta de desenvolvimento: Parte 2

Melhores práticas para a governança enxuta de desenvolvimento: Parte 3

Ágil com preço fechado

As terríveis consequências do uso de projetos de preço fixo em TI

PodCast de José Papo sobre RUP e OpenUP

RUP pode ser ágil - Podcast e explicação abaixo produzidos por Vinícius Teles

RUP pode ser ágil, ao contrário do que muitos acreditam. Isso é que nos explica José Paulo Papo no Improvecast número 20. José Papo trabalha com implantação de processos e gerência de projetos. Além disso, é professor de Engenharia de Software, de Lógica de Programação e de RUP e OpenUP.

Um dos destaques desse podcast foi a evolução do RUP nos últimos anos, no sentido de adotar princípios alinhados com os do Manifesto Ágil. Outro assunto interessante é o surgimento do OpenUP. Conversamos também sobre os seguintes assuntos:

Como e quando foi seu primeiro contato com abordagens ágeis de desenvolvimento de software?
O que mais chamou sua atenção nessas abordagens?
Que tipo de problemas você tinha antes de adotar tais abordagens?
Que tipo de uso prático você vem fazendo das metodologias ágeis atualmente? Você utiliza alguma ou algumas delas em seu trabalho?
Que práticas ágeis você mais utiliza atualmente?
Quais você considera mais fáceis?
Quais são as mais difíceis?
O que é o OpenUP?
Como você enquadra o OpenUP em relação às metodologias ágeis de desenvolvimento de software?
Na sua atuação como professor universitário, você ensina abordagens ágeis de desenvolvimento?
Pelo que você tem observado, as universidades estão começando a ensinar metodologias ágeis, ou ainda estão baseadas apenas nos modelos tradicionais de desenvolvimento de software?
Como você está vendo a evolução da adoção de métodos ágeis aqui no Brasil?
Quais são seus planos para o futuro, na área de desenvolvimento ágil?

Novas ferramentas livres para gestão ágil de projetos: Mingle e ProjectKoach

Duas novas ferramentas para gerenciamento ágil de projetos foram lançadas no mercado.

A ferramenta ProjectKoach é uma ferramenta leve e gratuita feita especialmente para gerenciar projetos usando o processo OpenUP 1.0. Com a ferramenta ProjectKoach você pode:

- planejar projetos
- gerenciar iterações
- Medir a velocidade da equipe
- Rastrear itens de trabalho a requisitos e outros itens
- Integração com o processo OpenUP e facilidades de editar o processo e alterar também a ferramenta automaticamente
- Guias de processo para analistas e desenvolvedores, que explicam em detalhes as tarefas alocadas.

A única funcionalidade que eu acho que ainda é necessária na ferramenta é a integração com ferramentas de controle de versões como Subversion, CVS, IBM Rational ClearCase, etc.

Vide abaixo uma figura da tela principal da ferramenta:


Faça o download do ProjectKoach e experimente a ferramenta! Você precisa apenas de um JDK do Java. Ela pode se tornar um excelente apoio ao seu projeto e, ainda melhor, sem custo!!!

A ferramenta Mingle foi desenvolvida pela famosa consultoria de projetos ágeis americana ThoughtWorks. Ela é gratuita para até 5 usuários. A partir do sexto usuário deve ser paga uma taxa de licenciamento conforme a tabela de preços.

A ferramenta Mingle está atualmente bem mais completa que o ProjectKoach, porém tem um custo após o sexto usuário. Ela inclusive possue integração com ferramentas de controle de versões e integração entre requisitos, casos de teste, defeitos e riscos.

Uma outra excelente funcionalidade é a capacidade de visualizar os requisitos e tarefas no Mingle como cartões na tela. Vide a imagem de exemplo abaixo:


Faça o download do Mingle e experimente a ferramenta! Você precisa ter o banco de dados MySQL 5 instalado.

OpenUP 1.0 finalmente lançado!!!

O OpenUP 1.0 foi finalmente lançado oficialmente no dia 01 de agosto de 2007. É recomendável que todos passem a usar a nova versão, que corrigiu e fechou cerca de 416 defeitos e requisições de mudança.

Faça o download da biblioteca de métodos e do site do OpenUP 1.0.

Caso você queira apenas navegar no site do OpenUP 1.0, a equipe do EPF disponibilizou-o em um wiki.

Scrum para manutenção de sistemas

Este artigo contém uma resposta a uma dúvida enviada para a lista CMM-Brasil.

Dúvida:

"Aqui na empresa temos uma suite de produtos para a área Contábil / Depto Pessoal / Fiscal. Não desenvolvemos novos produtos. O que fazemos, é dar manutenção corretiva (qdo necessária), e na maior parte das vezes manutenção evolutiva, visto que os softwares devem se adequar às legislações municipais, estaduais e federais.Trabalhamos com um repositório de solicitações de novas implementações ou manutenções em funcionalidades já existentes. Estipulamos um prazo em torno de 40 dias para contemplar algumas solicitações acordadas em reuniões de planejamento, e no fim, geramos uma nova versão do produto e encaminhamos à nossos clientes.Nem sempre as solicitações acordadas no começo do planejamento são concebidas na versão do produto, pois no meio do caminho novas solicitações mais importantes (como falhas do sistema) acabam entrando e consumindo o tempo necessário para as outras solicitações.Alguém aqui do grupo trabalha neste mesmo esquema? Quais metodologias são mais indicadas para este cenário?

Iniciamos, sem muito sucesso a implantação do CMMI nível 2 no ano passado. Definimos e institucionalizamos o processo e a política de REQM, treinamos os profissionais, mas em algumas equipes o uso no dia a dia do processo definido não foi bem aceito. Acredito que pelo fato de requisitos entrarem, saírem ou serem alterados a todo instante do "sprint" de 40 dias, o processo tenha se tornado muito burocrático e pouco dinâmico.Citei equipes pelo fato de cada equipe trabalhar com um sistema específico, exemplo: Equipe A só trabalha com sistema de Folha de Pagamento, Equipe X só com sistema de Contabilidade .. e assim por diante.Alaguem tem algum comentário a fazer sobre isso?"

Minha resposta:

Um processo excelente para trabalhar nesse formato da empresa onde você está é o SCRUM. Ele lida exatamente com essas questões de gestão de backlog de produtos. No Scrum o spint é definido como sendo de 30 dias. Porém pode-se variá-lo de uma semana até 6 semanas.

O Scrum tem uma regra clara para permitir uma organização mínima do backlog e manter a sanidade da equipe: JAMAIS pode haver mudanças de prioridades durante uma iteração ou sprint. Mas, caso seja imprescindível alguma alteração, então o SCRUM dá uma alternativa: cancela-se o sprint atual e refaz TODO o planejamento de um novo sprint. É crucial deixar claro para os stakeholders do projeto que, desse modo, parar uma sprint só deve ocorrer em casos extremos.

No seu caso talvez seja melhor também, para reduzir o número de alterações de requisitos vindos dos stakeholders durante um sprint, reduzir o tempo de um sprint entre outro. Tente fazer a empresa e a equipe ser mais ágil. Que tal, por exemplo, reduzir seus sprints de 40 dias para 20 dias?