ситуация, как я понимаю, совершенно типичная и на эти на эти грабли уже мильйон раз наступлено: IT стартап, который немножко вырос и нужно как-то организовать типа производственный процесс
( Read more... )
быренько, конспективненько, пока у меня тут как раз в agile перерыв: - откуда я знаю: я уже почти год руководю процессом постройки софта в одном небольшом консалтинге, за деньги, после работы. а еще, как мы знаем, работаю там, где, и мы тут как раз переходим на agile, кстати.
- что надо осознать, для того, чтобы понять, что делать и как:
что именно ты производишь: - продукт, который кто-то потом имплементирует? - вебсайт/веб аппликацию, на/в которую ты добавляешь функции? - технологическую фиговину, которую сама поддерживаешь и развиваешь?
кто у тебя есть, в штуках: - гении - программисты с оипытом - бизнес аналитики - токари-универсалы - и так далее
чего ты хочешь от жизни, чтоб куда оно дальше двигалось?
"На выпускном экзамене в школе милиции дали задание вставить деревянные пирамиду, шар и кубик в соответствующие отверстия в доске. Экзаменуемые разделились на две категории: очень глупые и очень сильные."
Но на самом деле, правильная организация процесса описана другой цитатой:
"Каждое рабочее место оборудуется двумя табличками, "кофе" и "минет". У работников, справляющихся со своими обязанностями, под табличками монтируются кнопки. Соответственно, у остальных работников - лампочки".
Светка, привет! Я ни разу не теоретик в этих вещах и книжка Макконнелла давно уже запылилась. Есть только долгий опыт участия в 2-х процессах. Один из них налажваал, по вольшей части, сам, в другом - взаимодействовал с Tooling-командой. Мне кажется, самое интересное, это то, как меняется стиль работы (если не сказать, сознание) девелопера при переходе со стартапа на регулярный процесс. Можно потрепаться на эту тему. А выбирать, скрам, канбан или ваще, водопад - это, ну как суженого выбирать: факторов и советчиков в избытке. Но переключиться с одного на другого всё же проще, чем в реале.
у меня Катька болела и я немножко выпала из рабочих проблем. Но ты прямо в точку попал: мне совершенно необходимо потрепаться на тему, как меняется стиль работы и сознание. И как их менять. И куда
Хорошо, что вовремя опознали заразу. Я вот тоже недавно этой пневмонией... впрочем, да ну её, есть более интересные темы поговорить.
Вот, год назад появился у нас в Калифорнии новый коллега. И взял быка за рога: в первую же неделю выкатил один коммит на полсотни файлов. Где-то порефакторил старый код, где-то форматирование поправил, заодно пару багов пофиксил. И отправил на ревью. Люди вначале повелись: количество комментариев за сотню перевалило. Потом, когда увидели, что коммит еще и тесты поломал, откатили все разом. Но время было убито.
Из этой можно сделать два вывода. Во-первых, в промышленной разработке важен не только внятный код, но и внятная история кода. То, что нельзя смешивать в одном коммите форматирование, рефакторинг и багфиксы, наш коллега вроде понял. Но на прошлой неделе пришлось опять вести с ним воспитательную беседу
( ... )
Comments 19
agile - это не очевидно плохо, все очень зависит.
позвони - поговорим :)
Reply
Reply
в субботу вечерком тогда, после 8:30, или в воскресенье :-)
Reply
- откуда я знаю:
я уже почти год руководю процессом постройки софта в одном небольшом консалтинге,
за деньги, после работы.
а еще, как мы знаем, работаю там, где, и мы тут как раз переходим на agile, кстати.
- что надо осознать, для того, чтобы понять, что делать и как:
что именно ты производишь:
- продукт, который кто-то потом имплементирует?
- вебсайт/веб аппликацию, на/в которую ты добавляешь функции?
- технологическую фиговину, которую сама поддерживаешь и развиваешь?
кто у тебя есть, в штуках:
- гении
- программисты с оипытом
- бизнес аналитики
- токари-универсалы
- и так далее
чего ты хочешь от жизни, чтоб куда оно дальше двигалось?
кто у тебя клиент?
Reply
Reply
но вот че-та пока в фб не напишешь, народ и не отзывается
Reply
Reply
Reply
Reply
а ты про что?
Reply
сильные."
Reply
"Каждое рабочее место оборудуется двумя табличками, "кофе" и "минет". У работников, справляющихся со своими обязанностями, под табличками монтируются кнопки. Соответственно, у остальных работников - лампочки".
Reply
Я ни разу не теоретик в этих вещах и книжка Макконнелла давно уже запылилась. Есть только долгий опыт участия в 2-х процессах. Один из них налажваал, по вольшей части, сам, в другом - взаимодействовал с Tooling-командой.
Мне кажется, самое интересное, это то, как меняется стиль работы (если не сказать, сознание) девелопера при переходе со стартапа на регулярный процесс. Можно потрепаться на эту тему.
А выбирать, скрам, канбан или ваще, водопад - это, ну как суженого выбирать: факторов и советчиков в избытке. Но переключиться с одного на другого всё же проще, чем в реале.
Reply
Reply
Вот, год назад появился у нас в Калифорнии новый коллега. И взял быка за рога: в первую же неделю выкатил один коммит на полсотни файлов. Где-то порефакторил старый код, где-то форматирование поправил, заодно пару багов пофиксил. И отправил на ревью. Люди вначале повелись: количество комментариев за сотню перевалило. Потом, когда увидели, что коммит еще и тесты поломал, откатили все разом. Но время было убито.
Из этой можно сделать два вывода. Во-первых, в промышленной разработке важен не только внятный код, но и внятная история кода. То, что нельзя смешивать в одном коммите форматирование, рефакторинг и багфиксы, наш коллега вроде понял. Но на прошлой неделе пришлось опять вести с ним воспитательную беседу ( ... )
Reply
Leave a comment