AK
Не ожидал такого дикого эффекта
Size: a a a
2016 August 16
AP
скажите, а вендор 1С понимает как надо развивать платформу для TDD, BDD и прочего CI/CD? если да, то это будет прорыв. комьюнити 1С огромное по стране.
Ну есть кое-какие зачатки для тестирования. Однако есть и инструменты от community, даже реализация Gherkin. Есть команды которые используют Jenkins чтобы прогонять тесты при обнолвении состояния хранилища (недо-VCS для конфигураций 1С).
TM
Не ожидал такого дикого эффекта
Я начал применять tdd для проекта под ms azure, через некоторое время один из программистов начал утверждать, что "дизайн ему подсказывают тесты" и что он чуть ли не говорит с ними - так что да, эффект сильный получился
AK
Да, все так.
A
Антох, нельзя посчитать то, что не существует в природе даже на уровне законченного осмысления. То, для чего придуман скрам - это вещь которой нет в природе, аналогов нет, ничего нет кроме продуктовой гипотезы, о том ,что это возможно будет так. Если у тебя продукт не такой, то и скрам нафиг не нужен, иначе это будет карго-культ. Возвращаясь к контрактованию, тут либо как ребята уже описали - у заказчика есть N денег и он готов их вложить в производство непонятной вещи беря на себя риски, но при этом получая полную прозрачность работы и вовлечение в результат. Либо никак. И даже 44ФЗ не при чем
Возвращаясь к вопросу Антона: бизнесу важно получить ответы на вопросы - сколько это будет стоить и когда это будет готово?
А весь наш agile не дает возможность ответить на эти вопросы, он лишь гарантирует что процесс будет прозрачным и практически\теоретически более выгодным чем водопадная модель с точки зрения стоимости разработки. То есть эти характеристики должны перевесить в беседе контракт с фиксед скоупом работ и ценой. Что выглядит почти нереальным.
А весь наш agile не дает возможность ответить на эти вопросы, он лишь гарантирует что процесс будет прозрачным и практически\теоретически более выгодным чем водопадная модель с точки зрения стоимости разработки. То есть эти характеристики должны перевесить в беседе контракт с фиксед скоупом работ и ценой. Что выглядит почти нереальным.
AV
#whois тестировщик из Германии. Учусь сам, учу других.
ИД
Возвращаясь к вопросу Антона: бизнесу важно получить ответы на вопросы - сколько это будет стоить и когда это будет готово?
А весь наш agile не дает возможность ответить на эти вопросы, он лишь гарантирует что процесс будет прозрачным и практически\теоретически более выгодным чем водопадная модель с точки зрения стоимости разработки. То есть эти характеристики должны перевесить в беседе контракт с фиксед скоупом работ и ценой. Что выглядит почти нереальным.
А весь наш agile не дает возможность ответить на эти вопросы, он лишь гарантирует что процесс будет прозрачным и практически\теоретически более выгодным чем водопадная модель с точки зрения стоимости разработки. То есть эти характеристики должны перевесить в беседе контракт с фиксед скоупом работ и ценой. Что выглядит почти нереальным.
есть уже нормальные подходы к agile-контрактам. где и скоуп отпускаем и заказчик не очкует.
A
поподробнее бы
A
Иван, на одной вашей конференции был на Сахарова, там не раскрыли этот вопрос
TM
Про "скоуп и очкование" какой-то дивный эльфийский мир
AN
Вот да, не очень понятно что такое “нормальные подходы к agile-контрактом”.
RK
Про "скоуп и очкование" - тут либо заказчик бизнес-риски берет на себя или хочет переложить их на подрядчика. Если бизнес-риски на заказчике (продукт не выстрелит, не закроет проблему), то от подрядчика нужно как можно лучше понять функциональные требования и как можно качественнее реализовать продукт. Agile в разработке помогает лучше понять и качественее делать продукт. Но ничего не делает с бизнес-рисками.
VK
Всем привет!
Меня зовут Виктор. Я CEO в стартапе, который принадлежит медиахолдингу.
У меня неплохой маркетинговый background. Недавно прошел тренинг PSM.
Могу рассказать, как мы масштабируем опыт agile в стартапе на медиахолдинг, в котором офлайновый бизнес (радио).
Очень интересно изучать опыт других. Узнал их фейсбука. #whois
Меня зовут Виктор. Я CEO в стартапе, который принадлежит медиахолдингу.
У меня неплохой маркетинговый background. Недавно прошел тренинг PSM.
Могу рассказать, как мы масштабируем опыт agile в стартапе на медиахолдинг, в котором офлайновый бизнес (радио).
Очень интересно изучать опыт других. Узнал их фейсбука. #whois
RK
Если заказчик хочет бизнес-риски переложить на разработчиков, то Agile тут не при чем — чтобы соглашаться на такое разработчики должны понимать в бизнесе лучше заказчика.
RK
Так и с контрактом — если бизнес-риски на заказчике, то в контракте не будет бизнес-метрик и "очковать" тут нечего — достаточно выбрать подрядчика с реальным опытом или правильно замотивировать, если подрядчик внутренний — программисты умеют программировать, а итерационная разработка это само по себе хорошо — чего тут очковать :)
RK
А вот если заказчик требует соблюдения бизнес-метрик в контракте, то разработка по agile отходит на второй план — подрядчик должен быть экспертом в бизнесе заказчика или вообще управление развитием бизнесом должно идти по agile
TM
Все так, однако, бизнес-риски заставляют заказчика менять требования (с пониманием здесь все ОК, просто за некое время требования эволюционировали), а это начинает влиять на разработчиков. Не всегда хорошо...
RK
Какие у бизнеса ожидания от разработчиков?
RK
Чтобы те запрограммировали что скажет бизнес или чтобы решили "какую-то проблему, что бы для этого не нужно было сделать"?