5

上司/チームに提示する、簡単に消化できる本を探しています。

背景情報: 職場での会議では、上司/チームが、このあたりでより多くの「ベスト プラクティス」を実装する方法を熟考することがますます多くなっています。(「ここ」 = 非常に小さなアプリケーション開発ショップ。4 人の開発者)

以下は、私のチーム全体が必要だと同意した項目です。

  • 夜間ビルド
  • バグトラッカーの「バグ」をより小さく、より具体的な項目に分解する
  • 自動テスト

私たちが直面している問題は、どのように始めるかです。

私の店が明確で具体的な計画や一連のルールを選択するだけで、他のすべてがうまくいくと信じています. 現在、私たちはあいまいで心地よいアイデアや響きの良い流行語についての議論に行き詰まっています。

TDDまたはアジャイルチーム/ショップを導くための管理スキームを実装するための明確で個別の連続したステップが含まれているお気に入りの本（またはオンラインリソース）を私に勧めてください.

TDD とアジャイル以外にも、これらの懸念に対処するパラダイムがあることは認識していますが、私自身の利益と偏見は TDD とアジャイルに向けられているため、チームの変化への欲求を利用して、その方向に「微調整」したいと考えています。 . または、私の意見に激しく反対する場合は、遠慮なく平手打ちしてください。気分を害することはありません。:)

他の人が述べているように、これらの質問は、回答者が回答ごとに 1 つの推奨書籍のみを挙げた場合に最もよく回答されると思います。

皆さん、ありがとうございました。

4

9 に答える 9

3

ミックスに別のプラグマティック プログラマー タイトルを投入するには: Ship It!

素晴らしい本 - ご覧ください。管理のニーズに合っているかもしれません。

于 2008-10-09T02:45:49.550 に答える
3

あなたのニーズに合わせて、Test Driven Development: By Example (Kent Beck) をお勧めします。それは明確に書かれており、理論よりも実用的であり、アジャイルでテスト駆動型のアプローチを採用するための実績のあるレシピを規定しています。

于 2008-10-08T18:04:58.510 に答える
2

アジャイルメソッドは実際にはメソッドではありません...

もっと精神があります。主なものは以下に焦点を当てています：

  • コミュニケーション

  • 変化に対する反応性

  • 顧客志向

これは多くの方法で達成でき、それを行う方法を見つけることがより重要です。この精神の例が必要な場合は、無料の37signalsのオンラインブックGettingRealを読むことができます。

しかし、あなたが始めることができるいくつかのステップがあります

これらは強制する必要のある大きなルールではありませんが、次のことを試して、チームでどのように機能するかを確認できます。

  • クイックスタンドアップミーティング。毎日5〜15分間のミーティングで、全員が立ち上がって、彼が成し遂げたこと、何をする必要があるか、何が彼のそれを妨げることができるかを説明します。最小限の人数で、15分以内に保管してください。

  • 数週間で大きな目標を設定するのではなく、短期間の期限に単純な目標を設定します。

  • 小さなチーム（3人）を作り、それらの間で作業を分割します。それらを同じ部屋に置き、中断することなく作業するために少なくとも半日があることを確認してください。

  • あなたの顧客との多くの小さな定期的なレビューを設定します。スペックを書かないでください。スケッチ、設計、プロトタイプ作成、顧客への提示、修正/適応/変更、そして構築。その後、もう一度やり直してください。

  • テスト、バージョン管理、バグ追跡はツールであり、メソッドではありません。あなたがそれをどのように行うか、そしてあなたがそれを行う限り、どのソフトウェアでそれを行うかは誰も気にしません。それらは問題ではありません。

于 2008-10-23T12:11:43.990 に答える
2

あなたが同意することから始めることをお勧めします: Nightly Builds と Automated tests. ナイトリービルドは簡単です。自動化されたテストの場合、次から始めます。

  • 新しい機能を含む各コミットには、少なくとも 1 つの自動テストが必要です
  • バグを修正する各コミットには、修正なしで失敗し、修正で成功する少なくとも 1 つの自動テストが必要です。

これを行うと、経験を積み始めます。この経験を積めば、文献にあるすべての良いアドバイスをより簡単に理解できるようになります。

優れた実践に関する優れた本はたくさんありますが、自分のチームにとって何が効果的かを理解する必要があります。

于 2008-10-08T18:56:05.520 に答える
1

これは実際にはステップバイステップの本ではありませんが、優れたアドバイスが満載で、簡単に理解できます。アジャイル開発者の実践。また、社内でTDDトレーニングを受講したい場合は、netobjectivesをお勧めします。私は彼らのTDDコースのものを持っていました、そしてそれは本当に私の目を開きました。

于 2008-10-08T18:38:21.703 に答える
1

マーティ・ケイガンの本をチェックしてください。

于 2014-12-18T22:12:16.673 に答える
1

Henrik Kniberg によるScrum and XP from the Trenches を印刷できます。TDD よりもアジャイル開発プロセスに焦点を当てていますが、簡単ですぐに読むことができます。

于 2008-10-23T11:51:21.537 に答える
1

悲しいことに、最も明確で具体的な計画でさえ、議論の余地があることが判明する可能性があります.

何がうまくいくか教えてあげましょう。すぐに TDD を開始します。境界があります。比較的簡単です。まだ百万の質問があります。

「しかし、ナイトリー ビルドはどうですか?」と言うのは自由です。「バグトラッカーを使うのはどうですか？」

多くの熟考は、2 つのことのいずれかを意味します。

まず、誰かが「懸念」や「疑問」で混乱している可能性があります。時々、これは「懸念」として表明された、変化に対する本当に不快感です。ときどき、これは本当に押しつぶされた自我です (「私は自分はかなり鋭いと思っていましたが、今では誰かが私に改善を課す必要があると言っています」)。

第二に、これはとてつもなく大きいことを意味する可能性があります。したがって、これを「多くの新しいベスト プラクティス」と見なさないでください。これはほんの数個の漸進的な改善と考えてください。自分自身を根本的に変えているわけではありません (そうなる可能性はありますが、それを計画として始めないでください)。

私の経験では、一度にできる新しいことは 1 つだけです。退屈になるまで TDD を実行します。それから何か他のことをしてください。多くの場合、堅牢なテスト スイートを作成すると、ナイトリー ビルドが明らかになります。それが退屈な場合は、他の小さな段階的なプロセス改善を行います。

一度に一つのことを。赤ちゃんのステップ。赤ちゃんをお風呂の水で捨てないでください。あなたが望むのは、今月よりも来月が少し良くなることだけです.

小さな段階的な改善を 1 つ採用することに懸念がある場合は、根本原因を見つけてください。誰のエゴが傷ついた？誰が変化を心配していますか？

于 2008-10-08T21:01:19.713 に答える
0

私のお気に入りはPlanning Extreme Programmingです

編集: XP/アジャイル チーム向けの従来のプロジェクト管理を完全に置き換えるものです。

危険なのは、最新の開発方法を採用し、それを古風なプロジェクト管理と管理の慣行で窒息させることです!

于 2008-10-08T19:17:27.677 に答える