お客様と話し合い、ユーザーが長い間待ち望んでいた製品の重要な機能を次のリリースでリリースすることに同意しました。 PlanningPokerの翼に駆けつけ、評価が始まり、バム...
-このモジュールには入らないようにしましょう。 コードは文書化されていないため、すべてが失敗して崩れ始め、特に課金が発生します。
-私たちの前に、愚か者のチームが働き、彼らはこのプロジェクトでプログラムすることを学びました。 ここに登ると、チームにやる気が落ちて......
-仕組み...コードを確認する必要があります。 書いた人はすでに去っていて、文書はありません。 少なくとも1か月。
-データをアップロードしましたが、すべてが遅くなり始めました。 原因の調査にスプリントを捧げる必要があります。 （そして連続していくつかのスプリントで）
あなたは、何か奇妙なことが起こっていること、プロジェクトが「病気」であること、あなたが前もって知っていればおそらくこれを避けることができたであろうことを理解しています...
そのような崩壊を避けるために、今誰が「顔を負かす」のか、次のプロジェクトがやって来たときに誰を防ぐべきなのかを理解しようとします。
古いプロジェクト
状況は予測可能です。 プロジェクトを継承すると、コードが理解できず、ドキュメントがないか、絶望的に古くなっていることがよくあります。 プロジェクトの名前に言及した開発者は、吐き出し始めます。
PlanningPokerは問題を特定します-同僚はこのモジュールに機能を追加するのにどれくらいの時間を評価するためにこのモジュールまたはそのモジュールがどのように構成されているかを理解しようとしていますが、すべてが混乱しているため、適切な評価を行うには数週間かかります...オコダ。 そして、リファクタリング/ハードリファクタリング-それ以上ではないにしても、数ヶ月かかります。
また、本質を理解した設計パターンを使用してコードをリファクタリングできるだけでなく、ドキュメント化されていないデータベースからドキュメンタリーからロジックを正常に抽出できる必要もあります。
体系的なアプローチが必要です。 誰に指示し、誰に同意しますか？
新しいプロジェクト
しかし、これはProductOwner初心者にとっては本当に驚きかもしれません！ 新しいプロジェクト-分解し始めています。
プロジェクトはまだ始まったばかりですが、心配する理由はありません。 PlanningPokerの見積もりは徐々に正確になり、チームの速度は向上し、定期的なデモはリリースの目標を達成する気分と信頼を高めています。 元気いっぱいのリズムをクリア。
症状1：技術的なバックログが大きくなり始めた
しかし、徐々に、ますます多くのタスクが技術的なバックログに現れ始めます-開発者はリファクタリングのための機能をそこに置きます。 はい、プロジェクトコードが「ファウル」ではないことを知っています。開発者がコード内の曲線/複雑な瞬間を特定し、振り返ってそれらについて話し、バックグラウンドで処理するためにこのクラスのタスクを登録できるようにする必要があります。
時々、これは終わりの始まりの兆候です。 チームは、間違った方向に進んでいることに気付き、コードを複雑にして、目の前で崩れ始め、何度も何度も書き直そうとしました-次のタスクの分配でこれに時間を割り当てようとしました：
-私たちは議論しました...モジュールを作成し、ORMライブラリを使用しました-しかし、それは私たちには合わず、複雑すぎて、データベースに直接クエリを書きたいです（2か月かかりました）
-継承のオブジェクト階層を複雑にしました。悪魔は理解しません。 書き直す必要があります（新しいプロジェクト！、Give Kalash）。
症状2：不安定なスプリント
可能性のある終了の別の兆候-何らかの理由で以前のスプリントで書かれた機能は...安定しません:-)。 それはバグをこぼします、そして、彼らの修正はますます時間がかかります。 はい、ある時点で、バグストリームは停止しているように見えます-しかし、機能の最小限の変更で、それは更新された活力で開きます。 理論的には、両手を広げて要件の変更を受け入れる必要がありますが、ここでは咳が怖いです。
症状3：「ブレーキ」
すべてが時計仕掛けのようになりました。 しかし、ここで彼らはシステムにテストデータをロードしました...そしてそれはダウンしました。 すべてのプログラマーがコードがデータの量にほぼ「独立して」動作することを理解しているわけではないことがわかります。テーブルからすべてのレコードを選択してコードで処理したり、メモリで数百メガバイトを回したりすることはできません。
多くの場合、システムに予想されるデータ量を処理する方法を教えるには、数か月かかる可能性のある深刻な書き換えが必要になります（！）。 そして、テスト、テスト...
症状4：独立のマトリックス
大きなプロジェクトを経験した経験豊富なファイターだけが知っている恐ろしいことがまだあります。 プロジェクトがチームの頭に置かれている限り、心配する必要はありません。 機能を追加するのは簡単です。こことここでロジックを変更した場合、何が起こり、システムのどこに反映されるかを理解します。
しかし、システム/ウェブサイトが大きくなると...人々は迷子になり始めます。 人生の簡単な例：
PO：同僚、追加の割引アプリケーションアルゴリズムのサポートを追加する必要があります.... 見積もり。
開発者：これを行うには、ここでライブラリを修正し、そこで出力テンプレートを修正する必要があります。 おそらく（！）すべて。
だからここに。 機能の導入後に判明しました...いくつかの支払いシステムが流出しました。 さらに、顧客はすぐにそれについて学び、「肯定的に」反応しました。
そして、 依存関係を追跡するツールがあり、それらが「アダルト」開発プロセスで使用されていることを知っています。 それらがなければ、チーム内の「おそらく」という言葉がより頻繁に繰り返されます。
自動化されたテスト...はい、彼らはコードをテストします。 複雑なビジネス要件、アルゴリズム間の依存関係をどのようにテストしますか？ アナリストにはすでに他のツールが必要です。
複雑化は陰険な敵です
プロジェクトが大きくなればなるほど、開発者、ProductOwner、および顧客の両方にとって、制御不能で起動しやすくなるようです。
カシは大きくなっています。
最悪の事態は（秘密裏に）「戻りのないポイント」です。いわば、プロジェクトを管理された状態に戻すことは非常に困難であり、それを地獄に閉める方が安価です。 誰もが混乱し、すべてが非常にバグが多く、ひどく広がります。
誰が顔を打ちますか？
何十ものプロジェクトを立ち上げると、失敗の原因を自然に分析し始め、回顧の精神に従って結論を導き出します。 数年が経過し、制作プロセスのバランスのために才能が発達しました。これはおそらく音楽の耳と比較できます。
アジャイルを使用している会社の私見では、強力なテクニカルディレクターが必要であり、彼の脊髄は使用された方法論とツールのバランスを感じています。 開発プロセスに関する本を読むことはある程度助けになります-必要なのは本能です。
さらに、プロジェクトが複雑になればなるほど、知識、経験、意志が必要になり、「リターンのないポイント」を通過できなくなります。 Techdirは少しスリープ状態になり、いくつかのプロジェクトはノーリターンのポイントを通過します-もちろん、6か月または1年間の仕事の見た目を作成し、笑顔ですべてがうまく管理されていることを示し、その後抽象的な理由で突然終了することができます。
TechDirの主要なタスク
そのため、アジャイル開発ではテトリスでtechdirが絶えず勝つことがわかりました。上からどれだけ多くのプロジェクトがダウンしても、PRODUCTIONはバランスが取れており、複雑さはスケールを超えてはなりません。 常にO（1）と良い気分;-)：
-必要に応じてデザインパターンを適切に使用するため、アーキテクチャはシンプルなままです（XPのシンプルデザイン）。 techdirから教えられた開発者が脊髄の合併症を発見した場合、リファクタリングが始まります。 またはtechdirは、経験豊富なアーキテクトを複雑なプロジェクトに配置します。
-プロジェクトのコードが「悪くなる」ことはありません-技術専門家によって教えられた開発者は、嗅覚を開発し、技術的なバックログで悪いコードを一掃するタスクを設定しました。
-コードには大量のデータが用意されています-開発者は資格があり、作成内容を理解しています。 それでも、techdirはプロジェクトの準備チェックリストで必須の負荷テストを規定しました。
-ユニットと他のタイプの自動テストのいずれかがすぐに使用されるか、プロジェクトの複雑な部分に使用されます。 ここでは、さまざまな継続的統合を時々固定できます。
-プロジェクトは必然的にモジュールに適切に分割され、互いに可能な限り独立しています。したがって、1つのモジュールを変更しても、システムの他の部分にはほとんど影響しません。
-技術文書は、自動化ツール（phpdocなど）を使用して維持されるか、ビジネスプロセスが構成され、変更が文書部門に送られます。
-分析文書、図、データベーススキーマ、およびアナリストが行うすべてのことは、頭に置かれたモジュールに分割され、それらによって最新の状態にきちんと維持されます。 アナリストはコードを見ませんが、さらに何かを設計できるようにするために、システム/モジュール内のすべてのビジネスプロセスを明確に理解する必要があります。
-才能のある人々はチームに残り、 彼らは興味深く、やりがいのある仕事に従事するために与えられています。 チームには敬意を表する専門的な雰囲気があり、テディールがそれに続き、プロではない職業人が人々に接触しないようにします。
そのような人が見つからない場合-交換可能な従業員との複雑なメガ形式化されたプロセスを構築するために、一つのことが残っています。 おそらくもっと高価で長くなります。
まとめ
ProductOwnerが満足し、機能が時間通りに行われ、リリース計画に従って着実に動き続けるためには、「ソフトウェア製品」と呼ばれる生き物が最も予期せぬ瞬間に下水噴水を噴き出さないようにします。前述のチェックリストの多様性に従って、脊髄によるプロセスとツールのバランスを感知します。
そうしないと、アジャイルホースアジャイルをサドルできなくなります。
アジャイルTechdirロール-テトリスゲーム
All Articles