読者です 読者をやめる 読者になる 読者になる

チームの生産性を改善するために決断疲れを最小化する | try! Swift Tokyo 2017 #tryswiftconf Day2-12 聞き起こし

チームの生産性を改善するために決断疲れを最小化する

twitter.com

ソフトウェアエンジニアとして、私たちは書いているコードの1行1行ごとに決断し続けています。 これに必要な時間とエネルギーの量はチームが生産的に働けるか、あるいは停滞させてしまうのかどうかを決定します。このトークではSwift開発における決断疲れを最小化し、チームの効率と同時にコミュニケーションとコラボレーションを改善する方法についての個人的な経験を共有します。

チームの生産性を改善するために決断疲れを最小化する

f:id:niwatako:20170303164100j:plain

Pivotal Labでの働き方

動やったら精神的な決断疲れを減らせるか、実際にやっている方法をお伝えします。

f:id:niwatako:20170303164202j:plain

f:id:niwatako:20170303164203j:plain

f:id:niwatako:20170303164206j:plain

プログラマはキーを打つ度に決断をしています。

タブ?スペース?Viewはどう書く?条件は?ライブラリは使う?CocoaPods?Carthage?

ちいさなことのように思えるが、しかし精神的に集中しないと決定できません。

そのために難しくなります。オプションの中でも最も努力のいらないものを選んだり、意思決定を限定的にしかみない、あるいは選択を避けることが有ります。これを決断疲れといいます。

我々はチームでコミュニケーションして決定します。

ここのアプローチがたまたま合致することはない

やろうとしなければ出来ない。結果だけ伝えるみたいになってしまう。そうすると疲労につながります。

f:id:niwatako:20170303164412j:plain

思わぬところに影響を及ぼすコードを書いたりしてしまったりします。

どうやって重要な決定にエネルギーを向けられるでしょうか

f:id:niwatako:20170303164442j:plain

意思決定をシンプルにすることで開発効率を高められると思います。

そのような疑問に答えるためにコンテキストの中で考えてみたいと思います

どうやって私たちは日常を送っているか

全てカバーしていきます。あらゆる決定が精神を疲れさせます

まずは朝ごはんをどうするかの決定が必要です。PivotalLabではそれは必要ありません。提供されるのでチームメイトと話すいい機会です。

9:06に朝礼を行います。新しいメンバーやお客さんの紹介、ヘルプの申し出、興味深いニュースが話題になります。

f:id:niwatako:20170303164615j:plain

その後プロジェクト向けの朝礼を行います。昨日何をして何が起きて今日何をするか。

非常に時間がかかったか、どこにリポジトリを入れるか決めるのが大変だったという話がありました。そしたら話し合ったほうが良さそうですよね。他のエンジニアもやはり同じ懸念を抱いていてそうだねという話になった。

f:id:niwatako:20170303164706j:plain

どこにファイルを置くべきか

f:id:niwatako:20170303164717j:plain

何を探しているか分かっていればファイル名やファイルナビゲーターで探していく、検索ができます。

f:id:niwatako:20170303164748j:plain

ファイルが置かれた場所は何故そんなに大事なのでしょう。

知らないプロジェクトを触るときは探し回ることになるわけです。ずっと長い時間を費やすことになります。思うより。

一定の組織化が必要ということになりました。

全く組織化しないことは、無いなという話に。

Helper, Utilはあまり何が入っているかの助けにならない。

MVCを使ったら?という人もいました。でも他の人も懸念を示しました。MVC概念に一致しない場合困ってしまうよね、それだけではダメだという話になりました。

Applicaiton、 Component, UIでフォルダを作りました。 テストも同じ形にしました。 ただResourceフォルダにはテスト関連のものだけが入ります。

f:id:niwatako:20170303164946j:plain

AppDelegateやMain.swiftは普段触らないので邪魔ですよね。

本当に作業が必要なものを集めます。

ComponentoはComponent毎にフォルダを分けました。モデルのようなものだと考えています。

f:id:niwatako:20170303165029j:plain

レストランリポジトリオブジェクト、パーサーオブジェクト、Presenterも使われますね。

UIは

f:id:niwatako:20170303165105j:plain

DelegateやDatasourceで関連したものがあればそこに入れていきます

予見性のある形でいれていくと、いちいちどこに入れるかで困らなくなります。そうすると決定要素が一つ減ります。

f:id:niwatako:20170303165141j:plain

エクストリーム・プログラミングテスト駆動開発、そしてペアプログラミングをやっています。

ペアプロはやったことはあるよと思っていましたが、Pivotalでやると、だいぶこれまで経験したものとは違うものになりました。

f:id:niwatako:20170303165227j:plain

キーボードと27インチディスプレイ。どちらの人もドライビングしていくことが出来ます。

一連のIndexカードがあります。いろいろな話をしたりダイアグラムを書いたりに役立ちます。

f:id:niwatako:20170303165303j:plain

ピンポンプログラミングの方法

テストコードを書いた人同士が交代で書く

f:id:niwatako:20170303165321j:plain

ナビゲーター・ドライバー

熟達者がナビゲーターとなってドライバーがコードを書く。教育に役立ちます。

f:id:niwatako:20170303165351j:plain

できるだけこのペアが一緒にすることが重要です。エンジニアやデザイナ、PMもペア位になります。毎日ペアを変え、仕事を変え、チーム全体でコードベースを共有します。

色々なトピックがあるがベネフィットとしてはすぐにフィードバックが帰ってくる。そしてすぐ意思決定を行えます。

f:id:niwatako:20170303165502j:plain

