私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い - メソッド屋のブログ
私はソフトウェアの専門家としてお答えすると、ウォータフォールは何のメリットも無いというのが私の意見であることを共有しておきたい。そういう意見に至った経緯をこのブログで書き留めて置きたい。 尚、これは所属会社の見解ではないことは明確にしておきます。 サム・グッケンハイマーの一言 私は DevOpsのエバンジェリストで、それ以前からアジャイル開発をかれこれ１５年ぐらい実施し、導入の支援をしている。私はかつては、日本の環境の制約の中で如何にアジャイル開発のメリットを最大に引き出すか？ということを考えていた。 ウォーターフォールに対する立場も、真っ向から否定するものでもなく、現状もあるし、それに慣れている人もいるし、実際ウォーターフォールでも失敗しない人も居る。だから、人にウォータフォールのメリット・デメリットを聞かれた時も「変化しないものに関してはウォータフォールはいいのかもしれない」と回答して
「それ、アジャイルできてへんのちゃいますか？」チェックリストの公開 - メソッド屋のブログ
DevOps を導入して、リードタイムの短縮などの効果を出したい時に、前提条件となっている「アジャイル」がまだ導入できていないケースが多い。そういったケースでは、まずアジャイル導入のご支援をすることもよくある。 そういった支援に入ると、「アジャイル導入前提」で構成されたはずのプロジェクトであっても、全然「アジャイル」のポイントを外しているというケースは珍しくない。更に問題なことに、「アジャイルをできます！」と言っているベンダーさんを連れてきても、全然ポイントを外しているというケースすら珍しくない。今回のブログではそういったケースでも、簡単に確認できる、「アジャイルになっていないかもしれない簡単なチェックポイント」を対策付きでいくつかご紹介しよう。 スプリントの中で、ウォータフォールを実施するのではない。それはミニウォータフォールというバッドプラクティスだ。 1. 進化型設計ができていない
Scrum ではコードレビューをどうやっているか？ - haradakiro's blog
森崎先生のソフトウェアレビューの講演を聴いて、今やっているレビューの方法をまとめときたいと思ったので、まとめてみます。今回は、コードレビューの話です。Scrum ではといっていますが、レビューのやり方はチームによって違うので、あくまでも例ですよ。PBI とか、仕様、ドメインモデルのレビューの話はまたこんど。 レビューの目的は、もちろん作成するプロダクトの品質向上です。障害を検出するのも、もちろん目的ではあるのですが、それ以降のスプリントで作成されるコードで同じ障害を作り込まないのが目的としては大きいです。そのため、レビューはプロジェクトもしくはチーム立ち上げ後、数スプリントで重点的にやります。後はスプリントの振り返りでレビューをやりたいが出てきたら、チームで決めます。 レビューのやり方 基本はチーム全員で集まってやります。最大２時間。それ以上やっても集中力が続かないので。プロジェクタで対象
アジャイルソフトウェア開発宣言
私たちはソフトウェア開発を実践あるいは実践の手助けをする ことによって、よりよい開発方法を見つけだそうとしている。 この活動を通して、私たちは以下の価値に至った。 プロセスとツールよりも個人と対話に。 包括的なドキュメントよりも動くソフトウェアに。 契約交渉よりも顧客との協調に。 計画に従うことよりも変化への対応に。 すなわち、左側に書かれたことがらに価値をおきながらも、 私たちは右側に書かれたことがらにより価値をおく。 Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler
アジャイルの「顧客に価値を届ける」の嘘と本当 - mizchi log
酔った勢いでアジャイルについて思うところを書く。 顧客に価値を届けるのは誰か 顧客に届く価値 = 目に見える成果物、という評価は、フロントに近い人間しか評価されなくなる傾向を抱え込む。顧客に価値が届くまでには段階がある。複雑なものほどワークフローが長大になる。お互いの価値を見積もれるのは、小さいチームでお互いの職種について理解がある場合の理想であり、多くの場合理想は理想である。大きなチームほど、フロントに遠い人間は自分の価値を伝えるのが難しい。 難しいことを難しいということ エンジニアが自分の仕事について、エンジニア以外への責任説明を果たそうとすると努力は必要だが、必ずしもそれが伝わるとは限らない。 難しいことを難しいと言えないと、「それってすぐできるんでしょ？」という展開になりがちで、「任せてくれ！」と言えるのはかっこいいが、誰しもがスーパーエンジニアではない。そして見積もりに失敗する。
ワンクリックデプロイ 〜いつまで手でデプロイしてるんですか〜 #devsumiA
2013/2/15に目黒雅叙園で行われたデブサミ2013 15-A-7セッションの資料です。Read less
自動テストの知識をプログラマは知らないと恥ずかしい | Act as Professional - hiroki.jp by HIROCASTER
１．テストやデバッグに使う時間を削減して、プロダクトコードの品質をあげる 単体・結合・統合テストは全体の8〜25%が費やされるべきであるといわれています。ですが、デバッグは開発の50%におよぶ場合があると言われています。これは、テストには本来多くの時間を割くべきであるが、デバッグが膨大な時間に及ぶことが事実としてあるということです。 プログラミングについてあまり知られていない７つのことより １．スキルのレベルにかかわらず、プログラマーは全時間のおよそ１０～２０％をコードを書くのにあてており、たいていのプログラマーは完成品ができるまで一日あたりおよそ１０～１２行のコードを書いています。優秀なプログラマーは残りの９０％のうち大部分を、考えること・調べること・最高の設計を見つけるための検証作業に費やします。ダメなプログラマーは残りの９０％のうち大部分を、やみくもに変更と検証を繰り返すようなデバッ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
アジャイルはプロジェクトをデスマーチにするか