タグ付けされた質問 「team」

私は、開発チームの規模を繰り返し削減している会社で働いており、以前の10人のチームは、製品ごとに1人の開発者（および5つの製品間で共有された2、3人のテスター）になりました。私たちは以前、かなり大きなプロセスを要し、大企業からのスピンオフであり、その多段階ウォーターフォールプロセスを継承していました。 ソフトウェアを十分な速さでリリースしていないこと、およびこれがプロセスの障害である可能性が高いことが経営陣から判明しました（90％の人員の損失はおそらく助けにはならなかったものの、それが原因である可能性があります）。設計ドキュメントの作成などに時間を費やさないようにするために、アジャイルプロセスに移行するよう強く求められてきました。 アジャイルへの切り替えが一人のチームで役立つかどうかについて私はちょうど興味があると思います。多くのメリットは、チームメンバー間の可視性の向上とコミュニケーションの向上から得られると私は理解していましたが、私は自分のしていることを理解しており、マネージャーもそうです。とにかく製品をテストする人がいないので、私はすでにTDDを行っています。 TL; DRバージョン：私が本当に求めていることは、1人の「チーム」でアジャイルを実装できますか、それから何かメリットがあると思いますか、それとも通常、大規模なチームにとってより効果的なものですか？

8 agile  team 

休業。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善してみませんか？この投稿を編集して、事実と引用で回答できるように質問を更新してください。 4年前休業。 多くの場合、「チームワーカー」や「チームで働くことを熱望する人」のようなもの、またはあなたが開発チームの良いメンバーになりたい、または良いメンバーになりたいと述べている雇用広告のようなものに遭遇します。 誰が優れたチームメンバーと見なすことができますか？チームでの作業に関して良い点と見なすことができる開発者の資質はどれですか。また、開発者はどのようにしてチームワークスキル（または、可能であれば属性）を向上させることができますか？

8 teamwork  team 

映画の締めくくりと同じように、一部のソフトウェアベンダーは、使用しているソフトウェアに取り組んだチームのフルネームをリストしています。 通常、スプラッシュスクリーン（Photoshop）に表示されます。 ...またはアバウトボックス（Traktor）。 でデモシーン、それは映画産業のように、必須の練習です。 自分のソフトウェアでそれをどのように見ますか？それをしない理由はありますか？企業にそれを奨励する理由はありますか？

8 team  motivation  credits 

休業。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善してみませんか？この投稿を編集して、事実と引用で回答できるように質問を更新してください。 5年前休業。 私のチームは最近、一部の作業をオフロードする必要があった開発者の数が非常に少なくなったチームからプロジェクトを継承しました。私たちが継承したプロジェクトの1つは、ネストされたコードが散らばったプロジェクトとひどい例外処理です（例外は実際にはgotoステートメントとして処理され、通常のプログラムフローの一部として使用されていました）。 全体として、それは誰かが数年間咳をしてきた毛深いコードボールでした。 現在、私たちはかなり長い間いくつかのチームガイドラインを用意していますが、オブジェクトの構造、コーディングスタイル、およびそうでないものに関するすべての考慮事項があります。ただし、例外処理については取り上げていません。 だから、例外処理に関してあなたのチームにガイドラインがあるかどうか、そしてもしそうならどのようにそれらを実施するのか？

8 documentation  team  exception-handling  coding-style 

私はLeonard Mlodinow の本「The Drunkard's Walk：How Randomness Rules Our Lives」を読んでいて、本当に啓蒙的な本です。本は確率と人間の推論を扱います。そして、記録のために、いくつかのことは時々うまくいきますが、あなたがそれをうまく動かしたと思ったものが、実際にそれを動かしたものとは無関係である可能性があるとだけ言いましょう。 確率は直感的ではありません。 しかし、それは私にアイデアを与えました。ソフトウェアエンジニアリングの取り組みの結果を数値化しようと試みた、これに関する研究はすでにあるはずです（もちろん、それ自体が難しい問題です）。そしてこれらの研究は、定量化可能な成功という点で、どのようなソフトウェアエンジニアリング手法が本当に重要であるかを指摘する必要があります。 すなわち TDDを採用するチームthisは、thisある種の問題を抱えている可能性がはるかに低くなります。 SOLID原則を採用しているチームthisは、thisある種の問題を抱えている可能性がはるかに低くなります。 などなど ここで私が探しているのは、実装と成功の間の強い相関を示すソフトウェアエンジニアリングの実践です。私はこれらのものが存在すると確信していますが、それらを手に入れるのは難しいので、私はこの質問をします。 実装と成功との間に強い相関関係があることを知っている研究や実践はありますか（成功は多少恣意的ですが、あなたはその考えを理解していると思います）？ ソフトウェアエンジニアリングがカウボーイコーディングよりも優れているという考えを売り込むなら、証拠が必要だと思います。

8 self-improvement  team 

テスターおよびブロガーのLanette Creamerが最近この質問をTwitterに投稿しました。 あなたがテスターと協力するプロのソフトウェア開発者であれば、あなたが知っている最高のテスターを考えてください。彼らに共通する特徴は何ですか？ ここでは素晴らしい質問になると思いました。 私の考えは： たとえ厄介な質問をすることになっても、要件から曖昧さを取り除きたいと考えています。 彼らは、それがどのように文書化されているかだけでなく、ソフトウェアが「機能するはず」である方法を見ることによって新しい機能を作成します。 彼らは正直さと誠実さを示し、周囲の人々にそれを奨励しますが要求はしません。つまり、動作をモデル化します。 あなたが一緒に働いた中で最高のテスターの特徴は何ですか？

7 team  testers