16
Системный Анализ и Требования / Re: Пользовательские истории и ГОСТ 34
« : 14 Января 2014, 03:30:15 »
Я бы добавил user stories в раздел Требования к Системе в подраздел Требования к функциональным характеристикам.
Просмотр сообщений
В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.
17
Управление Проектом / Re: Распространённые мифы о классическом процессе разработки
« : 21 Августа 2013, 00:36:03 »И наиболее правильный (IMHO) вариант, когда код тестов появляется до тестируемого кода. То что по настоящему нужно для автоматизации тестирования - это соглашение об интерфейсах.
Речь идёт не о юнит-тестах, а о функциональных тестах. Они разрабатываются параллельно с разработкой фичи, но интегрируются в билд-систему после того, как фича реализована. Эти тесты являются частью непрерывной интеграции. Они запускаются автоматически на тестовой машине после того, как билд-сервер соберёт очередной билд.
Так и есть. Это вовсе не миф. Хорошее время между внесением бага в код и донесением информации о нем до программиста - от секунд до четверти часа. Хорошее время между внесением бага в код и его исправлением - в пределах рабочего дня.
Вы рассматриваете процесс разработки с точки зрения разработчика, т.е. пытаетесь организовать его таким образом, чтобы он был удобен инженеру. Между тем, в разработке серьёзной программы принимают участие множество людей разных специальностей: бизнес-аналитики, маркетологи, продакт-менеджеры, менеджеры проекта, инженеры, тестеры, специалисты по пользовательскому интерфейсу, дизайнеры. Если речь идёт об игре, то добавьте с этому списку аудио дизайнеров, 3д моделлеров, продюсеров и т.д. и т.п. Кроме того, программу регулярно отсматривают бизнес-люди и независимые ревьюеры, которым просто необходим визуальный прогресс по запланированным фичам. Им важно "пощупать" фичу, чтобы понять, насколько её в таком виде можно продать клиентам. Чем раньше будут выявлены риски, связанные с неправильным дизайном фичи, тем лучше, т.к. могут быть внесены необходимые изменения.
Кроме того, на большом проекте в разработке принимает участие множество людей. На одном из проектов, в котором мне довелось принять участие, команда состояла из 100 человек. Из них было 40 или 50 инженеров. При таком размере команды адресовать баг тому инженеру, который разрабатывал подсистему, в которой произошла ошибка, не так-то просто. Это, конечно, делается. Но получается не всегда.
Так что, с точки зрения отдельно взятого разработчика, Вы правы - проще баг исправлять сразу, пока детали реализации фичи ещё содержатся в памяти. Однако с точки зрения проекта и команды в целом, это не так.
18
Управление Проектом / Re: Управление командой. просрочки
« : 20 Августа 2013, 00:05:58 »
Здравствуйте, Careeristka!
А как у Вас происходит контроль сроков? В какой момент времени менеджер проекта узнаёт, что разработчик не успевает справиться с задачей?
У нас это происходит так:
1. Перед началом production'а фичи разработчик прорабатывает технический дизайн фичи, который оформляется документально.
2. Разработанный дизайн ревьюится ведущим программистом, который вносит свои замечания, а разработчик - на основе этих замечаний - вносит изменения. После чего дизайн считается принятым.
3. Параллельно разработчик разбивает фичу на подзадачи, каждая из которых не может быть меньше 4-х и больше 24-х часов.
4. Эти задачи и их оценка также ревьюятся ведущим программистом, после чего вносятся изменения в задачи и их оценку, и далее - принимаются.
5. Затем задачи вносятся в систему контроля задач, и разработчик приступает к их выполнению.
6. Приступая к работе над задачей, разработчик ставит её в статус In Progress.
7. В конце каждого дня он обязан проапдейтить эстимейт по задаче. В ситуации, когда всё нормально, часы уменьшаются с запланированной скоростью.
8. Если задача пробуксовывает, то это сразу же становится видно менеджеру проекта, т.к. он собирает статистику каждый вечер после того, как все разработчики проапдейтят информацию по текущим задачам.
9. Далее менеджер пытается выяснить, в чём заключается причина пробуксовки. Если она носит организационный характер, то менеджер обязан помочь в её решении. Если причина - неучтённый технический риск, то он заносится в регистр рисков, и далее мониторится. Кроме того, происходит переоценка сроков. Если причина носит какой-то технический характер (например, разработчик не сталкивался с подобного рода задачами, и не знает, как её решить), то подключается ведущий программист, который помогает разработчику.
Не больничный, не отпуска, отговорки вроде "закопался в решении", "думал сделать так, чтобы при доработке не надо было все переделывать", работаю над очень крутым решением, поэтому долго".
А как у Вас происходит контроль сроков? В какой момент времени менеджер проекта узнаёт, что разработчик не успевает справиться с задачей?
У нас это происходит так:
1. Перед началом production'а фичи разработчик прорабатывает технический дизайн фичи, который оформляется документально.
2. Разработанный дизайн ревьюится ведущим программистом, который вносит свои замечания, а разработчик - на основе этих замечаний - вносит изменения. После чего дизайн считается принятым.
3. Параллельно разработчик разбивает фичу на подзадачи, каждая из которых не может быть меньше 4-х и больше 24-х часов.
4. Эти задачи и их оценка также ревьюятся ведущим программистом, после чего вносятся изменения в задачи и их оценку, и далее - принимаются.
5. Затем задачи вносятся в систему контроля задач, и разработчик приступает к их выполнению.
6. Приступая к работе над задачей, разработчик ставит её в статус In Progress.
7. В конце каждого дня он обязан проапдейтить эстимейт по задаче. В ситуации, когда всё нормально, часы уменьшаются с запланированной скоростью.
8. Если задача пробуксовывает, то это сразу же становится видно менеджеру проекта, т.к. он собирает статистику каждый вечер после того, как все разработчики проапдейтят информацию по текущим задачам.
9. Далее менеджер пытается выяснить, в чём заключается причина пробуксовки. Если она носит организационный характер, то менеджер обязан помочь в её решении. Если причина - неучтённый технический риск, то он заносится в регистр рисков, и далее мониторится. Кроме того, происходит переоценка сроков. Если причина носит какой-то технический характер (например, разработчик не сталкивался с подобного рода задачами, и не знает, как её решить), то подключается ведущий программист, который помогает разработчику.
19
Управление Проектом / Re: Распространённые мифы о классическом процессе разработки
« : 19 Августа 2013, 23:48:43 »
Здравствуйте, Эдуард!
На основе исторических данных. Если речь идёт о продукте, который выходит из года в год, то анализируется общее количество багов за несколько последних лет. Далее оно соотносится со сложностью и масштабностью изменений, которые были внесены в прошлые года и которые будут внесены в этом году. И на основе этого делается общий прогноз по количеству багов.
Аналогичным образом поступают при составлении прогноза по подсистемам (фичам). Смотрятся исторические данные, анализируется сложность вносимых изменений. Если фича (или подсистема) - совсем новая, то анализируются исторические данные другой аналогичной по сложности подсистемы.
Таким же образом поступают, если разрабатывается совсем новый продукт - исследуются исторические данные аналогов.
Хотел поинтересоваться: А каким образом и какими методами это делается?
На основе исторических данных. Если речь идёт о продукте, который выходит из года в год, то анализируется общее количество багов за несколько последних лет. Далее оно соотносится со сложностью и масштабностью изменений, которые были внесены в прошлые года и которые будут внесены в этом году. И на основе этого делается общий прогноз по количеству багов.
Аналогичным образом поступают при составлении прогноза по подсистемам (фичам). Смотрятся исторические данные, анализируется сложность вносимых изменений. Если фича (или подсистема) - совсем новая, то анализируются исторические данные другой аналогичной по сложности подсистемы.
Таким же образом поступают, если разрабатывается совсем новый продукт - исследуются исторические данные аналогов.
20
Управление Проектом / Распространённые мифы о классическом процессе разработки
« : 19 Августа 2013, 15:17:38 »
Классический процесс разработки программного обеспечения делится на 3 этапа: pre-production, production и post-production.
На этапе pre-production вырабатывается концепция продукта, разрабатывается его более-менее детальный дизайн, выполняется техническое проектирование и создаётся демонстрационная версия продукта, которая способна подтвердить правильность первоначальной задумки.
Во время production разрабатывается сама программа, т.е. делаются фичи (features). На этом этапе основная масса багов не исправляется – исправляются только критические баги, которые связаны с неправильным функционированием фич или которые блокируют усилия тестеров по проверке фич.
На этапе post-production — исправляются остальные баги.
К сожалению, применению такого подхода во многих российских компаниях мешают две вещи. Первая вещь – это элементарная лень руководства. (Согласитесь, куда проще говорить, что команда должна сама eliminate wastes, чем наладить процесс производства.) А вторая вещь – устоявшиеся мифы. И если с ленью я ничего не могу поделать, то мифы – постараюсь развеять.
Миф 1. Если исправление багов отложить на этап post-production, в скором времени количество багов вырастет, как снежный ком, и проект станет плохо прогнозируемым и плохо управляемым.
Управляемость проектом не будет потеряна, потому что:
1. В серьёзных компаниях при старте проекта отдел QA составляет прогноз, в котором расписано: сколько багов будет найдено, сколько багов будет содержать каждая крупная фича, сколько багов будет признано некорректными, сколько багов будет зашиплено и т.д. Этот прогноз используется в работе отделом QA и менеджментом проекта. Более того, он регулярно корректируется с использованием актуальных данных. Так что ни о какой "плохой прогнозируемости" и "плохой управляемости" не может быть и речи.
2. Во время production отдел QA находит далеко не все баги, а только их часть. В проектах, в которых я принимал участие, их количество составляет от 30 до 40 процентов от общего числа багов. Причина этого проста — основные силы QA подключаются незадолго до того, как все фичи будут реализованы. Подключать их ранее не имеет смысла, потому что фичи ещё не сделаны, и нечего тестировать. Кроме того, ещё не готовы тест-кейсы, т.к. фичи находятся в работе, и представление продюсеров о них может меняться. Во время production отсутствуют необходимые условия для подключения большой команды тестеров.
3. Если фича работает не так, как нужно, то это не баг, а не сделанная фича. В таком виде она не принимается у программиста, и он должен сделать так, чтобы она работала, как и было запланировано. Если во время работы фичи происходит крэш или ассерт, то отдел QA заводит баг и помечает его, как критический. Этот баг тоже фиксится, поскольку он мешает проверить работоспособность фичи до конца.
Дальше: http://askofen.blogspot.ru/2013/08/blog-post_19.html
21
Проектирование / Re: Онлайновые ресурсы по проектированию
« : 06 Ноября 2011, 18:30:27 »Тем не менее, я просил своих магистрантов почитать Ваш блог и вынести свое суждение: за или против с аргументами, естественно. Интересно, что получится?
Эдуард, мне интересно
.Хотя неплохо бы где-то положения Вашей парадигмы записать отдельно, тезисно.
Конечно, буду излагать. Просто сейчас мне нужно ещё разобрать хотя бы пару примеров. Возможно, с приведением программного кода.
22
Проектирование / Re: Онлайновые ресурсы по проектированию
« : 06 Ноября 2011, 17:35:01 »Да нет, вопрос в том, есть ли смысл писать о них в резюме. Из ответа понял, что в целом не вредно.
Денис, не люблю "якать". Третья форма более обезличенная.
23
Проектирование / Re: Онлайновые ресурсы по проектированию
« : 06 Ноября 2011, 17:32:47 »Я бы крайне осторожно подошел к написанному в этих блогах
Эдуард, а почему? Насколько я помню, Вы не высказали входе обсуждения каких-то серьёзных возражений.
24
Проектирование / Re: Онлайновые ресурсы по проектированию
« : 31 Октября 2011, 23:04:47 »
Software Design
Блог посвящён вопросам проектирования ПО. Автор делится своим личным опытом, детально разбирает конкретные примеры проектирования, предлагает и излагает свою методику, которая сформирована на базе 15-летнего опыта коммерческой разработки ПО. Никаких абстрактных, отдалённых от реальности теоретических изысканий. Все рекомендации проверены практикой.
http://askofen.blogspot.com/
Блог посвящён вопросам проектирования ПО. Автор делится своим личным опытом, детально разбирает конкретные примеры проектирования, предлагает и излагает свою методику, которая сформирована на базе 15-летнего опыта коммерческой разработки ПО. Никаких абстрактных, отдалённых от реальности теоретических изысканий. Все рекомендации проверены практикой.
http://askofen.blogspot.com/
25
Управление Проектом / Re: Модернизация существующей системы.
« : 18 Октября 2010, 16:27:36 »Поэтому есть желание проявить силу ума и построить модель имеющейся системы, чтобы оценить - какие изменения мы можем в неё внести для стабилизации и для повышения функциональности по запросам пользователей.
На мой взгляд, такая работа без чёткого понимания того, зачем она нужна, бесполезна.
Из Вашего описания я понял, что проект собираются закрывать или, во всяком случае, высвободить из-под него основные ресурсы. Поэтому, мне кажется, основная полезная задача, решение которой не будет воспринято руководством в штыки - это сокращение ресурсов на сопровождение программы.
Исходя из этого, ИМХО, имеет смысл строить не функциональную модель системы в виде юз-кейсов, а модель дефектов - распределение дефектов по модулям программы.
В этом случае, Вы узнаете:
1) какие модули спроектированы и реализованы хуже всего - в них будет много багов;
2) какие ошибки характерны для Вашей системы в целом и её отдельных модулей - возможно, причина в нечётких требованиях или плохой обратной связи с пользователями во время проектирования.
Как результат, Вы сможете повысить эффективность сопровождения программы.
26
Обучение / Проектирование электронных устройств (о том, как создаются новые продукты)
« : 07 Апреля 2009, 12:19:30 »
Реклама тренинга
"Рынок электронных устройств насыщен до предела. Как производители создают новые устройства? Типовой приём - взять за основу известное устройство и увеличивать количество полезных функций (см.: функциональный подход). Сейчас уже трудно встретить в продаже "чистый" mp3-плеер. Современный плеер позволяет не только слушать музыку, но и просматривать фотографии, видео-клипы и Интернет-сайты. Но увеличение количества полезных функций не всегда приводит к хорошему результату. Почему?"
http://www.treko.ru/techno
"Рынок электронных устройств насыщен до предела. Как производители создают новые устройства? Типовой приём - взять за основу известное устройство и увеличивать количество полезных функций (см.: функциональный подход). Сейчас уже трудно встретить в продаже "чистый" mp3-плеер. Современный плеер позволяет не только слушать музыку, но и просматривать фотографии, видео-клипы и Интернет-сайты. Но увеличение количества полезных функций не всегда приводит к хорошему результату. Почему?"
http://www.treko.ru/techno