アジャイル方法論が嫌いな場合、私はプログラマを悪くしますか？[閉まっている]

小さなイテレーションが好きです。単体テストが好きです。コードレビューが好きです。私が気に入らないのは、ドキュメントがほとんどないかまったくないところから始めることです。私はこれで一人ですか？プロセスについて誤解しているだけですか？

どんな考えでもいただければ幸いです。

覚えておいてください。アジャイルはドキュメントがないことを意味するのではなく、アジャイルは「クライアント」が欲しいものすべてを知らないことを理解しているため、すべてを概説する巨大な要件ドキュメントを提供できないことを意味します。アジャイルは、常にクライアントと話し、「これがあなたの望みですか」と言うことを提唱しています。または「Yが発生したときにXはどのように機能しますか？」一緒に要件を作成します。

とはいえ、特定の方法論が気に入らなければ、何も問題はありません。とにかく、ほとんどの人は異なる方法論のさまざまな側面を選んで選択しているようです。

アジャイル方法論では、その時点で必要なことだけを行うとしています。与えられているよりも多くのドキュメントが必要/必要な場合、それはプロセスの問題であり、それはあなたではありません。プロジェクトを続行するには、多くのドキュメントが必要になる場合があります。これを必要とすることはアジャイルに反しません。アジャイルを装って要件を緩めることは正当化できません。これは実際に私が見た大きな問題です。多くの人々は前もって怠惰になり、それをプロセスに振り向けます。本当の質問は、「開発者は必要なものを持っているか？」答えが「いいえ」の場合、さらに作業を行う必要があります。

これは極端になり、誰かが「プログラム全体が文書化されていなければ、私はそれに取り組むことができません」と言うことができます。時々これは本当ですが、チームはこれを本当に見て、これが本当に必要かどうかを確認する必要があります。

特定の方法論が気に入らないからといって、なぜあなたが悪いプログラマになるのかはわかりません。それを実装するショップとの統合が難しくなる場合があります。言われていることは、それがどこにでも効果的に実装されているかについていくつか疑問があります。

あなたを悪いプログラマーにするのは悪いコードです-簡単なことですが-あなたは好きな方法で好き/優秀であり、コードが適切でないので悪いプログラマーであり続けることができます。

アジャイルの基本的な考え方は、予知の才能がない限り、遠い将来を予測することはできないということです。したがって、予測できないことを文書化することはできません。

これは、ドキュメントがまったくないという意味ではありません。現在の要件の技術設計を文書化し（そしてもちろん、要件自体を文書化し）、現在の実装を文書化します。ダイナミックな世界に住んでいるため、要件が変わる可能性があるため、システムがさらに10回のスプリントをどのように処理するかを文書化することは期待されていません。

プロセスを誤解していると思います。どのドキュメントが必要ですか？始める前に、ある種の目標が必要です。まず、顧客との会話から収集したユースケースから始めます。派手な図を作るのに何日も費やしません。話をしてからWikiページを書いて、それについて説明します。次に、いくつかのテストを記述します。次に、コードを記述します。

チームの規模、ドメイン、言語、性格、予算、要件は無限にあります。あらゆる状況に最適な方法論はありません。同様に、多くの人が個人的な好みやスタイルを持っています。

あなたがそれが気に入らなくても、新しいアイデアを試してみる価値は批判的に結果を分析します。嫌いなことがたくさんありますが、しばらく試してから愛することを学びます。オリーブのように。

もう1つは、ファッションが定期的に変化することです。私はウォーターフォールで育ちましたが、当時は「最良のもの」であったRational Unified Processですべてを実行しようとするチームで働いていました。すぐにアジャイルはより新しくより良いものに置き換えられ、誰も再びアジャイルの言葉に言及しなくなります。

したがって、アジャイルのような1つの方法論を好きになる必要があると感じてはいけません。（私は個人的にそれが好きではありません）それはあなたを悪いプログラマーにするわけではありません。