アジャイルソフトウェア開発の未来

ソフトウェアは、人間社会のすべてのギャップに浸透します。 窓の外の通常の温度計ではなく、インターネットを介して天気を調べます。 ナビゲーターを使用して新しい住所に行きます。59ページのG7スクエアを探していません。自転車に乗るときにRunKeeperをオンにして平均速度を調べ、Twitterで披露します。 私たちは毎日ソフトウェアを使用しています。 おそらく、私たちはほとんどの人生を、愛する人とではなく、お気に入りのガジェットとソフトウェアで抱きしめています。

問題は、クールなソフトウェアを実際に素早く正確に書く方法を誰も知らないことです。 滝は世紀の変わり目に無事に亡くなり、新しい開発方法（アジャイル）は依然として根本的な問題を解決できません。 私たちは非常に興味深い時間に住んでいます。 現時点では、ソフトウェア開発業界全体が急速に発展しており、定性的なブレークスルーの基盤が蓄積されています。

アジャイルが主流になることは誰にとっても明らかであり、非常にすぐに、あらかじめ決められた寿命のある個々のマストドンが滝で機能します。 アジャイルがレースに勝ちました。 MicrosoftはTFSのアジャイルサポートを改善しており、多くの製品で反復開発を使用しています。 IBM、アジャイルジャズプラットフォームを発表 SAPでもアジャイルを実装しています（見たいです）

そして、これはドイツ銀行のCIOであるWolfgang Gatnerからの引用です

「私たちは前進しなければなりません。 従来の方法は十分に高速ではありません。 それらは複雑すぎて、イノベーションを妨げています。 これは明らかに明らかです。」

少なくともほとんどすべての企業は、以前のソフトウェア開発アプローチが機能しないことを認識し始めています。 彼らは物事を変えようとし、アジャイルは現時点で最良の解決策とみなされています。 しかし、アジャイルソフトウェア開発をいかに根本的に改善するのかという疑問が生じます。 改善します。 しかし、すべての問題を解決するわけではありません。 ひどいがらくたがまだ出てきます。 前と同じように、開発速度にはまだ多くのことが望まれています。 以前と同様、多くの決定の質は、バグに満ちた批判に耐えられず、あらゆる便利な、特に便利ではないケースで自分自身を感じさせます。

少なくとも数日間続いたAmazonサーバーの少なくとも最近の秋を見てください。 私たちのサーバーはほぼ一週間横たわっています！ Skypeは時々クラッシュします（特にMicrosoftによる購入後）。 誰もがタンバリンと踊ってそれを機能させることを覚えています。

時々、iOSで問題が発生します。 たとえば、次の更新後の私の電話は、ランダムなクリックと呼び出しは言うまでもなく、スタンバイモードへの移行を拒否し、8時間でバッテリーを着陸させました。 それはひどく迷惑でした。 私はほぼ一ヶ月間修正を待っていました！

正しいことをする

ソフトウェア開発の3つの基本的な問題を見ていきましょう。 主な仕事は正しいことをすることです。

どういう意味ですか？ 特定の問題を解決する必要があり、これらの問題を解決することは良いことです。 市場には数千のプロジェクト管理ツールがあります。 どれくらい本当に良いですか？ 10？ 20？ ほとんど20を超えません。

なぜ悪夢のようなインターフェイスを備えたこれらの不気味なモンスターが、ユーザーを苦しめ、クリエイターを苦しめ、人生を永遠に手放したくないのですか？ 配色、プラットフォーム、ログインフォームのデザインが異なる、同じことを行うこれらの何百もの簡単なツールが作成されたのはなぜですか？ 答えがありません。 しかし、誰も必要としないソフトウェアで溢れかえっており、他のソフトウェアから愚かにコピーされ、そのインターフェイスでユーザーを悩まし、誰もが愚か者を保持していることは明らかです。

業界の最初のタスクの1つは、適切なソフトウェアの作成方法を学ぶことです。 最初のリリースで人々の心に入る必要があります。

正しいことをする

2番目のタスクは何ですか？ 2番目のタスクは、物事を正しく行うことです。

私たちが正しいことをすれば、それは戦いの半分です。 しかし、私たちがそれをひどくやると、最終目標は達成されません。 はい、ユーザーはシステムの崩壊から崩壊まで、問題をすぐに解決できます。

