release - リリース スケジュールの実装

Question

私が働いている会社は、リリース スケジュールを実装しようとしています。私よりも構造化された環境で働いている人々から建設的なフィードバックを得たいと思っています。

1 つの製品が完成し、複数の顧客が使用していますが、さらに 4 つの製品が開発中であり、完成したかのように積極的に販売されています。（想像してみろ！）

私たちは非常に小規模な会社であり、非常に迅速に (そして時にはずさんな作業も)、締め切りも予算も限られているため、書面による要求事項や体系的な QA プロセスなどを行う余裕はありません。開発者 (私たち 3 人) にアイデアを提供し、それらを実装します。次に、対象分野の専門家が機能をテストして、アプリが本来の機能を果たしていることを確認します。

最後の段落で、あらゆる種類の「この方法ではできない」タイプのフィードバックが寄せられることはわかっていますが、それは必要ありません。このアプローチがいかに間違っているかを理解しています。ある時点で、私は所有者にプロジェクト マネージャーと QA 担当者を雇うよう説得することができましたが、しばらくして収益の損失のために両方とも解雇されました。私たちは今いる場所にいて、この時点で文化を変えることはありません.

私がやろうとしているのは、期待を管理することです。要求された機能のリストがあり、ここに私が提案したものがあります。

完成品の生産に対して四半期ごとにリリースを行います。最初のリリースは10月です。高/中/低の優先度に基づいて、今から次に何を行うかを管理しようとするのではなく、今から 9 月までに何を完了でき、何を完了できないかに基づいて機能を管理します。その時点で、すべての機能開発を停止し、テストと欠陥の修正に集中して、翌月に製品をリリースできるようにします。このプロセスを四半期ごとに繰り返します。基本的に手順は次のようになります。

1) 重要度に基づいて、すべての優れた機能を将来のリリースに配置します。2) 四半期中にこれらの機能に取り組みます。3) 新しい機能が要求されたら、特定のリリース サイクルの「キュー」に入れます。4) 機能を現在のリリースに含める必要がある場合は、他の機能を次のリリースに移動します。5) サイクル中の特定の時点で、どの機能が現在のリリースに含まれない可能性があるかを評価し、それに応じて調整します。6) 本番環境へのプッシュ予定の少なくとも 30 日前に機能の開発を終了し、テストとバグ修正に集中します。7) 予定日に何かを本番環境にプッシュし、最初に合意したすべての作業が完了していないことを熱弁します (ちょっと、私は現実的です... 私が働いている人々はそうではありません.)

あ、それと、「新しい仕事に就け」と言うつもりなら、わざわざ答えないでください。現時点では、それはオプションではありません。

この提案されたアプローチに関するアドバイス、またはこのプロセスを構築する方法をよりよく理解するのに役立つリソースへのリンクがあれば、大いに感謝します.

よろしくお願いします。

ダービス

Answer 1

プロジェクト管理や組織などが不足していることを考えると、四半期ごと（または任意の決まった日付）のリリースサイクルを強制しようとすると、問題が発生することになると思います。これは、開発に2か月以上かかる「大きな」機能があり、開発時間を考慮している場合に特に当てはまります。

私の提案は、機能ベースのリリースサイクルを実行することです。機能のキューを作成し、特定の時間枠で合理的に実行できると思う機能を決定します。これらの機能を実装し、テストのために1か月（または何でも）を与えてから、リリースします。次の機能グループに移動します。3か月ではなく2か月かかる場合は、すばらしいです。4かかる場合は、それでも構いません。

そうは言っても、私はこれを長くするのではなく、短くすることに焦点を当てたいと思います。この場合、特にQAなどを処理するための正式な手順（および人員）がないため、リリースをより多く、より小さくすることで実際に役立ちます。柔軟性を維持すると、リリースに発生する問題を修正するのに役立ちます...

Answer 2

非常に簡単に言えば、定義されたプロセスがないことを考えると、確実なリリーススケジュールを正常に実装する可能性はほとんどありません。これは悲観論だけではありませんが、私はそれがそうであることを容易に認めます。

成功が主にハードワークと少しの運に基づいているのと同じように、堅実で反復可能なリリーススケジュールはプロセスに基づいています。機能仕様や設計仕様などを用意することは、一貫した堅実なスケジュールでリリースできるようにするために非常に重要です。（人々がそのような仕様のものを持っている理由があることを知っていますか？）そしてそれはあなたがそのようなものなしであなたのスケジュールを達成して期待を解放することができないということではありません。あなたはおそらくそうすることができます。しかし、そのようなプロセスを実施することで、期待に応えることができる可能性が大幅に高まります。少なくとも部分的には、実装中に期待が「不合理な」領域に流れ込まないことが保証されるためです。

繰り返しますが、これは、上記で説明したことを実行するために必要なことを達成できないことを意味するものではありません。正直なところ、説明されているようなプロセスを実施することに積極的に敵対している環境にいる場合は、必要なことを達成するために最善の方法で作業している可能性があります。そして、私は完全に悲観的であるという意味ではありません。このようなことを成し遂げる方法をよく理解しているようです。作業しなければならないことについては、合理的なプロセスが整っているように思えます。しかし、私は事実上、あなたがたった2つのことを手に入れることができれば、あなたがより良くなることを保証することができます。1）ソフトウェアに何をさせたいかを説明する管理者からの機能仕様、および2）あなたがどのように管理するかを説明するエンジニアリングから管理者までの設計仕様 ソフトウェアが機能仕様で望むことを実行するようにします。これを自分のプロセスに適合させることさえできると思います。機能仕様は複雑である必要はありません。それらについての重要なことは、それらが書き留めて、経営陣が求めたものについての口論を防ぎます。そこにあります。また、設計仕様にも多くの時間をかける必要はありません。必要なものを（大まかに）実装する方法を管理者に知らせるための簡単なポケットベルは、聞いたことがあるという安心感を提供し、関連する複雑さを理解するのに役立ちます（ただし、行かないでください）。深すぎると、退屈して注意を失うリスクがあります）。

Answer 3

ソース管理に何を使用していますか？

私たちはSVNを使用しており、必要に応じて、次のリリースの時点で展開されるものに応じて、さまざまな異なるブランチを作成する柔軟性を備えています。リリースa1、a2、およびa3がリリースされるように設定されている場合、これらの変更を本番環境からのブランチにマージできます。a2の優先度が低くなった場合は、a2の変更のみをロールバックできます。重複がある場合は、新しいブランチを作成してa1とa3のみをマージし、a2を後のリリース用に残します。

所有者が特定のリリースの前に仕様を書き直す可能性はどのくらいありますか？私が働いている場所では、これは頻繁に発生するため、ギアをシフトしたり、必要に応じてロールバック/再マージしたりする機能が非常に役立ちます。

Answer 4

私の会社も機能要求で行き詰まります。

私たちが行ったことは、すべての機能を調べて、実装にかかる時間を見積もることです. 次に、「変更委員会」 (CEO、チーム リーダーなど) に任せて、次のスプリントで完成させる機能を提供します。

このようにして、不当に大きな作業負荷が与えられることはなく、エンド ユーザーは完了した内容について発言権を持っています。