「チケット駆動開発のフレームワーク」
デブサミ２０１３【14-B-5】について自社で資料と共に共有したくて、個人的にとぅぎゃりました。（^^;
「チケット駆動開発のフレームワーク
～現場の経験知からパターン言語へ」
資料：http://www.slideshare.net/akipii.oga/devsumi-ogawa-20130214
-
DiscoveryCoach
- 1319
- 0
- 0
- 0
-
- いいね！0
あきこ@しばらくしばらく趣味のつぶやき多め
@akiko_pusu
自律的なチーム。マイクロマネジメントしすぎない。『濡れぞうきんは絞らない』（本田宗一郎氏からIIJ鈴木氏への言葉。）#devsumiB
2013-02-14 15:50:48
NAKAMURA Shinya 中村真也
@shinnkm
SRA阪井誠氏：S/W開発は常に新しいことへの挑戦なので、チケット駆動開発で履歴の蓄積、課題・タスク・計画・知識等の共有をすると良い。チケットの起票権限は皆に与え、種類や属性は少なくして起票し易くする。棚卸しは適度に。 #devsumiB
2013-02-14 15:52:15
鎌玉 大
@kamatamadai
#devsumiB よく聞かれる質問。チケットの粒度、複数チームのタスク管理。判断基準が暗黙知なので明確にできない。チケット駆動はアジャイル開発なのか？
2013-02-14 15:52:22
joker1007 (アルフォートおじさん)
@joker1007
githubとredmineの連携をもうちょっと真剣に考えるか。Repo Hook APIとSinatraでゲートウェイ作ってごにょごにょする感じで。 #devsumiB
2013-02-14 15:54:12
鎌玉 大
@kamatamadai
#devsumiB チケット駆動開発を体系化していきます。ツールの説明を排除（RedmineでもPost itでも可能）。パターン化
2013-02-14 15:54:52
joker1007 (アルフォートおじさん)
@joker1007
チケットの粒度やタスク管理については、そもそもコンテキスト依存が強烈だから定式化しづらい。 #devsumiB
2013-02-14 15:55:47
はろ
@hidenorly
#devsumiB 製品の変更時管理すべき対象プロセス（チケットは製品に従う）。チケットはワークフローで制御される（チケットはワークフローに従う）。チケットは成果物や仕様ではない（成果物は構成管理に従う）
2013-02-14 15:58:08
はろ
@hidenorly
#devsumiB TiDDの原則。ticket first. SW開発の作業も課題も障害もチケットに。成果物は構成管理に従う。コード、仕様書は構成管理へ。Wiki, ticket集計に、議事録や報告書を入れる。履歴管理不要
2013-02-14 15:58:30
joker1007 (アルフォートおじさん)
@joker1007
個人的にはredmine捨てて、github issueとpivotalに移行したい所がある。 #devsumiB
2013-02-14 15:58:48