Не совсем про Spring Data (мы его пока не используем), но в тему Spring + Generics. Я реализовал следующий подход, который позволяет не использовать никакие общие абстрактные классы. Правда, потребовалась кастомная аннотация и фабрика для реализаций DAO.
@Target(ElementType.FIELD)
@Retention(RetentionPolicy.RUNTIME)
@Qualifier("coreDaoByAnnotation")
public @interface CoreDaoClass {
Class<?> value();
}
Ну и фабрика для конкретных реализаций DAO:
@Configuration
public class CoreDaoFactory {
@Bean
@Scope(ConfigurableBeanFactory.SCOPE_PROTOTYPE)
@Lazy
public <C> CoreDao<C> coreDaoForClass(Class<C> cls) {
return new CoreDaoImpl<>(cls);
}
@Bean
@Scope(ConfigurableBeanFactory.SCOPE_PROTOTYPE)
@Lazy
public CoreDao<?> coreDaoByAnnotation(InjectionPoint ip) {
CoreDaoClass annotation = AnnotationUtils.findAnnotation(ip.getAnnotatedElement(), CoreDaoClass.class);
if (annotation == null) {
throw new NoSuchBeanDefinitionException("CoreDao", "CoreDaoClass is not defined");
}
return new CoreDaoImpl<>(annotation.value());
}
}
А сколько у вас длится итерация и какого размера средняя задача? И как организовано тестирование — в какой момент и как быстро задача переходит от разработчика к тестировщику?
Как описано в статье, у нас задача попадает к тестировщику ещё до коммита. Поэтому в последние дни итерации количество непротестированных задач невелико — только те, что на данный момент в разработке.
Вам же нужно планирование по итерациям, а не по дням. Со временем вы поймёте, что выполняете за итерацию задач на 100 баллов, например.
Понятно, что сначала будет переходный период, когда оценивая будете думать «так, наверное задача на 4 балла — это примерно 4 часа». Но со временем это уйдёт.
Одно из преимуществ, например: если разработчик берёт задачу на 8 часов, делает её с утра и заканчивает где-то после обеда, то подсознательно он думает: «окей, на сегодня я план выполнил!». А если он делает задачу в 10 баллов за то же время… то так думать уже просто не получится :)
В таком случае, это не вопрос к методологии :)
По моему мнению, с людьми, которые не хотят работать, надо расставаться. Один такой человек может демотивировать всю остальную команду.
Субботники по исправлению ошибок, слава богу, остались где-то в прошлой жизни :)
Возможно, не все ошибки у вас настолько критичны? Может, стоит попытаться стать чуть меньшими перфекционистами? :)
У нас решение «исправлять / не исправлять» в конце итерации проходит при достаточно жарких дискуссиях. Чаще всего побеждает позиция «лучше обновить сейчас и выкатить новые функции».
Всё-таки, появление очень критичных дефектов перед обновлением — это пока редкость. Вероятно, в этом помогает двойное тестирование: перед коммитом и перед выпуском релизов.
Если быть до конца честными — то ситуации, конечно, бывают всякие.
Иногда приходится выпускать «технические обновления» или патчи для исправления супер-критичных ошибок, которые могли существовать в коде уже давно, но вот только сейчас проявиться. Пока что такие ситуации возникали только пару раз и в целом на релизный цикл, итерации, планирования и всё такое прочее не сильно повлияли. Т.е. это именно исключения.
Если это действительно ошибки, т.е. это мешает нормальному использованию системы, то мы отложим выпуск релиза до исправления этих ошибок. Нет никакого смысла доставлять пользователям неработающую функциональность.
Если это не критичные ошибки, например, немного снижающие удобство использования, но в целом новая функциональность может быть опробована уже сейчас — то мы выпускаем релиз в таком виде. Таким образом в этом релизе мы даём пользователям какую-то бизнес-ценность. А в следующем релизе мы исправим найденные замечания (если необходимость ещё останется).
Ну и сейчас мы стараемся спланировать итерацию так, чтобы на её конец приходились не самые «тяжёлые» задачи, как по времени разработки, так и по количеству изменений. Пока ещё рано делать выводы, но надеемся, что это нам поможет отлавливать критичные ошибки чуть раньше, чем в последние пару дней.
Мы наоборот считаем, что scrum хорош для нашего проекта именно сейчас (мы ещё в бете) — когда не каждый раз с точностью можно сказать, что именно нужно пользователям.
При этом, сами пользователи далеко не всегда могут ответить, что им требуется именно сейчас. На словах они могут высказывать какие-то свои фантазии, а после получения функциональности — никогда не пользоваться.
Т.е. scrum — это защита от ненужной функциональности, неважно от чьих фантазий эта функциональность родилась — от наших или от пользовательских.
Да, у нас на одну задачу идёт один коммит. А перед коммитом — обязательно проводится code review и тестирование. Только после этих двух операций код можно складывать в общий репозиторий.
> А если фитча содержит 10 коммитов?
Мы стараемся «распиливать» задачи таким образом, чтобы ни одна из них не занимала более трёх дней. Конечно, бывают исключения, но в целом мы справляемся.
По поводу количества коммитов — обычно это действительно один коммит.
> Если вашему более квалифицированному сотруднику приходится учиться у ваших низкоквалифицированных сотрудников, то у меня для вас плохие новости :)
Например?
«приходится учиться» — какое-то странное определение. У каждого человека существует миллион привычек, выработанных годами, а работа в паре позволяет смотреть не только на код, но и даже на то, как человек работает с мышкой, например или какие хоткеи использует. Ну говоря уже о более сложных вещах.
Не понятно, что может быть плохого в том, чтобы узнать что-то новое — совершенно не важно, от кого эта информация исходит.
Считать же что «более квалифицированный сотрудник» по определению знает абсолютно всё, что знает «мене квалифицированный» — по-моему, бред.
> Каждый раз отслеживать и запоминать список того, что нужно изменить и что изменили тоже сложно
Не очень понятно — мы просто смотрим исходящие изменения в Eclipse, ничего запоминать не нужно, все изменения видны.
Основная же суть review до коммита (как и тестирования до коммита) — разработчик не успевает отключиться от контекста задачи; ему не нужно тратить время, чтобы вспомнить чем он занимался.
> И смотреть код должен обязательно более квалифицированный сотрудник, чем тот, кто писал этот самый код, иначе смысла от такого код ревью будет немного
Т.е. у самого квалифицированного сотрудника код смотреть никто не будет? :) Как написал коллега в статье, мы рассматриваем code review ещё и как элемент парного программирования. И поверьте, более квалифицированному частенько есть чему поучиться у всех остальных.
Проводим ревью нового кода перед коммитом. Никакими дополнительными инструментами не пользуемся — садимся рядом и всё просматриваем-изучаем (благо команда не распределённая). От общения во время ревью мы получаем какую-то пользу как от парного программирования, надеюсь, что хотя бы процентов 5-10% :) (парное программирование, к сожалению, пока не хватило сил/смелости внедрить).
Чтобы не спорить «кто сейчас будет делать ревью?» — на итерацию назначается дежурный. У текущего дежурного ревью делает дежурный по предыдущей итерации.
Иногда поглядываю в эту статистику, но пока что платежей по безналу не так много — часто в магазинах и на заправках намного быстрее оплатить наличностью (будешь оплачивать карточкой — поколотят ещё).
Но на оплату карточкой вы меня замотивировали, да.
Кстати, было бы отлично, если бы ручной ввод операций присутствовал в android/iphone приложении.
В «итого» хотелось бы увидеть побольше конкретики. Перечислены всякие предпосылки, а в предпоследнем абзаце только одно разделение — «пользуются/не пользуются».
> Чтобы заказчик — product owner — понимал, что вот эта фича в два раза дольше другой, а вот эта, наоборот, в полтора раза проще.
Согласен. Тем более, если оценка сделана в «зелёных попугаях», то как она может быть дедлайном для команды?
У нас частая ситуация, когда увидев оценку product owner отказывается от выполнения каких-то задач в пользу других, действительно важных.
Вообще, да, согласен, что 7% это тоже не плохо. С другой стороны, ещё из этих 7% какая-то часть людей могла никогда не сталкиваться в реальной жизни с подобным выбором.
Использование выглядит всего лишь вот так:
Аннотация:
Ну и фабрика для конкретных реализаций DAO:
Возможно, не очень красиво (система ругается сообщением об ошибке при попытке редактирования пользователя habrauser), зато действенно.
Как описано в статье, у нас задача попадает к тестировщику ещё до коммита. Поэтому в последние дни итерации количество непротестированных задач невелико — только те, что на данный момент в разработке.
Понятно, что сначала будет переходный период, когда оценивая будете думать «так, наверное задача на 4 балла — это примерно 4 часа». Но со временем это уйдёт.
Одно из преимуществ, например: если разработчик берёт задачу на 8 часов, делает её с утра и заканчивает где-то после обеда, то подсознательно он думает: «окей, на сегодня я план выполнил!». А если он делает задачу в 10 баллов за то же время… то так думать уже просто не получится :)
По моему мнению, с людьми, которые не хотят работать, надо расставаться. Один такой человек может демотивировать всю остальную команду.
Возможно, не все ошибки у вас настолько критичны? Может, стоит попытаться стать чуть меньшими перфекционистами? :)
У нас решение «исправлять / не исправлять» в конце итерации проходит при достаточно жарких дискуссиях. Чаще всего побеждает позиция «лучше обновить сейчас и выкатить новые функции».
Всё-таки, появление очень критичных дефектов перед обновлением — это пока редкость. Вероятно, в этом помогает двойное тестирование: перед коммитом и перед выпуском релизов.
Иногда приходится выпускать «технические обновления» или патчи для исправления супер-критичных ошибок, которые могли существовать в коде уже давно, но вот только сейчас проявиться. Пока что такие ситуации возникали только пару раз и в целом на релизный цикл, итерации, планирования и всё такое прочее не сильно повлияли. Т.е. это именно исключения.
Если это действительно ошибки, т.е. это мешает нормальному использованию системы, то мы отложим выпуск релиза до исправления этих ошибок. Нет никакого смысла доставлять пользователям неработающую функциональность.
Если это не критичные ошибки, например, немного снижающие удобство использования, но в целом новая функциональность может быть опробована уже сейчас — то мы выпускаем релиз в таком виде. Таким образом в этом релизе мы даём пользователям какую-то бизнес-ценность. А в следующем релизе мы исправим найденные замечания (если необходимость ещё останется).
Ну и сейчас мы стараемся спланировать итерацию так, чтобы на её конец приходились не самые «тяжёлые» задачи, как по времени разработки, так и по количеству изменений. Пока ещё рано делать выводы, но надеемся, что это нам поможет отлавливать критичные ошибки чуть раньше, чем в последние пару дней.
При этом, сами пользователи далеко не всегда могут ответить, что им требуется именно сейчас. На словах они могут высказывать какие-то свои фантазии, а после получения функциональности — никогда не пользоваться.
Т.е. scrum — это защита от ненужной функциональности, неважно от чьих фантазий эта функциональность родилась — от наших или от пользовательских.
Именно поэтому у нас есть «дежурный по code review» — за одну итерацию переключением контекста страдает только один человек :)
> А если фитча содержит 10 коммитов?
Мы стараемся «распиливать» задачи таким образом, чтобы ни одна из них не занимала более трёх дней. Конечно, бывают исключения, но в целом мы справляемся.
По поводу количества коммитов — обычно это действительно один коммит.
Например?
«приходится учиться» — какое-то странное определение. У каждого человека существует миллион привычек, выработанных годами, а работа в паре позволяет смотреть не только на код, но и даже на то, как человек работает с мышкой, например или какие хоткеи использует. Ну говоря уже о более сложных вещах.
Не понятно, что может быть плохого в том, чтобы узнать что-то новое — совершенно не важно, от кого эта информация исходит.
Считать же что «более квалифицированный сотрудник» по определению знает абсолютно всё, что знает «мене квалифицированный» — по-моему, бред.
Не очень понятно — мы просто смотрим исходящие изменения в Eclipse, ничего запоминать не нужно, все изменения видны.
Основная же суть review до коммита (как и тестирования до коммита) — разработчик не успевает отключиться от контекста задачи; ему не нужно тратить время, чтобы вспомнить чем он занимался.
> И смотреть код должен обязательно более квалифицированный сотрудник, чем тот, кто писал этот самый код, иначе смысла от такого код ревью будет немного
Т.е. у самого квалифицированного сотрудника код смотреть никто не будет? :) Как написал коллега в статье, мы рассматриваем code review ещё и как элемент парного программирования. И поверьте, более квалифицированному частенько есть чему поучиться у всех остальных.
Чтобы не спорить «кто сейчас будет делать ревью?» — на итерацию назначается дежурный. У текущего дежурного ревью делает дежурный по предыдущей итерации.
Но на оплату карточкой вы меня замотивировали, да.
Кстати, было бы отлично, если бы ручной ввод операций присутствовал в android/iphone приложении.
Согласен. Тем более, если оценка сделана в «зелёных попугаях», то как она может быть дедлайном для команды?
У нас частая ситуация, когда увидев оценку product owner отказывается от выполнения каких-то задач в пользу других, действительно важных.