最近、別の請負業者との協力を継続することを拒否したクライアントが当社に来ました。 理由は標準です。 開発者はブラックボックスの原則に基づいて製品を作成しました。タスクのリストが決定され、すべての作業を行った後、クライアントに発生したすべてをすぐに展開しました。 したがって、多くの問題、クライアントへの絶え間ない不信、なぜなら 彼は、チームが今回何をしていたか、本当にそんなに時間を必要としているか、もしそうなら、その結果、クライアントがまだ満足していない理由を理解していません。 その結果、製品はクライアントが期待するものではなく、関係と評判が損なわれました。 両方の損失状況。
私たちは、透明性のある開発プロセスを整理することにより、状況を修正することができました。 前の請負業者と仕事をするとき、顧客はビジネスに専念するのではなく、プロジェクトの技術コンポーネントに多くの時間を費やし、開発者の絶え間ないチェックに従事しなければなりませんでした。 これで、クライアントはいつでもプロジェクトがどの段階にあるかを理解し、作業の進行状況を調整できるようになり、迅速なフィードバックを得ることができます。
私たちは、私たちが成功裏に適用するいくつかの柔軟なソフトウェア開発方法論の組み合わせの中で最も成功したバージョンを開発しました（詳細が変更され、特定のプロジェクトに適応する場合もあります）。 私たちのプロセスの主な構成要素を以下に説明します。これは、私の意見では、開発者とクライアント間の信頼関係の確立の速度に他の影響よりも大きく影響します。
透明度を追加する方法は？
柔軟な開発方法論が助けになります。 私の経験では、チームは厳密に1つの方法論、たとえばスクラムまたはかんばんを厳守することはありません。ほとんどの場合、各チームは異なる方法論のプラクティスの組み合わせを単純に適合させます。 たとえば、Planning Pokerを除く、極端なプログラミングのほとんどすべてのトリックを使用します。 方法論の適応によるこのような実験の結果として、チームに最適なプロセスが構築されます。
前のチームの開発プロセスの弱点を理解し、クライアントとのやり取りに直接関連するいくつかの重要なコンポーネントを導入することで、それらを排除しました。 以下が最も重要なものです。
頻繁なリリース
プロセスは次のように構成されました。 現在の段階で実行する必要がある特定の機能セットを計画しています。 たとえば、作業量は開発の月に対応しますが、これにより製品リリースが毎週（実際には毎日）リリースされ、新しい機能が1回ではなく徐々に追加されます。 したがって、1か月ではなく、1つではなく4つの更新をリリースします。 これにより、フィードバックを受け取り、できる限り迅速にフィードバックすることができます。
継続的インテグレーション
継続的な統合は、品質開発の不可欠な部分です。 すべての変更は、完全に組み立てられた形式でテストベンチに自動的に到達し、QAエンジニアが確認する必要があります。 この場合、主に2つの理由があります。フィードバックと顧客です。 何かがうまくいかなかったことをできるだけ早く理解することは、非常に重要でした。 さらに、クライアントがいつでも製品の最新バージョンにアクセスできるようになると（常に100％動作するとは限りません）、一般的に顧客の忠誠心にプラスの影響を与えます。
正しいボード
まず第一に、開発プロセスが反映されるボードは一般的に:)であるべきです。しかし、ステータスによるボードの誤った分割はプロジェクトにマイナスの影響を与える可能性があります。 タスクがボードに沿って「進む」とき、タスクに正確に何が起こり、どのようなステータスにあるかは間違いないはずです。 このプロジェクトでは、次の列が定義されました。バックログ-Todo-作業中-完了-テスト-解決済み-デプロイ。 別のケースでは、ほとんどの場合、別のセットがあります。 これらの列が問題の自然な経過に対応し、曖昧でないことが重要です。
QAエンジニア
製品全体の品質を担当するQAエンジニアは、チームに接続する必要があります。 これは、タスクの説明に従ってシステムを「突く」だけのテスターではありません。 これは、システムを使用するすべてのシナリオを完全に実行し、新しいタスクをテストし、回帰テストを実行する人です。 彼の仕事は主に製品の品質を決定するので、そのような人は仕事に関与しなければなりません。
スタンドアップミーティング
スタンドアップラリー-誰もがそれらについて知っていますが、実際には誰もがそれらを使用しているわけではありません。 15分以内のこれらのミニミーティングは、チームおよびプロジェクト全体にとって大きなメリットがあります。 毎朝（または正午前に）クライアントとSkypeを呼び出し、チームの各メンバーが昨日何をしたか、どのような問題が発生したか、どのように解決または解決するか、そして今日行われることをサブスクライブします。 このプラクティスは、とりわけ、クライアントとチームの間の信頼レベルを徐々に高めます。 [ところで、かんばんでは、スタンドアップが異なります]
デモ
各反復の終了後、クライアントに対して行われた作業を実証する必要があります。 完了または修正されたすべてを表示する必要があります。 クライアントがすべてを自分で見ることができるdev-serverへのリンクを与えるだけでなく、実証します。 彼は自分でそれを見ますが、デモの後です。 フィードバックをすぐに得ることが重要であり、おそらく何らかの議論を行うことが重要です。 デモンストレーションは非常に重要なコンポーネントです。 楽しくエキサイティング。 チーム全体が参加しますが、誰かが単独で、チームリーダーまたはQAエンジニアを直接示します。
おわりに
この記事では、ソフトウェア開発プロセスのいくつかの重要なコンポーネントをリストしました。これらのコンポーネントにより、他のチームとの経験が乏しいクライアントとの忠実な関係を構築できました。 もちろん、柔軟な方法論ははるかに異なる方法を提供しますが、その多くが使用していますが、ここでは、私の意見では、透明なプロセスとパフォーマーとの顧客信頼を構築するために他の方法よりも重要な方法を正確に引用しました。
同様の手法を実行し、高いテンポを維持するために、開発チームは十分に高いレベルである必要があることも注目に値します。 これは、極端なプログラミング手法の場合に特に当てはまります。その主なポイントは、特にエンジニアリングコンポーネントを対象としています。
ご清聴ありがとうございました。 まだ完全にセットアップされていないプロセスでチームを開始するために、この記事が役立つことを願っています。
参照資料
スクラムとかんばん：最大のスクイーズ、H。KnibergとM. Skarin 。
エクストリームプログラミング、C。ベック 。
無駄のないソフトウェア制作、M。ポペンディクとT.ポペンディク 。