ケータリングランチを食べます。だれかがプレゼンをしたり、動画を見たりします。

この日はObjc-ioの方をお招きしました

昼食後またプログラミングを続けます。

プランニングのミーティングがあることもあります。

f:id:niwatako:20170303165646j:plain

f:id:niwatako:20170303165657j:plain

ViewControllerを開いて新しいUIオブジェクトなどをどこに置くでしょう

Ctrl+6を押してナビゲーションをまずみます。

セクション化や共通パートを定義したりしていきます。

アノテーションなし→MARKありセパレーションなし→Markとセパレータ

f:id:niwatako:20170303165824j:plain

f:id:niwatako:20170303165833j:plain

プロパティ、ViewElements, initialization, Lifecycle, Privae methods,,,

f:id:niwatako:20170303165907j:plain

ViewControllerのボイラープレートをXcodeスニペットに登録している。

ぱっとテンプレートを使って自動化します。

プロトコル遵守も重要なトピックです。

f:id:niwatako:20170303165955j:plain

f:id:niwatako:20170303170019j:plain

MarkをつけてExtensionに切り出し、プロトコルに属するものであることを示す。

このように共通の形で組織化すると何がどこにあるかわかりやすくなる。新しく書くべき場所も分かりやすい。

f:id:niwatako:20170303170109j:plain

休憩はダブルスで同じようにペアで卓球、インフォーマルな関係を作れます。そして全く違うことをすることでリフレッシュします。

ペアプロは異なる担当でエンジニア・デザイナのペアなどもやる

f:id:niwatako:20170303170215j:plain

スタイルガイドはデザイナから提供されています。それらを実装し再利用する。

f:id:niwatako:20170303170242j:plain

UIColor の Extensionでカラーを定義しています。

f:id:niwatako:20170303170301j:plain

ボタンも定義されます。 ボタンをパラメータとしてとって、それぞれに適切な設定を行います。

UIButtonに対して適用していくことが出来ます。同様にViewやLabelにも。

f:id:niwatako:20170303170348j:plain

f:id:niwatako:20170303170355j:plain

ViewControllerがロードされると呼び出されます。

新しいスタイルを適用する時にどうしたら良いかわかります。

f:id:niwatako:20170303170422j:plain

チームメンバーのみで行います。

f:id:niwatako:20170303170503j:plain

マネージャーもステークホルダーも居ない場でチームメンバーだけで話します。お酒を飲むこともあります。

特に感情を取り扱います。この1週間どう思ったか。

f:id:niwatako:20170303170537j:plain

感じたことを書き込みます。ファシリテーターはボランティアです。

アクションアイテムは翌週取り組んでいきます。継続改善を反芻する、チームビルディングに重要です。

f:id:niwatako:20170303170627j:plain

問題が大きくなる前に解決する。

f:id:niwatako:20170303170643j:plain

Extream Programingの中でケント・ベック

真実を話すことで信頼が醸成される。

我々もふりかえりの中で信頼を醸成していきたい。

これらを実行することが重要です。

f:id:niwatako:20170303170718j:plain

意思決定の合理化は今も将来も一人でもチームでも重要です。

ベストな答えではないですが選択肢として。よりシンプルに出来るならどうすればより効率化出来るか考えてみて下さい。

意思決定をする場面でそうした意思決定が何回も反復されるならば同自動化出来るか簡素化出来るか考えてみて下さい。

個人、チームの意思決定が減り、チームのリソースをより重要な意思決定に向けられます。

f:id:niwatako:20170303170902j:plain

f:id:niwatako:20170303170904j:plain

f:id:niwatako:20170303170905j:plain

f:id:niwatako:20170303170910j:plain

Q&A

バランスの質問です。働いている時の快適さがあると思います。快適に感じる必要があります。(???)いろいろな修正が必要だったり2人でやることが必要化コスト化みたいな??

ペアプログラミングはユニークだと思います。人との関係で言うと非常に集中が必要である、好みのキーボードがある、好みのIDEを使うという人もいる。自分ではやっていないことを人から学ぶことが出来る。キーボードのショートカットなども。

チームに関して共感を得ることが出来る。

この人の他のメンバーが使うツールは自分の知らないアドバンテージが有るのかなと思うことが出来る。そうした学習を続けられることがいいことだと思う。

自分の好みを犠牲にしてももっといいものを見つけたり、気に入っているものを伝えられる。

私はリモートで働いていますがペアプログラミングが難しい。リモートで働く上で良い案はないでしょうか

ペアプログラミングをリモートでやるのは難しい。ペアプログラミングの昔ながらのスタイルは1台を共有して一人が入力、あるいは複数キーボードを使う。

適切な機器を持ってペアプログラミングをすることは一つの重要な要素だと思います。Skypeを使ってペアプログラミングをしている人は居ます。ただ可能であれば経験を得ていただきたいなと思います。ソーシャルな側面があります。

私はリモートで働いたことが有ります。その時は寂しかったです。FacetimeSkypeも試してみてはいかがでしょう、でも生身で出来るのが一番だと思います。

ちょっと不思議に思ったのは奇数の開発者が居たらどうしますか?

奇数の開発者ということも有りますよね、一人は残念ながら残されることになります。GetDoit?というツールを使っています。GetSoloというオプションが有ります。今の時点では午前と午後で分けています。ペアリングの頻度を変える。 そして正しい方向を探す必要がありますが、Backlogでちょあーず:探索や小さな仕事をする人たちですが、そういったタスクをすることになります。病気や休暇もあると思うのでそのような方法を試みます。