P300 スパイク

本書では、以下の様に定義されていた。

スパイクは短時間、タイムボックスでおこなう活動で、大規模だったり曖昧だったりするタスクやストーリーを完成するのにどんな作業が必要か見つけるためのものである

[注意点]
スパイクで見つけたタスクやストーリーは、現在のスプリントバックログに乗せれない。スパイクから見つかったストーリーやタスクは、プロダクトオーナーが優先順位をつけなければならないからである。
理由としては、現在のスプリントバックログにコミットしており、新しいタスクにコミットなどしていないし、何が出てくるかも分からないタスクにはコミットできないためである。
(所感)
とはいえ、スプリント期間が短いプロジェクトにおいては、すぐスプリントが終わって、次とかにタスク化されるかと思うので、スパイクやっている最中に含めるということは起きにくいかもしれない。
(なお、本書では1か月位のスプリントが中心で書かれた内容っぽいので、スパイクという考え方に違和感はない)

スクラム現場ガイド -スクラムを始めてみたけどうまくいかない時に読む本-

P299 税

本書ではチームの税は、下記の様に定義する。

会社のための仕事や必須の要求事項であり、チームやグループに重荷となる義務、任務、請求など

スクラムのオーバーヘッドについても、税としてまとめて考えている。
計画、ふりかえり、レビューはスクラムの税である。

スクラム現場ガイド -スクラムを始めてみたけどうまくいかない時に読む本-

P36 テストの小ワザ

## テスト計画

• テスト計画書を1人で作成してはいけない
• テスト計画書は全員の目につく場所に置く

## テスト設計

• 「なぜこの値を入力するのか」を明確にする
• 期待値に「処理が正しいこと」と書いてはいけない
• 1つのテストケースに2つの期待値があったら危険
• 仕様書に「~できる」を見たら「~できない」も連想する
• 仕様書が不十分でもテストケースを書き始める

　- どの仕様が不明確なかを書き出しながら書き進める
　- 仕様が決まったタイミングで更新しやすい様に工夫は行うこと

## テスト実行

• テストケースのできた順にテスト実行してはいけない
• 10分で判別できない不具合は「投げ込み」ボックスへ

　- 抱え込まずに一旦計上して、バグ/非バグの判定をチームでハンドリング
　- 10分はあくまでも目安

• 2回以上出た同じ質問を思い出す

　- 振り返りなどの際に同じ質問が出たことなかったかを確認する(ex. テスト環境、テストに付随する作業)
　- 振り返りの場だけでなく、朝会や夕会の場でも共有すると良いhttps://tech.nikkeibp.co.jp/atcl/nxt/mag/sys/18/SYS_backnumber/201909/

tech.nikkeibp.co.jp

ソフトウエアテスト実践ガイド (日経システム構築)

blame：ファイルの各行の最終コミットは誰なのかを確認する

【ユースケース】
ある時期にコミットされたファイルに対して、そのファイルの調査したい箇所が最後に誰が更新したコードなのかを調べたい時

【Forkを用いた調査方法】
調べたいタイミングのコミット箇所をまずは選択する。
その後、Changesタブ or FileTreeを選択し、調べたい対象のファイルを見つける。
調べたい対象のファイルを選択した状態で右クリックを行い、Blameをクリックする。
すると、モーダルウインドウが表示され、対象ファイルの左側に、どのタイミングでコミットされたものかが表示される。

わかばちゃんと学ぶ Git使い方入門〈GitHub、Bitbucket、SourceTree〉

Gitが、おもしろいほどわかる基本の使い方33 改訂新版〈バージョン管理、GUI、Sourcetree、Bitbucket〉

Stashを用いて変更を一時退避

[やりたいこと]
リポジトリに対して修正を行っていたが、一時的に同じブランチに対して先行して変更したい内容が現れた。
今直している内容のままではテストが動かせなく、ブランチを新しく作成するなどごにょごにょすると時間かかるので、手軽にブランチの元の状態で修正を行いたい。

[対応方法]
Stash機能を用いれば良い。

[ForkでのStash保管方法]
修正を行ている状態で、Stashアイコンをクリックする。

Stash

モーダルウインドウが表示されるので、適当な名前を付けて保管する。
この際、どのブランチか？という情報は補間してくれるので、どの様な内容かということを記載したら良い。
また、チェックボックスは新しく作成したファイルはStash対象として退避させるか？という事なので、基本的にはチェック付けとけばよいと思う。OKボタンを押すと、修正したファイルなどは、一度ブランチの元の状態に戻される。
その後、同じブランチに対して、一時的に行いたい内容を操作すれば良い。

[ForkでのStash復元方法]
Forkの左端のペインに表示されている欄で、Stashesから戻に戻したい内容をフォーカスしたのち右クリックする。 Apply 'On ブランチ名 コメント'という部分を選択する。
Stashに成功した場合、Stashファイルを削除するか？というチェックボックスがあるので、それらを選択した後にOKとすればよい。

GitHub実践入門 ~Pull Requestによる開発の変革 (WEB+DB PRESS plus)

GitLab実践ガイド impress top gearシリーズ

パッケージエクスプローラとエディタで開いているコードを連動させる

行いたい事

eclipseのエディタで開いているコードが、パッケージ上どこに存在するかを簡単に見つけたい。

対応方法

パッケージエクスプローラの両方向の矢印アイコン(エディタにリンク)をクリックする。
以後、カレントエディタに連動して、パッケージエクスプローラ上に該当モジュールが選択される様になる。

エディタにリンク

その他

細目にON/OFFした方が幸せなこと多いかも。
(ショートカットキー知っている方教えて下さい。。。)

JavaエンジニアのためのEclipse パーフェクトガイド

IntelliJ IDEAハンズオン――基本操作からプロジェクト管理までマスター

Forkでファイルの修正履歴を確認する方法

ファイルの修正が行われているコミットを選択する。
下のペインにFile Treeというタブが表示されるので、それを選択する。
そうするとファイルツリーが表示されるので、対象のファイルをフォーカスさせた状態で右クリック後Show File Historyを選択する。
結果、File Historyというモーダルウインドウが表示され、そこに対象ファイルのコミット履歴が表示される。
なお、任意のコミットを二つ選択を行った後に右クリック後External Diffを選択する事で、変更箇所比較を行う事が可能である。(※1)

※1　事前に[file] - [preferences]を選択した後、Integrationタブ内のExternal Diff Tool欄に比較ツールを設定しておく必要がある。当方は、今までWin Mergeを用いていたが、最近はMS VSCodeを設定して利用している。

GitHub実践入門 ~Pull Requestによる開発の変革 (WEB+DB PRESS plus)

はじめてのVisual Studio Code (I・O BOOKS)