2014年度、AVASYSとしては35期のスタートです。
4/4 の全社キックオフでは、
中竹竜二さんの講演があったのですが、
その中に、今期のRibbonModel推進テーマがずばり!
というのも、
2014年度は「分割」をテーマにする予定でした。
(キックオフ会場の成果展示には、いちおう掲載していましたが....)
すると講演の中で、
曖昧な問題の解決策として、
「似て非なるものは分けて考える」
と
「分ける」と「分かる」
というキーワードとお話を聞いて、
胸に突き刺さりました。
これだ! と言う感じです。
そして、これに、共有の要素を追加すると、
まさに、リボンモデルです!
「分ける」と「分かる」と「分かち合う」
いったいどーいう事???
と感じるかもしれませんね。
簡単に説明すると、
リボンモデルの特徴である
「単体テストとリファクタリング」
は、「分ける」事から始まります。
というより、分けないと不可能、もしくは困難になります。
そして、当然ながら「分かる」から
「単体テストとリファクタリング」
が可能となります。
「単体テストとリファクタリング」が可能となると
属人性や担当依存が低くなり、共有に繋がっていきます。
これが「分かち合う」ですね。
もう一つの特徴である
「小さな改善を繰り返す」
も同じです。
改善するには、問題や課題を「分ける」事が重要となります。
「分ける」事で、解決すべき問題がシンプルとなり、
「分かる」となります。
すると、チーム、顧客含めた情報共有がし易くなり、
「分かち合う」が可能となります。
そして、いずれも「分ける」事による
単純化(シンプルにする事)は、
開発スピードを劇的に向上させる事に繋がります。
但し、単純化の為には、
「似て非なるもの」を「分ける」事が大前提となりますが。
大前提となる ソフトウェア開発での
「似て非なるもの」を「分ける」については、また改めて!
2014年4月10日木曜日
2013年11月9日土曜日
XPはやっぱりすごい!
今更ですが、
eXtreme Programmingは改めてすごい!!
「運転で大切なのは,車を正しい方向に進めることじゃないのよ
大切 なのは、常に注意を払って
細かく左右に方向修正していくことなの」
これ、とっても、良い表現ですよね。
最初に読んだ時、かなり衝撃的だった。
社内でXPの推進を始めて、既に10年以上となりますが、
改めて、関連書籍を読み返しても、当時の衝撃が復活してきます
XP自体は、開発手法ですが、
プロジェクト管理も同じだと思う。
日本では、「かもしれない運転」を教えられるが、
まさに、
「大切 なのは、常に注意を払って
細かく左右に方向修正していくこと」
に尽きる。
プロジェクト管理は「かもしれない運転」を促すだけ。
そして、左右確認などを、キチンと実施している事をチェックする
車は来ないだろう
分かっているだろう
などはなく
車が来るかもしれない
分かっていないかもしれない(勘違いしているかもしれない)
というアプローチを絶えず実施する必要がある
これを実施する事で、
開発チーム内、顧客 の両面で認識違いによる無駄な後戻りがなくなり、
顧客満足度に貢献出来る。
更には、
「かもしれない運転」(確認する事)でコミュニケーションが円滑になり、
開発チーム内、顧客共にメタファが生まれる
メタファが生まれると、後は、確認の手間も軽減され話が早くなる。
あとは、課題の気づきや
スモールリリースなどでお互いに信頼関係が生まれ(顧客含めて)、
信頼がリスペクトへと成長すると、
顧客含めたeXtremeなチームが誕生する
素晴らしいぃ~!!!!
eXtreme ProgrammingはやっぱりeXtremeだね!
eXtreme Programmingは改めてすごい!!
「運転で大切なのは,車を正しい方向に進めることじゃないのよ
大切 なのは、常に注意を払って
細かく左右に方向修正していくことなの」
これ、とっても、良い表現ですよね。
最初に読んだ時、かなり衝撃的だった。
社内でXPの推進を始めて、既に10年以上となりますが、
改めて、関連書籍を読み返しても、当時の衝撃が復活してきます
XP自体は、開発手法ですが、
プロジェクト管理も同じだと思う。
日本では、「かもしれない運転」を教えられるが、
まさに、
「大切 なのは、常に注意を払って
細かく左右に方向修正していくこと」
に尽きる。
プロジェクト管理は「かもしれない運転」を促すだけ。
そして、左右確認などを、キチンと実施している事をチェックする
車は来ないだろう
分かっているだろう
などはなく
車が来るかもしれない
分かっていないかもしれない(勘違いしているかもしれない)
というアプローチを絶えず実施する必要がある
これを実施する事で、
開発チーム内、顧客 の両面で認識違いによる無駄な後戻りがなくなり、
顧客満足度に貢献出来る。
更には、
「かもしれない運転」(確認する事)でコミュニケーションが円滑になり、
開発チーム内、顧客共にメタファが生まれる
メタファが生まれると、後は、確認の手間も軽減され話が早くなる。
あとは、課題の気づきや
スモールリリースなどでお互いに信頼関係が生まれ(顧客含めて)、
信頼がリスペクトへと成長すると、
顧客含めたeXtremeなチームが誕生する
素晴らしいぃ~!!!!
eXtreme ProgrammingはやっぱりeXtremeだね!
組込みとTDD
振り返ってみると、私も長い間? 独自ではありますが、
単体テスト(xUnit)に取り組んでいます。
そのほとんどが組込みですが、なかなか浸透していないですよね。
ですが、最近は、組込み業界にも
テスト駆動や単体テスト処理実装の流れが押し寄せているように感じます。
この流れから、リーンやアジャイルの単なるやり方ではなく、
コンセプトがフォーカスされる事を強く望んでいます。
というより、微力でも、私にも何か出来る事が無いかと模索しています。
単体テスト処理実装&全単体テストの自動実行
とイテレーション型開発、
更にはMVP(Minimum Viable Product)は切っても切り離せないですからね。
私は、単体テスト処理の実装とリファクタリングを繰り返す
リボンモデルを社内で浸透させるべく活動していますが、
組込みは派生開発も多く、
途中から単体テスト処理を実装する事の
大変さというか、
空しさというか、
やり切れない切なさを実感しています。
そこに更に、リファクタリングなんて無理!
という現場の心の悲鳴を強く感じています。
しかしながら、一方で、
単体テスト処理の実装とリファクタリングを繰り返す事で、
高品質を維持する事が実現出来ている例もある という事で、
何をやるか というより、リボンモデルの基本の考え方
(単体テストとリファクタリングの繰り返し)
が、社内で広く浸透する為に、なにをすべきか
と、試行錯誤しています。
単体テスト(xUnit)に取り組んでいます。
そのほとんどが組込みですが、なかなか浸透していないですよね。
ですが、最近は、組込み業界にも
テスト駆動や単体テスト処理実装の流れが押し寄せているように感じます。
この流れから、リーンやアジャイルの単なるやり方ではなく、
コンセプトがフォーカスされる事を強く望んでいます。
というより、微力でも、私にも何か出来る事が無いかと模索しています。
単体テスト処理実装&全単体テストの自動実行
とイテレーション型開発、
更にはMVP(Minimum Viable Product)は切っても切り離せないですからね。
私は、単体テスト処理の実装とリファクタリングを繰り返す
リボンモデルを社内で浸透させるべく活動していますが、
組込みは派生開発も多く、
途中から単体テスト処理を実装する事の
大変さというか、
空しさというか、
やり切れない切なさを実感しています。
そこに更に、リファクタリングなんて無理!
という現場の心の悲鳴を強く感じています。
しかしながら、一方で、
単体テスト処理の実装とリファクタリングを繰り返す事で、
高品質を維持する事が実現出来ている例もある という事で、
何をやるか というより、リボンモデルの基本の考え方
(単体テストとリファクタリングの繰り返し)
が、社内で広く浸透する為に、なにをすべきか
と、試行錯誤しています。
登録:
投稿 (Atom)