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

亀岡的プログラマ日記

京都のベッドタウン、亀岡よりだらだらとお送りいたします。

#RxTstudy 第3回いってきましたよー。

勉強会

第3回、参加してきました。LT資料はいらないだろう常識的に考えて。
ということで、メモ書きをそのまま転機。疲れたのですよ。。。

Redmineプラグインの作り方

川端さん(@agilekawabata)


  • コマンド一発でViewやらControllerを生成できる


    • generateコマンドでViewもControllerも。



  • Railsの流儀


    • コントローラーは複数形にしてください!



  • HookLister(Redmine)を継承してListenerを追加する


    • Viewとして追加したい場所に放り込んでやる



  • gemsをbundleする設定が必要らすぃ。。。


    • スマートじゃない(By川端さん)



  • 後必要なもの


    • 天気設定のモデル

    • 都市のモデル



  • 都市のDBもdb.migrateでできる


    • Rubyコードからテーブル作ってくれるようなイメージ?



  • Ruby的な感じ


    • belongs_to で”属している”




webサイト Redmine.JP 4年4ヶ月

前田 剛さん


  • ごめんなさい、LT資料をここで書いてたのでここだけ薄いのです(´・ω・`)

  • RemineJPについて


    • PV:130000/month

    • nanocで管理している



  • CMS:nanoc


    • すべてテキストベースの静的HTML作成ツール


      • メリット


        • DB不要

        • sedで一発置換OK!





    • ruby製だ!




Backlogの開発で大事にしていること

染田さん(@tksnt)


  • キャリア


    • 始まりはインフラエンジニア

    • 2005年未踏 Tuigwaa

    • choistudy

    • Backlog



  • どうやってつくってるか


    • 3〜4ヶ月くらいのスパンでリリース


      • 例えば今はGit対応



    • 今のトレンドも意識する



    • フィーチャー決める

    • 画面モック作る


      • 画面イメージから機能を考える

      • 開発者が作る

      • かなり頑張って作っている・・・


        • これ、デザイン的知識ないと難しいよなぁ・・・

        • 色合いとか入ってるし!



      • レビューの観点


        • データの流れ

        • 情報の見せ方





    • デザインナに回してもんでもらう


      • レビューの観点


        • Backlog”らしさ”

        • 直感的か

        • 統一感



      • FBはあくまでざっくり


        • デザイナさんの発想をうまく使う





    • プロト → レビュー


      • やらないこともある

      • 実環境でやる


        • コレほんとうに便利なのか分からないものは、使わないと判断できない



      • chrome extentionでプロトを作る!!


        • jsとhtmlのみで作れるし。





    • 本開発 → レビュー


      • レビューの観点


        • 違和感はないか?


          • 8割を優先



        • 操作の気持ちよさ

        • 文言・表現







  • 特徴


    • レビューはめちゃくちゃ多く入れる

    • 結構捨てる、寝かせる


      • 違和感を感じたら、勇気を持ってやめちゃう。

      • 出してしまうと引っ込めるのは難しい





  • 大事にしていること


    • チームではたらく、すべての人に、Backlog

    • (ツールを使う人達が受ける)感情


      • 仕事を楽しく。

      • 達成感を表すような仕組み


        • 色の変化

        • バーンダウン上で褒めメッセージが出る



      • あえてタスクリストや検索に余白を入れる


        • 気持ちとしてゆとりをもってもらうように!



      • 遊び心



    • 分かりやすさ


      • 難しい機能をわかりやすくする

      • 第三者の目が大切

      • 機能設計のプロセスを規定しない

      • 要望の背景を考える


        • 概念モデルが違う人のことを考える


          • 複雑性を増す結果にならないか???



        • 例えば:親子タスク


          • みんなが機能を想像できるか?







    • コミュニケーション


      • 絵文字、アイコン


        • 言葉に出来ない感情はいっぱいある!





    • ↑を考えるために必要なこと:UI


      • 誰のためのデザインだ!

      • 誰が責任を持つ?


        • いわゆるUX担当者はいない

        • プロダクトオーナーが決定する



      • 神は細部に宿る





  • チームビルディング


    • Strength Finder


      • さぁ、才能にめざめよう



    • 年表づくり

    • 朝会



  • ユーザーとの対話

  • コラボレーションの4つの要素


    • Common Mission

    • Open Mind

    • Complementery Sterength

    • Wholeness




チームにRedmineを適用せよ

藤原さん(@daipresents)


  • 最初のチーム


    • タスク管理なし→失敗



  • 次のチーム


    • XP

    • 種々のツール

    • 問題


      • Menberが増えたので・・・

      • リーダーシップをもっと!!

      • バラバラ感



    • プラグイン作った


      • ぱっと一画面でチームの状況がわかる

      • 裏目的:働けてないひとを見える化

      • 進捗の見える化に成功


        • 裏目的も達成。こわい。







  • 3つ目のチーム


    • リファクタリング

    • 目標;他の人の改善

    • XP + Scrum

    • 定例会なし。朝会のみに。

    • 問題


      • 運用作業の増加



    • 改善のポイント


      • Parking Lot Chart プラグイン

      • リリースできないチケットは作らない!


        • 〜機能 など。



      • 藤原さんのプラグインはViewのみのカスタマイズでできているらしい。


        • たしかにそれで十分なのかも!!それなら作りやすそうだし。





    • 工数管理はめんどいので途中でやめた


      • それでも意味のあるデータは取れる



    • 成果・時間コストのの見える化

    • 開発メンバ以外への浸透



  • 2011


    • 開発メンバとのチーム

    • タスクボード中心へ移行


      • ダブルコストがきつい



    • ストーリー:1〜2週間

    • タスク:2〜3日


      • 本当は一日一つはタスクが終わるようにしたい



    • タスクってなあに?


      • モジュールで考えずに、機能で考えるべき


        • Fearture = Release * X

        • Release = Iteration * X

        • Iteration = Version * X

        • Verison = Task * X





    • ユーザーストーリマッピング。語り方を考える。


      • 例えば、リリースを自動化せよ を言い換える。


        • → 一日10回リリースせよ







  • どの?よりも、どう?よりも、なぜ使うか?