スクラムはアクティブな開発者をパッシブな開発者に変えますか？
私は3人の開発者と1人の設計者のチームで働くWeb開発者です。アジャイルスクラムソフトウェア開発方法論を実装してから約5か月になります。しかし、私はこのサイトで共有したいだけの奇妙な気持ちを持っています。
人間の生活における重要な要素の1つは、意思決定プロセスです。ただし、決定には大きな違いがあります。他の決定は完全にあなたの自由意志に基づいている一方で、いくつかの決定は内的または外的な力の結果に過ぎず、いくつかの決定は単にその中間にあります。意思決定の自由が増すほど、あなたの仕事はより自発的になります。これはルールのようです。私たちは自分自身の生活を形作る傾向があるからです。
何をすべきかを決定する、または何をすべきかを伝えられるの間に大きな違いがあります。
スクラムの前は、開発、分析、実装の優先順位付けなどに関連する決定をより自由に行えるようになりました。/自分がやっていることを決定している。
ただし、スクラム方法論により、現在、多くの決定は単に製品所有者から行われています。彼は PBIs を優先し、ソフトウェアがどのように機能するか、場合によってはUIと機能を実装する方法を分析します。これはスクラム方法論の一部であることを知っています。また、これが将来的に製品の売り上げを向上させる可能性があることも知っています。しかし、何かをすることを決心するのではなく、常に何かをするように言われます。このシンドロームは今、私は仕事に対してより受動的になりました。
- 私はより良い解決策、アプローチ、またはテクニックを見つけるために検索を減らす傾向があります
- 楽しい仕事ができると期待して朝起きない。むしろ、生きるために働かされているような気がする
- 仕事の後で自分の趣味のプロジェクトに取り組むことへの飢えがあります。
- より高い技術レベルに到達するためにチームをこれ以上プッシュしません
- 今はディナーやティータイムに多くの時間を費やしていて、仕事に戻る熱意があまりありません
- 家に帰れるように、もっと早く仕事を終えたいと思っています。
大きな問題は、同僚にもこの行動を見て診断することです。スクラムの結果ですか？スクラムは、開発チームがソフトウェア全体を形成することにまったく関与していないように感じ、プロジェクトを受動的にするのですか？どうすればこの気持ちを克服できますか？
しかし、何かをすることを決心するのではなく、常に何かをするように言われるようになりました。
これは、何かがRailsから削除されたことを示す深刻な指標です。アジャイルプロジェクトはこのように感じるべきではありません。その「プロセス上の人々」のレトリックには、「私たちが人々に強制するようなことを強制することはありません」を含める必要があります。ここにいくつかのアイデアがあります：
「スクラム」やってるの？つまり、一部はスクラムで、その他は一部です。 （つまり、「私たちはスクラムをやっていますが、すべてのストーリーは製品の所有者ではなく、PMOからのものである必要があります。」）最近、多くのクレイジーながらくたがスクラムと呼ばれています。
あなたは個人的に、あるべきプロセスに関与していませんか？ストーリーの内容に腹を立てる人はたくさんいますが、ストーリーがスプリントのバックログにある場合にのみ参加することがわかっています。ストーリーの開発の早い段階で製品の所有者と話し、フィードバックを受け取ります（POとして、彼らは最終的な発言権を持っていますが、それは彼らがそれを単独で行う必要があることを意味しません）。
スクラムでは、チームがプロセスを所有することになっています。プロセスは、チームのニーズに合わせて時間とともに変化することが予想されます。ふりかえりであなたの懸念を呼び起こす。あなたが提案するプロセス微調整を思い付くことができる場合、それはいくつかのチームのために販売しやすくする傾向があります。
あなたの問題はスクラムではありません（そして、Jarrod Robersonがコメントで述べたように、それはあなたが述べているものはスクラムではありません）-それは製品所有者のmicromanagementとあなたの（およびチームの）断定性の欠如。
"しかし、スクラムの方法論により、多くの決定は単に製品の所有者から行われるようになりました。PBIに優先順位を付け、ソフトウェアがどのように機能するか、場合によってはUIと機能をどのように実装するかを分析しています。これはスクラム方法論の一部です。」
あなたは間違っています。 Scrum のウィキペディアページをざっと見ただけで、次のことがわかります。 "チーム、実際の分析、設計を行う部門横断的なグループ、実装、テストなど。」参照してください。プロダクトオーナーは何をするかを指示しますが、それを行う方法を決定するのはチームの責任です。
あなたは実装の責任者なので、アプリケーションの実装方法を決定する必要があります。プロダクトオーナーの意見に耳を傾けますが、最終的な決定はあなた（またはチーム）が行います。
BTWマイクロマネージメントは、アクティブな開発者をパッシブな開発者に変えます。
説明しているのはスクラムではありません
あなたの技術的な仕事のやり方をあなたに言っているなら、あなたの製品の所有者は彼の限界を超えています、それはSCRUMがまったく何についてであるかではありません。
SCRUMは、開発者が開発の問題に集中できるように解放することであり、empowering彼らは、物事にかかる時間とその方法を決定する責任があります。
SCRUMは、すべての利害関係者間のコラボレーションを促進するための、スプリント計画会議の目的であるコラボレーションについてです。製品所有者、開発者、およびテスト。
はい、製品の所有者は機能、つまり顧客のニーズに応じて最初に提供する必要があるものを優先する必要がありますが、開発者は製品の所有者ではなくエンジニアリングと設計を行う必要があります。
開発者がGUIとワークフローを設計する必要があることに同意しません。開発者が顧客と連携して機能を顧客と直接ハッシュするように特別に任務と訓練を受けている場合を除きます。プログラマーがGUIを真空で作成しても、顧客のニーズを満たすことはほとんどありません。
SCRUMは、アジャイルマニフェストに対して予測可能で再現可能な軽量プロセスを適用することを目的としています。
このように非常に良いことが変態になっているという話を聞いて悲しくなります。
アジャイルへの冒険がスクラムによって破壊されたようです。すべてのアジャイル方法論の中で、スクラムは最もアジャイルではないことがわかりました。ミニチュアウォーターフォールや追加のプロジェクト管理に似ています。もちろん、これは、厄介な開発者からコントロールを取り戻していると感じている経営者に最も好かれますが、もちろん、状況の現実がわかります。
アジャイルは規定された道をたどることではなく、あなたの生産性とモチベーションを高めるように設計されています。 プロセスではない人々がマニフェスト（言い換え）を言っています、そしてそれはあなたが使っているシステムで失われています。
だからそれを変更します。それを経営陣に呼び寄せ、それがレトログラードのステップであり、生産性が以前よりも低く、すべてがうまく機能することに不満があると言います。 Agile Manifesto （およびその evil twin ）を示し、この実験から教訓を学んだだけでなく、それからより良いシステムに良いビットを進化させたいことを実証します（あなたが以前持っていたようなもので、あなたにとってはうまくいくように見えます）。
私はスクラムの前に推測していますが、誰もが望んだことをしただけですyippee ki-yay mf'er。あなたのユーザーはあなたの恩人であり、彼らは物語を推進し、代金を支払う。製品の所有者は、ストーリーが確実に完了するようにします。どういうわけか、あなたのグループは、プロダクトオーナーがプログラミングの方法を教えるべきだという結論に達しました。
あなたはコードを書いたり、かっこいいと思う小さなアプリを作りたいですか？ 「機能Bでなく機能Aを最初に実行したいので、選択の自由を維持できます。」新しい開発方法論ではなく、別の恩恵を見つけてください。
あなたはプロジェクトオーナーの肩書きなどに巻き込まれています。話に反対する正当な理由がある場合は、何か言ってみてください。常に勝つとは限りません。ユーザーの元に戻り、リクエストに有効な問題があることをユーザーに知らせるのは彼らの仕事です。それに直面してみましょう。もしバックアップが1日中ランダムにデータベースをドロップするように要求され、データの損失やダウンタイムが発生しない場合、問題を抱えており、ストーリーを正しく設定する義務があります。
私はあなたたちがより多くの所有権を持つことに慣れていると思います-そして私が思うすべての人、それは人間の性質です。
残念ながら、多くのソフトウェアはそれよりも少ないと思います。多くの場合、パーツはクライアントではなく開発者のために書かれているからです。あなたの新しいアプローチはそれを減らすべきです、しかしあなたの所有感を犠牲にして。
私はあなたが物事をより良くしたり、より楽しいものにする方法を提案する方法を知りませんが、それは素晴らしい質問であり、非常に良い洞察です。
ユーザーストーリーを「-ロール-として、-目標/欲望-として-利益-」として得ていますか？あなたのプロダクトオーナーは設計作業をしたいと思っているようですが、彼/彼女はそれを行うのに最適な人ではないかもしれません。ユーザーストーリーパターンを使用すると、プロダクトオーナーがビジネス上の関心にこだわり、ソフトウェア開発がソフトウェア開発者によって行われていることを確認できます。
スクラムには、開発者が貢献し、新機能、UI、使いやすさについて助言を与えるための十分なスペースがあります。スクラムでは、ビジネスマンと開発者の間のコラボレーションと会話が必要であり、それを可能にします。 ただし最後に、製品の所有者は常に最終的な発言権を持ちます。なぜなら、彼はスプリント後に生成されるスプリント（つまり、ROI）のソフトウェア増分のビジネス価値を最大化する責任があるからです。
アジャイル宣言から：
私たちの最優先事項は、貴重なソフトウェアの早期かつ継続的な提供を通じて顧客を満足させることです。
ただし、UIと機能をどのように実装する必要があるかを製品の所有者に告げることは認められません。その場合、youが最終的な発言権を持つ必要がありますyouが作成するソフトウェアの内部品質。
プログラマーが自由に機能を実装できる開発者によって作成された会社で働いているかもしれません。ただし、ほとんどのアジャイル手法では、ビジネスドメインの人々と、ソフトウェアの開発を担当するチーム（開発者、テスター...）を明確に分離しています。これは、ほとんどの場所で最も一般的な作業部門です。私の仮定が正しければ、「全体像に影響を与える」ことができなくなったという気持ちは理解できますが、会社が成長するにつれて、スクラムかどうかにかかわらず、そうであったと思います。
あなたが言及した分析、設計、およびその他のメタ開発活動（これもプロダクトオーナーが行うことは想定されていません）に関して、アジャイルチームは、部門横断的でサイロフリーであると想定されています。 1つの特定の開発活動に関するすべての知識を持っているとは限らないため、「コードモンキー」だけでなく、そこで多様化する機会があるかもしれません。
それどころか、製品の所有者に機能に関する決定をしてもらうと、品質の高いコードを作成するためにより多くの時間を費やすことができることがわかりました。さらに、正当な懸念がある場合は、常に製品所有者の決定に疑問を投げかけることができます。これは通常、実りある議論につながります。
ここではスクラムを練習しています。 2週間に1度の計画会議で、現在のビジネスの優先順位と、前のスプリントの成功と失敗をフィードバックし、次のスプリントに向けて何を取り組みたいかチームとしてを決定します。
これを実行する方法の1つは、ボードのバックログを複雑さを垂直に、ビジネスの優先順位を水平に並べ替えることです。その後、プロダクトオーナーは彼の意見を受け取ったので、私たちが何をしたいかを選ぶのはチーム次第です。明らかに、複雑度が高く優先度の低いタスクを選択することは避けられますが、これはチームとして決定しています。計画セッションは長くなりますが、それだけの価値があり、アジャイルプロセスのコア部分です。
そして、時々マイクロマネージメントがありますが、それは別の問題です。
あなたが説明している本当の問題は、チームがメソドロジを採用するときの一般的な病理です：彼らは彼らの頭をオフにします。これは、古い学校のヘビーウェイトシステムと同様に、新しい学校のアジャイルシステムにも当てはまります。
Q：方法論はxを規定していますが、xはうまく機能していません。私たちは何をすべき？
A：xの実装を改良してください。多分それを完全にやめる。方法論はあなたの上司ではありません！
この特定のケースでは、製品の所有者がやりすぎているように思われます。あなたはそれについて彼と話すのが快適ですか？ 「スクラムをやっていない」のなら、あなたはその会話をするのが快適でしょうか？製品所有者が建設的なフィードバックに敏感ではない場合、それは方法論の問題ではなく、製品所有者の問題です。
しばらくは滝のようになってきたので、私はスクラム全体とはあまり調和していません。
しかし、正直に言うと、これはプロジェクト管理手法の問題というよりは、管理者の問題のように聞こえます。技術ベースよりも人ベースが多いように。
私はスクラムで同じ経験があり、それを「物語の専制政治」と呼びたいです。
私の経験から、クリエイティブ/デザイン/フロントエンド側の開発者は、バックエンド作業に携わる人々よりも、それに苦しんでいるようです。
私がこれまでに見つけた唯一の方法は、スクラムを捨てる（多くの場合、それが利点であるため不可能または適切ではない）か、またはGoogleの20％のようなものを導入して、開発者に「あなた Login Page "の実装方法を自由に選択できます。実際には、実装は既存のコードとシステムアーキテクチャに制約されていないためです。つまり、「a forとwhileループ」は自由です。
自己組織化チームにおけるリーダーの役割 は、あなたの投稿から欠落しているように見える何かについてのブログ投稿になります。チームは、スプリントで実行する作業をどこで決定するのですか？チームはプロセスと作業の所有権をどこに持っていますか？あなたがスクラムをやっているほど十分にスクラムを知っている誰かがいて、変態バージョンのスクラムではありませんか？
私の経験によれば、スクラムはあなたが何をしているかを深く監視することです。それはあなたの肩に座って、あなたが何をしているのかを見ているだけです。独自の利点はありますが、スクラム方法論は嫌いです。品質ではなく、数を期待しています。スクラム方法論によって品質が低下しています。
あなたには大きな違いがあります何をすべきかを決める、または何をすべきかを伝えられる。
私の経験では、かなり長い道のりがありますfrom何をすべきか教えられるto何をすべきかを決める。
この方法の最後に、通常、私たちはそれらがパワーのようではなく、それらのためではなく、 何もすることはありません。まったく逆で、この方法の終わりに-theが私たちのチームに十分な信頼を得るとき-彼らは安心し、幸運にも私たちに多くのコントロールを渡します私たちが処理できるように（そして、彼らの信頼が本当にしっかりしているなら、彼らはそれ以上のものを渡そうとしさえします）
ああ、私の経験では、これは基本的にスクラム/アジャイルとは関係ありません。スクラム、反復、滝など、何でも起こりました。 信頼の問題はプロセスにとらわれないようです
私たちのチームでは、製品の所有者がwhatを行うように指示し、私たちはhowを行うことを決定します。この分離を行うことは本当に重要です。そうしないと、説明したような状況になってしまいます。