nDiki : レビュー

今日のさえずり: Slack のスレッド機能、スレ立ての最初のメッセージにセンスが求められる

2017年01月19日

• 09:50 Slack の iOS アプリでスレッドにしてみた。 iOS アプリ上だとスレッド表示になったけれど Mac アプリケーション版(2.3.4) で見ると普通の投稿として表示された。
• 09:52 Web で見たらきちんとスレッド表示になってた。
• 10:31 Slack for Mac 2.4.1 にした。
• 12:00 Slack のスレッド機能、スレ立ての最初のメッセージにセンスが求められる。
• 13:29 「嫌われる勇気」買った。 (@ 青山ブックセンター 本店 in 渋谷区, 東京都) https://www.swarmapp.com/c/ai0nJbpQmsF
• 23:01 企画的なレビューを求められているのか技術的なレビューを求められているのか意識できるようにしたい。

何もコミットしないスプリントで各自好きなことをして得られたもの

「プロダクトバックログアイテムについては何もコミットしない」で各自好きなことをして良い1週間スプリントが終わったのでチームでふりかえりました。

何をやらなかったか?

• スプリントプランニング。スプリントバックログは空。

何をやったか?

• チームとして
  • デイリースクラム(朝会)はいつも通りやった。
  • プロダクトバックログリファインメントもいつも通りやった。
  • スクラム外でやったことをレビューした。
• 開発メンバがやったこと
  • プロダクトバックログアイテムを準備完了にするための情報収集・まとめをやった。リリースできるものはリリースまでした。
  • BTS にある不具合報告についてどんどん調査をした。
  • まとまった時間でシェルの設定を見直して開発しやすくした。QOL が上がった。

このチームが自主的に決めたワーキングアグリーメント(記事)に

スプリントゴールが全て達成された場合は、優先する割り込みタスクがあれば対応し、そうでなければ準備完了になっていないプロダクトバックログアイテム(PBI)に関する情報収集・まとめを優先度の高いものからしよう。」

というのがあり、この活動をしていたメンバが多かったです。「スプリントバックログが空 = ただちにスプリントゴールが達成されたので PBI の準備に取り組んだ」わけですね。

環境整備にあてたりとかはあまり多くなかったようです。シェルの設定見直しをしたエンジニアは「失敗したら1日潰れてしまいそうで普段やれなかったことをできた」とやって良かったと言っておりました。

どう感じたか?

開発メンバからは以下のような意見が出ました。

• 「スクラムを始める前のチケット駆動開発時代に戻った感じ。」
• 「スクラムで開発をしない場合(タイムボックスが無い場合)、個人でしっかり時間・タスク管理する能力が求められると感じた。」
• 「半年に1度くらい頻度でまたやりたい。」
• 「スクラムでやりたい。」

得られた気付きは?

• タイムボックスの良さにあらためて気付いた(期日から逆算していつまでに何をやるということを考えやすい)。
• 複数人で作業を見積もることで自信が得られることに気が付いた。

自由になったことで、普段やっているアクティビティの良さを再認識できたようです。チームが取り組んでいるプロダクトの状況から考えるとスクラムではなくカンバンの方が進めやすいのかもしれないのではと私は考えていたのですが、今回の取り組みで開発メンバは「スクラムで続けたい」と改めて思ったとのことです。

スクラムの基本からは外れる取り組みではありましたが、基本通りにやっていたのでは感じ考えることのことができないことを得られたという意味では非常に有意義な1週間でした。

Remember The Milk でタスクと親タスクを別々にレビューできるようにスマートリストを追加

Remember The Milk Pro はサブタスクを作れて便利。ただ何かストレスだなと思っていたのですがその理由に今頃気が付きました。

1つのリストに入れた「通常のタスク」と「サブタスクを持つタスク(GTD で言うところのプロジェクト)」をそのままレビューしているからですね。やはり高度が違ったものが混ざったままレビューするのは負担がかかります。

かといって高度別にリストを分けると操作が面倒。もともとプロジェクトには prj タグをつけていたので、レビュー用にこれを抽出するスマートリストを追加しました。

Remember The Milk は3階層までタスク階層を作れます。プロジェクトを1つにまとめておきたいことはあるので、そのようなプロジェクトには bigprj というタグをつけて、これまた別途レビューできるようにしました。

さらにその上の「重点的に取り組む分野 (Areas of Focus)」レベルまで Remember The Milk で扱うようにすると破綻するのでこれで十分かなと思ってます。

今日のさえずり: チームのかんばんの優先順位会議というかレビューをした

2018年02月06日

