アジャイルが機能することを理解する方法

アスハット・ウラズバエフ（ScrumTrek）

私たちが内部からどのように見えるか、チームをトレーニングするときに直面する問題について話し始める前に、問題はアジャイルで働く人々、アジャイルチームがアジャイルチームであるとはどういう意味ですか？ これをどう定義しますか？









私の名前はAskhat Urazbayです、私はScrumTrekから来ました。 私たちは、企業や組織が非常に柔軟な方法論を実装するのを支援することにコミットしています。 私たちが直面している問題。







組織内には複数のチームが存在する場合があります。 一部のチームは、アジャイルに取り組んでいると考えています。 一部の幹部は、どのチームが実際にアジャイルに取り組んでいるのか、そしてこれが物理的に何を意味するのかという疑問を持っています。 つまり アジャイルに取り組んでいるかどうかをどのように判断できますか？







たとえば、スプリント、速度など、あらゆる種類の形式的なものがあります。 これらの用語が本当に好きな会社にそのような人々がいるかどうかは知りません。急いで言います。 アジャイルかどうか？」



そして、一般的に、アジャイルとは何ですか？ 予測可能な結果、変化する要件への適応性、変更への迅速な対応、短い反復。 これらはアイデアです。 どんなプラクティスがありますか？ たとえば、スライドにはスプリント、ベロシティ、ストーリーポイントがあります。 これをすべて保証するために使用される他のいくつかのもの。



時には、いくつかのチームがある組織や会社に来ます-いくつかはアジャイルで働き、いくつかはそうではありません。 スプリント、ベロシティ、または他のチームがどのようなプラクティスを使用しているかに基づいて、どのチームがよりクールであるかを判断する方法は？ あなたがそれがどのように機能するかを見ているという事実に基づいて、どのチームがより効果的であるかを言うのは非常に難しいです。



どのように頻繁に見えますか？ あなたはオフィスに来て、2つのチームがあります-1つにはすべてがあり、可能なものはすべて、テクノロジーから方法、実践、アプローチに至るまでまっすぐ詰め込まれています。 しかし、それらは分裂せず、生産されていません。結果はありません。 または、生産において、ある種のがらくたとは意見が異なります。 悪い、遅い。 これらは効果的に機能しないことがわかります。 そして、スプリントもベロシティもこれらのファッショナブルな用語も何も使用していないが、定性的な結果、顧客、エンドユーザーなどを共有している別のチーム 彼らに満足しています。







使用するアプローチと結果の間に100％の相関関係はありません。 そして、これはとても悲しい事実です。 これらのtsatskamやバッジ、または何らかの理由で人々が自分自身に固執するだけでどれだけ効果的かを追跡するのはかなり難しいことがわかります。



そのような場合がありました。 私たちがやり取りした会社の1つで、彼らは男たちがゲーミフィケーションを使用してバッジを配るのはクールだと判断しました。 速度を使用しますか？ あなたにはバッジがあります。 これは何につながりますか？ すべてのバッジにはイチジクがあり、すべてバッジです。しかしそれは意味がありません。 純粋なカーゴカルトになります。



アジャイルとは別の一般的な定義はアジャイルマニフェストです：







これらは変化に対する素早い反応です。 アジャイル定義として使用できますか？



マイナスがあります。 実際のところ、もしあなたのチームが「それがどのように機能するか」という方法に従って機能する場合、つまり ドキュメントを作成せず、プロセスやツールも何も使用せず、ドキュメントや顧客との契約関係もありません。今のところ計画を作成していません。これからアジャイルであることは可能ですか？ この定義から判断すると、原則としてはい。 このこと-アジャイルマニフェスト-は何かのためではなく、何かに対するものであることがわかります。 彼は滝に反対です。 要件が書かれている場合、設計が長いなど また、明確な定義として使用することはできません。



これがすべて捨てられた場合、これらすべてのニュアンスを理解しようとしましたが、アジャイルとは正確には何ですか？ 私はそれについて話をしようとします。







アジャイルプラクティスのためのアジャイルプラクティスは絶対に意味のないものであることがわかります。 はい、彼らは何かのために必要ですが、あなたは彼らが実行する理由、タスクを理解する必要があります。 定義としてのアジャイルマニフェストも機能しないか、すべての場合に機能しません。 有効性の定義は何ですか？



問題は次のとおりです。どのチームをクールと見なすことができますか？ 効果的ではなく、特にクールという言葉を使用します。 どのチームがあなたにとって素晴らしいですか？ どの略奪品が稼ぎますか？ しかし、それは家であり、あなたの会社の中にあり、ビジネスプロセスを自動化します。どんな生地がありますか？ スタートアップの場合はサルベージしますが、スタートアップでない場合は救済しますか？ 品質、期限、結果、配布、要するに。 満足している顧客も良い定義です。



