Компания
35,61
рейтинг
17 мая 2012 в 19:44

Разное → Наш процесс разработки: 50 месяцев эволюции

Нашей компании уже 6 лет. Она была основана на принципах agile и росла на них. Мы использовали Extreme Programming с самого первого дня, добавили немного Scrum позже и в конце концов переключились на Kanban. Хочется поделиться бесценным опытом и рассказать об изменениях нашего процесса разработки за последние 4 года.





Контекст


Контекст очень важен, потому что он помогает понять, что может для вас сработать, а что — нет. Мы создаем TargetProcess, достаточно большое веб-приложение. Наша команда находится на одном этаже в одном офисном здании — никакой распределенности нет и близко.

2008 2009 2011 2012
Размер компании (в человеках)
15 22 30 40
Структура команды
Одна кросс-функциональная команда Две комадны:
Ядро (5 разработчиков, Scrum Master, 3 тестировщика)
Интеграция (3 разработчика, Team Lead, тестировщик)
Несколько мини-команд. Мы формируем мини-команды для каждой большой фичи. Мини-команда полностью ответственна за реализацию этой фичи Несколько (но уже больше) мини команд
Технологии
C#, ASP.NET, ASP.NET Ajax, NHibernate C#, ASP.NET, ExtJS, NHibernate C#, jQuery, NHibernate, NServiceBus C#, NHibernate, NServiceBus, 100% Javascript front-end, REST, Python


Наблюдения


Одна команда → мини-команды. С ростом компании одна команда была заменена несколькими мини-командами. Мини-команда полностью отвечает за дизайн и реализацию большой фичи, и обычно состоит из дизайнера, 1-3 программистов, Product Owner, 1-2 тестировщиков и писателя. Мини-команда принимает все технические решения, брейнстормит идеи и находит решения задачи. Она очень автономна и сфокусирована. На текущий момент у нас 6 мини-команд.



Технология. Серверная часть достаточно стабильна. Это все тот-же .NET стэк. Хотя за это время мы мигрировали с .NET 2.0 до .NET 4. Мы добавили ESB для плагинов в прошлом году, что улучшило расширяемость и масштабируемость системы. Мы все меньше и меньше довольны тем, как работает NHibernate, и двигаемся в сторону CQRS. Front-end стабильным назвать нельзя. Текущий UI представляет собой достаточно печальный коктейль из ASP.NET Ajax, ExtJS и нашего собственного фреймворка. Текущие усилия направлены на унификацию всего этого счастья, так что в самом ближайшем будущем старый UI будет полностью заменен на новый. Что приятно, системой можно будет пользоваться и в старом, и в новом интерфейсе, а это должно серьезно упростить миграцию существующих пользователей. Вот как менялся наш фокус на технологии по годам:



Процесс


2008 2009 2011 2012
Итерации
1 неделя а нету итераций, мы переключились на Kanban
Инструменты контроля прогресса
Task Board, Iteration burn down, release burn down Kanban Board, Cycle time Kanban Board, Cycle time, Builds board Kanban Board, Team Board, Cycle time, Builds board, roadmap на кухне
2008 2009 2011 2012
Ретроспективы
каждые 2 недели Делаем собрания, когда это требуется, нет никаких периодов. Придумали Issue Board с лимитом в 3 проблемы. Как только накапливается 3 проблемы — делаем собрание и решаем их. Проблемы может писать кто угодно. У нас stop-the-line собрания только с людьми, которых проблема касается. Происходит это не часто.
Оценка работы
Planning poker. Оцениваем User Story в поинтах А вообще не оцениваем работу
Учет потраченного времени
Четкий учет на всех задачах и багах. Не ведем учет. Надоело.
2008 2009 2011 2012
Обсуждение требований
Собрание по планированию итерации «Стартовое собрание» для User Story. Каждая User Story обсуждается перед ее началом. На собрании есть Product Owner + Тестировщик + Разработчики + Дизайнер.
WIP лимиты
Итерации Лимит в 3 User Story. Больше в прогрессе работы быть не должно. Забили на лимиты 2 user stories на разработчика (рекомендована 1). Вообще мини-команда сама решает.
Планирование релизов
Формальное собрание. Обычно релиз длиться месяца 2 Нет никакого планирования Создаем высокоуровневый roadmap на следующие несколько месяцев. Пересматривается каждые 3 месяца.
2008 2009 2011 2012
Дробление User Stories
User Story должна влезать в недельную итерацию Пытаемся дробить, но как-то не очень получается Все еще не очень... Немного лучше, но по-прежнему сложная для нас практика
Definition of Done (DoD) для User Story
Спецификация актуальна
Набор пройденных тест кейсов
Юнит тесты
Стартовое собрание
Спецификация актуальна
Набор пройденных тест кейсов
Пользовательская документация
Демо команде
Стартовое собрание
Спецификация актуальна
Набор пройденных тест кейсов
Набор автоматических кейсов
Пользовательская документация
Демо команде
Стартовое собрание
Спецификация актуальна
Набор пройденных тест кейсов
Набор автоматических кейсов
Пользовательская документация
Демо команде
Зеленый билд
Человеческие тексты
Тесты производительности
2008 2009 2011 2012
Собрания
Планирование релиза (команда)
Планирование итерации (команда)
Демо итерации (команда)
Ретроспектива (команда)
Ежедневный (команда)
Запуск User Story (3-4 человека)
User Story демо (4+ человека)
Ретроспектива (команда)
Ежедневный
Запуск User Story
User Story демо
Stop-the-line (команда)
Ежедневный
Запуск User Story
User Story демо (до начала тестирования!)
Stop-the-line (нужные люди)
Ежедневный
Ежедневное собрание
Есть, в 10 утра, занимает около 10 минут Есть, в 11 утра, занимает около 15 минут
UX
Что? Wireframes Скетчи (много идей и быстро), Живые прототипы, юзабилити тесты на живых людях, design studio Скетчи, Живые прототипы, юзабилити тесты на рабочей системе
Craftsmanship
Что что? Семинары Зарплата зависит от обучения
Мини-конференции
Оплаченное посещение крутой конференции
Семинары
Пятничные шоу
5 часов на самообразование в неделю
Зарплата зависит от обучения
Мини-конференции
Оплаченное посещение крутой конференции
5 часов на самообразование или на персональный проект в неделю


Наблюдение


Итерации → Kanban. Мы использовали итерации 3 года, а потом переключились на Kanban. В целом это было хорошим событием. Главная цель — возможность выпускать каждую фичу и каждый фикс отдельно и как можно быстрее. Многие периодичные собрания были упразднены и заменены на собрания-по-требованию. Со временем мы отказались от учета времени и оценки работы. Одним негативным эффектом отказа от итераций стало стремление фич становится большими. Когда нет итераций — нет особой необходимости разбивать работу на более мелкую. Мы с этим боролись на протяжении 3 лет с переменным успехом. В целом, пока большие фичи побеждают, но в этом году ситуация стала лучше.

