5

もしそうなら、次のような「気分が良くない」ものにどのように対処しますか?

  • 単体テストを書かない
  • 継続的なビルドがない
  • リファクタリングしない
  • チームのコーディング標準がない
  • ペアプログラミングではない
  • 反復を行わない
  • 毎日のスタンドアップはありません
  • ふりかえりなし

現在、一部のアジャイル組織はこれらのプラクティスの一部を省略していますが、ほとんどの成功した組織にはそれらのほとんどが組み込まれています。

従来の開発プロセスの混乱に対処するために何をしていますか?

4

6 に答える 6

13

実際、私はアジャイル組織のウォーターフォール開発者です。

私にとって正しく「感じない」ものには、次のものがあります。

  • 何をすべきかほとんどわからない状態でプロジェクトの作業を開始します。
  • プロセスを文書化しますが、製品は文書化しません。誰かに相談しないと情報が得られない。必要なのは、要件ドキュメント、設計ドキュメント (自分で作成する場合もあります)、および Google だけです。
  • コーディングよりも会議に多くの時間を費やします。
  • 職場よりも自宅でのコーディングにより多くの時間を費やします。
  • プロジェクトがいつ完了するかわかりません。
  • PMはあらゆる点で役に立ちます。
  • 他の誰かがサーバーにログオンしてファイルをコピーする会議の準備をするための会議の準備をする会議を開催する; したがって、6 分かかるプロセスに 6 時間かかる
  • 複数のチェックアウト
  • 何かがどのように流れるかはわかっているが、実際の要件がない。
  • 開発者の固有のスキルセットは、開発者を交換不可能にするため、軽視されるか、完全に無視されます。
  • 残りのストーリーがなくなったら...何もすることはありません...ただそこに座ってください...新しい機能を追加する可能性があります。必要ないかもしれませんが、時間は無駄ではありません...
  • 半年ごとに契約を変更すると、新しいコーディング標準に適応する必要がありますか? 慣れる頃には、もう次の契約を探しています。
于 2008-10-25T05:54:53.363 に答える
2

これらのプラクティスがウォーターフォールと互換性がないのはなぜですか? 私が知る限り、これらのほとんどすべてが、ウォーターフォール アプローチで可能であるとは限りません。ウォーターフォール開発がカオスでなければならない特別な理由はありません。他にも欠点や課題があるかもしれませんが、カオスがリストの上位にある可能性は低いです。

于 2008-10-25T05:41:30.817 に答える
2

「泣き言」モードに入ることなく..私は質問の「対処」の部分に答えることにします。私の経験から、次のオプションに到達しました

  1. やや簡単な方法: やめて、もっと自分の好みに合った場所を見つけてください。雑多な理由でやや簡単だと言います。サブ問題: 「機敏な」職場がすぐ近くに存在しない可能性があります。移転は実行可能なアプローチではない可能性があります。機敏な職場の人々は「非機敏」である可能性があります。
  2. 中間の道: 個人的にアジャイルであり続ける。興味のある人を助け、教えてください..多分組織。ゆっくりと良い方向に変化していきます..最善を望み、「ノーリターンの終了点」に達しないことを祈ります.
  3. 非常に難しい方法: 組織に変化をもたらすよう努めます。これは万人のお茶ではありません。組織の文化は一朝一夕に変えられるものではありません。実質的な何かを始めるには、経営陣に「ローカル スポンサー」が必要です。それを、自分以外の人を本当に変えることはできないという事実と結び付けてください。ですから、あなたが情熱的で、忍耐強く、執拗で、非常に楽観的で、それをやり遂げる気があるなら、心から「 Fearless Change 」をお勧めします. （出典：informit.com）
    代替テキスト
于 2008-10-25T06:29:35.057 に答える
1

まず、アジャイル方法論はこれらのプラクティスを強調していますが、導入していません。これらは、アジャイルが登場するずっと前からソフトウェア開発プロセスに存在していました。したがって、スクラム/XP/RUP を使用していない場合、これらのプラクティスに従っていないと単純に言うのは明らかに間違っています。あなたがプロのソフトウェア開発組織である場合、これらのプラクティスは何らかの形で存在します。

