や、当たり前のことではあります。しかしながら、プロセス定義書やPFDを作っていると案外はまってしまう点なのかもしれないと感じました。プロセス定義書やPFDを作る時は「プロセス」を中心に記載するため、頭の中も「どうプロセスを組み立てよう」という状態になってしまいがちです。作るモノも一緒に考えながらプロセスを組み立てるのであれば尚更です。プロセスを定義する時は、プロセスが完了した結果、産み出されるモノ・成果物を強く意識した方が良いと考えます。

作るモノのフローを考えるのだから、PFDは「Process Flow Diagram」というより、ひょっとしたら「Product Flow Diagram」または「Production Flow Diagram」でもいいのかな、と思ったりしました。

これは計画や見積もりにも同じことが言えると思うのです。また、機会があればこれも考えてみたいと思います。

2014-07-02

達成できなかったTRY

Project Management 日記

プロジェクトでKPTによる振り返りを実施した時に、TRYの一部が達成できていない時はどうするか（続けるべきか）という課題に最近触れた。

アジャイルサムライのふりかえりに関する下記のような記述にもある通り、ふりかえりはできなかったことをつるし上げても価値は生まれにくい。

ふりかえりは魔女狩りじゃない

むしろ振り返ろうとする心を削いでしまうことが多い。
従って結論としては以下のような方針でやるのが良いのでは、という結論に至った。

できなかったものも含めてKPTして、TRYをもう1度出す
続けるかどうかはTRY次第
同じ目的でも別の方法でTRY

また、次のイテレーションではTRYのまず達成するアクションを決めてもらった。何も成果がない、という状態を防ぐためだ。アクション出せないなら、話し合おう、というのも伝えた。これもある意味でTRYだったかもしれない。
同じような課題にぶち当たった方々はどうしているのか聞いてみたい。

2014-06-26

組込みの現場とアジャイルの狭間で

アジャイル開発 Project Management

現在の僕の最大の課題は、どのように組込みシステムを、どのように組込みソフトウェア（F/W）を作り上げるか、という領域だと考えています。全ての組込みシステム開発が同様に作られているはずはないので、正確には現在関わっている組込みシステムをどのように作るか、かもしれません。

現在関わっているシステム開発方法も、水が下方に流れ落ちるように、様々な試行錯誤の結果としてあるわけで、過去から見ればきっと最善な方法であると信じています。しかし、まだまだ問題山積みであることと、なぜか悪化する方向に流れているような気がしてならない事があります。

アジャイル開発の一切の無駄を排除するような考え方やプラクティスを試行して、少しでも頑張らずに、楽しく開発できることを目指して活動しています。

Thought about system by Hiroyasu Ishikawa

We are uncovering better ways of developing system.

LVMとpartedと

XAMLとAndroid XMLと

タブ（インデント）を半角スペースに変換

Ruby 2.1.2 install on Ubuntu Linux

インストールの環境作り

rbenvのインストール

rubyのインストール

プロセスと成果物

達成できなかったTRY

組込みの現場とアジャイルの狭間で