Slackで簡単に「日報」ならぬ「分報」をチームで実現する3ステップ 〜 Problemが10分で解決するチャットを作ろう
Slackで簡単に「日報」ならぬ「分報」をチームで実現する3ステップ 〜Problemが10分で解決するチャットを作ろう〜 開発プロジェクトを進めていくと、チームは様々な課題に直面する。こうした課題は、週次のミーティングや日報で共有して解決していくことが多い。 課題は大小様々だが、特に数時間で解決できるような小さな課題をいかにリアルタイムで解決していくかで、チームのスピード感が大きく変わってくる。 僕のチームでは、リアルタイムの課題解決の為に、社内チャットSlackを社内Twitterのようにする邪道な使い方「分報」という取り組みを実践している。 > 日報の弱点日報の弱点 日報は一日の業務の報告書で、一般的に「進捗状況」「体験」「学習」「課題」が記載される。これらをチームで共有することで暗黙知を減らし、個人とチームを成長されることが目的だ。報告方法はチームによって様々だが、メールをはじめ、
テストを書くか書かないかの判断の話
writing_unit_test.md ユニットテストでテストを書くか書かないかの判断の話 お題 メソッドの出力の結果が、true か false のどちらでも返ってくる可能性がある場合、assert 文を書く時は true の場合だけで良いのだろうか テストとは まず、基本の考えとしてなぜテストをするのか？というのがあります。 テストとは、エラーをみつけるつもりでプログラムを実行する過程である。(via ソフトウェアテストの技法 [Glenford J. Myers]) という言葉のとおり、最小の手間でプログラムのエラーを見つけ出そうとする試みがテストです。裏を返せば、エラーが見つかる可能性が低いのにすべてのことを試すのはテストではありません。 判断するときの論点 いくつかこれを判断するときの論点があります (Boolean に限らず、「そのテストは必要か？」と考えるときの観点ともいえ
「始められても続けられない…」 リーンスタートアップを継続する２つのヒント #1 | Lean Startup Japan LLC
リーンスタートアップの考えに従って事業設計を「開始」することは、ステークホルダーの合意があればすぐにでも始められます。 ですが、それを成功するまで「継続」するとなると、とてもハードルが上がります。実際、多くのチームが仮説検証に取り組んでは、ほんの数ヶ月でアイディア重視に走ったり、プロダクト開発に着手してしまったりします。 これはいったいなぜなのでしょうか。 何度インタビューを行っても、ニーズを確信するに至らないからですか？ やっぱり、とにかくまずはサービスを作って、グロースハックをガンバってユーザ数を増やしていた方が、成功に近づいているように感じるからですか？ わかります！ これってつまり、事業開発をするチームには、たとえ仮説が「反証」され続ける状態であったとしても「前へ進んでる実感」が必要だと言うことなのです。 この「評価基準」を適切にセットすることなく仮説検証を始めてしまうと、自分たち
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
