Eliminando o verdadeiro ágil do buzzword ágil em uma entrevista [fechada]

14

Ultimamente, tenho entrevistado cooperativas (estágios remunerados) e um grande número de empresas com as quais tenho entrevistado afirmam que usam Scrum ou alguma outra metodologia ágil (o scrum é o mais popular). Eu sei que existem lojas reais ágeis e há lugares que dizem que usam uma metodologia ágil, mas estão realmente fazendo outra coisa e usando o ágil como palavra de ordem.

Minha pergunta é: quais são algumas das perguntas que posso fazer em uma entrevista que separariam essas lojas?

EDIT: Enquanto procuro um estágio, sinto que essas perguntas são relevantes para todos. A parte do estágio é um contexto.

indyK1ng
fonte
14
Hum, pergunte se eles são um porco ou uma galinha?
Robert Harvey
1
@Robert Lolwut?
Mateus Leia
@ indyK1ng 1. Você conhece alguma empresa que seja realmente ágil? 2. Na maioria das vezes, a metodologia deve ser ajustada à realidade para vice-versa. PS Eu concordo com a palavra da moda!
Amir Rezaei
2
@ Robert Eles devem responder: "Blá blá Agile. Blá blá blá. Paradigma blá blá."
Mark C

Respostas:

8

Eu sempre começo fazendo esta pergunta:

Qual é a duração de suas iterações?

Classifique a resposta deles:

1 semana é incrível, 2 semanas é ótimo, 3 está ok e 4 medíocre. Mais do que isso indica que eles estão lutando e mais de 8 semanas é apenas estranho. Se a resposta for depende , você sabe que eles não têm idéia alguma.

Acompanhamento com:

Com que frequência você libera?

Isso é para verificar a primeira pergunta. A resposta certa é diária ou final de cada sprint . Um agilista saberia que não deve haver diferença técnica entre uma versão interna e externa.

Martin Wickman
fonte
5
O padrão defacto é de 2 a 4 semanas. 1 semana de corrida ...? Hmm ... eu suspeitaria.
Aaron McIver
5
Não há "padrão"; varia entre empresas / equipes / situações. Acho que a sobrecarga do Scrum é, como uma proporção do comprimento do sprint, um desperdício demais para sprints de uma semana; portanto, usamos dois.
Christopher Christopher
1
Eu testei muitas durações diferentes e gosto de 1 em projetos muito pequenos em equipes pequenas, mas em projetos de grandes empresas, 3 ou 4 me deram melhores resultados.
3
Eu acho que são esses termos de "real" vs. "aguado" ágil que irritam minhas penas. Sempre apliquei os conceitos e princípios do Agile Manifesto, mas nunca usei uma das versões da marca do Agile. Insistir em apenas uma das muitas metodologias ágeis viola o primeiro princípio do manifesto. Mas eu entendo o que você está dizendo.
Berin Loritsch
2
Para mim, o "real" ágil é o ágil que aplica o manifesto e seus 12 princípios - independentemente do que é chamado. Existem muitas palavras-chave que aumentam o significado principal de ágil e afirmam que você não é ágil se não o fizer.
Berin Loritsch
6

Peça-lhes para defender metodologias ágeis. E então peça que refutem, descrevendo suas fraquezas. Pontos de bônus se eles puderem navegar neste curso sem jogar com chavões sem sentido.

Mark Canlas
fonte
4
+1 É sempre bom encontrar maneiras de entrevistar a empresa.
precisa saber é o seguinte
@ Jeremy, infelizmente, não aceitariam muito bem. Eu não recomendo!
Amir Rezaei 14/01
@Amir: Por favor, explique! Eu nunca saí de uma entrevista sem eles perguntando se eu tinha alguma dúvida. O que há de errado com o candidato a emprego que quer saber mais sobre a empresa? Se eles não aceitam bem, é um sinal claro de que não quero trabalhar para eles!
Jeremy Heiler
1
Sei que algumas empresas realmente não gostam quando o entrevistado não faz perguntas ... para elas isso mostra falta de interesse no trabalho.
Rachel
2
Eu acho que pedir para eles "defenderem metodologias ágeis" provavelmente não é o melhor método para perguntar;)
Matthew Leia
6

