ウクライナ軍に入隊したアジャイルコーチが、さまざまなメソッドを駆使して中隊長としてのリーダーシップを実現した話（前編）
ウクライナ軍に入隊したアジャイルコーチが、さまざまなメソッドを駆使して中隊長としてのリーダーシップを実現した話（前編） アジャイル開発の代表的な方法論であるスクラムをテーマに、都内で1月に開催されたイベント「Regional Scrum Gathering Tokyo 2024」で、経験豊富なアジャイル開発のエキスパートとしてウクライナを拠点にアジャイルコンサルタントをしていたドミトロ・ヤーマク（Dmytro Yarmak）氏が、ロシア軍の侵攻後にウクライナ軍に入隊し、中隊長としてリーダーシップを発揮するためにさまざまなメソッドを駆使して軍隊の組織を変革していった経験を語ったセッション「A True Story of Agile Coaching in Ukrainian Armed Forces」が行われました。 軍隊という、企業とは異なる構造や目的を備えた組織で、しかも多くの民間人が入
アジャイルと契約 / Agile Contracts
忙しい人向けダイジェストをこちらに用意しました。 https://www.agile-studio.jp/post/agile-contracts
140年の歴史を持つ日本経済新聞社が、日経電子版アプリで内製化とアジャイル開発に挑戦した理由と現実、そして課題とは（後編）
140年の歴史を持つ日本経済新聞社が、日経電子版アプリで内製化とアジャイル開発に挑戦した理由と現実、そして課題とは（後編） 1月12日と13日に行われたスクラムのイベント「Regional SCRUM GATHERING Tokyo 2017」では、日本経済新聞社でモバイルアプリケーションの開発チームを担当する武市大志が登壇。内製化やアジャイル開発を実現するために改革と改善を繰り返してきた背景と事情を詳しく解説してくれました。 本記事はその講演内容をダイジェストで紹介します。 （本記事は「140年の歴史を持つ日本経済新聞社が、日経電子版アプリで内製化とアジャイル開発に挑戦した理由と現実、そして課題とは（前編）」の続きです） バケツを大きくするためにリニューアル 次は、バケツを大きくしましょう。という話です。 なにをしたかというと、日経電子版のアプリを全面リニューアルしました。 2015年4
140年の歴史を持つ日本経済新聞社が、日経電子版アプリで内製化とアジャイル開発に挑戦した理由と現実、そして課題とは（前編）
140年の歴史を持つ日本経済新聞社が、日経電子版アプリで内製化とアジャイル開発に挑戦した理由と現実、そして課題とは（前編） 日本を代表する新聞社のひとつである日本経済新聞社は、スマートフォンから記事を読むことができる日経電子版を提供しています。そしてこのスマートフォンアプリ開発において、同社は内製化とアジャイル開発による迅速なリリース体制を実現しました。 講演者自身が「古い体質」と説明する企業で、それまで外注によって開発されてきたアプリを、どのように内製化へ持ち込み、アジャイル開発の体制を実現していったのでしょうか。 1月12日と13日に行われたスクラムのイベント「Regional SCRUM GATHERING Tokyo 2017」では、同社でモバイルアプリケーションの開発チームを担当する武市大志が登壇。内製化やアジャイル開発を実現するために改革と改善を繰り返してきた背景と事情を詳しく
続・アジャイルで人はどう育てるんだろうか - novtanの日常
色々ブコメ頂いたので、紹介がてらいろいろ考えたいです。 予めテーマを絞っておくと、教育にコストがかかる前提において世の中のプロジェクトが全部アジャイルになっちゃったら教育コストをどこから捻出していくイメージなのか、ということと、プログラミング以外のところがどういうプロセスで身についていくのか、というのが僕の関心の主眼です。 id:greencoffeemaker アジャイルをやるには、ある程度のレベルでシステムを修正できなくてはならないのがキツイ。場当たり的なコードで埋めたり、ガチガチに組まれたFWで業務処理だけ書けるというスキルではなかなか難しいのは実感ある。 やっぱり感覚としてはこういうところはあるんですよね。そこに到達するまではお荷物な部分を誰かがフォローするのか、余剰工数でやるのかってところですよね。 id:wwolf アプレンティスシップ・パターンを読もう（要するに徒弟制度） 読
日本でアジャイルが流行らない理由 - @ledsun blog
ポジション的なもの 個人的に、アジャイルは「（あんまり未来や遠くのことを考えるのをやめて）目の前にある問題を解決しよう」という思想と認識しています。 現実の問題を見ないで「将来、日本と米国のソフトウェア開発技術の差が広がるから、ウォーターフォールをやめてアジャイルをやろう」とか、何を言っているんだ、おまえは？ と、思います。 キーワード「エンタープライズ」が出てきているので、業務システムの話をします。 情けないぞアジャイルコーチ 私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い - メソッド屋のブログを読みました。 感想を書きます。 サム・グッケンハイマーの一言 サム・グッケンハイマーは、マイクロソフトが、アジャイル、そして DevOps 移行したことに関するソートリーダー の方が 「ウォータフォールは一切メリットがないので止めておきなさい」 といったそうです。まあ、ポジシ
「社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について」の資料が素晴らしい - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
「アジャイルがダメだと思う7つの理由」から始まったアジャイル論争の現時点のまとめ
「アジャイルがダメだと思う7つの理由」という刺激的なタイトルのエントリを、先週木曜日、3月21日にグロースエクスパートナーズの鈴木雄介氏が公開してから、アジャイル開発に関する議論の波紋が広がっています。 おそらく、これだけさまざまなブログを通じてアジャイル開発の議論が活発化したことはこれまで国内ではなかったのではないでしょうか？ ここでは現時点での議論をまとめますが、興味のある方はぜひここを起点にそれぞれのエントリを読んでみていただきたいと思います。 発端は鈴木雄介氏（id:arclamp）のブログarclampにポストされた「アジャイルがダメだと思う7つの理由」というエントリ。以下がその7つの理由として挙げられたものです。 1.全体スケジュールにコミットできない 2.アーキテクチャ上の無駄が生じる 3.コーチって何だよ 4.変化ヲ抱擁スルために固定化している 5.実証主義的な説明に過ぎな
アジャイルソフトウェア開発宣言
私たちはソフトウェア開発を実践あるいは実践の手助けをする ことによって、よりよい開発方法を見つけだそうとしている。 この活動を通して、私たちは以下の価値に至った。 プロセスとツールよりも個人と対話に。 包括的なドキュメントよりも動くソフトウェアに。 契約交渉よりも顧客との協調に。 計画に従うことよりも変化への対応に。 すなわち、左側に書かれたことがらに価値をおきながらも、 私たちは右側に書かれたことがらにより価値をおく。 Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler
SIがアジャイルやってよくならない点 - @ledsun blog
SIでアジャイルをやるとハイブリッドアジャイルやWater Scrum Fallになります。しかし以下の4点は解決はしません。SIのビジネスモデルでアジャイルが無理なのではなく、「期間と機能を固定して受注する」と変えられない点です。 営業中は、システム担当者は動くシステムを見れない*1。営業マンは見たことないシステムを想像しながら見積もるという高度なヒアリング技術が必要なまま。 開発会社とシステム担当者間で落とす機能を合意しても、「偉い」ユーザーの一声で落とした機能が復活する。多層構造*2による意思決定の遅さは残ったまま。 予算の見積もりは超過方向にしかブレない*3。（予算）見積もりのバッファ問題は残ったまま。 チームメンバによってベロシティ（開発速度）が２〜３倍は変わる。しかし単価はそれほど（４０万〜８０万）変わらない。 アジャイルといっても現時点でのSIのビジネス面へのインパクトは「少
アジャイル開発はなぜ難しい？--アジャイル開発を実案件に生かすための基礎知識（2）
柏木雅之、山下博之 （IPA SEC エンタプライズ系プロジェクト） 2011-06-01 12:00 前回（「アジャイル開発って何がいいの？」）はアジャイル開発について、ウォーターフォール型開発と比較しながらその概要を解説しました。今回はさらにもう一歩踏み込み、アジャイル開発の導入を阻んでいるさまざまな要因を分析し、それらの障害を乗り越えて導入へと向かうための方法を考えてみたいと思います。説明の都合上、若干前回と重複する部分もありますが、ご了承いただければと思います。 アジャイル開発への懐疑的な意見にどう答える？ アジャイル開発はもちろんソフトウェア開発における万能の開発手法ではありません。しかしながら、社会の動きが激しい現代において、要求の変化に柔軟に対応できるアジャイル開発は、顧客側にも開発側にも大きなメリットがある、魅力ある選択肢のひとつのはずです。 にもかかわらず、国内でのアジャ
アジャイルと受託開発
先日、永和システムマネジメント社がアジャイルによる受託開発サービスを発表し、話題になっている。多くの人の関心を引いているのは、アジャイル開発手法を取り入れるということだけでなく、その価格の安さだ。一ヶ月あたりの料金は、もっとも安いものでは月々15万円から、もっとも高額なプランでも月々150万円からとなっている。果たしてそんなので儲かるの！？というのが多くの人がいだいている疑問であろう。自分なりに「アジャイルによる受託開発サービス」について分析してみたので語ってみようと思う。なお、本エントリは永和システムマネジメント社が公開されている資料と筆者の推測に基づくものであるので、より詳細で正確な内容は永和システムマネジメント社さんへ問い合せて頂くよう悪しからず了承いただきたい。 採算割れしないのか？筆者の見解では、たぶんしない。何故か？それは一旦開発が終わったらそうそう頻繁にシステムの仕様を変更し
脱Excel！ Redmineでアジャイル開発を楽々管理
ソフトウェア開発のタスクをチケットに登録すると、作業を始めるチケット管理をメインに、進ちょく管理、問題管理などができる。 バグ管理システムだけでなく課題管理システム（ITS：Issue Tracking System）で運用する開発プロセスは、チケット駆動開発（TiDD：Ticket Driven Development）と呼ばれ、最近注目されている。 Ruby1.9の開発はRedmineで管理されているように、近ごろは事例も増えている。 Redmine運用前の問題点 筆者がRedmine運用前に持っていたプロジェクト管理の問題点は下記2点だった。 1．Excelでのタスク管理の限界 従来からプロジェクトマネージャやプロジェクトリーダーの多くは、進ちょく管理やタスク管理をExcelで行ってきた。 プロジェクト管理では顧客へ進ちょく報告するために、残工数と残タスク数を計算する必要がある。だが
アジャイルって受託開発との相性が最悪な気がする - GoTheDistance
全くもって、その通りだなぁと思った。 初期段階ですべての意志決定をしても、問題はコードを書き始めてから表れるのです。そして終わりに近い時点で判断する方が、より正しい判断ができるはずです。ですから、できるだけ意志決定は先延ばしにして、正しい意志決定をしようとするのがアジャイルのやり方です。 「有能な人がコードを書くべき」「意志決定はできるだけ先延ばし」「契約を変えるのは難しい」アジャイルの専門家の答え － Publickey ｢ウオーターフォールとは｣のラベル貼りの議論になるとめんどくさいから、とりあえず｢初期段階ですべての意志決定をしようとするシステム開発の進め方｣という定義で話を進めたいと思います。 滝 ｢要件定義｣→｢設計｣→｢実装｣→｢テスト｣という一連の流れがあって、ウオーターフォールなるものは前工程が100になるまでひたすらそこでPDCAを回します。100になると言う意味は、ソフ
【公開】KOF2008講演資料「Redmineでチケット駆動開発を実践する～チケットに分割して統治せよ」 - プログラマの思索
関西Ruby会議01＠関西-KOF2008講演資料「Redmineでチケット駆動開発を実践する～チケットに分割して統治せよ」を公開します。 CC Attribution ライセンスとします。 【元ネタ】 チケット駆動開発 … ITpro Challenge のライトニングトーク (4) - まちゅダイアリー(2007-09-07) チケット駆動開発は、まちゅさんが最初に提唱された。 しかし、チケット駆動開発の概念はまだ曖昧で、一部でしか注目されていない。 僕は、Redmineというプロジェクト管理機能を持つBTSがプロジェクト管理をIT化してくれて、プロジェクト運営が大きく変わったことを経験した。 その体験をチケット駆動開発(Ticket Driven Development)という概念へ昇華できないか、考えた内容が上記の資料です。 コメントがあれば嬉しいです。 【参考】 Rubyist
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
