スクラムとウォーターフォールの違いはどこにあるのか？ シミュレート可能なモデルを構築して検証する
社会人エンジニア向けの教育プログラム「トップエスイー」から、エンジニアの皆さんに対して有用な情報をお届けするコーナーです。ソフトウェアを開発するにあたり「ウォーターフォールモデル」と「アジャイル開発」は比較対象として取り上げられ、どちらが優れているのか、あるいはどちらが正しいのかという議論がよく見られますが、果たして比較可能な対象でしょうか。これらに限らず、さまざまな開発手法の違いを客観的に比較することができないだろうか、といった疑問を持ちました。客観的な基準があれば、何を採用するのかといった議論もスムーズに行えるはずです。任意の開発手法に対する比較は困難ですが、「ウォーターフォールモデル」と「アジャイル開発」に絞ったモデルを作成することで、それぞれの違いを比較できるところまで示すことができました。 開発手法の選択はなぜ難しいのか？ システム開発を進めるための手段には多種多様なものがあり、
Agile も DevOps も銀の弾丸なんかじゃない
This browser is no longer supported. Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support. ……と、のっけから噛みつかれそうなタイトルを掲げてみたのですが；、ここ最近、立て続けて数件、「いやそれはアジャイルとか無理だろ；」的な話があって、ちょっとエントリを書いてみようかと思った次第。どんな話だったのかというと、 アジャイルとか DevOps やれば必ず開発生産性上がるんでしょ？ → そんなわけないでしょ；。 これからの開発は当然アジャイルとか DevOps でしょ！ → そんなわけないでしょ；。 みたいな話；。2 年ほど前に、「続・拝啓『変わらない開発現場』を嘆く皆様へ ～ ウォータフォール
https://link.medium.com/1jsAtPLA6T
デザイン思考は、問題を探索・解決するための方法です。リーンは、私たちの信念を試し、適切な成果につなげる方法を学ぶためのフレームワークです。アジャイルは、ソフトウェアの変化していく状況に適応するための方法です。 デザイン思考は、能力と学習に関するものです。スタンフォードd.schoolのCarissa Carter主任は、デザイナーを高める能力について、素晴らしい記事を書いています。たとえば、曖昧さ、共感的学習、統合、実験などが、その能力として挙げられています。意味を生み出し、問題の枠組みを設定し、潜在的な解決策を探索する、デザイナーの能力が重要なのです。 『誰のためのデザイン？』の著者であるドナルド・ノーマンは「デザイナーは最初のアイデアに満足しない」と述べています。あなたも考えてみてください。最初のアイデアが最高のアイデアだったことはありますか？意味や新しいアイデアが生まれるのは、物事を
[Agile]Agileチームのアセスメントの方法 | Ryuzee.com
みなさんこんにちは。@ryuzeeです。 アジャイルな開発を行っているチーム（やっていなくても構いませんが…）のアセスメントを行う方法について考えてみました。 あくまで一例でこれが最適とは限りませんが、コーチとしてリアルなプロジェクトの具体的なところではない原点の部分を軸にしてチームの成熟度を把握できるようになりたいなぁということで、アジャイルマニフェストの12の原則をベースにして考えてみました（今後継続的に足していったり、現場で試してみる予定です）。 1. 顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。プロとして顧客のために行動できているか正しいことを行っているかどうかを常に意識しているか顧客のためとは顧客の言う事をすべてやることではないことを理解しているか価値は提供する側が決めるものではないことを理解しているか顧客にとって価値がなかったらどうなるか理解しているか2
![[Agile]Agileチームのアセスメントの方法 | Ryuzee.com](https://cdn-ak-scissors.b.st-hatena.com/image/square/df332fc34a3fa52667d1fd10e539a45e2f6a3550/height=288;version=1;width=512/https%3A%2F%2Fwww.ryuzee.com%2Fcontents%2Fblog%2Fimages%2F4657%2Fthumbnail.png)
アジャイル開発導入時に知っておきたい成果と効果測定のポイントとは？
cambiodefractal via Frickr アジャイルムーブメントの影響もあり、アジャイル開発を最近はじめた。またははじめようとしている方も多いと思います。私は2003年に社会人になり、第一次アジャイルブーム？か何かでXPを知り、少しだけ学んだ世代なのですが、去年の1月からアジャイル開発を勉強・実践するようになりました。 そんな中、アジャイルコーチを仕事としている方を間近で見たり、新人研修にアジャイル開発の手法を取り入れたり、実際に自分のチームで実践したりする経験を得ることができました。今年は、まったく自分に関係ないチームのプロジェクトリーダー/マネージャをしながら、アジャイルコーチのような役割を果たしているところなのですが、そこでのコーチング時にふと疑問が浮かびました。 「自分の成果はなんなのだろう？」 その疑問について、Twitterでいろいろと教えてくださった方からのアドバ
「アジャイル導入」や「プラクティス導入」といった大きい一歩を踏み出してうまくいかないと嘆くあなたに送るたったひとつのアドバイス
はじめにこの記事は一年くらい前に書きかけて放置していたのだけど、市谷さんが同じようなことを言ってるスライドをアップしていたので、二の矢として挙げることにする。 プラクティス導入がうまくいかない！！これまでも多くの人がそうだったし、これからもきっと多くの人が同じような状況に陥ると思われるのでメモしておく。 「現場でXXXを実施してみているのだがうまくいかない」という話は、色々なところで耳にする。XXXXはプラクティスでもいいし、スクラムでもいいし、ツールの導入でもいい。 例えば、プラクティスというのは、名前がついていて、各所で実践した例もいろいろあって、希望に満ち溢れているようにみえる。なので、ついつい手にとって試してみたくなる。TDD、ペアプロ、リファクタリング、カンバン、あー、たまらない！早くヤリたい！試してみたい！！ しかし、ぐっとこらえて、考えてほしい。 あなたが、その「キラキラ」し
「それ、アジャイルできてへんのちゃいますか？」チェックリストの公開 - メソッド屋のブログ
DevOps を導入して、リードタイムの短縮などの効果を出したい時に、前提条件となっている「アジャイル」がまだ導入できていないケースが多い。そういったケースでは、まずアジャイル導入のご支援をすることもよくある。 そういった支援に入ると、「アジャイル導入前提」で構成されたはずのプロジェクトであっても、全然「アジャイル」のポイントを外しているというケースは珍しくない。更に問題なことに、「アジャイルをできます！」と言っているベンダーさんを連れてきても、全然ポイントを外しているというケースすら珍しくない。今回のブログではそういったケースでも、簡単に確認できる、「アジャイルになっていないかもしれない簡単なチェックポイント」を対策付きでいくつかご紹介しよう。 スプリントの中で、ウォータフォールを実施するのではない。それはミニウォータフォールというバッドプラクティスだ。 1. 進化型設計ができていない
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
