Agile Japan 2012に参加！ #1

コメントをどうぞ

今まで全く予定があわず、行けなかったAgile Japan。今年は、参加してきました！

 

まずは、全体の感想。

メイン会場に入って思ったのは、思った以上にスーツが多かったこと。

毎年そうなのか分からないけどペア割り、上司や同僚を誘おうということで、会社関係の方と出席されている方が多かったんだろうか。とても素晴らしいことだと思う。

 

基調講演から出席できたので、その内容も書きたいのだけれどそちらはまだ、整理しきれていないのでまずは午後のセッションからまとめ。

 

・アジャイルな開発からアジャイルな組織へ

@ryuzeeさんのセッション。

http://www.slideshare.net/Ryuzee/agileagile-aj21-b2 

グラフを見せながらの説明だったのだけれど

WFは、開発が後半に集中するため後半になるほどリスクがあがる

Agile は、優先順位の高いものから着手し開発するため前半にリスクがある

とのこと。で思ったのが、

WFは、製品開発の工程全体のつじつまが合わなくなるリスクを担保したいから各フェーズごとにうまくいっているよねということを確認&決定しながら進めようとしているのかなと。

でも、実際は動く物を作らずに各フェーズでの決定が正しいことを証明出来る訳がなく、かつ、色んなステークホルダーに仕様の確認作業などが発生し、だんだん作業が遅れてくる。でもまだ動くものはいっさい出来ていない。

こんな状況で開発フェーズに入った頃には時間もコストも予定より膨らんでいることになる。

本来の意味での設計(コーディング)作業が最も品質と直結しているはずなのに、そこに時間をかけることが出来ない。

ここに無理が生じているのかなと。

 

Agileは、前半に要求の高いフィーチャを持ってくることで、そもそももっとも必要な要求が作られない/遅れるというリスクを早い段階で解消できる。

成果物に対する作った結果いらないや頼んでいないというリスクへのヘッジも出来る。

また、早い段階で実際に動くものが手に入るので要求の高い機能の品質を犠牲にする必要がない。

