06.03.2015, 15:19 | #41 |
Участник
|
Зависит от стадии отношений.
Сужу по тому как сам бываю заказчиком. В самом начале, чтобы понять на что способен исполнитель я обычно выделяю мини-задачу. И явно предупреждаю исполнителя, о максимальном бюджете и о том, что задача будет оплачиваться в любом случае, что я хочу посмотреть на что способен исполнитель. (Что-то типа тестовых заданий у Темы Лебедева при приеме на работу) На следующих стадиях конечно же задачи ставлю на том уровне, который достигнут на первой минизадаче. ============== Поэтому, как уже говорилось здесь: 1. подобные неопределенные задачи должны быть оплачены при любом исходе 2. такое очень даже нормально на первых этапах знакомства с исполнителем, чтобы понять его уровень Неопределенные задачи - всего лишь инструмент. В некоторых случаях вполне можно использовать. |
|
06.03.2015, 15:20 | #42 |
Участник
|
|
|
06.03.2015, 16:22 | #43 |
Banned
|
Цитата:
|
|
|
За это сообщение автора поблагодарили: fed (0), gl00mie (0). |
10.03.2015, 11:47 | #44 |
MCT
|
Цитата:
Суть фреймворка Scrum в том, что Product Owner определяет приоритет у задач и последовательность их реализации. Нормальные люди сначала основные функции реализуют, а потом за хотелки принимаются. Вот поэтому на турецких внедрениях и проблемы ))))
__________________
Axapta forever!!! |
|
10.03.2015, 12:03 | #45 |
Участник
|
владелец системы может вообще не ставить приоритеты по задачам, он определяет направление.
а вот приоритеты устанавливают ключевые пользователи, которые "громче всех кричат о наболевшем" |
|
10.03.2015, 12:43 | #46 |
Moderator
|
Цитата:
Сообщение от kALVINS
Это потому, что Product Owner нихрена в критичных задачах для своего бизнеса, методике внедрения и информационных системах не понимает, а не потому, что методология нерабочая!
Суть фреймворка Scrum в том, что Product Owner определяет приоритет у задач и последовательность их реализации. Нормальные люди сначала основные функции реализуют, а потом за хотелки принимаются. Вот поэтому на турецких внедрениях и проблемы )))) И решение всех этих проблем - это имено то, за что внедренцам ERP-систем и платят их неплохие почасовые ставки. Которые, кстати, заметно выше чем ставки у финансовых аудиторов или офшорных разработчиков. (Которые, по сути, смежные по проблематике профессии). |
|
10.03.2015, 12:45 | #47 |
MCT
|
Цитата:
Нет, Product Owner должен активно работать в команде внедрения и сам определять приоритеты всех задач.
__________________
Axapta forever!!! |
|
11.03.2015, 02:26 | #48 |
Участник
|
Эджайловский Product owner в применении к АХ это ответсвенный консультант за определенный участок. Таким образом, кто как не он будет заниматься пользователями и корректировать их требования согласно best practices, а уже потом вместо с командой клиента и своей командой (возможно с другими Product ownerами) расставлять приоритеты.
|
|
11.03.2015, 06:46 | #49 |
NavAx
|
Цитата:
Вопли пользователей это замечательно. Их надо писать в backlog. А когда идет планирование следующего этапа, ставится вопрос: "каким функционалом мы будем жертвовать?" Ибо априори все хотелки исполнить невозможно. Команда принимает только тот объем, который может осилить за спринт. Все остальное откладывается на потом. Если будет желание и бюджет, то будет хорошо всем. Не будет желания или бюджета, то будет система которая многих раздражает, но основные задачи выполняет.
__________________
Isn't it nice when things just work? |
|
11.03.2015, 10:36 | #50 |
Участник
|
Я всегда считал, что аджайл расчитан на работу поддержки, когда пользователи выдают понятные требования, критерии выполнения которых понятны и достижимы в короткий срок: добавить кнопку, она делает то-то. На следующем этапе покрасить кнопку в зеленый. Это не тоже самое, что добавить аналитический признак в те документы, которые надо, чтобы через полгода можно было выполнить консолидацию по правилам, которые ещё в разработке.
|
|
11.03.2015, 11:16 | #51 |
NavAx
|
Цитата:
Сообщение от mnt_dx
Я всегда считал, что аджайл расчитан на работу поддержки, когда пользователи выдают понятные требования, критерии выполнения которых понятны и достижимы в короткий срок: добавить кнопку, она делает то-то. На следующем этапе покрасить кнопку в зеленый. Это не тоже самое, что добавить аналитический признак в те документы, которые надо, чтобы через полгода можно было выполнить консолидацию по правилам, которые ещё в разработке.
Да, время от времени приходится переделывать, но издержки при этом гораздо меньше, чем на продумывание всеобъемлющих спек. Ведь все равно часто всего оказывается что клиент забыл консультанту что-то упомянуть и тщательно проработанную спеку можно в помойку выбрасывать.
__________________
Isn't it nice when things just work? Последний раз редактировалось macklakov; 11.03.2015 в 11:59. |
|
11.03.2015, 13:20 | #52 |
северный Будда
|
Цитата:
Сообщение от fed
Условно говоря - если бы клиент был такой умный, он бы проект сам сделал (иногда покупая разработчиков и консультантов на почасовку на тактические задачи), а не нанимал бы консалтинговую фирму. То есть - сам факт привлечения консультантов говорит о том что клиент не в состояни определять приоритет у задач, определять стратегию, строить ключевых пользователей, разрешать конфликты интересов между ключевыми пользователями и тд и тп.
И решение всех этих проблем - это имено то, за что внедренцам ERP-систем и платят их неплохие почасовые ставки Факт привлечения консультантов говорит только о том, что клиент НЕ ХОЧЕТ сам решать те задачи, которые на них возлагаются. Причины же нехотения при этом могут быть самые разные, "не могу" всего лишь одна из них.
__________________
С уважением, Вячеслав |
|
11.03.2015, 14:47 | #53 |
Участник
|
Об этом и речь - аджайл не подходит для внедрения ERP.
|
|
11.03.2015, 16:14 | #54 |
Участник
|
если используется как средство контроля исполнителей, то вполне подходит. другое дело, что уровнем выше, должны руководствоваться другими методологиями
|
|
|
За это сообщение автора поблагодарили: gl00mie (1). |
11.03.2015, 17:23 | #55 |
Участник
|
+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. |
|
12.03.2015, 01:16 | #56 |
NavAx
|
Это как ты такой вывод сделал? Я тут пытаюсь объяснить что весь смысл существования scrum это как-то работать с пользователем, который никак не определится, чего он хочет. Поэтому детальные спецификации, мягко говоря, не поощряются. Все направлено на то, чтобы клиент как можно быстрее получил на руки что-то работающее. А потом уже можно писать вдумчивую документацию. Если, опять таки, клиент этого захочет и у него будут деньги.
__________________
Isn't it nice when things just work? |
|
12.03.2015, 01:38 | #57 |
Участник
|
Цитата:
Сообщение от macklakov
Это как ты такой вывод сделал? Я тут пытаюсь объяснить что весь смысл существования scrum это как-то работать с пользователем, который никак не определится, чего он хочет. Поэтому детальные спецификации, мягко говоря, не поощряются. Все направлено на то, чтобы клиент как можно быстрее получил на руки что-то работающее. А потом уже можно писать вдумчивую документацию. Если, опять таки, клиент этого захочет и у него будут деньги.
В АХ аджайл очень удобный только для контроля команды (стендапы, канбан, оценка задач, ретроспективы). Но передавать задачу в разработку лучше в готовом для разработчика дизайне. |
|
12.03.2015, 07:26 | #58 |
NavAx
|
Цитата:
Документация это точно такая же задача как и разработка. Если пользователю нужны детальные инструкции, он их заказывает, если и так все ясно, незачем и время тратить. А бывает что инструкции должны доходить до уровня букваря по предметной области. И доподлинно выяснить, какой уровень документации нужен, можно только когда новые пользователи начнут в систему лезть. Что касается проектной документации, то функциональные требования фиксируются в виде историй перед началом каждого этапа. Более того, до начала работы они причесываются до состояния когда всем понятно о чем речь идет. А дизайн на совести команды разработчиков. Опять таки, если разработчики квалифицированные, то заморачиваться смысла нет, и так понятно какие патерны применяются к схеме данных и коду. Хватит и комментов в коде. Если же команда брызжет оригинальными решениями банальных задач, тогда стоит требовать детального описания того, что ваяется, чтобы потом можно было разобраться что к чему. Но решение, опять таки, принимается по мере возникновения проблем. Если через пару спринтов возникли вопросы "что это долдон тут наклепал?" тогда документирование более строгое, если же с использование чужого кода ни у кого проблем нет, то и заморачиваться незачем. Базовый принцип очень простой: "Очень много шансов что это все равно придется выбросить на помойку, поэтому делай как можно проще, быстрее и дешевле"
__________________
Isn't it nice when things just work? |
|
12.03.2015, 09:06 | #59 |
Участник
|
Несколько любопытных ссылок про скрам:
Вообще, как мне кажется, аджайл базируется на дешовых изменениях. В случае внедрения, некоторые изменения могут быть недешевые - например структура бюзы данных при наличии большого количества данных. Так, что наверное, жизнеспособен какой-то гибрид. |
|
12.03.2015, 09:22 | #60 |
Участник
|
Думаю, важно для нашего разговора определиться, что мы внедряем. Коробку с допилами или Самописку на платформе. И в том и в другом варианте что классика, что agile будут иметь свои плюсы и минусы.
__________________
Ivanhoe as is.. |
|
Теги |
agile, scrum |
|
|