Боюсь, вы путаете приоритеты и оценку по времени.
Бывает что задача на 15 минут, но сделать её надо вотпрямщас, а бывает что месячный трип по мозгу заказчика задачи может быть в целом несрочным. Равно как и наоборот.
В любом случае оценивать мелочевку смысла не имеет — имеет смысл делать её сразу же пачкой.
А да, еще есть задачи-детонаторы, выполняемые например в режиме «сделать первую версию — а там посмотрим» и/или с пометкой «уточнить требования».
Ну у вас же своя голова на плечах есть? Вы же можете визуально отличить тапок от молотка, а масло от бетонной стены, верно?
Я не агитирую за скрам, поверьте, нет. Я лишь говорю что скрам — это инструмент, все холивары вокруг которого рождаются от того, что натянуть его пытаются туда, куда он не налазиет. И делают это всегда конкретные люди, которые, видимо, не отличают тапок от молотка.
В то же время, я не исключаю что для некоторых инструментов множество случаев, где их можно успешно применить — пустое ;)
Теоретически да. Практически — такой подход переворачивает в голове разработчика процесс оценки с попытки определить объем работ по задаче и проанализировать риски на «набрать себе лукошко задач и разгребаться с ними». Вы можете поделить время до дедлайна разделив кол-во дней в часах на кол-во задач и получить нужную вам (а не разработчику) оценку. Разработчик (как и любой человек) не способен к быстрой оценке объемов работы. Однако оценивалка в режиме «успею-не успею» работает у людей куда лучше. Рекомендую попробовать.
Оценивать задачу путем вопроса «сколько это займет времени?» — ущербный подход.
Гораздо более хороший подход — Due Date. Т.е. «сколько ты успеешь к такому-то времени?». На практике эта методика оценки ведет к менее частым срывам сроков. Не очень понятно зачем скрам-мастерам требуется знать сколько времени уйдет на каждую отдельную задачу. Гораздо важнее знать что и к какому сроку человек успеет сделать. Если на то пошло, то от этого и надо плясать, а не выдавливать из разработчиков человеко-часы, играя на их неспособности к адекватной оценке и риск-анализу за 5 минут в голове.
Все равно что пытаться выдавить из токаря на станке оценку того, сколько времени он будет точить одну болванку. Он не может сказать. Зато может сказать сколько болванок он сделает к следующему понедельнику, если вы прямо сейчас от него отлупитесь.
К тому же, на сколько я понмю, в скраме же нет «времени», есть же «поинты» и во всех книжках одно время талдычили что поинты != время, и вообще оценка сравнительная, чтобы определить что сложнее, а что легче.
Ну вот есть грамотный способ — через статусы в JIRA например. И неграмотный — устанавливая людям на компьютеры тайм-трекер или (о боги, в 2017м-то году!) заставляя репортить время вручную.
Именно об этом я и сказал когда упомянул UpWork. Подойдет так же Paymo, TimeManiac, или ваш любимый тайм-трекер. Просто прелесть UpWork-подхода в том, что он устанавливает прямую (прямее некуда) взаимосвязь между потраченным временем и деньгами. Это порой сильно меняет отношения.
Когда я столкнулся с такой задачей — то набросал на WPF дивный инструмент для разбиения проекта на подзадачи (Work Breakdown Structure это называется в некоторых источниках), которым бил целые проекты на задачи вплоть до «добавить такой-то файл» (попутно я собирал потихоньку собственную «библиотеку элементарных задач» с хорошо известными оценками), которые оценивались PERT-ом с точностью до 10 минут.
В итоге получался excel-файл на потеху заказчику, в котором содержалось 400-600 мелких задач, складывающихся в недели и месяцы разработки. С таковым заказчику очень трудно аргументированно спорить, но оценка на сферическую в вакууме разработку получается дюже точной (в рамках оценок точности PERT-а), да и детальный план что делать — вот он вот. Хоть в JIRA выливай. Бонусом идет проектирование на ранних этапах.
Как водится, у подобного подхода есть одна сложность — это ж надо сидеть и работать. Оценка делается напряженным умственным трудом группы людей на протяжении 2-3 дней. А менеджер работать не любит. Менеджер, как правило, поговорить любит.
Большие рефакторинги надо относить на отдельную стадию разработки и согласовывать с управленческим звеном/клиентами. Т.е. «пока нет срочных задач». Исследование фреймворков надо относить на отдельных людей вне команды работы над продуктом, а потом вливать эти знания обратно в команду через тех самых отдельных людей. Но это особая управленческая магия, которая многим не по зубам.
А в остальном lair прав. Agile/Scrum тут ни при чем. Как раз процесс — это отвертка и инструмент. Внедряющий должен хорошо понимать границы его применимости для данной конкретной команды разработчиков и для данного проекта. И лично я не раз отмечал в отечественных компаниях отношение к методологии управления как к волшебной таблетке, которая может починить разом все огрехи проекта, превратить разработчиков в добрых паладинов, а заказчиков — в белых котяток, ну а бонусом прекратить войну на ближнем востоке и предотвратить кризисы капитализма. Очевидно, оно так не работает. Любая методология управления в любой компании де-факто гибридна и претерпевает множество поправок на объективную реальность, а то и вообще собрана из кусков разных методологий. Кто не умеет этого признавать — получает по голове в долгосрочной перспективе и обречен ходить по граблям.
Статья хорошая, а вот вывод автор делает неверный.
На мой взгляд — причина неудачного внедрения в том, что новые цепочки процесса управления во-первых убили напрочь обратную связь между командой разработки и менеджментом (или даже клиентом), во-вторых, само желание «высокого начальства» внедрить Scrum — сиречь, проконтролировать то, что контролировать не нужно (время на разработку) — было ущербным.
Если честно, я вообще не понимаю трекинг времени внутри команды в штате компании. К'мон, ребята, как будто вы заплатите сотруднику меньше денег, узнав что он решил задачу за X времени, когда по вашему скромному мнению она должна занимать Y времени. Вы или выкупаете команду оптом, без вопросов выплачивая фиксированную сумму в месяц и берете на себя все риски неправильной постановки задач, рабочей среды, коммуникаций и оборудования, или, если вам хочется контролировать время — отправляете сотрудников на UpWork с почасовой оплатой (правда, она будет выше в силу накладных расходов разработчиков).
А организовывать грибной менеджмент на сотрудниках на зарплате с допросами почему эта кнопочка заняла столько времени попахивает излишней укомплектованностью управленческого звена кадрами (читай: менеджеров пора выпинывать с работы, или придумывать чем занять).
Хотя с другой стороны — если менеджеру хочется поговорить вместо работы, то рыночно-ориентированный программист никогда не откажет ему в такой возможности. Любой каприз, как говорится, за ваши деньги. Менеджер имеет полное право получить услуги психотерапии усилиями программиста и по его рейту.
Я бы и с радостью, но у меня пока что нет вменяемой информации на английском. Окромя XMLDOC и встроенного дока в конфиге.
У меня есть пара контактов людей в русскоязычном сообществе MS — им уже отписал.
Прошу прощения за некропостинг, но мне кажется, стоило бы упомянуть bulk-вставки/удаления/обновления и нюансы треканья состояния сущностей (что будет актуально для пользователей EF).
Я как бы и не говорю что «виновата скамейка», нет :) Просто с ANTLR-ом у меня был неудачный первый опыт (который во многом влияет на восприятие технологии как таковой) и как-то так получилось что я перешел на Coco\R и вот я здесь.
Commits on Apr 24, 2014
@bkiers
Added an ECMAScript grammar.
А я свою грамматику (на Coco\R) написал где-то в марте прошлого года. Время, беспощадная ж ты штука.
А вообще то ли у меня руки не оттуда, то ли лыжи не едут… Но в общем была у меня какая-то грамматика для ANTLR-а, из которой я сгенерил все необходимое, сделал playground для тестирования, нажал F5 — и получил зацикливание на простеньком js-файле. С тех пор я ANTLR-ом не пользуюсь.
Я на Roslyn и написал уже, собсно, ту самую версию, которая ушла в анабиоз (при том вот сразу через пару дней после выхода Roslyn-а — пришлось Microsoft.CodeAnalyzis выдирать с мясом из исходников). Так что мне не привыкать много разрабатывать :).
Там, на самом деле, затык в том, что в TS называется тайпинги. Т.е. придется переписывать интерфейсы для внешний библиотек, что руками делать долго и скучно.
А на самом деле, первоначальная версия транслятора внезапно хороша тем, что там есть парсер JavaScript, который превосходно разбирает даже минифицированный jquery в AST. Не спрашивайте зачем он там нужен, но он есть.
Бывает что задача на 15 минут, но сделать её надо вотпрямщас, а бывает что месячный трип по мозгу заказчика задачи может быть в целом несрочным. Равно как и наоборот.
В любом случае оценивать мелочевку смысла не имеет — имеет смысл делать её сразу же пачкой.
А да, еще есть задачи-детонаторы, выполняемые например в режиме «сделать первую версию — а там посмотрим» и/или с пометкой «уточнить требования».
Я не агитирую за скрам, поверьте, нет. Я лишь говорю что скрам — это инструмент, все холивары вокруг которого рождаются от того, что натянуть его пытаются туда, куда он не налазиет. И делают это всегда конкретные люди, которые, видимо, не отличают тапок от молотка.
В то же время, я не исключаю что для некоторых инструментов множество случаев, где их можно успешно применить — пустое ;)
Теоретически да. Практически — такой подход переворачивает в голове разработчика процесс оценки с попытки определить объем работ по задаче и проанализировать риски на «набрать себе лукошко задач и разгребаться с ними». Вы можете поделить время до дедлайна разделив кол-во дней в часах на кол-во задач и получить нужную вам (а не разработчику) оценку. Разработчик (как и любой человек) не способен к быстрой оценке объемов работы. Однако оценивалка в режиме «успею-не успею» работает у людей куда лучше. Рекомендую попробовать.
Гораздо более хороший подход — Due Date. Т.е. «сколько ты успеешь к такому-то времени?». На практике эта методика оценки ведет к менее частым срывам сроков. Не очень понятно зачем скрам-мастерам требуется знать сколько времени уйдет на каждую отдельную задачу. Гораздо важнее знать что и к какому сроку человек успеет сделать. Если на то пошло, то от этого и надо плясать, а не выдавливать из разработчиков человеко-часы, играя на их неспособности к адекватной оценке и риск-анализу за 5 минут в голове.
Все равно что пытаться выдавить из токаря на станке оценку того, сколько времени он будет точить одну болванку. Он не может сказать. Зато может сказать сколько болванок он сделает к следующему понедельнику, если вы прямо сейчас от него отлупитесь.
К тому же, на сколько я понмю, в скраме же нет «времени», есть же «поинты» и во всех книжках одно время талдычили что поинты != время, и вообще оценка сравнительная, чтобы определить что сложнее, а что легче.
Когда я столкнулся с такой задачей — то набросал на WPF дивный инструмент для разбиения проекта на подзадачи (Work Breakdown Structure это называется в некоторых источниках), которым бил целые проекты на задачи вплоть до «добавить такой-то файл» (попутно я собирал потихоньку собственную «библиотеку элементарных задач» с хорошо известными оценками), которые оценивались PERT-ом с точностью до 10 минут.
В итоге получался excel-файл на потеху заказчику, в котором содержалось 400-600 мелких задач, складывающихся в недели и месяцы разработки. С таковым заказчику очень трудно аргументированно спорить, но оценка на сферическую в вакууме разработку получается дюже точной (в рамках оценок точности PERT-а), да и детальный план что делать — вот он вот. Хоть в JIRA выливай. Бонусом идет проектирование на ранних этапах.
Как водится, у подобного подхода есть одна сложность — это ж надо сидеть и работать. Оценка делается напряженным умственным трудом группы людей на протяжении 2-3 дней. А менеджер работать не любит. Менеджер, как правило, поговорить любит.
А в остальном lair прав. Agile/Scrum тут ни при чем. Как раз процесс — это отвертка и инструмент. Внедряющий должен хорошо понимать границы его применимости для данной конкретной команды разработчиков и для данного проекта. И лично я не раз отмечал в отечественных компаниях отношение к методологии управления как к волшебной таблетке, которая может починить разом все огрехи проекта, превратить разработчиков в добрых паладинов, а заказчиков — в белых котяток, ну а бонусом прекратить войну на ближнем востоке и предотвратить кризисы капитализма. Очевидно, оно так не работает. Любая методология управления в любой компании де-факто гибридна и претерпевает множество поправок на объективную реальность, а то и вообще собрана из кусков разных методологий. Кто не умеет этого признавать — получает по голове в долгосрочной перспективе и обречен ходить по граблям.
На мой взгляд — причина неудачного внедрения в том, что новые цепочки процесса управления во-первых убили напрочь обратную связь между командой разработки и менеджментом (или даже клиентом), во-вторых, само желание «высокого начальства» внедрить Scrum — сиречь, проконтролировать то, что контролировать не нужно (время на разработку) — было ущербным.
Если честно, я вообще не понимаю трекинг времени внутри команды в штате компании. К'мон, ребята, как будто вы заплатите сотруднику меньше денег, узнав что он решил задачу за X времени, когда по вашему скромному мнению она должна занимать Y времени. Вы или выкупаете команду оптом, без вопросов выплачивая фиксированную сумму в месяц и берете на себя все риски неправильной постановки задач, рабочей среды, коммуникаций и оборудования, или, если вам хочется контролировать время — отправляете сотрудников на UpWork с почасовой оплатой (правда, она будет выше в силу накладных расходов разработчиков).
А организовывать грибной менеджмент на сотрудниках на зарплате с допросами почему эта кнопочка заняла столько времени попахивает излишней укомплектованностью управленческого звена кадрами (читай: менеджеров пора выпинывать с работы, или придумывать чем занять).
Хотя с другой стороны — если менеджеру хочется поговорить вместо работы, то рыночно-ориентированный программист никогда не откажет ему в такой возможности. Любой каприз, как говорится, за ваши деньги. Менеджер имеет полное право получить услуги психотерапии усилиями программиста и по его рейту.
У меня есть пара контактов людей в русскоязычном сообществе MS — им уже отписал.
P.S.: я еще допилю в свое творение fluent-конфигурацию (просто пока сильно больно времени нет) и будет следующая статья.
Дадада. Вот оттуда я ее скачал и сгенерил парсер, который зациклился на самом простом js-файле.
А я свою грамматику (на Coco\R) написал где-то в марте прошлого года. Время, беспощадная ж ты штука.
А вообще то ли у меня руки не оттуда, то ли лыжи не едут… Но в общем была у меня какая-то грамматика для ANTLR-а, из которой я сгенерил все необходимое, сделал playground для тестирования, нажал F5 — и получил зацикливание на простеньком js-файле. С тех пор я ANTLR-ом не пользуюсь.
Там, на самом деле, затык в том, что в TS называется тайпинги. Т.е. придется переписывать интерфейсы для внешний библиотек, что руками делать долго и скучно.
А на самом деле, первоначальная версия транслятора внезапно хороша тем, что там есть парсер JavaScript, который превосходно разбирает даже минифицированный jquery в AST. Не спрашивайте зачем он там нужен, но он есть.