20200303 AWS Black Belt Online Seminar AWS Cloud Development Kit (CDK)

国内でのアジャイル開発の普及と共に、アジャイルという言葉が指す内容にも広がりがでてきました。同じ「アジャイル」という言葉を用いたとしても、それが何を指すのかを注意深く理解する必要が出てきたといってもいいでしょう。 そんな現状を、アジャイル開発の第一人者である平鍋健児氏がブログ「An Agile Way」にポストしたエントリ「アジャイルの「ライトウィング」と「レフトウィング」」で、非常に分かりやすい図と共に整理しています。以下に許可を得てその主な部分を転載します。 アジャイルの「ライトウィング」と「レフトウィング」 アジャイルの認知が進むにつれて、アジャイルという言葉がどんどん広がっている。アジャイル、という言葉の中にはいろんな要素が入っていることが分かる。もっと大きなものは、CI（継続的インテグレーション）を中核とする技術的なプラクティス群と、スクラムプロセスフレームワークのような、人と人

こんなエントリを書いて早4ヶ月。 なんでアジャイルに取り組みたいか - kaji_3's blog BtoBで対価を頂いてアジャイル開発として遂行した案件が先日終わったのでKPT形式でふりかえります。 前提 期間一ヶ月半 Scrumを参考にしてプロジェクト運用 イベント用WEBアプリケーション 案件の内容をぼかして書いているので、一部整合性の合わない記述があるかも知れませんがご了承ください。 Keep 高い顧客満足度 プロダクトオーナーから「自分たちの意志が反映できた物を作ることができた」とコメントを頂きました。フィードバックから実際のものができるまでのスプリントという考えについても好評でした。顧客の社風として良い物を最後まで模索するという考えがあるとのことで、仕様凍結後の変化は、仕様変更として好まれないウォーターフォールには不満があったとのことでした。 育つシステム 当初想定されていたシ

ここ最近の「アジャイル」という言葉の使われ方に違和感を感じています。 年々システム開発のプロジェクトは、短納期化と低コスト化の流れが進んでおり、それによってリスクが増して且つ利益の出にくい状況になりつつあり、多くのシステム開発を請け負うシステムインテグレータは様々な取り組みを進めています。 そして、その一つとして期待されているのが「速い・安い」を実現する「アジャイル開発」だと言うわけです。もはや、まるでファストフードです。 大手システムインテグレータが集まってアジャイル検定を始めるようです。一部引用します。 アジャイル検定の本格運用に向けた、アジャイルソフトウエア開発技術者検定試験準備委員会を設立 近年、ソフトウエア開発では、厳しい経済不況などの影響を受け、ユーザーの要件を確実に、高品質に、より短期間で提供することが求められています。このような環境の下で、注目されているのがアジャイル開発手

永和システムマネジメントさんのご厚意により、去る 3 月に Agile Japan 2012 での基調講演を提供するために来日された Jonathan Rasmusson さんに対するインタビューを実施させて頂きました。 Jonathan さんは、「アジャイルサムライ」というアジャイル開発の入門書の著者です。 「アジャイルサムライ」は日本で空前のブームを巻き起こしており、現在日本の各地で勉強会（道場）が開催されています。 インタビューでは、以下の 4 つの分野に渡り、Jonathan さんに質問をしました。 1. Jonathanさんのこれまでの経歴 2. アジャイル開発一般 3. アジャイルサムライ 4. プライベートな生活 今月と来月の 2 回に渡り、Jonathan さんへの突撃インタビューの結果をお届けします。 1. Jonathanさんのこれまでの経歴について -- 今日は、イン

みなさんこんにちは。@ryuzeeです。 昨年夏に同人誌として刊行された「Ultimate Agile Stories」に寄稿させていただいたのですが、昨日のJim Coplien氏の認定スクラムマスター研修でもコミットメントの話が出ていましたので、参考までに僕の考えを転載します。 なお、Ultimate Agile StoriesはIteration2として今年も刊行を計画されるそうなので、是非動向をウォッチしておいてください。昨年は平鍋さんをはじめとする日本のアジャイルコミュニティを牽引するすごい方たちがたくさん寄稿されていました。 システム開発をしていると「コミットメント」という単語をよく耳にするだろう。アジャイル、特にスクラムの文脈においては「コミットメント」は重大な意味を持っている。本稿ではシステム開発における「コミットメント」とは何なのかについて考察してみたい。 1. 辞書の定

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

はじめに 社内アジャイルエバンジェリスト（自称）として活動する事にしました。今週末に「アジャイルとはなんだっけか」というLTを社内の歓送迎会でやるテロを計画中でした。そんな私を後押しするかの如く色々状況は変わってきています。 NTTデータ、3年間で社員1000人をアジャイル開発人材に育成 - ニュース：ITpro 若手リーダー層を対象としたアジャイル開発研修を開始　2012年4月17日 | ニュースリリース | NTTデータ アジャイル開発検定試験の準備委員会を日本IBM、NTTデータ、日立ら7社が設立 － Publickey 最近、自分で発信する事で色々な方の考えに触れる機会が増えました。ただ、意見の触れる事は影響を受ける事であり未熟な私としては「なんでこれをやりたいと思ったか」を自分の言葉なのか人の言葉なのか区別が付きにくくなってきました。自分の考えがブラッシュアップされるのはよいとし

