実家に帰るので行ってきた。
残念なことに終了後の懇親会は行けなかったけどな。
★OPセッション
アジャイル開発に一番大事な物
→コミュニケーションで特に挨拶が重要
★アジャイルプロセス導入ポイント(永瀬さん)
今までアジャイル開発をやってきて成功している人々は、オブジェクト指向のスペシャリストみたいに新しいことが好きな人々である
最近企業でもアジャイル開発の実施が増えてきている
特にウォータフォールで開発をずっとやっている会社が最近アジャイル開発をやりだしている
しかし中々アジャイル開発での開発がうまくいかないことが多い。
また、やり方の導入ポイントが分からないことが懸念
伝統的にウォータフォールやっているところに対しての導入ポイント
△社内、部署の文化を見極める
→ウォータフォールでやってきたところは、ウェブ系の開発のように自由に開発をやっているところと違うことが多い
→社内もしくは部署で新しいもの好きが多いのか
→若い社員が多く、開発そのものをゲーム感覚でやっているのか
△正式なプロジェクトにしてもらう
→急に開発プロセスのやり方を変えても中間層の管理職などには受け入れられないかもしれない
→アジャイルで開発が成功している事例を出してみると認めてもらえるかもしれない(IBMなどで実際にやっている)
△開発を進めるにあたっては。ウォータフォールとアジャイルのどちらが良くてどちらが駄目とかは無い
→ウォータフォールのいいところは認めていく
→必要があればウォータフォールのよいところをアジャイルにも取り込んで行く
→分かりやすい言葉に置き換え、アジャイル特有の特殊な言葉を多用しない
△アジャイルで開発を行うには目的、目標のゴールを最初に決めておく
→生産性を高める具体的な数字の目標を出とよい
→会社としてアジャイルで取り組むには数字目標は大事でカイゼンという意味で理由になる
△作業の役割は残しておく
→PLやPMといった役割は残しておくこと
→ただし設計者とプログラマーには分けないこと
△設計書を書く担当者にはオブジェクト指向の教育をきっちり行う
→コピー&ペーストの設計で、イテレーションやソースコードのリファクタリングができなくなり、開発が成功しない
→設計を最適にしないとソフトウェアの改良が進まなくなる
上記ポイント(ハードルともいう)を超えるには以下のものが必要
勉強会
教育
開発への覚悟
△導入前にやること
→既存の開発で使用していたエクセルワードなど使いやすいツールを使うとよい
→開発用IDEは不慣れなものを使うぐらいなら変えないほうがよい
△有効なものを行う
→壁にストーリーカードを貼っておく
→ペアプロがやりやすい机配置にする
→楽しみながら開発ができる環境を整える
△開発の初めにやることは
→作業プロセスの手順書を最初に作りプロジェクトメンバー全員で共有する
→ストーリーに対してどんな設計を書いて、どんなテストをするのかといったことをプロセス手順書に明記する
→最低一ヶ月ぐらい手順書作成に時間をかける。
→自分たちにあったプロセスを作成する。
→プロセス手順書を作成するときには、専任のコンサルタントでもよいのでアジャイルをよく知っている人に入ってもらい作ること
△次ぎにやること
→SEの中でも上位設計者と下位設計者がいるので、どんな役割の人がプロジェクトに必要なのかを見極める
→ドキュメントとコードが一致するため、アジャイルでは詳細設計はいらない。
△アジャイルで重要なこと
→レトロスペクティブ(反省会)は、イテレーション毎にきっちりやる
→イテレーションが回らない恐れがあるので、レトロスペクティブは運営する人が考えて行う
→会議ではないので、場の空気を和らげながら行う
日本でやるには下記項目を行う
△設計をどうするか
→DB設計やコード設計など設計と一口にいっても幅が広いのでチームで決めていく必要がある
→UMLを導入して基本構造をモデリングをしていく(基本骨格を先に決めてしまう)
→要求で仕様がかわることがあるが、骨格は変わらない
→UMLは青果物にはなりえないが、プログラムを書く上でテスト工藤開発ができる
△テストのシナリオをどうするか
→従来は画面設計や詳細設計から起こしていた為
→欧米だと、お客が開発者と脚が同レベル前提
→テストの合意の取り方
→ストーリー(用件)が正しいのか
→機能一覧とブレナイようにするとよい
→本のとおりには行かない。自分たちの今までの作業のやり方を振り返り、必要なものを事前に準備する
△他に事前に決めることは
→ツール類の整備
→IDEは何にするのか
→ビルドツーる
→CIは何にするのか
△こういうことが必要だということを事前にリストアップする
△アジャイルだとテストが膨大になるのでテストの管理を行う
→テストのリファクタリング
→開発と平行で出来るようにCIのタイミングはいつにするのかを決定する
△分散開発するときには
→どんなツールが必要なのか
→事前にうまくいくか確認しておくが重要
会社でやるには上記準備が必要。
出来ているのかの確認にはチェックポイントを作るとよい
因みに、中国ではエンジニア不足中してるらしい。
中国内の開発だけでなく、日本からのオフショアで人が足りないそうだ。
なのでアジャイルが増えて行くかもしれない。
--------------------------------------------------------------------------------------------------------------------
2つめのセッション
★7月にマーチンファウラーが講演をやるらしい
★アジャイルSWテストというユーザーグループがある。
産業のかいぜんはシステムにある。５％ほどが働いているひとにある
組織文化を変えたければシステムを変える必要がある
欠陥は悪い方法からきてる
すべてのアジャイルにはベストプラクティスは無い。捨てる
シングルソーリューションも無い
一掃すべし
コピーメソッドの神話も問題
まっくおーりんずが勧めるのは、自分の組織に合わせてアジャイルを進める
アジャイルはベターですけど、イテレーションは悪いことをよくしていくようにする
ウォータフォールモデルでも正しいのであれば、アジャイルでやって価値を供給できないよりもいい
たくさんの組織はアジャイルにフォーカスしている。
アジャイルをやるkとがゴールになっている
でも真にやることは客へのニーズ提供。
アジャイルで価値を提供するのがテーマ。
最近では基本に戻りコード品質をよくしていく
我々がかんがえることは全体であって部分最適では無い
→サブモジュールの最適な状態をもとに単一のビジネスユニットに対してフォーカスしていく
ITはプッシュ型
いいものであっても使ってもらえなければ意味が無い
→こういうときにはその時それぞれで考える。
重要なのは
だれが
いつ
どこで
使用するのか
本質的な要求を理解する
無駄なプロセスが一旦はいるとそのまま長く続いてしまう
→非効率なことがおこってしまうと何も変えることができなくなる
間違った場所から出発
あたらしい技術を使ったりとか、先走り。先走りから貧弱な設計が自然に怒る。ワークフローもあわせて貧弱になる
客の利益やニーズを理解。顧客の視点で。
顧客からリーダーは見えない。銀行の窓口
かくれた無駄がいっぱいある
改善して組織を変わっていこうとする
改善のためには
まず外にでてみてシステムを調べる。現場を知ることから
外から中に入ってくるというやり方(顧客から)
check do plan
資料は公開予定。
--------------------------------------------------------------------------------------------------------------------
★パネルディスカッション
アジャイルは失敗するって本当ですか?
→本当ですw
@yasuohosotani
アジャイルは開発をマネージメントするための有効なフレームワークの１つ
永田さん
agile inspection。アジャイルは顧客とのやりとりが大事。ドキュメントの品質をあげるのに使える
永瀬さん
日本のソフト産業を崩壊させる方式の一つ
@nao_maru
リズムと愛
★何をすればアジャイルの成功?
マネージャからすると計画通りにプロジェクトがきちんとした品質とコストでできた時
→そうはいいつつもお客満足が第一
QCDが重要。バランス感覚必要。
→プロセス改善の話に繋がる
→アジャイルやればなんとかなるぜってやると失敗する。マネージメントをしっかりしないと破綻する
→アジャイルをやれば品質があがる訳ではない。品質は設計にあたる
★アジャイルでは大体この期間に何をするのかとい基本計画(ロードマップ)が大事。
→開発側や偉い人の不安を取り除いてやることが大切
→仕様変更だったりに対応できるように作業のタイムボックスを考える
★現状の日本だと以下２点がゴールに近い
→イテレーションが回るようになった
→楽しく開発が進んでる
★上記がゴールになる要因として考えられるのは「欧米と開発のスタイルが違う」ことにある思われる
→開発スタイルの危機感をもつ
→欧米と５年ぐらい離されている
★システムテストレベルだと要求がベースになるのでどうなっているのか?
→ウォータフォールと異なるので要求のマネージメントが大切で難しい。
→要求が複雑化することで、同時にテストも複雑になる
→欧米ではアジャイル開発には１週間のイテレーションで行っている
ツールを入れることは目的では無くプロセス改善に使う
→問題がないのに導入しなくてもよい
redmine
ある程度ユーザーにチケットを委譲できる。
リスケとかマネジメントしてもらうことができる
→何の為に使うのかを考える
→まずはマニュアルを整備する。
→ツールありきで使うのは駄目。
欧米ではマニュアルと併用。２重管理になっていることが多い。
★アジャイル開発は儲かるか?
→儲からない。
→開発側からすれば博打に近い。
→しかし顧客側には進捗が見えているから、将来を考えると損はしない。
→責任がユーザーに移る上に、早いといったメリットが多い。
→信頼関係の構築がしやすい。
★何を気にするか
まとめ
開発プロセスを変えたいと思うメンバーが何人いるかでアジャイルのパワーになってくる
→人数が多いと行動に移しやすい
アジャイル開発に失敗してもよくやりたければ、アジャイル開発のよさ悪さを感じ経験を作って自分の継ぎに生かす
エンジニアリングに何が必要かを考えるようになる
→柔軟に考える。うまくやると開発が楽しくなる
経験を積んでやってみる
