ユーザーストーリーに基づくバックエンド開発者
バックエンドの開発をユーザーストーリーに垂直に分割することを計画しました。しかし、私たちのチームのバックエンドの男は、これにより彼らの仕事が見えなくなると不平を言い始めました。
私の答えは
スプリントの計画とレビューのミーティングでは、関係者の前でバックエンドのタスクについて話し合い、それが見えるようにします。
プロジェクト中に高品質を維持すると、他のチームよりも起動のペースが遅くなりますが、プロジェクト中は速度が安定します。そして、速度は利害関係者に非常によく見えます。
「開発者として、ビジネスロジックをカプセル化できるように、ドメインレイヤーが必要です。」
チームを汚染する前に問題を解決するにはどうすればよいですか？
問題の根本は、私たちの経営陣が体系的にバックエンドの仕事を目に見えないものと見なし、支援された開発者の採掘者、または他の軽蔑的な言葉を呼ぶことです。
説明されている状況にはいくつかの問題点があります。明らかな問題は、バックエンドの開発者への尊敬の欠如です。この質問にはアジャイルのタグが付いているので、これは社会的な問題にすぎないことを示唆する他の回答を差し戻します。ストーリーには悪臭やアンチパターンがいくつかありますが、どれも無知な管理やストーリーのスライス方法とは関係ありません。
チームのメンバーのグループが仕事から栄光を得られなかったことで軽視されているという事実は、いくつかの考えられる問題のスマックを完了しました。
- バックエンド開発のみを行う人がいるべきではありません。一般的なアジャイルアプローチは、部門をまたがるチームを共有する練習を行う一般化スペシャリストで構成することです。コードの所有権。個人は、バックエンドまたはフロントエンドの開発だけに焦点を当てるべきではありませんが、確かに、他の人よりも経験が豊富であるか、またはいくつかの点で優れています。
- アーキテクチャは価値を生み出しません。ユーザーの観点から-本当に重要な唯一の観点-レイヤーやドメイン言語があるかどうかは関係ありませんまたはソリューションがプログラムされている場合でも。重要なのは、ユーザーに価値をもたらしたかどうかだけです。バックエンド開発者から提案された「ストーリー」はナンセンスな要件です。これは、ユーザー/顧客の観点から、必要な機能を実現するために何もしないという設計決定の要約です。つまり、特定のユーザーストーリーは、任意の数の異なるアーキテクチャ設計によって達成される可能性があります。ユーザーストーリーは、バックエンドをまったく変更せずに完了する可能性があります。これはそれを無効な話にしない。
- 体系的に考えることは依然として重要です。アーキテクチャは価値を得られない可能性がありますが、成功するには依然として重要です。バックエンド開発者にはいくつかの正当な懸念があります。どのようにシステムを構築するかについて考える必要があります。あなたはそれらの決定を書き留めるべきです。フロントエンドの機能だけがすべての栄光を得るものであるとしても、システム全体が重要です。
私の推奨は、建築をファーストクラスの市民として扱うことです-しかし、正しい方法で行ってください。 利害関係者との品質属性ワークショップ を実行します。 アーキテクチャレビュー に主要な利害関係者を関与させるか、少なくとも重要なマイルストーンで重要な設計決定を要約します。アーキテクチャを大きな紙に描いて、チーム全体が見えるように見えるようにします。
これが効果的に行われるようにする必要がある場合は、すべての人がシステムのすべての場所（フロントエンドとバックエンド）でプログラムをペアで開発する必要があります。ユーザー中心のユーザーストーリーの作成を続けます。しかし、なぜシステムが設計どおりに設計され、「バックエンド」設計に関する意思決定を推進するのかを示す主要な品質属性シナリオも特定します。もう見えなくなることがないように、アーキテクチャー設計を引き上げます。
これは社会問題のようですので、社会的な解決策が必要になります。
（私が理解しているように）バックエンド開発者が無視され軽視され、自分たちの仕事が十分に評価されていないと感じた場合、開発プロセスがこれを変更するためにできることはほとんどありません。
私が正しく理解している場合、開発者は少なくとも「独自の」ユーザーストーリーを持つべきだと感じているようです。そうすれば、開発者はそれらを指し示し、「これは私たちがやったことであり、バックエンドの人/ギャルだけです」と言うことができます。しかし、ストーリーをこのように「水平に」スライスすることは悪い考えであり、それらを垂直にスライスすることに同意します。
最善の解決策は、問題の開発者と（個別にまたはグループとして）静かに話し合い、根本的な問題に対処することです。ある時点で、これはおそらく管理にエスカレートする必要があります。
問題の根本は、私たちの経営陣が体系的にバックエンドの仕事を目に見えないものと見なし、支援された開発者の採掘者、または他の軽蔑的な言葉を呼ぶことです。
確かにこれが問題です。ストーリーで解決しないのは明らかです！
一般に、アジャイル開発の特徴の1つは透明性です。これはまた、組織の問題をより多くするmanifestことを意味します。
この問題に対する標準のアジャイルソリューションは、より「垂直」または「フルスタック」のアプローチを開発に採用することです。この場合、バックエンド開発者は、バックエンド層の快適ゾーンで作業するのではなく、上から下にストーリーを取得します。フロントエンド開発者も同様にバックエンド（*）に向かって伸びます。
言い換えれば、すべての人にエンドユーザーのための価値を生み出させる。
（*）注：すべてのストーリーにフロントエンドコンポーネントまたはバックエンドコンポーネントが必要なわけではありません。追加のバックエンド作業なしでUI要素を再シャッフルできます パフォーマンスは機能です 。
あなたの問題は：
あなたは彼らの目的を果たさないあなたのビジネスの管理の層を持っています。スクラム、アジャイル、私は気にしません。管理と開発は、テクノロジーについて！@＃$ ingの手がかりを持つ製品マネージャーによって取り扱われるビジネス上の懸念と切り離されるべきです。 Steve Jobsの場合はうまくいったかもしれませんが、技術に精通していないマネージャーが開発者に近づくことが健全なことであり、最終的にはチームが作成できる最高品質の製品を生産するのに役立つ状況にあったことはありません。
問題を解決するよりも外見を心配する開発者がいます。それは非常に深刻な文化的問題（おそらくこの「マイナー」現象全体を考えると思われる）であるか、開発品質の問題であるか、あるいは自信の欠如を考えるとショックを受けないでしょう。
そこにいる必要のない人たちを計画や立ち直りから追い出してください。フロントエンドよりもバックエンドの重要性が低いという考えを持っている人は、そこにいる必要はなく、実際にそこにいることによってプロセスを妨げている人です。
ストーリーを捨てる。そうです。私は本気です。それらがこの種の問題を引き起こしている場合は、エアロックを放り出してください。私の現在の仕事では、特定のタスクの「完了」基準に固執します。これは通常、アジャイル（20年間変化し続けている）のユーザーを怒らせる可能性があるユーザーよりもアプリに集中しています。手紙に従わない場合は機能しますが、実際に私たちがプロである場合、問題の原因となるものは何も必要ありません。くしゃくしゃにして、肩越しに投げます。
そして、開発者が本当に心配する必要があるのは彼らの直接の仲間であり、スプリントの計画を立てるのにあまりにも無知な人々ではないということを思い出させたいかもしれません。