Можно и для Digital ))

а про ремонт квартир. лет 5 назад PM в одной из крупных IT компаний, ярый сторонник Agile, рассказывал, как делал ремонт дома по Scrum. Стендапы с женой, короткие итерации, планирование и демо друг перед другом

Я так дом сейчас строю на даче! )))))

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

А у наших клиентов нет столько времени на это, они деньги зарабатывают , а все остальное делаем мы за 60 дней по готовым решениям

В сиысле по готовым?

Сорри, покажу один раз и все) это один из проектов

Антон , в смысле вот www. kvadrim.ru

👍🏻

Коллеги, а вот вопрос, который я много раз поднимал еще в группе gosagile-как считать стоимость проекта, если заказчик готов подписать (а госы только так и могут) исключительно в фикспрайс?

Пока внятных решений найти так и не удалось

#whois Антон. В недавнем прошлом работал с госструктурамм (силовой блок), с которыми умудрился реализовать несколько проектов только за счет agile в полный рост. Сейчас оказался в ортогональном мире - СберТех. :)

Anton, в такой ситуации имеет смысл договориться о том, что бюджет мы фиксируем, а scope — нет. Договариваетесь о каком-то минимальном объеме который в любом случае успеете сделать. И дальше делаете столько итераций сколько уложится в бюджет

#whois я Антон, product owner в небольшой команде единомышленников, собравшихся вокруг петабайта данных. Мы помним всё.

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

Вот это вот-сколько итераций успеем-это один из основных пунктов, которые выбегивают заказчика. Типа-ну да-кодите, пока бабки не кончатся. А если реально scope не зафиксить-то он станет бесконечным. Алексей, тут проблема именно в том, что "договариваетесь". Так с госами (и не только) не заработает.

Точнее заработает-сам так делал, но..... Это все договоренности на уровне слов и личногл доверия. А нужны понятные правила.

И вот че меня лично интересует-это практика именно оценки стоимости до начала проекта, но с фикспрайсом, который пойдет по agile... Может это вообще невозможно...?

Если заказчик хочет фикспрайс и фиксированный объем работ, значит он не готов риски брать на себя, а все риски взваливает на подрядчика. Единственный вариант тут - конвертировать риски в стоимость. Все риски на подрядчике - больше цена, чтобы в случае чего было чем питать проект

#whois Коллеги, я работаю в петербургской компании LPTracker, руковожу разработкой нового сервиса в компании — умного конструктора сайтов, пытаюсь выстроить процессы разработки по Scrum. На этом пути возникает много вопросов, хочется их задать знающим людям

Alexey Anisimov это факт )))) а теперь если через призму контрактации с госами по 44-фз взглянуть, то получается очень странная картина. Коррче-кто то из гуру аджайл может сказать-как считать стлимость контракта? В ватерфоле вон сколько накручено (типа Cocomo 2)

Alexey Anisimov это факт )))) а теперь если через призму контрактации с госами по 44-фз взглянуть, то получается очень странная картина. Коррче-кто то из гуру аджайл может сказать-как считать стлимость контракта? В ватерфоле вон сколько накручено (типа Cocomo 2)

Антох, нельзя посчитать то, что не существует в природе даже на уровне законченного осмысления. То, для чего придуман скрам - это вещь которой нет в природе, аналогов нет, ничего нет кроме продуктовой гипотезы, о том ,что это возможно будет так. Если у тебя продукт не такой, то и скрам нафиг не нужен, иначе это будет карго-культ. Возвращаясь к контрактованию, тут либо как ребята уже описали - у заказчика есть N денег и он готов их вложить в производство непонятной вещи беря на себя риски, но при этом получая полную прозрачность работы и вовлечение в результат. Либо никак. И даже 44ФЗ не при чем

Доброй ночи! Эксплуатирую неудачные и удачные agile решения вендоров в одном сотовом операторе) Специализируюсь на IN и VAS платформах

#whois Пешков Евгений, web-разработчик. Пока что в творческом отпуске.

Напиши в выходные в личку

#whois ▫️Какой у вас проект или где работаете? Руководитель группы разработки BI в Ahmad Tea Russia ▫️В чём вы специалист? SQL Server ▫️Чем можете быть интересны или полезны сообществу? Вопросами, идеями, предложениями, продвижением... )) ▫️Чем интересно сообщество вам? Темой 😊 ▫️Откуда вы? Москва ▫️Как узнали про группу? Пост @DenisIzmaylov в Facebook

👍

#whois 1. Портфель проектов, в который входят веб-сайты, мобильное приложение, мобильный сайт, веб-платформа, ретейл терминалы самообслуживания и информационные экраны. Работаю в "Лиге Ставок". 2. Специалист по букмекерской тематике, в части её реализации в онлайне (сайты и мобильное направление) и ретейлу. Как разработка продуктов с нуля, так и интеграция мировых вендоров с их продуктами. 3. Могу поделиться опытом ведения проектов в этом редком для российского бизнеса направлении, некоторыми Best practice. 4. Интересно узнать о ведении проектов в различных отраслях, об их специфике. Узнать свежие тенденции и лучшие практики. 5. Москва 6. Пост на фейсбуке в ленте из сообщества одноимённого.

