| 日時: | 2015-11-07 |
|---|---|
| 作: | 時雨堂 |
| バージョン: | 0.0.0 |
| URL: | http://shiguredo.jp/ |
銀の弾丸はない
複数の関係するプロジェクトを同時に走らせる事になったので、自分の考えを書き出してみた。
- 1 ヶ月の短期間
- メンバーは一桁
- 全員が開発と設計が可能
- プロジェクトはそれぞれ依存関係にある
なぜそのプロジェクトをやるのかという理由を説明する。 利益なのか宣伝なのか、挑戦なのか興味なのか。そのプロジェクトの立ち位置を明確に伝えておく。
設計者と開発者は同じとする
- 基本設計は @voluntas がすべて担当する
- 詳細設計は担当者が判断する
担当者が @voluntas が出した基本設計書に基づき設計を行う。
短期間でプロジェクトを回していく場合は、レビューを入れるのが一番効率が良い。 レビューなしで進めてうまくいった経験がない。
特に連携をとる必要がある場合はレビューを中心として議論するのが早い。
今回は社外のメンバーもプロジェクトに参加している。社外メンバーはレビューを中心に入ってもらっている。 社内だけでは気づけないことは多い。
とにかく困ったら考え込まずに相談する。相談相手は誰でもいい。言語関係なく相談する。 ここでの相談は技術的な相談が主になる。
プロジェクトの方針的な相談は @voluntas に相談するというルールにした。
複数人数で実装するのではなく、担当をプロジェクト単位で分けた。 また、プロジェクトの中でもフロントとサーバで分けた。
小規模開発は複数人数より一人で開発した方が早い。
それぞれ単独で開発を行う。ほかのメンバーとの疎通はドキュメントとレビューで行う。 主に API がメインになるので API のドキュメントを共有することを重視した。
期限が最優先。その期限までに品質が達成できない場合は機能を減らせ。 そもそも無理なら、期限を切っている @voluntas が悪いので、リリース時期の変更が必要。
技術または時間的に無理なら実装しないという選択を取れ。 ただし、個人で判断せず相談しろ。
まず手を動かして動くモノを作って見せてみる。悩むより動くコード。
手を動かさずに悩むな。
とにかく自分の担当以外の範囲でもレビューに参加する。言語やフロント、サーバ関係ない。 自社製品なんだからすべてを把握するべき。
会社の方針としてそれほど大きく複雑なサービスは自社では作らない。
レビューイーはレビューワーを育てる必要がある。
できるだけ最新の自分が良いと思う技術を使うこと。 それが古くなったのならすべて書き換えるという考えで開発する。
儲からなければ捨てれば良いし、儲かったのなら余裕があるはずだから書き直せば良い。
新しい技術を使うことは開発者を成長させる。問題が起きたら解決すれば良い。
基本なし。必要あれば集まる。Slack と Trello で事足りる。 会議は時間の無駄。決めるのがツライ場合は @voluntas が決めて、責任取るので良い。