인터뷰에서 유행어 민첩에서 실제 민첩성을 제거 [폐쇄]

나는 최근에 협동 조합 (유료 인턴쉽)을 위해 인터뷰를 해왔으며 인터뷰 한 많은 회사들이 스크럼이나 다른 민첩한 방법론 (스크럼이 가장 인기있는)을 사용하고 있다고 말하고 있습니다. 나는 실제 민첩한 상점이 있고 민첩한 방법론을 사용하지만 실제로 다른 것을하고 애자일을 유행어로 사용하는 곳이 있다는 것을 알고 있습니다.

제 질문은 인터뷰에서이 상점들을 분리 할 수있는 질문은 무엇입니까?

편집 : 인턴쉽을 찾고있는 동안이 질문은 모든 사람과 관련이 있다고 생각합니다. 인턴쉽 부분은 맥락입니다.

나는 항상이 질문을하면서 시작합니다.

반복 기간은 얼마입니까?

그들의 답변을 평가하십시오 :

1 주일은 굉장하고, 2 주일은 컸으며, 3 시간은 괜찮고 4 시간은 평범합니다. 그보다 길면 어려움을 겪고 있음을 나타내며 8 주 이상은 이상합니다. 대답이 달려 있다면 , 당신은 그들이 전혀 단서가 없다는 것을 알고 있습니다.

후속 조치 :

얼마나 자주 석방합니까?

이것은 첫 번째 질문을 확인하기위한 것입니다. 정답은 매일 또는 각 스프린트의 끝입니다 . agilist는 내부 릴리스와 외부 릴리스간에 기술적 차이가 없어야한다는 것을 알고 있습니다.

민첩한 방법론을 방어하도록 요청하십시오. 그런 다음 약점을 요약하여 반박하도록 요청하십시오. 무의미한 유행어로 어지럽히 지 않고이 코스를 탐색 할 수있는 경우 보너스 포인트.

그들이 왜 그것을 사용하는지 물어보십시오 .

당신은 즉시 알게 될 것입니다.

Agile 방법론을 사용할 때 소프트웨어 개발 수명주기를 설명하도록 요청합니다. 이들이 익숙하다면 SDLC의 각 단계를 정확하게 설명 할 수 있어야합니다.

편집 : 나는 당신이 면접관이 아니라 면접관의 관점에서 묻는다는 것을 깨달았습니다. 이 경우 SDLC에 대해 물어보고 그들이 수행하는 단계가 Agile의 실제 단계와 일치하는지 확인합니다.

