AXForum  
Вернуться   AXForum > Прочие обсуждения > Курилка
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 06.03.2015, 15:19   #41  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от slava09 Посмотреть сообщение
Смешно?
Зависит от стадии отношений.

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

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

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

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

Неопределенные задачи - всего лишь инструмент. В некоторых случаях вполне можно использовать.
Старый 06.03.2015, 15:20   #42  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от George Nordic Посмотреть сообщение
это бот. Который возродил очень интересную дискуссию. Темы объединил, дал более осмысленный заголовок. Бот забанен.
1. Блин
2. Спасибо
3. Вот ведь дискуссии раньше были - теплые, ламповые...
Старый 06.03.2015, 16:22   #43  
EVGL is offline
EVGL
Banned
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
4,445 / 3001 (0) ++++++++++
Регистрация: 09.07.2002
Адрес: Parndorf, AT
Цитата:
Сообщение от mazzy Посмотреть сообщение
1. Блин
2. Спасибо
3. Вот ведь дискуссии раньше были - теплые, ламповые...
Не проблема, щас испортим:
  • Пора валить!
  • А что есть в вашей Аксапте, чего нет в 1С?
  • Украинский программист умнее русского.
  • Жить стало лучше, а скоро станет еще лучше.
  • Доллар будет расти, евро - падать, а рубль сравняется с гривной.
За это сообщение автора поблагодарили: fed (0), gl00mie (0).
Старый 10.03.2015, 11:47   #44  
kALVINS is offline
kALVINS
MCT
SAP
NavAx Club
 
749 / 64 (4) ++++
Регистрация: 28.01.2005
Адрес: Moscow
Цитата:
Сообщение от fed Посмотреть сообщение
Более того - в той же Турции такой огромный процент факапов на проектах как раз из за широкого применения agile.
Это потому, что Product Owner нихрена в критичных задачах для своего бизнеса, методике внедрения и информационных системах не понимает, а не потому, что методология нерабочая!
Суть фреймворка Scrum в том, что Product Owner определяет приоритет у задач и последовательность их реализации. Нормальные люди сначала основные функции реализуют, а потом за хотелки принимаются. Вот поэтому на турецких внедрениях и проблемы ))))
__________________
Axapta forever!!!
Старый 10.03.2015, 12:03   #45  
ice is offline
ice
Участник
Аватар для ice
Лучший по профессии 2014
 
1,731 / 406 (17) +++++++
Регистрация: 23.03.2006
владелец системы может вообще не ставить приоритеты по задачам, он определяет направление.
а вот приоритеты устанавливают ключевые пользователи, которые "громче всех кричат о наболевшем"
Старый 10.03.2015, 12:43   #46  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,907 / 5717 (196) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Цитата:
Сообщение от kALVINS Посмотреть сообщение
Это потому, что Product Owner нихрена в критичных задачах для своего бизнеса, методике внедрения и информационных системах не понимает, а не потому, что методология нерабочая!
Суть фреймворка Scrum в том, что Product Owner определяет приоритет у задач и последовательность их реализации. Нормальные люди сначала основные функции реализуют, а потом за хотелки принимаются. Вот поэтому на турецких внедрениях и проблемы ))))
Как я обычно говорю - любая методология рассчитанная на вменяемость клиента и его способность четко сформировать цели, стратегию и критерии - заведомо обречена на провал. Условно говоря - если бы клиент был такой умный, он бы проект сам сделал (иногда покупая разработчиков и консультантов на почасовку на тактические задачи), а не нанимал бы консалтинговую фирму. То есть - сам факт привлечения консультантов говорит о том что клиент не в состояни определять приоритет у задач, определять стратегию, строить ключевых пользователей, разрешать конфликты интересов между ключевыми пользователями и тд и тп.
И решение всех этих проблем - это имено то, за что внедренцам ERP-систем и платят их неплохие почасовые ставки. Которые, кстати, заметно выше чем ставки у финансовых аудиторов или офшорных разработчиков. (Которые, по сути, смежные по проблематике профессии).
Старый 10.03.2015, 12:45   #47  
kALVINS is offline
kALVINS
MCT
SAP
NavAx Club
 
