restofwaterimpのぎじゅつMemo

SIerに所属してます。企画から運用までやってます。現状、プロジェクトをスクラムで回したい!と試行錯誤中です

【振り返り】Redmineをソフトウェア開発に導入して2年使ってみて(初期の頃)

今のお客さんの開発に携わり、割とプロジェクト管理に関するルールなども自社ルールに縛られず、お客さんのルールにも縛られずに入れる環境であったので、Redmine入れて管理したいなと思い導入してから約2年。

 

やってみて、個人的に便利 or あと少し・・・ということを勝手に振り返ります。

ただ、結論的に言えることは「Excel」管理やMSProjectには戻れないなと。

自分がやりやすいやり方に今は行き着いているので、これが正解と捉えず、こういう例もあるんだと捉えていただければ幸いです。

(スクラムっぽくプロジェクトもスプリントも設けて実施していましたが、ここではRedmineの使い方のみに焦点を当てています。)

 

1.導入した経緯

これまで進捗の管理にはMS Excelを利用してくる場面が多かった。なんでプロジェクト管理の手法が旧態依然のまま誰もが、それに従っていたのかよくわからず、「ルール」という縛りにあがらうことできず過ごしてました。

そこで、まあある意味実験的にいろいろと試すことができる環境に置かれたものだから、「アジャイル」「Lean」というバズワード(まあ、2015年ごろ入れたので、もう普通に使われてますね)に引かれ、「まずは使ってみよう」と自分のチームとお客さんに宣言して利用し始めました。

※かんばんを壁に紙で貼るということも考えましたが、お客さん先で複数ベンダーが入っている関係上、セキュリティ上NGでしたので、Redmineを利用しました。

 

2.初期のころ

Redmineの入門本を購入し、デフォルトの機能のみで管理してました。

(今考えると無鉄砲で計画性がなかったなと反省・・・)

 

Redmine超入門 増補改訂版 (日経BPムック)
飯田 治行 大澤 文孝 大和田 裕 小川 明彦 楠川 智久 阪井 誠 内藤 淳
日経BP社 (2015-06-30)
売り上げランキング: 345,042
この本をみながらBitnamiでPCにインストールし、Redmine運用。
(この当時はVersion 2.6を入れていたはず)
 
この時点で実施していたのは、RedmineSVN(tortoisesvn)で、
SVNRedmineは連係してませんでした。。(知らなかった)
また、全体を通してですが、うちのチームの初期の力ではTDDができなかったので、テスト方法はテストコードによるテストではなく、静的コードチェックと画面を利用したテストが中心です。
 

どう管理していたの??

「トラッカー」で作業を分類してました
良かった点1 
チケット登録するとき、トラッカー別に「設計」「実装」「テスト」「レビュー」と分けて登録できるので、登録は楽でした。
ある設計のチケットに対し、「実装」トラッカーを子チケットに。
ある「実装」チケットに対し、「テスト」「レビュー」のトラッカーを子チケットに。
 
先にWBSのようにチケットを登録し、ガントチャートやチケット一覧をみながらやれるのかなと思っていましたが・・・。
 
良かった点2
優先度をつけられるのはメンバにとって良かったらしいです。
どれから着手すべきか口頭で伝えられても忘れてしまうので、書かれているといいらしい。
同じように期日を切ってくれているとメンバ自身でスケジュールコントロールするときの一つの目安になっていいみたい。
 
問題点1 階層が深いとガントチャート以外で関連がわからない
 
階層を深くするとチケット一覧を確認しても「???」となりよくわからない。
進捗もよくわからないし、チケット数の管理が3桁越えると何が何だかわからず。
当時MAXで500くらいのチケットがアクティブで登録されていました。
やらなければならないタスクをとりあえず書いたのですが、「開始予定日」「完了予定日」でしっかりコントロールしないと「未着手」で遅延なのか、「まだやる必要ない」のかをチケット一つずつ内容をみないと行けなかったので、余計な管理工数がかかっていました。
 
 
問題点2 チケットの移動に制約が・・・
 
