Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...
はじめに 本連載では、「透明性」というキーワードで、アジャイル開発について説明していきます。第二回目は、顧客の視点からの透明性について考えます。 開発の状況をこまめに報告したり、コミュニケーションを円滑にして、情報の漏れや行き違いを防ぐことが大切です。その為にもっとも直接的で効果的な方法は、成果物(特に動作するソフトウェア)を実際に見てもらうことです。要求仕様へのフィードバックとして成果物を頻繁に顧客に提供し、実際に使ってもらうことで、要求仕様との適合性を検証するのみならず、要求仕様そのものの検証をしてもらうことが可能となります。 このような開発者から顧客へのフィードバックを如何にして有効なものとするかについて今回は整理してみましょう。 イテレーション アジャイル開発では、こまめに顧客のニーズの変化を要求仕様として反映させていくことを説明しました。しかし、一般的には要求仕様がコロコロと変
プロのトレーナーとコーチが何度も目にしてきたことがある。あまりにも多くのアジャイルチームがはまり込んでしまうパターン、すなわち、ワクワクするような、高度な「活躍」をする段階に進めず、ただの平均的な「導入」の段階で行き詰まってしまうという現象だ。読者の皆さんも考えてみてほしい。すべてのソフトウェア開発プロジェクトに共通することで、最大限にしたときに生産性が急上昇するものがあるかもしれない。実際、最も成功したチーム (アジャイルチームであれ従来からのチームであれ) の多くがソフトウェア開発の、一見単純ではあるが、よく忘れられる「秘伝」をすでに活用している。それは、頻繁にふりかえって学習する時間をつくることである。 何について学ぶのか?お互いのこと、テクノロジ、ドメイン、顧客など、すべてについてである。速く学習するチームは成功する。チームのパフォーマンスを妨げる目に見えない「学習ボトルネック」に
「お金なら出しますから、4ヶ月のところを2ヶ月で作ってくれませんか?」 システム開発で、顧客からこう言われた時、どうするか? SIerの経営者や管理職であれば、飛びついてしまうんじゃないだろうか。私だって飛びつきたい。確かにエンジニアがいるなら、もしくは、集める目処が立つなら、ありがたい話かもしれない。XPでも、「リソース・スコープ・品質・時間」のパラメータで、品質以外は変動可能としている。 ということは、リソースがなんとかなれば、時間を短くする、もしくは、時間を変えずにスコープを増やすことができるのだろうか。人月という単位で考えれば、計算上は出来るかもしれないが、実際には難しいと言わざるを得ない。それはなぜか。ボトルネックは、プログラムを作る速度か、それとも、仕様を決めて受け入れる速度か。 冒頭の台詞は、開発側にこそボトルネックがあり、コストさえかければスピードアップできると考えているか
Home » headline, プロジェクト・マネジメントを考える。 アジャイルは二度死ぬ(Agile Only Live Twice)その1:トム・デマルコ氏の蹉跌とその誤謬 アジャイルの隆盛 WEBの世界の中で、日々ITに関する情報を集めていると、アジャイル開発がシステム開発の完全なる主流になった気になってしまいます。偏った情報収集をしているせいだ、といわれればそれまでですが、WEB/ベンチャー業界・SIer業界・企業IT部門/IT子会社界・オープンソース界全てを通じて、Blogなどで声の大きい方々は多かれ少なかれ『アジャイル』という考えに肩入れしているように感じられます。 当然、世の中の流れが全てそうなっているかというと、そういうわけでは無さそうです。WEB/ベンチャー業界や、オープンソース界では、ほぼメインストリームとなっていると思いますが、SIer業界・企業IT部門/IT子会
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く