МакФейден из клана МакФейденов
Кросс-пост с rsdn, отсюда и далее. http://rsdn.ru/forum/message/2645901.1.aspx
G>>А вообще - блин, какие ссылки - всегда есть требования, дизайн, кодирование, отладка. Однажды я спросил одного из директора R&D CQG, только что заступившего в должность, какой цикл разработки он собирается применять и вообще - какую методологию? Может быть, RUP? Или, все-таки, XP? Ян МакФэйден, который перед этим возглавлял отдел разработки крупнейшего американского банка (Wells Fargo, кажется), засмеялся, и сказал что-то вроде этого: I don't really care. It's always something like requirements, design, coding, and testing. Whoops, I'm sorry guys, I need to take some evening beer with Dmitry (директор московского офиса)? Have you ever told that it's very dangerous - to stand between me and beer? И довольно заржал в одну калитку, манера у него была такая. Короче, мы были в шоке, и решили что пропал дом. Фигассе, не волнует его, пнимаешь.
G>>Далее - в течени полугода Ян МакФэйден быстро, четко, без истерик и лишних движений, комплексом мер эффективно решил проблемы с качеством клиента CQG - проблема тогда была, что темп появления дефектов превышал темп их исправления, и никто не знал, что делать. Теперь я понимаю, что более компетентного, эффективного, простого в общении, и вообще - классного директора R&D я в жизни не видел. Хардкорный профи. Впрочем, я их вообще не так много видел . Только в CQG - человек 5.
EM>Выделенное глубоко верно, но это и так все знают.
EM>Более интересно, какими именно мерами он "эффективно решил проблемы с качеством клиента CQG" ?
Ввел и наладил работу...
1) ...схемы приоретизации дефектов и планирования релизов. Дефекты начали сортировать по принципу value-cost, для этого собирался специальный triage meeting. Его МакФэйден вел лично.
2) ...а также улучшения маршрутизации дефектов и простейшей схемы контроля качества. МакФейден ввел код-ревью - все чекины, в которых не прописана фамилия проверяющего, отклонялись. Проверяющий был всегда компетентен в тех модулях, к которым относились исправления(была собрана матрица компетенции, которая применялась при назначениях). Это снизило количество дефектов, которые вносились исправлениями других дефектов.
Вот и все. Умница МакФейден. Как-то тихо все через полгода все забыли о проблемах с дефектами, когда схема заработала.
Я не так давно повторил этот фокус на последнем месте работы. Комания никак не могла выпустить maintenance release в срок, и каждый раз это было дикое напряжение и аврал - по 4 месяца задержки были. И вдруг через несколько месяцев - о чудо . Как-то незаметно и без напряжения все вдруг с удивлением обнаружили, что очередной maintenance release к выпуску готов . Странно, никто задницу на британский флаг не разрывал. Одна проблема - как-то слишком быстро и незаметно как-то все получилось, и customer support не успел поставить предыдущий release всем клиентам
А всего-то надо было делать несколько простых вещей. 1) code freeze - не подбрасывать в релиз, который проходит системный тест исправлений новых дефектов, просто потому, что "он все равно сломался" 2) Исправлять дефекты каждую неделю, не забивая на них полный болт. Скажем, по одному дню в неделю выделить на них каждому программерут 3) Иметь четкую отсечку по времени по выпуску каждого релиза. 4) разделить "зоны ответственности" между программистами, чтобы равномерно размазать по нима нагрузку по maintenance 5) и аккуратно управлять приоритетами, постоянно имея в виду всю эту схему - чтобы в первую очередь исправлялись критичные для кастомеров дефекты.
И все. Эти простые правила не напряжны для всех, и воистину творят чудеса Пункт 6) про code review - чтобы снизить количество неверных исправлений, я не смог до конца претворить в жизнь как непреложное правило (для этого нужна была новая инфраструктура билдов-VCS-issue tracker), но зоны ответственности уже положительно повлиял и на количество неверных исправлений.
EM>Кстати, я за этим чудо продуктом трейдил еще 9 лет назад и до сих пор этот ужас не забыл.
Не такой уж и ужас. Впрочем, было бы любопытно узнать, что именно вам не нравится в этом продукте - я это с удовольствием передам своему бывшему коллеге, который сейчас директор свой собственной конторы, и делает конкурента CQG . Заодно, расскажу, что из этого мы исправили с 1999 до 2005 года .
G>>А вообще - блин, какие ссылки - всегда есть требования, дизайн, кодирование, отладка. Однажды я спросил одного из директора R&D CQG, только что заступившего в должность, какой цикл разработки он собирается применять и вообще - какую методологию? Может быть, RUP? Или, все-таки, XP? Ян МакФэйден, который перед этим возглавлял отдел разработки крупнейшего американского банка (Wells Fargo, кажется), засмеялся, и сказал что-то вроде этого: I don't really care. It's always something like requirements, design, coding, and testing. Whoops, I'm sorry guys, I need to take some evening beer with Dmitry (директор московского офиса)? Have you ever told that it's very dangerous - to stand between me and beer? И довольно заржал в одну калитку, манера у него была такая. Короче, мы были в шоке, и решили что пропал дом. Фигассе, не волнует его, пнимаешь.
G>>Далее - в течени полугода Ян МакФэйден быстро, четко, без истерик и лишних движений, комплексом мер эффективно решил проблемы с качеством клиента CQG - проблема тогда была, что темп появления дефектов превышал темп их исправления, и никто не знал, что делать. Теперь я понимаю, что более компетентного, эффективного, простого в общении, и вообще - классного директора R&D я в жизни не видел. Хардкорный профи. Впрочем, я их вообще не так много видел . Только в CQG - человек 5.
EM>Выделенное глубоко верно, но это и так все знают.
EM>Более интересно, какими именно мерами он "эффективно решил проблемы с качеством клиента CQG" ?
Ввел и наладил работу...
1) ...схемы приоретизации дефектов и планирования релизов. Дефекты начали сортировать по принципу value-cost, для этого собирался специальный triage meeting. Его МакФэйден вел лично.
2) ...а также улучшения маршрутизации дефектов и простейшей схемы контроля качества. МакФейден ввел код-ревью - все чекины, в которых не прописана фамилия проверяющего, отклонялись. Проверяющий был всегда компетентен в тех модулях, к которым относились исправления(была собрана матрица компетенции, которая применялась при назначениях). Это снизило количество дефектов, которые вносились исправлениями других дефектов.
Вот и все. Умница МакФейден. Как-то тихо все через полгода все забыли о проблемах с дефектами, когда схема заработала.
Я не так давно повторил этот фокус на последнем месте работы. Комания никак не могла выпустить maintenance release в срок, и каждый раз это было дикое напряжение и аврал - по 4 месяца задержки были. И вдруг через несколько месяцев - о чудо . Как-то незаметно и без напряжения все вдруг с удивлением обнаружили, что очередной maintenance release к выпуску готов . Странно, никто задницу на британский флаг не разрывал. Одна проблема - как-то слишком быстро и незаметно как-то все получилось, и customer support не успел поставить предыдущий release всем клиентам
А всего-то надо было делать несколько простых вещей. 1) code freeze - не подбрасывать в релиз, который проходит системный тест исправлений новых дефектов, просто потому, что "он все равно сломался" 2) Исправлять дефекты каждую неделю, не забивая на них полный болт. Скажем, по одному дню в неделю выделить на них каждому программерут 3) Иметь четкую отсечку по времени по выпуску каждого релиза. 4) разделить "зоны ответственности" между программистами, чтобы равномерно размазать по нима нагрузку по maintenance 5) и аккуратно управлять приоритетами, постоянно имея в виду всю эту схему - чтобы в первую очередь исправлялись критичные для кастомеров дефекты.
И все. Эти простые правила не напряжны для всех, и воистину творят чудеса Пункт 6) про code review - чтобы снизить количество неверных исправлений, я не смог до конца претворить в жизнь как непреложное правило (для этого нужна была новая инфраструктура билдов-VCS-issue tracker), но зоны ответственности уже положительно повлиял и на количество неверных исправлений.
EM>Кстати, я за этим чудо продуктом трейдил еще 9 лет назад и до сих пор этот ужас не забыл.
Не такой уж и ужас. Впрочем, было бы любопытно узнать, что именно вам не нравится в этом продукте - я это с удовольствием передам своему бывшему коллеге, который сейчас директор свой собственной конторы, и делает конкурента CQG . Заодно, расскажу, что из этого мы исправили с 1999 до 2005 года .