機能のリリースを2倍の速さで開始した方法（ケーススタディ）

企業が日常業務をアプリに依存している場合、ニーズに迅速に対応するために十分な機敏性が必要です。 そうしないと、他の人は間違いなくそうします。 容赦のないSaaSの世界では、重要な機能を遅らせる（またはバグの多いコードを急ぐ）と、クライアントを失うことになります。 堅実なアジャイルワークフローは、すべての違いを生むことができます。

私たちはActiveCollabの背後にあるチームです。これは、増え続ける一連の機能とかなりのユーザーベースを備えたプロジェクト管理アプリです。 これは、機能のわずかな変更でさえ、多くの人々に影響を与えることを意味します。

SmashingMagの詳細：

• 忠実なユーザーを傷つけることなく新機能を展開する方法
• ウェブサイト立ち上げチェックリスト–公開する前の15の重要なチェック
• モバイルデバイスのWebデザインへのユーザー中心のアプローチ
• 何かを起動する方法
  

したがって、開発プロセスは、遅延を最小限に抑えて、スムーズかつ標準まで実行する必要があります。 変更がエンドユーザーに反映される前に、フィードバック、設計、開発、品質保証、および展開という5つの重要なフェーズを経ます。 この記事では、8年以上のビジネスの各段階について私たちが学んだこと（難しい方法）を共有します。

ウェイクアップコール

詳細に入る前に、これがどのようにして起こったのかを見てみましょう。 十分な精査なしに何年にもわたって機能を追加した後、私たちのアプリは機能の肥大化に苦しんでいました。 何年にもわたって非常に多くの機能を追加してきたため、新しいユーザーはUIの非常に複雑なことに恐れを感じていました（二度と戻ってこない）。 すべての機能を最初から書き直すことを意味する場合でも、ゼロから再構築する必要があることはわかっていました。

その後、遅延が発生しました。 新しいバージョンの機能は常に予定より遅れていました。 たとえば、ジュニア開発者はQuickBooksとの統合を開発することになっています。 必要な複雑さ、スキル、知識を正確に予測することはできませんでした。 さらに、彼はそのタスクに割り当てられた唯一の人であり、誰も彼を助けるためにすぐに飛び込むことができませんでした。 その結果、2週間の仕事になるはずだったのに5週間かかることになりました。 それらはいくつかの危険信号でした。

明らかに、より機敏なアプローチに切り替える時が来ました。 私たちはさまざまなアジャイル（そしてそれほどアジャイルではない）方法から好きなものを取り入れ、それを経験と組み合わせて、それ以来素晴らしい結果をもたらしている独自のバージョンを考え出しました。

機能がエンドユーザーに提供される前に移動しなければならない道を詳しく見てみましょう。

提案から機能まで

私たちのワークフローでは、新機能は開発チームに届くずっと前に形になり始め、通常はユーザーのフィードバックから生まれます。 これは偶然ではありません。以前は、誰も必要としない機能をリリースしていました。通常、1人のユーザーが特に騒々しかったか、何かがあれば素晴らしいと思ったからです。 ユーザーが必要とする可能性のある機能を想像する代わりに、実際の需要に基づいて決定を下すようになりました。

リーン生産方式に興味がある場合、お客様は特定の機能を他の機能よりも頻繁に要求することで「プル」すると言うでしょう。 私たちのサポートチームとセールスチームは、ニーズやアイデアを共有するユーザーと常に連絡を取り合っているため、プロセスの大きな部分を占めています。

フィードバックに基づいて、私たちのチームは次のようなフォームを更新します。

必要な情報がすべて揃っていない場合は、お客様に直接ご連絡いたします。 これは通常、慎重に選択されたサンプルに対する対象を絞った調査で行われます。 重要なのは、私たちが耳を傾けることです。 フィードバックが失われることはありません。 それは常に認められ、文書化されています。

次のステップは分析です。 毎月スコアを集計して、どの機能が最も多くの票を獲得したかを確認します。 また、適切に分類することで、ソフトウェアのどの部分で作業が必要かについて、より広い視野を得ることができます。 たとえば、カレンダーに多くの苦情が寄せられている場合は、投票数が最も多い機能（カレンダーのエクスポートなど）を導入するのではなく、セクション全体を刷新することを検討します。

ただし、結果が出たとしても、機能を導入するかどうかの決定は最終的なものではありません。 それがやることリストに載る前に、私たちは常に徹底的な健全性チェックを行います。

