Skip to content

Readingagilesamuraiinshimane20120517

Jump to bottom Edit New page
jaVuBax edited this page May 29, 2012 · 14 revisions

← Readingagilesamuraiinshimane

偵察 アクトシステムズ読書会

@tsurur によるアクトシステムズでの読書会 の紹介

IMG_0709

各藩　討論の内容

第13章 リファクタリング

虚構藩

IMG_0714 IMG_0767 IMG_0749

  • 開発者にとっては馴染みやすいリファクタリング、それゆえ我々が気になったことがある。
オブジェクト指向プログラマ（OOP）が使う隠し味…
  • なぜ、OOPって限定しているのか？
    • 本では後から効いてくるものだと説明してあるが。
    • オブジェクト指向言語じゃなくても、Cだったり他の言語でもリファクタリングはできる訳です。
  • それを考えた。
OOPっていうのは、コンピューターの為ではなく人の為のソースコードを書く。
  • 変数名を分かりやすくしたり、メソッドを抽出したり、リファクタリングは人の為にやっていること
    • OOPは人の為に活動して、お客様に価値を届けると定義すると、リファクタリングも次にソースコードを触る人の為にやることなので、OOPと限定している意味を導き出すことができた。
  • 質疑応答
    • 本当にオブジェクト指向プログラミングに限定されるのか？関数プログラミングでも重視されているので、対象がオブジェクトやクラスなのか関数なのかの違いはあるが、リファクタリングできると思います。
      • 着目したのはなぜこの本では限定したのか？ということ。確かに関数型でもできると思う。それでもあえてオブジェクト指向に限定したのは、『人の為に！』を伝えたかったかもしれない。関数プログラミングでも別のアプローチでリファクタリングっていうものを考えているのかもしれません。

IMG_0755 IMG_0757 IMG_0758

スズキ藩

IMG_0715 IMG_0730 IMG_0790

  • 負債という言葉

    • ネガティブなので、それより貯金と言う言葉を使った方がいいかも。

  • 自分の暮らす家

    • 大規模なプロジェクトでは価値観が違う人が大勢集まる。そうするとどうしても汚い部屋ときれいな部屋が混在することになる。トータル的にきれいな家というのは作りにくいと感じた。

  • 技術的負債と時間軸

    • リファクタリングのある時と無い時。リファクタリングがある時のグラフは本当に正しいの？

  • 技術的負債はコードだけじゃない

    • 重複する設定、重複するテストデータ、データベースの設計、名付けとか。

  • 技術的負債という名前

    • 普通の負債と言い方を分けているのは開発者にフォーカスし、開発者がリアルに感じれるネーミング。

  • 外部から見た○○の振る舞い

    • 外部ってどこのこと？利用者から見た視点？メソッドレベルの視点？

  • リファクタリングの費用対効果

    • リファクタリングをするタイミングが難しい。リファクタリングの価値を知らないユーザーにどう納得してもらうか？

  • 質疑応答

    • テストコードのリファクタリングの必要性を感じている。
      • 振る舞いを変えない前提だとテストコードのリファクタリングは振る舞いを変えてしまうのでは？
      • 価値を届け続ける為にテストコードがボトルネックになるなら、リファクタリングじゃなくても何かしらの処置はした方が健康的。

IMG_0743 IMG_0761 IMG_0762

１－２藩

