スクラムを味方につけろ！ - SEA関西プロセス分科会 - - ソフトウェアさかば
SEA関西プロセス分科会であったScrumワークショップに参加しました。アジャイル開発プロセスであるScrumには、以前から興味がありました。しかし、かつてのCMMブームのトラウマから少し不安がありました。それは 「スクラムは敵か味方か？」 ということです。アジャイルの目指すものは大いに賛同できるものですし、合理的であると考えていました。しかし、スクラムが普及し、組織的な導入が増えるにつれて、「本当に大丈夫なのか？」とおぼろげな不安を抱いていました。 しかし今回のワークショップに参加して、その疑問は氷解しました。 ＜CMMブームのトラウマ＞ 敵か味方かという不安は、1990年代半ばにCMMが普及しだした頃にも感じていたことです。それまでのソフトウェア工学の成果を集大成し、組織の成熟していく道を示したCMMについて、ソフトウェア工学を学んだ人間として、必ずしも反対するものではありませんでした
CodeReadingWiki：Rainy Day Codings：So-net blog
先のエントリ [1] の最後で GNU GLOBAL が作った HTML を Wiki に取り込むアイデアについて書いた。その後実際にそのアイデアの実装をしてみたのでこれを CodeReadingWiki と名づけて公開することにした。ダウンロードは [2] からできる。 正確に言うと Wiki に取り込むのではなくて GLOBAL の HTML を Wiki 化するというほうが正しい。ソースコードの任意の行をダブルクリックすると書き込みフォームが出てきてコメントを挿入できるという感じの使い勝手になっている。大げさな視覚効果はないけれども AJAX を使っているのでページ遷移なしで編集ができる。結構便利。 以下は README.txt から。 CodeReadingWiki 説明書 ====================== * 概要 CodeReadingWiki は「他人の書いたコー
なぜWIPの制限が重要なのか
アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください（初回相談無料） みなさんこんにちは。@ryuzeeです。 WIPの制限についてExplaining why Limiting WIP is so importantにて良い説明があったのでご紹介します。 ※図は上記サイトより引用 1. WIP(仕掛り中)の同時許容個数を減らす個人的には1開発者が同時に着手するタスク数は1〜2個であるべきと思っています。 したがって、WIPが「2 * チーム人数」より多いのは実質的に制限がなされていないことになってしまい効果が出ないかもしれません。 現実的に何個にするのかは仕事の内容やチームの人数に依存するので、運用しながら順次見直していけば良いでしょう。 ただし安易に数値を増やすことは慎むべきです。 2.
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