749 / 64 (4) ++++
Регистрация: 28.01.2005
Адрес: Moscow
Цитата:
Сообщение от ice Посмотреть сообщение
владелец системы может вообще не ставить приоритеты по задачам, он определяет направление.
а вот приоритеты устанавливают ключевые пользователи, которые "громче всех кричат о наболевшем"
При таком раскладе будут делаться хотелки того пользователя кто громче всех кричит )))
Нет, Product Owner должен активно работать в команде внедрения и сам определять приоритеты всех задач.
__________________
Axapta forever!!!
Старый 11.03.2015, 02:26   #48  
Bergman is offline
Bergman
Участник
 
50 / 18 (1) ++
Регистрация: 07.12.2012
Эджайловский Product owner в применении к АХ это ответсвенный консультант за определенный участок. Таким образом, кто как не он будет заниматься пользователями и корректировать их требования согласно best practices, а уже потом вместо с командой клиента и своей командой (возможно с другими Product ownerами) расставлять приоритеты.
Старый 11.03.2015, 06:46   #49  
macklakov is offline
macklakov
NavAx
Аватар для macklakov
 
2,225 / 976 (37) +++++++
Регистрация: 03.04.2002
Цитата:
Сообщение от ice Посмотреть сообщение
владелец системы может вообще не ставить приоритеты по задачам, он определяет направление.
а вот приоритеты устанавливают ключевые пользователи, которые "громче всех кричат о наболевшем"
Ну как-бы это его прямая должностная обязанность. Если он на это забивает, то к нему применимы обычные дисциплинарные меры. Если он не умеет, для этого есть специальные экспресс-курсы.
Вопли пользователей это замечательно. Их надо писать в backlog. А когда идет планирование следующего этапа, ставится вопрос: "каким функционалом мы будем жертвовать?" Ибо априори все хотелки исполнить невозможно. Команда принимает только тот объем, который может осилить за спринт. Все остальное откладывается на потом. Если будет желание и бюджет, то будет хорошо всем. Не будет желания или бюджета, то будет система которая многих раздражает, но основные задачи выполняет.
__________________
Isn't it nice when things just work?
Старый 11.03.2015, 10:36   #50  
mnt_dx is offline
mnt_dx
Участник
Axapta Retail User
Лучший по профессии 2014
 
1,747 / 188 (10) ++++++
Регистрация: 17.02.2011
Адрес: К Северу через Северо-Запад
Я всегда считал, что аджайл расчитан на работу поддержки, когда пользователи выдают понятные требования, критерии выполнения которых понятны и достижимы в короткий срок: добавить кнопку, она делает то-то. На следующем этапе покрасить кнопку в зеленый. Это не тоже самое, что добавить аналитический признак в те документы, которые надо, чтобы через полгода можно было выполнить консолидацию по правилам, которые ещё в разработке.
Старый 11.03.2015, 11:16   #51  
macklakov is offline
macklakov
NavAx
Аватар для macklakov
 
2,225 / 976 (37) +++++++
Регистрация: 03.04.2002
Цитата:
Сообщение от mnt_dx Посмотреть сообщение
Я всегда считал, что аджайл расчитан на работу поддержки, когда пользователи выдают понятные требования, критерии выполнения которых понятны и достижимы в короткий срок: добавить кнопку, она делает то-то. На следующем этапе покрасить кнопку в зеленый. Это не тоже самое, что добавить аналитический признак в те документы, которые надо, чтобы через полгода можно было выполнить консолидацию по правилам, которые ещё в разработке.
Вы что, кнопку 2 недели привинчиваете? За 2 недели парочка новых журналов с кастомной разноской и печатными формами делаются минимальной командой. И когда этот журнал делается, привинтить контроль аналитики тоже дело не хитрое. Если не плясать с бубном, в надежде сварганить бузупречную всеобъемлющую спеку на века, а быстро написать короткую историю, а с деталями настроики и девелопмента по ходу разбираться, процесс быстро идет.
Да, время от времени приходится переделывать, но издержки при этом гораздо меньше, чем на продумывание всеобъемлющих спек. Ведь все равно часто всего оказывается что клиент забыл консультанту что-то упомянуть и тщательно проработанную спеку можно в помойку выбрасывать.
__________________
Isn't it nice when things just work?

