近所の図書館にあったので読んでみました。
アジャイル系の開発プロセスを解説した本よりも一段上から、ソフトウェアの品質やプロセスについて記載されています。トヨタの話も出てきますが、トヨタ式が素晴らしいとかそういう話ではなく、製造と開発の違いも踏まえた上で良い部分をソフトウェア開発に用いようというスタンスで、面白かったです。
- 「原則」が、ある分野についての指針となる考えや洞察であるのに対し、「プラクティス」は、原則を実行するために、何をするか
- ソフトウェア開発の7つの無駄
- 未完成の作業のムダ
- 余分なプロセスのムダ
- 余分な機能のムダ
- タスク切り替えのムダ
- 待ちのムダ
- 移動のムダ
- 欠陥のムダ
- プロジェクトのトラッキングが複雑なら、おそらくそのシステムには、ほかの種類のムダが大量にある
- 開発(レシピを設計する)
- 実践利用に適していることが品質の基準
- バリエーションがある結果は善
- 反復は価値を無味出す
- 高レベルの設計と詳細な解法の間を行き来する
- フィードバックを増やすことが、問題のあるソフトウェアプロジェクトや環境に対処する唯一の効果的な方法
- 欠陥をためこまず、コードを書いてすぐにテストすること
- ドキュメントや詳細な計画を増やすのではなく、コードを書くことによって考えが正しいことを確認する
- 多くの要求をユーザから集めるのではなく、どのようなことができるかをユーザに見せ、ユーザから入力を得ること
- どのツールを使うかを入念に調べるのではなく、組織内での候補を3つ選び、それらを試してみる
- システム全体を一度に置き換える方法を見つけようとするのではなく、レガシーシステムにウェブインターフェースをつける、という新しいアイデアを試してみる
- あきらかに多くのリソースを費やして、多数のコンセプトを検討する。それにより、開発プロセス全般に渡って多数のオプションを選択できる状態に保ち、サブシステムのプロトタイプを多数作り出す
- ウェブサイトの構造について合意できない場合、2,3バージョンを用意し、それぞれ異なる画面遷移やページレイアウトを行うようにして、最終的に最高の機能を寄せ集めることで、優れたユーザビリティの点数が取れる
- 深さ優先のシーケンシャル開発と、広さ優先のコンカレント開発がある
- ソフトウェア開発でのコミットメントを遅らせるための戦略
- モジュールを使う
- インターフェースを使う
- パラメータ化する
- 抽象化を使う
- シーケンシャルプログラミングを避ける
- フレームワークは成功した実装を集めた中から抽出されるべきで、推測で作らない
- ソフトウェア開発の7つのシンプルルール
- ムダをなくす
- 学習効果を高める
- 決定をできるだけ遅らせる
- できるだけ速く提供する
- チームに権限を与える
- 統一性を作り込む
- 全体を見る
- チームでプロセスをチェックする
- 何があなたをスピードダウンささているのか、また、何がいい仕事をするじゃまをしているのか
- もっと速く、よく、安くするためには、何が役立つか?いいプラクティスと悪いプラクティスを作ること
Sorry, comments are closed for this article.