貧弱に書かれたソフトウェアは、驚くほど両面です。 彼は良いと助手であると言っているようですが、実際には、彼は古い難破船であり、気分では、オイルは不凍液と混合され、エアコンは冬にのみ機能し、ワイパーは天気の良いときにのみ、130の速度できしみますハーフシャフト。 しかし、彼は有能なセールスマネージャーの助けを借りて優れたプレセールトレーニングを受け、すぐにハンマーの下に入りました。 そして、エアコンが機能しないという事実、だから誰が冬にそれをオンにします。 はい、120を超える道路を運転することはできないため、これはバグとはみなされません。

数か月前、OmmWriterプログラムを使用しようとしました。 大量のテキストを書くための最小限のインターフェイス。 リラックスできる音楽。 テキスト以外のすべてを隠すフルスクリーンモード。 私はこのプログラムが好きで、使い始めました。



一度、私はほぼ一回で大きな記事を書きました。 約5ページ。 もちろん、私はしばしばそれを保持しました。 そしてもちろん、私はバックアップしませんでした。 翌日、私は仕事に来て、ブナを開き、OmmWriterを喜んで掛けました。 プロセスを強制終了し、OmmWriterを再度実行して、ドキュメントを開きました。 彼は空だった。 アイロンをオフにするのを忘れたと思った瞬間がありますか？ それで、背筋が冷たくなり、アドレナリンのレベルが上がり、取り返しのつかない感覚が私の後ろに落ちました。 握手をして、Finderでファイルを見つけ、そのサイズをチェックしました-0バイト。 OmmWriterを使用した最後の日でした。 データを失うプログラムは信頼を失います 。 最近、非常によく似たBywordプログラムを購入しました。 彼女は時計のように働いています。 満足しています。

曲がって書かれたソフトウェアは、開発して人生の新しい現実に変えることは非常に困難です。 このようなソフトウェアの開発は高価で時間がかかります。

かつて、 TargetProcessをすばやく作成しました。 それは仕事の後と週末に書かれたので、主なタスクはそれがどれほど実行可能であるかのアイデアをテストすることでした。 単体テストは少なかった。 アーキテクチャは脆弱でした。 たとえば、O / Rフレームワークは非常にうまく選択されていません。 スケーラビリティとパフォーマンスについて誰も考えませんでした。 しかし、主なタスクは達成されました-コンセプトはその実行可能性を証明しました。 その結果、すべてをゼロから書き直さなければならず、フルタイムで8か月かかりました。 その結果、TargetProcess 2.0が登場しました。 良かったのか？ 一方で、私たちは8か月を失ったようです。 一方、コンセプトを確認し、機能することを確認しました。

スピード

3番目の問題である速度にスムーズに移行しています。

ソフトウェア開発はユーザーに追いついていません。 プロジェクトの複雑さが増し、速度が低下します。 速度係数は、どの企業にとってもますます重要になっています。 ソフトウェアを高速化すれば、さまざまなオプションを試したり、市場の変化に対応したり、他よりも早く正しい道を見つけたりすることができます。 ソフトウェアをゆっくり作成すると、 2回目の試行は行われません ...

業界には、デュークヌケムフォーエバーなどの伝説的な長期建設があります。

1996年に開始され、2011年に完成しました。 いくつかの締め切りの後、開発者は公開評価を停止しましたが、単に「準備ができたら」ゲームをリリースすると言いました。 残念ながら、Duke Nukem Foreverはゲーマーの期待に応えることができませんでした。 Gamespotは、ゲームに3.5のスコアを与えました。 ゲームは退屈で、独創的で時代遅れでした。

なんて遅い国！ -女王は言った。 -さて、ここで、
あなたは知っている、あなたは同じにとどまるためにできるだけ速く走らなければならない
スポット！ 別の場所に行きたい場合は、少なくとも2倍の速度で実行する必要があります。

実際、他の人に遅れをとらないように、速く走る必要があります。 最初になりたいのであれば、もっと速く、もっと速く走らなければなりません。

ソフトウェア開発プロセスでは、これら3つの問題に焦点を当てる必要があります。一般に、適切なプロセスのスローガンは次のとおりです。

正しいことを正しく迅速に行う



