開発プロセス：50か月の進化

当社はすでに6歳です。 アジャイルの原則に基づいており、それらに基づいて成長しました。 初日からエクストリームプログラミングを使用し、後でスクラムを少し追加し、最終的にかんばんに切り替えました。 貴重な経験を共有し、過去4年間の開発プロセスの変化についてお話したいと思います。

コンテキスト

コンテキストは非常に重要です。なぜなら、それはあなたにとって何がうまくいき、何がうまくいかないのかを理解するのに役立つからです。 かなり大きなWebアプリケーションであるTargetProcessを作成しています。 私たちのチームは同じオフィスビルの同じフロアにいます-配布はまったくなく、近くにあります。

2008年	2009	2011	2012
会社の規模（人）
15	22	30	40
チーム構成
機能横断型チーム	2つのチーム： カーネル （5人の開発者、スクラムマスター、3人のテスター） 統合 （3人の開発者、チームリーダー、テスター）	いくつかのミニチーム。 大きな機能ごとにミニチームを編成します。 ミニチームは、この機能の実装を完全に担当します。	いくつかの（ただし、さらに多くの）ミニチーム
テクノロジー
C＃、ASP.NET、ASP.NET Ajax、 NHibernate	C＃、ASP.NET、 ExtJS 、NHibernate	C＃、 jQuery 、NHibernate、 NServiceBus	C＃、NHibernate、NServiceBus、100％Javascriptフロントエンド、 REST 、 Python

観察

1チーム→ミニチーム。 会社の成長に伴い、1つのチームが複数のミニチームに置き換えられました。 ミニチームは、大きな機能の設計と実装を完全に担当し、通常、デザイナー、1〜3人のプログラマ、プロダクトオーナー、1〜2人のテスターとライターで構成されます。 ミニチームはすべての技術的な決定を下し、アイデアをブレインストーミングし、問題の解決策を見つけます。 彼女は非常に自律的で集中しています。 現在、6つのミニチームがあります。







テクノロジー 。 サーバー側は非常に安定しています。 これはすべて同じ.NETスタックです。 この間、.NET 2.0から.NET 4に移行しましたが、昨年プラグイン用にESBを追加し、システムの拡張性とスケーラビリティを改善しました。 私たちは、NHibernateがどのように機能するかにあまり満足しておらず、CQRSに向かっています 。 フロントエンドを安定と呼ぶことはできません。 現在のUIは、ASP.NET Ajax、ExtJS、および独自のフレームワークからの悲しいカクテルです。 進行中の努力は、このすべての幸福を統合することを目的としているため、非常に近い将来、古いUIは完全に新しいUIに置き換えられます。 嬉しいことに、システムは古いインターフェイスと新しいインターフェイスの両方で使用できます。これにより、既存のユーザーの移行が大幅に簡素化されます。 ここ数年、テクノロジーへのフォーカスがどのように変わってきましたか。

プロセス

