「Redmineによるタスクマネジメント実践技法」の感想を集めてみたpart12 #tidd
久しぶりに「Redmineによるタスクマネジメント実践技法」の感想を集めてみた。
皆さんの感想を読むと色んな読み方があることに気づいて参考になる。
感想ありがとうございます。
【参考ページ】
clmemo@aka: Redmine によるタスクマネジメント実践技法 (小川 明彦, 阪井 誠)
(引用開始)
今までになかった、チケット駆動開発に主眼を置いた解説書。同じ言い回しが何度か出てきて、疎ましく感じることもある。それを差し引いても、一読の価値はあると思う。
最後にチケット粒度について。本書とぼくはチケット粒度について立場を異にする。これはその道の人でもちゃんとした答えが出ていない問題のようなので、自分のプロジェクトに合わせて試行錯誤する必要がありそう。
(引用終了)
感想「Redmineによるタスクマネジメント実践技法」 - yujioramaの日記
(引用開始)
devsumi2011 のセッションには参加できなかったけど、TiDD (Ticket Driven Development) は面白いと思います。
まちゅさんの記事の公開も結構昔なので、
「もうやってる」という現場も多いんじゃないでしょうか。
この本はそういった知識の集大成+実例になっててなんかすごいですね。
(引用終了)
Redmineによるタスクマネジメント実践技法 - takeboruta’s Blog
(引用開始)
Redmineを単なるチケット管理システムとしてではなく、すべての開発活動の中心において、「チケット駆動開発」という事に取り組むのであれば、読んで損はない本だと思います。
これから導入を検討している人、既に使っている人でも読んで参考になる部分があると思います。
Redmineはここ数年案件では必須ツールとして使っています。そういう意味で、既にRedmineを使ったシステム開発にどっぷり浸かっているのですが、それでも毎案件ごとに、同じような使い方をした記憶はありません。PJは案件によって色々と仕事の仕方が違ってくるのと同様に、その時々のメンバーもまた色々改善、指向錯誤を繰り返しながら開発案件というのは進んで行きます。その改善、対策に柔軟に対応できるからこそのRedmineであるし、Redmineで使える機能があるからこその改善というのもあります。
様々な作業を抜けなく、スムーズに実施し、複雑なソフトウェア開発を効率的に行っていくのに、今はかかせない存在になっています。
初めて導入するのであれば、本書などを参考にまずは真似から、既に導入経験がある人は、本書を読んで、同じ課題があれば、対策方法などを参考にするなどの使い方が良いと思います。
諸々の細かい部分は本書を参考にすれば良いと思いますが、一番のメリットだと思っているのは、開発に関わるコミュニケーションと見える化です。作業の抜けを出来る限りなくし、端折ることがなければ、チケット、タスクを管理しているリーダだけではなく、開発メンバー全員が知る事ができます。
(引用終了)
Redmineによるタスクマネジメント実践技法/小川 明彦, 阪井 誠:特に意味のない日記:So-netブログ
(引用開始)
アジャイルでの開発に、どのようにチケットを利用して開発を進めていくか、ということが主に書かれている。また、筆者らが実際にソフトウェア開発の現場で行ってきた経験から書かれており、参考になることが多い。Redmineでなくとも参考になることが多いと思う。
(引用終了)
Redmineによるタスクマネジメント実践技法, 小川 明彦 の感想 - ブクログ
(引用開始)
Redmineをこれから使用しようと思っている人、今使っているけれどいまいち上手く使いきれていない人にとって、非常に参考になることが書かれていると思う。
著者が実際に使用した経験をもとに書かれているので、現場で使うためのノウハウがたくさん詰まっている。
もっと早くこういう本に出合いたかった。
本書に書かれていることを試してみることで、自分の環境にあったやり方が見つけられると思う。
Redmineを使いたいと思っている人は、まず本書を読んでRedmineについて理解すれば、格段に早く使いやすいRedmineの環境を構築することができるだろう。
(引用終了)
(引用開始)
道具の使い方、運用の仕方は参考になるなと思って読んでいるものの、「自然と取り組むようになる」といった表現が登場し、Redmineと運用ルールを持ち込んだら成功したかのようなやや安直な表現が目についてしまった.
プロジェクトメンバーの構成員の様子と、道具やルールとの相性を解釈した章があったらより良いなと感じた.
(引用終了)
厳しい批判もありますが、処女作なのでご容赦下さい。
執筆した後にふりかえると、自分が経験したこと、理解したこと以上の内容は書けない事実に改めて気付かされます。
「Redmineによるタスクマネジメント実践技法」で紹介したアジャイル開発、PF、PMBOKやITIL、構成管理パターン、テスト管理などのノウハウはその界隈では既にプラクティスもアンチパターンも知られており、僕はそれら既に知られているプラクティスをチケット駆動開発に当てはめただけに過ぎないです。
でも、関係する情報をまとめて一つのコンテキストで翻訳しなおす作業は偉大な仕事の一つかもしれない、と最近思っています。
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- 「スクラムの拡張による組織づくり」のScrum@Scaleの感想(2024.03.31)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart2~プロセスのレイヤと達成目標のレイヤが異なる(2023.02.18)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart1~CSFはWBSみたいなものと捉える(2023.02.14)
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
- 現代日本人の弱点はリーダーシップ不足と生産性が著しく低いこと、そしてリスク許容度が著しく低いことだ(2022.12.23)
「Redmine」カテゴリの記事
- 「RedmineのUbuntu+Docker構築への移行」の感想 #redmineT(2024.11.24)
- 第27回redmine.tokyo勉強会の感想 #redmineT(2024.11.10)
- Redmineのバージョン設定でプロジェクトの設定方法が違う(2024.06.23)
- ウクライナのRedmine開発者が作ったRedmineテーマやプラグイン(2024.06.18)
- 第26回redmine.tokyo勉強会の感想~多様性はコミュニティが成功する重要な要因の一つ #redmineT(2024.06.15)
「ソフトウェア工学」カテゴリの記事
- アーキテクチャ設計はベストプラクティスを参照するプロセスに過ぎないのか?~Software Processes are Software, Too(ソフトウェアプロセスもまたソフトウェアである)(2024.09.22)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「システムアーキテクチャ構築の原理」の感想(2024.05.06)
- ソフトウェア工学の根本問題から最近のソフトウェア設計を考えてみる(2024.03.03)
- マイクロサービス設計は従来のアーキテクチャ設計と何が違うのか(2024.01.02)
「プロジェクトファシリテーション」カテゴリの記事
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
- 「世界を動かすプロジェクトマネジメントの教科書」の概念図(2022.01.16)
- 【資料公開】チケット駆動開発の解説~タスク管理からプロセス改善へ #redmine(2022.01.14)
- 昭和の管理者の承認処理は判子押印、令和の管理者の承認処理はいいねボタンを押すこと(2021.12.31)
- チケット駆動開発のプロセスとチケット管理システムの全体像 #Redmine(2021.12.28)
「チケット駆動開発」カテゴリの記事
- 第26回redmine.tokyo勉強会の感想~多様性はコミュニティが成功する重要な要因の一つ #redmineT(2024.06.15)
- チケットはデータでとプロセスの二面性を持つ #redmine(2023.12.24)
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
- プロジェクト管理の基本はテーラリング、Redmineはプロセスをテーラリングするツール(2022.04.21)
「Agile」カテゴリの記事
- 「世界一流エンジニアの思考法」の感想(2024.12.08)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「スクラムの拡張による組織づくり」のScrum@Scaleの感想(2024.03.31)
- ソフトウェア工学の根本問題から最近のソフトウェア設計を考えてみる(2024.03.03)
- 「GitLabに学ぶ 世界最先端のリモート組織のつくりかた」の感想(2023.12.10)
コメント