?

Log in

No account? Create an account

Entries by category: технологии

Мои профили в соцсетях


FB Twitter VK LinkedIn YouTube

Краткое резюме есть здесь


А еще я написал книгу, и потом написал еще одну.


Если у вас есть вопрос, то его можно обсудить в форуме

Ссылки на все мои слайдкасты перехали сюда


Иногда (если кто-то из моих самых лучших клиентов об этом просит) я помогаю проводить глобальную ретроспективу. Глобальную, это значит не Agile-ретроспективу, которая занимает 1-3 часа и вовлекает команду, а большую ретроспективу, на 2-3 дня, в которой участвует и разработка, и бизнес, и споровождение, и дизайнеры... а еще иногда и представители клиентов или заказчиков, подрядчиков и вообще всех, кто потенциально может оказаться полезным для извлечения мудрости...

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

История примерно такая:
Была у нас система, написанная на старых технологиях. Она была не расширяемая, не масштабируемая, вся в багах (нужное подчеркнуть) и жила в таком виде 5/7/10 лет. В какой-то момент к нам пришло осознание/новый архитектор/дополнительное финансирование и мы решили наконец-то сделать все по уму. Собрались, оценили альтернативы и поняли, что за две недели/месяц/полгода мы все перепишем на современном стеке технологий и сможем наконец-то быстро добавлять новые функции/покрыть все юнит-тестами/обеспечить новые требования по производительности.

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


Дальше были вариации.

Где-то уволили/кастирировали/лишили премии и все грустно продолжили развивать все в старой неразвиваемой системе.
Где-то скрепя сердце и гениталий чудом выпустили все в последнюю минуту в релиз (и еще полгода на бою правили критичные баги и траблы с производительностью).
А где-то после того, как скрипя сердцем и гениталиями выпустили новую версию... половина пользователей перешла в новую систему.... а другая половина - нет... И теперь каждую новую фичу надо было впиливать и в старую неразвиваемую систему и в новую (тоже неразвиваемую, так как полгода правок критичных багов на бою ее превратили в какашище)...


Поделитесь своими историями рефакторинга пожалуйста. Может, среди них найдется история с другой концовкой? Ну хрен с ним со сроками, хотя бы когда стало ЛУЧШЕ, чем было, пусть и дороже, чем ожидалось?
Перед каждой зрелой скрам-командой рано или поздно встает вопрос, как сравнивать StoryPoint-ы между собой?

Например этот вопрос может встать, когда команда пытается понять, стала ли она работать быстрее… Предположим, в прошлом квартале скорость команды была 50 StoryPoint-ов за спринт, а в этом квартале 75. Ускорилась ли команда?

Другой пример. Предположим, есть проект, который команда А со стабильной скоростью 50 StoryPoint-ов за спринт уже оценила в 300 StoryPoint-ов и есть команда В со скоростью 75 StoryPoint-ов. Обе команды работают на одинаковых технологиях, и их проекты идеологически и технологически очень похожи. Внимание вопрос, правда ли команда В выполнит этот проект быстрее команды А?

Казалось бы ответы очевидны… Но тут все портит относительная природа StoryPoint-ов. В первом примере команда могла постепенно завышать оценки (то, что в прошлом квартале оценивалось в 4 StoryPoint-а теперь превратилось в 8). Не со зла и без всякого умысла. Просто оценка начала дрейфовать, и это нормально. Во втором примере такая же ситуация, даже не смотря на схожесть проектов, команда А может давать 4 StoryPoint-а таким пользовательским историям, которые команда В оценила бы в 8.

Что же делать?Collapse )

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


Еще одна очень хорошая книга очень хорошего автора: Джеффри Лайкер, "Система разработки продукции в Toyota. Люди, процессы, технология"

