API構築の基礎を学んだ。QConは、開発者コミュニティにおける知識とイノベーションの普及を促進することで、ソフトウェア開発に力を与える。実務者主導のカンファレンスであるQConは、チーム内のイノベーションに影響を与える技術チームのリーダー、アーキテクト、エンジニアリングディレクター、プロジェクトマネージャー向けにデザインされている。Sheehy氏は、人工知能ハイプ時代における責任ある開発者としてのあり方について、洞察に富んだ開会基調講演をした。Grizzanti氏が、「スタッフ・プラス」への道と、それを「科学」というより「芸術」としてとらえ、芸術を創作することとソフトウェアを創作すること、そして組織のダイナミクスに対処することの類似性について語っている。Codeを採用する:確認するべき6つの適性LCNC(ローコード/ノーコード)プラットフォームは、プログラマーだけでなくプログラマーでなくても、最小限のコーディングとワンクリックのデプロイメントで、アプリケーションソフトウェアを開発できるよう設計されている。ドラッグ&ドロップ方式のインターフェースなどを利用することで、開発・デプロイメントプロセスを簡素化し、効率的なアプリケーション開発とデプロイメントを実現する。編集部N原文(投稿日:2010/03/02)へのリンクソフトウェア開発は、創造的なプロセスである、と知られている。方法論がかなり人気を得た。Scrumの採用が増えている。氏は、そう思っていない。Agileには重大な欠陥があると言っている。関する大部分の文書は、その栄光について語っていますが、私は、その欠陥について書きます:欠陥は、非常に深刻なので、もし修正されないと、あなたが好きなAgile手法は、去年の流行りだった、ということになります。AgileやScrumの焦点は、間違っている、と言う。これらは、ステークホルダーにビジネス価値を引き渡すことに焦点を合わせていない。あるすべての考えは、「開発者にとって都合がいい」ものへのソリューションであると言っている。マニフェストは、ひどく開発者寄りである。ステークホルダーについて述べていない。取り上げて、ステークホルダーに与えられる価値が、図のどこにもない、と言う。このことは、他の原則といっしょにされました。それはすばらしいが、2ページ目にです。1ページ目にあるべきで、おそらく単独で、もっとはっきりと、述べられる必要があり、目標とソリューションをごちゃまぜにすべきでありません:「よって」は、ほのめかすべきです-他にもっといい方法もあり得ますから-時々は!氏は次のことを強調したソフトウェアを開発することや、好みの開発プロセスやユーザストーリーのことでは、ありません。顧客あるいは、ユーザだけについてのことでもありません。関係するステークホルダーに価値の改善を届けることがすべてです。それこそが、彼らの関心があることであり、同意できる、最小限のあるいは、予め決めた費用内で、彼らの世界をより良くするものです。XPは開発中に繰り返されるサークルによってビジネス価値を加えている、とコメントしている。彼によると、ビジネス価値は、得たもの、いつ得たか、かかったコストに依存する。何をやるべきか、そしていつを決めるために、顧客は、自分が頼むものにかかるコストを知る必要がある。プログラマは、自分の経験に基づいて、この情報を提供する。それから、顧客は、何が欲しいかを選び、そしてプログラマは、それを作る。繰り返すこのサークル度に、我々は学ぶ。顧客は、彼らの提案したフィーチャが本当にどれだけ価値があるのかを学び、一方プログラマは、これらのフィーチャが本当にどれほど難しいかを学ぶ。Kai氏は、反論して、これでさえも、ステークホルダーに価値を加えていない、これは、明らかにプログラマの視点である、と言っている。開発のサークルは、付加価値への単なるリップサービスになってしまうだろう、とKai氏は、述べている。Agileの「幼児語」が開発者の創造性を殺している、と言っている。Agileは、機能でなく、ソリューションにフォーカスするので、開発者に創造的になる余地を与えていない、と言うのである。Agileをやっている者は、競争力のある製品を作ることができない、と氏は言っている。やることリストを実行する。システムの重大な「どのくらい良く」という側面には、焦点を当てないで、Scrumは、ソフトウェア開発をタスクのレベルに落としているので、腕がよく、創造的で、知識豊かな開発者を必要としない。開発者は、何を作るべきかは言われるが、製品品質の要求を満足するための最高の方法については、問われない。競争力のある製品を作るかについての理解がほとんど、あるいは全くない。逆のことが起きてしまっている。(アーキテクトではなく、アマチュア(ユーザ)によって作られる)ソリューションが要求され、もっと競争力のある選択肢は、システム的に落とされてしまう。手法は、役に立たなくなっている。Kai氏は、多くのAgileプロジェクトがユーザストーリーとして使っている例を上げた。購買者として、私は、ショッピングカートに本を入れたいと思う。彼が言うには、このユーザは、完全に間違っている。すべて間違っています。ブレークダウンしてみましょう。Kai氏によれば、このユーザストーリーによって、競争力のある製品を作ろうとする、開発者の創造性と熱意が奪われる、と言うのは、このユーザストーリーは、機能を提案するのではなく、ソリューションを実装するように言っているからである。純粋な機能は、「本を注文すること」です。「ショッピングカート」のような、注文をさせる特定の方法は、開発者がソリューションを見出すのに、本来存在する選択肢や創造性の余地を奪うものです。そのソリューションの方が、機能である「本を注文すること」をもっと良い品質にし、パフォーマンスもよくなるでしょう。彼が言うには、ユーザストーリーは、開発者にとって、「どのくらい良く」の部分が完全に落ちている。その機能は、ライバルよりも「どの程度」良くあるべきなのか、置き換えるシステムより「どのくらい良く」あるべきなのか、提案されているUIより、どのくらいもっとユーザフレンドリにできるのか、である。Scrumのアプローチでは、開発者は、何をすべきか言われている、単なるレンガ職人である、と言う。やるべきリストになってしまい、開発者に何をすべきかを告げ、開発者は、ただそれをやるだけなのです。近日、もっと重大な欠陥を明らかにする計画である。毎週火曜日に前週のまとめコンテンツをお送りいたします。(日本語版は不定期リリース)25万人のシニアな開発者コミュニティーにぜひご参加ください。サンプルを見るあなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。毎週火曜日に前週のまとめコンテンツをお送りいたします。(日本語版は不定期リリース)25万人のシニアな開発者コミュニティーにぜひご参加ください。サンプルを見る様々なイノベーターとアーリーアダプターがお送りするテクノロジーの概要を見る。自分がまだ知らないことに気づいていないと知るあなたが興味のあるトピックスをいつでも最新な情報に。あなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。Inc.プライバシーBT。