どうして何もできないの？
私は中規模の会社の小さなチームで働いています。そのほとんどはソフトウェア開発に関与していません。私は最新で経験の浅い開発者であり、開始する前はソフトウェアの専門的または学術的なバックグラウンドを持っていませんでしたが、私の入力がどれほど尊重されているかに非常に満足しており、キャリアの早い段階で真剣に受け止められたことに感謝しています。
それでも、私はこの寛大な量の通信時間でもっとやっているべきだと感じています。チームとして、私たちは物事を成し遂げるのに苦労しているようです。状況を改善するために何か提案できるようになりたいと思います。それが良いアイデアだったら聞いてもらえると思いますが、何を提案すべきか途方に暮れています。
問題として特定できるものは次のとおりです。
- 手元のタスクの仕様はまばらです。これは、管理がボトルネックであり、詳細な要件を必要なだけ解決するための資金や人員がいないためです。また、私たちが開発しているソフトウェアが調査中であり、その有効性を判断するために実証および使用されるまで正確な方法が明確でないことも一因です。
- Lead Devは、彼が「プロトタイピング」と呼んでいるものを非常に気に入っており、最近、すべてが「プロトタイピング」されていると主張し始めています。多くの場合、彼がこの演習から何を期待しているのかは明確ではありません。 「実際の」実装は、プロトタイピングからグッドプラクティスに時間がかかりすぎるという彼の主張のために苦しんでいます。私はこのねじれた論理を解き明かすことができるようにさえなり始めていません、そして私は私が試みたいかどうかわかりません。
- モデラーは、必要な方法論についてすべてを正確に詳細に説明することが期待されており、彼らが生み出すものは理論的に完璧であると絶対的に信頼されています。これはほとんど真実ではありませんが、この状況を是正するための措置は取られていません。モデリング側の誰も、行動を起こす可能性のある構造化された方法で懸念を提起したり、ベストプラクティスを適用する際のガイダンスを求めたりしません。彼らの受動性についても何もされていません。
- 私は以前にチームでTDDをプッシュしようとしましたが、それは私にとって新しいものであり、私の仕事を監督している人がそれを許容する用意がある間は困難であることがわかりました。機能を完成させずにうろつくことに費やす時間を正当化することはできないので、そのアイデアは-今のところ-放棄されています。仕事のやり方を教えられるのが好きな人はいないので、二度と取り上げられないのではないかと心配しています。
- 現在、継続的インテグレーションサーバーがありますが、ほとんどの場合、数時間の回帰テストを実行するためにのみ使用されています。フルカバレッジの単体テストと統合テストも実行する必要があることはオープンなままですが、現時点では誰も作成していません。
- リード開発者に品質の問題を提起するたびに、「機能Aのテストは簡単で、機能Bはユーザーにとってはるかに重要ですが、テストが難しすぎるため、機能をテストしないでください」という効果に対する回答が得られます。 A '。もう一度、私はこの論理を解き明かそうとして前進しませんでした。
....ふぅ。そのように言うと、思ったよりずっとひどく見えます。結局のところ、これは助けを求める叫びだと思います。
少しの間、悪魔の代弁者を演じさせてください。
手元のタスクの仕様はまばらです...リード開発者は、彼が「プロトタイピング」と呼んでいるものをとても気に入っています
リード開発者はプロトタイピングが好きですなぜなら仕様はまばらです。これはおそらく良いことです。これが反復ショップの仕組みです。
モデラーは、必要な方法論についてすべてを正確に詳細に説明することが期待されています
これは反復ショップでは機能しません。反復型開発の本質は、要件がしばしば不完全であるということです。反復は、要件を具体化するために必要なものです。
私は以前にチームでTDDをプッシュしようとしましたが、それは私にとって新しいので難しいと感じました
これも機能しません。伝道する前に、テクノロジーを理解する必要があります。さらに、要件が少ない反復ショップでは、TDDのオーバーヘッドが大きすぎる可能性があります。適切な単体テストの適用範囲を奨励することをお勧めします。
現在、継続的インテグレーションサーバーがありますが、ほとんどの場合、数時間の回帰テストを実行するためにのみ使用されています。
これは、小さな反復的なショップでは適切かもしれません。
リード開発者に品質の問題を提起するたびに、「機能Aのテストは簡単で、機能Bはユーザーにとってはるかに重要ですが、テストが難しすぎるため、機能をテストしないでください」という効果に対する回答が得られます。 A '
あなたの店にはかなり厳しい時間的制約があるようです。好むと好まざるとにかかわらず、あなたはそれらの制約に縛られています。
また、最初に市場に出すことよりも「正しい方法」で物事を行うことを重視するソフトウェア業界の一部から来たようです。バグのあるソフトウェアで最初に市場に出た人が勝者となることが多いことを除いて、これには何の問題もありません（実際には立派です）。それは公平ではありませんが、それはそうです。
ここではプロトタイピングに焦点を当てます
プロトタイプの主な問題は、プロトタイプが概念実証であることです。
ただし、プロトタイプをさらに構築できず、最終製品を最初から再構築する必要がある場合は、プロトタイプを構築しておらず、構築に時間を浪費している可能性があります。
あなたのチームへの私のアドバイスは、それらのプロトタイプである程度の品質と柔軟性を得ることです。完璧なものを最初に作成することは不可能ですが、将来の要件のために拡張性を維持するようにしてください
これらは良い答えです。私は、「コミュニケーションを試みること」はせいぜい気の利いた提案であると付け加えることしかできません。組織の働き方の変化はすぐには起こりません。それが起こるとき、それはしばしば潮のようであり、勢いは下からそして上から構築されます。ですから、期待を低く抑え、物事がどのように行われるかを話すチャンスを待つか、別の組織との協力を楽しみにしておくと、より幸せになります。
もしそうなら、「それを手に入れる」会社の誰かを特定しましたか？この男にとらわれて、彼から可能な限り多くを学びましょう。そうでない場合は、時間をかけて自分で学び成長を始め（オープンソースプロジェクトに参加するか、独自のプロジェクトを立ち上げて）、成長を促進できる場所を探してください。
起こりうる最悪の事態は、そこにとどまり、間違った方法で物事を行う方法を学ぶことです。はい、実用性を取り入れるべきですが、真に熟練したチームは正しい方法で物事を行うことができ、それでも高品質の製品に遅れることはありません。現在のチームには必要なものがないようです。新しいチームを探し始める必要があります。