• この機能はユーザーにどのようなメリットをもたらしますか？
• それは私たちの製品哲学に適合していますか？
• それは不必要な複雑さを追加しますか？
• 既存のインターフェースや機能とうまく調和していますか？
• 妥当な時間枠でそれを提供するためのリソースがありますか？

機能がチェックリストに合格し、製品の所有者がそれを承認したら、設計図に進みます。

ユーザーのためのデザイン

経験から、新しい機能を追加することは、それをUIの上に貼り付けることだけではなく、ユーザーを念頭に置いて既存のデザインとブレンドする必要があることがわかりました。 これを行わないと、すぐにアプリが非常に複雑になり、トライアルの最初の5分間で成功するのは勇敢な人だけになります（はい、私たちはそこにいました）。 美学も良い第一印象のために重要ですが、私たちの主な関心事は使いやすさです。 ユーザーにとって自然に感じる方法で機能を追加する必要があります。

ユーザーはこのオプションがどこにあると期待するのでしょうか。

既存のユーザーにとって、新しいデザインが使い慣れたパターンに従い、ワークフローを中断させないことが重要です。 また、私たち全員が（無意識のうちに）慣れている業界標準や慣習があります。 ユーザーが習慣を完全に変えることを期待しないでください。 インターフェースが直感的でない場合、彼らは他の場所を見る可能性が高くなります。

キーボードショートカットを使用します。 独自のショートカットのセットを作成し、ユーザーがそれらを学習することを期待できます（おそらく学習しないでしょう）。 または、人々がすでに使用しているものを追加することもできます。 たとえば、多くのユーザーがすでにSlackを使用しているため、使い慣れたショートカットを追加しました（ ActiveCollabでもクイックジャンプ用のCommand + Kが機能します）。

ユーザーフローが整ったら、UXデザイナーがSketchでデザインをモックアップします。 初期段階でHTMLを使用することはめったにありません。 よく考えられたSketchの視覚化により、コーディングを開始するときにバックトラックを実行する必要がないほどの柔軟性が得られます。 通常、初期設計は最終製品の約80％に一致します。 残りは途中で追加および調整されます。

設計プロセスのもう1つの重要なステップは、コピーです。 私たちのコピーライターは、すべての単語に多大な注意を払っています。 できるだけ親しみやすく、理解しやすい独自のスタイルガイドもあります。 たとえば、「SSL証明書」の代わりに「セキュリティ証明書」と言うことは、一般のユーザーがなじみのないことを素人の言葉で伝えます。

これがすべて完了すると、機能が開発チームに割り当てられます。 チームは、プロジェクトマネージャー、リード開発者、およびワークロードに応じて多数のバックエンドおよびフロントエンド開発者で構成されます。 プロジェクトマネージャーは、すべてがスムーズかつスケジュールどおりに実行されるようにし、リード開発者が技術的な側面を担当します。 彼らはまた、ジュニア開発者を調整し、指導します。

物事をキックオフする時間

私たちのキックオフミーティングは、やる気を起こさせるような集まりではありません。 これらは、開発チーム（ジュニアおよびシニア開発者で構成される）がプロジェクトマネージャーおよび製品所有者と会う機会です。

空の独白を許可する代わりに、私たちは皆の言葉を実行可能なタスクに入れることに焦点を合わせています。 1日を通して、 3つの重要な会議が開催されます。

• プロダクトオーナーは、チームに特定の機能、その背後にあるアイデア、初期設計、および期待される結果を提示します。
• 次に、チームは独自の会議を開き、アクションプラン、潜在的な問題、およびテストスケジュールについて話し合います。
• 最終会議には関係者全員が参加し、計画が最終的に形作られます。 この会議の終わりに、チームはデモの見積もりと最終的な期日を示します。

1日で3回の会議は大変なことのように聞こえるかもしれませんが、それが問題を早期に解決する方法です。 この段階で空白を埋めることで、開発者は多くの時間を節約でき、誤った開始とバックトラックが発生します。 会議はまた、チームワークを奨励し、誰もが自分の貢献が歓迎されていると感じさせます。

会議後、チームは必要なすべての情報を入手します。

