無料ブログはココログ

« 2015年7月 | トップページ | 2015年9月 »

[#TiDD] うまくいくチケット駆動開発 - リーンとリファクタリング - #UAS

Ultimate Agile Stories Iteration 5の出版を記念して、前号で書いた原稿を公開します。プロセスプログラミングのメタファでチケット駆動開発のテクニックを説明しました。

Ultimate Agile Stories は著者が自由にテーマを決めて寄稿しています。あまり参考にならないかも知れませんが、こんな感じの本です。

なお、アジャイル同人誌 UAS5 は 9月12日 (土) のXP祭り2015でも頒布される様です。

XP祭り2015にてUltimate Agile Stories頒布 - Yasuo's Notebook

このエントリーをはてなブックマークに追加

[#UAS] アジャイル開発とフィードバックそしてリスク - Ultimate Agile Stories Iteration 5 -

Uas5mini_2

ついに最終イテレーションになった Ultimate Agile Stories Iteration 5。今回の目玉はコプリエンさんの寄稿の日本語版、そして「アジャイル放談 in 東京」でしょう(執筆者とタイトル一覧)。

Ultimate Agile Stories Iterationはアジャイル同人誌として5年前に生まれ、頒布による利益を全額、東日本大震災の被災地支援として寄付されています。わたしもささやかながら寄稿と放談するという形で協力させていただきました。

今回で最後の特別企画として東京のアジャイラーが集まって、アジャイル放談が行われました。アジャイルについて3時間、熱く語られたようです。

放談の中で気になったのは「フィードバック」という言葉です。計算機が高価だった時はドキュメントでフィードバックを得る事が合理的でしたが、現代は実装して確認する事が合理的であるとの事。

ソフトウェア開発では、常にリスクを最小にできる様に考えるとうまくいくと思います。 特にフロント部分の開発では、UIのほか実装のリスクも解決できるので、アジャイル開発がうまくいくのでしょうね。

放談の中ではアーキテクチャの育て方がわからないとの議論がありましたが、実装すると減るリスクと、アーキテクチャに関わるリスクが異なるからではないかと思いました。

アーキテクチャだけに限れば、プロトタイピングやスパイクをきちんとやるなら上流設計をした方はリスクが減ると思います。DB設計なども実装よりも設計時に議論する方が、技術力が向上する様に思います。

アジャイル開発の実践者にフロントエンジニアの方が多いのは、そういうリスクの種類と関係しているのでしょう。

なお、アジャイル同人誌 UAS5 は 9月12日 (土) のXP祭り2015でも頒布される様です。

XP祭り2015にてUltimate Agile Stories頒布 - Yasuo's Notebook

このエントリーをはてなブックマークに追加

在庫推移監視方式にみるDOAのアプローチ #benkyoenkai

生産管理再入門-MRPを超えて <第43回IT勉強宴会> に参加しました。

メインの話題は在庫推移監視方式(Stock Projection Monitoring)で、その基本と事例の紹介でした。在庫推移監視方式はMRP(所要量計算)方式がバッチで処理するところを、手作業を前提とする事でリアルタイム処理する方式です。

在庫推移監視方式について

在庫推移監視方式は(1)新たな発注などの入出庫予定の変動があった際に、MRPは、(2)所要量の計算、(3)受払予定の再編成、(4)在庫推移の再計算、(5)推移以上の対応までバッチ行います。

しかし、実際は在庫を見たいだけなのに、(1)の入出庫予定の変動があるたびにバッチを実行しているユーザが多いそうです。そこで在庫推移監視方式は(2)と(3)だけをリアルタイムで行うことで、在庫の状況を確認できる様にしています。

在庫推移監視方式の事例

事例では、受注と発注の担当者を同じ組織にすることで、MRPがルールで行うことを人間によって調整できる様にしています。これによって、ムダに生産や在庫することが無い様に稼働を調整しているそうです。

在庫管理のポイントは、DB設計、方式設計、組織設計、工程負荷だそうですが、 在庫推移監視方式にあわせて組織設計までされたようです。

お話で興味深かったのは、在庫推移監視方式を知って実践したのではなく、実践してからそれが在庫推移監視方式であることに気付いたそうです。GoF本が出た時に「前からやっていた」という人がおられましたが、良いパターンは誰もがたどり着くものなのでしょうね。

そしてそのパターンを見いだして命名された渡辺幸三さんは、生産管理というドメインを極めたスパーエンジニアなのでしょうね。

在庫推移監視方式は方式設計?

在庫推移監視方式は方式設計ではないかということです。ドメイン分析の様に見えながら、実はリアルタイム処理かバッチかという方式まで決めています。

同じような感じは、ライブモデリングの時にもしました。データモデリングのようなのですが、理由を問われると「こんな有力画面を考えているんですよ」と答えられていました。

データモデリングと言いながら、画面設計もある程度できていたのです。DOAは常に実装と繋がっているのだと思います。

DOAのアプローチ

渡辺幸三さんは、ドメイン知識はDDDがいうような汎用的な方法では獲得が難しく、ドメイン専門家にならないといけない、といった主旨のお話をされていました。今回の在庫推移監視方式は専門的な経験があるからこそ、できる事なのでしょう。

DOAのアプローチはどちらかというと業務分析に始まるトップダウンアプローチです。でも、実装がどうなるかを意識していないと動くシステムは作れません。

たぶん、DOAはその溝を業務固有のデザインパターンでつないでいるのだと思います。今回は在庫推移監視方式というパターンでしたが、それ以外にも多くのパターンがあり、その獲得がドメイン専門家になるという事であると思いました。

このエントリーをはてなブックマークに追加


[#TiDD] ウォータフォール型開発の問題点とチケット駆動開発 #seakansai

SEA関西プロセス分科会「 価値ある製品を生み出すためのアジャイル実践ポイント」に参加しました。講師は 日新システムズに移られた前川さんと陸野さん。実践のお話から、チケット駆動開発に関してもより深く考えることができました。

講演は前川さんが共著されたわかりやすいアジャイル開発の教科書を踏まえて、前川さんと陸野さんの経験を語られました。

教科書的な内容を経験談をあわせるといくつか気になるところがありました。それは教科書的にアジャイル開発の対比として扱われるウォータフォール開発(WF)が現実よりもシンプルなことです。お2人の経験を踏まえると、WFの問題点は以下の様になると思います。

a. WFは変更を受け入れすぎる

アジャイル開発は変化を受け入れるがウォータフォールは受け入れない。そんなことはありません。アジャイル同人誌 UAS5のアジャイル放談でお話しした通りです。WFでは変更管理はするもののそのプロセスが重く、任意のタイミングで発生するので混乱しやすいと言う問題があると思います。前川さんの経験でもアジャイル開発導入前は変更要求で混乱していたそうです。

b. WFでもリリースは1回とは限らない

前川さんの事例ではアジャイル開発導入前も納品と最初のリリースが一致しません。リリースが1回ではすまないことが多かったとのこと。また、開発中にも色々な人が途中で見せるように内部リリースを求めてくるので、混乱に拍車をかけたそうです。

c. WFのチーム作りの理想はアジャイル開発と同じ

陸野さんのチームビルディングの説明では、CMMを提唱されたハンフリーさんのTSPガイドブック:リーダー編から引用して説明されました。この本の内容は私が100人のプロが選んだソフトウェア開発の名著 君のために選んだ1冊に「リーダーに求められる大切な事」(原稿が読めます)として、サーバントリーダーシップに求められることを引用した本です。

これらを踏まえて他の問題を考慮したWFの問題点と解決策を考えてみました。

1) 変化を受け入れる標準的なタイミングがない

スクラムで言うスプリントはいわばクリティカルセクションで、変更要求から開発チームの「集中」を守ります。
以前に壁の溝で例えた様に変更の受け皿を作る必要があると思います。また、変更要求を前倒し(フロントローディング)できる様に、適切なリリースを作らないといけません。前川さんのアジャイル開発の事例では、複数回リリースすることで変更要求を早期にだせるので、変更からチームを守られているようでした。

2) ロールが多く、構造が悪い

WFでは、マネージャ、リーダ、SQA、品質保証、SEPGのほか、営業や関連部署などが介在することが多く、各ロールの専門性が高いのでそれぞれに教育が必要です。また、それぞれが協調しないとうまくいきません。

スクラムのように組織パターン (Object Oriented SELECTION)の門番や防火壁などを用意して、開発チームへの介入をシンプルにする必要があるでしょう。

3) コミュニケーションが複雑

