新入社員向けスクラムゲーム

 # 新入社員向けスクラムゲーム

認定スクラムマスターを取得した2019年に、新入社員（１１人）向けのアジャイル開発の研修をしてほしいと社内で依頼がありました。

11人のメンバーはプログラムを大学で書いていたメンバーが5人であとはIT技術は素人でJavaの研修を受けたくらいです。

研修の内容は業務の内容とは関係なく、登場人物も仮称を利用させていただきます（僕以外は）。

研修の概要は以下のような感じです。

+ 単価マスターと売上情報を掛け合わせるような販売管理システムの構築

+ 社会人の開発者であれば1日か2日あれば作れるような内容

+ 4日間の作業研修で半日（3時間）が１スプリント

+ 1スプリント終了後に30分のスプリントレトロスペクティブを行う

+ 要件書類に不備がある（質問すると正しい答えを教えてもらえる）

+ スプリント中に３０分だけステークホルダ役への質問タイムがある

+ 5回めのスプリントでステークホルダの要望が追加される

+ 開発言語はユニケージ（何でもいいと思います）

開発言語が特殊で２日間ほどの研修を、アジャイル開発研修の前に行っていましたが、メンバーの中ではまだ経験が浅く、言語習得はまちまちな状態でした。

作業前に1日かけてスクラム開発の教育を行いました。

作業前のブリーフィングの様な感じです。

最初に技術力順に自己申告で並んでもらって、チーム編成をしました。

チームは３チームです。

Aチーム

一番技術力があるとされるメンバーが所属し、その代わりにメンバーは３人チーム

Bチーム

特に誰かが突出しているわけじゃない４人チーム

Cチーム

一人目立つメンバーがいるが、それ以外はおとなしい４人チーム

開始初日の動向

+ すべてのチームがチームの要のメンバーを中心に作業を行う

+ PBIをポストイットに記述して貼る作業を行っていない。

+ とにかく実装を行う（調査や情報の整理を行わない）

初日の動向を見てのフィードバックとして以下のような助言を行いました。

+ メンバー全員が効率的に動けるように業務分担する

+ PBIを必ず記述し調査や質問事項などもPBIで記述してホワイトボードに貼る

+ 初日のブリーフィングで教えたスプリントで必要とされるミーティング（プランニング、レビュー）などの実行を行う

+ PBIの作業コストはぼんやりでもいいので予想しておく

翌日の時点でBチームが初日の作業もPBIも捨てて作業し始めました。

勇気のいる行為でしたが、Bチームは誰かがメインで作業を行っていたA,Cと比べても目に見えて作業ができていなかったので、英断だったと思います。

Aチームは完全に技術力のあるメンバーがメインで動いていて、実装をゴリゴリに作成している感じでした。

他の二名は必要そうな設計などを調べていましたが、あまりメインで動いているメンバーと息があっている感じではなかったです。

Cチームもきっちりできるメンバーに頼り切りの場面が多くなっていました。

2日目を終えて折り返しでしたが、この時点で要件を満たしてしまうチームはいませんでした。

弊社に入社してくるレベルだと学生で突出した技術力のあるメンバーが居ることは少ないため今回の結果は妥当でした。

2日目のフィードバックとして

+ 作業中のメンバーは作業中のPBIを自分の手元において仲間に作業中のPBIを表示する

+ コミュニケーションを行うタイミングと作業するタイミングにメリハリを付ける

+ 質問時に現在作っているプログラムは動くようにしておいて動いている状態で進捗を報告する

2日目はじめに作業を全部捨てたBチームは2人ごとの2チームを内部で作り、ペアプログラミングをする形に変更し、スプリントの開始と終わりに必ずミーティングを行うこと、PBIの整理をその際に作り、不足分を協議して実装する場合に必要かの優先度をつけて作業をし始めました。

最初に教えたことを忠実に実践し始めました。

（ペアプログラミングは教えていませんでしたが、前日帰宅後に調べてきたようです）

3,4日目は時間ギリギリの中で全員が必死になって実装を行っていましたが、最終的に3チームとも実装はできていなかったです。