親子関係、関連付けをチケットにつけていると「ここからここにこのチケットは移動しよう」と思って動かしても、制約違反にかかる。。。移動できないじゃんということが発生。自由にチケット移動できず、どうしましょ、という状態でした。
 
問題点3 要件との紐付けをしていなかったので、まとまりがわからず
 
バグ管理や課題管理で利用している場合には作成したトラッカーに対して、それをこなせば、TODOとしては終わりですが、ソフトウェア開発となるとそうはいかず。
設計チケットをトップに記載したため、「あれ、この設計チケットってどの要件の話だっけ」とか設計チケット通しに関連性をつけていなかったので「このチケット直すとどこに影響するのか?」というのが第三者がみてわからなかった。
完全にチケット管理する前のワークフローなり、トラッカーの付け方の計画ミスでした。
 
どう解決したの?
 
プラグインというのを入れるのにこのころは抵抗があり(挙動を自分で管理できなかった)、カスタムフィールド等で解決してました。
 
解決策1 親子関係はつけない。カスタムフィールドで管理
 
とりあえず、親子のチケット関係は外しました。代わりにカスタムフィールドで属性を追加しました。
例えば、「トラッカー」でコントロールしていた内容を「作業内容」というカスタムフィールドを作成し、この列挙項目に「設計」「実装」「テスト」などを追加。
また、要件と紐づけるために「画面」とか「要件」というカスタムフィールドを作成し、列挙項目に要件名や画面ID等を描き、このカスタムフィールドでまとめられるようにしました。
 
解決策2 題名でも何しているかわかるように
 
解決策1では管理して、データを収集、集計するためには便利ですが、日々、メンバがチケットを確認する上では「わざわざチケットを開かないとなんの作業かわからない」という問題がありました。そこで、ありきたりですがチケットの題名に【設計作業】や【実装】など接頭に作業内容をつけてなんのチケットを書くかわかるようにしました。
 
 

ここまでで良くなったの?

この管理でかつ、途中でRedmineSVN連係も追加し、約1年はこの設定状態で管理をしました。

手持ちのチケット数が少ないとメンバも余裕があることと、自分自身のスケジュール管理もできていたのですが、追加・変更案件とテストによる指摘事項がチケットに混在してくると「どのチケットからやるの」「優先順位をどうつけるの」というのが錯綜し、若干パニック状態になりました。

 

また、内部管理はチケットやRedmineの内容で説明すればある程度状況の把握はできていましたが、第三者や上位の管理者に説明するときにスケジュールを数字化するのに一苦労しました。

チケット数の総数、消化数、残数。予定時間と実績時間から想定される予想残工数。バグ発生の予想数、消化予想工数から着地がどれくらいになるのか・・・。チケットから作成するのにデータを抽出し、こねこねしなければならず、プロジェクト管理が楽になったのか?というのが若干疑問でした。

 

しかし、とは言っても、Redmineに記載された内容がトレースできていたので、「書かれてさえいれば」何に困っていたのか。何がうまく言っていたのかを分析するのには大変助かりました。

 

 

つづく

 
 

メモ:文字列の部分分割とeval(数学パズルQ2)

今回のお題を実施するのには数値もしくは文字列の間に四則演算を入れなければならなかった。

 

そのため、自分は「部分参照とか文字列分割だね」と思い、

 

Ruby

 hoge[n,m] ・・・ nには開始位置(0開始)、mには終了位置を指定する

 

C#

 hoge.substring(n,m)・・・nには開始位置(0開始)、mには長さをしていする

 

として、取得した値をもとに四則演算を用いて書いていた。

 

しかし、いろいろな四則演算のパターンを書くのはすっきりしないなとと思い、ページをめくったら、evalを利用していた。

 

C#でやろうとすると自前でevalを作成するか、他のスクリプト言語(例えば、JavaScript)を利用するのも一つ手らしい。

 

