次のようにこれは私が、第二週21日シェアをオタクパンチに出席し、本当に学ぶための良い方法をまとめる時間が、今週、私はいくつかのより多くのソフトウェア工学の理解に行ってきましたです、毎日の要約は、読み取ります。
八日目
教師は、今日の宝石「ソフトウェアエンジニアリング美」を学んだ「？07 |メーカーは（下）アジャイルメソッドを使用している中で」、次のように私の要約です：
宝石の先生はアジャイル開発チームの日々の実装の例は、私たちはクライアント、より多くのフロントエンド、バックオフィス、オペレーション、製品設計、テストグループに機能によって人材派遣され、スケールは少しになりますまた、私たちと同じではありません引用しました。実質的に労働者の同様の部門は、製品の設計文書書かれた需要が、その後、私たちは毎日行われている日々の開発作業の背後にある作業量を評価し、説教する関係者を引き上げるだろう、ニーズやバグフィックスは、期間内に完了されています。私たちはそれぞれが担当することと、需要に応じて、スケジュール全体をプッシュするために所有者、所有者を設定します必要があり、開発が完了した後、トランクにまとめ、トランクプル機能ブランチの機能開発の開発に基づいて行われます、システムがリリース前にリリースブランチをプルアップしますテスト、そして最終的にオンラインに公開。実際、私たちは本当に厳密な意味でのアジャイル開発ではなく、価値観と原則は、チーMinjieの開発です。ただ実行する時間を持っていない私は、これは所有者の意識を訓練するより良い場所だと思い、このようなニーズを担当する必要の誰もが、良い場所は、残業、より多くのデッドタイムカード、需要に対処するために苦労し、開発者に必要な反復サイクルでありますいくつかの思考技術を構築し、成長します。
九日
教師は、今日の宝石「ソフトウェアエンジニアリング美」を学んだ「？08 |ソフトウェアの品質と時間コストの範囲との関係のバランスを取る方法」、以下は私の要約です：
私たちの毎日の仕事のためにこのレッスンの内容は非常に啓発、品質、コスト、レンジゴールデントライアングルプロジェクト管理ソフトウェアは、我々が作成したプロジェクトの必要な要素であるように、私たちは高品質を生成するために可能な限り最小のコストで行きたいです本当に良いビジョンです製品。しかし、実際のソフトウェアプロジェクトの開発プロセスでは、唯一、この三角形とのバランスで常に最適なソリューションを見つけるために妥協を作ります。
十日
教師は、今日の宝石「ソフトウェアエンジニアリング美」を学んだ「質問と最初のフェーズに答える」、以下は私の概要は次のとおりです。
基本的な理論的に言っ8の合計、以下のとおりです。
- 01 |ソフトウェア工学を理解するためにどのように最終的には？
- 02 |エンジニアリング思考：プロジェクトとして、すべてを得ることが推進します
- 03 |ウォーターフォールモデル：ソフトウェア開発成層の工場組立ラインと同じ
- 04 |ウォーターフォールモデル外で、どのような開発モデル？
- 05 |最後にアジャイルは問題を解決するのですか？
- 06 |ここでメーカーがアジャイルメソッドを使用していますか？（オン）
- 07 |ここでメーカーがアジャイルメソッドを使用していますか？（下）
- 08 |どのようにソフトウェアの品質と時間コストの範囲との関係のバランスをとるには？
私たちがするだけ知っている前に、8から再言う彼らに私は、ソフトウェアエンジニアリングの開発モデルのいくつかの基本的な概念を確認して、そのようなアジャイルと反復インクリメンタル開発、MVP可能な最小のバージョンなどのように実際に彼らの実際の作業のいくつかを考えますすべての問題を解決に後ろの終わりに各概念の深い理解に行きませんでしたが、このコラムの最大の価値は、私のプログラマは、より良い実際の開発作業を制御することを可能にするソフトウェアエンジニアリングの規律の新しい理解を作ることです需要を受け入れるために、受動的ではない、よりグローバルな視点は、そこから最良の意思決定を行う、からソフトウェアの品質と時間のコストとの関係について考えます。ボックスは、本当に私は視野を広げる作られ、多くの人が共有に大きな基準値を持っているがあります。
11日目
「先生は、今日の宝石「ソフトウェアエンジニアリング美」を学んだ？09 |ソフトウェアプロジェクトは、一般的に実現可能性の分析に注意を払うしない理由」、以下は私の概要は次のとおりです。
特別なソフトウェア・プロジェクト、限り、プロジェクトは、我々は現実的ではない場合、あなたは時間内にプログラムや停止を調整する必要があり、実行する必要がある、または不必要なトラブルを引き起こす可能性の条件のフィージビリティスタディを持っているよう。
実現可能性は、プロジェクトの失敗の確率を低減するために意識のフィージビリティスタディを作成することにより、科学的分析、フィードバック、合理的な方法を作ります。
フィージビリティスタディのためのイノベーションは、つまずきではなく、革新的なアイデアが飛んでいないからフィルタへのより正確な判断を下すことができます。
ソフトウェアプロジェクトのフィージビリティスタディ、主に次の側面から：
- 経済性（入力 - 出力比と長期的な利益を参照してください）
- 技術的な実現可能性（誰がプロである、技術的に存在する問題を解決）
- 社会的実現可能性（例えば、オープンソースの契約として法的、倫理的、社会的影響、）
12日目
教師は、今日の宝石「ソフトウェアエンジニアリング美」を学んだ10 |あなたが技術管理を有効にする場合は、プロジェクトを管理するための最初の試みが、以下は私の要約です：
技術移転の人事管理への障壁
あまりにも、プロジェクトの進捗状況を気にしない、より大きな絵を考えるのに十分ではない、他の人々とコミュニケーション無視することができ、技術的な詳細に焦点を当てました。
ソフトウェアプロジェクトを管理する方法？
チューブ良いの
人々があなたのメインのあるクライアントやプロジェクトメンバー、私たちは教育の製品を行うなど、当社の製品のユーザーは、当社の顧客は、プロジェクトの開発者、プロダクト、デザイン、操作、テストなどを担当するすべてのプロジェクト関係者です。
顧客の期待を管理するために、我々は、顧客は、そのような支払いの行動として、当社の製品に経済的価値を生成できるようにするために、時間と品質のコンテンツと高品質な製品をお届けしたいです。
プロジェクトメンバーは、プロセスを完了し、効率的なコラボレーション、時間上の完成品の反復を標準化する必要があります。チューブ良いの
行うためのソフトウェアプログラムは、プロジェクトの目標を完了することで、目標は一連の処理を完了することで、それを行うためのプロジェクト管理は、ソフトウェア開発プロセスの管理を行うことです。
- インクリメンタル反復モデルやモデルなどの適切な開発モデル、選択して
適切な開発モデルを保証するために、マッチング処理の仕様とツールを、適切な開発モデルをしているが実行されます- 優れたプロジェクト計画を作る
当社製品の反復は例を計画：
需要説教締め切り11.06
機能は、時間に11.20開発
機能検査は、完全な+のバグ修正が11.27完了している
舞台裏のリリース+プルリリースは11.28流れ
システムテスト+バグ修正完了12.04
チェックリスト+内部経験を12.05
グレー一週間12.05から12.11
の全体量は12.12に加えて
、特定のノードと完全なものに締め切り。- 制御およびトラッキングプログラム、優れたリスク管理
チームのメンバーが適切にワークロードを評価するために、初期のスローポイントのリスクは、あなたは、このような目標を達成するためのスコープと時間を制御するよう、目的の値を調整することができます。
第十三日
先生は、今日の宝石「ソフトウェアエンジニアリング美」を学んだコードは、動いていない計画が進ん| 11：、ここで私の結論であります
ソフトウェアプロジェクトマネジメント計画書は、プロジェクトが無秩序と混乱の実行中に落ちないようにすることです。
プログラマはまた、私たちはより良い実際の作業を手配することを可能にする計画を心配しなければならないためには、例えば、あなたが実行時に危険なタスクの間に存在する依存関係が存在するかどうかを心配する必要があります。
ステップ計画は、一般的に次の3つのステップがあります。
- タスク分解
タスク分解を分割するWBS（WBS）に従うことができ、分割位相大きいステージは、特定のタスクに小さい、小ステージさらに分割されます。- 推定時間
偏りがあるかもしれないので、推定時間は、プロジェクトマネージャーによって行うことができない、開発者やプロジェクトマネージャは、推定開発時間がより合理的になりそうという、このバイアスを排除するために、完全に通信する必要があります。- タスク放電パス
タスクシリアルず、タスクへの放電経路との間の関係、リソース消費量、排気の適切な順序。優れたプロジェクト計画を作成した後持っているビンではない、また追跡され、実際の状況に応じて調整する必要があり、それが定期的に収集するために、プロジェクトマネージャーの進捗状況を追跡したり、プロジェクトの参加者を報告するためのイニシアチブを取ることができます。また、日々の駅や看板などの一部のアジャイルプラクティスを参照することができます追跡されます。
第14日
先生は、今日の宝石「ソフトウェアエンジニアリング美」を学んだ12個の|プロセスと規範：交通信号機がバインドされていないが、効率を改善するために、次のように私の要約です：
グッドプロセス仕様が拘束されていませんが、チームの効率を改善すること。例えば、コードの仕様を指定し、私たちはほとんど差コード、改善コードの可読性と保守性の増加を書くことを、他の人はそれはあまりにも難しいことではないました。
この点について、私は合意に非常に多くの午前、良いコードを書くことができます異なるチームを作る能力を調整するだけでなく、新規参入者がより良いチームに統合できます。
仕様の開発プロセスは、一般的に4つのステップを有する：
最初のステップ：明確な問題を解決するために
ステップ2を：ソリューションが提案する
3段階：、合意に達するの実施促進する
第四の工程：連続的な最適化を、継続的な改善を最近、私はこのプロジェクトを担当していたものにホット・アップデートに上陸したが、また、対応するプロセス仕様を開発し、基本的にやってこれらの4つの手順に従ってください。
リミット値は、人に依存しすぎて、実行した場合、効率を改善するために設計されていますが、仕様、標準またはコード例を実行するための技術的手段を通じて、ヘルプの人々への方法を考える必要がありますので、効率が低下することがあり、それぞれの内部皆を暗記することは不可能ですルールは、我々は仕様を確認するために、開発者を支援するIDEまたはいくつかのコードフォーマットチェックツールを利用することができます。
遂に
第二週の内容は、正式に入力されたプロジェクト計画の論文これらの要素があり、プロセスと計画を開発する方法、実行する方法を、私は管理ニーズ全体でソフトウェアプロジェクトの実現可能性の分析の重要性の閉塞、および技術移転について学んだ今週、プロジェクトの計画をさらに行くための独自の努力をして、コードのカンフーの外には、私には、単に需要よりも多くの必要があり、成功したプロジェクトは、ルーチンがあります。より良い方法は、日常の仕事を導くために、ハードワークを忘れて見上げたことはありません。来週、私は米国の学習ソフトウェア工学におけるシェア内容に継続します、ありがとうございました。
巫魔女：社会的関心の番号へようこそ