わたしはまだ本格的な(?)アジャイル開発をやったことは無いけれども、周りのウォーターフォール脳に比べたらアジャイルプラクティスをプロジェクトに取り込むことが多い（プロジェクトマネージャーの立場で、スクラムマスター的に推進）。いくつかのプロジェクトを終えて、結果を振り返ってみるとチームメンバーの平均的な帰宅時間は早まったし、休日出勤することも減ったと思う。QoELは確実に上がったと思っていたけれども、一部のエンジニアからは「キツかった」と言われて驚いた。 アジャイルの前のほうが楽だった？ 「第5回 TFSUG：ウォーターフォールからアジャイル、リーンへ」での発表で、アジャイル開発に挑戦した方がやはり「前のほうが楽だった」というような事を書いている。 http://kaorun55.hatenablog.jp/entry/2012/04/17/001312 第5回TFSUG WFからAgile

このエントリーはStartup Scrumなブログではありません。Scrumというものに興味をもった当時23歳うさみみ系エンジニアがScrumという言葉を借りて開発してみた。という話です。2011/3から2011/5あたりの話。 2011/3。僕はデスマ４年目を終えて、新しいプロジェクトに移りました。 あるプロジェクトの中の4人チームのうちの1人として。もちろん僕はいちばん下っ端として。 （元請け会社の2人、当時同じ会社だった先輩、僕の4人） そのプロジェクトはWFだったんですけど、タイムボックスやリスク管理について理解があることは雰囲気で伝わってきました。 僕はその頃勉強し始めていたあらゆることを現場で試してみたいって強く思いました。 僕はMercurial、Jenkins、Groovyを趣味的に使い始めていて(MercurialとJenkinsは2010/10から。Groovyは201

私は夏休みの宿題のやり方を教えてもらったことがありません。約2ヶ月という限られた時間で、どういう風に消化していくと良いのかを学習したことがなかったのです。 夏の終わりに24時間テレビが放送されますが、あれを見ながら、答えをチラ見し、綺麗なドリル(*1)を1冊消化するのは忘れられない子供の頃の思い出です。 この経験はソフトウェア開発にも似ていて、開発の手法を知らなければ、良い結果を生むのは難しいのです。不幸なことに、夏休みの宿題のように明確に何をやるべきなのか、明確では無いのです。 夏休みの苦い思い出と、ウォーターフォールっぽい大失敗プロジェクトの経験をいくつか得た上で、アジャイルソフトウェア開発を学ぶことによって、ソフトウェアのつくりかたを学びました。 これは、中小のSIerでも、イケてるWEBサービスを提供している会社でも教えてくれたことではありませんでした。そう、夏休みの宿題のやり方を

Rustが再評価される：エコシステムの現状と落とし穴 In this article, we share findings and insights about the Rust community and ecosystem and elaborate on the peculiarities and pitfalls of starting new projects with Rust or migrating to Rust from othe...

先週の水曜日（10月19日）に、アジャイル開発手法「スクラム」を学ぶイベント「Scrum Gathering Tokyo 2011」が都内で開催されました。 スクラムを実際に導入した事例として紹介されたのが「Yahoo! JAPANにおけるアジャイル開発、スクラムへの取組み ～組織と現場から～」のセッションで紹介されたヤフー株式会社の例。 同社は2名の担当者が中心となり、社内セミナーなどでスクラムに興味を持ってもらうことで社内の自主的な変化を促す一方、評価制度や内部統制などの制度を調整する担当役も置くことで制度面での変化も後押しするなど、スクラム導入の具体的な手法が紹介されました。 そのセッションの内容を紹介しましょう。 2名で分担してアジャイル開発の推進を開始 ヤフー株式会社 R&D統括本部プラットフォーム開発本部本部長 志立正嗣氏。 組織の立場から見て、どういう風にスクラムを導入してき

「ソフトウェア見積り」を読んだ後に「アジャイルな見積りと計画づくり」を読み直したら、とても理解しやすかった。 理解できたことをメモ。 間違っていたら後で直す。 ※追記：一部修正した。 ※追記：Velocityの計算方法を「塹壕よりScrumとXP」から参照するようにした。 【元ネタ】 Twitter / @akipii: 見積について色々考えている。1.0MD(人日)という単位は規模・出来高・工数という複数の意味を持ち混乱しやすいから、ソフトウェア開発の計画づくりに支障をきたしているのではないかという仮説を考えている。その考えを深めるとScrumのストーリーポイントはよく考えられた概念だと思う。 アジャイルサムライで一番難しくて面白い概念～Velocity: プログラマの思索 ソフトウェア開発に特有な技術～ソフトウェア見積り: プログラマの思索 チームは加速するのか～Velocityの使い

メモ。 アジャイルとウォーターフォールを対比させるのは違和感があった。ので、少し考えてみた。 アジャイルソフトウェア開発宣言にある「包括的なドキュメント」とか「契約交渉」とか「計画に従う」とかと、「対話」「顧客との協調」「変化への対応」とかは、わりとばらばらなお題目が並んでいるように見える。少なくともこれがMECEだと思う人はいないと思う。 ばらばら並んでいる項目の共通点、類似点は何か。それはたぶん、「顧客」と「開発者」という2つのロールを仮定して、そのロールの人同士の間でのコミュニケーションコストを最大化する（という言い方が悪ければ「最大限許容する」と言い換えてもいい）というものだろう。文書や契約や計画は、あらかじめ（多少はコストをかけて）まとめておけば、それ以降のコミュニケーションは省略できる（ような気になる）、というものだろう。ツール・プロセスも同様だ。一方で、個人や対話、顧客との協