Comments 6
А какие стадии у задачи при данной методологии?
Думаю, одна из задач — обеспечить стабильный выпуск продуктов, уровня Enterprise, когда есть несколько крупных продуктов, состоящих из десятков-сотен зависимых и взаимосвязанных продуктов, над которыми кропят тысячи сотрудников ( владельцев, аналитиков, разработчиков, тестировщиков, инженеров и т.д. )
Хотя я могу и ошибаться в своём мнении.
Хотя я могу и ошибаться в своём мнении.
Если говорить о верхнеуровневой задаче то да, это одна из них. По-сути идея стоящая за этим фреймворком- перенести все прелести работающих гибких методик на масштаб крупного разработчика ( крупного это где-то более чем 100 разработчиков). Есть и другие подходы к масштабированию, но SAFe, на мой взгляд, один из самых проработанных, хотя при этом и несколько сложный в восприятии. Сравнение их — это другая тема.
SAFe, корректнее назвать фреймворком, который под собой собрал несколько методик: Scrum, Kanban, практики XP, Lean Software Development и связал их вместе.
А вот вопрос можно ли поподробнее раскрыть? Какие задачи У этого фреймворка? Или какие стадии задачи (на разработку, к примеру) в рамках этого фреймворка? И все равно нужно будет пояснить более конкретно сам вопрос.
А вот вопрос можно ли поподробнее раскрыть? Какие задачи У этого фреймворка? Или какие стадии задачи (на разработку, к примеру) в рамках этого фреймворка? И все равно нужно будет пояснить более конкретно сам вопрос.
- Все что я узнал из данной статьи -"Существует еще одна методология, которая подходит к одной абстрактной предметной области" (к которой, в частности, можно отнести все что угодно)
- Количество разнородных систем, а не количество разработчиков влияет на сложность проекта. 10 разработчиков, потеющих над фронтом не равно 10 ти разработчикам, 2 из которых пилят БД, 2 интеграцию, 2 бек офис и т.д. Вот тут действительно — разные команды, разное мировоззрение, не возможность коммуникаций.
- Имхо, лучшая методология решающая проблему пункта 2 SADD от Microsoft — за счет спирали можем делать короткие итерации в разработке, при этом существует роль бизнес и системного архитектора, который и налаживает коммуникации и контролирует качество всего продукта.
1. Это конкретная предметная область, масштабирование гибких подходов к разработке на крупную организации. Эта тема достаточно близка мне, и я общаясь с крупными компаниями вижу её очень даже вживую, потому ну никак не соглашусь, что это абстракция :)
2. расширю, что речь про организацию, процессы и технологии ( проект это частность), далее, усложняющие факторы, навскидку:
— Количество разработчиков (настаиваю:) и их структура подчинения
— Иерархия организации
— Количество систем и их архитектура
— Зрелость организации и каждого сотрудника в частности
— Степень автоматизации существующих процессов
…
Я, кстати, думаю, что основной трэш для гибкого подхода как раз не 2 на БД, 2 на API, 2 на бек офис.., а те самые 10 на фронт :)
3. с IMHO не буду спорить.
Скажу лишь, что если по структуре команд и по архитектуре софта вообще ничего не менять, то, разумеется, переход к коротким итерациям (каскад или спираль) позволит хоть как-то улучшить ситуацию, в сравнение с долгими релизами.
Речь в статье про переход именно на гибкий подход, с очень короткими итерациями и быстрым фидбэком, с возможностью часто выкатывать изменения в продуктив, ( 2 недели к примеру) и уйти от модели постановки требований, она, в среднем по больнице, плохо работает.
Есть ведь задачи когда lead time должен составлять недели, дни или даже часы, минуты. Это и есть двигатель изменений. Тут вопрос не в том какая методика нравится. А в том, какая подходит под текущую бизнес ситуацию и под конкретные задачи. У каждой есть зона(ы) применимости и зона(ы) непригодности. Точка.
2. расширю, что речь про организацию, процессы и технологии ( проект это частность), далее, усложняющие факторы, навскидку:
— Количество разработчиков (настаиваю:) и их структура подчинения
— Иерархия организации
— Количество систем и их архитектура
— Зрелость организации и каждого сотрудника в частности
— Степень автоматизации существующих процессов
…
Я, кстати, думаю, что основной трэш для гибкого подхода как раз не 2 на БД, 2 на API, 2 на бек офис.., а те самые 10 на фронт :)
3. с IMHO не буду спорить.
Скажу лишь, что если по структуре команд и по архитектуре софта вообще ничего не менять, то, разумеется, переход к коротким итерациям (каскад или спираль) позволит хоть как-то улучшить ситуацию, в сравнение с долгими релизами.
Речь в статье про переход именно на гибкий подход, с очень короткими итерациями и быстрым фидбэком, с возможностью часто выкатывать изменения в продуктив, ( 2 недели к примеру) и уйти от модели постановки требований, она, в среднем по больнице, плохо работает.
Есть ведь задачи когда lead time должен составлять недели, дни или даже часы, минуты. Это и есть двигатель изменений. Тут вопрос не в том какая методика нравится. А в том, какая подходит под текущую бизнес ситуацию и под конкретные задачи. У каждой есть зона(ы) применимости и зона(ы) непригодности. Точка.
Sign up to leave a comment.
Как улучшить мир?