Комментарии 147
> наш
> мы
> нас
Простите, а кто вы?
> мы
> нас
Простите, а кто вы?
Было интересно.
отлично, спасибо
Сколько незнакомых терминов. Автору спасибо за ссылки в тексте — пошел читать.
Используете свой продукт для разработки его же, надо же =)
Используем, конечно. Но в силу специфики процессов — далеко не полностью. На последней нашей внутренней конференции была замечательная презентация от нашего Product Specialist, как наши заказчики видят наш продукт. Достаточно интересно.
это ведь хорошо :)
использую свой продукт «сидишь в шкуре пользователя».
использую свой продукт «сидишь в шкуре пользователя».
Вы бы не могли подробнее рассказать почему вы вернулись к одному бранчу? Чем бранчи по фичам мешают continuous delivery?
На сегодня ситуация получается такая. Есть trunk, который пытаемся держать зеленым (получается где-то процентов на 70), есть одна большая ветка с новой функциональностью, в которой работают одновременно 5+2+1+1 человек (каждая команда над своей функциональностью, но очень часто пересекаемся), все остальное делается в trunk.
Это решается просто, есть ветка develop, и ветки staging и production.
На сервере CI тестируются все три, причем для каждой своё четко прописанное окружение (первое время одинаковое, потом на staging — как в будущем production).
На сервере CI тестируются все три, причем для каждой своё четко прописанное окружение (первое время одинаковое, потом на staging — как в будущем production).
Меня порой пугает, насколько современные разработчики с трудом управляются с ветками :(
> Это решается просто, есть ветка develop, и ветки staging и production
Где об этом можно почитать подробнее? Какая ветка за что отвечает, как происходит расслоение настроек окружения, etc?
Где об этом можно почитать подробнее? Какая ветка за что отвечает, как происходит расслоение настроек окружения, etc?
Частично описано тут, — nvie.com/posts/a-successful-git-branching-model/
К слову, на хабре есть перевод: habrahabr.ru/post/106912/
Вы описали как оно у вас устроено, но не описали почему. Хотелось бы услышать причины, по которым вы отказались от бранчей по фичам и пришли к той схеме, которую вы описали. Спасибо.
Интересно, в каких случаях недовольны NHibernate'ом?
Больше всего из-за производительности. Старая модель, посторенная на хибернейтовских классах, в полный рост страдает из-за N+1 проблем.
У вас Rich Domain Model, поэтому Вы не можете для каждого запроса назначать стратегию fetch'инга?
Или fetch используете, но это не помогает?
Или fetch используете, но это не помогает?
Да, rich model, плюс достаточно древний код, который сейчас никто переписывать уже не возьмется.
В таком случае, можно задать размер batch-size и при обращении к ленивым коллекциям сущности будут подгружатся страницами.
CQRS не отменяет наличие ORM и проблему N+1.
CQRS не отменяет наличие ORM и проблему N+1.
«Старая модель, посторенная на хибернейтовских классах»
А что значит на «хибернейтовских классах»?
А что значит на «хибернейтовских классах»?
Классы модели замаплены хибернейтом, потом модель «обогощена».
А, понятно. Ну еще Mark Seemann обсуждал это в комментах к своей превосходной статье At the Boundaries, Applications are Not Object-Oriented.
Ведь, Rich Domain, следующая канонам DDD — это строго объектно-ориентированная вещь. А «Entity», «сущности» в ORM — это, по сути, структуры, DTO, для передачи данных и трэкинга изменений через прокси-классы.
Ведь, Rich Domain, следующая канонам DDD — это строго объектно-ориентированная вещь. А «Entity», «сущности» в ORM — это, по сути, структуры, DTO, для передачи данных и трэкинга изменений через прокси-классы.
НЛО прилетело и опубликовало эту надпись здесь
Интересно, что вы используете .NET, C# и даже NHibernate на Application-уровне.
Переход с ASP.NET WebForms для web-frontend'а вполне понятен. Но странно, что вы включили новое звено в свой технологический стек — Python. Есть вопрос — почему не ASP.NET MVC или Node.js? Ведь вы уже пишете на этих языках.
Переход с ASP.NET WebForms для web-frontend'а вполне понятен. Но странно, что вы включили новое звено в свой технологический стек — Python. Есть вопрос — почему не ASP.NET MVC или Node.js? Ведь вы уже пишете на этих языках.
Думаю, пришла мини-команда извне и привила любовь к Python :)
Вообще, динамические языки доказали своё право на место в экосистеме.
Когда-то я был специалистом по C#, но последние годы я интенсивно пишу на JavaScript, Ruby, Perl, PHP и последнее время даже Python.
Вообще, динамические языки доказали своё право на место в экосистеме.
Когда-то я был специалистом по C#, но последние годы я интенсивно пишу на JavaScript, Ruby, Perl, PHP и последнее время даже Python.
Ничего не имею против динамических языков в целом, а тем более — против Ruby и Python. Просто уже используется один стек (в любом случае). Интегрировать тот же ASP.NET MVC куда проще с бэк-эндом, написанным на .NET. Или Node.js, чтобы фронтэнд-часть сервера и клиент вообще общались на одном языке.
MVC — это вообще не туда. Node.js — тоже. Нам нужно было сделать DSL. Для этого лучше подходит скриптовый язык. На .NET выбор небогат. F# можно было бы еще. Но исторически сложился Python.
Понял. Просто почему-то показалось так из схемы, где вы показываете развертку по технологиям и по годам, что вы его для фронтэнда используете.
Если DSL — вопрос снимается. F#, возможно, и лучше для DSL (и то, it depends), но вот это уж точно целая отдельная парадигма в существующий стек.
Мой вопрос был исключительно в контексте фронтэнда. На схеме вы указали REST, а он же не является конкретной технологией, как все остальное из перечисленного. Поэтому сразу и недопонял. У вас же написано JavaScript-frontend, то есть, в сторону JS вы все-таки двинулись. Кстати, интересно узнать, в каком виде там JS?
Если DSL — вопрос снимается. F#, возможно, и лучше для DSL (и то, it depends), но вот это уж точно целая отдельная парадигма в существующий стек.
Мой вопрос был исключительно в контексте фронтэнда. На схеме вы указали REST, а он же не является конкретной технологией, как все остальное из перечисленного. Поэтому сразу и недопонял. У вас же написано JavaScript-frontend, то есть, в сторону JS вы все-таки двинулись. Кстати, интересно узнать, в каком виде там JS?
Python появился в виде IDP одного из тестировщиков — на нем начали писаться тесты для REST api. Потом оказалось, что питон отлично подходит в качестве DSL. Python мы используем в виде IronPython. Вся логика продолжает крутиться на .net.
Тогда ты выбрали не тот язык )
Вам нужен Ruby. Факт, что он лучше подходит в качестве EDSL.
Вам нужен Ruby. Факт, что он лучше подходит в качестве EDSL.
IronRuby как-то не развивается, а вот IronPython очень даже.
И вопрос. Почему Руби лучше подходит?
И вопрос. Почему Руби лучше подходит?
Сила Ruby в данном случае в блоках и в метапрограммировании в целом.
Вот так выглядит DSL Chef:
А вот так DSL RSpec:
Частично объясняет devopsanywhere.blogspot.com/2011/09/how-ruby-is-beating-python-in-battle.html
Вот так выглядит 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
На мой взгляд метапрограммирование — это штука, которую с большой опаской нужно пускать в проект и особенно в проект, где задействовано много людей с разной степенью компетентности.
Лично меня куда больше устраивают парсеры в явном виде. И чем топорнее то, что они кушают в плане структуры, тем лучше.
Лично меня куда больше устраивают парсеры в явном виде. И чем топорнее то, что они кушают в плане структуры, тем лучше.
Программируете на lisp/scheme?
Да, случалось, это хороший язык для определенных задач, но речь идет именно о DSL.
Поясню свою мысль:
DSL необходимо отдельно спроектировать и отдельно продокументировать, то есть, в теории, человек должен его использовать не вникая в код с определения грамматики, куда вынесена сложность кусков использующих DSL, как бы не очень хорошо изучать ЯП по исходному коду компилятора :)
Версии грамматики тоже нужно отслеживать, и в принципе мы получаем кучу штук, которые требуют дополнительного контроля хотя где-то все стало несколько компактнее.
Использование парсера какого-то стандартного формата с хуками как правило покрывает 90% тех случаев, когда применяется DSL и прочий подобный препроцесс, и этот вариант скорее всего будет лучше понятен разработчику, который будет ковыряться в вашем коде и его поддерживать.
Поясню свою мысль:
DSL необходимо отдельно спроектировать и отдельно продокументировать, то есть, в теории, человек должен его использовать не вникая в код с определения грамматики, куда вынесена сложность кусков использующих DSL, как бы не очень хорошо изучать ЯП по исходному коду компилятора :)
Версии грамматики тоже нужно отслеживать, и в принципе мы получаем кучу штук, которые требуют дополнительного контроля хотя где-то все стало несколько компактнее.
Использование парсера какого-то стандартного формата с хуками как правило покрывает 90% тех случаев, когда применяется DSL и прочий подобный препроцесс, и этот вариант скорее всего будет лучше понятен разработчику, который будет ковыряться в вашем коде и его поддерживать.
Очень круто.
А можно пару мыслей, что у вас будет в 2013 году? К чем идёте?
Например, с возвратом к 1 бренчу, мы поняли, что git нам особо и не нужен, и можно было оставаться на svn?
А можно пару мыслей, что у вас будет в 2013 году? К чем идёте?
Например, с возвратом к 1 бренчу, мы поняли, что git нам особо и не нужен, и можно было оставаться на svn?
Ох. это сложный вопрос. Вернее, простой для любых знающих обе системы — выбор очевиден — git. Но обьяснить это ярому svn-man — сложно.
Возможность разработчику работать со своей историей коммитов, перелопачивать ее, локальные репозитории, гораздо более интерсный merge, и т.д. — это шикарно.
Возможность разработчику работать со своей историей коммитов, перелопачивать ее, локальные репозитории, гораздо более интерсный merge, и т.д. — это шикарно.
а что касается других моментов?
про технологии, методологии, подходы? к чему движтесь?
про технологии, методологии, подходы? к чему движтесь?
Я недавно сменил компанию. Тут используют SVN. Первый бэтл за SVN закончился ничем, причин много. Предлагают использовать git локально (или git-svn, но это вообще недопонимание).
Тут еще просто куча проблем, начиная с того, что utf-8 еще не общепринят (пришлось патчить сегодня Redmine из-за этого, потом переделаю...).
Тут еще просто куча проблем, начиная с того, что utf-8 еще не общепринят (пришлось патчить сегодня Redmine из-за этого, потом переделаю...).
Но уже было прикол:
1) Программист, ответственный за влитие кода тут в production, сегодня отказался производить merge из-за больших временных затрат. Предложил отдать готовые файлы (их никто не будет править, наверное, кроме одного?), пришлось самому это сделать (ручной rebase). Налицо одна из проблем SVN.
1) Программист, ответственный за влитие кода тут в production, сегодня отказался производить merge из-за больших временных затрат. Предложил отдать готовые файлы (их никто не будет править, наверное, кроме одного?), пришлось самому это сделать (ручной rebase). Налицо одна из проблем SVN.
Четыре года назад также плотно работал с CVS и SVN (.masterhost).
Факт в том, что rebase и merge чересчур ручные. А коммиты нельзя изменить.
А самым показательным был один из советов по rebase, — делай diff -u и patch…
Факт в том, что rebase и merge чересчур ручные. А коммиты нельзя изменить.
А самым показательным был один из советов по rebase, — делай diff -u и patch…
про git vs svn я не хотел спорить. Мне больше интересен сам процесс работы.
Посмотрите в сторону Mercurial:
1. Проще установить Windows, если у вас люди работают на нем.
2. Проще для понимания чем GIT
Ну и как бонус:
3. Хранение в репозитории истории ветки.
Хотя для вас, как мне кажется 2 первых пункта более важные.
1. Проще установить Windows, если у вас люди работают на нем.
2. Проще для понимания чем GIT
Ну и как бонус:
3. Хранение в репозитории истории ветки.
Хотя для вас, как мне кажется 2 первых пункта более важные.
Одинаковы они для понимания, просто с одного на другой непривычно переходить :)
Порог вхождения в Mercurial ниже, learning curve у него менее крутая, ну и конечно Principle of least surprise он удовлетворяет намного лучше, чем Git.
Спасибо, такой вариант ответа я уже слышал :) Может у вас есть пруфлинк на кривые обучения hg vs git?
У меня исключительно личный опыт и опыт коллег. Ну и потом, какой вы хотите пруфлинк? Пруф в плане доказательство? Вряд ли какой-то НИИ ставил эксперименты по всем правилам с контрольными группами и пр. на эту тему. Но если вы погуглите на тему git mercurial learning curve, вы увидите, что достаточно много людей думают так же, как я.
Добавлю ремарку о свём опыте изучения mercurial и git — первый изучить проще. Мнение субъективное, но не одинокое, от многих слышал такое же, а вот обратного (git изучить проще) не слышал.
Изучал как hg, так и git.
Hg проще, т.к. есть такое понятие, как центральный репозитарий.
+ На столько меньше проблем с кросплотформенностью у hg, т.к. он на Python
Hg проще, т.к. есть такое понятие, как центральный репозитарий.
+ На столько меньше проблем с кросплотформенностью у hg, т.к. он на Python
Эти плюсы — это плюсы даже не конкретно git-а, а децентрализованных репозиториев, просто самыми яркими представителями класса являются git и Mercurial (hg).
Тьфу-тьфу-тьфу, только не svn.
После git к svn? Я вас умоляю.
Вот что мне хотелось бы достичь за пару лет
1. Убрать роль Product Owner. Хочется чтобы команда сама понимала, в какую сторону двигать продукт, какие фичи делать и как они должны работать. Сейчас мы в этом направлении предпринимаем первые робкие шаги.
2. Выпускать новые фичи как только готовы. То есть без всяких задержек на стадии деливери. Сейчас задержки бывают около недели а то и двух, потому что выпускаются фичи батчами.
3. Полностью отказаться от ASP.NET, ExtJS. 100% UI на яваскрипте. Надеюсь это будет уже через год.
4. Добиться, чтобы приложение без труда работало с несколькими тысячами одновременно подключенных юзеров.
5. Научиться в конце концов дробить юзер стори
1. Убрать роль Product Owner. Хочется чтобы команда сама понимала, в какую сторону двигать продукт, какие фичи делать и как они должны работать. Сейчас мы в этом направлении предпринимаем первые робкие шаги.
2. Выпускать новые фичи как только готовы. То есть без всяких задержек на стадии деливери. Сейчас задержки бывают около недели а то и двух, потому что выпускаются фичи батчами.
3. Полностью отказаться от ASP.NET, ExtJS. 100% UI на яваскрипте. Надеюсь это будет уже через год.
4. Добиться, чтобы приложение без труда работало с несколькими тысячами одновременно подключенных юзеров.
5. Научиться в конце концов дробить юзер стори
спасибо.
Миша, расскажи, пожалуйста, как ты представляешь первый пункт. Имхо, Product Owner — это очень большой объем работы, именно он должен знать, куда развивается отрасль, какие фичи нужны, а какие нет…
Мне кажется, что задача продукт оунера — просто задавать стратегическое направление. Как максимум — определять эпики высокого порядка в виде проблем в виде «у нас очень сложно добавлять энтити в систему, надо чтобы это было просто и быстро» или «у нас нет возможности визуализировать прогресс для нескольких команд». Каждый эпик решает и делает мини-команда. Для этого, конечно, некоторым членам мини-команды придется поглубже погрузиться в предметную область, изучить что надо сделать, провести собрания и придумать решения. Не обязательно весь мини-тим должен это делать, может быть кто-то один для этого эпика возьмет на себя роль продукт оунера. Но в итоге, думаю, всем будет интереснее работать и результать может быть лучше на выходе.
А почему отказываетесь от ExtJS? Он вроде согласуется с вашей целью «100% UI на яваскрипте».
Спрашиваю не из праздного интереса. В нашей команде тоже использовали ExtJS длительное время и теперь от него уходим по разным причинам. Хочется сравнить опыт.
Спрашиваю не из праздного интереса. В нашей команде тоже использовали ExtJS длительное время и теперь от него уходим по разным причинам. Хочется сравнить опыт.
а можете огласить тут причины? Другим, тоже интересно их послушать :)
ExtJS придуман, чтобы транслировать экспериенс десктопного приложения в веб. Это пагубный и порочный путь, которым мы случайно начали идти. Его очень тяжело кастомизировать под наши нужды и в итоге оказалось, что мы используем практически на уровне ядра. Все наши компоненты кастомные. Все дефолтные темы ExtJS ужасны чуть более, чем полностью. Так что я не могу порекомендовать его использовать никому.
Не боитесь за пользователей у которых что-то будет меняться чуть ли не каждый день? Понятно, что вашими пользователями являются разработчики, но все же непрерывное изменение продукта, причем не всегда в пользу улучшения для данного конкретного пользователя, будет все большим числом пользователей восприниматься как что-то негативное? Ведь, если продукт достаточно mature, то легко можно хоть полгода не обновляться инсталяцию, все будут знать как она работает без каких-либо неожиданностей. Те же частые обновления Firefox уже воспринимаются достаточно отрицательно, а его еще нужно установить, в отличие от saas-приложения.
Если переформулировать вопрос, то о стабильных, LTS-версиях вашего сервиса думали?
Если переформулировать вопрос, то о стабильных, LTS-версиях вашего сервиса думали?
Не боюсь. Подавляющее большинство изменений делаются на основе пожеланий наших клиентов. Мажорные релизы, как ТП3, конечно происходят нечасто. Но минорные могут происходить хоть ежедневно, от этого всем только хорошо, главное чтобы даунтайма не было. Мы не собираемся замораживать никакие ветки, но решать подобные проблемы с помощью фича тоглинга и кастомизации. Firefox катится в говно. Обновления фейсбука, которые происходят часто, далеко не все вообще замечают. Кто-нибудь заметил непрерывную загрузку в нотификациях (сегодня появилась)?
Вот тоже хотел спросит про git, каково ощущение от использования его в corporate environment?
Нет проблем с тем что репозиторий целиком расползается по всем разработчикам? :)
Нет проблем с тем что репозиторий целиком расползается по всем разработчикам? :)
У нас не совсем corporate, даже совсем не corporate. Но локальные репозитории — это действительно очень удобно, хотя мы не используем всю мощь гита (на мой взгляд). Синхронизация все равно происходит через центральный репозиторий, с которого собираются билды CI, мы пробовали синхронизироваться друг с другом, но это оказалось ненужным.
Большое спасибо за статью! Всегда интересно перенять чужой опыт :)
По поводу эстимейтов — когда мы перешли на Канбан, задачи оценивать перестали. Просто держали очередь отсортированной по приоритету.
Но Project Owner'у в какой-то момент эстимейтов стало не хватать. Ведь сложно задавать задаче приоритет, не зная, сколько времени займёт её реализация. Даже подумывали возвратиться на Скрам с его planning-митингами.
Но в итоге придумали оценивать задачу грубо:
1. Очень маленькая (минуты);
2. Часы (от получаса до двух дней);
3. Дни (от пары дней до двух недель);
4. Недели (такие задачи обычно нужно разбивать на меньшие подзадачи).
Оказалось, что такая грубая оценка уже является достаточным критерием для Project Owner'а при краткосрочном планировании.
Более того, такие грубые оценки, как ни странно, оказываются более точными :) — в том плане, что разработчик намного реже ошибается и не выходит за пределы естимейта.
По поводу эстимейтов — когда мы перешли на Канбан, задачи оценивать перестали. Просто держали очередь отсортированной по приоритету.
Но Project Owner'у в какой-то момент эстимейтов стало не хватать. Ведь сложно задавать задаче приоритет, не зная, сколько времени займёт её реализация. Даже подумывали возвратиться на Скрам с его planning-митингами.
Но в итоге придумали оценивать задачу грубо:
1. Очень маленькая (минуты);
2. Часы (от получаса до двух дней);
3. Дни (от пары дней до двух недель);
4. Недели (такие задачи обычно нужно разбивать на меньшие подзадачи).
Оказалось, что такая грубая оценка уже является достаточным критерием для Project Owner'а при краткосрочном планировании.
Более того, такие грубые оценки, как ни странно, оказываются более точными :) — в том плане, что разработчик намного реже ошибается и не выходит за пределы естимейта.
Можете посоветовать хороший программный Kanban? Может что-то есть на примете.
Олсьют юнит тестов за сколько проходит? Мы приближаемся к отметке в 3000 и время прохождения тестов радует не так сильно, как раньше.
Насколько просто на практике происходит миграция с Selenium 1.0 на WebDriver? До миграции гоняли тесты в браузере или использовали RC?
Насколько просто на практике происходит миграция с Selenium 1.0 на WebDriver? До миграции гоняли тесты в браузере или использовали RC?
Юнит тесты запускаются параллельно в 8 пачках, по 6 минут на пачку где-то.
Миграция проходила достаточно гладко, сейчас новые тесты пишутся на WebDriver, старые нестаблильные тоже переводятся на webDriver. У нас хорошо была сделана абстракция от тестирующего фреймворка, поэтому проблем при миграции возникает куда меньше, чем ожидалось.
Не совсем понимаю разницу между RC и «в браузере» — у нас запускался selenium server и тест гонялись через него.
Миграция проходила достаточно гладко, сейчас новые тесты пишутся на WebDriver, старые нестаблильные тоже переводятся на webDriver. У нас хорошо была сделана абстракция от тестирующего фреймворка, поэтому проблем при миграции возникает куда меньше, чем ожидалось.
Не совсем понимаю разницу между RC и «в браузере» — у нас запускался selenium server и тест гонялись через него.
Как живо! Класс! Особенно графики супер!
Ребята, очень крутой пост, давно подобного не читал, спасибо.
Куча вопросов :)
Почему уходите от jQuery? Не смотрели в сторону Entity Framework? Сравнивали Git и Mercurial, Jenkins и Team City? Что используете для unit тестов?
Почему уходите от jQuery? Не смотрели в сторону Entity Framework? Сравнивали Git и Mercurial, Jenkins и Team City? Что используете для unit тестов?
В сторону Entity Framework не смотрели, потому что старая модель слишком уж «богатая», переписывать ее нет смысла — новый UI использует наш маленький «ORM», в будущем, надеюсь, получится выкристализовать бизнес правила и уйти от хибернейта полностью — куда, пока не ясно. Jenkins vs TeamCity — выбор был в пользу Jenkins из-за его бесплатности — под дженкинсом сейчас крутятся 35 виртуалок. Для unit тестов — NUnit, NBehave, Rhino.Mocks, Selenium Web Driver, IronPython. Еще T4 — очень много генеренных тестов (~1000).
На остальные вопросы ответов не знаю. :)
На остальные вопросы ответов не знаю. :)
Вместо NBehave не смотрели SpecFlow там есть поддержка DSL, NUnit -> xUnit, Rhino.Mocks -> Moq.
NBehave немного заточили для NUnit, теперь типичный тест выглядит приблизительно вот так:
nUnit — xUnit, moq — rhino — не вижу смысла менять шило на мыло.
[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 — не вижу смысла менять шило на мыло.
Прошу прощения, немного не в тему. А где вы так оформляли графику? Это сделано как-то программно или некий дизайнер вырисовывал на планшете? Очень понравилось оформление.
Клёвые картинки. Но текст очень менеджерский и энерпрайзный. Если бы я решил играть в bullshit-bingo, я бы ещё на первом абзаце выиграл.
Отличный пост, вот только самим TargetProcess пользоваться не советовал бы. Хотя альтернатив таких масштабных не знаю, но даже набор разных аппсов будет лучше. В TP даже багтрекер есть, но всё недоделано (например фильтры в багтрекере) и плохо спроектировано UX.
Чего стоит только аякс подгрузка основного контента после каждой загрузки страницы. Я оставлял фидбек об этом на дев форуме, но судя по игнору это в норме вещей. Всё настолько нефэншуйно что приводит к регрессиям, например ранее можно было работаьт с iPad/iPhone, в новой версии уже нет. Куча велосипедов в интерфейсе — одни вкладки можно открыть в новой табе, другие нет потому что это дивы. Главное — очень медленная работа клиент-сайда.
С другой стороны, много чего реализовано неплохо (доска плюс-минус; поиск), но в многих других нужно делать кучу кликов. Особенно отмечу историю задачи/бага — чтобы узнать кто закрывал/переоткрывал надо каждое изменение раскрывать отдельно.
Короче говоря, за полгода навязанного свыше использования накипело много негатива :(
Чего стоит только аякс подгрузка основного контента после каждой загрузки страницы. Я оставлял фидбек об этом на дев форуме, но судя по игнору это в норме вещей. Всё настолько нефэншуйно что приводит к регрессиям, например ранее можно было работаьт с iPad/iPhone, в новой версии уже нет. Куча велосипедов в интерфейсе — одни вкладки можно открыть в новой табе, другие нет потому что это дивы. Главное — очень медленная работа клиент-сайда.
С другой стороны, много чего реализовано неплохо (доска плюс-минус; поиск), но в многих других нужно делать кучу кликов. Особенно отмечу историю задачи/бага — чтобы узнать кто закрывал/переоткрывал надо каждое изменение раскрывать отдельно.
Короче говоря, за полгода навязанного свыше использования накипело много негатива :(
Это во многом правда, что выражено в предложении "Текущий UI представляет собой достаточно печальный коктейль из ASP.NET Ajax, ExtJS и нашего собственного фреймворка."
И собственно как раз эти проблемы сейчас и решаются "Текущие усилия направлены на унификацию всего этого счастья, так что в самом ближайшем будущем старый UI будет полностью заменен на новый."
Если быть конкретным, то можно будет фильтровать ВСЕ что угодно. Никаких перегрузок страниц не будет. Клиент-сайд будет летать. Велосипеды останутся — но мы стараемся их делать очень классными.
И на самом деле, если смотреть на альтернативные решения типа Rally и VersionOne, то там с UI все гораздо печальнее.
И собственно как раз эти проблемы сейчас и решаются "Текущие усилия направлены на унификацию всего этого счастья, так что в самом ближайшем будущем старый UI будет полностью заменен на новый."
Если быть конкретным, то можно будет фильтровать ВСЕ что угодно. Никаких перегрузок страниц не будет. Клиент-сайд будет летать. Велосипеды останутся — но мы стараемся их делать очень классными.
И на самом деле, если смотреть на альтернативные решения типа Rally и VersionOne, то там с UI все гораздо печальнее.
> и в конце концов переключились на Kanban.
Вот этот момент меня удивляет. Канбан это ОДИН из 14 (!!!) принципов управления производственным процессом той же TOYOTA.
Я представляю, как были бы удивлены менеджеры, которые управляют «бережливым» производством, когда бы им сказали, что за из всех принципов контроля за процессами и качеством мы за 4 года научились использовать только один.
Вот этот момент меня удивляет. Канбан это ОДИН из 14 (!!!) принципов управления производственным процессом той же TOYOTA.
Я представляю, как были бы удивлены менеджеры, которые управляют «бережливым» производством, когда бы им сказали, что за из всех принципов контроля за процессами и качеством мы за 4 года научились использовать только один.
Да ладно. Вы же читали статью. Не надо напрямую транслировать то, что используют на заводах на разработку софта.
Вы понятия не имеете, какие остальные 13 принципов, поэтому решили, что они не масштабируются на другие отрасли. На самом деле, по-моему 7-летнему опыту ПМства в ИТ, отрасль по подходу к управлению произведственным процессом находится если не в жопе, то где-то очень рядом.
В то время как экспертиза в этом домене в других отраслях уже давно впереди.
В то время как экспертиза в этом домене в других отраслях уже давно впереди.
Я ни на секунду не сомневаюсь в вашей гениальности как ПМа. Но чтобы перевести нашу увлекательную дискуссию в конструктивное русло, хотелось бы услышать, как вы в своей работе применяете все 14 замечательных принципов пр пр тойоты. Заранее извиняюсь, что спросил.
Сколько сарказма в трех строчках. Это такой завуалированный уход от скользкой темы с канбан? Давайте я Вам поведаю о моей ситуации, а Вы в ответ расскажите о Вашем отношении к TPDS и как Вы видите развитие управления производственными процессами в ИТ и какую роль вы отводите вашему инструменту в этой эволюции.
К сожалению, ПМ не главное лицо в функционально-ориентированной организации, поэтому я не могу самостоятельно определять политики даже внутри очередного проекта (или направления). Еще более прискорбно, что высший менеджмент не понимает всей ценности управления по методологиям scrum, agile, а тем более Lean (что, имхо, привело к уходу 60% квалифицированного персонала за последний год). Если бы соблюдались концепции TPDS из правил подсистемы работы с людьми (что в свое время я пытался наладить) этого не произошло бы.
В свою очередь хочу сказать, что в какой-то степени мне и тем, кому не было пофиг, удалось ввести в производственный процесс инструменты, которые попадают под описание подсистемы «инструменты и технлогия», но опять-таки, при попустительстве руководящих лиц им не был присвоен статус обязательных.
Итого: ИМХО — управление производственным процессом в ИТ больше hype и marketing-driven, чем какая-то глобальная научная задача. Местами есть светлые пятна, как-то же самый scrum или xp, но в целом не хватает системного подхода. А что самое интересное — можно реализовать ПО для ведения и контроля за ходом ИТ проектов, переняв методы из тех отраслей, где это уже обкатано и доказало свою эффективность.
Надеюсь, я увижу в скором будущем продукт, который будет не реализовывать еще один таск-трекер, а предлагать более умный подход к упр. производством в ИТ, что поможет снижать риски и повысит гибкость управления.
Извиняюсь за много букв и сумбурность изложения.
К сожалению, ПМ не главное лицо в функционально-ориентированной организации, поэтому я не могу самостоятельно определять политики даже внутри очередного проекта (или направления). Еще более прискорбно, что высший менеджмент не понимает всей ценности управления по методологиям scrum, agile, а тем более Lean (что, имхо, привело к уходу 60% квалифицированного персонала за последний год). Если бы соблюдались концепции TPDS из правил подсистемы работы с людьми (что в свое время я пытался наладить) этого не произошло бы.
В свою очередь хочу сказать, что в какой-то степени мне и тем, кому не было пофиг, удалось ввести в производственный процесс инструменты, которые попадают под описание подсистемы «инструменты и технлогия», но опять-таки, при попустительстве руководящих лиц им не был присвоен статус обязательных.
Итого: ИМХО — управление производственным процессом в ИТ больше hype и marketing-driven, чем какая-то глобальная научная задача. Местами есть светлые пятна, как-то же самый scrum или xp, но в целом не хватает системного подхода. А что самое интересное — можно реализовать ПО для ведения и контроля за ходом ИТ проектов, переняв методы из тех отраслей, где это уже обкатано и доказало свою эффективность.
Надеюсь, я увижу в скором будущем продукт, который будет не реализовывать еще один таск-трекер, а предлагать более умный подход к упр. производством в ИТ, что поможет снижать риски и повысит гибкость управления.
Извиняюсь за много букв и сумбурность изложения.
В виду того, что вы ничего не ответили на мой вопрос, я вынужден его повторить. Как вы в своей работе применяете 14 практик ТПДС. Я не знаю, как спросить конкретнее. Мне кажется, что вопрос очень конкретен.
В виду того, что вы похоже не потрудились понять, что я написал выше, я, честно говоря не понимаю, каким вам языком объяснить, как я их применяю (или хотел бы применять).
Как минимум упомянуто две подсистемы (из трех), которые частично были применены в постановке производственного процесса.
Хоть и объяснение было довольно общим, но человеку, который знаком с основами оно дает представление о том, что базовые принципы управления пр-вом кросс-индустриальны.
Похоже Вам выгоднее форма дискуссии, чем «конструктивное» русло, которым вы прикрылись в посте ранее. Увы, ничем тогда не могу помочь.
Как минимум упомянуто две подсистемы (из трех), которые частично были применены в постановке производственного процесса.
Хоть и объяснение было довольно общим, но человеку, который знаком с основами оно дает представление о том, что базовые принципы управления пр-вом кросс-индустриальны.
Похоже Вам выгоднее форма дискуссии, чем «конструктивное» русло, которым вы прикрылись в посте ранее. Увы, ничем тогда не могу помочь.
Спасибо, примерно таких общих ответов я и ожидал. В конкретные примеры вы не желает углубляться, из чего можно сделать два вывода. Либо вам лень, но тогда к чему длинный пост выше? Либо их нет. Этот вывод для меня пока более вероятен, если вы все же не сочтете возможным его опровергнуть.
Какие вам «конкретные примеры»нужны? Что мы создавали систему постоянного повышения квалификации или что реюзали компоненты, для повышения стандартизации и снижения вариабельности? Такими примерами можно пару скроллов исписать и к каждому можно еще анализ приложить что на что влияет, как связано и как формализовать использование.
Поэтому были сделаны обобщения на уровне подсистем.
Что я хотел от Вас услышать, что вы не еще одна жира, редмайн или очередное поделие Джоела Спольски. Что вы понимаете, что творится не только внутри software production, но и как оно происходит в других отраслях и готовы создавать уникальный и целостный продукт для индустрии. Похоже я этого не дождусь. Жаль, что компетенции вашей компании ограничиваются только 1/14 от того, что наука управления производством уже достигла (но для IT, как я уже говорил, этого, увы, хватает).
Поэтому были сделаны обобщения на уровне подсистем.
Что я хотел от Вас услышать, что вы не еще одна жира, редмайн или очередное поделие Джоела Спольски. Что вы понимаете, что творится не только внутри software production, но и как оно происходит в других отраслях и готовы создавать уникальный и целостный продукт для индустрии. Похоже я этого не дождусь. Жаль, что компетенции вашей компании ограничиваются только 1/14 от того, что наука управления производством уже достигла (но для IT, как я уже говорил, этого, увы, хватает).
Ваш вызов меня заинтриговал. Перед тем, как ответить, я хочу задать один вопрос: Как вы измеряете продуктивность программистов?
В попугаях, как это принято в agile/scrum.
Если вы о механизме, то в рамках текущей компании — никак, ибо не дозволено руководством. А в своей компании я бы использовал стат.методы и 6Sigma, например.
Может есть что-то еще, но я пока самообразовался только до нее.
Если вы о механизме, то в рамках текущей компании — никак, ибо не дозволено руководством. А в своей компании я бы использовал стат.методы и 6Sigma, например.
Может есть что-то еще, но я пока самообразовался только до нее.
Черт, вы можете ответить конкретно хоть на один вопрос? Как бы вы хотели оценивать продуктивность программиста?
Куда еще конкретнее-то? Попугаи в agile = стори поинты — других вроде не юзают.
П.С. Ответственность за коммуникацию несет коммуникант (теория коммуникации).
П.С. Ответственность за коммуникацию несет коммуникант (теория коммуникации).
Хорошо, я переформулирую вопрос. Вот есть у вас в команде 10 программистов. Как вы оцениваете, кто делает больше работы и насколько больше? Какая методика оценки продуктивности?
Я извиняюсь, что вмешиваюсь в ваш душевный разговор. Но хотел бы высказать по этому вопросу свое мнение.
Оценивать продуктивность программиста — это бред. И правильно делает руководство не разрешая это делать. Ни какая статистика не покажет важность наличия работы того или иного программиста.
Работу программиста имеет смысл оценивать лишь для возможности — его карьерного роста. И тут важно совсем не продуктивность. Тут надо оценивать может ли человек справится самостоятельно с задачей, которую ему поставили. Если он много задает вопросов, и таких вопросов, которые находятся внутри его сферы ответственности — значит это молодой программист и его еще надо обучать (поставить в пару с опытным).
Те программисты, которые справляются сами со своими проблемами, и вы на собраниях не слышите от него разговоров о том как сделать то или иное, а он берет слово и в это время и добивается от остальных решения проблем, которые ему важны, но за которые ответственны другие работники, то можно начинать думать о том, чтобы поставить его на роль ведущего программиста.
Когда же он начинает критиковать основы архитектуры, и начинает говорить обоснованно о том, что поменяв это или другое, программисты начнут делать меньше ошибок, что вот такая организация кода поможет сократить время разработки и повысит повторное использование, а здесь ограничит программиста такими рамками, что он просто будет вынужден написать качественный код, а иначе он просто не заработает. То стоит думать доверить ему роль архитектора.
Если же человек более интересуется не программной стороной вопроса, а коммуникацией с заказчиками и это у него получаются и все ему мило улыбаются и нет конфликтов с коллегами, т.к. он умело переводит язык заказчика на языка программиста — то подумайте о его роли как постановщика задач, аналитика предметной области.
Поэтому как видим оценка идет не по производительности, а по наличию особых качеств работы того или иного работника. И даже если он делает что-то медленнее, это еще не значит что это хуже, это может быть просто надежнее. И если человек объявляет вам сроки, как вам кажется завышенные в 3 раза, а другой готов это сделать в 4 раза быстрее — насторожится надо скорее там где, человек торопиться.
Оценивать продуктивность программиста — это бред. И правильно делает руководство не разрешая это делать. Ни какая статистика не покажет важность наличия работы того или иного программиста.
Работу программиста имеет смысл оценивать лишь для возможности — его карьерного роста. И тут важно совсем не продуктивность. Тут надо оценивать может ли человек справится самостоятельно с задачей, которую ему поставили. Если он много задает вопросов, и таких вопросов, которые находятся внутри его сферы ответственности — значит это молодой программист и его еще надо обучать (поставить в пару с опытным).
Те программисты, которые справляются сами со своими проблемами, и вы на собраниях не слышите от него разговоров о том как сделать то или иное, а он берет слово и в это время и добивается от остальных решения проблем, которые ему важны, но за которые ответственны другие работники, то можно начинать думать о том, чтобы поставить его на роль ведущего программиста.
Когда же он начинает критиковать основы архитектуры, и начинает говорить обоснованно о том, что поменяв это или другое, программисты начнут делать меньше ошибок, что вот такая организация кода поможет сократить время разработки и повысит повторное использование, а здесь ограничит программиста такими рамками, что он просто будет вынужден написать качественный код, а иначе он просто не заработает. То стоит думать доверить ему роль архитектора.
Если же человек более интересуется не программной стороной вопроса, а коммуникацией с заказчиками и это у него получаются и все ему мило улыбаются и нет конфликтов с коллегами, т.к. он умело переводит язык заказчика на языка программиста — то подумайте о его роли как постановщика задач, аналитика предметной области.
Поэтому как видим оценка идет не по производительности, а по наличию особых качеств работы того или иного работника. И даже если он делает что-то медленнее, это еще не значит что это хуже, это может быть просто надежнее. И если человек объявляет вам сроки, как вам кажется завышенные в 3 раза, а другой готов это сделать в 4 раза быстрее — насторожится надо скорее там где, человек торопиться.
Черт, вы испортили всю малину. Сейчас я уже вряд ли получу интересный ответ и никаких лулзов мы не словим :(
1. "… конструктивное русло"
2. «Я не знаю, как спросить конкретнее.»
3. «Черт, вы можете ответить конкретно хоть на один вопрос?»
4. «никаких лулзов мы не словим»
толстячка не покормили?
Зато могу припомнить, сколько лулзов словили мы, когда в конце 2010го года сотрудники вернулись с конференции и рассказали, что спикер от вашей конторы сказал, что вы не используете свой же продукт для разработки.
Похоже в ДНК вашей конторы уже заложено, что вы будете просто «кодить» чьи-то готовые модели и следовать очередному тренду моды, нежели стараться понять суть вещей и улучшить их.
2. «Я не знаю, как спросить конкретнее.»
3. «Черт, вы можете ответить конкретно хоть на один вопрос?»
4. «никаких лулзов мы не словим»
толстячка не покормили?
Зато могу припомнить, сколько лулзов словили мы, когда в конце 2010го года сотрудники вернулись с конференции и рассказали, что спикер от вашей конторы сказал, что вы не используете свой же продукт для разработки.
Похоже в ДНК вашей конторы уже заложено, что вы будете просто «кодить» чьи-то готовые модели и следовать очередному тренду моды, нежели стараться понять суть вещей и улучшить их.
>сотрудники вернулись с конференции и рассказали, что спикер от вашей конторы сказал, что вы не используете свой же продукт для разработки.
Я не знаю, с каких слов вы услышали этот бред. Мы использовали наш продукт с 2004 года и используем до сих пор. Конечно, не весь его функционал, а процентов наверное 50 сейчас.
Вот что я думаю о нашей дискуссии. Вы любите бросить свысока несколько фраз, подкрепив их красивыми терминами. Возможно, вы прочитали пару десятков книг. Все может быть. Но вы ни в коем случае не хотите углубляться в детали. А без деталей вся эта дискуссия о лин и канбан весьма бесполезна.
Я вам желаю удачи в поисках по настоящему матричной организации, руководство которой захочет внедрять пока-йока по настоящему. Бай бай!
Я не знаю, с каких слов вы услышали этот бред. Мы использовали наш продукт с 2004 года и используем до сих пор. Конечно, не весь его функционал, а процентов наверное 50 сейчас.
Вот что я думаю о нашей дискуссии. Вы любите бросить свысока несколько фраз, подкрепив их красивыми терминами. Возможно, вы прочитали пару десятков книг. Все может быть. Но вы ни в коем случае не хотите углубляться в детали. А без деталей вся эта дискуссия о лин и канбан весьма бесполезна.
Я вам желаю удачи в поисках по настоящему матричной организации, руководство которой захочет внедрять пока-йока по настоящему. Бай бай!
НЛО прилетело и опубликовало эту надпись здесь
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 – это ключевая фигура в организации.
Я так понимаю, вы прочли «Дао 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 – это ключевая фигура в организации.
Я прочел не только Дао Тойоты, но еще и основополагающую литературу по тем принципам, которые сейчас модно называть Lean. Уверен, что вам известно, о ком/чем я говорю.
За сцылу спасибо, почитаю Андерсена.
Успех любой методологии познается в сравнении с другими методологиями, а не «реальными делами».
И уж если говороть о методологиях, то нет «методологии Канбан», есть «инструмент канбан», наряду с такими инструментами, как — «пока-ёке», «хансей-кайзен», «джидока» и ряда других. Только проблема ИТ в том, что мы схватились только за «канбан» и пытаемся обернуть 1 процесс производственного цикла в него, упуская все остальные. А это идет в разрез в принципами Lean, которые направлены на создание «value» на протяжении всего жизненного цикла продукта.
Благодарю за совет с работой — это в процессе, но, к сожалению, организаций с матричной структурой, а тем более проектной — очень и очень мало.
П.С. Я прочитал пост вашего начальника. Думаю, что вы должны объяснить ему, что Continuous Delivery пагубно сказывается на качестве кода, что, судя по комментам ИТТ у вас и так страдает.
За сцылу спасибо, почитаю Андерсена.
Успех любой методологии познается в сравнении с другими методологиями, а не «реальными делами».
И уж если говороть о методологиях, то нет «методологии Канбан», есть «инструмент канбан», наряду с такими инструментами, как — «пока-ёке», «хансей-кайзен», «джидока» и ряда других. Только проблема ИТ в том, что мы схватились только за «канбан» и пытаемся обернуть 1 процесс производственного цикла в него, упуская все остальные. А это идет в разрез в принципами Lean, которые направлены на создание «value» на протяжении всего жизненного цикла продукта.
Благодарю за совет с работой — это в процессе, но, к сожалению, организаций с матричной структурой, а тем более проектной — очень и очень мало.
П.С. Я прочитал пост вашего начальника. Думаю, что вы должны объяснить ему, что Continuous Delivery пагубно сказывается на качестве кода, что, судя по комментам ИТТ у вас и так страдает.
Очень понравилась статья. Сразу возникло несколько вопросов :)
1. Сколько из общего количества человек разработчиков, ПМ? Чтобы понять масштаб бедствия.
2. Как вы справляетесь с ситуациями, когда функционал вроде как сделан, но не до конца? Заводите отдельный тикет, или добиваете этот и как вообще поступаете? Как стимулируете разработчиков писать качественный код?
3. Каково среднее время работы разработчиков? Практика показывает, что слаженность команды и скорость разработки очень трудно сохранять при наличии хоть какой-либо текучки.
1. Сколько из общего количества человек разработчиков, ПМ? Чтобы понять масштаб бедствия.
2. Как вы справляетесь с ситуациями, когда функционал вроде как сделан, но не до конца? Заводите отдельный тикет, или добиваете этот и как вообще поступаете? Как стимулируете разработчиков писать качественный код?
3. Каково среднее время работы разработчиков? Практика показывает, что слаженность команды и скорость разработки очень трудно сохранять при наличии хоть какой-либо текучки.
>Сколько из общего количества человек разработчиков, ПМ?
40 человек в компании. 14 разработчиков. 0 PM
> Как вы справляетесь с ситуациями, когда функционал вроде как сделан, но не до конца? Заводите отдельный тикет, или добиваете этот и как вообще поступаете?
Доделываем до конца. Иногда заводятся баги на юзер стори. Иногда не заводятся.
>Как стимулируете разработчиков писать качественный код?
Хм. А зачем им писать некачественный?
> Каково среднее время работы разработчиков?
Среднее время не считали.
Текучесть разработчиков такая
2007 — 0
2008 — 0
2009 — 1
2010 — 3 (2 мы сами попросили уйти)
2011 — 2 (1 мы сами попросили уйти)
2012 — 0
40 человек в компании. 14 разработчиков. 0 PM
> Как вы справляетесь с ситуациями, когда функционал вроде как сделан, но не до конца? Заводите отдельный тикет, или добиваете этот и как вообще поступаете?
Доделываем до конца. Иногда заводятся баги на юзер стори. Иногда не заводятся.
>Как стимулируете разработчиков писать качественный код?
Хм. А зачем им писать некачественный?
> Каково среднее время работы разработчиков?
Среднее время не считали.
Текучесть разработчиков такая
2007 — 0
2008 — 0
2009 — 1
2010 — 3 (2 мы сами попросили уйти)
2011 — 2 (1 мы сами попросили уйти)
2012 — 0
Спасибо за статью и классный продукт!
40 виртуальных серверов для тестов — это что-то облачное или купили несколько серверов и порезали их на виртуалки?
«Ежедневное собрание в 11 утра, занимает около 15 минут»
Меня вот интересует какой прок от таких собраний, и что именно можно обсудить за 15 минут?
Меня вот интересует какой прок от таких собраний, и что именно можно обсудить за 15 минут?
Стандартный stand up — услышать, что делают другие, рассказать, что делаешь сам. Так же услышать от саппорта, какие у них проблемы. Если надо что-то обсудить — это обсуждается после митинга.
Т.е. 40 человек 15 минут обсуждают предыдущий день и планы на будущее? Получается 10 человекочасов без учета того, что их всех прервали в начале рабочего дня. Как-то сложно представить, что это полезно даже половине присутствующих.
Ну, во-первых, не 40, а 15 — маркетинг раз в месяц рассказывает о новых клиентах, у ui team свой митинг. Насчет «прервали» не могу сказать — никогда не было в тягость сходить на митинг. А вот про полезность — это спорно, да. Мне, например, полезно — знать, что делается в команде целиком, подсказать, если знаю решение проблемы, попросить помощи, если нуждаюсь. Для других — это надо их спрашивать.
Ну, хорошо — вот у вас 6 групп, почему бы на митинге не встречаться 6 руководителям групп и решать вопросы взаимодействия, после чего в каждой группе не выслушать от руководителя план на неделю и того, что хотят другие группы. Там же поделить задачи на каждого человека и услышать от него обратную связь. Но именно не каждый день — что бесполезно, а понедельник. Это как генералы посовещались и довели до сведения личному составу. Это более эффективно.
:) описка
> Но именно не каждый день — что бесполезно, а понедельник
Но именно не каждый день — что бесполезно, а понедельно
> Но именно не каждый день — что бесполезно, а понедельник
Но именно не каждый день — что бесполезно, а понедельно
У нас нет руководителей групп.
И это скорее упущение
Как можно руководить группой в 1-2 человека?
… Если сам являешься членом группы.
> обычно состоит из дизайнера, 1-3 программистов, Product Owner, 1-2 тестировщиков и писателя
Насчитал как минимум 6. Если группа 1-2 то что-то не в порядке с разделением на группы
Насчитал как минимум 6. Если группа 1-2 то что-то не в порядке с разделением на группы
Впрочем можно говорить и о неформальном лидере группы, где 2-3 человека, кроме лидера. Это скорее даже лучше в социальном плане.
Правда, такому лидеру сложнее управлять работой команды — программисты люди упрямые. Но с другой стороны, лидер на то и лидер, чтобы не быть самодуром и выслушивать остальных членов команды.
«Неформальный лидер», который раз в неделю ходит с другими «неформальными лидерами» на закрытое совещание. :)
Писатель у нас один, продукт оунер тоже. Тестировщики и дизайнеры компетентны и достаточно автономны. «Группа» тут скорее не как единица ответственности, а просто те люди, которые будут делать фичу. Но работа по фичам ведь никогда не идет — работа идет по юзерстори, а там больше двух человек вряд ли бывает.
Писатель у нас один, продукт оунер тоже. Тестировщики и дизайнеры компетентны и достаточно автономны. «Группа» тут скорее не как единица ответственности, а просто те люди, которые будут делать фичу. Но работа по фичам ведь никогда не идет — работа идет по юзерстори, а там больше двух человек вряд ли бывает.
> «Неформальный лидер», который раз в неделю ходит с другими «неформальными лидерами»
В этом случае, они конечно встречаются по мере необходимости, но действительно только они — так как это не достаточно формально становится их областью ответственности
В этом случае, они конечно встречаются по мере необходимости, но действительно только они — так как это не достаточно формально становится их областью ответственности
Да, и к тому же в таких условиях говорить о группах — это скорее фикция. Тут скорее речь идет о одной группе, где каждый разработчик ответственен за свой участок кода. И это вполне нормально.
Так почему не достаточно обсудить то что нужно (если нужно) в отдельных командах, и предметно? Надо понимать — что это конечно никому особо не нужно, но это есть своеобразная форма контроля навязанная руководством. Типа я такой-то каждый день должен придумать, что пообещать сделать за сегодня. Но как правило, это фразы «продолжаю работу на модулем таким-то», и уж естественно, что никому не интересно кроме тестировщиков, что я исправил 10 ошибок таких-то. Поэтому если и делать подобные собрания то не чаще 1 раза в неделю, но зато по времени около часа.
Что же касается самоконтроля, то тут как раз парное программирование более эффективно, но как видим в компании от этого отказались, т.к. это раздражает людей — постоянно быть под «присмотром» коллег. Тоже не факт, что «присмотр» стимулирует — скорее это важно только для молодых программистов в паре с опытным.
Что же касается самоконтроля, то тут как раз парное программирование более эффективно, но как видим в компании от этого отказались, т.к. это раздражает людей — постоянно быть под «присмотром» коллег. Тоже не факт, что «присмотр» стимулирует — скорее это важно только для молодых программистов в паре с опытным.
Наше руководство присутствует на отдых силы 70% всех митингов, так что про контроль говорить не приходится. Про придумать — достаточно часто бывает, что на митинге говорят «я не знаю, что сегодня делать» — какой индикатор, что работа закончена.
Час на обсуждение того, чтобы было сделано, имхо, слишком много — вот здесь как раз и можно заскучать.
Час на обсуждение того, чтобы было сделано, имхо, слишком много — вот здесь как раз и можно заскучать.
Ах как все знакомо! Читал и умилялся.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Наш процесс разработки: 50 месяцев эволюции