さらに、見積った結果今後のスケジュールがどう進むかがわかるため再見積もりやリスケなどの手が早くにうてる。お客さんとのネゴシエーションも早く行えるし、ネゴシエーションのための材料も過去のスプリント(イテレーション）から見積もれるので、説得力もあり交渉の余地も生まれる。

ということは、Agileを初めてやったチームで、ベロシティがうまくあがらなくて心配になるというのは実はAgileでやっている証拠だったりするのだと思う。

これを知っているのと、知らないのとでは途中のチームメンバーの不安やモティベーションの維持が全然違うのではと感じた。

 

次に継続的デリバリについて

flickrのサイトに開発のデプロイ状況がかかれていて見せて頂いたけどかなりすごい。

１週間に24人で384回変更して68回デプロイした。

みたいなのが書かれてあった。68回デプロイってデバッグなら分かるけどここでは本番化だからな。すごい。

障害時のリリースが通常より早いのなら、普段からできるはず。

製品そのものをAgileにたもつ。

というのも言っておられた。

TDD, リファクタリング、CIだったりかな。

問題は、これを、お客さんにどう説明するか。

明日食べる物がないのに、数ヶ月先の食べる物の心配はなかなか出来る人はいない。

プロジェクトの開始段階では、明日食べる物はあったわけだから、最初から取り入れる方が受け入れやすいはずなのだけど、プロジェクト初期の１時間もリリース前の１時間も同じ１時間のはずなんだけどなぜか重要度が異なるかのように扱われる。

だからこそタイムボックスをきって、学生症候群もパーキンソンの法則（第１法則）も起こらないようにする必要があると感じた。

 

で言うだけでは意味がないので今後のアプローチだけど、

受託系の会社の場合、当然かもしれないけれど稼働率９９％という目標。

実際これのせいでかなり苦労していて、

プロジェクトとプロジェクトの合間はそんなにうまく埋まらなかったり必要としている人材がプロジェクトが始まったときに空いていなかったりするけど、数人日を惜しんで他の人材を加えたり先行着手したりということをやっている。

でも、その合間にScrumの勉強会、WorkShopを開いて皆が本気だしたらこんなもんじゃないよねということを思い出してもらおうと思う。

稼働率はいままでより良くないのに利益率はさがってないということが起きて正のスパイラルが証明できると思う。

チームを全体最適化させると自己組織化する

頑張って共有し合えるチームを作ろうと思う。

残りは後日。

Windowsに複数のRubyのバージョンをインストールする方法１

2件の返信

Macを使いたいのだけど、業務で全員MacをそろえてはもらえないのでWindowsでRuby on Rails環境を構築したときの手順。

 

手順

  1. 複数のRubyのバージョンをインストールする　←今回はここ
  2. Netbeansをインストール
  3. デバッグ環境を構築
  4. Oracle接続用の設定を行う

 

手順1:複数のRubyのバージョンをインストールする

【Ruby193をインストール】

取りあえず現状の最新(Ruby 1.9.3-p125）をダウンロードしてインストール

http://rubyinstaller.org/downloads/

コマンドプロンプトで

ruby -v

と入力して

ruby 1.9.3p0 (2011-10-30) [i386-mingw32]

と返ればインストール成功

 

【pikのインストール】

Windowsではrvmが使えないので、pikをインストール
（Cygwinを使うとかは別で）

pikのインストールは下記を参考にしました。

http://forza.cocolog-nifty.com/blog/2011/04/rubyrvmpik-d7e9.html

インストール後は、環境変数にpikをインストールしたパスを通しておくと便利。

 

【Ruby187のインストール】

さっきと異なるバージョンのRuby 1.8.7-p358を下記からDLしてインストール。

http://rubyinstaller.org/downloads/

 

【pikに複数バージョンを登録】

インストールした２つのバージョンのRubyのディレクトリが下記の場合
・c:/Ruby193
・c:/Ruby187
コマンドプロンプトにて下記を実行してRubyをpikに追加する

pik add c:/Ruby193
pik add c:/Ruby187

あとは、

pik sw 187

でRuby187へ切り替え

pik sw 193

でRuby193へ切り替えできる。

次回は、NetBeansインストールとデバッグ環境構築。

 

AdMobをAndroidアプリに追加したいけどAPIレベルが合わない

コメントをどうぞ

表題のままだけど、Android端末にAdMobの広告を表示したいけどAPIレベルが合わないからコンパイルできなかった。

結構調べて色々記事があったけどなぜか断片的にしか拾えなかったので備忘録的にまとめ。

みそは、
AndroidManifest.xmlとproject.propertiesに異なったAPIバージョンを記載する必要があること

まず、AndroidManifest.xmlには下記を追加。

AndroidManifest.xml

AndroidManifest.xml

 

project.propertiesに記載のバージョンに13を記載

project.properties

project.properties

実行すると×マークが表示されるんだけど、2.2系の実機で問題なく動作できました。

ちなみにAndroidのAPIレベルとOSのバージョンの関係は、ここを参照
Android API Levels

jQueryMobileで横スクロールが表示されてしまう

2件の返信

jQueryMobileを使用していてフッターを使用するとどうも横スクロールが表示されるみたい

<div data-role=”footer” data-position=”fixed” class=”ui-bar”>

なので、jQueryMobileのcssにfooterの定義があるだろうと「footer」で検索したところ

ui-footer

というのが検索に引っかかったので試しに独自cssを宣言して下記を追加したところ横スクロールがなくなった。

.ui-footer {

width: 90%;

}

ただし、端末に依存するかもしれないので全端末90%で良いかどうかわ分からない。

4Sは90%で横スクロールがなくなった。

コメントにてもっと良い方法を教えて頂いたので、下記に訂正。

.ui-footer {

padding-left:0; padding-right:0;

}
（フッタの中身を囲った要素）{

margin-left:10px; margin-right:10px;

}

 

Xcode4でのFrameWorkの追加方法

コメントをどうぞ

Xcode4からUIがかなりかわったため、FrameWorkの追加方法に迷ってしまったのでメモ。

プロジェクトのTop > TARGETS内のアプリ名 > Build Phasesタブ > Link Binary With Libraries

で、左下の「+」をクリックすると一覧がでてくるのでそこから追加できる

TracとHudsonを導入してみた１

コメントをどうぞ

 

 

 

 

 

 

請負プロジェクトでTracとHudsonを導入してみたふりかえり。

 

まずは、Trac。

開発初期からまずTracを導入。

最初は、wikiとしてのみ活用。特に強制した訳ではなく、おそらく一番Teamが書きやすい理解しやすいのがwikiだからだと思う。Teamが問題事項や気づきなどを共有し始める。

ここで注意したのが、Team全員にadmin権限を付与したこと。機能が制限されていると思うとどうしても管理者（プロジェクトリーダー）にコントロールされているように感じてしまうため（自分の場合がそうだった）、人の領域に入る気がしてwikiを記載するのに気が引けてしまったので、Team全員にadmin権限をつけることでそれを回避したかった。自己組織化に必要な要素の「透明性」と「権限委譲」をしたかったため。

プロジェクトの進捗やタスクは、別途WBSで管理。マイルストーンやタスクはそちらを参照。Teamで共有したい情報は、wikiへ記載といった感じ。

請負プロジェクなので、見積もりを基準にして開発が進む。

開発当初に見積もりを破棄していきなりScrumを導入する勇気がなかった、もてなかった。

理由は、進捗や全体像をタスクやvelocityから把握するやり方に自身がなかったのと、Agileの知識が全くないTeamにいきなりScrumを導入するのはリスクが高いと感じたため。

まずはプロジェクトにTrac導入を行って、Teamで情報共有すればプロジェクト開発はもっと楽しい物になるというところを理解してもらおうといった魂胆で導入してみた。

開発が終わってみて思うのは

・wikiが開発当初より充実していて、次回同じプロジェクトの改訂などが会った場合、wikiを見ればどういったプロジェクトだったすぐに思い出せること。

・途中参加のメンバーにプロジェクトの説明をする際に、まずはwikiを見てもらうことでスムーズに参加してもらえたこと

・admin権限の付与がよかったのか、皆wikiに記載していってくれたこと

 

つづいてHudson。

Hudsonは、プログラミング開始と同時に導入。当初は、コミット→ビルドして失敗していたらメールで通知という機能のみ使用。

導入当初、皆ビルドしてからコミットするのは常識だと考えていたため大して役に立つと思っていないようだったが、プロジェクトが終わってみると全員がHudsonからメールを受け取ることになった。。。恐るべし。

開発が進むにつれ、unitテスト実施、findbugs、checkstyleもコミットと同時に実行するようにしたためプロジェクトの最後に一斉に修正する必要がなくunitテストがいつ壊れたか分からないといった状況にもならなかった。

こちらも導入しない理由が見当たらない。No Risk, High Returnといった感じ。

次回も引き続き利用して、最終的にはScrumを導入できれば。。。

自作ViewをLayout xmlで使うには

コメントをどうぞ

Viewクラスなどを継承した自作ComponentをLayoutのxmlで使用するには、コンストラクタにAttributeSetを追加する必要があるみたい

/**

* XMLファイルから生成される場合に使用されるコンストラクタ

* @param context {@link Context}

* @param attr {@link AttributeSet}

*/

public ActionView(Context context, AttributeSet attr) {

super(context, attr);

this.mmmain = (MindMapMain)context;

this.setOnTouchListener(this);

gestureDetector = new GestureDetector(getContext(), this);

}

方法が分からなくてlayout xmlでは出来ないのかと思ってあきらめかけた。

Viewを継承してとか当たり前なんで出来ないとか、あんまりだなと思っていたけど、自分が方法を見つけきれていないだけだった。

 

ソフトウェアキーボードの表示、非表示

コメントをどうぞ

ソフトウェアキーボードの表示/非表示が自動では行われなかったので下記を実装。

EditTextにフォーカスがあたった場合に、ソフトウェアキーボードを表示して
EditTextからフォーカスがはずれた場合に、ソフトウェアキーボードを非表示にする


nodeAddText = new EditText(this);
nodeAddText.setOnFocusChangeListener(new View.OnFocusChangeListener(){
 @Override
  public void onFocusChange(View v, boolean flag){

    //フォーカスが外れた場合、ソフトウェアキーボードを非表示
   if(flag == false){
    final InputMethodManager imm = 
    (InputMethodManager)getSystemService(Context.INPUT_METHOD_SERVICE);
    imm.hideSoftInputFromWindow(v.getWindowToken(),0);

   } else {

    //フォーカスを取得した場合、ソフトウェアキーボードを表示
    final InputMethodManager imm = 
    (InputMethodManager)getSystemService(Context.INPUT_METHOD_SERVICE);
    imm.showSoftInput(v,0);
   }
  }

社内Scrum Master

コメントをどうぞ

社内でScrumを使用して開発します。といっても実際は、なんちゃってになってしまうか、そもそも受け入れらない。

だからといって、何もしないままだと何も始まらない。そもそもCSMを取得したからといって何か変わるわけではないことは重々承知だったわけだから出来ることからやろうということで、以下社内にScrumを取り入れるための策

・ProjectLeaderという役を引き受けているけれど、気持ちはScrumMater

・ProjectLeaderとしてではなく、ScrumMasterとしてお客様（Product Owner)との窓口業務をこなす

・ProjectLeaderとしてではなく、ScrumMasterとしてTeamをお客様の実現不可能な要求から守る

・ProjectLeaderとしてではなく、ScrumMasterとしてTeamを社内の雑音（鶏）から守る

・ProjectLeaderとしてではなく、ScrumMasterとしてTeamとお客様をProject成功のためにファシリテートする

…..ProjectLeaderをScrumMasterに置き換えただけだけれどもここから初めて見えてくることがあるはず。