現在、ソフトウェアリリースのワイヤーフレームとストーリーボードをどのように管理していますか？
私はアジャイル環境でのワイヤフレーミングは非常に新しいです（2週間のスプリント）。私のワイヤーフレームとストーリーボードには、即時リリースと将来のリリースの計画のための機能が含まれています。
私はVisioを使用しており、現在、さまざまな機能（サイトの一部）用に別々のvisioファイルを持っています。また、各visioファイルには、異なるリリースのワイヤーフレームが含まれています。しかし、それはワイヤーフレームをリリースすることが前もって明白ではないことを意味します。これまでのところ、ページを簡単に更新できるので、これでうまくいきます。ただし、初期のリリースで変更があった場合、将来のリリースでもページに複製を変更する必要がある場合があるため、少し面倒な場合があります。
私のアプローチが最善であるとは思いません。そのような環境での経験はたくさんあると思います。現在、ワイヤーフレームとストーリーボードをどのように管理して対処していますか？
「ダウンザロード」ワイヤーフレームは、忠実度スペクトル上では少し遠すぎるようです。言い換えると、地面がフィードの下で変化するときに多くの「痛み」を感じると、それらは詳細すぎます（私の場合だけでなく、私の場合もそうです）。
長期のワイヤーフレームにペン/マーカー/紙（ローファイ）を使用して、成果物が固まり始めたらVisio（ハイファイ）を節約してみましたか？
その方法は、設計プロセスでさらに進んでいて具体化されていることを開発者にさらに明確に伝えます。
スケッチが伝える→「状況は変わる可能性がありますが、これは私たちが探求したいアイデアです。」
さらに、フィデリティスペクトルに沿って、ワイヤーフレームや本格的なピクセルコンプなどに移動します…
ワイヤーフレーム通信→「これを改良し、設計に関する特定の質問を解決しています。」
Bill Buxtonがsketchからprototype（およびその間のアーティファクト）までのこの連続体についてSketching User Experiences（pp 135-141）。
私は通常、PowerPointでストーリーボードを作成し、中央のファイル共有に配置します。 （以前はSharepointでしたが、私が気に入っていました）。これは、開発者の出発点です。
私は通常、実際の製品について彼らと一緒に作業し、物事は元のPowerPointのデザインからシフトおよび変更されます。結局のところ、PowerPointは本物へのリンクが弱いだけです。それは時代遅れで役に立たなくなります。
デモの日が週に1回あり、そこではより大きなグループに作業を披露します。これが物事が固まり、「本来あるべき姿」になる場所です。それらの会議でパンチリストを作成します。 QAも参加するため、「設計された動作」とは何かを知っています。
その後、リリースに近づき（毎月）、トレーニング、サポート、製品マーケティングなどと連携して、既存の動作を文書化します。
メソッドはたくさんあります。これは私が使用するものです。これがお役に立てば幸いです。