Так уж сложилось, что последние несколько лет я занимал самые разнообразные руководящие должности в полудюжине компаний, занимающихся разработкой программного обеспечения разного рода. Довелось побывать и тимлидом, и менеджером проекта, и группы проектов, руководителем отдела и руководителем технического направления; подопечных бывало от двух до ста пятидесяти человек, да и размеры компании варьировались от трёх до двухсот тысяч работников. Неизменным оставалось только одно: чисто управленческая работа, постепенный и окончательный отход от технических задач.
Уважаемый автор, а несколько лет — это сколько?
Лучше если вы распишете, сколько лет отпахали на каждой из перечисленных должностей
нет, объясню используя аналогию. Вам нужно средство передвижения под ваши нужды. Вы можете изобретать средство передвижения с нуля, а можете взять автомобиль и «допилить» его под ваши нужды. Шанс того, что вы изобретете самолет мал да и бюджет такого «тыканья впотьмах» очень высок, поэтому лучше начинать с чего-то готового.
Риск в том что старую систему сломаете, а новая «не полетит». И/Или люди разбегутся в страхе перед «новомодной хренью». Понятно, это вопрос времени и денег в конце концов, но кто готов это оплатить?
Тут надо четко понимать, для чего и как вы будете делать. Необходимость перемен должна назреть, а уж как правильно проводить орг. изменения — это уже классика, вот можно книгу об этом почитать полезную: pimenaus.livejournal.com/3450.html
И всегда необходимо помнить притчу про Буриданова осла, который умер от голода так и не приняв решения из какого стога сена есть. Мы менеджеры и мы обязаны выдавать управленческие решения и нести за них ответственность.
Присоединяюсь к тезису. Если брать скрам, то Сазерленд говорит:
У вас есть беклог?
У вас есть таймбокс?
Команда проводит собрания для синхронизации деятельности?
Команда проводит ретроспективы?
Если на всё ответить «Да!», то у вас есть скрам :)
А остальное — это уже best practices, например я ещё ниразу не видел беклог в котором не было бы зависимостей между user story или отсутствовали user story не несущие маркетинговой ценности заказчику (т.н. технический долг)
Ещё хотел бы добавить…
Мне импонирует scrum вовлечением «синих воротничков» в совершенствование процесса разработки и принятие решений. Это то что называют «бесконечным совершенствованием процессов». Это не какое-то изобретение в IT или конкретно scrum. Это то, что японцы называют Kaizen и родом оно из 50-х годов. И именно такие вещи как kaizen позволили поднять Японскую промышленность (напомню, что когда-то американцы относились к японским машинам так как мы сейчас относимся к китайским, такое было качество).
Идём дальше… когда мы начинаем говорить о вовлечении «синих воротничков» в совершенствование процессов у нас пропадает менеджмент и появляется лидерство (обычными механическими способами мотивации такого не добиться). И именно лидерство позволяет сделать из «танцев с бубном» высокоэффективный инструмент, который может поднять продуктивность того-же самого коллектива разработки.
Поэтому при выборе agile или не agile задайте себе два вопроса:
1. Насколько быстро и дёшево вы хотите сделать проект.
2. Если вы выберете agile, действительно ли вам хватит личностных качеств чтобы реально его внедрить.
А по моему топикстартер просто описал классический scrum ради scrum или «культ карго». Всё хорошо в нужное время и в нужном месте. Правда я противник эволюционного подхода построения «проектного контракта», т.е. когда начинают изобретать методы управления проектами в надежде, что когда-то это устаканится во что-то хорошее. На мой взгляд надо взять готовый метод, внедрить его а затем адаптировать под суровые реалии проекта/команды.
P.S Заметил, что сейчас xfcnj любой проектный треш и помойку в работе оправдывать: «А у нас RUP».
По «книжке» надо делать рефакторинг просто так, во время спринта, но это не всегда получается (сами знаете, что может быть epic рефакторинг). Подобные вещи составляют технический долг проекта. PO объяснили суть технического долга и изредка проводили консолидацию разных технических доработок в отдельные стори.
А это «Изредка» определялось профилем нагрузки команды.
Про сложные методы, у меня народ часто обнаруживая такое ставил там коммент «TODO: Оптимизнуть». Потом, когда подбивали технические долги, объединяли разные TODO-шки в стори по рефакторингу.
Глобально, нужно выбрать из готовых или написать свой компонент для распознавания языков и кодировок.
Делалась стори на сбор и анализ существующих алгоритмов (на выходе должен быть артефакт — отчет с показателями быстродействия и поддерживаемыми языками и кодировками). Далее была стори на проработку архитектуры своего решения.
Стори на «наколенный» модуль по своему решению.
Стори по тестированию быстродействия и определения потенциала своего модуля
дальше приняли решение пилить свой модуль
Стори по рефакторингу для доведения своего модуля до продакшн системы
Стори по оптимизации и увеличению скорости работы
Думаю, что для выдавшего опцион, наверное нет. А человек, который хочет этот опцион реализовать может запросто действовать понимая к чему это приведёт.
для двух человек не надо играть в скрам, вы правильно заметили, что это становится бюрократией
под перечисленными функциями вы описали не только работу по НИОКР но и саму рутинную работу аналитика :)
по моему опыту — нормально можно запихнуть в scrum.
А про резерв времени, а почему бы просто не отвести весь спринт свободному поиску? по результатам спринта будет какой-то результат (список направлений для дальнейшего поиска или ещё что-то) по нему можно будет сделать ещё набор стори.
И ещё дополню, когда вводите метрику, задайте себе вопрос, а можно ли это напрямую спроецировать на ROI. Нельзя собирать метрику ради метрики.
Измеряйте размер тестов. Тестовые методы должны быть от пять до двадцати строк кода. Общее количество тестового кода должно быть примерно равно количеству продуктового кода.
— откуда такая средняя температура по больнице? как количество строк вообще влияет на качество тестов?
Измеряйте скорость тестов. Тесты должны отрабатывать быстро; минуты, а не часы. Поощряйте за быстрые тесты.
не согласен, тест должен быть качественным. При нормальном CI с Gated Commit надо просто делать набор быстрых тестов для проверки коммитов, а полные жирные тесты гонять по ночам. А уж судить о том хорошо тест или нет по скорости его работы — это неправильно.
Измеряйте хрупкость тестов (Прим. пер.: test breakage). Тесты должны быть разработаны таким образом, чтобы изменения в продуктовом коде приводили к небольшим поломкам тестов. Если большая часть тестов падает, когда изменяется продуктовый код, то тесты требуют рефакторинга (Прим. пер. test design needs improving).
изменеия в продуктовом коде не должны ломать тесты, на то они и тесты чтобы делать автоматический регресс. Если делаются изменения логики обработки, то это скорее сработавший архитектурный риск. Считаю что трата времени на продумывание менее хрупких тестов — это потеря. Хотя может у кого есть факт из реальной жизни, когда на правку тестов выходило больше времени, чем на продумывание менее хрупких?
Измеряйте Цикломатическую сложность. Функции, которые очень сложны (например, cc > 6 или близко к этому) должны быть подвергнуты рефакторингу. Используйте средства наподобие Crap4J, чтобы определить методы и функции, нарушающие это правило и имеющие наименьшее покрытие тестами.
Измеряйте размер функций и классов. Средняя функция должна иметь менее 10 строк кода. Функции длиннее 20 строк надо разбивать. Классы более 500 строк следует разбивать на два и более классов. Измеряйте корреляцию Брейтвэйта, она должна иметь значение более 2.
это практика XP по созданию чистого кода. Тут скорее надо смотреть на читаемость а не на количество строк
Измеряйте метрики зависимостей. Убедитесь, что нет циклических зависимостей. Убеждайтесь, что поток зависимостей идет в направлении абстрагирования, в соответствии с принципом обращения зависимостей и принципом стабильных абстракций (Прим. Принцип стабильных абстракций: пакеты, которые максимально неизменчивы, должны быть максимально абстрактными. Изменчивые пакеты должны быть конкретными. Абстрагированность пакета должна быть пропорциональна его изменчивости.). главное в этом не увязнуть. Нам нужен продукт а не офигенно абстрагированные пакеты.
Подсчитывайте количество комитов в день. Это число должно быть больше, чем число разработчиков в команде. Поощряйте частые комиты.
Подсчитывайте число дней в которые сборки упали в этом месяце. Поощряйте за месяцы без падений. Измеряйте время, пока неисправности остаются неустраненными.
вперёд изучать 6 Sigma, метрика вообще ниочем.
Измеряйте «завершенность», запуская тесты на системе непрерывной интеграции и следите за историями тестирования, которые прошли или упали. Используйте это как основу показателя производительности и прогресса команды. Внедрите правило, что user story не считается законченной, пока соответствующая история тестирования не пройдет тест, и никогда не позволяйте ломаться тестам, которые уже прошли.
а вы принимаете стори с нерабочими тестами? или сломанным регрессом? Это надо не вводить правило. Оно должно быть изначально
Да не божественное он создание. Он просто один из пассажиров лодки которая не должна утонуть, поэтому он должен рационально оценивать свои действия.
На счет стори, которые «фиг знает что делать» — это тоже самое, что и исследовательские стори, надо планировать в своей работе задачи по выявлению причин (да это не marketable feature, мы понимаем, что жизнь не идеальна). Здесь главное не оставлять стори в виде проблемы, а формулировать дальнейшие действия по её решению (не надо из спринта в спринт одну же стори дёргать по беклогам, надо эпик разбивать по шагам в зависимости от появляющихся или отметаемых гипотезах). И в данном случае я бы не наказывал команду за фейлы нескольких спринтов, когда они тыкаются как слепые котята в поиске решения. Тут надо четко понимать, когда нет результата по общесистемным причинам, а когда нет результата по особым причинам.
Проще всего скатиться обратно в состояние «научного центра», когда работу невозможно спрогнозировать и непонятно когда результат будет. Scrum в отличии от метода «научного цента» хотя-бы на момент формирования беклога заставляет задуматься о следующих шагах в решении эпичной проблемы.
Введение такой границы скатывает нас от agile опять в сторону «я хочу четкое ТЗ». С PO надо уметь работать, его не просто надо заставить подписаться под DOD на планнинге, его надо изредка приглашать на Daily Scrum, советоваться с ним (из разряда: хотим сделать так, это будет нормально или нет). И PO должен действовать адекватно и понимать, когда его хотелка разрастается, стоит ли завести новую стори, просить сделать доп. мелочи или договориться с командой об аборте спринта. В этом и заключается гибкий подход.
Кстати, у Майка Кона книга User Stories Applied на русский переведена, я даже небольшой обзор по ней делал: pimenaus.livejournal.com/12614.html
Вообще, проблема работы по численным показателям стимулирующим тактические действия — это не проблема Scrum или IT-отрасли. Это вообще проблема менеджмента в глобальном масштабе. «Приведи аналогию» — скажете вы. Ок, вот аналогия:
Есть компания которая вышла на IPO, там нанимают манагера и в качестве мотиватора к достижению дают ему опцион (преимущество покупки акций по определенной цене). Манагер начинает действовать в целях повышения курса акций (работать на свой опцион) зачастую ломая работу компании и нанося её непоправимый вред. Через некоторое время манагер поднимает курс, реализует опцион и сваливает. А компания оказывается в предбанкротном состоянии.
Дело вот в чем, если у вас команда начинает «костыльничать» на старте, она просто не понимает, что выкашивать эти костыли придётся ей через некоторое время. И тут как-раз встаёт вопрос к коучу, который эту команду ведёт: «А объяснил ли он это команде?».
Второе, в статье придумывается модель премирования команды по численным показателям — это очень опасная тема, и тут как раз можно угодить в ловушку, которой является основная тема статьи. Команда просто начинает работать не на результат а на показатель — и в этом ключевая проблема.
Как выход из положения я бы не стал рассматривать TDD. Начать скорее надо с Code Review и Gated Commits c точки зрения инженерии, а с точки зрения работы с командой — надо ставить не тактические а стратегические цели, надо сделать понимание у команды всего пути получения готового продукта и очень осторожно работать с численными показателями.
Проблема scrum в том, что в нём в качестве определяющей аксиомы написано «мы знаем, что хотим получить до того, как ткнём start progress». Когда цель ясна, дальше её можно дробить до состояния «нельзя не выполнить».
Не согласен. Там аксиома скорее такова, что мы мало что знаем о story на её старте и с помощью постоянного общения с PO мы уточняем детализацию в течении спринта. А если ещё и работать по правилу «Стори завершена, когда PO сказал что она завершена», то это только стимулирует общение.
Возражения на счет того, что PO будет в таком случае злоупотреблять не принимаю, т.к. в данном случае есть противопоставление PO команде, а это изначально неправильная постановка процесса разработки — горе такому скрам внедрителю.
Наличие PMO говорит только о том, что в конторе есть деньги на содержание PMO. Напрямую PMO кэш не генерит, а может наоборот вносить только лишнюю бюрократию для поддержания видимости своей ценности.
Scrum уже давно пора перестать считать чем-то экзотическим, свою эффективность и в нашей стране он доказал уже с лихвой. Уже всё тёрто-перетёрто, где и как он работает и где не работает (приведенный автором топика пример, где скрам не работает — не катит)
Чтобы не изобретать велосипеды с «мотивирует/не мотивирует», надо просто хоть немного изучить теорию. Обычно все ограничиваются рассмотрением пирамиды Маслоу, а дальше идут уже к современным непосредственным софт скиллам. Посмотрите например модель Герцберга, с плюшками станет яснее:
Если вам чего-то не хватает в вашей работе, то надо не сидеть на заднице, а добиваться нужного, тем более если вы тим-лид, PM или какой-нибудь другой мид-левел-менеджер. Открою секрет, топ-менеджеры понимают всё на уровне денег. Если вы переведете в деньги время компиляции продукта на дохлом компе (время за день * на ставка программера за день) и покажете время окупаемости (хотя-бы зарплатой программиста) апгрейда техники — вы добьетесь своего. А сидеть с позицией «Я программист, меня нанимали писать код, а не заниматься всякой фигней» — это позиция лузера и человека, который не заинтересован в успешности дела, в котором участвует. Всемирно известная метода непрерывных улучшений kaizen говорит о вовлечении персонала на всех уровнях в процессы связанные с оптимизацией производства и повышением качества.
А вы не пробовали использовать SWOT анализ? Цель проста: определить сильные и слабые стороны каждого участника команды, а также возможности и угрозы которые из этого исходят. А на дебрифе свести данные и смотреть с чем команде придется мириться, а где минусы одного человека стоит компенсировать плюсами другого. Ну и конечно что развивать.
Уважаемый автор, а несколько лет — это сколько?
Лучше если вы распишете, сколько лет отпахали на каждой из перечисленных должностей
нет, объясню используя аналогию. Вам нужно средство передвижения под ваши нужды. Вы можете изобретать средство передвижения с нуля, а можете взять автомобиль и «допилить» его под ваши нужды. Шанс того, что вы изобретете самолет мал да и бюджет такого «тыканья впотьмах» очень высок, поэтому лучше начинать с чего-то готового.
Тут надо четко понимать, для чего и как вы будете делать. Необходимость перемен должна назреть, а уж как правильно проводить орг. изменения — это уже классика, вот можно книгу об этом почитать полезную: pimenaus.livejournal.com/3450.html
И всегда необходимо помнить притчу про Буриданова осла, который умер от голода так и не приняв решения из какого стога сена есть. Мы менеджеры и мы обязаны выдавать управленческие решения и нести за них ответственность.
У вас есть беклог?
У вас есть таймбокс?
Команда проводит собрания для синхронизации деятельности?
Команда проводит ретроспективы?
Если на всё ответить «Да!», то у вас есть скрам :)
А остальное — это уже best practices, например я ещё ниразу не видел беклог в котором не было бы зависимостей между user story или отсутствовали user story не несущие маркетинговой ценности заказчику (т.н. технический долг)
Мне импонирует scrum вовлечением «синих воротничков» в совершенствование процесса разработки и принятие решений. Это то что называют «бесконечным совершенствованием процессов». Это не какое-то изобретение в IT или конкретно scrum. Это то, что японцы называют Kaizen и родом оно из 50-х годов. И именно такие вещи как kaizen позволили поднять Японскую промышленность (напомню, что когда-то американцы относились к японским машинам так как мы сейчас относимся к китайским, такое было качество).
Идём дальше… когда мы начинаем говорить о вовлечении «синих воротничков» в совершенствование процессов у нас пропадает менеджмент и появляется лидерство (обычными механическими способами мотивации такого не добиться). И именно лидерство позволяет сделать из «танцев с бубном» высокоэффективный инструмент, который может поднять продуктивность того-же самого коллектива разработки.
Поэтому при выборе agile или не agile задайте себе два вопроса:
1. Насколько быстро и дёшево вы хотите сделать проект.
2. Если вы выберете agile, действительно ли вам хватит личностных качеств чтобы реально его внедрить.
P.S Заметил, что сейчас xfcnj любой проектный треш и помойку в работе оправдывать: «А у нас RUP».
А это «Изредка» определялось профилем нагрузки команды.
Делалась стори на сбор и анализ существующих алгоритмов (на выходе должен быть артефакт — отчет с показателями быстродействия и поддерживаемыми языками и кодировками). Далее была стори на проработку архитектуры своего решения.
Стори на «наколенный» модуль по своему решению.
Стори по тестированию быстродействия и определения потенциала своего модуля
дальше приняли решение пилить свой модуль
Стори по рефакторингу для доведения своего модуля до продакшн системы
Стори по оптимизации и увеличению скорости работы
под перечисленными функциями вы описали не только работу по НИОКР но и саму рутинную работу аналитика :)
по моему опыту — нормально можно запихнуть в scrum.
А про резерв времени, а почему бы просто не отвести весь спринт свободному поиску? по результатам спринта будет какой-то результат (список направлений для дальнейшего поиска или ещё что-то) по нему можно будет сделать ещё набор стори.
— откуда такая средняя температура по больнице? как количество строк вообще влияет на качество тестов?
не согласен, тест должен быть качественным. При нормальном CI с Gated Commit надо просто делать набор быстрых тестов для проверки коммитов, а полные жирные тесты гонять по ночам. А уж судить о том хорошо тест или нет по скорости его работы — это неправильно.
изменеия в продуктовом коде не должны ломать тесты, на то они и тесты чтобы делать автоматический регресс. Если делаются изменения логики обработки, то это скорее сработавший архитектурный риск. Считаю что трата времени на продумывание менее хрупких тестов — это потеря. Хотя может у кого есть факт из реальной жизни, когда на правку тестов выходило больше времени, чем на продумывание менее хрупких?
Измеряйте Цикломатическую сложность. Функции, которые очень сложны (например, cc > 6 или близко к этому) должны быть подвергнуты рефакторингу. Используйте средства наподобие Crap4J, чтобы определить методы и функции, нарушающие это правило и имеющие наименьшее покрытие тестами.
это практика XP по созданию чистого кода. Тут скорее надо смотреть на читаемость а не на количество строк
Измеряйте метрики зависимостей. Убедитесь, что нет циклических зависимостей. Убеждайтесь, что поток зависимостей идет в направлении абстрагирования, в соответствии с принципом обращения зависимостей и принципом стабильных абстракций (Прим. Принцип стабильных абстракций: пакеты, которые максимально неизменчивы, должны быть максимально абстрактными. Изменчивые пакеты должны быть конкретными. Абстрагированность пакета должна быть пропорциональна его изменчивости.).главное в этом не увязнуть. Нам нужен продукт а не офигенно абстрагированные пакеты.Подсчитывайте количество комитов в день. Это число должно быть больше, чем число разработчиков в команде. Поощряйте частые комиты.
вперёд изучать 6 Sigma, метрика вообще ниочем.
а вы принимаете стори с нерабочими тестами? или сломанным регрессом? Это надо не вводить правило. Оно должно быть изначально
На счет стори, которые «фиг знает что делать» — это тоже самое, что и исследовательские стори, надо планировать в своей работе задачи по выявлению причин (да это не marketable feature, мы понимаем, что жизнь не идеальна). Здесь главное не оставлять стори в виде проблемы, а формулировать дальнейшие действия по её решению (не надо из спринта в спринт одну же стори дёргать по беклогам, надо эпик разбивать по шагам в зависимости от появляющихся или отметаемых гипотезах). И в данном случае я бы не наказывал команду за фейлы нескольких спринтов, когда они тыкаются как слепые котята в поиске решения. Тут надо четко понимать, когда нет результата по общесистемным причинам, а когда нет результата по особым причинам.
Проще всего скатиться обратно в состояние «научного центра», когда работу невозможно спрогнозировать и непонятно когда результат будет. Scrum в отличии от метода «научного цента» хотя-бы на момент формирования беклога заставляет задуматься о следующих шагах в решении эпичной проблемы.
Кстати, у Майка Кона книга User Stories Applied на русский переведена, я даже небольшой обзор по ней делал: pimenaus.livejournal.com/12614.html
Вообще, проблема работы по численным показателям стимулирующим тактические действия — это не проблема Scrum или IT-отрасли. Это вообще проблема менеджмента в глобальном масштабе. «Приведи аналогию» — скажете вы. Ок, вот аналогия:
Есть компания которая вышла на IPO, там нанимают манагера и в качестве мотиватора к достижению дают ему опцион (преимущество покупки акций по определенной цене). Манагер начинает действовать в целях повышения курса акций (работать на свой опцион) зачастую ломая работу компании и нанося её непоправимый вред. Через некоторое время манагер поднимает курс, реализует опцион и сваливает. А компания оказывается в предбанкротном состоянии.
Дело вот в чем, если у вас команда начинает «костыльничать» на старте, она просто не понимает, что выкашивать эти костыли придётся ей через некоторое время. И тут как-раз встаёт вопрос к коучу, который эту команду ведёт: «А объяснил ли он это команде?».
Второе, в статье придумывается модель премирования команды по численным показателям — это очень опасная тема, и тут как раз можно угодить в ловушку, которой является основная тема статьи. Команда просто начинает работать не на результат а на показатель — и в этом ключевая проблема.
Как выход из положения я бы не стал рассматривать TDD. Начать скорее надо с Code Review и Gated Commits c точки зрения инженерии, а с точки зрения работы с командой — надо ставить не тактические а стратегические цели, надо сделать понимание у команды всего пути получения готового продукта и очень осторожно работать с численными показателями.
Не согласен. Там аксиома скорее такова, что мы мало что знаем о story на её старте и с помощью постоянного общения с PO мы уточняем детализацию в течении спринта. А если ещё и работать по правилу «Стори завершена, когда PO сказал что она завершена», то это только стимулирует общение.
Возражения на счет того, что PO будет в таком случае злоупотреблять не принимаю, т.к. в данном случае есть противопоставление PO команде, а это изначально неправильная постановка процесса разработки — горе такому скрам внедрителю.
Наличие PMO говорит только о том, что в конторе есть деньги на содержание PMO. Напрямую PMO кэш не генерит, а может наоборот вносить только лишнюю бюрократию для поддержания видимости своей ценности.
Scrum уже давно пора перестать считать чем-то экзотическим, свою эффективность и в нашей стране он доказал уже с лихвой. Уже всё тёрто-перетёрто, где и как он работает и где не работает (приведенный автором топика пример, где скрам не работает — не катит)
Чтобы не изобретать велосипеды с «мотивирует/не мотивирует», надо просто хоть немного изучить теорию. Обычно все ограничиваются рассмотрением пирамиды Маслоу, а дальше идут уже к современным непосредственным софт скиллам. Посмотрите например модель Герцберга, с плюшками станет яснее:
Если вам чего-то не хватает в вашей работе, то надо не сидеть на заднице, а добиваться нужного, тем более если вы тим-лид, PM или какой-нибудь другой мид-левел-менеджер. Открою секрет, топ-менеджеры понимают всё на уровне денег. Если вы переведете в деньги время компиляции продукта на дохлом компе (время за день * на ставка программера за день) и покажете время окупаемости (хотя-бы зарплатой программиста) апгрейда техники — вы добьетесь своего. А сидеть с позицией «Я программист, меня нанимали писать код, а не заниматься всякой фигней» — это позиция лузера и человека, который не заинтересован в успешности дела, в котором участвует. Всемирно известная метода непрерывных улучшений kaizen говорит о вовлечении персонала на всех уровнях в процессы связанные с оптимизацией производства и повышением качества.
А теперь сносите карму :)
только не надо меня пытаться переубедить
P.S. ещё раз убеждаюсь в нецелесообразности холивара, думаю пора завязывать