アジャイルは開発者に実際の作業により多くの時間を費やすことを強制しますか？

一般的なアジャイルのプラクティスを見ると、彼らは（意図的または意図せずに）開発者にブログ/記事の閲覧、チャット、コーヒーブレイク、単なる先延ばしとは対照的に、実際により多くの時間を費やすように思われます。

特に：

1）ペアプログラミング-最大のワークフォーサー。2人が一緒に座っているときに先延ばしをするのは不便だからです。

2）短編小説-1か月などで行う必要のある大量の作業がある場合、最初の3週間で緩み、最後の1週間はOMG DEADLINEモードに切り替えるのが一般的です。

そして、小さなチャンク（1日以内に行う必要があります）では正反対です-時間はきついと感じ、操縦するスペースがなく、すぐにタスクの責任を負うことになりますので、開始しますすぐに動作します。

3）チームのコミュニケーションと結束-ゆっくり、遠く離れた静かな環境でパフォーマンスを下回っていても大丈夫だと感じるかもしれませんが、スクラムミーティングで一日の終わりに誰もが達成したことを誇り、実際に感じるかもしれないと言うことはありません恥ずかしい。

4）テストとフィードバック-再び、締め切りが突然発生するまで、タスクを「99％準備完了」（実際には20％程度）に保つことを防ぎます。

アジャイルのもとでは、「従来の」方法論よりも仕事をしていると感じますか？この圧力は、より快適な環境と、実際に正しいことを迅速に実行できるという感覚によって補われていますか？

アジャイルメソッドの背後にある主なアイデアは、生産性を高めることです-ポジティブな意味で。締め切りに間に合った場合、毎日1時間サーフィンをしていても、誰も気にしません。毎日30時間サーフィンするのに締め切りに間に合わないと、みんな怒ってしまいます。解決策：締め切りに間に合わせるのを簡単にします。

お気づきのとおり、ペアプログラミングを使用すると、集中力を維持できます（スキル/知識の普及、コードの改善、バグの減少、デザインの統一など、他のすべての利点の中でも特に）。

私にとって、規律は常に闘争であることがわかりました。私が誰かとペアになった場合、私たちのうちの1人が今日何らかの仕事をしたいと望み、もう1人を引き寄せることができます。そのため、「1か月の作業」は「1週間の共同作業」に変わることが多く、その膨大な量の作業が最終的に解決し、1日かそこらの回復（リファクタリング、コード内のTODOの修正、いくつかのテスト、明確な良心でのサーフィン）、そして翌月の仕事を手に入れました。

最終的な結果：私ははるかにリラックスしています（絶え間ない監督にもかかわらず、チームの結束がはるかに優れているため、作業がより迅速に行われ、人々はいくつかの小さな問題を数時間または数日間もぶらつくことはありませんより迅速に問題を見つけます）。

「実際に恥ずかしい思いをするかもしれません」と言うとき、それは良いことではありませんか？それは、あなたが間違ったことをしたと感じ、そうすべきだと感じることを意味しています。あなたは何も成し遂げるために報酬を得ていません。何もしなければ、あなたは無力感、不幸、価値のない、悲惨な気分になります。恥ずかしさを感じるのではなく、立ち止まって「なぜ今日は何も達成できなかったのか」と考えてください。何か手伝いましょうか？分からないことがありますか？現在のタスクは難しいですか？好きじゃない？たぶん、あなたは他の誰かとタスクを切り替えることができます。たぶん他の誰かがあなたを助けてくれるでしょう。アジャイルとは、文字列の操り人形のように細かく管理されるのではなく、責任を負うことです。ツールが必要ですか？あなたの上司に行き、それを求めてください。議論することを学ぶ。立ち上がる必要があるときに叫ぶことを学びます。

テストに関しては、コードが突然「ナイス」から「パーフェクト」に崩壊するスイートスポットがあります。それは、機能Xを実装する必要があることに気づいた瞬間であり、それが悪夢であり、コードがほとんどそこにあることを突然認識すると思ったときです。あちこちでちょっとしたリファクタリング。新しいクラスと完了。4週間の仕事が突然1日になりました。勝利！勝利！

同意する。

ペアプログラミング

非常に熱心で徹底的な作業方法であり、他の開発者から指導を受ける必要のある開発者がいない限り、それを適用することはありません（たとえば、新参者）

短編小説

チームのコミュニケーションと結束

テストとフィードバック

はい、アジャイル、特にスクラムは生産性を大幅に向上させます。正しく適用された場合、売上高は最大20％になります（5人に1人の開発者が退職します）。

理由は簡単です：スクラムは生産性を向上させませんit provides the whole company with much more visibility on what's going on（もちろん、管理を含む）。

• 開発者が最低限のことだけを行うことは不可能になります。最低限のミニマムがチーム平均になりました！

• 管理者が適切に連携しないことは不可能です。

これが、アジャイルがすべての組織（およびすべての人）のためではないことを（同様の質問の他の答えで）私が言った理由です。

たとえば、公共部門は本当にアジャイルに適していません。

アジャイルは圧力ツールとして使用されていますか？もちろん、私は何度も見ました。事態がさら​​に悪化するだけです。

アジャイルのもとでは、「従来の」方法論よりも仕事をしていると感じますか？この圧力は、より快適な環境と、実際に正しいことを迅速に実行できるという感覚によって補われていますか？

それは私をもっと働かせますが、何よりも、私は正しいことを働かせます。いつでも私は私が何をしなければならないかを知っています。

それは一種の正の圧力です。それは、外部の「あなたはすでに予定より遅れており、より多くの仕事をし、コードの残業をしている！」とはまったく異なります。-種類の圧力。

