Только что в нашем случае не было талмуда документации, и требования менялись по мере приближения даты выпуска, и понимая, как оно всё выглядит и как будет работать
В основном в технологии у нас англоговорящие иммигранты — американцы, австралийцы, новозландцы. Англичан, думаю, четверть, или даже треть. По одному человеку есть из разных стран — Румыния, Турция, Испания, Израиль. Разношёрстно.
В технологии все белые, это необычно для ай-ти в Лондоне.
Всё люди не будут знать, но будут знать, куда смотреть. А в паре — и то проще.
Ротация у нас не «насильственная» — если кто-то считает это плохой практикой, в Лондоне куча работ. Обычно инженеры очень рады работать с ротацией. Бывает, что конкретный программист хочет закончить задание в данной паре — это всегда пожалуйста.
Фокус-фактор и прочие характеристики мы не практикуем.
1) Пишут автотесты, придумывают, что ещё потестировать, проводят ручное тестирование — к сожалению, не всё можно автоматизировать. По-моему, у нас тестерам интересно работать — обычно это скучно и однообразно.
2) Одна из команд всегда «на дежурстве», и выполняет это сопровождение. Когда всё работает, они придумывают, как улучшить процесс — например, какие новые способы предотвращения неполадок, новые отчёты и пр.
3) Да, бывает. В зависимости от сложности — если мелочь, то программисты и аналитик решат, что хрен с ним. Бывает, доходит до ген. директора, но чаще всего бизнес решает (те, кто и запросили изменения)
4) Проблемы тоже случаются. Организационные реже — хотя вот в прошлой итерации моя команда что-то разучилась говорить «нет», в итоге потратили 2 дня на весьма бесполезный css. Технические — как у всех, думаю. То сервак заглючит, то лицензия не вовремя закончится, то просто окажется, что не совсем правильно спроектировано. Ничего особенного :)
Есть юнит тесты и тесты принятия (Acceptance tests).
Последние очень легко читабельны, их название всегда типа ценаДолжнаБытьПозитивнойИКратнойТику (priceShouldBePositiveAndMultipleOfTickSize) — и тест в нескольких строках убедится, что другая цена не примется.
Наша система разработана на Java, с использованием других новых компонентов для интеграции (мы получили какую-то награду за интеграцию с системой Informatica). Недавно мы перешли на новую версию Java, и так как этот язык, вроде, умирать пока не собирается, судьба мейнфреймов нам пока не грозит. Вообще, когда выходит новая версия чего-либо, мы её внедряем и остаёмся cutting edge :)
Люди у нас приходят и уходят, команда растёт и меняется. В этом году ушло 2-3 человека, пришло 4-5 — процесс и знания распространяются.
Если появятся новые инструменты, или какие-то прочие требования — мы их добавим. На то мы и agile. В этом году, например, мы удвоили колличество тогровых пар форекса.
Возраст инженеров у нас разнообразный. Есть совсем молодые (лет 25), много 40-летних, несколько постарше. Дети почти у всех есть…
Да, система всё равно не вечна, как и всё остальное. Ничего, построим новую, где-то в другом месте.
Технические решения принимаются всей командой — предложения обсуждаются, анализируются, если надо, инженеры идут к бизнесу, или к кому-то кто лучше понимает какой-то технический вопрос. Из-за постоянной совместной работы инженеры хорошо знают сильные и слабые стороны друг друга, и могут решить, основываясь на этом.
Случается, что ответ остаётся не ясен — например, остаются 2 конфликтных мнения, или несколько разных идей. В таком случае мы делаем «спайк» (spike) — выделенное колличество времени выделяем на R&D — research and development, исследование и разработку, где желающие пытаются изучить и реализовать прототип решения.
>вроде как должно дать меньшую зависимость от ключевых людей и большие возможности всех остальных иметь доступ к информации.
В том-то и дело, что «ключевых» людей не должно быть. Практически все решения производятся группой, а над сложными частями системы к концу реализации поработают практически все, прощупав и почувствовав каждый аспект — конечно, благодаря «спариванию» и ротации.
Офис организован так, что спонтанные сессии архитектурного дизайна всегда проходят в самом «гнезде» инженеров, на проходе, соединяющем все важные органы офиса (как митинг-румы, кухню, выход, туалет). У нас все инженеры — народ любопытный, и любит вставить свои три копейки — поэтому как только учуют интерес, присоединятся.
Такое «сования носа» у нас очень поощряется, и никто никогда не скажет, мол, иди работай, хватит подслушивать.
>когда все «отцы-основатели» ушли потому что у них появился новый вызов
Может прозвучать самоуверенно, но у нас мало народу уходит. Платят неплохо, процесс отличный, область — лучше не придумашь. Технологии передовые. Люди — приятейшие. Много пьют :) Большинство коллег пишут технические блоги, хорошо оцененные в сообществе. Одна девушка-программист ушла… и через 3 месяца вернулась!
SVN (subversion) — система контроля версий, где каждая новая версия получает свой номер, и всегда можно вернуть любую из прошлых версий.
Комит (commit) — внесение новой версии в систему SVN.
Ротация полезна свежим взглядом, и это отличный инструмент для обучения. Кроме того, автоматом получается аудит кода, и вносятся изменения.
Про Ганта отличный ответ от Goder.
Документы архитектуры имеют смысл в основном до её реализации. На их написание уходит невероятное колличество времени, и куча ревизий. А в результате всё равно может получиться нечто, неудовлетворяющее требования.
Технические решения принимаются всей командой — предложения обсуждаются, анализируются, если надо, инженеры идут к бизнесу, или к кому-то кто лучше понимает какой-то технический вопрос. Из-за постоянной совместной работы инженеры хорошо знают сильные и слабые стороны друг друга, и могут решить, основываясь на этом.
Случается, что ответ остаётся не ясен — например, остаются 2 конфликтных мнения, или несколько разных идей. В таком случае мы делаем «спайк» (spike) — выделенное колличество времени выделяем на R&D — research and development, исследование и разработку, где желающие пытаются изучить и реализовать прототип решения.
Только что в нашем случае не было талмуда документации, и требования менялись по мере приближения даты выпуска, и понимая, как оно всё выглядит и как будет работать
А так, бизнес очень неплохо понимает, что к чему. Конечно, кодить они не смогут, но знают ограничения.
В основном в технологии у нас англоговорящие иммигранты — американцы, австралийцы, новозландцы. Англичан, думаю, четверть, или даже треть. По одному человеку есть из разных стран — Румыния, Турция, Испания, Израиль. Разношёрстно.
В технологии все белые, это необычно для ай-ти в Лондоне.
Но да, весьма нормальное :)
Точно есть главный центр на супер-скоростной ветке интернета и второй, в другом месте, для Disaster Recovery. Где и что стоит — без понятия.
«Чтобы боялись» — это не наш метод.
Ротация у нас не «насильственная» — если кто-то считает это плохой практикой, в Лондоне куча работ. Обычно инженеры очень рады работать с ротацией. Бывает, что конкретный программист хочет закончить задание в данной паре — это всегда пожалуйста.
Фокус-фактор и прочие характеристики мы не практикуем.
Требования — посмотрите на сайте LMAX.
2) Одна из команд всегда «на дежурстве», и выполняет это сопровождение. Когда всё работает, они придумывают, как улучшить процесс — например, какие новые способы предотвращения неполадок, новые отчёты и пр.
3) Да, бывает. В зависимости от сложности — если мелочь, то программисты и аналитик решат, что хрен с ним. Бывает, доходит до ген. директора, но чаще всего бизнес решает (те, кто и запросили изменения)
4) Проблемы тоже случаются. Организационные реже — хотя вот в прошлой итерации моя команда что-то разучилась говорить «нет», в итоге потратили 2 дня на весьма бесполезный css. Технические — как у всех, думаю. То сервак заглючит, то лицензия не вовремя закончится, то просто окажется, что не совсем правильно спроектировано. Ничего особенного :)
Последние очень легко читабельны, их название всегда типа ценаДолжнаБытьПозитивнойИКратнойТику (priceShouldBePositiveAndMultipleOfTickSize) — и тест в нескольких строках убедится, что другая цена не примется.
У нас никого не увольняют :)
По собственному желанию — кто как. В Лондоне обычно меняешь работу года в 2-3.
В нашей компании, мне кажется, эта средняя повыше.
Люди у нас приходят и уходят, команда растёт и меняется. В этом году ушло 2-3 человека, пришло 4-5 — процесс и знания распространяются.
Если появятся новые инструменты, или какие-то прочие требования — мы их добавим. На то мы и agile. В этом году, например, мы удвоили колличество тогровых пар форекса.
Возраст инженеров у нас разнообразный. Есть совсем молодые (лет 25), много 40-летних, несколько постарше. Дети почти у всех есть…
Да, система всё равно не вечна, как и всё остальное. Ничего, построим новую, где-то в другом месте.
Технические решения принимаются всей командой — предложения обсуждаются, анализируются, если надо, инженеры идут к бизнесу, или к кому-то кто лучше понимает какой-то технический вопрос. Из-за постоянной совместной работы инженеры хорошо знают сильные и слабые стороны друг друга, и могут решить, основываясь на этом.
Случается, что ответ остаётся не ясен — например, остаются 2 конфликтных мнения, или несколько разных идей. В таком случае мы делаем «спайк» (spike) — выделенное колличество времени выделяем на R&D — research and development, исследование и разработку, где желающие пытаются изучить и реализовать прототип решения.
На крайняк есть svn :)
Знаем мы вас, отмоете наши стены, сметёте упавшие карточки — что мы будем делать?
Уборщики — смерть agile'у!
В том-то и дело, что «ключевых» людей не должно быть. Практически все решения производятся группой, а над сложными частями системы к концу реализации поработают практически все, прощупав и почувствовав каждый аспект — конечно, благодаря «спариванию» и ротации.
Офис организован так, что спонтанные сессии архитектурного дизайна всегда проходят в самом «гнезде» инженеров, на проходе, соединяющем все важные органы офиса (как митинг-румы, кухню, выход, туалет). У нас все инженеры — народ любопытный, и любит вставить свои три копейки — поэтому как только учуют интерес, присоединятся.
Такое «сования носа» у нас очень поощряется, и никто никогда не скажет, мол, иди работай, хватит подслушивать.
>когда все «отцы-основатели» ушли потому что у них появился новый вызов
Может прозвучать самоуверенно, но у нас мало народу уходит. Платят неплохо, процесс отличный, область — лучше не придумашь. Технологии передовые. Люди — приятейшие. Много пьют :) Большинство коллег пишут технические блоги, хорошо оцененные в сообществе. Одна девушка-программист ушла… и через 3 месяца вернулась!
SVN (subversion) — система контроля версий, где каждая новая версия получает свой номер, и всегда можно вернуть любую из прошлых версий.
Комит (commit) — внесение новой версии в систему SVN.
Ротация полезна свежим взглядом, и это отличный инструмент для обучения. Кроме того, автоматом получается аудит кода, и вносятся изменения.
Про Ганта отличный ответ от Goder.
Документы архитектуры имеют смысл в основном до её реализации. На их написание уходит невероятное колличество времени, и куча ревизий. А в результате всё равно может получиться нечто, неудовлетворяющее требования.
Технические решения принимаются всей командой — предложения обсуждаются, анализируются, если надо, инженеры идут к бизнесу, или к кому-то кто лучше понимает какой-то технический вопрос. Из-за постоянной совместной работы инженеры хорошо знают сильные и слабые стороны друг друга, и могут решить, основываясь на этом.
Случается, что ответ остаётся не ясен — например, остаются 2 конфликтных мнения, или несколько разных идей. В таком случае мы делаем «спайк» (spike) — выделенное колличество времени выделяем на R&D — research and development, исследование и разработку, где желающие пытаются изучить и реализовать прототип решения.