Кто нибудь понимает нафиг это надо и реально использует?

А тебе в SCRUM book не объяснили чтоле?

Давай разъясню на примере:

Начнем с «основных идей»:

У нас нет знаний и опыта управления проектами по нормальным стандартам, поэтому

люди и взаимодействие важнее процессов и инструментов

работающий продукт важнее исчерпывающей документации;

Но, поскольку никто не заморачивался с управлением требованиями, то рабочим считается все, что смогло запуститься на железе разработчика…

сотрудничество с заказчиком важнее согласования условий контракта;

В данном случае под «сотрудничеством» понимается подмена нормального управления рисками, требованиями и изменениями манипуляциями в переговорах с лохом заказчиком.

готовность к изменениям важнее следования первоначальному плану.

особенно, когда основным источником рисков является PO/PM…

Теперь «Принципы»:

удовлетворение клиента за счёт ранней и бесперебойной поставки ценного программного обеспечения;

Мы забили на управление требованиями, к тому же лох заказчик сам не знает, чего хочет, будем угадывать…

приветствие изменений требований даже в конце разработки (это может повысить конкурентоспособность полученного продукта);

Поскольку мы набрали разработчиков и PM по объявлениям, - основным источником рисков является сама команда, приходится как-то выкручиваться…

частая поставка рабочего программного обеспечения (каждый месяц или неделю или ещё чаще);

работающее программное обеспечение — лучший измеритель прогресса;

лучшие технические требования, дизайн и архитектура получаются у самоорганизованной команды;

тесное, ежедневное общение заказчика с разработчиками на протяжении всего проекта;

Лох заказчик должен «видеть прогресс», кроме того, за счет быстрой обратной связи мы хотим быстрее реагировать на внутренние и внешние риски, на которые мы изначально забили.

И да, поскольку у нас нет управления требованиями, мы, как «эффективные менеджеры» просто свяжем лоха заказчика с разработчиками, пусть сам им объясняет свои требования, мы все равно в этом ни хера не шарим.

спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп на неопределённый срок;

Управление расписанием и содержанием, нафиг-нафиг мы же аджайл!

А про то, что время - единственный невозобновимый ресурс - не, не слышали…

проектом занимаются мотивированные личности, которые обеспечены нужными условиями работы, поддержкой и доверием;

Не обращайте внимание, просто булщит для привлечения неофитов.

рекомендуемый метод передачи информации — личный разговор (лицом к лицу);

Чтобы потом можно было оперативно съехать с темы, типа «я не помню такого разговора с тобой».

А вообще, у нормальных руководителей личный разговор, - это самый дорогой канал коммуникаций, который применяют либо, когда есть время, либо в случае крайней необходимости.

постоянная адаптация к изменяющимся обстоятельствам. Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.

Опять реагирование на внутренние и внешние риски, которые сами же и создали…

Кто нибудь понимает нафиг это надо и реально использует?

А тебе в SCRUM book не объяснили чтоле?

Давай разъясню на примере:

Начнем с «основных идей»:

У нас нет знаний и опыта управления проектами по нормальным стандартам, поэтому

люди и взаимодействие важнее процессов и инструментов

работающий продукт важнее исчерпывающей документации;

Но, поскольку никто не заморачивался с управлением требованиями, то рабочим считается все, что смогло запуститься на железе разработчика…

сотрудничество с заказчиком важнее согласования условий контракта;

В данном случае под «сотрудничеством» понимается подмена нормального управления рисками, требованиями и изменениями манипуляциями в переговорах с лохом заказчиком.

готовность к изменениям важнее следования первоначальному плану.

особенно, когда основным источником рисков является PO/PM…

Теперь «Принципы»:

удовлетворение клиента за счёт ранней и бесперебойной поставки ценного программного обеспечения;

Мы забили на управление требованиями, к тому же лох заказчик сам не знает, чего хочет, будем угадывать…

приветствие изменений требований даже в конце разработки (это может повысить конкурентоспособность полученного продукта);

Поскольку мы набрали разработчиков и PM по объявлениям, - основным источником рисков является сама команда, приходится как-то выкручиваться…

частая поставка рабочего программного обеспечения (каждый месяц или неделю или ещё чаще);

работающее программное обеспечение — лучший измеритель прогресса;

лучшие технические требования, дизайн и архитектура получаются у самоорганизованной команды;

тесное, ежедневное общение заказчика с разработчиками на протяжении всего проекта;

Лох заказчик должен «видеть прогресс», кроме того, за счет быстрой обратной связи мы хотим быстрее реагировать на внутренние и внешние риски, на которые мы изначально забили.

