CTOへの公正な期待

私はあなたの新しいCTOです。

私たち全員が一時的にパラレルユニバースに移動したと想像してください。私はあなたの新しいテクニカルディレクターであり、チームからの私の期待についてお話しします。

過去に期限、コード品質、顧客満足度に問題があったことを知っていますが、業界として、コミュニティとして、私たちはそれらを克服し、より良く働くことができます。

私たちはプロですか？

これが主な質問です。 私はあなたに何を期待しているのかをお話しします。これにより、私たちがプロフェッショナルであるかどうかの質問に対する答えが決まります。



私たちは彼らである必要があります。 長年にわたり、私たちはプロ意識からは程遠いものでした。 私たちはコーヒーの上に座っていて、日付を気にしないオタクでした（冗談です、それは愚かでしょう）。

しかし、私たちの文明はそれに依存しているので、私たちは職業を真剣に受け止めていませんでした。



この部屋を見て、ここで動作するソフトウェアの量を数えます。 スマートフォンやラップトップさえ数えないかもしれません。 部屋を出て、ある平方メートルから別の平方メートルに移動し、エレベーターに乗り、自動ドアを通過する間、あなたの生活に影響を与えるソフトウェアをカウントします...これらはすべてソフトウェアによって制御されます。

空気の加熱と冷却、マイクとその録音による音声増幅の品質-すべてはソフトウェアによって制御されます。

あなたが外出すると、各マシンには複数のプロセッサがあり、それぞれがコードを実行します。 あなたはコードの海に囲まれています。

だから私の質問は次のとおりです。朝の3時に22歳のエンコーダーを書いた人に1日に何回あなたの人生を任せますか？

答えは多すぎる。 特定の段階で、イベントが発生します（既に発生している場合もありますが、そうではないことを願っています）。 非常に深刻なイベント。 いくつかのコーダーは愚かなことをし、何万人もの人々が死にます、そして世界のすべての政治家は正しいrightりで立ち上がって、私たちに指を向けます。

私たちがそれを与えなければ、彼らは私たちのためにそれを与え、そしてこの答えはコントロールになるからです。 私たちは皆公務員になりますが、これは業界にとっては良い転機にはなりません。すべてが公務員になるためです。

期待する

何よりもまず、他のすべてのことに先んじて、たわごとを公開しないことを期待しています。

なぜあなたはそれを言わなければならないのですか？ たわごとを展開したからです。

そして、プロフェッショナルなソフトウェア開発の本質は、今日で終了することです。 ここでこれに終止符を打つ予定です。また、不正なコードを再び公開することはありません。

なんで？ 私たちには責任があるからです。 私たちを雇った人々は私たちのコードを読むことができません。 彼らはそこで私たちが何をしているのかを知らず、私たちが書いていることを見て、それが良いかどうかを測定することはできません。

彼らが私たちに言うことができるのは、「私たちは木曜日までにこれを必要とします」です。

そして、私たちは実際に私たちが展開していることを知っている唯一の人です。 私たちがやっていることを誇りに思うのは、他の誰かではなく私たちのためです。

仕事で1日8時間過ごした後、家に帰ってシャワーを浴びる必要があるのは、彼が一日中stable舎をかき集めたからです。

私はあなたにこれが非専門的な行動であることを宣言します。 私は、私たち全員が毎晩自分自身に「神は見た、今日は素晴らしい仕事をした」と言うことができる必要があると宣言します。 規律に従って、良いコードを書いたので、ビジネスはそれでうまくいきます。」 労働の成果に誇りを持って帰らなければなりません。

いつでも準備ができていると期待しています。

つまり、ビジネスが展開したいとき、私たちは準備ができているということです。 遅延なし。 1〜2か月待たなければならない理由はありません。 QAが終了するか、コードが「解決」されるまで待つ理由はありません。 「待機期間」がある場合は、...専門外主義の程度...これはあなたにとってゼリーではありません！

コードは安定化されるべきではなく、ただ安定しているべきです。

いつでも準備が整い、デプロイの準備が整うのを待っています。 まあ、多分私はあなたに一週間を与えるでしょう。 「Deploy！」と言って、「OK、すべて金曜日までに」と言います。 「月」や「半年」を聞きたくありません。 準備をしてほしい。

安定した性能

生産性が安定していることを期待しています。 最初は速く働き、その後遅くなることは望ましくありません。

私はすでに、すべての開発者が尾なしで新しいプロジェクトのために集まっていることを見てきました。彼らは数ヶ月で山を転がすことができます...そして彼らは遅くなります。

そして、私たちが待つほど、彼らの仕事は遅くなり、プロジェクトの年齢と生産性は重要なポイントに落ちます。

もちろん、ビジネスはこれに対応する必要があり、開発者が増えるため、問題はさらに難しくなります。

