Re: PoC PrototypegapertonApril 28 2010, 07:59:57 UTC
В общем, я тоже так считаю.
Только здесь есть несколько ловушек. 1) Чтобы иметь возможность прикинуть, _как_ мы будет делать нечто, мы уже должны иметь неплохое представление, _что_ мы должны сделать.
Оно, это представление, далеко не всегда есть. Иногда, когда нам кажется, что оно есть - мы все равно можем пролететь, и ошибиться с ним.
Почему "экстремальные" Agile методы часто и срабатывают. Правда, чтобы они сработали в такой ситуации, надо иметь запас по времени, чтобы иметь возможность выкинуть в корзину результаты целой итерации. Не меньше. Чудес не бывает.
2) Получается, что для того, чтобы от предварительного проектирования был толк, надо в первую очередь уметь получать маль-мальски адекватный ответ на вопрос "что".
Это, в свою очередь, делается так - надо отличать _потребность_ клиентов от их желаний.
За потребностью обычно стоит объективная проблема, которую они хотят решить. "Желанием" же часто является их видение решения, которое малоадекватно и поэтому часто меняется. "Желания" клиента часто принимают за требования, а потом - удивляются, как часто "требования" меняются.
Как только вы при постановке начинаете работать с проблемами клиентов, и предлагать ему их решения, а не с их желаниями - жизнь сразу радикально упрощается. В этом - ключ.
3) "Ленивый" принцип. "Никогда не откладывай на завтра то, что можно сделать послезавтра". Цель проектирования - побить работу на независимые части, и сделать поменьше работы. Побили на крупные независимые куски, стало "по большей части понятно" - и все, откладывайте дальнейшее проектирование до момента, когда соответствующая задача реально понадобится.
Проектированием также не надо увлекаться потому, что оно часто является механизмом психологического избегания непонятной работы. Т.е. смотрим - проблема сложна, непонятна - надо написать мегабиблиотеку. И, вместо того, чтобы войти в контакт с непонятной проблемой - заряжаем проектирование какого-нибудь фреймворка, откладывая контакт с ней.
Впрочем, последнее при описанном мной подходе должно быть исключено.
Re: PoC PrototypegapertonApril 28 2010, 08:24:35 UTC
А вот обеспечить пункт (2) гораздо сложнее. В одиночку - легко. Но группой - практически все современные тулы и методологии будут в этом деле против вас :).
Берем мой предыдущий пример с котировками. Записываем в ТЗ - невинную фразу - "сервер исторических данных". И делаем вторую вполне невинную штуку - поручаем одному программисту "сервер", другому - клиента. А лучше всего - разным командам :) "Для дальнейшей проработки".
И все. Возможность прийти к решению, которое я описал - на практике _абсолютно_ исключена. :) Даже при наличии предварительного проектирования. Будет написан навороченный сервер :).
Забавно, правда? :) То, что понятно и легко в одиночку, к чертям ломается на группе. Причем, само собой.
Это - другая крупная психологическая ловушка. Подробно я ее разбираю в другом материале - Befehlstaktik и Auftragstaktik.
Ключ к решению - "функциональная" группировка людей в команды, кроссдисциплинарные команды, и особый, проблемно-ориентированный стиль выдачи заданий. В клинч с которым входят традиционные методики планирования, и их надо заменить чем-то другим... об этом у меня другой материал.
Единственная известная мне методология, которая нормально дружит с данным подходом - Feature Driven Development. Прекрасная штука, рекомендую. Автор - умница.
Только здесь есть несколько ловушек.
1) Чтобы иметь возможность прикинуть, _как_ мы будет делать нечто, мы уже должны иметь неплохое представление, _что_ мы должны сделать.
Оно, это представление, далеко не всегда есть. Иногда, когда нам кажется, что оно есть - мы все равно можем пролететь, и ошибиться с ним.
Почему "экстремальные" Agile методы часто и срабатывают. Правда, чтобы они сработали в такой ситуации, надо иметь запас по времени, чтобы иметь возможность выкинуть в корзину результаты целой итерации. Не меньше. Чудес не бывает.
2) Получается, что для того, чтобы от предварительного проектирования был толк, надо в первую очередь уметь получать маль-мальски адекватный ответ на вопрос "что".
Это, в свою очередь, делается так - надо отличать _потребность_ клиентов от их желаний.
За потребностью обычно стоит объективная проблема, которую они хотят решить. "Желанием" же часто является их видение решения, которое малоадекватно и поэтому часто меняется. "Желания" клиента часто принимают за требования, а потом - удивляются, как часто "требования" меняются.
Как только вы при постановке начинаете работать с проблемами клиентов, и предлагать ему их решения, а не с их желаниями - жизнь сразу радикально упрощается. В этом - ключ.
3) "Ленивый" принцип. "Никогда не откладывай на завтра то, что можно сделать послезавтра". Цель проектирования - побить работу на независимые части, и сделать поменьше работы. Побили на крупные независимые куски, стало "по большей части понятно" - и все, откладывайте дальнейшее проектирование до момента, когда соответствующая задача реально понадобится.
Проектированием также не надо увлекаться потому, что оно часто является механизмом психологического избегания непонятной работы. Т.е. смотрим - проблема сложна, непонятна - надо написать мегабиблиотеку. И, вместо того, чтобы войти в контакт с непонятной проблемой - заряжаем проектирование какого-нибудь фреймворка, откладывая контакт с ней.
Впрочем, последнее при описанном мной подходе должно быть исключено.
Reply
Берем мой предыдущий пример с котировками. Записываем в ТЗ - невинную фразу - "сервер исторических данных". И делаем вторую вполне невинную штуку - поручаем одному программисту "сервер", другому - клиента. А лучше всего - разным командам :) "Для дальнейшей проработки".
И все. Возможность прийти к решению, которое я описал - на практике _абсолютно_ исключена. :) Даже при наличии предварительного проектирования. Будет написан навороченный сервер :).
Забавно, правда? :) То, что понятно и легко в одиночку, к чертям ломается на группе. Причем, само собой.
Это - другая крупная психологическая ловушка. Подробно я ее разбираю в другом материале - Befehlstaktik и Auftragstaktik.
Ключ к решению - "функциональная" группировка людей в команды, кроссдисциплинарные команды, и особый, проблемно-ориентированный стиль выдачи заданий. В клинч с которым входят традиционные методики планирования, и их надо заменить чем-то другим... об этом у меня другой материал.
Единственная известная мне методология, которая нормально дружит с данным подходом - Feature Driven Development. Прекрасная штука, рекомендую. Автор - умница.
Reply
Leave a comment