過去を振り返ると、新規開発プロジェクトを結構多く担当させてもらってたので、
プロジェクト進行の俺的Tipsを、いまさらながら綴ってみる。
#全てうまくできているワケではないけど・・・。
■目的の共有
・ユーザー向けサービスである以上、「ユーザーに価値のあるもの」って目的は自明。
・チームに共有すべきは、「定量的な事業目的」(ex.PV,UU,DL数,収益,etc)。
・具体的数字は確実に出せないにしても、どれに重きを置くかは共有できるはず。
・これが伝わってないと、チームでブレストしても方向がズレる。
■心血注いで仕様書作成！
・仕様を見える化しないと、動くモノにズレが生じる。
・開発開始時点で詳細仕様を全て決められるワケはないけど、
それでも開始までに細かいところを出し切る。
・細かいところって何かと言うと、
例えば「◯順でリスト表示し、◯件毎にページング」とか「投稿画像の大きさは◯MBまで」とかとか。
・実際に使う事を想定し、一挙手一投足の仕様が必要。
てかプログラマーは一挙手一投足をプログラムしてゆく事を考えると、ないと困る
・最初に作って終わりじゃなく、随時手直し。←これ、超重要！
開発中盤で決まった仕様も追記しとく。
→これをやっとくと、テストフェーズで生きる。
・仕様書こそが非開発者の「創る」のアウトプット。
「アジャイルだからドキュメントは最小限」は怠惰。
世に言う開発プロジェクトは分厚いバインダー数冊分の、多種のドキュメントを作成してる。
最低限、仕様書がないと、結果的にリリースに影響する。
※仕様書なくても上手くいってる新規プロジェクトもあるが、それは開発者が神だから。
■実装フェーズこそ忙しくあるべき
・テストケース作成
プログラマーが責任持つテストは「単体テスト」。
サービスとして正しい挙動をしているか(異常系も含めて)は、
仕様書を作成した者が責任持つべき。
そのためのテストケースを、このタイミングで作れるはず。
・リリース後、ロケットスタートのイメージ。
ユーザーにどう広めるか、他サービスとどう絡むか、
場合によってはその為の機能実装の必要もある。
■テストフェーズ
・実装に要する期間の半分くらいは、テスト期間取っておくべき。
例えば実装2ヶ月なら、テスト1ヶ月。
実装ボリューム多いほど、テストでのバグ潰しに時間を要するのも自明。
・システム監査はリリースの2週前に設定。
1発通過とか見たコトないので、修正期間のバッファを考慮しとくのが間違いない。
(システム監査ってナニ(・∀・)?→ぐぐりましょうｗ引っかかるものとして多いのはこれ)
・監査と負荷テストと障害テストは同期間にスケジューリングしてもよいかと。
どれも、機能テスト完了した上で行われるもの。
ただ、監査中に負荷/障害やると、監査してくれる人は悩んじゃうので、
監査終了後の夜間に負荷/障害テスト実施となるかな。
■スマートフォンアプリの外注開発について
・毎週、エンジニアとも会うべき！
スマートフォンはやっぱUIがPC/ガラケーとは全然違うから、
新規開発においてもそっちに体重を乗せがち。
けど、少なくともUIと同じくらい、裏側の機能/システムを意識するのが重要。
外注開発で進めるにあたり、先方のディレクターと顔を合わせるだけだと、
気づいたら裏側の進捗が怪しい事に。。。
・Webアプリより難しい
新しい分野だから、まだ全体的にノウハウ溜まってないからってのもあるけど。
どこまでがアプリ内で完結でき、どこからはサーバー利用するか、
の意識合わせが重要。って結局は仕様決めの話に繋がるかな。
プロジェクト進行の俺的Tipsを、いまさらながら綴ってみる。
#全てうまくできているワケではないけど・・・。
■目的の共有
・ユーザー向けサービスである以上、「ユーザーに価値のあるもの」って目的は自明。
・チームに共有すべきは、「定量的な事業目的」(ex.PV,UU,DL数,収益,etc)。
・具体的数字は確実に出せないにしても、どれに重きを置くかは共有できるはず。
・これが伝わってないと、チームでブレストしても方向がズレる。
■心血注いで仕様書作成！
・仕様を見える化しないと、動くモノにズレが生じる。
・開発開始時点で詳細仕様を全て決められるワケはないけど、
それでも開始までに細かいところを出し切る。
・細かいところって何かと言うと、
例えば「◯順でリスト表示し、◯件毎にページング」とか「投稿画像の大きさは◯MBまで」とかとか。
・実際に使う事を想定し、一挙手一投足の仕様が必要。
てかプログラマーは一挙手一投足をプログラムしてゆく事を考えると、ないと困る
・最初に作って終わりじゃなく、随時手直し。←これ、超重要！
開発中盤で決まった仕様も追記しとく。
→これをやっとくと、テストフェーズで生きる。
・仕様書こそが非開発者の「創る」のアウトプット。
「アジャイルだからドキュメントは最小限」は怠惰。
世に言う開発プロジェクトは分厚いバインダー数冊分の、多種のドキュメントを作成してる。
最低限、仕様書がないと、結果的にリリースに影響する。
※仕様書なくても上手くいってる新規プロジェクトもあるが、それは開発者が神だから。
■実装フェーズこそ忙しくあるべき
・テストケース作成
プログラマーが責任持つテストは「単体テスト」。
サービスとして正しい挙動をしているか(異常系も含めて)は、
仕様書を作成した者が責任持つべき。
そのためのテストケースを、このタイミングで作れるはず。
・リリース後、ロケットスタートのイメージ。
ユーザーにどう広めるか、他サービスとどう絡むか、
場合によってはその為の機能実装の必要もある。
■テストフェーズ
・実装に要する期間の半分くらいは、テスト期間取っておくべき。
例えば実装2ヶ月なら、テスト1ヶ月。
実装ボリューム多いほど、テストでのバグ潰しに時間を要するのも自明。
・システム監査はリリースの2週前に設定。
1発通過とか見たコトないので、修正期間のバッファを考慮しとくのが間違いない。
(システム監査ってナニ(・∀・)?→ぐぐりましょうｗ引っかかるものとして多いのはこれ)
・監査と負荷テストと障害テストは同期間にスケジューリングしてもよいかと。
どれも、機能テスト完了した上で行われるもの。
ただ、監査中に負荷/障害やると、監査してくれる人は悩んじゃうので、
監査終了後の夜間に負荷/障害テスト実施となるかな。
■スマートフォンアプリの外注開発について
・毎週、エンジニアとも会うべき！
スマートフォンはやっぱUIがPC/ガラケーとは全然違うから、
新規開発においてもそっちに体重を乗せがち。
けど、少なくともUIと同じくらい、裏側の機能/システムを意識するのが重要。
外注開発で進めるにあたり、先方のディレクターと顔を合わせるだけだと、
気づいたら裏側の進捗が怪しい事に。。。
・Webアプリより難しい
新しい分野だから、まだ全体的にノウハウ溜まってないからってのもあるけど。
どこまでがアプリ内で完結でき、どこからはサーバー利用するか、
の意識合わせが重要。って結局は仕様決めの話に繋がるかな。