リーンのセットベース開発的なアプローチをした事例をまとめてみました。
セット・ポイント開発のススメ
組込みでの事例です。
2014年2月21日金曜日
2014年1月23日木曜日
2014年1月7日火曜日
仕事はじめ
AVASYSは6日が初日でしたが、
私はサボりました....
7日が仕事はじめです。
今年もリボンモデル実績を増やして、更に進化させていきます!
まずは、昨年の実績をちゃんと整理しなくては....
私はサボりました....
7日が仕事はじめです。
今年もリボンモデル実績を増やして、更に進化させていきます!
まずは、昨年の実績をちゃんと整理しなくては....
2013年12月27日金曜日
2013仕事おさめ
今日で仕事おさめです。
今年は、みなさんの成果をリボンモデルという形に出来ました。
公開後も少しずつ成長していて、少しずつ成果も見え始めています。
来年も、このリボンモデルに更なる成果を取り入れたいと思っています。
みなさん1年間お疲れ様でした!
今年は、みなさんの成果をリボンモデルという形に出来ました。
公開後も少しずつ成長していて、少しずつ成果も見え始めています。
来年も、このリボンモデルに更なる成果を取り入れたいと思っています。
みなさん1年間お疲れ様でした!
2013年12月18日水曜日
野中さん熱い!
やっとこ「アジャイル開発とスクラム」読みました。
野中さん、とても熱い方ですね!
私も久しぶりに熱くなりました。
で、さっそくお気に入りにの表現をリボンモデルに拝借しちゃいました。
さて、どれでしょう?!
野中さん、とても熱い方ですね!
私も久しぶりに熱くなりました。
で、さっそくお気に入りにの表現をリボンモデルに拝借しちゃいました。
さて、どれでしょう?!
2013年11月20日水曜日
TDDを開始するのはいつ?
みなさんはTDDをどのようなタイミングで開始していますか?
私はアーキテクチャが決まり、
テストフレームワークの環境構築が出来てから
だと思っています。
そんなの当たり前 と思う方もいると思いますが、
この「テストフレームワークの環境構築」には、
アーキテクチャの雛形ソースや
テストの為の実際のサンプルコードや例などが
いくつか出来ている状態までを含んでいます。
ここまで出来ていないと
恐らくTDDは難しいと思っています。
ここまでの環境が無いと
何から手を付けてい良いかが分からないですよね。
つまり、
環境が無い状態では、TDDは難しい
という事だと思っています。
昨今の顧客要求&論理量では
いきなりテストを作る といってもなかなか難しいですよね。
なので、いかに早い段階でアーキテクチャを決定し、
開発で使用するテストフレームワークを構築するか
が最大のポイントであり、プロジェクト成功の鍵である。
と思っています。
ですが、このアーキテクチャ決定と
テストフレームワーク構築が
難しいのでしょう。
難しいというより、やるべき事なので、
簡単とか難しいとか考えた事は無いですが、
やはり、これも昨今の要求の複雑化の影響だと思いますが、
この2つが難しい現状である事は間違い無いと感じています。
みなさんは、どのタイミングでTDDを開始していますか?!
私はアーキテクチャが決まり、
テストフレームワークの環境構築が出来てから
だと思っています。
そんなの当たり前 と思う方もいると思いますが、
この「テストフレームワークの環境構築」には、
アーキテクチャの雛形ソースや
テストの為の実際のサンプルコードや例などが
いくつか出来ている状態までを含んでいます。
ここまで出来ていないと
恐らくTDDは難しいと思っています。
ここまでの環境が無いと
何から手を付けてい良いかが分からないですよね。
つまり、
環境が無い状態では、TDDは難しい
という事だと思っています。
昨今の顧客要求&論理量では
いきなりテストを作る といってもなかなか難しいですよね。
なので、いかに早い段階でアーキテクチャを決定し、
開発で使用するテストフレームワークを構築するか
が最大のポイントであり、プロジェクト成功の鍵である。
と思っています。
ですが、このアーキテクチャ決定と
テストフレームワーク構築が
難しいのでしょう。
難しいというより、やるべき事なので、
簡単とか難しいとか考えた事は無いですが、
やはり、これも昨今の要求の複雑化の影響だと思いますが、
この2つが難しい現状である事は間違い無いと感じています。
みなさんは、どのタイミングでTDDを開始していますか?!
2013年11月9日土曜日
XPはやっぱりすごい!
今更ですが、
eXtreme Programmingは改めてすごい!!
「運転で大切なのは,車を正しい方向に進めることじゃないのよ
大切 なのは、常に注意を払って
細かく左右に方向修正していくことなの」
これ、とっても、良い表現ですよね。
最初に読んだ時、かなり衝撃的だった。
社内でXPの推進を始めて、既に10年以上となりますが、
改めて、関連書籍を読み返しても、当時の衝撃が復活してきます
XP自体は、開発手法ですが、
プロジェクト管理も同じだと思う。
日本では、「かもしれない運転」を教えられるが、
まさに、
「大切 なのは、常に注意を払って
細かく左右に方向修正していくこと」
に尽きる。
プロジェクト管理は「かもしれない運転」を促すだけ。
そして、左右確認などを、キチンと実施している事をチェックする
車は来ないだろう
分かっているだろう
などはなく
車が来るかもしれない
分かっていないかもしれない(勘違いしているかもしれない)
というアプローチを絶えず実施する必要がある
これを実施する事で、
開発チーム内、顧客 の両面で認識違いによる無駄な後戻りがなくなり、
顧客満足度に貢献出来る。
更には、
「かもしれない運転」(確認する事)でコミュニケーションが円滑になり、
開発チーム内、顧客共にメタファが生まれる
メタファが生まれると、後は、確認の手間も軽減され話が早くなる。
あとは、課題の気づきや
スモールリリースなどでお互いに信頼関係が生まれ(顧客含めて)、
信頼がリスペクトへと成長すると、
顧客含めたeXtremeなチームが誕生する
素晴らしいぃ~!!!!
eXtreme ProgrammingはやっぱりeXtremeだね!
eXtreme Programmingは改めてすごい!!
「運転で大切なのは,車を正しい方向に進めることじゃないのよ
大切 なのは、常に注意を払って
細かく左右に方向修正していくことなの」
これ、とっても、良い表現ですよね。
最初に読んだ時、かなり衝撃的だった。
社内でXPの推進を始めて、既に10年以上となりますが、
改めて、関連書籍を読み返しても、当時の衝撃が復活してきます
XP自体は、開発手法ですが、
プロジェクト管理も同じだと思う。
日本では、「かもしれない運転」を教えられるが、
まさに、
「大切 なのは、常に注意を払って
細かく左右に方向修正していくこと」
に尽きる。
プロジェクト管理は「かもしれない運転」を促すだけ。
そして、左右確認などを、キチンと実施している事をチェックする
車は来ないだろう
分かっているだろう
などはなく
車が来るかもしれない
分かっていないかもしれない(勘違いしているかもしれない)
というアプローチを絶えず実施する必要がある
これを実施する事で、
開発チーム内、顧客 の両面で認識違いによる無駄な後戻りがなくなり、
顧客満足度に貢献出来る。
更には、
「かもしれない運転」(確認する事)でコミュニケーションが円滑になり、
開発チーム内、顧客共にメタファが生まれる
メタファが生まれると、後は、確認の手間も軽減され話が早くなる。
あとは、課題の気づきや
スモールリリースなどでお互いに信頼関係が生まれ(顧客含めて)、
信頼がリスペクトへと成長すると、
顧客含めたeXtremeなチームが誕生する
素晴らしいぃ~!!!!
eXtreme ProgrammingはやっぱりeXtremeだね!
登録:
投稿 (Atom)