毎週、あなたの生産性は変わらないと予想しています。

これはおそらく、プロジェクトに混乱があると速度が低下するため、混乱を作成すべきではないことを意味しますが、私はそれをあなたに任せます。

生産性を一貫して高くしたい。

安価な適応性が欲しい。

そして、これによって私は些細な状況を意味します。ビジネスが変更を行いたいとき、あなたは言う。 問題はありません。それらを紹介します。いいえ、腎臓を与える必要はありません」

なんで？ 私たちが行うこのことは、「ソフトウェア」と呼ばれます。 最初の言葉はソフトです-ソフトであることになっています。 そして、なぜコード-ソフトウェアと呼ぶのですか？

変更しやすいと想定されています。 そして、彼をその状態に保つのはあなたの責任です。 私たちの製品が私の新しい要件を受け入れないということは言われたくありません。

アーキテクチャが私の要件を受け入れない場合、アーキテクチャの何が問題になりますか？

安価な適応性を提供できないチームの何が問題になっていますか？

変更が非常に高価なのはなぜですか？ それらが非常に高価な場合、何かが間違っています。

あなたからの絶え間ない改善を期待しています。 コード、プロセス、パフォーマンスの改善。

汚れたコードが表示された場合は、それをきれいにして、それを恐れないでください。

悪いプロセスを見つけた場合は、それを修正する必要があります。

私は継続的な改善を期待していますが、何も改善されない何らかの骨化した行動ではありません。

より良い！ 常に。

大胆不敵な能力

たとえば、画面でコードを開いて、「ああ、神様！」と最初に思ったとき、そして、「いいえ、触らない」と思ったのです。あなたがそれを破ると、それはあなたのものになります。

だから、あなたは完全に無能で、それを閉じて怖がっています。 まったく非専門的で無責任です。 私が何かを期待するなら、それは間違いなくそうではありません。 大胆不敵な能力が欲しい。 そのコードを目で見て、「私はあなたを変えます、気にします、私はあなたをきれいにします」と言ってほしい。

また、コードを恐れないように、必要なツールを適用する必要があります。

たとえば、テストを使用します。 あなたが他に何かできるなら、そうするが、あなたが作成したものを恐れてはいけません。

典型的な無責任は、あなたが突然変化することを恐れているシステムを作成することです。 彼女はあなたのコントロールを失い、あなたは彼をそこに留める義務を無視して、瓶から魔神を解放しました。

究極の品質

私は極度の品質を待っているので、絶え間ない掃除に関するこれらすべての言葉は重要です。

妥協についてのこのようなナンセンスな言葉を聞きたくありません。 これらの言葉だけが汚いです。

この古い考えは、「それを速く行う唯一の方法は、大きな混乱を作ることである」ということです。 誰がこれを教えたの？ 間違いなくママ。

混乱を広め、迅速に作業することはできません。 いいえ、あなたはそれがこのように感じるのであなたが速く働いているように見えますが、実際にはそうではなく、あなたはそれを知っています。

混乱して、とにかく速く進むことはできません。 高速で動作する唯一の方法は、できるだけ高品質を維持することです。

悪いコードに対処するとき、通常何人があなたの仕事を遅くしますか？



上司が来て言います。「木曜日までに必要です。 あなたが望むことをしてください、しかし、私は木曜日までにそれを必要とします。」

この状況で何をすべきか知っていますか？ 座って、できる限り最高のコードを書く必要があります。 必要なすべてのテスト。 プレッシャーがかかった場合にのみ、あなたがそれらを本当に信じることができるので、あなたはそれぞれの規則を二重に厳密に守ります。

ストレスがなければ、好きなことは何でもできますが、急いでやることは、あなたが本当に信じていることを示しています。

また、優れたコードを書くことが開発の迅速化に役立つと信じている場合は、急いでさらに良いコードを書くことになります。 テストが開発をスピードアップすると信じるなら、緊急時にさらに多くのテストを書くでしょう。

QAのせいにしません

QAにはバグの検索は含まれません。 実際、QAは何も見つけるべきではありません。

欠陥なくコードをリリースし、QAがテストを完了すると、「何も見つかりませんでした」というレポートが表示されることを期待しています。

彼らは一般的に彼らが仕事を持っている理由を疑問に思うべきです。 「何も見つからない、これらのプログラマの問題は何もない、彼らは私たちにバグを与えない」

もちろん、彼らは時々バグを見つけます。なぜなら、彼らはそこに座っているからです。 そして、彼らがそれを見つけたとき、開発者は途方に暮れるはずです。 「どうやってそこにたどり着けますか？」

QAあなたはバグを探すための僕ではなく、デバッガではありません。 できる限り最高のコードを作成することはあなたの責任であり、準備が整って動作するまでQAでリリースしないでください。