И да, поскольку у нас нет управления требованиями, мы, как «эффективные менеджеры» просто свяжем лоха заказчика с разработчиками, пусть сам им объясняет свои требования, мы все равно в этом ни хера не шарим.

спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп на неопределённый срок;

Управление расписанием и содержанием, нафиг-нафиг мы же аджайл!

А про то, что время - единственный невозобновимый ресурс - не, не слышали…

проектом занимаются мотивированные личности, которые обеспечены нужными условиями работы, поддержкой и доверием;

Не обращайте внимание, просто булщит для привлечения неофитов.

рекомендуемый метод передачи информации — личный разговор (лицом к лицу);

Чтобы потом можно было оперативно съехать с темы, типа «я не помню такого разговора с тобой».

А вообще, у нормальных руководителей личный разговор, - это самый дорогой канал коммуникаций, который применяют либо, когда есть время, либо в случае крайней необходимости.

постоянная адаптация к изменяющимся обстоятельствам. Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.

Опять реагирование на внутренние и внешние риски, который сами же и создали…

Кто нибудь понимает нафиг это надо и реально использует?

А тебе в SCRUM book не объяснили чтоле?

Давай разъясню на примере:

Начнем с «основных идей»:

У нас нет знаний и опыта управления проектами по нормальным стандартам, поэтому

люди и взаимодействие важнее процессов и инструментов

работающий продукт важнее исчерпывающей документации;

Но, поскольку никто не заморачивался с управлением требованиями, то рабочим считается все, что смогло запуститься на железе разработчика…

сотрудничество с заказчиком важнее согласования условий контракта;

В данном случае под «сотрудничеством» понимается подмена нормального управления рисками, требованиями и изменениями манипуляциями в переговорах с лохом заказчиком.

готовность к изменениям важнее следования первоначальному плану.

особенно, когда основным источником рисков является PO/PM…

Теперь «Принципы»:

удовлетворение клиента за счёт ранней и бесперебойной поставки ценного программного обеспечения;

Мы забили на управление требованиями, к тому же лох заказчик сам не знает, чего хочет, будем угадывать…

приветствие изменений требований даже в конце разработки (это может повысить конкурентоспособность полученного продукта);

Поскольку мы набрали разработчиков и PM по объявлениям, - основным источником рисков является сама команда, приходится как-то выкручиваться…

частая поставка рабочего программного обеспечения (каждый месяц или неделю или ещё чаще);

работающее программное обеспечение — лучший измеритель прогресса;

лучшие технические требования, дизайн и архитектура получаются у самоорганизованной команды;

тесное, ежедневное общение заказчика с разработчиками на протяжении всего проекта;

Лох заказчик должен «видеть прогресс», кроме того, за счет быстрой обратной связи мы хотим быстрее реагировать на внутренние и внешние риски, на которые мы изначально забили.

И да, поскольку у нас нет управления требованиями, мы, как «эффективные менеджеры» просто свяжем лоха заказчика с разработчиками, пусть сам им объясняет свои требования, мы все равно в этом ни хера не шарим.

спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп на неопределённый срок;

Управление расписанием и содержанием, нафиг-нафиг мы же аджайл!

А про то, что время - единственный невозобновимый ресурс - не, не слышали…

проектом занимаются мотивированные личности, которые обеспечены нужными условиями работы, поддержкой и доверием;

Не обращайте внимание, просто булщит для привлечения неофитов.

рекомендуемый метод передачи информации — личный разговор (лицом к лицу);

Чтобы потом можно было оперативно съехать с темы, типа «я не помню такого разговора с тобой».

А вообще, у нормальных руководителей личный разговор, - это самый дорогой канал коммуникаций, который применяют либо, когда есть время, либо в случае крайней необходимости.

постоянная адаптация к изменяющимся обстоятельствам. Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.

Опять управление реагирование на внутренние и внешние риски, который сами же и создали…

Кто нибудь понимает нафиг это надо и реально использует?

А тебе в SCRUM book не объяснили чтоле?

Давай разъясню на примере:

Начнем с «основных идей»:

У нас нет знаний и опыта управления проектами по нормальным стандартам, поэтому

люди и взаимодействие важнее процессов и инструментов

работающий продукт важнее исчерпывающей документации;

Но, поскольку никто не заморачивался с управлением требованиями, то рабочим считается все, что смогло запуститься на железе разработчика…

сотрудничество с заказчиком важнее согласования условий контракта;

В данном случае под «сотрудничеством» понимается подмена нормального управления рисками, требованиями и изменениями манипуляциями в переговорах с лохом заказчиком.

готовность к изменениям важнее следования первоначальному плану.

особенно, когда основным источником рисков является PO/PM…

Теперь «Принципы»:

