質問

私はここ PHP/MySQL ショップで最近採用された 2 番目の開発者です。私が採用されたのは、混沌とした混乱の中から何らかのプロセスを導き出した経験が主な理由です。少なくとも、私は前の会社でそうしていました。;)

私がここに来てから(数か月)、上司、プロダクトマネージャー、その他数人の重要人物を仲間に迎えてきました(ただし、スクラムベースの固定概念をご容赦いただければ、ほとんどがニワトリです)。また、1 年以上遅れている主要製品の開発サイクルをある程度可視化することにも貢献しました。人々はそれを気に入っています!

しかし、私の同僚 (今のところここにいる唯一の開発者) はそれに興味がありません。彼女はドアを閉めて仕事に集中し、一人でいることを好みます。自分?私は、コラボレーション、協力、オープン性というアジャイル アプローチ全体に興味があります。彼女の意見なしに、私はスクラムの実践を開始しました (毎日のスクラム、バーンダウン チャート、その他、私や以前のチームで効果があったとわかったもの (アラ H.クニーベルクのクールな壁図)。私たちが毎日立ち上がる間、彼女はまるで私たちが実際には彼女のドアのすぐ外に立っていないかのように(実際には私たちが立っているのですが)、そっと通り過ぎて私たちを無視します。かなりすごいですね。こんな抵抗は見たことがない。

質問...どうすれば彼女を乗せられますか?同調圧力が機能していない。

スクラムボーグ仲間からの感謝の意

美しい

役に立ちましたか?

解決

スクラムのような他のアジャイル手法は、多くの優れた実践例を体現していますが、時にそれに名前を付けて、(多くのブロガーがコメントしているように) 職場で採用しなければならない「宗教」にすることは、多くの人にとってかなり不快です。私自身も含めて。

それはあなたの選択肢やコミットメントによって異なりますが、私は、それが時流だからではなく、良いアイデアであるため、アイデアを受け入れることにもっと熱心であることを知っています。彼女の生活やワークフローをどのように改善できるかを示し、一度に 1 つずつ実践し、彼女を引き込んでみてください。

プログラマーは、物事を成し遂げるのに役立つ素晴らしいものが大好きです。彼らは、説教されたり、時流とみなされるものに乗るように頼まれたりすることを嫌います。後者ではなく前者として提示してください。(言うまでもなく、実際に前者であることを確認してください)

編集:別の質問

私は特定のアジャイル手法を使用する場所で実際に働いたことはありませんが、誇大宣伝や定説なしに多くのアジャイル実践を組み込んでいるという点で、今の自分の置かれている状況にはかなり満足しています (両方の長所、私見です) )。

しかし、スクラムについて読んだところですが、そのようなシステムは 2 人のチームにとっても有益なのでしょうか?スクラムはプロジェクトにある程度のオーバーヘッドを追加するようですが、コミュニケーションと計画がすでに容易な非常に小さなチームの場合は、その利点がメリットを上回る可能性があります。

他のヒント