実際、従来の方法を使用すると、生産性が大幅に向上します。従来の方法では、詳細な要件分析、実現可能性調査、機能仕様、技術仕様、および多くの会議プロトコルをすべて数か月以内に作成します。影響分析が完了したら、数行のコードを作成することもあります！

アジャイル、私が作成するすべては、いくつかの成果物です。

当社では、

ペアプログラミング-本当に複雑で広範な分析が必要な場合、2人の優秀な人材を集めて、短時間でタスクを完了します。ここでは、タスクの複雑さがペアプログラミングの必要性を決定します。

短編小説-その後、開発者として3週間（1日あたり約5〜6時間）怠け、最後の瞬間（1日あたり約12〜14時間）に急ぎます。1日約8時間働き、スケジュールを安定させてください。これは常にCOOLに見えます。

チームのコミュニケーションと結束-スクラム会議では、タスクのステータスだけでなく障害も共有します。ここで誰かが本当に助けを必要としているとき、他のメンバーは彼を助けるために彼らのアイデアを実際に思いつきます。しかし、確かにこれには優れたチームが必要です。私たちは:)

テストとフィードバック-確かに開発者として、バグを見つけた後の次の瞬間にバグを修正することで、最後にバグに悩まされることを望みません。次に行われ、それに応じて期限（必要な場合）を再スケジュールします。

ですから、開発者として、私は自分がとる仕事にとても満足しており、実際に期限のプレッシャーを感じたことはないと言うことができます。

アジャイルのもとでは、「従来の」方法論よりも仕事をしていると感じますか？

• もしあなたがアジャイルの下でより生産的だと思うのであれば、それは依存していると思います。
   
  _{私は通常、フェラーリ（従来）とランドローバー（スクラム）の観点から考えています。高速道路で運転するとき、フェラーリはランドローバーから地獄を打ちます。
   
  スポーツカーではなくジープが必要な場合はオフロードです-要件が不規則であるか、チームワークと管理経験がそれほど良くない場合は、スクラムを選択する必要がありますあなたが立ち往生-フェラーリがオフロードで立ち往生するように。}

「仕事より」、よく私はその可能性が過小評価プログラマのIQとの様々な形に適応する能力のようなものを期待ものだと思う管理認知症を。

これまで、私は2つのスクラムチームに参加し、異なる企業でまったく異なるプロジェクトを作成しました。両方のチームで、たとえば滝/反復と比較して、習慣に変化は見られませんでした。

これは私がとても特別で無敵だからだと主張できることを誇りに思いますが、率直に言って、チームの他のすべての男たちも無敵だという習慣を見てきました。

アジャイル開発では、アジャイル開発のさまざまな手法により、忙しい作業や必要のない作業が排除されるため、アジャイルはより有用な作業を強制します。

二人が一緒に座っているときに先延ばしをするのは不便です。

同意しません。私は喫煙者のグループと仕事をしましたが、「誰もがやっていた」ので、彼らは皆、長期間一緒に休憩を取ることができました。

最初の3週間で緩むのが一般的

これは、方法論に関係なく、不十分な管理の兆候です。1か月以内に大きなチャンクが予定されている場合でも、最初の週の終わりに何かが表示されることを期待しています。

あなたが実際に恥ずかしいと感じるかもしれないと言うことは何もありません。

あなたが3週間ジャークオフしたいなら、あなたは言うべきでたらめを考えるでしょう。

4）テストとフィードバック-再び、締め切りが突然発生するまで、タスクを「99％準備完了」（実際には20％程度）に保つことを防ぎます。

ウォーターフォールプロジェクトには、テストと毎日のビルドがあります。

個人的には、私はコードを書くのが嫌いで、1か月間何もしません。コード化されたレビューであれ、ユーザーのサインオフであれ、コードのフィードバックループを短くすることを好みます。他の人に私の仕事を承認してもらうことはやりがいがあります。それはちょうどあなたが彼女が彼女の仕事をしていることをあなたに知らせるためにあなたの玄関口でマウスをドロップする猫のようなものです。

アジャイルは開発者の仕事を増やすことを強制しませんが、より効率的に仕事をします

「開発者をもっと働かせる」という質問に否定的な印象を与えますが、実際にもっと多くのことをし、先延ばしを少なくすれば、確かに肯定的でしょうか？

とはいえ、それは良い点です。今年はアジャイルに少しうんざりしていましたが、これは筆者が認めていない大きな書面によるメリットです。

アジャイルは開発者の生産性を高めることに同意します。可視性、説明責任、先延ばしの傾向に関するあなたのポイントはすべて非常に真実です。

しかし、アジャイルは、ポジティブな理由で開発者をより熱心に働かせることができますし、またそうすべきです-ニンジン対スティック。アジャイルがうまくいけば、開発者はユーザーとより多くのやり取りができるようになります。

より多くの作業がまだ意味的に正しくないか、アジャイルに関連していない場合、目標は生産性を高めることです。具体的には、間違ったことにあまり取り組むのではなく、正しいことを普通に行うことに重点を置いています。これはもっと働くことを意味するものではなく、より生産的になるものです。

副作用として、怠け者や非効率的または能力のない怠け者を非常に迅速に露出させます。それはあなたが得ているもののように聞こえます。

方法論は、開発者が働いていないかどうかには関係ありません。プロセスは、ウォーターフォールでも、ほとんどのアジャイル方法論ほど透過的ではなく、管理レビューとコードレビューはこれらを実行することもできます。

「銃は人を殺さない。人は人を殺す！」アジャイルでも同じです。アジャイルは人々をより働かせるものではなく、マネージャーは人々をより働かせます。