Основная особенность наших разработчиков:
http://habrahabr.ru/post/185638/
http://habrahabr.ru/post/185638/
Показаны сообщения с ярлыком организация труда. Показать все сообщения
Показаны сообщения с ярлыком организация труда. Показать все сообщения
пятница, 5 июля 2013 г.
среда, 3 июля 2013 г.
Чужая статья. Особенности русской разработки
http://habrahabr.ru/company/scrumtrek/blog/185334/
Процитирую немного:
P.S. от себя добавлю одну неосторожную вещь, о которой не пишет автор - если у кого-то есть "вопросы" к работе своего менеджера (неважно какого уровня) - это по-русски означает - "стучать". Это - правда. И главное - ДРУГИЕ менеджеры так это и воспримут. И будут правы. На нашей почве.
P.P.S. Завидую людям, которые не "боятся" писать подобные статьи. Ибо это тоже означает "стучать". На нашей почве.
P.P.P.S. В России - только в маленьких конторах есть возможность ощущать "драйв" и "сопричастность". На нашей почве.
P.P.P.P.S. "резать правду матку" и "отгораживаться стеной" - можно с одним и тем же человеком. Вопрос - какую "роль" он в данный момент исполняет. На нашей почве.
Процитирую немного:
Все идет с раннего детства. Так нас воспитывали. И не только двор и школьные приятели. Когда мой старший сын ходил в детский садик, я своими ушами слышал, как воспитательница внушала рыдающему ребенку, который жаловался на толкнувшего его товарища, что ябедничать нехорошо.----
Это тоже часть нашей с вами культуры, обратная сторона нежелания эскалировать проблемы. Мы привыкли давать обратную связь своему товарищу намного более открыто и прямо. Мы не так сильно стесняемся конфликтовать, как наши западные коллеги.----
Наши доверяют людям, доказавшим свое превосходство. И реальные лидеры привыкают принимать решения самостоятельно и никогда не встречают сопротивления.----
Такое общение называется low context. Мы даем мало контекста. Апофеозом для меня было когда-то имейл от админа с одним словом «Да». Что да? Оказывается, я у него спросил что-то в коридоре и он обещал посмотреть.
P.S. от себя добавлю одну неосторожную вещь, о которой не пишет автор - если у кого-то есть "вопросы" к работе своего менеджера (неважно какого уровня) - это по-русски означает - "стучать". Это - правда. И главное - ДРУГИЕ менеджеры так это и воспримут. И будут правы. На нашей почве.
P.P.S. Завидую людям, которые не "боятся" писать подобные статьи. Ибо это тоже означает "стучать". На нашей почве.
P.P.P.S. В России - только в маленьких конторах есть возможность ощущать "драйв" и "сопричастность". На нашей почве.
P.P.P.P.S. "резать правду матку" и "отгораживаться стеной" - можно с одним и тем же человеком. Вопрос - какую "роль" он в данный момент исполняет. На нашей почве.
четверг, 13 июня 2013 г.
Новый коллега тут долго и мучительно искал ошибку в МОЁМ коде
"Новый" коллега тут долго и мучительно искал ошибку в МОЁМ коде. И в итоге - НАШЁЛ. Меня к этому процессу особо не привлекали - ну такое по-моему бывает везде - "мол конечно ты за 5 мин найдёшь, но с одной стороны - у тебя своих задач хватает, а с другой стороны - "пусть парень поиузучает"". А если что мол - "проконсультируешь". Что ХАРАКТЕРНО - "парень" - долго ВДУМЧИВО "курил" исходники, а потом написал мне комментарий, что "мол так и так, проблема в этом". И (как я сейчас понимаю) - комментарий был КРАЙНЕ вдумчив и КОРРЕКТЕН, и при этом описывал проблему ПРАКТИЧЕСКИ ПОЛНОСТЬЮ. Но мне что называется "было недосуг" и я "находился в плену собственных стереотипов" - ГДЕ БЫ эта ошибка могла бы быть. И я направил коллегу по ЛОЖНОМУ следу. Я вывалил на него МАССУ "полезной", но в принципе - НЕ ОТНОСЯЩЕЙСЯ к делу информации. Что мол - "я бы копал бы там-то и там-то". Что характерно - никакой "стены отчуждения", или нежелания помочь - не было. Мы потом не раз эту проблему обсуждали устно в курилке. С интересом. И всё дальше и дальше я направлял коллегу по ЛОЖНОМУ ПУТИ.
Потом - "СЛУЧИЛОСЬ ЧУДО". Мы вернулись на новый виток. Коллега был вдумчив и упорен. И на НОВОМ ВИТКЕ он мне написал СВОЙ ПЕРВЫЙ КОММЕНТАРИЙ. Ну СЛОВО В СЛОВО. Я его прочитал ВНИМАТЕЛЬНО и сказал - "ну вот же в чём проблема"! "Чего ж" ты мол раньше молчал! Вот "в этом" и "этом". И проблема - решилась.
Я правда потом (случайно) - перечитал самый ПЕРВЫЙ комментарий. И осознал, что там написано - РОВНО ТО ЖЕ САМОЕ. Что и в том комментарии, который РЕШИЛ проблему.
Мне стало даже "стыдно". За то что, что попусту потратил чужое время.
Я даже сказал коллеге об этом. Правда услышал в ответ - "зато я столько интересного узнал". И это кстати - правда. Может быть это конечно и к лучшему. Но к ДАННОЙ КОНКРЕТНОЙ проблеме это НЕ ОТНОСИЛОСЬ.
И вопрос КОММУНИКАЦИЙ (свой "резкий" стиль я - опущу, я - работаю на этим) и ПЕРЕДАЧИ знаний - как мучала меня ещё лет 10-ть назад - так и мучает. Непонятно, что с этим делать. Другие коллеги говорят - "пиши документацию". Я правда спрашиваю - "какую именно" и на этом обычно разговор - заканчивается. Потому что ответ - обычно не находится. Документов то - МНОГО. Но на КОНКРЕТНЫЕ сиюминутные вопросы - НЕПОНЯТНО как там найти ответ.
Но! в Этом КОНКРЕТНОМ случае - мне коллега сказал - "я почитал документацию. Там "почти" всего хватает". "Хорошая документация" - сказал он. Ну как-то так. При том, что эту документацию как раз НЕ Я писал. Мне тут "гордится" нечем. Я как раз там просил других коллег написать - как ОНИ это понимают. Ну чтобы не было такого - "ну тут всё понятно..."
И ВСЁ РАВНО - я НЕ ПОНИМАЮ - как передавать знания и как правильно читать чужие комментарии, в которых УЖЕ СОДЕРЖИТСЯ ответ.
Если я ОДИН такой - это пол-беды. Но что-то мне подсказывает, что это проблема ОТРАСЛИ.
Извините, если отвлёк ваше внимание без дела.
P.S. Другой коллега. Правда уже бывший. Прочитав сей пост спросил - "ну и долго ты его по-ложному следу водил?" Это он тоже кстати "не со зла" :-) Просто - УДИВИЛСЯ.
Потом - "СЛУЧИЛОСЬ ЧУДО". Мы вернулись на новый виток. Коллега был вдумчив и упорен. И на НОВОМ ВИТКЕ он мне написал СВОЙ ПЕРВЫЙ КОММЕНТАРИЙ. Ну СЛОВО В СЛОВО. Я его прочитал ВНИМАТЕЛЬНО и сказал - "ну вот же в чём проблема"! "Чего ж" ты мол раньше молчал! Вот "в этом" и "этом". И проблема - решилась.
Я правда потом (случайно) - перечитал самый ПЕРВЫЙ комментарий. И осознал, что там написано - РОВНО ТО ЖЕ САМОЕ. Что и в том комментарии, который РЕШИЛ проблему.
Мне стало даже "стыдно". За то что, что попусту потратил чужое время.
Я даже сказал коллеге об этом. Правда услышал в ответ - "зато я столько интересного узнал". И это кстати - правда. Может быть это конечно и к лучшему. Но к ДАННОЙ КОНКРЕТНОЙ проблеме это НЕ ОТНОСИЛОСЬ.
И вопрос КОММУНИКАЦИЙ (свой "резкий" стиль я - опущу, я - работаю на этим) и ПЕРЕДАЧИ знаний - как мучала меня ещё лет 10-ть назад - так и мучает. Непонятно, что с этим делать. Другие коллеги говорят - "пиши документацию". Я правда спрашиваю - "какую именно" и на этом обычно разговор - заканчивается. Потому что ответ - обычно не находится. Документов то - МНОГО. Но на КОНКРЕТНЫЕ сиюминутные вопросы - НЕПОНЯТНО как там найти ответ.
Но! в Этом КОНКРЕТНОМ случае - мне коллега сказал - "я почитал документацию. Там "почти" всего хватает". "Хорошая документация" - сказал он. Ну как-то так. При том, что эту документацию как раз НЕ Я писал. Мне тут "гордится" нечем. Я как раз там просил других коллег написать - как ОНИ это понимают. Ну чтобы не было такого - "ну тут всё понятно..."
И ВСЁ РАВНО - я НЕ ПОНИМАЮ - как передавать знания и как правильно читать чужие комментарии, в которых УЖЕ СОДЕРЖИТСЯ ответ.
Если я ОДИН такой - это пол-беды. Но что-то мне подсказывает, что это проблема ОТРАСЛИ.
Извините, если отвлёк ваше внимание без дела.
P.S. Другой коллега. Правда уже бывший. Прочитав сей пост спросил - "ну и долго ты его по-ложному следу водил?" Это он тоже кстати "не со зла" :-) Просто - УДИВИЛСЯ.
Совсем не Offtopic. Чужая ссылка. Мда...
"Чему я научился за 8 месяцев в Microsoft":
http://habrahabr.ru/post/183130/
P.S. постараюсь быть осторожным. Если и вправду в MS - ТАК, как ТАМ написано, то МНОГИЕ компании (Российские), которые я видел (и в частности и та в которой я работаю) - для меня как для разработчика - СИЛЬНО ПРИВЛЕКАТЕЛЬНЕЕ. Ну или ДЕЙСТВИТЕЛЬНО у MS - проблема МАСШТАБА?
http://habrahabr.ru/post/183130/
P.S. постараюсь быть осторожным. Если и вправду в MS - ТАК, как ТАМ написано, то МНОГИЕ компании (Российские), которые я видел (и в частности и та в которой я работаю) - для меня как для разработчика - СИЛЬНО ПРИВЛЕКАТЕЛЬНЕЕ. Ну или ДЕЙСТВИТЕЛЬНО у MS - проблема МАСШТАБА?
среда, 12 июня 2013 г.
Ссылка на хорошую статью про делегирование
Ссылка на хорошую статью про делегирование полномочий:
http://mnikitin.ru/%D0%B4%D0%B5%D0%BB%D0%B5%D0%B3%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BB%D0%B8-%D0%B4%D0%B5%D0%BB%D0%B5%D0%B3%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BB%D0%B8-%D0%B4%D0%B0-%D0%BD%D0%B5-%D0%B2%D1%8B%D0%B4%D0%B5/
http://mnikitin.ru/%D0%B4%D0%B5%D0%BB%D0%B5%D0%B3%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BB%D0%B8-%D0%B4%D0%B5%D0%BB%D0%B5%D0%B3%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BB%D0%B8-%D0%B4%D0%B0-%D0%BD%D0%B5-%D0%B2%D1%8B%D0%B4%D0%B5/
понедельник, 10 июня 2013 г.
Offtopic.Прочитал тут в одном ТЗ....
НЕ НАШЕМ...
"Это сделать - КРАЙНЕ важно".... За подписью "и выше и выше"...
Только один вопрос МЕНЯ волнует - а "что всё остальное ТАК не важно"?
ТО ЕСТЬ... Бывают ТЗ ВАЖНЫЕ.. А бывают "просто так"?
"Это сделать - КРАЙНЕ важно".... За подписью "и выше и выше"...
Только один вопрос МЕНЯ волнует - а "что всё остальное ТАК не важно"?
ТО ЕСТЬ... Бывают ТЗ ВАЖНЫЕ.. А бывают "просто так"?
суббота, 8 июня 2013 г.
Мне вот интересно
"Как пасти котов"
"Фронтовые очерки"
"Джоэл о программировании"
"Мифический человеко-месяц"
"Роман об управлении проектами"
"Психбольница в руках пациентов"
"Джоэл снова о программировании"
"GoF"
"Применение абстракций и спецификаций в разработке ПО"
-- это вообще в России (!!!) кто-нибудь, кроме "кодеров" читал?
"Фронтовые очерки"
"Джоэл о программировании"
"Мифический человеко-месяц"
"Роман об управлении проектами"
"Психбольница в руках пациентов"
"Джоэл снова о программировании"
"GoF"
"Применение абстракций и спецификаций в разработке ПО"
-- это вообще в России (!!!) кто-нибудь, кроме "кодеров" читал?
суббота, 1 июня 2013 г.
Жёсткая проектная организация на долговременной основе имеет ОДИН БОЛЬШОЙ МИНУС
Жёсткая проектная организация на долговременной основе имеет ОДИН БОЛЬШОЙ МИНУС - люди, да и сами проекты склонны "замыкаться в себе"... и всё что происходит ВОКРУГ они воспринимают как факторы раздражения или белый шум...
если бы меня спросили что делать - я бы активно перемешивал бы людей между проектами..
гораздо проще "послать" некоего абстрактного человека "неизвестно откуда", нежели человека с которым вместе поработал.. и не просто поработал, а вместе решил какие-то конкретные задачи.. и ПУД СОЛИ вместе съел...
да и флаги типа "вы со своим файл-серверным подходом.." в момент бы выкинулись.. потому, что каждый бы ощутил себя в шкуре другого... это касается и "представителей заказчика" (если это конечно не совсем РАЗОВЫЙ проект).. "представители заказчика не должны быть "сбоку" или "над".. они должны быть внутри..
Мне КАЖЕТСЯ - НАДО перемешивать людей между проектами. И между РОЛЯМИ. Чтобы людям было ТРУДНО говорить - "вот я бы на твоём месте.."
Чтобы люди ПОБЫЛИ на ЧУЖОМ месте и были сдержаннее в оценках....
Как-то так...
Каждый "хочет" быть на месте ДРУГОГО, но далеко НЕ КАЖДЫЙ готов к этому...
если бы меня спросили что делать - я бы активно перемешивал бы людей между проектами..
гораздо проще "послать" некоего абстрактного человека "неизвестно откуда", нежели человека с которым вместе поработал.. и не просто поработал, а вместе решил какие-то конкретные задачи.. и ПУД СОЛИ вместе съел...
да и флаги типа "вы со своим файл-серверным подходом.." в момент бы выкинулись.. потому, что каждый бы ощутил себя в шкуре другого... это касается и "представителей заказчика" (если это конечно не совсем РАЗОВЫЙ проект).. "представители заказчика не должны быть "сбоку" или "над".. они должны быть внутри..
Мне КАЖЕТСЯ - НАДО перемешивать людей между проектами. И между РОЛЯМИ. Чтобы людям было ТРУДНО говорить - "вот я бы на твоём месте.."
Чтобы люди ПОБЫЛИ на ЧУЖОМ месте и были сдержаннее в оценках....
Как-то так...
Каждый "хочет" быть на месте ДРУГОГО, но далеко НЕ КАЖДЫЙ готов к этому...
вторник, 21 мая 2013 г.
Offtopic. неКороткая заметка: Почему RUP и "прочие западные практики" не ложатся на российскую почву
http://ru.wikipedia.org/wiki/RUP
Я долго думал об этом.
И не раз ловил себя на мысли, что все "продвинутые западные практики" в БОЛЬШИНСТВЕ своём основаны на "демократизме" и "разговоре на равных". А также на вовлечённости "заказчика" (и прочих заинтересованных лиц, в частности и разработчиков) в процесс.
Так вот сколько я видел в своей практике - У НАС (в России) - такого - НЕТ.
Ну НЕ ЧИТАЮТ заказчики диаграммы. И НЕ ДЕТАЛИЗИРУЮТ требования. НИГДЕ, в России. Я лично - такого не видел. И не участвуют в приёмке.
Заказчиками выступают, либо "сильно занятые люди", либо "очень творческие", которым "не до мелочей".
Я это видел кстати ОЧЕНЬ и ОЧЕНЬ давно, когда писал АРМ для канцелярии полка милиции. Году в 94-м.
УМНЫЕ люди пишут - "надо привлекать к разработке stakeholder'ов и выяснять у них ВСЕ детали, чтобы они становились частью команды разработчиков". Я что-то не так понимаю? Может быть. Но я ТАКОГО в своей практике - НЕ ВИДЕЛ. Stakeholder'ам ИНТЕРЕСНО общаться с разработчиками - ТОЛЬКО пока "идея кипит и брызжет". Как только появляются "тысячи нудных и неудобных мелочных вопросов" - интерес - ПРОПАДАЕТ. Что - ЕСТЕСТВЕННО. Интересно же красить "крупными мазками", а детали.. В деталях же - дьявол зарыт... А он - неинтересен.
Это с одной стороны.
А с другой - все эти практики предполагают "командную работу", когда опять же - ВСЕ ВОВЛЕЧЕНЫ в процесс. И КАЖДЫЙ может чем-то поступиться в угоду общему делу. Но какая командная работа может быть, когда у нас - "каждый второй" - гений (это типа самоирония и сарказм в одном флаконе)? Какое "общее дело", если "я лично это вырастил"?
Code Review и указание на необходимость рефакторинга - "это удар по самолюбию". Именно поэтому я на эти темы в последнее время стараюсь говорить "осторожно" (насколько я вообще способен к такой осторожности).
Да и потом. Мы же можем "писать код без ТЗ вовсе". Не нужны нам такие мелочи как ТЗ. Нам так "интереснее". А ТЗ - "отнимают время". А тесты - "тем более". Знакомо?
То есть с ОДНОЙ стороны - все "западные практики" предполагают некий "демократизм" на этапе ОБСУЖДЕНИЯ, а с другой - "собранность и САМОКОНТРОЛЬ" - на этапе РЕАЛИЗАЦИИ. Ни того, ни другого я в России что-то не наблюдаю.
Я конечно передёргиваю (и никого конкретного не имею в виду). Может кстати и "на западе" так же?
Но я просто пытаюсь передать ОЩУЩЕНИЯ. Возможно я неправ. Как любит говорить один мой знакомый - "с этой мыслью надо переспать"...
Тут ИМЕННО дело в "ощущениях", а не в КОНКРЕТНЫХ фактах.
Просто я читаю книги УМНЫХ людей, а по факту - вижу "всё наоборот". И это (что самое странное) - кажется - ОЧЕНЬ естественным. Мол - "ваши западные практики" - нам не указ.
То ли дело в менталитете, то ли в исторической "тоталитарной системе" (хотя это бред по-моему).
То ли я лично - идеализирую "западные практики".
И я не говорю о той организации в которой работаю я. Я говорю о "настроениях вообще". Я много общаюсь с людьми из других организаций. И вижу, что практики "не ложатся" - не по причинам "непонятости" или "неудобности", а именно по причинам "филосовской" несовместимости.
Разрыв очень большой между "технарями" и "генераторами идей".
В итоге приходится "изобретать свои практики". А может это и правильно... Всё должно расти на СВОЕЙ почве.
P.S. Я думал об это же ещё 17-ть лет назад когда работал в Diasoft. Отчасти поэтому я оттуда и ушёл. Может я чего-то так и не понял...
P.P.S Почему-то многие у нас в стране не готовы к "парадигме конвейера" для программной разработки. Это я вижу по вопросам, которые мне задают. Просто - если "конвейер", то вопрос не может "ждать две недели". Или ТЗ - не проработано. У нас в организации кстати - "конвейер". По большей части. Не без проблем, но всё же...
P.P.P.S Просто например вопросы "а зачем тестирование" - повергают меня лично в шок. Хочется спросить - "а зачем методы поверки в технике"?
P.P.P.P.S Не сочтите кстати, что я "брюзжу" (что мне свойственно). Наоборот. Я пытаюсь конструктивно посмотреть на реалии. И делать из них выводы. Глупо же обижаться на дождь, но можно например взять зонтик.
P.P.P.P.S Кстати - "западные подходы" - на западе то работают?
P.P.P.P.P.S Почему вообще возник этот вопрос? Да потому, что программирование в отличии от техники (http://ru.wikipedia.org/wiki/%D0%9F%D0%BE%D0%B2%D0%B5%D1%80%D0%BA%D0%B0) или фармацевтики (http://ru.wikipedia.org/wiki/Good_Manufacturing_Practice (у меня мама кстати GMP плотно занимается - http://pharmpersonal.ru/publs/statji/arxiv/podgotovka-personala-ne-problema.html http://www.gmp-club.com/ru/about/gratitude.html хотя сейчас уже и не в рамках СКИФ)) - это "изотерика"... Работает - "и ладно" - практика - критерий истины.. Способы поверки - неочевидны... Пока по крайней мере...
На закуску - http://ru.wikipedia.org/wiki/ISO_9000
"Регламенты и инструкции" - МОЖНО написать. Но КАК "заставить" ВСЕХ им следовать? Чтобы не получалось как на "слайде" в начале поста...
Кто-то НЕ ЗАХОЧЕТ в силу своего положения, а кто-то "обидится" - потому что - "гений"..
И главное - КАК не ОШИБИТЬСЯ в НАПРАВЛЕНИИ "куда идти"? Чтобы не получалась "методология ради методологии", а "тесты - ради тестов", а "инструкция - ради галочки"...?
"А "заставишь" - в инструкциях и регламентах ВСЕГО не предусмотришь... И тогда, на любое отступление все будут спрашивать "что делать?"
Я долго думал об этом.
И не раз ловил себя на мысли, что все "продвинутые западные практики" в БОЛЬШИНСТВЕ своём основаны на "демократизме" и "разговоре на равных". А также на вовлечённости "заказчика" (и прочих заинтересованных лиц, в частности и разработчиков) в процесс.
Так вот сколько я видел в своей практике - У НАС (в России) - такого - НЕТ.
Ну НЕ ЧИТАЮТ заказчики диаграммы. И НЕ ДЕТАЛИЗИРУЮТ требования. НИГДЕ, в России. Я лично - такого не видел. И не участвуют в приёмке.
Заказчиками выступают, либо "сильно занятые люди", либо "очень творческие", которым "не до мелочей".
Я это видел кстати ОЧЕНЬ и ОЧЕНЬ давно, когда писал АРМ для канцелярии полка милиции. Году в 94-м.
УМНЫЕ люди пишут - "надо привлекать к разработке stakeholder'ов и выяснять у них ВСЕ детали, чтобы они становились частью команды разработчиков". Я что-то не так понимаю? Может быть. Но я ТАКОГО в своей практике - НЕ ВИДЕЛ. Stakeholder'ам ИНТЕРЕСНО общаться с разработчиками - ТОЛЬКО пока "идея кипит и брызжет". Как только появляются "тысячи нудных и неудобных мелочных вопросов" - интерес - ПРОПАДАЕТ. Что - ЕСТЕСТВЕННО. Интересно же красить "крупными мазками", а детали.. В деталях же - дьявол зарыт... А он - неинтересен.
Это с одной стороны.
А с другой - все эти практики предполагают "командную работу", когда опять же - ВСЕ ВОВЛЕЧЕНЫ в процесс. И КАЖДЫЙ может чем-то поступиться в угоду общему делу. Но какая командная работа может быть, когда у нас - "каждый второй" - гений (это типа самоирония и сарказм в одном флаконе)? Какое "общее дело", если "я лично это вырастил"?
Code Review и указание на необходимость рефакторинга - "это удар по самолюбию". Именно поэтому я на эти темы в последнее время стараюсь говорить "осторожно" (насколько я вообще способен к такой осторожности).
Да и потом. Мы же можем "писать код без ТЗ вовсе". Не нужны нам такие мелочи как ТЗ. Нам так "интереснее". А ТЗ - "отнимают время". А тесты - "тем более". Знакомо?
То есть с ОДНОЙ стороны - все "западные практики" предполагают некий "демократизм" на этапе ОБСУЖДЕНИЯ, а с другой - "собранность и САМОКОНТРОЛЬ" - на этапе РЕАЛИЗАЦИИ. Ни того, ни другого я в России что-то не наблюдаю.
Я конечно передёргиваю (и никого конкретного не имею в виду). Может кстати и "на западе" так же?
Но я просто пытаюсь передать ОЩУЩЕНИЯ. Возможно я неправ. Как любит говорить один мой знакомый - "с этой мыслью надо переспать"...
Тут ИМЕННО дело в "ощущениях", а не в КОНКРЕТНЫХ фактах.
Просто я читаю книги УМНЫХ людей, а по факту - вижу "всё наоборот". И это (что самое странное) - кажется - ОЧЕНЬ естественным. Мол - "ваши западные практики" - нам не указ.
То ли дело в менталитете, то ли в исторической "тоталитарной системе" (хотя это бред по-моему).
То ли я лично - идеализирую "западные практики".
И я не говорю о той организации в которой работаю я. Я говорю о "настроениях вообще". Я много общаюсь с людьми из других организаций. И вижу, что практики "не ложатся" - не по причинам "непонятости" или "неудобности", а именно по причинам "филосовской" несовместимости.
Разрыв очень большой между "технарями" и "генераторами идей".
В итоге приходится "изобретать свои практики". А может это и правильно... Всё должно расти на СВОЕЙ почве.
P.S. Я думал об это же ещё 17-ть лет назад когда работал в Diasoft. Отчасти поэтому я оттуда и ушёл. Может я чего-то так и не понял...
P.P.S Почему-то многие у нас в стране не готовы к "парадигме конвейера" для программной разработки. Это я вижу по вопросам, которые мне задают. Просто - если "конвейер", то вопрос не может "ждать две недели". Или ТЗ - не проработано. У нас в организации кстати - "конвейер". По большей части. Не без проблем, но всё же...
P.P.P.S Просто например вопросы "а зачем тестирование" - повергают меня лично в шок. Хочется спросить - "а зачем методы поверки в технике"?
P.P.P.P.S Не сочтите кстати, что я "брюзжу" (что мне свойственно). Наоборот. Я пытаюсь конструктивно посмотреть на реалии. И делать из них выводы. Глупо же обижаться на дождь, но можно например взять зонтик.
P.P.P.P.S Кстати - "западные подходы" - на западе то работают?
P.P.P.P.P.S Почему вообще возник этот вопрос? Да потому, что программирование в отличии от техники (http://ru.wikipedia.org/wiki/%D0%9F%D0%BE%D0%B2%D0%B5%D1%80%D0%BA%D0%B0) или фармацевтики (http://ru.wikipedia.org/wiki/Good_Manufacturing_Practice (у меня мама кстати GMP плотно занимается - http://pharmpersonal.ru/publs/statji/arxiv/podgotovka-personala-ne-problema.html http://www.gmp-club.com/ru/about/gratitude.html хотя сейчас уже и не в рамках СКИФ)) - это "изотерика"... Работает - "и ладно" - практика - критерий истины.. Способы поверки - неочевидны... Пока по крайней мере...
На закуску - http://ru.wikipedia.org/wiki/ISO_9000
"Регламенты и инструкции" - МОЖНО написать. Но КАК "заставить" ВСЕХ им следовать? Чтобы не получалось как на "слайде" в начале поста...
Кто-то НЕ ЗАХОЧЕТ в силу своего положения, а кто-то "обидится" - потому что - "гений"..
И главное - КАК не ОШИБИТЬСЯ в НАПРАВЛЕНИИ "куда идти"? Чтобы не получалась "методология ради методологии", а "тесты - ради тестов", а "инструкция - ради галочки"...?
"А "заставишь" - в инструкциях и регламентах ВСЕГО не предусмотришь... И тогда, на любое отступление все будут спрашивать "что делать?"
И получим "ручное управление"?"
четверг, 9 мая 2013 г.
Рост инфраструктуры проектов (по нарастанию потребностей)
- Еженедельные архивы исходного кода.
- "Бумажные" диаграммы.
- Ручное тестирование выпусков.
- Соглашение об оформлении кода.
- Подсчёт ссылок на объекты.
- Тестовые наборы "на коленке" и их ручное "протыкивание".
- Code Review.
- CVS
- Инструкция программирования и оформления исходного кода.
- Списки ToDo.
- Логирование ошибок с выводом стека.
- Учимся пользоваться Araxis Merge или его аналогами (jfc, tfc, afc, на худой конец - fc).
- Clear Quest или любая другая "плоская" база ошибок.
- Проверка утечек (в частности через подсчёт ссылок).
- "Ручные" ежедневные отчёты в почте.
- Usecase'ы.
- Документирование исправленных ошибок прямо в коде.
- High Level Test Cases.
- Ночные сборки на bat-файлах.
- "MVC".
- Рефакторинг.
- Сбор логов от пользователей.
- wiki-подобная база знаний и база ошибок.
- "Код у нас общий".
- Code Review в wiki с использованием обсуждений в электронном виде.
- Документирование исправленных ошибок со ссылками на wiki.
- Ночные сборки на продвинутых "скриптах" (например ant) с публикацией отчётов в wiki.
- Автоматизированные ежедневные отчёты в wiki.
- Автоматизированное тестирование чёрного ящика, через GUI (например Test Complete или разные другие роботы).
- Детализация требований.
- Применение шаблонов проектирования от GoF (и не только).
- UML.
- Кодогенерация из UML.
- Соглашения об унифицированной настройке среды.
- Нагрузочное тестирование.
- Проектнозависимые стереотипы для кодогенерации.
- Рефакторинг под влиянием UML.
- Тесты библиотек.
- Стереотипы для тестов.
- Расставлены определённые технологические точки над i с отделом маркетинга.
- Механизм контрольных точек.
- Ежедневные прогоны тестов.
- Рефакторинг при наличии тестов.
- Механизм "эталонов" для тестов.
- Механизм размножения тестов относительно тестовых наборов.
- GUI-тесты.
- Скриптованные тесты.
- Специализированные стереотипы для шаблонов проектирования (например GoF).
- Ежедневные прогоны тестов и их разбор специально выделенными людьми.
- Написание тестов по результатам УЖЕ найденных ошибок, специально выделенными людьми.
- Unit-тестирование.
- Выделение аспектов в примеси.
- Интеграционное тестирование.
- Трассировка требований в тесты.
- Автоматическая публикация новых ошибок и "возрождение" старых вследствие ежедневного прогона тестов после ночной сборки.
среда, 8 мая 2013 г.
Есть на что обратить внимание
http://habrahabr.ru/post/104377/
Называется - "Заповеди молодого разработчика Delphi".
Называется - "Заповеди молодого разработчика Delphi".
четверг, 25 апреля 2013 г.
15. RUMTMARC : Договариваемся с коллегами о порядке коммитов и использовании общих библиотек (AL)
Предыдущая серия была тут - http://18delphi.blogspot.com/2013/04/14-rumtmarc-al.html
Или у нас коллег с общими библиотеками нет? Или с ними УЖЕ всё давно договорено?
Следующая серия - http://18delphi.blogspot.com/2013/04/16-rumtmarc-uml.html
Или у нас коллег с общими библиотеками нет? Или с ними УЖЕ всё давно договорено?
Следующая серия - http://18delphi.blogspot.com/2013/04/16-rumtmarc-uml.html
среда, 24 апреля 2013 г.
1. RUMTMARC : Распределяем роли (AL)
Предыдущая серия была тут - http://18delphi.blogspot.com/2013/04/0-rup-uml-mda-etc-al.html
Пока участников - двое:
AK - Мой товарищ и специалист по сбору требований и работе с заказчиками.
AL - Ваш покорный слуга и ведущий этого блога.
AT - Мой знакомый специалист по тестированию.
Итак. Какие РОЛИ (а не должности) нам понадобятся:
1. Работа с требованиями - AK
2. Работа с заказчиком - AK
3. Аналитик проекта - AK и AL
4. Архитектор - AL
5. Библиотекарь - AL
6. Программист - AL
7. unit-тестировщик - AL
8. gui-тестировщик - AT и AL
9. Технический писатель - AK и AL
10. Аналитик тестирования - AT
Что-то забыл? Пишите!
P.S. если состав ролей или состав участников - будем меняться - мы будем писать про это отдельными постами.
Следующая серия - http://18delphi.blogspot.com/2013/04/2-rumtmarc-al.html
Пока участников - двое:
AK - Мой товарищ и специалист по сбору требований и работе с заказчиками.
AL - Ваш покорный слуга и ведущий этого блога.
AT - Мой знакомый специалист по тестированию.
Итак. Какие РОЛИ (а не должности) нам понадобятся:
1. Работа с требованиями - AK
2. Работа с заказчиком - AK
3. Аналитик проекта - AK и AL
4. Архитектор - AL
5. Библиотекарь - AL
6. Программист - AL
7. unit-тестировщик - AL
8. gui-тестировщик - AT и AL
9. Технический писатель - AK и AL
10. Аналитик тестирования - AT
Что-то забыл? Пишите!
P.S. если состав ролей или состав участников - будем меняться - мы будем писать про это отдельными постами.
Следующая серия - http://18delphi.blogspot.com/2013/04/2-rumtmarc-al.html
воскресенье, 21 апреля 2013 г.
О компьютерных играх и например UML
Когда-то я играл в компьютерные игры. Собственно (как и многие) пришёл от этого к программированию.
И процесс меня захватывал.
Особенно я любил поиграть в "конструкторские" игры типа Цивилизации или SimCity.
А потом - "как отрезало".
Я понял, что лично для меня программировать ГОРАЗДО интереснее.
Тот же UML. Берёшь "список доступных построек" - УЖЕ введённых стереотипов и проектных решений и строишь из них "новый город". Жмёшь кнопку "Next Turn" (кодогенерация) и смотришь что "построилось" в коде.
То же можно сказать и про тесты. Добавляешь новый тест. Изменяешь код. Жмёшь кнопку "Next Turn" (запуск тестового набора) и смотришь - как "поведёт себя противник".
По-моему - увлекательно. Да ещё за это и деньги платят.
Попробуйте посмотреть с этой стороны. Может быть вам понравится.
И процесс меня захватывал.
Особенно я любил поиграть в "конструкторские" игры типа Цивилизации или SimCity.
А потом - "как отрезало".
Я понял, что лично для меня программировать ГОРАЗДО интереснее.
Тот же UML. Берёшь "список доступных построек" - УЖЕ введённых стереотипов и проектных решений и строишь из них "новый город". Жмёшь кнопку "Next Turn" (кодогенерация) и смотришь что "построилось" в коде.
То же можно сказать и про тесты. Добавляешь новый тест. Изменяешь код. Жмёшь кнопку "Next Turn" (запуск тестового набора) и смотришь - как "поведёт себя противник".
По-моему - увлекательно. Да ещё за это и деньги платят.
Попробуйте посмотреть с этой стороны. Может быть вам понравится.
понедельник, 15 апреля 2013 г.
Исправление ошибок методом последовательных приближений (или методом "научного тыканья")
Проекты в нашей отрасли - сложные. Особенно если речь идёт о стыке алгоритмистики, бизнес-логики и пользовательского интерфейса.
Посему я лично не поручусь за себя, что могу обеспечить АНАЛИТИЧЕСКУЮ целостность решения. По молодости я пытался порождать "сферических коней в вакууме" и искать максимально общие правильные решения. Но с годами я понял, что я лично - не могу это осилить. Мысли разбегаются как тараканы. Начинаешь уходить в глубины деталей. Там и увязаешь.
Да и требования порой бывают противоречивые.
Я плохой математик. Никакой. В общем-то - посредственный программист и, уж конечно, - никакой аналитик. Я не умею решать задачи "сейчас и в общем".
Я скорее - "технарь" с "большим объёмом памяти" и набором сложившихся практик и типовых решений. (Как было подсказано - "типовые узлы" деталей и механизмов - сидят у меня в голове)
Посему - когда я натыкаюсь на заковыристую ошибку, то я поступаю следующим образом:
Я КОНЕЧНО сначала долго и вдумчиво трассирую систему, изучаю значения переменных и её поведение и стараюсь проникнуть в суть вещей. И понять логику системы. В этот момент я зачастую смотрю на систему и как на "белый" ящик и как на "чёрный".
Если мне это хоть как-то удаётся, то я поступаю так - http://18delphi.blogspot.com/2013/03/blog-post_54.html
Если не удаётся.
А это может быть по многим причинам:
1. Код написан коллегами, которые сейчас недоступны.
2. Пробелы в ТЗ.
3. Неясность логики.
4. Непонятные граничные условия.
5. Непредсказуемость данных.
6. Непредсказуемость поведения пользователя.
7. Сам писал "это", но забыл.
Тогда я поступаю следующим образом:
1. Прогоняю все доступные тесты. Убеждаюсь, что они срабатывают. Если не срабатывают, то разбираюсь с ними. Если не удалось разобраться, то отключаю их.
2. Смотрю на проблемное место.
3. Понимаю в каком месте логика пошла не так.
4. Разбиваю эту логику на несколько ветвей.
5. Те ветви, которые я не понимаю - я покрываю assert'ами (http://18delphi.blogspot.com/2013/04/blog-post.html).
6. Сосредотачиваюсь на ветке для исходной ошибки. Покрываю её тестом.
7. Убеждаюсь, что тест не проходит.
8. Пытаюсь исправить ошибку.
9. Убеждаюсь, что она исчезла. Руками.
10. Прогоняю тест и убеждаюсь, что он прошёл.
11. Прогоняю остальные тесты и смотрю - какие прошли, а какие нет.
12. Если тесты не прошли, то возвращаюсь к первому шагу.
13. Если тесты прошли - отправляю ошибку в Группу Качества.
14. Жду ответа от Группы Качества. Если они написали новые ошибки, то рассматриваю их отдельно. Если они вернули ЭТУ ошибку, то возвращаюсь к первому шагу.
15. В итоге - процесс обычно сходится.
P.S. как дополнительный "бенефит" - база тестов всё пополняется и пополняется.
Посему я лично не поручусь за себя, что могу обеспечить АНАЛИТИЧЕСКУЮ целостность решения. По молодости я пытался порождать "сферических коней в вакууме" и искать максимально общие правильные решения. Но с годами я понял, что я лично - не могу это осилить. Мысли разбегаются как тараканы. Начинаешь уходить в глубины деталей. Там и увязаешь.
Да и требования порой бывают противоречивые.
Я плохой математик. Никакой. В общем-то - посредственный программист и, уж конечно, - никакой аналитик. Я не умею решать задачи "сейчас и в общем".
Я скорее - "технарь" с "большим объёмом памяти" и набором сложившихся практик и типовых решений. (Как было подсказано - "типовые узлы" деталей и механизмов - сидят у меня в голове)
Посему - когда я натыкаюсь на заковыристую ошибку, то я поступаю следующим образом:
Я КОНЕЧНО сначала долго и вдумчиво трассирую систему, изучаю значения переменных и её поведение и стараюсь проникнуть в суть вещей. И понять логику системы. В этот момент я зачастую смотрю на систему и как на "белый" ящик и как на "чёрный".
Если мне это хоть как-то удаётся, то я поступаю так - http://18delphi.blogspot.com/2013/03/blog-post_54.html
Если не удаётся.
А это может быть по многим причинам:
1. Код написан коллегами, которые сейчас недоступны.
2. Пробелы в ТЗ.
3. Неясность логики.
4. Непонятные граничные условия.
5. Непредсказуемость данных.
6. Непредсказуемость поведения пользователя.
7. Сам писал "это", но забыл.
Тогда я поступаю следующим образом:
1. Прогоняю все доступные тесты. Убеждаюсь, что они срабатывают. Если не срабатывают, то разбираюсь с ними. Если не удалось разобраться, то отключаю их.
2. Смотрю на проблемное место.
3. Понимаю в каком месте логика пошла не так.
4. Разбиваю эту логику на несколько ветвей.
5. Те ветви, которые я не понимаю - я покрываю assert'ами (http://18delphi.blogspot.com/2013/04/blog-post.html).
6. Сосредотачиваюсь на ветке для исходной ошибки. Покрываю её тестом.
7. Убеждаюсь, что тест не проходит.
8. Пытаюсь исправить ошибку.
9. Убеждаюсь, что она исчезла. Руками.
10. Прогоняю тест и убеждаюсь, что он прошёл.
11. Прогоняю остальные тесты и смотрю - какие прошли, а какие нет.
12. Если тесты не прошли, то возвращаюсь к первому шагу.
13. Если тесты прошли - отправляю ошибку в Группу Качества.
14. Жду ответа от Группы Качества. Если они написали новые ошибки, то рассматриваю их отдельно. Если они вернули ЭТУ ошибку, то возвращаюсь к первому шагу.
15. В итоге - процесс обычно сходится.
P.S. как дополнительный "бенефит" - база тестов всё пополняется и пополняется.
вторник, 2 апреля 2013 г.
Подведение итогов дня
Вечером я гуляю с собакой.
Хожу и думаю. Подбиваю результаты. Собаке не очень это нравится. Ну а что делать...
Оцениваю - что получилось, а что нет. Ставлю - "галочки" - ЧТО ЖЕ я КОНКРЕТНО сделал. Хвалю себя, если есть за что.
Прикидываю план на следующий день. Расставляю приоритеты. Заношу заметки в телефон. Ставлю напоминалки - чтобы они на следующий день оповестили меня о том, что надо завести задачу.
Возвращаюсь домой и стараюсь выкинуть работу из головы. Совсем. До следующего утра.
Не всегда правда получается.
Хожу и думаю. Подбиваю результаты. Собаке не очень это нравится. Ну а что делать...
Оцениваю - что получилось, а что нет. Ставлю - "галочки" - ЧТО ЖЕ я КОНКРЕТНО сделал. Хвалю себя, если есть за что.
Прикидываю план на следующий день. Расставляю приоритеты. Заношу заметки в телефон. Ставлю напоминалки - чтобы они на следующий день оповестили меня о том, что надо завести задачу.
Возвращаюсь домой и стараюсь выкинуть работу из головы. Совсем. До следующего утра.
Не всегда правда получается.
Как поддерживать производительность труда и не терять самоуважения
Каждый день с утра, едучи на маршрутке на работу - я ставлю себе ЗАДАЧУ НА ДЕНЬ. Которую я должен сделать.
Это может быть:
1. Написание отлаженного класса.
2. Исправление ошибки.
3. Написание теста.
4. Реализация ТЗ.
5. Рисование UML-диаграммы.
6. Написание документации.
7. Уточнение ТЗ выразившееся в конкретные артефакты.
Хоть что-то из этого списка. А лучше - несколько. Болтовня в CQ и электронной почте в этот список не входит. Равно как и сёрфинг интернета. Равно как и болтовня на совещаниях. Важен РЕЗУЛЬТАТ, а не процесс
Должны быть артефакты, которые положены в CVS или SVN.
Если день прошёл без этого - я считаю день прожитым впустую.
Fire And Motion. Огонь и движение.
http://russian.joelonsoftware.com/Articles/FireAndMotion.html
http://www.joelonsoftware.com/articles/fog0000000056.html
Попробуйте. Может быть и вам понравится.
Это может быть:
1. Написание отлаженного класса.
2. Исправление ошибки.
3. Написание теста.
4. Реализация ТЗ.
5. Рисование UML-диаграммы.
6. Написание документации.
7. Уточнение ТЗ выразившееся в конкретные артефакты.
Хоть что-то из этого списка. А лучше - несколько. Болтовня в CQ и электронной почте в этот список не входит. Равно как и сёрфинг интернета. Равно как и болтовня на совещаниях. Важен РЕЗУЛЬТАТ, а не процесс
Должны быть артефакты, которые положены в CVS или SVN.
Если день прошёл без этого - я считаю день прожитым впустую.
Fire And Motion. Огонь и движение.
http://russian.joelonsoftware.com/Articles/FireAndMotion.html
http://www.joelonsoftware.com/articles/fog0000000056.html
Попробуйте. Может быть и вам понравится.
понедельник, 1 апреля 2013 г.
"Я же вам говорил!"
"Я же вам говорил!"
Это - неправильная фраза при согласовании ТЗ. А особенно для разработчика.
А особенно - когда он таки - оказался прав по результатам разработки.
Всё равно - ничего кроме негатива - она не несёт.
Не надо её использовать. Не надо "дразнить гусей". Это фраза не для разработчиков. Для КОГО УГОДНО, но только НЕ ДЛЯ разработчиков.
Просто - "поставьте себе галочку". Или напишите assert.
Я сам неоднократно пользовался этой фразой. Поверьте мне. И кроме негатива - я так ничего и не заработал.
И если услышите её из моих уст - напомните мне про этот пост.
P.S. эту фразу можете оставить только для САМЫХ БЛИЗКИХ ДРУЗЕЙ. Они вас наверное поймут.
Это - неправильная фраза при согласовании ТЗ. А особенно для разработчика.
А особенно - когда он таки - оказался прав по результатам разработки.
Всё равно - ничего кроме негатива - она не несёт.
Не надо её использовать. Не надо "дразнить гусей". Это фраза не для разработчиков. Для КОГО УГОДНО, но только НЕ ДЛЯ разработчиков.
Просто - "поставьте себе галочку". Или напишите assert.
Я сам неоднократно пользовался этой фразой. Поверьте мне. И кроме негатива - я так ничего и не заработал.
И если услышите её из моих уст - напомните мне про этот пост.
P.S. эту фразу можете оставить только для САМЫХ БЛИЗКИХ ДРУЗЕЙ. Они вас наверное поймут.
О ТЗ, цейтноте и "позабывании"
Фрейд З. ЗАБЫВАНИЕ ИНОСТРАННЫХ СЛОВ
Фрейд З. Психопатология обыденной жизни
З. Фрейд. Введение в психоанализ. Лекции >> Забывание имен собственных и иностранных названий, а также иностранных слов тоже можно свести к противоположному намерению, которое прямо или косвен...
Непроизвольная память
Людям свойственно забывать. Всем. Это - аксиома.
Руководству, дизайнерам, аналитикам, заказчикам (stakeholder'ам короче) - иногда свойственно не отвечать на ВСЕ заданные вопросы. Это - допущение. Если у вас не так - вам повезло. Тогда это пост не для вас. Не читайте. Спите спокойно.
Но! Часто бывает ситуация, когда ТЗ передано в разработку, но оно вызывает вопросы.
Делайте свою работу честно.
Нет ничего более ужасного, чем недовыясненные вопросы спрятанные в глубины вашего гениального кода. Его всё равно никто не оценит.
Уважайте своих коллег, которые придут "лет через десять после вас".
ЗАДАВАЙТЕ ВОПРОСЫ!
И ДОБИВАЙТЕСЬ ответов на них.
Если в процессе реализации ТЗ у вас возник вопрос требующий ответов stakeholder'ов, то для того, чтобы сохранять состояние "потока" и при этом НЕ СНИЖАТЬ темп разработки - я советую вам следующее:
1. Задайте вопрос.
2. УБЕДИТЕСЬ, что он дошел до адресата.
3. Напишите ASSERT. Да, да! Банальный assert с условием, которое вам непонятно.
4. Сформулируйте в комментариях к коду СУТЬ вопроса.
5. Укажите ДАТУ и время задания вопроса. По CVS это будет сделать муторно, да и лень.
6. Укажите номер "тикета" в базе данных или дайте ссылку на обсуждение, если оно проходит в электронном виде.
7. Предусмотрите более-менее вразумительное сообщение в лог для пользовательского варианта системы. ОТКЛЮЧАЙТЕ ASSERT'ы в пользовательском варианте системы.
8. Напишите - EXIT. Вдруг там дальше вы написали ёщё какой-то свой гениальный код.
9. Ждите ответа на вопрос и продолжайте реализацию ТЗ.
10. Если в течении "разумного" времени вы не получили ответа - дополните комментарий к коду подробностями - "когда, кто и где".
11. Если вы не получили ответов - закрывайте задачу и передавайте её в Группу Качества. Желательно при закрытии задачи указать список недовыясненных подробностей. Может быть группа качества поможет вам. И сразу откатит задачу с указанием подробностей.
12. Если вы получили ответ на вопрос - скажите "спасибо" тому, кто его дал. Ведь он - "сделал часть вашей работы".
13. Удалите ASSERT.
14. Напишите вменяемый код, учитывающий данный вам ответ.
15. Напишите тест - этот аспект системы занял не только ваше время и нервы, но и чужие. Он УЖЕ СТОИТ того, чтобы быть покрытым тестом.
16. Спите спокойно, пока какой-нибудь ASSERT не разбудит вас.
Попробуйте. Может вам понравится.
Сразу предупреждаю - может не понравиться stakeholder'ам. Но я бы - всё равно попробовал.
В конце концов - они честно делают свою работу , делайте и вы. Честно. И ДУМАЙТЕ о тех, кто придёт вам на смену. Они могут оказаться не такими гениальными как вы.
И если вы думаете - "ах у меня 800-т незаконченных задач. Ах как мне трудно.." Посмотрите сюда:
P.S. Есть и альтернативные сценарии. Но все они по-моему - менее выигрышные.
Вот как я их вижу:
1. Не задавать вопросы и полагаться на свои силы. Не считайте себя черезчур гениальным.
2. Не задавать вопросы и оставить всё как есть. По-моему - в не думаете о будущем.
3. Задать вопросы и переключится на другую задачу. Тут тратим силы и время на переключение контекстов и выход из одного "потока" и вход в другой. Это - затратно.
4. Задать вопросы и ждать все ответы на них. И ничего не делать. Я - так не умею. Я сразу начинаю мучатся безделием и терять уважение к самому себе.
5. Вернуть ТЗ на доработку и забыть о нём. "Пока эта вся бюрократия раскачается". Это - самый неконструктивный путь. Если вы выбираете его - подумайте - стоит ли вам работать программистом. "Просто получать деньги" - можно и в другом месте. Например на Forex. Или в других "мыльных пузырях".
Фрейд З. Психопатология обыденной жизни
З. Фрейд. Введение в психоанализ. Лекции >> Забывание имен собственных и иностранных названий, а также иностранных слов тоже можно свести к противоположному намерению, которое прямо или косвен...
Непроизвольная память
Людям свойственно забывать. Всем. Это - аксиома.
Руководству, дизайнерам, аналитикам, заказчикам (stakeholder'ам короче) - иногда свойственно не отвечать на ВСЕ заданные вопросы. Это - допущение. Если у вас не так - вам повезло. Тогда это пост не для вас. Не читайте. Спите спокойно.
Но! Часто бывает ситуация, когда ТЗ передано в разработку, но оно вызывает вопросы.
Делайте свою работу честно.
Нет ничего более ужасного, чем недовыясненные вопросы спрятанные в глубины вашего гениального кода. Его всё равно никто не оценит.
Уважайте своих коллег, которые придут "лет через десять после вас".
ЗАДАВАЙТЕ ВОПРОСЫ!
И ДОБИВАЙТЕСЬ ответов на них.
Если в процессе реализации ТЗ у вас возник вопрос требующий ответов stakeholder'ов, то для того, чтобы сохранять состояние "потока" и при этом НЕ СНИЖАТЬ темп разработки - я советую вам следующее:
1. Задайте вопрос.
2. УБЕДИТЕСЬ, что он дошел до адресата.
3. Напишите ASSERT. Да, да! Банальный assert с условием, которое вам непонятно.
4. Сформулируйте в комментариях к коду СУТЬ вопроса.
5. Укажите ДАТУ и время задания вопроса. По CVS это будет сделать муторно, да и лень.
6. Укажите номер "тикета" в базе данных или дайте ссылку на обсуждение, если оно проходит в электронном виде.
7. Предусмотрите более-менее вразумительное сообщение в лог для пользовательского варианта системы. ОТКЛЮЧАЙТЕ ASSERT'ы в пользовательском варианте системы.
8. Напишите - EXIT. Вдруг там дальше вы написали ёщё какой-то свой гениальный код.
9. Ждите ответа на вопрос и продолжайте реализацию ТЗ.
10. Если в течении "разумного" времени вы не получили ответа - дополните комментарий к коду подробностями - "когда, кто и где".
11. Если вы не получили ответов - закрывайте задачу и передавайте её в Группу Качества. Желательно при закрытии задачи указать список недовыясненных подробностей. Может быть группа качества поможет вам. И сразу откатит задачу с указанием подробностей.
12. Если вы получили ответ на вопрос - скажите "спасибо" тому, кто его дал. Ведь он - "сделал часть вашей работы".
13. Удалите ASSERT.
14. Напишите вменяемый код, учитывающий данный вам ответ.
15. Напишите тест - этот аспект системы занял не только ваше время и нервы, но и чужие. Он УЖЕ СТОИТ того, чтобы быть покрытым тестом.
16. Спите спокойно, пока какой-нибудь ASSERT не разбудит вас.
Попробуйте. Может вам понравится.
Сразу предупреждаю - может не понравиться stakeholder'ам. Но я бы - всё равно попробовал.
В конце концов - они честно делают свою работу , делайте и вы. Честно. И ДУМАЙТЕ о тех, кто придёт вам на смену. Они могут оказаться не такими гениальными как вы.
И если вы думаете - "ах у меня 800-т незаконченных задач. Ах как мне трудно.." Посмотрите сюда:
это - самоирония... если что...
P.S. Есть и альтернативные сценарии. Но все они по-моему - менее выигрышные.
Вот как я их вижу:
1. Не задавать вопросы и полагаться на свои силы. Не считайте себя черезчур гениальным.
2. Не задавать вопросы и оставить всё как есть. По-моему - в не думаете о будущем.
3. Задать вопросы и переключится на другую задачу. Тут тратим силы и время на переключение контекстов и выход из одного "потока" и вход в другой. Это - затратно.
4. Задать вопросы и ждать все ответы на них. И ничего не делать. Я - так не умею. Я сразу начинаю мучатся безделием и терять уважение к самому себе.
5. Вернуть ТЗ на доработку и забыть о нём. "Пока эта вся бюрократия раскачается". Это - самый неконструктивный путь. Если вы выбираете его - подумайте - стоит ли вам работать программистом. "Просто получать деньги" - можно и в другом месте. Например на Forex. Или в других "мыльных пузырях".
пятница, 29 марта 2013 г.
Как я исправляю ошибки
"Shit happens". Это постулат.
Если я получаю ошибку в разработку, то я делаю примерно следующее:
1. Выясняю все необходимые детали, если они ещё не выяснены.
2. Пишу тест (или прошу коллег сделать это, есть люди - более подкованные).
3. Идеально, если получается тест на синтетических данных и в "песочнице", а не на реальом приложении.
4. Если не получается, то я делаю скриптовый тест к реальному приложению. (Может быть когда-нибудь я дойду до того - как я это делаю)
5. Запускаю тест, убеждаюсь, что он падает.
6. Кладу тест и его эталоны в репозитарий.
7. Отлаживаю ошибку используя тест как полигон для испытаний.
8. Исправляю ошибку.
9. Убеждаюсь, что тест не падает.
10. Кладу исправленный код, тест и эталоны в репозитарий.
11. Прогоняю другие тесты.
12. Смотрю на упавшие.
13. Из упавших отбираю те где "это не ошибка, а стало только лучше". Исправляю эти тесты или их эталоны.
14. Исправляю остальные упавшие тесты или привлекаю коллег или УБЕЖДАЮСЬ в противоречивости ТЗ (тут надо писать ОТДЕЛЬНЫЙ пост - отчасти тут - http://18delphi.blogspot.com/2013/04/blog-post.html).
15. Прогоняю все тесты.
16. Убеждаюсь, что ошибок больше нет.
17. ОСТАВЛЯЮ НОВЫЙ тест в репозитарии тестов. ОТНЫНЕ - он работает на меня.
18. Сплю спокойно.
Попробуйте. Может быть и вам - понравится.
Если я получаю ошибку в разработку, то я делаю примерно следующее:
1. Выясняю все необходимые детали, если они ещё не выяснены.
2. Пишу тест (или прошу коллег сделать это, есть люди - более подкованные).
3. Идеально, если получается тест на синтетических данных и в "песочнице", а не на реальом приложении.
4. Если не получается, то я делаю скриптовый тест к реальному приложению. (Может быть когда-нибудь я дойду до того - как я это делаю)
5. Запускаю тест, убеждаюсь, что он падает.
6. Кладу тест и его эталоны в репозитарий.
7. Отлаживаю ошибку используя тест как полигон для испытаний.
8. Исправляю ошибку.
9. Убеждаюсь, что тест не падает.
10. Кладу исправленный код, тест и эталоны в репозитарий.
11. Прогоняю другие тесты.
12. Смотрю на упавшие.
13. Из упавших отбираю те где "это не ошибка, а стало только лучше". Исправляю эти тесты или их эталоны.
14. Исправляю остальные упавшие тесты или привлекаю коллег или УБЕЖДАЮСЬ в противоречивости ТЗ (тут надо писать ОТДЕЛЬНЫЙ пост - отчасти тут - http://18delphi.blogspot.com/2013/04/blog-post.html).
15. Прогоняю все тесты.
16. Убеждаюсь, что ошибок больше нет.
17. ОСТАВЛЯЮ НОВЫЙ тест в репозитарии тестов. ОТНЫНЕ - он работает на меня.
18. Сплю спокойно.
Попробуйте. Может быть и вам - понравится.
Подписаться на:
Сообщения (Atom)