スクラムはアクティブな開発者をパッシブな開発者に変えますか？

私は3人の開発者と1人のデザイナーのチームで働くWeb開発者です。アジャイルスクラムソフトウェア開発方法論を実装したのは、約5か月です。しかし、私はこのサイトで共有したかっただけの奇妙な気持ちを持っています。

人間の生活における重要な要素の1つは、意思決定プロセスです。ただし、意思決定には大きな違いがあります。一部の決定は内部または外部の力の結果にすぎませんが、他の決定は完全にあなたの自由意志に基づいており、一部の決定は単なる中間的なものです。意思決定の自由度が高いほど、仕事はより自己主導的になります。これがルールのようです。私たちは自分自身の人生を形作る傾向があるからです。

あなたが何をするかを決めるか、何をするかを言われるかには大きな違いがあります。

スクラムの前に、開発、分析、実装の優先順位付けなどに関連する決定をより自由に行えるようになりました。自分がやっていることを決定しているように感じました。

ただし、スクラム方法論により、多くの決定は製品所有者から単純に下されます。彼はPBIを優先し、ソフトウェアがどのように動作するか、時にはUIと機能をどのように実装するかを分析します。これはスクラム方法論の一部であることを知っています。また、これにより将来的に製品の売り上げが向上する可能性があることも知っています。しかし、私は今、何かをすることを決心するのではなく、常に何かをするように言われているように感じています。この症候群により、私は仕事に対してより受動的になりました。

1. より良いソリューション、アプローチ、またはテクニックを見つけるために、検索回数を減らす傾向がある
2. 楽しい仕事ができると期待して朝目が覚めない。むしろ、生きるために働くことを余儀なくされるような気がします
3. 仕事の後、自分の趣味のプロジェクトに取り組みたいと思っています
4. より高い技術レベルに到達するためにチームをプッシュすることはもうありません
5. 夕食やお茶の時間に今より多くの時間を費やしているので、仕事に戻る意欲があまりない
6. 私は家に帰ることができるように、仕事をもっと早く終わらせたいと思っています

大きな問題は、同僚でもこの動作を確認して診断することです。それはスクラムの結果ですか？スクラムは、開発チームに、ソフトウェア全体の形成に関与していないように感じさせ、プロジェクトを受動的にさせますか？どうすればこの気持ちを克服できますか？

しかし、私は今、何かをすることを決心するのではなく、常に何かをするように言われているように感じています。

これは、何かがレールから外れたことを示す深刻な指標です。アジャイルプロジェクトはこのように感じるべきではありません。「プロセスを超えた人々」のレトリックには、「人々に嫌悪感を与えることを強制しない」ことが含まれるべきです。ここにいくつかのアイデアがあります：

あなたは「スクラムが」やっていますか？つまり、一部はスクラム、一部は他のことです。（つまり、「私たちはスクラムを行っていますが、すべてのストーリーは製品所有者ではなくPMOからのものでなければなりません。」）最近、多くのクレイジーながらくたがスクラムと呼ばれています。

あなたは、個人的に、あなたがいるべきプロセスに関与していませんか？私は多くの人々が物語の内容に腹を立てていることを知っていましたが、物語がスプリントのバックログに載って初めて関与することがわかりました。ストーリーの開発の早い段階でプロダクトオーナーと話し合い、フィードバックを受け取ります（POとして最終決定権がありますが、それは彼らが一人でやらなければならないという意味ではありません）。

スクラムでは、チームがプロセスを所有することになっており、チームのニーズに合わせてプロセスが時間とともに変化することが予想されます。振り返りで懸念を表明してください。提案するプロセス調整を考え出すことができれば、それはいくつかのチームのために販売しやすくする傾向があります。

あなたの問題はスクラムではありません（そして、Jarrod Robersonがコメントで述べたように、それはあなたが説明しているスクラムではありません）-それはプロダクトオーナーのマイクロマネジメントであり、あなた（そしてチーム）の自己主張の欠如です。

「しかし、スクラム方法論により、現在多くの決定は単に製品所有者からのものです。彼はPBIを優先し、ソフトウェアの動作方法を分析します。UIと機能の実装方法も分析します。これはスクラム方法論の一部です。」

あなたは間違っています。スクラムのウィキペディアページを簡単に見ると、「チーム、実際の分析、設計、実装、テストなどを行う部門を超えたグループ」がわかります。見る？プロダクトオーナーが何をすべきかを教えてくれますが、その方法を決定するのはチーム次第です。

あなたは実装の責任者なので、アプリケーションの実装方法を決定する必要があります。プロダクトオーナーの意見に耳を傾けますが、最終的な決定はあなた（またはチーム）に任されています。

BTW micromanagement は、アクティブな開発者をパッシブな開発者に変えます。

あなたが説明しているのはスクラムではありません

あなたの製品の所有者は、技術的にあなたの仕事をする方法を教えているなら、彼の限界を超えています。それはSCRUMが何についてであるかではありません。

