| 日時: | 2024-04-16 |
|---|---|
| 作: | 時雨堂 |
| バージョン: | 2024.1 |
| URL: | https://shiguredo.jp/ |
銀の弾丸はない
複数の自社製品開発を同時に走らせる事になったので、書き出してみた
必要なタイミングで必要なリソースを投入する
- @voluntas が全ての製品責任者
- 関わっている技術者は全員でも 10 人程度
- 全員が開発と設計と検証を担当
- それぞれの製品は依存性がある
一緒に作業する相手を信頼する、信頼できない人と仕事なんかできない。
すぐに GitHub Issue を切る。 レビューを定期的に行い不要なら削除する。
削除するときはコメントを付けておくと、他の人がなぜ不要なのかわかる。
技術に明るい人に決めてもらう。好み問題は作業者優先。
フォーマッターやリンターを積極的に導入する。
基本的に期限は決めず、ドキュメントを先に書いてそれに沿って機能開発をする。 年 2 回のリリースサイクルに間に合わなければスキップする。
なぜその製品を開発するのかという理由を説明する。 利益なのか宣伝なのか、挑戦なのか興味なのか。その製品の立ち位置を明確に伝えておく。
設計者と開発者は同じとする
- 基本設計は製品管理者がすべて担当する
- 詳細設計は担当者が判断する
担当者が製品管理者が出した基本設計書に基づき設計を行う。
短期間で製品開発を回していく場合は、セルフレビューを徹底的に行うのが良い。 セルフレビューなしで進めてうまくいった経験がない。
とにかく困ったら考え込まずに相談する。相談相手は誰でもいい。言語関係なく相談する。 ここでの相談は技術的な相談が主になる。
小規模開発の場合は複数人数より一人で開発した方が早い。
それぞれ単独で開発を行う。ほかのメンバーとの疎通はドキュメントとレビューで行う。
技術または時間的に無理なら実装しないという選択を取れ。 ただし、個人で判断せず相談しろ。
まず手を動かして動くモノを作って見せてみる。悩むより動くコード。
手を動かさずに悩むな。
とにかく自分の主担当以外でも積極的に口を出す。言語やフロント、サーバ関係ない。
できるだけ最新の自分が良いと思う技術を使うこと。 それが古くなったのならすべて書き換えるという考えで開発する。
儲からなければ捨てれば良いし、儲かったのなら余裕があるはずだから書き直せば良い。
新しい技術を使うことは開発者を成長させる。問題が起きたら解決すれば良い。
基本なし。必要あれば集まる。Slack と Trello で事足りる。 会議は時間の無駄。決めるのがツライ場合は製品管理者が決めて、責任取るので良い。
担当者が好きに選定して良い。ただし選定責任は持つこと。 必要な OSS への貢献は製品開発の作業と見なす。
最小限でよい。利益を出せるようになってから充実させていけば良い。 基本はエンドツーエンドテストにすること。