ソフトウェア開発プロセスでカオスと聖戦に役立ついくつかのアイデアを共有したいと思います。 明確にするために、いくつかの詳細を追加します。私はプロジェクトマネージャーであり、中規模企業（〜40人の脳）がオフショアプログラミングに携わり、混合チーム（15％シニア、35％開発者、35ジュニア、15％インターン、および専門分野-開発、品質、インフラストラクチャ）。
プロセス
カオスの原因は十分にあります。顧客との長いコミュニケーションチェーン、異質で一般的に若いチーム、「スラブメンタリティ」（偏心した創造性と頻繁な瞑想;））、コミュニケーションの問題、販売員の政治的なゲーム（販売は私たちです"）などを販売する
カオスでは、正しく動作しません。 遅延、品質低下、ミサゴと顧客との不一致の主な原因です。 ソフトウェア開発のためにプロセスまたはライフサイクルを構築する必要があります。 このテーマに関する本はたくさんありますが、決して役に立たないというわけではありませんが、残念なことに、*私たちの*ケースへの直接の出口は見つかりませんでした。 繰り返しますが、これは私の経験です。 あなたの何人か、私の友人が、例えば本からスクラムを紹介することができた可能性があります。 残念ながら、私は成功しませんでした。 プロセスに必要な規則が多いほど、保護されていないプロセスの谷への進入が速くなります。
試行錯誤の方法により、実用的なアプローチ（木材のノック）がもたらされました。 プロセスは次のようになります。
これは反復的なアジャイルプロセスです。 要件は、短いユーザーストーリーとして表示されます 。 仕様はテストケースの形式です。 ここでは、スクラムから多くを取得しました。 プロダクトオーナーがいます。彼は通常アメリカ人です。彼の仕事は、顧客と密接にコミュニケーションを取り、頭の中でプロジェクトの一貫したアイデアを形成することです。 反復の開始時に、反復に進むタスクについて話し合います。 通常、この時点でユーザーストーリー（タスク名）のリストがあります。 その後、QAエンジニア（品質エンジニア）は、テストストーリー形式で各ストーリーの短い仕様を作成します。
最初の反復はアーキテクチャであり、その間に将来のシステムのレイヤーが構築され、暗い場所のプロトタイプが作成されます。 2番目から始まるすべての反復は機能します。 反復期間は3〜4週間です。
ガントチャートは 、プロジェクト評価計画（すべての反復）を表すために使用されます。 チームの構成に基づいて開発プロセスをシミュレートできます。 評価計画は、プロジェクトの予算または個々のフェーズを調整するために使用されます。
単一の反復を監視するために、バックログが使用されます。
これは、2つのバックログを含む機能的反復計画がどのように見えるかです。
最初のバックログには、従来、顧客と合意したユーザーストーリーおよび変更要求（または、一般的には簡単な方法で機能）が含まれ、2番目のバックログには、この反復に関連するバグが含まれます。 スクラムのように、スプリントと呼ばれる最初のバックログ。
さらに、機能またはバグの進行状況は興味深い方法で取得されます。 1つの問題があります-プログラマーはレポートを書くことを好みません。 また、誰かが質問する時だということを理解するのに時間がかかることもあります。 このような問題に完全に対処できる最新のアプローチがあります。 これはマイクロブログです。 マイクロブログの例はTwitterです。 プログラマーが自分のタスクに入り、次のような短い投稿を書くことができるオンラインツールを想像してください。「私は少しタスクにこだわっています。モデル内の2つのエンティティ間の接続のタイプを変更する必要があります：ユーザーとトレーニング。 そしてクーラーで水がなくなった。 完全な混乱。 完了率-47。」 さらに、このオンラインツールは、一般的な反復ガントでプログラマーによって導入されたタスク進捗の最後の値を表示します。
シンプルなマイクロポストとその頻度は、正式な日報よりもプログラマーの仕事について多くを語っています。
前述のオンラインツールとして、独自の開発を使用します。 ただし、スパムで告発されないように、この投稿ではリンクを示しません。 ブログ「I am PR」で後ほど説明します。 ただし、別の一般的なツールであるdotProjectを使用して、ガントとマイクロブログを操作できます。 しばらくの間、このツールのタスクでロギング機能を使用しました。
タスクや機能の終了箇所に尾を切り落とします。
長い間、私たちは許容できる品質でフェーズとプロジェクトを時間通りに引き渡すことができませんでした。 主な問題は、面倒なバグのリストという形での機能タスクの「テール」でした。
外見上はミサゴ全体が完了したように見えましたが、プレゼンテーションパスの右または左へのステップがヒゲの覆われたまたは覆われていない例外につながるため、プロジェクトをそのまま提供することはできません。
また、開発者から最初に受け取ったタスクの見積もりを追加する価値があるため、この状況は圧力の影響ではありませんでした。
実際、問題はプログラマーとQA-schikiの間で「機能が作られた」状況に対する異なる理解でした。 短い反復のため、先週のすべての未完成の機能の統合後にテストが実行されました。 そして悪夢が来ていた。 カオスの休日でした。
問題はどのように解決されましたか？ 私たちはルールを導入しました-プログラマーは自分のタスクに100％を設定する権利がありませんでした。 彼の最後のマイクロポストは次のようになっているはずです。 聞こえますか？ すべて！ 進捗は99％です。」 次にマイクロポストのリードまたはマネージャーが来ました。 ジェンヤをチェックします。 進捗は99％です。」 ZhenyaはQAボックスです。 ほとんどの場合、彼は1-2の実装バグ、1-2のテストケースからの失われたサイト、1-2の欠陥の使いやすさを発見し、タスクの下に次の投稿を書きました：「バグがあります[バグトラッカーへのリンク付きのリストがあります]。 進捗は60％です。」 次はタスクの完了です...
これらの100％-60％= 40％はタスクのテールです。 説明したアプローチで、それを切り落とすことを学びました。
このようにしてすべてのバグを機能に追い込んだとは思わないでください。 まだ統合エラー、仕様の論理エラー、アーキテクチャ上の制限などがあります。 これらのバグは2番目のバックログに分類され、優先順位付け、評価、有効化、反復から除外され、修復されます。
このメモで、投稿を終えたので、予想よりも長くなりました。 すべてを説明することはできません。 近い将来、この方向でさらに1-2の投稿をしようとするでしょう。
がんばって。