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

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.

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.

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.

Pergunte a eles por que eles usam .

Você saberá imediatamente.

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 é.

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.

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.

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.

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.

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.

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.

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.

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.

• 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.

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.

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.

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 .