• 15:15 渋谷ヒカリエへ。ヒカリの道。 https://t.co/eXPDirIPVc
• 16:45 そろそろかなと今朝から花粉症対策としてアレグラを服用し始めた。「飲み忘れと飲んだか忘れ」対策に習慣化アプリ HabitHub でリマインダと投薬記録できるように今年も設定した。 HabitHub 便利。
• 17:15 Naney の日記: 一橋大学・津田塾大学写真部 @hitphoto 対外展2018 に行ってきました。フィルム一眼レフカメラで撮ったものからコンパクトデジタルカメラで撮ったものまで、いろいろな作品が混ざっていて飽きない写真展でし… https://twitter.com/...
• 20:15 渋谷、雪降ってる!
• 20:24 @hyuki ですです。粉のような雪が少しパラパラと。寒いですねー。
• 23:30 今日はチームのかんばんの優先順位会議というかレビューをした。感覚的にはプロダクトバックログリファインメント(見積もりはしない)のような GTD の週次レビューのような。なんとなく TODO だったものが明確になっていってスッキリ。

今日のさえずり: 「ダウンタウン熱血行進曲 それゆけ大運動会」で五代(ごだい)が名前・体力表示枠まで落ちちゃって動けなくなってしまった

2018年02月18日

• 10:24 RT @KeithYokoma: 高校生のころ、ジャヴァの試験受けたら合格だったのでやったーと思ってたら担任が俺よりテンション上がってて新聞記者さんよんできて取材され、新聞の地方欄に載り、それがインターネットにアーカイブされて2chに至ったのをよく覚えている。
• 10:27 RT @hidey: 実は貴重なものでは!? というものが発掘された https://t.co/w14V3HSLR0
• 10:30 RT @hidey: まぁ、模写ならどんなものが好きだったかわかる程度で致命傷ですむだろう(深夜の判断力) https://t.co/n4giml4xqs
• 11:47 RT @sn_f: ロリポップでどんなサイトを作っていたかより、ロリポップで借りたドメインがhttp://kill.jpだったことがいちばんの黒歴史って感じ
• 13:00 構成が変わっていてもはや写ルンですとは別物に。 Utulens より広角なのいいなあ。 / “Wtulens レビュー：写ルンですのレンズを二枚使ったWtulensは写りも激しい変態レンズでした！” http://bit.ly/2EBDrek
• 13:03 Utulens は APS-C サイズの α6300 だと 35mm 判換算 48mm の画角で写ルンですとはちょっと勝手が違ってくるんですよね。 http://bit.ly/2ht8a6M
• 15:30 帰りなさい! 帰りなさい! https://twitter.com/...
• 23:16 「ダウンタウン熱血行進曲 それゆけ大運動会」で五代(ごだい)が名前・体力表示枠まで落ちちゃって動けなくなってしまったんだけれど、どうすればいいのコレ……。 https://t.co/XyxtgcBQD5

GitHub Flavored Markdown ファイルの Web ブラウザでのプレビューに Grip を使う

「Markdown で書いているノートを Web ブラウザで見るのに MkDocs を使う」とつぶやいたら @bsdhack 氏が Grip を紹介してくれました。

