プログラマーがより生産的に作業できることを経営陣にどのように証明しますか？
バックストーリー
私はコンピューターサイエンスの学位（ソフトウェアエンジニアリングの追加コースを含む）を1年未満卒業し、ソフトウェアエンジニアリングの学位をもう1度取得しました。現代のソフトウェア開発方法論（CI、スクラム、XPなど）に精通していると思います。
問題
私は中規模のゲーム開発会社で最初の（そして現在の）仕事を得ました。同社は数年前から存在し、複数のタイトルを成功させており、才能豊かで献身的な人々でいっぱいです。ただし、ソフトウェア開発は完全にその場限りの方法で行われます。私たちはSVNとバグトラッカーを使用していますが、それを超える計画はほとんどなく、自動テストも行われていないため、オフィスのどこにでもUML図を見つけるのは困難です。
これには2つの理由が考えられます。
- プログラマには、物事を適切に行うための十分な時間が与えられていないだけです。悲しいことに、上級管理職は、プログラマーに相談することなく期限を設定する傾向があり、その結果、多くの人が徹夜につながりました。
- プログラマー自身は、適切な技術を採用するための教育/動機に欠けています。
質問
私は最近これについて経営陣に話しました、そして私は代替案を提案するように励まされました。最初にすべきことは、上記の2番目の可能性を排除することだと考えます。つまり、プログラマーがより多くの呼吸スペースを与えられれば、彼らはより生産的になることができるという証拠を経営陣に与えます。しかし、どうすればいいのかよくわかりません。これまでの私の最高の考えは、プログラマーの間で彼らが知っているソフトウェア開発方法論、ならびにコードの品質などに対する彼らの態度について調査を行うことです。
tl; dr
プログラマーが最新のソフトウェア開発方法を採用できる/する意志があるかどうかを評価し、これが生産性の向上につながることを経営陣に証明するにはどうすればよいですか？
[〜＃〜]編集[〜＃〜]
私は明らかに私のポイントを適切に伝えられなかったので、状況について少し詳しく説明させてください。
最初、私はこれが彼のl33t教育で世界を救おうとし、これ以上何も知らない不機嫌な古い化石の邪悪な方法を変えようとする明るい目の新鮮な卒業生のように見えることを完全に認識しています。また、理論と実践には常に違いがあり、彼らが学校で教えることは実際の生活で起こることではないことも理解しています。それがまさにここで私が信じられないほど慎重で、進行中の充電ではなく現在の状況の感触を得ようとしている理由です「海の装い、これからすべてユニットテストをしましょう！」
2番目、@ psrは非常に良い点を提起します。改善の余地があると思う理由をいくつか挙げさせてください。
- 私たちの上級開発者は、ちょっとした異端者ですが、最終的には熟練して合理的な人物ですが、会社の歴史のこの時点では、より洗練された反復可能な開発プロセスを導入する必要があることに同意します。
- 私よりはるかに経験が豊富で、最新の方法を使用したプログラマーの1人は、私がそれらのいくつかを使用した場合、より生産性が高くなる可能性があることに同意します。
- 場合によっては、徹夜で機能をまとめてすべてのバグを追跡するのに、とんでもない時間がかかることがあります。他のことをするともっと悪いことになるとは思えません。
- 計画、設計、リファクタリング、および文書化の欠如は、コード品質の低下につながります。おそらくもっと重要なことは、プログラマーが数か月以内に自分のコードがどのように機能するかを忘れる（同じプロジェクトに取り組んでいる間！）ことにつながり、試行錯誤やスパゲッティをくぐり抜ける以外の方法を見つける方法がないことです。
- プロジェクトの管理にも苦労します。プロジェクトの進捗状況を数値化できる唯一の尺度は、未解決のバグの数だからです。しかし、（上記の理由により）いつでも何かが壊れる可能性があるため、これは非常に信頼できない数値です。
番目、私は同僚が現代の方法やそれらを使用する意欲の知識を欠いているとは実際には信じていません。現時点では、それを可能性として除外することはできません。これが私がここに来て、彼らが知っていることを知るための最良の方法は何であるかを尋ねる理由の1つです（明らかに、長い個人的なインタビューに加えて）。
4番目、UMLおよび自動テストに関するコメントをあまり真剣に受け取らないでください。これらは単なる例です。実際のところ、コードは設計者や管理者の気まぐれで作成され、ソフトウェアの設計は一切行われていません。おそらく、私はまだ大学発行のバラ色のメガネをかけていますが、それはガレージ開発の最高峰に私を驚かせます。
tl; dr
私はこれについて傲慢にならないように一生懸命努力していますが、私の同僚のプログラマーと管理者の両方が、ソフトウェアを開発するためのより予測可能で生産的な方法に対する欲求を表明しているようです。簡単な移行？
これについて開発部門の同僚に話しましたか？彼らが教育を受けていないことをどうやって知っていますか？それはかなり抜本的な声明であり、おそらくあなたはあなたが間違っていることに気付くでしょう。
新しい卒業生がそもそもなぜそうなっているのかを理解せずにプロセスをいじり始めたとしても、それほど下がるとは思いません。マネージャーはプロセスを愛し、追跡を愛し、愛されているように見えるので、私にとっての戦いで強化された懐疑論者は、マネージャーがあなたの見解に興味を持っていると感じています。
また、教科書でのソフトウェア開発方法は、現実の世界でのそれとは必ずしも必ずしも一致しないことに注意してください。彼らは確かに万能薬ではなく、バラ色の眼鏡を通して世界を見ることができます。 UMLはがらくたの負荷であり、それを持たないことはそれほど大きな問題ではありません。
まず、具体的な手順を明確にする経営陣が取るべきこと。 「プログラマーにもっと余裕を与える」はあいまいで、実行可能ではなく、測定できません。
次に、実際の問題を特定です。なぜプログラマーは徹夜で仕事をしているのですか？根本的な原因は常に存在し、その根本的な原因は「物事を成し遂げるのに十分な時間がない」だけにとどまりません。
第三に、信頼できる情報源を見つけると主張を裏付けるケーススタディ。ソフトウェア開発の問題の解決策について説明しているリソースは多数あります。あなたのケースを作るためにそれらを使用してください。
第4に、独自の条件で経営者にアピール。彼らは何を探していますか？測定できるという点で生産性を高める方法を探している可能性は高いです。つまり、「お金を見せて」ということです。
第5に、説明している問題が実際には存在しない可能性を考慮してください。会社が利益を上げており、開発者に十分な補償を行っている場合、徹夜は単純な計画の問題に要約され、不十分です。期待の管理。つまり、ソフトウェア開発方法の問題ではなく、スコープと機能の変更の管理の問題である可能性があります。
最後に、実践的な経験の不足を考慮に入れてください。教育は素晴らしいです。私にも1つありますが、その教育で自動的に専門家になることはできませんでした。それがやったことは、私を根本的に固めました。 「現実の世界」に入り、物事が実際にどのように機能するかを知ることは、まったく別の教育です。
あなたの会社はSVNとバグトラッカーを使用していますか？幸運を祈ります！卒業して新しい仕事を始めたばかりです。新しい会社のバージョンでは、ファイル名に日付が含まれているZipファイルを使用して、1つ以上の1回限りの10 kLOC VB6およびVB.NETアプリを管理していました。ただし、開発プロセスの改善に役立つと期待して採用したため、私の状況は少し異なります。以前の開発者は3〜5人であり、これらの開発者の1人を除くすべてが先に進んでいます。また、現在の雇用主を評価するためのはるかに優れた開発慣行を持つ別の同様の会社で1.5年のインターンシップを経験しています。
私はジュニア開発者として、教科書で読んだり、教授から聞いたことに基づいて大きな変更を加えるだけの十分な経験がないことをすぐに認めます。代わりに、より多くの経験を持つ人々の知恵を利用してください：実世界での経験を持つ教授、以前のインターンシップのメンター、および他の開発者のブログ。 Joel Spolskyの次の記事は洞察に満ちており、該当します。 Joel Test：12 Steps to Better Code 、および Getting Things Done With Done With a Grunt 。
ジョエルテストは次の質問で構成されています。
- ソース管理を使用していますか？
- ビルドを1ステップで作成できますか？
- あなたは毎日のビルドをしますか？
- バグデータベースはありますか？
- 新しいコードを書く前にバグを修正しますか？
- 最新のスケジュールはありますか？
- スペックはありますか？
- プログラマーは静かな労働条件を持っていますか？
- お金で購入できる最高のツールを使用していますか？
- テスターはいますか？
- 新しい候補者は面接中にコードを書きますか？
- 廊下のユーザビリティテストを行っていますか？
ソースコントロールとバグトラッカーを使用して、少なくとも2を獲得したようです。私の会社はゼロを獲得しました。正直、ゼロ。次の行を注意深く読んでください：真実は、ほとんどのソフトウェア組織が2または3のスコアで実行されていることです。私の会社は、ゼロのジョエルテストレベル。 （あなたのような！）利益を上げている成功している企業の多くは、あなたの会社のレベル以下のプロセスでお金を稼ぎ、ソフトウェアを書いています。
次に、「あなたが不平を言っているときに物事を成し遂げる」をコピーしてあなたの質問への回答として貼り付けることができます。私はそれを言い換え、ここで私たちの状況にいくつかの適応を加えました：
- Just Do It：彼らが公式でなくても、優れたソフトウェアエンジニアリング手法を個人的に使用します。ローカルマシンでVCS、 Jenkins CI および Redmine を実行しています。私は、バグを見つけたときにそれを排除し、コードを適切にテストし、可能な場合はユーザビリティテストを行うために懸命に取り組んでいます。自分自身に影響を与えることはできませんが、自分の仕様とスケジュールを書いています。私はドアを閉め、ヘッドホンをつけ、少し焦点を当てます。予備のセカンドモニター、数スティックのRAM、およびSSDを自宅から持ち込み、多くのオープンソースまたはフリーソフトウェアを使用してより優れたツールを用意しました。チームが望んでいない場合でも、優れたソフトウェアエンジニアリングの個人的なメリットの多くを自分に与えることができます。
- ウイルスマーケティングの力を利用する：変更が経営者の法定によるものではなく、有機的に広がることを許可します。ここで大胆な発言をします。これは、1年未満のジュニア開発者として変更を加えるための唯一の適切な方法です。調査を部門全体に電子メールで送信しないでください。ソフトウェアエンジニアリングに関する研究論文を読むようマネージャーに依頼しないでください。彼らにあなたがどのようにあなたの仕事を上手にやっているかを尋ねさせてください。年功がある場合は、直接変更することを検討できます。
- Pocket of Excellenceを作成する：優れたソフトウェアエンジニアリング手法を使用して、組織の他の領域よりも優れたコードを記述します。個人の開発者は、最初の10件のテストに自分で合格します。同僚のドメインに関する知識はありませんが、適切なコードを書くことができます。これは小グループに適用される＃1です。
- Bozosを無力化する：貧しいプログラマーがプロジェクトに与える可能性のある被害を最小限に抑えます。これは新入社員としての私たちの場所ではありません。人と本当に上手でない限り、あなたはおそらくこれを無視するべきです。
- 中断から逃れる：良い仕事を成し遂げることができる場所と時間を見つけます。管理に問題がなければ、ヘッドフォンが役立ちます。
- 非常に貴重になる：尊敬されるように本当に良いコードをたくさん書いてください（＃2と＃3を非常に助けます）。これは、仕事に保険をかけるためにひどいコードを書くことを意味するのではありません。これは、かけがえのない仕事と雇用保険の仕事の反対です。貴重であることは仕事をし、あなたに仕事の保険よりも良いキャリア保険を与えます。
記事をすべて読んでください、それは金です。私はプロセスに入って約6か月です。組織のスコアは約1.5で、これは開始時のゼロよりもはるかに優れています。私はその大きな進歩を考えており、私がここに1年いるまでに2つか3つまで達することができるなら、有頂天になるでしょう。
私の経験では、プロセス変更の提案が聞かれる前に、関係するグループとの評判を築かなければなりませんでした。グループが機能してきたシステム-多分よくないが、製品を何年も出荷するのに十分なシステム。未知の実績を持つ誰かの言葉に基づいて人々を未知のものに変えるように頼むことは大きな要求でした。
「現状維持は機能している。なぜそれを変えるのか。なぜあなたの言うことに耳を傾ける必要があるのか」
私は以前この道を行ったことがあります。それで私は何をしましたか？多くのこと（ソフトウェア開発の20年は長い）ですが、これは最も効果的に機能しているようです。私は評判を築くことから始めました。私は割り当てられたタスクを実行することで自分自身を達成したことを示しました。私は彼らのシステムとその背後にある理由も学びました。 （Steven Coveyは銀行口座の考え方を示しています。変更を要求することは、口座からの引き出しを要求することと同じです。大きな引き出しを行う前に、それをカバーするのに十分な量を入れる必要があります。）
評判を確立したら、小さな改善を提案する機会を待ちます。
「コードセットが変更されるたびにビルドを自動的に作成し、結果を開発者にメールで送信できたらどうなるでしょうか？」
「コードを自動的にビルドするようになりましたが、ビルドごとに単体テストを実行するとどうなるでしょうか？」
「開発サイクルの終わりに全員が1か月かけてコードレビューを行う代わりに、主要なセクションを作り直す前に、すべてのコミットをレビューしてみませんか？」
うまくいきましたか？はい。週に1回以上コードをチェックインするという考えに抵抗したチームは、現在、1日に複数回コミットしています。 CIシステムが1時間もダウンしていると、電話がかかってきます。すべてのソースコードは、ビルドごとに単体テスト（95％以上のカバレッジ！）を受けています。変更がコミットされると、チームは現在「継続的なコードレビュー」を行っています。
そして、私はまあ、私は再び私の評判を築き始めています。彼らはすでに、コミットごとに統合ビルドを作成するという考えを気に入っています...それを実現する方法があったら... :-)
かなり単純なはずです。最新のソフトウェア開発手法を採用して、他の手法よりも著しく生産性を高め、生産性をこれらの手法に反映させます。
だから...生産性がどこで発揮されるかについてリストを作成し、時間の経過とともに、リストの各項目について、卓越性を達成するために使用した方法の記録を保管してください。
製品やビジネスを管理するためのコピーブックの方法は、すべてに適しているわけではありません。私は医療画像プロジェクトで働いてきました。誰もがアジャイルな方法で働きたいと思っていましたが、問題は完全にアジャイルにできないことです。私たちのビジネスは規制されており、この製品が製品を販売するための条件を満たしていることを証明するには、非常に多くのドキュメントが必要です。
仕事の中心にいる人々は、実際にはプロセスについてそれほど気にしませんでした。彼らはそれをたわごとの仕事と考え、彼らの活動を遅くします（そうですほとんどのプログラマーはそうします）。
彼らは人々と協力して計画を立て、製品を出荷していると思います。これまでのところそれは機能しており、彼らはそれを変更する準備ができていません。
たとえば、Valveのような会社のオフィスにはマネージャーがいません。これは極端なケースですが、ほとんどの製品会社にはビジョンがあり、特定のものをハッキングして出荷します。プロセスを導入する際に、次の基本的な質問をします
- あなたが解決しようとしている問題は何ですか？
- 適切なプロセスなしで低品質の製品を出荷していることを発見しましたか？または、新しいプロセスを導入すると、チーム内での作業方法の改善に自信がありますか？
- 管理に問題がある場合、最初に修正する必要があるのはどれですか。彼らは従業員の士気に欠けていますか？
- どのようにして製品の品質を向上させることができますか。ユニットテスト、カバレッジ、コーディング標準、ガイドラインなどの簡単なものがプロジェクトに適合し、コードの品質を向上させることができます
- それらをそれほど傷つけることなくプロセスを合理化することはどのように可能ですか？
アジャイルな作業方法は、ビジネスのニーズに合わせて適切に調整する必要があります。 Web開発の場合は、うまく機能する可能性があります。彼らは早くて頻繁に出荷します。
UMLダイアグラムは一種の厄介なものであり、ほとんどの場合、あまり詳細なレベルのダイアグラムは必要ありませんが、時間がかかります。 アジャイルモデリング は完全に異なり、かなり単純です。このアプローチに従うように人々に頼むことができ、私たちのほとんどが簡単な手描きの図の観点から物事を話し合うとき、彼らはそれを行う準備ができているでしょう。
人々は変化を嫌い、私は調査が実際にはあまり役に立たないと確信しています。なぜなら、彼らが働き方に不満を持っているなら、彼らは自己学習組織として早くからそれを修正していたからです。しかし、ここであなたは彼らの問題を解決するために彼らの助けを求めています、そしてあなたは彼らにとって本当に何がうまくいくかはっきりと言うことはできません。じっくりと考えて、オーバーヘッドの少ない開発プロセスを合理化することをお勧めします。
抽象レベルでは、すべてのレベルの問題を明確に特定し、1つずつ取り組み（上から開始するのは簡単です）、チームを成功に向けて成長させる必要があります。
プログラマーが最新のソフトウェア開発方法を採用できる/採用する意思があるかどうかをどのように評価できますか？
あなたがする必要がある最初のことはあなたの同僚と話すことです。あなたの質問から、なぜあなたは現在のプロセスまたはそこに欠けているのがなぜ正しいのか理解していないという印象を受けます。誰かに聞いてください！同僚が代替案を認識していて、後で議論できる理由でそれらを使用しないことを選択している場合もあれば、知らない場合もあり、同僚を紹介して、彼らがあなたにどのように役立つかについて議論することもできます。チーム。
チームの文化、手順、または構造を変更することを試みることは、なぜそれが現在災害のレシピを作っているのかという理由を理解せずに。この場所につながった懸念を理解するために努力し、次にあなたが見るかもしれないいくつかの解決策について話し合ってください。新鮮な目が素晴らしいですが、それはあなたが領土をよく知っている人々と対話をしている場合に限られます。
ソフトウェア設計のほとんどの方法論とベストプラクティスでは、アプリケーションを最短の時間で構築できるとは主張していません。あなたの会社は、あなたが数人の徹夜者を通してあなたの方法で「カウボーイコード」をして、何かを解放することができるという証明です。彼らは時間通りに「それ」を成し遂げたので、経営陣は幸せです。
バグが現れると、それらに不釣り合いな時間を費やしますが、管理者は気にしません。どういうわけか、それらはそのリリース日を迎えることで強化されています。誰かがあなたのゲームを強化する素晴らしいアイデアを持っているでしょうが、あなたのコードはそのような劇的な変更を行うにはあまりにも脆弱です。まあ、何だったのでしょう。
ゲームの特定の領域にアイデアの1つを適用することを提案します。このようにして、他のアプリと比較して利点を追跡および測定し、これらの結果を経営陣に提示できます。例：自動テストを提案します。同僚のプログラマーは、実装できるかどうかにかかわらず、非常にすばやく表示されます。時間をかけてユニットテストに堪能になった開発者は、その使用に反対しています。
私見-任意の時間枠管理が開発を決定することがあなたの最大の問題です。これらのアイデアを思いついているユーザーや意思決定者に開発者を近づける必要があります。真の要件を発見してください。ゲームをさまざまなプラットフォームで利用できるようにする必要があるからといって、ブラウザで実行する必要があるわけではありません。猫の皮をむく方法は常に複数あります。
"予測可能な...ソフトウェア開発の方法。"
純粋なプロセスは予測可能な結果をもたらします。しかし、ソフトウェアの作成は、文字通りプロセスの作成であり、プロセスの単なるフォローではありません。製造の類推：ソフトウェア開発は、ウィジェットを作成するためのファクトリを設計するようなものです。ウィジェットファクトリの日常的な実行ではありません。
すべてのソフトウェア作成プロセスは不純です。 （自動生成されたソリューション以外）
不純なプロセスには、純粋なプロセスの予測可能性はありません。プロセスで発生するオンザフライのクリエイティブアクションが多いほど、純粋さが低下します。
純度は善悪を意味するものではありません。
生産性に関していくつかの重要な側面があると思います（私は管理の専門家ではないので、これは私の2セントにすぎません）。
これが私のポイントを説明するための簡単なシナリオです。
実装する機能のパッケージが2つ（XとY）あり、最初のパッケージX（最初のリリース）が完了するまでに6か月かかるとします。また、パッケージXが後のモジュール（Yなど）で使用されているとします。
プログラマーは「Xを正しく書く時間がない」とよく言うと思います。Xを書くとき、XはYで再利用されることを知っており、コードとデザインをクリーンアップして、より堅牢で再利用できるようにしたいからです。 。コードを再利用しない場合でも、クリーンなコードを使用すると、後でバグを修正する必要がある場合に多くの時間を節約できることがわかります。それはあなたが学校で学ぶことでもあり、これらは良い原則だと思います。
しかし、管理の観点（つまり、業界では、いわゆる現実の世界）から見ると、リリース1は100％確実なものであり、Xがリリース1に十分満足した後にXに費やされた余分な時間が考慮されます。時間の無駄。顧客はクリーンなコードではなく、機能するソフトウェアを購入します。
6か月後、Xを多用するパッケージYで作業するときに、適切な図と設計を作成し、設計をより拡張可能にしたいとし、6か月前にこれを行ったとしたら全体の問題はまだあなたの心の中にあります。
とにかく、Yを実行する必要があるため、Xを拡張する必要があります（追加作業）。 Xに拡張機能をすばやく追加すると、Xは乱雑になり始め、新しいバグが表示されます。したがって、代わりに
- リリース1の7か月（Xを適切に実行）、および
- リリース2の7か月（Yを適切に行い、Xの作業はほとんどありません）、
あなたが持っている
- リリース1で6か月（この作業を行う最小限のX実装）、および
- リリース2の9か月（Yの実装、Xでの回避策とバグ修正の実装）。
2番目のシナリオでは、平均で生産性は低くなりますが、管理の観点から見ると、計画できるのは短期/中期の計画のみです。基本的に、不要な可能性のあるものは最適化しません。リリース1とリリース2の両方について作業を計画することはできません。
これは逆説だと思います。マネージャはリリース1で1か月節約し、リリース2でさらに2か月費やすことを好みます。これは、リリース2での追加コストがリリース1での節約よりも確実でないためです。
そのため、多くのプログラマーのフラストレーションの多くは、「最初は適切に行う時間はないが、後で修正する時間は常にある」（そしてその結果としての生産性の損失）は、プロジェクトの方法に固有のものだと思います。計画中：2年後の市場がわからないため、最適な計画を立てることができず、生産性の低下を受け入れる必要があります。
あなたの質問はかなり大胆だと思います！私はあなたが何を意味しているのかを完全に理解しています。また、あなたが経験したことのいくつかの部分を共有しています。それが私が返信する理由です。
メソッドについては、それが返ってくるので、メソッドに適応する必要があると思います。あなたが彼らの立場に身を置くなら、彼らは「ちょうど卒業した男が私に（5年以上の開発）仕事のやり方を教えてくれるだろう、私が今までやったようにやっていることをやって昇進し昇進したら「ご存知のように、同僚とうまくいかない状況に発展する可能性のあるかなり危険な発言。最初に彼らがどのように使用するかを学び、後で対立せずに改善しようとする必要があるため、常に避けています。
あなたの経営陣からの返答は、「お金を見せるか、それを維持する」と理解しています。これも良くありません。何を扱っているか100％知らずにスポットライトを浴びます（以前の方法がどれほど効果的であるかを意味します）彼らへ）。
私の場合、私が知っている方法を自分にのみ適用する方法が対処法であり、UMLを維持する必要があるコードで使用し（現在は勤務時間外にそれを行っています）、それを示唆することなくそれを行った理由を説明する傾向があります正しい方法。 （ご存じのとおり、UMLはExplorerのマップとしてのコード用です。マップなしでExplorerを実行できますが、家に帰る途中でさらに2 km進んでも文句はありません:)）
現在、元の作成者よりもコードに関する質問が多くなっています。主にコードに慣れているためですが、短時間で何かを変更する方法に関するメモを含むニースマップ（UML）も追加しているためです。 （コードの所有者も変更を続けます）。
私のアドバイスは、あなたが自分で知っていることを使用しており、より効率的になると、スポットライトがあなたに向かって移動します。それから、信頼性を危険にさらす前に、有効性について話し始めることができます。