Ответ выше был, в общем-то, правильным. Мы делаем социальную сеть. Пока она живет, мы её развиваем, правим найденные баги и добавляем новый функционал. Если «готов» читать как «закончена работа над проектом», то готовым проект станет только в момент закрытия.
Основная часть прибыли идет от совместных программ с заведениями. Мы им — рекламу и посетителей через специальные акции, они нам выхлоп. Кроме того, мы постепенно расширяемся на рынок купонов.
Вы правы, изначально оно было совсем не так. Основные сложности возникали с организацией: люди не хотели подниматься на стендапы каждый день, было желание пропустить этап оценивания при планировании. Решение — объяснить разработчикам, почему им так будет работать легче и придерживаться жесткой дисциплины, пока это не войдет в привычку. В нашем случае помогло.
Оценивание задачи идет всей командой. На первых спринтах оценки от реальности отличались порой в два-три раза в обе стороны. Сейчас получается достаточно точно, но на получение опыта у нас ушло около четырех недельных спринтов. Скорость разработки может служить основанием для пропорционального увеличения времени выполнения задачи. Напоминаю — команда небольшая и такие вещи легко держать в голове. Когда имеем дело с новыми разработчиками, ставится дополнительная задача вида «изучение архитектуры».
Заинтересованность/стимул — на эту тему было написано много статей, так что что-то новое я вряд ли скажу. Отслеживается это на стендапах и по количественным показателям — время переключения между задачами и скорость выполнения задач. Стимулы в каждом случае свои, иногда работает переключение на новый фронт работ или отпуск/отгул для отдыха. Иногда речь идет о повышении з/пл, если недоследили, либо премия в следующем месяце по результатам работы.
Провалов по показателям из месяца в месяц у нас пока что не было, команда подобралась хорошая. Если будет — постараемся разобраться, почему так происходит. При небольшом количестве людей мне кажется намного более эффективным с каждым таким случаем разобраться отдельно.
Задачи с горкой мы стараемся не нагружать — это действительно плохо влияет на разработчиков. Мы предпочтем поставить спринт на 90-95 часов, но при этом с самого начала понимать, что могут и будут возникать проблемы и незапланированные задачи посреди спринта.
Причины:
— разработчики не находятся под стрессом невыполнимых сроков и видят, что результат достижим;
— у нас есть запас прочности на случай возникающих проблем;
— в случае если задачи закончатся, у нас всегда есть бэклог и PO.
Желание завысить время работы может возникнуть в любом случае. Решается проставлением времени задачи всей командой при планировании — когда никто лично не заинтересован в завышении оценки — и стендапами. Если разработчик увеличивает время задачи во время выполнения, он должен объяснить, почему так произошло.
Да, большая часть новых задач уходит в бэклог и, в будущем, в следующий спринт.
Но некоторые задачи очень не хочется откладывать даже на пару дней. Обычно это или критические баги, которые нашлись посреди спринта, или задачи, связанные со взаимодействием с нашими партнерами.
Сейчас детализация занимает 2-4 часа. Когда мы начинали использовать эту методику — уходил почти весь рабочий день.
Формулировка задачи должна быть понятна всем разработчикам. Если есть какие-то важные для выполнения и не следующие из формулировки моменты, они выносятся в комментарии к задаче.
Критерий выполнения должен быть ясен и достижим. «Протестировать работу сайта» — задача практически невыполнимая. Если её заменить набором задач вида «протестировать сохранение настроек пользователя», то будет гораздо лучше — в каждом отдельном случае область работы четко очерчена. Это свойство важно ещё и при оценке времени выполнения задачи.
Кроме того, в нашей практике мы пришли к выводу, что задача не должна подразумевать переключения между разными частями проекта. Задача «изменить структуру БД для N» — хорошая, её можно писать в спринт. Задачу «изменить структуру БД и добавить поля ввода для новых атрибутов» надо разбивать на две части перед добавлением.
Для этого у нас и проводятся ежедневные стендапы — они позволяют понять, где пошло расхождение с планом. Стендап проходит за 15-30 минут, основные вопросы всё те же:
— что за вчера было сделано;
— что за вчера не было сделано из запланированного и почему, какие проблемы возникли;
— что планируется сделать сегодня.
Разработчику понимание того, что завтра днем придется рассказывать, на что ушел сегодняшний день, очень хорошо помогает удерживаться в рамках плана. Тимлиду — уловить момент, когда пошло отклонение от плана и его скорректировать.
Во многом исторически сложилось — проект начали писать с SVN-репозиторием. Смысла в переезде особо не видим. По веткам — проблем с мержем не имеем, так как большая часть веток короткоживущие, да и разработчиков не так много.
Уходят в бэклог. Перед планированием бэклог перетрясается на предмет низкоприоритетных задач, которые там давно висят. О части просто забываем, у части поднимаем приоритет и выносим в спринт.
На редкость странная идея, на мой взгляд.
1. Становится в разы сложнее оценить собственное благосостояние.
2. Требуется стабильность. Получите инвалидность и поймете, что все пособие сантехникам уходит, а жить особо не на что.
3. Если хотите попробовать уже сейчас — берите кредиты. Много кредитов. Предупреждая возражение — маленькими долями и пожизненно тоже будет стоить намного дороже чем все сразу. Потому что сантехник будет лишен возможности пустить деньги в оборот.
Здесь не соглашусь. Условия у меня конечно относительно тепличные были — ВМиК МГУ, математическая кафедра — но при общей загрузке учебы мне хватало времени и на фриланс, и на написание небольших рогаликов/аркад/сайтов для себя. В том числе и во время написания диплома. Было бы желание.
Зачем заменять? Конкатенация строк же.
А если заменить — получится второй аргумент функции, который там в таком виде не нужен — судя по названию переменной.
Если расслабить зрение и смотреть через монитор на край белого пятна примерно под символами «board.», то создается впечатление, что волны плывут влево-вправо. Хотя это может быть моя личная иллюзия, но попробуйте.
А так — очень приятный, медитативный сайт. Помогает ни о чем не думать несколько минут, после чего можно посмотреть на дела с новой точки зрения.
Рискну предположить, что такая «усредненная» точка для разной целевой группы различается. Классификация аудитории — это как раз попытка найти эту точку и сделать так, чтобы интерфейс для некоторой её окресности был наиболее удобен.
И да — это не отменяет вылизанности интерфейса. Ежу ясно, что нелагающая программа лучше лагающей, а сайт, который показывает 404 или 502 на каждой третьей странице хуже того, который так не делает. В большинстве случаев.
Но при прочих равных кому-то удобнее чекбоксы в стиле сафари, а кто-то предпочтет стиль IE. Кому-то удобнее списки, а кто-то предпочтет большие простыни таблиц. Классификация и уточнение целевой аудитории приводит к возможности обоснованного выбора между примерно равными вариантами. Глупо для сообщества протанопов делать иконки красного, оранжевого и розового цветов — не поймут.
Документация по текущему состоянию проекта ведется одновременно с разработкой. Необходимое ТЗ на спринт создается до спринта.
Основная часть прибыли идет от совместных программ с заведениями. Мы им — рекламу и посетителей через специальные акции, они нам выхлоп. Кроме того, мы постепенно расширяемся на рынок купонов.
Оценивание задачи идет всей командой. На первых спринтах оценки от реальности отличались порой в два-три раза в обе стороны. Сейчас получается достаточно точно, но на получение опыта у нас ушло около четырех недельных спринтов. Скорость разработки может служить основанием для пропорционального увеличения времени выполнения задачи. Напоминаю — команда небольшая и такие вещи легко держать в голове. Когда имеем дело с новыми разработчиками, ставится дополнительная задача вида «изучение архитектуры».
Заинтересованность/стимул — на эту тему было написано много статей, так что что-то новое я вряд ли скажу. Отслеживается это на стендапах и по количественным показателям — время переключения между задачами и скорость выполнения задач. Стимулы в каждом случае свои, иногда работает переключение на новый фронт работ или отпуск/отгул для отдыха. Иногда речь идет о повышении з/пл, если недоследили, либо премия в следующем месяце по результатам работы.
Провалов по показателям из месяца в месяц у нас пока что не было, команда подобралась хорошая. Если будет — постараемся разобраться, почему так происходит. При небольшом количестве людей мне кажется намного более эффективным с каждым таким случаем разобраться отдельно.
Причины:
— разработчики не находятся под стрессом невыполнимых сроков и видят, что результат достижим;
— у нас есть запас прочности на случай возникающих проблем;
— в случае если задачи закончатся, у нас всегда есть бэклог и PO.
Желание завысить время работы может возникнуть в любом случае. Решается проставлением времени задачи всей командой при планировании — когда никто лично не заинтересован в завышении оценки — и стендапами. Если разработчик увеличивает время задачи во время выполнения, он должен объяснить, почему так произошло.
Но некоторые задачи очень не хочется откладывать даже на пару дней. Обычно это или критические баги, которые нашлись посреди спринта, или задачи, связанные со взаимодействием с нашими партнерами.
Формулировка задачи должна быть понятна всем разработчикам. Если есть какие-то важные для выполнения и не следующие из формулировки моменты, они выносятся в комментарии к задаче.
Критерий выполнения должен быть ясен и достижим. «Протестировать работу сайта» — задача практически невыполнимая. Если её заменить набором задач вида «протестировать сохранение настроек пользователя», то будет гораздо лучше — в каждом отдельном случае область работы четко очерчена. Это свойство важно ещё и при оценке времени выполнения задачи.
Кроме того, в нашей практике мы пришли к выводу, что задача не должна подразумевать переключения между разными частями проекта. Задача «изменить структуру БД для N» — хорошая, её можно писать в спринт. Задачу «изменить структуру БД и добавить поля ввода для новых атрибутов» надо разбивать на две части перед добавлением.
— что за вчера было сделано;
— что за вчера не было сделано из запланированного и почему, какие проблемы возникли;
— что планируется сделать сегодня.
Разработчику понимание того, что завтра днем придется рассказывать, на что ушел сегодняшний день, очень хорошо помогает удерживаться в рамках плана. Тимлиду — уловить момент, когда пошло отклонение от плана и его скорректировать.
Я бы даже сказал, что важнее второе слово.
1. Становится в разы сложнее оценить собственное благосостояние.
2. Требуется стабильность. Получите инвалидность и поймете, что все пособие сантехникам уходит, а жить особо не на что.
3. Если хотите попробовать уже сейчас — берите кредиты. Много кредитов. Предупреждая возражение — маленькими долями и пожизненно тоже будет стоить намного дороже чем все сразу. Потому что сантехник будет лишен возможности пустить деньги в оборот.
А если заменить — получится второй аргумент функции, который там в таком виде не нужен — судя по названию переменной.
А так — очень приятный, медитативный сайт. Помогает ни о чем не думать несколько минут, после чего можно посмотреть на дела с новой точки зрения.
И да — это не отменяет вылизанности интерфейса. Ежу ясно, что нелагающая программа лучше лагающей, а сайт, который показывает 404 или 502 на каждой третьей странице хуже того, который так не делает. В большинстве случаев.
Но при прочих равных кому-то удобнее чекбоксы в стиле сафари, а кто-то предпочтет стиль IE. Кому-то удобнее списки, а кто-то предпочтет большие простыни таблиц. Классификация и уточнение целевой аудитории приводит к возможности обоснованного выбора между примерно равными вариантами. Глупо для сообщества протанопов делать иконки красного, оранжевого и розового цветов — не поймут.