作業全体を終えて。

Aチーム

作成したプログラムは動作しているものの実装は途中までしかできていませんでした。明らかにメインと他2名で業務の差が大きく、メインのメンバーが間違えて実装していたことを指摘して戻るまでに半日（1スプリント）無駄にしたという報告をもらいました。

レトロスペクティブの時間も実装の話をしていたり、交流がしっかりできていなかったりというのが見受けられました。

チームで業務を行う上で今回の問題の解決策としてどうしたらよいか、ということを最後に話し合ってもらいました。

Bチーム

1日目を捨てたチームでしたが、実装がかなり進んでおり、2日目に出された追加要件以外は実装が終わっていました。一部処理の難しい帳票は省略した帳票で実装されており、もっともステークホルダの要望に答えられたチームとなりました。

成功の要因として、使い方のわからないコマンドはペア二人で別々で使い方を模索、そして本番コードは一緒に実装する。そこでわかったことはスプリントレトロスペクティブのミーティングでお互い情報を交換する。

このチームは30分とスプリント時間に比べて非常に長いレトロスペクティブの時間を実装時にどうするべきか、作業に詰まったところ、4人で並列に行う作業と、一緒に行う作業のタイプの分類などをしっかりと時間いっぱいに活用していました。

Cチーム

最後までバラバラでした。4日目になっても一人は実装していたけどほかのメンバーはそれを眺めているだけで手を動かす雰囲気もなく終わりました。

メンバーの中で自発的にどのように行動をするかなどの仕切るタイプもおらず、各自で分担して作業することもなく、研修を終えていました。

他のチームから比べて遅れてしまった最大の要因は誰かに任せてしまったことというのを口を揃えて発言していました。

今後の業務を行う上で、各自が自律して業務を行うためにどのようにしたらよいかを最後に話し合ってもらいました。

## 研修を通して学んだこと。

自分自身もスクラムで業務を行う前でしたが、今回一番学んだことは、Aチームのトップメンバーは11人の中では技術力は非常に高く技術的な感もあったためここがダントツで全部こなしていくことより、結果的にはメンバー4人がスクラムの規律の中で、自律して業務を行い、効率的に作業したBチームが最も実装を行えた結果を見れたことです。

初めて何かを作るという不確定性の高いことに、手探りで挑戦していく上でスクラムの規律に乗っ取り勧めていくことで、効率的に困難に立ち向かえることも学びました。

新入社員だけでなく、僕自身も学べましたので。

みなさまにも、研修の一環としてこのようなミニゲームを実践していくのをおすすめします。