2008年	2009	2011	2012
繰り返し
1週間	繰り返しはありません、 カンバンに切り替えました
進捗管理ツール
タスクボード 、反復バーンダウン、リリースバーンダウン	かんばん 、サイクルタイム	かんばんボード、サイクルタイム、 ビルドボード	かんばんボード、チームボード、サイクルタイム、ビルドボード、 キッチンのロードマップ
2008年	2009	2011	2012
回顧
2週間ごと		必要に応じて会議を開催します。期間はありません。 彼らは、3つの問題を制限したIssue Boardを思いつきました。 3つの問題が蓄積されるとすぐに、会議を開いて解決します。 誰でも問題を書くことができます。	私たちは、関係者のみと立ち会うことができます。 これは頻繁には起こりません。
職務評価
ポーカーを計画しています 。 ユーザーストーリーをポイントで評価する	しかし、仕事を評価しないでください
費やした時間の会計処理
すべてのタスクとバグの明確な会計。		記録を残しません。 疲れた。
2008年	2009	2011	2012
議論の要件
反復計画会議	ユーザーストーリーの「会議の開始」。 各ユーザーストーリーは、開始する前に説明します。 会議には、プロダクトオーナー+テスター+開発者+デザイナーがいます。
仕掛品の制限
繰り返し	3ユーザーストーリーで制限。 作業の進行状況をもっとすべきではありません。	制限のスコア	開発者あたり2ユーザーストーリー（1推奨）。 一般的に、ミニチームは自ら決定します。
リリース計画
公式会議。 通常、リリースは2か月続きます	計画はありません		私たちは、今後数ヶ月の高レベルのロードマップを作成しています。 3か月ごとにレビューされます。
2008年	2009	2011	2012
ユーザーストーリーの粉砕
ユーザーストーリーは毎週の繰り返しに分割する必要があります	私たちは分割しようとしますが、どういうわけかうまくいきません	それでもまだ...	少し良くなりましたが、練習するのはまだ難しいです
ユーザーストーリーの完了（ DoD ）の定義
仕様は最新です 合格したテストケースのセット 単体テスト	キックオフミーティング 仕様は最新です 合格したテストケースのセット ユーザードキュメント デモチーム	キックオフミーティング 仕様は最新です 合格したテストケースのセット 自動ケースのセット ユーザードキュメント デモチーム	キックオフミーティング 仕様は最新です 合格したテストケースのセット 自動ケースのセット ユーザードキュメント デモチーム グリーンビルド 人間のテキスト 性能試験
2008年	2009	2011	2012
ミーティング
リリース計画 （チーム） 反復計画 （コマンド） 反復デモ（コマンド） レトロスペクティブ （チーム） 毎日 （チーム）	ユーザーストーリーの起動（3〜4人） ユーザーストーリーデモ（4人以上） レトロスペクティブ（チーム） 毎日	ユーザーストーリーの起動 ユーザーストーリーデモ ストップザライン（チーム） 毎日	ユーザーストーリーの起動 ユーザーストーリーデモ（テスト前！） ストップ・ザ・ライン（適切な人々） 毎日
毎日の会議
朝10時に食べると約10分かかります	午前11時の食事には約15分かかります
Ux
なに？	ワイヤーフレーム	スケッチ （多くのアイデアと高速）、ライブプロトタイプ、 生きている人々のユーザビリティテスト 、 デザインスタジオ	スケッチ、ライブプロトタイプ、動作中のシステムでのユーザビリティテスト
職人技
なに？	ワークショップ	給与はトレーニングに依存 ミニカンファレンス クールな会議に参加して有料 ワークショップ 金曜日のショー 週に5時間の独学	給与はトレーニングに依存 ミニカンファレンス クールな会議に参加して有料 独学または個人プロジェクトの場合、週5時間

観察

反復→カンバン。 反復を3年間使用してから、かんばんに切り替えました。 全体として、それは良いイベントでした。 主な目標は、各機能と各修正を個別に、できるだけ早くリリースする機能です。 多くの定期的な会議は廃止され、オンデマンド会議に置き換えられました。 時間が経つにつれて、時間の追跡とパフォーマンスの評価を放棄しました。 反復を放棄することのマイナスの効果の1つは、フィーチャが大きくなることへの欲求でした。 繰り返しがない場合、作業を小さなものに分割する必要は特にありません。 私たちはさまざまな成功を収めて3年間これと戦いました。 一般的に、大きな機能が勝っていますが、今年は状況が良くなりました。



ポイント→評価の拒否。 反復開発では、見積もりが必要です。 かんばんに切り替えたとき、評価のメリットがあまりないことが明らかになりました。 ここで、「数日」、「暫定的に1週間」、「1か月以内」、「非常に長い」レベルで作業を評価します。 プロダクトオーナーが見積もりを逃すこともありますが、ロードマップの作成を開始したとき、このような大きな機能の一般的な見積もりはかなり正確であることが判明しました。



