Clever Geek Handbook

私は良くなっていますか？





私たちのテクニカルディレクターは、「私もあなたも彼らのようになってほしい」というコメントとともに、各プレゼンテーションにこの写真を掲載しました。



読者の皆様、ご挨拶。



柔軟性と密接な相互作用（ブルジョア-アジャイルとDevOps）の相互作用の雰囲気には、継続学習のようなものがあります。 本質的に、一般的な考え方は、単純な事実を認識することです。あなたがどんなに一生懸命働いても、どんなにプロになっても、あなたはいつでも、より良くすることができます。



劣等感を引き起こさないために、効率を95％にすることをルールにしました。

この数字は天井から取られていますが、プロセスに十分に関与していることを理解する権利を与えてくれます、私は自分の能力を最大限に活用しようとしていますが、常に5％が十分ではありません。 新しい知識が得られたので、もう一度試してみました-しかし、数字は常に同じです-95％で、1％以上ではありません。



ただし、同じ質問をするたびに、良くなりますか？



スクラムには、洗練（別名評価）などの興味深いプロセスがあります。 各チームメンバーは、スクラムポーカーカードのデッキを手に持ち、各ストーリーのポイント数が記載されたカードを表示する準備をします。 ストーリーは、すべてのチームメンバーが何をどのように行うかを正確に理解するまで、詳細に議論され、分解され、噛まれます。 コンセンサスに達した時点で、製品の所有者は神聖なフレーズを言います：「評価しますか？」 1人、2人、または3人のプレイヤーが互いの評価を見てマップを表示し、それらが異なる場合は、全員が同じ評価になるまで再度話し合います。



評価を決定する多くの方法がありますが、私たちのチーム（私たちは開発者ではなくエンジニアです）が評価の基準として次の基準を採用しました：期間、複雑さ、リスク、不確実性、および第三者との相互作用（読み取り-近隣のチームによる）。

たとえば、使用するすべてのサブネットをインベントリするタスクが表示されます。 これは難しい作業ではありません。原則として、コアルーターを登ったり、Vmwareで仮想スイッチを確認したり、極端な場合には他のエンジニアとチャットしたり、古いドキュメントを探して内臓を調べたりするだけで十分です。 ただし、1週間または2週間かけて、各Ipsnikを探すことができます。 そして、このタスクを評価する方法は？



しかし、別のタスクがあります-たとえば、特定のケースでAnsibleの動的インベントリをマスターする-同じVmware。 また、一見シンプルなタスクですが、さらに深くなると、別の質問が発生します。グループ化の方法は？ タグ、リソースプール、またはネットワーク別？ または、データセンターとクラスター内の補助グループに基づいて大規模なグループを構築しますか？ ESXホストまたはゲスト仮想マシンのみを追加する必要がありますか？ 「複雑さ」に加えて、このタスクには不確実性の基準があります。



さて、パルプ自体。 2週間全体で1人のエンジニアがかかる「最大の課題」は5ポイントであると考えています。 ここから次の否定的な点が流れ出します。





標準問題を示します



タイムラインに基づいて評価を行うことは正しい決定ではないことは既に上記で明らかです。

次に、標準タスクをいくつか実行します。たとえば、開発チーム用に1台のサーバーを準備します。 サーバーは、鉄または仮想のいずれかであり、インストール/作成、OSのインストール、IPサーバーの割り当て、ドメインへの追加、バックアップと監視のセットアップ、ドキュメントの記録、株主の運営へのサーバーの転送が必要です。 ストーリーは標準であり、チームのすべてのメンバーがそれに対処します。誰も何かを説明/教える必要はありません-1ポイント。



特定の基準に基づいて、人は次のことを理解します：「これに1時間、それに30分、まだ電子メールで、1日でできます。」標準を使用すると、大量の中断があってもこの方法で他のタスクを評価できます。



