Formando equipes de alto desempenho, parte 1: Início e fases de evolução
Nesta primeira parte de uma série sobre equipes de alto desempenho e gerenciamento Agile, veja uma introdução geral e uma apresentação dos estágios de formação das equipes.
Notícias
O conteúdo foi adicionado aos favoritos!
Houve um erro ao adicionar aos favoritos! Por favor, tente novamente.
Pai dos Casos de Uso diz: Agile precisa ser mais Smart
Postado 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ê”.
Manifesto Ágil
por
Sérgio Monteiro
Enviado
-
É 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?
1 comentário
Acompanhar Discussão Responder