내가 취하는 접근법은 민첩한 유행어와 거의 관련이 없지만 민첩한 관행과 관련이 있습니다. 모든 애자일 팀의 공통점 중 하나는 짧은 반복입니다. 대부분의 사람들은 그 부분을 얻습니다 ( http://agilemanifesto.org 사이트의 민첩성 뒤에 12 가지 원칙 중 하나임 ). 짧은 반복의 목적은 개발 된 소프트웨어의 품질에 대한 피드백을 조기에 얻는 것입니다. 내가 시작하는 곳입니다.

1. 단위 테스트에 대해 문의하십시오. 압도적으로 내가 여기에 얻는 대답은 "어, 우리는 시간이 충분하지 않아서 그만 두었습니다"(주 : 처음 두 개의 경고 플래그-시간과 단위 테스트가 없음)입니다.
2. 소프트웨어 테스트시기와 빈도에 대해 문의하십시오. 여기에서 답변을 창의적으로 얻을 수 있습니다. 특히 팀이 "Agile"을 모든 프로세스를 버릴 수있는 변명으로 사용하는 경우. 대답이 프로젝트의 끝 또는 각 반복 이외의 것에 대한 것이라면 민첩한 것이 무엇인지 모릅니다.

지금까지 나는 민첩한 것이 무엇인지 모른다는 것을 알기 위해 이것보다 더 멀리 갈 필요가 없었습니다. 또한 이미 민첩한 프로세스를 확립 한 회사와 한 번만 인터뷰했습니다.

애자일을 수행하는 방법은 여러 가지가 있으며 특정 브랜드 나 유행어보다 애자일 원칙에 더 관심이 있습니다.

민첩한 사람과 민첩한 사람을 구분하는 몇 가지 사항이 있습니다.

• CI 공제를 사용하지 않는 경우 지속적인 통합에 대해 문의하십시오. 그렇다면 포인트를 추가하십시오. 추가 포인트 :
  1. 2 단계 커밋을 사용하는 경우 1을 추가하십시오 (개발자가 체크인하기 전에 코드를 성공적으로 빌드해야 함).
  2. 빌드 스크립트에 테스트 스위트 실행이 포함 된 경우 1을 추가하십시오.
  3. 코드 범위가 특정 임계 값 아래로 떨어지는 경우 빌드가 실패하면 1을 추가하십시오.
  4. 한 번의 클릭으로 실행할 수 있도록 애플리케이션을 배치 할 수있는 경우 2를 추가하십시오.
• TDD (테스트 중심 개발)에 대해 묻고 TDD를 사용하지 않으면 2 점을 뺍니다.
• 반복에 대한 질문, 기간은 얼마입니까 (반복 개발을하지 않으면 2 점 빼기, 반복이 한 달보다 길거나 2 주 미만이면 1 빼기, 2 주이면 1 더하기)
• 스토리 포인트를 사용하는 경우 1을 더하고, 포커를 계획하는 경우 2를 추가하고, 절대 시간 추정을 사용하는 경우 1을 빼고, 개발자가 추정 프로세스에 관여하지 않으면 2를 빼십시오.
• 개발자가 특정 레이어 (수평 슬라이스)를 담당하는 경우 개발자가 기능을 위에서 아래 (수직 슬라이스)로 뺀 경우 1을 더하는 방법 1을 추가하십시오.

다른 여러 지표가 있지만 팀이 실제로 민첩한 경우 그 지표만으로도 좋은 그림을 제공해야합니다. 5 점 이상을 가진 팀이 자격을 갖습니다. 다른 것은 그들이 "민첩한"행동을 의미합니다. 애자일은 반복에 관한 것이 아니라 팀이 쉽게 변화에 적응할 수 있도록하는 것입니다. 외부 압력 하에서 작성된 테스트되지 않은 혼잡 한 코드를 반복적으로 작성하는 경우 반복적으로 쓰레기 코드를 작성하는 것입니다. 지속적인 통합 글 머리 기호만으로도 많은 포인트를 얻을 수 있습니다. 그러나 다른 관행을 따르지 않는다면 5 개 이상으로 충분하지 않습니다.

이 모든 것들과 마찬가지로 이론이 아니라 작업 한 프로젝트에서 실제 사례 를 요구합니다 . 이론적 대답을 받아들이는 것은 실제로 거기에 있지 않은 사람이 속이는 가장 쉬운 방법입니다.

따라서 실제 개발자 와 대화하고 다음과 같은 것을 요청하십시오.

• 따라서 현재 프로젝트를 통해 이야기하십시오. 초기 목표는 무엇입니까? 첫 스프린트에는 무엇이 포함되어 있으며 소프트웨어는 그 끝에 무엇을 할 수 있습니까?
• 폭포 형 프로젝트와는 다른 방식으로 작동했다고 생각되는 마지막 프로젝트의 기능 또는 디자인에 대한 예를 들어 주시겠습니까?
• 여러 가지 스프린트에서 큰 기능이 어떻게 분류되었는지 예를 들어 주시겠습니까? 이로 인해 어떤 비 효율성 / 재 작업이 이루어 졌습니까? 그리고 처음에 계획했던 것의 개선 또는 변화
• 민첩하게 작업을 시작했을 때, 초기 스프린트 동안 수행 한 작업이 방법론에 익숙해지면서 후 스프린트 (또는 프로젝트) 중에 변경 한 것이 있습니까?

그들이 달성하려는 것, 각 스프린트에 있었던 것의 예, 회의에서 나왔던 종류의 예, 사용자와의 상호 작용의 예와 같은 실제 프로젝트로 다시 가져옵니다 .

이론을 받아들이지 말고, 다른 사람들의 프로젝트를 받아들이지 말고, 그들 자신이 작업 한 것들만 직접 경험을 통해 이야기 할 수 있습니다.

그들은 당신이 당신의 물건을 알고 있다면 당신을 지나칠 10-15 분 분량의 물건을 만들 수 있도록 놀랍도록 좋은 거짓말 쟁이 여야합니다.

당신이 그들을 방어 적으로 만들고 싶지 않다면, 다음 질문은 그들이 실제로 민첩한 접근 방식을 사용하는지 아니면 립 서비스를 지불하는지에 대해 알아야 할 모든 것을 알려주는 대화를 시작한다는 것을 알았습니다.

소프트웨어 프로젝트의 요구 사항 / 사양을 작성하는 담당자는 누구입니까?

나는 민첩하다고 주장하는 많은 회사를 보았고 요구 사항 수집 프로세스에 대해 질문 할 때 Scrum Master 인증이 고전적인 큰 선행 설계 프로세스를 설명하기를 원했습니다.

나에게 눈에 띄는 것은 인턴쉽을 찾고 있다는 것인데,이 질문을하는 데 당신의 목적이 무엇인지 궁금해합니다. 인터뷰를 잘 진행하기 위해 민첩성에 대해 질문을하려고합니까? 아니면 실제로 전문 용어 민첩성을 사용하는 회사의 제안을 거부 하시겠습니까? 실제로 민첩한 환경을 찾고 있다면 질문 (애자일을 사용하는 이유, 대기 시간, 반복 시간 등)을 선택하고 전화 나 이메일을 통해 시간을 낭비하지 않고 질문하십시오. 회견. 수입을 찾고 있다면 인터뷰를 기다렸다가 반 민첩한 혐오를 사용하는 면접관을 당황하게하지 않으면 서 민첩한 방법론 (소프트웨어 개발 수명주기에 대해 알려주세요)에 대한 지식 / 흥분을 보여주는 질문을하십시오.

나는 처음부터 최종 배달까지 고객에게 전형적인 요청을 설명하도록 요청합니다.

또한 일반적으로 고객에게 제공하는 제품에 대한 장기적인 지원을 처리 할 것인지 묻습니다 (일반적으로 팀은 더 나은 제품을 개발할 것이기 때문에 노동절 주말 동안 일요일 오전 1시에 제품을 수정하는 것으로 알고 있기 때문에).

또한 프로세스 중에 경영진이 어떻게 역할을 수행하는지 묻습니다. 그들이 불을 잊어 버리는 태도 (우리가 발사하고, 날아가고, 목표에 부딪히는 지 묻습니다) 또는 "우리가 배를 강 위로 뛸 수 있도록 도와주십시오"라는 태도가 있는지를 쉽게 알 수 있습니다.

이들은 일반적으로 그들이 실제로 어떻게 행동하는지, 그들이 어떻게해야하는지, 그들이 어떻게 주장 하는지를 보여줍니다.

SDLC 관점에서 자신이하고있는 일을 아는 사람이 있는지 확인하는 가장 좋은 방법은 과거에 어디에서 망쳐 놓았는지, 어떻게 다르게 수행 할 것인지 묻는 것입니다. 이 과정을 몇 번 겪어 왔고 그들이 망 쳤던 곳을 완전히 인정하는 사람들은 일반적으로 매우 상세합니다. 그들은 그것을 논의하기 위해 열린 마음은 그들이 완전하지 않다는 것을 인정하기 때문에 자신감의 수준을 보여줍니다. "항상 거의 괜찮습니다."라고 말함으로써 질문을 피하는 것은 진정한 경고 신호입니다.

그들이 생산에 얼마나 자주 출시되는지. 시간이 길수록 민첩성이 떨어집니다. 그들이 얼마나 자주 리플렉션 워크샵을하는지. 그들이 당신이 무슨 말을하는지 알고 있다면 좋습니다. 팀 '캐치 업'회의가 얼마나 자주 있습니까? 매일은 좋고, 매달은 나쁘다. 지속적인 통합 서버가 있습니까? 이것은 반드시 필요한 것은 아니지만 도구 사용에 대한 아이디어를 제공합니다. 최종 사용자가 개발자와 얼마나 자주 앉아 있습니까? 그들이 민첩하지 않다는 의미는 아닙니다.

• 그들에게 상황을 제시하고 민첩하게 해결하도록 요청하십시오.
• 그들이 좋아하는 민첩한 관행에 대해 물어보십시오 (기획 포커, 페어 프로그래밍, bdd / tdd, kanban).
• 그들이 왜 다른 방법론 (폭포, rup 등)을 선택하지 않았는지 물어보십시오 .
• 민첩한 방법론 세계에서 가장 잘 알려진 사람들은이 용어를 만들었으며 가장 인기있는 책은 무엇에 관한 것입니까?

그들이 Scrum을 사용하고 있다면, 다음 스탠드 업을 볼 수 있는지 물어볼 수 있습니다. 그들이없는 경우, 왜 방법론의 일부가 아닌지 물어보십시오.

애자일에는 언급 할 가치가있는 몇 가지 측면이 있습니다. 스토리 보드, 백 로그가 얼마나 큰지, 또는 마지막 회고에서 볼 수있는 몇 가지 다른 아이디어에 대해 이야기 해보십시오. 여기서 중요한 것은 실제로 의미가없는 솜털 같은 단어와 비교하여 어떤 일이 일어나고 있는지를 보여주는 유형의 무언가를 얻는 것입니다.

그들이 디자인을 어떻게 다루는 지 물어보십시오. 그들이 민첩한 디자인이 없다고 말하면, 그들은 그것을 얻지 못하고 있습니다.

그들이 변화하는 요구 사항을 어떻게 관리하는지 물어보십시오. 요구 사항 변경에 자체 프로세스가있는 것처럼 들리면 아마도 얻지 못했을 것입니다.

그들이 스크럼을 사용한다고 주장한다면, 그들이 어떻게 그것을 쓰는지보십시오. 스크럼을 잘하는 상점은 그것을 쓰는 방법을 충분히 알고있는 경향이 있습니다. 힌트 : 스크럼이 아닙니다.

그것은 pedantry처럼 보일지 모르지만, 나는 Scrum, RUP, XP와 같은 프로세스 템플릿을 성공적으로 적용하기 위해서는 철학과 "이유"를 이해해야 적응 방법을 알 수 있다고 확신합니다. 조직의 "무엇". 스크럼에서 숙제를하는 대부분의 사람들은 그 작은 정보를 보게 될 것입니다. 프로젝트 관리를위한 요리 책 요리법을 찾는 사람들은 일반적으로 그 세부 사항을 놓칠 것입니다.

이해가되는 것은 애자일 프로세스의 일부를 어떻게 처리하는지 설명하도록 요청하는 것입니다. 지금은 내가 가장 좋아하는 것이 반복의 시작이지만 자신이 좋아하는 것을 개발할 수도 있습니다.

"스프린트 시작 부분에 티켓 더미를 주었고 여기에서 워크 플로우를 설명하십시오"

여기에 들어야 할 요점 :

• 개발자는 티켓을 추정합니까?
• 속도를 추적합니까?
• 추정치가 속도 이상으로 올 때 어떻게됩니까?
• 마감일이있을 때 추정치가 속도보다 더 높아지면 어떻게됩니까? (여기서 스핀을 살펴보십시오. 개발 팀이 복잡성을 줄이거 나 우선 순위를 매기거나 단순히 막을 내리는가?)

이것들 중 어느 것도 그 자체로 거래 차단기는 아니지만, 이러한 질문들에 대한 충분한 답변이 당신을 궁금하게 만든다면, 그들은 실제 민첩한 개발이 아니라 민첩한 의식에 관심이있을 것 입니다.