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

多くのプログラマーが管理および管理の役割から離れているのを見ています。彼らはものを作りたい。そしてその結果、これらのポジションの多くは非技術者によって満たされています。私は、彼らがどのように価値を付加するのか見ていません。会議のスケジューリング、オフサイトの予約、およびその他の管理作業は、その役割を正当化するのに十分ですか？

63 teamwork  management 

更新 私は4人の開発者の小さなチームで働いています。それらはすべてソース管理を使用しています。それらのほとんどはソース管理に耐えられず、代わりに使用しないことを選択します。ソース管理は専門能力開発の必要な部分だと強く信じています。いくつかの問題により、ソース管理を使用するように説得することが非常に困難になります。 チームはTFSの使用に慣れていません。2回のトレーニングセッションを行いましたが、1時間しか割り当てられていませんでした。 チームメンバーは、サーバー上のコードを直接変更します。これにより、コードが同期しなくなります。最新のコードで作業していることを確認するためだけに比較が必要です。そして、複雑なマージの問題が発生します 開発者が提供する時間の見積もりには、これらの問題の修正に必要な時間は含まれていません。ですから、nonoと言うと10倍時間がかかります...これらの問題を絶えず説明し、自分自身を危険にさらす必要があります。 サーバー上の物理ファイルは、〜100ファイルにわたって未知の点で異なります。マージには、当面のプロジェクトの知識が必要であり、したがって、開発者の協力を得ることはできません。 他のプロジェクトは同期していません。開発者はソース管理に不信感を持ち続けているため、ソース管理を使用しないことで問題を悪化させています。 開発者は、マージはエラーが発生しやすく、難しいため、ソース管理の使用は無駄だと主張します。これは議論するのが難しいポイントです。なぜなら、ソース管理がひどく誤用され、ソース管理が継続的にバイパスされると、間違いが起こりやすいからです。したがって、彼らの見解では証拠は「それ自身のために語る」。 開発者は、サーバーコードを直接変更し、TFSをバイパスすると時間を節約できると主張します。これも議論するのが難しいです。開始するコードを同期するために必要なマージには時間がかかるためです。これに私たちが管理する10以上のプロジェクトを掛けます。 永続ファイルは、多くの場合、Webプロジェクトと同じディレクトリに保存されます。そのため、公開（完全公開）は、ソース管理にないこれらのファイルを消去します。これはまた、ソース管理に対する不信感を引き起こします。「公開するとプロジェクトが壊れる」ためです。これらの場所はweb.configで設定されておらず、多くの場合複数のコードポイントに存在するため、これを解決する（保存されたファイルをソリューションサブフォルダーから移動する）には多大な時間とデバッグが必要です。 だから、文化はそれ自体が持続します。悪い習慣はより悪い習慣を生みます。悪い解決策は、新しいハックを駆り立てて、より深く、より時間のかかる問題を「修正」します。サーバー、ハードドライブのスペースを手に入れるのは非常に困難です。それでも、ユーザーの期待は高まっています。 この状況で何ができますか？

62 version-control  teamwork  team-foundation-server  cowboy-coding 

問題：私が関与するほとんどすべての開発努力で、開発を開始する前に計画にどれだけ時間がかかっても、プロジェクトの途中またはプロジェクトの終わりに向かって大量の変更が常に必要と思われます。これらは時々大きな変更であり、多くの再開発が必要です。 私はお金を払っているクライアントのために働いていません。これは社内開発ウェブサイトの社内開発チームです。だから、私はそれまたは何かのために充電できるようではありません。そして、一日の終わりには、締め切りに間に合わなければなりません。 質問：仕様の変更が途中または開発後に発生するのを最小限に抑え、防止するために皆さんが見つけた最良の方法は何ですか？

61 web-development  project-management  business  teamwork  time-management 

多くの悪い慣行がプロジェクトの開始時にコミットされていたので、私はそれらを認識し、それらすべてと戦った。私は自分の戦いを選んでいないので、上司は口から出るものはすべて非常に複雑な反応であると想定し、プロジェクトの最善の利益を探すのではなく、自分自身を守ることに多くの時間を費やしています。 全員が合意に達するまで4か月待たずに、または困難な全知としてのチームの評判を傷つけることなく、チームを正しい方向に進めるにはどうすればよいですか？

