3

アジャイル開発方法論 (SCRUM や XP など) の採用または移行についてビジネスに主張する必要がある場合、どのような主張をしますか (コンセプトをどのように売り込むか)?

例えば

  • 技術者ではない人に、概念と利点をどのように説明しますか?
  • 成功した場合、勝者となった議論/ケース/理論的根拠は何でしたか?
  • 編集:私が尋ねる理由は、私の友人(彼は会社のソリューションアーキテクトです)が現在、まさにこのトピックについて彼の経営陣にどのようにアプローチするかを決定しようとしており、提案に関して私ができることを彼に与えたからです。 . 特に、アジャイルに沿った方法論への移行を成功させた人々の話を聞くのは興味深いことです。

    4

    8 に答える 8

    5

    私の場合: この組織は 2 年間もの間、うまくいかずに失敗しましたが、最終的にはアジャイルの時流に飛び乗りました... (現時点では... 個人的な意見ですが) 世界が急速に進歩している速度で高品質のソフトウェアを作成するためのより良い選択肢はありません。変化します。もう古いやり方で物事を進める余裕はありません。難しい方法で学ぶ人もいます。

    部屋の中の象: アイデアが良いからといって、それが受け入れられるとは限りません。

    論理引数:

    • フィードバック ループが短い。顧客は、各月/イテレーションの終わりに動作するソフトウェアを確認し、それを試して、好みに合わせて調整および微調整できます。開発者が 1 年間生地をしゃぶり、馬を待っている顧客のために酔った象を連れて戻ってくることはもうありません。
    • 開発が機能する前に、すべてを石(聖なる SRS) に設定する必要はありません。時間が経つにつれて、ビジネスの優先順位/市場状況の変化を反映するように考えを変えることができます.. (開発者は癇癪を起こすことはありません)。
    • より良いコミュニケーション: 「これは私が求めていたものではありません!」ということはもうありません。船を救助するために何もできないとき。開発者は実際の顧客とリアルタイムで話し合い、疑念を明確にし、正しいものを構築していることを確認します。適切な製品を確実に構築するための責任は、顧客と開発にあります..常にお互いに話し合うことによって..
    • ヒューマン プロセス:アジャイルは、ソフトウェアは人によって他の人のために作られるという事実を認識しています。プラクティスは、チーム内の相互作用、学習、および尊重を促進します。士気の向上も見られる
    • TDD、自動テスト、ペア プログラミングなどのプラクティスに従うことで、より優れた品質の製品が生まれます。プロジェクト終了時の「バグ修正と変更」フェーズに従来費やされていた時間が最小限に抑えられます。
    • メンテナンスの容易さ。回帰テストはスナップです!構築されたシステムは、適切に行われた場合、変更/拡張が容易です.. 開発者は、シンプルさと過剰なエンジニアリングを第二の性質として重視しています。開発者は、「そこに行って変更する」ことを恐れません vs 「私はそのねじれたものに触れていません..前回の傷はまだ癒されていません.」
    • 開発者の賛同により、締め切りに間に合う可能性がより現実的になります。見積もりは、チャート/mpp/計画の作成を担当する担当者の直感的な見積もりではなく、実際のチームの速度に基づいて修正されます
    • 目に見える進捗状況- 大きな目に見えるグラフ (バーンダウンなど) は、プロジェクトで何が起こっているかを正確に教えてくれます。問題は目の前にあり、無視したり隠したりすることはできません。開発では、管理用の情報を生成するために、週に 1 日「進捗レポート」モードにコンテキストを切り替える必要はありません。開発者が気にしないように見える指標を簡単に収集できます。

    文字制限を破りましたか?:)

    于 2008-10-14T11:05:01.993 に答える
    2

    非技術者は、時間通りに予算内で高品質で完了し、納品時に要件を満たすプロジェクトに関心があります。アジャイルがこれらの品質を提供するのにどのように役立つかに焦点を当てる必要があります。


    次の 2 つの理由から、非技術者にアジャイルを売り込むのは非常に難しい場合があります。

    • 100% 前もって計画しようとしないという概念は、実際には直感的ではありません。
    • 非常に多くの人が、自分はアジャイルを使用していて、無残にも何も提供できず、偉大な SDP の評判を落としていると主張しています。

    変更を処理するアジャイル プロセスの能力について話します。

    すでにあなたと仕事をしている顧客と一緒に仕事をすれば、通常はより簡単です。たとえば、時間の経過とともに蓄積されたすべての変更要求を簡単に表示し、それらがプロジェクトのスケジュールとコストにどのように影響したかを示すことができます。次に、アジャイル プロセスがそのようなケースの処理にどのように役立つかを説明することができます。

    同様に、「ウォーターフォール プロジェクト」で行われた最初の見積もりを取得して、実際の結果と比較することもできます。


    品質へのアジャイルアプローチについてもお話したいと思います。反復中のテストにより、品質が大幅に向上します。すぐにフィードバックが得られる短いイテレーションも非常に役立ちます。

    于 2008-10-14T10:25:21.573 に答える
    1

    それをよく売るものは次のとおりです。

    • テスト、試用、およびリリースできる各反復後の具体的な製品。(自分のお金で何を買うかを見るのが好きな製品所有者に適しています)
    • これにより、開発プロセスに透明性がもたらされ、特に日常のスタンドアップ中に、機能の重複や混乱が削減されます。
    • 各スプリントの後にデモンストレーションを行うことで、製品がどの方向に向かっているのか、開発作業の後に何が利用可能になるのかについて仲間の従業員を教育し、人々がそれをさらに良くする方法について話したり考えたりします
    • 十数回のスプリントの後、開発の見積もりを妥当な精度で行うことができます。少なくともフォーカスファクターにいくつかの変更を加えた後。
    • 開発者が特定の機能を所有するようになると、開発者の賛同が向上します
    • アジャイルを使用した場合の製品変更のコストは、ウォーターフォール方法論を使用した場合よりもはるかに小さくなる傾向があります

    小規模な開発チームに最適ですが、開発チームからの賛同が必要です。

    于 2008-10-14T10:26:57.000 に答える
    1

    古い方法論の問題点と、新しい方法論がそれらの問題をどのように解決するかについて特に言及せずに、新しい方法論を導入することはほとんど不可能です。

    実際には、おそらくたくさんの選択肢を提供し、最後にお気に入りを推薦する必要があります。それがあなたのお気に入りである理由の十分な説明と、選択した方法論の弱点についての十分な知識を備えて準備してください.

    また、自分の感情の強さと主張の強さを混同しないように注意してください。また、個人的な価値観の選択や文化への愛着を客観的な技術的評価として偽装しようとしないでください。あなたの同僚は愚かではありませ

    これについて哲学的になりたい場合、コミュニケーションは実際には雄弁、レトリック、または明瞭さに依存するのではなく、メッセージが聞かれている感情的な文脈に依存します. 人々は、あなたの言葉が彼らを追いかけているときではなく、あなたに向かって動いているときだけあなたの声を聞くことができます.

    于 2008-10-14T11:41:01.203 に答える
    0

    私が読んだり聞いたりしたことから、アジャイルという用語は悪いラップを取得し、人々を怖がらせるようです。ビジネスの観点から言えば、より応答性の高い方法でビジネス価値を提供するにはどうすればよいかということです。アジャイルは、ビジネス価値を迅速に提供するという概念をサポートする方法です。

    技術的な用語で議論するのではなく、ビジネス用語で議論し、エンドカスタマーにより迅速にビジネス価値を提供するのに役立つアイデアがあることを友人に説明することをお勧めします。

    私は彼が方法としてXPやアジャイルについて議論することをお勧めしませんが、代わりに短くて成果物に焦点を合わせた会議(すなわち、SCRUM)を紹介し、そこからそれを成長させようとします。あなたが彼らが望むものをより速くそしてより予測可能な方法で彼らに手に入れることができるとあなたがビジネスに話し、あなたがその声明を実行するならば、あなたはあなたをそこに導く慣行に賛成するでしょう。

    于 2008-10-14T16:15:10.853 に答える
    0

    私の経験では、スクラムを非技術的な管理者に即座に売り込む唯一のものは、バーンダウン チャートです。毎日の進捗状況を示す紙のチャート (誰でも見ることができ、すぐに理解できる) があるというアイデアは、すぐに勝者になります。プロジェクトがスケジュール通りに進んでいるかどうかは、非常に早い段階で明確に示されます。

    バックログ、スプリント、デイリー スクラムなどはすべてバーンダウン チャートを機能させるために必要なので、最初にバーンダウン チャートのアイデアを売り込み、次にスクラムの残りの部分が必要であることを説明し、最後に実行可能であることを指摘します。スケジュールへの影響を最小限に抑えたプロセスの 3 週間のトライアル。

    于 2008-10-14T10:40:37.067 に答える
    0

    技術者ではない私のブーイングは、通常、新しい方法論がチームの生産性をどのように向上させるかについて耳を傾けることを好みます。そのため、管理方法論としてSCRUMを導入するという私たちのアプローチは、進捗状況の可視性より良いコミュニケーション、およびより迅速なフィードバックの向上に焦点を当てていました。

    事実として、他のすべての利益は、私の上司のような人々にとっては目に見えないものです。

    于 2008-10-14T13:26:45.263 に答える
    0

    このビジネスの最大のセールス ポイントは、彼らが何に取り組もうとしているのかを決定し、優先順位を設定することだと思います。

    于 2008-10-14T11:48:36.133 に答える