SysMLを使ったロボットアプリの事例をOMGで公開 astah/SysML版(β)：An Agile Way：オルタナティブ・ブログ
昨年１２月、米国サンフランシスコでのOMGミーティングにて、産総研の安藤さんと共同で、SysMLのロボットでの利用の事例を発表しました。 非常に簡単な例題（お掃除ロボットRoombaを使いました）をSysMLでモデル化し、 そのままそれを、RTC(Robot Technology Component)仕様のXMLにして吐き出す。 それを、OpenRTM(RTCを動かすミドルウェア）上で動作させる。 RTM としては、「OpenRTM-aist(産総研)」と「Honda R&D RTM（本田技術研究所）」 １つのモデルから、２つの実装が動いた！という報告とデモになっています。当然、ツールは、AstahのSysML版(Beta）です。
なぜ Agile Japan 2013 の基調講演に James Grenning さんを呼びたかったか：An Agile Way：オルタナティブ・ブログ
Agile Japan 2013 が 5/24 に決まりました。みなさん、予定を空けて置いてください。 http://www.agilejapan.org/ さて、今回の基調講演の一人は、James Grenning さん、アジャイル宣言にサインした一人です。私が James さんをぜひ今回呼びたかったのには、理由があります。 日本には、エンタープライズ系の開発とほぼ同じくらい、組込みソフトウェア開発があります。日本の中でアジャイルがしっかり根を下ろすためには、日本のエンジニアの約半分を占める、組込み系ソフトウェアエンジニアに、アジャイルのメリットを示す必要があるのです。 アジャイルは速さを求めるだけではなく、品質を高める新しい設計のあり方をも示しています。その１つがTDD（テスト駆動開発）です。 Jamesさんは、このテスト駆動開発を組み込みC言語で行うという、 「Test-Driven
『リーン開発の本質』のあとがき。日本のアジャイルをつくりたい。：An Agile Way：オルタナティブ・ブログ
わけあって『リーン開発の本質』を再読しています。る。日本の中でアジャイル開発を、できるだけ管理者の言葉として伝えたかった本です。この本は本当にたくさんの人に読んでほしいなぁ。ここに、そのあとがき、として書いた文章を掲載します。 最後に書いた、 多くの間違った標準化が、「人は本来怠け者でありしっかり働かせるために規則を作らなければならない」とか｢人は交換可能である｣というメンタリティから発している。もし、組織の文化や方針の中心にこのような考え方があると、もしくは多くの管理者がこのように考えているならば、「決して」リーン活動は成功しない。そうではなく、「人の持つ工夫のモチベーションを活かす」こと、「一人ひとりの人を育てる」ことこそ、マネジメントの中心となるべきだ。「人」の要素はプロセスの中心である。ここをやり間違えてはならない。 日本のソフトウエア業界が、人の持つ知恵と力を大切にしながら、高品
アジャイル開発とスクラム ～顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント～：An Agile Way：オルタナティブ・ブログ
この本は、近年注目を集めているソフトウェアの開発手法「アジャイル」とその1つである「スクラム」を体系的に、事例をまじえて平易に解説するものです。 さらに、スクラムはソフトウェア開発のみならず、組織や企業活動、企業経営全体にまで適用できることを示し、この手法を取り入れ、ビジネスと一体となってソフトウェアを開発する組織や、その組織に息を吹き込む、新しいタイプのリーダーシップ像について考え、日本企業のリーダーシップと競争力を高めるために必要な、知識創造プロセスの重要性を、あらためて力強く提言する形になっています。 今回は、ソフトウェア開発者はもちろん、ソフトウェア開発をマネジメントする層、ITを利用してビジネスを考える方々、にぜひ届けたい内容になっていて、「縦書き」で書いたものです。日本語ではじめから書かれたスクラムの本を、技術視点だけでなく、経営視点から書きたかった、そして、その視点は野中先生
スクラムの原典を読み解く(4)：An Agile Way：オルタナティブ・ブログ
開発フェーズを重複させる 開発フェーズを重複させることで、メンバーは専門分野を超えてプロジェクト全体に責任感をもつようになる。 オリジナルでは... 自己組織化されたチームは独自のリズムを作り出す。開発と製造では、もともとスケジュールの考え方が異なっているのに、それが一体となって全体のゴールを目指すことになる。Type Aのように行程を逐次通過する手法（リレーアプローチ）では、前工程の要求事項がすべて満たされて始めて次の工程に移る。次行程へと移るチェックポイント毎にゲートを設けてリスクをコントロールする仕組みだ。しかし、この手法は上流で全体の自由度を過度に奪ってしまい、決定が後戻りができない欠点がある。また、ある行程で障害に出会うと流れが止まってしまい、そこがボトルネックになって全体の進行を阻んでしまうこともある。 一方、行程が重なり合ったType BやType Cのような手法（ラグビーア
ペア・プログラミング：An Agile Way：オルタナティブ・ブログ
アジャイルのプラクティスを、もう一度解説して行きたいと思います。できるだけ、日本の文脈にあった内容を加えて、実践できるように。また、野中先生に後でコメントを頂く予定。 ペア・プログラミング 文字通り、2人一組になってペアでプログラミングを行う。XPでの１つのプラクティスに挙げられており、１台のPCを交互に使って行うのが基本形。昨今ではデュアルディスプレーを使ったり、ネットワークと画面共有を使ったりして遠隔地で実践しているチームもある。 コーディングは単純作業ではない。１つ１つの変数や操作の名前を決めることや、その構造、アルゴリズムにいたるまで、多くの設計判断が入り込む、クリエイティブな活動である。また、ミスが起こりやすい作業でもある。刑事やパイロット、スキューバダイビングなど、リスクが高い作業はペアで行うことは現実の世界にはたくさんある。二人でプログラミングを行うことで、リアルタイムにレビ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
