DZoneの自動化テストのガイドブックを読んでみた - The HIRO Says
海外の知人からの紹介で、『DZone's 2019 Guide to Automated Testing: Facilitating Continuous Delivery』というガイドブックを読んでみました。 2019年版とちょっと古めではありますが、 2021年の現時点でも、実務で参考になる／役立つ点が多かったこと 日本国内で、同ガイドブックのまとめ記事を見つけられなかったこと 自分用にメモを残しておきたかったこと から、個人的に気になった点やポイントをまとめてみました。 What Is This Guide? IT系情報サイトのDZoneが2019年に発行した、ソフトウェア業界における「自動化テスト」（Automated Testing）*1に関するガイドブックです。 DZoneの読者約500名に対するアンケートに基づく分析、および同調査に協力したソフトウェアベンダー各社の自動化テス
怒りを感じた時にできる「ちょっとした」工夫 - The HIRO Says
「最近怒りっぽくなったな〜（アカン）」という自省に基づくポエムです。 事例 皆さん、このような経験はありますか？*1 上司から、隣のチームへ書類を提出するよう頼まれた 実際に書類を提出してみると、隣のチームから「この書類はなんですか？」と言われた このような場合、私は即座に「なんですかとは何だ」「何で事情を把握していないんだよ」「バカにしているのか」と考え、怒りを感じがちです。*2 ポイント 上記の事例は、自分の前提と違うことが起きたことが、怒りのきっかけです。 上司は、隣のチームへ、私から書類が提出されること教えているはずだ／べきだ 隣のチームは、書類が提出されることを知っているはずだ／べきだ 隣のチームは、書類が提出されたら受け取るはずだ／べきだ 「〜いるはずだ／べきだ」という言葉が多いですね。 しかし、ちょっと冷静に考え直してみると、上司から隣のチームに話がそもそも届いていない可能性
長いミーティングの改善例 - The HIRO Says
SNSに溢れる、日々の業務への不満。 その中でも、「ミーティングが長い」「ミーティングが多すぎる」は、皆さんも頻繁に目にされている／経験されているのではないでしょうか？ 今回、業務で試してみて一定の効果が見られた、ミーティング時間の短縮の事例を紹介させていただきます。皆さんの不満を減らすヒントになれば幸いです。 1. 課題 複数チーム間で、お互いの進捗状況を報告・共有するミーティングにて。 報告の内容・粒度が、チームごとにバラバラ 各チームが、自分たちがやったことを事前にまとめたwikiを延々と読み上げていた 結果、時間内に終えられず、報告できないチームが出てきていた 回を追うごとに各チームの報告内容が長くなり、報告できないチームが増えつつあった ただwikiの内容を「聞かされる」だけで、何の意思決定も課題解決もできていなかった そのため、主催者・参加者の双方が大きなストレスを感じ始めてい
ソフトウェア開発者の評価指標を考えてみた2019 - The HIRO Says
私の勤めている会社は、ちょうど今が（人事）評価の時期です。 今日もチームメンバーと「どんな評価指標を使うのが良いのか」という雑談をしていたのですが、その内容が他のチーム・会社でも使えそうな気がしたので、ブログにまとめてみました。ちなみに雑談のまとめなので、あくまでアイデアの1つとして読んでいただければ幸いです。 ちなみに評価対象は、ソフトウェア開発に関わる人、具体的にはプログラマ・インフラエンジニア・QAあたりを想定しています。 1. ダメな評価指標例 まずは、「これは（アカン）」というものから。 (1) プログラム・コードを作成・追加した行数 そもそも、「行数が多い == 生産量が多い」ではないです。 何も考えずに行数だけ増やしてしまうと、メンテナンスコストやバグの混入確率が増え、結果としてチーム・会社にマイナスになります。 （実際に学術的にも実証されています。） (2) GitHubへ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
