В Минске пройдет семинар по TDD.
Посмотрел программу, лично меня не впечатлило.
Но кто впервые с этим сталкивается и на данный момент считает, что TDD - это просто некая мода - тому посетить нужно.
Лично я применял TDD, хотя и в ограниченном виде. Как методологию разработки для многих проектов - оцениваю как полезную.
Все принципы полезности выводятся из самого подхода к разработке. А подход, самый правильный, такой:
1) Use cases и фиксация багов. Отображаются в софте с он-лайн доступом. Когда вы можете продемонстрировать своим акционерам или просто начальству (финансирующему вас) - как у вас что движется - это большое дело. Не нужно размахивать руками и говорить как много вы сделали - покажите список выполненных фич и закрытых багов. Директор или акционеры, или сообщество - может/могут провести независимый аудит - как вам что удается. Важность отчетности, как результатов работы - нельзя не переоценить. Вы сможете потом вздохнуть спокойно или апеллировать ко мнению независимых технических специалистов. На этой отчетности вскроются все недостатки ваших проект-менеджеров (почему в первую очередь делаются второстепенные фичи? почему с марта по июль у вас закрыто только 2 бага - что, ушло 3 разработчика, может это проект-менеджер конфликтный, давайте разбираться), вскроется - чем руководствовался исполнительный директор, нанимая проект-менеджеров, равнозначно ли учитываются мнения "бизнес-стороны" (топ-менеджеров, акционеров) и технических специалистов (тим-лид, архитектор, разработчики). Не бывает безсбойной работы - сбои обеспечены. Но если вашему директору глубоко все равно, что творится со списком use cases - значит "рыба гниет с головы" - расслабьтесь и получайте удовольствие - причина всех дедлайнов и мата - не в вас. Но чтобы апеллировать к чему-то (на одной фирме, где я работал - приехал акционер, разобраться, почему сбиваются сроки) - вы должны вести отчетность. Вы тогда сможете всегда доказать. Это - ваш гарант спокойной жизни. Пускай ваш проект-менеджер висит по пол дня в соц. сетях и аськах - главное, чтобы вы вели отчетность, показывающую ВАШУ работу, реальную работу. С этой точки зрения - вам потом по-боку будет удаленная работа - вы каждый день сможете присылать отчеты, и по результатам месяца - из ваших отправленных e-mail-ов - создавать консолидированный отчет - что вы сделали за месяц. Пускай на фирме есть любимчики - вам это по боку, В СЛУЧАЕ ЕСЛИ ВЫ ВЕДЕТЕ ОТЧЕТНОСТЬ. Ваш директор не акцентирует на этом внимание, что нужно вести - ведите сами. Когда вас позовут "на ковер" из-за того, что кто-то где-то по сроками или чему еще завалил - вам достаточно будет собрать ваши отчеты за нужный период. Списки фич закрывались? Баги закрывались? 10 штук в июне, 14 штук в июле, в августе у вас был отпуск? - Покажите свой отчет, пришлите директору "консолидированный" e-mail с этой информацией. Директор абсолютно не в курсе, что вы делали и делали ли - убедите фактами. Есть факты - вопросы будут к другим.
2) Тесты в TDD помогают продемонстрировать выполнение фич и закрытие багов из п.1. Они придают вашей отчетности в этом - новое значение - независимые разработчики, использующие ваш API - могут с каждой вашей ревизией в SVN - видеть - закрыты ли баги, фичи и протестировать свои дополнения к вашему продукту - будут ли с их прибамбасами выполняться ваши тесты.
3) Тесты для каждодневно изменяющегося GUI - напрасный расход ресурсов. Директору очень хочется - пускай нанимает отдельного тестировщика под GUI. Есть у него финансирование для этого дела - его право. Нет - вы будете 2/3 времени тратить на тесты, завалите список фич. Объясните директору - что вы будет работать в 3 раза медленнее из-за этого. Если он согласен - потом к январю, когда его возьмут за жабры акционеры - перешлите ВАШ E-MAIL, в котором вы информировали его об этом (и его ответ). Крайним должен быть он, по определению. ;)
4) И еще раз п.1. Если не понимаете, что вам платят представители бизнеса и что им постоянно нужна отчетность - попробуйте заняться изучением экономики. Не бывает сферического разработчика, занятого каким-то программированием в себе. Кому-то будет делегирована функция (проект-менеджеру) - проверять, как тратятся чужие деньги за ваш труд. Но т.к. проект-менеджер может быть ленивым, директор - дураком и подлецом - ведите отчетность. "Умоете" всех и надолго. Вот - ваше место и роль в данной точке пространства и времени. Если вам кто-то что-то спускает - не расслабляйтесь. В другой фирме вас возьмут "за жабры", выработайте правильный подход изначально.
:)
Посмотрел программу, лично меня не впечатлило.
Но кто впервые с этим сталкивается и на данный момент считает, что TDD - это просто некая мода - тому посетить нужно.
Лично я применял TDD, хотя и в ограниченном виде. Как методологию разработки для многих проектов - оцениваю как полезную.
Все принципы полезности выводятся из самого подхода к разработке. А подход, самый правильный, такой:
1) Use cases и фиксация багов. Отображаются в софте с он-лайн доступом. Когда вы можете продемонстрировать своим акционерам или просто начальству (финансирующему вас) - как у вас что движется - это большое дело. Не нужно размахивать руками и говорить как много вы сделали - покажите список выполненных фич и закрытых багов. Директор или акционеры, или сообщество - может/могут провести независимый аудит - как вам что удается. Важность отчетности, как результатов работы - нельзя не переоценить. Вы сможете потом вздохнуть спокойно или апеллировать ко мнению независимых технических специалистов. На этой отчетности вскроются все недостатки ваших проект-менеджеров (почему в первую очередь делаются второстепенные фичи? почему с марта по июль у вас закрыто только 2 бага - что, ушло 3 разработчика, может это проект-менеджер конфликтный, давайте разбираться), вскроется - чем руководствовался исполнительный директор, нанимая проект-менеджеров, равнозначно ли учитываются мнения "бизнес-стороны" (топ-менеджеров, акционеров) и технических специалистов (тим-лид, архитектор, разработчики). Не бывает безсбойной работы - сбои обеспечены. Но если вашему директору глубоко все равно, что творится со списком use cases - значит "рыба гниет с головы" - расслабьтесь и получайте удовольствие - причина всех дедлайнов и мата - не в вас. Но чтобы апеллировать к чему-то (на одной фирме, где я работал - приехал акционер, разобраться, почему сбиваются сроки) - вы должны вести отчетность. Вы тогда сможете всегда доказать. Это - ваш гарант спокойной жизни. Пускай ваш проект-менеджер висит по пол дня в соц. сетях и аськах - главное, чтобы вы вели отчетность, показывающую ВАШУ работу, реальную работу. С этой точки зрения - вам потом по-боку будет удаленная работа - вы каждый день сможете присылать отчеты, и по результатам месяца - из ваших отправленных e-mail-ов - создавать консолидированный отчет - что вы сделали за месяц. Пускай на фирме есть любимчики - вам это по боку, В СЛУЧАЕ ЕСЛИ ВЫ ВЕДЕТЕ ОТЧЕТНОСТЬ. Ваш директор не акцентирует на этом внимание, что нужно вести - ведите сами. Когда вас позовут "на ковер" из-за того, что кто-то где-то по сроками или чему еще завалил - вам достаточно будет собрать ваши отчеты за нужный период. Списки фич закрывались? Баги закрывались? 10 штук в июне, 14 штук в июле, в августе у вас был отпуск? - Покажите свой отчет, пришлите директору "консолидированный" e-mail с этой информацией. Директор абсолютно не в курсе, что вы делали и делали ли - убедите фактами. Есть факты - вопросы будут к другим.
2) Тесты в TDD помогают продемонстрировать выполнение фич и закрытие багов из п.1. Они придают вашей отчетности в этом - новое значение - независимые разработчики, использующие ваш API - могут с каждой вашей ревизией в SVN - видеть - закрыты ли баги, фичи и протестировать свои дополнения к вашему продукту - будут ли с их прибамбасами выполняться ваши тесты.
3) Тесты для каждодневно изменяющегося GUI - напрасный расход ресурсов. Директору очень хочется - пускай нанимает отдельного тестировщика под GUI. Есть у него финансирование для этого дела - его право. Нет - вы будете 2/3 времени тратить на тесты, завалите список фич. Объясните директору - что вы будет работать в 3 раза медленнее из-за этого. Если он согласен - потом к январю, когда его возьмут за жабры акционеры - перешлите ВАШ E-MAIL, в котором вы информировали его об этом (и его ответ). Крайним должен быть он, по определению. ;)
4) И еще раз п.1. Если не понимаете, что вам платят представители бизнеса и что им постоянно нужна отчетность - попробуйте заняться изучением экономики. Не бывает сферического разработчика, занятого каким-то программированием в себе. Кому-то будет делегирована функция (проект-менеджеру) - проверять, как тратятся чужие деньги за ваш труд. Но т.к. проект-менеджер может быть ленивым, директор - дураком и подлецом - ведите отчетность. "Умоете" всех и надолго. Вот - ваше место и роль в данной точке пространства и времени. Если вам кто-то что-то спускает - не расслабляйтесь. В другой фирме вас возьмут "за жабры", выработайте правильный подход изначально.
:)
Комментариев нет:
Отправить комментарий