インタビューで流行語アジャイルから本物のアジャイルを取り除く[非公開]

私は最近、協同組合（有給インターンシップ）のインタビューを行っていますが、インタビューを行っている多くの企業は、スクラムやその他のアジャイル手法を使用していると言っています（スクラムが最も人気があります）。本当のアジャイルショップがあり、アジャイル手法を使用しているが、何か他のことをやっていて、アジャイルを流行語として使用していると言う場所があることを知っています。

私の質問は、これらの店を区別するインタビューで尋ねることができる質問は何ですか？

編集：私はインターンシップを探していますが、これらの質問はすべての人に関係があると感じています。インターンシップの部分はコンテキストです。

私はいつもこの質問をすることから始めます：

反復の期間はどれくらいですか？

回答を評価してください：

1週間は素晴らしく、2週間は素晴らしく、3は大丈夫、4は平凡です。それよりも長いと、彼らは苦労しており、8週間以上は奇妙です。答えが依存する場合、それらはまったく手がかりがないことがわかります。

に続いて：

どのくらいの頻度でリリースしますか？

これは最初の質問を確認するためです。正しい答えは毎日または各スプリントの終了です。専門家は、内部リリースと外部リリースの間に技術的な違いがないことを知っているでしょう。

アジャイル方法論を守るよう依頼してください。そして、彼らの弱点を概説することにより、反論するように彼らに依頼します。意味のない流行語を散らかさずにこのコースをナビゲートできれば、ボーナスポイントになります。

彼らになぜそれを使うのか尋ねてください。

すぐにわかります。

アジャイル手法を使用する場合、ソフトウェア開発のライフサイクルについて説明するよう依頼します。彼らがそれに慣れていれば、SDLCの各フェーズを正確に説明できるはずです。

編集：私はあなたがインタビュアーではなくインタビュイーの観点から質問していることに気付いた。その場合、私はおそらく彼らに彼らのSDLCについて尋ね、彼らが言うステップがアジャイルが本当に何であるかと一致するかどうかを見るでしょう。

私がとるアプローチは、アジャイルの流行語とはほとんど関係がありませんが、アジャイルのプラクティスとは関係があります。すべてのアジャイルチームの共通点の1つは短い反復です。ほとんどの人がその部分を取得します（http://agilemanifesto.orgサイトでアジャイルの背後にある12の原則の1つです）。短い反復の目的は、開発されたソフトウェアの品質に関するフィードバックを早期に取得することです。ここから始めます。

1. 単体テストについて尋ねます。圧倒的に私がここで得た答えは、「ええと、時間が足りなかったのでそれを切り捨てました」（注：最初の2つの警告フラグ-時間もユニットテストもありません）
2. ソフトウェアがいつテストされたか、そしてどのくらいの頻度かを尋ねます。答えはここで創造的になります。特に、チームがすべてのプロセスを破棄する言い訳として「アジャイル」を使用する場合。答えがプロジェクトの終わりに向かっている場合、または各反復以外のものである場合、彼らはアジャイルが何であるかを知りません。

これまでのところ、私はこの人がアジャイルとは何かを知らないことを知るためにこれ以上進む必要はありませんでした。また、すでにアジャイルプロセスが確立されている企業とのインタビューを1回だけ受けました。

アジャイルを行う方法は複数あり、特定のブランドや流行語よりもアジャイルの原則を重視しています。

アジャイルを「実行」している人とアジャイルをしている人を区別するものがいくつかあります。

• CIを使用していない場合、継続的な統合について質問してください。ある場合はポイントを追加します。追加ポイント：
  1. 2フェーズコミットを使用する場合は1を追加します（開発者がチェックインする前にコードを正常にビルドする必要があります）。
  2. ビルドスクリプトにテストスイートの実行が含まれる場合は1を追加します
  3. コードカバレッジが特定のしきい値を下回った場合にビルドが失敗した場合、1を追加します
  4. ワンクリックで実行できるようにアプリケーションをデプロイできる場合は2を追加します