タイムトラッキング→会計の拒否 。 夕方と週末に4人しか働いていない場合でも、プロジェクトの最初の日から費やした時間を記録しました。 そのため、時間の追跡は私たちの血の中にあり、給料さえも費やされた時間数に結びついていました。 時間の追跡をキャンセルする決定は容易ではなく、チームの多くがそれに反対しました。 驚くべきことに、数ヶ月後、すべてが落ち着き、震えのある大多数の人々はその日の時間を埋めることを覚えていました。 実際、作業を評価していない場合、時間を考慮することは意味がありません。



リリース計画→なし→ロードマップ。 このような左右のリールは、（側面から）奇妙に見える場合があります。 最初は、正式なリリース計画会議を開催しました。 そして、かんばんを紹介し、会議はどういうわけか死にました。 リリース計画がなければ悪化することがわかりました。 私たちは常に焦点を失いました。 明確なフォーカスリリースは非常に便利で便利です。 あなたは重要なことに集中し、残りは無視します。 焦点が合っていない場合は、疎結合された多くの小さくてあまり機能のないものを作成するという大きな誘惑があります。 これにより労力が消耗し、最終的には機能のリストのみがリリースされます。 少し前まで、リリースを計画する代わりにロードマップを作成することにしました。 開発では、3〜4個の大きな機能を使用できます。 各機能には特定の目的があり、3〜12か月かかります。 ロードマップには、現在のすべての機能と将来の機能がすべて表示されています。



ユーザーストーリーの破壊 。 おかしいが、それをうまくやる方法がまだわからない。 破砕作業は困難です。 はい、特定の改善がありますが、時折、大規模なユーザーストーリーが断片化せずに開発に漏れることがあります。 粉砕には何らかの内部的な複雑さがあるようです。



完了の定義 。 傾向は明確です。DoDは年々飽和状態になり、より多くのものが含まれています。 プロセスは開発中であり、すべての機能を完全にリリースする準備ができていることを確認したいと思います。 最近、テキスト検証とパフォーマンステストをDoDに追加しました。



毎日の会議。 私たちのレビューの昔の人は、ほとんど変わらずに4年間生き延びました。 人数の増加に伴い、私たちはあらゆる方法で会議を短く具体的にしようとしました。 一般に、これは可能でした-15人の場合、会議は約15分間続きます。



組み立て。 今では、特定の問題に焦点を当てた本当に有用な会議だけが生き延びています。 唯一の定期的な会議は、毎日の朝の礼拝です。 スクラムには非常に多くの会議があります。 これは、通常の開発プロセスを実装し始めたばかりの場合には良いかもしれませんが、時間が経つにつれて退屈で迷惑になります。 オンデマンド会議の方がはるかに優れています。人数が減り、焦点が絞られ、結果が向上します。



ユーザーエクスペリエンス。 それはすごかった。 4年前、私たちはUXについて何も聞いていませんでした。 現在、UXは会社のDNAにほぼ統合されています。 チームの多くの人々は、エンドユーザーによる製品の使いやすさ、デザイン、認識に多大な注意を払っています。 UXの植え付けプロセスは十分に長く、製品のビジョンの変更から始まりました。 私たちは人々を訓練し、会議に出席し、セミナーを実施し、本を読み、非常に異なる実践を試みました。 いくつかの良い結果は2年後に現れました。 そして今、私たちは新しい大きなリリースに取り組んでおり、中間結果はめちゃくちゃクールです（表示するまでは、陰謀を作成します）。



職人技。 4年前、プロのスキルのトレーニングと開発は会社の文化の一部ではありませんでした。 すべては2010年に開始され、開発戦略全体が完全に改訂および変更されました。 今、私たちは完全な知識の精神を持っています。 真剣に。



ここに、会社の発展の焦点が長年にわたってどのように変わったかを示します。

技術的慣行

