倉貫さんの資料プロエンジニアになるための「アジャイル開発」再入門が素晴らしいのでリンクしておく。 新入社員向けのアジャイル研修の資料は、これを使えば十分ではないかな、と思った。 以下はラフなメモ書き。 【研修資料】 【参考】 アジャイル開発とウォーターフォール型開発の違いについて再考: プログラマの思索 アジャイルとウォーターフォールは文化や価値観のレベルで異なるという話 - たなかこういちの開発ノート アジャイル開発の本質 ? アジャイルとウォーターフォールの違いとは | Social Change! ソフトウェアは完成しても価値はない ? アジャイル開発は何を解決するのか | Social Change! アジャイル開発とは：「アジャイル開発」をエグゼクティブサマリにまとめてみた | Social Change! ドキュメントをなくしてもうまくいく？ ? 人に依存するリスクへの対処とは
テストを小さくする。適切なツールを使う。プログラマとテストがペアになる。これらは、よいユニットテストを書くための、Adrian Bolboaca氏からの提案だ。 ユニットテストは、プログラミングとテストが混ざり合ったものだ。プログラマは、テスタと共に作業することで、お互いに学び合い、視野を広げることができる。 Adrian Bolboaca氏は、Mozaic Worksの組織と技術に関するコーチであり、ヨーロッパテストカンファレンス 2017において、様々なタイプの自動テストについて話す予定だ。 InfoQは、このカンファレンスについて、Q&A、要約、記事で扱う。 [ヨーロッパテストカンファレンス]は、専門家や実践者が一緒に話し、学び、テスト技術を実践するところです。 私たちは、テストをもっと効果的にするために、先進的な新しい方法を詳しく調べ、より強いコミュニティに成長する基本的な方法を十
Misoca開発チームの黒曜(@kokuyouwind)です。 先日大須演芸場で開催された名古屋Ruby会議03ではTwitterでひたすら実況していました。大喜利が思った以上に大喜利で面白かったです。 お題「みなさんRubocopになってもらって『直しました』といってください。『何を直したんですか？』と聞くので、直したところを答えてください」 須藤さん「直しました」「何を直したんですか？」「RSpecをTestUnitにしました」 #nagoyark03— 黒曜@技術書典2 か-13 (@kokuyouwind) 2017年2月11日 流しの技術フェローに教わったペアプロのコツ 先日、弊社技術フェローのkakutaniさん(@kakutani)からペアプログラミング(以下ペアプロ)のコツを教わり、社内でのペアプロ機運が高まっています。 今回はkakutaniさんから教わった内容のまとめと
その結果、自分はすっかり言及の減ってしまったリーンソフトウェア開発や、それらの源流であるトヨタの生産方式、トヨタが現在取り組んでいる自工程完結を評価するのがよいのではないかと思い至った。本稿は、そういうポエムである。 本稿でいうリーン（ソフトウェア）開発とは何か？ 2003年にメアリー・ポッペンディークとトム・ポッペンディークにより提唱されたトヨタ生産方式を源流とするリーン生産方式をソフトウェア開発に適用した原則集。以下を指す。 リーンソフトウエア開発～アジャイル開発を実践する22の方法～ リーン開発の本質 エリック・リース氏のリーンスタートアップやオライリーのリーンシリーズとは異なるので注意いただきたい。 きっかけとしてのアジャイル方法論の違和感：結局、アジャイルでも多くの課題が残る。 「今回のプロジェクトがやりにくいのはウォーターフォールでやっているからだ」、「今回のプロジェクトが適当
ポジション的なもの 個人的に、アジャイルは「（あんまり未来や遠くのことを考えるのをやめて）目の前にある問題を解決しよう」という思想と認識しています。 現実の問題を見ないで「将来、日本と米国のソフトウェア開発技術の差が広がるから、ウォーターフォールをやめてアジャイルをやろう」とか、何を言っているんだ、おまえは？ と、思います。 キーワード「エンタープライズ」が出てきているので、業務システムの話をします。 情けないぞアジャイルコーチ 私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い - メソッド屋のブログを読みました。 感想を書きます。 サム・グッケンハイマーの一言 サム・グッケンハイマーは、マイクロソフトが、アジャイル、そして DevOps 移行したことに関するソートリーダー の方が 「ウォータフォールは一切メリットがないので止めておきなさい」 といったそうです。まあ、ポジシ
私はソフトウェアの専門家としてお答えすると、ウォータフォールは何のメリットも無いというのが私の意見であることを共有しておきたい。そういう意見に至った経緯をこのブログで書き留めて置きたい。 尚、これは所属会社の見解ではないことは明確にしておきます。 サム・グッケンハイマーの一言 私は DevOpsのエバンジェリストで、それ以前からアジャイル開発をかれこれ１５年ぐらい実施し、導入の支援をしている。私はかつては、日本の環境の制約の中で如何にアジャイル開発のメリットを最大に引き出すか？ということを考えていた。 ウォーターフォールに対する立場も、真っ向から否定するものでもなく、現状もあるし、それに慣れている人もいるし、実際ウォーターフォールでも失敗しない人も居る。だから、人にウォータフォールのメリット・デメリットを聞かれた時も「変化しないものに関してはウォータフォールはいいのかもしれない」と回答して
アジャイル開発の基礎的な知識を問う「アジャイルソフトウェア開発技術者検定試験（アジャイル検定）」が2015年9月に始まった（画面1）。日立製作所や東京海上日動システムズなど9社が集う試験母体である「アジャイルソフトウェア開発技術者検定試験コンソーシアム」は早期に1万人まで合格者を増やしたい考えだ。 ユーザー側として参加した東京海上日動システムズのシステム開発本部長を務める大内美樹エグゼクティブオフィサーは「まずはしっかりとしたアジャイル開発を広めたいという気持ちがあり、そのためにはアジャイル開発の基本がわかる技術者を増やす必要があった」とアジャイル検定の意義を話す。 専門書2~3冊を読み込んだ知識レベルで合格 アジャイル検定はアジャイル開発のスキルを客観的な尺度で分析・判定する。基本的な知識を問うレベル1と、アジャイル開発の具体的な開発手法を問うレベル2の2階建ての試験となる。現時点ではレ
2001年、17人のメンバーによって アジャイル宣言 が発表されました。私はその立案者そして著者の1人であることに誇りを感じます。この出来事は、何かをする上でより良い方法を導き出すことへの期待、そしてソフトウェアを開発することで世界をより良くするといった、私自身の活力の源となり、極めて重要なターニング・ポイントとなりました。 あれから14年が経ち、私たちは行き先を見失っています。”アジャイル”という言葉はスローガン化してしまいました。本来の意味をなさなくなっただけならまだいいですが、最悪に考えれば排外的な存在になってしまったとすら言えます。2～3のソフトウェア開発のプラクティスを、不十分に生半可に試みるといった”軟弱なアジャイル”を行う人が数多く存在します。本来の目的を忘れて努力を重ねるといった、口先だけのアジャイルの 狂信者 がたくさんいるのです。 更にひどいのは、アジャイル開発手法その
1.全体スケジュールにコミットできない アジャイルはタイムボックス型（一定期間で棚卸しをして、それを繰り返す）のマネジメントをする。だから、全体としての計画は立てられない。「だって、最初に全ての機能を洗い出せないでしょ」というのは分かる、分かるけど全体の計画は立てないといけない。経営者は顧客やVCと全体の計画にコミットしなきゃいけないんだ。そのときに「やってみなきゃ分からない」なんて言えるわけでない。 てか「やってみなきゃ分からない」なんてことは誰でも知っているんだよ。でもさ、それを言わぬが花。大人なんだからコミットメントをしないといけないんだよ。そして、その達成ためには、あらゆる手段を尽くすのです。 2.アーキテクチャ上の無駄が生じる ソフトウェアの構造や構成は工程が進むほどに修正しにくくなり、ずっと残る。だから、アーキテクチャ設計は慎重に全体を考えながらやらなきゃいけない。でも、アジャ
関さんを囲む会Sapporo RubyKaigi 2012 のちょっと前に囲む機会があったのでいってきました。 なにもメモしていなかったのだけどさっきツイートをみて思い出せる限り書いてみました。だいぶ記憶がフワフワ 何か間違っていることとかあれとかあればご指摘ください!! はじめてのせきさん 意外と声が低い 意外とよく笑う 無表情でぽつぽつ喋るイメージだった(Twitterのアイコンのまま) アイスブレイク 生まれた都道府県の絵とポイントを描いて自己紹介 もういっちょアイスブレイクみたいなの 一日の生活リズムを円グラフで 無職だからだいぶひどいの書いた やむをえず正直に！ 生活リズムからせきさんへの質問タイムへしまださんが主に質問していた。 印象に残っていることを書きます。 懇親会も含めてかも？ 順番もおぼえてない 関さんはプロの無職をしている みんなの様子をみて手助けしてまわるひと 朝会
2年目の新人が去年1年間を振り返りつつ今年の新人にアドバイスする、という勉強会を社内でやっていて、拙いながらもそこで発表してきました。 いくつかアドバイスしたことがあるのですが、社内の機密情報なども含まれるので、一部だけ取り出してブログ用に書き直したいと思います。 今日のテーマは、タイトルにもあるとおり『タスクの書き方』です。 タスクを書くときに「○○をする。□□ができたらオッケー」という終了条件や、「○○をする。ただし△△になったら不要」という却下条件を書くと、タスクの選択や確認、棚卸しが捗るという話です。 大量のタスクがあると良く分からなくなる 仕事をしていると、次から次にやりたいことが沸いてきて、頭の中だけで整理するのは難しくなってきます。大抵の人は、やりたいことを紙にリストアップしたり、webサービスなどで管理したりすると思います。 しかし、何も考えずにタスクを追加していくと次のよ
プログラマ1人で完成できる仕事に、2人のプログラマを投入して、直感的に判断してペアプログラミングを拒否する人がいます。これには大きな間違いとリスクが潜んでいます。ペアプログラミングに対する真実を理解しましょう。 ペアプログラミングはコードを書く時間が15％増える 1999年にユタ大学でおこなわれた実験によれば、設計の時間を別にして、ソロプログラミングに対してペアプログラミングを実施したペアは平均して15％多く、プログラムを書く時間に費やしました。 では、なぜペアプログラミングを選択するのか？ 将来的なテストと現場のリソース要求を減少させるためです。一般的なシステムにバグが見つかると業界のデータでは、33時間から88時間を修正に費やすそうです。これが、開発期間中に欠陥を修正すると0.5時間から88時間の時間を節約できることになるのです。したがって、ペアプログラミングは寿命の長いソフトウェアほ
■1 『アジャイルサムライ』の書影と主な目次が出てこないから自分で貼るよ あわせて読みたい: 「アジャイル開発のディケイドと"The Agile Samurai"」 6/30正午付近に脱稿したら7/1に印刷入稿されたので(青焼の確認がまだあるけど)、いよいよひと区切り。このまま大きな事故がなければ、RubyKaigi 2011の頃には書店に並ぶはず(前日が書店搬入日の予定)。RubyKaigi初日が正式発売日なるスケジュールでオーム社開発局をはじめとした関係各社の総力戦である(RubyKaigi2011会場で先行発売とかそんなリードタイムではないのだ!!)。 でも残念ながら、すてきな三にんぐみのRails3についての素晴しい書籍と違ってまだAmazon.co.jpにレコードはない。版元のサイトにはエントリはあるけど書影もないし目次も企画書段階のときのまま。オーム社eStore(β)にも商品
この団体の役人体質は特筆すべきモノがあります。いや、感動的ですらある。 「アジャイル開発向け契約モデル」実証実験参加企業の募集 おかしいと思って読み違えないように何度か読んだんです。 でも、僕の理解が間違っていなければこういうことを言っています。 平成22年度に非ウオーターフォール型開発WG報告書を作ったよ。 コンセプトは固まったから、実際にフィールドワークをやりたいと思うんだ。 というわけで、僕らのモデルを理解してフィールドワークに参加してくれる企業を一般公募するよ。ユーザー企業がいいな、やっぱ。ベンダーじゃ説得力に欠けるしね。ユーザーにメリットがあることを実証したいからさ。 プロジェクトの契約方針・進め方は僕らIPAモデルに準拠して貰う。プロジェクト開始後のことは知らんよ。ベンダーは望めば紹介するけどコイツらがコケても知らないし、プロジェクトの成否は責任とれないし、もちろんカネはびた一
情報処理推進機構（IPA）のソフトウェア・エンジニアリング・センター（SEC）は2011年4月7日、アジャイル型開発プロジェクトをITベンダーに発注する際の契約書のひな型を公開した。「アジャイル開発に注目が集まるものの採用が進まない障壁の一つが、適した契約書のひな型がなかったこと。日本の大手ベンダーでも策定していなかった」（IPA/SECの山下博之 エンタプライズ系プロジェクトプロジェクトリーダー）。アジャイル開発は1週間から1カ月といった期間での開発（イテレーション）を繰り返しシステムを完成させる手法。 契約書は2種類ある。一つは「基本/個別契約モデル」と呼ぶもの。プロジェクト全体で開発を委託する基本契約を締結した後、イテレーションごとに個別の契約を結ぶモデルである。基本契約は法的拘束力はなく、個別契約に共通する事項を定める。個別契約はイテレーションで開発する機能が定まっていない場合は準
ここでは、PF=Project Facilitation(プロジェクトファシリテーション)について議論しています。 プロジェクトを活性化し、楽しくプロジェクトを成功に導くための、実践的な課題を扱います。 プロジェクトの成功に大切なものはなんでしょうか？ 個々人のスキルは重要です。そして、ここで取り上げるのは、集まった個人のスキルを１００％以上に発揮させるチーム作りとしての、「プロジェクトファシリテーション（PF）」です。 プロジェクトマネジメント（PM）が重要であることは昨今強く言われています。 PMが「計画達成のマネジメント」に重点を置くのに対してPFは「参加者の協調の場作り」に重点を置いています。PMは、計画の立案と実行、差異に注目した管理が中心で、どちらかと言うと「コマンド･コントロール型」のマネジメントスタイルが背後にあります。これに対してPFは、その場その場の変化に対応し、チーム
アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください（初回相談無料） みなさんこんにちは。@ryuzeeです。 今日は完成の定義について説明しようと思います。 完成の定義って何？チームとして定めた「出荷可能な製品」を作成するために実施しなければいけないことの一覧です。 例えば、コードを書く、ユニットテストする、統合テストをする、リリースノートを書く、などがそれにあたります。 プロダクトバックログアイテム単位での完成の定義、スプリント単位での完成の定義、リリース単位での完成の定義をすることもあります。 完成の定義はチームの成熟度や時間によって変わっていきますが、完成の定義なくしてのScrumはあり得ません。 詳しくはScrum Allianceの記事も参照してみてください。 また、あわせてHow
■1 第11回すくすくスクラム――ユーザーストーリービギンズナイトで講演してきました。 講演といってもワークショップ形式なので、あまりしゃべってないですけれども。 2時間という長時間でしたが、原メソッドのおかげでピッタリ時間通りに終わりました。ご参加いただいたみなさん、ust参加者のみなさん、スタッフのみなさん、どうもありがとうございました。 今回は、ワークショップへの参加者として思ってたことを2つ実践してみました。 （参加者同士の）自己紹介なんて必要なくね？ 模造紙って非日常的だから使えなくね？ もちろん異論はあるでしょうけれど。 ustの録画は以下。 ちゃんとした録画は、このへんにアップされるんじゃないかなあ。 http://www.microsoft.com/japan/powerpro/developer/agile/community/suc3rum.mspx 資料も、いずれこの
私たちはソフトウェア開発を実践あるいは実践の手助けをする ことによって、よりよい開発方法を見つけだそうとしている。 この活動を通して、私たちは以下の価値に至った。 プロセスとツールよりも個人と対話に。 包括的なドキュメントよりも動くソフトウェアに。 契約交渉よりも顧客との協調に。 計画に従うことよりも変化への対応に。 すなわち、左側に書かれたことがらに価値をおきながらも、 私たちは右側に書かれたことがらにより価値をおく。 Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く