最初の講義はチームで働くすべての人々に関連し、2番目の講義はプログラミングに関するものです。
柔軟性の習慣
この状況での柔軟性は、競技場のスペースによって制限され、前方への移動に関係しない体操選手の柔軟性としてではなく、障害物が現れたときに動きの方向を変える能力として理解されます。
習慣は私たちがストレスの多い状況、思考なしの行動で私たちがやってくるものです。
以下は、それ自体の開発がチームワークの改善に役立つ習慣です。
アプローチ
前向きな態度。 「すべてが悪い、災害、何もできない」と言う場合、前向きに考えることは非常に重要です-あなたは何もしません。 すべてがどれほど悪いのか本当に泣きたいなら、外に出て、一人でやって、戻ってきて、「これでどうする？」と言う必要があります。
透明性
成果、特に問題について率直に話すことが非常に重要です。
「スケジュールのco病者」のゲーム-スケジュールが破られることを誰もが知っており、ボスとの会議では誰もがタイミングについて沈黙しており、最初の人が「時間どおりではないようだ」と言うと、誰もが彼に振り向いて時間がありますか？！？！」 その結果、すべてが最初に言った人に当てはまり、スケジュールに遅れることは雪崩のように成長しています。
透明性は時間を節約します-「プロジェクトをするつもりはない」と言うと、誰もが考え始めます。 名前のせいではありませんか？ そして、「私はどこかで間違いを犯し、プロジェクトは失敗するだろう」と正直に言うよりもはるかに多くの時間を費やしているので、それをチェックしてみてください。
嘘は短期間（営業など）うまく機能しますが、長期的には真実は常に良いです。
責任
すぐに尊敬を集める仕事をするとき（たとえば、誰もやるリスクのないメイクファイルを構造化するとき）、他の人を訓練しないと、何年も素晴らしい隔離でこれを行うことに注意することが重要です。
極端なプログラミングでは、「完了」という用語がしばしば導入されます。「完了」と言うとき、人々はしばしば個人的に準備が整っていることを意味しますが、問題があるかもしれませんが、間違いではありません。 Finish-readyとは、すべてが実際に整頓されており、プロジェクトのこのセクションが問題を引き起こさないことを意味します。
アクション
最初に行動してから反映することが重要です。 最初に理論的な資料を収集したり、本を読んだり、フォーラムで他の人の経験を研究したりする場合、ほとんどの場合、直接行動することはありません。 最初にそれを試みる必要があります。 最初の試行でうまくいかない場合は、考えてもう一度試してください。 さらに、このアプローチは大部分が反復的であるため、どこから開始するかはそれほど重要ではありません。次の試行では、目的の開始点を見つけます。 「これを行う方法」という質問に対する正しい答えは、「この方法を試してみましょう。うまくいかない場合は、別の方法を考えます」です。
同様に重要な質問は、「これについてそれほど複雑なものは何ですか？」です。 ほとんどの場合、あなたは自分自身のほとんどの困難を考えただけであることに気付くでしょうが、タスクが本当に難しい場合でも、既存の障害の明確な考えが現れます。
同時に、反射について得られた結果の測定を忘れないことが重要です（以下を参照）。
時間
間違いなく利用可能であり、確実に終了する唯一のリソース。
1週間で2週間の仕事をすることはできません。
さまざまなタスクに焦点を絞り、時間を小さな領域に分割することで、良い結果が得られます。
トマトの原理：
キッチンタイマー（できればトマトの形）を購入し、25分間起動します。この25分間は、電話、SMS、メールなどに気を取られることなく作業を行います。 質問がある同僚のために、私たちは静かにタイマーを指して作業を続けます。 この25分後、タイマーを5分間起動し、この5分間で小さなことを行います。 そもそも、そのようなディープダイビングは1日に1回、次に2回などです。
仕事の安定したリズムは、鉄の自己規律よりも重要です。
単純なことは自動化する必要があります。 インストーラーの90％では、次に何度もクリックする必要がありますが、パラメーターを変更する必要はほとんどありません-自動化が不十分です。
コミュニケーションズ
各チームメンバーは、使用することが重要な独自のつながりを持っています-専門家とのつながりなど。
チームメンバー間のスキルに関するコミュニケーション-誰もがすべての分野で少なくとも少し知っているので、たとえば、CSSスペシャリストが休暇中であれば、残りは少なくとも彼の仕事の一部を行うことができます。
最も重要なのは顧客とのコミュニケーションであり、ここでの顧客とはプログラムの直接のユーザーを意味します。なぜなら、プログラマーが下した決定によって主に影響を受けるのは彼だからです。 不満なユーザーは満足しているユーザーよりもはるかに優れています-不満なユーザーを満足させることができれば、彼はプログラムと開発者としてあなたを最初に満足したユーザーがしないような広告を作成します。
ユーザーとのやり取りの方法がわからない場合は、まず試してみてください。最初は悪い結果になりますが、行動を起こせば、時間が経つにつれて良くなります。 プログラマーとエンドユーザーの間でシステムの変更について議論するときは、最小限の仲介者が必要です。
遠近法
地域の問題を解決する際のグローバルな方向性を覚えておくことは重要です。 アイデアが思い浮かんだ場合-いくつかの簡単な明確なフレーズにそれを結晶化し、「これは一般的な問題を解決するのに役立ちますか？」という質問を自問してください。 また、チームがオープンな作業原則のセットを持っていることも重要です。
リフレクション
この場合の重要な質問は「どうでしたか？」です。一方、悪いオプションを破棄するだけでなく、良いオプションを書き留めて何度も使用することも重要です。
4つのレスポンシブデザイン戦略
プロジェクトの最終設計！=元の設計。
この状況に対応するということは、周囲の現実に応じて変化することを意味します。
背景
デザインは、有用な関連要素または有用な関連要素のコレクションです。
デザインの研究は、内省的、経験的、定量的です。
ソフトウェア設計はフラクタルです（2つのオブジェクトの接続の設計は、2つのシステムの接続の設計とそれほど変わりません）。
安全な措置を講じる必要があります。1つの変更を行っても、10か所で故障することはありません。
何かを変更する前に、この部分を分離し、すべてが成功した場合は元に戻す必要があります。
開発の目標は、機能の継続的な流れです。
新しい機能の追加は、ねじれではなく直接である必要があります。
問題の解決策が完全にわかっている場合、設計の応答性はそれほど必要ではありません。 次の場合に必要です。
- 何かをする方法は知られていない。
- リソースとして知られていますが、十分ではありません。
- リソースがあることは知られていますが、チームの他のメンバーはこのオプションを理解していません。
安全な手順を実行するには、次のパラメーターのバランスを取る必要があります。
- 効率性
- リスク
- レビュー;
- チームワーク。
戦略
ジャンプする
次の場合に適用されます。
- 私たちはそれを行う方法を知っています
- このオプションを安全に作成して埋め込むことができると確信しています
次に：
- -1つのステップで複数のアクションを実行します。
+：より高い効率
-：リスクが高い
平行度
次の場合に適用されます。
- 私たちはそれを行う方法を知っています
- 安全にビルドできるかどうかわからない
次に：
- 両方の設計オプションを一時的にサポートし、古いものから新しいものに機能を徐々に移行します
+：セキュリティ
-：多くの余分な副次的作業
参考石
次の場合に適用されます。
- どうやってやるのか分からない
- 問題の解決を簡素化するために何ができるかを知っています。
次に：
- 目標を達成しやすい追加のプロジェクトを構築しています
+：他のプロジェクトで使用できるコンポーネントを取得する
-：余分な作業が多い
-：この段階ではフィードバックはありません。
単純化
次の場合に適用されます。
- 方法がわかりません。
- タスク全体を完了するためのリソースがありません
次に：
- タスクが1つの安全なステップで解決されるまで、要件を捨てます
- プロジェクト要件を徐々に復元します。
+：ほとんど常に可能
+：イニシアチブを開発
-：要件の復元順序に応じた非線形コスト。
補足説明
機能を直接追加できない場合：
- どうするか
- 後でこの決定の代価を支払う準備をしてください
いずれにせよ、グローバルな設計変更は顧客が負担します。新しい機能の追加を遅らせたり、各追加をめちゃくちゃにしたりしないように、しばらくの間それを拡張することが最も有利です。