SCRUMは開発問題に集中するために、開発者を解放し、についてです力づける彼らは物事を取るどのくらいそれらを行う方法を決定する電荷を取ります。

SCRUMは、すべてのステークホルダー間のコラボレーションを促進するためのスプリント計画会議の目的であるコラボレーションに関するものです。製品所有者、開発者、およびテスト。

はい、製品所有者は機能、顧客のニーズに応じて最初に提供する必要があるものに優先順位を付ける必要がありますが、開発者は製品所有者ではなくエンジニアリングと設計を行う必要があります。

顧客と連携して機能し、顧客と直接機能をハッシュ化するように特別にタスクとトレーニングを受けていない限り、開発者がGUIとワークフローを設計する必要があることに同意しません。プログラマーが作成したGUIは、顧客のニーズを満たすことはほとんどありません。

SCRUMは、アジャイルマニフェストに対して予測可能かつ反復可能な軽量プロセスを配置することです。

非常に良いものがこのように倒錯しているという話を聞くのは悲しい。

私はスクラムの前に、誰もが望んだことをやっただけだと思っています：yippee ki-yay mf'er。あなたのユーザーはあなたの恩人であり、彼らは物語を推進し、請求書を支払います。製品の所有者は、ストーリーが完成するようにします。どういうわけか、あなたのグループは、プロダクトオーナーがプログラミングの方法を教えてくれるべきだという結論に達しました。

あなたはコードを書くか、あなたがクールだと思うきちんとした小さなアプリを作りたいですか？「Bではなく機能Aを最初に実行したいので、選択の自由を維持できます。」新しい開発方法論ではなく、別の恩恵を見つけます。

あなたはプロジェクトオーナーのタイトルか何かに追いついています。ストーリーに同意しない正当な理由がある場合は、何か言って、主張して​​ください。常に勝つとは限りません。ユーザーに戻って、リクエストに有効な問題があることを知らせるのが彼らの仕事です。バックアップ、データの損失、またはダウンタイムなしで、1日を通してデータベースをランダムに削除するようにストーリーから求められた場合、問題があり、ストーリーをまっすぐにする義務があります。

アジャイルへの冒険はスクラムによって破壊されたようです。すべてのアジャイル方法論の中で、スクラムが最もアジャイルでないことがわかりました。ミニチュアの滝や追加のプロジェクト管理に似ています。これは、もちろん、それらの厄介な開発者からコントロールを取り戻していると感じる経営者に最も好まれますが、もちろんあなたは状況の現実を見ます。

アジャイルは規定された道に従うことではなく、生産性と意欲を高めるように設計されています。プロセスではない人はマニフェスト（言い換え）を言い、それはあなたが使用しているシステムでは失われます。

それを変更してください。それを経営陣に持ち込み、それは逆行性のステップであり、あなたの生産性は以前よりも低く、あなたはその方法にすべて不満だと言います。アジャイルマニフェスト（およびその邪悪な双子）を表示し、この実験から教訓を学んだだけでなく、そこから良い部分を進化させて、より良いシステム（以前と同じように機能するように見える）にしたいことを示しますあなたのために）。

単にあなたたちはより多くの所有権を持つことに慣れていると思う-そして私はそれを好むと思う誰もが、その人間性。

残念なことに、多くのソフトウェアは、クライアントよりも開発者向けに書かれていることが多いため、多くのソフトウェアはそれよりも少ないと思います。あなたの新しいアプローチはそれを減らすべきですが、あなたの所有感を犠牲にします。

物事をより良くしたり、もっと楽しくしたりすることを提案する方法はわかりませんが、それは素晴らしい質問であり、非常に優れた洞察です。

「--role--として、私は--goal / desire--が--benefit--として」という形でユーザーストーリーを取得していますか？プロダクトオーナーが設計作業を行うことを望んでいるように聞こえますが、それを行うのに最適な人ではない可能性があります。ユーザーストーリーパターンを使用すると、プロダクトオーナーがビジネスの利益にこだわり、ソフトウェア開発がソフトウェア開発者によって行われていることを確認できます。

スクラムでは、開発者が貢献し、新機能、UI、使いやすさについてアドバイスを与えるための十分なスペースがあります...ビジネスマンと開発者の間のコラボレーションと会話はスクラムで必要であり、それが可能になります。ただし、最終的には製品所有者が最終決定権を持ちます。なぜなら、彼は、スプリント後のスプリント（つまりROI）のソフトウェア増分のビジネス価値を最大化する責任があるからです。

アジャイル宣言から：

私たちの最優先事項は、貴重なソフトウェアを早期かつ継続的に提供することで顧客を満足させることです。

ただし、UIと機能をどのように実装する必要があるかを伝える製品所有者は受け入れられません。その場合、あなたはので、最終決定権を持つべきであるあなたは、あなたが作るソフトウェアの内部品質に責任があります。