• TDD（テスト駆動開発）について質問します。TDDを使用しない場合は2ポイントを引き、使用する場合は1ポイントを引きます。
• 反復について質問します（反復開発を行わない場合は2ポイントを引き、反復が1か月より長いか2週間未満の場合は1ポイントを引き、2週間の場合は1ポイントを引きます）
• ストーリーポイントを使用する場合は1を追加し、ポーカーなどを計画する場合は2を追加し、絶対時間の見積もりを使用する場合は1を減算し、開発者が推定プロセスに関与していない場合は2を減算します。
• 機能がどのように構築されるかを尋ねる開発者が上から下（垂直スライス）の機能を担当する場合は1を追加します開発者が特定のレイヤー（水平スライス）を担当する場合は1を減算します

他にも多くの指標がありますが、チームが実際にアジャイルである場合、それらだけで良い状況がわかります。5ポイント以上のチームが対象です。それ以外のことは、彼らがアジャイルを「行っている」ことを意味します。アジャイルは単なる反復ではなく、チームが変化に容易に適応できるようにすることです。外部からのプレッシャーの下で書かれた、テストされていない、混乱したコードを繰り返し書いているのなら、ただ繰り返してくだらないコードを書いているだけです。継続的インテグレーションの箇条書きから多くのポイントを取得できることに注意してください。しかし、それだけでは、他の慣行に従わない場合に5を超えるには不十分です。

これらすべてのことと同様に、理論ではなく、彼らが取り組んだプロジェクトの実世界の例を求めます。理論的な答えを受け入れることは、実際にそこにいなかった誰かによってだまされる最も簡単な方法です。

したがって、実際の開発者と話をして、次のようなことを尋ねます。

• だからあなたの現在のプロジェクトについて話してください。最初の最終目標は何でしたか？最初のスプリントには何が含まれていて、ソフトウェアは最後に何をすることができましたか？
• ウォーターフォールプロジェクトとして行ったものとは異なる方法で機能すると思われる最後のプロジェクトの機能または設計の例を教えてください。
• 機能の大部分が複数のスプリントにどのように分解されたかの例を教えてください。これはどのような非効率/再作業につながりましたか？そして、最初に想定されていたものからの改善点または変更点。
• アジャイルで作業を始めたとき、初期のスプリントで行っていたことは、後のスプリント（またはプロジェクト）で方法論を理解したときにどのように変更しましたか？

それらを実際のプロジェクトに戻してください -彼らが何を達成しようとしていたのか、各スプリントに何があったのかの例、会議で出てきた種類の例、ユーザーとのやり取りの例

理論を受け入れず、他の人々のプロジェクトを受け入れないでください。彼ら自身が取り組んできたものだけを実際の経験から話すことができます。

彼らはあなたがあなたのものを知っていればあなたを通り過ぎるだろう10-15分の価値のあるものを補うことができるために驚くほど良い嘘つきでなければなりません。

それらを防御的にしたくない場合は、次の質問が会話を開始し、彼らが実際にアジャイルアプローチを使用しているのか、単にリップサービスを支払っているのかを知る必要があるすべてを教えてくれることがわかりました：

ソフトウェアプロジェクトの要件/仕様を作成する責任は誰にありますか？

アジャイルであると主張し、スクラムマスターの認定を望んでいる多くの企業が、要件収集プロセスについて尋ねると、古典的な大きな先行設計プロセスを説明しているのを見てきました。

私が際立っているのは、あなたがインターンシップを探しているということです。これは、これらの質問をすることであなたの目的が何であるかを疑問に思います。アジャイルについて質問してインタビューをうまくやろうとしているのですか、それとも流行語アジャイルを使用している会社からのオファーを実際に拒否しますか？アジャイル環境を本当に探している場合は、質問を選んで（なぜアジャイルを使用するのか、何時にスタンドアップするのか、繰り返しの長さは何でも）、電話やメールで時間を無駄にせずに質問するインタビュー。収入を探している場合は、インタビューを待って、アジャイル方法論に関する知識/興奮を示す質問をしてください（ソフトウェア開発ライフサイクルについて教えてください）。

開始から最終的なクライアントへの配信まで、典型的なリクエストを説明するよう依頼します。

また、彼らがクライアントに提供する製品の長期サポートを通常処理するかどうかも尋ねます（労働者の週末の日曜日の午前1時にそれを修正するチームになるので、一般的にチームはより良い製品を構築します）。

また、プロセス中に経営陣がその役割をどのように見ているかを尋ねます。彼らが火をつけて忘れる姿勢（私たちは打ち上げ、飛ぶ、標的に当たったかどうかを尋ねる）か、「ボートを川でrowぎ上げるのを手伝う」姿勢かどうかを確認するのは非常に簡単です。

これらは一般に、彼らが実際にどのように物事を行うかを示します。

SDLCの観点から自分が何をしているかを誰かが知っているかどうかを確認するための最良の方法は、過去にどこで失敗したか、どのようにそれを行うかを尋ねることです。プロセスを数回行ったことがあり、どこで失敗したかを完全に認める人々。彼らはそれを議論することへの寛容さは、彼らが完璧ではないことを認めているので、自信のレベルを示しています。「常に大丈夫」という質問を避けることは、本当の警告サインです。

本番環境にリリースする頻度。時間が長いほど、アジャイルは少なくなります。彼らが反射ワークショップを持っている頻度。彼らがあなたの話していることを知っているなら、それは良いことです。チームが「キャッチアップ」ミーティングを行う頻度。毎日は素晴らしい、毎月は悪いです。彼らは継続的な統合サーバーを持っていますか？これは必須ではありませんが、ツールの使用に関するアイデアを提供します。エンドユーザーが開発者と一緒に座る頻度。決してアジャイルではないという意味ではありません。

• 彼らに状況を与えて、彼らに機敏な方法でそれを解決するよう頼んでください。
• お気に入りのアジャイルプラクティス（プランニングポーカー、ペアプログラミング、bdd / tdd、かんばん）について質問します。
• 他の方法論（ウォーターフォール、ループなど）を選択または移動しなかった理由を尋ねます。
• アジャイル方法論の世界で最もよく知られている人々、この用語を生み出した人、およびそれについて最も人気のある本は何ですか。

彼らがスクラムを使用している場合、次のスタンドアップを見ることができるかどうか尋ねることができます。持っていない場合は、なぜそれが方法論の一部であるのかを尋ねます。

アジャイルには、言及する価値がある側面もいくつかあります。他のいくつかのアイデアについては、ストーリーボード、バックログの大きさ、最後の回顧展のハイライトの一部を確認してください。ここで重要なのは、実際にはあまり意味のないふわふわした言葉と比較して、何が起こっているのかを示す具体的なものに到達することです。

彼らがデザインをどのように扱うかを彼らに尋ねてください。彼らがアジャイルにデザインがないとあなたが言うならば、彼らはそれを得ていません。

変化する要件をどのように管理しているかを尋ねます。要件の変更に独自のプロセスがあるように思える場合、彼らはおそらくそれを得ていないでしょう。

スクラムを使用すると主張している場合は、それをどのように書いているかを確認してください。スクラムを上手に行っているショップは、その書き方を十分に知っている傾向があります。ヒント：スクラムではありません。

それはつまらないように思えるかもしれませんが、スクラム、RUP、XPなどのプロセステンプレートを正常に適用するには、哲学と「なぜ」を理解して適応する方法を理解する必要があると固く信じています組織の「何」。スクラムでは、宿題をしているほとんどの人が、ほんの少しの情報に出くわします。プロジェクト管理のための料理のレシピを探している人は、通常、その詳細を見逃します。

私にとって理にかなっているのは、アジャイルプロセスの一部をどのように処理するかを説明するように依頼することです。今、私のお気に入りはイテレーションの始まりですが、あなたはあなた自身のお気に入りを開発するかもしれません。

質問：「スプリントの開始時にチケットの山を与え、ここからワークフローを説明してください」

ここで耳を傾けるキーポイント：

• 開発者はチケットを見積もりますか？
• 速度を追跡していますか？
• 推定値が速度以上になるとどうなりますか？
• 期限があるときに見積もりが速度よりも大きくなった場合はどうなりますか？（ここでスピンに注意してください：それらは複雑さを軽減しますか、それとも優先順位付けしますか、それとも開発チームを死に至らしめますか？）

これらはどれもそれ自体が取引ブレーカーではありませんが、これらの質問に対する十分な答えがあなたを疑問に思うなら、彼らは実際のアジャイル開発ではなくアジャイルの儀式に興味があるかもしれません。