Чи добре працює ваша команда, не дотримуючись методології роботи (наприклад, scrum)?

Я працював у низці невеликих команд протягом останніх 9 років. Кожен мав очевидні добрі практики, такі як короткі зустрічі, контроль за редакцією, програмне забезпечення для постійної інтеграції, відстеження випусків тощо.

За ці 9 років я ніколи не чув багато про методики розвитку; наприклад, ніколи не було "ми робимо scrum", або "давайте робити спритний", або що-небудь більше, ніж проходження посилання. Усі команди, здавалося, добре функціонують, не дотримуючись особливих процесів, ми просто переповнювались і просто природно працювали добре.

Хтось ще прогресував протягом тривалого періоду часу, не стикаючись з scrum / agile / тощо?

Єдине опромінення, яке я мав до цього, - це на таких сайтах. Я читаю такі питання, як спринт-зустрічі - про що говорити ... і всі розмови, здається, описують майже робототехнічні, як люди, які дотримуються методології обмеженого стану. Це справді (хоча й перебільшено)? Цікаво, чи люди, які розміщують в Інтернеті просто голосні прихильники "найкращої практики", з подібними поглядами на підручники, насправді не відображають, як люди працюють ... Або що я стикався з деякими командами, що складають свої процеси природно.

Крім того (я перебуваю у Великобританії, що може бути доречно) ... Я думаю, якби методологія була введена для будь-якої команди, над якою я працював, вони просто відкинуть її як дурну та непотрібну ... на. Я схильний погодитися, наступні процеси здаються трохи неприродними. Це типово чи часто?

Більше 20 років досвіду розвитку тут, і я ніколи не використовував офіційну методологію. Вони ніколи не потребували їх, і я не планую їх використовувати в майбутньому. Методології для деяких людей можуть бути нормальними, але вони не заміняють кваліфікованих програмістів, які пишуть хороший перевірений код.

Особисто я думаю, що було б багато людей, які б менше піклувалися про дотримання найгарячішої нової методології дня та більше зосереджувались на якості коду.

Чесно кажучи, якщо ваша маленька команда всі ці роки добре працювала без великих інцидентів, не замислюючись над процесом, ви, ймовірно, робили якусь форму спритного. Все спритний процес означає, що він відповідає "Agile Manifesto" http://agilemanifesto.org/, який має мало дивного сказання про ітеративні дошки, дошки тощо. Найпершим орендарем спритного є те, що ви віддаєте перевагу "Особи та взаємодії над процесами та інструментами ". Будь-яка команда, яка добре працює разом, насправді не потребує багато задумуватися над процесом.

Різні спритні бренди (як Scrum тощо) дуже корисні, якщо у вас абсолютно нова команда, яка не звикла працювати один з одним. Вони свого роду встановлюють основи для того, як створити згуртовану команду, яка, в свою чергу, створить згуртований продукт.

Якщо те, що ти робиш, працює, продовжуй це робити. Якщо ви постійно запізнюєтеся з результатами, вам доводиться регулярно витягувати понаднормово або виправляти основні помилки після того, як щось розгортаєте - значить, щось не так. Саме тоді ви вносите ряд невеликих змін, щоб усунути проблеми.

Якщо все добре, і це завжди добре, тоді немає жодних проблем - тому впровадження нової (ваші команди дотримуватимуться певної методології - формальної чи іншої) методології справді буде марною тратою часу.

Якщо методології справді допомагають, це коли команда стикається з проблемами або має проблеми, поставлені перед ними із зовнішніх джерел - методологія не просто запроваджує належну практику, вона допомагає вам їх захистити . Набагато простіше підтримувати добру практику в умовах стресу, коли ти їх свідомо робиш, інакше вони можуть швидко вичавитись.

Я не думаю, що вам обов'язково потрібна формальна методологія - але кожній команді потрібна якась схема (не обов'язково повторювана, це може бути спричинено подією), щоб їх робота була ефективною ІМХО.

Якщо у вас немає проблем вирішити, пощастило вам.

Я бачив, що багато команд (особливо в дуже малих компаніях) працюють добре без визначеної методології.

Запровадити методологію (або техніку) тому, що це весело або тому, що ви читаєте цю публікацію в Інтернеті дуже небезпечно.

Якщо ви добре, нічого не змінюйте. Просто спробуйте деякі оптимізації, коли зможете.

Існує величезний набір методологій, деякі досить розумні, деякі межують з божевільним. Вони, схоже, кодифікують здоровий глузд , дають їм кумедне ім’я, а потім продають багато книг / семінарів / тощо.

Тепер, якщо вашому керівництву або, власне, вашій команді бракує здорового глузду, і органічно не існує власних розумних методологій (свідомо чи невимовно), то, можливо, варто їх вивчити, а потім взяти на борт частини методики. відповідно до досвіду цієї команди .

Нав'язування найостанніших <insert-buzzword-here>практик роботи може викликати більше плутанини, ніж воно має на меті вирішити. Але, як правило, можна надати безліч показників прапорців, які менеджер рядків, що не кодують, може з ентузіазмом поставити галочку.

Можливо, ви не назвали це спритним або негідним, але це не означає, що ви не мали жодного процесу і не використовували його.

Так само, як і сама розробка програмного забезпечення. Ви, ймовірно, будете використовувати декілька моделей дизайну, навіть якщо ви прямо не думаєте про них своїми іменами.