Comments 24
Что вы делаете с задачами которые не «умещаются» в один спринт? А подзадачи этой задачи невозможно демонстрировать (как итог спринта) т.к они не самодостаточны.
Например?
Ну пусть юзер-стори «хочу бэкап на Луну, боюсь ядерного взрыва». Оценка 50-80 человеко-месяцев на самый простой канал до Луны. Раньше, чем через 2 месяца, вы ничего не можете показать.
Даже простой канал до Луны не строится мгновенно и в одно действие. Такой высокий уровень абстракции легко разбивается на подзадачи, а если речь идет о разработке ПО, декомпозировать задачи до 8-16 часовых подзадач — дело вполне реальное.
Дополню.
Показать же можно уже через спринт какое-то цельное и работающее решение. Пусть оно будет в виде тележки, подвозящей провод от генератора к площадке запуска, но оно будет работать.
Показать же можно уже через спринт какое-то цельное и работающее решение. Пусть оно будет в виде тележки, подвозящей провод от генератора к площадке запуска, но оно будет работать.
Задача разбивается на подзадачи, это понятно. Но пользовательскую историю как разбить на под-истории?
Что если не укладывается? Вот конкретно, с Луной :)
Важное требование к нашим историям – их размер: одна история должна укладываться в один спринт.
Что если не укладывается? Вот конкретно, с Луной :)
тут вы правы и не правы одновременно. можно разбить, но только это будет не совсем пользовательская история в таком случае в прямом понимании термина. поясню на примере:
делали per-to-per передачу данных с одного компьютера на другой через интернет(через NAT и так далее), разбили примерно так:
1. два компа нашли друг друга в инете
2. передали просто текстовое сообщение с одного на другое
дальше уже пошли более осмысленные истории близкие к конечному пользователю.
делали per-to-per передачу данных с одного компьютера на другой через интернет(через NAT и так далее), разбили примерно так:
1. два компа нашли друг друга в инете
2. передали просто текстовое сообщение с одного на другое
дальше уже пошли более осмысленные истории близкие к конечному пользователю.
Ну понятно, т.е. тоже можно показать результат по спринту. Вопрос был в том, как вы поступаете, если показать нельзя. Похоже, что ваш ответ — таких случаев не было :)
думаю были случаи, когда нельзя было показать, но в целом стараемся хотя бы что-то, но показать…
А вам действительно надо что-то показывать в конце спринта? Вы же не отдаете продукт конечному пользователю каждый спринт? Может тогда и время на это не тратить? Ведь основной момент — это понять, что конкретно было сделано за спринт, где вы находитесь, и где находится весь проект с точки зрения end-to-end продукта. Или я что-то пропустил? Это можно понять и по состоянию тест плана. Или нет?
В целом внешнего требования показать что-то в конце спринта нет, но мы стараемся все таки устраивать такие показы, чтобы команда видела прогресс.
чтобы понять где находится весь проект, мы используем burn-down на весь проект. Он, конечно, дает весьма примерное понимание, но так как у нас проект сопровождается постоянными изменениями, то в целом этого достаточно.
чтобы понять где находится весь проект, мы используем burn-down на весь проект. Он, конечно, дает весьма примерное понимание, но так как у нас проект сопровождается постоянными изменениями, то в целом этого достаточно.
Что значит не могу? Еще как могу. Если бекапим на какой-нибудь луноход, который уже на луне — сделаем аплоад и даунлоад одного килобайта. Если строим с нуля — прототипируем передачу килобайта на соседнюю гору. Всегда есть следующий маленький осмысленный шаг.
Процессы внедряются сверху вниз или снизу вверх?
Спасибо за статью. Практический опыт — это всегда интересно. Жаль только, мало кармы плюсануть -)
Хотелось бы узнать: как бы Вы охарактеризовали уровень сложности ваших проектов? В любой удобной для Вас форме.
Хотелось бы узнать: как бы Вы охарактеризовали уровень сложности ваших проектов? В любой удобной для Вас форме.
Важный момент: продукт должен быть выпущен точно в срок не позднее фиксированного момента времени.
А чем это обусловлено конкретно в вашем случае?
Когда прочитал «3. Четкие цели на спринт для всех участников проекта». Появилась мысль, что цели ставятся для каждого члена команды отдельно. Отсюда появился вопрос «Как обстоит дело с достижением общей цели на спринт?». И ниже читаю «Внедрение описанных выше механизимов обнажило другие проблемы: рассинхронизация команды и расфокусирование отдельных ее членов». Поэтому хотелось бы уточнить как вы до этого цели ставили? Например, Вася, ты делаешь вот это и это. Петя с тебя вот это и то. И т.д. Или это было в каком-то другом виде?
Еще был бы интересен технический момент. Контроль версий, прогон регрессии. Сколько времени это занимает? Какие уровни тестирования у вас вообще используются? На каких из них есть регрессия? Гоняется ли она для каждого изменения?
И еще комментарий насчет «С самого начала нужен хороший проектный план. Хороший — значит очень детальный: вся функциональность должна быть описана, продумана и запланирована. Очень похоже на первый этап каскадной модели.» Это же совсем не про Scrum. :) Одна из заявляемых вкусностей Scrum — это быстрая адаптация к новым требованиям, именно поэтому (как мне кажется) рисовать детальный план в начале проекта деятельность спорная. Однако, в вашем случае, как я понял, быстрая адаптация к новым требованиям не нужна, т.к. этого или совсем нет или бывает редко. Это так? Если да, то у вас получается что-то вроде Scrum в рамке водопада? И еще интересно было бы узнать как вы спецификацию пишите? Как правило вы же ее пишете до начала спринта, где будет идти разработка, или нет?
Еще был бы интересен технический момент. Контроль версий, прогон регрессии. Сколько времени это занимает? Какие уровни тестирования у вас вообще используются? На каких из них есть регрессия? Гоняется ли она для каждого изменения?
И еще комментарий насчет «С самого начала нужен хороший проектный план. Хороший — значит очень детальный: вся функциональность должна быть описана, продумана и запланирована. Очень похоже на первый этап каскадной модели.» Это же совсем не про Scrum. :) Одна из заявляемых вкусностей Scrum — это быстрая адаптация к новым требованиям, именно поэтому (как мне кажется) рисовать детальный план в начале проекта деятельность спорная. Однако, в вашем случае, как я понял, быстрая адаптация к новым требованиям не нужна, т.к. этого или совсем нет или бывает редко. Это так? Если да, то у вас получается что-то вроде Scrum в рамке водопада? И еще интересно было бы узнать как вы спецификацию пишите? Как правило вы же ее пишете до начала спринта, где будет идти разработка, или нет?
первый абзац: Есть определенные задачи на конкретных людей(Вася занимается вот этой историей, Сергей вот этой), а есть задачи на всю команду, которые складываются из задач конкретных людей. Например чтобы сделать историю, надо закончить девелопмент задачи, протестировать ее, покрыть автотестами. Это все делают зачастую разные люди. Но им надо понимать, что они в одной лодке и должны закончить конкретную историю.
второй абзац: Версии в SVN, каждые полчаса проверка сборки билда и урезанный набор тестов. Каждую ночь полная пересборка и прогон большого BVT, два раза в неделю прогон «Общих» автотестов, он занимает до полутора суток. Таким образом тестируется регрессия. Оно делается не для каждого изменения, так как за день может быть несколько комитов, но все же довольно часто. Есть еще ручное тестирование, там отдельные уровни тестирования.
третий абзац: Да, не про скрам, ну так я и описывал как мы эволюционировали =). Нам как раз нужна быстрая адаптация к новым требованиям. Ну вероятно можно сказать относительно быстрая, но все же. Спецификации и мокапы да, стараемся писать до начала спринта, но не всегда получается. Выходим из ситуации рассказывая на грумингах как и что собираемся сделать.
второй абзац: Версии в SVN, каждые полчаса проверка сборки билда и урезанный набор тестов. Каждую ночь полная пересборка и прогон большого BVT, два раза в неделю прогон «Общих» автотестов, он занимает до полутора суток. Таким образом тестируется регрессия. Оно делается не для каждого изменения, так как за день может быть несколько комитов, но все же довольно часто. Есть еще ручное тестирование, там отдельные уровни тестирования.
третий абзац: Да, не про скрам, ну так я и описывал как мы эволюционировали =). Нам как раз нужна быстрая адаптация к новым требованиям. Ну вероятно можно сказать относительно быстрая, но все же. Спецификации и мокапы да, стараемся писать до начала спринта, но не всегда получается. Выходим из ситуации рассказывая на грумингах как и что собираемся сделать.
Sign up to leave a comment.
There is no silver bullet, или как мы от водопада до Канбана через скрамовые аджайлы дошли