IMG_0716 IMG_0777 IMG_0734

  • 機能追加がまったくわくわくしない。

  • 実際に古いシステムだと負債しかないのではないかというレベル。カスタマイズが苦痛だぁ。

  • なので、毎分リファクタリングするというのはワクワクする。

  • でも、知識が無いとできないよね。オブジェクト指向とか。

  • でも、手を止めちゃだめ。あきらめないで！コードを打ちながら成長するんだ。

  • リファクタリングをする為にその規約が必要なのではないか。例えば名前付けとか。

  • 日常でもファイル名とか、同じ人でも時間が経てば違う付け方をしたりとか。後で後悔するよね。

  • 実際にコードレビューした後リファクタリングするのは、コードレビューの意味が無いのでは？

    • リファクタリングはコードの振る舞いを変えないことが前提なのでレビューの後でもしていいんじゃないと個人的に思う。
      • 振る舞いが変わらないことを保証しないといけない。
      • 　→　テストコードがあるから安心♪
      • 　　→　現実では、修正した後でレビューするんじゃない、普通は？

  • コードレビューとリファクタリングとテストを弛まなく繰り返すことを推奨しているのではないでしょうか。

IMG_0737 IMG_0764 IMG_0765

ワークショップ

アジャイルの一歩手前 ~ なぜ我々はアジャイルになりたいのか ~

  • 標的
    • 自分達のハート
  • 目的
    • アジャイルを進めて行く中で必ず迷子になりそうな時が来る。その時の道しるべとなるものを作る。
  • 進め方
    • 時間と立場のマトリクスを作り、各々それぞれに合った状況や課題を思うがまま付箋に書き出す。
    • 付箋をマトリクスにマッピングしながら、議論する。
    • チーム毎に発表
虚構藩の道しるべ
  • 昔
    • お金あったけど選べる技術が少なかったよね
  • 1995年をターニングポイントにした
  • 今
    • お金ないけど選べる技術が多い
  • アジャイルというキーワードにフォーカスすると2000年とか2003年がターニングポイントかも。
  • プロセスやツールよりも個人と対話をとあるが、なぜそうなったのか。
    • 昔はツールがあまりなくて、良いツールがひとつできると劇的に開発効率が上がった。それが最近は鈍化しているのではないかと感じる。
    • 逆に言うと、昔はツールが流行ってきたのでそれにばっかりのめり込んでしまって、ツールがありきの開発をするようになった。なので、いったん立ち止まって、顧客と対話しようとなったのかもしれない。
  • 計画に従うよりも変化への対応
    • 色々なシステムが入ってきて、バブル期にどんどん色々なアイテムを与えられた。いらないものも含めて。それにより要件が増えたが、ユーザー側でまときることができなくなっている。長いスパンで見ると変化は少ないけど、初期に要件がまとめられないことから変化が生まれているのかもしれない。

IMG_0806 IMG_0812 IMG_0813

スズキ藩の道しるべ
  • 昔
    • 利用者
      • ビジネスの変化が遅かったので一回作って長く使うことができていた。
      • 利用者はITリテラシーの高い人に限られていたので、ウォーターフォールが通じていた。
      • 成果物の価値よりも、コスト、納期、計画通りの機能とか、定量的な数字の方が評価された時代。
    • 技術者
      • 売り手市場が出来上がっていた。営業しなくても、努力しなくても仕事が出来ていた。
      • 作る人は疲弊し、利用者も思った通りのものができないどっちも不幸な時代があった。
      • 予算がついてて時間もビジネスの変化も少なかったので時間的な余裕があった。
      • 無駄な事やってても回る仕組みができた。
  • ターニングポイント
    • IT化がひと段落した。
    • 外資系の企業が参入して競争が激化
  • 今
    • 利用者
      • 出来たものの価値を評価するようになった
    • 技術者
      • 学ばなければ淘汰される
価格競争が激しくなった中で、
価値を提供するプロセスの中でなんとか無駄なものを無くして、
お互い利益を出せるようにする為にアジャイルになる必要がある。
  • 質疑応答
    • 昔ってどのくらい？
      • 高度経済成長のこと。
      • →　ビジネスのスピードは早かったけど、ITに関しては今より遅い

IMG_0795 IMG_0815 IMG_0816