適切な製品を正しく、しかしゆっくりと作ると 、市場にある機会を逃す可能性があります。 私たちは遅れることがあり、現実は大きく変化するため、私たちの製品を必要とする人はほとんどいません。

適切な製品を迅速に、しかし誤って作成すると、製品開発の問題に直面します。 小道具と松葉杖を挿入して10年以内に製品を埋めるか、または一から書き直します。これは高価です。

間違った製品を正確かつ迅速に作成した場合、明らかにそれを必要とする人はほとんどいないため、成功しません。 なぜ間違っているのか理解できず、正しい方向に素早く変更できない限り。

理想的には、センターに着く必要があります。

アジャイル開発の未来

これは、近い将来のアジャイルプロセスの進化的発展の写真です。 概して、すべてを2つの主な傾向、つまり速度と規模に縮小することができます。



あらゆる規模で正しいことを迅速かつ迅速に行う方法を学ぶ必要があります。

これが基礎です。

なぜ私は主要な存在としてスピードに耐えたのですか？ 速度とは、顧客の問題を解決するのにかかる時間を意味します 。 間違ったことをするとどうなりますか？ アイデアをやり直すか、完全に放棄する必要があります。 間違った場合はどうなりますか？ 先に進むにはやり直す必要があります。 すべての変更は、速度に最も悪影響を及ぼします。 したがって、正しいことを正しく行うと、長期的には速度が向上します 。

速度から始めましょう。 速度は、専門知識と迅速なフィードバックという2つのことで決まります。

フィードバック

フィードバックが重要な理由

元の姓エリクソンを持つスウェーデンの心理学者アンダースは、トレーニングに関連する多くの実験を実施しました。 特に、彼は多くの医師が卒業後にスキルを失うことに気付きました。 ただし、外科医は規則の例外です。 外科医には継続的なフィードバックと明確な目標があります。 腫瘍医はますます難しくなっています。 腫瘍医が画像を検査するとき、彼はがんがそこにあるかどうかを確実に知りません。 彼は、生検から数週間後に発見します。 またはそれ以降、癌がないことが明らかになった年月を通して。 すぐにフィードバックがなければ、医師の能力は時間とともに悪化します。 エリクソンは、古い事例の歴史を教える新しいモデルを提案しました。 写真を見て、結論を出して、すぐに実際の病歴から答えを得ることができます。 この場合、トレーニングの強度が大幅に向上し、いつかは数年の通常の練習よりも多くのストーリーを考慮することができます。

フィードバックにより、基本的に2つのことを学ぶことができます。 必要なことをやったことがありますか。 正しくやったか。 これをできるだけ早く知りたい。 理想的には、タスクを完了した直後。 私たちが正しいことをしていることをできるだけ早く見つける方法は？ 2つのソリューション：スケッチとプロトタイプ、短納期。

スケッチングソリューション

スケッチは、要件を見つけるための強力な手段です。 しかし、スケッチは狭く理解されるべきではありません。 スケッチは、実際のシステムをエミュレートする簡単な方法です。 フリーハンドのスケッチで十分な場合もあります。



また、それほど単純ではないモデルを作成する必要がある場合もあります。

数十年前、IBMは音声ベースのコンピューター制御インターフェースの作成を決定しました。 膨大な数のユーザーが、オペレーティングシステムを注文することを夢見ていました。 プロジェクトはほぼ開始されましたが、確認することを決めましたが、ユーザーは本当に気に入っていますか？ スケッチは簡単でした。 彼らはユーザーを連れてきて、コンピューターに彼を置きました。 ユーザーは霊感でコマンドを与え、別の部屋にはこれらのコマンドを聞いて実行した人がいました。 ユーザーは自分のモニターでプロセスとコマンドの結果を見ました。 独創的！ その結果、ほとんどのユーザーはこの方法でコンピューターを制御することを好まなかったため、遅く、特に効果的ではありませんでした。 キーボードとマウスが勝ち、プロジェクトは終了しました。 音声認識アルゴリズム、オペレーティングシステムへの音声コマンドの埋め込みなどにどのツールが費やされるかは容易に想像できます。 スケッチだけで多くのお金を節約し、正しい判断を下すのに役立ちました。