удовлетворение клиента за счёт ранней и бесперебойной поставки ценного программного обеспечения;

Мы забили на управление требованиями, к тому же лох заказчик сам не знает, чего хочет, будем угадывать…

приветствие изменений требований даже в конце разработки (это может повысить конкурентоспособность полученного продукта);

Поскольку мы набрали разработчиков и PM по объявлениям, - основным источником рисков является сама команда, приходится как-то выкручиваться…

частая поставка рабочего программного обеспечения (каждый месяц или неделю или ещё чаще);

работающее программное обеспечение — лучший измеритель прогресса;

лучшие технические требования, дизайн и архитектура получаются у самоорганизованной команды;

тесное, ежедневное общение заказчика с разработчиками на протяжении всего проекта;

Лох заказчик должен «видеть прогресс», кроме того, за счет быстрой обратной связи мы хотим быстрее реагировать на внутренние и внешние риски, на которые мы изначально забили.

И да, поскольку у нас нет управления требованиями, мы, как «эффективные менеджеры» просто свяжем лоха заказчика с разработчиками, пусть сам им объясняет свои требования, мы все равно в этом ни хера не шарим.

спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп на неопределённый срок;

Управление расписанием и содержанием, нафиг-нафиг мы же аджайл!

А про то, что время - единственный невозобновимый ресурс - не, не слышали…

проектом занимаются мотивированные личности, которые обеспечены нужными условиями работы, поддержкой и доверием;

Не обращайте внимание, просто булщит для привлечения неофитов.

рекомендуемый метод передачи информации — личный разговор (лицом к лицу);

Чтобы потом можно было оперативно съехать с темы, типа «я не помню такого разговора с тобой».

А вообще, у нормальных руководителей личный разговор, - это самый дорогой канал коммуникаций, который применяют либо, когда есть время, либо в случае крайней необходимости.

постоянная адаптация к изменяющимся обстоятельствам. Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.

Кто нибудь понимает нафиг это надо и реально использует?

А тебе в SCRUM book не объяснили чтоле?

Давай разъясню на примере:

Начнем с «основных идей»:

У нас нет знаний и опыта управления проектами по нормальным стандартам, поэтому

люди и взаимодействие важнее процессов и инструментов

работающий продукт важнее исчерпывающей документации;

Но, поскольку никто не заморачивался с управлением требованиями, то рабочим считается все, что смогло запуститься на железе разработчика…

сотрудничество с заказчиком важнее согласования условий контракта;

В данном случае под «сотрудничеством» понимается подмена нормального управления рисками, требованиями и изменениями манипуляциями в переговорах с лохом заказчиком.

готовность к изменениям важнее следования первоначальному плану.

особенно, когда основным источником риска является PO/PM…

Теперь «Принципы»:

удовлетворение клиента за счёт ранней и бесперебойной поставки ценного программного обеспечения;

Мы забили на управление требованиями, к тому же лох заказчик сам не знает, чего хочет, будем угадывать…

приветствие изменений требований даже в конце разработки (это может повысить конкурентоспособность полученного продукта);

Поскольку мы набрали разработчиков и PM по объявлениям, - основным источником рисков является сама команда, приходится как-то выкручиваться…

частая поставка рабочего программного обеспечения (каждый месяц или неделю или ещё чаще);

работающее программное обеспечение — лучший измеритель прогресса;

лучшие технические требования, дизайн и архитектура получаются у самоорганизованной команды;

тесное, ежедневное общение заказчика с разработчиками на протяжении всего проекта;

Лох заказчик должен «видеть прогресс», кроме того, за счет быстрой обратной связи мы хотим быстрее реагировать на внутренние и внешние риски, на которые мы изначально забили.

И да, поскольку у нас нет управления требованиями, мы, как «эффективные менеджеры» просто свяжем лоха заказчика с разработчиками, пусть сам им объясняет свои требования, мы все равно в этом ни хера не шарим.

спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп на неопределённый срок;

Управление расписанием и содержанием, нафиг-нафиг мы же аджайл!

А про то, что время - единственный невозобновимый ресурс - не, не слышали…

проектом занимаются мотивированные личности, которые обеспечены нужными условиями работы, поддержкой и доверием;

Не обращайте внимание, просто булщит для привлечения неофитов.

рекомендуемый метод передачи информации — личный разговор (лицом к лицу);

Чтобы потом можно было оперативно съехать с темы, типа «я не помню такого разговора с тобой».

А вообще, у нормальных руководителей личный разговор, - это самый дорогой канал коммуникаций, который применяют либо, когда есть время, либо в случае крайней необходимости.

постоянная адаптация к изменяющимся обстоятельствам. Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.