>> Про виноватых вопрос тоже хорош - все косячили, а крайней назначили меня, эй, я программист, я делаю свою работу, я не отвечаю за то, что менеджер идиот, и, кстати, грозил снижением премии за отказ от выполнения ненужной задачи.
это про черную пятницу?
ну вот я тоже так подумал, что все виноваты кроме я, но с другой стороны... например, заказчик, что он такого сделал? он просто сделал заказ, потом передумал. Все норм, имеет право.
Заказчик говорил, что функциональность будет простой, а потом усложнял и усложнял? Ну это просто классика жанра, такое вообще каждый раз почти происходит. Ошибка в том, что разработчик - соглашался (из лучших побуждений). Я много раз на это попадался но вот, думаю, это не свидетельствовало обо мне как он профессионале...
Автор считает, что разработчик профессионал должен говорить "Да, я успею" только если он действительно понимает что он успеет. Или даже он должен дать вероятностную оценку (об этом в других главах книги). Если он не понимает задачи/рисков, то он должен сказать - "я не знаю". Это будет сигнал для того, чтобы заказчик/менеджер уточнили бы требования и тд и тп.
Самое ужасное, по мнению автора, это то, что разработчик начал ухудшать качество. Тут просто у Р. Мартина есть мнение, что самое быстрое - это двигаться через максимальное качество. Почему - можно в книге почитать.
Кстати, в данном примере заказчик то не пострадал, им приложение и не понадобилось. Больше всего пострадал сам разработчик, который работал по 20 часов впустую. Вообще прочитайте сами этот кейс в книге - там он анализируется гораздо более глубоко. Плюс почитайте саму реальную ситуацию - http://raptureinvenice.com/is-good-code-impossible/.
>> Пункт про то, что работодатель не должен предоставлять условия для развития, - это вообще прекрасно, старых выбрасываем, набираем новых умных.
эээ ну там все совсем по другому вообще-то, даже есть пояснение в ответах ))
автор считает, что профессионал должен сам держать в руках свою карьеру, а не уповать на дядю, он должен сам стремиться развиваться и изучать то, что он считает правильным... если работодатель помогает, супер, это хорошо мне кажется тут больше вопрос про пассивную/активную жизненную позицию в вопросе своей карьеры
Ну вообще логика автора достаточно категоричная, но в целом заставляет задуматься:
Профессионал должен отдавать полностью рабочий код, он не должен заранее допускать, что там половина или 30% фич может не работать. Согласны? мне кажется логично...
Как вам гарантировать что функция будет работать? по мнению автора - это только написать автоматизированный тест. Вроде тоже логично, тк ручное тестирование - это долго, субъективно... сначала может и можно что-то протестить руками, но после некоторого времени протестировать руками все затронутые варианты становится просто невозможно
отсюда автор делает вывод, что нужно асимптотически стремиться к 100%... те понятно что 100% вы не получите, но цель ставить - 100%... ставить себе достаточный критерий, например, 70% - по логике автора неправильно
Сразу скажу, что я тут не рву на себе рубашку чтобы защитить точку зрения автора, на моем текущем проекте покрытие чуть более 70%, но фиг знает, может большее покрытие окажется более экономически эффективным.
Вообще у меня знакомый в фейсбуке работает, так у них в команде нет тестеров вообще. Разработчики сами все тестируют и выкатываю в прод. Как они это делают? У них это высокое покрытие кода автотестами + всякие там канареечные релизы. Честно говоря не знаю насколько это распространенная практика в интернет-компаниях, может тут есть кто от туда - поделитесь опытом? Может из гугла кто? или Яндекса? или из еще каких-то ИТ-компаний лидеров есть тут?
Мы не отказывались от оценки скоупа и планирования, мы просто избавили разработчиков от этого :-)
в статье коротко я написал о том как мы планируем и вычисляем сроки:
Мы отказались от традиционного планирования этапов с помощью диаграмм Ганта и оценок задач с привлечением разработчиков. Теперь используем прогнозирование с помощью имеющейся статистики. Главный аналитик оценивает количество историй, которые нужно реализовать для каждого блока функциональности, техлид смотрит, нет ли особенно рискованных требований - сопоставляем имеющиеся у нас возможности с потребностями заказчика. Если видим расхождения, то обсуждаем сами задачи и ищем решение, как уменьшить объем (предпочитаемый способ). Если так не получается, то тогда думаем над тем как увеличить команду.
Суть в том, что SpaceX не пытается идти каскадным подходом — они не пытаются сделать детальный техпроект сразу на финальное изделие, разработать сразу чертежи финальной версии ракеты и не пытаются сразу строить сразу итоговую ракету. Вот о чем здесь идет речь.
Мне кажется должно было быть понятно, что я хотел сказать… но, возможно, стоило вообще прямым текстом эту мысль написать, чтобы было еще понятнее…
>> Во вторых…
Полностью с вами согласен )). Даже не знаю к чему вы это пишите…
У нас есть несколько профессиональных QA, которые уже тестируют задачи когда разработчик перекинул в Ready for Test. Аналитики сами тоже тестируют.
У нас нет задач на тестирование, задача просто проходит все этапы начиная с в анализе и тд то этапа «в тестировании». Статистика по тому сколько времени задачи находится в тестировании в принципе есть, но мы на ней не фокусируемся, тк считаем, что более правильно смотреть на общее время производства задачи, а не на отдельные этапы.
Плюс у нас делается смоук/мини регресс каждый день перед выпуском тоже специалистом QA.
QA непосредственно постановку задачи не вырабатывают, но у нас принято обсуждать «эпики» всей командой (аналитик рассказывает коротко в чем суть, пробегает по макетам экранов и тд) — там QA тоже участвуют.
Да, это главное опасение. Есть рациональные аргументы в пользу «формализации» работы с заказчиком, есть аргументы в пользу его более тесного вовлечения.
Я думаю, некоторые вопросы сложно рационально объяснить и иногда надо сделать прыжок веры. Мне нравится тут подход Джефа Безоса, который говорит, что если вы не знаете что делать, то выбирайте вариант, который больше подходит клиенту.
Я верю, что для заказчика лучше вариант, когда мы работаем прозрачно, когда очень рано показываем свои решения и оперативно получаем обратную связь. В этом случае результат будет лучше для заказчика и его удовлетворенность от работы с нами вырастет. А если удовлетворенность вырастет, то возникнет другой уровень доверия и можно будет стараться подходить к описываемым вами ситуациям с позиции win-win.
1. Вопрос учитываем ли мы где-то время для бюджетирования? да, все участники проекта учитывают время нашей трекинговой системе. Но учет времени очень укрупненный — по задачам в джира мы время не трекаем.
2. У нас нет задач на анализ или на разработку. Задача одна и та же — она проходит разные стадии просто.
А на чем поиск делаете?
Что используете для полнотекстового поиска и для фасетного?
Какую бд используете для хранения товаров/лотов и их характеристик?
На чем ui пишете?
Есть такое. Признаюсь мне читать эту книгу было легче на английском. Некоторые термины прямо жутко режут глаз. Ну что делать, все равно лучше на нормальном русском потихоньку начинать разговаривать, а не одними англицизмами ))
да ладно, тут же не автомобиль разыгрывается )) мы все на доверии
я подумал, что полезнее дать ответы и пояснения, чем попытаться выяснить супер победителя
Спасибо за статью!
Вы пишете что вы хотите перейти на событийную архитектуру. Но при этом, вроде бы, решили другую задачу — синхронизировали таблицы (те по сути построили такую большую мат вьюху).
Мне кажется если мы говорим про события, то речь идет о следующем: сервис генерирует событие (как бы факт), это событие кидается в топик и куча других сервисов подписывается на эти события и как-то на них реагируют. Суть именно в возможности отреагировать на событие.
Если мы говорим о синхронизации таблиц — то мы просто хотим чтобы данные были одинаковые и мы никак нам особо ничего не надо делать при их изменении. Например, НСИ часто нам нужно просто синхронизировать, но никак не надо реагировать на изменение позиций в справочнике. Я правильно понимаю, что вы решали именно задачу синхронизации НСИ?
Есть ли у вас именно события? Если да, то интересно как вы обеспечиваете целостность при записи в Kafka?
Подскажите, пожалуйста, как часто вы выкатываете релизы на прод?
Используете ли вы кросфункциональнвн продуктовые / фича команды? Если да, то какого размера?
Какое у вас среднее время производства фичи? ( ну типа от момента когда взяли в работу и до выпуска на прод?)
Очень интересная реконструкция истории создания авто ).
По поводу того, что ПО имеет максимальную экономию на масштабе после того как оно разработано — об этом автор прямо пишет.
Однако будьте аккуратны: после того, как программное обеспечение разработано, эффект экономии на масштабе становится неограниченным. Мир переключается. Созданное программное обеспечение, вероятно, демонстрирует большую экономию на масштабе, чем любой другой продукт, известный человеку. (С экономической точки зрения, затраты на изготовление первого экземпляра чрезвычайно высоки, но затраты на изготовление идентичной копии (изготовление) по сути близки к нулю — «Ctrl-C Ctrl-V»).
Не очень понял в итоге с чем вы согласны или не согласны. Поясните, пожалуйста.
в смысле???
попытка получить экономию на масштабе в разработке ПО (по автору) — это когда вы пытаетесь разрабатывать и поставлять ПО большими релизами и мотивируете это тем, что много требований будет за раз реализовать эффективнее, чем если бы вы эти требования реализовывали маленькими партиями (релизами/версиями).
Выкопать ровную, соответствующую определённым допускам по ширине, глубине и полосе отвода (которые тоже проверяются вручную), траншею длиной 100 км силой только 500 землекопов с лопатой будет дороже, чем 100 участков по одному километру
>> Про виноватых вопрос тоже хорош - все косячили, а крайней назначили меня, эй, я программист, я делаю свою работу, я не отвечаю за то, что менеджер идиот, и, кстати, грозил снижением премии за отказ от выполнения ненужной задачи.
это про черную пятницу?
ну вот я тоже так подумал, что все виноваты кроме я, но с другой стороны... например, заказчик, что он такого сделал? он просто сделал заказ, потом передумал. Все норм, имеет право.
Заказчик говорил, что функциональность будет простой, а потом усложнял и усложнял? Ну это просто классика жанра, такое вообще каждый раз почти происходит. Ошибка в том, что разработчик - соглашался (из лучших побуждений). Я много раз на это попадался но вот, думаю, это не свидетельствовало обо мне как он профессионале...
Автор считает, что разработчик профессионал должен говорить "Да, я успею" только если он действительно понимает что он успеет. Или даже он должен дать вероятностную оценку (об этом в других главах книги). Если он не понимает задачи/рисков, то он должен сказать - "я не знаю". Это будет сигнал для того, чтобы заказчик/менеджер уточнили бы требования и тд и тп.
Самое ужасное, по мнению автора, это то, что разработчик начал ухудшать качество. Тут просто у Р. Мартина есть мнение, что самое быстрое - это двигаться через максимальное качество. Почему - можно в книге почитать.
Кстати, в данном примере заказчик то не пострадал, им приложение и не понадобилось. Больше всего пострадал сам разработчик, который работал по 20 часов впустую.
Вообще прочитайте сами этот кейс в книге - там он анализируется гораздо более глубоко. Плюс почитайте саму реальную ситуацию - http://raptureinvenice.com/is-good-code-impossible/.
>> Пункт про то, что работодатель не должен предоставлять условия для развития, - это вообще прекрасно, старых выбрасываем, набираем новых умных.
эээ ну там все совсем по другому вообще-то, даже есть пояснение в ответах ))
автор считает, что профессионал должен сам держать в руках свою карьеру, а не уповать на дядю, он должен сам стремиться развиваться и изучать то, что он считает правильным... если работодатель помогает, супер, это хорошо
мне кажется тут больше вопрос про пассивную/активную жизненную позицию в вопросе своей карьеры
Ну вообще логика автора достаточно категоричная, но в целом заставляет задуматься:
Профессионал должен отдавать полностью рабочий код, он не должен заранее допускать, что там половина или 30% фич может не работать. Согласны? мне кажется логично...
Как вам гарантировать что функция будет работать? по мнению автора - это только написать автоматизированный тест. Вроде тоже логично, тк ручное тестирование - это долго, субъективно... сначала может и можно что-то протестить руками, но после некоторого времени протестировать руками все затронутые варианты становится просто невозможно
отсюда автор делает вывод, что нужно асимптотически стремиться к 100%... те понятно что 100% вы не получите, но цель ставить - 100%... ставить себе достаточный критерий, например, 70% - по логике автора неправильно
Сразу скажу, что я тут не рву на себе рубашку чтобы защитить точку зрения автора, на моем текущем проекте покрытие чуть более 70%, но фиг знает, может большее покрытие окажется более экономически эффективным.
Вообще у меня знакомый в фейсбуке работает, так у них в команде нет тестеров вообще. Разработчики сами все тестируют и выкатываю в прод. Как они это делают? У них это высокое покрытие кода автотестами + всякие там канареечные релизы. Честно говоря не знаю насколько это распространенная практика в интернет-компаниях, может тут есть кто от туда - поделитесь опытом? Может из гугла кто? или Яндекса? или из еще каких-то ИТ-компаний лидеров есть тут?
Почему?
Мы не отказывались от оценки скоупа и планирования, мы просто избавили разработчиков от этого :-)
в статье коротко я написал о том как мы планируем и вычисляем сроки:
Мы отказались от традиционного планирования этапов с помощью диаграмм Ганта и оценок задач с привлечением разработчиков. Теперь используем прогнозирование с помощью имеющейся статистики. Главный аналитик оценивает количество историй, которые нужно реализовать для каждого блока функциональности, техлид смотрит, нет ли особенно рискованных требований - сопоставляем имеющиеся у нас возможности с потребностями заказчика. Если видим расхождения, то обсуждаем сами задачи и ищем решение, как уменьшить объем (предпочитаемый способ). Если так не получается, то тогда думаем над тем как увеличить команду.
На самом деле я больше смотрю на тренды, а не на медианы или процентили.
Нет, у нас с заказчиком нет SLA. Про медиану - так для статьи написал. На графиках можно увидеть другие процентили
Мне кажется должно было быть понятно, что я хотел сказать… но, возможно, стоило вообще прямым текстом эту мысль написать, чтобы было еще понятнее…
>> Во вторых…
Полностью с вами согласен )). Даже не знаю к чему вы это пишите…
У нас нет задач на тестирование, задача просто проходит все этапы начиная с в анализе и тд то этапа «в тестировании». Статистика по тому сколько времени задачи находится в тестировании в принципе есть, но мы на ней не фокусируемся, тк считаем, что более правильно смотреть на общее время производства задачи, а не на отдельные этапы.
Плюс у нас делается смоук/мини регресс каждый день перед выпуском тоже специалистом QA.
QA непосредственно постановку задачи не вырабатывают, но у нас принято обсуждать «эпики» всей командой (аналитик рассказывает коротко в чем суть, пробегает по макетам экранов и тд) — там QA тоже участвуют.
Я думаю, некоторые вопросы сложно рационально объяснить и иногда надо сделать прыжок веры. Мне нравится тут подход Джефа Безоса, который говорит, что если вы не знаете что делать, то выбирайте вариант, который больше подходит клиенту.
Я верю, что для заказчика лучше вариант, когда мы работаем прозрачно, когда очень рано показываем свои решения и оперативно получаем обратную связь. В этом случае результат будет лучше для заказчика и его удовлетворенность от работы с нами вырастет. А если удовлетворенность вырастет, то возникнет другой уровень доверия и можно будет стараться подходить к описываемым вами ситуациям с позиции win-win.
2. У нас нет задач на анализ или на разработку. Задача одна и та же — она проходит разные стадии просто.
А на чем поиск делаете?
Что используете для полнотекстового поиска и для фасетного?
Какую бд используете для хранения товаров/лотов и их характеристик?
На чем ui пишете?
я подумал, что полезнее дать ответы и пояснения, чем попытаться выяснить супер победителя
Вы пишете что вы хотите перейти на событийную архитектуру. Но при этом, вроде бы, решили другую задачу — синхронизировали таблицы (те по сути построили такую большую мат вьюху).
Мне кажется если мы говорим про события, то речь идет о следующем: сервис генерирует событие (как бы факт), это событие кидается в топик и куча других сервисов подписывается на эти события и как-то на них реагируют. Суть именно в возможности отреагировать на событие.
Если мы говорим о синхронизации таблиц — то мы просто хотим чтобы данные были одинаковые и мы никак нам особо ничего не надо делать при их изменении. Например, НСИ часто нам нужно просто синхронизировать, но никак не надо реагировать на изменение позиций в справочнике. Я правильно понимаю, что вы решали именно задачу синхронизации НСИ?
Есть ли у вас именно события? Если да, то интересно как вы обеспечиваете целостность при записи в Kafka?
Подскажите, пожалуйста, как часто вы выкатываете релизы на прод?
Используете ли вы кросфункциональнвн продуктовые / фича команды? Если да, то какого размера?
Какое у вас среднее время производства фичи? ( ну типа от момента когда взяли в работу и до выпуска на прод?)
А с аргументами автора какими конкретно вы Не согласны?
По поводу того, что ПО имеет максимальную экономию на масштабе после того как оно разработано — об этом автор прямо пишет.
Не очень понял в итоге с чем вы согласны или не согласны. Поясните, пожалуйста.
попытка получить экономию на масштабе в разработке ПО (по автору) — это когда вы пытаетесь разрабатывать и поставлять ПО большими релизами и мотивируете это тем, что много требований будет за раз реализовать эффективнее, чем если бы вы эти требования реализовывали маленькими партиями (релизами/версиями).
почему? не понял вашу мысль