Pergunte a eles por que eles usam .

Você saberá imediatamente.

user2567
fonte
8
Isso pode ser respondido com muita facilidade, embora com respostas enlatadas. "Reduzir nosso tempo de comercialização e permanecer competitivos". Tem que ser uma abordagem mais para frente e para trás. Se o OP estiver familiarizado com o Agile / Scrum e quiser ter certeza de que os negócios também estão; Eu diria que o OP deveria ter muitas perguntas sobre o assunto ... especificamente o que os incomodava em um local de trabalho anterior e como os novos negócios poderiam resolver isso.
Aaron McIver
2
A resposta que você mencionou não pode ser dita por alguém que entende de agilidade. É uma boa indicação de que eles não sabem por que devem usar o scrum. Toda empresa tenta reduzir o tempo de colocação no mercado e permanecer competitiva. Se você me responder a pergunta, eu responderia "é a única metodologia adaptada ao desenvolvimento de software" ou "traz muita visibilidade sobre o que devemos melhorar".
@Pierre 303 Qualquer razão para sugerir por que, do ponto de vista comercial, a adoção do Agile era um processo que poderia aumentar nosso tempo de comercialização e permanecer competitivo com lançamentos oportunos de nosso software não é válido e definiria esse indivíduo como não sabendo por que usar Scrum? Você precisa entender que os gerentes de contratação nem sempre são tecnicamente inclinados, mas isso significa que o uso do Scrum na organização é em vão.
Aaron McIver 14/01
1
@Pierre 303 Você pode elaborar um pouco sua resposta? O motivo para usar qualquer método de desenvolvimento de software é "agregar valor o mais eficiente possível aos nossos clientes" e isso se aplica tanto ao RUP ágil quanto ao RUP e outros.
Martin Wickman
1
Concordo plenamente. Pergunte a eles por que eles escolheram o Agile. Sólido. +1
Agile Scout
5

Eu pediria que descrevessem o ciclo de vida de desenvolvimento de software ao usar a metodologia Agile. Se eles estão familiarizados com isso, devem ser capazes de descrever cada fase no SDLC com precisão.

EDIT : Acabei de perceber que você estava perguntando do ponto de vista do entrevistado, não do entrevistador. Nesse caso, eu provavelmente perguntaria a eles sobre seu SDLC e veria se as etapas que eles dizem que seguem correspondem ao que o Agile realmente é.

Rachel
fonte
Bom ponto sobre perguntar sobre SDLC. No entanto, eu estive na organização onde eles seguiram todas as etapas do SDLC, mas a equipe aplicou mal a metodologia.
Amir Rezaei
@Amir: Se fosse esse o caso, eu assumiria que eles estavam tentando seguir a metodologia ágil. As chances são de que eles tenham um bom motivo para se desviar dele ou não sabem o que estão fazendo e estariam dispostos a aprender se você dedicasse algum tempo para ensiná-los.
Rachel
Eles têm um bom motivo. Eles adaptam a metodologia à sua realidade.
Amir Rezaei
3

