最近、 「アジャイルが私を悩ませているので、それについて話したい」という興味深い記事に出会いました。 マネージャーの観点からこのプロセスを調整することについて説明します。
プログラマーとしての私にとってアジャイルとは何かを説明したかったのです。 マニフェストと大きな言葉なし。 そして、他の方法論と比較してそれについて特別なことは何ですか。
先史時代
私は9年間プログラマーとして働いています。 この間、私は完全に「非生産的 」から認定されたSMMIレベル5 （それが何であるかを知っており、笑顔を抑えない）まで7社で試してみました。 私の人生で最も「厳格な」プロセスを持つこの会社で、私は始めます...
2008年。 モトローラの会社。 私は同時に研究所での研究を完了し、背中の後ろの専門分野で3年間働いた経験がありました。 一般的に、彼は自分を経験豊富なプログラマーと考えていました。 そして、ここで初めて（そして最後に）、本当に「柔軟性のない」プロセスに出会いました。 モトローラは、CMMIレベル5認定ソフトウェア開発モデルと、1986年のシックスシグマの生産管理コンセプトを誇りに思っていました。
鉄の開発には、そのプロセスが役立つ可能性があることを十分に認めています。 宇宙探査ソフトウェアも同様の何かの下で作成する価値がある可能性があります。 しかし、いくつかの単純なクライアントアプリケーションを記述する場合、コードの数倍以上のドキュメントが必要な場合、これはまったくばかげています。 私は本当の科学者のように感じました。 時空の曲率を調査する代わりに、彼は小さなJSRの注入に関する複数ページのドキュメントを書きました。 残念ながら、ロケットを火星に送ることはできませんでしたが、電話機のバッテリーレベルを取得するためのAPIのみを実装しました。
それから私はおそらくこれが大企業で必要だと考え、これが少なくとも何百万人もの人々によって使用される高品質の製品を達成することを望んでいました。 しかし、そのようなプロセスに長く取り組むほど、これらすべての文書の無益さを実感しました。 少なくとも、それらのほとんどは誰にも読まれたことがないため、作成とマルチレベルのレビューに多くの時間が費やされたためです。 同時に、これはコードの品質に良い影響を与えませんでした。
そして、Motorolaはお金を使い果たし、コスト削減になりました。 当局は、世界中の会社の食堂から使い捨てスプーンを取り除いて節約したお金を報告しましたが、これで終わりではありませんでした。 開発プロセスはアジャイルに劇的に変化しました。
「柔軟性のない」モトローラとの違い
何が変わった？ それだけです
主な違い：
- ドキュメントの作成を停止しました
代わりに、クラスとパブリックメソッドのコードとJavadoc内にコメントを挿入し始めました。 同時に、私たちが誰のためにこれを書いているのか（チームのために）明らかになりました。 また、これらのコメントは多段階レビューの対象ではありませんでした。 - 私たちと他の人々のコードの品質を監視し始めました。
多くの時間が厳密なドキュメントから解放され、今では基本的にコードとその品質に時間を費やし始めました。 同時に、コードは自己文書化されて生まれたはずです。 - 毎日のスタンドアップが始まりました
最後に、誰が私のチームで働いており、彼らが何をしているのかを知りました。 - 仕事の目的が変わった
ドキュメンテーションと多くの正式なプロセスからの焦点は、コードの品質と製品開発速度に急激にシフトしました。 - 開発速度が変更されました
それまでは、大企業であっても1年間働く必要はなく、100行のコードが実稼働に達するとは想像できませんでした。 これには数時間で十分であることがわかりました。 - 設計のアジャイルなタイミング:)）
また、設計者は「柔軟な」方法論を採用しました。 彼らはスプリントごとにデザインとコンセプトを変え始めました。 一般に、開発者とマネージャーの生活は非常に複雑でした。 - 作業時間
いいえ、8時間...残念ながら、私はもっと働き始めました。 基本的に、しかし、彼ら自身の主導で=）
プロセスレスとの違い
同時に、プロセスがまったくなかった最初の会社を思い出しました。
彼女にも多くの違いがありました。
- チーム配布ツール
毎日の議論と紙の貼り直しで、チーム全体がそれぞれの成功を完全に認識していること（後者の誠実さ）が気に入っています。 このように、スタハノビ人は容易に送られて、遅れた人を助けることができました。 - 開発時間
プロセスがなかった場合、明確なリリース時間はありませんでした。 むしろ、最初は聞いたことがありましたが、チーム内で作業を委任する手段がないため、ほとんど観察されませんでした。 または、低品質の製品はためらうことなくあきらめられました。 - あなたはもはや機能の達人ではありません
以前に、私は製品でそのような機能を行うと言ってそれに取り組んだことがありましたが、時には、Piで計画よりも多くの時間をかけて、今では不可能になっています。
第一に、計画中に、誰かがこの機能をより高速にすると言うことができ、それを行う機会を失いました。
第二に、「勝つ」という機能を備えていても、すべてが計画どおりに進んでいる間だけ作業しました。 遅れて、2つのオプションが登場しました。アシスタント/後継者が目立つか、機能が次のリリースに移行されました。 誰もスプリントの終了時間を変更しようとしませんでした。 - より速くする理由がありました（外向的）
率直に言って、私は人々が私を賞賛するときそれが好きです。したがって、アジャイルはすべてを可能な限り速く、より良いものにしたいという願望に大きく貢献しました。 - 毎日皆の前でひどく退屈でぎこちない15分間がありました（内向的）
私はこれも、主に内向的な人から聞いた-彼らは本当にスタンドアップで本当に不安でした。
アジャイルアップグレードの概要
私たちのチームはmyFavesアプリケーションを開発しました 。 T-Mobileの携帯電話会社を通じて販売したい電話プラットフォームごとに実装する必要があります。 したがって、このアプリケーションは、Motorolaの壁の中で何十回も開発されました。 しかし、会社の歴史の中で最短時間に出会ったのは私たちのチームでした。 品質も最高レベルであり、その結果、オペレーターは最初のテストサイクルで製品を受け入れました。 同時に、開発は、製品を作成するプロセスでこのシステムを学習するチームによって実行されました。 はい、Androidはまだ非常に未熟でした。 さらに、私のような人はJava自体を学びました。
さらなる考え
その後、韓国のサムスンで働き、その後国内およびアメリカの企業で働くさまざまなタイプのプロセスを学ぶ機会がありました。 しかし今のところ、すべてが私の現在のNetflix会社のアジャイルに戻っています。
アジャイルの長所
同時に、なぜ世界全体が柔軟な方法論に切り替わっているのかを完全に理解しています。 そして、エンジニアとしての私にとって、このプロセスには多くの不可欠な利点があります。
- やる気
時々、仕事に取りかかるのは難しいです。 誰も私をフォローしていないので、誰もが私に満足していることを知っているので、ゴミに苦しんだり、役に立たないニュースを読んだり、ソーシャルネットワークで凍結したりする大きな誘惑があります。 そして、ここでスタンドアップが助けになります！
フロイトが言ったように：「私たちのすべての行動は、性的欲求と偉大になりたいという欲求という2つの動機に由来します。」 この願望が、私があらゆるスタンドアップに真剣に準備することを可能にします。 スタンドアップのない日には、集まって計画した量の仕事をするのがより難しいことに気づきました。 - 柔軟性
残念ながら、プログラミングでは、特定のタスクにかかる時間を正確に予測することが難しい場合があります。 そして、プロセスが実装の過程でこのスプリントからいくつかのタスクを除外したり、最初の見積もりに誤りがあったことが判明した場合にリソースを再配布したりすることができれば非常に便利です。 - チーム同期
チームが毎日集まって、今何をしているのか、何をしようとしているのか、どのような問題が解決されているのか、そしてどの問題が起こっているのかを見つけることが好きです。 私の目の前では、多くの場合、数分でデッドロックの問題が解決されました。立ち上がった後（またはイデオロギーに違反して時にはチーム全体が）集まって、問題だけを考えました。 - コード品質
製品のエンジニアリング担当者が何らかのドキュメントではなく、コードそのものである場合、それに対する態度はより深刻になります。 多くの方法論において、コードは非常に重要ですが、エンジニアの仕事の結果がほとんど唯一のコードであるコードはほとんどありません。 そしてGitは彼を裁判官に責めました。 - 復習
このプロセスのレビューは非常に非公式であり、実際にコードの改善に集中できることが気に入っています。 同時に、私はコードレビューが直接行われるアジャイルの解釈に個人的に最も感銘を受けました。 これは現代的ではなく、常に可能ではないことを理解しています（特に一部がリモートで動作する場合）。 しかし、コードだけでなく、著者の意見も聞いた場合：なぜ彼がそれをやったのか、そして彼がそれで何を達成したいのかを聞くと、推論のエラーを見つけたり、改善のためのアイデアを見るのがはるかに簡単です。
短所
また、このプロセスの不完全さも印象的です。
- 要件の変更
要件が絶えず変化するため、製品自体の実装に関する初期条件を順守することは困難です。 また、割り当てられた時間内にすべてを完了することは不可能であり、他の何かを緊急に変更する必要があることが判明する場合もあります。
- キャンセルされた機能
プログラマーがあなたの努力が無駄であり、実現された機能が今後のリリースに含まれないことに決めたと言われたとき-これはめったに彼を刺激するのに役立ちません...
- デザインティム
設計者にとっての「柔軟な」プロセスは、多くの場合プログラマにとって地獄になります。 多くの場合、コードを書き直して、これがすぐには機能しないことを説明する必要があります。この変更により、通常、以前のすべての作業が無駄になります。 私見、彼らは機能を実装する前に赤信号を持っている方が良いです。
- スタンドアップ中に時間を失う
15分以内に維持することはめったに不可能であり、多くの場合、立っている多くの参加者にとってほとんどの時間は役に立たない。
- 悪いコードだけでも多くの害を及ぼすことがあります。
残念ながら、アジャイルは従業員とそのコードの品質に非常に敏感です。 このプロセスでは、不注意なプログラマーがチーム全体の生活を困難にする可能性があります。
- 私生活
通常、稼働時間も「柔軟」になります。 そして、1時間以内に、自分自身を解放できる時間と、週末に何かを緊急に完了する必要があるかどうかを明確に予測することは非常に困難です。
- ユニットテスト運転開発
私見では、アジャイルには多くのアイデアがあります。 単体テストの開発に多くの時間を費やしてから、正常に完了するようにコードを記述しますか？ おそらく、これが理にかなっているプロジェクトがあります。 しかし、私が通常会ったことは、プロによる5分間の実際のテストをカバーしない単体テストを開発するために、数ヶ月のプログラマーの仕事を必要としました。 最小限の自動テストのセットがおそらく必要ですが、それらから製品全体を開発する場合、IMHOは利点よりもはるかに多くの時間を運びます。 - ペアプログラミング...
この方法は、私の人生で3回本当に役に立ちました。 しかし、これはこのタスクで（通常、何らかの複雑なバグの経験から）実際に要求され、メソッドのためにメソッドとして使用されるべきではありません。
結論として、私はウィンストン・チャーチルの民主主義に関する有名なフレーズを思い出します。これはアジャイルに適用できます。
「民主主義は最悪の形態の政府です。ただし、時折試みられた他のすべてを除きます。」