スクラムを開発方法論に採用しているチームで開発者をしています。最近たまたま見積もりについての話題がチームであがり、私の経験や考えを整理してみる機会にしようと考えました。お断りとして、本稿の考え方が正しいと主張する意図はありません。世の中にはさまざまなチームや開発スタイルがあります。私が経験していない業務においては他のやり方もうまくいくケースがあると考えています。 スクラムガイド には見積もりの実践について明確な指針を提供していません。一方でスプリントを設定し、スプリントプランニングを行う上で通常はその期間内にスプリントゴールの達成を図ることから、必然的になんらかの見積もりを行うことを前提としています。インターネットを検索すると、プランニングポーカーとストーリーポイントを用いた見積もりの記事も多くみつかります。私の立場として、ストーリーポイントという見積もり手法をやや懐疑的にみています。この

本稿は Gergely Orosz 氏によって書かれた次の記事の日本語翻訳です。著者に翻訳の許可を得て公開しています。 blog.pragmaticengineer.com また本稿は DeepL Pro を使って下訳したものに手を加えています。日本語翻訳の不具合または誤訳については Gergely Orosz 氏ではなく、本稿のコメント欄にお願いします。 著者も機械翻訳を下地にしたやり方に関心をもたれたようです。 The article translated to Japanese: https://t.co/4uynyyhm4E The author was transparent and noted that the article is a modification of an ML-translated article. This person managed to transl

先日、ビジネスパーソン向けの Python 本を執筆したことを書きました。 t2y.hatenablog.jp 本稿では本書のことを「できるPy」と呼びます。 Amazon でいくつかカスタマーレビューもいただいて次のコメントをみつけました。 python3.7 対応ということで、pathlib を使ってる点が（古いpython は切り捨てる！的なところは）潔いと言えば潔いし、日本語のファイル名にも気を配っている記述はオライリーに期待するのは酷なところもある。でもこの本でもNFD問題は全くの記述無し。だめだろ、それじゃ。 Amazon CAPTCHA まさに仰る通りです。執筆時にそのことに気づかずご指摘いただいてありがとうございます。 ここでご指摘されている NFD 問題というのは、ファイル名のみに限った問題ではなく、Unicode の文字集合を扱ってエンコード／デコードするときに発生する

インプレスから「できる」シリーズの Python 版として発売されました。著者の1人として執筆に関わったので紹介します。 book.impress.co.jp 名前が長いので本稿では本書のことを「できるPy」と呼びます。誰も聞いていませんが、ハッシュタグは #dekiru_py です。 経緯 2018年3月頃に知人からビジネスパーソンを対象に本書の監修として企画・構成をしてほしいといった依頼をいただきました。そのとき、書き手はやる気のある若い人たちがたくさんいるからと、私が目次を作って全体の構成をまとめたら誰かがコンテンツを書いてくれて、私は出来上がったコンテンツをレビューするのが主な役割になるのかなと安易に考えていました。 結果的には私が他の執筆者全員に声をかけて書いてもらうようにお願いして、私自身も著者の1人として少なくない割合を執筆しました。 詳細な目次 インプレスサイトでは目次が公