タグ

関連タグで絞り込む (2)

タグの絞り込みを解除

agileに関するtakeo1031のブックマーク (6)

  • 組織をプロダクトオーナーにする、ということ[修正あり] - arclamp

    2014年7月31日(木)に開催された「Developers Summit Summer 2014」(通称:夏サミ)にて、「創業122年の企業と顧客価値にコミットした開発を実現する試みと成果について」という講演をしてきました。資料と動画は以下から。 講演には弊社の顧客である(株)東京商工リサーチ(以下、TSR)の青木さん(システム部 部長)にも参加いただきました。講演の最後に「GxPさんとは、まさに二人三脚のような関係を築けた」という言葉が非常にうれしかったです。 また、講演に向けて打ち合わせをする中で「我々は何をしてきたのか/何が出来たのか」というのをじっくり話せたのは良い経験でした。プロジェクトが完了したら顧客と一緒に講演する、みたいなことが毎回出来たらいいでしょうね。 速さよりもリズム さて、今回の講演のキーワードでもある「組織としてプロダクトオーナーの役割を果たす」も、そういう事

    組織をプロダクトオーナーにする、ということ[修正あり] - arclamp
  • To be an Agile Enterprise

    on E-Agility COnference

    To be an Agile Enterprise
  • アジャイル実践者が100人以上集まった「Agile Samurai Dojo Gathering」でGatheringしてきた! #agilesamurai | Act as Professional

    Be Agile from Programmers of my experience サムライ戦記として、僕の経験を導入編でトークしました。15分という短いトークは久しぶりだったので内容があまり詰め込めませんでした。アジャイルソフトウェア開発の導入自体はアジャイルサムライを読まれている参加者なので、インセプションデッキをやって、良いと思われるアジャイル開発手法を取り入れていけば良いと思います。よって、そういった内容については、一切触れない内容としました。 プログラマから非エンジニアを含むチームをアジャイルソフトウェア開発に変化していくために必要なポイントを話しました。結論からいうと、プログラマはまず、アジャイルソフトウェア開発に必要なエンジニアリングプラクティスを実践できる能力を身につけることが、アジャイルソフトウェア開発を成功へ導くということです。 アジャイルサムライのだいぶ終盤の方に、

    アジャイル実践者が100人以上集まった「Agile Samurai Dojo Gathering」でGatheringしてきた! #agilesamurai | Act as Professional
  • 高速で無駄のないソフトウェア開発を実現するための7つのポイント | Social Change!

    どうすれば小規模なチームでも大きな成果を出せるのか。大きな組織で沢山の量をこなすのは当たり前のことで、あまりクールではありません。少ない人数でも大きな成果を出すには、スピードをあげることと、そのためにも無駄をなくすことがポイントになってきます。 ソフトウェアをつくるための3つの役割で書いた通り、ソフトウェア開発をクラウドのようなサービス提供で続けていくには、プロダクトオーナーとプログラマーがキャッチボールのような形で、仕様と実装をずっと繰り返しながら作っていくのが自然です。 SonicGardenで使っているツールと開発の流れの全体は以下のようになります。大事なことは「動くソフトウェア」の状態を保ったまま、どれだけ回転数をあげていけるか、ということです。そのために、プロダクトオーナーとプログラマの間で待ち時間を減らすために並行して進めるようにするなど工夫しています。 ホワイトボードとMVP

    高速で無駄のないソフトウェア開発を実現するための7つのポイント | Social Change!
  • ロートルの嘆き、アジャイル開発って何 - 未来のいつか/hyoshiokの日記

    20数年前に大学を卒業しプログラマになって、この変化のとっても早い業界でまだ禄を得ている。最近でこそコードを書くことはないが(今でも職業としてコードを書きたいと強く思っている)、それでも、ソフトウェア開発について20数年前に得た知識、経験、スキルが役に立っているように思える。 日進月歩で日々新しいバズワードが登場し、若い人たちはそれをフォローするのにひーひー言っている。クラウドだアジャイル開発だなんだかんだ。 プログラマの一日は、会社に来て、テストを書いて、テストをして、不具合があればコードを修正し、またテストをして、問題がなければコード管理システムにチェックインする。その作業を淡々と日々こなす。この日常の流れというのは、使う道具立てこそ変わったとしても、基的に変化がないように思える。コードを書くのは20数年前も今もプログラマだし、テストを書くのもそうだし、テストを自動化することは20数

    ロートルの嘆き、アジャイル開発って何 - 未来のいつか/hyoshiokの日記
  • 【12-A-5】 ユーザー企業責任で25サイトをアジャイルに開発

    3. どんな事例か? ・完全内製ではないユーザ企業が、 ・自社システムのビジネス価値を高めるために、 ・アジャイル開発の考え方を自分たちの現場に適用させる試みを組織的に、 ・年単位(3年)で取り組んでいる ・素晴らしい正解ではないかもしれない (そもそもリクルートの中でも、いろいろなやり方があります) ・技術的に、特に新しいわけではない しかし、ビジネスの現場、開発の現場で、3年間、 「どうすればもっとよくなるか?」 を継続的に考えて実行してきた結果です。 特に、ヒトの考え方・習慣をポイントに、皆さんの考えるヒントになれば 4. Agenda 1.リクルートとは ◆リクルート概要とシステム担当の役割 ◆システム担当の組織概要 2.背景 ◆Webメディア・サービス設計・開発の課題 3.SWATとは? ◆思想 ◆歴史(3年間の歩み) ◆開発体制 ◆特徴 ・開発プロセス ・リスクの考え方 ・コミ

    【12-A-5】 ユーザー企業責任で25サイトをアジャイルに開発
  • 1