序文として
すべては2014年2月にAgileDays2014カンファレンスへの招待で始まりました。 同じ日の夕方、私は会議のウェブサイトに座って自分に興味のあるトピックを強調し、レポートへの訪問を計画しました。 5〜10分後、私はすでにAlternativa PlatformのAnton VolkovによるAgileDays 2013「Freedom and Responsibility」でのパフォーマンスの記録を見ました。
レポートで強調されている主な問題は、多くの従業員が仕事に時間を費やすだけで、責任感のある従業員はほとんどいないということです。 さらに、チームの責任はありませんが、言い訳、多くの言い訳があります。 ここには、効率、品質、従業員の常時監視が必要な問題があります。 すべてがすべての人に合っており、変化する欲求はありません。
責任感を育むために必要なもの：
- 責任の自発的な受け入れ。 たとえば、人自身がタスクを完了するための締め切りを呼び出すとき、彼は責任を受け入れます。 そして、用語が上から引き下げられた場合、責任を受け入れることの問題はありません、それは用語を下げた人にあります。
- 選択の自由-人々はどのような仕事をするかを決定し、問題を解決するための戦略を選択し、誰と働くか（チームの構成を決定する）を持っています。
- 行われた決定の結果（肯定的および否定的）、行動および非行動。 たとえば、私は時間通りに十分に実行された機能を渡し、同僚の認識を受け取り、おそらく追加の金銭的報酬を受け取りました。 または、食料品店の環境でバグを認め、同僚からscられたり非難されたりします。
結果は、各従業員（取締役を含む）が個別の公的評価/カルマを持ち、契約がタイムリーかつ高品質な方法で実行されたときに発生し（詳細は以下）、契約に記載されたリスクが発生したときに合併するという興味深い方法論でした。
契約は、請負業者と顧客の間の契約です。 完了基準とリスクで構成されています。 カルマポイントの価値と、個々のリスクの価値を持ちます。
優先順位の順に、契約のリストが1つあります。 チームが何かを働かせると、チーム自体がその構成（選択の自由が誰と働くかを行使する）と実装期間を決定します。 チームの構成は、契約の目標を達成するために必要な能力に応じて、契約ごとに動的に変化します。
したがって、従業員にはほぼ完全な自由があります-割り当てられたタスクを解決する方法の選択、働く相手との選択（チーム構成）、実行するタスクなど。
カルマへ
当時、私が働いている会社は柔軟な方法論を積極的に導入していました。 アントンがスピーチの最初の部分で話したほとんどすべてがわずかな違いを伴って繰り返されたことは面白いです。 ScrumTrekチームでさえ私たちを訪問しました（Askhat、こんにちは！会いたいですか？）。 私が気に入ったアイデアを「売る」という私の試みは、成功したとは言えません。
半年が過ぎても、アジャイルの魔法は私たちに降り注ぐことはありませんでした。 品質は向上せず、速度は以前とほぼ同じままで、継続的な監視が必要でした。 しかし、ITにKPIを導入するという話がありました。 ここで、カルマが実際にITで使用できる唯一の健全なKPIであることがわかりました。 この考えはリーダーシップによって表明されましたが、私は聞いていませんでした。 最終的に、ITでのKPIのグローバルトピックは静まり返りましたが、少なくとも私の影響の範囲内でカルマを使用してトピックを継続することにしました。 規模に興味がある人は、開発プロセス、開発者、プロジェクトマネージャー、アナリストの17人です。
カルマの紹介
開発チーム全体に対して方法論のプレゼンテーションが行われました。 私は、グループの約半分が当初この考えに懐疑的だったとすぐに言わなければなりません。 しばらくして、彼らのうちの何人かはそれにもかかわらず、何が楽しいかを理解し、サポーターに加わりました。 他は実装段階ですでに関与していました（そして、彼らは潜水艦からどこに行くべきですか？）。 アイデアを受け入れた人々はすぐにイニシアチブグループを形成し、仕事は沸騰し始めました。 どこでも、WEという単語が後で現れる場所では、KDDの実装のためのイニシアチブグループとして理解されるべきです。
方法論の詳細に飛び込み始めたとき、すぐに質問が現れ始めました：
- 誰も質問をせず、これにあまり時間を費やさないように、契約のコストを決定する方法は？
- ワークフローを方法論に適合させる方法は？
- 複数のプロジェクト間でタスクに優先順位を付けるための原則は何ですか？
適応された方法論の最終バージョンに注目します。
カルマ
個々の個人の評価/評判。
蓄積は、契約の質の高い実装を通じて発生します（以下を参照）。
契約で指定されたリスクがある場合、および1か月間の負荷が低い場合に削減が行われます。
計算を簡素化するために、1カルマを1人1日のコストと同一視しました。 したがって、各従業員には、就業日から休暇および病気休暇を引いた数に等しい計画があります。 同時に、低負荷は計画の80％未満と見なすことができます。
Karmaには2つのインジケーターがあります。
- 月次指標-計画を超過した場合、給与のボーナス部分の増加係数を計算するために使用できます。
- 累積インジケータ-人が会社にとってどれほど一般的に役立つかを示します。 ここでは、計画と事実の間の月間デルタが蓄積されます。 同時に、誰もそれを処理しないようにします。 休息した開発者は、疲れた開発者よりもはるかに効果的です。
合意
顧客と請負業者の間の問題解決に関する合意。 完了基準とリスクで構成されています。 カルマポイントの価値と、個々のリスクの価値を持ちます。
顧客は、適切な能力を持つ従業員であれば誰でもかまいません。
エグゼキュータは、個々の従業員でもチームでもかまいません。 チームが契約を処理する場合、契約のコストは、問題の解決への参加（％）に比例してすべてのチームメンバーに分配されます。
チームは固定されていません。 人々は、1つまたは別の合意を達成するために誰と協力するかを独自に決定します。
請負業者自身がコストと実装条件について顧客と評価し、同意します。
「AlternativaPlatformで生まれた契約の価格はどうですか？」という質問をめぐって非常に長い間戦ってきました。 あなたが好きなことを言って、あなたが問題を分析し、それを実装する方法を見つけた場合にのみ、健全な価格が表示され、これには膨大な時間がかかります。 私は個人的にそのような負荷の準備ができていませんでした、この問題は方法論のすべての利点を無効にしました。 しばらくして、洞察力が低下しました...しかし、商業的なアプローチを適用した場合はどうでしょう。 請負業者自身が作業コストと完了期限を発表します。 契約を非常に高いレベルで評価するだけで十分です。価格や期限が高すぎると思われる場合は、単に見積もりを求めます。 これで停止しました。
基本として、かんばんは次のステータスとステータス遷移で使用されます。
分析または実装のためにタスクをキューに移動する前に、ビジネスからのほとんどすべてのリクエストは、「何のために何を求めますか ？」という普遍的な質問でテストされます。 問題は、通常、ビジネスはターンキーソリューションでIT部門にやって来て、目標を指定することはほとんどないということです。 ビジネスのニーズを完全に満たすためには、まさに目標が必要です。 このステップを明示的な分析と呼びます。ステップの結果は、定式化された目標と「それを受け入れるか拒否するか」という決定です。
顧客が来て、足を撃つように頼みます。
もちろん、あなたはすぐにこれを行うことができます、私たちは素晴らしい仕事をして、私たちが尋ねられたとおりにしたことをしたようです。 「ショット足が痛い、何かをする」という問題を抱えていたとしても、顧客は再び来ます。 軟膏で塗りつけ、バンドエイドを作ります。
そして、「何のために何を求めますか？」という質問をすることができます。そして、人の足がかゆくなります。
私たち：「足をかきましょう」
顧客：「それも可能ですか？」
（この話の作者が誰なのかはわかりませんが、ScrumTrekのAskhatから聞きました。ここに私の解釈の簡単な言い直しがあります）
図からわかるように、分析用と実装用に別々に、1つのタスクに対して最大2つの合意を作成できます。 分解のために作られ、評価の精度を向上させます。
さらに、問題の明確な理解が得られるように、専用の分析手順が必要です。 これを行うには：
- 完了基準が形成されている-顧客が承認した肯定的なユースケース。
- リスクが評価される-否定的なシナリオ。
分析をバイパスして実装キューに直接移行することは、実行するだけで分析する必要がない小さなタスクの場合に可能です。
実装のタスクをラインから外すために、従業員自身が技術評価を実施し、タスクを完了することができる時間と構成を決定し、カルマで希望の価格を表明します。 結果は、署名された作業実行契約です。
品質管理に関して非常に興味深いことがわかりました。 当初、この段階はAlternativaPlatformと同じように計画されていました。 すべてのタスクは、タスク（データベース構造の設計の品質、コードの品質、UI / UXなど）に応じて、必要な品質センターにドラッグする必要があります。 タスクが品質センターを通過しない場合、チームはカルマでマイナスを受け取ります。 悪いことは何もないように。 そのため、このトピックについて激しい議論がありましたが、開発品質基準を策定して全員に合うようにすることは事実上不可能であり、特にコード品質に関して多くの趣味があります。 さらに、修正する必要があるものの、コードが罰金を科されるほど悪くないように見える場合があります。
その結果、必須の品質センターはコンピテンスセンター（以下、中央委員会）に再割り当てされ、すべての従業員がレビューを申請できるようになりました。 したがって、中央委員会への控訴はオプションとなった。 さらに、中央委員会への訴えを刺激するために、以下を提案しました：
- 完了した作業に関するフィードバックを簡単に取得したい場合は、実行者（個人またはチーム）がタスクのコストの10％を追加で受け取ります。 私はちょうどレビューにタスクを与えました-あなたはすでにボーナスを受け取っています。 懐疑論者はすぐにつぶやき、これがすべて必要ではないという事実についてつぶやいた。 それどころか、彼らは中央委員会にレビューのためのタスクを最初に提出した。
- 中央委員会に推奨事項がない場合（作業が完全に行われた場合）、または推奨事項に従って変更が行われた場合、請負業者はタスクのコストのさらに10％を受け取ります。
実装から何が得られましたか？
記事の公開時点で、私たちは約1か月間KDDに取り組んでいます。 私たちはプラスでのみ働き、統計を蓄積しますが、 リスクに対する短所はまだ発表されていません。
- おそらくこれは自己欺ceptionですが、デジタル化されたパフォーマンスインジケータの存在と中央委員会のレビューのために、作業がより速く、より良く行われ始めたように思えます。
- アクティビティは完全に透過的です。今では、部下が何をするかについて、マイクロ管理に頼ることなく、はるかにうまくガイドされています。
- 誰と協力するかを独立して選択することにより、心理的環境が改善されました。
- 人員衛生の効果-誰も働きたくない不必要な人々が特定されます。
- 誰かを蹴る必要はありません。人々自身が来て同意を求めます。
- スタンドアップは非常に高速かつ効率的になりました。 以前は、7人のチームで30から40分かかることがありましたが、今では15人で17人が収まります。
中間結果は、アントン・ヴォルコフの報告で表明されたものと非常に強く一致していることに注意したい。 私にとって、これは方法論が実際に機能していることの指標です。