http://engineer.typemag.jp/article/startuptechnight
スクラムは少しかじってみたのですが、4〜5人ならともかく、今の私の例のプロジェクトの2名体制ではいくらなんでも適さないことがわかりました。僕とアナタしかいないんだから、そこまでしなくてもね。
スクラムの他にも、今後色々なプラクティスが出てくるとは思いますが、
何にしても、どんなプラクティスだってその一般的な評判よりも、自分のチームの肌にしっくり合うかどうかが一番だと思います。
経済システムにしても、社会システムにしても、ダイエット法にしても英会話勉強法にしても、当事者(たち)がその方法論を心から気に入って、信頼できなければそれは上手く機能しない。
どんな時代にもどんな層にも通用する完璧なシステムなんてものは幻想で、それを謳い文句にする人達はまず疑ってかかるべきです。
その時々のいろんな事情に合わせるためにシステムやら方法論が創りだされるのが自然であるし、場合によっては人から与えられるだけでなく、自分たちでその仕組を創りだしたっていい(というかそれができるならベスト)。
話それたw
まぁ、今私がやっている個人ゲームプロジェクトは体制2名ですが、色々と模索中です。
(ちなみにソースコードリポジトリのフローは、Github flowとGit flowの中間的なものを採用しています)
ただ、テスト体制やCIはまだ全然ですね。Jenkinsは構築したんですが、まだ十分使いこなせていないw
方法論とかはともかく、自動化に関してはやってマイナスになることは少ないので、どんどんやっていかなくては。
開発プロセスは自分たちの肌に合うものを…
- emadurandal
- 記事: 10
- 登録日時: 11年前
- 連絡を取る:
Re: 開発プロセスは自分たちの肌に合うものを…
私のやっているプロジェクトは、半分ゲーム、半分Webサービスなので、主にWebサービス的な部分を意識してテスト、と書きました。
Web系はSeleniumとかあるから、まだやりやすいですが、ゲームについては特に描画系は難しいですよね。
シーンをいくつか固定して、OpenGLでいうならglReadPixelsやらオクルージョンクエリなどのクエリ系、あとレンダーステートのチェックなど、位のような気がします。
どうしても、目視によるテストは入ってくるでしょうね。
大手ゲーム会社は、そこらへんのテスト体制がかなり整っているようです。
調べるとしたら、GDC(ゲームデベロッパーカンファレンス)のスライドやら英語の文献やらがメインになってくるかと思いますが、ご興味あったらぜひ調べてみてください^^
Web系はSeleniumとかあるから、まだやりやすいですが、ゲームについては特に描画系は難しいですよね。
シーンをいくつか固定して、OpenGLでいうならglReadPixelsやらオクルージョンクエリなどのクエリ系、あとレンダーステートのチェックなど、位のような気がします。
どうしても、目視によるテストは入ってくるでしょうね。
大手ゲーム会社は、そこらへんのテスト体制がかなり整っているようです。
調べるとしたら、GDC(ゲームデベロッパーカンファレンス)のスライドやら英語の文献やらがメインになってくるかと思いますが、ご興味あったらぜひ調べてみてください^^