「アジャイルは死んだ」以降に残るものは何か -リーンソフトウェア開発を再評価し、自工程完結で全体観点で改善する - - Qiita
その結果、自分はすっかり言及の減ってしまったリーンソフトウェア開発や、それらの源流であるトヨタの生産方式、トヨタが現在取り組んでいる自工程完結を評価するのがよいのではないかと思い至った。本稿は、そういうポエムである。 本稿でいうリーン（ソフトウェア）開発とは何か？ 2003年にメアリー・ポッペンディークとトム・ポッペンディークにより提唱されたトヨタ生産方式を源流とするリーン生産方式をソフトウェア開発に適用した原則集。以下を指す。 リーンソフトウエア開発～アジャイル開発を実践する22の方法～ リーン開発の本質 エリック・リース氏のリーンスタートアップやオライリーのリーンシリーズとは異なるので注意いただきたい。 きっかけとしてのアジャイル方法論の違和感：結局、アジャイルでも多くの課題が残る。 「今回のプロジェクトがやりにくいのはウォーターフォールでやっているからだ」、「今回のプロジェクトが適当
ソフトウェアの開発にかかる時間の見積を廃止したいプログラマーたち | スラド デベロッパー
ソフトウェアの世界からプロジェクトの所要時間の見積をなくそうとする#NoEstimatesムーブメントについて、Mediumの記事が紹介している。所要時間を正しく見積もることは困難であり、時間の無駄だとプログラマーたちは主張する。一方、他のプロジェクト関係者は、計画を立て、プログラマーに責任をもって仕事をさせるために見積が必要だと考えている。妥協点はあるのだろうか。 記事によれば、「ソフトウェアプロジェクトの見積は誤っていることがあまりに多く、見積を作るのに時間を使えば使うほど、実際にソフトウェアを作成する作業時間が減ってしまう。また、マネージャーは開発者が適当に作った見積を契約上の締め切りのように扱う習慣があり、見積時間内に完成しなければ大騒ぎする。それだけではない。そのような結果を恐れる開発者は、より多くのエネルギーを見積という兎の穴に注いでいく。見積はヤクの毛刈りのように、実際の仕事
「Appleのソフトウェアへの不満」はOS Xの開発方法にフェデリギの「スプリントシステム」が採用されたからではないか？という匿名の元OS X開発者の書込みが面白い。
HackerNewsは投資会社YコンビネータLLCが運営する掲示板ですが、この掲示板に投稿されたスレッド”Apple has lost the functional high ground“のコメント欄に元AppleのOS Xエンジニアと現Appleエンジニアが書き込んで意見を交わしているとTUAWなどが紹介しています（HackerNewsは匿名性なの話半分ですが）。 元AppleのOS Xエンジニアの書込みは以下の通りで、彼の意見としては「騒がれているAppleのソフトウェア（OS X）の品質の話については昔の方が悪いと思う。昔の方が良かったという方は、古いOS Xが単に古く安定していたからで、近年のOS Xに違和感を覚えているならそれはクレイグ・フェデリギが導入した”スプリントシステム”が原因で更新頻度が頻繁になったからだと思います。」というものです。 Former OS X deve
「スクラムでは遅過ぎる」との声も。Google主催『Startup Tech Night』で聞いた、少人数で高速開発を進めるコツ - エンジニアtype | 転職type
転職・求人情報サイトのtype エンジニアtype スキル 「スクラムでは遅過ぎる」との声も。Google主催『Startup Tech Night』で聞いた、少人数で高速開発を進めるコツ 「ユーザーを中心に考え」て、「すばらしいプロダクトを作る」ことこそが、インターネットの世紀を生きる企業が行うべき最も重要なことである。良いプロダクトさえあれば、マネタイズやマーケティングの戦略もすべて後付けで立てられるからだ――。 Google会長のエリック・シュミット氏が著書『How Google Works』でこう述べるように、インターネットをベースにビジネスをする企業にとって、プロダクトを開発・発展させることこそがすべてである。ことさらスタートアップとなれば、開発・改善のスピードが大手と競争するための源泉となるだろう。 そんなスタートアップのエンジニアや、今後転職を考えるエンジニアを応援すべく、1
「これだけ! KPT」の感想 - プログラマの思索
【1】天野さんの体験談 ・チームの分裂を回避するためにKPTを実施 KPTを実施してみたら、実はチーム内では対立していなかった ・KPTのデジャブ 以前の会社で、完了報告書にベストプラクティスを教訓として残す作業があった 何が嬉しい？ 繰り返し型開発でKPTを実施したら、自然にプロセス改善された Keep＝ベストプラクティス、教訓 Problem＝問題 Try＝対応策 【2】KPTの使い方 ・学びを整理するKPT 教訓を残す ・現状打破のためのKPT 行動を促す より良くするため 問題を取り除くため ・カイゼンのKPT 継続的改善のため Problem→Try→Keep 問題解決 Try→Keep 新しいことに挑戦する Keep→Try→Keep 良かったことをもっと良くする 【3】PDCAサイクルを回せない管理職が多い ・理由：PDCAを回した経験がない プロセス改善の経験がない →PD
顧客に価値を届ける、ってなんだっけ - (define -ayalog '())
2013-12-09 顧客に価値を届ける、ってなんだっけ 開発 日記 最近、@syobochimのブログを読んでいたら、こんな言葉が書いてあった。 顧客に価値を届けたい。 私はいま、価値届けられてるんだろうか。 アジャイルサムライを読んだら意識高まってつらい - そこに仁義はあるのか(仮) 僕はどうだろうか。今のプロジェクトはありていに言えば"炎上"している。 そんな中で「誰の考え方が一番正しい」のか分からなくなった。ので、今日はそんな話を書いてみようと思う。 この話の登場人物 あやぴー 僕です。 マツダさん 僕と同じ会社の先輩。エンジニア歴10年位。 モリさん 僕と同じ会社の上司にあたる人。エンジニア歴20年位の大ベテラン。 イノウエさん 元請けの会社に8月くらいに中途で入社したエンジニアさんで立場的にはプロジェクトリーダー(PL)的な感じ。転職するまでPL1とかVBとかのお仕事を
久々に壮絶な自爆、というかブーメランを見ました。 - 30近いおっさんのブログ
「おい！どの口がアジャイル出来るって言ってるねん！」 さて、私にしては珍しくブチ切れ気味で記事を書いているのでこんな事書いていますが、ここからは、効果を本当に上げるアジャイル開発を実施したいときのリクルートで、どういうスキルを持った人を雇えばいいか？という話を進めたいと思います。これはとてもシンプルな一言で言えます。 テスト駆動開発が適切にできる能力があること この一言につきるのです。クライアントの皆さんは、是非アジャイルベンダーを雇うときはプログラマの人にこの能力を要求してください。注意しないといけないのは、テスト駆動が適切にできていないプログラマは、わかっていない事すらわかっていないこと、そして、営業さんとかマネージャさんのレベルだと、「テスト駆動が適切にできる人かどうか見分けがつかない事」が問題になってきます。これは、まともにテスト駆動ができる人がその人と話をすればテスト駆動をちゃん
【書評】アジャイルソフトウェアエンジニアリング
アジャイルソフトウェアエンジニアリング (マイクロソフト関連書)著者／訳者：Sam Guckenheimer、Neno Loje、日本マイクロソフト監訳、TFSUG監訳、トップスタジオ出版社：日経BP社発売日：2012-05-24単行本：320ページISBN-13：9784822294687ASIN：4822294684 日本マイクロソフトの長沢さんから献本いただきました。ありがとうございます！ まず結論から言うと、いわゆるアジャイルな開発におけるライフサイクルやプロセスと技術の関係を「実践」という観点でまとめた本としてオススメできる本だと思う（ただしアジャイル初心者の人にとっては難しいです）。 本にマイクロソフトやVisual Studioという文字があるので、それ以外の環境で仕事をしている人はスルーしてしまいがちですが、内容はVisual StudioやTeam Foundation
Scrumチームを編成する際の必読記事２点 - Always All Ways
昨日のエントリー（QA versus Testing! Antagonism or Symbiosis? - Always All Ways）でQA/テストからの視点でチーム編成に少し関連することを書きましたが、一般的に、Scrumにおけるチーム編成を行う上でポイントとなることが２点あります。それは、 チーム分けの切り口（フィーチャーチームvs.コンポーネントチーム） メンバーの多能工化の進め方 私自身も過去に複数チームで一つのシステムを開発するような組織へのScrum導入・展開を推進したときにメンバーからよく聞かれました。その時に自分自身で繰り返し参照したり、メンバーに読むことを進めたりした文献がありますので、少し前の文献になりますが改めてここで紹介しておきたいと思います。（「こんなのあるから、一度読んでみて！それから、うちの会社でどうすればいいか一緒に考えよう！」みたいな感じでディスカ
RedmineへScrumのアイデアを注入 - プログラマの思索
Redmineフォーラムで、Scrumのアイデアを実現しようと議論して、実際にプラグインが公開されていたので試してみた。 下記は、RedmineへProdctBackLog、SprintBackLog、TaskBoard、バーンダウンチャートの機能を追加しようとする野心的なプラグイン。 その時の画面をキャプチャしてみた。 【元ネタ】 Redmine - Agile methodologies and Redmine 【RedmineへProdctBackLog、SprintBackLog、TaskBoardを追加するプラグイン】 scrumalliance's redmine at master - GitHub 【Redmineへバーンダウンチャートを追加するプラグイン】 scrumalliance's redmine_burndown at master - GitHub 【1】Pro
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
スクラムガイド - Scrum Guide 2020 年 11 月
すべてが決まっているプロジェクトの成功の陰にあるスクラム
スクラムへの盲信
継続的デリバリー – Ryuzee.com