スケッチスキルの開発は、ソフトウェア開発の専門家にとって非常に重要であり、多くの場合、これを見逃しています。 今のソフトウェアはどうですか？ 要件は1つの大きなバックログに収集され、重要なユーザーストーリーが選択され、UIを描画してコードを記述します。 最良の場合、プロトタイプが作成され、最悪の場合、実際のシステムに発展します。 これは間違いなく十分ではありません。 最初の段階では、チームは正しいことを行うことを確認する必要があります。 はい、これはビジネスタスクです。 しかし、企業はソフトウェアの作成方法やUIの設計方法を十分に認識していません。 彼はそのような難しい仕事を自分で解決することはできません。

新しいプロジェクトに真っ向から向き合い、すぐにそれを開始することは、競合他社とほとんど変わらない平凡な製品をリリースするための実質的に保証された方法です。 ソリューションが1つしかない場合、チーム全体の動作と開発プロセスは歩行者と同様に予測可能です。

Bill Buxton、ユーザーエクスペリエンスのスケッチ

現時点では、システムの高速プロトタイプを作成するツールはほとんどありません。 すべてのプロトタイピングツールには欠陥があり、中程度の複雑さのプロトタイプを作成するには数週間かかります。 これは非常に長い時間です。 今後数年のうちに、数日でインタラクティブなプロトタイプを作成できるツールが登場するはずです。 このような大幅な時間の短縮は、フィードバックを高速化し、いくつかの代替ソリューションをテストし、正しいことを行うことを確認します。

継続的デリバリー

フィードバックを迅速化する2つ目の方法は、迅速な配送です。 各コミット後に配信することは、フィードバックを制限まで減らす超過激なアイデアです。



エンドユーザーにとって、これは通常、特に関心を引くものではありません。 しかし、チームにとって、このような極端な変更は開発プロセスを変更し、コードの品質の深刻な向上を余儀なくさせます。 CDを提供するためには、会社は一生懸命働く必要があります。

CDには、ユニットテスト、機能テスト、パフォーマンステスト、受け入れテストなど、ほぼ完全なテスト自動化が含まれています。 配送自体も自動化する必要があります。 このレベルの自動化には、重大な作業が必要であり、要件の設定からマーケティング部門まで、ソフトウェア開発プロセス全体の再構築が必要になることがよくあります。 つまり、スケールの問題が影響を受け、その実装が複雑になります。

専門知識

さらに人間の問題に移りましょう。 ソフトウェアは人によって書かれています。 コンベア上でソフトウェア開発を行う試みは成功しませんでしたが、驚くことではありません。 ソフトウェア開発業界自体は幼少期であり、二次的な性的特徴の出現を祝ったばかりです。

すべてが人々に保たれている間。 クールなプロのチームは、ほぼ任意の曲率のプロセスで通常のソフトウェアを作成します。 初心者チームは、上から下まで極端なプログラミングを行っていても、皆既日食のときだけクールなソフトウェアを作成できます。

人々には専門知識と問題解決スキルがあります。 それが開発と改善が必要なものです。

ドメイン知識

サブジェクト領域の知識は、正しいことをしているかどうかを理解するのに役立ちます。 車のデバイスを知っている場合、中央に5番目のホイールを追加することに同意する可能性は低いです。 人生で初めて車を見た場合、5番目のホイールを追加しても何もジャンプせず、容赦なく容赦なく実行します。

ドメイン知識はすべてのソフトウェア開発者の大きな失敗の1つです 。 もちろん、誰もが何らかの形でそれを掘り下げていますが、研究のために意図的に時間を割り当てる人はほとんどいません。 保険ビジネスでソフトウェアに取り組んだとき、保険会社の構造について読んで、キャリアがクラスレベルだけでなく実際のアカウントとどのように異なるかを知るのは1年後のことでした。 しかし、もしそれが私に起こった場合、私が一緒に仕事をした人は誰もそれをまったく思いつきませんでした。

通常、開発者にとっては、エンティティが現実の世界でどのように生活するかは重要ではありません。 一連のビジネスルールは彼にとって重要です。 彼は一貫した要件を取得し、それらを実装することが重要です。 彼にとって美しいアーキテクチャを作り、きれいなコードを書くことが重要です。

ここでは、イニシアチブは完全に会社にかかっています。 彼女の課題は、対象分野でトレーニングを組織することです。 たとえば、 当社では会議に人々を派遣し、アジャイルプロジェクト管理に関する本を読むことを強く推奨していますが、これでは十分ではありません。 誰もが私たちが何をしているのか、なぜそれをしているのか、そしてなぜそれが重要なのかを明確に理解する必要があります 。

