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

[mazzy]

Цитата:

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

Смешно?

Зависит от стадии отношений.

Сужу по тому как сам бываю заказчиком.
В самом начале, чтобы понять на что способен исполнитель я обычно выделяю мини-задачу. И явно предупреждаю исполнителя, о максимальном бюджете и о том, что задача будет оплачиваться в любом случае, что я хочу посмотреть на что способен исполнитель.

(Что-то типа тестовых заданий у Темы Лебедева при приеме на работу)

На следующих стадиях конечно же задачи ставлю на том уровне, который достигнут на первой минизадаче.

==============
Поэтому, как уже говорилось здесь:
1. подобные неопределенные задачи должны быть оплачены при любом исходе
2. такое очень даже нормально на первых этапах знакомства с исполнителем, чтобы понять его уровень

Неопределенные задачи - всего лишь инструмент. В некоторых случаях вполне можно использовать.

[mazzy]

Цитата:

Сообщение от George Nordic

это бот. Который возродил очень интересную дискуссию. Темы объединил, дал более осмысленный заголовок. Бот забанен.

1. Блин
2. Спасибо
3. Вот ведь дискуссии раньше были - теплые, ламповые...

[EVGL]

Цитата:

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

1. Блин
2. Спасибо
3. Вот ведь дискуссии раньше были - теплые, ламповые...

Не проблема, щас испортим:

• Пора валить!
• А что есть в вашей Аксапте, чего нет в 1С?
• Украинский программист умнее русского.
• Жить стало лучше, а скоро станет еще лучше.
• Доллар будет расти, евро - падать, а рубль сравняется с гривной.

[kALVINS]

Цитата:

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

Более того - в той же Турции такой огромный процент факапов на проектах как раз из за широкого применения agile.

Это потому, что Product Owner нихрена в критичных задачах для своего бизнеса, методике внедрения и информационных системах не понимает, а не потому, что методология нерабочая!
Суть фреймворка Scrum в том, что Product Owner определяет приоритет у задач и последовательность их реализации. Нормальные люди сначала основные функции реализуют, а потом за хотелки принимаются. Вот поэтому на турецких внедрениях и проблемы ))))

[ice]

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

[fed]

Цитата:

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

Это потому, что Product Owner нихрена в критичных задачах для своего бизнеса, методике внедрения и информационных системах не понимает, а не потому, что методология нерабочая!
Суть фреймворка Scrum в том, что Product Owner определяет приоритет у задач и последовательность их реализации. Нормальные люди сначала основные функции реализуют, а потом за хотелки принимаются. Вот поэтому на турецких внедрениях и проблемы ))))

Как я обычно говорю - любая методология рассчитанная на вменяемость клиента и его способность четко сформировать цели, стратегию и критерии - заведомо обречена на провал. Условно говоря - если бы клиент был такой умный, он бы проект сам сделал (иногда покупая разработчиков и консультантов на почасовку на тактические задачи), а не нанимал бы консалтинговую фирму. То есть - сам факт привлечения консультантов говорит о том что клиент не в состояни определять приоритет у задач, определять стратегию, строить ключевых пользователей, разрешать конфликты интересов между ключевыми пользователями и тд и тп.
И решение всех этих проблем - это имено то, за что внедренцам ERP-систем и платят их неплохие почасовые ставки. Которые, кстати, заметно выше чем ставки у финансовых аудиторов или офшорных разработчиков. (Которые, по сути, смежные по проблематике профессии).

[kALVINS]

Цитата:

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

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

При таком раскладе будут делаться хотелки того пользователя кто громче всех кричит )))
Нет, Product Owner должен активно работать в команде внедрения и сам определять приоритеты всех задач.

[Bergman]

Эджайловский Product owner в применении к АХ это ответсвенный консультант за определенный участок. Таким образом, кто как не он будет заниматься пользователями и корректировать их требования согласно best practices, а уже потом вместо с командой клиента и своей командой (возможно с другими Product ownerами) расставлять приоритеты.

[macklakov]

Цитата:

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

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

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

[mnt_dx]

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

[macklakov]

Цитата:

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

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

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

[pitersky]

Цитата:

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

Условно говоря - если бы клиент был такой умный, он бы проект сам сделал (иногда покупая разработчиков и консультантов на почасовку на тактические задачи), а не нанимал бы консалтинговую фирму. То есть - сам факт привлечения консультантов говорит о том что клиент не в состояни определять приоритет у задач, определять стратегию, строить ключевых пользователей, разрешать конфликты интересов между ключевыми пользователями и тд и тп.
И решение всех этих проблем - это имено то, за что внедренцам ERP-систем и платят их неплохие почасовые ставки

А я бы с этим поспорил.
Факт привлечения консультантов говорит только о том, что клиент НЕ ХОЧЕТ сам решать те задачи, которые на них возлагаются. Причины же нехотения при этом могут быть самые разные, "не могу" всего лишь одна из них.

[mnt_dx]

Цитата:

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

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

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

[ice]

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

[gl00mie]

+1. См. также Coordinated agility:

Цитата:

Project management happens differently at different levels of scale and abstraction. There is the team or feature level (around 10 people), the project level (between 50 and 5,000 people working on a specific release), and the product level (multiple releases led by executives). Agile methods work beautifully at the team level; formal methods work beautifully at the project level; and long-term strategic planning methods work beautifully at the product level. However, people rarely work at multiple levels at once; in fact, years typically separate those experiences for individuals. So people think effective methods at one level should be applied to others, which is how tragedies are often born. The moral is: small tight groups work differently than large disjointed organizations. Choose your methods accordingly.
Scrum is loaded with planning, and efficiently tracks more data in more detail than any other project management method I’ve seen at Microsoft (except for TSP, used by a few teams). Likewise, high-level project planning is critical to successfully scoping, coordinating, and delivering any large-scale initiative. If you have limited vision, then Scrum alone is fine. If you want to deliver lower quality and less customer value in more time than your competitors, or if you want to micromanage every aspect of your limited scope, then project planning alone is fine. If you have a bold vision with broad scope that you want delivered efficiently with high quality and copious customer value, then you need a balance of both high-level project planning and Scrum.

[macklakov]

Цитата:

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

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

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

[Bergman]

Цитата:

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

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

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


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

[macklakov]

Цитата:

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

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

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

[belugin]

Несколько любопытных ссылок про скрам:

• http://scrumtrainingseries.com - интерактивный тренинг
• Срач на RSDN

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

[Ivanhoe]

Думаю, важно для нашего разговора определиться, что мы внедряем. Коробку с допилами или Самописку на платформе. И в том и в другом варианте что классика, что agile будут иметь свои плюсы и минусы.