SI案件でアジャイル開発を進めるときの勘所
みなさんこんにちは。@ryuzeeです。 10月に発売となった『プロダクトマネジメント - ビルドトラップを避け顧客に価値を届ける』ですが、まだお読みになっていない方是非よろしくお願いします。 また、ここ数か月新しい書籍の翻訳に取り組んでいて、来年の春くらいには発売になるかと思います。この本も楽しい本だと思うので是非楽しみにお待ち下さい。 さて、先日、プライベート講演で、SIのコンテキストでアジャイル開発を進める場合に、どのような点に気をつけておくとよいかを話して来ました。 汎用的な内容で読者の方の参考になるかと思いますので、資料を公開しておきます。 以下、資料だけ見てもわからない方向けの解説です。 TL;DR（結論）SI案件でアジャイル開発を適用する場合、顧客側がアジャイルを正しく理解していない可能性があるので、案件開始前に教育すべしステークホルダーマネジメントは重要。これはウォーターフ
全訳版！オランダの銀行INGの「アジャイル」な組織変革がスゴすぎます｜とくさん｜MYCOPING
マッキンゼー: 「アジリティ」をどう定義しますか？ ING: アジリティとはまず「柔軟性」、そして新しい方向に向かってすばやく適応できる組織の力がポイントです。前例踏襲や官僚的な部分を避けて、みんなの力を引き出そうとするわけです。 また、能力が高くバランスの取れたプロフェッショナルを育成するという側面も重要です。アジャイルであること、は単にIT部門やその他いろいろな部門を変えるというのに留まりません。大切なのは、End to Endで一貫した原理を持つ、マーケティング、プロダクト、そして営業の専門家、UXのデザイナー、データアナリスト、そしてITエンジニアといった多様な分野の人たちからなるチーム - Squadと我々は呼んでいます - を作ること、そしてそのチームが、顧客のニーズを解決することに注力し、共通の成功の定義のもとに力を合わせるのが大切です。 このモデルはハイテク企業のやり方を参
「開発をアジャイルで」「でも契約は一括で」と言ってくる顧客がいたらどうすべきか？ - ミッションたぶんPossible
はじめに このブログでは言及してませんでしたが、宣言どおり無事転職して、今年の1月から新宿のSIerで働いています。まぁその辺の話は来月あたりの暇な時にでも書くとして*1、今回は別の話。 ついこの間、その新会社で、PM的役割をこなす社員を対象に開かれた「法務研修」という名のついた社内セミナーに参加しました。内容は、SIerの立場で契約に携わる時にどうすべきか、というもの。SIerあるあるの契約にまつわる揉め事を事例に、それを回避するために何に気をつけるべきか、といったことが扱われました。まぁこれ自体は目新しい内容ではなく、SIerに所属する者なら当然知っておく・気をつけるべきことばかり。再確認という意味では非常に有意義でしたが、それ以上でもそれ以下でも無かったなぁ、というのがオレの率直な意見でした。……研修本編終了までは。 ちょっとこれ大丈夫か、と思ったのは、Q&Aに入ってから。社員の誰か
銀の弾とアジャイルについてのメモ (Agile is a Silver Bullet) - ari's world
銀の弾とアジャイルについてのメモ (Agile is a Silver Bullet) 2018年10月9日 要点 1986年にソフトウェアエンジニアリングについて書かれたフレデリック・P・ブルックス氏（以下、Brooks）『人月の神話』「銀の弾はない」はすごい（久しぶりに読み返した）。まじリスペクト。 本質的な困難と、その攻略を通じて、アジャイル開発を理解するとスッキリする（個人的な見解です）。 はじめに アジャイル開発は、ソフトウェアエンジニアリングにおいて迅速かつ適応的にソフトウェア開発を行う軽量な開発手法群の総称である。 アジャイル開発の「なぜなのか(WHY)」や「どのような問題を解こうとしているのか」を、自分なりに整理したかった。その時、Brooks『人月の神話』を改めて読んで、びっくりした。これは、すごいと。 2018年10月9日に書いたメモがある。まだまだ整理や考える余地はあ
アジャイルにおける事前合意について - arclamp
昨年末、ブログをネタにTwitterで議論したことを akipii さんが「アジャイル開発にはモデリングや要件定義の工程はあるのか、という問題とその周辺: プログラマの思索」というエントリにまとめてくださいました。ありがとうございます！。 ブログで書かれたことに直接の返答にはならないのですが「アジャイルにおける事前合意はどうあるべきか？」ということを書きたいと思います。 アジャイルは最初に全てのCDSを決めない まず、狭義のアジャイル開発プロセスは優れたマネジメント手法です。システム開発を評価するQCDS（品質/コスト/期日/スコープ）ですが、Q（品質）というは「そのシステムにとって問題ないレベルにする」でしかないので、CDSの調整が論点になります。 ウォーターフォール型開発というのは、 「スコープは最初に確定」し、 「コストや期日はスコープを達成するために必要な分を最初に設定」し、 必要
泥の中のアジャイル - もがき続けてたどり着いたプログラミングという形 -
2017年11月8日（水）のエンタープライズアジャイル勉強会にて。
技術なきマネジメントの衰退とその対策 - メソッド屋のブログ
今回は、マイクロソフトにいて自分が感じているIT業界の大きなスタイルの変化の兆候とその対策について書いてみた。今回もいつも通り、単に自分の意見をシェアしているだけであって、他の人にどうこうしろと言いたいわけではない。ただ、日本のIT業界が米国に追いつき、追い越すための議論のきっかけになるといいなと思っている。自分も楽しみながらも、もがいていることと、そこで見えた光について書いてみたい。 世界は「技術力」の重視に向かっている 私のキャリアは、某大手SIerを12年勤めた後、ITコンサルティング企業に３年在籍して、主に超上流を実践した。その後独立し、ビジネスモデリングから、アジャイルや、DevOpsの導入支援、マネジメント、開発などを実施していた。 私がマイクロソフトを受けてみようと思ったのは、友人からの推薦の要素が大きかったのだが、その背景では、海外で勤務したいという希望があったのと、「技術
ユースケースとユーザーストーリー - 勘と経験と読経
いつか読もうと思っていた名著「ソフトウェア要求 第3版」を読んでゐる。ユースケースとユーザーストーリーについての説明がすごい腑に落ちたので勢い余って書き付けるもの。アジャイル開発プロセスとユースケースの関係について。 ソフトウェア要求 第3版に関する他の記事はこちら ソフトウェア顧客の要求に関する権利宣言と責任宣言 - 勘と経験と読経 ユースケースとユーザーストーリー ユースケースとユーザーストーリーは、非常によく似ている。両方ともに、異なる種類のユーザーが、ソフトウェアシステムとの相互作用を通じて、何を成し遂げる必要があるかを理解しようとしている。しかし、この2つのプロセスは、図に示すように、似たような出発点から始まって、異なる方向に進んでいく。 ソフトウェア要求 第3版 第8章 ユーザー要求の理解 ユーザーストーリーはユースケースの簡略バージョン、というイメージを少し持っていたけれども
厳格なウォーターフォールの金融系IT企業が、スクラムを採用した初のアジャイル開発プロジェクトの経緯と成果を語る（前編）。Regional SCRUM GATHERING Tokyo 2016
厳格なウォーターフォールの金融系IT企業が、スクラムを採用した初のアジャイル開発プロジェクトの経緯と成果を語る（前編）。Regional SCRUM GATHERING Tokyo 2016 金融系システム開発会社として、しっかりしたプロセス管理の下でウォーターフォールによる開発を続けてきたニッセイ情報テクノロジー株式会社。 同社は、1月19日と20日に都内で開催されたアジャイル開発手法の1つ「スクラム」をテーマにしたイベント「Regional SCRUM GATHERING Tokyo 2016」で、同社として初めてスクラムを採用したプロジェクト開発の事例を紹介しました。 金融系の開発で求められる高い品質などをアジャイル開発の特性を活かしながらどのような手法で確保したのか。そして厳格なプロセスで開発してきた文化を持つ企業の中でアジャイル開発を成功させた要因は何だったのか。事例から読み取る
ユニットテストを書かないことについて - Line 1: Error: Invalid Blog('by Esehara' )
はじめに 最近は、同じ職場で働いている人に対して、『テスト駆動開発入門』の本を貸したり、自分自身でも全く更地のところにユニットテストを書くという作業をやったり、あるいは実装中にもユニットテストを書かないと、コードを書く手が少し滞ってしまうくらいには、テストに依存している自分がいる。 さて、ここ最近で一連のテストの話が各方面から出ていて、それらの議論について興味深く感じる一方で、たとえば自分はそうだけど、「執拗にテストを書いているけれども、これで前に進んでいるんだろうが」という罪悪感みたいなのを抱えている人というのは、それなりにいるんじゃないかと。特にユニットテストを腐らせて、テスト自体を負債にしてしまった人であるなら特に。 ここ最近の、アジャイル開発であったりとか、あるいはプログラマのための本みたいなのを開いたりすると、たいてい「他のことは良いからテスト書け」と載っている一方で、見回してみ
とりあえず30分でひととおり分かった気にはなれるアジャイル入門
2012/12/22(土)の社内で開催した「プレゼン祭り」で発表した内容です。アジャイルに全く触れたことが無い人を対象にしたつもりが、「難しい」「内容が盛り沢山で覚え切れなかった」「寝ちゃった」などなどとあまり好評ではなかったのですが、自戒の念も込めて公開しておきます。 対象は「ウォーターフォール開発しか体験したことのない経験5〜6年程度の若者」です。 ※2022/04/11追記 Speaker Deckに移行しました。 https://speakerdeck.com/takigawa401/toriaesu30fen-tehitotoorifen-katutaqi-nihanareruasiyairuru-menRead less
こんなプログラマはアジャイル出来ますって言ったらアカンやろ - メソッド屋のブログ
最近、とある機会があって、いろんなアジャイルが出来るといってくるベンダーさんとあう機会があるけど、正直「おい！どの口がアジャイル出来るって言ってるねん！」って思う事がむっちゃくちゃ多い。 今は確かにアジャイル開発ブームで、世間では引き合いも多いらしい。いろんなベンダーの営業さんが、「うちもアジャイルできます」って言って営業してはるけど、マジでちゃんと自社でできるか調査してから営業してほしい。私はアジャイルを１０年以上やってるけど、元々は「この方法やったら、お客さんにホンマにええアプリを届けれるんちゃうか？」と思ったところから来ている。 それが、今や猫もしゃくしもアジャイル出来ますとか言って、ろくにアジャイルも出来へんのに売りつけて、結局効果がでなくて、「やっぱアジャイルなんかアカンやん」ってなるのがむっちゃくちゃ嫌なのだ。 これって数十年昔のオブジェクト指向ブームと一緒やん。当時のオブジェ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Overview - Large Scale Scrum (LeSS)
アジャイルひよこクラブ – Medium
タウンワークをドライブさせるためになんちゃってアジャイルをやめた話 #devsumi #devsumiB / devsumi2018