アジャイル開発は工事進行基準と相性が良いという仮説について考えたことをメモ。 【元ネタ】 Twitter / z200: スクラムを例に取ると、リリース（および検収）と売上・請求フローを組み合わせることは可能かと。開発で試したことはありませんが、制作現場では有効でした。 RT @akipii: そういう考え方もあるのか RT @z200: アジャイル開発は、工事進行基準との相性も良さそうだな。 【続報】ソフトウェア開発の売上げ計上タイミング：むささびの視線：ITmedia オルタナティブ・ブログ ソフトウェア開発の売上げ計上タイミング：むささびの視線：ITmedia オルタナティブ・ブログ 販売管理～売上の計上時期（売上計上基準） 【1】ソフトウェアの受託案件が一括請負契約の場合、例えば1年間頑張って作った後、ユーザの受入検収が完了して初めて売上計上されるのが普通。 作って納品しておしまい

IT業界で働く技術者は営業マンでないのに、コミュニケーション能力が必要とよく言われる。 特に、プログラマのプログラミング能力が優れていても、実力を発揮できないとき、君はコミュニケーション能力が足りない、とよく言われる。 その理由について考えたことをラフなメモ書き。 【1】営業マンにコミュニケーション能力が必要と言われるのは、初対面の顧客へモノを売りつける必要があるから。 いかに信頼して買ってもらえるか、人間関係の構築作りに力を入れる。 だが、IT技術者に必要とされるコミュニケーション能力は、営業マンのそれとは全く違うと経験的に思う。 自分よりも上位職の人へ働きかける政治力をすごく要求されるのだ。 特にプロジェクトリーダー、そしてプロジェクトマネージャのように上位の管理職になるほど、自分よりも上位職の力を借りて組織を動かす能力が必要とされる。 以下、どんな状況でそのようなコミュニケーション能

小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le

先週、アジャイルサムライ読書会に行ってきた。 スタッフ並びに勉強会の皆様、ありがとうございました。 考えたことをメモ書き。 【元ネタ】 アジャイルサムライ読書会(湯島道場) 第三回 火の巻に参加してきた #agilesamurai #湯島道場 - Shinya’s Dairy Report ReadingAgileSamuraiInYushima - GitHub Twitter / @ryuzee: 道場破り？の@akipiiさんがいますけどねｗ RT @haradakiro: 道場破りとかこないとヒマなのですね。RT @ryuzee: 用心棒だから黙ってるよ！ #agilesamurai #湯島道場 Twitter / @kakutani: 読書会が盛り上っているなあという感じがよく伝わる / アジャイルサムライ読書会(湯島道場) 第三回 火の巻に参加してきた #agilesamura

タックマンモデル、プロジェクトファシリテーション、PMBOKの人的資源マネジメント、内外製分析についてメモ。 ラフなメモ書き。 【元ネタ】 Educate.co.jp | タックマンモデル 新たな習慣へのトライ　 タックマンモデルを体感する 何故ファシリテーションが流行しているのか？: プログラマの思索 【PFP関西】段取りと仕切りのフレームワーク: プログラマの思索 現場リーダーの一つ上の役職であるプロマネの仕事を見ていると、二つの特徴がある。 それはチーム編成の技術と内外製分析。 チーム編成という技術は現場リーダーの仕事だが、プロマネは体制づくりという重要な仕事がある。 つまり、ITプロジェクトにどのような人員が必要なのか、プロジェクトの期間に応じてどれだけの人数が必要か、という計画を立てる。 PMBOKで頻出する資源カレンダーは月別の工数グラフであり、プロマネは、資源カレンダーに従っ

「アジャイル開発でよく言われるソフトウェアかんばんとは、仕掛けかんばんなのか？　引き取りかんばんなのか？」という質問を聞いたので、改めて調べてみた。 完全に理解できてないので、情報だけ集めておく。 【元ネタ】 InfoQ: 「かんばん」をソフトウェア開発に適用する: アジャイルからリーンへ カンバン - Wikipedia 教えて！Ziddyちゃん - 生産管理について2点 かんばん生産入門 　第1回 かんばん（狭義） | J I T基本用語集 仕掛けかんばん | J I T基本用語集 引き取りかんばん | J I T基本用語集 飲食店に学ぶ生産管理トップページ InfoQ: 「かんばん」をソフトウェア開発に適用する: アジャイルからリーンへの記事のように、平鍋さんはソフトウェアかんばんに、トヨタ式生産方式(TPS)にある仕掛けかんばんと引き取りかんばんのアイデアを注入しようと試されている

小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le

牛尾さんがCodeZineに、アジャイル開発の運用のハードルが何故高いのか、優れた記事を立て続けに書かれているのでリンクしておく。 牛尾さんのように、実際のAgileな開発だけでなくシステム化提案や要件定義のAgile化など、下流工程から上流工程まで全てで経験し尽くしている人だからこそ、分かっているような内容ばかりでとても興味深い。 【元ネタ】 ウォーターフォールの次に行け！～日本のソフトウェア開発を今一度洗濯いたし申し候（1/2）:企業のIT・経営・ビジネスをつなぐ情報サイト EnterpriseZine (EZ) なぜアジャイルは本のとおりに実践しても失敗するのか？（1/4）:企業のIT・経営・ビジネスをつなぐ情報サイト EnterpriseZine (EZ) なぜアジャイルは本のとおりに実践しても失敗するのか？（4/4）:企業のIT・経営・ビジネスをつなぐ情報サイト Enterpri

