従来のプロジェクト開始後のアジャイル開発の紹介

約一年半前、私はアジャイル開発をしていると主張する職場に入りました。私が学んだことは、この場所はいくつかのアジャイルプラクティス（毎日のスタンドアップ、スプリントの計画、スプリントのレビューなど）を採用しているが、原則（ジャストインタイム/十分に良いメンタリティ、失敗を早期に公開する、リッチなコミュニケーション）を採用していないことです。

私は今、チームをより機敏にすることを任されており、開発者とビジネスチームから完全に賛同できることを確信しています。パイロットプログラムとして、15か月の要件収集を完了し、110ページの分析と設計ドキュメント（「石で書かれた」と見なされる）があり、最後にアクセスできないプロジェクトが与えられました。ユーザー（実際に製品を使用しないユーザーのマネージャーで構成される委員会のみ）。

私は小さく始めて、最初の5つのスプリントに期待される成果物のリスト（将来のスプリントは未定義のまま）、最初のスプリントの目標のリストを与え、最初のスプリントの目標を満たすのに十分なユーザーストーリーを取得するためにA＆Dドキュメントを分析しました。

それ以来、彼らはなぜすべてのスプリントのすべての要件がないのか、なぜ私が3番目のスプリント（もっと重要だと考えているが最初のスプリントの成果物に基づいている）の作業に着手していないのかと尋ねてきました。 2つのスプリント）そして、私のITチーム全体が忙しい作業または私たちとは無関係であると考えるさらに多くのドキュメントを求めています（ユーザーマニュアルを前に書く、すべてのスプリントのすべてのデータフィールドを前にドキュメント化するなど） 「前払い」作業）。

これは私にとって新しいプロジェクトマネージャーとしてはかなり大雑把でしたが、ストーリー管理のスクラムバン、ペアプログラミング、顧客に受け入れテストを（要件ドキュメントの一部として）提供してくれるなど、効果的に実装した改善点があります。 。

だから私の質問は：

1. 抵抗力のあるビジネスに変更をより効果的に導入するにはどうすればよいですか？
2. ビジネスにアジャイルの利点を示すためにIT側に導入できる他のプラクティスはありますか？
3. 文書化の負担は私たちを苦しめています-ビジネスはそれをリスクとしてではなくリスク管理戦略としてまだ見ています。文書化の懸念と要求を緩和するために何ができるか（具体的には、文書化の量とそのすべてに対する事前のニーズ）。
4. 私たちは私たちのビジネスとは別の建物にあり、約3ブロック離れています。彼らは、プロジェクトに参加している人に、同じ場所に他のプロジェクトに取り組むことはできません。建物。" 彼らは私たちがいつもそこに行って質問をまとめることを期待しています。そうすればすべてを一度に尋ねることができ、その人の時間を「絶え間ない中断」で無駄にしないでください。彼らからより豊かなコミュニケーションを得るために私たちは何ができるでしょうか？

追加のアドバイスもいただければ幸いです。

ありがとう！

開発者とビジネスチームから完全な賛同を得ていることを確信しています[...]エンドユーザーへのアクセス権がありません[...]

はっきりしていることの1つは、一方で「賛同を得ている」ことを口頭で保証することと、他方であなたの仕事を後援している人からの実際のコミットメントとの違いです。

あなたへの私の最高のアドバイスは、ラベル「アジャイル」を完全に脇に置くことです。可能な限り会話から言葉を禁止してください。代わりに、次のことに集中してください。

• どのような結果をあなたが提供するように求められます（具体的には、いないチーム）
• ミッションの成功基準は何ですか（ここでも、チームのものではなくあなたのものです）
• あなたが自由に使えるとはどういう意味ですか（人、人へのアクセス、時間、情報、トレーニング予算など）

「チームの俊敏性を高める」ことは、実用的な目標ではありません。十分に具体的ではなく、測定不可能であり、終了条件はありません。必要なのは具体的なものです。目標は、Z日付ごとに、欠陥のXパーセントの減少、または機能の配信日のYパーセントで表されます。

これらの目標を達成するには、変更を導入する必要がある場合があります。ここで、いくつかの経験則が適用されます。すべての改善は変化ですが、すべての変化が改善であるとは限りません。多くの場合、人々が変更に抵抗するが、実際に人々は、レジストと言っています変更され、変更が改善されるかどうかわかりません。

あなたが簡単な勝利であり、ぶら下がりの実りであるとあなたが思う慣行に焦点を合わせてください。変更を実装するためだけでなく、変更の影響を評価し、それらが回帰ではなく改善をもたらしていることを人々に安心させるためのフレームワークを確立する実践に焦点を当てます。「情報ラジエーター」は遡及的であるようによいです。

これらの変更の中には、重要な情報を持つ人々へのアクセスを増やすなど、必要であると同時に脅威として認識されるものもあります。これらについて妥協しないでください。「買い込み」とは、要求されたものを提供するチャンスを実際に得る交渉のプロセスを意味し、子羊のように政治的虐殺に導かれるのではありません。

物事がうまくいかない場合に責任をあなたに移すのが難しいように物事を設定してみてください（そして、多くはおそらくうまくいかないでしょう）。これが発生する可能性があることに注意し、発生した場合に備えてください。出口戦略を把握してください。

新しいものをスムーズに導入するためには、人々がそれを脅威や永久的なものと見なさないようにする必要があります。

私たちの多くは、何らかの新しいことを避けるために自然に配線されています。それは生物学的です。通常、目新しさを求める人は、問題を引き起こしません。より不安な人々があなたの提案を彼らの現在の快適さに対する脅威として見ないようにする必要があります。

チームが実践やアイデアを採用する理想的な方法は、そのアイデアがチームや外部管理者などの外部の人々からではなく、ランダムなコンサルタントからではないことを確認することです。これを実現するには、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を運転するように頼むようであり、私はあなたがそれをするためにシェベットをあなたに与える。

必要なドキュメントの時間/リソース/コストを組み込んで、スケジュールがどれだけ進んでいるかを見てもらいます。

これは、プロジェクトチームにどれだけの労力を費やしているかを示し、そうしなかった場合にこれをどのように減らすことができるかを示すのに役立ちます。