Поинты → Отказ от оценок. В итеративной разработке оценки необходимы. Когда мы перешли на Kanban стало ясно, что от оценок особой пользы нет. Сейчас мы оцениваем работу на уровне «ну пару дней», «ориентировочно неделя», «не больше месяца», «очень долго». Иногда Product Owner скучает по оценкам, но когда мы стали делать Roadmap, такие общие оценки больших фич оказались достаточно точными.

Учет времени → Отказ от учета. Мы вели учет потраченного времени с первого дня жизни проекта, даже когда нас было всего четверо, работающих по вечерам и выходным. Так что учет времени был у нас в крови, и даже зарплата была привязана к количеству потраченных часов. Решение об отмене учета времени было непростым, многие в команде были против. На удивление, через пару месяцев все утряслось и подавляющее большинство людей с содроганием вспоминало заполнение тайм-шита за день. На самом деле нет никакого смысла учитывать время, если вы не оцениваете работу.

Планирование релизов → Ничего → Roadmaps. Такие шатания из стороны в сторону могут выглядеть странно (со стороны). Изначально у нас были формальные собрания по планированию релизов. А потом мы ввели Kanban и собрания как-то умерли. Оказалось, что без планирования релизов стало хуже. Мы постоянно теряли фокус. Релиз с четким фокусом — это очень хорошая и полезная вещь. Вы фокусируетесь на важных вещах и игнорируете остальное. Если фокуса нет, то имеется огромный соблазн сделать много мелких и не очень фич, которые слабо связаны между собой. Это размывает усилия и, в конечном итоге, выпускается просто список фич. Не так давно мы решили создавать roadmaps вместо планирования релизов. В разработке у нас может быть 3-4 больших фичи. Каждая фича имеет конкретную цель и занимает от 3 до 12 месяцев. Roadmap показывает все текущие фичи и некоторые будущие, только и всего.

Дробление User Stories. Забавно, но мы все еще не умеем делать это хорошо. Дробить работу — сложно. Да, у нас есть определенные улучшения, но время от времени большие User Stories все же просачиваются в разработку без всякого дробления. Кажется, в дроблении есть какая-то внутренняя сложность.

Definition of Done. Тренд четкий — DoD год от года становится более насыщенным и включает в себя все больше и больше вещей. Процесс развивается и хочется быть уверенным, что каждая фича готова к релизу полностью. Недавно мы добавили в DoD проверку текстов и тесты производительности.

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

Собрания. Сейчас у нас выжили только реально полезные собрания, которые сфокусированно решают конкретные проблемы. Единственное регулярное собрание — это ежедневное утренне. В Scrum довольно много всяких собраний. Это может и хорошо, когда вы только начинаете внедрять нормальный процесс разработки, но со временем они приедаются и надоедают. Собрания-по-требованию гораздо лучше: меньше людей, четче фокус, лучше результат.

User Experience. Это было круто. 4 года назад мы вообще ничего не слышали о UX. В настоящий момент UX практически встроен в ДНК компании. Многие люди в команде уделают большое внимание вопросам юзабилити, дизайна и восприятия продукта конечным пользователем. Процесс насаждения UX был достаточно длительным и начался с изменения видения продукта. Мы обучали людей, отправляли на конференции, проводили семинары, читали книги и пробовали очень разные практики. Какие-то хорошие результаты появились только через 2 года. А сейчас мы работаем на новым большим релизом и промежуточные результаты безумно классные (пока не покажем, создаем интригу).

Craftsmanship. Обучение и развитие профессиональных качеств не было частью культуры компании 4 года назад. Началось все в 2010, когда вся стратегия развития была полностью пересмотрена и изменена. Сейчас у нас тотальный дух знаний. Серьезно.

Вот как менялся фокус развития компании по годам:



Технические практики


2008 2009 2011 2012
Source control и бранчи
Subversion. Один бранч. Git. Каждая фича или баг-фикс делается в отдельном бранче. Мастер всегда готов к релизу. Git. Возвратились к одному бранчу, чтобы двигаться к continuous delivery
Парное программирование
Парное программирование строго обязательно. Разработчики меняют пару каждый день, чтобы посмотреть на проблему свежим взглядом, обменяться опытом и добиться реального коллективного владения кодом Обязательно для всех User Stories и сложных багов. Иногда люди работают в одиночку над более простыми задачами. Смена пар отменена. Оказалось, что это мешает сосредоточиться и раздражает Используется только для сложных задач Полностью опционально. Мини-команда решает сама, как ей работать
TDD/BDD
TDD настоятельно рекомендуется. Юнит тесты строго обязательны для каждой user story Весь новый код покрыт тестами. На стороне JavaScript ситуаци похуже. Также пытаемся использовать BDD На стороне JavaScript тоже все хорошо, используем QUnit. BDD ширится и растет Четкий фокус на BDD. Мы немного переделали NBehave под собственные нужны и сделали VS add-in для быстрого написания тестовых сценариев
Автоматические функциональные тесты
Несколько тестов на Selenium Много тестов на Selenium. Мы сделали собственный фреймворк на C# чтобы писать и поддерживать тесты Функциональные тесты запускаются параллельно на 20 виртуальных серверах Мигрируем на Selenium WebDriver. Виртуальных серверов уже почти 40
Continuous Integration
Очень простая. Компиллируется исходный код, запускаются юнит тесты в Cruise Control. Используем Cruise Control с несколькими разными сетапами Перешли на Jenkins По-прежнему используем Jenkins. Новая цель — перейти на Continuous Delivery со временем.
Feature toggling
Нету Мы используем feature toggling и двигаемся к continuous delivery.
Тестовое покрытие
черт его знает 50% покрытие юнит тестами и 30% покрытие функциональными тестами 70% покрытие юнит тестами и 40% покрытие функциональными


Наблюдения


Один бранч → Бранчи по фичам → Один бранч. Любопытная петля. Бранчи по фичам стали возможны после внедрения Kanban. Мы их использовали на протяжении 2 лет. Однако тяга к continuous delivery требует возврата в одному бранчу, что мы и сделали несколько месяцев назад. Переход был непростой, бранчи по фичам содержать гораздо проще и безопаснее, так что недели 3-4 trunk был красным 80% времени.

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

TDD → BDD. Разработка через тестирование применялась с самой первой строчки кода (ну почти) и использовалась все время. BDD более ориентированно на конечные кейсы и более понятно для Product Owner. Сейчас он пишет спецификации в формате Given/When/Then играючи. В целом, мы двигаемся к визуальным спецификациям, где много картинок, но мало слов.

И немного статистики на текущий момент:
  • 5200 юнит тестов
  • 2500 функциональных тестов (1700 Selenium и 800 JavaScript тестов)
  • Все тесты запускаются на 38 виртуальных машинах
  • Короткая сборка (без инсталляционного пакета) занимает 40 минут
  • Полная сборка занимает 1 час
  • 8400 коммитов в Git репозиторий в 2011 году




В заключение


