BT

Disseminando conhecimento e inovação em desenvolvimento de software corporativo.

Contribuir

Tópicos

Escolha a região

Início Notícias Pai dos Casos de Uso diz: Agile precisa ser mais Smart

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ê”.

Avalie esse artigo

Relevância
Estilo/Redação

Conteúdo educacional

BT