ICSE2012勉強会 岡山県立大学 天嵜 聡介 What Make Long Term Contributors: Willingness and Opportunity in OSS Community Minghui Zhou1 and Audris Mockus 2 Peking University1 Avaya Labs Research 2 動機・目的 OSS Community 新規の貢献者が長期に渡って 貢献するようになる条件は何か? Willingness (Attitude), Capability ( ability ) どのぐらい積極的にプロジェクトにかかわったか どのぐらいプロジェクトに貢献したか Core Opportunity (Environment) コミュニティ内でどのように扱われたか 参加時のプロジェクトの状況はどうだったか Peripheral 主要な貢献 • Willingnessとopportunityを定量的に定義した • Willingnessやopportunityが長期contributor になるかどうかの要因である可能性を示した Case Study • 対象プロジェクト – Gnome ( 2000 Jan – 2011 Jan) – Mozilla ( 1999 Jan – 2011 Jan) • 定量化の方針 – Willingness • 参加タスクの種類と数,およびそのタスク解決に費やした労力で計測できる – Opportunity • すべての貢献者が同じ影響を受ける要因 ( Macro Climate ) • 個々の貢献者によって影響が異なる要因 ( Micro Climate ) • 評価方法 – ロジスティック回帰モデルを用いて,要因毎のオッズ比を比較する Willingness, Opportunityの定量化 M. Zhou, A. Mockus, “What Make Long Term Contributors: Willingness and Opportunity in OSS Community, ICSE2012. より抜粋 評価結果 • 全ての因子が有意 (p < .001) – MozillaにおけるRSは除く • Willingness の方がより強い影響力があった 同じ環境下であれば、Willingnessが長期contributorになるかを決める 主要な要因である 異なる環境下であれば、Opportunityが長期contributorになるかを決め る主要な要因となるかもしれない Ambient Awareness of Build Status in Collocated Software Teams J. Downs1, B. Plimmer2, and J. G. Hosking3 The University of Melbourne1 The University of Auckland2 Australian National University3 Ambient Awareness System ビルド 失敗! Build server ビルド失敗 チームやビルドの品質にどのような影響を及ぼすのか? 主要な貢献 • Ambient awareness system の効果を実証的 に比較評価した • Ambient awareness system の影響を定量的 メトリクスによって測定した 比較対象: Prototype 1 ビルド 失敗! Build server ビルド失敗 比較対象: Prototype 2 ビルド 失敗! Build server ビルド失敗 ビルド失敗 ビルド失敗 比較対象: Prototype 3 ビルド ビルド 成功! 失敗! Build server ビルド失敗 ビルド成功 ビルド失敗 ビルド成功 ビルド失敗 ビルド成功 実験結果 定量的な変化が観察できた • • • • • 1日あたりのbuild回数が増えた ユニットテストの失敗によるbroken buildの数が減少した Broken buildが修正されるまでの期間が短縮した Broken buildの発生回数に変化はなかった Broken buildをcommitした人が修正した割合は増加しなかった 被験者の反応はよかった • 個人向けのambient awareness systemは好評だった • 全体向けのものについては賛否両論であった Ambient awareness system はビルド状態の認識には有用だったが、 必ずしもビルド修復の改善にはつながっていなかった Disengagement in Pair Programming: Does It Matter? L. Plonka, H. Sharp, and J. van der Linden The Open University 動機・目的 Pair Programming • 二人がパートナーとなってプログラミングに取り組む • 協力して1つの仕事を解決しようとする • 熟練者から新人へのknowledge transferのために行われることがある Disengagement • タスクの解決に集中しない • 問題を理解しようとしない • パートナーと協力して仕事をしようとしない ペアプログラミングにおいて 開発者が disengagement 状態に陥る 原因およびその解決策はどのようなものか? 主要な貢献 • ペアプログラミングにおける開発者の振る舞 いに着目した – 従来はペアプログラミングの効果に焦点 • Disengagementの原因を明らかにした 実験および分析 • データ収集の方法 1. 質問票 2. ペアプログラミングをビデオ撮影・録音 • 31人の開発者, 21セッション 3. インタビュー • 分析 1. Disengagement のエピソードを識別 2. Disengagement に至る状況の調査 3. Disengagement 回避の方法の調査 Disengagement の原因 • 他の作業者からの割り込み • パートナーとの連携が妨げられる • 専門に応じた分業 • 排他的なサブタスクに役割分担してしまう • 簡単なタスク • 同僚からの圧力 • 新人は熟練者に簡単なことは聞きにくい • 時間的な圧力 • 熟練者が一人で仕事を進めてしまう Development of Auxiliary Functions: Should You Be Agile? An Empirical Assessment of Pair Programming and Test-First Programming O. A. L. Lemos1, F. C. Ferrari2 , F. F. Silveira1, and A. Garcia3 Federal University of Sao Paulo1 Federal University of Sao Carlos2 Pontifical Catholic University of Rio de Janeiro3 動機・目的 crush function Auxiliary function experienced Auxiliary function Less experienced Agile Practice • Pair programming • Test First Development time-to-marketに影響を与えずreliabilityを改善できるか? 主要な貢献 • 補助的な関数の開発におけるアジャイル的な 取り組みの影響を明らかにした • アジャイル的な取り組みの影響について 一貫性のある結果を示した – Cross over designの採用 Cross Over Design Pair Programming Solo Programming Test First Test Last 被験者群 A 被験者群 B 被験者群 B 被験者群 A 実験結果 • Pair Programming – バグ減少 – 開発時間 増加 • Test First Development – バグ減少,カバレッジ向上 – 開発時間 増加 Agile Practiceの採用は,reliability の向上に寄与するが 開発に時間がかかるため,time-to-market は悪化
© Copyright 2024 ExpyDoc