私は自分のものを定式化しようとしました。なぜならこれらはすべて状況に依存しているからです。 私は、多かれ少なかれどんな状況にも適合する定義を考え出そうとしました。 クールなチームとは何ですか？







私の観点から、クールなチームは、遭遇する問題に対処する能力によって決定されます。 つまり たとえば、あなたがそのようなチームのリーダーである場合、彼らはあなたに何かを解決している間、1時間ごと、毎日、問題を解決するためにあなたに走ります、そしてこれは非常にクールなチームではありません。



別のクールなチームが、解決できる問題の規模を決定します。 そして、絶えず変化する条件に迅速に対応する能力。 何かが変化し、チームは順応し、前進します。 これは、私の観点からすると効率です。



顧客に満足してもらう必要がある場合...顧客は不満です-これはチームが解決できる問題です。 「チームが配布する」と言うと、これはチームが解決しなければならない問題の1つにすぎません。 彼女は、絶えず変化する状況にもかかわらず、これらの種類の問題に迅速に適応し、効果的に対処できる必要があります。



例。 非常に典型的な問題。







すべて完了しました！ 他に何が残っていますか？ バグを修正し、展開します。これがあなたに当てはまるかどうかはわかりませんが、これは非常に一般的な問題です。



この問題に対処する方法は？ アジャイルに戻ります。 つまり、アジャイルや他の製品で作業していても、作業して、作業して、作業してから終了しても、まだすべてを完了しているわけではありません。 アジャイルはこれをどのように処理しますか？ アジャイルに存在するものの1つは、Doneの定義と呼ばれます。 これは準備の基準であり、社内の特定の合意、チーム、つまりタスクが最後まで完了することを意味します。 完了の定義例：







チームがこれを確実に実行できるように特別に訓練されたスピードメーターの人がいます。 このことはどのように行われますか？ あなたはチームとプロジェクトマネージャーになり、座って一緒にそれをし、書きます。 そして、これが行われていることを確認してください。



そのような契約の存在は、あなたが何かをしていない人のところに来てこう言う機会があるので、すでにあなたを大いに助けます。 同意しました。」 ユラは言う：「はい、そうしよう。」 一般的に、良心に圧力をかける機会があります。



彼らはこれらのことをそれほど多くない数で書き込もうとしています。 問題が何であるか。 たとえば、「コードはコミットされます。」 書く必要はなく、コミットされることは明らかです。 つまり 重要なことが書かれています。







そのようなものが沈んで通過するときに観察する別の興味深いものがあります。 しばらくすると、これらのものは死に始めます。 アジャイルを実装する人の観点から見ると、次のようになります。「みんな、クールなもの、Defined of Doneを思いつきました。 彼女はカッコイイと言ったのに、なぜあなたは定義の完成をやめたのですか？」 それらのすべて：「はい、どういうわけか私はもう何かを必要としません。」 確かに、このことは徐々に消滅し始めています。



サイクルは無意識の無能から始まります-あなたには問題があることを知りません。 それからあなたは意識的な無能を持っています-あなたは問題があることを知っています。 次に、あなたはそれを解決します-意識的な能力。 あなたはそれを解決する方法を知っており、アプローチがあり、それを燃やし、それについて考え、あなたがそれに対してとてつもない量のエネルギーを費やしています。 これに焦点を当てます。 しばらくして、学習しました。 そして、このことは無意識の能力になります。



どのチームが効果的であるかに戻る。 誰が何に問題を抱えているかは明らかであり、注意の焦点が向けられました。 「コードをリリースすることはできません。リリースしますが、顧客は何にも満足していません。」 この注意の焦点はあなたにとって重要です。 そして、これは現在、意図的な無能の状態で起こっています-どのように私たちは知らないようです。



学んだ後はどうなりますか？ たとえば、共有することを学びます。 絶えず変化する要件にもかかわらず、品質の結果を予定通りに生産に提供できます。 多くの場合、これを行う方法を学ぶために非常に多くのことを使用していることがわかります-ストーリーポイントでそれらを評価した、ある種のストーリーマッピングを使用した、いくつかの異なるアプローチがあるなど 建設中の家の森のようなものです。 あなたはそれらを入れ、それらを置き、それらを考え、あなたはこれを病気にした（アジャイルマネージャーは平均3年間病気になっている）。 あなたが学んだとき、すでに他のものへの注意が切り替わります。 学習したらすぐに、これらすべてを削除する必要があります。 バラストで保持する必要はありません。 人々にリゾートを作ってもらいましょう。 さあ、やりなさい！」 彼らが信頼し、顧客がそれらに満足している場合、すべて削除します。 これらのすべてのフォレストを削除します。







