fin :)

https://twitter.com/totheralistair/status/471221317744984065

А с каких пор много рефпкторинга это плохо?)) Чище код же

речь не о том

И легче поддерживаемость

если ты точно знаешь что тебе надо, то пиши сразу и не рефактори.

алилуя:)

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

если ты точно знаешь что тебе надо, то пиши сразу и не рефактори.

Блин, ты тоже веришь в мифических заказчиков которые точно знают хоть что-то?

вообще просто Алистар под старость лет сошел с ума, как вы догадались )))

Или все же ты за цитату Сократа - я точно знаю только одно, что ничего не знаю?))

это не обязательно заказчик может быть

пример из интела

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

не надо тут рефакторить. не надо тут самоорганизации.

не надо тут аджайла

очень хорошо работает ватерфол

алилуйя

И никакого инкрементального дизайна )

тоже не надо

здесь не поспоришь :)

И никаких спринтов )

И даже юнит тесты в топку

ниче не надо. не не, тесты как раз надо

Можно одними приемочными тестами обойтись

чтобы спецификация сохранялась. но не юнит, а блэкбокс

старыми при чем :)

Имею в виду автотесты на вход / выход

Да

да, точно

любой программистский разговор всегда скатывается в рефакторинг

Алистер клевый, знатно троллит)

отож ))))

ща пацаны скажут пипец. пришли в группу по аждайлу а нам тут впаривают как ватерфол хорош ))))

А че плохого в ватерфоле, вот например если мы все стадии за неделю прошли? ;)

это неправильный ватерфол ))

А есть тут консультанты-1с?

Автоматизация бизнес процессов вот это все. У меня тут проект, где исполнитель продает ватерфолл, мне надо получше в контекст залезть

ща пацаны скажут пипец. пришли в группу по аждайлу а нам тут впаривают как ватерфол хорош ))))

Уточнить что он только для простых продуктов и норм)

Уточнить что он только для простых продуктов и норм)

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

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

Ага) Главное за простой мир киневина не выйти и все будет хорошо.

Ага) Главное за простой мир киневина не выйти и все будет хорошо.

+1

Что то переписка не соответствует теме группы))

А есть тут консультанты-1с?

не консультанты. но 1с

им реально по фану дебажить, что ли?)

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

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

Надо статью!

Может таки cost of delay перетрем? Как приоритизируете эпики,которые уже не во власти одного PO?

Считаем сколько бабок принесет Эпик и сами приоритезируем по бабкам

И информируем всех PO что вам жи бабки нужны

А если бабок не принесет, но риски снимет?

Или даст возможность потом на других эпиках заработать (enabler-epic)?

Снимет риски, этож тоже бабки, потенциальные , значит рассчитываем по формуле стоимость с весами как средневзвешенную добавляя больше в сторону что принесет, чем какие потенциальные риски снимет Про enabler-epic, берем время разработки этого эпика, берем время разработки следующего за ним, который невозможен без enabler-epic, берем его сумму в бабках. Делим эту сумму в бабках на время разработки и получаем кпд, аналогично делаем для других эпиков и выстраиваем по КПД

Часто грумите программный бэклог?

Грумите? Переведи пожалуйста :)

Оцениваете?

Ну типа того, оценка, уточнение, переосмысление.

Да, постоянно, иначе нельзя приоритезацию делать корректную. Другое дело, что команда оценивает позже, а оценку беклога полную делает РП, этого достаточно для приоритезации, а уже когда набирают на спринт, оценивают задачи разработчики

Заодно оценка беклога РП дает возможность сроки говорить когда та или иная фича докатиться до пользователей

С точностью до месяца

Более высокая точность после оценки разработчикамм )

РП сам все оценивает один?

Для грубой оценки для грубого планирования и выдачи сроков да

А потом вместе с командой оценивает уже точнее

Понятно.

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

Можно попросить ссылку или имя автора и название доклада?

автор я, название пошаговая инструкция по переходу на спринты

А есть тут консультанты-1с?

Есть

а есть у кого-нибудь опыт внедрения agile в отделе продаж?

есть смысл?

расскажите, пожалуйста, об опыте, негативном тоже

@MarinaSim расскажет, что смысл есть)

Всем добрый день!

добрый день

Опыт очень позитивный!

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

Недельные спринты первые пол года

@MarinaSim маркетинг у вас как независимый отдел (департамент и т.п.)? или он с кем-то что-то согласует из своих задач? не всегда удастся согласовать все возможное в рамках одного спринта, впрочем, ничего невозможного нет при правильных процессах. И какие элементы у маркетинга, если не секрет, укладываются в недельные спринты по маркетинговым кампаниям?

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

С маркетингом как раз все оч просто, похоже на разработку. А вот с продажами сложнее. Что если длина сделки пол года, как в таком случае определить инкремент?

В бэклоге не только цифры, а еще качественные показатели. Не важна длина сделки. Важно что в бэклоге.