Можно рассматривать «planning poker» Scrum, как идентификацию и оценку риском методом методом экспертной оценки и прецедентов.
Тогда все становится на свои места :)
В целом же я не вижу никакого смысла в «формальном описании» которое сложнее реализации. Реализация задачи может считаться формальным описанием?
Извиняюсь, что сломаю ваше мнение о «невозможно» и "… дороже чем..".
Логика тут немного другая. Есть бюджет проекта, скажем 100 денег.
Есть два варианта решения:
10 денег — аналитика «тяп-ляп»
20 денег — срач/менеджемент по ходу проекта
60 денег — ваять-кодить решение (пару-тройку раз переделав)
10 денег — тестить
или
40 денег — аналитика «формально корректная»
10 денег — срач/менеджемент по ходу проекта
30 денег — ваять-кодить решение (сделано сразу верно)
20 денег — тестить
Так получилость, что у меня было штук 6 похожих проектов сделанные этими двумя разными подходами и мог сравнить метрики проектов.
Фактически получалась «перемена мест слагаемых» :)
Выбор решения состоит в балансе между знанием предметной области и предоставлением MVP.
В большинстве случаев этот выбор — проблема психологии. Клиенту все равно «куда говорить» — в draft проекта или «формальную бумажку», главное что бы его слушали и записывали. А в код или UML- ему пофиг. Главое что бы к моменту Х все было готово.
Я Вас понимаю. Сам почти год «забил» на все и отдыхал мозгом.
выдержав постоянно нарастающего стресса, ощущения что из тебя пытаются сделать автомат, которому на вход подали задачу, на выход ожидают получить точный и безошибочный временной прогноз
Посмотрите на это следующим образом: На двигателе Ролс Ройса в графе мощность двигателя написан «Достаточная» :)
Ваша «мощность» — Достаточная :) А если от Вас ожидают «минута в минуту» точность оценки, то просто выдайте «достаточную», Если хотят — больше, то возьмите попкорн, откиньтесь на спинку и пусть Вам предоставят технологию, как оценить «минута в минуту» :)
Идиоты не истребимы :)
Менеджеры ведь тоже не идиоты. Они же уже подписались на замену лампочки за $5.
Это как раз и есть «идиоты за 5$». За чей счет банкет, если ценник 50$? За счет разработчика? Компании?
Подписался за 5, а стоит 50? Ну так выплати из своего кармана остальные 45 :)
А что бы такого не было, и прописали процессы типа «мойте руки после туалета....», что бы не было "… а то г@вн# в вентилятор снег в башка попадет, совсем мертвый будешь".
Так что любая UserStory «уходит корнями» в то, что видит пользователь. Любая. А вот размер у них может быть совсем не таким, как того хотят менеджеры, но вот это вот — уже таки их проблемы
Это навык менджера «считать косты». Если они игнорирует этот этап, или ему не нравится «счет» — уволить его нафиг.
А я наблюдаю, как PO считают за юзер-стори только видимый пользователю функционал. Если таска не начинается с слов «Я как пользователь хочу ...», то это не юзер-стори. Добавить поле ввода и кнопку, которые затрагивают всё, от БД до UI становится юзер-стори только из-за UI, а все слои ниже, это вам технические задачи, которые как бы не совсем юзер-стори.
Есть такая штука, как «декомпозиция задач». И есть рекомендация «делать задачи короткими». Из практики 8...24 часа, иначе просто теряется контроль.
Если команда разработки нарежет/декомпозирует UserStory «Все Хорошо» на перечень измеримых и вменяемых задач — значит так надо. Согласен менеджер с этим подходом или нет — это только проблема менеджера.
и менеджеров в Agile вроде как не предусмотрено — но вся беда в том, что внедряют-то зачастую именно они
Есть Product Owner, с ОБЯЗАННОСТЬЮ сформировать backlog спринта.
Этого более чем достаточно. Если он не в состоянии этого сделать, то утопить такого менеджера, что бы не мучался…
Команда, в данном случае, выступает как инструмент оценки для product owner-а
Притом, что исходный поинт абсолютно верный — Скрам действительно формализует процесс разработки.
Любой SDLC формализует и пытается его сделать предсказуемым для бизнеса. От этого никуда.
Нужно просто одновременно с внедрением Скрама массово набирать тех, кому нравится «работать разработчиками»
Это не так, поскольку не запрещает делать ПО вам удобным (экономически обоснованным) способом.
Если карго-культ, то да… «это не нравится… постепенно переводить на....»
в компанию нанят скрам-мастер, все разработки были переведены в TargetProcess. С точки зрения менеджмента это было сделано для того, чтобы улучшить скорость и качество разработки, а так-же получить понимание, на что тратят время разработчики.
Кто-то сильно «солгал» когда запускал этот проект :) С таким же успехом могли менять коврики у мышей с синих на фиолетовые. Менеджеры — безграмотные дауны… увы.
Тут, как водится, сразу возникло недопонимание между менеджментом и разработчиками. Как перенос проекта с Symfony 2.6 на Symfony 3.0 может занять почти неделю времени разработчика, ведь это просто обновление с одной версии на другую?
Мы начинаем ценить работу других людей, только когда начинаем делать ее сами :)
Знаешь как сделать быстрее — давай знания. Если не знаешь — заткнись и не мешай. Менеджеры — идиоты… увы.
Результатом внедрения такой методологии послужило то, что энтузиазм разработчиков поутих. Стали выполняться только задачи (User Story), приходящие от менеджеров, ни на какую незаметную, но полезную деятельности времени у разработчиков оставаться не стало. Доходило до того, что при нахождении бага где-то на продакшне разработчики не могли его чинить, т.к. на это требуется задача, чтобы списывать туда время. Да и сами разработчики были завалены своими задачами.
А какие претензии к разработке? заказал задачи — получите задачи.
Удивляет, что есть технологические задачи?
Задачам стали присваивать приоритеты. Менеджеры начали конфликтовать между собой, пытаясь присвоить своей userStory высший приоритет, т.к. у них обязательства перед заказчиками и никого не волнует занятость разработчиков.
См начало: Кто-то сильно «солгал» когда запускал этот проект, поскольку хотел «уделать» своих конкурентов :)
Что и требовалось доказать: мы менеджеры безграмотные-дауны-имибицилы перегрыземся, между собой потому что не можем поуправлять между собой. А так как мы менеджеры-идиоты «все в белом», то мы еще и г#вн@ в вентилятор накидаем, что бы всем было не скучно…
Скрам, к тому что вы описали не имеет ровным счетом никакого отношения. Это просто безграмотная команда менеджеров, и с любым инструментом управления, получился бы точно такой-же п… ц.
То, что разработчики делают оттуда ноги — это самое разумное что они могут сделать, после того как доедят свой попкорн. увы.
Можно, было бы, сделать аудит процессов и привести систему в порядок, но это из разряда фантастики.
Сначала спросил у разработчиков, сколько займет реализация, мне сказали месяц. Пообещал клиенту «через пол года». Уже год прошел, где?! Что мне отвечать клиенту?
А вопрос «когда сможете сделать и представить Клиенту?» задавался? Если нет — то в чем претензии? Сам пообещал «через пол-года» сам сделал :)
Девять женщин за месяц не родят одного ребенка :)
или убирай фичи, или ищи ресурсы в следущем объеме или объясняй клиенту, что ты солгал…
В противном случае: «мы постараемся» трактуется как «вы же кровью подписались! вы виноваты», а у Клиента срабатывают бизнес риски.
Да и обычно «нужно постаряться» идет лично от продажника, ибо ему процент капнет «сейчас», как раз когда завезли новые айФоны :))
Не очень понимаю, почему продажник продал «Angular»? По идее его задача принести в «клювике» Клиент ожидаете получить XYZ. Сколько стоит?
Какое его его дело как это будет сделано: кодом на Angular или хрустальный шар натрут кровью младенца в лунное затмение если это в рамках закона?
То, что вы говорите сути не меняет. Вы говорите о желании осознанно принимать решения куда тратить ваши деньги и желательно получать отчет, на что они были потрачены. Это похвальное стремление.
Но вы должи понимать, что от общественных институтов, на которые «скидываются все» уйти не получится. Медицина, армия, суды, гос управление. Вы не можете у себя во дворе сделать «аццкую фиговину», хотя бы потому что на это нужно работа десятков тысяч людей и годы фундаментальных исследований и только вашей жизни не хватит. Вам придется договариваться с кем-то.
Текущие институты государства — это «значения по умолчанию». Механизмы конфига этих значений и бизнес-логики — это отдельная тема :)
Вы начали прохождения квеста с уровня «Очень сложно» :))
В любом случае, профит вы с них можете поиметь :)
Например, родится ребенок, его нужно кормить, обувать, учить. А эти услуги его родители будут покупать у вас. Потом вырастет и будет служить в армии и защищать вас от врагов.
С безработными примерно тоже самое — дать ему денег, иначе он будет вам «кирпич продавать» в подворотне не потому что злой, а потому что кушать хочет :) Денег вы все равно лишитесь, только с лишним отверстием в теле или нет.
С пенсионным фондом примерно такая-же штука.
Правда это в Самой Лучшей Стране, гда нас не было и не будет :)
Вы как нибудь постройте финансовую модель ИТ компании на года 3 минимум, вы сильно удивитесь цифрам конечным. начиная от амортизации железа в 3 года, обучения сотрудников в течении года… двух как минимум и загрузкой сотрудиков на 80..90%. При рентабельности в 30% компания к конце второго года начинает выходить в 0.
Не стоит считать деньги в чужом кармане… ошибетесь :)
Теперь, когда срок сократился до пяти календарных дней,
…
коэффициент x5, может больше, но точно меньше x10
Т.е час работы аналитика ВА (при созвоне рассказываю + писать DoD с моим ревью задачи + ...) порождает примерно 5..10 часов разработки +ревью +QA?
А можно табличку «В таблице указано количество дней, в течение которых задача находилась на каждом этапе разработки. » не в днях, а человеко-часах глянуть?
В проектах что я видел, в случае проблем, выяснялось, что «экономия» часа работы BA порождало проблемы на ~8...16 часов в лучшем случае. Худшее пока что я видел — это порядка 80 часов.
Прочие метрики — нормальные «здоровые» :)
С точки зрения итеративной разработки такая упреждающая разработка провоцирует кучу ненужных проблем, и с кодом в том числе. У вас, по идее, провоцируется осознанно риск реализация не подтвержденных задач, поскольку Клиент еще не принял текущую итерацию и, дополнительно, может перепланировать следующую. Например отказать от уже сделанной «заранее задачи». Это провоцирует бизнес-риск: за работу заплачено, но она не продана.
Если я верно понимаю, обработка этого риска будет Вашей заботой?
При такой проблеме, предпочитаю дать людям книжку — пусть учаться на смежном :) через пару итераций — начнет окупаться.
Но потом всплыла задача которая была ошибочно оценена.
Рискну предположить, что это проистекает из:
DoD пишет тестировщик и я его проверяю.
Есть мнение, что если буду писать DoD сам, то тестироваться задачи будут только по моим DoD и никак иначе, что увеличит вероятность попадания ошибки на прод.
Честно говоря, не видел такой проблемы. Правильные методологии тестирования не пропускают такие ошибки. Обычно QA от 3 лет опыта знает их.
Для больших задач я при созвоне рассказываю как пользователи будут это использовать, но это не является исчерпывающим критерием приемки.
Нет формализованных критерием приемки от Заказчика и каскадом проблемы аналитика->планирование->реализация->тестирование-> показ/приемка.
Было бы интересно узнать пару эмпирических метрик: сколько в среднем стоит час ошибки или «экономии» в аналике и архитектуре?
«Экономия» — это изначально не сделанная работа, но которую потом все равно пришлось делать.
Цена — сколько работы было сделано «не корректно» по всей цепочке.
Команда сама приходит к мысли что им проще жилось бы с какой-то технологией/средством, они мне об этом говорят и обосновывают свою позицию. Если убеждают (обычно убеждают), то мы начинаем её использовать.
По идее это сугубо дело команды, а не кого-то со стороны. Хотя с точки зрения бизнес-рисков это имеет смысл.
Если то что они хотят поменять укладывается условно в 1 день, то я просто принимаю это решение.
…
Если же надо к примеру на неделю остановить процесс и всё переписать, то тут я более подробно анализирую что именно это нам даст и иду с этими данными к бизнес заказчику.
Странно. А заказчику эти подробности зачем? И почему остановить процесс? просто задачи помещаются в спринт и процесс идет дальше своим ходом.
По идее вмешиваться в спринт — не лучшая идея.Максимум что рекомендуется делать, это выкинуть задачу из спринта.
Если уж настолько и срочно меняется в течении спринта набор задач, то разумнее остановить спринт и начать заново, но предпочтительней — завершить текущий.
а) программист может быстро успеть решить все таски в текущем спринте и приступить к следующему, что приведет что часть его задач будет долго ждать релиза.
По идее если программист закроет свои таски в спринте, то маскимум, что он может сделать, это взять чужие таски из этого спринта. Если он бежит впереди паровоза, то это странная штука… честно говоря, не помню такого ни в одном фреймвоке.
б) программист может сильно затянуть с решением своих задач, которые критически выкатить в ближайший релиз, что может привести к увеличению срока всех остальных задач
По идее спринт не может начаться, если все не согласятся со сроками преварительно обсудив методы решения. Своеобразная перекрестная проверка. Если не уложился, то фичу можно просто перенести в следующий спринт.
Спринт то планируется так, что бы объем задач в спринте не более чем доступно ресурсов на спринт. Меньше — можно. А у вас как-то два правила трактуются своеобразно.
Тогда все становится на свои места :)
Извиняюсь, что сломаю ваше мнение о «невозможно» и "… дороже чем..".
Логика тут немного другая. Есть бюджет проекта, скажем 100 денег.
Есть два варианта решения:
или
Так получилость, что у меня было штук 6 похожих проектов сделанные этими двумя разными подходами и мог сравнить метрики проектов.
Фактически получалась «перемена мест слагаемых» :)
Выбор решения состоит в балансе между знанием предметной области и предоставлением MVP.
В большинстве случаев этот выбор — проблема психологии. Клиенту все равно «куда говорить» — в draft проекта или «формальную бумажку», главное что бы его слушали и записывали. А в код или UML- ему пофиг. Главое что бы к моменту Х все было готово.
Ищу себе что-то подобное на i7
Посмотрите на это следующим образом: На двигателе Ролс Ройса в графе мощность двигателя написан «Достаточная» :)
Ваша «мощность» — Достаточная :) А если от Вас ожидают «минута в минуту» точность оценки, то просто выдайте «достаточную», Если хотят — больше, то возьмите попкорн, откиньтесь на спинку и пусть Вам предоставят технологию, как оценить «минута в минуту» :)
Идиоты не истребимы :)
Это как раз и есть «идиоты за 5$». За чей счет банкет, если ценник 50$? За счет разработчика? Компании?
Подписался за 5, а стоит 50? Ну так выплати из своего кармана остальные 45 :)
А что бы такого не было, и прописали процессы типа «мойте руки после туалета....», что бы не было "… а то
г@вн# в вентиляторснег в башка попадет, совсем мертвый будешь".Это навык менджера «считать косты». Если они игнорирует этот этап, или ему не нравится «счет» — уволить его нафиг.
Есть такая штука, как «декомпозиция задач». И есть рекомендация «делать задачи короткими». Из практики 8...24 часа, иначе просто теряется контроль.
Если команда разработки нарежет/декомпозирует UserStory «Все Хорошо» на перечень измеримых и вменяемых задач — значит так надо. Согласен менеджер с этим подходом или нет — это только проблема менеджера.
Есть Product Owner, с ОБЯЗАННОСТЬЮ сформировать backlog спринта.
Этого более чем достаточно. Если он не в состоянии этого сделать, то утопить такого менеджера, что бы не мучался…
Команда, в данном случае, выступает как инструмент оценки для product owner-а
Любой SDLC формализует и пытается его сделать предсказуемым для бизнеса. От этого никуда.
Это не так, поскольку не запрещает делать ПО вам удобным (экономически обоснованным) способом.
Если карго-культ, то да… «это не нравится… постепенно переводить на....»
Кто-то сильно «солгал» когда запускал этот проект :) С таким же успехом могли менять коврики у мышей с синих на фиолетовые. Менеджеры — безграмотные дауны… увы.
Мы начинаем ценить работу других людей, только когда начинаем делать ее сами :)
Знаешь как сделать быстрее — давай знания. Если не знаешь — заткнись и не мешай. Менеджеры — идиоты… увы.
А какие претензии к разработке? заказал задачи — получите задачи.
Удивляет, что есть технологические задачи?
См начало: Кто-то сильно «солгал» когда запускал этот проект, поскольку хотел «уделать» своих конкурентов :)
Что и требовалось доказать: мы менеджеры безграмотные-дауны-имибицилы перегрыземся, между собой потому что не можем поуправлять между собой. А так как мы менеджеры-идиоты «все в белом», то мы еще и г#вн@ в вентилятор накидаем, что бы всем было не скучно…
Скрам, к тому что вы описали не имеет ровным счетом никакого отношения. Это просто безграмотная команда менеджеров, и с любым инструментом управления, получился бы точно такой-же п… ц.
То, что разработчики делают оттуда ноги — это самое разумное что они могут сделать, после того как доедят свой попкорн. увы.
Можно, было бы, сделать аудит процессов и привести систему в порядок, но это из разряда фантастики.
А вопрос «когда сможете сделать и представить Клиенту?» задавался? Если нет — то в чем претензии? Сам пообещал «через пол-года» сам сделал :)
или убирай фичи, или ищи ресурсы в следущем объеме или объясняй клиенту, что ты солгал…
В противном случае: «мы постараемся» трактуется как «вы же кровью подписались! вы виноваты», а у Клиента срабатывают бизнес риски.
Да и обычно «нужно постаряться» идет лично от продажника, ибо ему процент капнет «сейчас», как раз когда завезли новые айФоны :))
Какое его его дело как это будет сделано: кодом на Angular или хрустальный шар натрут кровью младенца в лунное затмение если это в рамках закона?
Но вы должи понимать, что от общественных институтов, на которые «скидываются все» уйти не получится. Медицина, армия, суды, гос управление. Вы не можете у себя во дворе сделать «аццкую фиговину», хотя бы потому что на это нужно работа десятков тысяч людей и годы фундаментальных исследований и только вашей жизни не хватит. Вам придется договариваться с кем-то.
Текущие институты государства — это «значения по умолчанию». Механизмы конфига этих значений и бизнес-логики — это отдельная тема :)
Вы начали прохождения квеста с уровня «Очень сложно» :))
Например, родится ребенок, его нужно кормить, обувать, учить. А эти услуги его родители будут покупать у вас. Потом вырастет и будет служить в армии и защищать вас от врагов.
С безработными примерно тоже самое — дать ему денег, иначе он будет вам «кирпич продавать» в подворотне не потому что злой, а потому что кушать хочет :) Денег вы все равно лишитесь, только с лишним отверстием в теле или нет.
С пенсионным фондом примерно такая-же штука.
Правда это в Самой Лучшей Стране, гда нас не было и не будет :)
Не стоит считать деньги в чужом кармане… ошибетесь :)
Т.е час работы аналитика ВА (при созвоне рассказываю + писать DoD с моим ревью задачи + ...) порождает примерно 5..10 часов разработки +ревью +QA?
А можно табличку «В таблице указано количество дней, в течение которых задача находилась на каждом этапе разработки. » не в днях, а человеко-часах глянуть?
В проектах что я видел, в случае проблем, выяснялось, что «экономия» часа работы BA порождало проблемы на ~8...16 часов в лучшем случае. Худшее пока что я видел — это порядка 80 часов.
Прочие метрики — нормальные «здоровые» :)
Если я верно понимаю, обработка этого риска будет Вашей заботой?
При такой проблеме, предпочитаю дать людям книжку — пусть учаться на смежном :) через пару итераций — начнет окупаться.
Рискну предположить, что это проистекает из:
Честно говоря, не видел такой проблемы. Правильные методологии тестирования не пропускают такие ошибки. Обычно QA от 3 лет опыта знает их.
Нет формализованных критерием приемки от Заказчика и каскадом проблемы аналитика->планирование->реализация->тестирование-> показ/приемка.
Было бы интересно узнать пару эмпирических метрик: сколько в среднем стоит час ошибки или «экономии» в аналике и архитектуре?
«Экономия» — это изначально не сделанная работа, но которую потом все равно пришлось делать.
Цена — сколько работы было сделано «не корректно» по всей цепочке.
Я не рассматриваю ваш процесс как Scrum.
По идее это сугубо дело команды, а не кого-то со стороны. Хотя с точки зрения бизнес-рисков это имеет смысл.
Странно. А заказчику эти подробности зачем? И почему остановить процесс? просто задачи помещаются в спринт и процесс идет дальше своим ходом.
По идее вмешиваться в спринт — не лучшая идея.Максимум что рекомендуется делать, это выкинуть задачу из спринта.
Если уж настолько и срочно меняется в течении спринта набор задач, то разумнее остановить спринт и начать заново, но предпочтительней — завершить текущий.
По идее если программист закроет свои таски в спринте, то маскимум, что он может сделать, это взять чужие таски из этого спринта. Если он бежит впереди паровоза, то это странная штука… честно говоря, не помню такого ни в одном фреймвоке.
По идее спринт не может начаться, если все не согласятся со сроками преварительно обсудив методы решения. Своеобразная перекрестная проверка. Если не уложился, то фичу можно просто перенести в следующий спринт.
Спринт то планируется так, что бы объем задач в спринте не более чем доступно ресурсов на спринт. Меньше — можно. А у вас как-то два правила трактуются своеобразно.