Хорошо, я переформулирую вопрос. Вот есть у вас в команде 10 программистов. Как вы оцениваете, кто делает больше работы и насколько больше? Какая методика оценки продуктивности?
Спасибо, примерно таких общих ответов я и ожидал. В конкретные примеры вы не желает углубляться, из чего можно сделать два вывода. Либо вам лень, но тогда к чему длинный пост выше? Либо их нет. Этот вывод для меня пока более вероятен, если вы все же не сочтете возможным его опровергнуть.
В виду того, что вы ничего не ответили на мой вопрос, я вынужден его повторить. Как вы в своей работе применяете 14 практик ТПДС. Я не знаю, как спросить конкретнее. Мне кажется, что вопрос очень конкретен.
Я ни на секунду не сомневаюсь в вашей гениальности как ПМа. Но чтобы перевести нашу увлекательную дискуссию в конструктивное русло, хотелось бы услышать, как вы в своей работе применяете все 14 замечательных принципов пр пр тойоты. Заранее извиняюсь, что спросил.
Не боюсь. Подавляющее большинство изменений делаются на основе пожеланий наших клиентов. Мажорные релизы, как ТП3, конечно происходят нечасто. Но минорные могут происходить хоть ежедневно, от этого всем только хорошо, главное чтобы даунтайма не было. Мы не собираемся замораживать никакие ветки, но решать подобные проблемы с помощью фича тоглинга и кастомизации. Firefox катится в говно. Обновления фейсбука, которые происходят часто, далеко не все вообще замечают. Кто-нибудь заметил непрерывную загрузку в нотификациях (сегодня появилась)?
ExtJS придуман, чтобы транслировать экспериенс десктопного приложения в веб. Это пагубный и порочный путь, которым мы случайно начали идти. Его очень тяжело кастомизировать под наши нужды и в итоге оказалось, что мы используем практически на уровне ядра. Все наши компоненты кастомные. Все дефолтные темы ExtJS ужасны чуть более, чем полностью. Так что я не могу порекомендовать его использовать никому.
>Сколько из общего количества человек разработчиков, ПМ?
40 человек в компании. 14 разработчиков. 0 PM
> Как вы справляетесь с ситуациями, когда функционал вроде как сделан, но не до конца? Заводите отдельный тикет, или добиваете этот и как вообще поступаете?
Доделываем до конца. Иногда заводятся баги на юзер стори. Иногда не заводятся.
>Как стимулируете разработчиков писать качественный код?
Хм. А зачем им писать некачественный?
> Каково среднее время работы разработчиков?
Среднее время не считали.
Текучесть разработчиков такая
2007 — 0
2008 — 0
2009 — 1
2010 — 3 (2 мы сами попросили уйти)
2011 — 2 (1 мы сами попросили уйти)
2012 — 0
Это во многом правда, что выражено в предложении "Текущий UI представляет собой достаточно печальный коктейль из ASP.NET Ajax, ExtJS и нашего собственного фреймворка."
И собственно как раз эти проблемы сейчас и решаются "Текущие усилия направлены на унификацию всего этого счастья, так что в самом ближайшем будущем старый UI будет полностью заменен на новый."
Если быть конкретным, то можно будет фильтровать ВСЕ что угодно. Никаких перегрузок страниц не будет. Клиент-сайд будет летать. Велосипеды останутся — но мы стараемся их делать очень классными.
И на самом деле, если смотреть на альтернативные решения типа Rally и VersionOne, то там с UI все гораздо печальнее.
Мне кажется, что задача продукт оунера — просто задавать стратегическое направление. Как максимум — определять эпики высокого порядка в виде проблем в виде «у нас очень сложно добавлять энтити в систему, надо чтобы это было просто и быстро» или «у нас нет возможности визуализировать прогресс для нескольких команд». Каждый эпик решает и делает мини-команда. Для этого, конечно, некоторым членам мини-команды придется поглубже погрузиться в предметную область, изучить что надо сделать, провести собрания и придумать решения. Не обязательно весь мини-тим должен это делать, может быть кто-то один для этого эпика возьмет на себя роль продукт оунера. Но в итоге, думаю, всем будет интереснее работать и результать может быть лучше на выходе.
MVC — это вообще не туда. Node.js — тоже. Нам нужно было сделать DSL. Для этого лучше подходит скриптовый язык. На .NET выбор небогат. F# можно было бы еще. Но исторически сложился Python.
40 человек в компании. 14 разработчиков. 0 PM
> Как вы справляетесь с ситуациями, когда функционал вроде как сделан, но не до конца? Заводите отдельный тикет, или добиваете этот и как вообще поступаете?
Доделываем до конца. Иногда заводятся баги на юзер стори. Иногда не заводятся.
>Как стимулируете разработчиков писать качественный код?
Хм. А зачем им писать некачественный?
> Каково среднее время работы разработчиков?
Среднее время не считали.
Текучесть разработчиков такая
2007 — 0
2008 — 0
2009 — 1
2010 — 3 (2 мы сами попросили уйти)
2011 — 2 (1 мы сами попросили уйти)
2012 — 0
www.versionone.com/screenshots/VersionOne_R8_ScopeChange.gif
agileexecutive.files.wordpress.com/2010/10/apropos_23.jpg
И собственно как раз эти проблемы сейчас и решаются "Текущие усилия направлены на унификацию всего этого счастья, так что в самом ближайшем будущем старый UI будет полностью заменен на новый."
Если быть конкретным, то можно будет фильтровать ВСЕ что угодно. Никаких перегрузок страниц не будет. Клиент-сайд будет летать. Велосипеды останутся — но мы стараемся их делать очень классными.
И на самом деле, если смотреть на альтернативные решения типа Rally и VersionOne, то там с UI все гораздо печальнее.