SCRUMを実装することにした理由
それで、私たちの隣に別のプロジェクトがあります。 その中の人々は、2、3時間、絶えず議論し、叫び、話し合います。 彼らは私たちの側にいるように表明されたリーダーを持っていません。 そして、すべてがうまくいきますが、ここに私たちの修道院のスクラムが来ました。これは本質的にこの部門からチームを作ることを目的としており、私たちの部門は会社のように、どこにでも実装されているように思われました。 最初は喜んでいたが、今では2つのチームに1人のテスターがいる。 また、スクラム開発では、単体テストを作成する必要があります。 「クール」と私は思った、今では彼らは土曜日に私に手紙を書かないだろう：「修理-何かが機能していない」 そしてすべてが透かし彫りになります。
そして、トレーニングは合格しました
印象は2つあります。隣人が1時間か2時間悲鳴を上げたり話し合ったりするだけでなく、今では「私たちの土地」に来るということに気付きました。 今、私たち一人一人に個性があり、それぞれが彼の重い意見を表しています。 そして、チームはすべてに責任を持つようになったため、誰も何にも責任を負いません。 トレーニングには課題があり、レゴのコンストラクターがいて、顧客がいて、2つのチームがありました。 時間の2時間。 タスクは、都市を構築することです。 私たちはまず、顧客にとって重要なことを強調することから始めました。 それなしでは、彼のプロジェクトは存在しません。 タスクの複雑さを打ち破ります。 始めました。 そして、混乱はすべての栄光になりました。 評価されたタスクで最初に紙を手にした人は誰でもそれを行い、私があなたを助けることができるかどうか尋ねられると、彼は彼を森の中に遠くに送ります。 このイテレーションでは、最も機敏なコンストラクターが組み立てられ、残りは単に詳細を突っ込み、重要なことをしているふりをしました。 次の繰り返しで、二度と立ち寄らないように、誰もが彼自身が引き出せなかったタスクをつかみました。 圧倒される。 まあ、すべてが圧倒されるわけではありませんが、顧客はセットアップされたものの約50〜70％を使いました。 複雑さの評価と、コンストラクターでの時間の選択自体が大幅に異なることに注意してください。 1時間以上評価された...他に注目すべきことは、人々はスプリントが失敗する可能性があることを知ったとき、喜んだ。 そして、はい、私たちは都市を建設しましたが、店はありません。 店は失敗し、顧客のお金はなくなった。 今、住民は虫を食べるようになります。
まとめ
これまで自分が耐えてきたものは、今ではラリー中にテストを書く時間を取ることができるので、スプリントの緊急モードで動作します。 私は間違いなく好きです。 結局、私がいつもそのように働く前に、緊急モードで、そして今、私はそれのためのスプリントとタスクを持っています。 そして、「昨日それが必要だった」というタスクは私の人生から消えることを望み、プロジェクト全体がテストで覆われます。 別のプラスとして、私はより多くの人々とコミュニケーションを取ります。 ラリーは数時間の紛争に発展する傾向があるため、これはマイナスですが、その終わりには、概して、**終わりまでに、ただ終わるだけです。 プロジェクトには創造性があります。つまり、一人が決めるときです-これは一つのことですが、議論の中で生まれるものは通常より良く、問題の思慮が大きくなります。 このアプローチのマイナス点は、集会が何時間も論争に発展する傾向があり、作業が止まることです。
一般的に、私たちは最善を願っています。