Agile2.0時代のAgile開発が目指す方向を示唆する書籍を2冊あげておく。 「アジャイル開発の本質とスケールアップ 変化に強い大規模開発を成功させる14のベストプラクティス」と「実践アジャイルテスト テスターとアジャイルチームのための実践ガイド」の2冊は、今後Agile開発を実践しようとする開発者にとって必須の書籍だと思う。 初期のAgile開発は、XPのように少人数のチームが小規模案件でAgilityを活かして開発するスタイルが主流だった。 それらの開発スタイルから、XPの優れたプラクティスであるテスト駆動開発、継続的インテグレーション、小規模リリースなどが発見された。 しかし、初期のAgile開発では、その事例の規模が小さいために、「アジャイル開発はスケールアップが難しい」「アーキテクチャや品質の作り込みの考慮が足りない」などの弱点を指摘され続けてきた。 Agile2.0時代のA

第42回　SEA関西プロセス分科会に行って、松原友夫さんのセーフウェア、岸田さんのソフトウェア開発における美学原理の講演を聞いてきた。 感想をメモ。 【元ネタ】 第42回　SEA関西プロセス分科会のご案内 【告知】第42回SEA関西プロセス分科会「セーフウェア～システム安全とコンピュータ」: プログラマの思索 松原友夫さんは日立に長く勤められて、品質管理やソフトウェア工学を1960年代からずっと研究されている。 2005年のSEA関西の講演でも聞いたことがあり、それ以来尊敬している。 講演では声が小さくて聞き取りにくい部分もあったけれど、メモしながら色々考える所があった。 セーフウェアとは、システム安全には組織的な取り組みが必要であることを意味する著者ナンシーの造語であり、今回出版のタイトルでもある。 セーフウェアの本「セーフウェア 安全・安心なシステムとソフトウェアを目指して (IT A

TestLinkでテスト管理をしてみた経験、他の人から聞いた話から、TestLinkを運用したけど使いこなせない症状にパターンがあるような気がした。 それらをアンチパターンとしてまとめてみた。 【元ネタ】 TestLinkがExcelのテスト仕様書よりも素晴らしい点 TestLinkを運用して気付いたことpart4～TestLinkの概念を再考 TestLinkを運用して気付いたことpart5～TestLinkのテストケースの概念 TestLinkを運用して気付いたことpart6～テスト工程のプロジェクト管理 TestLinkを運用して気付いたことpart7～要件カバレッジは難しい TestLinkを運用して気付いたことpart8～みなしバグ、ブロッキングバグ、周辺テスト、そしてクリティカルパス TestLinkを運用して気付いたことpart9～後追いテスト 【公開】脱Excel！ Tes

Redmine.JP | Redmine on Twitterで、OpenPNE3が何故Trac＋SVNからRedmine＋Gitへ変更したのか、その理由と運用例が書かれていたのでメモ。 内容がとても素晴らしいので、共有する為に書く。 #下記は僕の想像の部分も含む。 【元ネタ】 【提案】OpenPNE3 の BTS と SCM を Trac + SVN から Redmine + Git に変更する ([Suggestion] Switch the BTS and the SCM that are used for OpenPNE3, from Trac + SVN to Redmine + Git) - openpne-dev | Google グループ OpenPNE 3 - Ticket Workflow (ja) - OpenPNE Issue Tracking System Ope

アジャイル開発の本質はどこにあるのか？を考えてみた。 ラフなメモ書き。 アジャイル開発の特徴は一体何があるか？ それはタイムボックス形式で小刻みにリリースすること。 それは小規模リリース。 それは設計と開発に区別がないこと。 それは人を重視したプロセス。 それはリーン開発である。 それはテスト駆動開発である。 それは変化を受け入れるプロセスである。 色々言われているけど、本質は何だろうか？ 僕は「頻繁にリリースできること」だと思っている。 技術・マネジメント・環境の3つの観点で考えてみた。 【技術】 以前に比べると、「頻繁にリリースできる技術」は確実に進歩している。 XPが生み出した継続的インテグレーション(CI)はその最たるものだ。 CIの本質は、常時リリース可能なコードラインを保持出来る点にある。 trunkをHudsonでワンクリックすれば、すぐにビルド＆デプロイできるのだ。 Cob

アジャイル開発のFAQについてメモ。 【1】アジャイル開発のような繰り返し型開発は、作業やリソースの重複が多くて生産性が低いのではないですか？ 【回答】最初のイテレーションは試行錯誤しがちですが、イテレーションをこなすたびに慣れていき、生産性は上がっています。 特にSW開発は常に新技術を取り入れているので、開発者の学習曲線を考慮する必要があります。 アジャイル開発では、開発者の成長を意識的に支援するプラクティスが含まれています。 例えば、イテレーション毎にふりかえりMTを開いてプロセス改善する意識を開発者に植え付けますし、ペアプログラミングで開発者と技術や設計思想を共有するプラクティスもあります。 特に、プロジェクトファシリテーションでは、開発者の成長を促進するプラクティスが多々あるので参考にしてみてはいかがでしょうか？ 【2】開発を繰り返すから、コストが高いのでは？ 【回答】最初のイテレ