1. 何？ これは機能の範囲であり、実行する必要のあるすべてのものと、潜在的なブロッカーおよびボトルネックが含まれます。 できるだけ多くのシナリオとエッジケースを予測するようにしています。 それらすべてを予測することは簡単ではありません。 彼らは私たちが行くにつれてしばしば出てきます。
2. なんで？ プロダクトオーナーは、機能のビジネス価値を見積もり、努力する価値がある理由を説明します。 このようにして、チームは顧客と製品へのメリットを明確に把握できます。 ここでの主な動機は、誰もが自分の仕事が重要である理由と、それが会社全体にどのように貢献するかを理解する必要があるということです。
3. どのように？ 機能を完了するために必要な手順の概要を説明することで、開発者がコンパスを紛失しないようにします。 また、複雑さのタグを追加することで現実的な期待を設定します。 Tシャツのサイズを採用しました。Sは数時間以内に解決できますが、XXLは完了するまでに数週間以上かかります。
4. WHO？ チームリーダーは、機能またはタスクを時間どおりに完了し、進捗状況について製品所有者を更新する責任があります。 他のチームメンバーは独自のサブタスクのセットに割り当てられているため、誰が何に責任があるかが完全に明確になります。 これを可能な限り透明に保つことは、誰かが苦労しているか、遅延を引き起こしているかどうかを確認するのに役立ちます。
5. いつ？ すべてを考慮して、期日が見積もられます。 タスクが遅れた場合は、その理由を分析し、次回はその経験を利用します。 そうすれば、締め切りに間に合わなかったことが学習の機会になり、ストレスの原因にはなりません。

キックオフの日は忙しくなることがありますが、それはまた非常に実り多いものです。 誰もがアイデアやコメントを提案します。 タスクは、コメント、編集、更新のために空のスレートからハブに変換されます。 1日の終わりまでに、開発チームは、今後の作業の明確な全体像と、基盤となる確固たる基盤を手に入れます。

作業を開始する前に、このチェックリストを確認します。

• 機能の説明、
• 完了の手順の概要、
• プロダクトオーナーによって割り当てられたビジネス価値、
• チームによって割り当てられた複雑さ、
• 機能とバグの依存関係が特定され、
• 特定されたパフォーマンス基準（必要な場合）、
• デモが予定されています
• チームリーダーが設定した開始日と終了日。

これは、タスクが「進行中」列に移動する瞬間です。

コーディングの時間です！

展示中のチームワーク

私たちの開発者は決して一人で作業することはありません—それは常にチームの努力であり、それは新機能をリリースするためのはるかに効率的な方法です。 チームが導入される前は、（ジュニアの）開発者は問題に悩まされ、何日も（誰も気付かずに）輪になって回っていたかもしれません。 または、彼らがローンレンジャータイプでなければ、彼らは常に同僚やマネージャーの気を散らしていたでしょう。

一方、チームでは、さまざまなスキルセットと経験レベルを持つ人々を混ぜ合わせます。 これは、全員に自分のレベルに適した一連のタスクが割り当てられることを意味します。 さらに、シニアはジュニアチームメイトを管理および指導する方法を学ぶという利点を得ることができ、ジュニアは助けを求めることができます。 これはチームの努力であり、全員が同じ目標に向かって取り組んでいるため、質問は気を散らすものとは見なされず、チームはあらゆる問題にはるかに効率的に取り組むことができます。 チームは自己組織化されたエンティティになり、作業をフェーズ（またはスプリント）に分割し、デモ中に作業を提示します。

表示して伝えます

スケジュールに従って、チームはプロダクトオーナーのためにデモを行います。 デモの目的は、機能が現在の状態でどれだけうまく機能しているか、そしてどこでさらに磨きをかける必要があるかを示すことです。 これは、「最後の仕上げが数回必要なだけです」（さらに1か月かかるタッチ）などの言い訳を許さない現実のチェックです。 また、物事が間違った方向に進み始めた場合、製品の所有者は迅速に対応するようになります。

毎週の会議

まず、すべての開発者が参加する定期的な短い毎日の会議から始めました。 各開発者は、彼らが取り組んでいること、彼らの問題、彼らのブロッカー、そして彼らが助けを必要としているかどうかを簡単に説明しました。 これらの会議はより焦点を絞り、具体的な結果を提供する必要があることがすぐに明らかになりました。 そこで、週に1回程度、個々のチームとのミーティングに切り替えました。 これは、製品所有者とプロジェクトマネージャーがループにとどまり、すべての潜在的な問題がその場で処理される方法です。

それをテストする

コードが書かれ、デモは成功し、すべてがうまくまとめられているようです…機能をリリースしてアプリがクラッシュするのを確認するまで。 そのため、私たちが作成するすべての機能は品質保証（Q / A）を受けています。 いつも。 私たちのテスターは、考えられるすべてのシナリオを綿密に調べ、すべてのオプションをチェックし、さまざまな環境でテストを実行します。 機能が最初にQ / Aを通過することはめったにありません。

