iosFighTimerは作業をカテゴリ別に計測・記録してグラフで一望できるアプリです。シンプルで可愛らしいUIと簡単な操作で自分のがんばりを振り返ることができます。再読するなら9つのプラクティスを目次で。半年に1回とか、自分のプロジェクトの軌跡と照らし合わせてこの行いができたかを振り返る一連の流れを説明している本なので、各手法の細かい方法を把握したい場合はそれ専用の専門書を買うべき。Coupled:疎結合Encapsulated:カプセル化Assertive:断定的Nonredundant:非常帳...な、コードを心がける6まずテストを書く7テストで振る舞いを明示する9レガシーコードをリファクタリングする素晴らしきTDD8設計は最後に行う設計を後に回し、末端から作ることでソースの重複やよりカプセル化された構造にできる。読んでる本のジャンルが被ってるのでそんなに目新しい発見はなかったかな的な。レガシーコードを意識するための本としては良さそう。sorahako·0件のコメント書籍情報アジャイルコーチングAmazon概要チーム(対人)にアジャイルを浸透させる術、アジャイルを導入させる側としての本。ところどころにチームリーダーとしての意識を考えさせられるような記述あり。具体的な見積もり手法とかの話はアジャイルな見積もりと計画づくりの方が濃い。必須なし推奨スクラムの実経験アジャイルを導入させるための本なので、導入させるつもりがあって読むべき。再読するならアジャイルを実践して、壁に当たったとき。各章末尾に「苦難」の項目があり、こんなときは...の参考になる。方法論なので、そんなに再読する系ではない。コーチングの基本アジャイルが云々というよりも、コーチとして、人の上に立つリーダーとして、認識しておきたい事項の確認。旅を始めるアジャイルコーチのはじめ方~また次へ、を簡潔に説明した章。コーチを始める前に、動機・スキル・責任・支援を再認識するチームへは適切に紹介を受けて加入する。曖昧に入ると、コーチとしての信頼を失うPrOpERサイクルを意識する。問題を探し(Problem)、改善の選択肢を検討し(Option)、実験(Experiment)、成果をレビューする(Review)時間の概念を持ち、問題の原因・結果を考えるペースを維持する。みんなと一緒に働くチームとして他人と働く上でのコミュニケーションで大切にするべき部分の話。相手の話はきちんと聞くとか、行間を読むとか。議題によって対立した場合には即座に仲裁役に回る必要はなく、話を聞いたり、出ている意見に投票して視覚的に理解できるようにして感情論にならないようにする。変化を導くアジャイルの導入としてだけではなく、なにかの導入のときの心がけとも読める。チームに急速な変化を求めない提案は宗教ではない。説明だけでなく、実演して見せる導入しないことによる問題を提示する「提案された内容」ではなく、当事者意識を持たせることで自主性が高まる・相手にオープンクエスチョン(「なぜ~だと思う?」のように、YesNoで回答できない質問)をする・5回のなぜ(原因を5回探すとその間に根本的な問題が現れる)・質問は誘導尋問ではない。アジャイルチームを作るアジャイルチームを作る前に、チームとしてのあるべき姿を考える話。心理的安全性の話とかまさにこれ。チームとしてお互いを信頼し、働くための場所を整える(物理的な席の場所を近づける)チームのやる気を維持する。簡単すぎず、難しすぎない程よい目標を常に立てる説得力のあるゴールを決めるイノベーションの時間を設ける(ゴールドカードを出した日は自分のやりたいことをやる&結果を発表するとか)インセンティブ報酬には気をつける。チームで計画づくりいよいよスクラムし始める。デイリースタンドアップいわゆる朝会。チーム全員がボード前に立って昨日の作業・今日の作業予定・困ってることを10分程度で報告しあうのがテンプレ。(これに限らず)ルールに縛られる必要性はない。「ルールに従っていればいい」と思うと自主性がなくなる。チーム間での作業情報共有が目的なので、特定人物だけが話す場にはしない。2部構成にして、対開発チーム・対営業チームとか分ける手法もあり(スクラムオブスクラム)開始時間は絶対に朝ではなく、チームの都合で決める。コーチとしては話が脱線したら補正する、当事者が慣れてしまった問題がないかを第3者の目線で考えながら参加する。何を作るか理解するユーザーストーリーの作り方の話。「**というユーザーとして**という機能がほしい。すれば**という利益が得られる」をテンプレとして作成する。3C(カード・会話・確認)が重要。ストーリーを作成したあとにストーリーテストの詳細を確認する。ユーザーの要求に応じて、詳細を詰めていく。ユーザーが触れない機能(インフラ整備とか)もユーザー→プロダクトマネージャなどに置き換えて同じようにストーリー化できる。前もって計画するユーザーストーリーを出したあとの見積もり・優先度会議の話。決定する・顧客にも説明する)イテレーションは数回の平均=チームの作業可能実績であって、徐々に上がり続ける値ではない。そのような期待を持たない。イテレーション内で計画が変わり続ける場合、見積もりなどがうまく行っていない。調査が必要であればスパイクを設けるバグ修正の見積もりは難しい。やすい...なら、割となんでも良さそう。ストーリーを優先度順に縦に貼って、横にToDOなどを並べるのが一般的な様子。(他の本もだいたいそうなんでも見えるようにする必要はない。必要なくなれば運用を終える。保守の仕方はチームで集まって検討するのが吉。品質に気を配るテストどうするべきか?とかリファクタリングとか。この本自体が非エンジニア向けだから、こういう手段もあるよという紹介なんだと思う。深い部分までは突っ込まれてない。完成させるストーリーテストの完成の定義を明確にする。「テストする」だけでなく、自動テストとか、データ用意とか、実は作業はたくさんある。バグを埋もれさせない。頻繁に連絡して士気を下げるとか、やり取りは対人であることを意識する。ストーリー未達を真摯に受け止め原因を振り返る。テストで開発を駆動するストーリーの完成条件でもあるテスト、それをTDDにしてみませんか、という提案。TDDが早すぎるケースもある。チームがテストのあり方について理解・同意できていない。そのときは書き方を学ぶことから。どこからテストを書くべきか?まずは分離しやすい中間コードから。CIも大切だがCIの規律はより大切。CI結果を無視しないテストに時間がかかるようになると生産性が落ちてTDD持続も難しくなる。実行時間にも気を配る。クリーンコード作り続けるだけではなく、コードの綺麗さも考え続ける必要がある。分析麻痺に陥ってないか?ソースコードを書かずに設計ばかり考えてる。ユーザーストーリーに対して設計も意識する。リファクタリングとか、チームでコードを共通所有する意識とか、ペアプロの話。ペアプロは勉強のためではない。少なくとも同じ言語で行う。初心者対ベテランの組み合わせは問題ないし、お互いにお互いの意見をリスペクトし合う。フィードバックに耳を傾けるイテレーションが終了して、次のイテレーションへ...行く前の、イテレーションデモ・その回のイテレーションの振り返りの話+α。結果をデモするイテレーションの終了時のデモのやり方の話。プレゼンの構成を決めて、全員が役割を果たす。リリース事項として確認すべき事項も掲載。技術的問題でデモが実行できない等は避けるべし。事前準備・確認や、安定版を用意する。ふりかえりで変化を推進するふりかえりのあるべきでない姿が載っている。見返して、自分たちの行っているふりかえりがどうかを考えてみると良さそう。その期間にあった出来事と感情を導き出す。その時の気づきから改善のアイデアを探し、次に実行するリリースレトロスペクティブでチーム全員で振り返る。これは大規模なので、事前に準備もする。全員から、建設的な話を得るための場である。話さない人がいる、不満ばかりの場になるべきではない。あなたの成長あなた自身が成長するために...のきっかけを渡そうとする章。読み返すべきとすればこの章だけど、自己啓発話なので、それに特化した本を読んだほうが良さげ。カイゼン・ジャーニーなどのスクラムの流れを把握できる本アジャイルを初めて勉強するためには向かなさそう。先に別の本を読んでおきたい。再読するなら第22章:なぜアジャイルな計画づくりがうまくいくのかアジャイル計画試したけど何かの壁に当たったとき。計画づくりのためのガイドラインが載ってて9ページ。内容メモ第7部・ケーススタディから逆算する結局の所、~の手法がわからないから読み返したいはずなので、ケーススタディの流れに沿って再読するのが良さそう。ユーザーストーリーの洗い出しP273:「プレイヤーとしてxxしたい」をベースにユーザーストーリーを探し出す。見積もりのスケールフィボナッチ数列(1,2,3,5,8...)を利用する。スケール値をバケツと見なし、若干多く入れることもできるが、多すぎるとあふれる、程度の感覚でスケールする対比・分割ストーリーごとの見積もり結果が同じ程度の単位までに収まるようにする。1~8であれば、作業間の規模を読み取れるが、1:100では100の規模を読み違える。第12章:ユーザーストーリーの分割ストーリーが大きすぎて1つのイテレーションに収まらない場合は分割を考慮する。タスク単位への分割は行わない。各人にスケール値のカードを配り、ストーリーに対する見積もりを同時に出す・同時に出すので、他人の意見に引きずられない・値に差が出たときにそう感じた理由を説明してもらう。チーム全員が話すことになるため、団結感が出やすい・説明により、全員が同意して平均化された値になる。・フィーチャの開発によって低減できるリスクP106:図9.2の「リスクと価値の四象分類」がある。フィーチャごとにこの図に載せて決定するのもあり。15章:イテレーションの長さを決めるリリースまでの長さを考慮して決める。大体1~2週間がオススメ。イテレーションの計画を作成P288:第1イテレーションの計画づくりこの段階までで、ユーザーストーリーはあくまで「プレイヤーとして新しいゲームを開始したい」の単位から変更していない。ユーザーストーリーの優先順位が付けられ、優先度の上位から改めてユーザーストーリーをタスクに分割する。第14章:イテレーション計画づくりユーザーストーリーをタスク(+作業時間)に昇華する。この時点では担当者は決めない。ストーリー割当の基準ベロシティ駆動1イテレーションごとの目標ベロシティを決定し、それに収まる量のユーザーストーリーをそのイテレーションの目標に定める。定めた分のユーザーストーリーをタスクに見積もる。コミットメント駆動ユーザーストーリーを一つ選びタスクを見積もる。それのコミットがイテレーション内で確約できるなら対応し、次のユーザーストーリーを見積もる。確約できないなら、それまでの確約分がそのイテレーションの目標になる。大きくても1営業日=1タスク程度の粒度で有るべき。タスクが見積もれないときP170:調査をする・修正するの2タスクに分ける。第16章:ベロシティの見積もり下手に予想するよりは実際にやってみるほうが良し。個人レベルの作業可能時間も見積もり、1イテレーションあたりの作業可能時間も見積もることで、進捗の把握がしやすくなる(バーンダウンチャート)。第17章:不確実性に備えるバッファの計画1タスクごとにバッファをつけるとパーキンソンの法則により、いっぱいまで時間を使ってしまいがちになる。プロジェクトバッファを別枠で確保する。・先を見越した計画づくりチームAのデータがなければチームBの作業が進まないケースなど。その場合、チームAの作業がイテレーション0.5分だったとしても、チームBは次イテレーションからの作業開始とする。(チームAの作業が完全完了できなかったとき、イテレーション中での待ち時間を避ける、合流バッファの考え方リリースプランニングP296:プロダクトリサーチの結果などを用いて、リリース時点での製品状態を確定する。タスクボードP239:タスクボードを用意し、ストーリーごとにタスク・作業中・確認待ち(+その他)を貼り出すことで、視覚的にわかりやすくなる。イテレーション終了時点で行うことP251の報告書の内容を確認していく。ダウンチャートリリースまでの残り作業の理想グラフに対して、実際の残り作業量グラフを書き込む。理想に対する作業の進み具合・停滞具合が視覚化されるので、大きく問題が起きていたときに気づきやすい。作業進捗+作業が溢れてることを確認できる。メモバグの扱いP168そのイテレーションで発生したバグであれば、そのイテレーション内で直すべきである。前イテレーションのバグ・着手できなかったバグは次以降のイテレーションのバグタスクとして積まれる。Themeisle.。