Comments 40
Два вопроса:
1. Основной язык (фреймворк) разработки.
2. Почему не используете TDD/BDD?
1. Основной язык (фреймворк) разработки.
2. Почему не используете TDD/BDD?
1. Мы пишем на Java (Spring, GWT).
2. На этот вопрос трудно ответить. Наверное потому же, почему мы в полной мере не используем парное программирование, о чем я писал в предыдущей статье habrahabr.ru/company/itarena/blog/133016/. Но и здесь мы движемся — пишем тесты, хотя и не перед кодированием.
2. На этот вопрос трудно ответить. Наверное потому же, почему мы в полной мере не используем парное программирование, о чем я писал в предыдущей статье habrahabr.ru/company/itarena/blog/133016/. Но и здесь мы движемся — пишем тесты, хотя и не перед кодированием.
disclaimer: «Я еще не волшебник, я только учусь». И скрам мы только думаем вводить.
Но книжки говорят, что TDD — одна из самых сложных техник. То есть сложно в нее врубиться. И что надо довольно долго это делать, думая про себя «что за херня, ну ладно потерплю еще немного» — и со временем оно взлетит.
Так что я думаю, что с TDD начинать не надо. Есть множество более простых техник, которые быстрее дают ощутимый результат. Ну а потом можно и TDD вводить, для того и ретроспективы придуманы, чтоб все процессы можно было переделывать если надо.
Но книжки говорят, что TDD — одна из самых сложных техник. То есть сложно в нее врубиться. И что надо довольно долго это делать, думая про себя «что за херня, ну ладно потерплю еще немного» — и со временем оно взлетит.
Так что я думаю, что с TDD начинать не надо. Есть множество более простых техник, которые быстрее дают ощутимый результат. Ну а потом можно и TDD вводить, для того и ретроспективы придуманы, чтоб все процессы можно было переделывать если надо.
Поделитесь, пожалуйста, какие книги Вы читали по TDD и более простые и эффективные методики. Мне было бы интересно тоже ознакомиться.
ну, конкретно вот это — где рассматривается не «скрам» как единое нечто, а именно набор отдельных практик — «Patterns of Agile Practice Adoption» by Amr Elssamadisy.
есть бесплатная pdf-ка и более полная книжка на амазоне:
www.infoq.com/minibooks/agile-patterns
www.amazon.com/Agile-Adoption-Patterns-Roadmap-Organizational/dp/0321514521
например, вместо TDD (что там называется «Test-First Development») можно применять «Test-Last Development» (не так тру как TDD, но лучше, чем вообще без юнит-тестов). Скорее всего вы так и делаете уже.
есть бесплатная pdf-ка и более полная книжка на амазоне:
www.infoq.com/minibooks/agile-patterns
www.amazon.com/Agile-Adoption-Patterns-Roadmap-Organizational/dp/0321514521
например, вместо TDD (что там называется «Test-First Development») можно применять «Test-Last Development» (не так тру как TDD, но лучше, чем вообще без юнит-тестов). Скорее всего вы так и делаете уже.
TDD — одна из самых сложных техник? Да что вы, ровно наоборот, TDD — это просто и весело.
Конечно, бывают сложные тесты, в которых приходится эмулировать поведение внешних объектов, но сложности есть в любом деле. Но в целом TDD — это клёва, в первую очередь для самого разработчика.
Конечно, бывают сложные тесты, в которых приходится эмулировать поведение внешних объектов, но сложности есть в любом деле. Но в целом TDD — это клёва, в первую очередь для самого разработчика.
Меня лично stand-up митинги задолбали через полгода, некоторых коллег еще раньше.
Стресс с выходом нового релиза (у нас был каждый месяц) — создавал ощущение никому не нужной суеты (все пытались закончить свои задачи вовремя). Через год скрама решили вернуться к обычному планированию — все снова вздохнули с облегчением. Решили просто использовать jpeg-модель с каскадным планированием. Скрам, в этом есть что-то от белки в колесе — невидимое давление на головы людей, которые должны этой головой работать.
Стресс с выходом нового релиза (у нас был каждый месяц) — создавал ощущение никому не нужной суеты (все пытались закончить свои задачи вовремя). Через год скрама решили вернуться к обычному планированию — все снова вздохнули с облегчением. Решили просто использовать jpeg-модель с каскадным планированием. Скрам, в этом есть что-то от белки в колесе — невидимое давление на головы людей, которые должны этой головой работать.
Скрам хорош на поздних стадиях выполнения проекта — дабы отдать заказчику именно то что он хотел, дав возможность поиграться с недельными-двухнедельными релизами.
Мы наоборот считаем, что scrum хорош для нашего проекта именно сейчас (мы ещё в бете) — когда не каждый раз с точностью можно сказать, что именно нужно пользователям.
При этом, сами пользователи далеко не всегда могут ответить, что им требуется именно сейчас. На словах они могут высказывать какие-то свои фантазии, а после получения функциональности — никогда не пользоваться.
Т.е. scrum — это защита от ненужной функциональности, неважно от чьих фантазий эта функциональность родилась — от наших или от пользовательских.
При этом, сами пользователи далеко не всегда могут ответить, что им требуется именно сейчас. На словах они могут высказывать какие-то свои фантазии, а после получения функциональности — никогда не пользоваться.
Т.е. scrum — это защита от ненужной функциональности, неважно от чьих фантазий эта функциональность родилась — от наших или от пользовательских.
А был ли у Вас scrum-мастер, пытающийся выяснить причины недовольств? А то, что задачи не были выполнены, возможно, вы, как команда брали на себя непосильные обязательства. Ведь скрам, с ежеитеративным расчётом velocity для того и нужен, чтобы помогать правильно прогнозировать и не бегать с очумелыми глазами перед релизом.
Не поделитесь, как часто теперь у Вас выходит релиз?
Не поделитесь, как часто теперь у Вас выходит релиз?
Как человек только что перешедший с релизов 2 раза в неделю на раз в неделю, считаю еженедельные релизы идеальными :-Р Зато не нужно потом выпускать пяток патчей для «того что не успело войти» или «это нужно срочно, следующего релиза ждать слишком долго».
При этом ничто не мешает в отдельной ветке работать над проектом 4 месяца, и отправлять его в пре-релизный билд когда практически все готово.
При этом ничто не мешает в отдельной ветке работать над проектом 4 месяца, и отправлять его в пре-релизный билд когда практически все готово.
А как вы боритесь со следующей проблемой?
Тестер тестирует, а значит и находит ошибки, до самого конца итерации. Т.е. получается, что какие-то ошибки на конец итерации не поправлены. Просто физически на это не остаётся времени. Получается, что какие-то задачи, запланированные на итерацию, всегда остаются не выполнены. И релиза не получается.
Понятно, что варианты решения этой проблемы могут быть разные. А как у вас?
Тестер тестирует, а значит и находит ошибки, до самого конца итерации. Т.е. получается, что какие-то ошибки на конец итерации не поправлены. Просто физически на это не остаётся времени. Получается, что какие-то задачи, запланированные на итерацию, всегда остаются не выполнены. И релиза не получается.
Понятно, что варианты решения этой проблемы могут быть разные. А как у вас?
А у вас релизится только то, в чем нет ни одной ошибки?
Некоторые баги находятся и в продакшене, просто уходят в следующую итерацию как часть задач.
Некоторые баги находятся и в продакшене, просто уходят в следующую итерацию как часть задач.
А у вас тестер(ы) в последние дни вдруг прерстаёт находить критические ошибки? Или программисты, сделав за полинтерации все свои задачи, сидят и ждут, а не найдёт ли тестер у них ошибку? Или во время демонстрации по окончанию итерации ничего серьёзного никогда не всплывает?
У нас всё вышеперечисленное гарантировано даёт несколько ошибок, с которыми, как бы это помягче сказать, версию выпускать не хочется.
У нас всё вышеперечисленное гарантировано даёт несколько ошибок, с которыми, как бы это помягче сказать, версию выпускать не хочется.
Во время демо иногда всплывает, но как правило тогда, когда трудоемкость задачи / сроки были определены неправильно. Оно при этом не само всплывает, а как правило человек уже тестировавший этот код показывает где чего. Потому что если демо будет проводить девелопер, они могут аккуратно обойти гиблые места в надежде что дофиксят позже.
Если же критичные баги всплывают в последний момент постоянно, то осмелюсь предположить, что тестеры у вас так себе либо требования не расписаны. Потому что обычно все же тестируются самые критичные модули, самая важная функциональность. У нас четко видна закономерность: в начале тестирования вносятся P1-P2 баги, а в конце в основном P3-P4 находятся.
Если же критичные баги всплывают в последний момент постоянно, то осмелюсь предположить, что тестеры у вас так себе либо требования не расписаны. Потому что обычно все же тестируются самые критичные модули, самая важная функциональность. У нас четко видна закономерность: в начале тестирования вносятся P1-P2 баги, а в конце в основном P3-P4 находятся.
Мы, похоже, не понимаем друг друга.
Ситуация предельно проста. Разработчики закончили свои последние в итерации задачи. Это происходит в последние дни итерации. После этого тестер берёт результат и проверяет. Находит критические ошибки. Т.е. появляются критические ошибки в последние дни. Каким образом эти баги могут НЕ всплывать?
Или у вас итерация на программирование, а следующая на тестирование? Тогда, конечно, легко сначала смотреть и править критичные модули, а потом другие.
Ситуация предельно проста. Разработчики закончили свои последние в итерации задачи. Это происходит в последние дни итерации. После этого тестер берёт результат и проверяет. Находит критические ошибки. Т.е. появляются критические ошибки в последние дни. Каким образом эти баги могут НЕ всплывать?
Или у вас итерация на программирование, а следующая на тестирование? Тогда, конечно, легко сначала смотреть и править критичные модули, а потом другие.
А сколько у вас длится итерация и какого размера средняя задача? И как организовано тестирование — в какой момент и как быстро задача переходит от разработчика к тестировщику?
Как описано в статье, у нас задача попадает к тестировщику ещё до коммита. Поэтому в последние дни итерации количество непротестированных задач невелико — только те, что на данный момент в разработке.
Как описано в статье, у нас задача попадает к тестировщику ещё до коммита. Поэтому в последние дни итерации количество непротестированных задач невелико — только те, что на данный момент в разработке.
А, я поняла. У нас просто когда учитывается задача, которая может быть выполнена в итерацию, выставляются рамки когда должен быть готов код. То есть если релиз в среду, то код должен пройти демо в понедельник, а тестер иметь возможность начать тестирование еще раньше — в четверг минимум (если это не просто изменение дизайна интерфейса). И если программист говорит, что у него написание кода займет всю итерацию, то тогда эту задачу дробят либо релиз переносят в следующую итерацию после выполнения тестирования и баг фиксов.
В интересной книге «Lean Software Development» от идеи до прибыли Тома и Мери Поппендик есть ответ на этот вопрос. Ошибки, как и задачи на разработку чего-то нового нужно приоритезировать. Некоторые ошибки могут быть очень минорными и вообще не попадать в разряд ошибок, а относиться к «хотелкам».
В итоге на production практически с нулевой вероятностью попадают высокоприоритетные, критичные дефекты, а на минорные мало кто обращает внимание. Главное — регулярность обновлений с новыми функциями.
В итоге на production практически с нулевой вероятностью попадают высокоприоритетные, критичные дефекты, а на минорные мало кто обращает внимание. Главное — регулярность обновлений с новыми функциями.
Ну это всё теория. А на практике тестер в последние пару дней может найти пяток ошибок (и находит, зараза), с которыми нельзя выпускать релиз. Как вы решаете эту проблему?
Позволю себе ответить за коллегу.
Если это действительно ошибки, т.е. это мешает нормальному использованию системы, то мы отложим выпуск релиза до исправления этих ошибок. Нет никакого смысла доставлять пользователям неработающую функциональность.
Если это не критичные ошибки, например, немного снижающие удобство использования, но в целом новая функциональность может быть опробована уже сейчас — то мы выпускаем релиз в таком виде. Таким образом в этом релизе мы даём пользователям какую-то бизнес-ценность. А в следующем релизе мы исправим найденные замечания (если необходимость ещё останется).
Ну и сейчас мы стараемся спланировать итерацию так, чтобы на её конец приходились не самые «тяжёлые» задачи, как по времени разработки, так и по количеству изменений. Пока ещё рано делать выводы, но надеемся, что это нам поможет отлавливать критичные ошибки чуть раньше, чем в последние пару дней.
Если это действительно ошибки, т.е. это мешает нормальному использованию системы, то мы отложим выпуск релиза до исправления этих ошибок. Нет никакого смысла доставлять пользователям неработающую функциональность.
Если это не критичные ошибки, например, немного снижающие удобство использования, но в целом новая функциональность может быть опробована уже сейчас — то мы выпускаем релиз в таком виде. Таким образом в этом релизе мы даём пользователям какую-то бизнес-ценность. А в следующем релизе мы исправим найденные замечания (если необходимость ещё останется).
Ну и сейчас мы стараемся спланировать итерацию так, чтобы на её конец приходились не самые «тяжёлые» задачи, как по времени разработки, так и по количеству изменений. Пока ещё рано делать выводы, но надеемся, что это нам поможет отлавливать критичные ошибки чуть раньше, чем в последние пару дней.
Если быть до конца честными — то ситуации, конечно, бывают всякие.
Иногда приходится выпускать «технические обновления» или патчи для исправления супер-критичных ошибок, которые могли существовать в коде уже давно, но вот только сейчас проявиться. Пока что такие ситуации возникали только пару раз и в целом на релизный цикл, итерации, планирования и всё такое прочее не сильно повлияли. Т.е. это именно исключения.
Иногда приходится выпускать «технические обновления» или патчи для исправления супер-критичных ошибок, которые могли существовать в коде уже давно, но вот только сейчас проявиться. Пока что такие ситуации возникали только пару раз и в целом на релизный цикл, итерации, планирования и всё такое прочее не сильно повлияли. Т.е. это именно исключения.
Как раз исключения меня не очень волнуют. Меня беспокоит, когда это происходит систематически. А у нас это происходит регулярно :( И у меня ощущение, что проблема эта методологическая. см. habrahabr.ru/company/itarena/blog/134235/?reply_to=4469150#comment_4469213
А то, что можно выкрутится с помощью, например, «субботника» по чистке ошибок — это я знаю. Продукт-то мы всё ж таки выпускаем как-то :)
А то, что можно выкрутится с помощью, например, «субботника» по чистке ошибок — это я знаю. Продукт-то мы всё ж таки выпускаем как-то :)
Субботники по исправлению ошибок, слава богу, остались где-то в прошлой жизни :)
Возможно, не все ошибки у вас настолько критичны? Может, стоит попытаться стать чуть меньшими перфекционистами? :)
У нас решение «исправлять / не исправлять» в конце итерации проходит при достаточно жарких дискуссиях. Чаще всего побеждает позиция «лучше обновить сейчас и выкатить новые функции».
Всё-таки, появление очень критичных дефектов перед обновлением — это пока редкость. Вероятно, в этом помогает двойное тестирование: перед коммитом и перед выпуском релизов.
Возможно, не все ошибки у вас настолько критичны? Может, стоит попытаться стать чуть меньшими перфекционистами? :)
У нас решение «исправлять / не исправлять» в конце итерации проходит при достаточно жарких дискуссиях. Чаще всего побеждает позиция «лучше обновить сейчас и выкатить новые функции».
Всё-таки, появление очень критичных дефектов перед обновлением — это пока редкость. Вероятно, в этом помогает двойное тестирование: перед коммитом и перед выпуском релизов.
Вопрос у меня был методологический.
Методы работы с ошибкой, найденной в начале итерации могут сильно отличаться от тех, что используются в конце. Т.е. бегунок на шкале исправить______похерить к концу итерации начинает смещаться вправо. Не видел, чтобы это как-то учитывалось в методологиях управления проектами.
Методы работы с ошибкой, найденной в начале итерации могут сильно отличаться от тех, что используются в конце. Т.е. бегунок на шкале исправить______похерить к концу итерации начинает смещаться вправо. Не видел, чтобы это как-то учитывалось в методологиях управления проектами.
ну, если строго по теории, то в конце спринта проводится ретроспектива. Там обсуждаются причины, почему опять всплывают критические ошибки в последние дни. И, например, может решиться, что проблема с качеством кода, и надо работать в этом направлении — упрощать дизайн и функциональность, code review, парное программирование, TDD, и так далее. Или, может, проблема в другом — velocity не считается каждый день или stand-up meetings не работают, и получается в конце каждого спринта мини-аврал, когда все лезут из кожи вон чтоб успеть. Или еще что-нибудь, вам видней.
И ещё в догонку. Вы бы послали этот пост в категорию Управление проектом или Agile. Может народу больше бы ознакомилось и обсудило.
как быть с читом, когда люди оценивая задачи завышают сроки, а потом спокойно полдня решают свои задачи. Спринт получается заполнен, но по факту загрузка максимум 50%.
А это чисто теоретический вопрос или Вы с этим сталкиваетесь?
По моему опыту, программисты, если речь идёт о них, не склонны завышать объёмы работ, с целью выделить время для попинания балды. Я встречался с тем, что они ещё где-то подрабатывают. Но это, если ты в плотном контакте с группой, довольно быстро становится понятно. А дальше оргвыводы, которые зависят от традиций Вашей организации ;)
По моему опыту, программисты, если речь идёт о них, не склонны завышать объёмы работ, с целью выделить время для попинания балды. Я встречался с тем, что они ещё где-то подрабатывают. Но это, если ты в плотном контакте с группой, довольно быстро становится понятно. А дальше оргвыводы, которые зависят от традиций Вашей организации ;)
Наблюдаю такую картину время от времени. Понятно что они не всегда пинают балду, иногда занимаются своими делами. Проблема тут еще кроется в том, что даже если ты сделаешь соответствующие выводы, то в белой компании расстаться таким человеком тяжело. (ну или 2 ЗП при увольнении) А на фоне катастрофической нехватки людей на рынке поведение некоторых вообще попахивает чуть ли не шантажом.
уважаемый коллега, одним из способов исключения описанных ситуаций может стать оценка не в реальных промежутках времени, а в относительных (часы, дни -> баллы, очки, story points). таким образом не нужно считать никаких фокус факторов и загрузки, а только velocity. после пары итераций Вы увидите реальную скорость, velocity и в дальнейшем смолжете отслеживать отклонения в ту или иную сторону и делать какие-то выводы.
кроме того, сама команда будет видеть и сможет помогать себе справляться с людьми, не желающими посвящать себя работе в рабочее время.
кроме того, сама команда будет видеть и сможет помогать себе справляться с людьми, не желающими посвящать себя работе в рабочее время.
Хм, не совсем понимаю как перевести баллы в часы, что бы распределять задачи по спринту? Не совсем уверен что люди смогут оценить в баллах (они в часах то не всегда смогут оценить корректно). При этом мы оцениваем чистое время на выполнение задачи (плюс время на взаимодействие)
То что команда начнет помогать решать проблемы с людьми, которые не работают — это пока миф. «Неужели вы действительно думаете что все участники команды будут стучать друг на друга или делать выводы кто подвел команду, зная что эти выводы впоследствии обернуться виновникам административными мерами», вот примерно то что я услышал в ответ на моё мнение по этому поводу.
То что команда начнет помогать решать проблемы с людьми, которые не работают — это пока миф. «Неужели вы действительно думаете что все участники команды будут стучать друг на друга или делать выводы кто подвел команду, зная что эти выводы впоследствии обернуться виновникам административными мерами», вот примерно то что я услышал в ответ на моё мнение по этому поводу.
оценка в нереальных единицах, баллах и вслепую — более точна. это утверждение основывается на исследованиях американских ученых-статистиков. перевод баллов в часы не нужен и абсолютно недопустим. после пары спринтов оценки в баллах, Вы увидите реальную скорость, тут без обсуждений будет включено всё: и поход за чаем, и время на общение и на изучение.
тут стучать никому не надо. всё будет видно. команда будет видеть кто, как и что делает. если это действительно команда, то ещё и пытаться помочь. если человек не хочет участвовать в командной работе, то и ему будет некомфортно с командой и команде с ним. тут уже что-то да произойдёт само собой.
тут стучать никому не надо. всё будет видно. команда будет видеть кто, как и что делает. если это действительно команда, то ещё и пытаться помочь. если человек не хочет участвовать в командной работе, то и ему будет некомфортно с командой и команде с ним. тут уже что-то да произойдёт само собой.
Хм, похоже я этот момент не совсем понимаю. Вот есть задача А, и задача Б. Задачу Б оценили в 4 балла а задачу А в 7 баллов. Как это ложится на доску с планированием по дням?
Вам же нужно планирование по итерациям, а не по дням. Со временем вы поймёте, что выполняете за итерацию задач на 100 баллов, например.
Понятно, что сначала будет переходный период, когда оценивая будете думать «так, наверное задача на 4 балла — это примерно 4 часа». Но со временем это уйдёт.
Одно из преимуществ, например: если разработчик берёт задачу на 8 часов, делает её с утра и заканчивает где-то после обеда, то подсознательно он думает: «окей, на сегодня я план выполнил!». А если он делает задачу в 10 баллов за то же время… то так думать уже просто не получится :)
Понятно, что сначала будет переходный период, когда оценивая будете думать «так, наверное задача на 4 балла — это примерно 4 часа». Но со временем это уйдёт.
Одно из преимуществ, например: если разработчик берёт задачу на 8 часов, делает её с утра и заканчивает где-то после обеда, то подсознательно он думает: «окей, на сегодня я план выполнил!». А если он делает задачу в 10 баллов за то же время… то так думать уже просто не получится :)
а где можно более подробно почитать про оценку в баллах и как это все организовано?
Например, scrum.org.ua/wp-content/uploads/2008/12/scrum_xp-from-the-trenches-rus-final.pdf
Про story points на стр. 19. И дальше читаем, как использовать. Книга небольшая, найти будет легко.
Про story points на стр. 19. И дальше читаем, как использовать. Книга небольшая, найти будет легко.
У нас трудоемкость задачи оценивается группой. Разумеется, если это фронт-енд задача, то слово фронт-ендщика имеет решающий вес, но он должен аргументировать почему эта задача сложнее аналогичных в предыдущих проектах. Или наоборот, изменение может быть небольшим, но тут тестер поднимет вопрос, что оно затрагивает всю систему, а автоматизировано недостаточно, чтобы регрешн прошел быстро, и повышает трудоемкость.
Халтурщики обычно хорошо видны, и первый этап — микроменеджмент таких товарищей, второй — увольнение.
Халтурщики обычно хорошо видны, и первый этап — микроменеджмент таких товарищей, второй — увольнение.
Sign up to leave a comment.
Живой пример применения гибкого подхода к разработке ПО в российском стартапе