私は小さな製品ベースの会社で働いています。既存の製品をゼロから書き直そうとしています。開発にはアジャイル手法を採用する予定です。私の質問は、プロジェクトの開始前でも既存の製品を書き直しているので、すべての要件があるので、アジャイルの世界に飛び込む価値はありますか？すべての要件を事前に用意しておらず、段階的に要件を取得する場合、アジャイルの方が便利ではありませんか？

次に、アジャイルに移行した場合、データベースを設計するためのベストプラクティスは何でしょうか。最初のイテレーションで、ログインシステムを作成したとしましょう（ユーザーはログイン、ログアウトなどができます）。他のテーブルを気にすることなく、Usersテーブルを作成する必要があるだけですか？そして、他のテーブルは私たちの製品が進歩するにつれて進化するでしょうか？

アジャイルの世界に飛び込む価値はありますか？

はい。

すべての要件が事前になく、段階的に要件が得られる場合、アジャイルの方が便利ではありませんか？

いいえ。

すべての要件がない場合は、それが進歩する唯一の方法です。それ以外のものは、最終的には誤りであると証明される空想的な仮定を必要とします。アジャイルは単に空想的な仮定を少なくします。

すべての要件がある場合でも、アジャイルのすべての原則に従う必要があります。

先に進む前にこれを読んでください：http : //agilemanifesto.org/

これらのすべての点は、要件をどの程度知っていても当てはまります。

スクラムなどのアジャイルメソッドを使用することで、より現実的な期待が得られるため、メリットがあります。

データベースを設計するためのベストプラクティスは何ですか？最初のイテレーションで、ログインシステムを作成したとしましょう（ユーザーはログイン、ログアウトなどができます）。

なんてひどい最初の繰り返しだ。

他のテーブルを気にすることなく、Usersテーブルを作成する必要があるだけですか？そして、他のテーブルは私たちの製品が進歩するにつれて進化するでしょうか？

はい。データベースを段階的に作成します。

すべてを段階的に行います。

ユーザーにとって最も価値のあるものに基づいて優先順位を付けます。空想的な（そしてばかげた）技術的な考慮事項ではありません。

私の質問は、プロジェクトの開始前でも既存の製品を書き直しているので、すべての要件があるので、アジャイルの世界に飛び込む価値はありますか？

はい。ただし、アプリケーションの現在の設計方法にはいくつかの変更が加えられる可能性があると思いますが、これは、既知の情報を考慮して、よりクリーンな設計を行うためのさまざまな技術的負債を解消するときになるためです。

すべての要件が事前になく、段階的に要件を取得する場合、アジャイルの方が便利ではありませんか？

アプリケーションを再度ビルドしても、これらの要件が変更されないという確信はどのくらいありますか？取得するデザインがリファクタリングされないことを確信していますか？

次に、アジャイルに移行した場合、データベースを設計するためのベストプラクティスは何でしょうか。最初のイテレーションで、ログインシステムを作成したとしましょう（ユーザーはログイン、ログアウトなどができます）。他のテーブルを気にすることなく、Usersテーブルを作成する必要があるだけですか？そして、他のテーブルは私たちの製品が進歩するにつれて進化するでしょうか？

ここにはさまざまなオプションがたくさんあります。それが機能するのに十分なだけ行います。ユーザーテーブルが必要なすべての場合、素晴らしいです。他に必要なテーブルがいくつかあるため、DBがより正規化された形式になっている場合は、その方が適切な場合があります。初めて完璧になることはありません。アジャイルは、試行錯誤のような方法論に関するものです。ユーザーが持っているものを示すと、アジャイルを継続させるためのフィードバックが得られることがよくあります...（また、新しい人々はそれからものも求め始めるかもしれないので、要件が来るでしょう）

私は小さな製品ベースの会社で働いています。既存の製品をゼロから書き直そうとしています。開発にはアジャイル手法を採用する予定です。私の質問は、プロジェクトの開始前でも既存の製品を書き直しているので、すべての要件があるので、アジャイルの世界に飛び込む価値はありますか？

アジャイルプラクティスの使用を計画している小さな会社（経営陣）は、通常、採用を推進する開発者であるため、優れた出発点にあります。チームレベルで採用を推進し続けることをいとわないリーダーを特定することをお勧めします（トレーニング、制度化など）。

要件を把握したら、1回の反復で何が見たいかをユーザーに尋ねます。その後、お届けします。次のイテレーションを繰り返します。あなたの仕事に早く触れることができるユーザーは、あなたが行くにつれて要件を洗練するのを助けます。現在、自動化されたプロセスがない場合、またはチームが継続的な開発を理解していない場合は、スケジュールを立てて、プロセスが確実に実行されるようにします。

アジャイルはあらゆる開発プロジェクトに適用可能であり、特に要件がまだ指定されていない完全なグリーンフィールドプロジェクトには適用できません。アジャイルプロジェクト管理では、小さなステップを踏み、ステップを頻繁に見直し、次のステップを改善することで、プロジェクトを自己学習し、自己改善します。アジャイルに関するブログはたくさんあります。グーグルはあなたの友達です...

アジャイルデータベース開発に関する特定の質問については、あなたは正しい方向に進んでいます。最初は残りを気にせずにユーザー管理を開発できます。プロジェクトにさらに進んだ場合、それはおそらくいくつかのやり直しに終わるでしょうが、それは小さな集中的な反復を行うコストと見なすことができます。中途半端なアプローチでは、データベースモデルを少し前もって調査し、いくつかのスプリントを先に進めることができる設計を作成します。そうすれば、手直しが減ります。

