Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 9
Только, если отсутствует должное QA. Именно на этом сделан акцент. Суть вывода и рекомендации: Agile эффективно работает в связке с качественным производственным циклом, в котором используются все виды тестирования. Если не используется DevOps, нет автоматизированных тестов, то жди проблем в Agile.
тут скорее проблема DoD-а, чем жестче прописано, тем выше качество и на долгосрочной перспективе уменьшение t2m
Безусловно, но в Agile можно при этом уменьшить T2M. В умелых руках и при правильной организации любой подход будет работать хорошо. Я сделал некоторый обзор выступлений, Lessons Learned, а не сравнивал Agile и Waterfall. Последние годы трендом является уход от классики в Agile при отсутсвие готовности организации к смене подходов, что приводит к отрицательным результатам. А консалтерам только это и нужно: «впарить» и заработать. Коллеги делились сложностями, с которыми они столкнулись. Я считаю, что далеко не всегда нужно использовать Agile.
Качество снижается не столько из-за стремления уменьшить t2m, а сколько из-за изменения подхода к созданию продуктов. Выкатываем MVP, и смотрим на реакцию. Дальше допиливаем по мере понимания что допиливать.
Ну и консьюмеризация. Средний уровень ит-знаний у массовых аудиторий постепенно уменьшается, продукты следуя этому тренду становятся все более простыми (внешне). Вероятность что появится какая-то фича удобная ит-продвинутым пользователям, все время уменьшается.
Ну и консьюмеризация. Средний уровень ит-знаний у массовых аудиторий постепенно уменьшается, продукты следуя этому тренду становятся все более простыми (внешне). Вероятность что появится какая-то фича удобная ит-продвинутым пользователям, все время уменьшается.
TL;DR
Критикую Ваш пост, но стараюсь при этом не развести холивар!
Читая Ваш пост у меня сложилось впечатление, что Вы довольно далеки от темы и возможно интерпретировали материалы в ”своем” ключе (ну или выступления были не качественные).
Хочу сделать пару комментариев со своей стороны:
1) Вы несколько раз упоминаете Трайбы, которые являются аттрибутом Spotify Engineering Culture. В списке литературы у Вас упомянается только SAFe и кастомные внедрения (от Delloitte например). Всё это Scaled Agile Methodologies. Значит если я правильно понимаю тему — рекомендации по внедрению Scaled Agile Methodologies, а не Agile-тренды или Agile трансформации.
2) ”Методология Agile изначально разрабатывалась для гибкого управления небольшими продуктами с помощью команд 7-15 человек для эффективного использования имеющихся ресурсов."
а) «небольшими» — есть много примеров необычайно сложных (комплексных систем) сделаных по Agile методологиям — например интегрированная система данных FBI или любой сервис Google, Facebook etc.
б) «продуктами» — ключевое слово. Все современные Agile методологии по умолчанию оперируют в продуктовых средах разработки (Productized environment в терминах PMI). Поэтому конечно комично что PROJECT management institute проводит такой эвент).
с) «команд 7-15 человек» — хммм странное число, никогда такого не слышал. 5-9 в Scrum, до 8 команд по 8 человек в LeSS на 1 продукт и т.д.
д) «имеющихся ресурсов» — не знаю сколько еще ревизий PMBoK нужно PMI чтобы перестать называть людей ресурсами!
3) «Масштабирование подхода на большие организации требует изменения подходов корпоративного управления, стратегического планирования, бюджетирования и мышления сотрудников внутри организации.»
a) «Масштабирование подхода на большие организации» — всё таки мы говорим про Scaled Agile Methodologies, которые более высокая ступень Agile трансформации и для успеха требуют некоторого уровня зрелости с Team Level Agile, Agile in Business Processes, Agile HR и пр.
б) «требует изменения подходов корпоративного управления, стратегического планирования, бюджетирования и мышления сотрудников внутри организации.» — любая Scaled Agile методология это маленькая революция — изменение ролей и обязанностей, изменение процессов, изменение подходов к бизнессу и разработке. Так что в моем понимании внедрение Scaled Agile методологии = изменения подходов корпоративного управления, стратегического планирования, бюджетирования и мышления сотрудников внутри организации + еще куча всего прочего
4) «повышению эффективности, уменьшению показателей Time to Market (T2M) и к уменьшению затрат на изменения, а в отдельных, к негативным последствиям: ухудшению сроков реализации проектов, качества планирования и увеличению операционных затрат»
a) «к негативным последствиям» — согласно исследованиям HBR 2/3 всех Agile инициатив провальные (согласно моему опыту намного выше))
б) «повышению эффективности» — смотря что мерить и как вы определяете эффективность
с) «уменьшению показателей Time to Market (T2M)» — у Вас может быть супер эффективная разработка — быстро и качественно, но это не сделает Вашу компанию успешной. Доставляя быстро то что никому не нужно! Agile фокусируется на Value. T2M второстепенная метрика Вашего flow, которая обычно сама подтягивается при успешной адаптации Agile
д) «ухудшению сроков реализации проектов»
— в продуктовой разработке нет финального срока vs. классический Project Management
— Вы же знаете что в Project Constraints если Time фиксировано --> Scope flexible. Видимо проблема на Продуктовой стороне в этом случаею
5) «Эффективным способом при внедрении методологии Agile является совмещение классических подходов проектного управления с гибкими методиками» — это ну очень спорное утверждение. Я легко могу представить практики из Agile внедренные в классический Project Management (сам так делал), а вот наоборот?!? У Вас есть примеры в Вашем исследовании?
6) «Роль проектного офиса, программного и портфельного управления проектами при переходе на Agile обычно упраздняется в процессе трансформации, что является негативным фактором. В результате происходит потеря связи между стратегическим планированием, развитием организации и реальной деятельностью Agile команд» — тоже очень спорное утверждение.
— Старые роли упраздняются в силу их «несовместимости» с внедряемыми фреймворками, а их обязаности перераспределяются между новыми ролями. Часть ложится на команды, часть на продуктовиков, часть на leadership team (логично же — мы делаем революцию)
— «происходит потеря связи между стратегическим планированием, развитием организации и реальной деятельностью Agile команд» — каждая Scaled Agile методология предлагает решение этой проблемы (это посути и есть смысл их внедрения).
7) «Отсутствует явное бюджетирование новых инициатив, поскольку бюджет выделяется на цели и задачи трайба. Механизмы расширения и видоизменяя трайба не являются ключевыми в методологии. Это приводит к замедлению внедрения инноваций внутри организации» — простите, но это ересь!
— Когда Spotify выкатывали свою Engineering Culture они уже были Agile компанией (разработка по Scrum, Agile HR, Agile business processes etc.). Многие говорят про Spotify Model, считая её Scaled Agile Methodology — что в моем представлении не правильно. Spotify Engineering Culture предлагает в первую очередь новую модель Organizational Management --> которая формирует принципы постоянных инноваций и закладывает фундамент для Scaled Agile.
— Spotify Engineering Culture самая инновационно-ориентированная организационная структура из всех что я знаю — если это у кого-то не работает — не значит что это проблема модели — скорее проблема её понимания и внедрения (нельзя просто так взять и скопировать))
8) «Качество продуктов снижается из-за выделенном акценте на уменьшении T2M» — хочу обратить внимание на Agile Manifesto --> WORKING software is the primary measure of progress. В Agile качество это априори, а не переменная. На какой метрике делать акцент это индивидуальный выбор — но если разработчики софта доставляют не работающий софт — какой в них смысл (пусть даже и быстро)?
9) «Регуляторные требования могут реализовываться с использованием Agile принципов, но с особым акцентом на качество конечного результата» — я рад что это получилось у кого-то из презентующих. Я часто встречаю людей, которые уверяют меня что это не возможно. При этом большинство не знакомо с точной формулировкой регуляторных требований или же документов это предписывающих — мне так сказали! — говорят они.
10) «Уровень и качество коммуникаций между подразделениями при использовании Agile должны быть существенно увеличены. При недолжном уровне взаимодействия и взаимопонимания использования Agile только увеличит T2M и стоимость внедрения изменений» — а в не Agile не так? Отсутствие коммуникации и взаимодействия может привести к уменьшению T2M если мы можем доставить результат без вмешательства «тормозящих» подразделений — автономия, кросс-функциональность, самоорганизация — такое возможно по вашему?
11) «Использование специализированного программного обеспечения для единого управления задачами, проектами, портфелем и программой проектов, целевыми показателями эффективности организации, интеграция процессов изменения с ERP и CRM системами, существенно увеличивает эффективность применения Agile и взаимодействия команд» — в теории да, никогда такого не видел на практике. Централизация vs. децентрализация. Автономные команды, которые сами формируют процесс, позволяющий быль эффекивными или централизованые инструменты контроля выполнения — что больше вписывается в Agile Manifesto (Individuals and interactions over processes and tools). Не поймите меня неправильно, я не против программных инструментов как ERP и CRM, но я против полной стандартизации. Должна быть «золотая середины» в стандартизации, достигнутая обсуждением между командами, а не какого-либо центрального органа (PMO и пр.)
12) «Во всех Agile практиках особое внимание уделяется обратной связи, анализу спринтов внутри команд, но на уровне выше (продукты, программы, трайбы) эта связь теряется для рядовых членов команд» — опять же каждая Scaled Agile Methodology предлагает решение этой проблеме (потому что для решения этих проблем и были придуманы!). Я мог бы перечислить ряд методик из SAFe, LeSS, Spotify, SoS, SatS, Nexus — но вы можете их лучше меня нагуглить.
13) «Внедрение Agile в крупной организации это не вопрос одного месяца, полугода или года. Это системная стратегическая работа на несколько лет с кардинальным изменением всех процессов и принципов работы организации» — так то это навсегда. Не будет такого что однажды Вы проснетесь и скажете — мы теперь Agile компания можно больше ничего не делать! Так не получится). Вы всегда будете искать где и что улучшить, попробовать новые практики, обучить новых сотрудников и пр. Все течёт, все меняется.
Рекомендации:
1) «Высший менеджмент организации должен стать проводником, лидером Agile изменений. Необходимо ежемесячно на уровне каждого трайба выступать перед сотрудниками с обзором текущих целей, прогрессом их выполнения, анализом текущих уроков. Ежеквартально организовывать аналогичные meetup между лидерами трайбов с веб-трансляцией и открытым участием всех желающих сотрудников организации» — а вне Agile это не рекомендуется?
2) «Необходимо усилить роль и объем обучения Agile методикам» — можно бесконечно обучать — это не гарантирует успешного внедрения. А вот содействовать внедрению и паралельно обучать на практике — звучит как больше шансов на успех.
3) «Дополнительно необходимо проводить психологическое тестирование и выявлять сотрудников, которые не готовы к новым изменениям внутри компании» — таких людей легко выявить и без психологического тестирования. И Ваше предложение что с ними делать?
4) «Проектный офис должен выполнять координационную и коммуникативную роль (ежемесячные и ежеквартальные meetup), быть во главе стратегического планирования и обеспечивать мониторинг качества деятельности трайбов» — лично я не согласен (я думаю вы уже поняли мою позицию про централизацию)
— «быть во главе стратегического планирования» — а продукт менеджеры что будут делать?
— «обеспечивать мониторинг качества деятельности трайбов» — хммм что именно? Качество — а сами разработчики на что? Value — а продукт менеджеры на что? Ну я думаю вы поняли мою идею — PMO обязанности будут перераспределены на другие роли.
5) «Должен быть создан соответствующий on-line механизм внутри трайба и между трайбами с соотвествующими КПЭ у всех руководителей. » — круть! On-line, а не F2F и KPI на качество взаимодействия и коммуникаций между людьми (простите РЕСУРСАМИ по PMI). Ну а что? Мы же должны это контролировать! Не доверять же РЕСУРСАМ на самом деле. Шутки-шутками, но я только в 1 Agile трансформации видел такой KPI внедренным более-меннее успешно.
6) «должны быть объединены в единой оценке сотрудников всех уровней» — бам! Команда то, команда сё. Взаимодейстие, коммуникации — оцениваем каждого индивидуально! Agile HR на Вас нет! (https://www.agilehrmanifesto.org/)
7) «Используемые ИТ-решения для ведения бэклога, дашборды для Scrum, Kanban не должны ограничиваться только в их использовании для DevOps процессов и реализации спринтов, а являться информационной основой для выполнения пользовательских историй и проектов, портфелей и программ проектов, иметь связь с ERP системой, связь с КПЭ чаптеров, кластеров, трайбов и организации в целом» — ни одна из этих систем не позволит Вам контролировать действительно важные KPI. Только второстепенные, которые не отражают реальности.
Извините я под конец похоже устал и стал писать в более сжато-агрессивном формате. Это статья в очередной раз напомнила мне почему я больше не посещаю PMI эвенты.
Я восхищаюсь Вашим желанием распространять полученные знания.
Критикую Ваш пост, но стараюсь при этом не развести холивар!
Читая Ваш пост у меня сложилось впечатление, что Вы довольно далеки от темы и возможно интерпретировали материалы в ”своем” ключе (ну или выступления были не качественные).
Хочу сделать пару комментариев со своей стороны:
1) Вы несколько раз упоминаете Трайбы, которые являются аттрибутом Spotify Engineering Culture. В списке литературы у Вас упомянается только SAFe и кастомные внедрения (от Delloitte например). Всё это Scaled Agile Methodologies. Значит если я правильно понимаю тему — рекомендации по внедрению Scaled Agile Methodologies, а не Agile-тренды или Agile трансформации.
2) ”Методология Agile изначально разрабатывалась для гибкого управления небольшими продуктами с помощью команд 7-15 человек для эффективного использования имеющихся ресурсов."
а) «небольшими» — есть много примеров необычайно сложных (комплексных систем) сделаных по Agile методологиям — например интегрированная система данных FBI или любой сервис Google, Facebook etc.
б) «продуктами» — ключевое слово. Все современные Agile методологии по умолчанию оперируют в продуктовых средах разработки (Productized environment в терминах PMI). Поэтому конечно комично что PROJECT management institute проводит такой эвент).
с) «команд 7-15 человек» — хммм странное число, никогда такого не слышал. 5-9 в Scrum, до 8 команд по 8 человек в LeSS на 1 продукт и т.д.
д) «имеющихся ресурсов» — не знаю сколько еще ревизий PMBoK нужно PMI чтобы перестать называть людей ресурсами!
3) «Масштабирование подхода на большие организации требует изменения подходов корпоративного управления, стратегического планирования, бюджетирования и мышления сотрудников внутри организации.»
a) «Масштабирование подхода на большие организации» — всё таки мы говорим про Scaled Agile Methodologies, которые более высокая ступень Agile трансформации и для успеха требуют некоторого уровня зрелости с Team Level Agile, Agile in Business Processes, Agile HR и пр.
б) «требует изменения подходов корпоративного управления, стратегического планирования, бюджетирования и мышления сотрудников внутри организации.» — любая Scaled Agile методология это маленькая революция — изменение ролей и обязанностей, изменение процессов, изменение подходов к бизнессу и разработке. Так что в моем понимании внедрение Scaled Agile методологии = изменения подходов корпоративного управления, стратегического планирования, бюджетирования и мышления сотрудников внутри организации + еще куча всего прочего
4) «повышению эффективности, уменьшению показателей Time to Market (T2M) и к уменьшению затрат на изменения, а в отдельных, к негативным последствиям: ухудшению сроков реализации проектов, качества планирования и увеличению операционных затрат»
a) «к негативным последствиям» — согласно исследованиям HBR 2/3 всех Agile инициатив провальные (согласно моему опыту намного выше))
б) «повышению эффективности» — смотря что мерить и как вы определяете эффективность
с) «уменьшению показателей Time to Market (T2M)» — у Вас может быть супер эффективная разработка — быстро и качественно, но это не сделает Вашу компанию успешной. Доставляя быстро то что никому не нужно! Agile фокусируется на Value. T2M второстепенная метрика Вашего flow, которая обычно сама подтягивается при успешной адаптации Agile
д) «ухудшению сроков реализации проектов»
— в продуктовой разработке нет финального срока vs. классический Project Management
— Вы же знаете что в Project Constraints если Time фиксировано --> Scope flexible. Видимо проблема на Продуктовой стороне в этом случаею
5) «Эффективным способом при внедрении методологии Agile является совмещение классических подходов проектного управления с гибкими методиками» — это ну очень спорное утверждение. Я легко могу представить практики из Agile внедренные в классический Project Management (сам так делал), а вот наоборот?!? У Вас есть примеры в Вашем исследовании?
6) «Роль проектного офиса, программного и портфельного управления проектами при переходе на Agile обычно упраздняется в процессе трансформации, что является негативным фактором. В результате происходит потеря связи между стратегическим планированием, развитием организации и реальной деятельностью Agile команд» — тоже очень спорное утверждение.
— Старые роли упраздняются в силу их «несовместимости» с внедряемыми фреймворками, а их обязаности перераспределяются между новыми ролями. Часть ложится на команды, часть на продуктовиков, часть на leadership team (логично же — мы делаем революцию)
— «происходит потеря связи между стратегическим планированием, развитием организации и реальной деятельностью Agile команд» — каждая Scaled Agile методология предлагает решение этой проблемы (это посути и есть смысл их внедрения).
7) «Отсутствует явное бюджетирование новых инициатив, поскольку бюджет выделяется на цели и задачи трайба. Механизмы расширения и видоизменяя трайба не являются ключевыми в методологии. Это приводит к замедлению внедрения инноваций внутри организации» — простите, но это ересь!
— Когда Spotify выкатывали свою Engineering Culture они уже были Agile компанией (разработка по Scrum, Agile HR, Agile business processes etc.). Многие говорят про Spotify Model, считая её Scaled Agile Methodology — что в моем представлении не правильно. Spotify Engineering Culture предлагает в первую очередь новую модель Organizational Management --> которая формирует принципы постоянных инноваций и закладывает фундамент для Scaled Agile.
— Spotify Engineering Culture самая инновационно-ориентированная организационная структура из всех что я знаю — если это у кого-то не работает — не значит что это проблема модели — скорее проблема её понимания и внедрения (нельзя просто так взять и скопировать))
8) «Качество продуктов снижается из-за выделенном акценте на уменьшении T2M» — хочу обратить внимание на Agile Manifesto --> WORKING software is the primary measure of progress. В Agile качество это априори, а не переменная. На какой метрике делать акцент это индивидуальный выбор — но если разработчики софта доставляют не работающий софт — какой в них смысл (пусть даже и быстро)?
9) «Регуляторные требования могут реализовываться с использованием Agile принципов, но с особым акцентом на качество конечного результата» — я рад что это получилось у кого-то из презентующих. Я часто встречаю людей, которые уверяют меня что это не возможно. При этом большинство не знакомо с точной формулировкой регуляторных требований или же документов это предписывающих — мне так сказали! — говорят они.
10) «Уровень и качество коммуникаций между подразделениями при использовании Agile должны быть существенно увеличены. При недолжном уровне взаимодействия и взаимопонимания использования Agile только увеличит T2M и стоимость внедрения изменений» — а в не Agile не так? Отсутствие коммуникации и взаимодействия может привести к уменьшению T2M если мы можем доставить результат без вмешательства «тормозящих» подразделений — автономия, кросс-функциональность, самоорганизация — такое возможно по вашему?
11) «Использование специализированного программного обеспечения для единого управления задачами, проектами, портфелем и программой проектов, целевыми показателями эффективности организации, интеграция процессов изменения с ERP и CRM системами, существенно увеличивает эффективность применения Agile и взаимодействия команд» — в теории да, никогда такого не видел на практике. Централизация vs. децентрализация. Автономные команды, которые сами формируют процесс, позволяющий быль эффекивными или централизованые инструменты контроля выполнения — что больше вписывается в Agile Manifesto (Individuals and interactions over processes and tools). Не поймите меня неправильно, я не против программных инструментов как ERP и CRM, но я против полной стандартизации. Должна быть «золотая середины» в стандартизации, достигнутая обсуждением между командами, а не какого-либо центрального органа (PMO и пр.)
12) «Во всех Agile практиках особое внимание уделяется обратной связи, анализу спринтов внутри команд, но на уровне выше (продукты, программы, трайбы) эта связь теряется для рядовых членов команд» — опять же каждая Scaled Agile Methodology предлагает решение этой проблеме (потому что для решения этих проблем и были придуманы!). Я мог бы перечислить ряд методик из SAFe, LeSS, Spotify, SoS, SatS, Nexus — но вы можете их лучше меня нагуглить.
13) «Внедрение Agile в крупной организации это не вопрос одного месяца, полугода или года. Это системная стратегическая работа на несколько лет с кардинальным изменением всех процессов и принципов работы организации» — так то это навсегда. Не будет такого что однажды Вы проснетесь и скажете — мы теперь Agile компания можно больше ничего не делать! Так не получится). Вы всегда будете искать где и что улучшить, попробовать новые практики, обучить новых сотрудников и пр. Все течёт, все меняется.
Рекомендации:
1) «Высший менеджмент организации должен стать проводником, лидером Agile изменений. Необходимо ежемесячно на уровне каждого трайба выступать перед сотрудниками с обзором текущих целей, прогрессом их выполнения, анализом текущих уроков. Ежеквартально организовывать аналогичные meetup между лидерами трайбов с веб-трансляцией и открытым участием всех желающих сотрудников организации» — а вне Agile это не рекомендуется?
2) «Необходимо усилить роль и объем обучения Agile методикам» — можно бесконечно обучать — это не гарантирует успешного внедрения. А вот содействовать внедрению и паралельно обучать на практике — звучит как больше шансов на успех.
3) «Дополнительно необходимо проводить психологическое тестирование и выявлять сотрудников, которые не готовы к новым изменениям внутри компании» — таких людей легко выявить и без психологического тестирования. И Ваше предложение что с ними делать?
4) «Проектный офис должен выполнять координационную и коммуникативную роль (ежемесячные и ежеквартальные meetup), быть во главе стратегического планирования и обеспечивать мониторинг качества деятельности трайбов» — лично я не согласен (я думаю вы уже поняли мою позицию про централизацию)
— «быть во главе стратегического планирования» — а продукт менеджеры что будут делать?
— «обеспечивать мониторинг качества деятельности трайбов» — хммм что именно? Качество — а сами разработчики на что? Value — а продукт менеджеры на что? Ну я думаю вы поняли мою идею — PMO обязанности будут перераспределены на другие роли.
5) «Должен быть создан соответствующий on-line механизм внутри трайба и между трайбами с соотвествующими КПЭ у всех руководителей. » — круть! On-line, а не F2F и KPI на качество взаимодействия и коммуникаций между людьми (простите РЕСУРСАМИ по PMI). Ну а что? Мы же должны это контролировать! Не доверять же РЕСУРСАМ на самом деле. Шутки-шутками, но я только в 1 Agile трансформации видел такой KPI внедренным более-меннее успешно.
6) «должны быть объединены в единой оценке сотрудников всех уровней» — бам! Команда то, команда сё. Взаимодейстие, коммуникации — оцениваем каждого индивидуально! Agile HR на Вас нет! (https://www.agilehrmanifesto.org/)
7) «Используемые ИТ-решения для ведения бэклога, дашборды для Scrum, Kanban не должны ограничиваться только в их использовании для DevOps процессов и реализации спринтов, а являться информационной основой для выполнения пользовательских историй и проектов, портфелей и программ проектов, иметь связь с ERP системой, связь с КПЭ чаптеров, кластеров, трайбов и организации в целом» — ни одна из этих систем не позволит Вам контролировать действительно важные KPI. Только второстепенные, которые не отражают реальности.
Извините я под конец похоже устал и стал писать в более сжато-агрессивном формате. Это статья в очередной раз напомнила мне почему я больше не посещаю PMI эвенты.
Я восхищаюсь Вашим желанием распространять полученные знания.
Большое спасибо за столь подробные комментарии. Внимательно прочитал все ваши замечания, и хотел бы отметить, что они не критические и агрессивные, как вы упомянули, а в большинстве случаев расширяют или уточняют мои тезисы. Многостраничные книги написаны по всей этой тематике, а я сжал все до двух страниц. Конечно данные выводы должны вызывать желание спорить и дискутировать. Это и является моей целью. Отвечая на ваш общий вопрос, да, выступления были низкого качества, и PMI вынужденно притягивает Agile к своей деятельности, следуя вызовам времени. Я, безусловно, структурировал и интерпретировал материалы, исходя из своего понимания процессов, опыта и подал их, исходя из своего представления и «прекрасном». Я полностью в этой теме, XP для своих команд я использую с девяностых, и, как только начали появляться статьи на эту тему, оказалось, что мы с товарищами так и делаем программы, как они описывают. C нулевых уже пошли проекты по стандартам PMI и PRINCE2. Теперь всех «бросило» в Agile, и на моей текущей работе мы находимся в данном процессе, поэтому все оцениваю, интерпретирую, анализирую, чтобы добиться позитивного результата. Расплескать воду легко, собрать ее трудно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Современные тренды и рекомендации по аджайлизации крупных финансовых институтов