Вот к чему мы пришли за последние 4 года



P.S. Если кто-то знает, как заставить Хабр форматировать нормально таблицы — дайте знать.
Автор: @9zloy
Taucraft Limited
рейтинг 35,61
Реклама помогает поддерживать и развивать наши сервисы

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

Похожие публикации

Комментарии (147)

  • +2
    > наш
    > мы
    > нас

    Простите, а кто вы?
    • 0
      Представитель «TargetProcess, Inc.» видимо?
    • +10
      Нашел-таки, кто вы, у вашей конторы же есть блог на хабре. Почему не туда?
  • +1
    Было интересно.
  • 0
    отлично, спасибо
  • +3
    Сколько незнакомых терминов. Автору спасибо за ссылки в тексте — пошел читать.
  • +2
    Используете свой продукт для разработки его же, надо же =)
    • 0
      Используем, конечно. Но в силу специфики процессов — далеко не полностью. На последней нашей внутренней конференции была замечательная презентация от нашего Product Specialist, как наши заказчики видят наш продукт. Достаточно интересно.
    • 0
      это ведь хорошо :)
      использую свой продукт «сидишь в шкуре пользователя».
  • +9
    Вы бы не могли подробнее рассказать почему вы вернулись к одному бранчу? Чем бранчи по фичам мешают continuous delivery?
    • 0
      На сегодня ситуация получается такая. Есть trunk, который пытаемся держать зеленым (получается где-то процентов на 70), есть одна большая ветка с новой функциональностью, в которой работают одновременно 5+2+1+1 человек (каждая команда над своей функциональностью, но очень часто пересекаемся), все остальное делается в trunk.
      • +6
        Это решается просто, есть ветка develop, и ветки staging и production.
        На сервере CI тестируются все три, причем для каждой своё четко прописанное окружение (первое время одинаковое, потом на staging — как в будущем production).
        • +4
          Меня порой пугает, насколько современные разработчики с трудом управляются с ветками :(
        • +1
          > Это решается просто, есть ветка develop, и ветки staging и production

          Где об этом можно почитать подробнее? Какая ветка за что отвечает, как происходит расслоение настроек окружения, etc?
      • +2
        Вы описали как оно у вас устроено, но не описали почему. Хотелось бы услышать причины, по которым вы отказались от бранчей по фичам и пришли к той схеме, которую вы описали. Спасибо.
  • +1
    Интересно, в каких случаях недовольны NHibernate'ом?
    • 0
      Больше всего из-за производительности. Старая модель, посторенная на хибернейтовских классах, в полный рост страдает из-за N+1 проблем.
      • +1
        У вас Rich Domain Model, поэтому Вы не можете для каждого запроса назначать стратегию fetch'инга?
        Или fetch используете, но это не помогает?
        • +1
          Да, rich model, плюс достаточно древний код, который сейчас никто переписывать уже не возьмется.
          • +1
            В таком случае, можно задать размер batch-size и при обращении к ленивым коллекциям сущности будут подгружатся страницами.
            CQRS не отменяет наличие ORM и проблему N+1.
            • +1
              А причем тут CQRS?

              P.S. Проблему fetch-стратегий он не решает, очевидно. Он хорош для масштабирования.
              • +1
                >Мы все меньше и меньше довольны тем, как работает NHibernate, и двигаемся в сторону CQRS.

                Подумал, что автор считает, что это связано. my bad.
                • +1
                  Оу, сорри, просмотрел этот момент в топике.

                  CQRS, очевидно, не панацея, просто другой подход (хороший). Вы все верно написали, NHibernate и CQRS (как подход) — не взаимоисключающие вещи.
      • +1
        «Старая модель, посторенная на хибернейтовских классах»
        А что значит на «хибернейтовских классах»?
        • +1
          Классы модели замаплены хибернейтом, потом модель «обогощена».
          • +2
            А, понятно. Ну еще Mark Seemann обсуждал это в комментах к своей превосходной статье At the Boundaries, Applications are Not Object-Oriented.

            Ведь, Rich Domain, следующая канонам DDD — это строго объектно-ориентированная вещь. А «Entity», «сущности» в ORM — это, по сути, структуры, DTO, для передачи данных и трэкинга изменений через прокси-классы.
  • НЛО прилетело и опубликовало эту надпись здесь
    • +1
      Ну вот не надо обобщать. В статье описана продуктовая компания, а ведь есть и разработка на заказ и проекты с фиксированным бюджетом, там без оценок и дедлайнов никуда.
  • +2
    Интересно, что вы используете .NET, C# и даже NHibernate на Application-уровне.

    Переход с ASP.NET WebForms для web-frontend'а вполне понятен. Но странно, что вы включили новое звено в свой технологический стек — Python. Есть вопрос — почему не ASP.NET MVC или Node.js? Ведь вы уже пишете на этих языках.
    • +1
      Думаю, пришла мини-команда извне и привила любовь к Python :)

      Вообще, динамические языки доказали своё право на место в экосистеме.

      Когда-то я был специалистом по C#, но последние годы я интенсивно пишу на JavaScript, Ruby, Perl, PHP и последнее время даже Python.
      • +1
        Ничего не имею против динамических языков в целом, а тем более — против Ruby и Python. Просто уже используется один стек (в любом случае). Интегрировать тот же ASP.NET MVC куда проще с бэк-эндом, написанным на .NET. Или Node.js, чтобы фронтэнд-часть сервера и клиент вообще общались на одном языке.
        • +1
          MVC — это вообще не туда. Node.js — тоже. Нам нужно было сделать DSL. Для этого лучше подходит скриптовый язык. На .NET выбор небогат. F# можно было бы еще. Но исторически сложился Python.
          • 0
            Понял. Просто почему-то показалось так из схемы, где вы показываете развертку по технологиям и по годам, что вы его для фронтэнда используете.
            Если DSL — вопрос снимается. F#, возможно, и лучше для DSL (и то, it depends), но вот это уж точно целая отдельная парадигма в существующий стек.

            Мой вопрос был исключительно в контексте фронтэнда. На схеме вы указали REST, а он же не является конкретной технологией, как все остальное из перечисленного. Поэтому сразу и недопонял. У вас же написано JavaScript-frontend, то есть, в сторону JS вы все-таки двинулись. Кстати, интересно узнать, в каком виде там JS?
    • +2
      Python появился в виде IDP одного из тестировщиков — на нем начали писаться тесты для REST api. Потом оказалось, что питон отлично подходит в качестве DSL. Python мы используем в виде IronPython. Вся логика продолжает крутиться на .net.
      • +2
        Тогда ты выбрали не тот язык )

        Вам нужен Ruby. Факт, что он лучше подходит в качестве EDSL.
        • +1
          IronRuby как-то не развивается, а вот IronPython очень даже.
          И вопрос. Почему Руби лучше подходит?
          • +2
            Сила Ruby в данном случае в блоках и в метапрограммировании в целом.

            Вот так выглядит DSL Chef:

            package "erlang"
            
            deploy "/home/ourcoolproject" do
              repository "https://git.example.com/repo..git"
              revision "production"
              user "site"
              enable_submodules false
              migrate true
              migration_command "rake db:migrate"
              # Giving a string for environment sets RAILS_ENV, MERB_ENV, RACK_ENV
              environment "production"
              action :deploy
              restart_command "touch tmp/restart.txt"
              before_migrate do
                # release_path is the path to the timestamp dir 
                # for the current release
                current_release = release_path
                 
                # Create a local variable for the node so we'll have access to
                # the attributes
                deploy_node = node
             
                # A local variable with the deploy resource.
                deploy_resource = new_resource
             
                python do
                  cwd current_release
                  user "myappuser"
                  code<<-PYCODE
                    # Woah, callbacks in python!
                    # ...
                    # current_release, deploy_node, and deploy_resource are all available
                    # within the deploy hook now.
                  PYCODE
                end
              end
            end
            

            А вот так DSL RSpec:

            describe Git do
              COMMIT = "45435ffdf5"
            
              describe :describe do
                mock(Git).shell("git describe #{COMMIT}") { "cool!"}
                Git.describe(COMMIT).should be "cool!"
              end
            end
            
            


            Частично объясняет devopsanywhere.blogspot.com/2011/09/how-ruby-is-beating-python-in-battle.html
            • 0
              На мой взгляд метапрограммирование — это штука, которую с большой опаской нужно пускать в проект и особенно в проект, где задействовано много людей с разной степенью компетентности.

              Лично меня куда больше устраивают парсеры в явном виде. И чем топорнее то, что они кушают в плане структуры, тем лучше.
              • 0
                Программируете на lisp/scheme?
                • 0
                  Да, случалось, это хороший язык для определенных задач, но речь идет именно о DSL.

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

                  Использование парсера какого-то стандартного формата с хуками как правило покрывает 90% тех случаев, когда применяется DSL и прочий подобный препроцесс, и этот вариант скорее всего будет лучше понятен разработчику, который будет ковыряться в вашем коде и его поддерживать.
  • +1
    Очень круто.
    А можно пару мыслей, что у вас будет в 2013 году? К чем идёте?
    Например, с возвратом к 1 бренчу, мы поняли, что git нам особо и не нужен, и можно было оставаться на svn?
    • +2
      Ох. это сложный вопрос. Вернее, простой для любых знающих обе системы — выбор очевиден — git. Но обьяснить это ярому svn-man — сложно.

      Возможность разработчику работать со своей историей коммитов, перелопачивать ее, локальные репозитории, гораздо более интерсный merge, и т.д. — это шикарно.
      • +1
        а что касается других моментов?
        про технологии, методологии, подходы? к чему движтесь?
        • +1
          Я недавно сменил компанию. Тут используют SVN. Первый бэтл за SVN закончился ничем, причин много. Предлагают использовать git локально (или git-svn, но это вообще недопонимание).

          Тут еще просто куча проблем, начиная с того, что utf-8 еще не общепринят (пришлось патчить сегодня Redmine из-за этого, потом переделаю...).
          • +2
            Но уже было прикол:
            1) Программист, ответственный за влитие кода тут в production, сегодня отказался производить merge из-за больших временных затрат. Предложил отдать готовые файлы (их никто не будет править, наверное, кроме одного?), пришлось самому это сделать (ручной rebase). Налицо одна из проблем SVN.
          • +1
            Четыре года назад также плотно работал с CVS и SVN (.masterhost).

            Факт в том, что rebase и merge чересчур ручные. А коммиты нельзя изменить.

            А самым показательным был один из советов по rebase, — делай diff -u и patch…
          • +1
            про git vs svn я не хотел спорить. Мне больше интересен сам процесс работы.
          • +1
            Посмотрите в сторону Mercurial:
            1. Проще установить Windows, если у вас люди работают на нем.
            2. Проще для понимания чем GIT

            Ну и как бонус:
            3. Хранение в репозитории истории ветки.

            Хотя для вас, как мне кажется 2 первых пункта более важные.
            • 0
              Одинаковы они для понимания, просто с одного на другой непривычно переходить :)
              • 0
                Порог вхождения в Mercurial ниже, learning curve у него менее крутая, ну и конечно Principle of least surprise он удовлетворяет намного лучше, чем Git.
                • 0
                  Спасибо, такой вариант ответа я уже слышал :) Может у вас есть пруфлинк на кривые обучения hg vs git?
                  • –1
                    У меня исключительно личный опыт и опыт коллег. Ну и потом, какой вы хотите пруфлинк? Пруф в плане доказательство? Вряд ли какой-то НИИ ставил эксперименты по всем правилам с контрольными группами и пр. на эту тему. Но если вы погуглите на тему git mercurial learning curve, вы увидите, что достаточно много людей думают так же, как я.
                  • 0
                    Добавлю ремарку о свём опыте изучения mercurial и git — первый изучить проще. Мнение субъективное, но не одинокое, от многих слышал такое же, а вот обратного (git изучить проще) не слышал.
              • –1
                Изучал как hg, так и git.
                Hg проще, т.к. есть такое понятие, как центральный репозитарий.

                + На столько меньше проблем с кросплотформенностью у hg, т.к. он на Python
                • +1
                  В hg центральный репозитарий совершенно не обязателен (он в общем то не отличается от других ничем, кроме того, что разработчики договорились между собой считать его центральным).
                  В git можно построить работу точно так же, в этом он от hg как раз не отличается.
                  • 0
                    Невозможно в git построить работу так же как и в hg.
                    А вот обратное достоверно. Смотрите что такое именованные ветки.
                    • 0
                      не всегда возможно*
                    • 0
                      Я знаю про ветки, но моё «можно построить работу точно так же» относилось к вашему высказыванию про «центральный репозитарий».
      • +3
        Эти плюсы — это плюсы даже не конкретно git-а, а децентрализованных репозиториев, просто самыми яркими представителями класса являются git и Mercurial (hg).
    • 0
      Тьфу-тьфу-тьфу, только не svn.
    • +1
      После git к svn? Я вас умоляю.
    • +1
      Вот что мне хотелось бы достичь за пару лет
      1. Убрать роль Product Owner. Хочется чтобы команда сама понимала, в какую сторону двигать продукт, какие фичи делать и как они должны работать. Сейчас мы в этом направлении предпринимаем первые робкие шаги.
      2. Выпускать новые фичи как только готовы. То есть без всяких задержек на стадии деливери. Сейчас задержки бывают около недели а то и двух, потому что выпускаются фичи батчами.
      3. Полностью отказаться от ASP.NET, ExtJS. 100% UI на яваскрипте. Надеюсь это будет уже через год.
      4. Добиться, чтобы приложение без труда работало с несколькими тысячами одновременно подключенных юзеров.
      5. Научиться в конце концов дробить юзер стори
      • 0
        спасибо.
      • 0
        Миша, расскажи, пожалуйста, как ты представляешь первый пункт. Имхо, Product Owner — это очень большой объем работы, именно он должен знать, куда развивается отрасль, какие фичи нужны, а какие нет…
        • 0
          Мне кажется, что задача продукт оунера — просто задавать стратегическое направление. Как максимум — определять эпики высокого порядка в виде проблем в виде «у нас очень сложно добавлять энтити в систему, надо чтобы это было просто и быстро» или «у нас нет возможности визуализировать прогресс для нескольких команд». Каждый эпик решает и делает мини-команда. Для этого, конечно, некоторым членам мини-команды придется поглубже погрузиться в предметную область, изучить что надо сделать, провести собрания и придумать решения. Не обязательно весь мини-тим должен это делать, может быть кто-то один для этого эпика возьмет на себя роль продукт оунера. Но в итоге, думаю, всем будет интереснее работать и результать может быть лучше на выходе.
      • 0
        А почему отказываетесь от ExtJS? Он вроде согласуется с вашей целью «100% UI на яваскрипте».

        Спрашиваю не из праздного интереса. В нашей команде тоже использовали ExtJS длительное время и теперь от него уходим по разным причинам. Хочется сравнить опыт.
        • 0
          а можете огласить тут причины? Другим, тоже интересно их послушать :)
        • 0
          ExtJS придуман, чтобы транслировать экспериенс десктопного приложения в веб. Это пагубный и порочный путь, которым мы случайно начали идти. Его очень тяжело кастомизировать под наши нужды и в итоге оказалось, что мы используем практически на уровне ядра. Все наши компоненты кастомные. Все дефолтные темы ExtJS ужасны чуть более, чем полностью. Так что я не могу порекомендовать его использовать никому.
          • 0
            Э… почему не кому?
            Если нужно сделать ERP систему на 100 форм, может он то что нужно, не?
            • 0
              Ну пожалуй что подойдет :)
      • +2
        Не боитесь за пользователей у которых что-то будет меняться чуть ли не каждый день? Понятно, что вашими пользователями являются разработчики, но все же непрерывное изменение продукта, причем не всегда в пользу улучшения для данного конкретного пользователя, будет все большим числом пользователей восприниматься как что-то негативное? Ведь, если продукт достаточно mature, то легко можно хоть полгода не обновляться инсталяцию, все будут знать как она работает без каких-либо неожиданностей. Те же частые обновления Firefox уже воспринимаются достаточно отрицательно, а его еще нужно установить, в отличие от saas-приложения.

        Если переформулировать вопрос, то о стабильных, LTS-версиях вашего сервиса думали?
        • +1
          Не боюсь. Подавляющее большинство изменений делаются на основе пожеланий наших клиентов. Мажорные релизы, как ТП3, конечно происходят нечасто. Но минорные могут происходить хоть ежедневно, от этого всем только хорошо, главное чтобы даунтайма не было. Мы не собираемся замораживать никакие ветки, но решать подобные проблемы с помощью фича тоглинга и кастомизации. Firefox катится в говно. Обновления фейсбука, которые происходят часто, далеко не все вообще замечают. Кто-нибудь заметил непрерывную загрузку в нотификациях (сегодня появилась)?
  • +1
    Вот тоже хотел спросит про git, каково ощущение от использования его в corporate environment?
    Нет проблем с тем что репозиторий целиком расползается по всем разработчикам? :)
    • +1
      У нас не совсем corporate, даже совсем не corporate. Но локальные репозитории — это действительно очень удобно, хотя мы не используем всю мощь гита (на мой взгляд). Синхронизация все равно происходит через центральный репозиторий, с которого собираются билды CI, мы пробовали синхронизироваться друг с другом, но это оказалось ненужным.
  • +3
    Большое спасибо за статью! Всегда интересно перенять чужой опыт :)

    По поводу эстимейтов — когда мы перешли на Канбан, задачи оценивать перестали. Просто держали очередь отсортированной по приоритету.
    Но Project Owner'у в какой-то момент эстимейтов стало не хватать. Ведь сложно задавать задаче приоритет, не зная, сколько времени займёт её реализация. Даже подумывали возвратиться на Скрам с его planning-митингами.
    Но в итоге придумали оценивать задачу грубо:
    1. Очень маленькая (минуты);
    2. Часы (от получаса до двух дней);
    3. Дни (от пары дней до двух недель);
    4. Недели (такие задачи обычно нужно разбивать на меньшие подзадачи).

    Оказалось, что такая грубая оценка уже является достаточным критерием для Project Owner'а при краткосрочном планировании.
    Более того, такие грубые оценки, как ни странно, оказываются более точными :) — в том плане, что разработчик намного реже ошибается и не выходит за пределы естимейта.
    • +1
      У меня примерно такие же ощущения.
  • 0
    Можете посоветовать хороший программный Kanban? Может что-то есть на примете.
    • +3
    • 0
      • 0
        Трело хороший. Но он не поддерживает лимиты и отчеты всякие. Если нужна просто доска со стейтами — то лучше трелло сложно найти
  • +1
    Олсьют юнит тестов за сколько проходит? Мы приближаемся к отметке в 3000 и время прохождения тестов радует не так сильно, как раньше.

    Насколько просто на практике происходит миграция с Selenium 1.0 на WebDriver? До миграции гоняли тесты в браузере или использовали RC?
    • 0
      Юнит тесты запускаются параллельно в 8 пачках, по 6 минут на пачку где-то.

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

      Не совсем понимаю разницу между RC и «в браузере» — у нас запускался selenium server и тест гонялись через него.
      • 0
        Не пробовали использовать Watin? Если да, то не могли бы сказать о ± того и другого? Мне всегда казалось что Watin использовать удобнее из-за того, что там не требуется ничего кроме mstest
        • 0
          Нет, насколько знаю, watin не пробовали. Сейчас мы вообще уходим от функциональных тестов как таковых — UI разделился на rest + JS, каждый тим пишет свои тесты — js на qunit, rest — на питоне, тестирование в браузере как таковое становится не нужным.
  • +1
    Как живо! Класс! Особенно графики супер!
  • +2
    Ребята, очень крутой пост, давно подобного не читал, спасибо.
  • +1
    Куча вопросов :)
    Почему уходите от jQuery? Не смотрели в сторону Entity Framework? Сравнивали Git и Mercurial, Jenkins и Team City? Что используете для unit тестов?
    • 0
      В сторону Entity Framework не смотрели, потому что старая модель слишком уж «богатая», переписывать ее нет смысла — новый UI использует наш маленький «ORM», в будущем, надеюсь, получится выкристализовать бизнес правила и уйти от хибернейта полностью — куда, пока не ясно. Jenkins vs TeamCity — выбор был в пользу Jenkins из-за его бесплатности — под дженкинсом сейчас крутятся 35 виртуалок. Для unit тестов — NUnit, NBehave, Rhino.Mocks, Selenium Web Driver, IronPython. Еще T4 — очень много генеренных тестов (~1000).

      На остальные вопросы ответов не знаю. :)
      • 0
        Вместо NBehave не смотрели SpecFlow там есть поддержка DSL, NUnit -> xUnit, Rhino.Mocks -> Moq.
        • 0
          NBehave немного заточили для NUnit, теперь типичный тест выглядит приблизительно вот так:
          [Test]
          public void ShouldShowCorrectEntityStatesInDropDownListWhenAddNewBug()
          {
          	@"Scenario: Should Show Correct Entity States In Drop Down List When Add New Bug
          	Given project 'Project1' for process 'All Practices' created
          	When user 'admin' logged in via login page
          		And navigate to add new bug page
          	Then add/edit Bug page should contain states: Open, Fixed, Invalid, Closed
          	".Execute(In.GlobalContext());
          }
          


          nUnit — xUnit, moq — rhino — не вижу смысла менять шило на мыло.
  • 0
    Прошу прощения, немного не в тему. А где вы так оформляли графику? Это сделано как-то программно или некий дизайнер вырисовывал на планшете? Очень понравилось оформление.
    • +1
      Я рисовал на iPad в приложении Bamboo стилусом.
  • +3
    Клёвые картинки. Но текст очень менеджерский и энерпрайзный. Если бы я решил играть в bullshit-bingo, я бы ещё на первом абзаце выиграл.
  • 0
    Отличный пост, вот только самим TargetProcess пользоваться не советовал бы. Хотя альтернатив таких масштабных не знаю, но даже набор разных аппсов будет лучше. В TP даже багтрекер есть, но всё недоделано (например фильтры в багтрекере) и плохо спроектировано UX.

    Чего стоит только аякс подгрузка основного контента после каждой загрузки страницы. Я оставлял фидбек об этом на дев форуме, но судя по игнору это в норме вещей. Всё настолько нефэншуйно что приводит к регрессиям, например ранее можно было работаьт с iPad/iPhone, в новой версии уже нет. Куча велосипедов в интерфейсе — одни вкладки можно открыть в новой табе, другие нет потому что это дивы. Главное — очень медленная работа клиент-сайда.

    С другой стороны, много чего реализовано неплохо (доска плюс-минус; поиск), но в многих других нужно делать кучу кликов. Особенно отмечу историю задачи/бага — чтобы узнать кто закрывал/переоткрывал надо каждое изменение раскрывать отдельно.

    Короче говоря, за полгода навязанного свыше использования накипело много негатива :(
    • +2
      Это во многом правда, что выражено в предложении "Текущий UI представляет собой достаточно печальный коктейль из ASP.NET Ajax, ExtJS и нашего собственного фреймворка."

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

      Если быть конкретным, то можно будет фильтровать ВСЕ что угодно. Никаких перегрузок страниц не будет. Клиент-сайд будет летать. Велосипеды останутся — но мы стараемся их делать очень классными.

      И на самом деле, если смотреть на альтернативные решения типа Rally и VersionOne, то там с UI все гораздо печальнее.
  • –1
    > и в конце концов переключились на Kanban.

    Вот этот момент меня удивляет. Канбан это ОДИН из 14 (!!!) принципов управления производственным процессом той же TOYOTA.
    Я представляю, как были бы удивлены менеджеры, которые управляют «бережливым» производством, когда бы им сказали, что за из всех принципов контроля за процессами и качеством мы за 4 года научились использовать только один.
    • 0
      Да ладно. Вы же читали статью. Не надо напрямую транслировать то, что используют на заводах на разработку софта.
      • –1
        Вы понятия не имеете, какие остальные 13 принципов, поэтому решили, что они не масштабируются на другие отрасли. На самом деле, по-моему 7-летнему опыту ПМства в ИТ, отрасль по подходу к управлению произведственным процессом находится если не в жопе, то где-то очень рядом.
        В то время как экспертиза в этом домене в других отраслях уже давно впереди.
        • +2
          Я ни на секунду не сомневаюсь в вашей гениальности как ПМа. Но чтобы перевести нашу увлекательную дискуссию в конструктивное русло, хотелось бы услышать, как вы в своей работе применяете все 14 замечательных принципов пр пр тойоты. Заранее извиняюсь, что спросил.
          • –1
            Сколько сарказма в трех строчках. Это такой завуалированный уход от скользкой темы с канбан? Давайте я Вам поведаю о моей ситуации, а Вы в ответ расскажите о Вашем отношении к TPDS и как Вы видите развитие управления производственными процессами в ИТ и какую роль вы отводите вашему инструменту в этой эволюции.
            К сожалению, ПМ не главное лицо в функционально-ориентированной организации, поэтому я не могу самостоятельно определять политики даже внутри очередного проекта (или направления). Еще более прискорбно, что высший менеджмент не понимает всей ценности управления по методологиям scrum, agile, а тем более Lean (что, имхо, привело к уходу 60% квалифицированного персонала за последний год). Если бы соблюдались концепции TPDS из правил подсистемы работы с людьми (что в свое время я пытался наладить) этого не произошло бы.
            В свою очередь хочу сказать, что в какой-то степени мне и тем, кому не было пофиг, удалось ввести в производственный процесс инструменты, которые попадают под описание подсистемы «инструменты и технлогия», но опять-таки, при попустительстве руководящих лиц им не был присвоен статус обязательных.
            Итого: ИМХО — управление производственным процессом в ИТ больше hype и marketing-driven, чем какая-то глобальная научная задача. Местами есть светлые пятна, как-то же самый scrum или xp, но в целом не хватает системного подхода. А что самое интересное — можно реализовать ПО для ведения и контроля за ходом ИТ проектов, переняв методы из тех отраслей, где это уже обкатано и доказало свою эффективность.
            Надеюсь, я увижу в скором будущем продукт, который будет не реализовывать еще один таск-трекер, а предлагать более умный подход к упр. производством в ИТ, что поможет снижать риски и повысит гибкость управления.
            Извиняюсь за много букв и сумбурность изложения.
            • +1
              В виду того, что вы ничего не ответили на мой вопрос, я вынужден его повторить. Как вы в своей работе применяете 14 практик ТПДС. Я не знаю, как спросить конкретнее. Мне кажется, что вопрос очень конкретен.
              • –2
                В виду того, что вы похоже не потрудились понять, что я написал выше, я, честно говоря не понимаю, каким вам языком объяснить, как я их применяю (или хотел бы применять).
                Как минимум упомянуто две подсистемы (из трех), которые частично были применены в постановке производственного процесса.
                Хоть и объяснение было довольно общим, но человеку, который знаком с основами оно дает представление о том, что базовые принципы управления пр-вом кросс-индустриальны.
                Похоже Вам выгоднее форма дискуссии, чем «конструктивное» русло, которым вы прикрылись в посте ранее. Увы, ничем тогда не могу помочь.
                • +1
                  Спасибо, примерно таких общих ответов я и ожидал. В конкретные примеры вы не желает углубляться, из чего можно сделать два вывода. Либо вам лень, но тогда к чему длинный пост выше? Либо их нет. Этот вывод для меня пока более вероятен, если вы все же не сочтете возможным его опровергнуть.
                  • 0
                    Какие вам «конкретные примеры»нужны? Что мы создавали систему постоянного повышения квалификации или что реюзали компоненты, для повышения стандартизации и снижения вариабельности? Такими примерами можно пару скроллов исписать и к каждому можно еще анализ приложить что на что влияет, как связано и как формализовать использование.
                    Поэтому были сделаны обобщения на уровне подсистем.
                    Что я хотел от Вас услышать, что вы не еще одна жира, редмайн или очередное поделие Джоела Спольски. Что вы понимаете, что творится не только внутри software production, но и как оно происходит в других отраслях и готовы создавать уникальный и целостный продукт для индустрии. Похоже я этого не дождусь. Жаль, что компетенции вашей компании ограничиваются только 1/14 от того, что наука управления производством уже достигла (но для IT, как я уже говорил, этого, увы, хватает).
                    • 0
                      Ваш вызов меня заинтриговал. Перед тем, как ответить, я хочу задать один вопрос: Как вы измеряете продуктивность программистов?
                      • 0
                        В попугаях, как это принято в agile/scrum.
                        Если вы о механизме, то в рамках текущей компании — никак, ибо не дозволено руководством. А в своей компании я бы использовал стат.методы и 6Sigma, например.
                        Может есть что-то еще, но я пока самообразовался только до нее.
                        • +1
                          Черт, вы можете ответить конкретно хоть на один вопрос? Как бы вы хотели оценивать продуктивность программиста?
                          • 0
                            Куда еще конкретнее-то? Попугаи в agile = стори поинты — других вроде не юзают.

                            П.С. Ответственность за коммуникацию несет коммуникант (теория коммуникации).
                            • +1
                              Хорошо, я переформулирую вопрос. Вот есть у вас в команде 10 программистов. Как вы оцениваете, кто делает больше работы и насколько больше? Какая методика оценки продуктивности?
                              • +2
                                Я извиняюсь, что вмешиваюсь в ваш душевный разговор. Но хотел бы высказать по этому вопросу свое мнение.

                                Оценивать продуктивность программиста — это бред. И правильно делает руководство не разрешая это делать. Ни какая статистика не покажет важность наличия работы того или иного программиста.

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

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

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

                                Если же человек более интересуется не программной стороной вопроса, а коммуникацией с заказчиками и это у него получаются и все ему мило улыбаются и нет конфликтов с коллегами, т.к. он умело переводит язык заказчика на языка программиста — то подумайте о его роли как постановщика задач, аналитика предметной области.

                                Поэтому как видим оценка идет не по производительности, а по наличию особых качеств работы того или иного работника. И даже если он делает что-то медленнее, это еще не значит что это хуже, это может быть просто надежнее. И если человек объявляет вам сроки, как вам кажется завышенные в 3 раза, а другой готов это сделать в 4 раза быстрее — насторожится надо скорее там где, человек торопиться.
                                • 0
                                  Черт, вы испортили всю малину. Сейчас я уже вряд ли получу интересный ответ и никаких лулзов мы не словим :(
                                  • 0
                                    1. "… конструктивное русло"
                                    2. «Я не знаю, как спросить конкретнее.»
                                    3. «Черт, вы можете ответить конкретно хоть на один вопрос?»
                                    4. «никаких лулзов мы не словим»
                                    толстячка не покормили?
                                    Зато могу припомнить, сколько лулзов словили мы, когда в конце 2010го года сотрудники вернулись с конференции и рассказали, что спикер от вашей конторы сказал, что вы не используете свой же продукт для разработки.
                                    Похоже в ДНК вашей конторы уже заложено, что вы будете просто «кодить» чьи-то готовые модели и следовать очередному тренду моды, нежели стараться понять суть вещей и улучшить их.
                                    • 0
                                      >сотрудники вернулись с конференции и рассказали, что спикер от вашей конторы сказал, что вы не используете свой же продукт для разработки.

                                      Я не знаю, с каких слов вы услышали этот бред. Мы использовали наш продукт с 2004 года и используем до сих пор. Конечно, не весь его функционал, а процентов наверное 50 сейчас.

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

                                      Я вам желаю удачи в поисках по настоящему матричной организации, руководство которой захочет внедрять пока-йока по настоящему. Бай бай!
    • 0
      Вы себе количество персонала ТОЙОТА представляете?
      • 0
        вы глубину своей мысли раскройте, а то никак не могу понять взаимосвязь кол-ва персонала в компании и подходом к управлению производством. Случай «сам себе начальник» не рассматриваю.
    • 0
      The tool used to operate the [Tayota Production] system is Kanban © Taichi Ohno
      Я так понимаю, вы прочли «Дао Toyota. 14 принципов менеджмента ведущей компании мира» Джеффри Лайкера, но слабо представляете как методологию Канбан адаптировали для производства ПО. Впервые о ней заговорил David Anderson в 2004 году, он потом в 2010 году книгу написал:
      www.amazon.com/Kanban-Successful-Evolutionary-Technology-Business/dp/0984521402
      Обратите еще внимание на то, что под Канбан подразумевает ведущие европейский консультант Henrik Kniberg “Kanban vs Scrum”
      www.crisp.se/henrik.kniberg/Kanban-vs-Scrum.pdf
      Успех любой методологии можно доказать только в комплексе реальных дел и обстоятельств, поэтому я представляю, как были бы удивленные менеджеры, которые сделали World of Tanks, когда им бы сказали что они многое упускают :)
      TargetProcess — инструмент с фокусом на компании основной вид деятельности которых — производство ПО. Возможно вы имеете ввиду какое-то другое производство, в котором АйТи отдел это всего лишь маленькая часть другого процесса.
      > К сожалению, ПМ не главное лицо в функционально-ориентированной организации, поэтому я не могу самостоятельно определять политики даже внутри очередного проекта (или направления). Еще более прискорбно, что высший менеджмент не понимает всей ценности управления по методологиям scrum, agile, а тем более Lean (что, имхо, привело к уходу 60% квалифицированного персонала за последний год).
      Мне кажется, вам стоит поменять работу ибо в том же Scrum, Product Owner – это ключевая фигура в организации.
      • 0
        Я прочел не только Дао Тойоты, но еще и основополагающую литературу по тем принципам, которые сейчас модно называть Lean. Уверен, что вам известно, о ком/чем я говорю.
        За сцылу спасибо, почитаю Андерсена.
        Успех любой методологии познается в сравнении с другими методологиями, а не «реальными делами».
        И уж если говороть о методологиях, то нет «методологии Канбан», есть «инструмент канбан», наряду с такими инструментами, как — «пока-ёке», «хансей-кайзен», «джидока» и ряда других. Только проблема ИТ в том, что мы схватились только за «канбан» и пытаемся обернуть 1 процесс производственного цикла в него, упуская все остальные. А это идет в разрез в принципами Lean, которые направлены на создание «value» на протяжении всего жизненного цикла продукта.
        Благодарю за совет с работой — это в процессе, но, к сожалению, организаций с матричной структурой, а тем более проектной — очень и очень мало.
        П.С. Я прочитал пост вашего начальника. Думаю, что вы должны объяснить ему, что Continuous Delivery пагубно сказывается на качестве кода, что, судя по комментам ИТТ у вас и так страдает.
  • 0
    Очень понравилась статья. Сразу возникло несколько вопросов :)

    1. Сколько из общего количества человек разработчиков, ПМ? Чтобы понять масштаб бедствия.
    2. Как вы справляетесь с ситуациями, когда функционал вроде как сделан, но не до конца? Заводите отдельный тикет, или добиваете этот и как вообще поступаете? Как стимулируете разработчиков писать качественный код?
    3. Каково среднее время работы разработчиков? Практика показывает, что слаженность команды и скорость разработки очень трудно сохранять при наличии хоть какой-либо текучки.
    • +1
      >Сколько из общего количества человек разработчиков, ПМ?

      40 человек в компании. 14 разработчиков. 0 PM

      > Как вы справляетесь с ситуациями, когда функционал вроде как сделан, но не до конца? Заводите отдельный тикет, или добиваете этот и как вообще поступаете?

      Доделываем до конца. Иногда заводятся баги на юзер стори. Иногда не заводятся.

      >Как стимулируете разработчиков писать качественный код?

      Хм. А зачем им писать некачественный?

      > Каково среднее время работы разработчиков?

      Среднее время не считали.
      Текучесть разработчиков такая

      2007 — 0
      2008 — 0
      2009 — 1
      2010 — 3 (2 мы сами попросили уйти)
      2011 — 2 (1 мы сами попросили уйти)
      2012 — 0

  • 0
    Спасибо за статью и классный продукт!
    • 0
      То ли еще будет. Следите за анонсом ТП3
  • 0
    40 виртуальных серверов для тестов — это что-то облачное или купили несколько серверов и порезали их на виртуалки?
    • 0
      Сервера внутри. Купили и порезали.
  • 0
    «Ежедневное собрание в 11 утра, занимает около 15 минут»

    Меня вот интересует какой прок от таких собраний, и что именно можно обсудить за 15 минут?
    • 0
      Стандартный stand up — услышать, что делают другие, рассказать, что делаешь сам. Так же услышать от саппорта, какие у них проблемы. Если надо что-то обсудить — это обсуждается после митинга.
      • +1
        Т.е. 40 человек 15 минут обсуждают предыдущий день и планы на будущее? Получается 10 человекочасов без учета того, что их всех прервали в начале рабочего дня. Как-то сложно представить, что это полезно даже половине присутствующих.
        • 0
          Ну, во-первых, не 40, а 15 — маркетинг раз в месяц рассказывает о новых клиентах, у ui team свой митинг. Насчет «прервали» не могу сказать — никогда не было в тягость сходить на митинг. А вот про полезность — это спорно, да. Мне, например, полезно — знать, что делается в команде целиком, подсказать, если знаю решение проблемы, попросить помощи, если нуждаюсь. Для других — это надо их спрашивать.
          • 0
            Ну, хорошо — вот у вас 6 групп, почему бы на митинге не встречаться 6 руководителям групп и решать вопросы взаимодействия, после чего в каждой группе не выслушать от руководителя план на неделю и того, что хотят другие группы. Там же поделить задачи на каждого человека и услышать от него обратную связь. Но именно не каждый день — что бесполезно, а понедельник. Это как генералы посовещались и довели до сведения личному составу. Это более эффективно.
            • 0
              :) описка

              > Но именно не каждый день — что бесполезно, а понедельник

              Но именно не каждый день — что бесполезно, а понедельно
            • 0
              У нас нет руководителей групп.
              • 0
                И это скорее упущение
                • 0
                  Как можно руководить группой в 1-2 человека?
                  • 0
                    … Если сам являешься членом группы.
                  • 0
                    > обычно состоит из дизайнера, 1-3 программистов, Product Owner, 1-2 тестировщиков и писателя

                    Насчитал как минимум 6. Если группа 1-2 то что-то не в порядке с разделением на группы
                  • 0
                    Впрочем можно говорить и о неформальном лидере группы, где 2-3 человека, кроме лидера. Это скорее даже лучше в социальном плане.
                    • 0
                      Правда, такому лидеру сложнее управлять работой команды — программисты люди упрямые. Но с другой стороны, лидер на то и лидер, чтобы не быть самодуром и выслушивать остальных членов команды.
                    • 0
                      «Неформальный лидер», который раз в неделю ходит с другими «неформальными лидерами» на закрытое совещание. :)

                      Писатель у нас один, продукт оунер тоже. Тестировщики и дизайнеры компетентны и достаточно автономны. «Группа» тут скорее не как единица ответственности, а просто те люди, которые будут делать фичу. Но работа по фичам ведь никогда не идет — работа идет по юзерстори, а там больше двух человек вряд ли бывает.
                      • 0
                        > «Неформальный лидер», который раз в неделю ходит с другими «неформальными лидерами»

                        В этом случае, они конечно встречаются по мере необходимости, но действительно только они — так как это не достаточно формально становится их областью ответственности
                      • 0
                        Да, и к тому же в таких условиях говорить о группах — это скорее фикция. Тут скорее речь идет о одной группе, где каждый разработчик ответственен за свой участок кода. И это вполне нормально.
      • 0
        Так почему не достаточно обсудить то что нужно (если нужно) в отдельных командах, и предметно? Надо понимать — что это конечно никому особо не нужно, но это есть своеобразная форма контроля навязанная руководством. Типа я такой-то каждый день должен придумать, что пообещать сделать за сегодня. Но как правило, это фразы «продолжаю работу на модулем таким-то», и уж естественно, что никому не интересно кроме тестировщиков, что я исправил 10 ошибок таких-то. Поэтому если и делать подобные собрания то не чаще 1 раза в неделю, но зато по времени около часа.

        Что же касается самоконтроля, то тут как раз парное программирование более эффективно, но как видим в компании от этого отказались, т.к. это раздражает людей — постоянно быть под «присмотром» коллег. Тоже не факт, что «присмотр» стимулирует — скорее это важно только для молодых программистов в паре с опытным.
        • 0
          Наше руководство присутствует на отдых силы 70% всех митингов, так что про контроль говорить не приходится. Про придумать — достаточно часто бывает, что на митинге говорят «я не знаю, что сегодня делать» — какой индикатор, что работа закончена.
          Час на обсуждение того, чтобы было сделано, имхо, слишком много — вот здесь как раз и можно заскучать.
          • 0
            > Наше руководство присутствует на отдых силы 70% всех митингов

            Эту фразу я не понял
            • 0
              Тьфу. Т9.
              * на 70% всех митингов.
  • –1
    Ах как все знакомо! Читал и умилялся.

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

Самое читаемое Разное