Ребята, раз уж тут все представляются - напишу несколько слов о себе: я директор "Института публичных выступлений" и разработала курс для моих клиентов, по ораторскому искусству и коммуникациям в Agile. Задачи ставил клиент: презентовать сложное простым языком, объяснить быстро, не теряя много времени, объяснить так, чтобы все поняли одинаково, найти новое решение, когда уже все перебрали. Проводила тренинг несколько раз, для вузов и стартаперов. Это для тех, кто уже работает в стиле Agile, и заметен пробел именно в коммуникациях, то есть недопонимание тормозит работу группы.

#whois HPMO в разработчике мобильных игр ZeptoLab

#whois Всем привет. Аналитик + РП (в прошлом . Net разработчик) в ГК Астерос. Занимаемся разработкой собственного продукта для автоматизации бизнес-процессов. Во многих командах с разной степенью эффективности поработал по Agile/Scrum.

#whois привет. РП в разработке мобильных приложений (в последнее время создаем полноценный проектный офис в компании). Внедряем процессы, следим за эффективностью, помогаю своим коллегам с решением проектных вопросов. О группе узнал из поста в FB

#whois всем привет! РП в разработке saas сервиса, доцент, преподаю методологии анализа, проектирования и разработки в вузе.

куратор стартап-проектов Казанского ИТ-парка. Изучаем Agile в маркетинге и продажах.

#whois категорически приветствую! DevManager проектов разработки авиационных систем и ПО для авионики. Стараемся менять подходы в очень консервативном окружении.

Всем привет! Я Agile sales&marketing coach. Мы с нашей командой развиваем в России это направление, переводим и издаем книги, приглашаем мировых экспертов и конечно сами создаем Agile команды продавцов и маркетологов :-)

#whois категорически приветствую! DevManager проектов разработки авиационных систем и ПО для авионики. Стараемся менять подходы в очень консервативном окружении.

На SAFe смотрели? многие software+hardware компании его выбирают

#whois Привет! Сейчас я разрабатываю платёжный агрегатор. Фанат TDD, XP практик и чистого кода при котором скорость разработки просто улетает. Помимо разработки помогаю менять команде образ мышления в сторону Agile-ценностей. Мы в прошлом банк, тяжеловато идёт. Рад буду поотвечать на на процессные темы.

Сейчас сам хочу с SAF разобраться (смотрел и сайты и вебинары), пока выглядит многообещающе, но реальных кейсов (из отечественных) компаний я не нашёл

На SAFe смотрели? многие software+hardware компании его выбирают

Отличный "фон" у аватарки

#whois Привет, я руководитель отдела разработок регионального партнера сети Консультант Плюс, руковожу разработкой внутренней системы учета (1С, Rails, Angular), хочу заставить 1Сников работать по Scrum :)

#whois Привет, я руководитель отдела разработок регионального партнера сети Консультант Плюс, руковожу разработкой внутренней системы учета (1С, Rails, Angular), хочу заставить 1Сников работать по Scrum :)

Почему "заставить"? :-)

Есть для них определенный надрыв, особенно в области инженерных практик)

@onedevlink я частно слышал от разработчиков, что TDD в начале разработки замедляет процесс: не только код нужно писать но и тесты. Как по вашему опыту, какова область применимости TDD?

Можно ещё у ребят в @qa_ru спросить

TDD - долго на старте, но потом это ускоряет сильно разработку.

Есть для них определенный надрыв, особенно в области инженерных практик)

А при чем здесь "инженерные" практики? ;)

tdd на старте сложно тем, кто его начинает применять

@onedevlink я частно слышал от разработчиков, что TDD в начале разработки замедляет процесс: не только код нужно писать но и тесты. Как по вашему опыту, какова область применимости TDD?

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

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

Можете сказать, какой у вас опыт разработки и ЯП?

Привет! Меня зовут Валерия, я HR, сейчас -тренер-эксперт компании МегаФон (Новосибирск). В недавнем прошлом - тренер Сбербанка, немножко не дожила до зеленого пояса бережливого производства, хотя по факту в бизнесе реализовывала проекты. Меня интересует очень практика работы групп по Agile и SCRUM. А консультировать я могу по тому, как происходят в группах коммуникации и что происходит с настроениями отдельных участников или группы в целом. В группу прошла по ссылке из Facebook #whois

Можете сказать, какой у вас опыт разработки и ЯП?

Уже лет 9, последние пару лет работал в банке пиля кошельковое решение. Для десктопа пишу на c#, веб - php.

Уже лет 9, последние пару лет работал в банке пиля кошельковое решение. Для десктопа пишу на c#, веб - php.

