私のチームは、スクラムからリーン/かんばんに移行し、ますます正式なプロセスが少なくなる軽量な方法論を徐々に採用しています。ある時点で、Cowboy Coding に戻ります。確かに、私たちはすでに境界線にいるのではないかと心配しています。
非常に軽量なリーンおよびアジャイル プロセスとアナーキーの境界線はどこにあるのでしょうか? 一線を越えたことをどうやって知ることができるでしょうか。どうすれば一線を越えないようにできるでしょうか。
この質問は、「ムダを排除しようとするリーンの意欲の中で、安全に排除できないプロセスはどれか」と言い換えることもできます。
コードに関する何かが、グループ内の 1 人だけが知っている、または管理できる場合、あなたは大きな素敵な赤く光る「サルーン」のサインの下にいて、基本的にドアを押していることになります。
おそらく、カウボーイコーディングの影響について心配しているでしょう：
これらの悪影響を回避するための計画/メカニズム/プロセスがある限り、問題はありません。右？
その行の一部として、いつタスク/ストーリー/作業単位が実行されるかという問題が思い浮かびます。テストが必要で、カウボーイになりたい不正な開発者の状況を防ぐのに役立つ可能性のある何かを見た場合。同様に、コードはどのようにして本番環境に移行しますか？チームの誰かが気まぐれでコードをプッシュできる場合、それは私の心への警告サインになります。
私が注意したい他のいくつかの警告サインは次のとおりです。
ある種のコードレビューを続けていれば、こちら側では間違いないでしょう。他のプログラマーが何をしているのか、どのようにやっているのか誰も知らないのなら、あなたはこの境界線を越えたかもしれません。
見た場合にカウボーイの領域にいることを示す警告サインの決定的なリストは、おそらくないでしょう。個人的には、人々がテストされていないコードをリリースしたり、明確に理解されていない機能を開発したり、とにかく仕事を急いだり、警告サインを無視したりすると心配になります.
自分の判断で使ったほうがいいです。願わくば、あなたが質問をしているのですから、あなたが保安官にふさわしい人物であることを願っています。
カウボーイ コーディングは不正なコーディングです。不正行為を許す唯一のことは、当局による監視がないことです。
アジャイルの「自己組織化」は、開発チームが日和見的に「自己決定」を意味するように再解釈するため、この用語をほとんど無意味にするほど乱用されることがよくあります。
管理に対する無駄のない組織的アプローチは、アジャイル チームであっても、私たちが慣れ親しんでいるものとは大きく異なる可能性があります。そして、すべての違いを生み出すのは、この組織と方向性、およびその組織メカニズムの問題です。
ソフトウェアにおけるリーン製品開発の採用はまだかなり歴史が浅く、残念なことにかんばんによる気晴らしにかなり悩まされています。しかし、これは当然のことです。メソッドの最も外部化可能な側面は、通常、最初に認識され採用されます。これらは通常、最も機械的な側面です。かんばんはリーンの目に余るほど機械的な部分です。しかし、それはほんの一部です。
リーンは、アジャイルよりもはるかに組織的な変化です。組織内の取締役の役割を変えなければ、リーンの最も物質的で機械的な側面のみにアクセスすることになり、おそらく最も単純な方法でアクセスすることになります。
組織内の誰もが不正にならないようにするには、期待を満たすように指示する必要があります。ただし、無駄のない組織におけるディレクターの役割は、いじめっ子だけではありません。無駄のない組織 (開発チームなど) のディレクターも熟練労働者であり、責任を受け入れた期待に応えるために必要なスキルを他の人に教えることができます。
どのような特定のプロセス (コード レビュー、ペアリング、インセンティブなど) を実施するにしても、それらを検討している特定の瞬間に組織に固有の非常に多くの要因に依存します。取り組みのディレクターは、チーム全体の集合的な頭脳の力を結集して、探索、実験、学習の良い解決策や手段を見つけ、最良の決定を下す方法を理解する必要があります。コレクティブはリーンな方法で若いです）。
たとえばかんばんのような無駄のない知的唯物論によって、あなたの組織が弱い取締役の問題から完全に気を散らされない限り。人々が不正を行っている場合、方法論の問題ではなく、組織の問題があります。組織に問題がある場合は、必然的に取締役の問題や、権限の非生産的な使用の問題があります。
(私は罪を犯した)
「ムダをなくそうとするリーンの意欲の中で、安全に排除できないプロセスは何ですか」?
これは、正確に答えるのが難しい非常に一般的な質問です。
価値を生み出さない管理プロセスを捨てる一方で、eXtreme Programming に見られるようなより技術的なプラクティスを含める必要があります。私が話したほとんどのアジャイル コーチは、アジャイルの導入に取り組んでいるとき、テスト駆動開発、ペア プログラミング、および継続的インテグレーションが当然のことであると考えています。これらのテクニックを使って「カウボーイ プログラミング」を回避するのは非常に困難です。コードが手に負えなくなるのではないかと心配している場合は、コード レビューも行います。
保安官を雇って (または代理して)、コードを囲い込み、コードがコミットされるだけでなく、集団全体に見られるようにします。
リーンとアジャイルはどちらも、価値の提供という非常に特殊な状況で無駄を最小限に抑えることを伴います。
効率的に価値を生み出すのに役立つプロセスの使用をやめると、価値が少なくなるか、価値を生み出す速度が遅くなります。
リーンとアジャイルの両方の手法には、価値の生成においてどの程度進んでいるかを測定することが含まれるため、いつ一線を越えたかを判断し、有用なプラクティスを排除できる必要があります。
ベロシティやサイクル タイムを使用して価値の提供を測定していない場合は、すでに一線を越えています。
ここで、スクラムマスター/リーン/アジャイル コーチの価値が生まれます。チームでその役割を果たしている人は誰でも、チームの自己規律が失われていることを検出し、チームがお互いに約束したことをチームに思い出させることができる必要があります。コードの品質。
他にできることは、コンテナを調整することです。カンバン ボードにコード レビューを追加し、それが確実に完了するように制限を設けます。さらに良いのは、すべてのコードをペアで数週間書くことを要求して、良い習慣が強化され、誰もコードのセクションの所有権を主張できないようにすることです。
最後に、スクラムの正式なプロセスから離れるのは少し時期尚早だったかもしれないと考えてください。スクラムのルールは、まったく異なる考え方と作業方法を教えるためのものです。リーンとアジャイルの価値がまだチームに根付いていない場合、古い習慣に逆戻りするのは非常に簡単です。これは、チームの準備が整うまで、スクラムのルールを厳密に実施することが役立つ場所です。
かんばんはツールであることを忘れないでください。その使用法にリーンとアジャイルの原則を一貫して適用していない場合、十分なメリットを得ることはできません。
カウボーイのコーディングの何が問題になっていますか? 品質が低く、コードの配信に時間がかかり、エンド ユーザー (または誰がお金を払っているか) の期待に応えられないことがわかり始めたら、その時です (私は PM であり、これを言っています)。優れた/堅実なプログラミング チームを持っている場合、正式なプロセスは必要ありません。通常は内部化されています。優れたプログラマーは、優れた形式/プロセスに自然に従います。多くの場合、優れた/優れたパフォーマーに悪影響を及ぼします。優れたプロジェクト マネージャーは、特定の状況に合わせてプロセスのバランスを取る必要があります...リード/フォロー/邪魔にならないタイプのアプローチ
おそらく顧客を巻き込むので、ビジネスが実際に望んでいないBAU予算の下で理論的なシステムを作成しないでください? 上司ともっと話してください。