BT

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

por Shane Hastie , traduzido por Flávia Castro de Oliveira em 20 Abr 2009 |

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

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

Manifesto Ágil by Sérgio Monteiro

É normal as pessoas se aproveitarem de algo que está fazendo sucesso para redirecionar os holofotes para si. Tudo o que o Sr. Jacobson falou sobre "Ser Smart" já é praticado no mundo ágil pelos bons agilistas. Não vejo evolução ou inovação alguma no que disse e acrescento que a lista dele de Unsmart e Smart foi totalmente baseada no Manifesto Ágil. Aproveitando, o RUP na sua totalidade é Smart ou Unsmart? Hummm?

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

1 Dê sua opinião
Feedback geral
Bugs
Publicidade
Editorial
Marketing
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2016 C4Media Inc.
Política de privacidade
BT

We notice you’re using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.