こんなスクラムには気をつけろ!?
こんにちは。@ryuzeeです。 支援をしている際に、こういう兆候があったら注意して見る、というポイントがいくつかあるので共有します。 あくまで課題発見用のツールなので、マルバツ表を作ってどうこうする、という類のものでもないですし、そうすべきでもありません。 スクラムマスターの人、外部から支援する人は、自分用の確認ポイントを整理しておくと良いと思います。 なお、スクラムを実践すること自体は目的足り得ないので改めて言っておきます。 全体なんでもアジャイルでやろうとするそもそもアジャイルを採用することが目的化しているプロジェクト初期にマイルストーンやスケジュールを決めていない十分にトレーニングを受けていない認定資格をとればそれで十分だと思っている全体の要件やアーキテクチャを考えずいきなりコードを書く予定できることなのに、「アジャイルだから」と予定しないドキュメントを書かない文化や考え方を変える
ベストプラクティスは全員にとってベストなのか？
全国1000人のエンタープライズベストプラクティスマニアのみなさんこんにちは。 Esther Derbyさんといえば、アジャイルレトロスペクティブズ 強いチームを育てる「ふりかえり」の手引きの作者で有名ですが、最近のブログ記事、Seven Agile Best Practicesが良い内容だったので、紹介します。 アジャイル開発でもクラウド導入でもDevOps推進でもいきなりベストプラクティス教えてほしい、とかどうやったら一番うまくいきますかとか聞かれることがありますが、全部に適用できるようなものはありません。 売っているプラクティスを買ってきてうまくいくのであれば、もっと高い金額で売るでしょうし、次から次に新しいものが出てくるはずがありません。またたとえうまくいったとしても自分たちで変化に対応できなければいずれ陳腐化していきます。 本当に大事なのは自分たちの問題だと認識して当事者として考
アジャイルのレトロスペクティブはなぜ難しいのか？
レトロスペクティブ（ふりかえり）は，チームの作業方法を見直して修正することによって，自らの作業を改善するものだ。より多くの価値をユーザに提供する手段として，アジャイルの重要な手法のひとつに数えられることも多い。しかし時には，レトロスペクティブを行うのが難しく思われることもある。変更すべき対象がチームメンバのコントロール範囲外にあると感じられたり，改善の余地がないように思われたり，適切なアクションの定義が難しく感じたられりすると，アクションの定義よりも先に不満が口をつき始める。そうなるとレトロスペクティブがつまらない，単なる時間の浪費だと感じられてしまうのだ。このような問題に対処して，より有意義なレトロスペクティブを行う方法を見つけるには，どうすればよいのだろう？ Keith McMillan氏のブログ記事 agile concept of the week: retrospective に
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