そのようなものがあります-#NoEstimateアプローチと呼ばれます。 これだけです。 評価を停止し、顧客が満足している場合は評価を拒否できます。 これを放棄することを可能にするアプローチ、原則があります。 同時に共有する方法がわからない場合、もちろんこれを行う必要はありません。共有することを学んだ人だけが話しているので、このフェーズに進むことができます。



これを行うには、顧客に価値を継続的に提供し、顧客があなたに不満を抱いているために速度を落とす外部の依存関係を取り除き、機会とニーズを平準化する必要があります。 顧客と共有する結果、および最終顧客、ユーザーなどのニーズに関するあなたの能力。 それがすべて同じであり、それらが等しい場合、顧客は「いつ？」という質問であなたのところに来るのをやめます。 あなたは彼のために合理的な時間に彼が必要とすることをするだけです、それがすべてです。



つまり これらの森林を削除すると、他の事柄があなたの注意を引くようになり、それら自体が現れます。 まるであなたのサークルのように、あなたはそれについて考えています：「どうやってそれに対処することができますか？」、しばらくすると、あなたのサークルは徐々に成長し、さらに多くの問題があることがわかります。 しかし、そのような人々と話をすると、生産中の人はどうにかうまくいかず、他の人は市場を促進するための戦略を考えているように見えます...私はチームについて話しているのです。 これは、あなたが知っているように、誰かが液体スープを持っている、そして誰かが小さな真珠を持っている-この種の話が続いています。 つまり はい、私たちには多くの問題があります、もっとあるように見えますが、これらの問題の冷静さのレベルははるかに高いです。 そして、そのようなチームははるかに効果的です。



しかし、私のような外部のオブザーバーの観点からは、アジャイルを実装し、チームが内部で共有できることを確認するマネージャーは、クールなチームとクールなチームは同じように見えます。 プラクティスの存在に関係なく、同じ速度を使用するかどうかにかかわらず、同じように見えます。 しかし、一方は配布し、もう一方は配布しません。



ここで何が重要ですか？ カーゴカルトのようなものを避けることが重要です。







カーゴカルトのアイデアはこれです。 第二次世界大戦中、アメリカが日本と戦ったとき、彼らは自力で操縦できるように太平洋の島に飛行場を建設しました。 彼らは飛行場を建設し、飛行機を飛ばし、衣服や食べ物を落としました。 時々彼らは飛行場を逃しました、そして、それがこのように見えたので、先住民は幸せでした－飛行場が島に現れるとすぐに、食物は空から落ち始めました。 直接的な明確なコミュニケーション。 そして、彼らは滑走路とほぼ同じ飛行場を建設し始めました。 第二次世界大戦が終わった後、彼らは「飛行場」を作り続け、それが宗教に変わりました。 彼らはそれを信じ始めます。



だから、人々が管理者の側から来て、「みんな、あなたは分割しないで、あなたはそのような習慣を持っている」と言うとき、それは時々貨物カルトに変わります。 時々、これは実際に機能しますが、チームには結果がありません。 たとえば、チームでの作業を開始するとすぐに、Definition of Doneを起動しましたが、コミック形式の問題はまだ発生していませんでしたが、この問題はまだ発生していません。 しかし、Done of Doneを起動しました-このことは機能しているようです...これらの森林を放棄することは非常に困難な場合があります-それらは有用であるように思えます。 すべてを拒否できます。これは柔軟性です。







チームAはどのような問題を解決しますか？ スプリント、速度、ストーリーポイント。 したがって、配信も配信もされないことがわかります。 それは素晴らしいことであり、彼女はそれに集中しています。 チームBが何をしているのかはまだ明らかではありません。



成長分野は何ですか？ どこで開発できますか？







原則として：

• 配送
• 技術試験の面での品質、テストの面での品質だけでなく、結果としての技術の品質、
• および製品-エンドユーザーが必要とすることを行いますか？

これらの各領域で開発できます。







そして、毎回私たちが戦うドラゴンが一人います。 したがって、そのようなチームをデフォーカスして、以前のポジションに戻すことは無意味です。







原則として、最初のドラゴンは補給品です。 高品質の提供はチーム内の規律、チームが共有する能力、つまり品質を確保するために次のレベルで必要な技術的なタスクを意味するため、共有しない場合、予測できないほど顧客のために共有する必要があります。



