このソフトウェア開発プロジェクトのチェックリストに何を追加しますか？
私はチェックリストの大ファンです。 トラベルチェックリスト 、 移動チェックリスト 、さらに スクラムチェックリスト があります。
Context：大企業に雇用され、ソフトウェア開発環境全体、プロセス、チームなどをセットアップするという使命を与えられました。ブランチ」。お客様は、ソフトウェアの有効な増分を作成する責任があります。プロジェクトの規模：2000人/日。
次の（意図的に小さく不完全な）チェックリストにどの項目を追加しますか？
- 継続的インテグレーションサーバーのインストール
- DoDを作成する
- 1ページのコーディングガイドラインを書く
- 製品バックログを作成する
- バグ追跡システムをインストールする
- 通常のフェイスタイムをスケジュールする
* 1.）開発者に相談して、本当に必要なものを確認してください！ *
2.）複数の環境を非常に迅速に起動するためのソリューションを調査します（流行語に準拠していない場合は、パブリックまたはプライベートのクラウドインスタンス、または旧式の仮想マシンを考えてください）。
3.）ソース/バージョン管理
4.）コードレビューシステム（例としてCrucbile/Fisheye）
5.）かんばん壁（または類似のもの）
6.）通信プロトコル（リアルタイムチャットは大きなプラスです）、wikiはコラボレーションも促進します。これは、社内の広報活動にも適用されます。ビジネスオーナー、テクニカルサポートスタッフ、その他のグループとどのように連携しますか？
7.）電子ホワイトボード
8.）開発者にとって快適な環境（ソファ、テーブル、チルアウトエリア、良好なWiFiなど）
9.）素晴らしいコーヒー!!!
- Toolchain setup-IDE、CIサーバー、コード品質サーバー、ソース管理、ウェブサーバー、データベース、課題追跡など.
- バックアップ-チームの各人にはどのような役割がありますか？彼はどのプロセス/モジュールを「所有」しており、誰がバックアップしていますか？
- （ユーザー承認）テスト環境セットアップ-継続的な統合だけでなくw。単体テストですが、統合テストは本当に悪いこと、複数のプラットフォーム、アプリケーションサーバー、VMなどをカバーします。
- パフォーマンステストセットアップ-「パフォーマンスが大幅に低下した機能/マイルストーンはどれですか？」と回答するには履歴データが必要になるため、早いほど良いです。
- （エンドユーザー）ドキュメントの概要-ドキュメントには何が含まれますか？どの種類のドキュメントが必要ですか？
- マーケティングチャネル-内部マイルストーンと外部リリースはどのように発表されますか？ソフトウェア、ロゴ、色、言葉遣いなどのクールな名前はありますか？
- 内部コミュニケーション-他のチームのピアはどのように変更について通知されますか？コラボレーションはどのように行われていますか？ウィキ？アクセス権？
- 品質保証人とプロセス-誰が何を、どのくらいの頻度で、どのような基準でテストするのですか？
- リリースプロセス-いつ、どのくらいの頻度で、どのように、誰が実行しているか、誰がリリースを受信しているかなど。
- リスク管理-最悪のシナリオ（プロジェクト管理のPovから、および実行時のPovから、たとえば、「ソフトウェアがモジュールXで失敗したため、顧客は損失を出している。バックアップ計画は何か？」
- Securingコア開発環境の例。エスクロー用に仮想化
- 場所公式および非公式の会議用
- トレーニングまたはすべての人のためのイントロなので、すべての設定が何であるか、各部分の目的、およびそれらの使用法を知っています。
- 世話人の識別そして、物事がうまくいかなかったときに実際に世話をする必要があるすべてのもの（許可など）を彼に与えます
事後レビュー-ブロックで物事に取り組んでいるので、（チームのサイズに応じて）1〜2時間のレビューをスケジュールし、（可能な場合は）顔を合わせてミーティングを行い、全員が回って、何が正しく行われたか、何がより良くできるか、そして何が必要でなかったかを言います。開発プロセスでのミスから早期に学ぶことができるということは、作業する時間があまりないときに後でミスをすることを避けることができることを意味します。
まず、プロジェクトに適した専門家の優れたチームを雇うことから始めましょう。典型的なビジネスアプリでは、少なくともデータベース開発者、dba、QA担当者、システム管理者、ビジネスアナリスト、アプリケーション開発者、UIスペシャリスト、チームリーダーを雇う必要があります。 DBA、システム管理者、ビジネスアナリスト、QAは、開発チームとは別のレポートチェーンに属している必要があります。開発データベースのスペシャリストは、アプリケーション開発者およびUIスペシャリストと同じテクニカルリードに報告する必要があります。
オフィススペースを設定します。私的なオフィスは、それらを手に入れることができればすばらしいですが（これで幸運を祈っています）、最低限、デスク、電話、コンピューター、ホワイトボード、およびいくつかの専用会議室が必要です。昼休み、冷蔵庫、ソフトドリンク、スナック、コーヒーを用意できる場所があることを確認してください。無料のソフトドリンクとコーヒーをさらにお楽しみいただけます。
アプリケーションとデータベースの両方にdev/qa/stagingサーバーとprodサーバーをセットアップします。データベースをアプリケーションと同じサーバー上に配置することはできません。プロジェクトのサイズと範囲によっては、環境ごとに複数のサーバーやSANなどが必要になる場合があります。
サーバーがセットアップされたらすぐに、ファイルシステム、データベース、およびデータベーストランザクションログのバックアップをスケジュールします。これを行うのは、セットアップの最初の日です。 Iron Mountainのような会社を雇って、バックアップをオフサイトで毎週取得します。
ソース管理システムをセットアップし、それがどのように使用されるかを説明するドキュメントを作成します。すべてのデータベース構造の変更とルックアップタイプのテーブルへのデータ挿入は、ソース管理のスクリプトに含めることを忘れないでください。これにより、展開が容易になります。
商用ソフトウェアを購入するか、すべての関連ユーザーのライセンスで使用することに決めたツールセットのオープンソースソフトウェアをダウンロードします。
高速で動作し、2つのモニターを備えた開発者用マシンを購入します。ゆっくりとうめき声を出していて、ユーザーがデスクトップ上で持つ典型的なものである、少なくとも1台のテストユーザーマシンを購入します。
やりたいことを新しい開発者にトレーニングします。ジュニア開発者がいるほど大きなチームがある場合は、チームに追加のトレーニングをスケジュールし、プロジェクト計画に時間を含めます。ジュニアを少なくとも3か月間非常に注意深く監視します。最初の月は、すべての新入社員を注意深く監視します。デッドウッドと悪質な開発者をできるだけ早く取り除きます。
何をどの順序で実行する必要があるかを決定します（クリティカルパス）。依存するタスクが完了するまで、クリティカルパスの最後にタスクを割り当てないでください。
テスト計画と要件を作成します。
クライアントと定期的にスケジュールされた進捗会議を設定します。彼らはあなたが何をしているか、そして何が障害であるかを知るのに値します。物事がいつ遅れるかを必ず伝えてください。あなたが締め切りから3週間離れていて、あなたがすでにそれを逃すことを知っているなら、あなたがクライアントに伝える必要がある前にその赤字が魔法のように消えることはありません。追加された要件は追加のコストと時間を意味すること、および追加されたすべての要件は他のタスクを削除する必要があるか、または新しいタスクの時間数によって期限が変わることをクライアントが知っていることを確認してください。これを最初から明確にしておくと、多くの痛みと残業時間を節約でき、クライアントではなくグループが吸収するオーバーランの費用がかかります。
1人のユーザーの速度だけでなく、予想される同時ユーザー数をテストできる環境をパフォーマンステストに設定します。稼働する前日まで、このテストを行うのを待たないでください。
プロジェクト計画では、QAがバグを見つけ、修正に時間がかかると想定します。最後に1日だけQAをスケジュールしないでください。
データベースが想定するサイズとほぼ同じサイズのテストデータを作成します。すべての開発者に、このサイズのデータベースに対してコードをテストしてもらいます。開発者が個人のマシン上の小さなデータベースに対してのみ開発することを許可しないでください。これは、プロダクションに到達するまで正常に機能するコードの頻繁な原因です。
予算に報酬を計画します。それは彼らが彼らの数ヶ月のために彼らの尻をオフにすると人々をやる気にさせ、マネージャーだけがボーナスを得る。また、頻繁に書面でお礼を述べます。
追跡する必要のあるものを追跡するには、プロジェクト管理システムが必要か、少なくともスプレッドシートを設定する必要があります。プロジェクトの計画を立てるときは、計画の担当者が1日6時間以内であることを想定してください。これは、休暇、病欠、休日、人事会議、パフォーマンスレビューなど、プロジェクトに費やされない時間を明らかにするのに役立ちます。 11月1日から1月1日まで（米国では）、休暇や休日の時間を増やすために、追加の手当が必要になる場合があります。開発者が休暇と休暇を放棄することを期待するのは不公平であり、病気の時間、陪審義務、死別時間などのようなことがいつ起こるか誰も予測できない。彼らがこのプロジェクトであなたのチームに起こると仮定します。
質問とその後の回答に表示されないもの：
災害復興計画。開発ボックスのバックアップ、ステージング、テストなどはどのように行っていますか？すべての開発者は、時折雪の日に自宅で作業するために必要なものを持っていますか？等。
訓練計画。あなたの開発者は何週間のトレーニングを何週間も続ける必要がありますか？誰か追跡していますか？ （ほとんどのチームではスプレッドシートで十分です。）報告するメカニズム（「何でも」で2時間のWebキャストを2時間視聴したことを誰かに電子メールで送信することでおそらく十分です）と、管理者が計画するためのメカニズム（たとえば、誰に何を送るか）今年の会議。
ツールの位置。これは「すべてのMSDNサブスクリプションを提供します。作業用のマシンに他に何もインストールしないでください」という種類の場所ですか、それとも「コードが必要ですが、編集、コンパイル、テストに何を使用するかは関係ありません」 「一種の場所。決定を下し、記録します。
あなたが立つことができるか、できる限り多くの統合されたALM。通常、「インピーダンスの不一致」、二重入力、ツールのオーバーラップ、回転チェアアプリケーションの統合の理由は、システムが少しずつ成長したためです。ゼロから始めて、サイクル全体を通じて従業員が単一のツールにとどまることができることを示す必要があります。 Xでコードを入力しない、Yでコンパイルする、Zでテストする、Aで作業項目/タスクのステータスを変更する、Bで費やした時間を報告する、待っている人にCに進むことができることを伝え、理解しようとするDで次に何をするか、Eで全体の進捗状況を確認するなど。
より多くの工数を交渉します。
人々が最初に十分に割り当てることはまれなイベントです。
[後で... re-negiotiateさらにもっと...]
私がサードパーティのライブラリとその使用に関して最も問題を抱えているのを見てください：
- 使用するライブラリとバージョンを決定します。
- ライブラリの更新をプロジェクトに統合するプロセスを作成します。
- 開発者全員がライブラリの選択に参加していることを確認してください。
- 使用されているテクノロジーについてのオープンディスカッションのための有益なチャネルを作成します。
どうして？サードパーティのライブラリ（独自仕様）に、何週間も開発期間を短縮するようなバグがありましたが、上または下に移動するプロセスがなかったため、その数はわかりません。または、「どのバージョンを使用しましたか？非推奨とマークされた関数を使用したのはなぜですか？」
組織に多額のコストがかかっても、開発ライフサイクル全体でセキュリティに予算が割り当てられるわけではありません。これは、通常、セキュリティが実際には効果的でなく、費用のかかる一連のアクティビティや制御を導入して遅すぎて、多くのことを行うことができないことを意味します。
開発の他のすべての側面と同じように、主要なマイルストーンを備えた初期プロジェクト計画からセキュリティを組み込み、反復プロセスを使用してセキュリティガイダンスを最新の状態に保ちます。セキュリティからの最終的な承認は、すべてのセキュリティ制御が設計どおりに実装されたことの当然のチェックであるはずです。
そうしないと、実装後にセキュリティを実行することになり、8〜10倍のコストがかかる可能性があります（Gartner、IBMなどの数値）。機能に影響が及ぶ可能性があり、悪用を防ぐには遅すぎるため、人々を混乱させます。そして損傷。
1。チームに持っていく
プログラマに質問してください！本当に、それが最も重要なことです。開発者がこの変更に直接関与していない場合、多くの抵抗に遭遇します。結局のところ、それはあなたではなくそれらがどのように機能するかについてです。言うまでもありませんが、方法とツールを人々に強制しようとすることは、通常、恐ろしいことです。
2。調査して適応
経験を生かして、選ばれたトラックに乗るのをやさしく助けるために、チームに最良の作業方法を見つけてもらいます。次に、定期的かつ共同で、自分（彼ら）の様子を振り返り、プロセスを改善して改善します。