in WACATE 2019 Winter https://wacate.jp/workshops/2019winter/
ΞδϟΠϧͱςετ8"$"5&8JOUFS
View Slide
ࣗݾհ• ֯ా ढ़• ιϑτΣΞ։ൃऀ• ίϛϡχςΟ׆ಈ• 8"$"5&࣮ߦҕһ• /B*5& ࡚*5ٕज़ऀձӡӦҕһ
͜ͷηογϣϯʹ͍ͭͯ•ΞδϟΠϧͷ֓೦ͷઆ໌•ΞδϟΠϧ։ൃͷதͰςετʹؔΘΔࣄͷҰ෦Λհ• ςετͷߟ͑ํ• ςετͷΓํ
࣍•ΞδϟΠϧʹ͍ͭͯ•ΞδϟΠϧͷςετʹ͍ͭͯ•ϫʔΫ
ΞδϟΠϧͱςετ
ੈͷதͷྲྀΕ•ੈͷதͷมԽ͕ૣ͍• ιϑτΣΞٕज़ͷมԽ• ιϑτΣΞͷχʔζ•χʔζΛͦͦᘳʹ֬ఆ͢Δͷ͕͍͠• ιϑτΣΞͷࣾձͷ͕Γ• ιϑτΣΞར༻ऀͷ֦େ
仕様変更や、要求の変更があまりない外部要因に左右されず、新しい技術も使⽤していないような不確実性があまりないシステム外部要因に⼤きく影響を受け、新しい技術やなどを使⽤する不確実性が⾼いシステム↑ アジャイル向きなシステム
https://agilemanifesto.org/iso/ja/manifesto.html
→ まだソフトウェアを完璧に開発できる⽅法論は⾒つかっていない
→ ⽅法論は⾒つかっていないけれど、⽅向性は⾒えてきた
→ 対話してどうしていくのがベストかを話し合おう
→ 完璧なドキュメントを作るよりも動くものを早く作ろう
→ 関係者みんなで協⼒して良いものを作ろう
→ 想定外の変化はあるし、変化へ対応できるようにしていこう
→ 左側も価値があること。だけど、右側をより重視する。
ソフトウェア開発をより良くするため考え⽅の提案
顧客満⾜を最優先し、価値のあるソフトウェアを早く継続的に提供します。→ ソフトウェアを使う⼈を優先に考える。価値を⽣むソフトウェアを早く提供するようにする。また、ソフトウェアを継続的に改善していく。
要求の変更はたとえ開発の後期であっても歓迎します。変化を味⽅につけることによって、お客様の競争⼒を引き上げます。→ 競争⼒を上げるような仕様変更は歓迎する。ソフトウェアの価値を第⼀に考える。
動くソフトウェアを、2-3週間から2-3ヶ⽉というできるだけ短い時間間隔でリリースします。→ 半年、１年という⻑期開発ではなく、短いサイクルでソフトウェアを提供する。
ビジネス側の⼈と開発者は、プロジェクトを通して⽇々⼀緒に働かなければなりません。→ ビジネスを達成するためにみんなで協⼒してソフトウェアを開発していく。
意欲に満ちた⼈々を集めてプロジェクトを構成します。環境と⽀援を与え仕事が無事終わるまで彼らを信頼します。→ 意欲のある⼈達を集めてチームを構成する。開発者を信頼する。
情報を伝えるもっとも効率的で効果的な⽅法はフェイス・トゥ・フェイスで話をすることです。→ 対⾯でのコミュニケーションを⼤切にする。
動くソフトウェアこそが進捗の最も重要な尺度です。→ 動作するソフトウェアを確認することで開発の進捗を判断する
アジャイル･プロセスは持続可能な開発を促進します。⼀定のペースを継続的に維持できるようにしなければなりません。→ ⼀定のペースで開発していく。詰め込んだり、だらだらした開発はしない。
技術的卓越性と優れた設計に対する不断の注意が機敏さを⾼めます。→ 技術的に優れた設計をしていくことで、変更強いソフトウェアを開発する。
シンプルさ（ムダなく作れる量を最⼤限にすること）が本質です。→ ムダを排除し、価値あるソフトウェアをより多く作れるようにする。
最良のアーキテクチャ・要求・設計は、⾃⼰組織的なチームから⽣み出されます。→ チームは⾃⼰組織的なチームを⽬指す（⾃⼰組織的＝⾃律的でリーダーに依存しない）
チームがもっと効率を⾼めることができるかを定期的に振り返り、それに基づいて⾃分たちのやり⽅を最適に調整します。→ 振り返りにより、効率を更に上げて最適を⽬指す。
要求分析 設計 テスト実装ウォータフォールモデルアジャイル的開発モデルリリースリリース リリース リリース半年、１年以上でリリース⼯程はほぼ同時で⾛り短期間でリリース要求分析設計実装テスト
https://www.industriallogic.com/blog/evolutionary-design/
アジャイル宣⾔アジャイルプロセスモデルアジャイルプラクティス原則(ルール)技術 価値 ・・・より良いソフトウェアの開発⽅法論を⽬指しているのがアジャイル宣⾔アジャイル宣⾔がより良くしようとしている分野は多岐に渡る
アジャイルプロセスモデルアジャイルプラクティス原則(ルール)技術 価値 ・・・アジャイルプロセスモデルよらず、適応可能なものもある
ΞδϟΠϧํ๏•91 F9UFBN 1SPHSBNJOH•εΫϥϜ•'%% ػೳۦಈܗ։ൃʣ•ΫϦελϧ•ϦʔϯιϑτΣΞ•Χϯόϯ•ϞμϯΞδϟΠϧ
91 F9SFBN 1SPHSBNJOH•ϓϩάϥϛϯάٕ๏ɺ໌֬ͳίϛϡχέʔγϣϯɺνʔϜϫʔΫͳͲΛΈʹར༻ͯ͠ɺΑΓྑ͘ιϑτΣΞΛ։ൃ͢Δ։ൃελΠϧ•ᐆດͰٸʹมԽ͢Δཁ݅ʹ͖߹͏தখنͷιϑτΣΞ։ൃνʔϜͷͨΊͷܰྔڃͷํ๏
Ձ•ίϛϡχέʔγϣϯ•γϯϓϦγςΟ•ϑΟʔυόοΫ•༐ؾ•ϦεϖΫτ
ݪଇ•ਓؒੑ•ܦࡁੑ•૬ޓརӹ•ࣗݾ૬ࣅੑ•վળ•ଟ༷ੑ•;Γ͔͑Γ•ྲྀΕ•ػձ•ੑ•ࣦഊ•࣭•ϕΠϏʔεςοϓ•ͷҾ͖ड͚
ओཁͳϓϥΫςΟε•શһಉ੮•νʔϜશମ•ใຬࡌͷϫʔΫεϖʔε•͍͖͍͖ͱͨ͠ࣄ•ϖΞϓϩάϥϛϯά•ετʔϦʔ• ि࣍αΠΫϧ• ࢛ظαΠΫϧ• ΏͱΓ• ̍̌Ϗϧυ• ܧଓతΠϯςάϨʔγϣϯ• ςετϑΝʔετϓϩάϥϛϯά• ΠϯΫϦϝϯλϧͳઃܭ
εΫϥϜͱ•ෳࡶͰมԽͷܹ͍͠ʹରԠ͢ΔͨΊͷϓϩδΣΫτͷਐΊํͷϑϨʔϜϫʔΫ•ՄೳͳݶΓՁ ͷߴ͍ϓϩμΫτΛੜ࢈త͔ͭతʹಧ͚Δ͜ͱΛతͱ͍ͯ͠Δ
εΫϥϜͷཧ•ಁաੑ•ݕࠪ•దԠ
ಁաੑ•ࢀՃऀશһ͕ڞ௨ೝࣝΛ࣋ͭ͜ͱྫɿwϓϩηεͷ༻ޠΛࢀՃऀશһͰڞ༗͍ͯ͠Δɻw࡞ۀͷʮʯͷఆٛΛڞ༗͍ͯ͠Δɻ
ݕࠪ•࡞εϓϦϯτΰʔϧͷਐḿΛසൟʹݕࠪ͠ɺ·͘͠ͳ͍มԽΛݕ͢Δ•ݕࠪΛසൟʹߦ͍࡞ۀΛ͛ͳ͍Α͏ʹ͢Δ
దԠ•ϓϩμΫτΛड͚ೖΕΒΕͳ͍ͱݕࠪ୲ऀ͕அͨ͠߹ɺϓϩηεͦͷߏཁૉΛௐ͢Δ•ௐͰ͖Δ͚ͩૣ͘ߦ͏
εΫϥϜνʔϜ•ϓϩμΫτΦʔφʔ•։ൃνʔϜ•εΫϥϜϚελʔ
εΫϥϜΠϕϯτ•εϓϦϯτϓϥϯχϯά•σΠϦʔεΫϥϜ•εϓϦϯτϨϏϡʔ•εϓϦϯτϨτϩεϖΫςΟϒ
プロダクトバックログスプリントバックログスプリントプランニング開発スプリントレビューデイリースクラムスプリントレトロスペクティブ
ΞδϟΠϧ։ൃͰͷςετҐஔ͚•ΞδϟΠϧͰͷςετʹϑΟʔυόοΫΛಘΔͱ͍͏త͕͋Δ• ࣗୡ͕࡞͍ͬͯΔͷͷํੑ͍͋ͬͯΔ͔• ࡞ͬͨͷҙਤ௨Γಈ࡞͢Δ͔• ఆ֎ͷ͜ͱى͖ͳ͍͔•ಈ͘ιϑτΣΞͱ࣮ͯ͠ࡍʹݟͯϑΟʔυόοΫ͕ಘΒΕΔ
հ͢Δ͜ͱ•සൟͳίϛϡχέʔγϣϯ•खΓΛݮΒͨ͢Ίͷෳਓಉ࣌࡞ۀ•ςετϑΝʔετΞϓϩʔν•ࣗಈͱखಈͰͷςετͷ͚۠•ܧଓతΠϯςάϨʔγϣϯ•ΠςϨʔγϣϯͱςετܭը
සൟͳίϛϡχέʔγϣϯ•ੵۃతͳൃݴ• ΠςϨʔγϣϯΛ௨ͯ͠ͷεςʔΫϗϧμʔνʔϜϝϯόͱੵۃతʹର• ༷ʹର͢Δ࣭؍Ͱͷҙݟ• ෆेͳςετϕʔεʹରԠ͢ΔͨΊͷೝࣝ߹Θͤ• վળͷఏҊ• ٙݒ೦ૣΊʹฉ͘• ΠςϨʔγϣϯظؒʹґΔ͕࣌ؒͰϩε͕େ͖͍
ϖΞϓϩάϥϛϯάhttps://ja.wikipedia.org/wiki/ペアプログラミングDriverNavigator
Ϟϒϓϩάϥϛϯάhttps://ja.wikipedia.org/wiki/Mob_programmingNavigatorDriver
खΓΛݮΒͨ͢Ίͷෳਓಉ࣌࡞ۀ作業 レビュー作業レビュー時間フィードバックが遅れると⼿戻りが多くなりムダな作業が多くなる
ෳਓಉ࣌࡞ۀͰͷςετ• /BWJHBUPSͰ։ൃऀͷಉ࣌ฒߦϨϏϡʔ• ςετ؍• ࣭؍• ͦͷଞɺΑΓྑ͍ΞΠσΞ• ෳਓಉ࣌Ͱͷςετ࡞ۀ• ςετܭը• ςετઃܭɺςετੳ• ϋΠϨϕϧςετέʔεΛϕʔεͱͨ͠ςετ࣮ߦ• ୳ࡧతςετ
ςετϑΝʔετΞϓϩʔν•ϓϩάϥϜΛ։ൃ͢ΔલʹςετઃܭΛߦ͏• 5%%ʢςετۦಈ։ൃʣ• #%%ʢৼΔ͍ۦಈ։ൃʣ• ड͚ೖΕςετۦಈ։ൃ• ϢʔβετʔϦʔ•࡞ۀͷୡ͢Δ͖ඪͷ໌֬Խ• είʔϓ• ࡞ۀΰʔϧ
ड͚ೖΕج४ͷ໌֬Խ•͍ΠςϨʔγϣϯͰͷΰʔϧΛ໌֬Խ͢Δ• ࣮͖͢ػೳͷ֬ೝ• ݱΠςϨʔγϣϯͰ࣮͠ͳ͍ػೳͷ֬ೝ• ୡ͢Δ͖ඇػೳཁ݅•͜ΕΒͯ͢ςετέʔεͱඥ͘͜ͱʹͳΔ
ඇςετϑΝʔετΞϓϩʔνͱςετϑΝʔετΞϓϩʔν開発 テスト設計 テスト実⾏テスト設計 開発 テスト実⾏テストが通るように開発を⾏う時間テスト設計で開発していた内容の間違いに気が付くことがある
͍αΠΫϧͰͷςετϑΝʔετΞϓϩʔνテスト設計 開発 テスト実⾏時間テスト実⾏で失敗すると原因の特定を⾏わなれないけない対象となる範囲が広いと時間がかかる
https://en.wikipedia.org/wiki/Extreme_programming
http://www.agilemodeling.com/essays/costOfChange.htm
ࣗಈςετ•ΞδϟΠϧͰ܁Γฦ͠ૣ͘ϦϦʔε͢Δʹࣗಈςετ͕ඞཁʹͳΔ•ςετΛੵΈॏͶΔͱ͍͏ߟ͑ํ• ςετͷίʔυͱಉ͡Α͏ʹੵΈॏͶ͍ͯ͘• ࣭ͷѱ͍ςετΛੵΈॏͶͳ͍
ࣗಈςετͷׂ߹TestPyramidhttps://martinfowler.com/bliki/TestPyramid.html
https://lisacrispin.com/2011/11/08/using-the-agile-testing-quadrants/
୳ࡧతςετテスト設計テスト実⾏学習フィードバック
୳ࡧతςετ•ࣝΛ࣋ͬͨςελʔ͕ߦ͏ख๏• ςετͷٕज़ࣝ• ϓϩμΫτͷࣝ•ςετνϟʔλΛ༻ҙͯ͠ςετઃܭɺςετ࣮ߦΛಉ࣌ʹߦ͏•ηογϣϯϕʔεͳ୳ࡧతςετͰ͖ͬͪΓ࣌ؒΛܾΊΔ•ΞυϗοΫςετʹͳΒ͍ͳ͍Α͏ʹҙ͢Δ
ܧଓతΠϯςάϨʔγϣϯ・静的解析・コンパイル・テスト実⾏・デプロイ・レポートの表⽰コードリポジトリソースコードのコミット結果の通知
ܧଓతΠϯςάϨʔγϣϯͰͷϑΟʔυόοΫ•ܧଓతΠϯςάϨʔγϣϯͰɺఆظతʹ੩తղੳɺϏϧυɺࣗಈςετͳͲ͕࣮ߦ͞ΕΔ•࣭͕ѱ͘ͳͬͨ͜ͱΛ։ൃऀʹૉૣ͘ϑΟʔυόοΫ͢Δ͜ͱ͕େ• ੩తղੳͷߴϨϕϧΞϥʔτͷ૿Ճ• ࣗಈςετͷࣦഊ•ܯࠂΛड৴ͯ͠ɺܯࠂΛ์ஔ͠ͳ͍͜ͱ͕େ
ׂΕ૭ཧ「建物の窓が壊れているのを放置すると、誰も注意を払っていないという象徴になり、やがて他の窓もまもなく全て壊される」という考え⽅https://ja.wikipedia.org/wiki/割れ窓理論継続的インテグレーションの静的解析やテスト実⾏失敗のアラートを無視し続けるとその状況は蔓延していく
スプリントΠςϨʔγϣϯͱςετܭըスプリントゼロ スプリントスプリント (リリーススプリント)
εϓϦϯτθϩ•࡞͢ΔγεςϜΛཧղ͢Δ•ϓϩμΫτͷϦϦʔεܭըΛ֬ೝͯ͠શମͷςετܭըΛߟ͑Δ•ϢʔβετʔϦʔͷଥੑΛ֬ೝ͢Δ•༻͢ΔπʔϧڥΛ४උ͢Δ•ϦεΫੳΛߦ͏
εϓϦϯτ•εϓϦϯτͰ࡞͠Α͏ͱ͍ͯ͠ΔͷͷςελϏϦςΟΛߟ͑Δ•εϓϦϯτͰͷςετܭըΛߦ͏•εϓϦϯτͰͷϦεΫੳΛ࣮ࢪ͢Δ•ςετ؍ɺ࣭؍Ͱͷҙݟग़͠Λߦ͏
εϓϦϯτΛ௨ͯ͠ͷςετ•શମΛ௨ͯ͠ͷςετܭըΛৗʹݟ͢•:"(/*Ͱ࣮ݱ͞Ε͍ͯͳ͍ͷΛ͍࣮ͭݱ͢Δ͔ߟ͑Δ˞:"(/*:PVBJObU HPOOB OFFEJUඇػೳཁ݅ͳͲޙճ͠ʹͳΓ͕͕ͪͩɺͲͷ͘Β͍ͷ࣌ظͷεϓϦϯτͰղܾ͖͢ͳͷ͔Λ໌֬ʹ͢Δ•ϦϦʔεલ·ͰʹΔ͖͜ͱΛݕ౼͢Δผ్ɺϦϦʔεεϓϦϯτΛઃ͚Δ͔ݕ౼͢Δ
ϫʔΫ
લఏ•ΞδϟΠϧʹܾ·ͬͨϓϩηε͋Γ·ͤΜɻ•ࣗͨͪͰࣗୡʹ͋ͬͨϓϩηεΛݟ͚ͭͯߦ͘͜ͱ͕େ
ৼΓฦΓϫʔΫ•ΞδϟΠϧએݴͱɺͷݪଇΛݩʹࣗͷۀͷΓํΛݟͯ͠ΈΑ͏•ͲΜͳখ͞ͳࣄͰ͍͍ͷͰɺվળΛݟ͚ͭΑ͏• ݸਓϫʔΫ • άϧʔϓڞ༗
/&95
%FW0QThttps://ja.wikipedia.org/wiki/DevOps
ϚΠΫϩαʔϏεΞʔΩςΫνϟhttps://microservices.io/
ࢀߟจݙ• 'PVOEBUJPO-FWFM&YUFOTJPOγϥόε ΞδϟΠϧςετ୲ऀIUUQKTURCKQEM+452#4ZMMBCVT'PVOEBUJPO"HJMF&[email protected]+QEG• ΞδϟΠϧιϑτΣΞ։ൃએݴIUUQTBHJMFNBOJGFTUPPSHJTPKBNBOJGFTUPIUNM• ΤΫετϦʔϜϓϩάϥϛϯάΦʔϜࣾ• εΫϥϜΨΠυIUUQTXXXTDSVNHVJEFTPSHEPDTTDSVNHVJEFW4DSVN(VJEF+BQBOFTFQEG
imtnd
ksudate
nsuz
ivargrimstad
yui_knk
skume
alli83
ffjlabo
maaretp
totokit4
twada
qualiarts
numeroanddev
bkeepers
eileencodes
paulrobertlloyd
brianwarren
myddelton
davidbonilla
chriscoyier
caitiem20
holman
jonyablonski
aarron
zenorocha