私は物語を共有したいと同時に、habrasocietyの他のメンバーの意見を聞きたいです。 これは、ロシアの単一のIT企業におけるアジャイル（スクラム）開発方法論の積極的な実装が、同社の最高の開発者の脱出の始まりであったことについての短編小説です。 通常、アジャイルに関する記事では、アジャイルがどのようなクールで有用な方法であるかを説明します。一般的に、これはこの方向で発明された最高のものです。 おそらく、この記事はアジャイルを反対側から見るのに役立つでしょう。なぜなら、結局のところ、コインには両面があるからです。
一般に、2010年に1つのロシアの会社が設立され（会社を特定する意味がないため）、IT開発の分野で働きました（銀行商品のソフトウェア）。
いつものように、最初はすべてがほぼスタートアップモードで機能していましたが、それにもかかわらず、会社は自信を持って立ち上がってすぐに支払いをしました。 徐々に、会社の従業員、マネージャー、フロントおよびウェブ開発者の数が増加し、現在では50人を超え、最初の駐在員事務所が海外に開設されました。
開発者の数が直接増加するにつれて、プロジェクトは投資を引き付け、新しい管理者を雇用しました。 テクニカルディレクター、人事部門、多くの管理スタッフ、あらゆるストライプのマネージャーの無数の軍隊が登場しました。
開発者は仕事をし、プロジェクトは細部までデバッグされました。 すべてが良さそうで、劇的な変化を示すものは何もありませんでした。 タスクが設定され、実行されました。5年後、開発者の構成はそれほど変わりませんでした。会社の設立から5年後、原点に立った人はほとんどいません。 そして、これは、私にとっては、人々が会社で快適に働いていたことの指標です。
ある時点で、会社の経営陣は、ロシア向けの新しい形式の開発手法を試すことを決定しました。 アジャイル（スクラム）が選択され、スクラムマスターが会社に雇われ、すべての開発がTargetProcessに移されました。 管理の観点から、これは開発の速度と品質を改善し、開発者が何に時間を費やしているかを理解するために行われました。 ところで、開発者について。 これらは本当に小さな技術のスタックを所有していて、プロジェクトよりもプロジェクトの本質についてより多くを知っている彼らのプロジェクトを本当に心配している本当に素晴らしい人々です。
もちろん、時代は変化していることを私は完全に理解しており、おそらく以前は、プロジェクトの開発は少し創造的だったでしょう。 現在、これは合理化されたビジネスプロセスであり、その目的はお金を稼ぐことです。 しかし、このプロセスは神格化され、創造性への渇望とプロジェクト開発への関心を抑えることができます。
最初は、新しいスクラムの導入後、誰もがその論理と外部のシンプルさに喜びました。 すべてが明確であり、開発プロセスをスプリントに分割し、ユーザーストーリーマネージャー（タスクの処理）を取得し、特定のスプリントにそれらを含めます。
しかし、その後、開発部門は、ドライバーやハンマーなどのツールにお金をもたらす会社の中核から離れたという事実に成長しました。 マネージャーはタスクを思いつき、IT部門に任せて実装を待ち、同時に開発とテストに費やした時間を数えました。 開発者とテスターは、TargetProcessでタスクを完了する時間を書き留めるように指示されました。 経営陣は、実装中にタスクを変換し始めました。もちろんコストもかかりました。 ここでは、いつものように、すぐに経営陣と開発者の間で誤解がありました。 Symfony 2.6からSymfony 3.0にプロジェクトを移行するには、あるバージョンから別のバージョンへの単なるアップグレードであるため、開発者にとってほぼ1週間かかります。 おそらく、ビジネスの観点から見ると、開発部門は、開発コストを削減し、スピードを上げるために、3倍、または5倍速く働くことができれば、常に怠laな従業員のように見えます。
もちろん、彼らの観点からは、すべてが論理的です。彼らはそれをより速くしました-つまり、より少ない費用を負担し、契約をより早く完了し、お金とボーナスを受け取りました。 しかし、開発者の観点から見ると、わずかに異なる状況が現れました。開発者は仕事を奪われず、それぞれ3つまたは5つのプロジェクトに同時に取り組みました。管理者からのプレッシャーと労働時間ごとの報告があったためです。 「なぜこれを開発したりテストしたりするのに丸一日費やしたのか」という精神から疑問が生じ始めました。
一ヶ月のinりの後、情熱は少し落ち着き、開発部門は徐々に「ドライバー」の運命に慣れました。
ソフトウェア開発は、創造性に密接に関連する技術であり、まったく同じタスクをうまく行うことも、創造的に非常によく行うこともできます。
ここで、開発者に対処する方法に関するbobukのパフォーマンスを思い出します。 回答：子供と同様。 もちろん、誰もがこのように続けて扱われる必要があるとは思いませんが、会社のゲームのルールの急激な変更を誰もが好むわけではないことを心に留めておく必要があります。
このような方法論の導入の結果、開発者の熱意は静まりました。 マネージャーからのタスク（ユーザーストーリー）のみが実行され始め、開発者には目立たないが有益なアクティビティの時間はありませんでした。 プロダクションのどこかでバグが見つかった場合、開発者はそれを修復できませんでした。 そこで時間を帳消しにするのにタスクが必要です。 そして、開発者自身が自分のタスクであふれていました。 タスクの優先順位付けが開始されました。 マネージャーは、自分たちのuserStoryに最高の優先順位を割り当てようとして、お互いに対立し始めました。 彼らには顧客に対する義務があり、誰も忙しい開発者を気にしません。
その結果、このシステム全体が小さな地域崩壊につながり始めました。 開発者はすべての熱意を失い、正式に開発に関係し始めました。 タスクがあります-私たちはしますが、タスクはありません-私たちはしません。 さらに、1時間ごとの時間レポートでは、誰かがあなたの後ろに立って、ボタンを押すのを見ているという後味が残りました。
当然、マネジメントの観点からは、状況はよりバラ色で、プロジェクトの開発に費やされた時間に関する完全なレポートと、ほぼリアルタイムで誰が何をするかについての理解を受け取りました。
しかし、開発者も人であり、それに耐えられなくなりました。 わずか1か月で、3人の主要なコア開発者が退職しました。 現時点では、どこにも手に入らない代替品。 彼らは創業の瞬間から会社で働いており、実際に会社を今のようにした。 他の開発者の負荷は指数関数的に増加し始めました。 開発部門はカードの家のようによろめき、会社で5年間働いていた開発者が辞め始めました。 会社の一部であると感じなくなり、「ドライバー」に変わりました。
まとめ
開発プロセスをコンベヤーに変えるスクラム方法論は、主にチームの人間関係を考慮せず、会社の一部のことは従業員の熱意のためにしかできないという事実を考慮せず、UserStoryにラップすることはできません。
このようなストリーミング開発方法論への積極的な移行は、社内の関係の「形式化」につながります。 鋭い実装の結果、経営陣は会社で何が起こっているかをよりよく把握できるようになりましたが、会社には主要な開発者はいません。
これらの従業員は、順応できなかった、または慢に振る舞えなかったと自分自身で責めるべきだと言うのは、私にとってはこれは間違いです。 おそらく、アジャイル実装プロセス自体は正しく構成されていなかったかもしれませんが、どういうわけかこのプロセスには黒面がありました。