チケットという資産を有効活用する - rabbit2goのブログ
ソフトウェアの開発プロジェクトが終わると、Tracには大量のチケットが生み出される。やれやれ、一件落着、こんな障害情報なんて見たくもないという人が多いかも知れないけれど、実はこの情報は次の開発に生かすべきヒントを含む重要な情報だと思っている。こんな貴重で、しかも面白い情報を見捨ててしまうのは非常に勿体ない話だ。 例えば、wikiページに障害のまとめを載せて大凡の傾向や注意すべき点などを整理しておき、振り返りの時の反省材料に使ったり、チェックリストやガイドライン更新時の参考材料にしている。もちろん、Tracのチケットはずっと残っているのでいつでも誰でも参照出来るけれど、たくさんのチケットを一度に見せられてもなかなか理解出来ないし、全体像を把握するのは難しい。そんな時にこそ、このような要約ページが有ると有り難い。 下記は、障害の原因をキーとした分類例であり、なぜなぜ分析の如くさらに深く追求して
仕様書は作成過程が大切 - rabbit2goのブログ
ソフトウェア開発の現場で良く聞く発言。 「仕様書をキッチリ書こう」 「きちんとした仕様書を書ける人が欲しい」 「仕様書に記載漏れが無いようにしてくれ」 仕様書とは、完成した文書が一つ有れば全てが片付くような性質のものではなく、何をどう作るかという検討内容を記録として明文化したものだ。だから、仕様書の作成行為そのものが設計行為であり、個々の対応項目を明確にして、設計上の漏れ・不備・矛盾を早期に見つけ出すための重要な作業だ。単に、これをやる、あれをやるという程度の文章の断片が並んでいるようでは、それは仕様書としての役割を果たしてない。 後のテスト工程で火を噴くような開発プロジェクトに共通しているのは、そのような明確な設計工程が欠如している点だ。仕様の検討を疎かにしたり、漏れや矛盾の確認を事前に行っていない以上、潜んでいた問題点が顕在化してくるのは当然のことだ。こんな時「仕様書が無いから」という
やっぱりベテランは使えない - rabbit2goのブログ
ソフトウェア開発の現場にいるベテランには、他の人の手本となるような達人もいるけれど、その一方で見習ってはいけない悪い見本の人も少なからずいる。その一例。 開発資料を作らない 「ソースコードを読めば分かる」「資料を書くのは労力の無駄」と豪語して資料を何も作らない。後からフォローする人は、そもそも何をやっているコードなのか？などコードの設計思想や背景を読み取れないので苦労する。 自分の立場を分かっていない 開発チームを良い方向へ導くとか、若手の指導を行うという積極的な態度に欠ける。チームへの協力的な姿勢が無く、組織のあり方とか、ビジネスの方向性といった視点を持っていない。 知識を共有しない 「自分の持っている知識は大したことない」と謙遜するそぶりを見せながらも、自分からは決して情報発信を行わない。他人の情報には文句を付けるのに、自分からは何も出そうとしない。 新しい技術に挑戦しない 歳をとって
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
