-
Notifications
You must be signed in to change notification settings - Fork 48
Readingagilesamuraiinhiroshima20150930
いろいろと立て込んでいましたので少し期間が空いてしまいましたが、１６日に開催させていただきました。２回目より「すごい広島」と共催？させていただいております、場所はムービンオンになります。月末なので申し込み者がおられません、初のボッチ開催となりましたが、最初からボッチでもやろうと思っていたので、無問題です（キリッ
会場に行く前に献血していきました、最近カンバンで不足不足と書いてあったのを見たので。。。
次回は、１０月１４日にしたいと思います。
イテレーションの回し方を扱う章、アジャイルプロジェクトのマネジメントの背後にある仕掛けを理解するのがこの章、マネジメントと言っちゃってるけど多分あのマネジメントとは異なるマネジメントなんだと思う。
何もかも文章にまとめる時間なんて無いってことだ、だから、手軽で性格で必要な分だけを必要な時にアウトプットする方法が必要。開発プラクティスをプロジェクトに根付かせる。コードはいつも整理して（リファクタリング）テストして結合した状態を保つ。テストは開発と一緒になって進める必要が有る。
タイムボックスは１週間か２週間、顧客にとって優先順位の高い方から順番に、開発チームが動くソフトウェアにしていく。イテレーション＝エンジン。そうすることで、必要に応じてプロジェクトの方向性を修正できる。
最初の２週間で２つのストーリーが実現されるだけでも非常に助かる。まさにこのシュチュエーション！がアジャイルが必要な場面であるが、このような場面はみんな経験があるのでは、そしてそれは自然とアジャイルになっていたのでは？アジャイル自然発生説
「必要な分だけを、必要なときに」分析する。分析についてもイテレーションに含めるやり方は、しようがない場合もあるが、分析だけは早めにやっておいた方が良い派である。仕事の関係上でもあるが、アドホックに開発はよくない、技術面でも肝心な部分は最初に叩く必要が有るし、技術以外のマーケティングについても事前に行う必要がある。この章では１イテレーションを使って分析をしているので、たぶん事前分析が掘り下げて分析されるものと思うが、「必要な分だけを、必要なときに」という言葉が先行すると間違いの元と考える。
フローチャートもこの段階、ペルソナもこの段階、ペーパープロトタイプでデザインにも、受入テストを書いて、ストーリーの満足条件を定義しよう。そのほか使えるものはどんどん使っていくと良い。
ペアプログラミングは万人向けのプラクティスではない、チームメンバーがどういう仕事のスタイルを望むかは重要なポイント。ジャストインタイムに分析したストーリーを「金塊」に変えていく。自動化されたテスト、常にリファクタリング、インテグレーションする、顧客の言葉に合わせてコードを書く。
アジャイルの魔法を引き起こすには、本格的なエンジニアリングのプラクティスで支えなきゃならない。しかし、プラクティスをやればアジャイルに出来るかと言えば、それはたぶん違うのだろうな。目的はアジャイル、プラクティスは手段。
イテレーション・ゼロは、開発作業の準備を整えること。ソースコード管理、ビルドの自動化、開発環境テスト環境、アーキテクチャスパイクなどはイテレーション・ゼロで行う作業とのこと。コードベース全体でコーディング標準を守る秘訣がコードの共同所有。
アジャイルプロジェクトでは何もかももテストしているはずなのに、リリース前には正式な受入テストも必要なの？答えはイエスだ！それはいつでも受入テストできるようにすることだ。正式な受入テストはしばらく無くさないほうが良い。まずは君自身が確信を持てるようになるのが先だ！
カンバンはトヨタが開発した情報伝達システムに由来する。カードを使って、組み立てラインでのパーツ補充の工程を調整する仕組みをカンバンと呼んでいる。カンバンでは仕掛かり（WIP:Work In Progress）にできる作業に上限を儲けている。チームが同時に着手する作業の数はこの制限を超えてはならぬ。
カンバンではイテレーションが必要ないってことだ、チームが気にかけるのは作業リストの中にある、優先順位のもっとも高い作業だけだ。
カンバンで仕事を進めていくことによる、利点は次のとおり（イテレーションのプレッシャーから解放される、一回のイテレーションに収まらない仕事にも取り組める、期待をマネジメントしやすい）一度にこなせる仕事の量はかぎられているんだ
１回のイテレーションに収まらないような大きな課題にぶつかったとき、収まらないなら、それは収まらないんだ。そこでも顧客の期待をマネジメントすることを考える。
忘れないためのメモ、次回は付箋を用意して各自記入するようにする。
実際におこったこととしては、システム全体が適切に動作しているとおもったら、システムの外と連携して問題が発覚したことがあった。 連携するサブシステムをふくめて、全体をみなければならない。
機能としては実現しているが、ユーザの目線にたったとき、ユーザには利用できないインターフェースで提供していることがある。 結局それはユーザが価値を得られないので注意をする。 APIであればAPIを利用するクライアントが何か提供されているべきである。
ストーリーやテストを記述したときにテスト条件をかいていなかった。 あったほうが良いと感じた。
ドメインエキスパートの言葉に合わせてコードをかくDDDでも言われている手法だ。