Последний раз редактировалось macklakov; 11.03.2015 в 11:59.
Старый 11.03.2015, 13:20   #52  
pitersky is offline
pitersky
северный Будда
Аватар для pitersky
Ex AND Project
Соотечественники
 
1,506 / 428 (18) +++++++
Регистрация: 26.09.2007
Адрес: Солнечная система
Цитата:
Сообщение от fed Посмотреть сообщение
Условно говоря - если бы клиент был такой умный, он бы проект сам сделал (иногда покупая разработчиков и консультантов на почасовку на тактические задачи), а не нанимал бы консалтинговую фирму. То есть - сам факт привлечения консультантов говорит о том что клиент не в состояни определять приоритет у задач, определять стратегию, строить ключевых пользователей, разрешать конфликты интересов между ключевыми пользователями и тд и тп.
И решение всех этих проблем - это имено то, за что внедренцам ERP-систем и платят их неплохие почасовые ставки
А я бы с этим поспорил.
Факт привлечения консультантов говорит только о том, что клиент НЕ ХОЧЕТ сам решать те задачи, которые на них возлагаются. Причины же нехотения при этом могут быть самые разные, "не могу" всего лишь одна из них.
__________________
С уважением,
Вячеслав
Старый 11.03.2015, 14:47   #53  
mnt_dx is offline
mnt_dx
Участник
Axapta Retail User
Лучший по профессии 2014
 
1,747 / 188 (10) ++++++
Регистрация: 17.02.2011
Адрес: К Северу через Северо-Запад
Цитата:
Сообщение от macklakov Посмотреть сообщение
Ведь все равно часто всего оказывается что клиент забыл консультанту что-то упомянуть и тщательно проработанную спеку можно в помойку выбрасывать.
Об этом и речь - аджайл не подходит для внедрения ERP.
Старый 11.03.2015, 16:14   #54  
ice is offline
ice
Участник
Аватар для ice
Лучший по профессии 2014
 
1,731 / 406 (17) +++++++
Регистрация: 23.03.2006
если используется как средство контроля исполнителей, то вполне подходит. другое дело, что уровнем выше, должны руководствоваться другими методологиями
За это сообщение автора поблагодарили: gl00mie (1).
Старый 11.03.2015, 17:23   #55  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5798 (201) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
+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  
macklakov is offline
macklakov
NavAx
Аватар для macklakov
 
2,225 / 976 (37) +++++++
Регистрация: 03.04.2002
Цитата:
Сообщение от mnt_dx Посмотреть сообщение
Об этом и речь - аджайл не подходит для внедрения ERP.
Это как ты такой вывод сделал? Я тут пытаюсь объяснить что весь смысл существования scrum это как-то работать с пользователем, который никак не определится, чего он хочет. Поэтому детальные спецификации, мягко говоря, не поощряются. Все направлено на то, чтобы клиент как можно быстрее получил на руки что-то работающее. А потом уже можно писать вдумчивую документацию. Если, опять таки, клиент этого захочет и у него будут деньги.
__________________
Isn't it nice when things just work?
Старый 12.03.2015, 01:38   #57  
Bergman is offline
Bergman
Участник
 
50 / 18 (1) ++
Регистрация: 07.12.2012
Цитата:
Сообщение от macklakov Посмотреть сообщение
Это как ты такой вывод сделал? Я тут пытаюсь объяснить что весь смысл существования scrum это как-то работать с пользователем, который никак не определится, чего он хочет. Поэтому детальные спецификации, мягко говоря, не поощряются. Все направлено на то, чтобы клиент как можно быстрее получил на руки что-то работающее. А потом уже можно писать вдумчивую документацию. Если, опять таки, клиент этого захочет и у него будут деньги.
Потом попадаешь на такой проект с огромным количеством незадокументированных модификаций, причем со многими из них даже пользователи не знакомы