私たちの多くが「製品が機能するまでいつでも作成できる」という計画方針を採用しています。

製品はいつでもデプロイできます。名前を付けるだけです。

それが機能する場合、それは別の質問です...

QAで行うことは次のとおりです。 私たちは彼らに製品を送り、それが機能しないことを知り、期限を遅らせる方法としてそれらを使用します。

自動化

多くの自動化を期待しています。 あなたのテスト。 手動テストは必要ありません。なぜ人々が手動でテストするのかまったく理解できません。

画面の画像を参照してください 。 これらは、大企業のQAマネージャーの手です。 彼が保持している文書は、彼の手動テスト計画の目次です。 8万件の手動テストがあり、彼は6か月ごとにインドにテストを送ります。インドでは、テスターの軍隊がテストを実行します。

彼がスライドに載っている理由は、2008年があり、危機があるからです。 そして、彼はこの文書に「上司が手動テストの予算を半分に削減した」という言葉を渡してくれました。

それで彼は、テストの半分を捨てるべきかと私に尋ねました。

私は彼に答えた。 システムの半分が機能することを確信することは決してありません。」 手動テストは常に終了するはずです。

システムがますます多くなると、より多くのテストが必要になり、より高価になり、最終的にはCFOの予算の行になり、彼はそれを見て、「うーん、これはバカだ」と言うので、彼は正しい、これは愚かです。 自動化！ 手遅れになる前にテストを自動化します。

脆弱性なし

壊れやすいものはないと思います。 システムのそのような部分について聞くのはうんざりです。

「そのモジュールに触れることはできません。毎回行うと、7か所で壊れます。 そうしないとクライアントは運命づけられるので、誰も彼に触れてはいけません」、いいえ、私はこれを必要としません。

あなたのコード、その一部を恐れることをやめ、最終的にはプロのように振る舞うようにしてください。

お互いを支え合う

私たちはチームです。 チームはお互いをカバーしています。 コードの上に座ってそれに触れることを許可されていないプログラマーの束は必要ありません。 コードに特定の所有者を持たせたくない。 共有する必要があります。 互いに交換できるようにしてほしい。

各選手が自分の立場を持っているが、人々は失敗する可能性があるため、それぞれが他の選手でプレーできるスポーツチームを想像してください。

海の船を想像してください。

同じように振る舞う必要があります。

私たちは、私たちが助けを持っていることを確認するために、役割を変え、他のすべての人に説明する必要があります。

プログラマーとして、私が何らかの理由でどこかに姿を消した場合に備えて、私の仕事の仕方を知っていることを確認します。

チームに1人の従業員がいて、休暇中にプロジェクト全体を停止することは専門的ではありません。

別の質問は、あなたがそれをどうするかです。 知りません。ペアプログラミングを試してみてください。 それが好きではありません-別の方法を見つけますが、この方法が必要です。そうしないと、お互いを交換することができません。

時間の正直な推定

時間の評価では常に問題があることを知っています。 これらはあなたに責任を負わせるものです。

誰かが「これは受け入れられない、もっと速くする必要がある」と言うかもしれませんが、開発者はそれを知らされません。 あなたには正直な評価が必要ですが、それは何ですか？

日付は嘘です。 あなたが日付を呼び出す場合-あなたは嘘をついている、あなたはこの日付をキャッチすることはできません、それはあまりにも正確です。 範囲を聞きたいです。 確率分布とは何ですか？ この金曜日または来週の金曜日までにすべての準備が整う可能性を知りたい。

私はその範囲を聞くことを期待しており、彼らが「もっと早くやれますか？」というスタイルの質問であなたを押しつぶし始めたら、「いいえ」を聞くと期待しています。

ノーと言う

専門家のすべてのタスクのために-これが最も重要です。 ところで、あなたが雇われたのは彼女のためです。 いいえ あなたはそれを信じないかもしれません、あなたはあなたが「はい」と言うために雇われたと思うかもしれません。

しかし、誰でもイエスと言うことができます。 たとえば、犬はとてもうまくやっています。 あなたが雇われたのは、上司やマネージャー、そしてビジネス全体が持っていないような知識を持っているからです。 そして、この知識はあなたにノーと言う力を与えます。

いつノーと言うべきですか？ これは、あなたや専門家が直面する最も困難な課題であり、最も重要な課題でもあります。

気まぐれに「いいえ」と言ってはいけません。「私はあなたが好きではないので、いいえ」と言ってはいけません。

あなたが本当にすべきでないことは、答えが「いいえ」である間に「はい」と言うことです。なぜなら、それは嘘であり、あなたは雇われたものをしていないからです。

もちろん、失敗は否定性を引き起こしますが、これは予想されることです。 ビジネスは進歩を望んでおり、彼らにとって重要です。 彼らがあなたの拒否に感謝することを期待するのは愚かですが、拒否も同意として重要です。