彼女の意見なしに、私はスクラムの実践を開始しました (毎日のスクラム、バーンダウン チャート、その他、私や以前のチームで効果があったとわかったもの (アラ H.クニーベルクのクールな壁図)。毎日のスタンドアップ中、彼女はそっと通り過ぎて、まるで私たちが実際に彼女のドアのすぐ外に立っていないかのように(実際には私たちが立っています)、私たちを無視します。かなりすごいですね。こんな抵抗は見たことがない。

質問...どうすれば彼女を乗せられますか?同調圧力が機能していない。

うわぁ!誰がそのような抑圧的な環境で働きたいと思うでしょうか?運が良ければ、彼女が履歴書を送ってくれるので、あなたの開発プロセスに協力してくれる人を雇用できるでしょう。

あなたが彼女にしがみつきたいと仮定すると、私はそのようなレトリックを断り(またはオフにし)、まずは友人や同僚になることに努めます。プロジェクトが 1 年遅れれば、彼女は自分自身に満足していないはずがあり、あなたは自分の成功を宣伝することを恐れていないようです。それは恐ろしいことかもしれません。

ただし、スクラムについては何も知りません。あなたの同僚の立場になって歩き回ったらどうなるだろうかと想像しているところです。

美しい、相棒、

Steve Yegge のブログ「 「良いアジャイル、悪いアジャイル」. 。これは古いものですが、良いものであり、約 2 か月前の私のように、職場のアジャイル化に少し「熱心すぎる」人にとっては必読の書だと思います。アジャイルには多くの優れたプラクティスが用意されていますが、それらをすべて割り引いて受け止め、欠けているものを採用し、特定の状況では役に立たない可能性のあるその他の不要なものはすべてスキップする必要があります。毎日のスクラム。あなたの同僚が静かにコードを書きたいだけで (これが良い理由については Peopleware を読んでください)、彼女が生産的なチームメンバーである場合は、スクラムで彼女を困らせるのをやめて、彼女が最も好きな方法で仕事をさせてください。

あなたが彼らに近づき、単に「少し時間ありますか?聞いてください、今はコミュニケーションが本当に問題になっています。あなたが何をしているのかわからないような気がします。また、先週のようにすでに書いたことを書くのに二日も費やして、また足を踏み入れたくないのです。これに取り組みましょう。Xを試してみたいのですが、どう思いますか?」思いやりを持ち、「悪いリンゴ」を容認しないでください。文字通り、私が職場を敏速に改善した方法です。そして、多くの問題が蒸発し始めました。私たちは、機能し、必要なものはすべて使用しているだけなので、100% XP または 100% スクラム準拠の場所ではありません。

単純。スクラムについては話さないでください。彼女にスクラムを使わないでください。代わりに、スクラムの基礎となる原則を採用します (例:アプリケーションではなく目的)、彼女の仕事のやり方に適応しながらもスクラムの微妙な色合いを持つさまざまなアプローチを作成します。

人間は皆異なり、多くのプログラマーはスクラムを嫌います。逆効果になるだけなので、強制はしません。開発プロセスの問題を (スクラム以外の方法で) 特定し、問題が存在することに彼女に同意してもらえるかどうかを確認してから、質問することをお勧めします。 彼女 彼女が考える良い解決策は何か。彼女の協力とプロセスへの意見は彼女の協力にとって不可欠であり、賛同がなければ彼女は国民にはなりません。

そこからは、うまくいけば、ある種の準ハイブリッド スクラムと彼女のプロセスへのアプローチを作成し、両者が前進する方法について同意できるようになります。

重要なのは、そもそもなぜあなたがスクラムをやっているのかを彼女に理解してもらうことだと思います。あなたにも理由があると思いますので、彼女に話してみてはいかがでしょうか?関係者がなぜ変化があるのか​​、それによって何が得られるのかを理解していなければ、どんな変化に対しても抵抗を受ける可能性があります。スクラムを使用する理由と次の利点を、彼女の日常業務に関連した形で説明できれば、彼女はスクラムに対してより前向きな姿勢を示す可能性が高くなると思います。

彼女がスクラム プロセスに何の価値も感じていない場合、またはスクラム プロセスが自分にどのように関係しているかを理解していない場合、おそらく彼女はそれを気にしないでしょう。

スクラムに関して理解すべき最も重要な概念の 1 つは、個人ではなくグループとして作業し、プロジェクトにコミットするという事実だと思います。多くの人にとって、これは「自分の世界」に住むことに慣れているため、理解するのが最も難しいことです。

スクラムがここでの中心的な問題であるかどうかはわかりません。彼女は、新しい男がたくさんの新しいアイデアを持ち込んで物事をかき混ぜることに脅威を感じているのだと思います。私は以前、物事に新しい視点をもたらす新しい人としてそのような状況に陥ったことがありますが、既存の人々にすぐに新しい考え方をもたらすのは難しい場合があります。多くの場合、文化の変化が必要ですが、それは一夜にして起こるものではありません。

物事についてできるだけ彼女の意見や意見を得るようにし、彼女があなたよりも長くチームに在籍していることを尊重していることを示すようにしてください。しばらく経っても彼女が参加しない場合は、マネージャーにその旨を伝え、そこから参加してもらうしかありません。

他の開発者を巻き込む努力を続けてください。この変化を起こしたいのはあなた自身であることを忘れないでください。抱えている問題について助けを求めてください。毎日のスタンドアップミーティングに招待してください。私は現在、毎日のスタンドアップの計画を立てており、すべての豚と鶏が招待されていることを確認しています。あなたがプロジェクトのリーダーである場合、状況に対処し、リスクを負うかどうかはあなた次第です。自分自身をそこに置いてください。

ライセンス: CC-BY-SA帰属
所属していません StackOverflow
scroll top