並び順

ブックマーク数

期間指定

  • から
  • まで

281 - 320 件 / 20332件

新着順 人気順

agileの検索結果281 - 320 件 / 20332件

  • 台東区区議会議員「酔った二人組がやって来て、避難者カードの記入をお願いしたところ、記入をせずに帰って行った。」「職員が、苦情対応に張り付きになってしまった」→不正確だったと訂正

    一般社団法人 あじいる(フードバンク+隅田川医療相談会) @agile_2019 上野近郊の方が避難する忍岡小学校で、野宿している方が行ったら断られたという情報あり。 問い合わせてみたら、台東区として野宿している方が避難できる場所は用意していないとのこと。 上野周辺には普段約100名の方が野宿しています。 ふざけてる。人権侵害です。 2019-10-12 15:15:39 一般社団法人 あじいる(フードバンク+隅田川医療相談会) @agile_2019 【拡散希望】台東区長が本部長の台東区災害対策本部に問い合わせると、「今後避難準備・避難勧告が出る可能性があるが、ホームレス(住所不定者)については、避難所は利用できないことを対策本部で決定済み」と言われました。事実上、台東区の災害対策は、ホームレスを排除しています。 #台風19号 2019-10-12 17:15:17

      台東区区議会議員「酔った二人組がやって来て、避難者カードの記入をお願いしたところ、記入をせずに帰って行った。」「職員が、苦情対応に張り付きになってしまった」→不正確だったと訂正
    • 他社向けの提出資料としても使えるレベルのプロトタイプ作成&プロジェクト管理·Serena Prototype Composer MOONGIFT

      受託開発におけるプロジェクト管理というと、開発会社側で管理すべき項目に対して有効なものが多い。そのため、開発案件が終わるとあまりメンテナンスはされなくなる。さらに開発プロセスの管理に限るので、実際の納品物とは乖離することがある。 WebサイトもWindowsアプリケーションプロトタイプも作成できる だがそれでは勿体ない。開発のはじまりから終了、そしてその先まで全体を見られる管理ツールがあると便利だ。そう考えたことのある方はSerena Prototype Composerを導入しよう。 Serena Prototype ComposerはWindows向けのフリーウェアで、プロジェクト管理のみならずプロトタイプやワークフローの管理まで行えるプロジェクト管理ソフトウェアだ。 Serena Prototype Composerは特にWebシステムに限ったものではないようだ。プロトタイプ作成では

        他社向けの提出資料としても使えるレベルのプロトタイプ作成&プロジェクト管理·Serena Prototype Composer MOONGIFT
      • すべてがXPになる ─ エクストリームプログラミングで見える開発風景(セミナーレポート) - Agile Journey

        アジャイルソフトウェア開発を企業が導入する際に、スクラムと並んで名前が挙がる開発手法にエクストリームプログラミング(XP)があります。ガイドブックや研修が存在するスクラムに対して、ペアプログラミング(ペアプロ)やテスト駆動開発といったプラクティスをエクストリーム(極限的)に実践しようというXPの導入には、どこから始めればよいのかと戸惑う開発組織もあるようです。 2022年6月に開催されたユーザベース主催の勉強会「エクストリームプログラミングで見える開発風景」では、XPの提唱者であるケント・ベックの著作などの翻訳者として知られる角征典さんと、XPを導入しているユーザベースのソフトウェアエンジニアである野口光太郎さんが講演したのち、XPの始め方やエンジニア以外との体制づくりなどについて、視聴者の質問をもとにパネルトークが行われました。 本記事では、組織にXPをどのように導入するか、またスクラム

          すべてがXPになる ─ エクストリームプログラミングで見える開発風景(セミナーレポート) - Agile Journey
        • 見習いプログラマが読んでも、ほとんど無意味な10冊 - カレーなる辛口Javaな加齢日記

          http://blog.usagee.co.jp/2010/11/23/level-up-programmer id:lizy javablackさんが来そうな内容だw http://b.hatena.ne.jp/entry/blog.usagee.co.jp/2010/11/23/level-up-programmer いやまったく.毒と分かっていても食らうしかないのは不幸だ. http://d.hatena.ne.jp/JavaBlack/20080401/p1 http://d.hatena.ne.jp/JavaBlack/20070522/p1 悪書 憂鬱なプログラマのためのオブジェクト指向開発講座 (DDJ Selection) 作者: Tucker出版社/メーカー: 翔泳社発売日: 1998/05/31メディア: 大型本購入: 10人 クリック: 508回この商品を含むブログ

            見習いプログラマが読んでも、ほとんど無意味な10冊 - カレーなる辛口Javaな加齢日記
          • 永和システムマネジメント アジャイル開発支援事例|株式会社ネクスウェイ

            ネクスウェイ システム推進室 松森正彦 氏、小田切一成 氏 に、永和システムマネジメントのアジャイル開発支援サービスを採用した経緯と評価について詳しく聞きました。 第一部: 「アジャイル開発指導を取り入れて、ヒット商品の開発に成功」 第二部: 「NEXLINK BASICがヒット商品になった本当の理由」 第三部: 「『開発を一度ストップする』という決断」 第四部: 「プロジェクトマネージャーは知っておいた方がよい、アジャイル開発の影の部分」 ネクスウェイについて ネクスウェイは、ソフトウエア、FAX、メールなどを通じてBtoBマーケティング支援する企業です。主な商品は、NEXLINK、eオンデマンド便サービス、e帳票-FAXサービスなど。年商249億円、取引法人 約8000法人、従業員数249名、創立は2004年10月。 NEXLINK BASICについて NEXLINK BASICは企

            • そろそろ全体を見た話が聞きたい2 - ニューロサイエンスとマーケティングの間 - Between Neuroscience and Marketing

              2010年の年末に『イシューからはじめよ』を出版した。何ヶ月か後、歴史的な大地震(いわゆる311)が来た。大津波の死者・行方不明者は無数、フクシマは爆発する、東京は計画停電が始まるしで、何がなんだか訳のわからない不安と混乱が世の中を覆い尽くしていた。随分目先のしかも全体観のない議論ばかりが行われていて不毛だと感じ、10日あまり経ったところで課題の全体観を俯瞰したブログエントリを書いた。 kaz-ataka.hatenablog.com 今見てもそれほど大きな違和感がない。初動、その後の対応の残念さ、せっかくの刷新にもうまく繋げられたとは言い難かったことも明らかになっているのだが、それは一旦おいておこう。 _ いま僕らを襲っているのは歴史的には人類最大の死因の一つ、疫病だ。 拙著『シン・ニホン』が2月20日に世に出たときはまだ中国と日本のダイヤモンド・プリンセス号にほぼ閉じた話だったが、現在

                そろそろ全体を見た話が聞きたい2 - ニューロサイエンスとマーケティングの間 - Between Neuroscience and Marketing
              • Rails の ActiveRecord モデルテストの書き方ガイドライン - passingloopの日記

                このエントリでは,Ruby on Rails (以下 Rails)の ActiveRecord モデルテストについて,1) どこの何をテストすればよいか,2) どのようにテストを書けばよいか,のガイドラインを示します.このガイドラインは Rails 公式のものではなく,id:passingloop が使っている私的なものです.疑問・質問・批判・間違いの指摘はページ下部のコメント欄までお願いします. はじめに Rails は TDD/BDD サポートが充実した Web アプリケーション開発フレームワークです.Rails で使える Test::Unit や RSpec などといったテスティングフレームワークの使い方に関する解説も豊富にあります.しかし,「どこをどうテストすればよいのか」についての解説は,「使い方」の解説と比較して少ないように思います.もっとも,テスト一般についてどう書くかはアプ

                  Rails の ActiveRecord モデルテストの書き方ガイドライン - passingloopの日記
                • Free Programming Books

                  Here is an uncategorized list of online programming books available for free download. The books cover all major programming languages: Ada, Assembly, Basic, C, C#, C++, CGI, JavaScript, Perl, Delphi, Pascal, Haskell, Java, Lisp, PHP, Prolog, Python, Ruby, as well as some other languages, game programming, and software engineering. The books are in various formats for online reading or downloading

                  • リモートワークでも生産性を上げる!スクラム創始者直伝の実践ノウハウを日本語化して入門者向けにまとめました。 - Qiita

                    リモートワークでも生産性を上げる!スクラム創始者直伝の実践ノウハウを日本語化して入門者向けにまとめました。プロジェクト管理スクラムリモートワークコミュニケーションコロナウイルス はじめに 認定スクラムマスター(LSM)取得者向けに「Distributed Teams: Mitigating Business Risk in Uncertain Times」と題したウェビナーがスクラム創始者の Jeff Sutherland 氏を交えて3月に行われました。 この投稿はウェビナーの内容を噛み砕き、リモートワーク環境でもスクラムの実践がスタートできる内容を目指しました。チームリーダーやマネージャーとしてスクラムを推進している方や、これから導入を検討している方のご参考になれば幸いです。 まずは結論から リモートワークでより成果を上げる働き方は可能なの? 可能。→ リモートチームを成功させた企業のユ

                      リモートワークでも生産性を上げる!スクラム創始者直伝の実践ノウハウを日本語化して入門者向けにまとめました。 - Qiita
                    • DevOpsに関する12のアンチパターン

                      みなさんこんにちは。@ryuzeeです。 DevOpsGuysというサイトのTwelve DevOps Anti-Patternsという記事が秀逸です。 作者の方に許可を頂き翻訳しましたので公開します。 原文も軽妙なタッチで読みやすいと思いますのでぜひご参照ください。 また本文で様々なスライドや資料へのリンクがありますので、そちらも見ていただくと理解が深まるんじゃないかと思います! えっとDevOpsを始めたいのかな?おっけー。ただ始める前に、やってはいけないいくつかのことについて見ておこう。 古き良き時代には単に「良くないアイデア」って呼んでいたんだけど、外交やポリティカル・コレクトネス運動の結果、ブレストやアイデアシャワーをして、最近は「アンチパターン」と呼ばれるようになった。 パターンが絶対的に正しいのであれば、すなわち「アンチパターン」は間違いということになる。そして間違いを避ける

                        DevOpsに関する12のアンチパターン
                      • Scrum / DevOps の導入を加速するグローバルマインドセット ~8つの習慣 その1 ~ - メソッド屋のブログ

                        クロスカルチャーの専門家Rochelle Koppさんと一緒に考案した 新技術の導入を加速させるための「8つの習慣」をまとめ上げた。この習慣を習得することで、米国と同じようなスピードで新しいことに対応したり、生産的になることができる。今回はその一つ目の習慣について解説してみた。 今回、日本最大級のアジャイル開発のイベントの一つである Scrum Gathering Tokyo で先のRochelle さんと一緒に「8つの習慣」を初めて発表させていただいた。 2017.scrumgatheringtokyo.org 「8つの習慣」は日本での Agile / DevOps をはじめとする最新技術やプロセスの導入を米国並みのスピードにすることを目指している。Agile や DevOps を開発した人は西洋の人なので、西洋文化の上に成り立っている。だから、日本の文化の上でそれらを使うと、どうもうま

                          Scrum / DevOps の導入を加速するグローバルマインドセット ~8つの習慣 その1 ~ - メソッド屋のブログ
                        • 突撃!隣の開発環境 パート7【永和システムマネジメント編】 | DevelopersIO

                          こんにちは!おおはしりきたけです。パート7の今回は、アジャイル開発で受託開発を行ったり、アジャイルのコーチングやidobataというグループチャットアプリなどの開発も行っている永和システムマネジメントのアジャイル事業部にお邪魔しました。インタビューに答えてくださったのは、Idobataエンジニアの寺田さんと、受託開発でエンジニアをやられている松島さんです。 突撃!隣の開発環境とは 技術事例やノウハウなどは、ブログや勉強会などで共有されることが多いと思います。しかし、各社の開発環境や開発体制などは意外と共有されていないこと多いと思います。ノウハウの流出になるかもしれませんが、それ以上に、より良い開発を目指している会社さん同士で情報交換を行い、良いチーム、良いプロダクトを作っていくという志の会社さんの為の情報共有のための企画になります。開発環境や開発体制なども技術領域によっても変わってくると思

                            突撃!隣の開発環境 パート7【永和システムマネジメント編】 | DevelopersIO
                          • アジャイルとDevOpsの品質保証と信頼性 - Test Automation

                            このブログエントリは日本信頼性学会論文誌 Vol.42, No.2, 2020年3月号に寄稿した「アジャイル/DevOps開発における品質保証と信頼性」という解説論文の転載です。 (品質管理研究会でこの解説論文の内容をもとにした特別講義を来年実施します。ご興味ある方はぜひご参加ください。) --- 概要 近年日本のソフトウェア開発チームでも取り入れられるようになったアジャイル/DevOps などのソフ トウェア開発手法は,今まで主流であったウォーターフォール開発と異なる特徴を持つため,その品質保 証や信頼性の考え方をそのまま適用できない場合も多い.アジャイル/DevOps 開発では短い開発サイクル の中で小刻みなフィードバックループと改善活動を繰り返しながら開発する.そのため,QA テストとして の品質保証の役割はアジャイル/DevOps においても依然重要であるが,それに加え開発サイクル

                              アジャイルとDevOpsの品質保証と信頼性 - Test Automation
                            • 「アジャイルの現状と未来、次に来るもの。~リーン開発への展望~」Agile Japan 2010基調講演から

                              「アジャイルの現状と未来、次に来るもの。~リーン開発への展望~」Agile Japan 2010基調講演から アジャイル開発手法として知られるXPやスクラムは、国内で徐々に浸透し始めています。しかしアジャイルをさらに推し進めて企業レベルでアジャイルを活用したり、あるいは企業自身がビジネスをアジャイルに回すためにはどうすればよいのでしょうか。 4月9日と10日の2日間開催されたイベント「Agile Japan 2010」。2日目の基調講演に登壇したAlan Shalloway氏は「アジャイルの現状と未来、次に来るもの。〜リーン開発への展望〜」(What Is Next In the Agile World)と題し、企業をマネジメントする視点からのアジャイルについて講演を行いました。 Shalloway氏の講演は、アジャイルについてよく言われる「プロジェクトではうまくいくが、会社レベルで展開し

                                「アジャイルの現状と未来、次に来るもの。~リーン開発への展望~」Agile Japan 2010基調講演から
                              • ヘキサゴナルアーキテクチャ(Hexagonal architecture翻訳)

                                Alistair Cockburn による Hexagonal architecture の翻訳です。PoEAAで言及されていることから、2002年ごろにはすでにC2 Wikiにページがあった模様。似たようなアーキテクチャである クリーンアーキテクチャ も翻訳したので参考にしてください。 この記事は著者から許可を得て公開しています。Thanks to Alistair Cockburn! 目次 パターン: Ports and Adapters (構造に関するパターン) 意図 動機 解決法の本質 構造 サンプルコード ステージ1: FIT アプリ 定数をモックデータベースとして ステージ2: UI アプリ 定数をモックデータベースとして ステージ3: (FITまたはUI) アプリ モックデータベース 応用ノート 左右の非対称性 ユースケースとアプリケーションの境界 ポートはいくつ? 既知の用

                                  ヘキサゴナルアーキテクチャ(Hexagonal architecture翻訳)
                                • ウノウラボ Unoh Labs: アジャイルな開発をチームでやってみた(2010年版)

                                  こんにちは murahashi です。 アジャイルな開発をチームでやってみている(2010年)のですが、いざやってみると結構ハマリどころがありました。やってみたことを共有しておこうと思います。 かたちから入ろう 朝会 アジャイルな開発と言えば朝会なので、朝会から始めました。 開始時刻をメンバーで決めて、それぞれが昨日やったこと、今日やること、おしらせ、困っていること、を共有しました。 さらに、朝会前に社内wikiにメモ書き程度の項目を書いておきます。これにあらかじめ目を通すことで、一番の課題に時間を集中することができました。 アンチパターン・決めた時刻を守らない 11時から朝会始めようと決めたのに、11時過ぎに汗だくで飛び込んできて「遅れてすみません」「wiki書いてません」「wiki読んでません」というのは、チームの空気を悪くするだけでなく、単純に全員の時間を無駄にしてしまいま

                                  • Redmineでアジャイルチームのスピードやパワーを見える化する

                                    burndown chart via kakutani アジャイルなチームを目指す。私がチーム運営を始めたときのポリシーでした。どうやって作業をこなすだけから、アウトプットへの価値へとシフトしていくか?チームの方向を示すためにも、様々なメトリクスやKPIを見える化する必要がありました。 通常のプロジェクト管理方法だと、ガントチャートでロードマップを設定、進捗の状態を管理。WBSなどを作ってそれぞれのタスクを管理・・・といった形が一般的なのでしょうか。しかし、それではワクワクしない。そんな中、常に改善を心がけ、私が試して行き着いた方法を紹介させていただこうとおもいます。 唯一生き残ったプラグイン バーンダウンやタスクボードなど、Redmineのプラグインで様々な見える化をしましたが、ずっとそれを使うことはしませんでした。その中で、最終的に生き残ったのがパーキングロットチャートです。なぜ、これ

                                      Redmineでアジャイルチームのスピードやパワーを見える化する
                                    • 最強のパスワード管理ソフト 1Password [Mac OS X]

                                      Agile Web Solutions のパスワード管理アプリ、1Password をようやく使いこなし始めました。予想外のエラーのせいで(後述)手間取りましたが、うまく動き始めるとこれほど便利なものもありません。$30 という値段は決して安くはありませんが、それだけの価値はあります。 1Password はスタンドアローンのパスワード管理ソフトであり、ブラウザの拡張機能を通じてフォームの自動入力を便利にしてくれるツールです。一つだけマスターパスワードを決めておけば、残りのパスワードは 1Password が一元管理して、ブラウザのフォームなどに自動入力してくれます。 Firefox のパスワードマネージャもよいのですが、いろいろな理由でブラウザとパスワード管理を分離したいという方もいると思いますし、1Password を使えば対応しているブラウザに横断してパスワードを利用することができる

                                        最強のパスワード管理ソフト 1Password [Mac OS X]
                                      • Groovy - Home

                                        Groovy WikiGroovy... is an agile and dynamic language for the Java Virtual Machine builds upon the strengths of Java but has additional power features inspired by languages like Python, Ruby and Smalltalk makes modern programming features available to Java developers with almost-zero learning curve supports Domain-Specific Languages and other compact syntax so your code becomes easy to read and ma

                                        • 【翻訳記事】テストに対する考え方「Testing Manifesto」 - ブロッコリーのブログ

                                          はじめに(Testing Manifestoを紹介するに至った背景) 既にこのブログでお伝えしたように、先日『Agile Testing Condensed』の日本語翻訳本を出版しました。 この書籍の中で、テストマニフェスト(Testing Manifesto)が紹介されています。 アジャイルソフトウェア開発宣言(Agile Manifesto)を元ネタにして作ったものだと思います。 この考え方は書籍を購入していない人にもぜひ知ってほしいと感じているので、この記事でも紹介することにしました。なお、記事に載せることについては、この画像の作者であるKarenとSamにメールを送り許諾を得た上で掲載しています。*1 テストマニフェスト 翻訳した画像はこちらです。*2 オリジナルの画像等はこちらにあります。 www.growingagile.co.za また、画像だけでなく文章も残しておきます。

                                            【翻訳記事】テストに対する考え方「Testing Manifesto」 - ブロッコリーのブログ
                                          • 状態ではなく、振る舞いをモックせよ

                                            TL;DR GOOS本『実践テスト駆動開発』で触れられている「ロールをモックせよ」について、違った角度で解説ドメインモデルを豊かにすることでコードがシンプルになる例Mock Behaviors, Not Statesユニットテストを記述する際、テスト対象のオブジェクトが利用しているオブジェクト(依存オブジェクト、隣接オブジェクト)はモックオブジェクトにして、テストしたい状況をテストコード側からコントロールします。しかし、闇雲にモックを使ってテストを記述すれば良いわけではありません。今回は、モックが有効に機能するテストとはどういったものなのかを解説します。 サンプルコード簡単なサンプルで説明します。Extract Till You Dropのモデルと近いものを使います。グループ、メンバー、およびグループリポジトリがあります。グループオブジェクトはインメモリでは所属メンバーの情報を保持しておら

                                              状態ではなく、振る舞いをモックせよ
                                            • マーチン・ファウラー氏が語る、21世紀のソフトウェアデザインとしてのアジャイル開発(前編)。Agile Conference tokyo 2011 - Publickey

                                              アジャイル開発に関する論客の一人マーチン・ファウラー氏は、7月20日にテクノロジックアートが主催したイベント「Agile Conference tokyo 2011」で「21世紀のソフトウェアデザイン」をテーマに基調講演を行いました。 ファウラー氏の基調講演の様子を紹介しましょう。 アジャイル開発の意味が希薄化している ThoughtWorksのマーチン・ファウラー氏。 アジャイルソフトウェア開発宣言から10年がたち、そのあいだいろんな人が伝えていくうちに当初の意味の希薄化(Semantic Diffusion)が起きてしまったと思う。私の役割は、最初の意味を思い出してもらうことだ。 要件の安定性に依存するのは不健全だ まずは「予想的な計画(Predictive Plannning)」と「適応的な計画(Adaptive Plannning)」について。 土木や建築に由来するのが「計画駆動開

                                                マーチン・ファウラー氏が語る、21世紀のソフトウェアデザインとしてのアジャイル開発(前編)。Agile Conference tokyo 2011 - Publickey
                                              • インデセプションデッキ|ネスケラボ

                                                インセプションデッキとは インセプションデッキとは、プロジェクトの全体像(目的、背景、優先順位、方向性等)を端的に伝えるためのドキュメントです。ThoughtWorks社のRobin Gibson氏によって考案され、その後、アジャイルサムライの著者 Jonathan Rasmusson氏 によって広く認知されるようになりました。 インセプションデッキについては、Jonathan氏のブログ「The Agile Inception Deck」にて説明を読むことができます。 Jonathan氏が作成したインセプションデッキのひな形 インセプションデッキ(Inception Deck)を直訳すると「最初のデッキ(カードの束)」という意味となり、アジャイルプロジェクトにおける「プロジェクト憲章」に近い意味合いを持ちます。 プロジェクト憲章とは PMBOKにおけるプロジェクト憲章(Project Ch

                                                • ウォーターフォールの方が楽ですか?

                                                  (顧客) そのシステムを作った結果に対して、顧客自身が結果責任を背負っていない場合は、ウォーターフォールの方が楽。最初に仕様合意して最後に「納品」されれば良い。場合によっては、システムによって得られる価値が目的なのではなく、「システムを作る」こと自体がアリバイ的に目的であるケースすらある。こういう場合は、顧客自体のプロジェクトへの参画が必要なアジャイルは面倒だと思うだろう(顧客) また、顧客が開発部隊に対して政治的に極めて強い力を持っている場合なんかは、基本的に全てのリスクを政治的な力によって移転できるので顧客側が大きくコミットする必要性はなく、ウォーターフォールの方が彼らにとっては楽かもしれない(顧客) その一方で顧客自身が結果責任を背負っている場合やそのシステム自体がビジネスの中心を担っているような場合、肉体的ではなくリスクマネジメントとして楽なのは圧倒的にアジャイルであると言える。市

                                                    ウォーターフォールの方が楽ですか?
                                                  • DC/クラウド/通信事業者サービスの障害事例よせあつめ - # cat /var/log/stereocat | tail -n3

                                                    はじめに データセンタ障害の話題がちらほら流れておりますが、その中で見かけた「データセンタでそんな障害あったら意味ねえじゃん」みたいなコメントにちょっと引っかかるところがありまして。まあ確かに電源の二重化云々とかいろいろ災害やトラブルに対する対策はしてますよ。してますけど、でもデータセンタ・オーダーの障害とかも実際あるんですよね。落ちるときは落ちるんですよデータセンタだろうと。信頼性は高いけど100%じゃない。 ということで、じゃあ過去どんな事例があったのか、ざっと事例を挙げてみようと思いました。基本的には過去の私のツイートとかはてブとかネットをざーっと検索して出てくるものを取り上げています。「データセンタ使ってるからオールオッケー」みたいな話ではなくて、その上で・さらにこういうこともあるんだ、という話を見るのに参考にしてもらえれば良いかと思います。 なお、ここで取り上げている事例は、特定

                                                      DC/クラウド/通信事業者サービスの障害事例よせあつめ - # cat /var/log/stereocat | tail -n3
                                                    • Freight Forwarders - Smokescreen.us

                                                      Navigating the World of Freight Forwarders: Expertise, Evolution, and Efficiency Freight forwarders are the unseen architects of global trade, ensuring that the gears of commerce keep turning smoothly. Their ability to adapt and innovate in the face of changing trade dynamics, regulatory environments, and technological advancements will be crucial in shaping the future of global trade. In a world

                                                        Freight Forwarders - Smokescreen.us
                                                      • アジャイル開発を、人はどのようにして学ぶのか。アジャイルの第一人者、平鍋さんに聞いた

                                                        「アジャイル開発は、実は本を読んで理解するのがとても難しい」。9月4日に、有志によるアジャイル開発のイベントの基調講演「アジャイル開発の現在・過去・未来」の中で、アジャイルの第一人者であるチェンジビジョン代表取締役社長の平鍋健児氏はこう発言しました。 本を読んで理解するのが難しいのだとすると、アジャイル開発はどのようにして学んでいくのがいいのでしょうか? 平鍋さんが伝えようとしたことを詳しく聞くために、メールインタビューをしました。 自分で考えることが本質 先日のXP祭りで平鍋さんの講演を聞いたとき、「アジャイルは人づてに伝わっていく」という部分が印象に残りました。また、「アジャイルは、実は本を読んで理解するのがとても難しい」ともおっしゃっていました。とはいえ、アジャイル開発を本や講演などから学び始める人も多いはずです。そういう方々にアジャイルをどう学ぶのがいいのか、というアドバイスを届け

                                                          アジャイル開発を、人はどのようにして学ぶのか。アジャイルの第一人者、平鍋さんに聞いた
                                                        • Matzにっき(2008-01-29): PHP使いの反論

                                                          << 2008/01/ 1 1. 年賀状 2. ゴビウス 3. [Ruby] ZSFA -- Rails Is A Ghetto 2 1. 新年会 3 4 1. The Mythical 5% 5 6 7 8 1. [言語] Substroke Design Dump 2. [言語] A programming language cannot be better without being unintuitive 3. [OSS] McAfee throws some FUD at the GPL - The INQUIRER 9 1. [言語] Well, I'm Back: String Theory 2. [言語] StringRepresentations - The Larceny Project - Trac 10 1. [Ruby] マルチVMでRubyを並列化、サンと東大が

                                                          • [動画]Ruby設計者まつもとゆきひろといろいろ語りたい - @IT情報マネジメント

                                                            プログラム言語Rubyとアジャイルソフトウェア開発の連携が生み出す新たな可能性を縦横無尽に語り合う。全6回シリーズの第1回。まつもとゆきひろ(ネットワーク応用通信研究所)がRubyの来歴を語り、平鍋健児(チェンジビジョン)がアジャイル開発とRubyの接点を模索する。角谷信太郎(永和システムマネジメント)が両者の橋渡しをする。 なぜ、「まつもとゆきひろ」か? 「RailsによるアジャイルWebアプリケーション開発」は一風変わった書籍である。RubyによるWebアプリケーションフレームワーク、Ruby on Rails解説の決定版である本書は、書名に「アジャイル」を冠しながらも、本文では具体的なアジャイルソフトウェア開発手法への言及がほとんどない。その理由は「アジリティ(agileであること)はRailsの構造の一部」であり「フレームワーク自体にアジャイル宣言の原則を語らせるように」執筆したと

                                                              [動画]Ruby設計者まつもとゆきひろといろいろ語りたい - @IT情報マネジメント
                                                            • アジャイルの「ライトウィング」と「レフトウィング」:An Agile Way:オルタナティブ・ブログ

                                                              アジャイルの認知が進むにつれて、アジャイルという言葉がどんどん広がっている。アジャイル、という言葉の中にはいろんな要素が入っていることが分かる。もっと大きなものは、CI(継続的インテグレーション)を中核とする技術的なプラクティス群と、スクラムプロセスフレームワークのような、人と人との会話のプロトコルと協働関係を作るしかけだろう。自分の現状を、アジャイルに変えるためには、どうしたらよいだろう? "最近、「アジャイル」といっても中にいろんな要素があるために、「あなたのアジャイルは何のことを言っていますか?」と聞くことからはじめないと、話がかみ合わない"、と、Agile2012帰りのかわぐちさんと話していて、そのときに、かわぐちさんが描いた絵(たぶんどこかにある4象限の図)がいまひとつ自分にしっくりこなくて、私が描いて見た絵がこの絵だ。 あなたが、現状の開発現場を「アジャイル」に変えたい、と考え

                                                                アジャイルの「ライトウィング」と「レフトウィング」:An Agile Way:オルタナティブ・ブログ
                                                              • Playwrightを使ったE2Eテストを導入した話 - Uzabase for Engineers

                                                                はじめに こんにちは。ソーシャル経済メディア「NewsPicks」の QA/SET チームの海老澤です。 先日 弊社で E2E テスト実行するために Playwright を導入したため紹介させてください。 E2Eテストとは E2Eテスト(エンドツーエンドテスト)とは、ソフトウェア開発におけるテスト手法の一つで、アプリケーションが実際の運用環境と同様の条件下で正しく動作することを確認するためのテストです。 システムの開始点から終了点までを通じて、ユーザーの視点でアプリケーションのフローを追い、機能全体が連携して期待通りに動くかを検証します。具体的には、ユーザーが行うであろう一連の操作をシミュレートして、データがシステムを通じて適切に流れるかや、最終的なアウトプットが正しいかどうかを確認します。E2Eテストにより、部分的な単体テストや統合テストでは見逃されがちな問題を発見することができます。

                                                                  Playwrightを使ったE2Eテストを導入した話 - Uzabase for Engineers
                                                                • InfoQ: 「かんばん」をソフトウェア開発に適用する: アジャイルからリーンへ

                                                                  図1 かんばんとプル生産方式 図1は、かんばんシステムの抽象的なモデルです。図1で示されているのは、上流と下流の2つのプロセスであり、上流プロセスが下流プロセスに部品を供給しています。最終的な顧客に製品を供給するために、プロセスは部品を生産し、その部品を下流に流し込まなければなりません。しかし、多すぎてはいけません。過剰生産は最悪のムダだと考えられます。そこで、過剰生産を防ぐため、上流が完成した部品を下流に押し出す(プッシュ)のでなく、その代わりに、下流が上流から自発的に部品を取ってきます(プル)。部品が置かれる場所は、「ストア」と呼ばれます。(または、「スーパーマーケット」3 - 大野耐一氏 がアメリカのスーパーマーケットに行った時にかんばんの最初の考えを手に入れました。そこでは、店の人ではなく顧客自身が店の中で必要なものを取りに行きます。) ストアは上流に置かれ、WIPの「バッファ」や

                                                                  • 日本Ruby会議2011 1日目レポート[更新終了] | gihyo.jp

                                                                    本日7月16日(土)から18日(月)までの3日間にわたり、練馬文化センターにて日本Ruby会議2011(略称:RubyKaigi2011)が開催されます。本ページでは、1日目の模様を随時レポートしていきます。 スタッフの皆さんは朝から集まり、当日準備が行われました。 スタッフの方は、専用のTシャツ、STAFF腕章をつけていますので、もし会場で困ったことなどがあれば相談してみましょう。 オープニング 実行委員長、高橋征義さんの挨拶 本イベントの実行委員長である高橋征義さんからオープニングの挨拶があり、そのなかで「RubyKaigiは2006年から数えて6回目で、集大成かつ一つの区切りとなる最後にして最高の日本Ruby会議を楽しんでいってほしい」と述べました。 笹田耕一さん「日本Ruby会議2011[+α]プログラムについて⁠」⁠ 続いて、プログラム委員長である笹田耕一さんから、これまでのRu

                                                                      日本Ruby会議2011 1日目レポート[更新終了] | gihyo.jp
                                                                    • 継続的デリバリーのソフトウェア工学 | Agile Studio

                                                                      2022のアジャイル本紹介です。『継続的デリバリーのソフトウェア工学』は、久しぶりにソフトウェア工学を題した「アジャイル開発」の本です。もう一度、ソフトウェア工学の観点からアジャイルを説明していて、ま...

                                                                        継続的デリバリーのソフトウェア工学 | Agile Studio
                                                                      • 『Amebaの開発環境について』

                                                                        コンニチハ たぶんサーバサイドエンジニアの@pnskです。 約1年前に設立した、「Ameba Dev. Center」という 「Amebaの開発環境周りに関わる事であれば、何でもやる」というスタンスで いつか世の中に出しても恥ずかしくない開発環境とその文化をAmebaに根付けられたらなぁと野望を持った組織に所属しています。 さてはて。 今回は、エンジニアブログ執筆の機会をいただいたので、Ameba開発環境についてこしゃべりをしようと思います。 誰得情報ですが・・ Amebaの開発環境ですが、この1年でちょっぴり変わりました。 (誰も気づいていないかもしれないですけど・・・) topicでいうと、GitHubEnterprise、JIRA、HipChatが導入されました。 現在は ・ドキュメント管理はConfluence ・課題管理はJIRA、アジャイル開発補助ツールとしてJIRA Agil

                                                                          『Amebaの開発環境について』
                                                                        • Yum is dead, long live DNF | DNF

                                                                          Do you wonder why you don’t have yum package installed on the Fedora 22 clean installation and why you get warnings when calling /usr/bin/yum executable or any yum-util plugin about deprecation of Yum? You see right, Yum is gone. Literally. And DNF is the new default Fedora package manager. DNF is fork of Yum with the state-of-art SAT-based dependency solver and was supposed to replace Yum in Fedo

                                                                          • 「システム構築はどこから始めるべきだろうか。システム構築が終わったらこうなる、というストーリーを語るところからだ。」 - Qiita

                                                                            「システム構築はどこから始めるべきだろうか。システム構築が終わったらこうなる、というストーリーを語るところからだ。」アジャイル要求ユーザーストーリー はじめに ◆この記事は何? アジャイル開発における「要求」や「ユーザーストーリー」を細分化する記事です。 ◆対象は? 要求やユーザーストーリーを整理する方 アジャイル開発に関わる方 ◆ねらいは? アジャイル開発に関わる方が、何気なく使っている「要求」や「ユーザーストーリー」の解像度を上げること エンジニア人生に影響を与えたフレーズ 「システム構築はどこから始めるべきだろうか。システム構築が終わったらこうなる、というストーリーを語るところからだ。」は、書籍『テスト駆動開発』に出てくるフレーズです。 そして書籍『テスト駆動開発』の中で、私が最も印象に残っている文章です。 この文章に出会ってから、私は「言われた通りにシステムを作る」から脱却して、「

                                                                              「システム構築はどこから始めるべきだろうか。システム構築が終わったらこうなる、というストーリーを語るところからだ。」 - Qiita
                                                                            • Lean Startup リーンスタートアップ解説(1):An Agile Way:オルタナティブ・ブログ

                                                                              サンフランシスコ周辺で最近大きな話題になっている、リーンスタートアップ、について、簡単に導入解説したいと思います。 これによって、アジャイルは「既存の組織改革」という1つの出口から、「新しい起業の創業(スタートアップ)」という、もう1つの大きなビジネスホームグラウンドを見つけたように思います。 この資料は少し古くて、2009年に Eric Ries が Web2.0. Expo にて発表したものの一部です。オリジナルスライドはこちら。 「ウォーターフォール」、「アジャイル」、そして「リーンスタートアップ」、という3段階で説明していきましょう。 ウォーターフォール型の製品開発モデルでは、問題が既知で、解法も既知、という前提にたっています。計画したことが計画通りにうまくいけば、それでOKという世界観です。 ここでの進捗単位は、工程を1つ進む、ということ。となります。計画駆動の進め方です。 これ

                                                                                Lean Startup リーンスタートアップ解説(1):An Agile Way:オルタナティブ・ブログ
                                                                              • Redmineのプラグインが充実している - プログラマの思索

                                                                                昨年に比べると、Redmineのプラグインがすごく充実している。 いろいろ試してみてメモ。 【コードレビュー】 r-labs - Code Review - Redmine Redmineリポジトリ画面からコードレビューのチケットを発行できる。 UIも使いやすいし、チケットでレビュープロセスを管理できるから、ReviewBoardでわざわざコードレビューしなくても良い気がしてきた。 それぐらい素晴らしいプラグイン。 【Hudson】 r-labs - Hudson - Redmine RedmineからHudsonと連携できる。 以前は、Redmine - PluginSimpleCI - RedmineでしかCIツールと連携できなかったが、このプラグインの方がはるかに高機能。 Hudsonを使っているなら、このプラグインは必須。 このプラグインのおかげで、ビルド管理をチケット駆動開発に含

                                                                                  Redmineのプラグインが充実している - プログラマの思索
                                                                                • カンバンボードで業務を可視化・整理しよう - 組織に合ったカンバンの設計・運用をヴァル研究所の実践に学ぶ - Agile Journey

                                                                                  Agile Journeyをご覧の皆さん、こんにちは。ヴァル研究所の熊野壮真 / 小泉翔太です。 私たちの勤務する株式会社ヴァル研究所は、日本で最初に発売された経路検索サービス「駅すぱあと」を中心に、公共交通に関連するさまざまなプロダクトを展開しています。最近では MaaS (Mobility as a Service))といった、未来の移動のあり方を変えていくような取り組みにもチャレンジしています。 これらプロダクト開発の現場にはアジャイルの考え方が浸透しており、各チームでは現場ごとに合わせたさまざまな形のアジャイルの実践が見られます。その実践手法は多様ですが、各チーム、共通して力を入れているのが「カンバン」による仕事の可視化の取り組みです。こと「カンバン」に関しては開発部門のみならず、バックオフィス部門でも積極的に活用しており、その活用場面の多さ、バリエーションの豊かさは当社の特色と言

                                                                                    カンバンボードで業務を可視化・整理しよう - 組織に合ったカンバンの設計・運用をヴァル研究所の実践に学ぶ - Agile Journey