第二に、あなたがウォーターフォール組織のアジャイル開発者であろうと、その逆であろうと、多くのことを行うことはできません。少なくとも、効果的または重要なことはできません。組織がどのような開発「文化」を持っているかは、経営陣と幹部のコミットメントと焦点の機能です。それが存在しない場合は、「ビット」を実行できますが、最終的には負けます。これが、多くの組織がアジャイルに移行したときに失敗する理由です。なぜなら、彼らは文化を変えたくないからです。

于 2008-10-25T06:20:47.133 に答える
1

私は疑似アジャイル組織に所属しており、あなたが提起した点に対する私の回答は次のとおりです。

  • 単体テストを書かない: 私は 100% のカバレッジを信じています。はい、100% のカバレッジがあり、非常に悪いテストを書くことができると言うのは簡単ですが、私が書いた新しいコードは、受け入れテストまたは統合テストを行い、自分が取り組んでいるものを100% のカバレッジにするために最善を尽くします。ビルドでは、カバレッジ チェックを入れて、現在の制限を下回らないようにしました。
  • 継続的なビルドがない: 誰もが以前に作業した方法のために、ほとんどの人はカバレッジ チェックなしでビルドを実行します。言うまでもなく、継続的なビルドがオンになっているように見えることもあれば、オフになっているように見えることもあります。私は自分のCIボックスをセットアップすることに非常に近づいています。
  • リファクタリングしない: できることは何でもリファクタリングするので、同じクラスをもう一度見たときに吐き気を催すことはありません。
  • チームのコーディング標準がない: 会社にはコーディング標準がありますが、それには多くの問題があります。したがって、私はそれを変えるために上層部に物事を持ち込むために最善を尽くします. 彼らが正しいと思う方法でコーディングすることは、時には苦痛です。たとえば、パブリック、プライベート、プロテクト、フィールド、定数などの巨大な Java コメント セクション ヘッダーをファイル全体に配置します。これは昔々行われたと思います。なぜなら、クラスが制御不能になり (たとえば、何千行もの長さ)、パブリック メソッドの開始場所とプライベート メソッドの開始場所を見つけることができるようにセクション ヘッダーが必要になったからです (!!)
  • ペア プログラミングではありません: 幸いなことに、私の後ろに私のような考えの人が座っていて、椅子を回してできるだけ頻繁にアイデアを話したり話し合ったりして、補うようにしています。
  • イテレーションを行わない: 3 週間のイテレーションがありますが、非常にアドホックに感じます。各イテレーションの間にクリーンアップ/レビューの週があり、理論的には 4 週間のイテレーションになります。私はそれについて他に何もできません。1 週間しかかからないはずのコードを書くのに実際には 3 週間もかかってしまうほどコードがひどいため、反復を短くするよう説得するのは困難です。
  • 毎日のスタンドアップはありません: スタンドアップがあります。
  • ふりかえりなし: ふりかえりがあります。
于 2008-10-25T07:35:56.857 に答える
1

真剣に、あなたの組織があなたの言うようにカオスでアマチュア的であるなら、私は組織が崩壊する前に別の仕事を探し始めるでしょう. マーティン・ファウラーがかつて皮肉ったように

組織を変えられないなら組織を変えろ

一方、変更できると思われる場合は、リストの他の何よりも先にふりかえりを紹介することで、その変更を開始しようとします. 人々が互いに話し、進行中の無駄を特定し始めることができ、関係者がそのフィードバックに耳を傾け、変更を加えるのに十分な権限を持っている場合、たとえ暫定的であっても、正しい方向に進むことができます.

あなたが特定した他のすべてのプラクティスは、特定の種類の無駄を排除するための手法です。たとえば、ユニット テストを記述して、プロジェクトの後半で欠陥を修正する無駄を減らします。ふりかえりを開催することで、これらの無駄に光を当てることができ、人々がより専門的に物事を行いたいと考える余地を与えることができます。

結局のところ、それは自尊心です。つまり、あなた自身、同僚、そして組織全体です。今まで通りのやり方でごちゃごちゃしているだけで満足ですか、それともできる限り上手になりたいですか？

幸運を！

于 2008-11-21T08:45:24.767 に答える