私はgithubなどのmdファイル(https://t.co/nyoqRnjsN7)を読むために python製の grip 使って↓なスクリプトを書いて使ってます。

grip --export ${1:-README.md} - | w3m -T text/html

— Mitzyuki IMAIZUMI (@bsdhack) 2018年2月28日

さっそく試してみました。

 $pip2 install grip

でインストールしたら Markdown ファイルを指定して Grip を起動します。

 grip index.md

Grip が http://localhost:6419/ で Web サーバとして立ち上がるので Web ブラウザでアクセスすると index.md の HTML 変換されたものを見ることができます。なお

 grip -b index.md

とすれば起動と同時に Web ブラウザで開いてくれます。URL でパスを指定すればそのまま同じ/サブディレクトリにある Markdown ファイルもプレビューできるので、ハイパーリンク付けをしておくことでドキュメント群をブラウジングすることもできます。なるほどお手軽で便利。 GitHub 上とほぼ同様の見慣れたデザインになるのがいいですね。

そもそも Grip は「GitHub Readme Instant Preview」で GitHub 上での表示確認のためのツールで、 GitHub の REST API を使ってレンダリング結果を生成しているので当然といえば当然だったりはします。

ただそのかわり GitHub の API を使うので

• オフラインでは使えない(オフラインレンダリングは開発中)
• 外部サービスを使って変換させたくないドキュメントには使えない

と場合によっては不便な部分があります。なお後者については GitHub Enterprise があるなら Grip でそちらを指定するとう手もあります。

GitHub に push する前にチェックしたい時はもちろん、それ以外でさっと Web ブラウザで見てみたい時にも便利なツールですね。

• https://github.com/joeyespo/grip

今日のさえずり: イトーヨーカドー 大井町店のポッポとうとう今日まで。名残惜しい。

2018年02月28日

• 08:03 Google Chrome 68 の HTTP サイトでの表示は「保護されていません」になるのかな。ニュースサイトが書いていた「非安全」ほどはキツくない表現。 / “保護されたウェブの普及を目指して” http://bit.ly/2FBonP5
• 08:05 RT @mhatta: ジェットストリームのパーカータイプ替芯が出た http://www.mhatta.org/.../ https://t.co/IRBkuaDXVH
• 13:00 イトーヨーカドー 大井町店のポッポとうとう今日まで。名残惜しい。
• 15:15 Mac 上にある Markdown で書いたノートファイルを Web ブラウザで見るのに MkDocs を使ってみた。ビルトイン Web サーバ付き。 http://bit.ly/2F0lWV4
• 17:21 とんかつ屋さん #α6300 + GIZMON #Utulens http://bit.ly/2ht8a6M https://t.co/mNUuKKt3ep
• 22:27 @bsdhack ありがとうございます。 Grip 初めて知ったので使ってみました!
• 22:28 GitHub Flavored Markdown ファイルの Web ブラウザでのプレビューに Grip を使ってみた。 http://bit.ly/2t4U2Wk
• 22:31 @bsdhack Grip で変換するの単独ページだけかと思ったらちゃんとディレクトリ階層中の Markdown ファイルも表示できて「おー」となりました。
• 22:36 お疲れ様でした & お大事に! @orga_chem / “退職の前座エントリ - 若き JavaScripter の悩み” http://bit.ly/2CP3vR9

プロジェクトでみんなをバスに乗せるために書いておく項目リスト

みんなをバスに乗せるためにプロジェクトのプランニングで明確にして共有した方が良いドキュメント形式って、方法論やプロジェクトの段階によっていろいろな名前のものがありますが、基本的に項目はどれも似たような感じです。

項目名を整理して決めておくと楽なのでちょっと書き出してみました。

コンセプトシート

比較的軽量にまとめる時。

• タイトル
• 概要 (What)
• 目標 (Goals)
• 背景と目的 (Why)

プロダクトプラン

プロダクトプランニング(エンビジョニング)のアウトプットとして。エピックレベル(数カ月程度の大きさ)。

• プロダクト名
• プロダクトビジョン
  • 概要
  • 目標
  • 背景と目的
  • 成果物
  • 完了条件
  • スコープ(含むの・含まないもの)
  • (opt) 依存するプロジェクト・制約条件
  • (opt) リスク
  • (opt) 予算
  • (opt) メンバ
• 概要レベルのプロダクトバックログ
• プロダクトロードマップ

ポートフォリオバックログアイテム

ポートフォリオプランニングで、プロダクトプランを評価した結果のもの。エピックレベル(数カ月程度の大きさ)。

• プロダクト名
• プロダクトプラン
• 期間
• 遅延コスト(ビジネス価値・時間価値・リスク軽減/チャンスと利用)
• WSJF

プロダクトバックログアイテム

スクラムで1スプリントで完成できるサイズのアイテム。フィーチャーレベル。

• プロダクトバックログアイテム名
• ユーザーストーリー(誰・概要と目標・背景と目的)
• 満足条件(あれば成果物を含む)
• サイズ
• レビュー方法

タスクチケット

ちょっとしたタスク。

• タスク名
• 概要
• (opt) 背景と目的 (概要で自明でない場合)
• (opt) 成果物/アクション (概要で自明でない場合)
• 完了条件
• 期日

プロジェクト憲章

• プロジェクト名
• 概要
• 目標
• 背景と目的
• 成果物
• 完了条件
• スコープ(含むもの・含まないもの)
• (opt) 依存するプロジェクト制約条件
• (opt) リスク
• (opt) スケジュール・期限
• (opt) 予算
• (opt) メンバ

備考

他には以下のような形式もあります。

• One Pager
• インセプションデッキ
• 製品要求仕様書 (PRD: Product Requirements Document)
• リーンキャンバス

[ プロジェクトマネジメント ]

Ulysses で TextBundle を使うのどうなのか調べてみた

Markdown 形式ファイルと、そこから参照されている画像ファイルを1つにまとめて管理する形式として TextBundle がある。ライティングアプリ Ulysses が対応しているのでちょっといじってみた。

• http://textbundle.org/

TextBundle は package format と compressed format がある。 package format は macOS のパッケージの形になっていて、 textbundle という拡張子をつけたディレクトリの中に info.json と text.* (Markdown なら text.md)、それからテキストファイルから参照しているファイルを asserts/ サブディレクトリに置くという仕様である。macOS の Finder からは1つのファイルのように表示される。

TextBundle を使うメリット

メリットは以下。

• テキストファイルと参照されている画像ファイルを一緒に管理できる(ばらけないで移動したりできる)。
• TextBundle に対応していないテキストエディタでも text.md を簡単に開いて編集できる。

TextBundle を使うデメリット

非対応アプリケーションから使う場合にデメリットを感じる。

• 非対応アプリからみると TextBundle 毎にディレクトリがあることになるので、ディレクトリだらけな感じになる。ドキュメント毎にディレクトリを開いて中のテキストファイルにアクセスする必要がある。
• Markdown ファイル名が text.md 固定なので、ファイル名だけでは区別できなくなる。

Ulysses for Mac の場合

Ulysses は TextBundle に対応しているので通常の Markdown ファイルと同様1つのシートとして自然に扱える。

普段 Ulysses for Mac では Dropbox の中のディレクトリを外部フォルダとして指定して使っているので以下、外部フォルダの時の話し。

Ulysses の外部フォルダ上の Markdown ファイルに貼った画像をエディタ上でプレビューできるのは現状 TextBundle だけ。エクスポート時も TextBundle 内の画像ファイルは書き出されれるけれど、(相対パス・絶対パス問わず)ファイル名で参照しているものは書き出されない(http/https な URL で指定した画像は HTML でエクスポートする際は画像が貼られる形になるが PDF ではだめ)。Ulysses だけを使って画像を扱いたいなら TextBundle を使う以外選択がない感じだ。

Ulysses 上で TextBundle なシートを保存するたびに参照されている画像ファイルを残して他は assets/ から消されてしまう。なので assets/ の下に画像作成に使ったソース・ファイル(マインドマップファイル)を一緒に置いておくおような管理はできない。そもそもテキスト編集で間違えて画像参照を消して保存実行してしまうと、画像ファイルだって消えてしまうので、画像ファイルだってオリジナルを別で保存しておく必要がある。

TextBundle は使うのは控えた方が良さそうだ。

Marked 2 で Markdown プレビュー時に自動的に画像を探すようにした

ライティングアプリ Ulysses for Mac では画像ファイルのプレビューがいい感じじゃなかったので、 Markdown プレビューアの Marked 2 を使うことにした。

• http://marked2app.com/

Marked 2 は相対パス指定・絶対パス指定のローカルの画像ファイルや URL で指定したネットワーク上の画像もきちんと扱ってくれるので便利だ。

画像ファイルをどこにおいておくか

さて Markdown ファイルから参照している画像ファイルをどこに置いておくか。Markedown ファイルと同じディレクトリに置くのが素朴だが以下の点で却下。

• Markdown ファイルを別のディレクトリに移動する時に参照している画像ファイルを一緒に動かすのが面倒。
• Markdown で書いた日別のノートファイルがたくさんあるようなディレクトリでは画像ファイルが邪魔。

別のところにまとめて置いておくのがよさそうだけれど、そうするとパス指定の問題が出てくる。ファイル移動時の参照書き換えをするは面倒なので嫌。

どうしようかなと思っていたら、 Marked 2 のプリプロセッサ機能で画像のパスを書き換える例を発見。その記事ではローカルホストでのプレビュー時とサイト公開時とでパスが違うことの解決に利用していたんだけれど、ローカルホスト上でも応用できるな。

パス指定はプリプロセッサにやらせてしまえばいいじゃない。画像のファイル名をユニークにしておき(もともとそうしている) Markdown ファイル上ではそのファイル名だけで画像参照として書く。プレビュー時に画像ファイルをローカルホスト上で検索して見つかったパスで書き換えてやれば良いなと。

さっそく Perl プログラムとしてプリプロセッサを作成。 Markdown ファイル中の画像参照があったら、Markdown ファイルのあるディレクトリレクトリ以下および指定したパス以下のディレクトリから File:Find::find で探し、見つかればそのパスに書き換えるようにしてみた。

あ、これ便利。

画像ファイルをいちいち Markdown ファイルの近くにエクスポートするとか、一緒に移動させるとかする必要なくてめちゃくちゃいいわ。

Marked 2 ライセンス購入

Markdown プレビューアの Marked 2 がいい感じだったのでライセンス購入した。

• http://marked2app.com/