タグ

2012年4月20日のブックマーク (7件)

  • TDDの前方依存と後方依存 - pocketberserkerの爆走

    『注意』 この記事には間違っているかもしれないことが含まれています。 また個人の意見なので鵜呑みにしないようにしてください。 あと疑問符がついている部分の答えはここには書いてません。 TDD自体は簡単な概念と思う TDDそれ自体は簡単な概念だ。 Red、Green、Refactor…実にシンプルである。 だがしかし、TDDは難しいという話はことあるごとに聞く(ような気がする) 「では何が難しいのだろう?」というわけで脳内で妄想を膨らませてみる。 [追記]前方依存、後方依存という言葉をだしているが、勝手に考えた造語なので項目ごとに定義も追加しておきます。 技術的な前方依存 『TDDを始める前と終TDDを実際やるために必要な技術』 最低限対象言語でコードがかけるようになって 最低限テスティングフレームワークを使えるようになって リファクタリングをしっかり学んで 対象言語でのきれいなコード、設計

    TDDの前方依存と後方依存 - pocketberserkerの爆走
    kaji_3
    kaji_3 2012/04/20
    同じようにプロジェクトでテストとテストコードをどう入れて行けばいいのか混乱してきたのでエントリを書こうかな
  • 社会的必然性としてのアジャイル - Always All Ways

    今朝、巷でちょっと盛り上がっていたやつに私も乗っかっておきます(笑)。 # 最初は乗っかるつもりはなかったのですが、読めば読むほど味わい深いので、私なりの解釈や思うところを書き記しておきたいと思った次第です。 # 元記事の著者お二人の意図に反した解釈を勝手にしている部分もあるかもしれませんが、あくまで私なりの解釈とそれらについての個人的見解とご理解くださいね。 元記事ふたつ ウォーターフォールのほうが楽だという話 - 勘と経験と読経 ウォーターフォールの方が楽ですか? | Ryuzee.com 著者のお二人は個人的にもお付き合いがありどちらも尊敬している人です。ユーモアまじりの記事の中でそれぞれの視点や考え方が出ていて興味深く読みました。 まず、両記事を読んで私が感じたのは、(おそらくお二方も承知の上で敢えて書かれているのだと思いますが) 「どちらが楽か」というのは、PMやコーチとしてメン

    社会的必然性としてのアジャイル - Always All Ways
    kaji_3
    kaji_3 2012/04/20
    今社会がこうなっているから、組織としてこう進むべきを考える。踏み込んだ事を会社の人と話す機会があんまりないが作りたいな(チラチラ
  • 日本のアジャイル10年史 -hiranabe編-

    KentBeckに「おまえはおれか!」、JUDE開発でのXPの実践と事例発表、そして海外と日アジャイルコミュニティの懸け橋に。日アジャイルはこの人を置いては語れない。Mr.Flypan、hiranabeさんの10年を通して、日アジャイルを振り返る。 ■あわせて読みたい 日アジャイル10年史 sandayuu編 http://togetter.com/li/100325 kuranuki編 http://togetter.com/li/100356 続きを読む

    日本のアジャイル10年史 -hiranabe編-
  • 海外挙式を支える技術 - GeekFactory

    2012年3月、グアムで結婚式を挙げました。 良かったことや苦労したことを振り返ってみます。これから海外挙式を考えている方のお役に立てれば幸いです。 はじめに 結婚式は立派なプロジェクトです。共同作業をしながら期日までに成果を出さなければなりません。プロジェクトマネジメントの力量によって成果は大きく変わると思います。 奥様はプロダクトオーナーです。結婚式にかける情熱は大きく、多くのことを知っています。ゼクシィでドメイン知識を得て対等に話せるようになるにはかなりのパワーが必要です。 私たちは以下の理由から海外挙式を選びました。 新郎新婦ともに上京して地元が離れている。 新郎新婦で共通の友人が多い。 両親に海外旅行プレゼントしたい。 海外挙式ではゲストに遠方からお越しいただくことになります。したがって、プロジェクトのスコープは挙式だけでなくツアー全体です。自分たちの結婚式を頑張るだけでなく、

    海外挙式を支える技術 - GeekFactory
    kaji_3
    kaji_3 2012/04/20
    "奥様はプロダクトオーナ""究極のウォーターフォール"
  • ウォーターフォールの方が楽ですか?

    アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください(初回相談無料) (顧客) そのシステムを作った結果に対して、顧客自身が結果責任を背負っていない場合は、ウォーターフォールの方が楽。最初に仕様合意して最後に「納品」されれば良い。場合によっては、システムによって得られる価値が目的なのではなく、「システムを作る」こと自体がアリバイ的に目的であるケースすらある。こういう場合は、顧客自体のプロジェクトへの参画が必要なアジャイルは面倒だと思うだろう(顧客) また、顧客が開発部隊に対して政治的に極めて強い力を持っている場合なんかは、基的に全てのリスクを政治的な力によって移転できるので顧客側が大きくコミットする必要性はなく、ウォーターフォールの方が彼らにとっては楽かもしれない(顧客) その一方で顧客自身

    ウォーターフォールの方が楽ですか?
    kaji_3
    kaji_3 2012/04/20
    "終われば良いというフォースが一番強く働く" 「開発」だけのプロジェクトにいるとそれを強く感じる。「保守・運用」を担当している人達の方が考え方はアジャイルは向いているはず。
  • ウォーターフォールのほうが楽だという話 - 勘と経験と読経

    わたしはまだ格的な(?)アジャイル開発をやったことは無いけれども、周りのウォーターフォール脳に比べたらアジャイルプラクティスをプロジェクトに取り込むことが多い(プロジェクトマネージャーの立場で、スクラムマスター的に推進)。いくつかのプロジェクトを終えて、結果を振り返ってみるとチームメンバーの平均的な帰宅時間は早まったし、休日出勤することも減ったと思う。QoELは確実に上がったと思っていたけれども、一部のエンジニアからは「キツかった」と言われて驚いた。 アジャイルの前のほうが楽だった? 「第5回 TFSUG:ウォーターフォールからアジャイル、リーンへ」での発表で、アジャイル開発に挑戦した方がやはり「前のほうが楽だった」というような事を書いている。 http://kaorun55.hatenablog.jp/entry/2012/04/17/001312 第5回TFSUG WFからAgile

    ウォーターフォールのほうが楽だという話 - 勘と経験と読経
    kaji_3
    kaji_3 2012/04/20
    今常駐で短期リリースだけど常時本気モードなのできつい。これだと8時間が精一杯。塹壕よりScrumとXPでは自由研究日というスプリント間の休憩があったけどやろうとしたらできるかな。
  • スクラム道.09に参加してきた #scrumdo - うさぎ組

    なんかいろいろあって2012.04.09のスクラム道09に参加しました。 Workshop的なスクラム系イベントはこれが初参加だと思います。 テーマはインセプションデッキでした。 すすめてくださったのは@nawotoさん。 あんまりまともにメモをとっていなかったので詳細を覚えていなかったのですが、@changeworldsさんがブログにしてくれていました。 「スクラム道.09 に参加してきました。 #scrumdo - Change The Worlds」 >>追記 Toggeterはこちら 「スクラム道.09 #scrumdo - Togetterまとめ」 追記<< あんなに大勢で意見を言い合うのは初めてだったので楽しかったです。 自分も含めてそうだったかもしれませんが、質問ばかりだったのが正直言うとあまりよくなかったかなーって思いました。 すんごく個人的な思いを言うと「どんなことが出来

    スクラム道.09に参加してきた #scrumdo - うさぎ組