Embedded Files
スクラム入門(THESCRUMPRIMER_jp)
本文書の原文はこちらから。 (You&I)
P.2 紹介されている図書 (You&I)
http://www.amazon.co.jp/dp/4894715899 (アジャイルソフトウェア開発スクラム)
P.15 紹介されている図書 (You&I)
http://www.amazon.co.jp/dp/4274066983 (アジャイルレトロスペクティブズ)
従来のソフトウェア開発(P3)
P.3 1行目 「”フォーターフォール”」いきなりtypoですね・・・。 (You&I)
P.3 6行目 「利害関係者」用語集に説明がありますが、アジャイル本ではステークホルダーと表現される事もあります。 (You&I)
P.3 中段 「イノベーション」イノベーションとは技術的な革新に留まらず、世の中に普及する新しい概念を全般に指す言葉である。 (You&I)
P.3 下の方 「当然のことをする」原文では「do the right thing」正しい事をするとも読めるが、ここでは改善活動を行いより良い製品にしようとする事を差すかと。 (You&I)
P4「そして、逐次的な開発はおもしろくありません」個人的にはこれがアジャイルへの動機として大きいです（ヤマモト）
製造業におけるライン生産とソフトウェア作成は根本的に違うものだと認識・理解する事も大事ですね。 (You&I)
P.4 「残念なことに、多くのチームは反対のこと「より一生懸命にしようと努力すると、より悪くなる！に気づきます」」従来のやり方が正しいという考え方。やり方を変えてはいけないだったり、前と同じやり方をしていれば失敗しないという考えは正しいだろうか？ (You&I)
アジャイル開発とスクラム(P4)
スクラムの概要(P4)
P.4 「スプリント」 アジャイル本では、「反復」「イテレーション」と表記される事もあり。 (You&I)
P.4 「決して延長されません」スプリントをまたいで作業を行う事は可能であるが、それは見積ったタスクの粒度に問題があったと見なされる。 (You&I)
P.5 「チームは利害関係者と共に、構築した製品を実際に用いてスプリントを検査します。参加者は、次のスプリントで具現化できるフィードバックを得ます。」ふりかえりの事。 (You&I)
P.5 「スクラムは開発工程を短くし」開発期間が短くなる訳ではない。スプリント期間で出来る範囲のタスクについて、設計～開発～テストの流れを行う事を短くと表現している。 (You&I)
スクラムの役割(P5)
P.6 上段 「実際問題として、「価値」とは曖昧な表現です。」誰にとって価値があるものなのかを考える必要がある。自分にし価値のないものは無駄の可能性がある。 (You&I)
P.6 上段 「これは、内製のアプリケーションではよくあります」日本では請負作業が中心であるが、アジャイル本にもある通り欧米では内製開発が多い。 (You&I)
P.6 中段 「ブタとニワトリの物語(冗談話)」 (You&I)
P.6 中段 「書類作成」アジャイル開発でも必要なドキュメントは作成する。無駄なドキュメントは作らない。 (You&I)
P.6 中段 「多人数の集団に適用する場合では、複数のスクラムチームで構成されます」 Scrum of Scrumと呼ばれます。下位のチームを束ねる上位のスクラムチームを構成する。 (You&I)
P.6 下段 「スクラムマスターは、チームの管理者でもプロジェクト管理者でもありません」プロマネがスクラムマスターをやる訳ではない。 (You&I)
P7 真ん中あたり 「スクラム（で）の役割が変化する間、とても貴重な役割です。」ちょっと意味が分かりません。（ヤマモト）
↑ While their role changes in Scrum, they remain valuable. ← 原文
スクラムの中で、 いろいろな機能を担っている（多能工） 3つの役割以外に、「変わらない単一の機能的な役割」があるということなのでしょうか？（尾画茶）
P.7 下段 「マイクロマネージメント」上司が部下に過剰介入したり、部下の権限範囲の事であっても部下に意志決定させない状態のこと。 (You&I)
スクラムの開始(P7)
P8の図2は「スクラム」ではなくて「プロダクトバックログ」。
同じくP8の上から4行目の「...は含まれません。」は「...も含まれます。」の誤訳と思われます。（ヤマモト）
P.8 上段 「クレジットカード合法化を早く」クレジットカード認証の高速化の誤訳 (You&I)
P.8 上段 「別に追跡システムがあります」作業項目としてのプロダクトバックログとは別に、不具合項目向けにバグトラッキングシステムのようなものがあるという事。 (You&I)
P.8 上段 「ユースケース」UMLのダイアグラムの一つ。ユースケース図だったりユースケース記述だったり。 (You&I)
P.8 上段 「ユーザーストーリー」書籍アジャイルサムライでの定義(P.105～)は以下の通り。 (You&I)
顧客に取って何かしらの価値が書かれている事(お客さんが対価を払っても良いと思える事)
EndToEndになっている事(他のストーリーと独立している、機能縦断的で一連の流れになっている事)
交渉の余地がある
テストできる
小さい
見積もれる
P8真ん中よりすこし下あたり「スクラムは、実現するための技術または、プロダクトバックログ項目の優先順位付けの方法を定義しません。そして、見積りの技術も定義しません。」スクラムのスタンスが明確に表れていると思います。興味深いです。（ヤマモト）
P.8 中段 「相対的に見積もります」アジャイルな見積において相対見積は基本。何か基準を決めてそれとの対比で見積もっていく。 (You&I)
P9 「優先度の低い項目は、着手まで時間があり、”粒度が荒い"もしくは大きい状態でよ」い。なるほど。論理的だと思います。（ヤマモト）
スプリントの計画(P9)
P10 図3は「実現可能時間の見積り」というより「稼動可能な時間の見積もり」ですよね。（ヤマモト）
P.10 中段 「多能工」トヨタ生産方式由来の言葉。各人の能力を平準化して生産の偏りを減らして生産性を高める。 (You&I)
P.11 全般的に翻訳が直訳的ですね。 (You&I)
P.12 上段 「プロダクトオーナーは、次のスプリント開始までにプロダクトバックログを変更しなければならない」プログラマが開発中にプロダクトオーナーは何をするのか。 (You&I)
デイリースクラム(P12)
朝会（デイリースクラム）で話すことは、昨日何を*完了*させたか、今日何を*完了*させようとしているか、なんですね。厳格なんだなと感心しました。（ヤマモト）
スプリントバックログとスプリントバーンダウンチャートの更新(P12)
プロダクトバックログの見直し(P13)
P14冒頭「しかし、頻繁に利用される技術は、障害を取り除きチームとプロダクトオーナーが献身的に働けるスプリントの終盤に集中します。」
は「よく使われるテクニックは、スプリントの終わりごろに行われる集中したワークショップです。これによりチームとプロダクトオーナーは割り込みを避けて作業に集中することができます。」だと思います。（ヤマモト）
P.14 「２週間のスプリントでは、スプリントの５％(半日)をプロダクトバックログの見直しに費やします。」この改善活動をスプリントのどのタイミングで行うのか記述がありませんね。チームで行うものと定義があるので、スプリント中には実施できない気がします。ふりかえりのタイミングでやるのでしょうか？ (You&I)
スプリントの終了(P14)
「スプリント期間を決して延長しません。」タイムボックスの考え方ですね。時間枠で縛って、もし計画通りに行かなかったらなぜかを考えてなにかを改善するきっかけにするわけですね。（ヤマモト）
スプリントレビュー(P14)
スプリントレビューにおいて、デモが主目的でないとは！驚きです。（ヤマモト）
スプリントレトロスペクティブ（ふりかえり）(P15)
「次のスプリントで少しの改善を試み、次のレトロスペクティブ（ふりかえり）でその結果を確認する」PDCAサイクルってやつですね。（ヤマモト）
リリースバックログとバーンダウンチャートの更新(P15)
図9リリースバーンダウンチャートの縦軸はスプリントバーンダウンチャートと同じで「残り作業の新たな見積り」となっていますね。あれー？「残りストーリーポイント」がふさわしいと思うのですが？（ヤマモト）
次スプリントの開始(P16)
リリーススプリント(P17)
リリーススプリントでは探索的テストや「~性テスト」などを行うといいかな、と思いましたが、それらも通常のスプリント内でこなすことが推奨されているわけですね。（ヤマモト）
リリース計画と初期プロダクトバックログの見直し(P17)
アプリケーションもしくは製品の焦点(P18)
非生産的な並行作業という考え方は、TPSの考え方につながるものがありますね。（ヤマモト）
共通課題(P18)
「もう一つのよくある過ち」の説明がよくわかりません。スクラムは~を要求しませんが、多くの場合~は有効なプラクティスです、ってことですかね？（ヤマモト）
付録：専門用語(P20)
P21 プロダクトバックログ項目：「ビジネス上の重要性と依存性によって優先順位付けされ見積られた、機能要件、非機能要件および課題」ですかね。（ヤマモト）
Page updated
Google Sites
Report abuse