Конечно не обязательно применять только к админам. Менеджер может быть снежинкой. Слесарь в автосервисе; бригада, ремонтирующя квартиру; продавец сотовых телефонов… Снежинки встречаются везде…
А на самом деле откровенных снежинок в нашей индустрии не так уж и много. Как правило, за внешними проявлениями качеств человека-снежинки лежит более глубокая системная проблема.
Эхххх, давайте покоментирую. Сразу скажу, работу проделали не зря. Вещь очень достойная! Тем более ничего подобного пока не попадалось.
А теперь буду придираться:
1. «Команда сидит в одном месте (colocaltion) » — зря так сразу в первом разделе и первым пунктом :) Будто сами не видели распределенных скрам-команд :) Это тебование ортодоксального ХР, а не скрама.
2. «Для каждой фичи из баклога указаны приемочные тесты » — Зачем? Для каждой фичи, запланированной на эту итерацию — еще куда не шло. А для всего беклога-то зачем? Не исключено, что у меня половина беклога заменится совершенно новыми фичами и получится, что я зря для старых расписывал приемочные тесты. А если будете говорить, что приемочные тесты не надо расписывать подробно, то тогда чем этот пункт будет отличаться от следующего: «Для каждой фичи из баклога указан сценарий демонстрации»
3. «Все истории имеют оценки » — правильный пункт! Только место ему не в «Планировании итерации», а в «Product Backlog». Пока в бэклоге у нас есть юзер сторизы без оценок, у нас нет контроля проекта на макро-уровне.
4. «Длительность каждой из задач не превышает двух дней» — зачем тут абсолютная величина? Если спринт в неделю, а задачи в два дня, то по чеклисту я пройду, а берндаун будет похож на зубы акулы. Мое мнение: декомпозировать истории на задачи надо так, что бы каждый член команды, практически на каждом стендапе мог ответить на «Что ты сделал вчера», просто назвав ID завершенной задачи.
5. «Оценки задач каждый день корректируются» да ну? Мое ИМХО, оценки остаются как есть, просто если вскрылись сложности, то это повод добавить еще одну задачу, а не подкручивать оценку уже имеющейся. Но тут дело вкуса. Почему задача оказывается недооцененной? Скорее всего не учли, что нужно сделать еще то-то и то-то. «сделать еще то-то и то-то» — это уже дополнительные задачи.
6. «Члены команды могут легко поменять план итерации » — ээээ, а это как? Типа я не отвечаю за базар перед продакт оунером? ЗАхотел поменял, не захотел не помнял? :)
7. " Баклог продукта корректируется в соответствии с пожеланиями заинтересованных лиц ". Он не корректируется. Его корректирует продакт оунер! Естественно, учитывая пожелания заинтерисованных лиц. Когда беклог сам корректируется на основании мнении толпы стейкхолдеров (половину из которых занесло на демку случайным ветром) результат может не оправдать ожидания. Ну это так :)
8. «РЕКОМЕНДОВАННОЕ ЧТЕНИЕ » — а как же Алистер Коберн (Agile Software Development), Крэг Ларман (Agile andIterative software development: Manager's guide, вообще пипец полезно для новичков!)? :)
Буду ждать второго релиза. Кстати, очень неплохая заготовка под модель зрелости :)
Что бы представить себе «нагрузку до 40g в течение 11 мс»… Какого порядка будет перегрузка и в течении какого времени, если уронить его плашмя с высоты 1м на кафельный пол?
Очень хорошая обзорная книга по основным методологиям:
Craig Larman, «Agile and Iterative Development: A Manager's Guide» (в переводе, к сожалению, я ее пока не встречал)
«Всегда думал, что водопад итерационен» вот и в оригинальной статье Уалкер Ройса так написано. Однако практика показала, что 10 страниц — это много и подавляющее большинство прочитало только первые 3.
В идеальном мире непонимание не является проблемой методологии, однако, жизнь повернулась так, что Уинстона до конца жизни гнобили за однопроходный водопад…
1. Открытием это для меня не будет. Моментом рождения каскадной модели разработки ПО считается 1970, когда Ройс опубликовал свою статью в IEEE Software. Однако, еще в 60-е года процветали итеративные и инкрементальные модели разработки. Например Evo (автор и идеолог — Tom Gilb). Методологию Evo тот же Craig Larman относит к категории Agile. То есть, итеративные модели появились раньше
2. Кстати о автомобилях. Даже у жигулей были опытные варианты, которые не шли в продакшн ;) По ним потом получали фидбек, вносили изменения и делали следующую версию.
3. «Попробуй agile-ом создать информационное обеспечение какой-нибудь системы жизнреобеспечения» В свое время я рулил разработкой куска бортовой системы (где была и интеграция с железом, которого еще не было на тот момент и еще куча всяких приключений). Никто не умер. Итеративная и инкрементальная модель и там оказалась на много надежнее и эффективнее. Просто тут постояный переход в крайности:
а. Документация сама по себе не делает код надежнее
б. Ни одна из методологий (даже Agile методологий) не запрещает нам писать документацию.
Просто нужно знать меру.
в. Не надо первые прототипы испытывать на живых людях
А еще исследователи теории сетей (например Albert-Laszlo Barabasi) исследовали половые сети по которым в 70е годы распространялся СПИД. Лавинообразному распространению этой бяки очень сильно поспособствовал французский 3.14дарас-стюард (имя уже не помню).
Кстати, 80% людей находятся друг от друга в не более, чем 10 половых контактах…
А на самом деле откровенных снежинок в нашей индустрии не так уж и много. Как правило, за внешними проявлениями качеств человека-снежинки лежит более глубокая системная проблема.
Распределенная команда, я думаю :) Или начальство всех в одну комнату не пускает ;)
А теперь буду придираться:
1. «Команда сидит в одном месте (colocaltion) » — зря так сразу в первом разделе и первым пунктом :) Будто сами не видели распределенных скрам-команд :) Это тебование ортодоксального ХР, а не скрама.
2. «Для каждой фичи из баклога указаны приемочные тесты » — Зачем? Для каждой фичи, запланированной на эту итерацию — еще куда не шло. А для всего беклога-то зачем? Не исключено, что у меня половина беклога заменится совершенно новыми фичами и получится, что я зря для старых расписывал приемочные тесты. А если будете говорить, что приемочные тесты не надо расписывать подробно, то тогда чем этот пункт будет отличаться от следующего: «Для каждой фичи из баклога указан сценарий демонстрации»
3. «Все истории имеют оценки » — правильный пункт! Только место ему не в «Планировании итерации», а в «Product Backlog». Пока в бэклоге у нас есть юзер сторизы без оценок, у нас нет контроля проекта на макро-уровне.
4. «Длительность каждой из задач не превышает двух дней» — зачем тут абсолютная величина? Если спринт в неделю, а задачи в два дня, то по чеклисту я пройду, а берндаун будет похож на зубы акулы. Мое мнение: декомпозировать истории на задачи надо так, что бы каждый член команды, практически на каждом стендапе мог ответить на «Что ты сделал вчера», просто назвав ID завершенной задачи.
5. «Оценки задач каждый день корректируются» да ну? Мое ИМХО, оценки остаются как есть, просто если вскрылись сложности, то это повод добавить еще одну задачу, а не подкручивать оценку уже имеющейся. Но тут дело вкуса. Почему задача оказывается недооцененной? Скорее всего не учли, что нужно сделать еще то-то и то-то. «сделать еще то-то и то-то» — это уже дополнительные задачи.
6. «Члены команды могут легко поменять план итерации » — ээээ, а это как? Типа я не отвечаю за базар перед продакт оунером? ЗАхотел поменял, не захотел не помнял? :)
7. " Баклог продукта корректируется в соответствии с пожеланиями заинтересованных лиц ". Он не корректируется. Его корректирует продакт оунер! Естественно, учитывая пожелания заинтерисованных лиц. Когда беклог сам корректируется на основании мнении толпы стейкхолдеров (половину из которых занесло на демку случайным ветром) результат может не оправдать ожидания. Ну это так :)
8. «РЕКОМЕНДОВАННОЕ ЧТЕНИЕ » — а как же Алистер Коберн (Agile Software Development), Крэг Ларман (Agile andIterative software development: Manager's guide, вообще пипец полезно для новичков!)? :)
Буду ждать второго релиза. Кстати, очень неплохая заготовка под модель зрелости :)
Интересно, а что в 2025 будут писать на хабре наши дети про наши ноуты?
Сейчас как раз думаю над идеей следующего мультика.
Очень хорошая обзорная книга по основным методологиям:
Craig Larman, «Agile and Iterative Development: A Manager's Guide» (в переводе, к сожалению, я ее пока не встречал)
Мне она очень понравилась в свое время
Хм… как бы выглядело начало деловой встречи, если бы все было наоборот?..
Если набраться терпения и прочитать дальше 3-й страницы, то там появляется итеративный подход.
Остольные факты в книгах и статьях Уалкера Ройса, Крэга Лармана, гугле и википедии.
В идеальном мире непонимание не является проблемой методологии, однако, жизнь повернулась так, что Уинстона до конца жизни гнобили за однопроходный водопад…
Собственно, об этом и мульт.
1. Открытием это для меня не будет. Моментом рождения каскадной модели разработки ПО считается 1970, когда Ройс опубликовал свою статью в IEEE Software. Однако, еще в 60-е года процветали итеративные и инкрементальные модели разработки. Например Evo (автор и идеолог — Tom Gilb). Методологию Evo тот же Craig Larman относит к категории Agile. То есть, итеративные модели появились раньше
2. Кстати о автомобилях. Даже у жигулей были опытные варианты, которые не шли в продакшн ;) По ним потом получали фидбек, вносили изменения и делали следующую версию.
3. «Попробуй agile-ом создать информационное обеспечение какой-нибудь системы жизнреобеспечения» В свое время я рулил разработкой куска бортовой системы (где была и интеграция с железом, которого еще не было на тот момент и еще куча всяких приключений). Никто не умер. Итеративная и инкрементальная модель и там оказалась на много надежнее и эффективнее. Просто тут постояный переход в крайности:
а. Документация сама по себе не делает код надежнее
б. Ни одна из методологий (даже Agile методологий) не запрещает нам писать документацию.
Просто нужно знать меру.
в. Не надо первые прототипы испытывать на живых людях
А пропагандой Agile вся моя слайдшара забита ;)
Кстати, 80% людей находятся друг от друга в не более, чем 10 половых контактах…