プロジェクトマネージャーのPavelは、どのようにしてほとんどの問題を簡単に解決できるかについての話を共有しました。
昨年5月からKUKU.io SMMアプリケーションを開発してきましたが、タスクの混乱を最小限に抑え、できる限り頻繁に尋ねられる新しい機能機能にユーザーが満足するように、すべてのプロセスを構成することができました。
KUKU.ioは、開始時に4つのソーシャルネットワーク（Facebook、Vkontakte、Twitter、Linkedin）にコンテンツを公開できました。 間違いなく、ソーシャルネットワークの本格的な管理とは言えず、アプリケーションは徐々に他の機能を獲得し始めました。ユーザーは、 ソーシャルネットワークアカウントのチャネルまたはプロジェクトへの分離を見たいと思っていました。 ソーシャルネットワークの分析は 、サービス、 、1つの投稿の多くの写真、新しいソーシャルネットワーク（現在KUKU.ioは10をサポートしています）など-これらはすべて実装する必要がありました。
私がプロジェクトに来た初期には、すべてがはっきりしているように思える状況がありましたが、実際には何もはっきりしていません。 この製品はすでに生産されているので、詳細なしで、どのようなプロジェクトを非常に迅速に実現しました。 さらに、チームはすぐにクールなUX / UIの世話をしました。ソーシャルネットワークから遠く離れた人でも、数分でそれを把握できます。
チーム...チームがあります。全員が優秀で、その分野の専門家です。非現実的な開発者からマーケティング担当者やsmmshchikまで。 誰が明確でないことをします。 :) プロジェクト管理とシステムには何らかの種類があります：JiraとGanttPRO、それらには何かがありますが、これはちょっとしたアイデアでもありません（タスクを待つ、それらの最小限の説明、ロジック、何もない）。
私はドキュメントを調べています-ドライブにはたくさんのフォルダーがあり、アルファ版、競合他社の分析、ベータ版、デモ、スペック1.0バージョンなどの名前に従って類似したものが計画されています。 あなたが開きます-見出し、いくつかの下書き、それだけです。
その結果、私たちには次のようなものがあります：どのように、そして何が機能するのか、誰が何に取り組んでいるのか、誰が製品の所有者で、誰が何に責任を持ち、プロジェクトがどこに向かっているのか、将来の目標は何なのか、作業ルールは何なのか あなたが見ることができるように、計画はそれが何であるかを決定しませんでした、彼らはある種の柔軟なフレームワークに来ようとしましたが、彼らはそれをすべて捨てました。 その結果、4か月で大量のリリース、オープンスプリント、巨大なスプリントがありました。 作業プロセスにはそのようなスキームがありました。チームのほとんどすべてのメンバーは、説明なしで自然にJiraで問題を作成しました。
つまり スプリントまたはバックログに登ります。「既存のブロックを変更する」または「ログインが機能しない-コンソールエラー＃」というバグがあります。
クリアビジネス、ごく最近生産中の製品。 多くのバグがあり、機能的な機能だけでは十分ではないため、迅速に展開する必要があります。 さらに、支払いシステムは結び付けられていなければならず、火災は完了しています。
したがって、簡単なものから始めました。
- 基本かんばんを採用しました（プロジェクトなので、タイミング基準はありません）。
- 誰が何に責任を持ち、誰が決定を下すかを決定しました。
- 実際のタスクを選択しました。
- 優先順位を設定します。
- 環境の説明とともに、ユースケースの形式でバグを説明する方法について、QAに同意しました。
- 最後に、彼らはバックログをフィードしました（多くの時間がかかりました）。
- バグの数を減らすために、ストーリーを通してすべてを説明し始めました。
アウトソーシング企業に適しているが、独自のプロジェクトでは完全に実現不可能なさまざまなメカニズム、推定手法、およびフレームワークがあります。 私たちはさまざまな方法論から要素を選択し始め、何が根付くかを試してみました。
スクラムからデイリーミーティングに参加しました。これにより、ワークフローの問題点がすぐにわかり、誰が何に取り組んでいるかを把握し、チーム内でコミュニケーションを確立することができました。 残念ながら、最初は非常に長い時間、時には最大1時間かかりました。 この問題は、チームがより自律的になったときに解決されました。現在、会議で問題を議論する場所はありません。誰が何をし、それを行う予定かについての簡単なレポートのみが作成されます。
その後、 反復を試みましたが、製品がライブであり、チームが機能を1つずつ爆撃し、バグが小枝であるため、これは望ましい効果を与えませんでした。 最初はあまり助けにはなりませんでしたが、ゆっくりと、しかし確実に、これに到達します。
特別な意味がなかったため、回顧展は導入しませんでした 。 計画は1か月間行われました。これは、あまりにも動的なプロジェクトであることがほとんどわかっていなかったためです。ただし、期限に問題があります。 後でストーリーポイントに行き、すべてをタスクに残すことにしましたが、ロジックとユースケースの説明により、すぐに結果が得られました：受け入れ条件は誰にでも明らかであり、バグの数は減りました。
CI（継続的インテグレーション）の大部分はXPから取得され 、更新を加速し、より良いリリースをリリースすることを許可しました;ユーザーのフィードバックは優先順位付けの基礎として採用されました。 すべての決定は、自己の責任において下されました。
ところで、優先順位について。 これは最も痛みを伴うプロセスの1つになりました。 誰もが彼の仕事が最も重要であると信じており、最後までそれのために戦っていますが、私はより少ない「血」を優先したいと思います。
以前は、すべてのユーザーを満足させるために何をすべきかわからず、すべてに急いでいたようなタスクとフィードバックのストリームがありました。 次の段階は、アクションの完全な非同期でした。私のタスクがメインです。 ある種のプロセスをデバッグし、それがすべての人にとってうまく機能しないことを理解したので、ユーザーの推奨事項を適切に配布し、内部タスクと新しいリクエストのバランスを取り始めました。 嬉しいことに、ユーザーのリクエストはほとんどの場合非常に似ており、自信を持って新しい機能を追加できます。
Kanbanは理事会を支援し、 CIのニーズに基づいていくつかの列を追加しました。
後でスクラムからストーリーと叙事詩を取り上げました -詳細な計画を立てます。 より詳細な計画と短い反復に取り組んでいると言えます。 これで、ほぼ1か月前に80〜90％の前進が得られることがわかりました。 また、簡単に編集することができます。
私たちの次のステップは自律チームの作成です 。 誰もが自治チームはクールだと書いています-そして、それは本当にクールです（すでに多くのことがあります：より多くの関与、興味、リターン、それは志を同じくする人々のグループをチーム、より少ないリスクと誤解と呼ぶことを可能にします）-しかし、ほとんどの開発者は彼らを好む彼らは触れなかった、彼らは私たちにTKを詳細に教えてくれます、そして私たちはこのTKに従ってすべてをします、そしてそれが明確でないなら、私たちはすべてクールで、私たちの裁量でそれを行い、私たちの意思も決定します
私たちの場合、自律性につながったもの：
1） 絶えず変化し成長している製品と休日 -すべてが他の参加者の役割で火薬を嗅ぎ、 製品に何がどのように配置されているかを考えました。
2） 毎日の集会 -私たちは皆に何をしているのかを伝えるだけでなく、問題を迅速に解決しようとするため、少なくとも耳からはチーム全体が変更または問題について知っています（議論が引き継がれることを理解したら、残りはリリース参加者）。
3） 計画 -私たちは現在何を持っているのか、そしてどこに行くのかを知っています。
4） チームの結束 -バーに行く 、企業のパーティー 、活発なコミュニケーション、プレッシャーの欠如。
5） コミュニケーション -私たちはまだこの方向に成長する必要がありますが、今、誰かが問題を抱えている場合、彼らは長い間彼女を毛布に入れたままにしませんが、すぐに彼らの妖精を言うか鐘を打つ、声を出す恐れはありません
これはすべて、中期的な目標が明確であるため、仲間や外的要因へのタスクの依存関係を知っている男たちが盲目的に働かず、小さな学校や問題が芽や芽ですぐに修正されるという事実につながりました:)、より少ない修正と技術的負債。
それで、結果は何ですか？ まず、バグの数を減らしました。どれだけ言っても、絶対に取りません（正直言って、記録を残さず、分析するのは面白いです）が、出力では非常に堅実な製品があり、表示されるバグは重大ではありません-軽微な欠陥これは主に不注意によるものです（ただし、マージとデプロイにはまだ妨害があります）。 しかし、QA（および1を持っています）がより使いやすくなり、リリースされたユーザーに非常に満足しています。
約1か月を計画してから、修正、リグレッション、展開を行います。 合計で、約5〜6週間ごとに、主要な機能を備えたアップデートとバグ修正を備えたアップデートをリリースします-ユーザーからのメッセージが到着するとすぐに。 以前は、一般的に、私たちの計画は宇宙空間でした。 3週間のスプリントは、数か月間引きずられる可能性があります。
明るい最近の例：これは、ソーシャルネットワークのコンテンツプラン、およびSMMとマーケティング代理店、および複数の人がソーシャルネットワークのプロモーションに従事している企業のチームプランです。 最初の見積もりで1か月後に行うと考えた最後の方法は、それがどうあるべきかを理解していません。 分析、分解、小さな「仕様」の作成後、タスクの範囲は2か月で評価されました。 実際、チームはチームプラン、そのための一連のボディキット、SMMとマーケティングパン、年間サブスクリプション、ソーシャルネットワークでの分析の改善、これらすべてのテスト、回帰を行い、3か月で本番環境にリリースしました。 これには、3人の開発者がいて、2人がホステルからのセッションと立ち退き、コンテンツプランが並行して作成され、相互に接続されており、競合することなく中断する必要があるという事実を考慮しています。 そして、それはすべて説明どおりに機能しました。 これは大成功です！
別の成果は巨大な成果です-チーム内の競合が少なくなります。
さらに、私はより頻繁なリリースに来て、私たちの今後のアップデートをユーザーに通知したいと思います。 ロードマップ全体を表示するのはそれほどクールではないようです-関心はなく、誰もがあなたの手のひらの上にいて、彼らはこのように待つでしょう。 :)