たぶん、プログラマーが望む機能を自由に実装できる開発者が作成した会社で働いているかもしれません。ただし、ほとんどのアジャイル手法では、ビジネスドメインの人々と、ほとんどの場所で最も一般的な作業部門であるソフトウェア（開発者、テスターなど）の作成を担当するチームを明確に分離しています。私の仮定が正しければ、「全体像に影響を与える」ことはもうできないというあなたの気持ちは理解できますが、会社の成長とともに、スクラムであろうとなかろうと思います。

あなたが言及する分析、設計、およびその他のメタ開発活動（これはプロダクトオーナーが行うことは想定されていません）に関して、アジャイルチームは機能横断的かつサイロフリーであると考えられています。特定の開発活動に関するすべての知識を持っている人はいないため、「コードモンキー」ではなく、そこで多様化する機会があるかもしれません。

それどころか、製品の所有者に機能に関する決定を下すことで、品質の高いコードの作成により多くの時間を費やすことができることがわかりました。加えて、有効な懸念がある場合、私はいつでも製品所有者の決定に疑問を投げかけることができ、それは通常実りある議論につながります。

ここでスクラムを練習します。2週間に1回の計画会議を開催し、現在のビジネスの優先順位、および前回のスプリントの成功と失敗をフィードし、チームとして次のスプリントに取り組む内容を決定します。

これを行う方法の1つは、ボード上のバックログを複雑度によって垂直に、ビジネスの優先度を水平にソートすることです。その後、プロダクトオーナーが入力を行ったので、何をしたいかを決めるのはチーム次第です。明らかに、複雑さの低い優先度の低いタスクを選択することは嫌われますが、私たちはこれをチームとして決定しています。それは計画セッションをより長くしますが、それは価値があり、アジャイルプロセスの中核部分です。

また、場合によってはマイクロ管理がありますが、それは別の問題です。

あなたが説明している本当の問題は、チームが方法論を採用するときの一般的な病理学です。彼らは脳をオフにします。これは、新しい学校のアジャイルシステムでも、古い学校のヘビーウェイトシステムの場合と同じです。

Q：方法論はxを規定していますが、xはうまく機能していません。私たちは何をすべき？

A：xの実装を改良します。たぶんそれを完全にやめる。方法論はあなたの上司ではありません！

この特定のケースでは、製品の所有者がやりすぎている可能性があります。そのことについて彼と話をしてもいいですか？「スクラムをしている」のでなければ、その会話をするのは快適ですか？製品所有者が建設的なフィードバックに敏感でない場合、それは方法論の問題ではなく、製品所有者の問題です。

しばらくの間、より多くの滝があったので、私はスクラム全体と実際には調和していません。

しかし、正直なところ、これはプロジェクト管理手法の問題というよりも、管理人員の問題のように聞こえます。技術ベースよりも多くの人がベースになっています。

自己組織化チームでのリーダーの役割は、あなたの投稿から欠落していると思われる何かに関するブログ投稿になります。スプリントで行われる作業を決定するチームはどこですか？チームはプロセスと作業の所有権をどこに持っていますか？スクラムを知っている人がいますか？

私はスクラムで同じ経験をし、それを「物語の専制」と呼んでいます。

私の経験からすると、開発者はクリエイティブ/デザイン/フロントエンドの方がバックエンドの作業に携わる人々よりも苦しんでいるようです。

私がこれまでに見つけた唯一の方法は、スクラムを捨てることです-多くの場合、不可能であるか、または適切であるために適切でないか、または開発者に「あなた」以外の創造的なアウトレットを提供するGoogleの20％のようなものを導入することですログインページの実装方法を自由に選択できます。実際には、既存のコードやシステムアーキテクチャに制約されているわけではないため、「a for and a whileループ」から選択する自由を考慮しない限り、自由。

あなたが何をするかを決めるか、何をするかを言われるかには大きな違いがあります。

私の経験では、何をすべきかを言われてから何をすべきかを決定するまでには、かなり長い道のりがあります。

この方法の終わりには、彼らが権力を好むからではなく、彼らがやるべきことは何もないからではない、ということが一般に判明します。まったく逆に、この方法の最後に-彼らは私たちのチームに十分な自信を得ると-彼らは安心し、私たちが扱うことができる限り多くのコントロールを喜んで渡しますそれ以上）

ああ、私の経験では、これは基本的にスクラム/アジャイルとは関係ありません。スクラム、反復、滝など、何でも起こりました。信頼の問題は、プロセスに依存しないようです

私たちのチームでは、製品の所有者が何をすべきかを私たちに教え、私たちはそれをどうするかを決めます。この分離を行うことは本当に重要です。さもないと、説明した状況になってしまいます。

私の経験では、スクラムはあなたが何をしているかを深く見守ることです。それはただあなたの肩の上に座って、あなたが何をするかを見ているだけです。独自の利点がありますが、スクラム方法論は嫌いです。品質ではなくカウントが期待されます。スクラム方法論により品質が低下しています。