ページ

2011年12月21日

とある開発の風景

これは、アドベントカレンダーとは一切関係ありません。では、アリエルじゃどんな風に開発しているのか、ってお話です。開発と言ってもプログラマに限ったお話です。めんどいのでプログラマによる機能の追加とバグの修正を開発って書きます。

開発は基本的にすべてチケットを通して行います。チケットの粒度は様々です。大きな粒度のチケットはプログラマの判断で細分化されて行きます。大元になるチケットは、プロジェクトの開始の時に偉いヒトによって各プログラマに割り振られます。開発者によってある程度の持ち場が決まっているので、割り振られるときはその持ち場と今後の進んでいって欲しい方向とスキルによって分けられます。偉いヒトがざっとした工数見積もりも済ませているので、プロジェクトの工数があふれない程度の量です。

バグ修正的なチケットは、バグを直せばいいだけです。大きな機能追加は全く違った開発プロセスを歩むので、ここでは書きません。適切な粒度の機能追加的なチケットは、大まかな方向性は決まっていますが、詳細は決まっていません。基本は担当開発者がまず、外部仕様策定から始めます。仕様は、チケットをあげたヒトやプロジェクトマネージャ、プロダクトマネージャと相談しながら決まっていきます。プロダクトマネージャがこうしたいと思っても、表向きは担当開発者が決める形になっています。ただ、あまりにも紛糾していて物事が進まないときは、偉いヒトの強権が発動されます。

機能の合意が取れると開発が始まります。プロジェクトの開始の時に、大体の締め切りを決めてそれにむけて開発を行います。2点見積もり(だっけ?)にした方がいいと僕は思うのですが、プロジェクトマネージャがうんといわないので、その締め切りに間に合うように開発します。

開発中の質疑応答などはほぼチケットを通して行われるので、ログとして機能します。実装が終わると単体テストを開発者が行って問題ないと、コードレビューが行われます。これは、大体横にいる人にやって貰います。コードレビューを通さずにコミットするヒトもいますが・・・。レビューが通ればコミットします。

コミットするとJenkinsさんとか自動テストととか、いろいろチェックされます。問題があるとチケットは差し戻されます。それ以外にも、大量のコミットをピンポイントで眺めている変人がいて、変なモノをコミットするとチケットが差し戻されたり、勝手に修正されたりします。怖いですね。 

それからドキュメントがチケットに書かれます。 レビューや実装前にドキュメントを書くヒトもいますが、それは人それぞれです。書かないといけない内容は、リリースノートに書く機能の説明とそれに付随する情報、テスターさんがテストするための情報とさらに詳細にテストした方がいいところ、実装方法のまとめとか、バグであればその原因とか。

そして、チケットが閉じられるとテスターさんが再度いろいろテストします。開発者とテスターさんの境界線上のことはいいたいこともありますが、それは別の機会に。テスターさんがテストを行って問題があると差し戻されてまた、修正します。テストがクリアすると、ドキュメントに不備がないかチェックされ、それが終わると本当の終了となります。ふー。

至って普通でおもしろみがないですね。 

 



0 件のコメント: