[#TiDD] Scrum × PBL × チケット駆動開発 - 第9回 RxTstudy(Redmineやタスク管理を考える勉強会@大阪) -
『大学で学んだ事は役に立たない』というのは都市伝説。そんな思いを抱いた第9回RxTstudy の招待講演:大阪大学 井垣宏先生「Scrum × PBL × チケット駆動開発」でした(資料、あきぴーさんのまとめ、togetter)。
大学では専門知識が学べるメリットがあります。たとえば、Key Value StoreのひとつであるRedisのマニュアルを読むにも「計算量」を知らなければRedisのありがたみは半減します。大学で専門知識を学ぶメリットはあるでしょう。
とはいえ情報系の学部でないだけでなく、文系の学部を出た方でも、ソフトウェア業界で活躍されている方はたくさんおられます。後から専門知識を学んだなら、その方の資質や経験を生かす能力などの方が、長期的には実社会での能力差になるのかもしれません。
Project Based Learning
企業にいれば現場経験によって、そうそう大学には負けないと考えていました。専門知識で負けても、現場の経験がなければわからない事もたくさんあるからです。
しかし、アジャイル開発のワークショップやコースを見ると、必ずしも現場的ではありません。学ばなければいけないポイントを絞ってトレーニングが行われています。
それは実験計画法のように感じます。実験計画法では、評価対象以外の要素の影響を排除する事で、評価対象の効果を明確にします。例えば、被験者を2群に分けて一方はA・Bの順に実施して、もう一方はB・Aの順に実施するなどです。
講演された授業での、以下の内容を 教授目標とされています。
- Scrumフレームワークの理解 各イベントにおけるプロセスと成果物
- 各ロールの振る舞い
- プロセスの透明化(記録),検査,適応
- ・チームソフトウェア開発プロセス
- 構成管理, CI(Continuous Integration)等
- 実装,レビュー,テスト
- プロダクトスキル
- MongoDB, JavaScript, JavaによるWebアプリケー ション
これだけを数日で教える事はなかなか困難です。そこで、教えたい事をしぼって制約を与えられています。
先日の原田さんのScrum&DDDのワークショップでは、受講者にわからない形で教えたい内容が理解できるように導かれていました。そうする事で、自然と理解できるように考えられているようでした。
井垣先生の場合は、できる学生だけが実装してしまうなど影響を排除したい内容が多いので、自然と導く事は難しいのでしょう。逆に制約を明示する事で、教えていない事を明らかにされているように思いました。
現場で実践すべし
大学が現場に追いついてきたのなら、我々現場の人間はどうすれば良いのでしょう。たぶん、ワークショップだけで、わかったつもりになっていてはいけないのでしょう。それでは学生さんと変わりません。
また、大学の授業が文献を元にした偏りの少ない知識が得られるのに対し、企業人の講師は実践的である反面、講師の思い入れが入っていますので良くも悪くもサブセットになっています。
そこで、企業人がプロであるためには、学ぶ際も「現地・現物」を徹底すべきだと思います。学んだ事をチャンスを見つけて仕事に生かすのです。人から聞いたり、限定的なトレーニングでなく、現場で実践して自分のモノにする事が大事だと思います。
プロジェクトの経験を活かせ!
講演された授業ではチケット駆動開発で実践されていました。ホワイトボードでの打ち合わせとtracを併用されていた様です。
このチケットは作業の履歴として、プロセスの確認に用いられていました。きっとソフトウェア工学のリポジトリマイニングのように研究ネタにも利用されるのでしょう。
さて、現場をふりかえってみると古くから多くのメトリクスが収集されていますが、活用されているでしょうか?必ずしもチケット駆動開発である必要はありませんが、プロジェクトの経験をムダにせず、活用していくべきだと思いました。
講演後の議論の中で、ルール(制約)を守ってきちんとチケットとコミットを関連づけていたチームの話題がありました。厳密な評価ではありませんが、ルールを守っていないのは優秀なチームとあまり成果の良くないチームで、ルールを守っていたチームは特に優秀ではないが比較的成績の良いチームである傾向があったそうです。
作業者や作業方法によっては、経験を生かせるチケット駆動開発は悪くない選択肢なのかも知れません。
まとめ
インターネットブームの元になったアメリカのUNIXの普及は、大学でUNIXを学んだ学生がUNIXを就職先を選ぶ際の条件にした事がきっかけだそうです。Scrumやチケット駆動開発も、同じような普及の仕方をするのかもしれません。
現場の私達も、負けないように腕を磨いておかないといけませんね。
« [#TiDD] リポジトリマイニング - お手軽にリアルタイムの生データ - | トップページ | アジャイル開発の「考え方」と「やり方」を学べ »
「私のアジャイル」カテゴリの記事
- 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)
- Greedy algorithmと2割8割の法則 - Software Processes are Software, Too -(2021.12.12)
- 「任せて、任せず」「魚を与えるのではなく"釣り"を教えよ」(2021.08.16)
「チケット駆動開発」カテゴリの記事
- 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)
この記事へのコメントは終了しました。
コメント