Эхххх, давайте покоментирую. Сразу скажу, работу проделали не зря. Вещь очень достойная! Тем более ничего подобного пока не попадалось.
А теперь буду придираться:
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 половых контактах…
В теории сетей это давно известный факт (годов эдак с 80-х). Если у нас имеется:
1. Растущая сеть
2. Новые узлы предпочитают соединятся с узлами у которых уже много связей
3. Связи направлены
То топология сети будет выглядеть именно таким образом.
По этой причине поисковые движки имеют возможность добавить произвольный сайт для индексации — это оказывается полезным, когда новый сайт оказывается в зоне изгоев. По этой же причине в компании образуются «феодальные» общинки.
По иронии судьбы в своем ЖЖ я написал ровно об этом двумя неделями ранее: Правда-правда (там же еще и линк на книжку про это есть).
Опять же не совсем так. Если верить библиографам, то ни Майкл Делл, ни Билл Гейтс, ни Сэм Уолтон не чувствовали этого. Это были простые парни, без богатого наследства или родственников. Просто у них получилось.
Например приводится история Майкла Делла с его подходом «не делать ничего, пока не придет заказ». В принципе, в 70е года этот подход был известен, назывался Just-In-Time и активно внедрялся в Тойоте (дяденьку звали Таичи Оно). Подобный подход накладывает некоторые требования на работу с поставщиками (так как нет огромных закупок «про запас», а все подкупается по мере необходимости), но если их к этому приучить, то наступает всеобщее счастье.
Еще говорилось про Макла Делла, что он стремился увеличивать долю продаж через интернет (что бы снизить издержки розничных продаж)
Или, например, Лу Герстнер, бывший СЕО IBM. Тот внедрил установку продавать не сервера, а решения. В начале 90-х это спасло IBM от гибели. Мысль, вроде как банальна, но не все это понимают. Например, очень часто встречаю программистов, которые просто пишут код, а не решают проблему нашего заказчика, со всеми вытекающими последствиями (ни шагу в сторону от ТЗ, даже если это даст явно больше ништяка заказчику).
Герб Келлахер (CEO SouthWest Airlines) и сам фрик, и на работу предпочитает брать фриков. Будучи в штатах в коммандировке оценил кайф его авиакомпании — там реально пилоты корки мочат. Для сноба вроде меня не смешные, но все равно приятно.
Основатель Wal-Mart Сэм Уоллтон по книжке рекомендует учится даже у самых своих отстойных конкурентов. Кстати, до него на розничном рынке США было уже много жирных игроков, но он за 20 лет их всех отжал.
Ну это так, если вкратце. А еще там есть Билл Гейтс, Джек Уэлч, Энди Гроув (переключивший Intel с производства памяти на производство процессоров)…
В плане расширения кругозора (и понимания чего читать дальше), книжка очень приятная.
Я сам практикую очень много того, о чем узнал из книжек. В подобных книжках тяжело найти реально практический пример, готовый к использованию в произвольном контексте, но найти ценную мысль можно, а после того, как мысль найдена, нужно ее углублять, в частности, читая другие книжки. До прочтения этой книги я упорно внедрял (и внедряю) практики Lean (это близко к Майклу Деллу).
Кстати, с удовольствием прочту ваш обзор книг по тайм менеджменту.
Зависит от того, сколько Вы уже прочитали подобных бизнес-мурзилок. Если эта будет стоять в первой пятерке, то с хорошей вероятностью новое вы там найдете. Если счет перевалил за два десятка — тогда вряд ли.
Распределенная команда, я думаю :) Или начальство всех в одну комнату не пускает ;)
А теперь буду придираться:
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 половых контактах…
1. Растущая сеть
2. Новые узлы предпочитают соединятся с узлами у которых уже много связей
3. Связи направлены
То топология сети будет выглядеть именно таким образом.
По этой причине поисковые движки имеют возможность добавить произвольный сайт для индексации — это оказывается полезным, когда новый сайт оказывается в зоне изгоев. По этой же причине в компании образуются «феодальные» общинки.
По иронии судьбы в своем ЖЖ я написал ровно об этом двумя неделями ранее: Правда-правда (там же еще и линк на книжку про это есть).
Например приводится история Майкла Делла с его подходом «не делать ничего, пока не придет заказ». В принципе, в 70е года этот подход был известен, назывался Just-In-Time и активно внедрялся в Тойоте (дяденьку звали Таичи Оно). Подобный подход накладывает некоторые требования на работу с поставщиками (так как нет огромных закупок «про запас», а все подкупается по мере необходимости), но если их к этому приучить, то наступает всеобщее счастье.
Еще говорилось про Макла Делла, что он стремился увеличивать долю продаж через интернет (что бы снизить издержки розничных продаж)
Или, например, Лу Герстнер, бывший СЕО IBM. Тот внедрил установку продавать не сервера, а решения. В начале 90-х это спасло IBM от гибели. Мысль, вроде как банальна, но не все это понимают. Например, очень часто встречаю программистов, которые просто пишут код, а не решают проблему нашего заказчика, со всеми вытекающими последствиями (ни шагу в сторону от ТЗ, даже если это даст явно больше ништяка заказчику).
Герб Келлахер (CEO SouthWest Airlines) и сам фрик, и на работу предпочитает брать фриков. Будучи в штатах в коммандировке оценил кайф его авиакомпании — там реально пилоты корки мочат. Для сноба вроде меня не смешные, но все равно приятно.
Основатель Wal-Mart Сэм Уоллтон по книжке рекомендует учится даже у самых своих отстойных конкурентов. Кстати, до него на розничном рынке США было уже много жирных игроков, но он за 20 лет их всех отжал.
Ну это так, если вкратце. А еще там есть Билл Гейтс, Джек Уэлч, Энди Гроув (переключивший Intel с производства памяти на производство процессоров)…
В плане расширения кругозора (и понимания чего читать дальше), книжка очень приятная.
Я сам практикую очень много того, о чем узнал из книжек. В подобных книжках тяжело найти реально практический пример, готовый к использованию в произвольном контексте, но найти ценную мысль можно, а после того, как мысль найдена, нужно ее углублять, в частности, читая другие книжки. До прочтения этой книги я упорно внедрял (и внедряю) практики Lean (это близко к Майклу Деллу).
Кстати, с удовольствием прочту ваш обзор книг по тайм менеджменту.