アジャイル開発は以前に彼はアジャイル開発で行ったアジャイル開発を理解するために言われて、関連コンテンツを見ている、と後で私が「擬似アジャイル」モードの効率を改善するために、プロジェクトのセットを確立する方ができ滝やアジャイル開発を兼ね備えています。
まず、アジャイル開発は何ですか
ユーザーニーズへのアジャイル開発は、ソフトウェア開発のためのコア、反復的、漸進的なアプローチとして進化します。初期構築物におけるアジャイル開発ソフトウェアプロジェクトは、視覚的に、各サブプロジェクトの成果は、テストされているサブプロジェクトの複数に切断され、統合された機能を使用して実行することができます。言い換えれば、このプロジェクトは、相互に接触し、多数に分割して、だけでなく、小規模なプロジェクトとは独立して実行することができ、使用可能な状態になっている本ソフトウェアの過程で完成しました。 - ソースBaiduの百科事典
実際には、内部の上記の説明から、アジャイル開発は、チームワークをより重視、迅速な応答、連続生産、滝に比べて、継続的な可用性「「」アジャイル開発ステップによって「ユーザニーズは、進化」」繰り返し、ステップの中核概念でありますアウト。2つのモデルが自分の長所と短所があり、実際には、非常に少数の純粋なアジャイル、稀に純粋な滝の開発は、より多くの二つの組み合わせです。
第二に、私の「擬似アジャイル開発」
純粋なアジャイル開発は、ユーザーのニーズ、およびオンライン急速その後、チーム分析チームのモデリング、急速な発展に基づいています。同社の製品のほとんどは、製品ラインを担当することに加えて、純粋な生成物ではありませんので、しかし、このアプローチは、テストチームと制御の仕事ですが、また、他の多くの仕事を取り、チームの質と能力は非常にではないかもしれません高いです。だから、純粋なアジャイル開発には比較的まれです。
我々のチームのほとんどは滝であり、私は事態の正常化が一晩であるとして、次に開発するチーム、オンラインバルク、生と死の大部分は、ライン上のすべてのマークされている、需要の束をしました。また、私はこの練習を始めたが、後に細かいの解体を要求するにはあまりにも疲れた、あなたは常にプロジェクトを停止することができますので、最小限にファンクションポイント間の結合を低減し、徐々に出力用に設定されますが、また、顧客の需要を満たすために継続していないが、また、実装チームを要求しても問題。
これは、コアとして滝に、その上にあるが、生成された「擬似アジャイル開発」と組み合わせるアジャイル開発設計に取り付けられています。この追求は、需要の過半数、他のメジャーバージョンアップデートせずに、オンラインで行われている改善、チーム減圧を促進するためのチームを再生する機能です。
私の練習のいくつか：
図1に示すように、機能テストに深く関与した生成物は、細部の品質を制御します
その後、私はチームを取った、この相互作用するかどうかを理解しやすく、理解しやすいボタンをコピーするように注意し、一人ですべての機能の詳細を、製品をテストするために必要とされています。スタッフは単に製品設計の多くを発見したので、その後、ユーザーがフィードバックの問題が発生することができ、設計と実装、そして最終的には直接ユーザーにするインタラクションデザイナーを投げました。しかし、プロセス内で、製品の品質要件は、非常に低く、製品設計につながる、よりスラグ、この製品がより攻撃的なスラグのユーザーエクスペリエンスデザインを知りません。
図2に示すように、監視期間及び実施例品質の周波数の間
、前：月曜日、5それぞれの正規の仕事のニーズを議論するために月曜日に週に一度の会議、今週と、金曜日の進捗更新として、来週の予定。基盤となるアーキテクチャのこの段階では、開発者は、定期的に、毎日の議論はまだ一日となり、製品が限りのような大きな特長の方向からの偏りがないよう（ここでの唯一のチーム全体が通信会議に焦点を当てたと言う、他のプロジェクトを行う必要があり、設計に集中する研究ニーズに専念するためにテストを行うことができます）;
B、中期：月曜日三〇から五毎朝のミーティング一度、目的は、プロジェクトの進捗を促進するための圧力を作成することで、問題は、多くのチームに最も傾向がある時間を感じ、デザインは、ゆっくりと中期的に需要を挽くことがあります。実装プロセスは、製品の参加の詳細を強化します。何度も、開発者が一部で立ち往生、問題を抱えているが、助けを求める方法を知らない、この時点では、製品を促進する必要があります。
C、後半：朝アップデートの進行状況は毎日、共通テストクイックフィックスの問題や完成品の品質を向上させます。品質は、実際には非常に問題である制御するための人員をテストし、単に開発に頼るのほとんどの開発者、テスター、「テスト」ユーザーの視点なしにただ機能テスト、（彼らは、ユーザーエクスペリエンスチームを心配している場合、それは十分に把握され、）行かせてはいけません。
3、需要が会議やレビューになります
、我々は会議を議論する必要があります。この会議は、一度実際には開いていない、十分な、基本的な最初だけ自分のクールな製品をはぎ取るために世界を強制的に、開かれています。I最初の総会の需要、需要が深い詳細に言うが、しませんが、ただ、私たちはこの事、おそらく目的をしなければならないことを通知します。その後一週間、現在の需要の意志を行う準備ができ、徹底的な議論について。日々の開発を奨励し、テストは、資料の更新を維持する必要性を、需要の詳細を調整し、需要をおしゃべり。
このような行為は、需要の恩恵を植え付けるために、内部の要件を設計するために一緒にチーム全体の参加を促進するために続けています。私は非常に簡単だたびに、私のデザインがゴミである、あなたが注意を払うために時間を行う、私のピットことはありません、私は設計上の問題は、完全に完全な通知を変更するには、一緒に話をする私に来てください感じています。このような開発は、テストは、ビジネスの設計が合理的である分析する比較的より喜んなり、チームが参加の強い感覚になります。
Bは、検討します：毎週の検討会を、私は最初の要件について疑問を持っている人称賛でしょう、私たちはより良い設計しましょう。誰が品質、良いNiubi、機能を終えました。これは通常、製品やプロジェクトのために彼らの能力をフルに貢献し、チームにあなたを聞かせて、チームメンバーの作業に注意を払う賞賛の下で貴重なをピックアップし、観察されます。
最初の反復を行った後、私たちは何が行われたかの下で言ってまず、小さな回顧展を開催します、その結果は、プロセス内のいくつかの良い練習を賞賛する方法です。その後、誰もが、良い良いんです、自分のを書き、あなたが改善することができます。最後に、一緒に話しています。しかし、我々は時間のスタッフの高いレベルは単なる形式だった、あなたはいつものようにリラックスした態度をかもしれない見つけました。
4、看板上の対象ユーザ肖像
このプロジェクトは、看板にそうも対象とチャットを持っている可能性が高い時間の要件に話し、そして、カードを要求するだけでなく、看板の肖像画、フローチャート、いくつかのユーザーをターゲットします。私たちは、このプロセスに問題がある、これらのユーザーのためのサービスを提供する必要があり、その後、物事が判明する方法を見て、そうではありませんか？
私の経験のいくつか：
1は、満たさなければならないというすべての追求よりも、期間のコア・ポイントに注意を払います
コアストリームの滝の使用が、事前の需要があり、プロジェクトのドキュメントがあるので、ファンクションポイントの束を行うが、実装プロセスでは、私は、コアファンクションポイントの完了にもっと注意を払うプロジェクト全体の期間を疑問視し、詳細があり関連した需要、または優先度の低いものは、コアプロセスとは独立して、ポイントを求め、私は直接のを放棄する必要がある場合があります
各バージョンには、目的を持っているコアのニーズの周りの目的といくつかの非中核要件、コア要件の唯一の品質があるだろう、程度が完了することができ、その後、このバージョンでは、プロジェクトがすべて書かれた、すべての詳細の追求があるのではなく、完全です完璧なものにします。そのため、高コストの価格を支払うために、この百パーセント完璧な必要性の、簡単にリソースを浪費することはできません。
2、アジャイル開発は、朝の会議は、かんばんこれらのものではありません
これは、/プロセスのニーズを議論するために、優れたチームは、私たちのアジャイル開発、組織のニーズアセスメント会、整理ワークロードの評価（カードサイズは、評価を必要とする）、プロジェクトの看板（付箋、需要の流れ）、朝/週の検討会を開始しましたこれらの事はように変更と。最初に接触したとき、私は非常に奇妙な感じはなく、心の初日に接触して疑問があり、これらはMinjieのMoですか？アジャイル開発の中核と記事を参照することと同じではありません。
完全な開発の後、より多くのものを見つけるために、そして一つの結論に反映さ：朝のミーティング、看板は、アジャイル開発の中核ではないのコミュニケーションを促進することを目的唯一の手段、方法、ツール、です！ユーザーからの議論は、最終的な出力は依然として大きな出力バージョンであり、ソフトウェアプロセスが使用できなくなっています。
図3は、チームが関与していない、等しくない敏捷性を行います
彼はその時に共通のシーンを言った：誰もが昨日行われたかについてお話します朝、今日の計画は、ご質問/ヘルプがあり、その後、ほとんどの人は何の問題も言いません！このシナリオでは、午前中に非常に一般的ではありません同日に終了した場合、一般的に問題のあるホストを持っていない、内部の毎週の会議やになります。しかしターン、最初に口の開発と言った：「吸盤、時間の無駄」
アジャイルモデリングは、チーム全体と一緒に製品がユーザーの要求や可能性などの機能を満たすように、このタスクを達成するために一緒にそれぞれの分野を再生する能力が必要とされます。通常の状況下では、需要が乾燥するために聞いた後、待機するようにオーバーテストし、その後、開発良いです。しかし、通常の状況下では、実装チームは全く問題ではないではありませんが、問題は技術的な問題があり、それは話をするまで来ませんでした。最後に、朝は単なる形式になり、チームの誰もが本当に内部の製品の設計に参加しなかった、トップシーンに進化します。
チームを導くためにどのように通信し、内部のチームに統合、これはアジャイル開発の中核ポイントの一つです。アジャイル開発は、私の意見では、ユーザーのニーズを満たすために、高品質のサービスを生産、短時間でチームのより多くの強度を使用することです。
4、イライラ「肌」を停止するには、「変化を受け入れる」を使用しないでください
非常に一般的なシナリオのほかに：製品はインタラクションデザイナーと話をした後、プランAを議論するために取得する必要があり、私Pidianpidianは（私が肉に戻って~~小さなを果たした当時）のプロトタイプ書かれた需要を描い書きました。インタラクションデザイナーが製品を見つけ、次の日、よく感じていない、そのデザインの話は、その後、連絡後、プランBに、よく、私はその後、文書を変更しました。そして、三日目に状況を満たすように設計されているようだ製品対話するデザイナーと話を探している計画に戻って通信した後、まだ非常に、非常に良いではありません！！！この時、私の心1万泥の馬で、私は最初の二つのプログラムは基本的に、違いはありません、実際には、ユーザーからのフィードバックを見てください、私は尋ね、議論に介入し始めました。
なぜ私は、私が見つけたので、これを言う「肌」の相互作用の問題のいくつかであるか、2つのオプションは、基本的にユーザーのニーズの彼らの議論に影響を与えない、そしてこの要求は最初からこのコアデマンド機能の点ではありませんが、それは仲間を必要とします。そして、もっと重要なのは、そのうちの2つだけは、そのユーザーを想像しますが、私は2つのインタラクションデザインのレベルを発見したという点で、常に投げるので、強力ではありません。
なぜコアが「肌」の上の点をトスする必要があり、米国はまた、アジャイル開発と呼ばれる変更されませんでしたが、常にこのに関与し、何度も製品自体や人格の問題のレベルは躊躇設計につながるため、この上記のシナリオは、非常に一般的です変化を受け入れるために、アジャイル開発が凍結された需要ではありません。
これは、需要が変更することはできませんが、分析したい、ユーザーのコアビジネスへの変更かどうか、全体の機能のコア上かどうか、正または負の影響と言うことではないでしょうか？これは、実際の基準の変更です。
最後に、プロジェクト管理のほぼすべての内容が、しかしプロダクトマネージャーとして、まだリソースの展開に応じて、チームの能力をプレイできるようにする必要があります。それの唯一の「技術」方法は、コアは、コアのプロダクトマネージャである、作業を改善し、効率を改善し、問題を解決することを目的とする「道路」。モードが良いか悪いかではなく、実際には、絶えず改善し、常にアップグレードし、誰もがこの事を改善する方法を考えるために行くことができますか？私はすぐに、あなたがあなた自身の「スキル」と見つけると確信してい「道を。」
私の他の記事を表示し続けることができます興味があるのは：