A abordagem adotada realmente tem pouco a ver com os chavões ágeis, mas tem a ver com práticas ágeis. Um dos pontos comuns em todas as equipes ágeis é a iteração curta, a maioria das pessoas recebe essa parte (é um dos 12 princípios por trás do ágil no site http://agilemanifesto.org ). O objetivo da iteração curta é obter feedback antecipado sobre a qualidade do software desenvolvido. É aqui que eu começo.

  1. Pergunte sobre o teste de unidade. Surpreendentemente, a resposta que recebi aqui foi "uh, cortamos isso porque não tivemos tempo suficiente" (nota: os dois primeiros sinalizadores de aviso - sem tempo e sem testes de unidade)
  2. Pergunte sobre quando o software foi testado e com que frequência. As respostas podem ser criativas aqui. Especialmente se a equipe usar "Agile" como uma desculpa para deixar todo o processo de lado. Se a resposta estiver no final do projeto, ou qualquer outra coisa que não seja a cada iteração, eles não saberão o que é ágil.

Até agora, não precisei ir além disso para saber que a pessoa não sabe o que é ágil. Também estive em apenas uma entrevista com uma empresa que já possuía processos ágeis bem estabelecidos.

Há mais de uma maneira de agir com agilidade, e eu me preocupo mais com os princípios de agilidade do que com qualquer marca ou palavra-chave específica.

Berin Loritsch
fonte
2

Existem várias coisas que separam aqueles que estão "agilizando" daqueles que são ágeis:

  • Pergunte sobre a integração contínua se eles não estiverem usando o IC deduzir um ponto. Adicione um ponto se estiver. Pontos extras:
    1. Adicione 1 se eles usarem confirmações em duas fases (o código deve ser criado com êxito antes que o desenvolvedor possa fazer check-in).
    2. Adicione 1 se o script de construção incluir a execução de um conjunto de testes
    3. Adicione 1 se a construção falhar se a cobertura do código ficar abaixo de um determinado limite
    4. Adicione 2 se for possível implantar o aplicativo para que esteja pronto para ser executado em um clique
  • Pergunte sobre TDD (desenvolvimento orientado a teste) subtraia 2 pontos se eles não usarem TDD e adicione 1 se usarem.
  • Pergunte sobre as iterações, quanto tempo elas são (subtraia 2 pontos se não fizerem o desenvolvimento iterativo, subtraia 1 se a iteração for maior que um mês ou menos de duas semanas, adicione 1 se for 2 semanas)
  • Pergunte como é feita a estimativa. Adicione 1 se eles usarem pontos da história, adicione 2 se eles planejam poker ou algo semelhante, subtraia um se usarem estimativas de tempo absoluto, subtraia 2 se os desenvolvedores não estiverem envolvidos no processo de estimativa.
  • Pergunte como os recursos são criados, adicione 1 se um desenvolvedor for responsável pelo recurso de cima para baixo (fatia vertical) subtraia 1 se os desenvolvedores são responsáveis ​​por uma camada específica (fatia horizontal)

Existem vários outros indicadores, mas somente esses devem fornecer uma boa imagem se a equipe realmente estiver ágil. Uma equipe com 5 pontos ou mais se qualifica. Qualquer outra coisa significa que eles estão "agilizando". O Agile não é apenas sobre iterações, é sobre permitir que a equipe se adapte às mudanças facilmente. Se você estiver escrevendo iterativamente código não testado e confuso, sob pressão externa, bem, você está apenas escrevendo código porcaria nas iterações. Observe que você pode obter muitos pontos apenas com o marcador de integração contínua. Mas isso por si só não é suficiente para trazer mais de 5, se você não estiver seguindo as outras práticas.

Michael Brown
fonte
1
"Pergunte sobre TDD (desenvolvimento orientado a teste) subtraia 2 pontos se eles não usarem TDD e adicione 1 se fizerem" não faz sentido. Basta adicionar 3 se o fizerem.
Cbrandolino
Entendo o que você está dizendo ... não simplifiquei minha fórmula ... mas acho que meu argumento é claro.
Michael Brown
1
O WTF tem CI e TDD a ver com o Agile? Claro, facilita a liberação, mas você realmente não precisa trabalhar de maneira ágil. E acredite, eu conheço empresas com TDD e CI que NÃO são ágeis.
Gbjbaanb
Somente o TDD e o CI não tornam um ambiente ágil. No entanto, a falta desses elementos é um sinal de alerta de que não há um verdadeiro compromisso de ser ágil.
Michael Brown
2

Como em todas essas coisas, você pede exemplos do mundo real de projetos nos quais eles trabalharam , não teoria. Aceitar respostas teóricas é a maneira mais fácil de ser enganado por alguém que realmente não esteve lá.

Então você pede para falar com desenvolvedores reais e pergunta coisas como:

  • Então me fale sobre seu projeto atual. Qual foi o objetivo final inicial? O que o primeiro sprint continha e o que o software poderia fazer no final dele?
  • Você pode me dar exemplos de funcionalidade ou design em seu último projeto que você acredita que funcionaram de maneira diferente do que você fez como um projeto em cascata?
  • Dê-me um exemplo de como uma grande parte da funcionalidade foi dividida em vários sprints? A que ineficiências / retrabalho isso levou? E que melhorias ou mudanças em relação ao inicialmente previsto.
  • Quando você começou a trabalhar com o Agile, que coisas que você estava fazendo durante os primeiros sprints mudou durante os sprints (ou projetos) posteriores à medida que se familiarizava com a metodologia?

Continue trazendo-os de volta aos projetos reais - o que eles estavam tentando alcançar, exemplos do que havia em cada sprint, exemplos dos tipos de coisas que surgiam nas reuniões, exemplos de interações com os usuários.

Não aceite a teoria, não aceite os projetos de outras pessoas, apenas coisas em que elas mesmas trabalharam e com as quais podem falar por experiência própria.

Eles teriam que ser um mentiroso incrivelmente bom para poder inventar de 10 a 15 minutos em coisas que passariam por você se você as conhecesse.

Jon Hopkins
fonte
2

Se você não quiser deixá-los na defensiva, descobri que a seguinte pergunta iniciará uma conversa que informará tudo o que você precisa saber sobre se eles estão realmente usando uma abordagem ágil ou apenas prestando atenção:

Quem é responsável por escrever requisitos / especificações para seus projetos de software?

Eu já vi várias empresas que afirmaram ser ágeis e até desejarem uma certificação Scrum Master descrever um grande processo clássico de design inicial quando você pergunta sobre o processo de coleta de requisitos.

JohnFx
fonte
2

O que me destaca é que você está procurando um estágio, o que me leva a pensar qual é o seu objetivo em fazer essas perguntas. Você está tentando fazer uma pergunta sobre o ágil para que a entrevista corra bem ou recusaria uma oferta de uma empresa usando o agile da palavra-chave? Se você está realmente procurando por um ambiente ágil, escolha uma pergunta (por que você usa o ágil, a que horas são os seus standups, por quanto tempo as iterações, o que quer que seja) e pergunte por telefone ou por email sem perder tempo com um entrevista. Se você estiver procurando por renda, aguarde a entrevista e faça perguntas que mostrem seu conhecimento / entusiasmo sobre metodologias ágeis (conte-me sobre seu ciclo de vida de desenvolvimento de software) sem embaraçar o entrevistador se ele estiver usando alguma abominação semi-ágil.

Marca
fonte
Essa é uma pergunta que eu faria durante a parte "Você tem alguma pergunta para mim" da entrevista. Estou fazendo uma pergunta para determinar se eles estão dizendo a verdade quando estão dizendo que são ágeis. Eu já estive em um ambiente de cowboy e gostaria de impedir que isso aconteça. Eu sei que existem organizações que usam o ágil como palavra de ordem, então estou tentando filtrá-las. Além disso, as entrevistas são nos dois sentidos, eu estou entrevistando a empresa enquanto eles estão me entrevistando.
indyK1ng
1

Peço que eles descrevam uma solicitação típica, desde o início até a entrega final ao cliente.

Também pergunto se eles geralmente lidam com suporte de longo prazo para o produto que fornecem ao cliente (porque as equipes que geralmente constroem um produto melhor, sabendo que será ele quem o consertará à 1 da manhã de domingo no fim de semana do Dia do Trabalho).

Também pergunto como a gerência vê seu papel durante o processo. É muito fácil ver se eles têm a atitude de disparar e esquecer (lançamos, voamos, perguntamos se atingimos o alvo) ou a atitude "ajudamos a remar o barco rio acima".

Isso geralmente mostra como eles realmente fazem as coisas, não como eles deveriam fazê-las ou como eles afirmam fazê-las.

Christopher Mahan
fonte
1

A melhor maneira que eu encontrei para ver se alguém sabe o que está fazendo da perspectiva do SDLC é perguntar a eles onde eles se enganaram no passado e como eles fariam isso de maneira diferente. As pessoas que já passaram pelo processo algumas vezes e admitem totalmente onde erraram, e geralmente são bastante detalhadas. A abertura para discutir mostra um nível de confiança, porque eles admitem que não são perfeitos. Evitar a pergunta dizendo "Eles sempre fazem bem o tempo todo", é um verdadeiro sinal de alerta.

kemiller2002
fonte
1

Quantas vezes eles lançam em produção. Quanto maior o tempo, menos ágil eles são. Quantas vezes eles têm oficinas de reflexão. Se eles sabem do que você está falando, então é bom. Quantas vezes eles têm reuniões de recuperação da equipe. Diariamente é ótimo, mensal é ruim. Eles têm um servidor de integração contínuo. Este não é um item obrigatório, mas lhe dará uma idéia sobre o uso de ferramentas. Com que frequência os usuários finais ficam com os desenvolvedores. Nunca significa que eles não são ágeis.

Henry
fonte
+1 na IMO, a primeira coisa que morre em uma organização com aspirações ágeis é a retrospectiva. Esse é realmente um conceito do Scrum, mas o ágil bem-sucedido vem com a compreensão de quão bem o seu processo está permitindo, em vez de desativar a sua organização. Sem algum mecanismo de introspecção, não vejo como isso é possível.
MIA
0
  • Dê a eles uma situação e peça que resolvam de maneira ágil;
  • Pergunte a eles sobre suas práticas ágeis favoritas (planejamento de pôquer, programação de pares, bdd / tdd, kanban);
  • Pergunte a eles por que eles não escolheram ou se mudaram de outras metodologias (cascata, rup, etc.)
  • Quais são as pessoas mais conhecidas no mundo da metodologia ágil, que cunharam o termo e quais livros mais populares são escritos sobre ele.
Eimantas
fonte
1
Honestamente, eu falharia no quarto ponto. Sei o que é ágil e já li vários recursos on-line sobre como diferentes pessoas se destacaram. No entanto, meu caminho para o ágil sempre foi personalizado para a equipe / ambiente em que trabalho.
Berin Loritsch
0

Se eles estiverem usando o Scrum, você pode perguntar se poderá assistir ao próximo stand-up. Se eles não os tiverem, pergunte por que não, pois isso normalmente faria parte da metodologia.

Existem alguns aspectos do Agile que também podem ser mencionados. Peça para ver o storyboard, qual o tamanho do registro posterior ou quais foram alguns dos destaques da última retrospectiva para algumas outras idéias. A chave aqui é chegar a algo tangível que mostra o que está acontecendo em comparação com apenas palavras fofas que não significam muito.

JB King
fonte
0

Pergunte a eles como eles lidam com o design. Se eles disserem que não há design no ágil, eles não o entenderão.

Pergunte a eles como eles gerenciam os requisitos variáveis. Se parece que a mudança de requisitos tem seu próprio processo, eles provavelmente não estão conseguindo.

Se eles estão alegando usar o Scrum, veja como eles o escrevem. As lojas que fazem bem o Scrum tendem a saber o suficiente como escrevê-lo. Dica: não é SCRUM.

Pode parecer um pedantismo, mas acredito firmemente que, para aplicar com êxito um modelo de processo como Scrum, RUP, XP ou qualquer outra coisa, você precisa entender a filosofia e o "porquê" para saber como se adaptar o "o que" para sua organização. No Scrum, a maioria das pessoas que está fazendo a lição de casa encontrará esse pouco de informação. As pessoas que procuram receitas de livros de receitas para gerenciamento de projetos geralmente perdem esse detalhe.

MIA
fonte
0

O que faz sentido para mim é pedir que descrevam como lidam com parte do processo Agile. No momento, meu favorito é o início de uma iteração, mas você pode desenvolver seu próprio favorito.

Pergunte: "com uma pilha de tickets no início do sprint, descreva seu fluxo de trabalho daqui"

Pontos principais a serem ouvidos aqui:

  • Os desenvolvedores estimam os tickets?
  • Você acompanha a velocidade?
  • O que acontece quando suas estimativas ultrapassam sua velocidade?
  • O que acontece quando suas estimativas atingem mais do que sua velocidade quando você tem um prazo? (Preste atenção na rotação aqui: eles reduzem a complexidade, repriorizam ou apenas marcam a equipe de desenvolvimento?)

Nenhuma delas é uma quebra de negócio por si só, mas se suas respostas a muitas dessas perguntas o fazem pensar, talvez estejam interessadas em rituais ágeis , e não em desenvolvimento ágil real .

RyanWilcox
fonte