61 teamwork 

私たちは、プロジェクトの1つに貢献する必要がある非プログラマー（ライター）と協力しています。 現在、彼らは自分の作業をバージョン管理するためにGit（またはそのことは何でも）を使用するという考えを嫌っています。これは、バージョン管理のねじれた概念に頭を悩ませるだけの価値がないためだと思います。（私が最初にそれらをブランチとマージに紹介したとき-彼らは私がそれらを怒らせていたように見えました。） 今、私たちは彼らを教育したり、それを使うように説得する立場にはありません。私たちは、彼らのすべての作業をバージョン管理するための代替案を探しています（これが必要なものです）-彼らは簡単なワークフローを取得し、彼らの仕事に集中します。 私はいくつかのアイデアを思いつきました... 自明ではない変更を行うたびに作業を個別のファイルとして保存するように指示し、変更を追跡するために差分を使用します。 CSSEditの「マイルストーン」を何らかの方法で実装するプログラムを（Pythonで）作成します。 プロジェクトについて： これは自然言語処理システムです（C + Pythonで記述されています）。さまざまな言語でシステムの入力を準備するために、いくつかのライターを雇いました。そして、ソフトウェアを進化させると、それらのライターが入力（記事）を変更する必要があります。時々、変更は非常に小さい（1つか2つ）こともあれば、大きくなることもあります。 これらの変更をバージョン管理する必要があるのは、入力のあらゆる小さな/大きな変更がシステムの出力を劇的に変更する可能性があるためです。

57 programming-practices  version-control  teamwork 

私が毎日使用しているコードベースには、自動テスト、一貫性のない命名、「なぜこれが必要なのか」、「これが必要かどうかわからない」、「このメソッドに正しい名前が付けられていない」などの大量のコメントがなく、コードが散らかっていますソース管理を使用しているにもかかわらず、「変更ログ」。私たちのコードベースはリファクタリングを使用できると言えば十分です。 バグを修正したり、新しい機能を追加したりするタスクは常にあるため、コードをリファクタリングしてよりモジュール化するための時間は確保されておらず、優先度は高くないと思われます。 タスクリストに追加されるようなリファクタリングの価値をどのように実証できますか？許可ではなく許しを求めて、リファクタリングするだけの価値はありますか？

57 refactoring  teamwork 

私のチームメンバーの1人であるジュニアプログラマーは、彼の経験レベルに対して優れたプログラミングスキルを持っています。 また、コードのレビュー中に、間違いを指摘するのではなく、学習を重視することを信じています。 しかし、若いプログラマーは、より上級のプログラマーのコードレビューに関与すべきでしょうか？または、コードレビューには、対応する経験を持つプログラマーのみが参加する必要がありますか？

55 teamwork  code-reviews  pair-programming 

私は、全員が1年未満のソフトウェア開発経験を持つ小さなチームのリーダーです。私は決して自分をソフトウェアの第一人者とは言いませんが、ここ数年でソフトウェアを書いていることをいくつか学びました。 コードレビューを行うとき、私はかなりのミスを教えて修正します。「これは非常に複雑で複雑であり、これが理由です」または「このメソッドを別のクラスに移動することについてどう思いますか？」質問や意見の相違がある場合は大丈夫ですので、話し合う必要があることを伝えるのは特に慎重です。私は誰かを修正するたびに、「あなたはどう思いますか？」と尋ねます。または類似のもの。 しかし、意見が合わない場合や理由を尋ねることはめったにありません。そして最近、私は彼らが私の声明に盲目的に同意し、彼ら自身の意見を形成していないというより露骨な兆候に気付いています。 指示に従うだけでなく、物事を自律的に正しく行うことを学ぶことができるチームが必要です。ジュニア開発者をどのように修正しますが、それでも彼が自分で考えることを奨励しますか？ 編集：ここに、彼らが彼ら自身の意見を形成していないというこれらの明白な兆候の1つの例があります： 私：拡張メソッドを作成するというあなたのアイデアは好きですが、大きな複雑なラムダをパラメーターとして渡す方法は好きではありません。ラムダは、メソッドの実装について他人にあまりにも多くのことを強制します。 ジュニア（私を誤解した後）：はい、私は完全に同意します。ここで拡張メソッドを使用しないでください。これは、他の開発者に実装について多くの知識を強要させるためです。 誤解があり、それは対処されました。しかし、彼の声明には論理のOUNCEさえありませんでした！彼は私の論理を逆流していると思い、なぜ彼がそれを言っているのか全く分からないときに理にかなっていると思った。

