[#redmineT] 裾野が広がるRedmine「チケット駆動開発導入のヒント - 自律と規律 -」
redmine.tokyo 第9回勉強会で発表させていただきました。
今回の勉強会は入門的な内容だったこともあり、80名を超える方に参加していただけました。そのうち初めての方の比率が高く、懇親会には約1/3の方が参加されました。
以前、Redmineはキャズムを超える - redmine.tokyoに参加して -と書きましたが、本当に裾野が広がってきた様に思います。
これまではRedmineの利用方法にはAsIsとToBeの2つのの進め方があると説明してきましたが、講演をしていると導入時点で失敗している相談を受ける事が多くありました。そこで、プロセス改善やPDCAサイクルと管理者・開発者の利益の視点から導入方法のヒントを説明しました。
うなずいてくださる方も多かったのですが、Tweetでの反応で予想外のものもありました。「ピンチはチャンス」というタイトルでプロジェクトが大変でどうしようもない時に導入すると良いと説明したのですが、「無理だ」という反応がありました。
プロセス改善は効果が見込めるから実施するもので、効果がないなら導入してはいけません。みんなが頑張る方が効率的に乗り切れるなら、そうすべきです。
ピンチのときにチケット駆動開発をして効果があるのは、何をすべきか見えていないので気付いた事を共有するとか、混乱の原因がコミュニケーションや情報共有にある場合です。そのような問題をチーム全体で共有して、負担よりもメリットが大きい場合のみ導入すべきです。
そのような注意書きがなかったので、嫌な経験をした方には納得できなかったのでしょう(もし、私の過去の発表がきっかけになっていたらごめんなさい)。
なお、スライド中で参照している乗松さんのスライドのPDFはここ(Jaspic)です。
追加でお話しした日本Redmineユーザグループ発起人会のスライドのPDFはここに置きました。
これまでも東京はredmine.tokyoと大阪にはRxTstudyというコミュニティがありましたが、日本全体のユーザの場をつくりたいと思っています。Facebookのグループや、地方での普及協力、開発者への支援など夢は広がりますが、先ずは有志で集まりませんか?というお話をしました。
ご興味のある方はPDFをご覧の上、Twitter (@sakaba37) などでご連絡ください。
« 反復型開発の混乱 - Iterative and Incremental あるいは 繰り返し - | トップページ | プレゼンテーションの時間を調整する方法 »
「チケット駆動開発」カテゴリの記事
- One fact in one placeとチケット駆動開発 - Software Processes are Software, Too -(2021.12.21)
- マルチスレッド処理と進捗管理・配員・作業分割/割り当て- Software Processes are Software, Too -(2021.12.20)
- カプセル化と組織パターン - Software Processes are Software, Too -(2021.12.20)
- [#TiDD] ポケモンGOにチケット駆動開発のポイントを学ぶ(2018.05.01)
- [#TiDD] プロジェクトを成功させるチケット管理(2017.07.02)
「Redmine」カテゴリの記事
- [#TiDD] プロジェクトを成功させるチケット管理(2017.07.02)
- Redmineが得意なプロジェクト(2016.09.20)
- 『Redmine実践ガイド』に書き忘れた事 - 管理を容易にするチケット番号の一意性 -(2016.08.11)
- [#Node-RED] Node-REDでTwitterのDMからRedmineのチケットを作成する(2016.04.17)
- [#Node-RED] RedmineのREST API を呼ぶ(2016.04.17)
この記事へのコメントは終了しました。
コメント