以下。 品質、製品。 私はそれらをはしごに勝手に配置しました。もちろん、それらは大きな重なりで配置されています。 しかし、たとえば、供給が確保されていない場合、チームが高品質の製品を製造できるようにすることに集中できるとは言えません。 たとえば、並列起動など。 2か月以内に、実験できるように機能を修正する必要があります。 または3週間-それはあなたが持っているビジネスの種類によって異なります。 そして、あなたが供給しない場合は？ 予想外に供給したら？ チームのプロダクトマネージャーの間で絶えず対立しているように見え、マネージャーが「さて、どこで？」と言ってきます。 あなたは言う：「あなたの要件は、正直に言うと、たわごとです。」 そして、彼は次のように言います。「とにかく配達しなければ、どのような違いが生じるのですか？」 あなたはこの状況のせいです。 彼がどんな悪い要件をあなたに提供しなくても、あなたは責任があります、同意しますか？ とにかく、あなたは長すぎました。 たぶん、この間に要件が変更されたのでしょうか？ 要件を変更する時間よりも早く提供する必要がある。 その後、この方向に移動できます。



それでは、トピックに戻ります-アジャイルは実際にはどういう意味ですか？







デミングサイクルがあります。それは左側にあり、混同しないでください。 計画、実行、確認、行動。 そして右側-これは同じ「それがどうなるか」であり、彼らはただ走りました。 そして原則として、私の観点からは、それらの境界はアジャイルチームと非アジャイルチームを区別します。 私たちが公園で遊ぶだけで、すべてが悪い場合-それはあまりアジャイルではなく、この方法はより構造化されています、この方法はより効果的な結果をより速く導きます。 計画、実行、確認、行動。



計画-計画。 バッチ処理（正しい単語が見つかりませんでした）-小さな計画を立てます。 スクラムについて話している場合、これは2週間前です。 技術的な改善について話している場合、用語も非常に短いです。 無駄のないスタートアップについて話している場合、非常に短い期間もあります-おそらく、数日です。



行う-私たちはそれを行います。 ここでは規律が重要です、私たちは結果を達成します。 私たちは単に形象化するだけではないので、後でうまくいかない場合は、次のスプリントを転送します。 何をする準備ができているかを判断しましょう。 最後に完成した小さなミサゴ。



チェック-フィードバックと指標も非常に重要です。 これが効果的な柔軟なチームを区別するものであるように思えます。 前のケースでは、この方法で作業するため、常にフィードバックが得られるわけではないため、サイクルを際限なくスピンすることができ、達成可能な結果は得られません。







実験-新しいことを試してみる必要があります。実験の形でそれを行ってください。 そして、改善のこの短いサイクルは絶えずねじれています。 私たちは常にいくつかの改善を試みています。







これが典型的なスクラムの外観です。バックログ、スプリントは、30日間クラシックスクラムで動作します。 ほぼ同じサイクルになります。







スプリントは、スプリントプランニング、タスクボード、スタンドアップと言えば、Doneの定義が規律を提供し、スクラムでフィードバックのためのデモを実施します。



そのため、実験を実施して、目的の結果が得られるかどうかを確認できます。 ペアプログラミングを試してみて、それがあなたに利益をもたらすかどうかを確かめてください。 これはいやらしい例です。多くのそのような例があります。私たちが見ることができるメトリックを選択するだけで、生産性が向上するかどうかを確認できます。



これがスクラム、これが配信です。 共有方法がわからない場合、スクラムは方法の1つです。2番目の方法はかんばんです。これは、絶え間ない改善のサイクルを提供します。







テスト駆動開発について話す場合、技術的な部分-赤、緑、リファクタリングについて。



Agile, , , . , . , (- ), . ? , Agile, ? - , , , - , , ? , .







. ? , .



, , — , . , . , . ? . : «, , . ». , story, , . .



— , . , , — cycle, velocity , User Story, Story Mapping, Estimation, Definition of Done ..







Lean Startup . , , , learn, build, measure.



- , , -, welcome- , . Welcome- . , : «, ». : «, ». : «, , . , , welcome-, ». , , . どうする Lean startup , Minimum Viable Product, , , , . real time. , , , , .. つまり , , , , , . .



, . Agile . , . , . , .







, .



-, . Lean Startup , Scrum' . . Customer Development, Lean Startup, Design Thinking.







— , , . . -, . , -, , . , , , Open Running. , . . .



, . , , time to market, , , , . , , - , , . , « », , , .



Test Automation, Continuous Integration Continuous Delivery, DevOps — . , , , . , . , .

連絡先

» askhat@scrumtrek.ru

» Facebook

» Twitter

» Zibsun

» Scrumtrek

— Whalerider .

2017 , :)



, WhaleRider .



ScrumTrek, agile — AgileDays