Какая методология лучше в случае "Сначала сделайте, а мы посмотрим"

[mnt_dx]

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

[macklakov]

Цитата:

Сообщение от mnt_dx

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

Вы что, кнопку 2 недели привинчиваете? За 2 недели парочка новых журналов с кастомной разноской и печатными формами делаются минимальной командой. И когда этот журнал делается, привинтить контроль аналитики тоже дело не хитрое. Если не плясать с бубном, в надежде сварганить бузупречную всеобъемлющую спеку на века, а быстро написать короткую историю, а с деталями настроики и девелопмента по ходу разбираться, процесс быстро идет.
Да, время от времени приходится переделывать, но издержки при этом гораздо меньше, чем на продумывание всеобъемлющих спек. Ведь все равно часто всего оказывается что клиент забыл консультанту что-то упомянуть и тщательно проработанную спеку можно в помойку выбрасывать.

[mnt_dx]

Цитата:

Сообщение от macklakov

Ведь все равно часто всего оказывается что клиент забыл консультанту что-то упомянуть и тщательно проработанную спеку можно в помойку выбрасывать.

Об этом и речь - аджайл не подходит для внедрения ERP.

[macklakov]

Цитата:

Сообщение от mnt_dx

Об этом и речь - аджайл не подходит для внедрения ERP.

Это как ты такой вывод сделал? Я тут пытаюсь объяснить что весь смысл существования scrum это как-то работать с пользователем, который никак не определится, чего он хочет. Поэтому детальные спецификации, мягко говоря, не поощряются. Все направлено на то, чтобы клиент как можно быстрее получил на руки что-то работающее. А потом уже можно писать вдумчивую документацию. Если, опять таки, клиент этого захочет и у него будут деньги.

[Bergman]

Цитата:

Сообщение от macklakov

Это как ты такой вывод сделал? Я тут пытаюсь объяснить что весь смысл существования scrum это как-то работать с пользователем, который никак не определится, чего он хочет. Поэтому детальные спецификации, мягко говоря, не поощряются. Все направлено на то, чтобы клиент как можно быстрее получил на руки что-то работающее. А потом уже можно писать вдумчивую документацию. Если, опять таки, клиент этого захочет и у него будут деньги.

Потом попадаешь на такой проект с огромным количеством незадокументированных модификаций, причем со многими из них даже пользователи не знакомы


В АХ аджайл очень удобный только для контроля команды (стендапы, канбан, оценка задач, ретроспективы). Но передавать задачу в разработку лучше в готовом для разработчика дизайне.

[macklakov]

Цитата:

Сообщение от Bergman

Потом попадаешь на такой проект с огромным количеством незадокументированных модификаций, причем со многими из них даже пользователи не знакомы

Как это возможно, если пользователи работают в системе минимум половину длительности проекта? И каждый этап завершается демонстрацией и приемкой работающего решения?
Документация это точно такая же задача как и разработка. Если пользователю нужны детальные инструкции, он их заказывает, если и так все ясно, незачем и время тратить. А бывает что инструкции должны доходить до уровня букваря по предметной области. И доподлинно выяснить, какой уровень документации нужен, можно только когда новые пользователи начнут в систему лезть.
Что касается проектной документации, то функциональные требования фиксируются в виде историй перед началом каждого этапа. Более того, до начала работы они причесываются до состояния когда всем понятно о чем речь идет. А дизайн на совести команды разработчиков. Опять таки, если разработчики квалифицированные, то заморачиваться смысла нет, и так понятно какие патерны применяются к схеме данных и коду. Хватит и комментов в коде. Если же команда брызжет оригинальными решениями банальных задач, тогда стоит требовать детального описания того, что ваяется, чтобы потом можно было разобраться что к чему. Но решение, опять таки, принимается по мере возникновения проблем. Если через пару спринтов возникли вопросы "что это долдон тут наклепал?" тогда документирование более строгое, если же с использование чужого кода ни у кого проблем нет, то и заморачиваться незачем.
Базовый принцип очень простой: "Очень много шансов что это все равно придется выбросить на помойку, поэтому делай как можно проще, быстрее и дешевле"

[mnt_dx]

Цитата:

Сообщение от macklakov

Это как ты такой вывод сделал? Я тут пытаюсь объяснить что весь смысл существования scrum это как-то работать с пользователем, который никак не определится, чего он хочет. Поэтому детальные спецификации, мягко говоря, не поощряются. Все направлено на то, чтобы клиент как можно быстрее получил на руки что-то работающее. А потом уже можно писать вдумчивую документацию. Если, опять таки, клиент этого захочет и у него будут деньги.

Клиенту ERP нужно работающее что-то большое, под его конкретику, а не абы что, что можно быстро сделать. Scrum требует конкретных постановок, тут не подходит неопределившийся пользователь. Можно по этой методологии вести поддержку или дорабатывать коробку, которая уже развернута и настроена, но не внедрение с нуля.
Наверняка можно организовать и миграцию из одной системы в другую, если функциональность задокументирована.

[macklakov]

Цитата:

Сообщение от mnt_dx

Клиенту ERP нужно работающее что-то большое, под его конкретику

Клиент обычно знает что ему нужно лишь в общих чертах. Поэтому в кошерном agile по глобальным хотелкам составляется дорожная карта. А вот что конкретно и как будет реализовано, решается уже на ходу.
Насчет чего-то большого есть старинная притча про поедание слона. Очень сложно слона сразу проглотить и не подавиться. А вот если его нарубить меленько, то очень даже посильно. И когда наелся можно остановиться. Передохнуть. А потом опять продолжить.

[mnt_dx]

Цитата:

Сообщение от macklakov

Клиент обычно знает что ему нужно лишь в общих чертах. Поэтому в кошерном agile по глобальным хотелкам составляется дорожная карта. А вот что конкретно и как будет реализовано, решается уже на ходу.

Скрам еще подойдет для длительного пресейла.

Цитата:

Сообщение от macklakov

Насчет чего-то большого есть старинная притча про поедание слона. Очень сложно слона сразу проглотить и не подавиться. А вот если его нарубить меленько, то очень даже посильно. И когда наелся можно остановиться. Передохнуть. А потом опять продолжить.

Есть ещё ролик про самолет, который строят ИТшники