54 learning  teamwork  team-leader 

私は、大企業内でライフサイクルの中間点にあるアプリケーションの小さな開発者チームを管理しています。残念ながら、これは通常、プログラミングタスクが「その他の技術的作業」に30/70分割されていることを意味します。この作業には以下が含まれます。 DBA / Unix / Network / Loadbalancerチームとのさまざまなタスクでの作業 異なる地域でのハードウェアまたはインフラストラクチャの注文と配置の管理 まだCIに移行されていないテストの実行 分析 サポート/調査 開発者はすべて、これらのより日常的なタスクを行うよりもコーディングを好むと言うのは当然です。そのため、楽しいプログラミングジョブをチーム間で均等に配布するようにします。 ほとんどのチームは、独自のコンパイラ/ゲームエンジン/高頻度取引システムなどを作成するためのエリートプログラミングスキルを持たないかもしれませんが、「物事を成し遂げる」ことができ、他のチームと協力する優れたコミュニケーターであるため、採用されました、そしてここで複雑な官僚機構をいくぶんナビゲートします。彼らは優れた開発者ですが、優れた総合的な技術スタッフでもあります。 ただし、チームの1人のメンバーはおそらく平均以上のコーディングスキルを持っていますが、平均以下のコミュニケーションスキルを持っています。従来、以前の開発マネージャーは、上記のより日常的なタスクではなく、プログラミングタスクを提供する傾向がありました。ただし、大企業のIT部門で一般的に必要とされるバランスのとれたスキルセットを開発する適性を示している他のチームにとって、これが公平だとは思いません。 この状況ではどうすればよいですか？彼にもっとプログラミングの仕事を与え続けると、それがより速く行われることを知っています（そして逆に、彼は他の仕事をより遅く完了すると期待しています）。しかし、それは私の原則に反しており、単にあなたが好きではないタスクに悪いことによって、あなた自身のために「快適なニッチ」を切り開くことができるという考えを促進します。 clarifyみが原因でこの問題に対処しようとしていないこと、または言及したように「肩に欠けている」ことを明確にしたいと思います。バランスの取れたチームを維持する方法についてのアドバイスを探しています。チームは幸せでやる気があります。この質問に対するさまざまな答えを観察することにより、これを達成する方法について多くの異なる意見があるようです。

52 teamwork  management  communication  maintenance  team-leader 

最近、私は作るのが難しくないように思えるプロジェクトを始めました。コンセプトは、時々入力を受け入れなければならないかなりシンプルなアプリケーションであり（おそらく1日10倍）、それらに対していくつかの操作を実行し、すべての結果を収集しようとしました最後に。その後、このアプリケーションは、顧客が結果を表示するために使用できるフロントエンドWebポータルを取得しますが、ロケット科学そのものではありません。 このために、私は最初にPythonの組み込み同時実行ライブラリ（ThreadPoolExecutor）をスマートに使用し、フロントエンドに使いやすいライブラリを使用しました（初心者には簡単で、保守とテストが比較的簡単なため、Flaskを選択しました）。 プロジェクトの半分に達した後、PMは、スレッドの代わりにサードパーティのメッセージキュー機能を使用する必要があり、負荷分散を実装する必要があると述べました。最終的に起こったことは、最終的にCelery、Redis、RabbitMQ、Nginx、uWSGIそして、誰も実際に経験したことのない他の大規模なサードパーティサービスの束。 最終的に、これはスパゲッティコードの束、テスト不能なタスク（サードパーティライブラリの複雑さ、コードのパッチ適用が機能しなかったため）、およびこれらのサービスの付加価値が誰にもわからないために頭痛の種につながります。 「はい、これらのサービスを使用する必要があります」と言う前に、誰もこれらの使用方法を知らないか、競合状態に悩まされているコードを導入する以外に彼らが何をするかさえ知らないことに留意してください。 これについてどうすればよいですか？この時点では、最終製品が当初よりも悪くなったとしても、私たちが持っていたものに戻すにはコストがかかりすぎ、PMはこれらのサービスを使用することに行き詰まっています。彼とこれについて議論するのに使用さえありますか？もっと時間が必要ですか？または厳しい答えは、私は自分の仕事にはあまりにも愚かですか？