書籍には逆ポーランド記法を利用するとも載っていた。

結構なソースコード量になると思われる・・・ので、作成しやすい言語で今は考える元しようと思う。。。

 

また、eval利用するとコンパイラを通してや、IDEを通じて、エラーチェックや警告が走らないのが欠点。

頭の体操?にはよさそうだが、実際にものを作成するときには慎重に利用することが必要に感じた。

文字列を実行時に処理するだけなので、人間系で事前に処理の正しさ(仕様と違うか、セキュリティ的に文字解析の結果が大丈夫か)が必要ですね。

 

メモ:進数の変換と文字列の反転(数学パズルQ1)

数学パズルをやり始めました。

仕事でソースをチェックすることはありますが、コーディングすることが少なくなってきているので、楽しみながら、パズルを解いてます。

 

最近扱っている言語が、RubyC#なので、書きやすさってのが比較できないかなと。

 

Q1で利用したメソッド

 

進数の変換

Ruby

hote.to_s(num)    # numには変換したい進数

 

C#

Convert.ToString(hoge,num)   -- hogeには指定の数値、numには変換したい進数

 

文字列の反転

Ruby

  hoge.reverse

 

C#

 string.Join("" , hoge.Reverse())

 

 普通にhoge.Reverse()を記述すると、Iteratorが戻り値になるため、文字列にならない。

 また、配列に対して、Reverseをすると配列の添字の順番を逆で並び替えるということが行われる。

 

 

Q2へ続く

 

 

【メモ】アスペクト指向とオブジェクト指向

達人プログラマーの新装版の言葉で余り知らない言葉を調べてまとめてます。。。

 

AOP(Aspect Oriented Programming)

 OOPでうまく分解できないソフトウェアの「様相」や「側面」といったものが存在し、

 このような「様相」「側面」は複数のオブジェクトにまたがる操作となる。

 これを「横断要素」という。

 例として、プログラムの実行の様子を記録すするロギング操作がある

 横断要素はコード中に散在し、すべてを把握し管理することが難しい。

 その為、こうした要素を「アスペクト」としてモジュール化し、分解することで、把握・管理・変更を容易にする。

 OOPを補完する。

 

https://yo1000.gitbooks.io/self-study-spring/content/chapter7.html

 

インたセプタを織り込むタイミングは2つ。

1.コンパイル

 独自に用意されたコンパイラを利用することで、コンパイルのタイミングでインたセプタを織り込む

  代表例・・・AspectJ(Javaの拡張言語)

2.クラス・ロード型

 特別な実行環境(コンテナ)を提供することで、実行(クラス・ロード)時にいんたセプタを織り込む

 

 

OOP(Object Oriented Programming)

 属性(データ)と操作(メソッド)の集合であるオブジェクトをソフトウェアの分解単位として扱う

 コードの再利用性、継承、多態性を利用し再利用可能なモジュールを作成する

 

 

http://e-words.jp/w/AOP.html

 

http://itpro.nikkeibp.co.jp/article/COLUMN/20051122/225023/

WPF開発をするために読んだ本

昨日、自社の上司と面談を行った。

「これまでCOBOL開発ばっかりだったけど、どうやって今の開発ができるように馴染んだの?」と

と問われ、

「本を読んで、ちょっとコーディングしてみて」と軽く伝えたのですが、

何を購入してたのかな〜〜というのをちょっと振り返り。

 

<参考となる方>

今回のプロジェクトの役割はプログラマーではなく、プロジェクトリーダーですが、設計も開発もテストもしている身でした。

ちなみにこれまでのC#経験はなし。WPFも初めて知ったという人間です。。。

そんな人でも開発者と会話しながらプロジェクトが進められるようになるために・・・という書籍だと思います。

 

 

C#の知識

購入、図書館を元に参考。猫で基本を知り、独習C#はパラパラと見ました。

プログラマーとして参画するならば、独習C#までしっかり読み込むのがいいかと。

他言語のプログラム経験があれば、十分かなと。