> Written with [StackEdit](https://stackedit.io/).

アジャイル開発歴

こちらは僕のアジャイル開発に関する略歴です。

大学在学時に、学生ベンチャーに所属した際に、インフラ中心の開発技術者として業務を行っていました。

メンバーはサーバ及び、アプリの開発をJavaにて行っており、開発はXP開発を基本として行っていました。

アジャイルマニフェストや、基本的なアジャイル開発をその頃に書籍及び、実践にて学びました。

とはいえインフラエンジニアなので、要件の整理や開発管理などで開発自体は行っていませんでした。

最初のベンチャーからネット広告会社に転職しました。

その際に、WEBサービス開発として入ったのですが、結果的に、前職の経験からインフラエンジニアに転向しました（サービス企画開発や、新規サービスのPoCは行っていましたので、小規模な開発業務を行っていましたが。）

会社の規模の割に、インフラ担当は僕だけなので、

効率的な構築と、サービス停止が起こらないような安定的な作業などが必要で、サーバの規格化、サーバの構築

の自動化、複雑な遠隔監視のための整備、リモートデスクトップやDRACなどのリモートコンソールの整備などを行いました。

トラブルの発生の際や新しい方式の追加ごとに監視や設定や運用を見直し、各種インフラの設定ファイルの管理を集中化し、サーバ構築時のOSインストールの自動化のためのシェル整備、特殊な監視のためのプログラムの追加なども行っていたので、インフラ業務でありましたが、開発作業も結構行っていました。

多分今風の言葉で言うところのSREの業務だったと思います。

AWSのサービスが始まったか始まっていないかの頃で、これらの業務を行っていたため、クラウドサービスが充実した今となっては、この頃の作業の大部分はクラウドサービスを利用することで、簡易化されるようになりました。

そこから転職して、インフラエンジニアを卒業してWEBアプリケーションエンジニアになりました。

少人数で開発する、社内外サービスの要件から開発まででアジャイル開発案件を担当しています。

現在はXP開発だけでなく、スクラムでの開発も行っています。

デベロッパーやプロダクトオーナー、スクラムマスターなど案件により立場は変わっています。

> Written with [StackEdit](https://stackedit.io/).

raspbianでのswapファイルサイズの変更

/etc/dphys-swapfileの中の
以下のパラメータを変更する。
※MB単位です。


CONF_SWAPSIZE=100

.vimをdotfilesで管理している時のneobundleのインストールshell

dotfilesディレクトリを作成して.bashrcや.rubocop.ymlや.vimを管理している人がいると思いますが。
.vim以下にgitリポジトリを別で持つと面倒なので(submoduleでできると思うけど)、.vim/bundle/以下をあとからshellでインストールするようにします。

想定している構造はこんな感じ。

/dotfiles/.git/
/dotfiles/.gitignore

/dotfiles/vim/

/dotfiles/bashrc
                :

まずは.gitignoreに/vim/bundle以下を管理しないように記述。

/vim/bundle

以下のシェルファイルをdotfiles以下に記述


=====install_neobundle.sh======

#!/bin/sh

PWD=$(dirname $(readlink -f $0))

if ! [ -d ${PWD}/vim/bundle ]

then

  mkdir ${PWD}/vim/bundle/

  cd ${PWD}/vim/bundle

  git clone https://github.com/Shougo/neobundle.vim

fi

exit 0

===========

新環境で利用する際には、展開後にshellを実行して。

vimで:NeoBundleInstallを実行する。

ActiveRecord Enumとselect boxの連携でrails_configを使う

環境は以下になります。
ruby: 2.2.0
rails: 4.2

config(旧rails config)をインストールします。
（settinglsogicでも利用できる方法だと思います）
Gemfileに以下の記述を追記します。

gem 'config'

gemをインストールします。

$ bundle install

rails_configをrailsにインストールします。

$ bundle exec rails g config:install

今回はtestdata（モデル）にstatus（カラム）を設定してenumを利用します。
scaffoldを作成します。

$ bundle exec rails g scaffold testdata status:integer

statusで利用するリストをconfig/settings.ymlに記述します。

model:
  testdata:
    status:
      admin: 10
      normal: 20
      guest: 30

記述に対してデータを設定します。
app/model/testdatum.rbに記述します。

class Testdatum < ActiveRecord::Base
  enum status: Settings.model.testdata.status
end

設定したデータをviewフォームに適応します。
app/view/testdata/_form.html.erbでの該当のフォームを以下の記述に変更します。
selectedも同時に設定します。

  <%= f.label :status %>
  <%= f.select :status, @testdatum.statuses.keys , selected: @testdatum.status %>

yum group

メモ

yum grouplist

->

yum groupinstall

rails3でのdependentでrestrictを設定した場合の対処法

モデルでのdependentをrestrict にした場合の

消去出来なかった場合のエラー対処方法

 

Model

class ShareType < ActiveRecord::Base
  has_many :shares, :dependent => :restrict
end

Controller

class ShareTypesController < ApplicationController
  def destroy
    begin
      @share_type.destroy
      flash[:success] = "successfully destroyed." 
    rescue ActiveRecord::DeleteRestrictionError => e
      @share_type.errors.add(:base, e)
      flash[:error] = "#{e}"
    ensure
      redirect_to share_types_url
    end
  end
end 

元ネタはこちらから

http://apidock.com/rails/ActiveRecord/DeleteRestrictionError