51 productivity  teamwork  third-party-libraries 

最も基本的なドキュメントでさえも書くことに嫌悪感があるようです。プロジェクトのREADMEは比較的むき出しです。ドキュメントには依存関係の更新されたリストさえありません。 プログラマーがドキュメンテーションを書くことを嫌うような業界で私が知らないことはありますか？必要に応じてドキュメントの段落を入力できますが、なぜ他の人はそれを嫌うのですか？ さらに重要なことは、ドキュメントを書くことで将来の時間とフラストレーションを節約できることを彼らに納得させるにはどうすればよいでしょうか？

47 documentation  teamwork 

たぶん個人的な経験かもしれませんが、私はさまざまなグループやタイプの人々と関わっており、私が遭遇したプログラマのかなりの割合が「良くない」か、より良い定義を試みているようです。 見下す ひどい 彼らは人々について話す方法で否定的 同じことに気づいた場合、その理由についての理論はありますか？これらのプログラマーの一人に彼らがどのように行動しているのかを丁寧にまたは丁寧に教えて、彼らが仕事をしたいと思うプロとして認識されたい場合は修正することを提案しますか？ あるいは、私は悪いサンプルに出くわしただけで、名前を付けることができるすべての人々のグループに悪い種があります。

47 teamwork 

これは、チームでの作業方法に関する質問です。 最近、私は6人のチームで最初の大規模（〜80クラス、Java）プログラミングプロジェクトに取り組みましたが、コードに継続的に取り組んでいたのは4人だけでした。私たちは早い段階で行われる作業を配布しましたが、ある時点で、私は共同プログラマーの1人によってまだ実装されていないメソッドを呼び出す必要がありました。これに対処するための推奨される方法はどうですか？ 私が見たオプション、私はそれらのどれも本当に好きではありませんが： 自分の書き込み//TODO及び方法がその間に実装されているかどうかを確認するために、後のコード行を再訪。 対応するチームメンバーに今それを実装するよう頼む。 まだ実装されていないものの明確な説明を含むカスタムruntimeExceptionをスローします。（少なくとも、何が足りないかを見つけるために長い時間を探す必要はありません） するために必要なメソッドを追加し、そのクラスとそれらの書き込み//TODOメッセージ本文に、おそらくも彼らにその変更についての簡単なメッセージを送信します。（これはもう私の問題ではありませんが、その間にこのメソッドで作業していた場合、迷惑なマージ競合が発生する可能性があります） 実際に作業を行うコードを記述する前に、すべての抽象クラスまたはインターフェースを定義します。（これらのインターフェイスは頻繁に変更されたため、うまく機能しませんでした）

45 teamwork 

卒業（2005年後半）以来、私はc ++ソフトウェアエンジニアと同じ会社で働いていました。1年前、私はソフトウェアアーキテクトとして昇進しましたが、資格の取得とバグの修正、レベル2サポートにますます関与するようになりました。 私の時間の50％は、Notepad ++でソフトウェアログを分析し、何が問題だったのかを把握するために費やしました。30％が他のバグを修正し、残りの（存在する場合）開発者のスパゲッティコードをレビューします。 私はこの製品を嫌い、この会社の出口戦略について考え始めました。 この状況で私にできることは何だと思いますか？他のソフトウェアアーキテクトはまだコードのバグを修正していますか？

45 architecture  teamwork  software 

あるプログラマーはSVNリポジトリーにいくつかの作業をコミットしてから帰宅しました。彼が去った後、ハドソンの自動ビルドは失敗しました。別のプログラマーはこれを見て、コードの変更を調べた後、問題が1つのライブラリーがないことを検出しました。彼はこのライブラリをSVNに追加し、次のビルドが正常に完了しました。 2番目のプログラマーは正しいことをしましたか、それとも最初のプログラマーが問題を解決するまで待つべきでしたか？

45 teamwork  continuous-integration