Pai dos Casos de Uso diz: Agile precisa ser mais Smart

Na conferência Software Education SDC em Melbourne - Austrália e Wellington - Nova Zelândia, no mês passado, Ivar Jacobson, autor do trabalho original sobre Casos de Uso, a Unified Modeling Language (UML) e o Rational Unified Process (RUP), disse que o desenvolvimento Ágil precisa “ser mais Smart”.

Ele afirmou que a indústria de tecnologia da informação está muito pendente da moda, tendo uma tendência para se apoderar das balas de prata e listou os seguintes exemplos:

• Quinze anos atrás era tudo sobre OO
• Dez anos atrás era sobre componentes, UML, Unified Process
• Cinco anos atrás era sobre RUP e CMMi
• Dois anos atrás era sobre XP
• Hoje é sobre Scrum

Todos tem bons elementos – mas nenhum deles é o que precisamos, o que nós precisamos é Trabalhar com mais Inteligência. Ele diz “Ser Smart é uma evolução de ser Ágil”:

• Agile significa ser flexível e adaptável
• Agile fornece pontos simples/leves
• Ser smart é saber quando ir além do agile
  • Saber o momento de seguir as regras e quando quebrá-las
  • Saber quando ser consistente e quando mudar
  • Saber quando crescer e quando encolher

De acordo com Jacobson “Smart é Agile++”. Ele continuou a dar exemplos de várias práticas e abordagens smart (e não-smart) que ele reconheceu ao longo dos anos. Algumas das práticas Smart e Não-smart que ele idenficou são:

• Unsmart com as pessoas – visualizar os processos e ferramentas como mais importante do que as pessoas
• Smart com as pessoas – reconhecer e entender que o software é construído por pessoas, não com processos e ferramentas!
  
  “Um tolo com uma ferramenta é ainda um tolo, mas um tolo perigoso”
  
• Unsmart com os Times – Os times organizados em grupos responsabilidades separadas (requisitos, análises, design etc)
• Smart com os Times – Cross funcional, pequeno (idealmente 10 ou menos pessoas) times auto-organizados com uma combinação adequada de habilidades para realizar o trabalho.
  
  “Um time de software é como um time de esporte com todas as competências necessárias para vencer”
  
• Unsmart com os Projetos – Tentar seguir uma abordagem waterfall
• Smart com os Projetos – Construir um “sistema magro” para demonstrar que você eliminou todos os riscos críticos e em seguida adicionou mais capacidades sobre o sistema magro conforme necessário.
  
  “Pense grande, construa em várias etapas”
  
• Unsmart com os Requisitos – Tentar definir todos os requisitos pela frente (uma constante em desenvolvimento de software é que os requisitos mudarão)
• Smart com Requisitos – Base precoce de decisões sobre requisitos leves e os detalhes de como e quando necessário – requisitos são negociáveis e as prioridades mudarão
  
  “Desenhe seu projeto para mudanças de requisitos”
  
• Unsmart com Arquitetura – sem arquitetura é tão ruim quanto tentar desenhar tudo antes do desenvolvimento
• Smart com Arquitetura – apenas a arquitetura o suficiente para construir o sistema magro, a arquitetura deve resultar em código executável
  
  “Começar a construir sistemas magros, mais tarde adicionar músculos em pequenos passos”
  
• Unsmart com Testes – ter dois tipos de pessoas – desenvolvedores e testadores. Os testadores de projetos unsmart são “os limpadores no mundo de software” – pegam a desordem deixada pelos desenvolvedores
• Smart com Testes – todo o time é co-responsável pela qualidade e os testadores são cidadãos de primeira-classe
  
  “O que você faz, não está feito até que você tenha verificado que você fez o que queria fazer”
  
• Unsmart com Documentação – preencher cegamente um template de documento só porque algumas regras de processo diz que isso tem que ser feito
• Smart com Documentação – reconhecer a “lei da natureza: as pessoas não lêem documentos”. Documente somente o que é absolutamente necessário
  
  “Foque no essencial – os espaços reservados para as conversas – as pessoas descobrem o resto por si próprias”
  
• Unsmart com Processo– continuamente se apoderando da última moda e tentando mudar tudo o que faz em resposta ao novo livro de regras
• Smart com Processo – Não jogue o bebê junto com a água da banheira:
  
  1. Comece com sua maneira existente de trabalhar
  2. Encontre os pontos a problemáticos
  3. Mude uma prática de cada vez
  
  “As pessoas não lêem livros de processo, para concentrar no essencial, as pessoas descobrem o resto por si próprias”

 O elemento chave para se tornar Smart é focar nas pessoas, como Jacobson diz e “isso tudo se resume a você”.