１－２藩の道しるべ

  • 昔

    • 利用者の状態
      • IT利用者は一部の人しかいなかった。とりあえずIT化すれば、業務の効率化できて万々歳であった。
      • 案件についても、長期の計画、規模も大きく、予算も潤沢にあった。また、実現したいことも明確だった。
    • 開発者の状態
      • 技術の数が少なかった。→ 出来ることが限られていた。
      • 作れば売れる。ハッピーな時期。

  • 自治体の発注方式が一般化、固定化された発注方式。→ ターニングポイント

  • 今

    • 利用者の状態
      • 当事者の意識の欠如。自分達が使うシステムなのに開発者に丸投げする状態。
      • 予算は少ないが、やりたい事が増え、短期で使いたい。要件も複雑化、また、変わる。
      • 以前に比べて、言いたいを遠慮せずに言う力（知識）がついた。
      • 売り手市場から買い手市場？
    • 開発者の状態
      • 技術の多様化、選択肢が増えた。技術の進歩が目まぐるしい。
      • 作っても売れない。
      • 開発者が余っている。
      • 我々としてはWIN-WINの関係を気づきたい。お互い利益を得られるような状態に持っていく必要性に迫られている。

  • よって

    • オープンソースを利用してコロコロ変わる要件に対応する為にアジャイルにソフトウェア作る必要性に駆られている。

  • 質疑応答

    • アジャイルになる必要性の根拠は？
      • 感じていることは、プロジェクトが進むにつれてお客さんの求めているものは変わる。そういうアンマッチは一回プロジェクトが終わった後に、保守案件として扱う。そうじゃなくて、日々取り込んでいくという形がお客さんにとっても開発者にとってもいいんじゃないか。

IMG_0787 IMG_0818 IMG_0820

発起人ふりかえり

Keep

  • 新規参加者、ありがたい。
  • 他の道場の様子を知ることができた

Problem

  • お題が曖昧すぎて、期待していた結果に結びつけることができなかった。
  • お題探し、相変わらず難しい。

Try

  • ワークショップの準備を入念して、的外れな議論にならないようにする

参加者ふりかえり

Keep

  • ディスカッションへの参加
  • 気になる点を確認できた
  • 学ぶ姿勢と今日ココに来たこと
  • 参加し続ける
  • 昔の話を聞けた
  • やさしく回答できた
  • 他の道場の話
  • 参加者多し
  • 新参者多し
  • 早めのアナウンス
  • 早めに来た
  • 進行役を頑張った
  • 発表者になる！
  • 人と話をするのは楽しいね
  • ワークショップ楽しい

Problem

  • 瞬発力が足りない
  • 時間管理が出来なかった
  • もっと考えて喋った方が良かった
  • リファクタリング
  • 遅刻…
  • 他の人の話をちゃんと聞いてなかった
  • 本多クンをもう少し発表に引き出したかった
  • 発表者時間オーバー
  • 全体で時間オーバー
  • Time is Money
  • 本を忘れてしまって予習出来なった
  • ディスカッションのペース配分。尻切れトンボ…
  • 話が長かった（誰の？）
  • のどが調子悪くてあまり発言できなった
  • ワークショップのお題の解釈の範囲が広すぎてまとめ難しかった

Try

  • 会話の瞬発力（気になったら発言）
  • 時間管理を意識する
  • 考察する
  • 発言する
  • 人脈を広げる
  • 次回も参加する
  • 質問する
  • 予習してくる
  • 他の人の話しをもっとよく聞く
  • 発表や進行役などをチャレンジする
  • 他の人が気付かない文言をピックアップする
  • 早めのアナウンス
  • 時間厳守！時間オーバーしたら発表は斬る！サムライだけに。
  • My pen を持参。
  • 高尾さんのような型にハマらない発表
  • 予習して発言内容を溜めておく
  • 活発な議論

SAPA ~ ShimaneAgilityPointAverage ~

10.8 → 第12回読書会 → 12.6

Readingagilesamuraiinshimane20120419 ← → Readingagilesamuraiinshimane20120531

Add a custom footer
Add a custom sidebar
Clone this wiki locally