スクラムフェス札幌2020での発表資料です https://confengine.com/scrum-fest-sapporo-2020/proposal/15056/agile-sapporo-learn-from-experience-and-continue-to-repair-wholeness
AmazonでSteve Freeman, Nat Pryce, 和智 右桂, 高木 正弘の実践テスト駆動開発 (Object Oriented SELECTION)。アマゾンならポイント還元本が多数。Steve Freeman, Nat… 1.プロジェクト開始直後に本番に近い環境にデプロイする”プロジェクト開始直後からデプロイとテストを行うことで、チームはシステム全体をどうやって実際の世界に適合させていくか理解しなければならなくなる。 プロジェクト初期段階に、会議室や机上だけでの何を何故つくるべきかどうやってつくるべきかの判断は、たいてい間違いや抜け漏れが含まれています。大事なことを知らないことすら気付いていないこともあります。ソフトウェア開発において、その間違いや知らないことに手っ取り早く、具体的に気付く方法は、早期に小さくつくってデプロイし動かしてみることです。動かそうとすれば仕事の
組織の「外から変える」ではなく「中から変わる」―永和システムマネジメント平鍋健児と、LINE横道稔が語る“アジャイル開発”の本質 「ソフトウェア開発は仕様書通りにさえやればいい」そんなふうに思っていませんか?顧客、企画者、開発者、すべてが一丸となって作り上げることで最高の製品を目指す「アジャイル開発」という手法があります。 人と人とのやりとりに重きを置くことで、製品に、世の中にもっとインパクトが与えられないか。作り手の熱意が漏れない製品開発に挑み続けるアジャイル開発の達人・永和システムマネジメント平鍋健児氏と、LINE株式会社で組織の中から価値の伝播に取り組む横道稔氏が、「アジャイル開発の本質」について語ります。 対談者プロフィール 横道 稔(よこみち・みのる) LINE株式会社 Delivery Managementチーム SIer、事業会社を経て、2018年 LINE株式会社入社。De
昨年12月に行われた和田卓人氏と『時を超えたプログラミングの道』編集長/『スクラム実践入門』著者の家永英治氏の『健全なビジネスの継続的成長のためには健全なコードが必要だ』対談の記事第5弾をお届けします。 対談のこれまでの記事は以下になります。
9. アジャイルまでの歴史 ‣ IBM System/360('64) ‣ ソフトウェアの危機('68) 6 (参考)玉井哲雄「ソフトウェア工学」http://www.graco.c.u-tokyo.ac.jp/ tamai/pub/sebook.pdf 10. アジャイルまでの歴史 ‣ IBM System/360('64) ‣ ソフトウェアの危機('68) ‣ 構造化プログラミング('70s) 6 (参考)玉井哲雄「ソフトウェア工学」http://www.graco.c.u-tokyo.ac.jp/ tamai/pub/sebook.pdf 11. アジャイルまでの歴史 ‣ IBM System/360('64) ‣ ソフトウェアの危機('68) ‣ 構造化プログラミング('70s) • Winston W. Royce 「Managing the Development of Lar
Over the past decade, innovative companies, software industry thought leaders and lean/agile pioneers have discovered simpler, sturdier, more streamlined ways to be agile. These modern approaches share a focus on producing exceptional outcomes and growing an outstanding culture. Today, it makes far more sense to bypass antiquated agility in favor of modern approaches. Modern agile methods are defi
Nagoya.Testing in Tokyo ソフトウェアテストを強いられている人達の話 で発表したスライドです。ただ7割くらいは口頭での説明なので、参加した人の思い出し用です。
エンジニア組織を強くするための本を出版しました Qiitaでエンジニアリングをめぐる様々なコミュニケーションの問題とその解決策や考え方を書いてきた。それらの背後にあるエッセンスをこの度書籍として出版するに至りました。 エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング この書籍は、エンジニアリングを「不確実性を削減する」という第一原理で捉え直し、様々なエンジニアリングとその間のコミュニケーションをめぐる現象を説明していくものです。 はじめに 何かはじめてのことをする場合、人はとても「不安」を感じます。人は未来を考えることができる生き物です。その特異な能力ゆえに、未来に起こるかもしれないよくないことを考えると「不安」を感じてしまうのです。 仕事のプロジェクトなどは、「間に合わなかったらどうしよう」とか「この仕事はちゃんと終えられるのだろうか。」など、未来のことを
最後の原則は「正直は割に合う」です。 ――岡島幸男[1] はじめに 本連載ではアジャイル開発を「アジャイルに開発する人たち(アジャイル開発者)が開発するからアジャイル開発」と考え、アジャイル開発者に必要なスキルを磨くための習慣を紹介しています。 今回は、まずアジャイルな開発を現場に根付かせている人たちが実践している習慣を「信頼貯金を増やす」というキーワードから考えます。そのあとで、信頼貯金を増やすために重要な、アジャイル開発者としてのスキルの構成と磨き方を整理します。そして、最終回らしく連載のこれまでを総括します。 アジャイル開発者と信頼貯金 アジャイルに開発できている開発者と、そうでない開発者の違いは、技術スキルの優劣だけではないと私は考えています。うまく開発をアジャイルにできている開発者は、スキルを磨いているのはもちろんですが、それと併せて信頼貯金を増やすことも習慣の一つとして身につけ
(当日の様子や、なぜこのようなイベントが開催されたのかはCTOのエントリ 第1回ペパボテックカンファレンスを開催しました #pbtech - delirious thoughts をご覧ください。) ペパボテックカンファレンスという企画が立ち上がったとき、最近ずっとスピリチュアルなことばっかりやってるし、テッキーなことはまだ発表できるほど成果だせてないし、という思いがあって登壇を保留していました。(普段外に出ない人に発表してほしいというコンセプトもあり) ただ、社内でも「見積りと計画づくり」について何度か説明しており、参考文献にあげたような書籍を全部読まなくても概要を理解できるような資料の必要性を感じていたので、自分の考えていることを技術という切り口で言語化してみるといいかもしれないと思い、今回発表させていただきました。 現実社会の厳しさと戦っている皆さんのヒントになれば幸いです。 さて、
Many people equate Lean and agile or claim that one is a subset of the other. In fact, they have almost opposite emphases: thinking versus doing; teams versus individuals; planning versus reacting; and many more. This talk will help you clarify the distinction in a way that will help you focus soberly on how to improve your environment, team, product and process, by going beyond the buzzwords to t
Japanese version only. Agile Japn 2012 講演資料Read less
AgileJapan2012で私が最も期待しているセッションをご紹介します。 アジャイルをも活用した新しいビジネスモデル アジャイルとビジネスモデルに関するパネルディスカッションなので、本来であれば私がぜひ登壇して「納品のない受託開発」を紹介したいところですが、私は東京サテライトを担当しており、大阪に行けないため代理で弊社ソニックガーデンの副社長に出てもらうことにしました。彼が表舞台に出ることはあまりないので貴重な機会ですが、ソニックガーデンの契約書など全て彼の仕事なので、私よりも具体的な話が聞けるはずです。 そして、そのパネルには当然ですが「価値創造契約」を掲げる永和システムマネジメントの方が登壇されます。そこもきっと永和システムマネジメントの木下さんが出てくるものだと思っていたら、登壇するのは市谷くん(papanda)だというのです。DevLOVEの立場でなく永和システムマネジメントと
Fulcrumはストーリーベースのアジャイル開発にマッチしたプロジェクト管理システム。 FulcrumはRuby on Rails製のオープンソース・ソフトウェア。アジャイル開発において用いられるユーザストーリー。利点としては機能をユーザ視点で捉えることで、実装されるべき機能が明確になりイテレーションが終わった段階できちんとできているか確認がしやすいことだ。 4つの枠が特徴 そのため通常のタスク管理に比べると大ざっぱに見えてしまい、逆に細かな進捗が見づらくなってしまう場合もあるようだ。そんな状態を解決するには、最適なプロジェクト管理を導入することにあるだろう。今回紹介するのはFulcrumだ。 Fulcrumはストーリーベースのタスク管理を実現する、アジャイル開発向けのプロジェクト管理だ。完了したストーリー、作業上、バックログ、Chilly Bin(終わらなかったタスクを放り込んでおく場所
アジャイル開発で有名な永和システムマネジメント(以下、永和さん)が、新しいシステム提供形態のサービスを開始したと発表がありました。 http://www.esm.co.jp/trial/new-agile-contracts-service.html コスト面だけ簡単にまとめると 初期費用0円 納品されてから、月額サービス利用料という形で料金を支払う(レンタルする) 月額サービス利用料の範囲である程度機能追加開発も請け負う 規模に応じて15万円(月額)〜300万円(月額) ※どこかで似たサービスを聞いたことがあるような気がするのはきっと気のせいです。 規模がどのくらいかわからないですが、SSであれば開発期間3ヶ月程度。 で、年間利用料は15万*12ヶ月=180万円、5年使うとして720万円(4年目以降半額なので) 一定量の機能追加はサービス料金で対応というのが、保守・サポートチケットのこと
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く