Какую проблему вы пытаетесь решить в контексте методологий? Каждая из них старается максимально сократить объем информации, доносимый до остальных в срезе Guide / Manifest. И подчеркивают это «lightweight framework» как бы намекая, что все остальное в других местах? В скраме про Risk Management тоже мало сказано, но его никто не отменял.
Конечно есть. Разница лишь в том, что в PM на бенче сидят люди, а в AM — проекты. Действуют все те же инструменты, что и в проектном управлении, но с некоторыми метаморфозами (см. Management 3.0). Тот же «scutter plot» c «Monte Carlo» позволяют стоить планы на основе статистики команд, т.е. для сработанной команды можно довольно точно предсказывать вхождение в треугольник: время, цена, объем задач. У Agile команд очень даже заданы временные рамки каденцией итераций, и определен бюджет — команда не меняется. Вопрос лишь в том, насколько менеджер вместе с командой и заказчиком смогут договориться об объеме и степени детализации приемки проекта.
В случае, если у компании свой продукт, то проектами могут выступать эпики или проектные инициативы (стримы).
Если собрать людей в кучу и назвать их Agile командой, ничего не изменится. Если игнорировать практики, толку будет ровно в том контексте, что описали. Agile Management отличается от Project Management лишь фокусом на людей вместо проектов. И когда этой трансформации не происходит, ни одна из церемоний не спасет; shu-ha-ri никто не отменял.
И да, Agile/Scrum требует, чтобы по завершению каждого спринта изменения уходили в LIVE.
И пока мне не представят «сравнительную табличку»
«value и их cost & profit» в силу вполне явных причин указывать не в праве, но переход с Watefall на Agile/Scrum c 3 недельным циклом дал ускорение разработке на ~30% и снизил рейт оплат на ~60%. Сам проект стабилен уже больше двух лет после миграции. Code Coverage по критическим модулям не ниже 95%, покрытие увеличивается каждый спринт и является обязательной частью разработки (Team City, Test Rail, Robot Framework, PHPUnit, JUnit, Jasmine). Документация через JIRA/Confluence обновляется через User Story и от изменений в коде, каждый push происходит через линковку с JIRA тикетом, что отражается в логах; ну и Api Gen никто не отменял.
Дело всегда в отсутствии должных знаний:
«Огромное число людей, помноженное на низкую квалификацию и чудовищный спрос, рождает высокую необъективную самооценку, невежество, илитизм» Perl Power
«Низкая квалификация ведет к незнанию стандартов, а высокая самооценка ведет к их игнорированию» Perl Power
Хватит скатываться во флейм с элементами нарциссизма. Вы понятия не имеете, с кем общаетесь (собственно, как и я)… поэтому любой переход на личности с голословными обвинениями не более чем элементы черной риторики для смещения фокуса с непосредственной темы.
Никакая религия не запрещает сделать дополнение к контракту, согласно вновь открытых обстоятельств, и юридически корректно провести. Этим ПМ занимается
В рамках Watefall, когда каждую из итераций представляет отдельно взятая фирма (или несколько фирм), ни о каких дополнениях к соглашению речи не идет. Препирательства по архитектуре решения приводят к замене человека / команды / фирмы на более сговорчивых согласно представленному ТЗ.
Банальное: 15..20 спринтов пилили платежку «с преферансом и стразиками». Потом вспомнили, что PCI DSS сертификация нужна
Если после 20 релизов заказчику (и пользователям) не понадобилась PCI DSS, так может она и не нужна была? За год то можно было выявить отсутствие краеугольных камней. А если не было вывода кода на реальные сервера, то при чем здесь Scrum? Аккредитованный Scrum Master с уровнем Solution/Sofrware Architect? Сертифицированные разработчики в команде с уровнем Senior? Scrum Master не следил за целостностью проекта? Документация не велась вообще? А тесты?
Если согнать студентов и назвать Scrum Team,… да еще и оставить их наедине с задачей на год или два, то эффекта в лучшем случае не будет. Отсутствие должной компетенции всегда продуцирует проблемы. Да и нет волшебной методологии, гарантирующей 100% успех… к слову:
Scrum предполагает высокую степень самоорганизации, соответствующей квалификации и мотивации всех членов команды. И если считать своё мнение превыше метров IT; а фамилии Фаулер, Бек и Дейв — воспринимать как пустой звук; то дискуссия в принципе завершена.
Waterfall или существует другое представление данной методологии? Не раз возникали ситуации, когда не согласен со спецификацией, «спущенной сверху»… но договор подписан и суммы озвучены. В случае с Continues Integration, Agile/Scrum выглядит куда привлекательней лично для меня, Product Owner на каждом StandUp, можно высказаться и скорректировать развитие продукта.
Scrum — лишь один из множества в семействе Agile, но даже при нем
без соблюдения методологии и «Scrum board» просто… не выполнит своего предназначения
вряд ли может хоть как-то противоречить тому, что люди должны договариваться. Ни одна методология не заработает должным образом при нарушенной коммуникации.
Если коснемся вопросов «передачи знаний» при найме нового человека или «умер» участник команды
Проще не брать нового человека, скорость разработки всегда существенно проседает. Перенабор команды происходит после потери более 3 разработчиков, minimal points rate при этом обнуляется и начинаются экспериментальные спринты для установки новой медианы.
что делать если возник конфликт хотелок 5, 8 и 16 спринтами — без вменяемой документации фиг разобраться.
Абсолютно не понял, как может возникнуть конфликт, если каждый спринт заканчивается релизом в production. 5 фича противоречит 8му спринту? не вопрос, обсудим на Refinement Session, выкосим функционал или перенастроим под 8ку. В 16м захотелось перебить функционал. Да не вопрос… В этом и есть весь смысл, в отсутствии противоречий в требованиях, даже если они противоречат себе из спринта в спринт. Заказчик значит захотел поэкспериментировать, имеет право.
Этим кто-то будет себя успокаивать, когда будет продавать квартиру или почку что бы покрыть убытки клиента согласно условиям контрата :)) Банку будет пофиг, когда потребует возврат кредита с процентами
Какой-то уж больно жирный троллинг… Обычное долгосрочное делегирование разработчиков напрямую заказчику. Клиент сам покрывает свои убытки, если таковые случаются; а бездарное составление контрактов никакого отношения к вопросу методологий не имеет.
Каждая модель имеет право на жизнь пока имеет своих адептов. Поэтому, даже если что-то не вклинивается в парадигму, непринятие лучше провокационного словоблудия.
Здесь разногласий нет совершенно. И дело вовсе не в том, что «многабукфф»… а том, как подходит руководство к процессу интеграции тех или иных подходов. В контексте Agile и PMBOK сравнивать вообще нельзя. «Манифест методологии не товарищ». Аля проповедование Agile направлено лишь на один единственный пункт из PMBOK — «Руководство проектом»
… это функция надзора, соответствующая модели организационного руководства и охватывающая жизненный цикл проекта. Система руководства проектом предоставляет руководителю проекта и команде проекта структуру, процессы, модели принятия решений и инструменты для управления проектом, одновременно поддерживая и контролируя проект с целью достижения успеха.
Waterfall был взят лишь в качестве примера, для отражения «Подготовительной и заключительной фаз»
Руководство PMBOK® состоит из ~600 страниц, у Agile всего одна: http://agilemanifesto.org Люди и взаимодействие важнее процессов и инструментов Работающий продукт важнее исчерпывающей документации Сотрудничество с заказчиком важнее согласования условий контракта Готовность к изменениям важнее следования первоначальному плану
Waterfall, в большинстве случаев, и отличается тем, что согласование плана важнее всего процесса, а разработчики «общаются» с заказчиком через менеджеров.
В рамках Agile/(Scrum/Kanban|XP|...) первоначальные условия могут измениться на диаметрально противоположные. Здесь вообще отсутствует что-либо, где можно было бы зацепиться за отсутствие гибкости у Agile или неприемлемость Waterfall.
Комьюнити сталеет, набирается критическая масса опытных специалистов для качественных переходов. JS был разработан за 10 дней, у первой версии PHP так же был малый цикл. Это не Haskell с его академическими выкладками, или Erlang под долгой вычисткой. Поэтому ожидать отсутствия ошибок в ядре не приходится… но срабатывает принцип «количество в качество». Чем обширнее компьюнити, тем вероятнее появление качественных архитектурных решений.
Переносить сразу весь проект — гиблое дело, и статья скорее об этом (ровно как и «выбросить старый код и написать все на X»). Но если писать новые модули только на языке X, постепенно рефакторить и адаптировать старый код под безболезненную миграцию… вполне даже реально.
Что-то я был «слегка» невнимателен (собственные надстройки порой сбивают)… но помимо указанных двух есть еще iconv_* (которые используются наряду с mb_*). Вызов третьей функции можно сделать единожды на проект для упрощения (как правило, setlocale, mb_internal_encoding, bind_textdomain_codeset,… выставляются в utf8), или вовсе не использовать, оперируя вторым параметров функции для задания кодировки.
В качестве альтернативы:
$length = preg_match_all('(.)su', $text);
> Actionable Agile Metrics, 2015 — Daniel S. Vacanti
В случае, если у компании свой продукт, то проектами могут выступать эпики или проектные инициативы (стримы).
И да, Agile/Scrum требует, чтобы по завершению каждого спринта изменения уходили в LIVE.
«value и их cost & profit» в силу вполне явных причин указывать не в праве, но переход с Watefall на Agile/Scrum c 3 недельным циклом дал ускорение разработке на ~30% и снизил рейт оплат на ~60%. Сам проект стабилен уже больше двух лет после миграции. Code Coverage по критическим модулям не ниже 95%, покрытие увеличивается каждый спринт и является обязательной частью разработки (Team City, Test Rail, Robot Framework, PHPUnit, JUnit, Jasmine). Документация через JIRA/Confluence обновляется через User Story и от изменений в коде, каждый push происходит через линковку с JIRA тикетом, что отражается в логах; ну и Api Gen никто не отменял.
Дело всегда в отсутствии должных знаний:
«Огромное число людей, помноженное на низкую квалификацию и чудовищный спрос, рождает высокую необъективную самооценку, невежество, илитизм» Perl Power
«Низкая квалификация ведет к незнанию стандартов, а высокая самооценка ведет к их игнорированию» Perl Power
В рамках Watefall, когда каждую из итераций представляет отдельно взятая фирма (или несколько фирм), ни о каких дополнениях к соглашению речи не идет. Препирательства по архитектуре решения приводят к замене человека / команды / фирмы на более сговорчивых согласно представленному ТЗ.
Если после 20 релизов заказчику (и пользователям) не понадобилась PCI DSS, так может она и не нужна была? За год то можно было выявить отсутствие краеугольных камней. А если не было вывода кода на реальные сервера, то при чем здесь Scrum? Аккредитованный Scrum Master с уровнем Solution/Sofrware Architect? Сертифицированные разработчики в команде с уровнем Senior? Scrum Master не следил за целостностью проекта? Документация не велась вообще? А тесты?
Если согнать студентов и назвать Scrum Team,… да еще и оставить их наедине с задачей на год или два, то эффекта в лучшем случае не будет. Отсутствие должной компетенции всегда продуцирует проблемы. Да и нет волшебной методологии, гарантирующей 100% успех… к слову:
Scrum предполагает высокую степень самоорганизации, соответствующей квалификации и мотивации всех членов команды. И если считать своё мнение превыше метров IT; а фамилии Фаулер, Бек и Дейв — воспринимать как пустой звук; то дискуссия в принципе завершена.
Waterfall или существует другое представление данной методологии? Не раз возникали ситуации, когда не согласен со спецификацией, «спущенной сверху»… но договор подписан и суммы озвучены. В случае с Continues Integration, Agile/Scrum выглядит куда привлекательней лично для меня, Product Owner на каждом StandUp, можно высказаться и скорректировать развитие продукта.
Scrum — лишь один из множества в семействе Agile, но даже при нем
вряд ли может хоть как-то противоречить тому, что люди должны договариваться. Ни одна методология не заработает должным образом при нарушенной коммуникации.
Проще не брать нового человека, скорость разработки всегда существенно проседает. Перенабор команды происходит после потери более 3 разработчиков, minimal points rate при этом обнуляется и начинаются экспериментальные спринты для установки новой медианы.
Абсолютно не понял, как может возникнуть конфликт, если каждый спринт заканчивается релизом в production. 5 фича противоречит 8му спринту? не вопрос, обсудим на Refinement Session, выкосим функционал или перенастроим под 8ку. В 16м захотелось перебить функционал. Да не вопрос… В этом и есть весь смысл, в отсутствии противоречий в требованиях, даже если они противоречат себе из спринта в спринт. Заказчик значит захотел поэкспериментировать, имеет право.
Какой-то уж больно жирный троллинг… Обычное долгосрочное делегирование разработчиков напрямую заказчику. Клиент сам покрывает свои убытки, если таковые случаются; а бездарное составление контрактов никакого отношения к вопросу методологий не имеет.
Каждая модель имеет право на жизнь пока имеет своих адептов. Поэтому, даже если что-то не вклинивается в парадигму, непринятие лучше провокационного словоблудия.
Waterfall был взят лишь в качестве примера, для отражения «Подготовительной и заключительной фаз»
http://agilemanifesto.org
Люди и взаимодействие важнее процессов и инструментов
Работающий продукт важнее исчерпывающей документации
Сотрудничество с заказчиком важнее согласования условий контракта
Готовность к изменениям важнее следования первоначальному плану
Waterfall, в большинстве случаев, и отличается тем, что согласование плана важнее всего процесса, а разработчики «общаются» с заказчиком через менеджеров.
В рамках Agile/(Scrum/Kanban|XP|...) первоначальные условия могут измениться на диаметрально противоположные. Здесь вообще отсутствует что-либо, где можно было бы зацепиться за отсутствие гибкости у Agile или неприемлемость Waterfall.
https://blog.codinghorror.com/the-ugly-american-programmer/
В качестве альтернативы:
$length = preg_match_all('(.)su', $text);