В АХ аджайл очень удобный только для контроля команды (стендапы, канбан, оценка задач, ретроспективы). Но передавать задачу в разработку лучше в готовом для разработчика дизайне.
Старый 12.03.2015, 07:26   #58  
macklakov is offline
macklakov
NavAx
Аватар для macklakov
 
2,225 / 976 (37) +++++++
Регистрация: 03.04.2002
Цитата:
Сообщение от Bergman Посмотреть сообщение
Потом попадаешь на такой проект с огромным количеством незадокументированных модификаций, причем со многими из них даже пользователи не знакомы
Как это возможно, если пользователи работают в системе минимум половину длительности проекта? И каждый этап завершается демонстрацией и приемкой работающего решения?
Документация это точно такая же задача как и разработка. Если пользователю нужны детальные инструкции, он их заказывает, если и так все ясно, незачем и время тратить. А бывает что инструкции должны доходить до уровня букваря по предметной области. И доподлинно выяснить, какой уровень документации нужен, можно только когда новые пользователи начнут в систему лезть.
Что касается проектной документации, то функциональные требования фиксируются в виде историй перед началом каждого этапа. Более того, до начала работы они причесываются до состояния когда всем понятно о чем речь идет. А дизайн на совести команды разработчиков. Опять таки, если разработчики квалифицированные, то заморачиваться смысла нет, и так понятно какие патерны применяются к схеме данных и коду. Хватит и комментов в коде. Если же команда брызжет оригинальными решениями банальных задач, тогда стоит требовать детального описания того, что ваяется, чтобы потом можно было разобраться что к чему. Но решение, опять таки, принимается по мере возникновения проблем. Если через пару спринтов возникли вопросы "что это долдон тут наклепал?" тогда документирование более строгое, если же с использование чужого кода ни у кого проблем нет, то и заморачиваться незачем.
Базовый принцип очень простой: "Очень много шансов что это все равно придется выбросить на помойку, поэтому делай как можно проще, быстрее и дешевле"
__________________
Isn't it nice when things just work?
Старый 12.03.2015, 09:06   #59  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,622 / 2925 (107) +++++++++
Регистрация: 16.01.2004
Записей в блоге: 5
Несколько любопытных ссылок про скрам:
Вообще, как мне кажется, аджайл базируется на дешовых изменениях. В случае внедрения, некоторые изменения могут быть недешевые - например структура бюзы данных при наличии большого количества данных. Так, что наверное, жизнеспособен какой-то гибрид.
Старый 12.03.2015, 09:22   #60  
Ivanhoe is offline
Ivanhoe
Участник
Аватар для Ivanhoe
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
4,143 / 2156 (80) +++++++++
Регистрация: 29.09.2005
Адрес: Санкт-Петербург
Думаю, важно для нашего разговора определиться, что мы внедряем. Коробку с допилами или Самописку на платформе. И в том и в другом варианте что классика, что agile будут иметь свои плюсы и минусы.
__________________
Ivanhoe as is..
Теги
agile, scrum

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Сделайте пожалуйста обновления одного раздела. без обновления всей страницы -O_o- Обсуждение форума 1 31.05.2013 12:49
Какая модель управления эффективнее? lagr221374 Курилка 13 26.01.2012 16:01
Звездочки заменены на символ "Сила сигнала". Стало ли лучше? mazzy Информация для участников 12 28.07.2009 13:29
Новая версия движка 3.5.4. Стало ли лучше? Сбор багов и замечаний здесь mazzy Обсуждение форума 102 25.05.2006 00:25
Методология распределения рабочего времени консультанта / программиста ushastik Курилка 12 24.02.2004 09:22

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 06:47.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.