少なくとも数人が対象分野について十分な知識を持っているチームは、問題をビジネスと平等に話し合い、解決策を考え出すことができます。 そのようなチームに対する自信は何度も高まります。 チームが間違ったことをする可能性が低くなります。 これは、開発の速度が向上することを意味します。

職人技

プログラマーの心により近いのは、 職人技の概念です。 コンセプトの本質は、意思決定の質と専門的スキルの開発を改善することです。 職人の技は、ほぼ完全に正しいことを行うことに集中しています。

速く進む唯一の方法は、正しく行くことです。

おじさんボブ・マーティン

ソリューションの品質を向上させるには、適切なアーキテクチャを構築し、優れたテストカバレッジを確保し、理由を問わず意思決定を複雑にしないことが必要です。

専門能力開発のために、 Coding DojoやCoding Kataなどのアスリートや武道にトレーニング技術を適用する試みが行われています。 もちろん、これは大きな質問です。プログラマーを訓練するためにそのようなテクニックを適用することは可能ですか？ しかし、いずれにしても、何らかのトレーニングが必要です。 プロダクションコードで常に作業している場合、同じ問題を同じ方法で解決でき、まったく開発することはできません。 特定の何かを作成するのではなく、特定のスキルを磨くためのクラスが本当に必要なようです。 最も効果的な方法は、さまざまな技術を使用して、同じ問題を異なる方法で解決することです。 現在のアーキテクチャに対する継続的な改善も優れています。 現在の状況に絶えず疑問を投げかけ、ソリューションを改善し、よりシンプルで柔軟で理解しやすいものにする必要があります。

明らかに、システムの複雑さを増すには多くの人が必要です。 これで、C、データ構造、アルゴリズムを知ることができなくなりました。 ここで、OOP、パターン、ライブラリ、関連する一連の技術および分野を知る必要があります。 必要な知識の量は毎年増加しています。 ただし、過去数年間のプログラミング抽象化のレベルはそれほど変化していませんが、システムの複雑さは大幅に変化しています。 FacebookやTwitterのアーキテクチャは非常に複雑で 、システム全体がどのように機能するか想像できる開発者はいないと思います。 そのため、プログラマには学習を停止する権利はありません 。

問題解決

おそらく問題を解決することは、誰にとっても主要なスキルです。 もしそうなら、あなたはあなた自身のギャップとあなたが働いている会社の開発プロセスのギャップを簡単に埋めることができます。

ほとんどすべてのチームで回顧がどのように行われるかをご覧ください。 人々は集まり、しばしば表面にある問題を提唱し、表面にもある解決策を提供します。 まれに影響を受け、解決された根本的な問題。 ごくまれに、実際には非標準のクールなソリューションが提供されます。 このような会議では、問題識別ツールはほとんど使用されません。 体系的思考、 TRIZ 、ブレーンストーミングテクニック-ほとんどのチームは、スキルと知識がないため、これをすべて無視します。 プログラマーは体系的な思考を教えられません。 プログラマーはTRIZを教えられません。 プログラマーはブレーンストーミングを教えられません。 プログラマーは箱の外で考えることを教えられていません。



問題を解決するための技術は、学校でも研究所でも大学でも研究されていません。 これは信じられないほどです！ 職業生活の主なスキルの1つは、どの講義でも言及されていません！

プログラマー自身は、プログラミング戦略と戦術に関連するすべてのことを学ぶのが大好きです; ほとんどのことはほとんどの開発者にとってあまり興味がありません。 プログラマーは問題を解決するアルゴリズム的な方法を知っていますが、実際には発見的で創造的な方法を知りません。 プロセスを改善するためのタスクは、ほとんど常に複雑で創造的であり、アルゴリズムを使用して解決することはできません。 アーキテクチャの課題には、創造的な思考も必要です。

経験豊富なトレーナーは、新しいプラクティスを回顧に取り入れようとしますが、常に成功するとは限りません。 多くの場合、彼ら自身は問題解決の専門家ではありません。多くの場合、彼らの知識をチームに伝えることは不可能です。