たとえば、Puppet-正面の同伴者はすでに犬を食べていましたが、特に使用していません（ノードとロールを登録するだけで、それほど気にする必要はありません）。 そして、ここに状況があります-メールスキャナーを1時間ではなく5分でデプロイできるように、amavis用のモジュールを書く必要があります。 利点は明らかであり、その利点は計り知れません。Infrastructure-as-Codeは同じです。 しかし、モジュールの書き方を誰も知りません。 そして、ここに別のチェーンがあります-マニュアルを吸う、ベストプラクティスを求める人に行く、開発、テスト環境のセットアップ、テスト、修正、テスト、修正、Puppetfileへのモジュールの追加など -たくさんのこと。 ここで、エンジニアはすでにスラックを与えることができます-多くの「if」に怖がって、彼はタスクを過大評価するか、さらに悪いことに過小評価することができます。 しかし、タスクの「スケルトン」を思い出せば、このタスクにどれだけの労力、血、汗、痛みがかかるかを少なくともおおよそ理解できます。



標準の数は異なる場合があります。





したがって、特定のパフォーマンスが形成され、バーが設定され、それを増やす必要があります。 しかし、「改善するか」という元の問題は残っています。



解決方法は？



速度に基づいて



評価の追加の利点は、結果を測定し、以前のスプリントと比較できることです。 このスプリントは10ポイントで、私はオフィスに来たばかりで、同僚は私を最新の状態にするために多くの時間を費やしました。 ここではすでに15人に達していますが、2人のエンジニアが休暇中です。 すでに20ポイント、クールですが、これがベースバーです。 いばらから星まで、無限に移動できます。 Velocityは、チームの潜在能力を測定するための基本的な指標の1つですが、それを唯一の客観的基準とすると、スクラムマスター/ POでは、同僚がタスクを2〜3倍評価し始めることを期待します。 :)



タスクのスケルトンの状況は異なります-サーバー配信。 タスクが1ポイントの「重さ」になると、vmwareで手でサーバーを作成し、テンプレートからOSをインストールし、手でIPを登録し、NRPEをインストールし、Veeamを構成してこのマシンをバックアップする必要があることを理解しています-すべてが自動化されている場合 ここでは、Terraformでマシンの構成を行い、ビルドはCIでリグされ、サーバーはタグに基づいて動的インベントリの目的のグループに追加され、別のビルドがリグされます-VZHUHとNagiosのエージェントのロールがロールバックされ、バックアップスケジュールにサーバーを追加するスクリプトが実行されます これは、タスクの労力が削減されることを意味しますか？ もちろん。



この場合、タスクテンプレートを確認する必要があり、結果としてパフォーマンスに悪影響を与える可能性があります。 そして、別の基準が表示されます。



成果物



消費されるストーリーポイントの数だけでなく、行われた作業の実際的なメリットも重要です。 それは非常に抽象的な方法で測定されます-私たちの場合、それは一般的に利害関係者の笑顔の大きさですが、「私たちのチームはこのスプリントのためにすべてのサーバーを新しいドメインに移行し、古いスプリントは全滅できます」と言う方がはるかに良いですポイント。」 50ポイント、すごいクールですが、何をしましたか？



しかし、繰り返しますが、成果物の数を増やすというルールにしましょう。チームはより良く機能しますが、何が間違っているのでしょうか？



別のケースがあります-クリスマスの準備。 これは当社のeコマースプラットフォームにとって特別な時期であり、すべての開発者、エンジニア、アナリストが次々と新しい機能を投入し、次の質問に答える準備をしています。





インフラストラクチャの松葉杖をどのように強化したかについては後で報告しますが、これは成果物と間違えることはありません。来年、この質問が再び発生し、Sansaraの車輪が再び曲がります。



チームはうまく機能していないと考えられていますか？ いや



それで、私が良くなっているかどうかをどのように知っていますか？！



仕事。



この質問に対する特別な標準的な回答が得られることを期待して、アジャイルコーチをすべて調べました。 回答を受け取りました-特別な標準的な回答はありません。 しかし、1つの推測があり、彼女の名前はWorkです。



作業中とは、1つの成果物に費やされた時間を指します。 時間は、ストーリーポイントから経験的に計算されます。出力では、結果と費やされた労力の比率を取得できます。



その結果、エンジニアとしてチームのメンバーとして、20ポイントで4つの成果物を配達した場合、病院内の平均気温は1つの成果物で5ポイントであることを理解しています。 次のスプリントは10 x 30、そして15 x 40です。



したがって、私のチームがより速く、よりスマートに、より高く、より強く 、より効率的になったかどうか、そしてエンジニアとしての昨日よりも強くなったかどうかを理解します。


More articles:


All Articles