どうして何もできないの？

私は中規模の会社の小さなチームで働いています。そのほとんどはソフトウェア開発に関与していません。私は最新かつ最も経験の浅い開発者であり、開始する前にソフトウェアの専門的または学問的なバックグラウンドを持っていませんでしたが、私の入力がどれほど尊重されたかに非常に満足しており、私のキャリアの早い段階で真剣に受け止められたことに感謝しています。

それでも、私はこの寛大な量の放送時間でもっと多くのことをすべきだと感じています。チームとして、物事を成し遂げるのに苦労しているようです。状況を改善するために何か提案できるようになりたいと思います。それが良いアイデアだったら聞いてもらえると思いますが、何を提案すべきか途方に暮れています。

問題として特定できるものは次のとおりです。

• 手元のタスクの仕様はまばらです。これは、管理がボトルネックであり、私たちが望むほど詳細な要件を解決するために費やすお金や人がいないためです。また、開発中のソフトウェアは調査対象であり、その有効性を判断するために実証および使用されるまで正確な方法が明確ではないためです。
• Lead Devは、彼が最近すべてを「プロトタイピング」していると主張し始めたところまで彼が「プロトタイピング」と呼んでいるものを非常に気に入っています。多くの場合、彼がこの演習から何を期待しているのかは明確ではありません。「実際の」実装は、プロトタイピングに時間がかかりすぎるという彼の主張のために、苦しみます。私はこのねじれた論理を解くことができるようになり始めていないので、試してみたいと思いませんか。
• モデラーは望ましい方法論についてすべてを正確に詳細に教えてくれることが期待されており、彼らが生み出すものは理論的に完璧であるという絶対的な信頼に基づいています。これはほとんど真実ではありませんが、この状況を修正するためのアクションは取られません。モデリングの側の誰も、行動を起こそうな構造化された方法で懸念を提起したり、ベストプラクティスを適用する際のガイダンスを求めたりすることはありません。彼らの受動性についても何も行われません。
• 私は以前にチームでTDDをプッシュしようとしましたが、それは私にとって新しいものであり、私の仕事を監督している人はそれを許容する用意がある一方で難しいと感じましたが、他の誰からも熱意はありませんでした。機能を詰め込んで仕上げるのではなく費やす時間を正当化することはできないため、このアイデアは（現時点では）放棄されています。私はそれが再び取り上げられないのではないかと心配しています。
• 現在、継続的インテグレーションサーバーがありますが、ほとんどの場合、数時間の回帰テストを実行するためにのみ使用されています。フルカバレッジの単体テストと統合テストも実行する必要があることはオープンなままですが、現時点では誰も作成していません。
• リード開発者と一緒に品質の問題を提起するたびに、「機能Aのテストは簡単です。機能Bはユーザーにとって非常に重要ですが、テストが難しいため、機能をテストするべきではありません。 A '。もう一度、私はこの論理を解き明かそうとして進んでいません。

....ふw。そんなふうに言うと、思っていたよりもずっと悪く見えます。結局のところ、これは助けを求める叫びだと思います。

ちょっと悪魔の擁護者を演じましょう：

手元のタスクの仕様はまばらです...リード開発者は、彼が「プロトタイピング」と呼んでいるものをとても気に入っています

仕様がまばらであるので、リード開発者はプロトタイピングが好きです。これはおそらく良いことです。これが反復的なショップの仕組みです。

モデラーは、望ましい方法論についてすべてを正確に私たちに伝えることが期待されています

これは、反復的なショップでは機能しません。反復的な開発の本質は、要件がしばしば不完全であることです。反復は、要件を具体化するために必要なものです。

私は以前にチームでTDDをプッシュしようとしましたが、それは私にとって初めてなので難しいと感じました

これも機能しません。伝道する前に、テクノロジーを理解する必要があります。さらに、要件が不十分な反復的なショップでは、TDDのオーバーヘッドが大きすぎる可能性があります。適切な単体テストカバレッジを推奨することをお勧めします。

現在、継続的インテグレーションサーバーがありますが、ほとんどの場合、数時間の回帰テストを実行するためにのみ使用されています。

これは、小さな反復的なショップでは適切な場合があります。

リード開発者と一緒に品質の問題を提起するたびに、「機能Aのテストは簡単です。機能Bはユーザーにとって非常に重要ですが、テストが難しいため、機能をテストするべきではありません。 A '

ショップにはかなり厳しい時間制限があるようです。好むと好まざるとにかかわらず、これらの制約に拘束されます。

また、最初に物事を市場に出すことよりも「正しい方法」で物事を行うことを重視するソフトウェア業界の出身者のようにも聞こえます。バグのあるソフトウェアで最初に市場に出た人が勝者となることが多いことを除いて、これには何の問題もありません（実際には立派です）。それは公平ではありませんが、それはそうです。

ここでプロトタイピングに焦点を当てます

プロトタイプの主な問題は、プロトタイプが概念実証であることです。

ただし、プロトタイプをさらに構築することができず、最終製品をゼロから再構築する必要がある場合は、プロトタイプを構築しておらず、構築に時間を浪費している可能性があります。

あなたのチームへの私のアドバイスは、これらのプロトタイプにある程度の品質と柔軟性を持たせることです。完璧なものを最初に作成することは不可能ですが、将来の要件に合わせて拡張性を維持するようにしてください

これらは良い答えです。「コミュニケーションしようとする」ことはせいぜい不確かな命題であると付け加えることができるだけです。組織の仕組みの変化はすぐには起こりません。それが起こるとき、それは潮のようであり、勢いは下からそして上から構築されます。ですから、期待を低く抑え、物事がどのように行われるかを話すチャンスを待つか、別の組織との協力を楽しみにしておくと、より幸せになります。

もしそうなら、それを「手に入れる」会社の誰かを特定しましたか？そうでない場合は、時間をかけて、自分で学習と成長を始め（オープンソースプロジェクトに参加するか、独自のプロジェクトを開始して）、成長を促進できる場所を探します。

起こり得る最悪のことは、あなたがそこに留まり、間違った方法で物事を行う方法を学ぶことです。はい、実用性を取り入れるべきですが、真に熟練したチームは正しい方法で物事を行うことができ、それでも高品質の製品に遅れることはありません。現在のチームには必要な能力がないため、新しいチームを探す必要があります。