アジャイルとオフィスについて少し
最近、 アジャイル開発でスクラムトレーニングと2日間のワークショップ（トレーニングと呼ぶことはできません-50％の時間でライブドキュメントを操作し、プロジェクトに関する情報を取得するアーティファクトを生成します）でアジャイル-REQ-アジャイル要件分析で要件を収集しました。
とても面白かったです。 最初のトレーニングは、ほぼ円卓の形で行われました。 4時間、アジャイルについて議論しました。アジャイルとは何か、アプローチが特定のプラクティスを推奨する理由です。 これには特別な魔法はないという結論に達しました。これはプロジェクトの作業を整理する際の常識です。
参加者の1人がこのトレーニングについて楽しく語りました。 ：
「Nikita Filipovとのトレーニングでした-脳へのアジャイル注入。 「私たちはプロジェクトでアジャイルを使用します」のような人に強く勧めます。 実生活で非常に安全に存在するこれらの非常に多様な倒錯はすべて、アジャイルでもスクラムでもないことを理解すること。 アジャイルは、たとえば、チームが十分に動機付けられていない、またはチーム内で矛盾があるという問題を解決しないという事実と同様に。 スクラムは、予見可能な将来に優れた（中程度の）プログラマーの効果的なチームを構築するための良い方法です。 。 第一に、このレシピは必ずしもすべての人に役立つわけではなく、第二に、単に「正しく調理する方法がわからない」だけかもしれません」- 感情的なレビューをありがとう:)
私にとって、もう1つの重要なイベントは、Newspaper Laneの新しいオフィスですでにこのトレーニングを行ったことです。 現在、私たちの小さなトレーニングルームとオフィスがあり、同僚のイリーナとアスクハットがScrumTrekとロシア市場で最高の企業になるために役立つ企業のために仕事をしています:)。 したがって、私たちはすべての友人や知人が私たちを訪問するのを待っています。
要件管理
2日目と3日目は「ワーキンググループ」の雰囲気に包まれました。8人のプロダクトオーナーとプロジェクトマネージャーの輪で2日間、アジャイルプロセスで要件を収集するライフサイクルについて話し合いました。 もちろん多くの議論がありましたが、それらのいくつかは要件に直接対応していませんでしたが、プロセスの性質のものでしたが、それらをバイパスしませんでした。 トレーニング全体は、いくつかのアクティビティで構成されていました。
- 理論
- 効果のない製品管理の原因を特定するのに役立つ事例研究の議論。
- 業界が開発した実用的なツールと演習、およびこの分野の企業との個人的な経験。
初日は、プロジェクトのマネージャーまたは製品マネージャーの観点から、要件の収集と製品全体の構築に関連する原則と問題に焦点が当てられました。
2日目は、コンセプトからリリースの計画と再スケジュールまでのライフサイクルの継続的なシミュレーションとして編成されました
ロシア市場での製品開発と欧米の顧客とのアウトソース開発というさまざまなセグメントのトレーニングマネージャーが出会ったのは嬉しかったです。 興味深い議論が始まりました 。そして、 Roma Yuferev（Avicode）の経験は、私の練習からのケースよりも多くにとって有用でした。
トレーニングの後、Romanは私に彼の関連するレビューとともに手紙を書きました。
ソフトウェア開発の分野で働くスペシャリストが最も頻繁に遭遇する問題のうち、プロセスの問題と製品の問題の2つの最も重要な分野を区別できます。 そして多くの場合（少なくとも私の実践では）、努力の主な焦点はプロセスの作成/改善にあります。 特に、アウトソーシングプロジェクトでは、「シンデレラ現象」を時々観察できます。プロセスは最愛の娘であり、製品とその問題は「良い妖精」-プロダクトオーナーのみを心配します。 現時点では、2つのアウトソーシングプロジェクトと1つの内部プロジェクトでこの「良い妖精」の役割を担っていることから、私の場合の重要な問題の1つは、要件の収集、分析、整然とした作業の問題であることを明確に理解しました。 Nikita Filippovaによるトレーニング「Agile Requirement Analysis」は、2種類のプロジェクトの要件を処理するプロセスを合理化し、再構築するのにすでに役立ちました（1週間しか経っていませんが）。 すべての「ギャップ」がまだ修正されているわけではありませんが、問題はすでにはっきりと見えており、開発プロセスへの影響は明確であり、これらの問題を解決するための対策が特定されています。 私の意見では、このようなトレーニングは、スクラム自体が何も提供しない問題の領域をカバーするため、非常に有用です。 トレーニングでは、ビジョンの作成、プロジェクトの目標と制限の定義、ユーザーロールの定義など、ほぼすべての反復的な開発プロセスに適用できる一連のプラクティスとツールを学習（想起）できました。 そのため、どのプロセスを使用していても（おそらくWTFでも...申し訳ありませんがウォーターフォール）-このトレーニングはおそらく役に立つでしょう。
ここに昨年2月のニュースがあります:)