従来のプロジェクト開始後のアジャイル開発の紹介
約一年半前、私はアジャイル開発をしていると主張する職場に入りました。私が学んだことは、この場所はいくつかのアジャイルプラクティス（毎日のスタンドアップ、スプリント計画、スプリントレビューなど）を採用しているが、原則（ジャストインタイム/十分に良いメンタリティ、失敗を早期に公開する、リッチなコミュニケーション）を採用していないことです。
私は今、チームをより機敏にするという任務を負っており、開発者とビジネスチームからの完全な賛同を得ていると確信しています。パイロットプログラムとして、15か月の要件収集を完了し、110ページの分析と設計のドキュメント（「石で書かれた」と見なされる）があり、最後にアクセスできないプロジェクトが与えられました。ユーザー（実際に製品を使用しないユーザーのマネージャーで構成される委員会のみ）。
私は小さく始めて、最初の5つのスプリントに期待される成果物のリスト（将来のスプリントは未定義のまま）、最初のスプリントの目標のリストを与え、最初のスプリントの目標を満たすのに十分なユーザーストーリーを取得するためにA＆Dドキュメントを分析しました。
それ以来、彼らは私たちがすべてのスプリントのすべての要件を持っていない理由、なぜ私が3番目のスプリントのためのものに取り組み始めていないのか（彼らはより重要だと考えていますが、最初の成果物に基づいています） 2つのスプリント）そして、ITチーム全体が忙しい仕事や私たちとは無関係であると考えるさらに多くのドキュメント（ユーザーマニュアルを事前に作成する、すべてのスプリントのすべてのデータフィールドを事前に文書化するなど）を求めています。 「前払い」作業）。
これは私にとって新しいプロジェクトマネージャーとしてはかなり大雑把でしたが、ストーリー管理、ペアプログラミングのためのスクラムバンなど、私が効果的に実装した改善点があります。 。
だから私の質問は：
- 抵抗力のあるビジネスに変化をより効果的に導入するにはどうすればよいですか？
- ビジネスにアジャイルの利点を示すためにIT側で導入できる他のプラクティスはありますか？
- 文書化の負担は私たちを悩ませています-企業は依然としてそれをリスクではなくリスク管理戦略と見なしています。彼らの文書化の懸念と要求（具体的には、文書化の量とそのすべてに対する事前の必要性）を軽減するために私たちは何ができるでしょうか？
- 私たちは私たちのビジネスとは別の建物にあり、約3ブロック離れています。彼らは、プロジェクトに参加している人々が「私たちにいる間は他のプロジェクトに取り組むことができない」というb/cに住むことを拒否しています。建物。"彼らは私たちがいつもそこに行き、質問をまとめて、すべての人に一度に尋ねることができ、その人の時間を「絶え間ない中断」で無駄にしないことを期待しています。彼らからより豊かなコミュニケーションを得るために私たちは何ができるでしょうか？
追加のアドバイスもいただければ幸いです。
ありがとう！
開発者とビジネスチームからの完全な賛同を得ていると確信しています[...]エンドユーザーにアクセスできません[...]
非常に明確にする必要があることの1つは、口頭で「賛同」していることを保証することと、一方で実際のコミットメントからあなたの作品を後援している人は誰でも。
あなたへの私の最善のアドバイスは、「アジャイル」というラベルを完全に取っておくことです。言葉をできるだけ会話から禁止してください。代わりに、次のことに焦点を当てます。
- 何結果あなたは提供するように求められます（あなたは具体的には、チームではありません）
- あなたの使命の成功基準は何ですか（ここでも、チームではなくあなたのものです）
- 何手段自由に使えるか（人、人へのアクセス、時間、情報、トレーニング予算など）
「チームの俊敏性を高める」ことは、実用的な目標ではありません。それは十分に具体的ではなく、測定可能ではなく、終了条件がありません。必要なのは特定のものです。ターゲットは、欠陥がXパーセント少ない、または機能の配信日のYパーセントがZ日で表されます。
これらの目標を達成するには、変更を導入する必要がある場合があります。ここで、いくつかの経験則が適用されます。すべての改善は変化ですが、すべての変化が改善であるとは限りません。人々は変化に抵抗するとよく言われますが、実際には人々は抵抗します変化しているそして変化が改善になるかどうかわからないのです。
あなたが簡単に勝つと思う練習に焦点を合わせてください。変更を実装するためだけでなく評価の変更のためのフレームワークを確立するプラクティスに焦点を当て、それらが回帰ではなく改善をもたらしていることを人々に安心させます。 「情報ラジエーター」は、回顧展と同様に優れています。
これらの変更の一部は、重要な情報を持っている人々へのアクセスを増やすなど、必要であり、脅威と見なされる可能性があります。これらについて妥協しないでください。「バイイン」とは、子羊のように政治的虐殺に導かれるのではなく、求められているものを提供するチャンスを実際に得る交渉のプロセスを意味します。
物事がうまくいかない場合に責任をあなたに移すのが難しいように物事を設定するようにしてください（そして多くはおそらくうまくいかないでしょう）。これが発生する可能性があることに注意し、発生した場合に備えてください。出口戦略を把握してください。
新しいものをスムーズに導入するためには、人々がそれを脅威および永久として認識しないようにする必要があります。
私たちの多くは、あらゆる種類の新しいことを避けるために自然に配線されています。それは生物学的です。通常、目新しさを求めている人は、問題を引き起こすことはありません。より不安な人々があなたの提案を彼らの現在の快適さに対する脅威と見なさないようにする必要があります。
チームが実践やアイデアを採用するための理想的な方法は、アイデアがチームからのものであることを確認することであり、経営陣やさらに悪いことに、ランダムなコンサルタントなどの外部の人々からのものではありません。これを実現するには、1つのトピックのみを使用してチーム全体でブレーンストーミング会議を作成します。トピックが問題になるはずです。会議では、慎重にアイデアを持ち込み、議論と事実を提示する必要があります。
恒久的なものについて決定を下すのは好きではありません。潜在的な変化の影響をすでに心配しています。その行動はペットショップでよく知られています。犬を買うことは非常に大きな決断であり、あなたの人生を根本的に変えるでしょう。あなたが店にいるとき、セールスマンはしばしばそれを家に持ち帰って、気が変わったらそれを返すようにあなたに提案します。ご想像のとおり、返品はほとんどありません。この提案の目的は1つだけです。それは、人々が決断を下すのを妨げる不安を減らすことです。チームの練習に、その効果を評価した後、一定の時間試してみることを提案します。
2番目の質問については、一度に1つずつ持参することを強くお勧めします。
あなたのドキュメンテーションの問題は、ここP.SEに投稿する価値があります。両方が定期的に会うことをいとわないのであれば、2つの異なる建物にいるという事実に問題はありません。どちらか一方がまったく会いたくないという状況があります;）
アジャイルは万人向けではありません。あなたのビジネスはアジャイルを言うのが好きなようです。まず第一に、真のアジャイル手法のようにプロセスを作り始めるために、まったく新しいプロジェクトまたは小規模なメンテナンスプロジェクトを推進することはおそらく良い考えでした。すでに進行中のプロジェクトを使用して方法論を再設計しようとすることは、8車線の高速道路の真ん中でタイヤを変更しようとすることに似ています。アジャイルが機能することを示す方法が必要ですが、アジャイルが機能する可能性がある環境が必要ですが、あなたが言ったことに基づいて、アジャイルは確立された文化でうまく機能する可能性は低いです。
彼らがドキュメントに何を求めているかに応じて、これが使用しているツールから自動的に生成されるか、冗長であり、ドキュメントBにドキュメントAが表示するように要求された情報があることを示すことができる場合があります。また、ドキュメントの計画を調整し、見積もりが変更される理由を知らせ、要求されるドキュメントの量を減らすか、ビジネスアナリストなどのリソースをドキュメントの作成に充てるように依頼する必要があります。
Since then, they've asked why we don't have all the requirements for all the sprints, why I haven't started working on stuff for the third sprint (which they consider more important but is based off of the deliverables of the first 2 sprints) and are pressing for even more documentation that my entire IT team considers busy-work or un-related to us (such as writing the user manual up-front, documenting all the data fields from all the sprints up front, and more "up-front" work).
それはあなたの問題だ。彼らはそれを理解していません。誰かがあなたにもっと機敏になるように頼むことはできず、乗るために一緒に行くことをいとわないでしょう。彼らは間違った期待を持っています。あなたが始める前に、物事は前もって壊れています。期待を修正しないと失敗します。それは私にあなたに150 MPHを運転するように頼むようであり、私はあなたがそれをするためにシェベットをあなたに与える。
必要なドキュメントの時間/リソース/コストを組み込んで、スケジュールがどれだけ進んでいるかを見てもらいます。
これは、彼らがプロジェクトチームにどれだけの作業を押し込んでいるか、そして彼らがそうしていなかった場合にどのようにこれを減らすことができるかを示すのに役立つかもしれません。