Надо завидовать белой и стремиться к лучшему. Эти ребята еще круче сделали, с полным циклом от приемочных критериев до тестов с детальными отчетами по покрытию функциональности. Вот ссылка на их прошлое выступление.
Это открывает врата соблазна всю халтуру списывать на технический долг, а соответственно разрешает делать халтуру в принципе. Если за этим не углядеть, то может быть пичалька…
Про фреймворк спросил, потому что мне очень не нравится подход с хранением шагов в javadoc. Нужно постоянно заботиться об их синхронности с тестом, что нелегко при постоянно меняющихся тестах. Взгляните на систему отчетов Thucydides — там все генерируется из тестового кода, шаги легко повторно использовать, привязка к требованиям через аннотации и куча полезностей. Наличие своего фреймворка не преграда, знаю команды, которые перешли с самописных и очень счастливы.
Еще пара советов по вашей статье:
— если вы для каждого элемента имеете ID, то используйте CSS локатор #my_id или на крайний случай оптимизированный XPath локатор id(«my_id») на основе функций XPath
— EMMA как инструмент для измерения покрытия кода отмирает, в Java мире сейчас принято использовать JaCoCo
Из описанного у вас достаточно стройная и эффективная система. Есть два вопроса: почему вы не используете распространенный шаблон PageObject (по крайней мере такое ощущение сложилось из ваших примеров) и почему не взяли за основу существующий фреймворк, например Thucydides?
С техническим долгом могут помочь также статические анализаторы. Помимо отлавливания общих проблем в коде и агрегации результатов, они могут также обрабатывать архитектурные проблемы в виде todo специального типа. Но это предполагает, что все честные и, вставляя костыль, добавляют todo с описанием проблемы и рисков с ней связанных. Тогда статический анализатор сводит все воедино и некоторые даже считают технический долг по заданным параметрам, переводя его в человеко-часы и деньги.
Бороться с такой ленью достаточно просто — надо работать в паре на таких задачах. Но это в предположении, что не вся команда одновременно ленится. На ежедневном митинге, если видно что человек не укладывается в командную оценку, то он объясняет какие есть сложности. Если у техлида или кого-то другого есть подозрение на лень, то он может просто предложить доделать задачу в паре. А а в паре лениться гораздо сложнее.
Мы практикуем решение таких задач в отдельных бранчах с указанием, что этот код был «просто написан», чтобы потом к нему не было доверия на том же уровне как к остальному коду. Тогда для разовых задач или прототипов это вполне приемлемый подход. Не так давно обсуждали это в другой ветке.
1. Дедлайны всегда есть, просто в скраме под них подгоняется скоуп (сколько успеем сделать к дате дедлайна). Есть альтернативный подход с датами дедлайна в зависимости от времени на фиксированный скоуп. Но без дедлайнов разработка практически возможна только в теории. «Команда работает сколько нужно» — идеализированный подход для сверхкоманды, да и то на нее будет действовать закон Паркинсона.
2. Тут я с вами согласен по поводу необходимости требований и формат User Story мне тоже нравится. Но в скраме он не предписывается в качестве обязательного. Знаю много команд, в которых замечательно работают в скраме другие процессы управления требованиями.
3. При таком подходе вы все дальше от Continuous Delivery. Вы же сами в первом пункте сказали, что стори готова когда команда сказала «ГОТОВО». Так о каких доработках и фиксах идет речь? Это в простонародье называется стабилизационной итерацией и многие считают это антипаттерном.
4. Тут я снова с вами соглашусь. Есть соблазн «немного поднажать», но он может привести к плохим последствиям.
А вот по поводу снижения темпа я с вами категорически не согласен. Тут речь не только о стабильности, но и о скорости разработки. На протяжение итерации команду не отвлекают разной ерундой, на планировании и в ходе разработки дают все необходимое, не давят по срокам, все прозрачно и контролируемо. Поэтому при правильном применении скрама скорость разработки не падает.
Agile не спасет проект, в котором не было требований ни в каком более-менее адекватном виде. Так же как и проект-калеку на костылях. Это миф, который многие (а именно адепты Scrum, но далеко не все) пытаются успешно продавать.
А довел до текущего состояния еще один интересный миф из мира стартапов — можно делать как угодно, лишь бы быстрей взлететь. Так действительно в большей части делать разумно, но есть нюанс — долго так не протянуть. Обычно люди просто читают между строк и этот факт упускают. А дальше аргументация «мы как все другие стартапы, посмотрите по сторонам»…
Я сейчас умру от смеха. То есть «если бы вы знали базовую теорию», «прочтя несколько поверхностных книжек», «очень смешно выглядит», «выгодно только если вы срам-тренер, чтобы продавать свои услуги», «выглядит откровенно бредовой», «еще более бредово», «маркетинговый тренерский буллшит» и прочие ваши реплики — это вовсе не прямые оскорбления??? А меня вы совершенно не задели, я таких как вы встречаю пачками и переходить на грубости для меня просто не имеет смысла, иначе бы я только ходил и ругался. Продолжить в личном общении я предложил, потому что ваши доводы ходят по кругу и мы просто тратим понапрасну время на написание комментариев, которые никому не интересны…
Ваше маленькое эго не дает вам покоя. Вы точно знаете какие книжки и сколько я прочитал, что я — один из никчемных скрам тренеришек, которые жизни то и не видели, зарабатывая на краюху хлеба обманом и мошенничеством, что системности во мне нет и не будет… Если очень хотите помериться, то можете отписаться мне в скайп или на почту. Обсудим и прочитанные книжки и опыт и образование.
Вы опять мимо! Я не Scrum тренер. И даже не сертифицированный ScrumMaster. Консультирую по Scrum только когда обращаются компании. Но вам разве это можно доказать? Трололо в вас никогда не признает истины (смотрите картинку выше).
По поводу Тойоты я вам ответил в следующем же комментарии с примером из разработки. Нарушать NDA из-за трололо не вижу никакого смысла. Таких проектов полно и можете посмотреть публичные доклады как там все делается (примеры я приводил в самых первых комментариях, видео есть на InfoQ).
Мы говорим не о «теории информационных систем», а о практической действительности. Вы намешали в единую кучу и бизнес метрики и метрики процесса разработки. Количество багов никак не меряет степень соответствия спецификациям, которых во многих проектах формально и нет. «Как же тогда контролировать качество?» — воскликните вы. «Ведь в теории информационных систем и втором томе описания RUP четко сказано...». Так вот в жизни все гораздо проще. Продукт разбивают на инкременты и делают их итеративно. Качество контролируется после сдачи каждой итерации. Также в виде автоматизированных тестов или примеров поведения (в BDD) фиксируется, что на тот момент считалось качественным. После этого качество контролируется самостоятельно запуском этих тестов.
Я ни с кем никогда не начинаю мериться. Тут просто некоторые товарищи, включая вас, любят переходить на личности. Вы многократно подчеркнули, что вы преподаватель, что в моей статье полно бреда, булшита, несистемности, отсутствия четкой терминологии… Очень напоминает вот это:
Если вы уже решили перейти на личности и светануть в качестве аргумента моим профилем в LinkedIn, то хочу вас уведомить о специфике своей работы в компании. Я занимаюсь запуском заказных продуктов с нуля. В большинстве своем это сложные распределенные системы: социальные сети, программы лояльности, интеллектуальные краулеры интернета. Два проекта в 2011 году вошли в топ 100 мировых успешных стартапов. Так что это не тот классический аутсорсинг, о котором вы по выходным читаете в уютном кресле за чашкой чая. И описанные в статье подходы отлично работали и работают по сей день.
Вы видимо мало что слышали о современных подходах к разработке и тестированию: Scrum, XP, Kanban. Я уже не говорю про Lean философию и Agile принципы в целом.
Отдельное спасибо за «деформацию мышления» и сомнения в моих обучающих способностях, в которых вы не имели возможности убедиться лично.
Еще пара советов по вашей статье:
— если вы для каждого элемента имеете ID, то используйте CSS локатор #my_id или на крайний случай оптимизированный XPath локатор id(«my_id») на основе функций XPath
— EMMA как инструмент для измерения покрытия кода отмирает, в Java мире сейчас принято использовать JaCoCo
1. Дедлайны всегда есть, просто в скраме под них подгоняется скоуп (сколько успеем сделать к дате дедлайна). Есть альтернативный подход с датами дедлайна в зависимости от времени на фиксированный скоуп. Но без дедлайнов разработка практически возможна только в теории. «Команда работает сколько нужно» — идеализированный подход для сверхкоманды, да и то на нее будет действовать закон Паркинсона.
2. Тут я с вами согласен по поводу необходимости требований и формат User Story мне тоже нравится. Но в скраме он не предписывается в качестве обязательного. Знаю много команд, в которых замечательно работают в скраме другие процессы управления требованиями.
3. При таком подходе вы все дальше от Continuous Delivery. Вы же сами в первом пункте сказали, что стори готова когда команда сказала «ГОТОВО». Так о каких доработках и фиксах идет речь? Это в простонародье называется стабилизационной итерацией и многие считают это антипаттерном.
4. Тут я снова с вами соглашусь. Есть соблазн «немного поднажать», но он может привести к плохим последствиям.
А вот по поводу снижения темпа я с вами категорически не согласен. Тут речь не только о стабильности, но и о скорости разработки. На протяжение итерации команду не отвлекают разной ерундой, на планировании и в ходе разработки дают все необходимое, не давят по срокам, все прозрачно и контролируемо. Поэтому при правильном применении скрама скорость разработки не падает.
А довел до текущего состояния еще один интересный миф из мира стартапов — можно делать как угодно, лишь бы быстрей взлететь. Так действительно в большей части делать разумно, но есть нюанс — долго так не протянуть. Обычно люди просто читают между строк и этот факт упускают. А дальше аргументация «мы как все другие стартапы, посмотрите по сторонам»…
Вы видимо мало что слышали о современных подходах к разработке и тестированию: Scrum, XP, Kanban. Я уже не говорю про Lean философию и Agile принципы в целом.
Отдельное спасибо за «деформацию мышления» и сомнения в моих обучающих способностях, в которых вы не имели возможности убедиться лично.