# Отримати в SCRUM

<datetime class="hidden">2004-07-04T00:00</datetime>

<!-- category -- mostlylucidcouk, Imported -->
Я зараз прокладаю собі шлях через книжку ."[Розвиток агресивного програмного забезпечення зі Scrum](http://www.amazon.co.uk/exec/obidos/ASIN/0130676349/mostlylucid-21)" від [Швабер і Бейдл.](http://www.amazon.co.uk/exec/obidos/ASIN/0130676349/mostlylucid-21) [[США](http://www.amazon.com/exec/obidos/ASIN/0130676349/mostlylucid-21)Я лише на півдорозі, але поки що це виглядає як єдиний процес розвитку, який насправді може спрацювати для компанії на кшталт [ту, на якій я зараз працюю.](http://www.stormid.com/)Проблема в тому, що ми схильні до швидкого проектування з дуже маленькими командами (здебільшого, з 1 розробником з випадковими інструкцією дизайну/ ділових аналітиків) і швидким "випромінювання" (тобто жахливе мутування) вимог - отже, [старий](http://www.ogc.gov.uk/prince/) [Моноліт](http://www.rational.com/products/rup/index.jsp) Розробка процесів не пасує до того, як ми працюємо. [СКРАМConstellation name (optional)](http://www.controlchaos.com/) є тим, для чого він створений [пасує до існуючих процесів розробки](http://www.controlchaos.com/xpScrum.htm) (Таких, як [Крайня програма](http://www.controlchaos.com/XPKane.htm)Це лише дає трохи більше контролю та видимості всьому процесу.
Дивно, що деякі з найкращих менеджерів, з якими я працював на [Попереднє](http://www.theregister.co.uk/content/7/20204.html)[компанії](http://www.vistiscotland.com/) використовував дуже схожі методи - хоча насправді вони не базуються на цьому конкретному процесі, тільки тому, що це здавалося правильним. [СКРАМConstellation name (optional)](http://www.amazon.co.uk/exec/obidos/ASIN/0130676349/mostlylucid-21) - ви можете бути дуже здивовані!