管理中心にプロセスが構成されていて、チーム内で協力できる様なコミュニケーションが支援されていません。 チームはコマンドコントロールでなく、サーバントリーダーシップによって自律的に行動できるような支援が必要です。

前川さんと陸野さんの発表ではタスクボードを理解した上で、チケット駆動開発を導入されていました。チケット駆動開発では管理のプロセスだけでなく、それ以外の現場プロセスが詳細に見える化されますので、サーバントリーダーシップで活発になったチーム内のコミュニケーションを支援することができます。

4) マネージメントが難しい

WFでうまく開発するにはマネージャやリーダの協力が必要なほか、適切なマイルストーンやリリースの設定される必要があります。また、多くのステークフォルダーと調整しつつ、組織レベルでは規律で管理し、現場レベルではサーバントリーダーシップを発揮しなければいけません。上下関係もあるので、かなり難しい仕事です。

スクラムでは組織パターンで問題を単純化してプロダクトオーナが門番、スクラムマスタが防火壁になります。この点はチケット駆動開発でも意識してワークフローを考えないといけません(必ずしもITSのワークフローで制限しなくて構いません)。

5) スピードが遅い

WFのリスクを考慮したスパイラルモデルでは、部分的なプロトタイピングを取り入れましたが、1回のループ半年から2年と長いものでした。これは変更のリスクだけを考慮してプロセスを再構築したからだと思います。