アジャイルは、チームでの自己組織化を望んでいます。 そのため、チーム自体が問題を効果的に特定して解決する必要があります。 そうでなければ、必然的に同じレーキを踏むことになります。 ただし、アジャイル手法には、問題解決ツールが含まれたり、促進されたりするものはありません。

興味深いことに、デザインとUXの分野では、人々はこれらのツールを使用します。 ありふれたものであり、単なる作業ツールのセットです。 開発者はしばしばこれを欠いています。

優れた開発者には、創造的で革新的な思考が必要です。 彼は詩を作曲できる必要はありませんが、首尾一貫した良いテキストを書くことは不可欠です。 紳士の皆さん、正しい半球を開発してください！

スケール

スケールは、アジャイルプロセスの深刻なテストです。 基本的に、スケーラビリティの問題は会社全体および分散したチームに関係します。

会社全体

アジャイルは個々のコマンドレベルでうまく機能します。 単一のチームは、スクラム+ XPまたはかんばんに切り替えることで、その有効性を本当に真剣に改善できます。 しかし、会社全体のためのアイデアを開発しようとすると、非常に頻繁に深刻な抵抗と誤解に会います。

そもそも、アジャイルは多くの企業の企業文化と対立しています。 透明性、信頼、謙虚さなど、アジャイルの基本原則-ビジネスの世界は困惑しています。 透明性？ 信頼？ 謙虚？ うーん...多くの企業で政治ゲーム、キャリア、自慢と無能が支配しています。 そのような企業にとって、アジャイルは既存のシステムを破壊する恐れのあるウイルスとして認識されています。

アジャイルは、伝統的な会社の恒常性を破壊しようとし、すべての不足電流、隠れた欠陥、および通常の条件下で水に沈まないすべてのものを表面にもたらします。



たとえ会社が透明性と信頼性に優れていても、非常に複雑な問題が残っています。 人事部は人材採用のアプローチを変え、スキルだけでなく会社の文化にも適した人材を選択する必要があります。 マーケティング部門は、頻繁なリリースで何をすべきかを把握する必要があります。 設計部門は、開発チームに自分を含める方法を理解する必要があります。 トップマネジメントは、会社全体の多くのアジャイルチーム間の相互作用を整理する方法を理解する必要があります。 これはすべて非常に難しく、多くの質問に対する答えはまったくありません。 大企業はアジャイル再編成プロセスを開始しているところです。

最近、UXチームと開発チームが積極的に参加しています。 深刻な進歩があります。

多くのチームの相互作用については、すべてがここで非常に悲しいです。 スクラムオブスクラムは、完全に機能しないことを示しています。 明確なメカニズムはまだありません。誰もが同じレーキを踏んで自分の自転車を発明します。

分散チーム

長年のアジャイル問題はグローバル化です。 インターネットの発展により、分散したチームが出現しました。 世界中に数十カ国にオフィスを持つ企業があり、数百人の作業を同期する必要があります。 アジャイルは、同じ場所に配置されたチームのレベルで生まれたため、最初は分散チームで深刻な問題を抱えていました。 OUNER製品が午前9時に起動し、開発者が午後4時に眠そうに現れると、継続的なコミュニケーションとフィードバックの減少は困難です。

この問題の解決策は複雑であり、まず第一に、通信チャネルの飽和度を高めることで実装する必要があります。 オフィス間の直接連続ビデオ通信が最適なソリューションです。 ひげを剃っていない顔で今日の気分を見て、人が今質問できるかどうか、または待つ方が良いかどうかを知ることは常に素晴らしいことです。

リモートペアプログラミング、ブレーンストーミング、およびテスト用のツールも表示および開発されます。 TargetProcessのようなツールは、どの分散チームにとっても避けられません。

おわりに

ソフトウェア開発業界の主なタスクは、センターに到達することです。 正しいことを迅速かつ迅速に行うことを学ぶ。



可能だと思います。 これを行うには、次のことが必要です（優先度の降順）：

• TRIZなどの問題解決技術を研究し、革新的思考と体系的思考を開発する
• あらゆる方法でフィードバック時間を短縮する
• 研究対象分野
• 企業全体および分散チームにアジャイルマインドセットを拡大する方法を学ぶ

PSはい、私はこの記事が素晴らしいことを知っています。 しかし、彼女を打ち負かすために私は要点を見ません。