サウスポーなエンジニアの独り言サウスポーなエンジニアが日々感じた、気づいた、学んだことを徒然と書いています。2017.12.31Tweet過去のメモを整理していたところ、2年程前のプロジェクトで悩んでいた時に書いたメモが出てきたので備忘録としてアップしておきます。System=問題追跡システム...こういう呼び名だと今、初めて知りました)に登録するチケットの粒度、単位です。背景Railsを採用したWebシステムを4,5人で構築するというものでした。そのPJで、本格的にITSを使って「チケット駆動開発」(的)なことをしてみようとなったわけです。やってみたMVCモデルで分割していたので、機能毎のモデル/コントローラ/ビューをそれぞれ1つのチケットとして登録してみました。その結果なかなか「チケット駆動開発」のリズムになりませんでした。?(推測)1:チケットの粒度が大きすぎた。(設計の善し悪しもありますが)当時はコントローラにそれなりの量の業務ロジックが実装されていました。下手すると1日以上かかる実装量を1枚のチケットにしてしまったのが原因ではと思います。2:Railsの開発スタイルとチケットの単位が合っていなかった。Railsでは頻繁にMVC間を行き来して、分業したりせず開発するスタイルが合っていました。ところが前述したようにチケットはMVC単位だったため、MVCともちょくちょく進んではいるものの...という感じで、チケットの完了による進捗が見えませんでした。次やるとしたらどうするだろう?これの解は出ていません。今のPJ(SAStruts+S2JDBCで3,4人)では(粒度もまちまちですが)少なくともタスク漏れがあるよりはマシ...という考え方から、「まずは登録!」のスタイルで運用しています。感覚的には、数分程度で終わる、かつ、チームメンバーの確認(レビューや仕様確認)が不要なタスクはチケット登録しないようにしています。朝会などの中で、チケット間の親子関係を作るなりして、「進捗が見える」単位に調整しているという感じです。なんかこの辺の運用方法は、メンバーの人数、スキル、マインドにもよるので、絶対的な正解はないと思いますが、議論したりして深掘りしたい内容です。※注意:この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。旧館よりJavaの格言―より良いオブジェクト設計のためのパターンと定石[読書感想]仕事でJavaを使ってのシステム構築をしています。勉強したり、資格を取るためJavaをさわることはあっても仕事は初めてです。思い立って以前に買って積読していた↓をちゃんと読んでみました。■(Javaの格言―より良いオブジェクト設計...旧館より教えてもらう、教える時に気をつけていること仕事やバレーで教えてもらったり、教える(そこまでいかなくてもアドバイスする)ことが、ちょくちょくあります。伝え手の場合に気をつけていることです。「××社内システムの再構築の件ですが、○○ベンダーさんに発注することになりました」と報告を聞いていて、冒頭のことを思いました。会社を移ることになりました2012年6月末で会社を移ることになりました。(何度か転職をしているのですが)今のところ、社会人経験の中で一番長く所属していた会社になっていました。入社後しばらくして、(弊社では)お客様向けとして開発実績の...仕事のやり方トラックナンバーを考えるプロジェクト上で強く意識するキーワードに「トラックナンバー」があります。意味は「トラックに轢かれるとプロジェクトの遂行が困難になる最少の人数」です。「会社を移る」ことと「部署・プロジェクトを移る」こと主に月末/月初に「退職します(した)」エントリ、「入社します(した)」エントリやつぶやきがちょくちょく見受けられます。弊社からも新天地へ行った方もたくさんいて、中には「おぉ、あの人もいなくなるのか...寂しいなぁ」という方もいます。コメントをキャンセルコメントを投稿するにはログインしてください。サウスポーなエンジニアの独り言.ホーム検索トップサイドバータイトルとURLをコピーしました。