スタートアップをアジャイル開発で動作させるにはどうすればよいですか？
私たちのスタートアップでは、これまで従来のウォーターフォールモデルを使用して作業してきましたが、アジャイル手法を使用して次のプロジェクトを試してみたいと思います。
私たちはアジャイルプロセス全体にほとんど異質なので、これを考慮して、アジャイルを理解し（リソースと実用的なハンドブックが役立つ場合があります）、特定の方法論（スクラムなど）を決定し、それを開始するための最良の方法は何ですか？私たちの次のプロジェクト？
アジャイルは市場投入までの時間を短縮し、開発者の生産性を向上させるため、アジャイルを採用したいとおっしゃっていましたが、その特定の側面に焦点を当てたいと思います。
市場投入までの時間
従来のウォーターフォール製品では、利害関係者は要件にサインアップする機会を1回だけ取得します。アジャイルでは、はるかに小さなビジョンを作成し、後で要件を追加できます。これが、市場に迅速に参入するための最良の方法です。これを行うには、次のことを確認する必要があります
- コードベースは簡単に変更できます
- コードを簡単に、繰り返し、確実にデプロイできます
- 利害関係者は、彼らが望むものではなく、彼らが本当に必要としているものに関与し、話し合う準備ができています。
したがって、利害関係者を少し教育する必要があります。ストーリーマッピングや機能インジェクションなどのテーマを読み、アジャイルから何を得たいかについて話します。彼らがウォーターフォールの分析で得ていた確実性はそこにはありませんが（もしあったとしても！）、代わりに彼らは考えを変えて製品の方向性を形作る機会が増えることを覚えておいてください。
コードベースを簡単に変更できるようにするためのプラクティスについては、KentBeckの「XPExplained」をお勧めします。また、TDD、BDD、継続的インテグレーションとデプロイメントについても詳しく見ていきます。
可能な限り本番環境に近い環境内で利害関係者にショーケースを提供することは、非常に役立ちます。これは2週間ごとに行うことをお勧めします。展開が非常に簡単で、利害関係者がより多くの関与を望んでいる場合は、反復を1週間に短縮できます。デプロイが非常に難しい場合は、開発者のマシン上にある必要がある場合でも、2週間ごとに何らかの形でフィードバックを受け取ることができることを確認してから、可能であれば毎月1〜2回リリースしてください。これを行っている間に、展開を非常に困難にしている原因を突き止め、自動化を開始します。定期的に展開することを妨げている政治団体がある場合は、ゲートキーピングプロセスを短縮するために彼らに見せることができるかもしれないことを考え出し、彼らがチームを教育し、大きなものを1つ持つ代わりに継続的にチェックする役割にそれらを移動できるかどうかを確認します最後に確認してください。
生産性の向上
アジャイルは、開発者がより短い時間でより多くの作業を行えるようにする方法ではありません。代わりに、開発者は、「万が一に備えて」行われる作業に関して、やり直しが少なく、無駄な労力が少なく、お互いに、そしてチームの他のメンバーから学ぶことができる、より協調的なアプローチがあります。
チームを同じ場所に配置することが、これを実現するための最大の要因であるIMOです。開発者は、テスターと協力してバグを早期に発見できる必要がありますが、バグの修正方法は覚えています。アナリストと協力して、理解していない要件のどの部分にも疑問を投げかけることができるようにします。そして、彼らが新しいアイデア、デザイン、そして彼らが学んだことを共有できるように、お互いに。ほとんどのXPプラクティス、特にペアプログラミング、コラボレーティブコードの所有権、およびTDDは、バグを減らし、したがってやり直しもします。
スクラムに関する警告
これは、推定と速度測定を使用している場合に特に当てはまります。
あなたがやろうとしていることの多くはあなたにとって新しいものであり、物事がどれだけ長くかかるかから始めるのは難しいでしょう。見積もりと速度測定を使用して作業を追跡し始める場合、見積もりは最初からかなりの方法である可能性があります。これは正常です。
スクラムはまた、コードを簡単に変更できるようにするための技術的手法を義務付けていません。あなたが求めているもの（市場投入までの時間と生産性）については、それらの技術的慣行は必須になります。そのため、スクラムを導入するだけでなく、開発作業で卓越性を採用し始め、その周りでプロセスを柔軟にしてください。高品質で協調的なコードと高度な学習環境を備えているだけで、多くのメリットが得られます。
コーチングとトレーニング
問題が発生する可能性が高くなります。いくつかのCSMクラスからセルフコーチをした1つの会社に会っただけで、彼らは素晴らしい文化を持っていました。助けを求めることを恐れないでください、そして広範囲に読んでください。そこにある方法論はスクラムだけではなく、他のソースからもアイデアを得ることができます。
アジャイルブックの場合 読む 。アジャイルプロジェクトの経験がある人を雇うことを強くお勧めします。また、読むことから始めます アジャイルマニフェスト
Jim Shores book で概説されているアプローチが好きです。
彼は、組織がXPの価値と実践を学ぶために1日1時間、1〜2週間を費やすことを推奨しています。彼はそれをétudesと呼んでおり、アイデアはアジャイルな主題について読んでから、特定の質問に答える特定の時間にタイムボックス化されている間にペアでそれを議論することです（これは私たちにとってどのように新しいのですか？それで何が問題になるのでしょうか？など）。最終的には、アジャイルが良いアイデアのように思えるかどうかにかかわらず、人々はそれを理解し始め、情報に基づいた決定を下せるようになるはずです。
私は個人的にこのアプローチを使用しましたが、非常にうまく機能しました。アジャイルプラクティス（タイムボックス、ペアリング、コラボレーション）を人々に紹介するのが好きです。これは、組織が必要とするキックスタートにすぎない可能性があります。
私たちはアジャイルプロセス全体にほとんど異質なので、これを考慮して、アジャイルを理解し（リソースと実用的なハンドブックが役立つ場合があります）、特定の方法論（スクラムなど）を決定し、それを開始するための最良の方法は何ですか？私たちの次のプロジェクト？
もちろん、ここにいる他のみんなが言ったことをして、読んだり学んだりしてください。
それを超えて、「次のプロジェクト」を選択しないでください。アジャイルメソッドを使用して成功するプロジェクトを選択してください。プロジェクトを成功させるには、プロジェクトの範囲が小さく、リスクが低く、顧客価値が高く、達成可能である必要があります。チームは小さく、同じ場所に配置され、変化を受け入れる意思がある必要があります。また、自動化されたプロセス（特にビルドとテスト）を実施する必要があります。
これらが揃ったら、次の方法で成功するようにチームを設定します。継続的なフィードバックとオープンなコミュニケーションのためにチームと提携することを約束する興奮した顧客を用意します。製品の所有者が、顧客が何を必要としているかを明確にし、最初に何に取り組むべきか、次に何に取り組むべきかを優先することをいとわないことを確認してください。次に、チームにビルドを毎週顧客/ POに配信して、受け入れとフィードバックを依頼します。
私が上で説明したことは、あなたが知る必要があることの一部にすぎませんが、それは継続的で持続可能な成功につながる重要な部分です。
私は「アジャイルを行う必要がある」という観点から始めません。
代わりに、既存のプロセスを調べて、発生した問題を修正する方法を確認してください。現在行っていることから始めて、継続的な改善が重要な私見です。
どうして？多くの「標準的な」アジャイルプロセスは、スタートアップにはあまり適していません（おかしなことに聞こえます）。
代わりに、現在の問題の解決に役立つプラクティスを選択して選択し、必要に応じてプラクティスを1つずつプラグインします。
メタレベル：
- フィードバックに焦点を合わせます。スタートアップは、ユーザーのフィードバックにどれだけうまく対応でき、どれだけうまく反復できるかで生きて死にます。これは、機能を迅速に開発して本番環境に移行できることを意味します。より速く構築し、より簡単に展開するのに役立つプラクティスを選択してください。
- スタートアップでは、80％が「何を構築するか」、20％が「どのように構築するか」です。 「何を構築するか」を決定するのに役立つプラクティスに焦点を当てる
練習レベルで：
- ユーザーストーリーのマッピングを調査します。これは、構築しようとしているものの範囲を理解できるようにする手法です。あなたがしていることのビジョンと「全体像」を覚えておくのに非常に便利です。
- 自動テストは良い考えです。 jUnitなどのユニットテストフレームワークについて学びます（すべてのプログラミング言語にそのようなフレームワークが1つあり、グーグルの「ユニットテスト」です）。
- 一度に1つの機能に焦点を合わせます。複数の機能を並行して構築しないでください。
そして、本を読んだり、スクラムやアジャイルのトレーニングに参加したりする場合、これらは私が使用する部分です使用しない
- 見積もり：スタートアップが長期計画やロードマップを行う必要はめったにありません。 3か月のロードマップでさえ時代遅れになる可能性があります。だから、見積もりを気にしないでください、それは時間の無駄です。ストーリーのポイントやあらゆる種類の複雑なことについて聞くことができます。すべて忘れてください。
- 反復/スプリント：スタートアップにとってオーバーヘッドが多すぎる。
代わりに、私は次のようなことをします：
- 一枚の紙を入手してください。実装したい機能を書き留めます（これらは、前述のユーザーストーリーマッピング手法から得られます）
- 次に実装する機能を1つ選択してください
- 誰もがこの機能に取り組んでいます
- 機能を展開する
- ユーザー/顧客の反応を見てください
- 新しい学習でストーリーマップ/機能リストに戻り、必要に応じてストーリーマップ/機能リストに変更を加えます
- 手順2に戻ります
- たまに、どのように改善できるかを見てください。どのような問題がありましたか。また、何か別のことをする必要がありますか、それとも新しいプラクティスを追加する必要がありますか。
それでおしまい！あなたは今アジャイルです:)
NDC2011カンファレンスのプレゼンテーションで多くの素晴らしいガイダンスを見つけました： http://ndc2011.no/agenda.aspx?cat=1071&id=-1&day=3726 でアジャイルタグを探してくださいスケジュール。始め方は。小さなもの、できれば組織の内部使用を対象とするプロジェクトから始めます。そうすることで、プロセスを機能させるために必要な効果と選択について、より多くの洞察を得ることができます。