masuidrive on rails » Blog Archive » masuidrive的プロジェクトの方針



このプレゼンは超同意しまくりで、プログラマ脳の人にとってはすごく理想的でプラグマティックな進め方だと思う。
自分が今の会社で悶々としていることはこのスライドのとおりやればほぼ解決されると思う。

でも今の自分の立場に置き換えて考えた場合、これはこのままでは絶対に無理だ。

そもそもmasuidriveさんのブログを好んで読んでいるような人たちとならあえてこのようにプレゼンしなくともうまくいく気がする。

トラックバック先で仕様書をどうやってsubversion管理するかと悩まれている方がいた。
そうwordやexcelは差分の確認ができないのだ。

それに対しmasauidriveさんはexcelは使わない方向らしいのだが
少なくともプログラマ以外の人にこれを強制するのはかなり厳しいと思う。
個人的にはtracやtwikiなどの変更履歴がすべて保持できるようなwikiで設計書を書くのが好きだが
若い世代はともかく（wiki慣れしているしこれから覚える世代なので）、非技術職の人や職業プログラマの人はほぼ納得してくれない。

やはりxdocdiffを試してみるべきか。

上記のようなことはmasuidriveさんも重々承知しているようで
masuidrive on rails » Blog Archive » 続masuidrive的プロジェクトの方針
において

この文章自体の前提が普通の会社の組織じゃないので、そのまま参考にはちょっとならないかもしれません。ただ自分の考えをプレゼンにするというのが、すこしでも普及してくれると嬉しいなと思ってます。プレゼン資料を作りつつ、脳内プレゼンをしていると、意外に抜けている自分に気がつくので。

　この対象のプロジェクトメンバーは波長の合う人を社内公募などで募って、そもそもこれを受け入れて一緒にやっていける人を前提に考えています。なのでかなり上段から見たような文章になっていますw ウチの会社自体は、とがった会社ではないので他部署で適用することは、あまり考えてません。

　私が個人でやってきた方法論が、どこまで組織で通用するのか、どこで行き詰まるのかを自分で楽しみにしてます。それを糧にもう少し一般化した方法論が書けないかなとも思っています。

と言うことらしい。

僕としてもどこで行き詰るのか、果たして行き詰らないのか、どうやったらそれなりの組織でも適用できるのか、などなどものすごく気になることだらけなので
これからも参考に追っていきたいと思った。

masuidrive on rails » Blog Archive » プロジェクトの始まりはTracから
なんかは実践的ですごく参考になる。
個人的におおっと思ったのは↓ここ

次にコンポーネントを変更します。

trac-admin ./ component rename component1 コード
trac-admin ./ component rename component2 仕様書
trac-admin ./ component add 会議 somebody

コンポーネントはうまく活用すればかなり色々対応できるんだなぁと思った。
あとはフローのカスタマイズがどれくらいできるかだなぁ。