2008年	2009	2011	2012
ソース管理とブランチ
転覆 1つのブランチ。	Git 各機能またはバグ修正は、別々のブランチで行われます。 ウィザードは常にリリースの準備ができています。		ギット。 1つのブランチに戻り、継続的デリバリーに移行
ペアプログラミング
ペアプログラミングが厳密に必要です。 開発者は毎日ペアを変更して、問題を新鮮な外観で確認し、経験を交換し、真の集合的なコード所有権を達成します	すべてのユーザーストーリーと複雑なバグには必須です。 時には人々はより単純なタスクで一人で作業します。 ペアの変更がキャンセルされました。 フォーカスを妨げ、迷惑になることが判明しました	複雑なタスクにのみ使用されます。	完全にオプションです。 ミニチームは自分で仕事の仕方を決めます。
TDD / BDD
TDDを強くお勧めします。 ユニットテストは、ユーザーストーリーごとに厳密に必要です。	すべての新しいコードはテストでカバーされています。 JavaScript側では、事態はさらに悪化しています。 また、 BDDを使用しようとしています	JavaScript側では、すべてが順調です。QUnitを使用します。 BDDは拡大および成長しています	BDDに明確に焦点を当てます。 NBehaveを自分のニーズにわずかに変更し、VSアドインを作成してテストスクリプトをすばやく作成しました
自動機能テスト
Seleniumのいくつかのテスト	Seleniumの多くのテスト。 テストを作成およびサポートするために、独自のC＃フレームワークを作成しました。	20台の仮想サーバーで機能テストを並行して実行	Selenium WebDriverへの移行。 ほぼ40の仮想サーバーがあります
継続的インテグレーション
とても簡単です。 ソースコードがコンパイルされ、 Cruise Controlの単体テストが開始されます。	いくつかの異なるセットアップでCruise Controlを使用します。	ジェンキンスに切り替え	まだJenkinsを使用しています。 新しい目標は、時間の経過とともに継続的デリバリーに切り替えることです。
機能の切り替え
いや			機能の切り替えを使用して、継続的な配信に移行します。
テストカバレッジ
神は知っている		単体テストで50％、機能テストで30％	単体テストで70％、機能別で40％

観察

1つのブランチ→ブランチの機能→1つのブランチ。 好奇心が強いループ。 機能ブランチは、かんばんの導入後に可能になりました。 2年間使用しました。 ただし、継続的な配達を望む場合は、数か月前に1つのブランチに戻る必要があります。 移行は簡単ではなく、機能ごとにブランチを維持するのがはるかに簡単で安全だったため、3〜4週間のトランクは80％の確率で赤くなりました。



ペアプログラミング。 このプラクティスは、必然的に完全にオプションになりました。 必須のペアプログラミングは非常に難しいものです。 あなたは一日中カップルとして働き、コミュニケーションし、議論し、あなたの視点を守ることを余儀なくされています。 エネルギーを消費します。 はい、あなたは多くのことをしたと感じていますが、少なくとも数ヶ月連続で働くことは容易ではありません。 現在、ペアプログラミングは主に非常に難しいタスクに使用されています。



TDD→BDD。 テストによる開発は、コードの最初の行（まあ、ほぼ）から適用され、常に使用されていました。 BDDは、プロダクトオーナーにとってより事例指向であり、理解しやすいものです。 彼は現在、Given / When / Thenフォーマットでふざけて仕様を書いています。 一般に、私たちは視覚的な仕様に移行しています。視覚的な仕様では、多くの写真がありますが、言葉はほとんどありません。



そして、現時点でのいくつかの統計：

• 5200ユニットテスト
• 2500の機能テスト（1700のSeleniumと800のJavaScriptテスト）
• すべてのテストは38台の仮想マシンで実行されます
• 短いアセンブリ（インストールパッケージなし）には40分かかります
• 完全な組み立てには1時間かかります
• 2011年のGitリポジトリへの8400のコミット

結論として

それが私たちが過去4年間でやってきたことです







PS誰かがHabrにテーブルを普通にフォーマットさせる方法を知っていたら-教えてください。