Не скрою, эта книга определила ход моего доклада на SoftwarePeople'11. Книга очень интересна и рассказывает как создаются новые автомобили в Тойота. Изучая бережливое производство я пытаюсь найти новые эффективные пути работы в нашей индустрии - разработке программного обеспечения. Скептически настроенный человек может аргументированно заметить, что система производства Тойоты (TPS) придумывалась для управления "конвеером", где вариабельность задачи от раза к разу минимальна. Это так. С одной стороны, этот факт не мешает использовать определенные элементы TPS в разработке ПО. С другой стороны, в разработке ПО неопределенности и вариабельности на много больше, что заставляет усомниться в применимости ДАО Тойоты в этой области.

На самом деле вариабельность и неопределенность не помеха ДАО Тойоты. Задача разработки нового автомобиля на много ближе (если вообще не то же самое) к разработке ИТ-системы. И там и там есть неопределенность, нечеткость требований в самом начале проекта, много рисков и всякого непонятного. И Тойота с этим справляется...

В книге подробно и с примерами разбираются 13 основных принципов разработки продукции в Тойота (эти принципы отличаются от рассмотренных в 14 принципов ДАО Тойота). 13 основных принципов объединены в 3 группы:

Процесс
  1. Определить, в чем ценность продукта для потребителя, что бы отличать добавление ценности от потерь. В нашей индустрии имеет смысл добавить еще и принцип 0 - определить, кто является нашим потребителем. Команда по разработке может считать своим потребителем того, кто платит деньги; владельца продукта или customer proxy; команду аналитиков/тестировщиков (если оргструктура в компании выделяет аналитиков/тестировщиков в отдельные единицы); ген. директора фирмы (той, которая платит деньги за разработку или зарплату) и т.п. В зависимости от этого понятие ценность будет иметь различные значения.
  2. Обеспечить правильный старт процесса разработки, чтобы на ранней стадии проектирования досконально изучить все альтернативные варианты. При разработке продукции в Тойота используются практики параллельного проектирования на базе альтернатив. В качестве примера, Лайкер дает ссылку на историю разработки силовой установки Приуса, когда с самого начала команда рассматривала 80 различных вариантов. Этот же принцип уходит корнями в основную практику Lean - "Deffer Commitment", подразумевающую, что всякое необратимое решение мы принимаем на столько поздно, на сколько это возможно, что бы не было потом мучительно больно, за "поторопились и получилось как всегда".
  3. Обеспечить выровненный поток процесса производства продукции. Это достаточно важно. Очереди - зло. Теория очередей гласит, что как только загрузка команды превышает определенный порог, время выполнения "заказа" начинает экспоненциально расти вместе с ростом загрузки. Еще раз, очереди - зло. Что бы избежать очередей в высоковариабельной среде, нужно либо иметь избыточную пропускную способность (чем выше вариабельность - тем выше избыток. А в разработке вариабельность ой как высока...) либо... не создавать очередей. Дробить все на кусочки и пропускать через систему кусочками. Если мы передаем ИТ-систему в поддержку, то не обязательно приходить к команде поддержки только когда все на 100% готово (и функционал и документация). Если выдавать все маленькими порциями, то перевариваться оно будет на много быстрее. Тут же используются принципы вытягивания для обеспечения "точно вовремя" и принципы синхронизации параллельных потоков. В общем, очень похоже на TPS.
  4. Применять жесткую стандартизацию, что бы снизить вариацию, повысить гибкость и обеспечить предсказуемость. Стандартизация - отдельная тема системы разработки продукции в Тойота. До недавнего времени стандарты у меня ассоциировались с чем-то неизменным, тяжелым, неэффективным и ненужным. Признаюсь, сейчас я радикальным образом изменил свое мнение. Мало того, начал замечать, сколько возможностей упускается из-за отсутствия стандартизации. Например, есть 4 команды и в каждой из них свой собственный скрам (специально для скептиков - скрам эволюционирует и это нормально. В разных командах по-разному...) Если бы скрам был бы менее "разный", то результаты ретроспектив можно было бы шарить между командами, в результате чего быстрее эволюционировать.
