Моя команда исторически насчитывала в среднем около 40 человек в течение нескольких лет, а часто и больше. У нас довольно сложный продукт, затрагивающий несколько проблемных областей. Мы переключились с водопада на схватку, и, оглядываясь назад, я должен сказать, что ни то, ни другое не сработало (хорошо). Как сказал мне один PM, наш проект был «всегда желтым или красным» (то есть в состоянии высокого риска или серьезно откладывался).
Watefall «заработал», потому что после того, как мы официально закончили разработку и перешли к тестированию, не многие из официально сделанных функций действительно работали, а эффективная разработка была сделана во время (длительного) тестирования и утомительно исправлена. Можно сказать, что это был своего рода официальный водопад в сочетании с неким итеративным процессом.
Мы перешли на Agile/Scrum (в очень простой форме). Из огня да в полымя: теперь у нас ужасные проблемы с получением логически непротиворечивого продукта. Это не странно, учитывая, что у нас есть 5 основных подкоманд (не все из них в одном географическом местоположении) и действует закон Конвея. Кроме того, повторный стресс в конце итерации в течение нескольких лет имеет тенденцию изматывать/истощать людей (хотя это мое субъективное ощущение, у меня нет достоверных данных, подтверждающих это). Также было ужасно удерживать людей достаточно долго в одном месте/подсистеме продукта, чтобы они могли стать экспертами и высокопродуктивными на своем месте: у меня создалось впечатление, что в этих постоянных изменениях мы развиваемся, становясь мастерами на все руки и мастерами своего дела. ничего такого. Оглядываясь назад, я не могу сказать, что схватка дала нам какие-то явные преимущества (у нас есть «схватка из скрамов»). конечно, и я не могу обнаружить, что это имело какое-либо значение). Конечно, отсутствие большого предварительного дизайна в моем POV является серьезным недостатком: работа рассинхронизируется, плохо разбита на разделы, и ее нужно будет переделывать или модифицировать позже.
Это похоже на классический тупик процесса CS, только перенесенный на уровень концепции/дизайна: разработчик/подгруппа A ждет, пока разработчик/подгруппа B завершит дизайн X, на который он/она рассчитывает, чтобы он мог завершить свой дизайн Y, в то время как разработчик/подгруппа B ждет, пока А сделать свой/их дизайн Y, чтобы они/он могли сделать X.
Scrum ничего не говорит об инфраструктурных задачах, кроме «втиснуть это в какую-нибудь пользовательскую историю» (и поэтому страдает инфраструктура). Дополнительные 3 небольшие группы по подтемам (внутренняя, внешняя, команда контент-провайдера, использующая продукты обеих предыдущих) для конкретной области все еще не могут даже договориться об общем представлении данных и формате. Отслеживание фактического состояния миллиона задач — это кошмар. В команде согласны с тем, что скрам не дал нам никаких преимуществ, но потребовал дополнительных затрат. Конечно, это не заставило нас уделять больше внимания тому, что на самом деле нужно клиентам/конечным пользователям.
Я не могу поверить, что говорю это, но у нас водопад работал (немного) лучше, чем скрам (или, если быть более точным: он был «не так плох, если только чуть менее плох»).
К счастью, некоторые подсистемы в значительной степени ортогональны, иначе мы бы ничего не сделали. Однако это чистая случайность: чуть больше внутренних зависимостей между подсистемами (относительно концептуальной целостности, производительности и т. д.), и мы были бы поджарены. То, что тебя спасла глупая удача, не является доказательством эффективной организации или мудрости.
С моей точки зрения это так: если проект небольшой (может быть собран одним человеком полностью или близко к этому) или состоит из кучи почти независимых концепций и фич, подойдет любая методология. Если проект большой (один человек даже не может вникнуть в подсистему целиком + существует множество внутренних зависимостей между подсистемами в концепциях, дизайне, бизнес-логике и алгоритмах), никакая методология не работает.
Единственное решение, которое я лично вижу, было бы таким:
Если это не сработает, я должен сказать, что для меня мой проект подобен «гордиеву узлу из ада», который в принципе неразрешим (хорошо) с моей точки зрения.
Эта очень длинная справочная информация подводит меня к моему вопросу: существуют ли методологии управления проектами, которые хорошо работают на больших проектах?
Я понимаю, что карта не дорога. Конечно. Но я не могу представить, как добраться до Аляски из ЮАР без карты. :-) Как говорят в математике, методология для меня необходимое, а не достаточное условие.
Проблемы:
Я знаю, что люди раскритикуют мое видение как «требование автопилота / панацеи», но я склонен думать, что А. Уайтхолл был прав, когда сказал, что прогресс измеряется рядом вещей, которые мы можем делать, не задумываясь. Идеальная методология подойдет любой команде: просто имейте смелость следовать процедуре. Если «другие факторы» — неизвестные факторы — необходимы для успеха проекта, то какие?
Я начинаю думать, что все это бесполезно. Я сделал несколько грубых расчетов в качестве примера: Представьте: n функций, m классов (при условии объектно-ориентированного программирования), k характеристик программного обеспечения (надежность, производительность в различных контекстах, безопасность, стоимость реализации, количество дефектов, время, необходимое для завершения разработки, тестирования). стоимость, время тестирования и т. д.), o люди. Потенциальная сложность: каждую функцию можно разделить на p классов (p меньше m, при этом сумма всех p для всех функций == m), она влияет не более чем на k характеристик и может потребовать работы или вмешательства любого подмножества из o людей.
Таким образом, сложность в наихудшем случае (количество комбинаций) равна n*m*k*o. с 20 функциями, 500 классами, 10 аспектами и 40 людьми, что составляет 4 000 000 (4 млн). Предполагая щедрое время выпуска в 18 месяцев, это 222222 (222 тысячи) комбинаций в месяц. Предположим, мы разрезаем 500 (или «m») классов на 50 управляемых коллекций, причем каждую коллекцию можно модифицировать/рефакторить внутри, не затрагивая другую коллекцию. Это по-прежнему более 22 тысяч комбинаций в месяц.
Человек не может отследить столько потенциальных влияний функций/классов/лиц на k (характеристики программного обеспечения) и выбрать наилучшие комбинации (запланировать заранее). Какой-то научно-фантастический инструмент с искусственным интеллектом должен был бы это сделать. В противном случае мы просто бросаем «радуйся жизни»: может быть, это сработает достаточно хорошо в достаточном количестве случаев, чтобы проект не задерживался. А может и не будет.
Справочная информация, чтобы дать вам лучшее представление о рассматриваемой системе. Это должно быть своего рода «анонимным» по причине конфиденциальности.
К счастью, это довольно просто: агенты <-> сервер, причем сервер состоит из следующих основных подсистем:
(конечно, есть много вспомогательных подсистем, от консоли конфигурации сервера до веб-интерфейса и REST API, но я не включаю их здесь)
Выполнение
Технологии: C, Java, SQL. Среды варьируются от сотен до десятков тысяч агентов (самая большая среда: около 100 тыс. агентов).
Размер кода: несколько тысяч файлов Java, организованных примерно в 500 пакетов. Всего на данный момент около 900 KLOC (не считая агента). Так что он не такой уж большой, но сложный в том смысле, что включает множество проблемных областей.
Агрегация — самая сложная и ресурсоемкая часть приложения. Мы используем простой SQL для повышения производительности, но даже в этом случае агрегация не может завершиться за 24 часа для больших сред (как раз тогда, когда должен начаться следующий раунд агрегации, т. е. на следующий день). Просчет может быть довольно серьезным, поскольку может стоить клиенту десятки миллионов долларов.
Следуя ответу Тиаго, проблема заключается не в методологии, а в том, как методология адаптируется к вашим проектам.
Основываясь на моем опыте работы над проектами биозащиты для правительства США, по мере того, как сложность проекта возрастает, возрастает и ваша потребность в предварительном планировании и тщательном надзоре за проектом. Независимо от того, используете ли вы водопад, agile или что-то еще:
Спрашивать, существует ли методология , которая хорошо работает для большого проекта, звучит все равно, что спрашивать, может ли маршрут на карте привести кого-то из Южной Америки на Аляску.
Есть ли (методика или карта)? Да. Будет ли он делать это (работать или путешествовать) сам по себе? Определенно нет.
Методика – это ориентир. Но, как и карта, это всего лишь подсказки, как чего-то или куда-то достичь, а не сама судьба.
Вы упомянули Waterfall x Agile. ЗДЕСЬ есть очень хорошее обсуждение этой темы , и я считаю, что ответ Павла потрясающий (как обычно!). В вашем случае, как для большого проекта, кажется, что более формальная методология подойдет лучше (например, водопад), но нет строгого правила, говорящего об этом.
Итог: проблема не в карте . Проблема не в методологии . Сказав это, основной вопрос здесь:
Какова проблема вашего проекта номер один? Или почему ваши проекты всегда между янтарным и красным?
Вам нужно будет определить основную причину проблем вашего проекта, а затем вы сможете оценить, какая методология лучше всего подходит для вашего проекта. Не наоборот.
В комментариях ОП подробно рассказал о среде своего проекта. Он сказал:
[T] основная проблема с нашим проектом не в том, что он большой в KLOC / FP или «сложный» ... Проблема в том, что проект больше похож на «чашу со скрепками», чем на набор независимых функций - вы не можете коснуться какой-либо функции или проблемы, не повлияв на большинство других аспектов, подсистем и проблем.
Насколько я понимаю, проблема в том, что задачи, вехи, функции и цели проекта настолько взаимозависимы, что любое изменение или отклонение требует рефакторинга всего плана и/или расписания проекта.
Итак, это проблема X/Y, потому что:
Основываясь на моем понимании первопричины, я бы рекомендовал рефакторинг плана проекта, а не перепроектирование процесса управления проектом. Конкретно:
Вы также можете рассматривать серьезные межзадачные зависимости как проектный риск. Надлежащим образом документируйте риск, сообщайте о рисках вышестоящему руководству и позвольте им либо принять риск, либо санкционировать необходимые меры по снижению риска.
И, наконец, если ничего не помогает, установите точку отсчета, когда проект выходит за пределы допусков настолько, что его следует рекомендовать к прекращению. Хотя обычно роль руководителя проекта не заключается в том, чтобы санкционировать выдергивание вилки из розетки, в вашу компетенцию, безусловно, входит определение пределов риска и капитальных затрат, которые организация готова терпеть. Как только эта информация станет известна, вы сможете справиться с этой метрикой и порекомендовать своевременное досрочное прекращение (если отказ неизбежен), чтобы сэкономить деньги компании.
Водопад успешно используется в самых крупных проектах в мире, например, 500 человек в течение 6 лет при стоимости 21 миллиард долларов. В основном это инфраструктурные проекты (мосты, туннели и железные дороги), аэрокосмические и оборонные проекты (самолеты и системы вооружения) и энергетические проекты (трубопроводы, буровые установки).
Подводит не методология, а реализация и «вибрация» среды проекта. В качестве примера «вибраций» в среде проекта я только что вернулся с семинара, на котором изучалась разработка истребителя FA-18 Hornet стоимостью 3,3 миллиарда долларов. Одним из важнейших факторов успеха, упомянутых в проекте, было создание атмосферы доверия и точный поток данных по проекту.
Вам нужно взглянуть на организацию, руководство и проектную среду. Это не вопрос методологии.
Дэвид Эспина
Тьяго Кардосо
Тодд А. Джейкобс
мркафк
мркафк
Тьяго Кардосо
мркафк
мркафк
Тьяго Кардосо