Мизансцена: product owner за компьютером, разработчики вертят в руках колоды planing poker, доска с тикетами сгруппированными по сложности (на 0.5, 1 и 21 мало), все смотрят на вопрос в bug tracker, чтобы получше уяснить подробности и, черт-возьми, отэстимэйтить этот тикет!
11 комментариев:
FUU!! Планирование! А каг же "песать код блеать"? xD
Да... Наблюдал я когда-то высказывания "Так давайте писать уже что-то, пол дня и ничего не написали". В большинстве случаев решение задачи все-равно использовать было нельзя :)
Не-не-не! Без планирования не поедем!
Как же без него создавать продуктивный высококачественный код? (см. галеры)
=)
Да-да, видал я этих любителей Белого Совета. Сначала пол дня делают вид, что строят план и находят решения задач, а в итоге просто устаналивают временную точку, до которой программист имеет право ебашить код =)
Решение же в итоге все равно выдумывается разработчиком на ходу, причем из-за лимита времени оно частенько не отличается особой изящностью.
Твои представления о планировании остались в шестнадцатом веке. =)
Сейчас все несколько и иначе.
Вспомнилась цитата из Эврики: "More typing, less speaking!"
Но без планирования - никуда! Я с радостью вспоминаю когда у меня (у заказчика, который весь этот код использует) появился Мантис (на экране проектора такой зеленый с усами). Наконец-то перестали "теряться" заявки, наконец-то мне стало понятно над чем программисты работают, наконец-то стало понятно где мои глюки в ТЗ, но самое важное - это осознание того что Большой Брат наблюдает за всем этим!
Как итог работы мантиса - софт наконец-то стал насыщяться той функциональностью которой была нужна заказчику. Заказчик (Я) удалил около 50% первоначальных требований после переосмысления и/или нахождения дублей.
Да, мантис это на самом деле удобный инструмент, если хотеть пользоваться.
Ну, если под планированием подразумевать естественный процесс постановки и контроля решения задач, то канешна, куда уж без него.
Ну, тоже не совсем так. Но, уже намного ближе! =)
Ну так поведай, что я упускаю =)
Постановка и контроль решения это немного за рамками планирования.
На планировании мы:
а) разжевываем каждую задачу поподробнее, чтобы вся команда понимала как ее надо решать. Это полезно тем, что кто бы ни взял задачу способ уже обговорен, архитектор проекта контролирует ситуацию и уже на планировании может не пропустить плохое решение и тестировщики примерно понимают реализацию и могут строить свои планы по тестированию.
б) определяем сложность задачи по условной шкале. После первого пункта это не сложно.
в) Набираем задач на следующую итерацию сколько сможем сделать исходя из их важности и сложности.
Отправить комментарий
Примечание. Отправлять комментарии могут только участники этого блога.