「プロジェクトが成功するためならなんでもする」と考えておけば十分か - haradakiro's blog
まあ、大人げないと思いつつ。いろいろ考えるのですよ。 というわけでアジャイルに不慣れな受託のマネージャー向けに。 「プロジェクトが成功するためならなんでもする」 まあ聞いたことがあるよねこの言葉。SIer にいたころに協力会社の営業から。できれば頼みたくない会社だったりするんだが、そういうところに限って見積が安かったりするんだな。 で、トラブルになっても何もしない。唯一やってくれるのは、「人が足りないんですか？職務経歴書お送りしますよ。」だ。 あうち。 ソフトウェアにアーキテクチャがあるように、プロセスにもアーキテクチャがある。変わりにくいものと変わりやすいことを読むのが本質だ。 ソフトウェア開発において、みんなどこでも「なんでもやりますよ」をやるとどうなるかはみんな知っているだろう。大きな泥だんご(Big Ball of Mud)っていうやつだ。結局何もできなくなるまで、無駄を生み続ける
デイリースクラムで ScrumMaster がやるべきこと - haradakiro's blog
デイリースクラムのやり方は、いろいろなところに書いてあるし、チームによっていろいろ工夫をしていると思うので、ここでは書かない。 Scrum Guide にも書いていないけれど、ScrumMaster が絶対にやるべき重要なことがある。 メンバーの顔色を確認することだ。メンバーの体調を計測することだ。それだけでも、ScrumMaster がフルタイムの役割である十分な理由がある。 メンバーの体調は、常に気を配っていないと気付くことはできない。デイリースクラムの３つの質問に気を遣うと同時に、ScrumMaster はメンバーの体調についても十分注意を払う必要がある。 どうも風邪薬や栄養剤のCMのおかげで、体調が悪くても会社にいくべき、のような風潮がある。でも、この時期、インフルエンザのメンバーを一日出社させてしまったら、そのスプリントは終わりだ。チームが全滅するだろうし、他のチームにも迷惑をか
Scrum ではコードレビューをどうやっているか？ - haradakiro's blog
森崎先生のソフトウェアレビューの講演を聴いて、今やっているレビューの方法をまとめときたいと思ったので、まとめてみます。今回は、コードレビューの話です。Scrum ではといっていますが、レビューのやり方はチームによって違うので、あくまでも例ですよ。PBI とか、仕様、ドメインモデルのレビューの話はまたこんど。 レビューの目的は、もちろん作成するプロダクトの品質向上です。障害を検出するのも、もちろん目的ではあるのですが、それ以降のスプリントで作成されるコードで同じ障害を作り込まないのが目的としては大きいです。そのため、レビューはプロジェクトもしくはチーム立ち上げ後、数スプリントで重点的にやります。後はスプリントの振り返りでレビューをやりたいが出てきたら、チームで決めます。 レビューのやり方 基本はチーム全員で集まってやります。最大２時間。それ以上やっても集中力が続かないので。プロジェクタで対象
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