生産性を向上させるために、以前はこのフェーズで開発者が新機能を開始できるようにしましたが、その結果、多くの遅延した、半分完成した機能が発生しました。 そのため、現在、開発チームは、機能のレビュー中に小さなメンテナンスタスクに取り組むことで忙しくしています。 Q / Aで問題が見つかった場合、開発者はすぐに問題を修正して再送信します。 このプロセスは、機能がQ / Aに合格し、コードレビューに進むまで繰り返されます。

これは、上級開発者がコードが当社の標準に従って記述されていることを確認するときです。 リリース前の最後のステップは、ドキュメントを作成することです。誰も使用方法を知らない機能をリリースした後、サポートメールに圧倒されたくないでしょう。 また、コピーライターはリリースノートを更新し、電子メールのお知らせやブログ投稿などのマーケティング資料を作成します。

「完了」の定義は次のとおりです。

• 書かれた自動テスト、
• Q / Aが完了し、結果として得られるすべてのタスクが完了しました。
• コードレビューが完了し、コードがマスターにマージされました。
• リリースノートが更新され、
• 機能とバグの依存関係が特定されました。

タスクは「リリースQ」と呼ばれる最終段階に達しました。

リリース日

新しいリリースの日を選択するとき、私たちはすぐに金曜日と月曜日に反対することにしました。 潜在的な問題は月曜日まで解決されないため、金曜日は良くありません。 さらに、サポートチームはその時すでにかなり忙しかった。 メジャーアップデートには準備が必要であり、週末に行う必要があるため、月曜日は最適な時間ではありません。 最終的な修正のために1日を残すことは常に良いことです。 これにより、オプションが3日間に絞り込まれ、火曜日になりました。 理由は次のとおりです。

• 月曜日にリリースを確認し、展開する前に最後の仕上げを追加する必要があります。
• 翻訳されていないフレーズがある場合（当社のWebアプリは7つの言語で利用可能です）、翻訳を完了するのに十分な時間があります。
• マーケティングチームには、ソーシャルメディアを介してニュースレターやお知らせを送信するための十分な時間があります。
• 残りの週は、アップグレードサポートを迅速かつ効率的に提供できます。
• なんらかの理由で締め切りが過ぎた場合でも、水曜日または木曜日に作業を完了する必要があります。

無料アクティビティデー

メジャーリリースの翌日は、チームにとって自由な日です。 これは、彼らが新しいスキルを習得したり、仕事に関連して面白いと思うことをしたりするときです。 誰もが次の日に開始する機能を知りたがっていますが、チームはまだそれについて話し合っていません。 代わりに、彼らはリラックスしてErlangの歴史についてのプレゼンテーションを見たり、PSR-7とミドルウェアが現代のPHP開発にとって重要である理由についての記事を読み終えたり、独自の回顧的な議論をしたりします。 彼らのバッテリーを充電し、よくやった仕事を祝うのにふさわしい日です。

バグハントデー

主要な新機能の開発とは別に、既存の機能に対して行うべき作業が常にあります。 バグ修正、設計の更新、機能の小さな変更など、チームは妥当な時間内にそれを処理する必要があります。

これが、少なくとも月に1回はバグハンティングの日がある理由です。 それは、すべての開発者がメインプロジェクトでの作業をやめ、メンテナンスに注意を向けるときです。 この集中的な取り組みは大成功であることが証明されています。 全員が同じ日にバグだけに取り組み、互いに助け合うことができる場合、チームは膨大な数の問題を解決します。

結果は何ですか？

大きな機能のリリースには、キックオフから開発、テスト、コードレビュー、ドキュメント、最終リリースまで、平均して約3週間かかります。 同等の複雑さの機能は、45日かかっていました。 私たちの観点からすると、これは生産性の100％の向上です。 同じリソースと人員でそれを達成しましたが、唯一の違いはワークフローの改善です。

ですから、私たちがあなたのために1つの持ち帰りを持っているなら、それはこれです：変化の恐れを排除する企業文化を育むことはあなたのチームがそれが何をするかでより良くなるでしょう。 それがあなたの会社の成長を助ける限り、あなたがそれをスクラム、かんばん、またはリーンと呼ぶかどうかは関係ありません。 実験と革新は、アジャイルアプローチの中心にあります。 さまざまなソリューションをテストし、結果を測定し、その結果に基づいて既存のプラクティスを変更することを恐れないでください。 良い結果が続きます。