Ненормальный Agile в финансах

    О системе

    Фирма, в которой я работаю, разработала свою трейдинговую платформу типа MTF. В этой системе ежесекундно производятся десятки тысяч торговых операций, и с помощью паттерна Disruptor, средняя скорость выполнения трейда не превышает 20.5 миллисекунд. В проекте задействованы сложнейшие интеграции с третьими сторонами — крупными банками, Лондонским Домом Клиринга LCH и другими корпорациями.

    На разработку проекта ушло около 3 лет и команда из примерно 20 инженеров. В проекте нету и не было ни одного руководителя проекта, координатора, планов проекта, диаграмм Гантта, документов архитектуры, спецификаций требований, и планов тестирования.

    Кроме наград за выдающиеся технологии, компания признаётся в сообществе Agile за простой и эффективный процесс разработки. О нём я и хочу рассказать в этом посте.

    О процессе

    Компания использует свой процесс разработки на базе Agile. Разработка системы никогда не прекращается, и новые требования клиентов регулярно исполняются, с циклом выпуска новой версии раз в 2 недели.

    Разработчики компании разделяются на 3-4 группы, каждая из которых занимается определённым направлением. В каждой группе 5-6 программистов, тестер и аналитик.

    Работа всех команд разделяется на двухнедельные итерации. Итерация начинается в среду, и заканчивается через 2 недели во вторник. Середина недели выбрана для того, чтобы не надо было срочно заканчивать разработку в пятницу, задерживаясь на работе.

    Требования на новую версию появляются в основном от клиентов, отдела маркетинга и отдела продаж. Все пожелания записываются на картонные карточки, которые приклеиваются на стену планирования.

    Стена планирования поделена вертикально на команды, и горизонтально – на итерации. Все стена содержит задания на четверть года, 6 итераций. Новые карточки приклеиваются на самый верх, а беклог находится внизу. Между ними – 6 итераций.

    Каждый вторник все заинтересованные стороны собираются возле стены планирования и переклеивают карточки по приоритетам, таким образом планируя следующие итерации. Обычно в итерации на команду бывает 2-4 карточки.

    Аналитик собирает детальные требования для карточек следующей итерации. Требования записываются в систему Mingle. Обычная карточка содержит 5-10 критериев принятия, в форме предложений типа «Если трейдер выставил размер заказа, он должен сохранится до последующего изменения»

    О работе в итерации

    Каждую вторую среду в 10 утра начинается ретроспектива и «кик-оф» следующей итерации. Команды разбегаются по митинг-румам или диванам (кому не хватило), и начинают встречу с поедания торта.

    В ретроспективе команда обсуждает, что было хорошо, что плохо, какие есть вопросы и идеи. Для этого доска расчерчивается на 4 сегмента, куда назначенный доброволец записывает рассуждения членов команды. Цель этого упражнения — придумать улучшения для следующей итерации.

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

    Потом начинается разбор новых историй, где аналитик рассказывает о плане на следующую итерацию. Разработчики задают вопросы, проясняя требования.

    Карточки переезжают со стены планирования на стену канбан для этой команды. Стена канбан поделена на задачи – горизонтально, и статус – вертикально. В первой колонке содержатся все неначатые задачи. Следующие колонки занимают начатую карточку, потом «в прогрессе» и «закончено».

    Разработка истории начинается с разбития её на подзадачи. Вся команда собирается на кухне, и на клейких листках разбивает карточку на подзадачи. Нередко на этом этапе проектируется решение – для этого мы используем белую стену и разноцветные маркеры. Клейкие листки переходят на доску канбан в раздел «Начато». Выбирается первая и вторая задача, с парой инженеров на каждую.

    Обычно первой задачей является написание тестов. Этим занимается пара из программиста и тестера, тестера и аналитика, или аналитика и программиста. Тесты пишутся ориентируясь на критерии принятия.
    Все тесты – это исполнимые спецификации. Тесты являются непосредственной частью кода системы, и участвуют в среде постоянной интеграции (CI). На данный момент у нас около 20 000 тестов, и каждый комит подвержен автоматическому тестированию против этих тестов.

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

    Кроме «спаривания», мы используем «столпотворение» (swarming) – разработку одной истории несколькими парами одновременно. Одни делают пользовательский интерфейс, другие тем временем – серверную сторону. Так как разбивка на подзадачи и проектирование было совершено всей командой, все отлично знают что надо делать.

    В разработке тоже происходит постоянная ротация – пары сходятся и расходятся, меняются заданиями. В результате все знают всё, и нужда в отдельных ревью кода исчезает. Кроме того, повышается доверие и улучшаются отношения в команде, потому что она просто работает как один организм.

    Изменения постоянно отправляются в SVN, где подвергаются автоматическому тестированию.
    Теоретически, система готова для запуска в любой момент времени. Посреди офиса висят мониторы, отображающие статус тестирования, скорость исполнения, латентность и прочие параметры.

    Вот такой нетипичный для финансовых организаций процесс разработки используется в Лондонской Бирже Разнообразных Активов (LMAX). Все планирование выставленно на всеобщее обозрение, каждый разработчик знает работу всей системы и практически каждой конкретной функции. В результате «спаривания» и «столпотворения» спецификации не нужны, нету конфликтов между разными частями организации. Каждый всегда может предложить новое решение, ознакомившись с «настенной живописью» соседней команды. Документы отсутствуют как класс, электронная почта практически не используется. Нету комитетов принятия решения и скучных встреч обсуждения планов…

    Кстати, нам всегда нужны талантливые тестеры и программисты Java.

    P.S. работа в Лондоне
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 68

      +2
      Как-то все очень идеально звучит.
      Вы хотите сказать, что весь процесс проектирования происходит на доске и только? Этого достаточно что бы писать качественный код и не ловить на тестах кучу багов?

      З.Ы. Ваша доска итераций и задач напоминает мне Jira+GreenHopper… ;)
        0
        Ответ ниже — случайно не туда закомментировала :)
        +4
        В основном — да, на доске.
        Если функциональность немного более серьёзная, аналитик продумает всё заранее, но в итоге, опять-таки, «задокументирует» это на доске. В случае если решение сложное или черезчур оригинальное, фото доски выкладывается на корпоративную вики…

        Качественный код достигается благодаря способным программистам :) и постоянному спариванию. Каждый принимает ответственность за свой кусок, и старается его сделать как можно лучше. Временами оказывается, что не всё было учтено, и приходится делать рефакторинг в середине итерации. При спаривании такой рефакторинг сложнее смести под ковёр.

        Jira+GreenHopper звучат знакомо. У нас все процессы планования малотехнологичны :)
        • НЛО прилетело и опубликовало эту надпись здесь
            +3
            Побочные эффекты спаривания многогранны!
            0
            А что ещё есть в вашей вики? :)
              +2
              Некоторые советы по программированию, инструкции установки используемых программ, объяснения как делать релис, немного инфе по системе…

              Так же там хранилище финансовых процессов и требований регурирующей организации…
                0
                В принципе, очень классно что экономится куча времени, которое иначе тратится на создание всяких описаний архитектуры и т.д., жаль что не во всех организациях применим такой подход (нарисовал — сфоткал). Насколько я понимаю, архитектура не описывается целиком и описание не обновляется, люди сами помнят или могут поднять забытое из тестов и вики. Я так понимаю что всё вами описанное работает где-то около 3 лет… Или больше?
                  +2
                  Жестких правил по обновлению ресурсов нету. Если инженер чувствует, что изменение важно и\или сложно, он обновит вики.

                  Система работает чуть более года, а разработка длилась около 3х лет.
                    0
                    Есть такой тренд: поддерживать up to date как можно более полное описание архитектуры, что вроде как должно дать меньшую зависимость от ключевых людей и большие возможности всех остальных иметь доступ к информации. Реально же почти всегда проекты делаются командой без особых описаний, на драйве и слаженной работе, но поддерживать этот продукт другим людям, когда все «отцы-основатели» ушли потому что у них появился новый вызов, почти невозможно. Так вот где компромис? Ваша версия, если не лень, конечно. :)

                    P.S. Спрашиваю потому что мне кажется, что даже используемый вами подход может дать сбой, если люди начнут остывать к общему делу и расходиться.
                      +2
                      >вроде как должно дать меньшую зависимость от ключевых людей и большие возможности всех остальных иметь доступ к информации.

                      В том-то и дело, что «ключевых» людей не должно быть. Практически все решения производятся группой, а над сложными частями системы к концу реализации поработают практически все, прощупав и почувствовав каждый аспект — конечно, благодаря «спариванию» и ротации.
                      Офис организован так, что спонтанные сессии архитектурного дизайна всегда проходят в самом «гнезде» инженеров, на проходе, соединяющем все важные органы офиса (как митинг-румы, кухню, выход, туалет). У нас все инженеры — народ любопытный, и любит вставить свои три копейки — поэтому как только учуют интерес, присоединятся.

                      Такое «сования носа» у нас очень поощряется, и никто никогда не скажет, мол, иди работай, хватит подслушивать.

                      >когда все «отцы-основатели» ушли потому что у них появился новый вызов

                      Может прозвучать самоуверенно, но у нас мало народу уходит. Платят неплохо, процесс отличный, область — лучше не придумашь. Технологии передовые. Люди — приятейшие. Много пьют :) Большинство коллег пишут технические блоги, хорошо оцененные в сообществе. Одна девушка-программист ушла… и через 3 месяца вернулась!
                        0
                        Можно к вам уборщиком?:)
                          +2
                          Неа.

                          Знаем мы вас, отмоете наши стены, сметёте упавшие карточки — что мы будем делать?
                          Уборщики — смерть agile'у!
                          +2
                          Организация процесса правда впечатляет. На самом деле. Спасибо вам за рассказ и ответы на вопросы, они дали пищу для размышлений.

                          Я понимаю что у меня не получается точно спросить что хочу узнать. Потому что это вопрос из другой категории и напрямую к рабочему процессу, вроде как, отношения не имеющий. Я задал его как вопрос про новые вызовы, но то, о чём я на самом деле хотел спросить — шире.

                          Смотрите, трейдинг сейчас это совсем не то же самое, что трейдинг 10 лет назад. Даже совсем не то же самое что 5 лет назад. Это к тому что если сейчас ваш продукт это cutting edge всего что есть в трейдинге сейчас, то через 5 лет могут случиться две вещи сразу: спрос на те виды операций, которые ваш продукт может обрабатывать, не изменится, но появится 100500 новых инструментов, которые и будут новым cutting edge. Люди станут старше (кстати, интересно каков средний возраст сейчас) и их сфера интересов почти неизбежно сместится в сторону семьи. Заметьте, а продукт всё ещё востребован и не меньше чем раньше, а время идёт: 5, 10, 15 лет.

                          Я сейчас работаю с людьми, которые строили похожий cutting edge в 80-х, на коболе и мейнфреймах. В какой-то момент произошло насыщение рынка и стех пор нет большего спроса на их продукт, но нет и меньшего, но есть ворох новых требований, которые надо внедрять. Но к чему я веду, к тому что их знание более никому не передаётся и система будет жить пока они не уйдут на пенсию. При этом они — отличная команда, у них классно всё налажено, но они создали такую степень устойчивости процесса, что у них не было необходимости искать что-то на стороне. И ни смотря на то, что они постоянно развивались, они совершенно выпали из мейнстрима и сейчас они — последние из могикан. И насколько я могу судить, такая изоляция от мира присуща любой команде и чем лучше процессы в команде и чем глубже знание технологии, тем сложнее им развиваться и пробовать новое. Может не поначалу (первые 5-10 лет), но дальше.

                          Надеюсь, мне удалось донести мысль не слишком путано.
                            +1
                            Наша система разработана на Java, с использованием других новых компонентов для интеграции (мы получили какую-то награду за интеграцию с системой Informatica). Недавно мы перешли на новую версию Java, и так как этот язык, вроде, умирать пока не собирается, судьба мейнфреймов нам пока не грозит. Вообще, когда выходит новая версия чего-либо, мы её внедряем и остаёмся cutting edge :)

                            Люди у нас приходят и уходят, команда растёт и меняется. В этом году ушло 2-3 человека, пришло 4-5 — процесс и знания распространяются.

                            Если появятся новые инструменты, или какие-то прочие требования — мы их добавим. На то мы и agile. В этом году, например, мы удвоили колличество тогровых пар форекса.

                            Возраст инженеров у нас разнообразный. Есть совсем молодые (лет 25), много 40-летних, несколько постарше. Дети почти у всех есть…

                            Да, система всё равно не вечна, как и всё остальное. Ничего, построим новую, где-то в другом месте.
                            0
                            А как у вас происходит процесс принятия решения при разделении мнений сторон?
                              0
                              Скопиирую с другого ответа:

                              Технические решения принимаются всей командой — предложения обсуждаются, анализируются, если надо, инженеры идут к бизнесу, или к кому-то кто лучше понимает какой-то технический вопрос. Из-за постоянной совместной работы инженеры хорошо знают сильные и слабые стороны друг друга, и могут решить, основываясь на этом.

                              Случается, что ответ остаётся не ясен — например, остаются 2 конфликтных мнения, или несколько разных идей. В таком случае мы делаем «спайк» (spike) — выделенное колличество времени выделяем на R&D — research and development, исследование и разработку, где желающие пытаются изучить и реализовать прототип решения.
                  0
                  а аудит систем вы как проходите без документации внесенных изменений?
                    0
                    А зачем документы?
                    На крайняк есть svn :)
                  +1
                  «и начинают встречу с поедания торта» А заканчивают в тренажерке?
                    +2
                    :)
                    У нас половина народу на великах на работу добирается, они стройны, спортивны и красивы.

                    Тортами мы вообще грешим — последние 2 недели каждый день по несколько тортов, пирогов, коробок конфет…
                      0
                      А что со второй половиной?
                        +2
                        Они на диете :)
                    +1
                    Всё настолько любопытно, что хочется задать кучу вопросов:
                    Правильно ли я понимаю, что аналитики полностью разбираются в предметной области?
                    Проходят ли какую-то предварительную фильтрацию требования от кастомеров, прежде чем появиться на доске планирования?
                    Каким образом производится включение новых сотрудников в команду?

                    Заранее спасибо :)
                      +3
                      Да, аналитики отлично разбираются в предметной области, а так же неплохо — в коде.

                      Требования от клиентов фильтруются сначала просто продажами-маркетингом (если мы это сделаем, кто ещё извлечёт от этого выгоду? Стоит ли игра свеч? Совпадает ли это с нашим направлением?), а позже — всеми остальными. У нас нет барьеров — и если инженер, проходя мимо беклога, или, после встречи планирования, решает, что требование бессмысленно, или трудновыполнимо, его мнение обсуждается и учитывается.

                      Новых сотрудников сначала обучают системе — один из опытных программистов проводит с ним полдня, рисуя на доске архитектуру системы и поясняя решения. Потом он начинает «париться» наравне с остальными — начиная задачами попроще.

                      Ещё у нас серьёзный испытательный срок — бывает, человек не приживается.
                      +1
                      Спасибо за рассказ, очень интересно!
                      И тоже хочется задать несколько вопросов.

                      1. Не бывает ли такого, что при внесении изменения возникает вопрос «Почему это было сделано именно так? Кто это просил? Кто и почему это так запрограммировал?». И никто из текущих людей этого не помнит (допустим, было написано давно, несколько лет назад). Как решаете такое?

                      2. Сколько в среднем разработчик и аналитик работает на этом проекте?

                      3. Как решаете архитектурные вопросы, если у людей в команде существенно разные мнения и нет формального архитектора? Есть неформальный? Или как-то все-таки быстро договариваетесь?

                      4. Сколько строк кода в итоге есть в системе и на каком языке? Сколько из них — тесты?

                      5. Сколько времени проходит от прихода в проект нового человека до его полноценного погружения? Ну, хоть примерно? Сколько времени длится испытательный срок?

                      6. Есть ли в системе СУБД и как от нее экранируетесь для тестирования? Как тестируется само взаимодействие с БД и ее структуры?
                        +1
                        1. Обычно такого не бывает, потому что 4-5 человек всегда участвовали в разработке, и ещё 3-4 слышали краем уха. Иногда случается, что забывается, как оно было сделано, но и тут есть решения — первое — почитать тесты, второе — покопать код. Так как эти действия тоже совершаются парно, скоро память восстанавливается :)

                        2. Не совсем поняла вопроса. Вместе мы обычно работаем вначале каждой истории, при написании тестов. Аналитики и программисты сидят рядом, а из-за того, что программеры парятся, даже если аналитик не в паре, он слышит все обсуждения и при надобности, вставляет свои 5 копеек, лезет в код или начитает что-то объяснять.

                        3. Архитектора нет, ни формального, ни неформального. Некоторые немного лучше разбираются в некоторых вопросах, чем другие. Нередко возникают горячие дискуссии, идём спрашивать у клиента, привлекаем кого-то их другой команды, но в итоге приходим к решению.

                        4. Ой… пишем на Java… (ушла строки считать)

                        5. До погружения, конечно, зависит от способностей. 3 недели назад присоединился новые инжинер, уже в полном порядке и с кучей отлчных идей. Испытательный срок длится 3 месяца.

                        6. База есть, но очень простая — в основном для аудита и прочих логов. Практически все операции происходят в памяти. Для тестирования у нас разработана спецальная библиотека, и при надобности она делает запросы в БД. Я тольком не знаю, как она работает — если когда разберусь, напишу отдельно.

                        ПС. Строк около 1 000 500, из них тестов около 133 000.
                          0
                          > 2. Сколько в среднем разработчик и аналитик работает на этом проекте?

                          Я имел в виду, есть ли уже какая-то статистика сколько времени человек работает до увольнения? Или пока только нанимаете?
                            0
                            Как это, до увольнения?
                            У нас никого не увольняют :)

                            По собственному желанию — кто как. В Лондоне обычно меняешь работу года в 2-3.
                            В нашей компании, мне кажется, эта средняя повыше.
                            0
                            Хм… Удивительно мало тестов, на мой взгляд. И это — при отсутствии другой документации.
                            На что похожи эти тесты? Или есть несколько категорий тестов? Модульные? Приемочные?
                              0
                              Есть юнит тесты и тесты принятия (Acceptance tests).

                              Последние очень легко читабельны, их название всегда типа ценаДолжнаБытьПозитивнойИКратнойТику (priceShouldBePositiveAndMultipleOfTickSize) — и тест в нескольких строках убедится, что другая цена не примется.
                              0
                              Ой, еще вопросы созрели!

                              * А чем у вас занимаются тестеры, если разработка начинается с написания автотестов?

                              * А кто у вас занимается сопровождением эксплуатируемой системы? У нее же есть пользователи и есть проблемы и непонятки, которые нужно оперативно решать, в т.ч. с привлечением разработчиков? Как это происходит?

                              * В ситуации, когда есть несколько важных вещей, которые нужно сделать, но все сделать не успеваете — КТО решает, куда бросить ресурсы?

                              * Какие проблемы известны в проекте? :) Технические и организационные? Ведь без проблем не бывает.
                                0
                                1) Пишут автотесты, придумывают, что ещё потестировать, проводят ручное тестирование — к сожалению, не всё можно автоматизировать. По-моему, у нас тестерам интересно работать — обычно это скучно и однообразно.

                                2) Одна из команд всегда «на дежурстве», и выполняет это сопровождение. Когда всё работает, они придумывают, как улучшить процесс — например, какие новые способы предотвращения неполадок, новые отчёты и пр.

                                3) Да, бывает. В зависимости от сложности — если мелочь, то программисты и аналитик решат, что хрен с ним. Бывает, доходит до ген. директора, но чаще всего бизнес решает (те, кто и запросили изменения)

                                4) Проблемы тоже случаются. Организационные реже — хотя вот в прошлой итерации моя команда что-то разучилась говорить «нет», в итоге потратили 2 дня на весьма бесполезный css. Технические — как у всех, думаю. То сервак заглючит, то лицензия не вовремя закончится, то просто окажется, что не совсем правильно спроектировано. Ничего особенного :)
                            –3
                            Орфографию поправьте, пожалуйста.
                              +1
                              Я вроде сделала спеллчек — больше ничего не вижу. Укажите на ошибки, поправлю.
                              –2
                              Не хватает расшифровки терминов:
                              «канбан»
                              «комит»
                              «SVN»

                              И не понятно, почему постоянная ротация обеспечивает хороший результат и так ли это на самом деле. Вообще не вижу в этом смысла. Свежий взгляд конечно хорош, но уходит время на разбор чужого кода и новой задачи. Зачем?

                              >«В проекте нету и не было ни одного руководителя проекта, координатора, планов проекта, диаграмм Гантта, >документов архитектуры, спецификаций требований, и планов тестирования.»
                              А разве все эти доски не являются планами проекта, тестировнаия и диаграммой Ганта?
                              Так же как и белая доска с маркером заменяет документы архитектуры и спецификации требований.

                              Разница в том, что документ согласовывается и утвреждается для определённости. А как здесь происходит отсев левых изменений — не ясно. Подошёл участник к доски, внёс рац предложение, а если оно не «рац», а как раз наоборот — кто решает принимать его или нет? А если сталкиваются два противоположных предложения — кто решает какое оставить?
                                +2
                                Статья явно для людей, связанных с программированием, и интересующихся разработкой сложных проектов. Описывать работу с системами управления версиями, на мой взгляд, излишне для такой аудитории.

                                Ганта рассчитывают до исполнения на основе трудоёмкости операций, определяя последовательно выполнения операций и время работы. В Agile, насколько я понимаю, спланировать весь проект невозможно, разработка идет от итерации до итерации, а внутри итерации операции выполняются исходя из приоритетов разработчиков.
                                  +3
                                  Канбан — японская система организации производства. Основное отличие — малое колличество параллельных задач. В данном случае имеется ввиду стена типо вот этой — technitai.files.wordpress.com/2011/04/simple-kanban-board.png

                                  SVN (subversion) — система контроля версий, где каждая новая версия получает свой номер, и всегда можно вернуть любую из прошлых версий.

                                  Комит (commit) — внесение новой версии в систему SVN.

                                  Ротация полезна свежим взглядом, и это отличный инструмент для обучения. Кроме того, автоматом получается аудит кода, и вносятся изменения.

                                  Про Ганта отличный ответ от Goder.

                                  Документы архитектуры имеют смысл в основном до её реализации. На их написание уходит невероятное колличество времени, и куча ревизий. А в результате всё равно может получиться нечто, неудовлетворяющее требования.

                                  Технические решения принимаются всей командой — предложения обсуждаются, анализируются, если надо, инженеры идут к бизнесу, или к кому-то кто лучше понимает какой-то технический вопрос. Из-за постоянной совместной работы инженеры хорошо знают сильные и слабые стороны друг друга, и могут решить, основываясь на этом.

                                  Случается, что ответ остаётся не ясен — например, остаются 2 конфликтных мнения, или несколько разных идей. В таком случае мы делаем «спайк» (spike) — выделенное колличество времени выделяем на R&D — research and development, исследование и разработку, где желающие пытаются изучить и реализовать прототип решения.
                                    +2
                                    Про документы архитектуры можно 5 копеек? К тому же после воплощения системы в коде, в документах почти всегда найдётся что поправить, но бюджета на это уже, как правило, нет и документ остаётся таким как был до создания системы. Можно сказать, что это из-за кривых рук составителей документов, что в очень общем по своей сути документе были слишком конкретные детали, но это будет лишь половиной правды, потому что заказчик часто грешит детализацией там, где она не нужна ему самому.
                                  0
                                  Судя по тому, что народ на великах добирается — разработка не в Москве?
                                    0
                                    Все, увидел :)
                                      +1
                                      В Лондоне велики — смерть за поворотом :)
                                      0
                                      Блин, так вот, что такое agile и kanban :) Оказывается, мы этих два страшных слова тоже у себя применяем :)
                                        0
                                        > В разработке тоже происходит постоянная ротация – пары сходятся и расходятся, меняются заданиями. В результате все знают всё, и нужда в отдельных ревью кода исчезает.

                                        Мне кажется, не могут люди знать все о такой крупной системе, как не делай ротацию. Но все познается в сравнении: был опыт работы без «насильственной» ротации разработчиков? Интересно сравнить фокус-фактор или другие количественные характеристики спринта в том и другом случае.

                                        P.S. А требования+условия работы в вашей компании, как узнать?
                                          0
                                          Всё люди не будут знать, но будут знать, куда смотреть. А в паре — и то проще.

                                          Ротация у нас не «насильственная» — если кто-то считает это плохой практикой, в Лондоне куча работ. Обычно инженеры очень рады работать с ротацией. Бывает, что конкретный программист хочет закончить задание в данной паре — это всегда пожалуйста.

                                          Фокус-фактор и прочие характеристики мы не практикуем.

                                          Требования — посмотрите на сайте LMAX.
                                          0
                                          не прочел все комменты :) я прям переживаю за вашего проектного менеджера или так сказать за звено между разработчиками и инвесторами, то есть кто понимаю и те кто не понимают…

                                          Не ужели не одна из стороне понимают что документация, как и библия, написано для того чтобы помнили, и боялись :)

                                          Я рву на себе волосы просто!!!
                                            0
                                            У нас нет тех, кто «не понимает». Бывает, не знаешь чего-то — идёшь и спрашиваешь. Всё просто.

                                            «Чтобы боялись» — это не наш метод.
                                              0
                                              хотите сказать от инвестора до самого программиста знает все от A до Z ?? ))
                                                0
                                                Инвесторы — это частные люди, их мы лично не знаем. Счёт открыть может кто угодно, это онлайн-сервис.

                                                А так, бизнес очень неплохо понимает, что к чему. Конечно, кодить они не смогут, но знают ограничения.
                                                  0
                                                  Хорошо что бизнес уже построен и имеются прибыли и это минимизируется риски, но мне было интересно, когда команда еще собиралось и не окупаемости, разве тогда не было контроля документации??

                                                  Ведь не было еще 100% уверенности во всей команде? на любом этапе могло произойти полная смена команды разве не так?
                                                    0
                                                    ну не на любом этапе, я имел ввиду первые этапы разработки, на любом из них.
                                            0
                                            А у вас изначально с самого нуля разработка шла по agile или эту медодику вы уже внедрили на сопровождении?
                                              +1
                                              Да, с нуля. У нас в офисе есть стена, на которой приклеены все законченные карточки. Впечатляет.
                                                0
                                                а как в таком случае «бизнес» (руководство) определял в самом начале (когда вообще ещё ничего не было), что продукт должен быть выпущен такого-то числа с таким-то стартовым функционалом?
                                                  0
                                                  Примерно так же, как и везде.

                                                  Только что в нашем случае не было талмуда документации, и требования менялись по мере приближения даты выпуска, и понимая, как оно всё выглядит и как будет работать
                                                    0
                                                    Т.е. всё-таки изначально было классическое «водопадное» планирование?
                                                      0
                                                      Честно говоря, не знаю, не видела.
                                                      Судя по стене выполненных задач — не было.

                                                      Но наверное, были какие-то планы и доказательства бизнес идеи — хотя бы для получения спонсорства.
                                                  0
                                                  а как в таком случае «бизнес» (руководство) определял в самом начале (когда вообще ещё ничего не было), что продукт должен быть выпущен такого-то числа с таким-то стартовым функционалом?
                                                0
                                                Это как раз самое нормальное программирование… Но пока не все понимают :)
                                                  0
                                                  Это как раз нормальное программирование… Но пока не все это понимают :)
                                                    0
                                                    По-настоящему, не везде такая модель подойдёт.

                                                    Но да, весьма нормальное :)
                                                    0
                                                    можете написать про ваш технический парк серверов, сколько и какое там железо =)
                                                      0
                                                      Вот как раз с этим мне не приходилось работать. Не знаю.

                                                      Точно есть главный центр на супер-скоростной ветке интернета и второй, в другом месте, для Disaster Recovery. Где и что стоит — без понятия.
                                                      0
                                                      Русских у вас много или Вы одна такая? :) Или как вообще распределение по народностям, все англичане кроме Вас или все разные?
                                                        0
                                                        Есть несколько русских, но в технологии я одна.

                                                        В основном в технологии у нас англоговорящие иммигранты — американцы, австралийцы, новозландцы. Англичан, думаю, четверть, или даже треть. По одному человеку есть из разных стран — Румыния, Турция, Испания, Израиль. Разношёрстно.

                                                        В технологии все белые, это необычно для ай-ти в Лондоне.
                                                        0
                                                        Тащемта, 20 толковых инженеров отлично будут работать в любом более-менее адекватном процессе. Цените своих людей, рад за вас.
                                                          0
                                                          В среде, поощряющей отличную работу, это ещё легче :)
                                                            0
                                                            Конечно. В случае хорошей комманды главное правило менеджмнта: «не навреди». Agile, тем более канбан, отлично выполняет это правило. Скрам вот иногда даже слишком строгим оказывается.

                                                        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                        Самое читаемое