25

ここでは私は例外かもしれませんが、3 人以上の開発者または 5 人以上のチームで働いたことはありません。それでも、なんとか仕事をやり遂げることができました（何とか）。

この「極端な」シナリオに適合するソフトウェア開発プロセスはありますか? また、スタンドアロンのプログラマーとして働いている場合、日常生活をより予測可能にし、一貫性を持たせ、文書化し、仕事を終わらせるために日常生活に適応できるものはありますか?

4

8 に答える 8

23

アジャイル方法論は良い出発点です。私見ですが、アジャイル方法論は小さなグループにより適しているからです。

個人的な作業ペースを維持するには、TODO リストとTask2Gatherのようなツールに基づく方法をお勧めします。GTDも参照してください。

私のチームであっても決してあきらめないこと：

  • ソースのバージョン管理
  • バックアップ
  • TODO
  • 単体テスト/ TDD
  • コードのドキュメント
  • リファクタリング/コードレビュー
于 2008-10-03T10:26:23.987 に答える
6

強力なSecretGeeekがスタンドアロン プログラマーになる方法を教えてくれます。楽しみ ：）

   intellisense 
        ||
        \/
       code >>> compile >>>>> run >>>> success >>>> profit ;-)
        /\         ||          ||         
        ^^         \/          \/
        ^^      errors       errors 
        ^^          \\       //
        ^^           \\     //
        ^^             google
        ^^              ||
        \\              \/
         \<<<<<<<  copy N paste
于 2009-02-28T21:15:10.783 に答える
5

TODO主導の開発

SecretGeekからの重大な提案。

TODO タグを含むすべての行を自動的に一覧表示するように開発環境またはエディターを設定します。Visual Studio は既定でこれを行います。

ステップ1

  • クラスまたはメソッドのアウトラインを記述します (つまり、コードを含まない「Public Class ...」または「Public Sub...」)。
  • 大まかなロジックを含める
  • 「TODO:」を前に付けた疑似コードを追加します。
  • 非常に簡単なコードのみを記述します。それ以外は TODO を追加するだけです

ステップ2

  • アプリケーション全体がラフアウトされるまで、手順 1 を繰り返します
  • 「TODO」タスクの大きなリストができました
  • 完全性をチェックする（幅）
  • 削除できるものを参照してください。
  • 単純化できるものを参照してください (例: 2 つの類似した todo コメント: それらを同一にできますか?

ステップ 3

  • TODO を存在しないクラスやメソッドなどの呼び出しに置き換えます (テスト駆動型開発の場合は、これらのメソッド/クラスごとに徹底的なテストを作成します)。

ステップ 4

  • 次の方法で、一度に 1 つのコンパイル エラーを修正します。
    • クラス、メソッドなどのシェルを書く
    • TODO: 疑似コードをそれぞれに追加します。
    • (時間がない場合は、必要に応じて「HACK:」コメントと説明も追加してください)
    • 必要に応じて、TODO を必要な簡単なコードに置き換えます。

ステップ 5

  • コンパイル エラーがなくなるまで、手順 4 を繰り返します。
  • TODO が残っている場合は、手順 3 に戻ります。

(事前の計画、紙のプロトタイピング、顧客とのミーティング、議論、先延ばし、データベース設計、コーヒーを飲む、sproc と crud-sproc 呼び出しのコード生成、再利用可能な DAL のインポート、PAG ブロックの使用、go PAG もたくさんあります。 !、ドキュメントのサインオフ前の議論、議論、深夜、フラストレーション、友人とのおしゃべり、電子メールのふるい分け、visio でのスクラッチ、印刷物を山積みにする、ステープルを探す、捕まえるバス、背中と首のストレッチなどを行いますが、簡単にするためにすべて省略しています...)

(MarkJ 再び) Code Completeの疑似コード プログラミング プロセスに少し似ています。そして、誰もが Code Complete を読むべきであることに同意しますよね?

于 2009-02-28T21:26:05.407 に答える
4

アジャイル方法論のほとんどは、あなたのプロファイルに適合します。

現在最も人気があるのはSCRUMです。小規模なチームでの生産性を高めるように設計されており、ファンは開発時間が従来のウォーターフォール方式よりも 5 ～ 10 倍優れていると主張しています。

読み始めたい場合は、 Headfirst Software Developmentの本をお勧めします。

于 2008-10-03T10:30:59.250 に答える
4

クリスタルクリア法がおすすめ

七つの財産

  • タイムボックス化されたイテレーションを使用した頻繁な配信/統合
  • 反省と改善、批判と修正
  • 浸透型（受動的）な知識の獲得と、オフィス組織とオープンチャネルを通じたコミュニケーション
  • 個人の安全、正直に言って安全、法廷での批判に対する自信
  • 集中力を維持し、タスクを明確にし、仕事の優先順位をつけ、仕事量を制限する
  • エキスパート ユーザーへのアクセス、迅速で質の高いフィードバック
  • 通常のアジャイル関連: 自動テスト、CM、継続的インテグレーション
于 2008-10-03T10:43:40.330 に答える
2

開発プロセスは基本的に大規模なチーム向けに作成され、混乱を回避します。自分で大規模なプロジェクトを実行しようとしている場合、時間内に必要なものを達成するには多数が必要になるため、どのような開発プロセスを使用しても失敗します。

小規模なプロジェクトで作業する場合は、どのアジャイル メソッドでもかまいません。GTD はメソッドではありません。メソッド志望です。それは私の脳のプロセスの特許を取っているようなものです。

于 2009-10-20T08:49:51.993 に答える
1

継続的インテグレーションは、私が取り組んでいるチームで常に最初にセットアップしようとします。これは、優れた開発プラクティスの基盤であると信じているためです。つまり、頻繁に統合、自動ビルド/リリース、自己テストビルド、誰でも簡単に最新情報を入手できます。

詳細については、http： //martinfowler.com/articles/continuousIntegration.htmlをご覧ください。

于 2009-10-20T10:10:18.433 に答える
1

あなたの質問に対する直接的な回答ではありませんが、Steve McConnell はLess is Moreという記事を 10 年以上前に書いており、小さなチームのほうが生産性が高い理由について述べています。

于 2009-10-20T10:05:55.287 に答える