既存のコードベースをTaigaに取り込む

既存のシステムから始める

架空の備品申請サービスが、すでに存在しています。チームは、動作している連携を維持しながら、Taigaで保守したいと考えています。

Productの作成時に、Import codebaseを選びます。リポジトリを接続し、分析を開始します。この方法では、新しいproductの会話の代わりに、リポジトリ分析を使います。ゼロから作成したproductに、後からこのインポート経路を追加することはできません。

リポジトリへのアクセスと、Taigaが対象にするブランチを確認します。適切なコンテキストのレベルに、継続的な制約を追加します。この例では、既存の従業員ID連携を引き続き使う必要があると明示します。

最初に推定された仕様をレビューする

Taigaはコードからproduct文書を生成し、リポジトリの参照箇所を含めます。その参照は、解釈を確認するために役立ちます。ただし、既存のすべてのパターンの業務上の意図を確定するものではありません。

仕様では、三つの点を確認します。

• 目的： 記載された目標は、サービスが存在する理由と一致しているか。
• 制約： どのパターンが、意図的な要件なのか。
• 既知の不具合： 現在のどの振る舞いを変えるべきか。

備品サービスには、古い認可モジュールがあります。文書が、その利用を正確に記述しているかもしれません。それでも、チームがその利用を拡張すべきだという意味にはなりません。

参照されたファイルを開き、関連する振る舞いを記述内容と比較します。リポジトリの外にある設定や運用上の振る舞いなど、利用可能な証拠の限界を記録します。

適切な修正方法を選ぶ

インポート文書はコードに追従します。将来のシステムについて、手動で更新し続ける説明書として扱わないでください。文書を更新すると、その文書が依存する文書も再生成されます。そのため、後段の文書の更新には、より多くの作業が必要になる場合があります。

古いモジュールについては、例えば「古い認可モジュールへの新しい呼び出し元を追加しないでください。新しい作業では、承認された代替インターフェースを使ってください」と指示できます。そのインターフェースが存在することを検証し、実際のリポジトリ内の場所を示します。

最初のinitiativeを評価する

インポートのワークフローでは、リポジトリのスキャン、公開済みポリシーに照らした評価、最初のinitiativeの計画も実行します。必要な前提条件がそろっていない段階は、説明とともにスキップされる場合があります。計画は、利用可能な指摘とポリシー評価を使います。

提案された不足を、リポジトリに照らしてレビューします。最初のinitiativeは、不足する機能、基盤、関連する未解決の依存関係の問題に対処します。誰も求めていない新機能の一覧ではありません。

有用な既存の機能は保ちます。不要な作り直しにつながる提案は、拒否または修正します。新しい業務要件には、別のinitiativeを追加します。

証拠に基づく出発点を保つ

Discoveryを完了し、initiativeの提案をレビューします。詳細な計画の前に、環境とデリバリーの責任を確認します。作業を進める間も、インポート、コード変更、productの指示の整合性を保ちます。

成果は、理解された出発点と、編集可能なbacklogです。既存のすべての振る舞いが正しいという宣言ではありません。続いて、initiativeの計画を学んでください。