みなさんこんにちは！ 年間を通じて、
Elbaサービスを開発してきました。 私たちのプロジェクトでは、開発者だけでなく、アナリスト、インターフェイスサイエンティスト、エンジニアリング心理学者、ドキュメンタリー、テスター、プロモーター向けにチーム全体にアジャイルプラクティスを導入しました。 うまくいったようで、この経験を共有したいと思います。
なぜ極端なのですか？
サーキットでのトレーニング中に
ケント・ベックは、彼がいかに極端なプログラミングを思いついたのかを語った。 当時、いくつかの優れたプラクティスが知られていました：ペアでのプログラミング、単体テストコード、継続的インテグレーション、反復作業など。 ケントのノウハウは、これらすべてのプラクティスを同時に使用することを提案し、ケースバイケースではなく、一般的に常にこれを行うことを提案したことでした。 つまり、この場合の「極端な」という言葉は、「過激主義」ではなく「極値」に由来します。
プロジェクトの作業開始時の状況はやや似ていました。開発者はアジャイルの実践を知っており、それを適用しましたが、チームの他のすべての人は開発者の数倍でした。 それから、これらの慣行を仕事に関係するすべての人々に広げようとする考えが生まれました。 したがって、アジャイルは「極端な」ものになりました:)
しかし実際は、誰もがすぐに興味を持つように、記事の名前を大きくしたかっただけです。 まあ、そしてサーキットでのケント・ベックのトレーニングに言及して、世間の注目を集めるようにしましょう。
プロジェクトについて
エルバは、小企業の会計士に代わるものです。会計と行動を形成し、税金を考慮し、報告書を作成し、いつ、どの報告書を提出する必要があるかを伝えます。
プロジェクトの詳細：
- プロジェクトには、彼が必要とするものを親切に説明し、そしてこの人生の休日の費用を支払う特定の顧客はいません。 かなり一般的な用語でのみ、私たちがやりたいことを示しているので、時間のかなりの部分がユーザーの調査に費やされています。
- 報告はそれほど単純ではありません。私たちの法律は複雑で、規則は定期的に変更され、互いに矛盾しているため、鳥の言語から人間の言語への規制文書の翻訳に別の重要な時間を費やす必要があります。
- ユーザーは会計に精通していないため、法律の悪夢からユーザーを救う非常に明確なインターフェイスが必要です。すぐに良いインターフェイスを作成することはできないため、開発を開始する前に、プロトタイプインターフェイスの設計とユーザビリティテストに別の重要な時間を費やす必要があります。
チームは次のようになります。
合計：全体的な結果を達成しなければならない21人。 これに使用するプラクティスは以下のとおりです。
1つの部屋にすべて
これは最も簡単なパターンであり、その利点はすぐに感じられます。 最初は、別のフロアに座って、メールで話し、それに多くの時間を費やしました。 ある部屋に移動するとすぐに、その効果をすぐに感じました。長い手紙を書くのをやめ、一般的に書く回数が減りました。 質問は現在、はるかに速く、より成功しており、より積極的に解決されています。
計画中
なぜ計画しているのですか？
- 計画が成功を収め、チームの意欲を高めます。 反復で行われたすべてのタスクを実行しようとしますが、これにより良好な状態が維持されます。
- すでに書いたように、私たちの場合、プログラミングを開始して開始することはできません。タスクは、アナリスト、インターフェイス科学者、心理学者など、さまざまなグループが処理する必要があります。 計画はアクションを同期します。
今年の最初の計画を立てました。それは非常に詳細だったので、すぐに時代遅れになりました。 それ以来、私たちは長期計画に従事していません。 それにもかかわらず、計画なしでは実行できません。2週間の反復を計画し、次の1.5か月から2か月で何をするかを大まかに想像してください。
したがって、イテレーションの初日に、チーム全体が計画委員会に集まります。 現在の反復のタスクは詳細に計画されています。 また、次の反復をいくつか計画しますが、おおよそ、タスクを分解することはありません。 大幅に簡略化すると、計画は次のようになります。
したがって、タスクはリリース日まで「ポップアップ」します。
実際、すべてのタスクが開発にそれほど長い道のりを行くわけではありません。 むしろ、これは大規模で複雑なタスクで発生します。 例外的なケースでは、タスクを開発者の反復に直接入れます。 たとえば、パートナー向けのプロモーションコードを作成するというアイデアが生まれたとき、誰もがこのタスクの重要性を非常に感じ、翌日にリリースしました。 一般に、人生において、計画委員会は
少し混乱するように見え
ます 。
一般的な計画が完了した後、グループはコーナーで分岐し、反復で入力されたタスクを評価します。 誰もがこれに関与しているわけではありません-開発者、インターフェース科学者、アナリストのみ：残りのグループの活動は十分に計画されていません。 タスクを評価するために、
プランニングポーカーをプレイします。 評価の結果、タスクが反復に適合しないことが判明した場合、何を捨てる必要があるかを決定します。
TK = HZ
最初は、長くて詳細なToR（習慣から）を準備しましたが、開発者は一般的に読むのが好きではなく、開発者も例外ではありません。 さらに、反復中に、読む時間がなく、ペアになっていることがはるかに少ないため（開発者はほとんど常にペアで座っています）、したがって、TKはかなりHZに名前が変更されました。
HZでの作業方法 このように：
インターフェイスプロトタイプが最高のTK
プログラマーはテキストを見るのではなく、デザイナーが開発したインターフェースのプロトタイプを見る。 プロトタイプを読む必要はありません。何をする必要があるかはすぐにわかりますが、プログラマーはまだ式と形式のためにTKに行きます。
アナリストプレゼンテーション
アナリストが別のトピック（たとえば、年金基金への報告）を作成するとすぐに、チーム全体のプレゼンテーションを手配します。 プレゼンテーションの後、少なくとも一般的な意味で、誰もが何を想像します。
わからない-尋ねる
私たちは隣同士に座っているので、疑問が生じたとき、TKで答えを探したいという欲求はありません。アナリストに聞いてください。 一般的に、私たちは非常に多くのことを伝え、これの利点を感じます（分析でも:)。
デザインピース
TKとインターフェイスのプロトタイプの両方がシステム全体に完全に準備されているわけではありません。この時間はありません。その意味はありません。1年前にインターフェイスの詳細なプロトタイプを設計できたとしても、1か月で廃止されます。 アナリティクスを準備し、近い将来に開発されるもののみを設計します。
毎日の飛行
すべての人にタスクを渡す専用の人はいませんが、自己組織化が大きな役割を果たします。 それが機能するためには、その行動を他の人と調整する必要があります-誰もが他の人がやっていること、やろうとしていることを知っている必要があります。 デイリーフライはこの問題を解決します。全員が毎日同じ時間にイテレーションボードに集まります。
反復ボードには、現在の反復で行う予定のタスクが含まれています（反復の開始時のタスクシートは、計画ボードからこのボードに接着されています）。
私たちは上から下に進みます-各グループは、1日で何が行われたか、明日何をする予定かを報告し、タスクを上回ります。
その場で、誰かが他の誰かが非常に重要だと考えているタスクをしていないか、タスクの解決が遅れているかをすぐに確認できます。
これにはすべて約20分かかります。
デモンストレーション
デモンストレーションは、反復の最後に行われます。 その上で、指示は反復が行われたものを示し、議論します。 これは、すべてのプロジェクト参加者に情報を広めるもう1つの方法です。
- 開発者がシステムを表示します。 常にイテレーションの終わりまでではなく、すべてが美しく正確に機能しますが、常に示すものがあります。
- デザイナーはプロトタイプを見せます。 プロトタイプからは見えない微妙な点を説明してください。 多くの場合、開発者はこのプロトタイプを開発の次の反復で使用するため、デモンストレーションは特に役立ちます。
- グラフィックデザイナーは、システムの新しいセクションのバナー、チラシ、グラフィックデザインを表示します。
- ドキュメントにはヘルプ動画が表示されます。
- アナリスト、心理学者、昇進者は通常何も示さず、彼らの仕事の結果はそれほど明白ではありません。
人生は、多くのチームメンバーにとって、デモンストレーションがリリース前にシステムを見る唯一の機会であることを示しました:)
回顧
振り返ってみると、チーム全体が過去のイテレーションで良かった点と悪い点を振り返っています。 誰もが彼を興奮させるものを伝えることができます-反復中に、この時間は必ずしもありません。
回顧の結果、次のイテレーションで何をする必要があるかについての計画が得られるので、全員が良くなります。 通常、これらは機能しないタスクです。たとえば、レイアウトデザイナーをチームに連れて行ったり、twitterポップコーンで写真を撮ったりします。
これが、「extreme agile™」という観点での開発プロセスの一般的な見方です。 後で、より詳細にいくつかの側面を紹介したいと思います。また、コメントであなたの質問に答える準備ができています。 あなたの質問に答えるプロセスが私の職場の後ろに押しつぶされることはないように、誰かが記事の著者と私たちのチームの主なアジャイルのイデオローグ、Zhenya KobzevとSemyon Molotkov（私はPMでアドレスを提供します）
ここに続く：
habrahabr.ru/blogs/agile/113419