クリストファー・アレグザンダー再考 | 難波和彦
クリストファー・アレグザンダー再考 | 難波和彦 A Reconsideration of Christopher Alexander | Namba Kazuhiko 最近、若い建築家や建築研究者がクリストファー・アレグザンダーのデザイン理論に注目している。大きな潮流になっているわけではないが、彼らの紹介を通じて、アレグザンダーのデザイン理論は再び見直されるような予感がする。彼らは現時点でのアレグザンダーのデザイン理論に注目しているが、それだけでは彼の理論の可能性を十分にくみ取ることはできない。僕の考えでは、現在の彼の理論よりも一九六〇年代の初期アレグザンダーの理論のほうに学ぶべき可能性がある。初期の理論はデザインのあり方を根本的に問い直しているからである。現在のアレグザンダーの理論は一九六〇年代から紆余曲折を経て辿り着いた、彼なりのひとつの終着点である。僕たちには彼とは異なる展開の選択
InfoQ: 「かんばん」をソフトウェア開発に適用する: アジャイルからリーンへ
図1 かんばんとプル生産方式 図1は、かんばんシステムの抽象的なモデルです。図1で示されているのは、上流と下流の2つのプロセスであり、上流プロセスが下流プロセスに部品を供給しています。最終的な顧客に製品を供給するために、プロセスは部品を生産し、その部品を下流に流し込まなければなりません。しかし、多すぎてはいけません。過剰生産は最悪のムダだと考えられます。そこで、過剰生産を防ぐため、上流が完成した部品を下流に押し出す(プッシュ)のでなく、その代わりに、下流が上流から自発的に部品を取ってきます(プル)。部品が置かれる場所は、「ストア」と呼ばれます。(または、「スーパーマーケット」3 - 大野耐一氏 がアメリカのスーパーマーケットに行った時にかんばんの最初の考えを手に入れました。そこでは、店の人ではなく顧客自身が店の中で必要なものを取りに行きます。) ストアは上流に置かれ、WIPの「バッファ」や
スクラムをカンバンで強化するスクラムバン！
たまに耳にする「スクラムバン」が気になったので調べてみました。元ネタはCorey Ladasさんによって書かれた「Scrum-ban（スクラムバン）」です（2008年の記事なのでちょっと古いけど）。なかには読み間違い、勘違いがあるかもしれないですが、読んで感じた私の主観をふまえてまとめてみます。 スクラムバン？ スクラムが世界的に広がっているので、その中でカンバン（方法論としてのカンバンです）に興味を持っている人を見つけるのはかなり簡単でしょう。なぜなら、みんなプロセス改善やマネジメント、リーンのアイデアなどに興味があり、仕事で活用したいと思っているからです。 カンバンはチームの性能を高めることに役立ちます。すでに現在、スクラムに取り組んでいるところでも活用できるはずです。スクラムバンでは、スクラムとカンバンのハイブリッドを現場で活用する方法が説明されています。 価値と量をコントロールする
アジャイル時代のモデリング: アジャイルチーム拡大のためにはコードの次に何を保つべきなのか
図１．シンプルなスクラム構成 この最小限のフレームワークの中で、チームのインプットとなるのが”ユーザ要求”としての”プロダクトバックログ”です。そして、アウ トプットは”動くソフト ウェア”としてのコード（”製品コード”と”テストコード”）です。 そこには他の設計要素が明示的に現れてはいません。スプリントの中で作られたすべての意図的な設計はチームの財産として実行コートの中に組み込まれるのが 望ましいですが、そこには直接コード化されない情報もあります。スクラムは開発プロセスであり、設計に関しては敢えて何も言及していませんが、設計と設 計活動はチーム内部であいかわらず行われています。 Grady Booch氏は”コー ドは真実ではあるが、すべての事実ではない” と語っています。だから、もしそこにコードで表現又は伝われない情報が残されるとしたら、私達はその情報をどこに格納できるでしょうか？その質
改善のためのちょっとしたコツ
改善してますか？ 改善がうまくいっていない、改善に疲れたと思っているなら、ちょっと助けになるかもしれません。Read less
なぜ見積もりはバラバラになるのか？「モバイル見積もり勉強会」 #モバイル見積 を通じて分かったこと - ひつじのにっき
2014/1/24(金)19:00-21:30 に スマホアプリを新規作成したらいくらかかる？モバイル見積もり勉強会 #モバイル見積 を@youten_redoと共催しました。 勉強会の目的と資料等 開始前の、勉強会の目的は「見積もりのノウハウ共有とかそんなのが1割とあとは興味本位が9割」という具合でした。 今回、勉強会を通じて色々な発見があったので、見積もりという単語のあいまいさと考え方についてエンジニア視点でメモしておきます。 割と書きたいことだけ書いていること、ケーススタディの一つなので汎用性の高い話ではなく特定分野のお話ということ、を念頭に置いてください。 イベント詳細 http://www.zusaar.com/event/3147004 『カレー屋チェーン店「ペッパー警部」の公式アプリを作る』仮想案件の見積もりを各チームで行う、という流れです。 共催者、参加者の感想は http
Git を学ぶ - チュートリアル、ワークフローおよびコマンド | Atlassian
Git は、元々 Linus Torvalds によって 2005 年に作られた、無料でオープンソースのバージョン管理システムです。他の SVN や CVS といった中央バージョン管理システムと違って、Git は分散型で、すべての開発者がローカル環境で彼らのコードのリポジトリの完全な履歴を持っています。これは、最初のリポジトリのクローン作成に時間がかかりますが、commit、blame、diff、merge、log といったこれに続く作業を劇的にスピードアップします。 Git は多くの革新的で強力なワークフローやツールにつながる、リポジトリ履歴のブランチ、マージ、および書き換えに非常に役立ちます。プル リクエストは、チームが Git ブランチでコラボレーションを行い、他のコードを効果的に見直すことができる、非常に人気のツールです。Git は現在世界で最も広く使用されているバージョン コント
スクラムの先へ進む
アジャイル初心者の多くは、スクラムでアジャイルをはじめる。スクラムには明確な指針、ルール、プラクティスがあり、チームにアジャイルを導入するのに役に立つ。ところがスクラムもまた組織の中でさまざまな問題に直面し、多くの会社にとって成功を難しくする一因になっている。スクラムをやってきた人たちは自問する。どうすればよいのだろう？ スクラムだけで十分なのだろうか？ Jimmy Bogard氏は、なぜスクラムをやめたのか、なぜ彼のチームはスクラムで成功した後、そのコアプラクティスをいくつかやめることでパフォーマンスを改善できたのかについて、次のように説明する。 イテレーションはpullベースのアプローチほど効率的ではない。 タイムボックスで仕事をすること、割り当てて空きを埋めることには、何かしら心理的影響があります。明確なタイムボックスのイテレーションをやめて、できる限り早く納品することにのみ注力する
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
カンバン初心者のための『カンバン・キックスタート』
Service development for users - Speaker Deck