ユーザーストーリーに基づくバックエンド開発者

バックエンド開発をユーザーストーリーに垂直に分割することを計画しました。しかし、私たちのチームのバックエンドの男は、これにより彼らの仕事が見えなくなると不平を言い始めました。

私の答えは

• スプリントの計画とレビューのミーティングでは、関係者の前でバックエンドのタスクについて話し合い、それが見えるようにします。

• プロジェクト中に高品質を維持すると、他のチームよりも起動のペースが遅くなりますが、プロジェクト中は速度が安定します。そして、速度は利害関係者に非常によく見えます。

「開発者として、ビジネスロジックをカプセル化できるように、ドメインレイヤーを用意する必要があります。」

チームを汚染する前に問題を解決するにはどうすればよいですか？

問題の根本は、私たちの経営陣が体系的にバックエンドの仕事を目に見えないものと見なし、支援された開発者の鉱夫やその他の軽蔑的な言葉を呼ぶことです。

説明されている状況にはいくつかの問題があります。明らかな問題は、バックエンドの開発者への尊敬の欠如です。この質問にはアジャイルのタグが付いているので、これは社会問題にすぎないことを示唆する他の回答を押し戻します。ストーリーには悪臭やアンチパターンがいくつかありますが、どれも無知な管理やストーリーのスライス方法とは関係ありません。

チームのメンバーのグループが仕事から栄光を得られなかったことで軽視されているという事実は、いくつかの考えられる問題のスマックを完了しました。

• バックエンドの開発のみを行う人がいてはいけません。 一般的なアジャイルアプローチは、共有コードの所有権を実践する一般化された専門家で構成された部門横断的なチームを持つことです。個人は、バックエンドまたはフロントエンドの開発だけに専念するべきではありませんが、確かに、他の人よりも経験や知識が優れている場合があります。
• 建築は価値を生み出しません。 ユーザーの観点から-本当に重要な唯一の視点-レイヤーやドメイン言語があるかどうか、またはソリューションがプログラムされているかどうかは関係ありません。重要なのは、ユーザーに価値をもたらしたかどうかだけです。バックエンド開発者から提案された「ストーリー」はナンセンスな要件です。これは、ユーザー/顧客の観点から、必要な機能を実現するために何もしないという設計決定の要約です。つまり、特定のユーザーストーリーは、任意の数の異なるアーキテクチャ設計によって達成される可能性があります。ユーザーストーリーは、バックエンドをまったく変更せずに完了する可能性があります。これはそれを無効な話にしない。
• 体系的に考えることは依然として重要です。 アーキテクチャは価値を生み出さないかもしれませんが、それでも成功には不可欠です。バックエンド開発者にはいくつかの正当な懸念があります。どのようにシステムを構築するかについて考える必要があります。あなたはそれらの決定を書き留めるべきです。フロントエンドの機能だけがすべての栄光を得るものであるとしても、システム全体が重要です。

私の推奨は、建築をファーストクラスの市民として扱うことです。ただし、正しい方法で行ってください。実行品質は、利害関係者とのワークショップを属性。アーキテクチャレビューに主要な関係者を関与させるか、少なくとも重要なマイルストーンで重要な設計決定を要約します。アーキテクチャを大きな紙に描いて、チーム全体が見えるように見えるようにします。

これが効果的に行われるようにする必要がある場合は、すべての人がシステムのすべての場所（フロントエンドとバックエンド）でペアプログラムを開発する必要があります。ユーザー中心のユーザーストーリーの作成を続けます。しかし、なぜシステムが設計どおりに設計され、「バックエンド」設計に関する意思決定を推進するのかを示す主要な品質属性シナリオも特定します。もう見えなくなることがないように、アーキテクチャー設計を引き上げます。

これは社会的な問題のようですので、社会的な解決策が必要になります。

（私が理解しているように）バックエンド開発者が無視され軽視され、自分の仕事が十分に評価されていないと感じた場合、開発プロセスがこれを変更するためにできることはほとんどありません。

私が正しく理解している場合、開発者は少なくとも「独自の」ユーザーストーリーを持っているべきだと感じているようです。開発者はそれらを指し示し、「これは私たちがやったことであり、バックエンドの人/ギャルだけです」と言うことができます。しかし、ストーリーをこのように「水平に」スライスすることは悪い考えであり、垂直にスライスすることに同意します。

最善の解決策は、おそらく問題の開発者と（個別にまたはグループとして）静かに話し、尊重されているように見える根本的な問題に対処することです。ある時点で、これはおそらく管理者にエスカレーションする必要があります。

問題の根本は、私たちの経営陣が体系的にバックエンドの仕事を目に見えないものと見なし、支援された開発者の鉱夫やその他の軽蔑的な言葉を呼ぶことです。

確かにこれが問題です。ストーリーで解決しないのは明らかです！

一般に、アジャイル開発の特徴の1つは透明性です。これはまた、より多くのあなたの組織的な問題を作ることを意味マニフェスト。

この問題に対する標準のアジャイルソリューションは、開発に「垂直」または「フルスタック」アプローチを採用することです。この場合、バックエンド開発者は、バックエンド層の快適ゾーンで作業するのではなく、上から下にストーリーを取得します。フロントエンド開発者も同様にバックエンド（*）に向かって伸びます。

言い換えれば、すべての人にエンドユーザーのための価値を生み出させる。

^{（*）注：すべてのストーリーにフロントエンドコンポーネントまたはバックエンドコンポーネントが必要なわけではありません。追加のバックエンド作業なしでUI要素を再シャッフルでき、パフォーマンスは機能です。}

あなたの問題は：

• あなたは彼らの目的を果たさないあなたのビジネスの管理層を上に持っています。スクラム、アジャイル、私は気にしません。管理と開発は、テクノロジーについて！@＃$ ingの手がかりを持つ製品マネージャーによって取り扱われるビジネス上の懸念と切り離されるべきです。スティーブ・ジョブズにとってはうまくいったかもしれませんが、技術に精通していないマネージャーが開発者に近いことが健全なことであり、最終的にはチームが作ることができる最高品質の製品を生産するのに役立ちました。

• 問題を解決するよりも外見を心配する開発者がいます。それは非常に深刻な文化的問題（おそらくこの「マイナー」現象を考えると思われます）であるか、開発品質の問題であるか、または自信の欠如を考えるとショックを受けないでしょう。

そこにいる必要のない人たちを計画や立ち直りから追い出してください。バックエンドがフロントエンドほど重要ではないという考えを持っている人は、そこにいる必要はなく、実際にそこにいることによってプロセスを妨げている人です。

ストーリーを捨てる。そうです。私は本気です。それらがこの種の問題を引き起こしている場合は、エアロックを放り出してください。私の現在の仕事では、特定のタスクの「完了」基準に固執します。これは通常、アジャイル（20年間変化し続けている）のユーザーを怒らせる可能性があるユーザーよりもアプリに集中しています。手紙に従わない場合は機能しますが、実際に私たちがプロである場合、問題の原因となるものは何も必要ありません。くしゃくしゃにして、肩越しに投げます。

そして、開発者が本当に心配する必要があるのは彼らの直接の仲間であり、スプリント計画に参加するための無知な人ではないということを思い出させたいかもしれません。