ビジネスは最終的に状況を評価し、「うーん、これらの人がノーと言ったのは良いことだから」と言うからです。 彼らが同意すれば、数百万ドルを無駄にしたかもしれません。」

あなたはみな、拒否することになっている間に誰かが「はい」と言った死んだプロジェクトを見ました。

他に何も言えない？ 「少なくとも試して」というリクエストが来たとします。 正解はノーです。

そして、それだけではありません。 あなたが同意した場合、それはあなたが何かを予備にしたことを意味します。 あなたのポケットの中の銀の弾丸のようなもの。 そして、あなたはそれについてマネージャーに伝えませんでした。

だから、彼はついにあなたから「私はしようとします」を絞り出し、あなたは今、あなたがあなたのポケットからこの弾丸を手に入れることを確信しています。

しかし、真実はあなたがそれを持っていないということです。 あなたは他に何もしません、あなたのアプローチを変えないでください。 何も変わりません。 また、以前と同じ速度で、他の場合と同じコードを記述します。

「試してみます」と言うだけでは、何もしません。 あなたが変えた唯一のことは嘘だった。 あなたが試してみることに同意したとき、あなたが実際に言ってみたので、「去って、私はあなたにうんざりしていて、それについてもう話したくない」

継続的な積極的なトレーニング

皆さんそれぞれがこのアプローチをとることを期待しています。 まあ、この部屋ではむしろ教授に講義をしますが、それでも言わなければなりません。

ソフトウェア開発者の責任は最も重要なことの1つであり、学ぶことです。 私たちは驚異的なスピードで発展している産業です。 数年ごとに新しい言語、絶えず新しいプロセス。 私たちは非常識なペースで動いており、少しでも遅れをとっている誰もが追いつくことはないでしょう。

言語は波のようになり、プロの開発者のスキルは、彼らの紋章に留まることです。

たぶん、あなたはRubyを知っています。 あなたはそれをあきらめ、5年も経っていません。 何か他のものがあるでしょう。

したがって、次の波を楽しみにする必要があります。 クロージャーまたはScala、おそらくF＃、知っている人。 その時が来て、あなたは次の波に飛び乗って、その波にとどまり続ける必要があります。

私たちは皆、常に積極的に学ぶ必要があります。 雇用主がこれを行うことを期待する場合、あなたは運が悪いです。 あなたが彼らが本を買って会議にあなたを送ると予想するなら、あなたはすでに予定より遅れています。 早く学ぶ必要があります。

あなたは医者に来て、あなたの医者が夕方に家に座って多くの医学雑誌を読み、スコッチテープの大きなボトルを持って帰って来ないで、次の4時間か8時間脳を我慢できないことを望みます。 あなたはそれが発展することを望みます。

訴えられた場合、弁護士が必要な最新の法律をすべて知っており、勤務時間外にこれを行うことを希望して弁護士に頼ります。

これはあなたにも当てはまります。

キャリアに週に20時間余分に費やすことを期待してください。 これがプロの仕事です。

これは労働者には適用されません。

メンタリング

互いに教えます。 業界にはひどい教育問題があります。 教育機関は、若いプログラマーが仕事を始めたときに直面しなければならないことに備えるために何もしません。

彼らは彼らに言語、big-O記法、アルゴリズムを教えます。 多分彼らはプロジェクトで働いています。

これらのプロジェクトを想像できますか？

若い男たち、学生。 彼らはどのようにプロジェクトを作りますか？

ビールパーティーの後の午前3時に、彼らが学ぶ方法を示します。

その後、彼らはオフィスにいることに気づき、なぜ彼らは行動を変えるのでしょうか。 研究所ではすべてが素晴らしかった。

誰もこれについて何もしません。 これらの人々を専門家に変える必要があり、それは私たちの責任です。

私たちの仕事は、プロフェッショナリズムの種をsoき、産業界が後でそれらを刈り取ることができるようにすることです。

業界に15年以上在籍している方は、トレーニングを受ける必要があります。 若い人たちに何をどのようにやるかを教えること。 どんなルールが存在し、良いコードと悪いものがあります。

振る舞いと同じこと。

これは私が皆に期待することです。



現在、学習はしばしば問題です。

同僚をTDDに固執させるにはどうすればよいですか？ まさか。 自分に固執してください。

それらを専門家のように振る舞わせる方法。 まさか、プロのように振る舞ってください。

これは個人的な決定です。 自分でそれを行うと、他の人が言うかもしれない、「うーん、彼は頭の中に良い考えを持っています。 たぶん私は彼のようにすべきです。」 または、彼らはこれが彼ら自身のビジネスであると言わないかもしれません。

しかし、決定はあなた次第です。



ご清聴ありがとうございました。