Comments 46
> Unit test driving development
Тут лучше подойдет т.н. behavior-driven development. Юнит тесты важны и нужны, но строить по ним разработку — как-то уже слишком.
А вообще, с моей точки зрения в некоем роде интроверта, все эти стендапы и митинги — это адская и мало кому нужная потеря времени. Карго-культ в чистом виде.
Большинство вопросов решаются за 5 минут посредством чата/звонка или электропочты, без отрыва от производства.
Возможно, выходом бы было проводить их только для тех, кому они действительно нужны, но не для всей команды.
Тут лучше подойдет т.н. behavior-driven development. Юнит тесты важны и нужны, но строить по ним разработку — как-то уже слишком.
А вообще, с моей точки зрения в некоем роде интроверта, все эти стендапы и митинги — это адская и мало кому нужная потеря времени. Карго-культ в чистом виде.
Большинство вопросов решаются за 5 минут посредством чата/звонка или электропочты, без отрыва от производства.
Возможно, выходом бы было проводить их только для тех, кому они действительно нужны, но не для всей команды.
Я имел ввиду конечно же TDD из extreme programming.
Просто иногда руководство решает его применять совершенно серьезно в своем Agile с элементами XP.
Просто иногда руководство решает его применять совершенно серьезно в своем Agile с элементами XP.
А вообще, с моей точки зрения в некоем роде интроверта, все эти стендапы и митинги — это адская и мало кому нужная потеря времени.Ну, потеря времени не всегда такая уж адская… Хотя при своём избытке «состояние потока» ломают, факт. Но, как я понимаю, agile претендует на то, чтоб эффективно обходится и без «состояния потока» у исполнителя. К тому же желательно, чтоб общую картину видел каждый. Хотя, с одной стороны, вместо отвлечения людей на митинги теоретически можно сделать нечто для общего информирования, например, какие-нибудь плугины в JIRA, с другой — не каждый их добровольно будет смотреть ежедневно…
Большинство вопросов решаются за 5 минут посредством чата/звонка или электропочты, без отрыва от производства.Пятиминутный разговор — это отрыв от производства минимум на 20, учитывая время возврата «в поток». Если таких пятиминуток несколько в день — от рабочего дня почти ничего не остается. Поэтому гораздо лучше решать эти вопросы например раз в день сразу все.
Ну это таки лучше, чем переть с утрища в офис на митинг, и тратить на это половину дня (в лучшем случае — пару часов).
А при определенных договоренностях, можно все это дело организовать одной рассылкой в день.
А при определенных договоренностях, можно все это дело организовать одной рассылкой в день.
Я тут подумал, что наверное мне стоит немного пояснить свою точку зрения.
Итак,
— Краткий отчет (в групповом чате например) в начале дня, вида «что сделано вчера / планы на сегодня» — это очень гут. Четко видно процесс разработки (кто над каким таском работает, не пересекается ли он с моим и т.д.).
— Долгие и нудные митинги раз в неделю-две — это не гут. Вот именно про них я и говорил.
Итак,
— Краткий отчет (в групповом чате например) в начале дня, вида «что сделано вчера / планы на сегодня» — это очень гут. Четко видно процесс разработки (кто над каким таском работает, не пересекается ли он с моим и т.д.).
— Долгие и нудные митинги раз в неделю-две — это не гут. Вот именно про них я и говорил.
«что сделано вчера / планы на сегодня» — это очень гут. Четко видно процесс разработкиМне кажется из этого только четко видно, кто лучше языком чесать умеет. По мне так отчет по открытым-закрытым задачам из таск-трекера куда информативнее, и не отнимает времени.
— Долгие и нудные митинги раз в неделю-две — это не гут. Вот именно про них я и говорил.Любые совещания должны быть четко организованы: подготовлен список вопросов, которые необходимо решить, есть регламент (например 1 минута на выступление, 5 минут на обсуждение, 4 на принятие решения или откладывание). Иначе вы правы, получаются посиделки-поп… делки.
> Мне кажется из этого только четко видно, кто лучше языком чесать умеет. По мне так отчет по открытым-закрытым задачам из таск-трекера куда информативнее, и не отнимает времени.
Никакого чесания, пара строк вида «названия/ID тасков» и все. Кому нужно — посмотрят в трекере по ID. Ну и краткие комменты, если какие-то интересности/необычности встретились по пути. А просто шарить по трекеру долго и скучно.
Никакого чесания, пара строк вида «названия/ID тасков» и все. Кому нужно — посмотрят в трекере по ID. Ну и краткие комменты, если какие-то интересности/необычности встретились по пути. А просто шарить по трекеру долго и скучно.
Так все-таки какая цель подобных выступлений? Если рассказать что-то интересное для всех — то согласен. Если отслеживать прогресс и занятость команды — то пожалуй нет.
А просто шарить по трекеру долго и скучно.не шарить а заранее настроенный отчет снимать. Скучно-не скучно, но это работа РП.
> Так все-таки какая цель подобных выступлений? Если рассказать что-то интересное для всех — то согласен. Если отслеживать прогресс и занятость команды — то пожалуй нет.
Скорее первое, ну и чуть второе (например, интересно наблюдать прогресс выполнения какой-то большой фичи, разделенной на несколько тасков). И еще иногда бывают смежные таски (например, я вчера делал таск «А», а сегодня, допустим, Михаилу упал таск «Б», который есть расширение некоторой части моего таска «А»).
Скорее первое, ну и чуть второе (например, интересно наблюдать прогресс выполнения какой-то большой фичи, разделенной на несколько тасков). И еще иногда бывают смежные таски (например, я вчера делал таск «А», а сегодня, допустим, Михаилу упал таск «Б», который есть расширение некоторой части моего таска «А»).
например, интересно наблюдать прогресс выполнения какой-то большой фичи, разделенной на несколько тасковТак что вам мешает тихонько снять отчет с трекера по «большой фиче» и не дергать программиста с рассказами?
Программист не дергается, он тоже имеет с этого профит.
Так вы ж сами написали:
переть с утрища в офис на митинг, и тратить на это половину дня (в лучшем случае — пару часов).
Не, смотрите часть два в megamozg.ru/post/8666/#comment_438814 :)
Все вышеописанное же происходит в чате в начале дня и занимает ровно 5 минут для всей команды (ну так было, когда я в том проекте принимал участие, как дела сейчас — не знаю).
Все вышеописанное же происходит в чате в начале дня и занимает ровно 5 минут для всей команды (ну так было, когда я в том проекте принимал участие, как дела сейчас — не знаю).
Вообще — в скраме эти выступления задуманы, чтобы обсуждать не закрытые вчера таски, а проблемы, которые возникли :)
Разработчики очень неохотно рассказывают, что где-то у них случился затык и решение не придумывается.
Но, если я обещал вчера таск сделать, но возникли проблемы — на общем собрании я об этом расскажу и команда мне поможет.
А так — мог бы до дедлайна возиться.
Но, к сожалению — часто стендапы делают формальными, как и вообще методологию.
Разработчики очень неохотно рассказывают, что где-то у них случился затык и решение не придумывается.
Но, если я обещал вчера таск сделать, но возникли проблемы — на общем собрании я об этом расскажу и команда мне поможет.
А так — мог бы до дедлайна возиться.
Но, к сожалению — часто стендапы делают формальными, как и вообще методологию.
Мы перестали писать документациюДокументация — это одно, комментарии в коде — совсем другое, как по содержанию, так и по размеру. Если вы документацию запихали в комментарии, то теперь на экране у вас текст с описанием занимает больше места чем, собственно, сам код?
Вместо нее начали вставлять комментарии прямо внутри кода и Javadoc для классов и публичных методов. При этом стало понятно, для кого мы это пишем (для своей команды). Также эти комментарии не подвергались многоступенчатому review.
Фокус с документаций и множества формальных процессов вдруг резко сместился на качество кода и скорость разработки продукта.И человек, которому нужна только документация, но который не пишет код в данном проекте непосредственно, должен лезть в код и выискивать документацию там?
Есть такая вещь как Javadoc. И если правильно оформлять комментарии, то собрать из них документацию в виде html не составляет труда.
Этим, к примеру, занимается одна небеизвестная контора… вот их пример документации собранной прямо из кода: developer.android.com/reference/android/view/View.html
Этим, к примеру, занимается одна небеизвестная контора… вот их пример документации собранной прямо из кода: developer.android.com/reference/android/view/View.html
Комментарии для Javadoc — это не полная замена документации. По-мимо этих комментариев, если уж вы сами упомянули Google, есть сайт с полноценным доками.
Позволю с вами не согласиться — по моему опыту разработки под Android настоящей документации у Гугла как не было, так и нет.
В последние годы они стали выпускать нечто похожее типа блогов Ромейна, но по-прежнему, основная документация обычно находится на блогах любителей-разработчиков.
Но гугл — это лишь пример. При таком размере и популярности системы уже безусловно пора делать настоящую документацию.
Я же писал, про обычные конторы, API которых не используется миллионами разработчкиков по всему миру.
В последние годы они стали выпускать нечто похожее типа блогов Ромейна, но по-прежнему, основная документация обычно находится на блогах любителей-разработчиков.
Но гугл — это лишь пример. При таком размере и популярности системы уже безусловно пора делать настоящую документацию.
Я же писал, про обычные конторы, API которых не используется миллионами разработчкиков по всему миру.
Javadoc позиционируется как полная документация по API. Программистам, которые используют библиотеку, обычно только по API документация и нужна.
Приведённая вами ссылка на документацию больше напоминает не «документацию», а «книжку по разработке под Android».
Приведённая вами ссылка на документацию больше напоминает не «документацию», а «книжку по разработке под Android».
Простая и наглядная агитация за Agile. Эта система заставляет вкалывать сверхурочно, да ещё и с улыбкой на лице за свои 15-ть секунд славы на стендапе.
Совершенно верно — все как в демократии ;)
Кстати на фотографии половина разработчиков стоят в закрытой позе, они нервничают.
Вы уж простите, но система никого ничего не заставляет делать. Честно.
Если оценка проведена правильно и используется тотже SCRUM то переработки минимальны и то в случае непредвиденных обстоятельств. Я, для примера, за более чем пол года работы «под скрам» работал сверхурочно 2 раза. И то изза багов в железе.
Если оценка проведена правильно и используется тотже SCRUM то переработки минимальны и то в случае непредвиденных обстоятельств. Я, для примера, за более чем пол года работы «под скрам» работал сверхурочно 2 раза. И то изза багов в железе.
CMMI не требует ничего конкретного. В частности, многие agile-практики с ним вполне себе уживаются. Обычно он касается организации на более высоком уровне, а как кому удобно колбасить код — это уже не так важно.
Хочу еще добавить, что Agile — это не методология, а подход к процессу. В котором не обязательны стендапы, комментарии в коде. а всего лишь:
Люди и взаимодействие важнее процессов и инструментов
Работающий продукт важнее исчерпывающей документации
Сотрудничество с заказчиком важнее согласования условий контракта
Готовность к изменениям важнее следования первоначальному плану
(да, Agile манифест)
Все остальное — домыслы.
Люди и взаимодействие важнее процессов и инструментов
Работающий продукт важнее исчерпывающей документации
Сотрудничество с заказчиком важнее согласования условий контракта
Готовность к изменениям важнее следования первоначальному плану
(да, Agile манифест)
Все остальное — домыслы.
Совершенно верно, но в жизни работодатель обычно не говорит: «у нас Scrum» или «у нас XP».
Большинство контор называют свой процесс «кастомизированный Agile», вставляя в данный подход к процессу элементы из разных методологий.
Большинство контор называют свой процесс «кастомизированный Agile», вставляя в данный подход к процессу элементы из разных методологий.
Проблема в том, что в таких конторах часто получается формальный кастомизированный Scrum, а Agile там и не пахнет :(
Можо сделать гибкий waterfall — и он будет работать гораздо круче таких подходов.
А можно внедрить Scrum, но толку не будет никакого. Но зато всем можно рассказывать, что «у нас Agile» :)
Можо сделать гибкий waterfall — и он будет работать гораздо круче таких подходов.
А можно внедрить Scrum, но толку не будет никакого. Но зато всем можно рассказывать, что «у нас Agile» :)
Про кастомизированный Scrum в большинстве «Agile» контор я полностью согласен, но почему там обычно не пахнет самим Agile?
А чем гибкий waterfall круче Scrum?
А чем гибкий waterfall круче Scrum?
Как по мне не круче. На прошлой работе он был гибкий в плане того что:
1. Сроки мы вам не скажем.
2. Делайте то что запланировали не следующий месяц вчера.
3. А теперб сделайте то что не собирались. И завтра должно быть готово.
З.Ы. Хотя не могу понять почему это считалось ватерфолом. Наверное совсем гибко было.
1. Сроки мы вам не скажем.
2. Делайте то что запланировали не следующий месяц вчера.
3. А теперб сделайте то что не собирались. И завтра должно быть готово.
З.Ы. Хотя не могу понять почему это считалось ватерфолом. Наверное совсем гибко было.
потому что делать Scrum и быть Agile — это разные вещи :)
Если команда заявляет, что «мы не пишим документацию, потому что мы Agile» — это плохой признак.
Если команда заявляет, что «мы не можем поменять таски в итерации, потому что у нас Scrum» — это тоже плохой признак.
Если при проблемах с клиентом люди начинают тыкать в договор — это очень плохой признак.
И если вместо решения проблем начинают заявлять «у нас процесс такой» — все очень печально :)
Если команда заявляет, что «мы не пишим документацию, потому что мы Agile» — это плохой признак.
Если команда заявляет, что «мы не можем поменять таски в итерации, потому что у нас Scrum» — это тоже плохой признак.
Если при проблемах с клиентом люди начинают тыкать в договор — это очень плохой признак.
И если вместо решения проблем начинают заявлять «у нас процесс такой» — все очень печально :)
Скрам стоит использовать, когда не очень понятно, что будет дальше и долгосрочное планирование не работает.
Ватерфол наоборот — хорошо работает, когда план уже понятен. Такое вполне бывает.
У меня знакомые собираются выпускать приложение, но сами проргаммировать не умеют, будут заказывать.
При этом они 3 месяца валидируют идею, собирают прототипы на моках, делают дизайн, тестируют на пользователях.
В итоге — при самой разработке там скрам нафик не нужен, просто за 2 недели оживить прототип, все остальное готово. Есть ТЗ, бери и делай по нему, ничего меняться уже не будет, все давно проверено.
Ватерфол наоборот — хорошо работает, когда план уже понятен. Такое вполне бывает.
У меня знакомые собираются выпускать приложение, но сами проргаммировать не умеют, будут заказывать.
При этом они 3 месяца валидируют идею, собирают прототипы на моках, делают дизайн, тестируют на пользователях.
В итоге — при самой разработке там скрам нафик не нужен, просто за 2 недели оживить прототип, все остальное готово. Есть ТЗ, бери и делай по нему, ничего меняться уже не будет, все давно проверено.
Позволю себе уточнить пару моментов:
1. TDD, BDD и прочее неизбежно приводят Вас к качественному коду, если, конечно, овладеть умением писать хорошие тесты;
2. При всем стремлении к качеству кода, я почти на 100% уверен, что некоторые его места практически невозможно протестировать в виду тех или иных технических решений, принятых без учета тестирования;
Тестируемость кода, есть один из критериев его качества, на мой взгляд.
А по времени — разработчик, хорошо владеющий TDD (BDD) выдает «на-гора» протестированный платформо-браузеро-БД-независимый код за тоже время, что тратит «write-build-press-print-debug» разработчик на создание такого же функционала, но без всего этого сахара. Не хочу никого обидеть, просто мне не доводилось работать с людьми, которые пишут код круто и с первого раза. Про таких ходят легенды…
P.S.: я просто очень люблю юнит-тесты :)
1. TDD, BDD и прочее неизбежно приводят Вас к качественному коду, если, конечно, овладеть умением писать хорошие тесты;
2. При всем стремлении к качеству кода, я почти на 100% уверен, что некоторые его места практически невозможно протестировать в виду тех или иных технических решений, принятых без учета тестирования;
Тестируемость кода, есть один из критериев его качества, на мой взгляд.
А по времени — разработчик, хорошо владеющий TDD (BDD) выдает «на-гора» протестированный платформо-браузеро-БД-независимый код за тоже время, что тратит «write-build-press-print-debug» разработчик на создание такого же функционала, но без всего этого сахара. Не хочу никого обидеть, просто мне не доводилось работать с людьми, которые пишут код круто и с первого раза. Про таких ходят легенды…
P.S.: я просто очень люблю юнит-тесты :)
1. Не верю, что TDD приводит к качественному коду. Ну написал я тесты, потом написал код, чтобы они проходили и чего?
Может быть вы еще считаете, что тестирование (любого вида) способно выявить насколько код легко масштабируем, читаем и легок для изменений в будущем?
2. Вы имеете ввиду, что ручным тестированием нельзя проверить работоспособность всего кода? Согласен. Правда, не факт, что такие части вообще стоит тестировать, если они никак не заметны для конечного пользователя.
Но вообще я не против юнит-тестов, просто они должны быть для конкретной задачи — скажем, для быстрого прогона автоматической регрессии после каждого билда. А вот когда весь код пишется с юнит-тестами — это обычно чрезмерный оверхед в разработке для красивой отчетности менеждеров.
Может быть вы еще считаете, что тестирование (любого вида) способно выявить насколько код легко масштабируем, читаем и легок для изменений в будущем?
2. Вы имеете ввиду, что ручным тестированием нельзя проверить работоспособность всего кода? Согласен. Правда, не факт, что такие части вообще стоит тестировать, если они никак не заметны для конечного пользователя.
Но вообще я не против юнит-тестов, просто они должны быть для конкретной задачи — скажем, для быстрого прогона автоматической регрессии после каждого билда. А вот когда весь код пишется с юнит-тестами — это обычно чрезмерный оверхед в разработке для красивой отчетности менеждеров.
Весь код с unit tests — это, в первую очередь, удобно.
Благодаря им есть чёткий критерий завершённости работы над feature/bugfix и лёгкий способ проверить «а не сломал ли я попутно что-нибудь?».
Благодаря им есть чёткий критерий завершённости работы над feature/bugfix и лёгкий способ проверить «а не сломал ли я попутно что-нибудь?».
Поймите меня правильно. Я не стремлюсь кого-то убедить или же доказать истинность того, что я написал. Это просто моя точка зрения. И выводы сделаны из личного опыта.
По порядку:
Это действительно так (в смысле действительно приводит), если изменить свое отношение к тестам и понимание их смысла. Простите за отсутствие конкретики. Для полноценного объяснения потребуется написать статью (я постараюсь это сделать в ближайшее время).
elkews, Вы не будете возражать, если я положу нашу с Вами дискуссию в основу статьи на Хабре?
По порядку:
1. Не верю, что TDD приводит к качественному коду. Ну написал я тесты, потом написал код, чтобы они проходили и чего?
Это действительно так (в смысле действительно приводит), если изменить свое отношение к тестам и понимание их смысла. Простите за отсутствие конкретики. Для полноценного объяснения потребуется написать статью (я постараюсь это сделать в ближайшее время).
Может быть вы еще считаете, что тестирование (любого вида) способно выявить насколько код легко масштабируем, читаем и легок для изменений в будущем?Нет, это не так. Масштабиреум — неверное да. Читаем — совсем не обязательно. Легок для изменений в будущем — да, потому что есть тесты в качестве regression.
Вы имеете ввиду, что ручным тестированием нельзя проверить работоспособность всего кода?Нет, я не об этом. Просто определенные вещи нельзя покрыть юнит-тестами, если не думать об этом заранее. Думаю всем поклонникам TDD известно, что паттерн Singleton не есть хорошо. Его поведение только мешает тестированию.
elkews, Вы не будете возражать, если я положу нашу с Вами дискуссию в основу статьи на Хабре?
0xFE, конечно я не буду возражать. Мне нравится, что вы не раздражаетесь, а спокойно отстаиваете свою точку зрения.
Я даже готов буду с вами подискутировать, если это будет нужно =)
Я даже готов буду с вами подискутировать, если это будет нужно =)
Судя по всему, у вас там Scrum с XP. И после статьи первая мысль — куда смотрим ваш Скрам-мастер? У него явно много работы :)
Меняющиеся требования и отменённые фичи — эти пункту в минусах намекают, что программисты еще не восприняли Agile как образ мышления. Над этим важно работать :)
Проблемы с дизайнерами — это намекает, что что-то не так с планированием и взаимодействием между людьми. Надо общаться с дизайнерами и планировать вместе, слушая друг друга :)
Потеря времени во время стендапов — меняйте формат стендапов, чтобы вовлекать всех в обсуждение, а не просто отчитываться :)
Личная жизнь — если это происходит часто, то опять же, у вас серьезные проблемы с планированием :)
Плохой код, TDD и парная разработка — это все нужно, чтобы проргаммист чаще проверял свой код. Если этого не делать — тестировщики будут перегружены лишней работой, а их часто в команде меньше. Поэтому тратить их время на то, что может сделать и проверить сам программист — не выгодно :)
В целом: манифест — это не громкие слова, а способ избежать кучи проблем :)
Меняющиеся требования и отменённые фичи — эти пункту в минусах намекают, что программисты еще не восприняли Agile как образ мышления. Над этим важно работать :)
Проблемы с дизайнерами — это намекает, что что-то не так с планированием и взаимодействием между людьми. Надо общаться с дизайнерами и планировать вместе, слушая друг друга :)
Потеря времени во время стендапов — меняйте формат стендапов, чтобы вовлекать всех в обсуждение, а не просто отчитываться :)
Личная жизнь — если это происходит часто, то опять же, у вас серьезные проблемы с планированием :)
Плохой код, TDD и парная разработка — это все нужно, чтобы проргаммист чаще проверял свой код. Если этого не делать — тестировщики будут перегружены лишней работой, а их часто в команде меньше. Поэтому тратить их время на то, что может сделать и проверить сам программист — не выгодно :)
В целом: манифест — это не громкие слова, а способ избежать кучи проблем :)
Поэтому тратить их время на то, что может сделать и проверить сам программист — не выгодно :)
Не выгодно тратить время программистов на то что может быть проверенно автоматически) Теми-же юнит тестами.
Чтобы откуда-то появились юнит-тесты, программист сначала должен их написать.
Не во всех проектах целесообразно городить этот огород (как правило, чем больше и сложнее, тем целесообразнее).
Не во всех проектах целесообразно городить этот огород (как правило, чем больше и сложнее, тем целесообразнее).
По-моему, здесь нет противоречия :)
Просто тратить время тестировщиков на написание юнит-тестов — чаще всего не выгодно, дешевле это повесить на разработчиков :)
Просто тратить время тестировщиков на написание юнит-тестов — чаще всего не выгодно, дешевле это повесить на разработчиков :)
Sign up to leave a comment.
Agile с точки зрения программиста