Получить профит от применения гибкой методологии в общении с госзаказчиком сложно. Для него основная модель — жёстко заданные, согласованные в нескольких ведомствах требования по срокам, бюджету и качеству. Пересматривать эти параметры он физически и юридически не может. Потому мы должны подстраиваться под эти внешние обстоятельства, что, однако, не отменяет возможность применения гибкой методологии внутри нашего процесса разработки.
Тут надо вспомнить, что кроме требований заказчика в рамках конкретной работы всегда есть требования других заинтересованных сторон. И хотя заказчик фиксирует свои требования, подписывая ТЗ, требования других сторон остаются плавающими. Последний пример. Делаем вторую версию нашей системы. Первая находится в проме, и на ней возникает сбой. Исправления нужно учесть в новой версии, но модель предметной области в ней поменялась, и простой мерж двух веток кода не проходит. Возникает дополнительная задача с высоким приоритетом, и она возникает вне проекта разработки второй версии. Т.к. интересы заказчика представляет в нашем процессе архитектор, то с ним и идёт согласование каждой итерации. И именно он вносит новую задачу, меняя требования.
Ну, не совсем обучающий материал. Скорее, ликбез. И я бы сказал, самопродвижение.
Мне бы хотелось увидеть практику применения таких договоров. Ведь бес всегда сидит в деталях.
И ещё я бы добавил в самое начало пункт «Посмотреть на сайте производителя системы список известных проблем (если он предоставляет такие сведения): возможно, решение проблемы уже известно.»
Соответственно:
Придерживайтесь фактов и отбросьте эмоции.
Если проблема решена — поблагодарите того, кто вам помог. Люди обрабатывают десятки запросов в день и перегружены негативным обращением. Сделайте им приятное.
Лишние эмоции, конечно, вредны. Но не только отрицательные. Важно минимизировать поток информации и обеспечить возможность для быстрого нахождения полезной информации. В идеале, минимум вежливости («Добрый день» в начале и «Спасибо» в конце исходного текста запроса) и всё остальное — только фактическое описание проблемы.
И никакой благодарности в ответ на решение конкретного запроса! Такая благодарность только отвлекает и без того загруженных специалистов техподдержки. Приятно, конечно, когда тебе говорят спасибо. Но лучше не в ответ на решение проблемы: когда таких сообщений сотни в день, это уже не так приятно и можно запросто пропустить что-то важное. Ведь такая благодарность изначально воспринимается, как новый запрос или возобновление уже решённого. Мы специально пишем заказчикам, чтобы они не отвечали на наш ответ, если проблема успешно решена.
Лучше по результатам квартала отправьте благодарственное письмо на имя руководителя организации, осуществляющей качественную техподдержку. Одно!
Есть несколько минусов работы с аутсорсерами, которые проявляются на практике.
Прежде всего, это контроль применяемых решений и технологий. Допустим, бизнес привлекает аутсорсеров к созданию некоторой системы. Аутсорсеры выполняют работу. Бизнес получает работающую систему, но не получает знаний о том, как она реализована. После этого бизнес и аутсорсеры расходятся, и бизнес, не знающий тонкостей реализации, вынужден платить минимум вдвое больше за сопровождение системы, поскольку требуется сначала провести дорогостоящий анализ кода для диагностики, и лишь потом исправить ошибку. Как в старом анекдоте: $1 за ремонт и $99 за знание того, где ударить.
Во-вторых, аутсорсерам редко доверяют критические участки кода или код, который реализует закрытые технологии. Это ведёт к тому, что аутсорсеры чаще занимаются типовыми задачами, лежащими на поверхности, но совершенно не имеют знаний о том, как работают применяемые ими фрейворки и компоненты. Недавно один менеджер — представитель аутсорсинговой компании вещал мне, что разработчику совсем необязательно знать работу сборщика мусора в .NET. Увы, это не исключение, а правило.
В-третьих, в аутсорсинговых компаниях большая текучка кадров. Элементарно, программисты хотят расти, а не заниматься вечно одними и теми же задачами. И уходят они в самый разгар проекта, вы не можете ни предвидеть это, ни отсрочить. А с разработчиком уходит и часть знаний о проекте (вот только не надо говорить, что разработчик обязан документировать каждый свой чих в проекте — в теории звучит красиво, на практике платить за это никто не хочет).
Итого, аутсорсинг имеет большие ограничения, о которых автор не сказал.
Бьёрн Страуструп: «Язык программирования служит двум связанным между собой целям: он является выразительным средством программиста для указания действий, которые надо выполнить, а также набором концепций, которыми пользуется программист при решении проблемы.»
Нет, им не стыдно. Это я как физик говорю. Просто их программы настолько специфичны, что представляют интерес только для узкого круга их коллег. А вылизаны проги, действительно, до мельчайших деталей. Иначе расчёты просто не сходятся.
Любая система, зависящая от человеческой надежности, ненадежна.
То же самое касается ORM. ORM стуканёт. Вопрос только в том, при каких обстоятельствах это произойдёт и какой ущерб это принесёт. И если система, использующая ORM, спроектирована с учётом этих моментов, эта система может быть надёжнее самой ORM. А если нет, то чей-то бизнес оказывается в прямой зависимости от чужого кода.
Развитие ORM — вещь неизбежная, и не скажу, что это плохо. Но я всё же пойду и разберусь, как эти новые штуки работают изнутри, и заставлю своих проггеров выучить sql. Чтобы, когда ORM стуканёт на каком-то запросе, мы могли быстро поставить заплатку. А когда стуканёт у Вас, мы могли с этого поиметь ещё и дополнительную денюжку.
Я не сказал, что продвинутые инструменты — это плохо. Я сказал, что трудозатраты не стали меньше, они перераспределились: вместо того, чтобы возиться с памятью, программист теперь учит, что такое управляемый код, как работает GC и как его приручить, чтобы программа работала оптимально. При этом пониманием того, как выделяется память при работе программы, программист всё равно должен обладать. Т.е. вместо того, чтобы тратить время и силы на поиск уязвимостей в своём коде и учиться писать свой код правильно, программист теперь тратит время и силы на получение кучи дополнительных знаний и навыков, а потом ищет уязвимости и в своём коде, и в коде фреймворка.
Для молодого программиста, работающего в небольшом проекте, выигрыш от использования сторонних решений вполне себе ощутим: он не умеет писать собственный оптимальный код, а используемый фреймворк на его задачах не рушится. Для бизнеса тоже сторонние решения выгодны: можно привлекать менее квалифицированный персонал, можно полагаться на протестированные за чужой счёт решения. Но всё это — тоже абстракция от реальности, и рано или поздно такая абстракция начинает рушиться.
Я знал программистов, которые писали на Delphi, и когда пришёл .NET, они не смогли найти себе хорошее место работы, поскольку не понимали разницы в абстракциях Delphi и C#. И я знаю проекты, которые программисты не смогли в нужный момент перевести с Delphi на C#, из-за чего бизнес их владельцев серьёзно пострадал.
Инструменты и сторонние решения — это хорошо, но с существенными ограничениями.
Я наблюдал развитие средств разработки последние два десятка лет. И меня не покидает смутное сомнение. Средства разработки становятся «как бы проще»: не надо выделять память и потом следить за её освобождением, не надо думать, на что указывает указатель, не надо даже скобки расставлять… Но вот объём знаний, который должен иметь разработчик, чтобы сделать действительно серьёзный продукт, от этого нисколько не уменьшается. И даже наоборот, растёт чуть ли не по экспоненте. Каждая среда разработки, каждый фреймворк вносят свои абстракции, и на первый взгляд всё работает. Но наступает момент, когда абстракция начинает трещать по всем швам. И тогда приходится лезть в глубины того же фреймворка и смотреть, что у него не так с той же памятью, с теми же указателями…
Т.е. простота и удобство инструментария не отменяет знаний глубин взаимодействия софта и железа.
И по мере того, как эта истина проявлялась, возникал вопрос: почему? Моё ощущение, что разработчики сред разработки в определённый момент начали гонку за студентами и топ-менеджерами, приучая их именно к своему детищу. Когда я был студентом, были популярны C++ и Delphi. Потом стала набирать популярность Java, потом появился C#. Как бизнес набросился на RAD-разработку! Это же целый прорыв: за мизерные деньги можно было сделать свой http-сервер! И как потом бизнес-сообщество приняло .NET!..
Семя упало в плодородную почву, «простые» фреймворки заполонили головы молодёжи и топ-менеджеров. И теперь программисты должны учить не только выполнение машинного кода ядром процессора и распределение байтов в регистрах памяти, но и уйму информации о функциях используемых ими библиотек, а потом ещё и оправдываться за то, что эти библиотеки не работают так, как хотелось бы бизнесу… Как говорил Стив Балмер, «у нас не монополия, у нас рынок, а это не одно и то же».
Конечно, это не умаляет достоинства инструментов. Но в целом легче программистам от этого не стало, только трудозатраты перераспределились в сторону «непроизводительной» деятельности по саморазвитию программистов, за которую бизнес теперь не платит.
Уильям Эдвардс Деминг: «Совершенствоваться не обязательно. Выживание — дело добровольное.»
Нужно искать золотую середину. Перфекционизм, конечно, — не здоровая тенденция, но нужно иметь здоровый уровень самокритики, чтобы двигаться вперёд. Это особенно тяжело, когда от тебя такого движения никто из окружающих не ждёт.
Я не вижу ничего плохого в том, чтобы стремиться к идеалу, если это стремление правильным образом спланировано и организовано. Я вижу свою цель, я знаю свои недостатки, я знаю, как сделать первые шаги. И после каждого шага мне, возможно, станет виден мой путь ещё на один шаг.
boblenin, не надо передёргивать. Я сказал, что архитектуру «нужно начинать продумывать уже на стадии формирования концепции продукта.» Но не сказал, что на стадии концепции работа над архитектурой заканчивается. Основная работа проводится, когда основные функциональные требования становятся известны. Как было указано в приведённой мной выше цитате, «важно, особенно при проектировании и разработке по гибкому процессу, чтобы итерация включала как проектирование архитектуры, так и разработку реализации». И это — на каждой итерации.
Спринт одной системы отличается от спринта другой системы. В том числе и по масштабу. Всё, что выполнено в рамках спринта, должно быть проверено. Если количество нового/изменённого кода было много или/и были затронуты многие компоненты, тестирование может быть весьма серьёзной задачей. Проще и дешевле подумать до того, как отрезать, чем пытаться пришить отрезанное.
И ещё раз, тестирование — это подход к контролю качества, а не способ его обеспечения.
От tutorial'а для молодых коллег ожидал четко сформулированных задач, которые должна решать будущая система, и список требований, которым должна удовлетворять будущая система.
Это полная цитата. Так что вопрос переадресуйте автору комментария.
Цель статьи — не разработка электронного дневника. Её цель — показать, с чего и как можно начать проектировать систему. Соответственно, пример, приведённый в статье, — всего лишь иллюстрация. Если бы я начал погружаться в детали, потерялась бы основная идея.
Если вас волнует вопрос о концепции самого дневника, предметной областью я владею с разных сторон. Бизнес-логику в БД в данном случае засунуть не удастся.
когда архитектура создается малой кровью, большая кровь появляется на этапе реализации и сопровождения.
Если подходить академически к вопросу, то согласен полностью. Но если со стороны реальности, то получается «как всегда», увы. И эта ситуация не всегда зависит от нас. Хотя да, архитектору надо стремиться к самосовершенствованию и быстро переходить из стадии выживания в стадию стабильного развития.
Отдавать проектировать систему человеку, у которого для этого недостаточно знаний? И нет времени на самообучение?
lair, если подходить к вопросу академически, Вы правы. Но реальность, как всегда, шире и глубже.
Вот пришёл ко мне юный архитектор, вроде как образование профильное и всё такое. Но на практике с разработкой архитектуры он в вузе не сталкивался. Что, снова его послать учить? Не работает. Надо натаскивать на практику в боевых условиях. Мой подход в этом случае работает и помогает человеку быстро войти в работу. Уже через пару часов у него есть первый макет архитектуры, и можно с ним говорить о более глубоких деталях.
А в соседнем отделе начальство… дало программисту (даже не ведущему) проектировать систему. Приходит ко мне, типа «как быть». Что, послать его учиться? Да его уволят, хотя, заметьте, не он виноват. Поэтому я даю ему маленький толчок, как начать работу. И дальше он может работать со справочниками типа того же Руководства MS, и задавать вопросы мне, Вам или кому-то ещё из опытных коллег. Это работает. А когда цейтнот спадёт, тогда уже можно послать парня учиться.
А зачем? Обычно к книгам по архитектуре приходят люди, которые и так знают, зачем им это надо. А тех, кто не знает. может, лучше и не заинтересовывать?
Не совсем так. Жизнь сложнее. Вот простой пример, когда спроектировать систему нужно (например, руководство отдало приказ программисту), а знаний не достаточно. На то, чтобы читать книги и аккуратно всё применять на практике, времени в этом случае нет. И что парню в этом случае делать? Ему архитектура, может, и не интересна, но работу надо делать. А Вы, вместо того, чтобы ему помочь, предлагаете ему пойти подальше. Нехорошо. Я предложил свой путь решения: быстро набросать схему и воспользоваться Руководством MS, написанным в виде справочника (т.е. не обязательно его читать с самого начала). Методологически моё решение закончено.
Тут надо вспомнить, что кроме требований заказчика в рамках конкретной работы всегда есть требования других заинтересованных сторон. И хотя заказчик фиксирует свои требования, подписывая ТЗ, требования других сторон остаются плавающими. Последний пример. Делаем вторую версию нашей системы. Первая находится в проме, и на ней возникает сбой. Исправления нужно учесть в новой версии, но модель предметной области в ней поменялась, и простой мерж двух веток кода не проходит. Возникает дополнительная задача с высоким приоритетом, и она возникает вне проекта разработки второй версии. Т.к. интересы заказчика представляет в нашем процессе архитектор, то с ним и идёт согласование каждой итерации. И именно он вносит новую задачу, меняя требования.
Мне бы хотелось увидеть практику применения таких договоров. Ведь бес всегда сидит в деталях.
Лишние эмоции, конечно, вредны. Но не только отрицательные. Важно минимизировать поток информации и обеспечить возможность для быстрого нахождения полезной информации. В идеале, минимум вежливости («Добрый день» в начале и «Спасибо» в конце исходного текста запроса) и всё остальное — только фактическое описание проблемы.
И никакой благодарности в ответ на решение конкретного запроса! Такая благодарность только отвлекает и без того загруженных специалистов техподдержки. Приятно, конечно, когда тебе говорят спасибо. Но лучше не в ответ на решение проблемы: когда таких сообщений сотни в день, это уже не так приятно и можно запросто пропустить что-то важное. Ведь такая благодарность изначально воспринимается, как новый запрос или возобновление уже решённого. Мы специально пишем заказчикам, чтобы они не отвечали на наш ответ, если проблема успешно решена.
Лучше по результатам квартала отправьте благодарственное письмо на имя руководителя организации, осуществляющей качественную техподдержку. Одно!
Прежде всего, это контроль применяемых решений и технологий. Допустим, бизнес привлекает аутсорсеров к созданию некоторой системы. Аутсорсеры выполняют работу. Бизнес получает работающую систему, но не получает знаний о том, как она реализована. После этого бизнес и аутсорсеры расходятся, и бизнес, не знающий тонкостей реализации, вынужден платить минимум вдвое больше за сопровождение системы, поскольку требуется сначала провести дорогостоящий анализ кода для диагностики, и лишь потом исправить ошибку. Как в старом анекдоте: $1 за ремонт и $99 за знание того, где ударить.
Во-вторых, аутсорсерам редко доверяют критические участки кода или код, который реализует закрытые технологии. Это ведёт к тому, что аутсорсеры чаще занимаются типовыми задачами, лежащими на поверхности, но совершенно не имеют знаний о том, как работают применяемые ими фрейворки и компоненты. Недавно один менеджер — представитель аутсорсинговой компании вещал мне, что разработчику совсем необязательно знать работу сборщика мусора в .NET. Увы, это не исключение, а правило.
В-третьих, в аутсорсинговых компаниях большая текучка кадров. Элементарно, программисты хотят расти, а не заниматься вечно одними и теми же задачами. И уходят они в самый разгар проекта, вы не можете ни предвидеть это, ни отсрочить. А с разработчиком уходит и часть знаний о проекте (вот только не надо говорить, что разработчик обязан документировать каждый свой чих в проекте — в теории звучит красиво, на практике платить за это никто не хочет).
Итого, аутсорсинг имеет большие ограничения, о которых автор не сказал.
Вот, целый ворох:
ссылка
ссылка
ссылка
Хотя понятие качества у них, конечно, своё.
Видимо, Вы на практике ещё не сталкивались с разрушением дисковой памяти. Это хорошо, и я искренне рад за Вас. Но вот только недавно Хакер.ру писал о надёжности SSD: SSD могут терять данные через 7 дней после обесточивания.
Есть замечательный закон Джилба:
То же самое касается ORM. ORM стуканёт. Вопрос только в том, при каких обстоятельствах это произойдёт и какой ущерб это принесёт. И если система, использующая ORM, спроектирована с учётом этих моментов, эта система может быть надёжнее самой ORM. А если нет, то чей-то бизнес оказывается в прямой зависимости от чужого кода.
Для молодого программиста, работающего в небольшом проекте, выигрыш от использования сторонних решений вполне себе ощутим: он не умеет писать собственный оптимальный код, а используемый фреймворк на его задачах не рушится. Для бизнеса тоже сторонние решения выгодны: можно привлекать менее квалифицированный персонал, можно полагаться на протестированные за чужой счёт решения. Но всё это — тоже абстракция от реальности, и рано или поздно такая абстракция начинает рушиться.
Я знал программистов, которые писали на Delphi, и когда пришёл .NET, они не смогли найти себе хорошее место работы, поскольку не понимали разницы в абстракциях Delphi и C#. И я знаю проекты, которые программисты не смогли в нужный момент перевести с Delphi на C#, из-за чего бизнес их владельцев серьёзно пострадал.
Инструменты и сторонние решения — это хорошо, но с существенными ограничениями.
Т.е. простота и удобство инструментария не отменяет знаний глубин взаимодействия софта и железа.
И по мере того, как эта истина проявлялась, возникал вопрос: почему? Моё ощущение, что разработчики сред разработки в определённый момент начали гонку за студентами и топ-менеджерами, приучая их именно к своему детищу. Когда я был студентом, были популярны C++ и Delphi. Потом стала набирать популярность Java, потом появился C#. Как бизнес набросился на RAD-разработку! Это же целый прорыв: за мизерные деньги можно было сделать свой http-сервер! И как потом бизнес-сообщество приняло .NET!..
Семя упало в плодородную почву, «простые» фреймворки заполонили головы молодёжи и топ-менеджеров. И теперь программисты должны учить не только выполнение машинного кода ядром процессора и распределение байтов в регистрах памяти, но и уйму информации о функциях используемых ими библиотек, а потом ещё и оправдываться за то, что эти библиотеки не работают так, как хотелось бы бизнесу… Как говорил Стив Балмер, «у нас не монополия, у нас рынок, а это не одно и то же».
Конечно, это не умаляет достоинства инструментов. Но в целом легче программистам от этого не стало, только трудозатраты перераспределились в сторону «непроизводительной» деятельности по саморазвитию программистов, за которую бизнес теперь не платит.
Нужно искать золотую середину. Перфекционизм, конечно, — не здоровая тенденция, но нужно иметь здоровый уровень самокритики, чтобы двигаться вперёд. Это особенно тяжело, когда от тебя такого движения никто из окружающих не ждёт.
Я не вижу ничего плохого в том, чтобы стремиться к идеалу, если это стремление правильным образом спланировано и организовано. Я вижу свою цель, я знаю свои недостатки, я знаю, как сделать первые шаги. И после каждого шага мне, возможно, станет виден мой путь ещё на один шаг.
Спринт одной системы отличается от спринта другой системы. В том числе и по масштабу. Всё, что выполнено в рамках спринта, должно быть проверено. Если количество нового/изменённого кода было много или/и были затронуты многие компоненты, тестирование может быть весьма серьёзной задачей. Проще и дешевле подумать до того, как отрезать, чем пытаться пришить отрезанное.
И ещё раз, тестирование — это подход к контролю качества, а не способ его обеспечения.
Пожалуйста.
Это полная цитата. Так что вопрос переадресуйте автору комментария.
Если вас волнует вопрос о концепции самого дневника, предметной областью я владею с разных сторон. Бизнес-логику в БД в данном случае засунуть не удастся.
Если подходить академически к вопросу, то согласен полностью. Но если со стороны реальности, то получается «как всегда», увы. И эта ситуация не всегда зависит от нас. Хотя да, архитектору надо стремиться к самосовершенствованию и быстро переходить из стадии выживания в стадию стабильного развития.
lair, если подходить к вопросу академически, Вы правы. Но реальность, как всегда, шире и глубже.
Вот пришёл ко мне юный архитектор, вроде как образование профильное и всё такое. Но на практике с разработкой архитектуры он в вузе не сталкивался. Что, снова его послать учить? Не работает. Надо натаскивать на практику в боевых условиях. Мой подход в этом случае работает и помогает человеку быстро войти в работу. Уже через пару часов у него есть первый макет архитектуры, и можно с ним говорить о более глубоких деталях.
А в соседнем отделе начальство… дало программисту (даже не ведущему) проектировать систему. Приходит ко мне, типа «как быть». Что, послать его учиться? Да его уволят, хотя, заметьте, не он виноват. Поэтому я даю ему маленький толчок, как начать работу. И дальше он может работать со справочниками типа того же Руководства MS, и задавать вопросы мне, Вам или кому-то ещё из опытных коллег. Это работает. А когда цейтнот спадёт, тогда уже можно послать парня учиться.
Не совсем так. Жизнь сложнее. Вот простой пример, когда спроектировать систему нужно (например, руководство отдало приказ программисту), а знаний не достаточно. На то, чтобы читать книги и аккуратно всё применять на практике, времени в этом случае нет. И что парню в этом случае делать? Ему архитектура, может, и не интересна, но работу надо делать. А Вы, вместо того, чтобы ему помочь, предлагаете ему пойти подальше. Нехорошо. Я предложил свой путь решения: быстро набросать схему и воспользоваться Руководством MS, написанным в виде справочника (т.е. не обязательно его читать с самого начала). Методологически моё решение закончено.
Если у Вас есть своё решение, предложите его.