アジャイル開発ではソフトウェア開発のリスクを見直して、プロセスの優先順位を決めて(アジャイルソフトウェア開発宣言)最適化したので開発スピードを上げることができたのだと思います。

ということで、組織パターンの実現、教育、プロセスの最適化の考慮は必要ですがが、アダプタブルWFで(ウォーターフォール型開発をアダプタブルにする3+1)もかなりいけるのではないかと思いました。アダプタブルWFの詳しい解説は アジャイル同人誌 UAS5にも書きましたし、SQiP2015の併設チュートリアルでもお話しします。

なお、アジャイル同人誌 UAS5 はXP祭り2015でも頒布される様です。
XP祭り2015にてUltimate Agile Stories頒布 - Yasuo's Notebook

このエントリーをはてなブックマークに追加


[#TiDD] チケット駆動開発の3要素

前回の続きです。発表準備を進める中で、チケット駆動開発プロセスモデリングとの関係を示すだけでは不十分で、そもそもチケット駆動開発とは何か、そこではどのような考慮が必要かを考えないといけないと気付きました。

以下の図に示す様に、チケット駆動開発にはモデリング、見える化、チーム作りの3要素があり、それぞれの設計が必要です。

3_2

プロセスモデリングに関しては、 前回の説明の通りです。ゴールの段階的詳細化、チケットの粒度、規律を考慮したモデリングが必要です。

データの見える化は利用シーンを考えないといけませんし、そもそもどのようなチームを作るのかを考えて、そのコーディネートが重要です。

チケット駆動開発はフローか、ストックか、という議論がある様ですが、「両者と共にチームづくりが必要である。」というのが、私の意見です。以下の講演でも、その路線で説明する予定です。是非ご参加ください。

2015年8月29日(土) @大阪(ヒルトンプラザウエスト)
RxTStudy(Redmineとタスクマネジメントに関する勉強会@大阪) #13
「Redmine再入門 〜達人に学ぶRedmineの徹底指南〜」
https://rxtstudy.doorkeeper.jp/events/28631


2015年9月16日(水) @東京(東洋大学 白山キャンパス)
ソフトウェア品質シンポジウム 2015 併設チュートリアル
チケット駆動開発入門 ~基礎から応用まで~
http://www.juse.jp/sqip/symposium/timetable/tutorial/

スライド抜粋:ウォーターフォール開発におけるチケット駆動開発 -ウォータフォール開発をアダプタブルにする-

このエントリーをはてなブックマークに追加


[#TiDD]失敗しないチケット駆動開発 - プロセスモデリングの視点から+告知 -

チケット駆動開発はうまくいく人と失敗する人がおられる様です。これまでは必勝法しかお話ししていませんでしたが、失敗しない方法を説明します。

必勝法

開発プロセスを変更してチケット駆動開発を導入するのですから、それによってプロセスが改善できないといけません。問題点を明確にして、その解決法としてチケット駆動開発を導入します。

とはいえ、チケットシステムとして用いるITSがどのようなものかわかっていないと、難しい運用をしてしまいかねません。まずは障害管理にITSを導入するなどして、どのような機能があって、どのくらい面倒かを見極めてください。

障害管理で使うと、現状の問題も見えてくるでしょう。情報の共有、連絡の遅延、ゴールに対する齟齬などの問題や、計画道理に進まないなど。これらの問題点を明確にしてリズミカルに開発することで作業漏れが減り、協力してゴールに向かうチームズくりなど、チケット駆動開発の基本的な良さがわかるでしょう。

その上で、タスクに関する問題を見極めてタスクを管理してください。多くの場合は障害管理と同じ様に情報共有の問題ですので、制約の少ないワークフローでも効果が得られるでしょう。

机上では失敗する

チケット駆動開発の失敗パターンで多いのは、興味を持って始めたものの面倒臭くなってやめるパターンです。

たとえば、チケット駆動開発のプラクティスには“No Ticket, No Commit !”というものがありますが、これをチケットとコミットを1対1にするルールだと間違えている人が多い様です。

障害管理でITSを使った経験があるなら、チケットは障害票である事に気付くでしょう。そして、複数のコミットの履歴がチケットに残る事で、

  • 一つの障害の解決には色々な修正が必要だったこと
  • 最初のコミットに漏れたファイルも必要だったこと
  • 結合テストの準備でデグレがみつかって同時に修正しないといけないファイルが見つかったこと

などがわかります。ここまでのコミット履歴が一つのチケットに残っていることで、類似の障害を修正する際の参考になります。個別にチケットを発行してはいけない事がわかるでしょう。

コミット毎にチケットを発行するのが面倒臭いのはあたり前です。このように役に立たないのですから。

ITSはプロセス支援ツール

実はチケット駆動開発をした場合、ITSはプロセス支援ツールになってます。プロセス支援ツールは定義されたプロセスモデルに従って支援をしますので、プロセスモデリングをしないと効果を得る事ができません。

問題が明確であれば、その点を中心にモデル化してあとは自由度を高くすれば良いでしょう。しかし「どうもうまくいっていないので少しでも良くしたい」といった場合には、どのような支援が可能かを知っておく必要があります。

ここで参考になるのはプロセスモデリングのゴールでしょう。

  • 人間が理解する事
  • プロセス改善
  • プロセス管理
  • 自動実行
  • 自動ガイド

* Bill Curtis, Marc I. Keller and Jim Over, Process Modeling, Communications of the ACM (Impact Factor: 2.86). 09/1992; 35(9):75-90

プロセスモデリングはプロセスの見える化です。見える化する事で、プロセスを伝え、改善し、管理し、自動化し、ガイドする事が可能になります。

ただ、気をつけないといけないのは、問題になっているところだけでなく、問題でないところもモデリングが必要なことです。

問題となっているところは、問題を解決できる様に厳密に、あるいは、より自由度を高くすれば良いでしょう。問題でないところは、AS-IS、つまり現状が基本です。

プロセスモデリングをする際は、ついついこってしまいがちで、色々とコントロールしようとしてしまいます。しかし、プロセスには慣性力のようなものがあり、人間が新しい事に慣れるには時間がかかりますので、現状からあまり替えない方が良いと思います。

続きは勉強会、チュートリアルでもお話しします

では、プロセスモデリングのゴールはどのように実現すればよいか。それがわかれば、うまくプロセスをモデリングできることがわかるでしょう。このブログでも紹介していくつもりですが、近々まとめてお話しする機会がありますので、是非ご参加ください(チケット駆動開発の3要素につづく)。

2015年8月29日(土) @大阪(ヒルトンプラザウエスト)
RxTStudy(Redmineとタスクマネジメントに関する勉強会@大阪) #13
「Redmine再入門 〜達人に学ぶRedmineの徹底指南〜」
https://rxtstudy.doorkeeper.jp/events/28631


2015年9月16日(水) @東京(東洋大学 白山キャンパス)
ソフトウェア品質シンポジウム 2015 併設チュートリアル
チケット駆動開発入門 ~基礎から応用まで~
http://www.juse.jp/sqip/symposium/timetable/tutorial/

スライド抜粋:ウォーターフォール開発におけるチケット駆動開発 -ウォータフォール開発をアダプタブルにする-

このエントリーをはてなブックマークに追加


標準プロセスに隠れたお化けと定量的な品質評価 - 優先席でのスマホ -

先日、優先席でスマートホンを触っているとスマートホンの電源を切る様に注意する男性がいました。「あぁ、知らないんだな」と思い、阪急電車では混雑時以外は切らなくて良い旨を説明しました(おまけ参照)。

怪訝そうな雰囲気なので、ペースメーカーをされているのかと思い「気になりますか?」と聞くと「阪急は知らんが優先席では切るものだ」とか言われます。ガサガサされるのが嫌なんだな、と思ってスマホを片付けました。

すると、その男性は調子に乗って、周りの人にも注意を初めました。その人たちに悪い事をしたと思いました。注意された人が少し引いているので、よく顔を見ると少し怖そうなおじさんでした。

男性は良い事をしているつもりなのでしょうけど、意味の無い事を押し付けるのは困り者です。でも、ルールというのは守るべきものですので、理由を考えないと形骸化してしまう危険性があるのだと思いました。

標準プロセスに隠れたお化け

ソフトウェア開発に目を向けると、標準プロセスにも同じような形骸化のお化けが隠れています。

標準プロセスは組織的に活動を統一し、組織全体で安定した開発と改善を進める土台となるものです。共通のプロセスが実現できれば、新しい技術の導入する際はテストプロジェクトの成果を容易に展開できます。

このような考え方はCMMで広く知られる様になりましたが、「レベル3で固まる」という事象が多く見受けられました。このレベル3は「定義されたプロセス」というもので、組織内で共通のプロセスが実践される様になり改善の土台ができたレベルです。

1990年代後半のCMMブームの頃に推進していた方達は、その危険性を踏まえて形骸化しない様に努力されていました。しかし、標準プロセスはルールなので、どうしても形骸化しやすいようでした。

形骸化のお化けが現れると、不十分ながらも工夫していた開発者はルールに従う事を強制されて考える事をやめてしまいます。逆に管理する側はルールに従わせるだけで力つき、本来の目的である改善を忘れてしまいます。

開発者も管理者もソフトウェアという技術を扱う「技術者」なのになぜそれが必要かを考えるのを忘れてしまい、いつの間にか「労働者」になってしまうのです。

技術者として「なぜか」を考える組織づくりが大切だと思います。

定量的な品質評価に関して

最近、定量的な品質評価に関して色々な議論がされていますが、個人的には愚痴るのは論外だと思っています。

多くの会社には標準プロセス(とお化け)が存在するのですから、契約前に確認するのがあたり前です。詳細は確認できないにしろ、開発者にどのような成果物やメトリクスが求められているかを確認すべきです。

ある程度の変更(テーラリング)が許されるなら調整してから契約すれば良いですし、合わないなら契約しなければ良いだけです。わかっていて契約をしたなら、受けた側の問題でしょう。

プロセスメトリクスも納品物の一つです。確認しないで見積もりなんてできません。

おまけ:優先席でのスマホ

優先席でスマートホンや携帯の電源を切る様に言われ出したのは、心臓ペースメーカーを誤動作させる危険性が報道されてからです。

阪急電車でも優先席での利用が禁止されましたが、あまり徹底されませんでした。そこで阪急では、電車の端の1両を携帯電話オフ車両として、車掌が注意するなど徹底を図りました。

その後、ペースメーカーへの影響が再調査されて影響を受けるのはごく一部かつ密着したときのみである事がわかり、携帯電話オフ車両を廃止し、混雑時のみ優先席で禁止する様に変わりました。

関西では相互乗り入れがあることから、混乱を避ける様に他社も同じルールで統一されているようです。

このエントリーをはてなブックマークに追加

« 2015年7月 | トップページ | 2015年9月 »