Effective C#は購入したけど、自分自身には少しハイレベルだった。

ただ、開発メンバーと話をするときの話のきっかけとして利用。

 

猫でもわかるC#プログラミング 第3版 (猫でもわかるシリーズ)
粂井 康孝
SBクリエイティブ
売り上げランキング: 275,968
独習C# 第3版
独習C# 第3版
posted with amazlet at 16.02.15
ハーバート・シルト
翔泳社
売り上げランキング: 23,934
Effective C# 4.0
Effective C# 4.0
posted with amazlet at 16.02.15
ビル・ワグナー
翔泳社
売り上げランキング: 175,035

■.NETフレームワーク

 難易度の順番で書きました。

 .netの内面がわからないとも、.netFrameworkがどこを包含しているのか。

WPFの基礎知識やLINQのさわりもここで知ることも出来ます。

ただ、読んだからといってすぐ開発できるか・・というとちょっと違うなと。

全体概要をつかむための書籍という印象です。

 

.NET開発テクノロジ入門 2014年版 VisualStudio2013対応版 (MSDNプログラミングシリーズ)
酒井 達明 山田 祥寛 小高 太郎 中原 幹雄 芝村 達郎 和田 健司
日経BP
売り上げランキング: 200,284
C#によるiOS、Android、Windowsアプリケーション開発入門 (MSDNプログラミングシリーズ)
エッセンシャルWPF:Windows Presentation Foundation (Programmer's SELECTION)
インタフェースデザインの実践教室 ―優れたユーザビリティを実現するアイデアとテクニック
ひと目でわかる Visual C# 2013/2012 アプリケーション開発入門 (MSDNプログラミングシリーズ)
アジャイルソフトウェア開発の奥義 第2版 オブジェクト指向開発の神髄と匠の技
ロバート・C・マーチン Robert C. Martin
SBクリエイティブ
売り上げランキング: 20,458
スクラム 仕事が4倍速くなる“世界標準”のチーム戦術
ジェフ・サザーランド
早川書房
売り上げランキング: 88,766
スクラム実践入門 ── 成果を生み出すアジャイルな開発プロセス (WEB+DB PRESS plus)
貝瀬 岳志 原田 勝信 和島 史典 栗林 健太郎 柴田 博志 家永 英治
技術評論社
売り上げランキング: 243,320
アジャイルなゲーム開発 スクラムによる柔軟なプロジェクト管理
SBクリエイティブ (2013-11-15)
売り上げランキング: 72,379
アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣
Venkat Subramaniam Andy Hunt
オーム社
売り上げランキング: 168,799
リーン・スタートアップ
エリック・リース
日経BP
売り上げランキング: 6,419
実践 反復型ソフトウェア開発
津田 義史
オーム社
売り上げランキング: 541,253
UMLモデリング入門
UMLモデリング入門
posted with amazlet at 16.02.15
児玉 公信
日経BP
売り上げランキング: 40,609
UMLモデリングの本質 第2版
児玉 公信
日経BP
売り上げランキング: 148,534
■テスト
システムテスト自動化 標準ガイド (CodeZine BOOKS)
Mark Fewster Dorothy Graham テスト自動化研究会 伊藤 望 玉川 紘子 長谷川 孝二 きょん
翔泳社
売り上げランキング: 24,097
JUnit実践入門 ~体系的に学ぶユニットテストの技法 (WEB+DB PRESS plus)

【メモ】ITCAの研修を受けて

プロジェクトマネジメントの体系をしる講座を受けた。

 

PMI系のPMBOKの講座を受けていたが、やっぱり体系集のため、うまく現場に還元できないなと感じていた。

どうも、PMI以外にPM系の体系をまとめているものは他にもあり、イギリス系、ドイツ系などあるようである。

 

 

特に、事例集的に書いてあるのは

イギリス系の

www.axelos.com

 

axelosというものであった。

 

もちろん前編英語みたいですが、ポートフォリオから運用系のITILまで幅広くBestPracticeが記載されているようです。

 

後で、参考として見てみることに。

 

この研修で一番印象に残る講師のコメントは

「実行権限も予算権限も決断力もない人とアジャイル開発をしてはいけない。」

ということ。

 

ごもっともということ。プロダクトオーナーに携えるのはそれなりの権限を持つ人を

持ってこなければ、混乱の元になるのは目に見えている。

 

そんな経験も私もしているので。。。

 

 

スクラム始めました-スプリント5実施【#3】

ずいぶん間が会いてしまいましたが・・・

 

4月より進めてきたスプリントもすでに5サイクル目に。

スクラムっぽくは実施しているが、なかなかうまくいかないなということが

多く出てきているので、自分の整理を込めて今回は記載。

 

<遂行が難しい点>

1.新規開発での難しさ

開発フレームも整っておらず、利用する言語について、深い見識があるメンバーがいない中で始めて入る部分もあり、開発の生産性が高まらない中、スプリントを繰り返している。

徐々に部品は出来上がっており、作り始めにおけるコストは下がっているのだが、要求の変化に伴う、機能の変化にうまく対応できておらず、波に乗れない。

 

2.ふわふわすぎる要求

プロダクトオーナーとの打ち合わせを実施しているが、要望ではなく、確認会になっているのも原因と考えている。本来ならば、オーナー側に業務プロセスのイメージを固めてもらい、「こうやって進めたい」というのベースに、システムとしてはどうするというのを検討する形になるのだが、業務プロセスもシステムも構築サイドで検討している状況。

作成したものを見て、業務プロセスを考えなおすというやり方になっているため、機能要求に沿ったテストが出来ないことやいつまで立っても仕様が確定しない。

(スプリントのゴールは出しているが、リリースの条件を満たさない状況になっている)

 

3.広がる要求

小さく進めて開発しているのだが、今回はWebサービスではなく、ビジネスアプリケーションの一部分の開発である。そのため、スプリントで作成したものだけではリリースはできず、複数機能を全て作成し、システムテスト、ユーザテストを経ないとリリースができない。

 

が、エンドは切られているにも関わらず追加で要求が増える状況。。

これくらいの規模だったらこれくらいかかるなという感覚がプロダクトオーナーにはないことと、要求を持ってきた時点でエンドユーザーと入れる方向性で話を持ってきているため、柔軟に納期を変更できない。しかし、要求は増えていく。。。

 

<やっていて良い点>

スクラムでやることによって、今までの分業制で開発していたのとは異なるという点もありました。

1.実装時に仕様やユーザ視点に立った場合の問題点に気づいてくれる

がちっとした仕様書を書いているわけではなく、Redmineにチケットを発行し、やりたいことを備考欄に記載して、タスクを割り振っている。

また、都度あることにプロダクトオーナーと話したこと、エンドユーザの仕事、業務の内容を説明している。そのため「こういう機能だと、ここにこまらないかな?」と考えてながら実装する意識が芽生えてきている。

言われたとおり作成するというのではなく、考えて作る意識に変えられるのがいいこと。

 

2.タスクの分割

タスクが大きすぎると分割!とすぐ気づく文化が醸成できている。

タスクが大きいと進捗が個人の内部に隠れ、「どこまで進んでいるんだろうか?」が分からないが、細かくし、都度進捗を記載してもらうことである程度状況を把握できる。

 

 

<ロケーション上困っていること>

スクラムの書籍などを読んでいると、壁にタスクボードやカンバンがはられ可視化できているが、私のプロジェクトはできてない。

と、いうのもお客さん先の環境で実施しており、他のベンダーとの共有環境で作業を実施しているため、情報を外に出せない。

システムが充実してきており、デジタルで実施できることは増えている一方、コンプライアンスやセキュリティーなどの要件で、アナログな手法が使えなくなっているのが制約だなと・・。プロダクトオーナーへのインパクトがデジタルだと弱い・・と感じています。