А сам tdd давно стали применять и что повлияло на решение?

скажите, а вендор 1С понимает как надо развивать платформу для TDD, BDD и прочего CI/CD? если да, то это будет прорыв. комьюнити 1С огромное по стране.

Пардон за оффтоп, а кроме как отключить нотификации никакой настройки нет? Counter все равно показывает число в трее

это плата за коллабарацию

А сам tdd давно стали применять и что повлияло на решение?

Те же пару лет назад. Решением было заценить новую практику, и я конкретно подсел.

Не ожидал такого дикого эффекта

скажите, а вендор 1С понимает как надо развивать платформу для TDD, BDD и прочего CI/CD? если да, то это будет прорыв. комьюнити 1С огромное по стране.

Ну есть кое-какие зачатки для тестирования. Однако есть и инструменты от community, даже реализация Gherkin. Есть команды которые используют Jenkins чтобы прогонять тесты при обнолвении состояния хранилища (недо-VCS для конфигураций 1С).

Не ожидал такого дикого эффекта

Я начал применять tdd для проекта под ms azure, через некоторое время один из программистов начал утверждать, что "дизайн ему подсказывают тесты" и что он чуть ли не говорит с ними - так что да, эффект сильный получился

Да, все так.

Антох, нельзя посчитать то, что не существует в природе даже на уровне законченного осмысления. То, для чего придуман скрам - это вещь которой нет в природе, аналогов нет, ничего нет кроме продуктовой гипотезы, о том ,что это возможно будет так. Если у тебя продукт не такой, то и скрам нафиг не нужен, иначе это будет карго-культ. Возвращаясь к контрактованию, тут либо как ребята уже описали - у заказчика есть N денег и он готов их вложить в производство непонятной вещи беря на себя риски, но при этом получая полную прозрачность работы и вовлечение в результат. Либо никак. И даже 44ФЗ не при чем

Возвращаясь к вопросу Антона: бизнесу важно получить ответы на вопросы - сколько это будет стоить и когда это будет готово? А весь наш agile не дает возможность ответить на эти вопросы, он лишь гарантирует что процесс будет прозрачным и практически\теоретически более выгодным чем водопадная модель с точки зрения стоимости разработки. То есть эти характеристики должны перевесить в беседе контракт с фиксед скоупом работ и ценой. Что выглядит почти нереальным.

#whois тестировщик из Германии. Учусь сам, учу других.

Возвращаясь к вопросу Антона: бизнесу важно получить ответы на вопросы - сколько это будет стоить и когда это будет готово? А весь наш agile не дает возможность ответить на эти вопросы, он лишь гарантирует что процесс будет прозрачным и практически\теоретически более выгодным чем водопадная модель с точки зрения стоимости разработки. То есть эти характеристики должны перевесить в беседе контракт с фиксед скоупом работ и ценой. Что выглядит почти нереальным.

есть уже нормальные подходы к agile-контрактам. где и скоуп отпускаем и заказчик не очкует.

поподробнее бы

Иван, на одной вашей конференции был на Сахарова, там не раскрыли этот вопрос

Про "скоуп и очкование" какой-то дивный эльфийский мир

Вот да, не очень понятно что такое “нормальные подходы к agile-контрактом”.

Про "скоуп и очкование" - тут либо заказчик бизнес-риски берет на себя или хочет переложить их на подрядчика. Если бизнес-риски на заказчике (продукт не выстрелит, не закроет проблему), то от подрядчика нужно как можно лучше понять функциональные требования и как можно качественнее реализовать продукт. Agile в разработке помогает лучше понять и качественее делать продукт. Но ничего не делает с бизнес-рисками.

Всем привет! Меня зовут Виктор. Я CEO в стартапе, который принадлежит медиахолдингу. У меня неплохой маркетинговый background. Недавно прошел тренинг PSM. Могу рассказать, как мы масштабируем опыт agile в стартапе на медиахолдинг, в котором офлайновый бизнес (радио). Очень интересно изучать опыт других. Узнал их фейсбука. #whois

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

Так и с контрактом — если бизнес-риски на заказчике, то в контракте не будет бизнес-метрик и "очковать" тут нечего — достаточно выбрать подрядчика с реальным опытом или правильно замотивировать, если подрядчик внутренний — программисты умеют программировать, а итерационная разработка это само по себе хорошо — чего тут очковать :)

А вот если заказчик требует соблюдения бизнес-метрик в контракте, то разработка по agile отходит на второй план — подрядчик должен быть экспертом в бизнесе заказчика или вообще управление развитием бизнесом должно идти по agile

Все так, однако, бизнес-риски заставляют заказчика менять требования (с пониманием здесь все ОК, просто за некое время требования эволюционировали), а это начинает влиять на разработчиков. Не всегда хорошо...

Какие у бизнеса ожидания от разработчиков?

Чтобы те запрограммировали что скажет бизнес или чтобы решили "какую-то проблему, что бы для этого не нужно было сделать"?