Добавляете больше структуры нашим процессам разработки?

Я работаю с небольшой командой (4 разработчика), пишу прошивку и программное обеспечение для нашего нестандартного оборудования. Я ищу лучшие способы организовать команду и лучше определить процессы.

Наши текущие настройки

  • Разработчики обычно работают над 2-3 проектами одновременно.

  • У нас есть проекты, которые работают итеративно, когда разработчик постоянно общается с заказчиком, а функции медленно добавляются и исправляются ошибки.

  • У нас также есть проекты с фиксированными сроками поставки, а при длительном сроке поставки окончательное оборудование может появиться всего за несколько недель до поставки. Фиксированные проекты, как правило, представляют собой небольшие изменения в существующем продукте или реализации, и работа каким-то образом перемешана.

  • Мы также переходим от консалтинга к продуктам, поэтому время от времени мы добавляем функции, которые, по нашему мнению, добавят ценность за наш счет.

Проблемы

У нас еженедельная встреча, на которой для каждого проекта отводится доля времени. «Клиент А хочет протестировать функцию X на следующей неделе», поэтому отводится необходимое время. «У клиента B проблемы с Y, может ли разработчик P пойти вниз и посмотреть?» И т. Д.

Когда мы заняты, эти планы очень слабо соблюдаются. Возникают проблемы, и вещи с более низким приоритетом отбрасываются назад. Иногда приоритеты не ясны для разработчиков, поэтому возникает проблема, когда приоритеты изменяются. На следующей неделе будет осознание того, что мы отстаем от проекта Z и у нас уйдет несколько долгих дней.

Мне сказали, что это довольно распространенное явление для небольшого стартапа в нашей отрасли, но я просто ищу способы ограничить количество "пиццы в офисе" на всю ночь.

4 голоса | спросил Tim 29 12010vEurope/Moscow11bEurope/MoscowMon, 29 Nov 2010 04:25:45 +0300 2010, 04:25:45

4 ответа


0
  

Разработчики обычно работают над 2-3 проектами одновременно.

Многозадачность невероятно неэффективна. Переключение мозга с одной задачи на другую требует времени для переключения передач.

  

Когда мы заняты, эти планы очень слабо соблюдаются.

Тогда зачем вообще создавать планы?

Можно ли посвятить всего одного разработчика одной задаче /продукту /клиенту? Таким образом, разработчик P является единственным, кто разговаривает с клиентом B? (Конечно, разработчик должен точно задокументировать, что он делает, на случай, если его сбьет автобус, но он все равно должен записывать проблемы и планы).

  

На следующей неделе будет осознание того, что мы отстаем в проекте Z и у нас уйдет несколько долгих дней.

Если бы в проекте Z в любом случае был только один разработчик, его бы не отвлекли проблемы клиента A.

Не думайте с точки зрения группы разработчиков, обслуживающих группу клиентов, подумайте об одном разработчике для данного клиента. (Это может сделать планирование отпуска немного сложнее, но если вы постоянно тянете всех на ночь, вы все равно не проводите достаточно времени вне офиса.)

ответил chrisaycock 29 12010vEurope/Moscow11bEurope/MoscowMon, 29 Nov 2010 05:15:24 +0300 2010, 05:15:24
0
  

Мне сказали, что это довольно распространенное явление для небольшого стартапа в нашей отрасли, но я просто ищу способы ограничить количество "пиццы в офисе" на всю ночь.

Не все ли мы.

  

«Клиент А хочет протестировать функцию X на следующей неделе», поэтому необходимо выделить необходимое время.

Выделено кем?

Вы создаете свои собственные графики? Если нет, то единственный ответ руководству, создающему для вас расписание, - «все ночи».

Реалистичные графики не на ночь будут беспокоить руководство. Пока вы не сможете доказать , что ваши клиенты хотят лучшего графика с меньшим количеством ночей, вы ничего не можете сделать.

Единственный способ уменьшить количество ночных клубов - это сделать что-то раньше. Но если оборудование не приходит раньше, вы ничего не можете сделать, не так ли?

ответил S.Lott 29 12010vEurope/Moscow11bEurope/MoscowMon, 29 Nov 2010 04:29:03 +0300 2010, 04:29:03
0

Две мысли: повысить качество и улучшить оценки.

Я работаю в небольшом магазине программного обеспечения, который производит продукт. Самым значительным отличием между нами и другими магазинами аналогичного размера, в котором я работал, является QA (сейчас более одного). Ценность, которую этот человек должен принести в первый день, не тестируется, пока тесты не будут записаны. Мы используем TestLink . Есть несколько причин для такого подхода:

  1. Повторение тестов для поиска ошибок регрессии. Вы что-то изменили, что сломалось?
  2. Подумайте, как заранее протестировать функциональность - это совместная работа разработчика и QA, и, если это не повредит, вы, вероятно, делаете это неправильно.
  3. Когда кто-то еще тестирует и проверяет ваш код, это хорошая идея .

Поместите некоторую структуру вокруг вашей оценочной деятельности. Повторно используйте формат, будь то Excel, MS Project или что-то еще (по крайней мере, сделать это в цифровом виде). Сделайте это, и вы начнете видеть шаблоны, повторяющие то, что вы делаете при создании программного обеспечения. Вообще говоря, включайте в свои оценки время на обдумывание (a.k.a. design), сборку, тестирование (QA), исправление и развертывание. Кроме того, прочитайте книгу Макконнелла Оценка программного обеспечения , используйте все, что, по вашему мнению, стоит того Это отличная книга.

Низкое качество означает более длительные циклы разработки. Наиболее эффективным шагом является QA, если не считать этих модульных тестов. Если бы это было веб-приложение, я бы также предложил что-то вроде Selenium, но вы имеете дело с оборудованием, поэтому не знаете, что можно сделать. Улучшение оценок означает способность пытаться прогнозировать, когда все будет плохо, что может показаться не таким уж большим, но заблаговременное знание может быть катарсным.

ответил orangepips 29 12010vEurope/Moscow11bEurope/MoscowMon, 29 Nov 2010 06:36:56 +0300 2010, 06:36:56
0

Я предлагаю вам следовать Scrum Framework. Создайте среду Scrum с корпоративным продуктом. Пусть продуктовые группы работают над функциями своих собственных продуктов, которые являются частью объединенного корпоративного продукта. Если у вас есть ресурсы, имейте поддержку по вопросам производства /проблем и инфраструктуры Scrum Team. Если проблемы решаются слишком быстро, попросите команду инфраструктуры попробовать Kanban или Scrumban.

Scrum Framework сам по себе решит большинство ваших проблем, если его правильно принять.

ответил sjt 29 12010vEurope/Moscow11bEurope/MoscowMon, 29 Nov 2010 05:49:50 +0300 2010, 05:49:50

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132