はじめに
ソフトウェア開発の現在のペースは、そのスピードに驚くばかりです。 機能は常に「昨日必要」です。 なんで？ 競争-バイパス、追い越し。 テストする時間はありません。機能を出荷する必要があり、必要であり、必要であり、必要です。
開業医、方法論、アプローチ、明確な規制が開発チームの助けになります。 「穏やかな」開発の概念を10のルールの形式で定式化しようとします。 そして、最新のソフトウェア開発方法論の使用を強制します。 そして、顧客は落ち着いていて、彼の神経は安全です。 利益！
問題
映画「シリコンバレーパイレーツ」では 、長いマラソンで苦しめられたアップルのデベロッパーがよく紹介されています。 そして、疲れた開発者のコードは、翌日でも彼にとって不快なことがよくあります。 結論-疲れたコードを書かないでください。 はい、パフォーマンスは良くありません。
しかし、要件は常に変化しており、製品の視野はあいまいであり、顧客は自分が望むものを明確に説明することはできません。 そのような場合、彼らはアジャイルを思いついた。 関連するすべての方法により、チームの健全性を損なうことなく、変化する顧客要件に柔軟に適応し、適切な開発ペースを維持できます。
「静かな」開発のルールに移りましょう。
ルール
- 緊急のタスクはなく、優先事項があります
タスクに致命的な優先度がある場合、1週間前にそれについて考える必要がありました。 明示的な計画エラー。 または、ポイント9は無視され、「ハムスター」は手の床を噛むと脅しました。
- 完全に理解した後、タスクに進みます
大規模システムでの典型的な間違い。 彼は何かをし、何らかの形でチェックし、何かを得た。
- 顧客との対話を確立する
どのプロジェクトでも、妥協を求め、優先順位を付けなければなりません。 顧客と共通言語を見つけることは非常に価値があります。
- TKをフォローする
TKは、パラグラフ3を使用する場合に理想的であるため、問題はありません。 機能要素がない場合は、実行する必要はありません。
- 検証済みのコードのみを使用してください。
すべてのコードは、顧客に配信される前に、深刻な検証サイクルを経る必要があります。 サードパーティのモジュールはすべてテストコードでカバーし、十分にテストする必要があります。 コードは必ず確認する必要があります。
- 営業日8時間
非常に役立つアイテム。 これを思い出す必要がある場合があります。 家族も注意を必要とし、彼らの健康は保護されなければなりません。 十分な時間がない場合は、ポイント1を参照してください。
- ドキュメントを書く
ドキュメントがなければ、機能はありません。 また、関心のある人にリンクを張るだけで十分なので、時間を大幅に節約できます。 ドキュメントが明確でない、古くなっている、または二重の解釈がある場合は、更新する必要があります。
- コードを整理しておく
恐ろしいコードは書き直されるべきであり、システムに成長するべきではありません。 時間がない TODOを入れて、次の空き時間に修正してください。 - 顧客は実験用の実験用ハムスターではありません
「トレーサー射撃」というアプローチがあります。 これは、まだまだ機能的な若い製品でのみ使用できます。 製品が成熟するやいなや、顧客は些細なミスでも我慢しなくなります。 製品は完璧でなければなりません。 そうしないと、ロイヤルティが低下し、報酬のレベルが低下します。
- テスト
非常に重要なポイント。 関数にテストがない場合、そのパフォーマンスについては何も言えません。 ソフトウェアは不安定です。 SQLiteの鮮明な例。 そのため、このデータベースはさまざまなシステムで正常に機能します。
おわりに
健康を守り、高品質のコードを書き、仕事を楽しんでください。 落ち着いて！ 言及すべき他のルールは何ですか？