過去6か月間、私はPivotal Labsのニューヨークオフィスのプロジェクトで、大手銀行の1つで働かなければなりませんでした。 これは、これまで見たエンタープライズ開発全体とは大きく異なります。
最初に目を引くのは、ペアリングされた職場、ソフトウェアがプリインストールされた同一のAppleマシン、2つのキーボードと2つのモニターです。 全員がペアで働き、カップルは毎日チーム内で回転します。 明日どこに座るのか、誰と仕事をするのか、どんな話をするのかはわかりません。 チームからチームにいつでも移ることができます。
労働時間は厳しく制限されており、私たちが働いている時間の9時から半時、昼食、そして6時まで続きます。 シックスゼロワンでは無料です。
（はい、実際は見た目が怪しいようです。お気に入りのテキストエディタを静かにインストールしたり、ニュースや技術レビューを読んで半日スイングしたり、コーナーを手配したり、隣人と大騒ぎしたりすることはできません。最初の3か月間は、新しい個人の境界、入力または思考するときに誰かが見ているという事実、他の機能がどのように機能するかを半時間以上見ているが、眠りに落ちるか完全にオフになるという事実に慣れる5月 彼はあなたが上で何が起こっているか知っていることを想定しているためだ。あなたがいる場合は、声を出して、各ステップを説明します）。
したがって、あなたに残っているのは、今日どのような歴史が優先されているかを彼に尋ね、それを始めることです。 すべての要件は、should-it-should形式で記述されているため、テスト仕様を簡単に作成できます。 すべての仕様は実装の前に書かれており、誰かが緊急に他の方法を望んでいる場合、パートナーは彼を修正します。 このプロセスでは、通常、テストを作成し、2番目の実装を作成し、次にその逆を作成します。
（精神的には、これは2人の警官が同じ車の中で輪になって走り、ハンバーガーを食べ、何が起こっているかについてコメントするシリーズに似ています）。
一日の終わりまでに、未完成または未完成のストーリーはWipコミットに行き、明日は他の誰かがそれを開始できます。 通常、1日で1つのストーリーを終了し、2つ目のストーリーを開始することもあります。ストーリーは数日間にわたって広がり、ストーリーを保持できません。 どちらもコミットにサインインしますが、誰かを罰することはありません。なぜなら、2人は危険な変更を行うことはめったにないからです。明日には単純に書き換えられます。
Jenkinsには常にテストが含まれています。 乙女に何かを殺すことは考えられない、パートナーは理解しません。 テストなしで何かをコミットする場合も、誰もそれが何であるかを理解することはなく、ほとんどの場合、単純にロールバックします。 仕様で理解できないものを書く-も。 そのため、仕様は常にチケットトラッカーの内容を反映し、コードは仕様が記述されたとおりに機能します。 テストをコミットするだけです-明日、他の誰かが実装を書くでしょう。
すべての仕様は、外部サービスへの依存を除外するために、抽象形式で記述され、モック実装を含める必要があります。 「外部サービスのデータが更新されるため、テストが中断する」ということは起こりません。
特定の技術スタックは重要ではなく、プロジェクトによって異なります。たとえば、現在のサイクルは次のようになります
jira-ticket >> selenium feature spec >> enzyme\jest spec >> react\redux mock implementation >> react/redux real implementation >> spring boot backend service spec >> backend mock implementation >> spring boot backend real test with oracle \ mq \ whatever
Uiは常に消費者主導の契約を使用します。つまり、データベースにあるものからではなく、フォームに表示したいものから踊っています。
通常、「10個のフィールドでフォームを描画し、検証してデータベースに送信する」ように見えるストーリーは、500から1000のテストをカバーする10から20のストーリーのように見え始めます。 フォームにフィールドを配置することは1つのストーリーです。 入力のフォーマットは別です。 バックエンドからのデータを表示-3番目。 4番目は、バックエンドデータをデータベースにバインドすることです。 情報不足のためにブロックがどこかにある場合、バックログの状態はブロックによって正確に表示され、「スプリントからスプリントへと移動する100ポイントの履歴のバックログがあります」。 すべてのストーリーはユーザーが作成したものであり、ユーザーの価値を伴わない「データベースリファクタリング」シリーズのストーリーはありません。
実際、バグは同時に評価されず、バックログを詰まらせることはありません。バグが表示されます-修復、フィード、それが指すストーリーをマークします。 とても健康的です。
個人的には、このようなシステムが実装に関する議論を実質的に誰にとっても面白くない段階に押しやることができてうれしいです。 どのデータベースが必要かわからない場合は、ファイルまたはモックサービスからデータを読み取ります。 今日のベースが気に入らない場合、仕様があるため明日は新しいアダプターを作成します。
定義上、すべてのコードはレビューを通過しました。 誰かが2つのスペースでタブを書き、4つのスペースで誰かが日食とタブを持っているということは起こりません。 1つはロンボクを使用し、2つ目はプロパティをペンで書き込むことはありません。
プログラマーのレベルは良いニュースではないという事実にもかかわらず、彼らはしばしば回転し、基礎となる言語とフレームワークを非常によく知らない（これは超建設ハッキングと美しいものを除く）、彼らはすべてテストライブラリをよく知り、moki、スタブとフェイクを区別する必要があり、わかりやすい仕様を作成し、必要に応じて、独自にテストライブラリを作成できます。
最小限の改善は、便利なホットキーからgitコマンドのパラメーターやフレームワークの機能まで、ペアのローテーションを通じて即座に広がります。
ローテーションは社会的スキルの維持に大きく貢献し、実際、1人のローテーションサイクルで新しい人をすばやく引き付けることができます。通常、人はすでに何が起こっているかを理解しています。 さらに、原則として、彼はプロジェクト全体のビジョンを必要としません。 さらに、「このコードは、古い友人のVasya叔父によって書かれたものであり、削除すると気分を害することになる」という事実に恥ずかしさはありません。
回転したペアでお互いに戦うのはかなり不便なので、チームは通常、空気の平和と幸福を持っています。 したがって、一般的に、すべては友達です。
稼働中のシステムを見ると、それを実装するのがどれほど難しいか、外部からの反対がどれほどあるかがわかります。 必要なのは、主にこの方法で仕事をする準備ができており、「みんな、一日でシキを弾き、一日でケーブルをほどきましょう」、「すぐに生産に入りましょう」などの提案に妥協しない、非常に多くのマニアです。 。 そして、あなたはそれを完全に受け入れる準備ができている必要があります。 チームの1人が遅れると、ソリューションの説明を拒否したり、テストを書いたり、ストーリーを壊したりします。システムはその意味を失い、残りをやる気にさせます。 したがって、実施する意志とリソースが必要です。 システムは現在、ウォール街で急速に発展していますが、その機能の限界はまだ明確ではありません。 おそらくすぐに、少なくとも通常の銀行企業では、従来の開発方法を吸収するでしょう。