Люди
  1. Развивать систему главных инженеров для интеграции всего процесса разработки. Система главных инженеров в Тойота - отдельный разговор. Идея такого человека мне очень понравилась. Во-первых, главный инженер отвечает за новый продукт от и до. От разработки концепции нового автомобиля, до послепродажного обслуживания проданных тачек. И он единственный, кто отвечает за все это. Есть еще и другое приключение в должности главного инженера - группы разработки формально не подчиняются ему. И руководство производится исключительно за счет годами заработанного авторитета и доверия (что бы стать главным инженером в Тойота, зарабатывать доверие нужно 10-15 лет!!! Это явно не спроста). 
  2. Создать организационную структуру, которая позволяет сочетать функциональную компетентность и межфункциональную интеграцию. В Тойота используют матричную структуру! Я был удивлен. Настоящая матричная структура, в том виде, как оно описывается в классических книжках. Каждый центр разработки состоит из "функциональных шахт" - групп, специализирующихся на определенной функции. Есть мнение, что такая структура может эффективно работать только благодаря опытному и уважаемому главному инженеру.
  3. Повышать уровень технических знаний всех инженеров. Здесь стоит акцент на слове "технический". Тойота делает ставку на углубление, а не расширение знаний своих инженеров. В итоге в Тойота есть множество людей, знающий практически все, про практически ничто. Кто-то посвящает свою жизнь разработке ручек стеклоподьемников... Или кнопок аварийки... Для западных компаний (где принято инженерам через курсы МВА уходить в менеджеры) это кажется дикостью. Но в совокупности с предыдущими двумя принципами этот подход Тойоты реально работает.
  4. Сделать поставщиков составной частью системы разработки продукции. Про это читал у Вуммека... В какой-то момент Lean-компания обнаруживает, что большая часть ценности добавляется уже за пределами компании. Что бы продолжить борьбу с потерями, необходимо сделать поставщиков своим собственным продолжением, включить их "в семью". Ровно это и происходит в Тойота.
  5. Создать систему обучения и непрерывного совершенствования. Способность учиться позволяет Тойоте без опаски обучать принципам своей работы даже прямых конкурентов: "пока они освоят то, о чем мы им рассказали, мы уже будем далеко впереди". Кстати, а сколько в вашей команде прочитано книг по специальности за последний месяц? ;)
  6. Сформировать культуру постоянного стремления к совершенству. Это немного ассоциировалось у меня с самобичеванием. Культура Тойоты - это постоянный акцент на собственных недостатках. Именно это заставляет их все двигаться и двигаться вперед. Именно по этой причине TPDS нельзя внедрить, это можно только выращивать.
Технологии
  1. Адаптировать технологию к потребностям людей и процесса. Тойота достаточно консервативная организация, и не торопится внедрять очередное красивое ИТ-решение, о котором совсем недавно только услышали на конференции. Технологии не относятся к конкурентному преимуществу ни разу - их легко копировать. В отличии от ДАО.
  2. Координировать работу организации с помощью простых средств визуальной коммуникации. Здесь возникают мои любимые канбаны, и отчет формата А3. Отчет формата А3 - такой же просто инструмент как и метод "5 почему". Просто напишите отчет на листе А3. Не хватает листа А3, тогда используйте А4. ("5 почему" - тоже достаточно простой метод. Видите нежелательное явление? Спросите себя "почему?" 5 раз и с очень хорошей вероятностью вы доберетесь до корневой причины. Правда!)
  3. Использовать эффективные инструменты стандартизации и организационного обучения. Опять стандарты. Если у вас нет стандартов - у вас не будет кайдзен. И это правда. Если какое-то дело вы каждый раз выполняете будто впервые, то как можно это улучшить? В качестве стандартов в Тойота очень любят чек-листы, за которые отвечают те, кто их использует (а не служба качества или еще кто бы то ни было)
Книга дала очень много поводов подумать и оставила после себя ряд идей, которые скоро пойдут во внедрение...

Рекомендую.

Tags:


Коллеги, представляю вам первую часть своего бухтелова на TestLabs'09. Скоро появятся оставшиеся две.

Tags:

Profile

Cartmendum
cartmendum
cartmendum

Latest Month

September 2019
S M T W T F S
1234567
891011121314
15161718192021
22232425262728
2930     

Syndicate

RSS Atom
Powered by LiveJournal.com
Designed by Tiffany Chow