Я большой поклонник контрольных списков. Существует Путешествие Контрольного список , Перемещение Контрольного списка и даже Scrum Контрольного списка .
Контекст : вы были наняты крупной корпорацией и получили задание настроить всю среду разработки программного обеспечения, процессы, команду и т. Д. У вас есть «карт-бланш». Вы будете нести ответственность за создание рабочих приращений программного обеспечения. Размер проекта: 2000 чел / сутки.
Какие элементы вы бы добавили в следующий (намеренно маленький и неполный) контрольный список:
- Установите сервер непрерывной интеграции
- Написать DoD
- Написать руководство по кодированию на одной странице
- Создать бэклог продукта
- Установите систему отслеживания ошибок
- Расписание обычного времени для лица
project-management
development-process
Томас Оуэнс
источник
источник
источник
Посмертные обзоры - Поскольку вы работаете над вещами в блоках, я бы запланировал одно-двухчасовой обзор (в зависимости от размера команды), чтобы провести очную встречу (если это возможно), где все идут вокруг и говорят, что было сделано правильно, что можно было бы сделать лучше, а то, что не было нужно. Возможность учиться на своих ошибках в процессе разработки на ранних этапах означает, что вы можете избежать их на более позднем этапе, когда у вас не так много времени для работы.
источник
Начнем с найма хорошей команды подходящих профессионалов для вашего проекта. В типичном бизнес-приложении вам нужно как минимум нанять разработчика базы данных и администратора базы данных, специалиста по обеспечению качества, системного администратора, бизнес-аналитиков, разработчиков приложений, специалиста по пользовательскому интерфейсу и руководителей команд. DBA, системный администратор, бизнес-аналитики и QA должны находиться в отдельной цепочке отчетности от команды разработчиков. Специалист по разработке баз данных должен подчиняться тому же техническому руководителю, что и разработчики приложений и специалист по пользовательскому интерфейсу.
Настройте офисное пространство. Частные офисы хороши, если вы можете их получить (я желаю вам удачи в этом), но как минимум вам нужны столы, телефоны, компьютеры, доски и пара выделенных конференц-залов. Убедитесь, что есть место для перерывов на обед, холодильник, безалкогольные напитки, закуски и кофе. Бесплатные безалкогольные напитки и кофе еще лучше.
Настройте серверы dev / qa / staging и prod для приложения и баз данных. Базы данных никогда не должны находиться на одном сервере с приложениями. В зависимости от размера и масштаба проекта вам может потребоваться несколько серверов или сетей SAN и т. Д. Для каждой среды.
Как только серверы настроены, запланируйте резервное копирование файловой системы, базы данных и журналов транзакций базы данных. Сделайте это в самый первый день, когда все готово. Нанимайте такую фирму, как Iron Mountain, для еженедельного резервного копирования.
Настройте систему контроля версий и создайте документ, описывающий, как она будет использоваться. Не забывайте настаивать на том, чтобы ВСЕ структурные изменения базы данных и вставки данных для таблиц типов поиска были в сценариях контроля версий. Это облегчит развертывание.
Купите коммерческое программное обеспечение или загрузите программное обеспечение с открытым исходным кодом для набора инструментов, который вы решили использовать с лицензиями для всех соответствующих пользователей.
Купите машины разработчика, которые кричат быстро и имеют два монитора. Купите хотя бы один тестовый пользовательский компьютер, который стонет медленно и типично для того, что пользователи будут иметь на своих рабочих столах.
Обучите своих новых разработчиков тому, как вы хотите, чтобы все было сделано. Если у вас достаточно большая команда, чтобы иметь несколько начинающих разработчиков, запланируйте для них дополнительное обучение и включите время в планирование своего проекта. Очень внимательно следите за юниорами в течение как минимум трех месяцев. Следите за всеми новыми сотрудниками внимательно в течение первого месяца. Избавьтесь от мертвой древесины и мошеннических разработчиков как можно скорее.
Определите, что нужно сделать в каком порядке (критический путь). Не назначайте задачи в конце критического пути, пока задачи, от которых они зависят, не будут выполнены.
Создание планов испытаний и требований.
Организуйте регулярные запланированные встречи с клиентами. Они заслуживают того, чтобы знать, что вы делаете, и каковы препятствия. Не забудьте сказать им, когда будет поздно. Если у вас три недели до крайнего срока, и вы уже знаете, что пропустите его, этот дефицит не исчезнет волшебным образом, пока вы не сообщите об этом клиенту. Убедитесь, что клиент знает, что добавленные требования означают добавленные затраты и время и что при каждом добавленном требовании должны быть либо отменены другие задачи, либо конечный срок изменится на количество часов в новых задачах. Если вы сделаете это с самого начала, это сэкономит вам массу времени и времени, а также приведет к перерасходу средств вашей группы, а не клиента.
Настройте среду для тестирования производительности, а не только скорость одного пользователя, но такую, где вы можете протестировать ожидаемое количество одновременных пользователей. Не ждите, чтобы сделать это тестирование до дня, прежде чем вы начнете жить.
При планировании проекта предположим, что QA найдет ошибки и что на их устранение потребуется время. Не планируйте QA только на один день в конце.
Создайте тестовые данные примерно того размера, который, по вашему мнению, будет иметь базу данных. Заставьте всех разработчиков проверить свой код на базе данных такого размера. Не позволяйте разработчикам разрабатывать только против небольшой базы данных на своих персональных компьютерах. Это частая причина того, что код работает нормально, пока не попадет в производство.
Планируйте вознаграждения в бюджет. Это демотивирует людей, когда они отрабатывают свои задницы в течение нескольких месяцев, и только менеджеры получают бонусы. Также говорите спасибо часто и письменно.
Вам может понадобиться система управления проектами или, по крайней мере, настроить электронные таблицы для отслеживания того, что вам нужно отслеживать. При планировании проекта принимайте в свой план не более шести часов в день человека. Это помогает учесть время, которое будет потрачено не на проект, например, отпуск, больничное время, праздники, встречи с персоналом, обзоры эффективности и т. Д. Если вы знаете, что проект находится в периоде высокой недоступности (например, проект, который выполняется с 1 ноября по 1 января в США), возможно, вам придется сделать дополнительные надбавки для большего отпуска и отдыха. Несправедливо ожидать, что разработчики откажутся от своих отпусков и отпусков, и никто не может предсказать, когда произойдут такие вещи, как больничный, присяжные, тяжелая утрата и т.д. Предположим, они произойдут с вашей командой в этом проекте.
источник
Некоторые вещи, которые я не вижу в вопросе и последующих ответах:
План по ликвидации последствий катастрофы. Как вы делаете резервные копии блоков разработки, постановки, тестирования и т. Д.? Есть ли у каждого разработчика то, что ему нужно для работы из дома в случайный снежный день? И т.п.
План тренировок. Сколько недель тренировок нужно вашим разработчикам, чтобы оставаться в форме? Кто-нибудь отслеживает это? (Электронной таблицы может быть достаточно для большинства команд.) Имейте механизм для того, чтобы они могли отчитываться (посылая кому-либо электронное письмо, в котором говорилось, что он смотрел 2 часа веб-трансляций на «что угодно», вероятно, достаточно), и чтобы руководство планировало - например, кого мы должны отправить на что конференция в этом году.
Положение инструмента. Это место типа «мы даем вам всем подписку MSDN; пожалуйста, не устанавливайте ничего на ваших рабочих машинах» или «нам нужен ваш код, но нам все равно, что вы используете для его редактирования, компиляции и тестирования». "вроде места. Примите и запишите решение.
столько интегрированного ALM, сколько вы можете себе позволить. Обычно причина «несоответствия импеданса», двойного входа, перекрытия инструмента и интеграции приложений с вращающимся креслом заключается в том, что система росла по частям. Начиная с нуля, вы хотите показать, что ваши люди могут оставаться в одном инструменте на протяжении всего цикла. Не вводить код в X, компилировать с Y, тестировать с Z, изменять статус рабочего элемента / задачи с A, сообщать о времени, проведенном с B, говорить человеку, который ждал, что теперь он может продолжить с C, пытаясь понять что делать дальше с D, оценивая общий прогресс с E и т. д.
источник
Запутать больше человеко-дней.
Это редкое событие, когда люди выделяют достаточно изначально.
[Позже ... заново обсудить еще больше ...]
источник
Поскольку у меня больше всего проблем со сторонними библиотеками и их использованием:
Почему? Я не могу сказать вам, сколько раз в сторонних библиотеках (проприетарных) были чудовищные ошибки, которые возвращали нас на несколько недель назад, потому что у нас не было процесса перемещения вверх или вниз. Или иметь дело с разработчиками, которые говорят: «Какую версию вы использовали? Почему вы использовали функции, помеченные как устаревшие?»
источник
Большим расходом для организаций не является выделение бюджета на безопасность на протяжении всего жизненного цикла разработки, это означает, что безопасность обычно заканчивается после того, как слишком неэффективный дорогостоящий набор действий или элементов управления введен слишком поздно, чтобы принести большую пользу.
Получите встроенную защиту из первоначального плана проекта, с ключевыми этапами, как и во всех других аспектах разработки, и используйте итеративный процесс, чтобы постоянно обновлять руководство по безопасности. Окончательный выход из системы безопасности должен стать неожиданной проверкой того, что все меры безопасности были реализованы в соответствии с проектом.
В противном случае вы в конечном итоге обеспечите безопасность после внедрения - где это может стоить в 8–10 раз дороже (данные Gartner, IBM и др.), Расстроит людей, так как функциональность может быть затронута и может быть слишком поздно для предотвращения эксплуатации. и ущерб.
источник
1. Отнеси это команде
Спроси программистов! Действительно, это самое главное. Вы встретите большое сопротивление, если разработчики не будут напрямую вовлечены в это изменение. В конце концов, речь идет о том, как они работают, а не о вас. Само собой разумеется, но попытка навязать людям методы и инструменты обычно приводит к ужасным последствиям.
2. Осмотреть и адаптировать
Пусть команда выяснит, как лучше работать, используя свой опыт, чтобы аккуратно помочь им встать на выбранную трассу. Затем регулярно и совместно оглядывайтесь назад на то, как вы (они) делаете, и адаптируйте процесс, чтобы сделать его лучше.
источник