次に、アジャイルに移行した場合、データベースを設計するためのベストプラクティスは何でしょうか。最初のイテレーションで、ログインシステムを作成したとしましょう（ユーザーはログイン、ログアウトなどができます）。他のテーブルを気にすることなく、Usersテーブルを作成する必要があるだけですか？そして、他のテーブルは私たちの製品が進歩するにつれて進化するでしょうか？

このアプローチをやり過ぎないように注意してください。それは家を建てて、基礎がまだ設定されている間に1つのバスルームを完全に仕上げようとするようなものです。おそらく、アプリケーションの基盤、データベース、および基礎となるオブジェクトモデルが成熟していないか、構造をサポートするのに十分安定していない場合、作業のかなりの部分を完全にやり直す必要があるでしょう。

また、アジャイル/スクラムを使用していると言っても、適切なユニットテストや堅固なデータベースやオブジェクトの設計など、優れたソフトウェアエンジニアリング手法を使用することを言い訳するものではありません。アジャイルが誤って適用されると、コードに簡単に陥り、非常に苦痛であるか、回復が不可能でさえある可能性のある死のスパイラルプロジェクトを修正できます。

アジャイルとは、生産性と柔軟性の向上です。なぜアプリケーションを書き直すのですか？理由は次のとおりです。

1. プラットフォームの変更（WindowsからLinuxなど）
2. 言語の変更（ASP.NETからPHPなど）
3. リファクタリング量が非常に多いため、リライティングはコスト削減オプションになります
4. ビジネスは大きく変わったので、実際には新しいアプリケーション（必要に応じて、同じテーマに基づいた新しい曲）を作成しています。

これらの理由のいずれかで、あなたはあなたの製品を一晩で配達することはありません、そしてもちろんそれは時間がかかります。

製品のバックログを持つことは、アジャイルが推奨する項目の1つにすぎません。何について言う全体のビジネスを知っすでに製品バックログに多くのPBISのを持っていることを意味します。

しかし、すべてのスプリントの最後に新製品の一部を納品する方がいいのではないでしょうか。それはあなたがより機敏になり、変化に敏感になるのではないでしょうか。たとえば、新しいアプリケーションを美しくしようとしているとします。新しいデザインが受け入れられないことを10か月後に知っておくのは悪いことではありませんか？2〜3週間後にそのことを聞かされたら、それは良い習慣ではないでしょうか。

あなたの質問に対する私の答えは：

アジャイル開発には、書き換えられたアプリケーションであっても、明らかに多くの機能があります。

アジャイルの世界に飛び込む価値はありますか？

多分。特にすべての人にとって新しいものである場合は特に、何か新しいことを試みることはリスクを伴います。個人的には、アジャイルが正しく実行されたときに役立つと思います。

すべての要件が事前になく、段階的に要件が得られる場合、アジャイルの方が便利ではありませんか？

要件がまだない場合は、要件を促進するのに役立ちます。ただし、これは、ユーティリティが運転要件のみに限定されていることを意味するものではありません。

データベースを設計するためのベストプラクティスは何ですか？

繰り返します。データベースの移行を使用します。

提案

• アジャイルを実行したい場合は、それは素晴らしいことです。以前にそれを行った人にプロセスを手伝ってもらいます。

• 最初にアジャイルを試すとき、人々はしばしばリファクタリングのステップを無視します。しない。プロジェクトを強制終了します。

• レイヤーではなく、垂直方向のスライス（機能）について考えます。垂直スライスを実装して、最初の機能カードが完了した後にシステムが機能するようにします。機能したら、機能を維持し、各機能カードに追加します。

古いアプリケーションから新しいアプリケーションのセットと新しいアーキテクチャへの移行を伴うプロジェクトでアジャイルを使用してきました。既存のアプリケーション（販売、財務、調達、倉庫部門で内部的に使用されている）をやり直そうとしているだけでなく、途中で各部門のエクスペリエンスを改善しようとしているという点で、状況は少し異なります。アジャイルを使用して見た1つの課題は、特定のビジネスユニットの機能の一部を移動することのビジネス価値は高いが、他の部分は低いということです。そのため、移行中に新しいアプリケーションを作成し、古いアプリケーションを実行し続けることができます。ある「顧客」を完全に新しいアプリケーションに移行することに集中することの価値をビジネスに理解させるのに苦労しています。しかし、私たちはスプリントに多くの高価値のストーリーを取り入れています。一度に1つのユニットに焦点を当てる必要があることをビジネスに納得させなければならないとき、私たちはすぐにやっとパイントになると思います。

したがって、元の質問に答えるには、はい、アジャイルは良い方法です。途中でいくつかの依存関係が発生し、チームの決定のいくつかを導くように準備します。

最も重要なのは、スクラムプロセスが役立つことです。あなたの仕事がもっと良くなるなら、それを取ってください。しかし、あなたがそれを試さない限り、あなたは決してわかりません。

もう一つのポイントは、本でスクラム処理をする必要がないということです。うまくいくものを選んでください。たとえば、私たちのチームにはスクラムボードがありません。必要ないからです。

設計については、将来の変更に時間がかからないように設計してください。システムは堅牢でなければなりません。